From arno@natisbad.org Fri May 1 01:24: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 DEBA23A700A for ; Fri, 1 May 2009 01:24:53 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 1hpr6Bva4Ykl for ; Fri, 1 May 2009 01:24:53 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id DBC433A6E0A for ; Fri, 1 May 2009 01:24:52 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Lzo4R-0001AK-Ok; Fri, 01 May 2009 10:26:12 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Victor Blake" References: <003801c9c9de$f6323ce0$e296b6a0$@com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090501:mext@ietf.org::GM168mnlYjEufQjZ:00007TLL X-Hashcash: 1:20:090501:vrparente@aol.com::d0X5Caio1pQHqn8U:00000000000000000000000000000000000000000000Ago0 Date: Fri, 01 May 2009 10:26:58 +0200 In-Reply-To: <003801c9c9de$f6323ce0$e296b6a0$@com> (Victor Blake's message of "Thu, 30 Apr 2009 17:59:38 -0400") Message-ID: <87ws915iul.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] MEXT Digest, Vol 22, Issue 23 draftebalard-mext-hld-security-00.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, 01 May 2009 08:24:54 -0000 Hi Victor, "Victor Blake" writes: > Your assumption in 4.1 is that the HA relies exclusively on the BU message > from the MN. AFAICT, this is what RFC 3775 specifies. Hence my concerns. > In fact an HA can rely not only on the BU message itself, but also the > source of the update (BU). That is that the HA, may (not necessarily > but could) know about the Layer 2 source address of MN to validate the > update is coming from the MN it says it is coming from based on > the L3 address. In short, the L2 and L3 address can be correlated. I am not sure introducing the L2 address in the solution space will help but I may be wrong. Anyway, this will not solve the issue because the MN may still act (drop protection) upon reception of a fake RA. Such a proposal may help preventing the emission of the BA but this is just a workaround. > I believe that there could be other stateful methods as well uses > other link attachment mechanisms such as MIH, DNA, or FMIP in which > the sequence in the state machine would not be valid if such an attack > occurred within the appropriate preceeding and post registration > events. It's possible. But this would be worth looking if the same kind of attacks apply or not. I would bet that the Security Considerations sections of associated documents do not consider such attacks. > If we try to address the argument beyond just that particular message > to other DoS, I think it is true that there could be cause for > concern. However, regardless of IPsec, Layer 2 DoS attacks would in > any event still be possible. Right ? I agree with you that DoS attacks against a MN are possible (easy) but there are (at least in my opinion) a limited concern compared to attacks that may lead an IPsec-protected MN to drop its protection in front of an attacker. RFC 3775 does not prevent a particular implementation to test the link/path it is switching to in order to verify that it indeed provides some real connectivity to the outside world (i.e. to the Home Agent). At the moment, a RFC3775-compliant MN has no way to be sure that the router advertising its Home Prefix is indeed its HA, i.e. that it is at home. Thanks for your comments, Victor. Cheers, a+ From tsirtsis@googlemail.com Fri May 1 02:28: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 928983A681A for ; Fri, 1 May 2009 02:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.121, 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 NaR86a+lzeRg for ; Fri, 1 May 2009 02:28:16 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id 6C8E93A67EB for ; Fri, 1 May 2009 02:28:16 -0700 (PDT) Received: by gxk10 with SMTP id 10so4713610gxk.13 for ; Fri, 01 May 2009 02:29:39 -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:content-type :content-transfer-encoding; bh=+EZI+NQSVHtnSTTbO8jvu7BGWnaG8d2ODGR9RmjhqX8=; b=O2s9+LfunMxHrxsc9RuRgwgQIgr516l50+j9FVEUg+gqtF2VsDjdovcsS5Le04tZb5 86hIgWxd7Pjf7QK+7vMHjqbWhy64men+3pOxbSkQ6S9Sws0jWWz13cIaepbLbgYiXyxv VjkPwRrD0pb0bsFWmLt/ti+l2orFK9CCNM5ww= 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 :content-type:content-transfer-encoding; b=mdjEapB87dCESJDPhmYquGtAyhti4Lq7tN7q8BApIQXUB7yqBRfNowc+l3zJWE76hN YMsJ5+5xGn8EE404CPiKGZ7jeyY/teXGimTutA1YtycAtnFCTOTdajXbXmVOIZQXRNHB ga2/YCHdtHrpQkGQThE0rfJ7jf4Dbcx+u4vNI= MIME-Version: 1.0 Received: by 10.90.100.20 with SMTP id x20mr2104733agb.43.1241170179562; Fri, 01 May 2009 02:29:39 -0700 (PDT) In-Reply-To: <20090430224501.6387828C137@core3.amsl.com> References: <20090430224501.6387828C137@core3.amsl.com> Date: Fri, 1 May 2009 10:29:39 +0100 Message-ID: From: George Tsirtsis To: mext Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] Fwd: I-D ACTION: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, 01 May 2009 09:28:17 -0000 Hi all, We just published a new version of the flow bindings draft. Marcelo, we think this is ready for WGLC, and there is enough interest and momentum at the moment to get a good set of reviews in a reasonable time frame. I also just submitted draft-tsirtsis-mext-binary-filters-00.txt which is defining the binary flow descriptors as discussed, I am requesting to take this up as a MEXT WG document. Thanks George ---------- Forwarded message ---------- From: Date: Thu, Apr 30, 2009 at 11:45 PM Subject: I-D ACTION:draft-ietf-mext-flow-binding-02.txt To: i-d-announce@ietf.org Cc: mext@ietf.org 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. =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Flow = Bindings in Mobile IPv6 and Nemo Basic Support =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : G. Tsirtsis, H.= Soliman, N. Montavont, G. Giaretta, K. Kuladinithi =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf= -mext-flow-binding-02.txt =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 33 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = 2009-4-30 This document introduces extensions to Mobile IPv6 that allow nodes =C2=A0 to bind one or more flows to a care-of address. =C2=A0These extensio= ns =C2=A0 allow multihomed nodes to instruct their peers to direct downlink =C2=A0 flows to specific addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-02.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. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From marcelo@it.uc3m.es Fri May 1 02:32: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 9702A28C18D for ; Fri, 1 May 2009 02:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 uqqoAufJUofc for ; Fri, 1 May 2009 02:32:16 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A04F428C1B4 for ; Fri, 1 May 2009 02:31:00 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (112.pool85-53-134.dynamic.orange.es [85.53.134.112]) by smtp02.uc3m.es (Postfix) with ESMTP id E66FE65564F; Fri, 1 May 2009 11:32:19 +0200 (CEST) Message-ID: <49FAC1A2.7060206@it.uc3m.es> Date: Fri, 01 May 2009 11:32:18 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext References: <49EF37D8.2010408@it.uc3m.es> In-Reply-To: <49EF37D8.2010408@it.uc3m.es> 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-16614.006 Cc: Jari Arkko Subject: Re: [MEXT] Moving forward with MEXT documents 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, 01 May 2009 09:32:17 -0000 FWIW, the deadline for this is about the expire and we only received a couple of volunteers so far. marcelo bagnulo braun escribió: > Hi, > > At this point in time, the WG has the following documents that are > ready for WGLC: > > draft-ietf-mext-firewall-admin-00 > draft-ietf-mext-firewall-vendor-00 > draft-ietf-mip6-hareliability-04 > draft-ietf-monami6-mipv6-analysis-05 > draft-ietf-monami6-multihoming-motivation-scenario-03 > > And the following document that we need to ask for adoption: > > draft-premec-mext-extended-home-link-01 > > According to our new ground rules, each of these documents to proceed > will need 5 thorough reviews. Since this is a considerable amount of > effort from the WG, we would like soem feedback on how to manage this > effort. In particular, we would like to get feedback from the WG about > which documents should we issue the WGLC or adoption call first and if > possible volunteers to do the reviews for the documents. > > We will receive input on this till the 3rd of may and then decide how > to move forward. > > Regards, marcelo > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From kaaspetersen@yahoo.dk Fri May 1 04:37: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 722A63A688D for ; Fri, 1 May 2009 04:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 ly0Ds3lbG63J for ; Fri, 1 May 2009 04:37:41 -0700 (PDT) Received: from web27801.mail.ukl.yahoo.com (web27801.mail.ukl.yahoo.com [217.146.182.6]) by core3.amsl.com (Postfix) with SMTP id 45F553A682A for ; Fri, 1 May 2009 04:37:41 -0700 (PDT) Received: (qmail 77128 invoked by uid 60001); 1 May 2009 11:39:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1241177944; bh=ajJxawdF61i6pTwO+quCqt1QQ9ivia4Bz/IvHLqB80A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=srE/Kofo/cEHtF1yPyayPHTOUTyxttQbZaZa62zBlLF8LrSd+H+ZRIBMsL4wK4UnkArNOJkCRMykL5iB0qlQIwAKo2gG0S7STqVWAntMaw3ZmW4gxibPK/elevbm7Y1RERuJBAjqRs1y38XZ0V1zxWa1HAdZx7XcsXZSzumJoPg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f1OrbJDFF/aR5L+k/nmyBltL5PkCvMKeIpdlL76Y/EffmPJTRmj19IXAEJJ3YxcQ3jD0kGLUT9NPYFUGzIS2ZVrSUK4MHCkCdwFnGhiO/Z/p3uXPL1TjsD49J8UJzNFlxTURmCHIXDGQ2fQ+e02nRh9SaZDOwj6B5Niaq3X0Sy0=; Message-ID: <296286.77052.qm@web27801.mail.ukl.yahoo.com> X-YMail-OSG: JIZgrmEVM1lvpcxEnoTq4qLERRkEv2bbwtBKfEO3MG.q26BkzE7hyFKV Received: from [193.15.240.60] by web27801.mail.ukl.yahoo.com via HTTP; Fri, 01 May 2009 11:39:03 GMT X-Mailer: YahooMailClassic/5.2.20 YahooMailWebService/0.7.289.1 Date: Fri, 1 May 2009 11:39:03 +0000 (GMT) From: Christian Kaas-Petersen To: mext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] flow binding draft 2 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, 01 May 2009 11:37:42 -0000 Having read draft-ietf-mext-flow-binding-02, I should like to be informed about two design rationales. The first is related to the PRO field in the Flow Identification Mobility Option. The mobile node must explicitly inform if it is an Add or a Modify operation; the mobile node does implicitly inform if it is a delete operation. In principle there is no need for the PRO field. There are three cases. (a) If a FID-value is absent in BU and present in Flow Binding List =3D> remove (b) If a FID-value is present in BU and absent in Flow Binding List =3D> add (c) If a FID-value is present in BU and present in Flow Binding List =3D> modify With these cases PRO field can be removed. Alternatively, one could take the other extreme, also explicitly naming the FID-values to be removed. The document has made an in-between choice. I'm not suggesing a change, I'm looking for an explanation. The other item relates to what in section 4.4 is denoted a "valid BID". When a BU wants to insert a FID-entry, and this FID-entry refers to one or more BID-values, all of those BID values must be found in the BID Entries List, and thus an entry will always achieve the Active state. However, at later times BID-entries may be removed, and so a state may change to Inactive. What is reason for a state not being allowed Inactive to start with? Again, I'm just looking for an explanation. A few minor points. * Abstract: uses the word "peer" as a short term for correspondent node, home agent, and mobility anchor point. In general, a mobile node's peers are all the nodes with which it has TCP/UDP sessions. I think the term "peer" has a too wide interpretation. * Section 4.1, in the description of BID-PRI field, the words "a higher number" assumes reading the 7-bit field as an unsigned integer. * Section 4.2, in FID description, 8-bit should be 16-bit. * Section 4.2, in 1 Forward, a forward reference for Binding Reference sub-option would be helpful when reading this document first time. * Section 4.3, in Option Type, I think a copy from the section 4.2.1. * Section 4.4, para 2, one of the words "change" or "modify" should be enough. * Section 4.4, Action bullet: "PRO field" to be replaced with "Action field". * Section 4.4, para just above Ordered Flow Binding Entries, "three flow bindings" to become "four flow bindings". Christian =0A=0A=0A Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - = http://dk.yahoo.com/r/pat/mm From tsirtsis@googlemail.com Fri May 1 05:09: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 C27E328E04F for ; Fri, 1 May 2009 05:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_36=0.6, SARE_LWSHORTT=1.24] 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 M9y34SlMm3I9 for ; Fri, 1 May 2009 05:09:54 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id E995C28C670 for ; Fri, 1 May 2009 05:03:03 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so2630285yxb.49 for ; Fri, 01 May 2009 05:04:26 -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=KnnHhtOWmn1Q2AYjwo9xlek+jE5EBj93hauIGuU6j6g=; b=KBuF1YYPXSBcE/SopNE2+8ayctnEbv6mkj9lsccIlbznHdzP1N1emxFtREax+iYamz QH+zHxG7DM+kc60Xh/vr/czQjPEIHjBccuc1pgGufZsX3YuDVKhjaIwwLmKt8UUJlt7V 9Kd9iZwN0wHR/8vTGP9LX7dzF/5VJUgEFLj7k= 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=wg+YQfAGvPGnUnPR6pYa6nJPSwUAIGT8ReCx9oxR38IFzTp23mxgixengFUCH4T65I WjOCKh7Uv4AR7IXcK8e36ePo+lbENnhNgb7ZvAh0Vjd6gP/Ihc6M3Wem3CNygAAfbgHO vgIUme7GiFdHcvHKRnr38/q1YGKHZEBIC4zW0= MIME-Version: 1.0 Received: by 10.90.104.15 with SMTP id b15mr2193246agc.98.1241179466013; Fri, 01 May 2009 05:04:26 -0700 (PDT) In-Reply-To: <296286.77052.qm@web27801.mail.ukl.yahoo.com> References: <296286.77052.qm@web27801.mail.ukl.yahoo.com> Date: Fri, 1 May 2009 13:04:25 +0100 Message-ID: From: George Tsirtsis To: Christian Kaas-Petersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 01 May 2009 12:09:57 -0000 Hi Christian, Wow, very quick turnaround, and a good review, thanks! Marcelo, are you counting? :-) See comments inline... On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen wrote: > > Having read draft-ietf-mext-flow-binding-02, I should like to be > informed about two design rationales. > > The first is related to the PRO field in the Flow Identification Mobility > Option. =C2=A0The mobile node must explicitly inform if it is an Add or a > Modify operation; the mobile node does implicitly inform if it is a > delete operation. =C2=A0In principle there is no need for the PRO field. > There are three cases. > > (a) If a FID-value is absent in BU and > =C2=A0 =C2=A0present in Flow Binding List =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D>= remove > (b) If a FID-value is present in BU and > =C2=A0 =C2=A0absent in Flow Binding List =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D>= add > (c) If a FID-value is present in BU and > =C2=A0 =C2=A0present in Flow Binding List =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D>= modify > > With these cases PRO field can be removed. =C2=A0Alternatively, one could= take > the other extreme, also explicitly naming the FID-values to be removed. > GT> You are right that instead of ADD/MOFIDY we can always overwrite existing FID with new FIDs when they already exists and add them when the do not exists. The reason, however, we left the ADD/MODIFY is to make it easier for the MN and HA to catch errors e.g., cases where the MN things its adding something new but the FID actually already exists. Or the case where the MN thinks its modifying something but the HA has no record of that. Unlike ADD and MODIFY, the REMOVE value is creating more trouble than it is worth. Given the soft-state nature of the protocol it is important to refresh all FIDs in all BUs, so if an FID is not included in a BU it MUST be removed. The PRO=3DREMOVE, then creates two ways of doing the same thing (remove FID by not including it in BU, or by setting PRO=3DREMOVE), which is something we wanted to avoid GT>> Again, I think your proposal to drop PRO is not unreasonable, it is just that RPO field provides an error detection functions which we think could be useful. > The document has made an in-between choice. =C2=A0I'm not suggesing a cha= nge, > I'm looking for an explanation. > GT> I hope the above satisfies you? > The other item relates to what in section 4.4 is denoted a "valid BID". > When a BU wants to insert a FID-entry, and this FID-entry refers to one > or more BID-values, all of those BID values must be found in the > BID Entries List, and thus an entry will always achieve the Active state. > However, at later times BID-entries may be removed, and so a state may > change to Inactive. =C2=A0What is reason for a state not being allowed > Inactive to start with? =C2=A0Again, I'm just looking for an explanation. > GT> It is not clear why the MN would create an entry that is inactive to begin with. It seems to me that the entry can always be created when the MN actually needs it. The reason Inactive FIDs are defined in the draft is to handle the case where BIDs are subsequently removed. Without the inactive FID concept this would mean an implicit removal of FIDs pointing to the removed BID. That again could cause confusion since it would create two ways of removing an FID entries (remove FID by not including it in BU, or by removing all of the BIDs associated with it) GT> So, we could allow the MN to add an inactive FID entry, but the added complication does not seem to provide useful flexibility. > A few minor points. > GT> All of your minor points are welcome and will be corrected in the next version of the draft. > =C2=A0* Abstract: uses the word "peer" as a short term for correspondent = node, > =C2=A0 home agent, and mobility anchor point. =C2=A0In general, a mobile = node's > =C2=A0 peers are all the nodes with which it has TCP/UDP sessions. =C2=A0= I think > =C2=A0 the term "peer" has a too wide interpretation. > > =C2=A0* Section 4.1, in the description of BID-PRI field, the words "a hi= gher > =C2=A0 number" assumes reading the 7-bit field as an unsigned integer. > > =C2=A0* Section 4.2, in FID description, 8-bit should be 16-bit. > > =C2=A0* Section 4.2, in 1 Forward, a forward reference for Binding Refere= nce > =C2=A0 sub-option would be helpful when reading this document first time. > > =C2=A0* Section 4.3, in Option Type, I think a copy from the section 4.2.= 1. > > =C2=A0* Section 4.4, para 2, one of the words "change" or "modify" should= be > =C2=A0 enough. > > =C2=A0* Section 4.4, Action bullet: "PRO field" to be replaced with > =C2=A0 "Action field". > > =C2=A0* Section 4.4, para just above Ordered Flow Binding Entries, "three= flow > =C2=A0 bindings" to become "four flow bindings". > > Christian > > > > > =C2=A0 =C2=A0 =C2=A0Find din nye laptop p=C3=A5 kelkoo.dk. Se de gode til= bud her - http://dk.yahoo.com/r/pat/mm > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From Vrparente@aol.com Fri May 1 06:44: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 3B48E3A6C04 for ; Fri, 1 May 2009 06:44:11 -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 UxoWQJ4VtPxE for ; Fri, 1 May 2009 06:44:10 -0700 (PDT) Received: from imo-m23.mx.aol.com (imo-m23.mx.aol.com [64.12.137.4]) by core3.amsl.com (Postfix) with ESMTP id 3185E3A6A6E for ; Fri, 1 May 2009 06:44:10 -0700 (PDT) Received: from imo-m19.mx.aol.com (imo-m19.mx.aol.com [64.12.137.11]) by imo-m23.mx.aol.com (v107.10) with ESMTP id RELAYIN1-249fafc7120a; Fri, 01 May 2009 09:43:14 -0400 Received: from imo-m27.mx.aol.com (imo-m27.mx.aol.com [64.12.137.8]) by imo-m19.mx.aol.com (v107.10) with ESMTP id RELAYIN3-449fafc612de; Fri, 01 May 2009 09:42:57 -0400 Received: from imo-m28.mx.aol.com (imo-m28.mx.aol.com [64.12.137.9]) by imo-m27.mx.aol.com (v107.10) with ESMTP id RELAYIN1-249fafc5b61; Fri, 01 May 2009 09:42:51 -0400 Received: from imo-m19.mx.aol.com (imo-m19.mx.aol.com [64.12.137.11]) by imo-m28.mx.aol.com (v107.10) with ESMTP id RELAYIN1-249fafc4d1d1; Fri, 01 May 2009 09:42:37 -0400 Received: from imo-ma04.mx.aol.com (imo-ma04.mx.aol.com [64.12.78.139]) by imo-m19.mx.aol.com (v107.10) with ESMTP id RELAYIN1-249fafc4817; Fri, 01 May 2009 09:42:32 -0400 Received: from Vrparente@aol.com by imo-ma04.mx.aol.com (mail_out_v40_r1.5.) id o.d1f.4766b917 (34940); Fri, 1 May 2009 09:41:56 -0400 (EDT) Received: from Study ([216.246.69.52]) by cia-da05.mx.aol.com (v123.4) with ESMTP id MAILCIADA051-887c49fafc22f0; Fri, 01 May 2009 09:41:55 -0400 From: "Victor Blake" To: "'Arnaud Ebalard'" References: <003801c9c9de$f6323ce0$e296b6a0$@com> <87ws915iul.fsf@small.ssi.corp> In-Reply-To: <87ws915iul.fsf@small.ssi.corp> Date: Fri, 1 May 2009 09:41:27 -0400 Message-ID: <002501c9ca62$8800f660$9802e320$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnKNoLnSfNoaJboRqWJMfKIhwouOwAK6rqg Content-Language: en-us X-AOL-IP: 64.12.137.11 Cc: mext@ietf.org Subject: Re: [MEXT] MEXT Digest, Vol 22, Issue 23 draftebalard-mext-hld-security-00.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, 01 May 2009 13:44:11 -0000 Arnaud, To be clear, I wasn't suggesting that a Layer 2 to 3 address match be required, just that (as you say towards the end of your reply) it is permissible and found in some products. Thanks for your response. -Victor -----Original Message----- From: Arnaud Ebalard [mailto:arno@natisbad.org] Sent: Friday, May 01, 2009 4:27 AM To: Victor Blake Cc: mext@ietf.org Subject: Re: [MEXT] MEXT Digest, Vol 22, Issue 23 draftebalard-mext-hld-security-00.txt Hi Victor, "Victor Blake" writes: > Your assumption in 4.1 is that the HA relies exclusively on the BU message > from the MN. AFAICT, this is what RFC 3775 specifies. Hence my concerns. > In fact an HA can rely not only on the BU message itself, but also the > source of the update (BU). That is that the HA, may (not necessarily > but could) know about the Layer 2 source address of MN to validate the > update is coming from the MN it says it is coming from based on > the L3 address. In short, the L2 and L3 address can be correlated. I am not sure introducing the L2 address in the solution space will help but I may be wrong. Anyway, this will not solve the issue because the MN may still act (drop protection) upon reception of a fake RA. Such a proposal may help preventing the emission of the BA but this is just a workaround. > I believe that there could be other stateful methods as well uses > other link attachment mechanisms such as MIH, DNA, or FMIP in which > the sequence in the state machine would not be valid if such an attack > occurred within the appropriate preceeding and post registration > events. It's possible. But this would be worth looking if the same kind of attacks apply or not. I would bet that the Security Considerations sections of associated documents do not consider such attacks. > If we try to address the argument beyond just that particular message > to other DoS, I think it is true that there could be cause for > concern. However, regardless of IPsec, Layer 2 DoS attacks would in > any event still be possible. Right ? I agree with you that DoS attacks against a MN are possible (easy) but there are (at least in my opinion) a limited concern compared to attacks that may lead an IPsec-protected MN to drop its protection in front of an attacker. RFC 3775 does not prevent a particular implementation to test the link/path it is switching to in order to verify that it indeed provides some real connectivity to the outside world (i.e. to the Home Agent). At the moment, a RFC3775-compliant MN has no way to be sure that the router advertising its Home Prefix is indeed its HA, i.e. that it is at home. Thanks for your comments, Victor. Cheers, a+ From kaaspetersen@yahoo.dk Fri May 1 07:03: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 2526628C1A4 for ; Fri, 1 May 2009 07:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, SARE_LWSHORTT=1.24] 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 r22PMHmbKo38 for ; Fri, 1 May 2009 07:03:08 -0700 (PDT) Received: from web27802.mail.ukl.yahoo.com (web27802.mail.ukl.yahoo.com [217.146.182.7]) by core3.amsl.com (Postfix) with SMTP id 2327D28C1EA for ; Fri, 1 May 2009 07:01:28 -0700 (PDT) Received: (qmail 80653 invoked by uid 60001); 1 May 2009 14:02:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1241186572; bh=p1cOnEIo+enOkp43jUOxEBLau0jqvTEETKoKZ/+DdZ0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BZBTpsFQIj8YHF7tb4unFHM9/VSVQfJ2yS5FVcJXZeKgIW+VY/o78FnedorLOxyL6RTgNdwqZGb4wFDjFXjJ6PXAK251yhHmiOARIrqRToFFc0aZaPdXB5MoKyxGUd9iHLcsmC31Cj5Xz81W6rOnvSFla3pHaId7P6g4sS6QDG0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Zsx+k9YVxwbd0dJQZxdcvpAuzEQh5hR8WQdfvdS5zAOzfyAxTRyHh10tBnL16DNub2nF/TX1ReEWfjV8nOMMNuSUL5zZYqVLh5d+Hm0odJUCAdGGR6UUUnqYZHpqNI9Amy/5TdLnJtlmc1uy/8ZKSq1BJvwW5AVMlOGzbLMg73Q=; Message-ID: <339203.80394.qm@web27802.mail.ukl.yahoo.com> X-YMail-OSG: 66chcYUVM1lgWR4znAC4uUyApWq__SLpbg1CJF3uiK.pQDDVTx4jABU8 Received: from [193.15.240.60] by web27802.mail.ukl.yahoo.com via HTTP; Fri, 01 May 2009 14:02:51 GMT X-Mailer: YahooMailClassic/5.2.20 YahooMailWebService/0.7.289.1 Date: Fri, 1 May 2009 14:02:51 +0000 (GMT) From: Christian Kaas-Petersen To: George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 01 May 2009 14:03:09 -0000 The explanations are fine. I hope they in one form or another will find a way into the document. When reading the first two entries of chapter 3, it appears to me the term "flow" references "flow description", and "flow description" relies on "flow" for its definition. I should like to suggest the following definitions, where flow description is defined without reference to flow. The following is input to the editing process. flow description: A rule which can be applied to an IP packet. The rule may compare for example source address, destination port, protocol number, DSCP value, or other information from the packet with predefined values. The result of applying the rule is MATCH or NO-MATCH. flow: A subset of IP packets from the total set of IP packet handled by a node; the subset is identified by applying a flow description to each IP packet. flow identifier: A number (16-bit unsigned integer). flow binding: A three-tuple consisting of a flow identifier, a flow description, and an action. An IP packet for which the rule of the flow description gives the result MATCH, will be processed according to the action. Christian --- Den fre 1/5/09 skrev George Tsirtsis : Fra: George Tsirtsis Emne: Re: [MEXT] flow binding draft 2 Til: "Christian Kaas-Petersen" Cc: mext@ietf.org Dato: fredag 1. maj 2009 14.04 Hi Christian, Wow, very quick turnaround, and a good review, thanks! Marcelo, are you counting? :-) See comments inline... On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen wrote: > > Having read draft-ietf-mext-flow-binding-02, I should like to be > informed about two design rationales. > > The first is related to the PRO field in the Flow Identification Mobility > Option. =A0The mobile node must explicitly inform if it is an Add or a > Modify operation; the mobile node does implicitly inform if it is a > delete operation. =A0In principle there is no need for the PRO field. > There are three cases. > > (a) If a FID-value is absent in BU and > =A0 =A0present in Flow Binding List =A0 =A0 =A0 =A0=3D> remove > (b) If a FID-value is present in BU and > =A0 =A0absent in Flow Binding List =A0 =A0 =A0 =A0 =3D> add > (c) If a FID-value is present in BU and > =A0 =A0present in Flow Binding List =A0 =A0 =A0 =A0=3D> modify > > With these cases PRO field can be removed. =A0Alternatively, one could ta= ke > the other extreme, also explicitly naming the FID-values to be removed. > GT> You are right that instead of ADD/MOFIDY we can always overwrite existing FID with new FIDs when they already exists and add them when the do not exists.=A0 The reason, however, we left the ADD/MODIFY is to make it easier for the MN and HA to catch errors e.g., cases where the MN things its adding something new but the FID actually already exists. Or the case where the MN thinks its modifying something but the HA has no record of that. Unlike ADD and MODIFY, the REMOVE value is creating more trouble than it is worth. Given the soft-state nature of the protocol it is important to refresh all FIDs in all BUs, so if an FID is not included in a BU it MUST be removed. The PRO=3DREMOVE, then creates two ways of doing the same thing (remove FID by not including it in BU, or by setting PRO=3DREMOVE), which is something we wanted to avoid GT>> Again, I think your proposal to drop PRO is not unreasonable, it is just that RPO field provides an error detection functions which we think could be useful. > The document has made an in-between choice. =A0I'm not suggesing a change= , > I'm looking for an explanation. > GT> I hope the above satisfies you? > The other item relates to what in section 4.4 is denoted a "valid BID". > When a BU wants to insert a FID-entry, and this FID-entry refers to one > or more BID-values, all of those BID values must be found in the > BID Entries List, and thus an entry will always achieve the Active state. > However, at later times BID-entries may be removed, and so a state may > change to Inactive. =A0What is reason for a state not being allowed > Inactive to start with? =A0Again, I'm just looking for an explanation. > GT> It is not clear why the MN would create an entry that is inactive to begin with. It seems to me that the entry can always be created when the MN actually needs it. The reason Inactive FIDs are defined in the draft is to handle the case where BIDs are subsequently removed. Without the inactive FID concept this would mean an implicit removal of FIDs pointing to the removed BID. That again could cause confusion since it would create two ways of removing an FID entries (remove FID by not including it in BU, or by removing all of the BIDs associated with it) GT> So, we could allow the MN to add an inactive FID entry, but the added complication does not seem to provide useful flexibility. > A few minor points. > GT> All of your minor points are welcome and will be corrected in the next version of the draft. > =A0* Abstract: uses the word "peer" as a short term for correspondent nod= e, > =A0 home agent, and mobility anchor point. =A0In general, a mobile node's > =A0 peers are all the nodes with which it has TCP/UDP sessions. =A0I thin= k > =A0 the term "peer" has a too wide interpretation. > > =A0* Section 4.1, in the description of BID-PRI field, the words "a highe= r > =A0 number" assumes reading the 7-bit field as an unsigned integer. > > =A0* Section 4.2, in FID description, 8-bit should be 16-bit. > > =A0* Section 4.2, in 1 Forward, a forward reference for Binding Reference > =A0 sub-option would be helpful when reading this document first time. > > =A0* Section 4.3, in Option Type, I think a copy from the section 4.2.1. > > =A0* Section 4.4, para 2, one of the words "change" or "modify" should be > =A0 enough. > > =A0* Section 4.4, Action bullet: "PRO field" to be replaced with > =A0 "Action field". > > =A0* Section 4.4, para just above Ordered Flow Binding Entries, "three fl= ow > =A0 bindings" to become "four flow bindings". > > Christian =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig g= ode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From hesham@elevatemobile.com Fri May 1 07:18:47 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 5977E3A7097 for ; Fri, 1 May 2009 07:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-1.442, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=1.396, SARE_LWSHORTT=1.24] 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 0j+iF1LHLUzA for ; Fri, 1 May 2009 07:18:46 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id F15FB3A706F for ; Fri, 1 May 2009 07:18:45 -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 1Lztap-000314-Ts; Sat, 02 May 2009 00:20:01 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sat, 02 May 2009 00:19:56 +1000 From: Hesham Soliman To: Christian Kaas-Petersen , George Tsirtsis Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnKZ+bWdLcjsd+bS0+J8r5aG16n9Q== In-Reply-To: <339203.80394.qm@web27802.mail.ukl.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] flow binding draft 2 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, 01 May 2009 14:18:47 -0000 It's always good to remove circular definitions. I'm fine with that. Hesham On 2/05/09 12:02 AM, "Christian Kaas-Petersen" wrote: >=20 > The explanations are fine. I hope they in one form or another will > find a way into the document. >=20 > When reading the first two entries of chapter 3, it appears to me > the term "flow" references "flow description", and "flow description" > relies on "flow" for its definition. I should like to suggest the > following definitions, where flow description is defined without > reference to flow. The following is input to the editing process. >=20 > flow description: A rule which can be applied to an IP packet. > The rule may compare for example source address, > destination port, protocol number, DSCP value, or other > information from the packet with predefined values. > The result of applying the rule is MATCH or NO-MATCH. >=20 > flow: A subset of IP packets from the total set of IP packet > handled by a node; the subset is identified by applying > a flow description to each IP packet. >=20 > flow identifier: A number (16-bit unsigned integer). >=20 > flow binding: A three-tuple consisting of a flow identifier, a > flow description, and an action. An IP packet for which > the rule of the flow description gives the result MATCH, will > be processed according to the action. >=20 > Christian >=20 >=20 >=20 > --- Den fre 1/5/09 skrev George Tsirtsis : >=20 >=20 > Fra: George Tsirtsis > Emne: Re: [MEXT] flow binding draft 2 > Til: "Christian Kaas-Petersen" > Cc: mext@ietf.org > Dato: fredag 1. maj 2009 14.04 >=20 >=20 > Hi Christian, >=20 > Wow, very quick turnaround, and a good review, thanks! >=20 > Marcelo, are you counting? :-) >=20 > See comments inline... >=20 > On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen > wrote: >>=20 >> Having read draft-ietf-mext-flow-binding-02, I should like to be >> informed about two design rationales. >>=20 >> The first is related to the PRO field in the Flow Identification Mobilit= y >> Option. =A0The mobile node must explicitly inform if it is an Add or a >> Modify operation; the mobile node does implicitly inform if it is a >> delete operation. =A0In principle there is no need for the PRO field. >> There are three cases. >>=20 >> (a) If a FID-value is absent in BU and >> =A0 =A0present in Flow Binding List =A0 =A0 =A0 =A0=3D> remove >> (b) If a FID-value is present in BU and >> =A0 =A0absent in Flow Binding List =A0 =A0 =A0 =A0 =3D> add >> (c) If a FID-value is present in BU and >> =A0 =A0present in Flow Binding List =A0 =A0 =A0 =A0=3D> modify >>=20 >> With these cases PRO field can be removed. =A0Alternatively, one could tak= e >> the other extreme, also explicitly naming the FID-values to be removed. >>=20 >=20 > GT> You are right that instead of ADD/MOFIDY we can always overwrite > existing FID with new FIDs when they already exists and add them when > the do not exists.=A0 The reason, however, we left the ADD/MODIFY is to > make it easier for the MN and HA to catch errors e.g., cases where the > MN things its adding something new but the FID actually already > exists. Or the case where the MN thinks its modifying something but > the HA has no record of that. > Unlike ADD and MODIFY, the REMOVE value is creating more trouble than > it is worth. Given the soft-state nature of the protocol it is > important to refresh all FIDs in all BUs, so if an FID is not included > in a BU it MUST be removed. The PRO=3DREMOVE, then creates two ways of > doing the same thing (remove FID by not including it in BU, or by > setting PRO=3DREMOVE), which is something we wanted to avoid >=20 > GT>> Again, I think your proposal to drop PRO is not unreasonable, it > is just that RPO field provides an error detection functions which we > think could be useful. >=20 >> The document has made an in-between choice. =A0I'm not suggesing a change, >> I'm looking for an explanation. >>=20 >=20 > GT> I hope the above satisfies you? >=20 >> The other item relates to what in section 4.4 is denoted a "valid BID". >> When a BU wants to insert a FID-entry, and this FID-entry refers to one >> or more BID-values, all of those BID values must be found in the >> BID Entries List, and thus an entry will always achieve the Active state= . >> However, at later times BID-entries may be removed, and so a state may >> change to Inactive. =A0What is reason for a state not being allowed >> Inactive to start with? =A0Again, I'm just looking for an explanation. >>=20 >=20 > GT> It is not clear why the MN would create an entry that is inactive > to begin with. It seems to me that the entry can always be created > when the MN actually needs it. The reason Inactive FIDs are defined in > the draft is to handle the case where BIDs are subsequently removed. > Without the inactive FID concept this would mean an implicit removal > of FIDs pointing to the removed BID. That again could cause confusion > since it would create two ways of removing an FID entries (remove FID > by not including it in BU, or by removing all of the BIDs associated > with it) >=20 > GT> So, we could allow the MN to add an inactive FID entry, but the > added complication does not seem to provide useful flexibility. >=20 >> A few minor points. >>=20 >=20 > GT> All of your minor points are welcome and will be corrected in the > next version of the draft. >=20 >=20 >> =A0* Abstract: uses the word "peer" as a short term for correspondent node= , >> =A0 home agent, and mobility anchor point. =A0In general, a mobile node's >> =A0 peers are all the nodes with which it has TCP/UDP sessions. =A0I think >> =A0 the term "peer" has a too wide interpretation. >>=20 >> =A0* Section 4.1, in the description of BID-PRI field, the words "a higher >> =A0 number" assumes reading the 7-bit field as an unsigned integer. >>=20 >> =A0* Section 4.2, in FID description, 8-bit should be 16-bit. >>=20 >> =A0* Section 4.2, in 1 Forward, a forward reference for Binding Reference >> =A0 sub-option would be helpful when reading this document first time. >>=20 >> =A0* Section 4.3, in Option Type, I think a copy from the section 4.2.1. >>=20 >> =A0* Section 4.4, para 2, one of the words "change" or "modify" should be >> =A0 enough. >>=20 >> =A0* Section 4.4, Action bullet: "PRO field" to be replaced with >> =A0 "Action field". >>=20 >> =A0* Section 4.4, para just above Ordered Flow Binding Entries, "three flo= w >> =A0 bindings" to become "four flow bindings". >>=20 >> Christian >=20 >=20 >=20 > Tr=E6nger du til at se det store billede? Kelkoo giver dig gode tilbu= d p=E5 > LCD TV! Se her http://dk.yahoo.com/r/pat/lcd > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From tsirtsis@googlemail.com Fri May 1 07:37: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 BCF7D3A6CE4 for ; Fri, 1 May 2009 07:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_36=0.6, SARE_LWSHORTT=1.24] 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 foYC4AsQGMfQ for ; Fri, 1 May 2009 07:37:34 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id 729943A6C6B for ; Fri, 1 May 2009 07:37:34 -0700 (PDT) Received: by gxk10 with SMTP id 10so4919274gxk.13 for ; Fri, 01 May 2009 07:38:51 -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=sGV6iCq8J9G353TiPKSoA1wLr4rcKNE/mys0ORYK5EQ=; b=tMtoKdNzYsNWo6AA2xnC/yt8YECg0STx2Cg6Yk/qh1lNVftSuHQZk2SE8EByLE0lfo rzm4/v+XPN09M11epgJxP9HzPBTNd+TzDcV/Wh6alCJjNAqxTD+uLp+rKfzWLY4ow+gA so7ll6m9z5SSwSRhZGDb8MnCzqaqoiob9OxCk= 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=I69TLBMfpRv3mn6NTaTaZQ82dGCA5GGiMyqqOVm5Zng7X9sKjBL2gtUYRViGGzAJ4R 70v5Pry8dtf7FPzjxqglUmlAK7BTU8OcO189PATV2pDpT6D1sqI8IPpUjdpOkPau4AZt kVucUtGAq5uxaNFx1tfK+kDNzjpUp2Gk4ZwRE= MIME-Version: 1.0 Received: by 10.90.84.2 with SMTP id h2mr1621879agb.31.1241188731193; Fri, 01 May 2009 07:38:51 -0700 (PDT) In-Reply-To: References: <339203.80394.qm@web27802.mail.ukl.yahoo.com> Date: Fri, 1 May 2009 15:38:51 +0100 Message-ID: From: George Tsirtsis To: Hesham Soliman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 01 May 2009 14:37:35 -0000 yes, sounds good. Thanks Christian. George On Fri, May 1, 2009 at 3:19 PM, Hesham Soliman w= rote: > It's always good to remove circular definitions. I'm fine with that. > > Hesham > > > On 2/05/09 12:02 AM, "Christian Kaas-Petersen" > wrote: > >> >> The explanations are fine. =C2=A0I hope they in one form or another will >> find a way into the document. >> >> When reading the first two entries of chapter 3, it appears to me >> the term "flow" references "flow description", and "flow description" >> relies on "flow" for its definition. =C2=A0I should like to suggest the >> following definitions, where flow description is defined without >> reference to flow. =C2=A0The following is input to the editing process. >> >> =C2=A0 flow description: A rule which can be applied to an IP packet. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 The rule may compare for example source addr= ess, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 destination port, protocol number, DSCP valu= e, or other >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 information from the packet with predefined = values. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 The result of applying the rule is MATCH or = NO-MATCH. >> >> =C2=A0 flow: A subset of IP packets from the total set of IP packet >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 handled by a node; the subset is identified = by applying >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 a flow description to each IP packet. >> >> =C2=A0 flow identifier: A number (16-bit unsigned integer). >> >> =C2=A0 flow binding: A three-tuple consisting of a flow identifier, a >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 flow description, and an action. =C2=A0An IP= packet for which >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the rule of the flow description gives the r= esult MATCH, will >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 be processed according to the action. >> >> Christian >> >> >> >> --- Den fre 1/5/09 skrev George Tsirtsis : >> >> >> Fra: George Tsirtsis >> Emne: Re: [MEXT] flow binding draft 2 >> Til: "Christian Kaas-Petersen" >> Cc: mext@ietf.org >> Dato: fredag 1. maj 2009 14.04 >> >> >> Hi Christian, >> >> Wow, very quick turnaround, and a good review, thanks! >> >> Marcelo, are you counting? :-) >> >> See comments inline... >> >> On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen >> wrote: >>> >>> Having read draft-ietf-mext-flow-binding-02, I should like to be >>> informed about two design rationales. >>> >>> The first is related to the PRO field in the Flow Identification Mobili= ty >>> Option. =C2=A0The mobile node must explicitly inform if it is an Add or= a >>> Modify operation; the mobile node does implicitly inform if it is a >>> delete operation. =C2=A0In principle there is no need for the PRO field= . >>> There are three cases. >>> >>> (a) If a FID-value is absent in BU and >>> =C2=A0 =C2=A0present in Flow Binding List =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D> remove >>> (b) If a FID-value is present in BU and >>> =C2=A0 =C2=A0absent in Flow Binding List =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =3D> add >>> (c) If a FID-value is present in BU and >>> =C2=A0 =C2=A0present in Flow Binding List =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D> modify >>> >>> With these cases PRO field can be removed. =C2=A0Alternatively, one cou= ld take >>> the other extreme, also explicitly naming the FID-values to be removed. >>> >> >> GT> You are right that instead of ADD/MOFIDY we can always overwrite >> existing FID with new FIDs when they already exists and add them when >> the do not exists.=C2=A0 The reason, however, we left the ADD/MODIFY is = to >> make it easier for the MN and HA to catch errors e.g., cases where the >> MN things its adding something new but the FID actually already >> exists. Or the case where the MN thinks its modifying something but >> the HA has no record of that. >> Unlike ADD and MODIFY, the REMOVE value is creating more trouble than >> it is worth. Given the soft-state nature of the protocol it is >> important to refresh all FIDs in all BUs, so if an FID is not included >> in a BU it MUST be removed. The PRO=3DREMOVE, then creates two ways of >> doing the same thing (remove FID by not including it in BU, or by >> setting PRO=3DREMOVE), which is something we wanted to avoid >> >> GT>> Again, I think your proposal to drop PRO is not unreasonable, it >> is just that RPO field provides an error detection functions which we >> think could be useful. >> >>> The document has made an in-between choice. =C2=A0I'm not suggesing a c= hange, >>> I'm looking for an explanation. >>> >> >> GT> I hope the above satisfies you? >> >>> The other item relates to what in section 4.4 is denoted a "valid BID". >>> When a BU wants to insert a FID-entry, and this FID-entry refers to one >>> or more BID-values, all of those BID values must be found in the >>> BID Entries List, and thus an entry will always achieve the Active stat= e. >>> However, at later times BID-entries may be removed, and so a state may >>> change to Inactive. =C2=A0What is reason for a state not being allowed >>> Inactive to start with? =C2=A0Again, I'm just looking for an explanatio= n. >>> >> >> GT> It is not clear why the MN would create an entry that is inactive >> to begin with. It seems to me that the entry can always be created >> when the MN actually needs it. The reason Inactive FIDs are defined in >> the draft is to handle the case where BIDs are subsequently removed. >> Without the inactive FID concept this would mean an implicit removal >> of FIDs pointing to the removed BID. That again could cause confusion >> since it would create two ways of removing an FID entries (remove FID >> by not including it in BU, or by removing all of the BIDs associated >> with it) >> >> GT> So, we could allow the MN to add an inactive FID entry, but the >> added complication does not seem to provide useful flexibility. >> >>> A few minor points. >>> >> >> GT> All of your minor points are welcome and will be corrected in the >> next version of the draft. >> >> >>> =C2=A0* Abstract: uses the word "peer" as a short term for corresponden= t node, >>> =C2=A0 home agent, and mobility anchor point. =C2=A0In general, a mobil= e node's >>> =C2=A0 peers are all the nodes with which it has TCP/UDP sessions. =C2= =A0I think >>> =C2=A0 the term "peer" has a too wide interpretation. >>> >>> =C2=A0* Section 4.1, in the description of BID-PRI field, the words "a = higher >>> =C2=A0 number" assumes reading the 7-bit field as an unsigned integer. >>> >>> =C2=A0* Section 4.2, in FID description, 8-bit should be 16-bit. >>> >>> =C2=A0* Section 4.2, in 1 Forward, a forward reference for Binding Refe= rence >>> =C2=A0 sub-option would be helpful when reading this document first tim= e. >>> >>> =C2=A0* Section 4.3, in Option Type, I think a copy from the section 4.= 2.1. >>> >>> =C2=A0* Section 4.4, para 2, one of the words "change" or "modify" shou= ld be >>> =C2=A0 enough. >>> >>> =C2=A0* Section 4.4, Action bullet: "PRO field" to be replaced with >>> =C2=A0 "Action field". >>> >>> =C2=A0* Section 4.4, para just above Ordered Flow Binding Entries, "thr= ee flow >>> =C2=A0 bindings" to become "four flow bindings". >>> >>> Christian >> >> >> >> =C2=A0 =C2=A0 =C2=A0 Tr=C3=A6nger du til at se det store billede? Kelkoo= giver dig gode tilbud p=C3=A5 >> LCD TV! Se her http://dk.yahoo.com/r/pat/lcd >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > From behcetsarikaya@yahoo.com Fri May 1 07:58: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 8D5263A70E4 for ; Fri, 1 May 2009 07:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_LWSHORTT=1.24] 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 sp212PSyzRAN for ; Fri, 1 May 2009 07:58:35 -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 D79543A6BBC for ; Fri, 1 May 2009 07:58:29 -0700 (PDT) Received: from [68.142.230.28] by n1.bullet.mail.re3.yahoo.com with NNFMP; 01 May 2009 14:59:53 -0000 Received: from [67.195.9.83] by t1.bullet.re2.yahoo.com with NNFMP; 01 May 2009 14:59:53 -0000 Received: from [67.195.9.106] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 01 May 2009 14:59:52 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 01 May 2009 14:58:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 51394.86056.bm@omp110.mail.gq1.yahoo.com Received: (qmail 32302 invoked by uid 60001); 1 May 2009 14:59:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241189992; bh=cCq6vE0A2RdQL7dqrlkRsmXkYn+Yi9lnWCzZosLnZJI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=DzZLFelWgTf5cd9BsGf+lyM9yTSQ5LZUbZ5GxSkbriyt5K/mp6/3iDwaWmfRrE7N2/X8dcMWHIYbv6nQizKx1R0FMWbMZv6bdx4HZknmp2sT6rYwXwp0DYjf/iuCo4/ESknypEEqdC9TKhX4Y/idXJA+Hd2eSTAqvA+PZSeuwHg= 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; b=bM2pCgWqr+SZNm6p4Md8WtDzG9FoCwaJX8vqSN/3pLYdsLR6MCUYag6IeOVYXCwvYooUOT+OOrtipHekcqGMCWvvUR/N5jm8CWUYfSItgsZfRkP8yZncvgtpLk+IwNzf0CVmebEXM/07FgbnHdQXcoXYz9glS/QM9s6pWp49o4g=; Message-ID: <539177.32202.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: QOEd0Y0VM1lBGW5HKtenlQ07MFG0JpHPN9c2Azz_upDAOJZb4ZvYs13NVXyWqq6fh.hH_XFqBOcVhcYqmUtUgybb29M5wpPjoFovZpfzRBdTeA9RspK6_7O6x6KErrUezgYB7TYnJJmp5UlxDVra0iHk_CvBzFGosCjIgo3.Bf7ihwd.jqCI7fuGqUqbujFASedtHfJp3SMBEpx0euoY9jDMnyuYgu0Z1arTNQJW5u1Fi9kpvQ9AOgrrtUNRGBjVzSciew8NdBsNYSqWgI1ZoHXBwv4iONK00yaCbruLh9A74C8gRGblTSrx.cKDvELUtiNMlJavPOO3DalXQWkVdOlFwDmFgg-- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Fri, 01 May 2009 07:59:52 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <296286.77052.qm@web27801.mail.ukl.yahoo.com> Date: Fri, 1 May 2009 07:59:52 -0700 (PDT) From: Behcet Sarikaya To: Christian Kaas-Petersen , mext@ietf.org In-Reply-To: <296286.77052.qm@web27801.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1658165612-1241189992=:32202" Subject: Re: [MEXT] flow binding draft 2 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, 01 May 2009 14:58:36 -0000 --0-1658165612-1241189992=:32202 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hesham,=0A=A0 Here are a few of my observations:=0A=0A-Flow Binding defi= nition in Sec. 3 became circular, I thought previous definition was OK.=0A-= My biggest concern is there has been an artificial attempt in this version = to introduce/increase dependency on MCoA draft. =0AI would like to ask why?= =0AI would like to ask Hesham if he personally agrees, pointing to the fact= that he made public comments contrary to this?=0A=0A=A0 Note this is not a= full review.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A_____________________= ___________=0AFrom: Christian Kaas-Petersen =0ATo: m= ext@ietf.org=0ASent: Friday, May 1, 2009 6:39:03 AM=0ASubject: [MEXT] flow = binding draft 2=0A=0A=0AHaving read draft-ietf-mext-flow-binding-02, I shou= ld like to be=0Ainformed about two design rationales.=0A=0AThe first is rel= ated to the PRO field in the Flow Identification Mobility=0AOption.=A0 The = mobile node must explicitly inform if it is an Add or a=0AModify operation;= the mobile node does implicitly inform if it is a=0Adelete operation.=A0 I= n principle there is no need for the PRO field.=0AThere are three cases.=0A= =0A(a) If a FID-value is absent in BU and=0A=A0 =A0 present in Flow Binding= List=A0 =A0 =A0 =A0 =3D> remove=0A(b) If a FID-value is present in BU and= =0A=A0 =A0 absent in Flow Binding List=A0 =A0 =A0 =A0 =3D> add=0A(c) If a F= ID-value is present in BU and=0A=A0 =A0 present in Flow Binding List=A0 =A0= =A0 =A0 =3D> modify=0A=0AWith these cases PRO field can be removed.=A0 Alt= ernatively, one could take=0Athe other extreme, also explicitly naming the = FID-values to be removed.=0A=0AThe document has made an in-between choice.= =A0 I'm not suggesing a change,=0AI'm looking for an explanation.=0A=0AThe = other item relates to what in section 4.4 is denoted a "valid BID".=0AWhen = a BU wants to insert a FID-entry, and this FID-entry refers to one=0Aor mor= e BID-values, all of those BID values must be found in the=0ABID Entries Li= st, and thus an entry will always achieve the Active state.=0AHowever, at l= ater times BID-entries may be removed, and so a state may=0Achange to Inact= ive.=A0 What is reason for a state not being allowed=0AInactive to start wi= th?=A0 Again, I'm just looking for an explanation.=0A=0AA few minor points.= =0A=0A* Abstract: uses the word "peer" as a short term for correspondent no= de,=0A=A0 home agent, and mobility anchor point.=A0 In general, a mobile no= de's=0A=A0 peers are all the nodes with which it has TCP/UDP sessions.=A0 I= think=0A=A0 the term "peer" has a too wide interpretation.=0A=0A* Section = 4.1, in the description of BID-PRI field, the words "a higher=0A=A0 number"= assumes reading the 7-bit field as an unsigned integer.=0A=0A* Section 4.2= , in FID description, 8-bit should be 16-bit.=0A=0A* Section 4.2, in 1 Forw= ard, a forward reference for Binding Reference=0A=A0 sub-option would be he= lpful when reading this document first time.=0A=0A* Section 4.3, in Option = Type, I think a copy from the section 4.2.1.=0A=0A* Section 4.4, para 2, on= e of the words "change" or "modify" should be=0A=A0 enough.=0A=0A* Section = 4.4, Action bullet: "PRO field" to be replaced with=0A=A0 "Action field".= =0A=0A* Section 4.4, para just above Ordered Flow Binding Entries, "three f= low=0A=A0 bindings" to become "four flow bindings".=0A=0AChristian=0A=0A=0A= =0A=0A=A0 =A0 =A0 Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her= - http://dk.yahoo.com/r/pat/mm=0A_________________________________________= ______=0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailman/l= istinfo/mext=0A=0A=0A=0A --0-1658165612-1241189992=:32202 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hesham,
=0A
  Here are a few of my ob= servations:
=0A
 
=0A
-Flow Binding definition in Se= c. 3 became circular, I thought previous definition was OK.
=0A
-M= y biggest concern is there has been an artificial attempt in this version t= o introduce/increase dependency on MCoA draft.
=0A
I would like t= o ask why?
=0A
I would like to ask Hesham if he personally agrees,= pointing to the fact that he made public comments contrary to this?
= =0A
 
=0A
  Note this is not a full review.
=0A=
 
=0A
Regards,
=0A
 
=0A
Behcet
=0A

=0A
=0A
=0A= From: Christian Kaas-Peters= en <kaaspetersen@yahoo.dk>
To= : mext@ietf.org
Sent: Friday, May 1, 2009 6:39:03 AM
Subject: [MEXT] flow binding draft 2


Havi= ng read draft-ietf-mext-flow-binding-02, I should like to be
informed ab= out two design rationales.

The first is related to the PRO field in = the Flow Identification Mobility
Option.  The mobile node must expl= icitly inform if it is an Add or a
Modify operation; the mobile node doe= s implicitly inform if it is a
delete operation.  In principle ther= e is no need for the PRO field.
There are three cases.

(a) If a F= ID-value is absent in BU and
    present in Flow Binding List&= nbsp;       =3D> remove
(b) If a FID-value is present = in BU and
    absent in Flow Binding List      &n= bsp; =3D> add
(c) If a FID-value is present in BU and
   = ; present in Flow Binding List        =3D> modify
With these cases PRO field can be removed.  Alternatively, one co= uld take
the other extreme, also explicitly naming the FID-values to be = removed.

The document has made an in-between choice.  I'm not s= uggesing a change,
I'm looking for an explanation.

The other item= relates to what in section 4.4 is denoted a "valid BID".
When a BU want= s to insert a FID-entry, and this FID-entry refers to one
or more BID-va= lues, all of those BID values must be found in the
BID Entries List, and= thus an entry will always achieve the Active state.
However, at later t= imes BID-entries may be removed, and so a state may
change to Inactive.&= nbsp; What is reason for a state not being allowed
Inactive to start with?  Again, I'm just looking for an explanation.

A few minor= points.

* Abstract: uses the word "peer" as a short term for corres= pondent node,
  home agent, and mobility anchor point.  In gen= eral, a mobile node's
  peers are all the nodes with which it has T= CP/UDP sessions.  I think
  the term "peer" has a too wide int= erpretation.

* Section 4.1, in the description of BID-PRI field, the= words "a higher
  number" assumes reading the 7-bit field as an un= signed integer.

* Section 4.2, in FID description, 8-bit should be 1= 6-bit.

* Section 4.2, in 1 Forward, a forward reference for Binding = Reference
  sub-option would be helpful when reading this document = first time.

* Section 4.3, in Option Type, I think a copy from the s= ection 4.2.1.

* Section 4.4, para 2, one of the words "change" or "m= odify" should be
  enough.

* Section 4.4, Action bullet: "PRO field" to be replaced with
  "Action field".

*= Section 4.4, para just above Ordered Flow Binding Entries, "three flow
=   bindings" to become "four flow bindings".

Christian



      Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - http://dk= ..yahoo.com/r/pat/mm
_______________________________________________
M= EXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext<= BR>

=0A=0A --0-1658165612-1241189992=:32202-- From behcetsarikaya@yahoo.com Fri May 1 13:27: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 1A0323A69B4 for ; Fri, 1 May 2009 13:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[AWL=-0.254, 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 EaqrRaKOZimh for ; Fri, 1 May 2009 13:27:00 -0700 (PDT) Received: from n64.bullet.mail.sp1.yahoo.com (n64.bullet.mail.sp1.yahoo.com [98.136.44.189]) by core3.amsl.com (Postfix) with SMTP id E63203A6C33 for ; Fri, 1 May 2009 13:25:40 -0700 (PDT) Received: from [69.147.84.144] by n64.bullet.mail.sp1.yahoo.com with NNFMP; 01 May 2009 20:27:05 -0000 Received: from [67.195.9.81] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 01 May 2009 20:27:05 -0000 Received: from [67.195.9.110] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 01 May 2009 20:27:04 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 01 May 2009 20:24:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 707267.69476.bm@omp114.mail.gq1.yahoo.com Received: (qmail 27774 invoked by uid 60001); 1 May 2009 20:27:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241209623; bh=QEQhHo35WkQsgQ2yoi9am64NRxtrvHQ8zoqUcZjwcCE=; 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=dB9LG7GoBjx4rRJHfW7z+lLh7B+F/c2UaLDejUte6+5Q6cqf08xYJFbACcQStN8wsgAm6Ic9JkPWIfTdFivvN+or+nkaQglspSr6SPq1dpJyE5eoKAlteqoE4tkJrgTGBRj7j8vKQg8RLV1zISQxodcJhbDw6WT8fJT1aOK7NJ0= 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=qOzbo1bYwLQs+0exlyknabsZl2UKLiT6lLBMsvw0JN7X3UG17pVrSRy9HkfGIOeoU5OSLiF3IeIXiRLjX/6rx/u/4WHypaziV6fr1R/9byWe+bBAZf/Fc0ezr+SgKn67zcg9h+fkIVjmlnCy7G0qN2Hz2wASdjF0PxQ+Imhoxuc=; Message-ID: <874135.27179.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: RruUGxcVM1mT6TkxVIc_vQy6Kphcm2O7UpaSskkAuP0x_xaeP4msQ0SQlvRHTnMg52ktdUBZxw0ArTx9Kyn.rlj17m.1f2fiQCfiu0whzDKYx0IDDwgCzMSeIa5He_mKlSDnXIHAA.gfXssbhU0tMxnpYBFd3o.v4yKyPQz_GIzoR0BQv0U6R0OfxG_gfYv2G2c04TmTgPNXmwkZUCTFqjisJ4J6y7AsaPjwSAzlQ0_8mtwlpbdxGe2x_D4aoPBf8CMvgVxAiMHAPrEVoimWhzk1PtCd3YgePXN9jNqtryXyZg09RmTI1TJFrBunjWCVWDwg Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Fri, 01 May 2009 13:27:03 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EF37D8.2010408@it.uc3m.es> <49FAC1A2.7060206@it.uc3m.es> Date: Fri, 1 May 2009 13:27:03 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun In-Reply-To: <49FAC1A2.7060206@it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-240955171-1241209623=:27179" Cc: mext Subject: Re: [MEXT] Moving forward with MEXT documents -draft-ietf-mip6-hareliability-04 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, 01 May 2009 20:27:01 -0000 --0-240955171-1241209623=:27179 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marcelo,=0A=A0 Here is my review for the HA Reliability draft:=0A=0AThis= draft describes two methods of switching HAs in case of failure: virtual s= witch in which HAs themselves detect failure and HA2 takes over HA1 and har= d switch in which a standby HA notifies MN to register with it.=0A=0AAny im= provements: yes, the document can cover the local mobility anchor reliabili= ty. All the messages defined in the draft are exchanged by HAs so they woul= d apply to LMAs as well. Virtual switch will be almost the same. Maybe some= work for the hard switch due to the architectural differences.=0A=0ANits:= =0AInformative References ID-HAHA ID-LOCALHAHA ID-PS-HARELIABILITY if there= are any co-authors, they don't appear.=0A=0A7.5.2. s/in-active/inactive=0A= 1. RFC-3776 why not replace with RFC-4877 which updated 3776?=0A=0A=0ARegar= ds,=0A=0ABehcet=0A=0A=0A________________________________=0AFrom: marcelo ba= gnulo braun =0ATo: mext =0ACc: Jari Arkk= o =0ASent: Friday, May 1, 2009 4:32:18 AM=0ASubject: = Re: [MEXT] Moving forward with MEXT documents=0A=0AFWIW, the deadline for t= his is about the expire and we only received a couple of volunteers so far.= =0A=0Amarcelo bagnulo braun escribi=F3:=0A> Hi,=0A> =0A> At this point in t= ime, the WG has the following documents that are ready for WGLC:=0A> =0A> d= raft-ietf-mext-firewall-admin-00=A0 =A0 =A0 =A0 =A0 draft-ietf-mext-firewal= l-vendor-00=A0 =A0 =A0 =A0 =A0 draft-ietf-mip6-hareliability-04=A0 =A0 =A0 = =A0 draft-ietf-monami6-mipv6-analysis-05=A0 =A0 =A0 =A0 draft-ietf-monami6-= multihoming-motivation-scenario-03=0A> =0A> And the following document that= we need to ask for adoption:=0A> =0A> draft-premec-mext-extended-home-link= -01=0A> =0A> According to our new ground rules, each of these documents to = proceed will need 5 thorough reviews. Since this is a considerable amount o= f effort from the WG, we would like soem feedback on how to manage this eff= ort. In particular, we would like to get feedback from the WG about which d= ocuments should we issue the WGLC or adoption call first and if possible vo= lunteers to do the reviews for the documents.=0A> =0A> We will receive inpu= t on this till the 3rd of may and then decide how to move forward.=0A> =0A>= Regards, marcelo=0A> =0A> =0A> =0A> ______________________________________= _________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.ietf.org/= mailman/listinfo/mext=0A> =0A=0A___________________________________________= ____=0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailman/lis= tinfo/mext=0A=0A=0A=0A --0-240955171-1241209623=:27179 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marcelo,
=0A
  Here is my review for = the HA Reliability draft:
=0A
 
=0A
This draft descr= ibes two methods of switching HAs in case of failure: virtual switch in whi= ch HAs themselves detect failure and HA2 takes over HA1 and hard switch in = which a standby HA notifies MN to register with it.
=0A
 =0A
Any improvements: yes, the document can cover the local mobility = anchor reliability. All the messages defined in the draft are exchanged by = HAs so they would apply to LMAs as well. Virtual switch will be almost the = same. Maybe some work for the hard switch due to the architectural differen= ces.
=0A

Nits:
=0A
Informative References ID-HAHA ID-= LOCALHAHA ID-PS-HARELIABILITY if there are any co-authors, they don't appea= r.
=0A
 
=0A
7.5.2. s/in-active/inactive
=0A1. RFC-3776 why not replace with RFC-4877 which updated 3776?
=0A 
=0A
 
=0A
Regards,
=0A<= DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times= , serif"> =0A
Behcet
=0A
=0A
=0AFrom:<= /B> marcelo bagnulo braun <marcelo@it.uc3m.es>
To: mext <mext@ietf.org>
Cc: Jari Arkko <jari.arkko@piuha.net= >
Sent: Friday, May 1= , 2009 4:32:18 AM
Subject: Re: [MEXT] Moving forward with MEXT documents

FWIW, the de= adline for this is about the expire and we only received a couple of volunt= eers so far.

marcelo bagnulo braun escribi=F3:
> Hi,
> <= BR>> At this point in time, the WG has the following documents that are = ready for WGLC:
>
> draft-ietf-mext-firewall-admin-00  &n= bsp;       draft-ietf-mext-firewall-vendor-00    &= nbsp;     draft-ietf-mip6-hareliability-04      &n= bsp; draft-ietf-monami6-mipv6-analysis-05        draft-ietf= -monami6-multihoming-motivation-scenario-03
>
> And the follow= ing document that we need to ask for adoption:
>
> draft-preme= c-mext-extended-home-link-01
>
> According to our new ground r= ules, each of these documents to proceed will need 5 thorough reviews. Sinc= e this is a considerable amount of effort from the WG, we would like soem f= eedback on how to manage this effort. In particular, we would like to get f= eedback from the WG about which documents should we issue the WGLC or adopt= ion call first and if possible volunteers to do the reviews for the documen= ts.
>
> We will receive input on this till the 3rd of may and = then decide how to move forward.
>
> Regards, marcelo
> =
>
>
> _______________________________________________<= BR>> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.or= g/mailman/listinfo/mext
>

_______________________________= ________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailm= an/listinfo/mext

=0A=0A=0A=0A --0-240955171-1241209623=:27179-- From hesham@elevatemobile.com Fri May 1 19:47: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 A79263A6B74 for ; Fri, 1 May 2009 19:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_LWSHORTT=1.24] 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 MQTTNKto2Kuz for ; Fri, 1 May 2009 19:47:43 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 0081C3A63C9 for ; Fri, 1 May 2009 19:45:49 -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 1M05Fr-00067S-W1; Sat, 02 May 2009 12:47:08 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sat, 02 May 2009 12:47:03 +1000 From: Hesham Soliman To: Behcet Sarikaya , Christian Kaas-Petersen , Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnK0EXPMHLvGgExZUCPRzlAyeKjVw== In-Reply-To: <539177.32202.qm@web111404.mail.gq1.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [MEXT] flow binding draft 2 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, 02 May 2009 02:47:44 -0000 Hi Behcet > -My biggest concern is there has been an artificial attempt in this versi= on to > introduce/increase dependency on MCoA draft. =3D> First, "introduce" and "increase" are not synonyms so which one did you want? We certainly didn't introduce this in this rev. Support for MCoA was included in 2006 if I remember correctly. I did ask the question in the las= t meeting to see if people had any opinions on mandating the use of MCoA and received no feedback. So the authors discussed it and we thought it was easiest to mandate it and avoid confusion. You mention that it's your biggest concern; why is that? > I would like to ask why? > I would like to ask Hesham if he personally agrees, pointing to the fact = that > he made public comments contrary to this? =3D> Which public comments are you referring to? As far as I remember I was not convinced in 2006 that adding MCoA was necessary but I was convinced by people on the list that it was a good idea so we agreed to include it back then. What comments are you referring to? Anyway, I'm not a politician; so I can say something and be proven wrong an= d accept that. I'm still not sure why you think this is a concern for the draft. Hesham >=20 > =A0 Note this is not a full review. >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 >=20 > ________________________________ > From: Christian Kaas-Petersen > To: mext@ietf.org > Sent: Friday, May 1, 2009 6:39:03 AM > Subject: [MEXT] flow binding draft 2 >=20 >=20 > Having read draft-ietf-mext-flow-binding-02, I should like to be > informed about two design rationales. >=20 > The first is related to the PRO field in the Flow Identification Mobility > Option.=A0 The mobile node must explicitly inform if it is an Add or a > Modify operation; the mobile node does implicitly inform if it is a > delete operation.=A0 In principle there is no need for the PRO field. > There are three cases. >=20 > (a) If a FID-value is absent in BU and > =A0 =A0 present in Flow Binding List=A0 =A0 =A0 =A0 =3D> remove > (b) If a FID-value is present in BU and > =A0 =A0 absent in Flow Binding List=A0 =A0 =A0 =A0 =3D> add > (c) If a FID-value is present in BU and > =A0 =A0 present in Flow Binding List=A0 =A0 =A0 =A0 =3D> modify >=20 > With these cases PRO field can be removed.=A0 Alternatively, one could take > the other extreme, also explicitly naming the FID-values to be removed. >=20 > The document has made an in-between choice.=A0 I'm not suggesing a change, > I'm looking for an explanation. >=20 > The other item relates to what in section 4.4 is denoted a "valid BID". > When a BU wants to insert a FID-entry, and this FID-entry refers to one > or more BID-values, all of those BID values must be found in the > BID Entries List, and thus an entry will always achieve the Active state. > However, at later times BID-entries may be removed, and so a state may > change to Inactive.=A0 What is reason for a state not being allowed > Inactive to start with?=A0 Again, I'm just looking for an explanation. >=20 > A few minor points. >=20 > * Abstract: uses the word "peer" as a short term for correspondent node, > =A0 home agent, and mobility anchor point.=A0 In general, a mobile node's > =A0 peers are all the nodes with which it has TCP/UDP sessions.=A0 I think > =A0 the term "peer" has a too wide interpretation. >=20 > * Section 4.1, in the description of BID-PRI field, the words "a higher > =A0 number" assumes reading the 7-bit field as an unsigned integer. >=20 > * Section 4.2, in FID description, 8-bit should be 16-bit. >=20 > * Section 4.2, in 1 Forward, a forward reference for Binding Reference > =A0 sub-option would be helpful when reading this document first time. >=20 > * Section 4.3, in Option Type, I think a copy from the section 4.2.1. >=20 > * Section 4.4, para 2, one of the words "change" or "modify" should be > =A0 enough. >=20 > * Section 4.4, Action bullet: "PRO field" to be replaced with > =A0 "Action field". >=20 > * Section 4.4, para just above Ordered Flow Binding Entries, "three flow > =A0 bindings" to become "four flow bindings". >=20 > Christian >=20 >=20 >=20 >=20 > =A0 =A0 =A0 Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - > http://dk.yahoo.com/r/pat/mm > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From w52006@huawei.com Mon May 4 00:12: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 E4AF53A6F6D for ; Mon, 4 May 2009 00:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.224 X-Spam-Level: X-Spam-Status: No, score=0.224 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_36=0.6, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] 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 8dKg0zjEWIGD for ; Mon, 4 May 2009 00:12:27 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CC7A33A69CC for ; Mon, 4 May 2009 00:11:36 -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 <0KJ300IBLYPFIQ@szxga03-in.huawei.com> for mext@ietf.org; Mon, 04 May 2009 15:12:51 +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 <0KJ3001USYPFDH@szxga03-in.huawei.com> for mext@ietf.org; Mon, 04 May 2009 15:12:51 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ300L5EYPEQR@szxml04-in.huawei.com> for mext@ietf.org; Mon, 04 May 2009 15:12:51 +0800 (CST) Date: Mon, 04 May 2009 15:12:50 +0800 From: Yungui Wang In-reply-to: To: 'George Tsirtsis' , 'Christian Kaas-Petersen' Message-id: <012701c9cc87$bc8824e0$150ca40a@china.huawei.com> Organization: huawei 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: AcnKWZBhH6O/cTrTQsehwC+LTiioTACI/EqA Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 04 May 2009 07:12:35 -0000 Hello I do think it is necessary to keep the REMOVE operation. In my understanding, the explicit REMOVE operation can avoid that, once a certain flow is added/modified, all the flows have to be updated. In addition, you mentioned implicit REMOVE operation (remove FID by not including it in reg-BU) should be disallowed. Secondly, from the draft's description and your explanation, I don't find that the Inactive status is similar meaningful. It has to be updated to active state if the inactive flow is enabled to be used. Maybe the only reason why the Inactive status exists is the confusion of Remove operation (two ways) you mentioned. However, I don't think this reason is very good. The general operation of BID deletion could be: when a BID is being deleted, MN and HA both should modify its associated FIDs to refer new BID or delete them. B.R. Yungui > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of George Tsirtsis > Sent: Friday, May 01, 2009 8:04 PM > To: Christian Kaas-Petersen > Cc: mext@ietf.org > Subject: Re: [MEXT] flow binding draft 2 > > Hi Christian, > > Wow, very quick turnaround, and a good review, thanks! > > Marcelo, are you counting? :-) > > See comments inline... > > On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen > wrote: > > > > Having read draft-ietf-mext-flow-binding-02, I should like to be > > informed about two design rationales. > > > > The first is related to the PRO field in the Flow > Identification Mobility > > Option. ?The mobile node must explicitly inform if it is an Add or a > > Modify operation; the mobile node does implicitly inform if it is a > > delete operation. ?In principle there is no need for the PRO field. > > There are three cases. > > > > (a) If a FID-value is absent in BU and > > ? ?present in Flow Binding List ? ? ? ?=> remove > > (b) If a FID-value is present in BU and > > ? ?absent in Flow Binding List ? ? ? ? => add > > (c) If a FID-value is present in BU and > > ? ?present in Flow Binding List ? ? ? ?=> modify > > > > With these cases PRO field can be removed. ?Alternatively, > one could take > > the other extreme, also explicitly naming the FID-values to > be removed. > > > > GT> You are right that instead of ADD/MOFIDY we can always overwrite > existing FID with new FIDs when they already exists and add them when > the do not exists. The reason, however, we left the ADD/MODIFY is to > make it easier for the MN and HA to catch errors e.g., cases where the > MN things its adding something new but the FID actually already > exists. Or the case where the MN thinks its modifying something but > the HA has no record of that. > Unlike ADD and MODIFY, the REMOVE value is creating more trouble than > it is worth. Given the soft-state nature of the protocol it is > important to refresh all FIDs in all BUs, so if an FID is not included > in a BU it MUST be removed. The PRO=REMOVE, then creates two ways of > doing the same thing (remove FID by not including it in BU, or by > setting PRO=REMOVE), which is something we wanted to avoid > > > GT>> Again, I think your proposal to drop PRO is not unreasonable, it > is just that RPO field provides an error detection functions which we > think could be useful. > > > The document has made an in-between choice. ?I'm not > suggesing a change, > > I'm looking for an explanation. > > > > GT> I hope the above satisfies you? > > > The other item relates to what in section 4.4 is denoted a > "valid BID". > > When a BU wants to insert a FID-entry, and this FID-entry > refers to one > > or more BID-values, all of those BID values must be found in the > > BID Entries List, and thus an entry will always achieve the > Active state. > > However, at later times BID-entries may be removed, and so > a state may > > change to Inactive. ?What is reason for a state not being allowed > > Inactive to start with? ?Again, I'm just looking for an explanation. > > > > GT> It is not clear why the MN would create an entry that is inactive > to begin with. It seems to me that the entry can always be created > when the MN actually needs it. The reason Inactive FIDs are defined in > the draft is to handle the case where BIDs are subsequently removed. > Without the inactive FID concept this would mean an implicit removal > of FIDs pointing to the removed BID. That again could cause confusion > since it would create two ways of removing an FID entries (remove FID > by not including it in BU, or by removing all of the BIDs associated > with it) > > GT> So, we could allow the MN to add an inactive FID entry, but the > added complication does not seem to provide useful flexibility. > > > A few minor points. > > > > GT> All of your minor points are welcome and will be corrected in the > next version of the draft. > > > > ?* Abstract: uses the word "peer" as a short term for > correspondent node, > > ? home agent, and mobility anchor point. ?In general, a > mobile node's > > ? peers are all the nodes with which it has TCP/UDP > sessions. ?I think > > ? the term "peer" has a too wide interpretation. > > > > ?* Section 4.1, in the description of BID-PRI field, the > words "a higher > > ? number" assumes reading the 7-bit field as an unsigned integer. > > > > ?* Section 4.2, in FID description, 8-bit should be 16-bit. > > > > ?* Section 4.2, in 1 Forward, a forward reference for > Binding Reference > > ? sub-option would be helpful when reading this document first time. > > > > ?* Section 4.3, in Option Type, I think a copy from the > section 4.2.1. > > > > ?* Section 4.4, para 2, one of the words "change" or > "modify" should be > > ? enough. > > > > ?* Section 4.4, Action bullet: "PRO field" to be replaced with > > ? "Action field". > > > > ?* Section 4.4, para just above Ordered Flow Binding > Entries, "three flow > > ? bindings" to become "four flow bindings". > > > > Christian > > > > > > > > > > ? ? ?Find din nye laptop p? kelkoo.dk. Se de gode tilbud > her - http://dk.yahoo.com/r/pat/mm > > _______________________________________________ > > 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 Mon May 4 01:36: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 BCD933A6A42 for ; Mon, 4 May 2009 01:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_36=0.6, SARE_LWSHORTT=1.24] 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 Dusr8D9BzmIi for ; Mon, 4 May 2009 01:36:51 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 719DB28C14B for ; Mon, 4 May 2009 01:36:47 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so2464307rvb.49 for ; Mon, 04 May 2009 01:38: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=xo9KR3qHGYDIlcTCueufi3bTHi2tk/NQCWQYqAaIJYw=; b=Ojy9RJ51Z65IeaqB+p/B8yf5TzhvmGUSaHCna6DoQWAWM/FGKDeQ1odGUPAW2vZ+qH RtT7Ysrn5YObrzOtT5h7KyeTqtXpAhWqjXw5sClPdlFU97eZk1yfo4hkScnb1rGUrHKd MSIrJ5tCL5R4qSG7UYHfc4Wid+jWPAwx6xKPw= 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=ucAMCPAnPT+GVifHQy0YZAKLWqNRbQLOro3hJHjSw+2NyM6ECtpZ4jSjKKC2znK2ID 76xZSW3lUDbeX0F9riYOn38TGG/WWj/+YK12ir/P70YiWT6lBgxp7wn8NCHz/aOgbgFe 5WAeacksw2CB55fckIwVYAVrS8D2vygS89WAI= MIME-Version: 1.0 Received: by 10.142.142.16 with SMTP id p16mr2343464wfd.231.1241426290015; Mon, 04 May 2009 01:38:10 -0700 (PDT) In-Reply-To: <012701c9cc87$bc8824e0$150ca40a@china.huawei.com> References: <012701c9cc87$bc8824e0$150ca40a@china.huawei.com> Date: Mon, 4 May 2009 09:38:09 +0100 Message-ID: From: George Tsirtsis To: w52006@huawei.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 04 May 2009 08:36:54 -0000 inline On Mon, May 4, 2009 at 8:12 AM, Yungui Wang wrote: > > Hello > > I do think it is necessary to keep the REMOVE operation. In > my understanding, the explicit REMOVE operation can avoid > that, once a certain flow is added/modified, all the flows have > to be updated. In addition, you mentioned implicit REMOVE > operation (remove FID by not including it in reg-BU) should be > disallowed. > GT> As I already explained in the exchange with Christian, an explicit REMOVE operation is indeed possible. It is not, however, preferable since it would result in two ways of removing an FID. It is not good design practice to have multiple ways of doing the same thing, and in this case there is no reason to do so. > Secondly, from the draft's description and your explanation, > I don't find that the Inactive status is similar meaningful. > It has to be updated to active state if the inactive flow is > enabled to be used. > Maybe the only reason why the Inactive status exists is > the confusion of Remove operation (two ways) you mentioned. > However, I don't think this reason is very good. The general > operation of BID deletion could be: when a BID is being > deleted, MN and HA both should modify its associated > FIDs to refer new BID or delete them. > GT> Again, as I already explained the inactive state is there for the same reasons i.e., to avoid two ways of doing the same thing. Regards George > > B.R. > Yungui > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of George Tsirtsis >> Sent: Friday, May 01, 2009 8:04 PM >> To: Christian Kaas-Petersen >> Cc: mext@ietf.org >> Subject: Re: [MEXT] flow binding draft 2 >> >> Hi Christian, >> >> Wow, very quick turnaround, and a good review, thanks! >> >> Marcelo, are you counting? :-) >> >> See comments inline... >> >> On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen >> wrote: >> > >> > Having read draft-ietf-mext-flow-binding-02, I should like to be >> > informed about two design rationales. >> > >> > The first is related to the PRO field in the Flow >> Identification Mobility >> > Option. ?The mobile node must explicitly inform if it is an Add or a >> > Modify operation; the mobile node does implicitly inform if it is a >> > delete operation. ?In principle there is no need for the PRO field. >> > There are three cases. >> > >> > (a) If a FID-value is absent in BU and >> > ? ?present in Flow Binding List ? ? ? ?=3D> remove >> > (b) If a FID-value is present in BU and >> > ? ?absent in Flow Binding List ? ? ? ? =3D> add >> > (c) If a FID-value is present in BU and >> > ? ?present in Flow Binding List ? ? ? ?=3D> modify >> > >> > With these cases PRO field can be removed. ?Alternatively, >> one could take >> > the other extreme, also explicitly naming the FID-values to >> be removed. >> > >> >> GT> You are right that instead of ADD/MOFIDY we can always overwrite >> existing FID with new FIDs when they already exists and add them when >> the do not exists. =C2=A0The reason, however, we left the ADD/MODIFY is = to >> make it easier for the MN and HA to catch errors e.g., cases where the >> MN things its adding something new but the FID actually already >> exists. Or the case where the MN thinks its modifying something but >> the HA has no record of that. >> Unlike ADD and MODIFY, the REMOVE value is creating more trouble than >> it is worth. Given the soft-state nature of the protocol it is >> important to refresh all FIDs in all BUs, so if an FID is not included >> in a BU it MUST be removed. The PRO=3DREMOVE, then creates two ways of >> doing the same thing (remove FID by not including it in BU, or by >> setting PRO=3DREMOVE), which is something we wanted to avoid >> >> >> GT>> Again, I think your proposal to drop PRO is not unreasonable, it >> is just that RPO field provides an error detection functions which we >> think could be useful. >> >> > The document has made an in-between choice. ?I'm not >> suggesing a change, >> > I'm looking for an explanation. >> > >> >> GT> I hope the above satisfies you? >> >> > The other item relates to what in section 4.4 is denoted a >> "valid BID". >> > When a BU wants to insert a FID-entry, and this FID-entry >> refers to one >> > or more BID-values, all of those BID values must be found in the >> > BID Entries List, and thus an entry will always achieve the >> Active state. >> > However, at later times BID-entries may be removed, and so >> a state may >> > change to Inactive. ?What is reason for a state not being allowed >> > Inactive to start with? ?Again, I'm just looking for an explanation. >> > >> >> GT> It is not clear why the MN would create an entry that is inactive >> to begin with. It seems to me that the entry can always be created >> when the MN actually needs it. The reason Inactive FIDs are defined in >> the draft is to handle the case where BIDs are subsequently removed. >> Without the inactive FID concept this would mean an implicit removal >> of FIDs pointing to the removed BID. That again could cause confusion >> since it would create two ways of removing an FID entries (remove FID >> by not including it in BU, or by removing all of the BIDs associated >> with it) >> >> GT> So, we could allow the MN to add an inactive FID entry, but the >> added complication does not seem to provide useful flexibility. >> >> > A few minor points. >> > >> >> GT> All of your minor points are welcome and will be corrected in the >> next version of the draft. >> >> >> > ?* Abstract: uses the word "peer" as a short term for >> correspondent node, >> > ? home agent, and mobility anchor point. ?In general, a >> mobile node's >> > ? peers are all the nodes with which it has TCP/UDP >> sessions. ?I think >> > ? the term "peer" has a too wide interpretation. >> > >> > ?* Section 4.1, in the description of BID-PRI field, the >> words "a higher >> > ? number" assumes reading the 7-bit field as an unsigned integer. >> > >> > ?* Section 4.2, in FID description, 8-bit should be 16-bit. >> > >> > ?* Section 4.2, in 1 Forward, a forward reference for >> Binding Reference >> > ? sub-option would be helpful when reading this document first time. >> > >> > ?* Section 4.3, in Option Type, I think a copy from the >> section 4.2.1. >> > >> > ?* Section 4.4, para 2, one of the words "change" or >> "modify" should be >> > ? enough. >> > >> > ?* Section 4.4, Action bullet: "PRO field" to be replaced with >> > ? "Action field". >> > >> > ?* Section 4.4, para just above Ordered Flow Binding >> Entries, "three flow >> > ? bindings" to become "four flow bindings". >> > >> > Christian >> > >> > >> > >> > >> > ? ? ?Find din nye laptop p? kelkoo.dk. Se de gode tilbud >> her - http://dk.yahoo.com/r/pat/mm >> > _______________________________________________ >> > 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 kaaspetersen@yahoo.dk Mon May 4 03:12: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 C84903A6AC0 for ; Mon, 4 May 2009 03:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_20=-0.74] 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 1JYT-Grxj2kJ for ; Mon, 4 May 2009 03:12:28 -0700 (PDT) Received: from web27808.mail.ukl.yahoo.com (web27808.mail.ukl.yahoo.com [217.146.182.13]) by core3.amsl.com (Postfix) with SMTP id 11A753A6FFA for ; Mon, 4 May 2009 03:11:53 -0700 (PDT) Received: (qmail 4398 invoked by uid 60001); 4 May 2009 10:13:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1241431997; bh=tMGPKS17hLrqrpxY/RyntyfP2A7pxcKE9E+kE8YNmcQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=beAazeOFwOj+SKedk1VZImrr4xLZjZIAHJfKE3nTHwnJOMLMjc7x5Zmv8OqAjFwPuG5kB7XoOnBXsg2cVlG5W9o5RFLG11hIdLZiCxZnFMpOxbzlW8Er2reYBdJXS9cbmeTRsoUZWVVbBpgDJbYrScUAPz244593GvGeIxoSiDY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ydx0vP/i+tb9rtUimzkOOfztZQXxYxnkMdU3VOp3k1AtbqY9cJ3eXlfNxsMLowG9DAGPtYweOYrgE9f4ZYCWaerApFsk6aJQp7Y8Wcuoczh6u6QaXKI9/PY4ddyD320h7dkFBM7NWYhiUvjjqUknC+qVDa4UTR1F0rJnAVXk/+0=; Message-ID: <860528.4365.qm@web27808.mail.ukl.yahoo.com> X-YMail-OSG: N_a4MkAVM1mVclzt0T_Hbxwb2gIjgZI1FX3CQu0kmB2eQNnArI.WpN.iFQP1LJ7aMj0M1ndX29n5vmyah4t3pW9lf8T9VEVtekGCjm5U2D0SLYLQgB6LAHutlYZFceU7tcRDZVFABn2bOyn7EY9vLiQ3EWDxTrfGKK8OULlGGGiTJ.an5bFaw2JYDaKCgLt6VP7APzxE5qhB65GAicLbL1FuMFUV4ub1GG9XZaBRakEVlXt5jaEshD180wanrYdIKre5faxekF6TiZvksS0wssy3xD3FsHZdJ4QArAf0oOX94HUilQYTY_jDS_7362KfZzA1mm.p5X6UWH2pL17cuQEn3bKzv4FoOx3b.gn5axrL78iQCPmUkhJROBxF5Gc- Received: from [193.15.240.60] by web27808.mail.ukl.yahoo.com via HTTP; Mon, 04 May 2009 10:13:17 GMT X-Mailer: YahooMailClassic/5.2.20 YahooMailWebService/0.7.289.1 Date: Mon, 4 May 2009 10:13:17 +0000 (GMT) From: Christian Kaas-Petersen To: mext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] binary filters draft 0 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, 04 May 2009 10:12:35 -0000 A few comments. * Flow description and flow descriptor seem to be used interchangeably. I should like to use flow description for what is presented in the draft, and flow descriptor as an index into a table (just like UNIX file descriptor is an index). In MEXT setting there is no need for flow descriptor, as the term flow identifier is used. * Figure 1 and Figure 3: I count 4 bits for the NxPs field, although the text says they are 3-bit fields. * Section 3.1. Hasn't TOS gone out of use, so that DSCP should be used instead? * Section 3.1. Address ranges are specified by a single address and a prefix, whereas port ranges are specified from low to high. I guess the motivation for this, is that addresses will most often be a single address (MIP) or a prefix (NEMO). I like to have such design rationales mentioned in the document. The traffic selectors of IPsec prefer address ranges from low to high value, and this document could have followed what IPsec is doing. * Section 3.1. In Source Port - High, why not stay firm: If only one port is of interest, Source Port - High must be absent. Somewhere, probably in flow binding draft, there will be an error code for a malformed flow description. Christian =0A=0A=0A Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - = http://dk.yahoo.com/r/pat/mm From arno@natisbad.org Mon May 4 06:09: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 F314C3A6B0E for ; Mon, 4 May 2009 06:09:07 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 KdL2GyU7kcog for ; Mon, 4 May 2009 06:09:05 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 0EB1D3A6A04 for ; Mon, 4 May 2009 06:09:05 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M0xvv-0004xJ-Dw; Mon, 04 May 2009 15:10:11 +0200 X-Hashcash: 1:20:090504:ryuji.wakikawa@gmail.com::51gg7abwwBJqtBiW:00000000000000000000000000000000000001Dq+ From: arno@natisbad.org (Arnaud Ebalard) To: Ryuji Wakikawa References: <49EF37D8.2010408@it.uc3m.es> <49FAC1A2.7060206@it.uc3m.es> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090504:mext@ietf.org::CqoQIpXADBWAqPfq:000008M3 X-Hashcash: 1:20:090504:jari.arkko@piuha.net::GMIJuXh9VIjvUqH5:000000000000000000000000000000000000000008RDY X-Hashcash: 1:20:090504:marcelo@it.uc3m.es::NSJ+YLI5JYHoQ+Bu:0000000000000000000000000000000000000000000DZgx Date: Mon, 04 May 2009 15:10:58 +0200 Message-ID: <87hc0157z1.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jari Arkko , mext Subject: Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-mip6-hareliability-04 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, 04 May 2009 13:09:08 -0000 Hi, Some comments on an inline version of draft-ietf-mip6-hareliability-04 are provided below. >From a general standpoint, I think the document is useful and provides a sensible solution to the problem while taking into account the various difficulties and possible cases. That been said, at some point during the reading, I started considering that the most interesting review would be (as usual) from someone that would have tried implementing *and testing* the protocol. Ryuji, are you aware of some tentative implementation or is it only a pure spec at the moment? Just a thought before starting: I understand the technical difficulties to implement the HA Virtual Switch functionality compared to the HA Hard Switch one but I think it is worth the effort both from a user (no additional traffic, no need for additional computations, code and logic), traffic and a management perspective. > Home Agent Hard Switch > > In the Home Agent Hard Switch, IPsec/IKE states synchronization is > not required. The home agents are addressed by different IP > addresses. When an active home agent fails, a mobile node will > receive a notification (Home Agent Switch message [RFC-5142]) from > a standby home agent, and send a Binding Update to the standby > home agent. In order for the mobile node to receive the Home > Agent Switch message securely from the standby home agent, the > mobile node needs to establish an IPsec SA with both the active > and the standby home agents beforehand. I understand the need for the SA to be available beforehand. Some questions though: - I guess that the pair of SA is similar to the ones negotiated between the HA and the MN, i.e. that they reference the HoA, not the CoA, don't they? - When the MN moves and the CoA changes, the IKE_SA on both sides (MN and standby HA) need to be updated. On the MN side, this is feasible because the MIPv6 module is aware of the handover and of the new CoA but because no exchange occur *directly* between the MN and the standby HA, this is trickier on the standby HA side. Is it expected that the handover information received from the state synchronization with the active HA be used for that purpose? If this is the case, it should be stated/described. If not, how is it done? Full rekeying initiated by the MN? > State Synchronization > > The information for mobile nodes must be able to be synchronized > between an active home agent and standby home agents. This > includes the Binding Cache, AAA information, other Mobile IPv6 and > NEMO related information. Note that the Home Agent Reliability > protocol exchanges only running states of mobile nodes. > Therefore, we do not have any specific operation for synchronizing > the configuration information. For instance, when Mobile IPv6 is > operated with Authentication protocol, the synchronizing the > configurations of the Authentication protocol is out of scope in "the synchronizing the configurations": first 'the' should be removed > this document. Operators MAY correctly configure in multiple home > agents. Maybe it's just my english, but I do not understand last sentence. > 4.1. Home Agent Virtual Switch > > A mobile node remains unaware about the change in the active home > agent since the home agents have replicated all session state > including IPsec/IKE/ESP states. IPsec/IKE/ESP state transfer is out > of scope of this document. What about changing 'IPsec/IKE/ESP' to 'IPsec/IKE' > 4.2. Home Agent Hard Switch > > The overview of the Home Agent Hard Switch is shown in Figure 2. > This mode is not transparent to the mobile node when the active home > agent failure occurs. > > > MN HA1(active) HA2(Standby) > | | | > |<--------->| | 1. IKE exchange (with HoA assignment) > |---------->| | 2. Binding Update > |<----------| | 3. Binding Acknowledgment > |<--------------------->| 4. IKE exchange (without HoA assignment) > | | | > | |<--------->. 5. State exchanges (binding cache) > | | | > | X | HA1 FAILURE > | X | > | X<----------| 6. Failure Detection > |<----------------------| 7. Sending Home Agent > | X | Switch message > |<--------------------->| 8. Binding Registration > | X | > | X | RECOVERY COMPLETE > > > Figure 2: Overview of Home Agent Hard Switch > > The mobile node establishes IPsec/IKE state with all the home agents > in the redundant home agent set beforehand (1 and 4), however it > registers its binding only with the active home agent (2 and 3). > When an active home agent fails, a standby home agent uses a pre- > existing IPsec SA to notify the mobile node about the failure by > securely sending a Home Agent Switch message. In order to discover > home agent addresses, two different mechanisms are defined, as > described in Section 9.4.1. The active home agent synchronizes the > required states of the mobile nodes, such as Binding Cache and AAA > information, with other standby home agents periodically (5). The > mobile node MUST NOT request a home address(es) assignment through > the IKE exchange to the standby home agent when it establishes an SA > with it (4). > > When the standby home agent detects the failure of the active home > agent (6), it sends a Home Agent Switch message to all the mobile > nodes that were registered with the failed home agent (7). The Home > Agent Switch message must be encrypted by a pre-established IPsec SA. > After the switch message, the mobile node MUST send a binding update > to the new active home agent in order to update the Mobile IPv6 > tunnel end points (8). s/end points/endpoints/ > 2: Reply-Ack > > The message is called State Synchronization Reply-Ack (SS-ACK) > and is used to acknowledge to the SS-REP. This message is s/acknowledge to/acknowledge/ > * IP Address Option (Sub-type: Home Address) defined in [RFC- > 5268]. If a home agent wants the Binding Cache information for > a particular mobile node, it includes the mobile node's home > address in an IPv6 Address Option. If a home agent want to wants to > solicit all the active mobile nodes' states, it can include the > unspecified address (0::0) in an IPv6 address option. s/0::0/::/ > 5.1.4. Home Agent Switch Message > > This message is defined in Section 9.4.3. The Home Agent > Reliability protocol extends this message for the Home Agent Hard > Switch. Waht about changing those two sentences for the following: "This message is defined in [RFC5142]. The Home Agent Reliability protocol extends this message for the Home Agent Hadr switch, as described below. Its precise use in the context of HA reliability mechanism is defined in section 9.4.3." > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |# of Addresses |I| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > . Home Agent Addresses . > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . Mobility options . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 7: Home Agent Switch Message > > IPsec Re-key (I) > > The IPsec re-key (I) bit is set to indicate that the mobile node > SHOULD start an IPsec re-key with the home agent specified in the > Home Agent Addresses field. This flag is used when a failed home > agent recovers and needs to re-establish IPsec SA/IKE state with a > mobile node. When this flag is set, the mobile node does not > switch the home agent, but only re-key the SA. If I understand things correctly, when a Home Agent Switch message is sent to a MN by a standby HA, it means that the MN should send a binding update to the standby HA (referenced in the Home Agent Addresses field of the message), *except* when the I flag is set in the message which in that case means that the MN should perform an IKE negotiation with the HA in the Home Agent Addresses field *but* not send a binding update to that HA. If that is correct, this breaks the semantic of the message. In that case, having a simple flag changing the whole purpose of the message looks like a bad idea. I reread RFC5142 (more precisely the end of section 5.1 and the content of section 6.1 describing how the MN should process the message). 2 cases are described (from a MN perspective): - Home Agent Switch message is sent by a HA which is our current HA, containing one or more addresses which should be considered in order. In all cases, the MN is expected to send a de-registration binding and send a BU to the first HA of the list. - Home Agent Switch message is sent by a HA which is not our current HA: the message SHOULD contain one address, which is the address of the sender of the message, which implies the MN should switch to the sender of the message, i.e. send a BU. Current proposal in section 5.1.4 of the draft would basically add the additional third case: - Home Agent Switch message is sent by a HA (standby or not based on what is in 9.4.3, but chances are high is is the active HA) *with* I flag set *and* an address different from the one of the sender. In that case, the MN does not switch, it just setup an IPsec SA with the addresses in the message. In the context of Hard Switch mechanism, I understand the need to have the MN set up SA with the reborn HA (in order for that standby HA to be able to send switch messages later in the process). But IMO that "Please rekey" feature needs a different (MH) container. > Reserved > > The reserve field is reduced from 8 to 7 bits s/reserve/reserved/ > 5.2.2. Binding Cache Information Option > > The binding cache information option has an alignment requirement of > 8n+2. The Binding Cache Information option is only valid in a State > Synchronization message. Its format is as follows: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD | Length = 40 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lifetime | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | Home Address | > + + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Care-of Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . . > . Mobile Network Prefix Option . > . . > . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 8: Binding Cache Information Option > > The fields of Home Address, Care-of Address, Flags, Sequence Number, > and Lifetime are copied from the registered binding of a particular > mobile node or mobile router. The 8-bit Reserved field MUST be set 16-bit > 5.2.3. AAA Information Option > > This option is used to carry the AAA state of the mobile node's > Mobile IPv6 sessions. The AAA state information can be carried in > RADIUS or Diameter AVP formats including the user and session info. > This information option is only valid in a State Synchronization > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . . > . AAA AVPs . > . . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 9: Vendor Specific Inforamtion Option Information > 7. Home Agent Common Operation > > 7.1. Home Agent List Management > > In Mobile IPv6 [RFC-3775], each home agent periodically sends router > advertisements with the Home Address Information option [RFC-3775] > when there are multiple home agents present on a link. This > information is managed in a home agent list. For the Home Agent > Reliability Protocol, HA-HELLO messages are used to manage the home > agent list. There are several reasons to use HA-HELLO message > instead of Router Advertisement such as: > > 1. In the Home Agent Virtual Switch mode, if the standby home agents > send unsolicited Router Advertisements to the home link, the > mobile nodes attached to the home link are aware of the presence > of standby home agents. However, the standby home agents must be > hidden until the active home agent fails. HA-Hello messages are > exchanged only between home agents. > > 2. As shown in Section 6.1, standby home agents are not always > configured at the same link. In this case, Router Advertisements > cannot be sent to the recovery link unless the home link and the > recovery link are connected (ex. L2TP). HA-HELLO can be sent > beyond the link. > > 3. The Home Agent Reliability protocol defines to manage s/defines/is defined to/ > additional information such as Group ID and Active/Standby > Status of the home agents in the home agent list. > In Mobile IPv6, Router Advertisement are to carry the home agent > information to both mobile nodes on the home link and the home > agents. On the other hand, in the Home Agent Reliability protocol, > HA-Hello is to exchange the information among the home agents and the > Router Advertisement is used to notify the information to the mobile > nodes. nodes on the home link. > 7.3.2. Sending Hello Message > > Each home agent periodically sends HA-HELLO for the home agent's > failure detection. The interval time is configured at each home > agent. Each home agent MUST also send a HA-HELLO in following case: > > 1. when a home agent receives a HA-HELLO with the R-flag set > > 2. When a home agent detects its local information such as home > agent preference, home agent lifetime, and registration status > change. > > 3. When a new home agent boots up, it SHOULD solicit Hello messages > by multicasting a Hello message with the R-flag set in parallel > with sending its own Hello message. > > When a home agent sends HA-HELLO, the following rule MUST be applied. > o Whenever a home agent generates HA-HELLO, it MUST increment in s/increment in/increment/ > o If the source IPv6 address of HA-HELLO is not belong to one of s/is not belong/does not belong/ > o If the Group ID field of the received HA-HELLO and the receiver's > Group ID is different, HA-HELLO MUST be discarded. HA-HELLO MUST > NOT be sent to home agents whose Group ID is different from the s/sent/unicasted/ > o If the Sequence Number value in the HA-HELLO is equal to or less > than the last received Sequence Number value stored in the home > agent list entry, the HA-HELLO MUST be discarded. Except when the number wraps, I imagine. > 7.4.1. Requesting State of a Particular Mobile Node(s) > > When a home agent needs the state information for a particular mobile > node or a subset of mobile nodes, it sends a SS-REQ message > constructed as follows: > > o It MUST set the Type field to 0 (Request). > > o It MUST set a random value in the Identifier field that does not > coincide with any other currently pending Requests. > > o It MUST include an IP address mobility option(s) which subtype is > set to the home address if the target is mobile node(s). > > o It MUST include a Mobile Network Prefix mobility option(s) for > mobile router(s). > > o It MUST set the unspecified address (0::0) in the Home Address s/0::0:/::/ > 7.4.2. Synchronizing State > > State synchronization messages SHOULD be sent when: > > 1. The active home agent receives SS-REQ. > > 2. The active home agent creates a binding cache entry for a > particular mobile node. > > 3. The active home agent deletes a binding cache entry for a > particular mobile node. > > The active home agent MAY additionally send state synchronization > message in following cases: > > 1. The active home agent update the state information for all > sessions that changed since the last update in a periodic > interval > > 2. Only for the Home Agent Virtual Switch mode, the active home > agent updates a binding cache entry for a particular mobile node > whenever the binding cache entry is updated. In the Home Agent > Hard Switch mode, standby home agents only need the mapping > information of a home address of the mobile node/router and the > home agent address of the active home agent to which the mobile > node/router is currently registering. This mapping is used to > send a Home Agent Switch message. > > If an active home agent sends a State Synchronization message > whenever the local state information changes, such as a binding cache > change, the number of the State Synchronization messages sent can be > quite large. > > All the state information of the requested mobile nodes is stored in > the SS-REP. Following rules must be applied when the active home > constructs SS-REP. the active home agent constructs SS-REP. > o If the unspecified address is found in the Home Address mobility > option carried with the SS-REQ, the active home agent MUST return > the state of all the active mobile nodes and mobile routers by the > SS-REP. The IP fragmentation can be occurred depending on the > total size of all the states. What about changing last sentence by: "The message may be fragemented depending on the total size needed to carry all states" > 7.5.2. Active Home Agent becomes in-active inactive > 7.6. Interworking with VRRP not that familiar with VRRP, I skipped the section. > 8.1. Consideration of Routing and Neighbor Discovery Protocol > > This section gives a brief explanation of how a home agent interacts > with routing and Neighbor Discovery Protocol (NDP) when the Home > Agent Virtual Switch mode is used. > > When a standby home agent becomes active in the Home Agent Virtual > Switch mode, it MUST start to advertise the home agent address and > the home prefix of the home addresses serviced by the redundant home > agent set into the routing infrastructure. This operation is > normally done using a route selector such as BGP or an OSPF modifier. > For example, we can use the AS_Path prepend operation for BGP, and > the Metric field in OSPF for the route selection. When each home > agent participates in OSPF routing, each home agent should be > configured with the appropriate metric matched to the home agent > preference value. When the active home agent fails, OSPF detects the > failure and can dynamically switch the route to the standby home > Agent based on the OSPF cost value. If this cost conflicts with s/cost/creates/ > 9.1. Home Agent Recovery > > After detecting the active home agent has failed, the standby home > agent whose preference value is the highest MUST take over the failed > home agent. The standby home agent MUST send a Home Agent Switch > message to all the mobile nodes that were registered at the failed > home agent as described in Section 9.2, using the pre-established > IPsec SA. The standby Home Agent MUST set its own address in the > Home Agent Address field in the Home Agent Switch message so that it > will receive the binding update from the mobile node as an > acknowledgment of the sent Home Agent Switch message. The home acknowledgement > 9.2. Sending Home Agent Switch Messages > > The standby home agent which is going to be active MUST send a Home > Agent Switch message as defined in [RFC-5142] to all the mobile nodes > that were being served by the failed home agent. The Home Agent > Switch message must be securely sent to the mobile node by using > IPsec ESP. The standby home agent MUST include only its own home > agent address in the Home Agent Switch message. When it gets active. At the moment, when I flag is set, it contains the address of another HA. > When a failed home agent recovers, it MUST re-establish an IPsec SA > with each mobile node served by its redundant home agent set. > Otherwise, it cannot be either a standby or active home agent for the > mobile nodes. Therefore, as soon as the active home agent detects > the recovery of the failed home agent, it sends a Home Agent Switch > message with the I-flag set to all the mobile nodes serving by other s/serving/served/ > 9.4.2. IKE/IPsec pre-establishment to Home Agents > > After a mobile node obtains multiple home agent addresses, it needs > to trigger multiple IKE exchanges with the multiple home agents > selected from the home agent list. Since both IKEv1 and IKEv2 can be > used to bootstrap Mobile IPv6, this solution does not introduce any > new operations to co-operate with IKEv1 or IKEv2. It should initiate > IKE for home agents as soon as home registration is complete. > > The mobile node MUST follow the standard IKEv2 exchange in the > bootstrapping solution of the split scenario [RFC-5026]. Home > Address configuration maybe also be included, if necessary, for the > first IKE exchange. After its Home Address is assigned or approved > by the first home agent, mobile node SHOULD register itself with the > second home agent with IKE using the same Home Address. Therefore, > no home address configuration should be used in the second IKEv2 > procedure. Note that the mobile node only sends a Binding Update > message to the first home agent. I have the feeling that this subsection should be extended in order to describe what happens when a handover occurs, from an IKE standpoint (IKE_SA management/update on both sides) between the reborn HA and the MN. > 9.4.3. Receiving Home Agent Switch message > > A mobile node must follow the operation specified in [RFC-5142] when > it receives a Home Agent Switch message. > > If the I-flag is set in the received Home Agent Switch message, the > mobile node MUST re-key the SA with the home agent addresses stored > in the Home Agent Addresses field. The mobile node MUST NOT change > its active home agent when the I-flag is set. If the home agent > address is not known from the bootstrapping described in > Section 9.4.1, the mobile node MUST NOT start an IKE session with the > unknown home agent. Instead, it SHOULD re-start home agent discovery > again to update its home agent address information. > > When the mobile node receives a Home Agent Switch message without > I-flag set, and if the message contains the IPv6 address of a standby > home agent, it MUST select the standby home agent in the switch > message as the active home agent and send a new Binding Update > > message to it. Note that the standby home agent address in the Home > Agent Switch MUST be equal to the sender of the Home Agent Switch > message. The standby Home agent expects the Binding Update as an > acknowledgment of the Home Agent Switch message. The mobile node > already has a pre-established SA with the standby home agents and > should use that SA to send the Binding Update. If the address stored > in the Home agent address field is different from the sender, the > mobile node MUST send a binding update to the sender. I already provided some comments about the content of that section at the beginning of the review. > 10. Security Considerations > > Since Mobile IPv6 operation requires ESP in transport mode between > the mobile node and the home agent, we will discuss the ESP field > synchronization issues between the mobile node and the redundant set > of home agents. This synchronization is required only for Home Agent > Virtual Switch mode. Most of fields should be synchronized based on > [RFC-4301]. The ESP header has the following fields: > > SPI > > This field identifies the SAD at the receiver. > > The mobile node negotiates only one IPsec SA. Hence, the SPI > value will remain unchanged upon home agent failover. > > Sequence Number > > This field is used for "anti-replay" feature of ESP. The > transmitter must include this monotonically increasing number. > The receiver may process the sequence number based on local > policy. > > The mobile node and the redundant home agent set will have the > same set of sequence numbers for transmit and receive. Hence, > synchronization of the sequence number field is mandatory in this > mode of operation. > > The SA1, SA2, SA3, SA4 could be synchronized between the home > agents as these messages are not sent continuously. Moreover for > the Binding Update case, if the mobile node is in the middle of > sending a Binding Update to an active home agent for a binding > refresh, and the active home agent is not available at that > moment, the mobile node will not get any response from the active > home agent. After a standby home agent becomes active, the mobile > node will retry and it will receive the Binding Update from the > mobile node with a sequence number that is +n from its last known > sequence number for SA1. For the Binding Acknowledgment case > (SA2), the standby home agent SHOULD add a random number to the > last known sequence number over and above the replay window to > ensure that the packet passes the replay check at the mobile node. > The same applies to HoTi and HoT messages with SA3 and SA4. Note > that this windowing of the sequence numbers for Mobile IPv6 > signaling is only needed to cover the corner cases when Binding > Update or HoTi is in-flight and the active home agent fails. > > The technique explained above should work for user data packets if > ESP is used to encrypt user data traffic as well. The actual > switchover time and the routing infrastructure convergence time is > the only latency that the user may perceive. > > Initialization Vector > > Since the Initialization Vector will be delivered in each exchange > between a mobile node and home agent, this field is not > necessarily synchronized between home agents. > > Others > > Other fields should be synchronized based on RFC4301 [RFC-4301] > > In the Home Agent Hard Switch mode, the standby home agent needs to > send a Home Agent Switch message using IPsec encryption. Since the > mobile node has pre-established an IPsec SA with both the active and > standby home agents, the standby home agent can send the message to > the mobile node with the pre-established IPsec SA. I wonder if previous text really belongs to the "Security Considerations" section. IMHO, it should be in a dedicated section. Cheers, a+ From ryuji.wakikawa@gmail.com Mon May 4 11:10: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 786AA3A7043 for ; Mon, 4 May 2009 11:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZsJ94jsqpU3 for ; Mon, 4 May 2009 11:10:27 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id AAAA53A6C1E for ; Mon, 4 May 2009 11:10:27 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so2666178rvb.49 for ; Mon, 04 May 2009 11:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=PWjnMCIRCbRKmGQ453a3AnaIkhlI0hK2YuggaFAo19E=; b=SBjdUXQic9h89Qh/WqbURVYsgycK684iVG6yN38xEA3RXc0tLLhnrtvXaVebKwDRK1 S4PJEu46is3WjwtmOF0tx+pYh7lw4pGPg9TMfMilmLH3nsmW2w9JJxjBv6oK9zYWPS7A dPxmDaEAdPi7xCo5Vxup1dWJ+ldy1xdI/i9D0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=xSsryJ/+LSm+PrEKfvM5idDjiG4cOYEvt5IT32gq+fnDMIzKe/0Nl0H1iT/+cZ3/ku QCq8UjysCuUA29b+rKVYJW0hvqWSU6BeN2qEq74KnmAHYuSyRbq23ZmItVfSm2sf/80I IPGZ2DdfvlLUTKCOCW8jmzIkOaIdEWnPCHCyw= Received: by 10.141.137.16 with SMTP id p16mr2195109rvn.180.1241460711984; Mon, 04 May 2009 11:11:51 -0700 (PDT) Received: from ?192.168.110.115? ([206.132.173.18]) by mx.google.com with ESMTPS id g14sm15910542rvb.2.2009.05.04.11.11.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 May 2009 11:11:51 -0700 (PDT) From: Ryuji Wakikawa To: marcelo bagnulo braun In-Reply-To: <49EF37D8.2010408@it.uc3m.es> References: <49EF37D8.2010408@it.uc3m.es> Message-Id: <5BD29D7D-9C20-42CC-9C75-35AAEA70FD82@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 11:11:48 -0700 X-Mailer: Apple Mail (2.930.3) Cc: Jari Arkko , mext Subject: Re: [MEXT] Moving forward with MEXT documents 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, 04 May 2009 18:10:28 -0000 Hi Marcelo, 1. The following two document are ready for WGLC. These documents are stable for long time. WGLC can be done at the same time. draft-ietf-monami6-mipv6-analysis-05 draft-ietf-monami6-multihoming-motivation-scenario-03 2. draft-ietf-mip6-hareliability This document is also stable for a long time. The WGLC is good phase to receive the inputs from MEXT. 3. These are -00 documents. I don't remember if they have any comments after -00. If there are any, it's better to wait for -01 documents. draft-ietf-mext-firewall-admin/vendor regards, ryuji On 2009/04/22, at 8:29, marcelo bagnulo braun wrote: > Hi, > > At this point in time, the WG has the following documents that are > ready for WGLC: > > draft-ietf-mext-firewall-admin-00 draft-ietf-mext-firewall- > vendor-00 draft-ietf-mip6-hareliability-04 draft- > ietf-monami6-mipv6-analysis-05 draft-ietf-monami6- > multihoming-motivation-scenario-03 > > And the following document that we need to ask for adoption: > > draft-premec-mext-extended-home-link-01 > > According to our new ground rules, each of these documents to > proceed will need 5 thorough reviews. Since this is a considerable > amount of effort from the WG, we would like soem feedback on how to > manage this effort. In particular, we would like to get feedback > from the WG about which documents should we issue the WGLC or > adoption call first and if possible volunteers to do the reviews for > the documents. > > We will receive input on this till the 3rd of may and then decide > how to move forward. > > Regards, marcelo > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From behcetsarikaya@yahoo.com Mon May 4 11:47: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 56ECE3A684F for ; Mon, 4 May 2009 11:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.829 X-Spam-Level: X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_LWSHORTT=1.24] 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 yeHTjRp4CyuP for ; Mon, 4 May 2009 11:47:00 -0700 (PDT) Received: from n56.bullet.mail.sp1.yahoo.com (n56.bullet.mail.sp1.yahoo.com [98.136.44.52]) by core3.amsl.com (Postfix) with SMTP id F39CC3A6B87 for ; Mon, 4 May 2009 11:46:59 -0700 (PDT) Received: from [216.252.122.217] by n56.bullet.mail.sp1.yahoo.com with NNFMP; 04 May 2009 18:48:24 -0000 Received: from [67.195.9.83] by t2.bullet.sp1.yahoo.com with NNFMP; 04 May 2009 18:48:24 -0000 Received: from [67.195.9.97] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 04 May 2009 18:48:24 -0000 Received: from [127.0.0.1] by omp101.mail.gq1.yahoo.com with NNFMP; 04 May 2009 18:48:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 705569.18084.bm@omp101.mail.gq1.yahoo.com Received: (qmail 94856 invoked by uid 60001); 4 May 2009 18:48:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241462903; bh=tl1r7+p/eYhdu41locinXT8QxCLcaZdF3FVI3rqgG1g=; 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=JS+HR1ymkwQlLmbonXmgT2pOHT1sD1y5Tbsx1lO87suHSwhGqX4pqmx6SSVfZ2XXTUxNczyS9/qZsixpPEJlBCFyEeSV+ybladRoBhoRSLyNkplbsSN7JIqohZZsQlY0Viwtx+OFfRuE32PBzt9tPwTMLyL61HGWD/OCH38Y+vY= 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=KlTE53IEPd79YhW2nX2ZpuE+lqepJBuN7J0CkCkbKxGoPqskaazRM8nT6fQVS3+GbCujkgnNAP3ll6z8DdJROa5WseddBlzystdc7wA0/lFSEe41/goQSC+idmt2h/GqTwemOv1L9S8DEVMU/yyYz3ZVrM4eSHYe/kA7xAdEwpw=; Message-ID: <701538.94514.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: eC6pNRIVM1lNtS8NrGZrTa5VyOGwWPzjbqWVtRTSIhVv0k_7wQXPjzSBg.jGsq7iTftj_w2YkI2_euhKPK2y4DTdsEGSM_49qXLKGXnSFxSPzki_p7OQmrWY82YGOYojbLpkXx.1zIRwdx5brPgKbzopCTCzjW5.ysJkoOe1JZnDhzchpLyTCL2O8L5eVYFgbypdgoT38yAYl.wzq4vWwTj_bQAUft9Y_PMiRHzK7bq8.rX4.OWXx9.sb3ReuqFivVeQYsY3Z.TZIrkGptMiqFS6wivyW8hwF3Z_02Oc.Gcz5_XvVUWtbXj8VSVKQyeDxz78mfsLCNFrtVLg Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Mon, 04 May 2009 11:48:23 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: Date: Mon, 4 May 2009 11:48:23 -0700 (PDT) From: Behcet Sarikaya To: Hesham Soliman In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-170502453-1241462903=:94514" Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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: Mon, 04 May 2009 18:47:06 -0000 --0-170502453-1241462903=:94514 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hesham,=0A=A0 You sounded like there was nothing new in this version as = to MCoA draft .=0AYou added binding identifier mobility option in Sec. 4.1 = which comes even before the main option of flow identification mobility opt= ion.=0A=A0 There is probably no need to discuss these things more again, I = am OK with the previous versions in which there is an optional binding refe= rence sub-option and I am OK with an informative reference to the MCoA draf= t.=0A=A0 Yes I was referring to the 2006 discussions.=0A=0ARegards,=0A=0ABe= hcet=0A=0A=0A=0A=0A________________________________=0AFrom: Hesham Soliman = =0ATo: Behcet Sarikaya ; Chris= tian Kaas-Petersen ; mext@ietf.org=0ASent: Friday, M= ay 1, 2009 9:47:03 PM=0ASubject: Re: [MEXT] flow binding draft 2=0A=0AHi Be= hcet=0A=0A=0A> -My biggest concern is there has been an artificial attempt = in this version to=0A> introduce/increase dependency on MCoA draft.=0A=0A= =3D> First, "introduce" and "increase" are not synonyms so which one did yo= u=0Awant? We certainly didn't introduce this in this rev. Support for MCoA = was=0Aincluded in 2006 if I remember correctly. I did ask the question in t= he last=0Ameeting to see if people had any opinions on mandating the use of= MCoA and=0Areceived no feedback. So the authors discussed it and we though= t it was=0Aeasiest to mandate it and avoid confusion.=0AYou mention that it= 's your biggest concern; why is that?=0A=0A> I would like to ask why?=0A> I= would like to ask Hesham if he personally agrees, pointing to the fact tha= t=0A> he made public comments contrary to this?=0A=0A=3D> Which public comm= ents are you referring to? As far as I remember I was=0Anot convinced in 20= 06 that adding MCoA was necessary but I was convinced by=0Apeople on the li= st that it was a good idea so we agreed to include it back=0Athen. What com= ments are you referring to?=0AAnyway, I'm not a politician; so I can say so= mething and be proven wrong and=0Aaccept that. I'm still not sure why you t= hink this is a concern for the=0Adraft.=0A=0AHesham=0A=0A> =0A> =A0 Note th= is is not a full review.=0A> =0A> Regards,=0A> =0A> Behcet=0A> =0A> =0A> = =0A> =0A> ________________________________=0A> From: Christian Kaas-Peterse= n =0A> To: mext@ietf.org=0A> Sent: Friday, May 1, 20= 09 6:39:03 AM=0A> Subject: [MEXT] flow binding draft 2=0A> =0A> =0A> Having= read draft-ietf-mext-flow-binding-02, I should like to be=0A> informed abo= ut two design rationales.=0A> =0A> The first is related to the PRO field in= the Flow Identification Mobility=0A> Option.=A0 The mobile node must expli= citly inform if it is an Add or a=0A> Modify operation; the mobile node doe= s implicitly inform if it is a=0A> delete operation.=A0 In principle there = is no need for the PRO field.=0A> There are three cases.=0A> =0A> (a) If a = FID-value is absent in BU and=0A> =A0 =A0 present in Flow Binding List=A0 = =A0 =A0 =A0 =3D> remove=0A> (b) If a FID-value is present in BU and=0A> =A0= =A0 absent in Flow Binding List=A0 =A0 =A0 =A0 =3D> add=0A> (c) If a FID-v= alue is present in BU and=0A> =A0 =A0 present in Flow Binding List=A0 =A0 = =A0 =A0 =3D> modify=0A> =0A> With these cases PRO field can be removed.=A0 = Alternatively, one could take=0A> the other extreme, also explicitly naming= the FID-values to be removed.=0A> =0A> The document has made an in-between= choice.=A0 I'm not suggesing a change,=0A> I'm looking for an explanation.= =0A> =0A> The other item relates to what in section 4.4 is denoted a "valid= BID".=0A> When a BU wants to insert a FID-entry, and this FID-entry refers= to one=0A> or more BID-values, all of those BID values must be found in th= e=0A> BID Entries List, and thus an entry will always achieve the Active st= ate.=0A> However, at later times BID-entries may be removed, and so a state= may=0A> change to Inactive.=A0 What is reason for a state not being allowe= d=0A> Inactive to start with?=A0 Again, I'm just looking for an explanation= ..=0A> =0A> A few minor points.=0A> =0A> * Abstract: uses the word "peer" as= a short term for correspondent node,=0A> =A0 home agent, and mobility anch= or point.=A0 In general, a mobile node's=0A> =A0 peers are all the nodes wi= th which it has TCP/UDP sessions.=A0 I think=0A> =A0 the term "peer" has a = too wide interpretation.=0A> =0A> * Section 4.1, in the description of BID-= PRI field, the words "a higher=0A> =A0 number" assumes reading the 7-bit fi= eld as an unsigned integer.=0A> =0A> * Section 4.2, in FID description, 8-b= it should be 16-bit.=0A> =0A> * Section 4.2, in 1 Forward, a forward refere= nce for Binding Reference=0A> =A0 sub-option would be helpful when reading = this document first time.=0A> =0A> * Section 4.3, in Option Type, I think a= copy from the section 4.2.1.=0A> =0A> * Section 4.4, para 2, one of the wo= rds "change" or "modify" should be=0A> =A0 enough.=0A> =0A> * Section 4.4, = Action bullet: "PRO field" to be replaced with=0A> =A0 "Action field".=0A> = =0A> * Section 4.4, para just above Ordered Flow Binding Entries, "three fl= ow=0A> =A0 bindings" to become "four flow bindings".=0A> =0A> Christian=0A>= =0A> =0A> =0A> =0A> =A0 =A0 =A0 Find din nye laptop p=E5 kelkoo.dk. Se de = gode tilbud her -=0A> http://dk.yahoo.com/r/pat/mm=0A> ____________________= ___________________________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> htt= ps://www.ietf.org/mailman/listinfo/mext=0A> =0A> =0A> =0A> ________________= _______________________________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A>= https://www.ietf.org/mailman/listinfo/mext=0A=0A=0A --0-170502453-1241462903=:94514 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hesham,
=0A
  You sounded like there = was nothing new in this version as to MCoA draft .
=0A
You added binding identifi= er mobility option in Sec. 4.1 which comes even before the main option of f= low identification mobility option.
=0A
  There is probably n= o need to discuss these things more again, I am OK with the previous versio= ns in which there is an optional binding reference sub-option and I am OK w= ith an informative reference to the MCoA draft.
=0A
  Yes I w= as referring to the 2006 discussions.
=0A
 
=0A
Rega= rds,
=0A
 
=0A
Behcet
=0A

=0A<= DIV style=3D"FONT-SIZE: 13px; FONT-FAMILY: arial, helvetica, sans-serif">=0A
=0AFrom: Hesham Soliman <hesham@elevatemobile.com>To: Behcet Sarikaya <sa= rikaya@ieee.org>; Christian Kaas-Petersen <kaaspetersen@yahoo.dk>;= mext@ietf.org
Sent: Fri= day, May 1, 2009 9:47:03 PM
Subject= : Re: [MEXT] flow binding draft 2

Hi Behcet

> -My biggest concern is there has been an artificial attempt in th= is version to
> introduce/increase dependency on MCoA draft.

= =3D> First, "introduce" and "increase" are not synonyms so which one did= you
want? We certainly didn't introduce this in this rev. Support for M= CoA was
included in 2006 if I remember correctly. I did ask the question= in the last
meeting to see if people had any opinions on mandating the = use of MCoA and
received no feedback. So the authors discussed it and we thought it was
easiest to mandate it and av= oid confusion.
You mention that it's your biggest concern; why is that?<= BR>
> I would like to ask why?
> I would like to ask Hesham if = he personally agrees, pointing to the fact that
> he made public comm= ents contrary to this?

=3D> Which public comments are you referri= ng to? As far as I remember I was
not convinced in 2006 that adding MCoA= was necessary but I was convinced by
people on the list that it was a g= ood idea so we agreed to include it back
then. What comments are you ref= erring to?
Anyway, I'm not a politician; so I can say something and be p= roven wrong and
accept that. I'm still not sure why you think this is a = concern for the
draft.

Hesham

>
>   Note th= is is not a full review.
>
> Regards,
>
> Behcet<= BR>>
>
>
>
> ________________________________
> From: Christian Kaas-Petersen <= ;kaaspetersen@yahoo.dk>
> To: mext@ietf.org
> Sent: Fr= iday, May 1, 2009 6:39:03 AM
> Subject: [MEXT] flow binding draft 2>
>
> Having read draft-ietf-mext-flow-binding-02, I sho= uld like to be
> informed about two design rationales.
>
&g= t; The first is related to the PRO field in the Flow Identification Mobilit= y
> Option.  The mobile node must explicitly inform if it is an = Add or a
> Modify operation; the mobile node does implicitly inform i= f it is a
> delete operation.  In principle there is no need for= the PRO field.
> There are three cases.
>
> (a) If a FI= D-value is absent in BU and
>     present in Flow Binding List        =3D> remove
> (b) If a FID-value = is present in BU and
>     absent in Flow Binding List = ;       =3D> add
> (c) If a FID-value is present in= BU and
>     present in Flow Binding List    &nb= sp;   =3D> modify
>
> With these cases PRO field can b= e removed.  Alternatively, one could take
> the other extreme, a= lso explicitly naming the FID-values to be removed.
>
> The do= cument has made an in-between choice.  I'm not suggesing a change,
= > I'm looking for an explanation.
>
> The other item relate= s to what in section 4.4 is denoted a "valid BID".
> When a BU wants = to insert a FID-entry, and this FID-entry refers to one
> or more BID= -values, all of those BID values must be found in the
> BID Entries L= ist, and thus an entry will always achieve the Active state.
> However, at later times BID-entries may be removed, and so a state may
= > change to Inactive.  What is reason for a state not being allowed=
> Inactive to start with?  Again, I'm just looking for an expla= nation.
>
> A few minor points.
>
> * Abstract: u= ses the word "peer" as a short term for correspondent node,
>   = home agent, and mobility anchor point.  In general, a mobile node's>   peers are all the nodes with which it has TCP/UDP sessions.&nb= sp; I think
>   the term "peer" has a too wide interpretation.>
> * Section 4.1, in the description of BID-PRI field, the wor= ds "a higher
>   number" assumes reading the 7-bit field as an u= nsigned integer.
>
> * Section 4.2, in FID description, 8-bit = should be 16-bit.
>
> * Section 4.2, in 1 Forward, a forward r= eference for Binding Reference
>   sub-option would be helpful when reading this document first time.
>
> * Section = 4.3, in Option Type, I think a copy from the section 4.2.1.
>
>= ; * Section 4.4, para 2, one of the words "change" or "modify" should be>   enough.
>
> * Section 4.4, Action bullet: "PRO fi= eld" to be replaced with
>   "Action field".
>
> * = Section 4.4, para just above Ordered Flow Binding Entries, "three flow
&= gt;   bindings" to become "four flow bindings".
>
> Chris= tian
>
>
>
>
>       Find = din nye laptop p=E5 kelkoo.dk= . Se de gode tilbud her -
> http://dk.yahoo.com/r/pat/mm
> = _______________________________________________
> MEXT mailing list> ME= XT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
> >
>
> _______________________________________________
= > MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/li= stinfo/mext



=0A=0A --0-170502453-1241462903=:94514-- From w52006@huawei.com Mon May 4 17:56: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 726413A69FE for ; Mon, 4 May 2009 17:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.594 X-Spam-Level: X-Spam-Status: No, score=0.594 tagged_above=-999 required=5 tests=[AWL=-1.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=0.6, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] 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 GzMz4NRFjyXe for ; Mon, 4 May 2009 17:56:51 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B8A233A69FC for ; Mon, 4 May 2009 17:56:50 -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 <0KJ500G4TC0US3@szxga04-in.huawei.com> for mext@ietf.org; Tue, 05 May 2009 08:58:06 +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 <0KJ500GBUC0U9X@szxga04-in.huawei.com> for mext@ietf.org; Tue, 05 May 2009 08:58:06 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ5002XQC0TFF@szxml04-in.huawei.com> for mext@ietf.org; Tue, 05 May 2009 08:58:06 +0800 (CST) Date: Tue, 05 May 2009 08:58:05 +0800 From: Yungui Wang In-reply-to: To: 'George Tsirtsis' Message-id: <000001c9cd1c$8cb8a7e0$150ca40a@china.huawei.com> Organization: huawei 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: AcnMk6i94KTeV7lGR3KPWntHJdOk8wAgpdig Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 05 May 2009 00:56:52 -0000 Hello I agree with you that "not do the same thing with multiple ways". However, I don't think new version of this draft is good designed on the REMOVE operation. You could try to implement a simple example: One MN has added 100 flows to HA. Following one additional flow is dynamically to be added, it has to also carry the previous 100 flows to HA. Do you think it is indeed acceptable? There are two ways which are usually designed for session/binding deletion for your information: 1, explicit REMOVE operation; or 2, add parameter: lifetime of FID; BU(FID, lifetime=0), => delete the FID. In this way, below nits can be avoided in this draft: i) implicit REMOVE operation; ii) useless Inactive state; B.R. Yungui > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Monday, May 04, 2009 4:38 PM > To: w52006@huawei.com > Cc: Christian Kaas-Petersen; mext@ietf.org > Subject: Re: [MEXT] flow binding draft 2 > > inline > > On Mon, May 4, 2009 at 8:12 AM, Yungui Wang wrote: > > > > Hello > > > > I do think it is necessary to keep the REMOVE operation. In > > my understanding, the explicit REMOVE operation can avoid > > that, once a certain flow is added/modified, all the flows have > > to be updated. In addition, you mentioned implicit REMOVE > > operation (remove FID by not including it in reg-BU) should be > > disallowed. > > > > GT> As I already explained in the exchange with Christian, an explicit > REMOVE operation is indeed possible. It is not, however, preferable > since it would result in two ways of removing an FID. It is not good > design practice to have multiple ways of doing the same thing, and in > this case there is no reason to do so. > > > Secondly, from the draft's description and your explanation, > > I don't find that the Inactive status is similar meaningful. > > It has to be updated to active state if the inactive flow is > > enabled to be used. > > Maybe the only reason why the Inactive status exists is > > the confusion of Remove operation (two ways) you mentioned. > > However, I don't think this reason is very good. The general > > operation of BID deletion could be: when a BID is being > > deleted, MN and HA both should modify its associated > > FIDs to refer new BID or delete them. > > > > > GT> Again, as I already explained the inactive state is there for the > same reasons i.e., to avoid two ways of doing the same thing. > > Regards > George > > > > > B.R. > > Yungui > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >> Behalf Of George Tsirtsis > >> Sent: Friday, May 01, 2009 8:04 PM > >> To: Christian Kaas-Petersen > >> Cc: mext@ietf.org > >> Subject: Re: [MEXT] flow binding draft 2 > >> > >> Hi Christian, > >> > >> Wow, very quick turnaround, and a good review, thanks! > >> > >> Marcelo, are you counting? :-) > >> > >> See comments inline... > >> > >> On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen > >> wrote: > >> > > >> > Having read draft-ietf-mext-flow-binding-02, I should like to be > >> > informed about two design rationales. > >> > > >> > The first is related to the PRO field in the Flow > >> Identification Mobility > >> > Option. ?The mobile node must explicitly inform if it is > an Add or a > >> > Modify operation; the mobile node does implicitly inform > if it is a > >> > delete operation. ?In principle there is no need for the > PRO field. > >> > There are three cases. > >> > > >> > (a) If a FID-value is absent in BU and > >> > ? ?present in Flow Binding List ? ? ? ?=> remove > >> > (b) If a FID-value is present in BU and > >> > ? ?absent in Flow Binding List ? ? ? ? => add > >> > (c) If a FID-value is present in BU and > >> > ? ?present in Flow Binding List ? ? ? ?=> modify > >> > > >> > With these cases PRO field can be removed. ?Alternatively, > >> one could take > >> > the other extreme, also explicitly naming the FID-values to > >> be removed. > >> > > >> > >> GT> You are right that instead of ADD/MOFIDY we can always > overwrite > >> existing FID with new FIDs when they already exists and > add them when > >> the do not exists. ?The reason, however, we left the > ADD/MODIFY is to > >> make it easier for the MN and HA to catch errors e.g., > cases where the > >> MN things its adding something new but the FID actually already > >> exists. Or the case where the MN thinks its modifying something but > >> the HA has no record of that. > >> Unlike ADD and MODIFY, the REMOVE value is creating more > trouble than > >> it is worth. Given the soft-state nature of the protocol it is > >> important to refresh all FIDs in all BUs, so if an FID is > not included > >> in a BU it MUST be removed. The PRO=REMOVE, then creates > two ways of > >> doing the same thing (remove FID by not including it in BU, or by > >> setting PRO=REMOVE), which is something we wanted to avoid > >> > >> > >> GT>> Again, I think your proposal to drop PRO is not > unreasonable, it > >> is just that RPO field provides an error detection > functions which we > >> think could be useful. > >> > >> > The document has made an in-between choice. ?I'm not > >> suggesing a change, > >> > I'm looking for an explanation. > >> > > >> > >> GT> I hope the above satisfies you? > >> > >> > The other item relates to what in section 4.4 is denoted a > >> "valid BID". > >> > When a BU wants to insert a FID-entry, and this FID-entry > >> refers to one > >> > or more BID-values, all of those BID values must be found in the > >> > BID Entries List, and thus an entry will always achieve the > >> Active state. > >> > However, at later times BID-entries may be removed, and so > >> a state may > >> > change to Inactive. ?What is reason for a state not being allowed > >> > Inactive to start with? ?Again, I'm just looking for an > explanation. > >> > > >> > >> GT> It is not clear why the MN would create an entry that > is inactive > >> to begin with. It seems to me that the entry can always be created > >> when the MN actually needs it. The reason Inactive FIDs > are defined in > >> the draft is to handle the case where BIDs are > subsequently removed. > >> Without the inactive FID concept this would mean an > implicit removal > >> of FIDs pointing to the removed BID. That again could > cause confusion > >> since it would create two ways of removing an FID entries > (remove FID > >> by not including it in BU, or by removing all of the BIDs > associated > >> with it) > >> > >> GT> So, we could allow the MN to add an inactive FID entry, but the > >> added complication does not seem to provide useful flexibility. > >> > >> > A few minor points. > >> > > >> > >> GT> All of your minor points are welcome and will be > corrected in the > >> next version of the draft. > >> > >> > >> > ?* Abstract: uses the word "peer" as a short term for > >> correspondent node, > >> > ? home agent, and mobility anchor point. ?In general, a > >> mobile node's > >> > ? peers are all the nodes with which it has TCP/UDP > >> sessions. ?I think > >> > ? the term "peer" has a too wide interpretation. > >> > > >> > ?* Section 4.1, in the description of BID-PRI field, the > >> words "a higher > >> > ? number" assumes reading the 7-bit field as an unsigned integer. > >> > > >> > ?* Section 4.2, in FID description, 8-bit should be 16-bit. > >> > > >> > ?* Section 4.2, in 1 Forward, a forward reference for > >> Binding Reference > >> > ? sub-option would be helpful when reading this document > first time. > >> > > >> > ?* Section 4.3, in Option Type, I think a copy from the > >> section 4.2.1. > >> > > >> > ?* Section 4.4, para 2, one of the words "change" or > >> "modify" should be > >> > ? enough. > >> > > >> > ?* Section 4.4, Action bullet: "PRO field" to be replaced with > >> > ? "Action field". > >> > > >> > ?* Section 4.4, para just above Ordered Flow Binding > >> Entries, "three flow > >> > ? bindings" to become "four flow bindings". > >> > > >> > Christian > >> > > >> > > >> > > >> > > >> > ? ? ?Find din nye laptop p? kelkoo.dk. Se de gode tilbud > >> her - http://dk.yahoo.com/r/pat/mm > >> > _______________________________________________ > >> > 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 Mon May 4 20:26: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 4DEBD3A69B5 for ; Mon, 4 May 2009 20:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, SARE_LWSHORTT=1.24] 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 kCFzyAL-s9dQ for ; Mon, 4 May 2009 20:26:41 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id DECCA3A67FA for ; Mon, 4 May 2009 20:26:39 -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 1M1BK4-0007Jo-EU; Tue, 05 May 2009 13:28:01 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 05 May 2009 13:27:54 +1000 From: Hesham Soliman To: , 'George Tsirtsis' Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnMk6i94KTeV7lGR3KPWntHJdOk8wAgpdigAAbOdl0= In-Reply-To: <000001c9cd1c$8cb8a7e0$150ca40a@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] flow binding draft 2 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, 05 May 2009 03:26:42 -0000 On 5/05/09 10:58 AM, "Yungui Wang" wrote: > Hello > > I agree with you that "not do the same thing with multiple > ways". However, I don't think new version of this draft is > good designed on the REMOVE operation. You could try > to implement a simple example: > One MN has added 100 flows to HA. Following one > additional flow is dynamically to be added, it has to also > carry the previous 100 flows to HA. => No it doesn't, because it only sends the summary option in addition to the new FID. Hesham > >> -----Original Message----- >> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >> Sent: Monday, May 04, 2009 4:38 PM >> To: w52006@huawei.com >> Cc: Christian Kaas-Petersen; mext@ietf.org >> Subject: Re: [MEXT] flow binding draft 2 >> >> inline >> >> On Mon, May 4, 2009 at 8:12 AM, Yungui Wang wrote: >>> >>> Hello >>> >>> I do think it is necessary to keep the REMOVE operation. In >>> my understanding, the explicit REMOVE operation can avoid >>> that, once a certain flow is added/modified, all the flows have >>> to be updated. In addition, you mentioned implicit REMOVE >>> operation (remove FID by not including it in reg-BU) should be >>> disallowed. >>> >> >> GT> As I already explained in the exchange with Christian, an explicit >> REMOVE operation is indeed possible. It is not, however, preferable >> since it would result in two ways of removing an FID. It is not good >> design practice to have multiple ways of doing the same thing, and in >> this case there is no reason to do so. >> >>> Secondly, from the draft's description and your explanation, >>> I don't find that the Inactive status is similar meaningful. >>> It has to be updated to active state if the inactive flow is >>> enabled to be used. >>> Maybe the only reason why the Inactive status exists is >>> the confusion of Remove operation (two ways) you mentioned. >>> However, I don't think this reason is very good. The general >>> operation of BID deletion could be: when a BID is being >>> deleted, MN and HA both should modify its associated >>> FIDs to refer new BID or delete them. >>> >> >> >> GT> Again, as I already explained the inactive state is there for the >> same reasons i.e., to avoid two ways of doing the same thing. >> >> Regards >> George >> >>> >>> B.R. >>> Yungui >>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>> Behalf Of George Tsirtsis >>>> Sent: Friday, May 01, 2009 8:04 PM >>>> To: Christian Kaas-Petersen >>>> Cc: mext@ietf.org >>>> Subject: Re: [MEXT] flow binding draft 2 >>>> >>>> Hi Christian, >>>> >>>> Wow, very quick turnaround, and a good review, thanks! >>>> >>>> Marcelo, are you counting? :-) >>>> >>>> See comments inline... >>>> >>>> On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen >>>> wrote: >>>>> >>>>> Having read draft-ietf-mext-flow-binding-02, I should like to be >>>>> informed about two design rationales. >>>>> >>>>> The first is related to the PRO field in the Flow >>>> Identification Mobility >>>>> Option. ?The mobile node must explicitly inform if it is >> an Add or a >>>>> Modify operation; the mobile node does implicitly inform >> if it is a >>>>> delete operation. ?In principle there is no need for the >> PRO field. >>>>> There are three cases. >>>>> >>>>> (a) If a FID-value is absent in BU and >>>>> ? ?present in Flow Binding List ? ? ? ?=> remove >>>>> (b) If a FID-value is present in BU and >>>>> ? ?absent in Flow Binding List ? ? ? ? => add >>>>> (c) If a FID-value is present in BU and >>>>> ? ?present in Flow Binding List ? ? ? ?=> modify >>>>> >>>>> With these cases PRO field can be removed. ?Alternatively, >>>> one could take >>>>> the other extreme, also explicitly naming the FID-values to >>>> be removed. >>>>> >>>> >>>> GT> You are right that instead of ADD/MOFIDY we can always >> overwrite >>>> existing FID with new FIDs when they already exists and >> add them when >>>> the do not exists. ?The reason, however, we left the >> ADD/MODIFY is to >>>> make it easier for the MN and HA to catch errors e.g., >> cases where the >>>> MN things its adding something new but the FID actually already >>>> exists. Or the case where the MN thinks its modifying something but >>>> the HA has no record of that. >>>> Unlike ADD and MODIFY, the REMOVE value is creating more >> trouble than >>>> it is worth. Given the soft-state nature of the protocol it is >>>> important to refresh all FIDs in all BUs, so if an FID is >> not included >>>> in a BU it MUST be removed. The PRO=REMOVE, then creates >> two ways of >>>> doing the same thing (remove FID by not including it in BU, or by >>>> setting PRO=REMOVE), which is something we wanted to avoid >>>> >>>> >>>> GT>> Again, I think your proposal to drop PRO is not >> unreasonable, it >>>> is just that RPO field provides an error detection >> functions which we >>>> think could be useful. >>>> >>>>> The document has made an in-between choice. ?I'm not >>>> suggesing a change, >>>>> I'm looking for an explanation. >>>>> >>>> >>>> GT> I hope the above satisfies you? >>>> >>>>> The other item relates to what in section 4.4 is denoted a >>>> "valid BID". >>>>> When a BU wants to insert a FID-entry, and this FID-entry >>>> refers to one >>>>> or more BID-values, all of those BID values must be found in the >>>>> BID Entries List, and thus an entry will always achieve the >>>> Active state. >>>>> However, at later times BID-entries may be removed, and so >>>> a state may >>>>> change to Inactive. ?What is reason for a state not being allowed >>>>> Inactive to start with? ?Again, I'm just looking for an >> explanation. >>>>> >>>> >>>> GT> It is not clear why the MN would create an entry that >> is inactive >>>> to begin with. It seems to me that the entry can always be created >>>> when the MN actually needs it. The reason Inactive FIDs >> are defined in >>>> the draft is to handle the case where BIDs are >> subsequently removed. >>>> Without the inactive FID concept this would mean an >> implicit removal >>>> of FIDs pointing to the removed BID. That again could >> cause confusion >>>> since it would create two ways of removing an FID entries >> (remove FID >>>> by not including it in BU, or by removing all of the BIDs >> associated >>>> with it) >>>> >>>> GT> So, we could allow the MN to add an inactive FID entry, but the >>>> added complication does not seem to provide useful flexibility. >>>> >>>>> A few minor points. >>>>> >>>> >>>> GT> All of your minor points are welcome and will be >> corrected in the >>>> next version of the draft. >>>> >>>> >>>>> ?* Abstract: uses the word "peer" as a short term for >>>> correspondent node, >>>>> ? home agent, and mobility anchor point. ?In general, a >>>> mobile node's >>>>> ? peers are all the nodes with which it has TCP/UDP >>>> sessions. ?I think >>>>> ? the term "peer" has a too wide interpretation. >>>>> >>>>> ?* Section 4.1, in the description of BID-PRI field, the >>>> words "a higher >>>>> ? number" assumes reading the 7-bit field as an unsigned integer. >>>>> >>>>> ?* Section 4.2, in FID description, 8-bit should be 16-bit. >>>>> >>>>> ?* Section 4.2, in 1 Forward, a forward reference for >>>> Binding Reference >>>>> ? sub-option would be helpful when reading this document >> first time. >>>>> >>>>> ?* Section 4.3, in Option Type, I think a copy from the >>>> section 4.2.1. >>>>> >>>>> ?* Section 4.4, para 2, one of the words "change" or >>>> "modify" should be >>>>> ? enough. >>>>> >>>>> ?* Section 4.4, Action bullet: "PRO field" to be replaced with >>>>> ? "Action field". >>>>> >>>>> ?* Section 4.4, para just above Ordered Flow Binding >>>> Entries, "three flow >>>>> ? bindings" to become "four flow bindings". >>>>> >>>>> Christian >>>>> >>>>> >>>>> >>>>> >>>>> ? ? ?Find din nye laptop p? kelkoo.dk. Se de gode tilbud >>>> her - http://dk.yahoo.com/r/pat/mm >>>>> _______________________________________________ >>>>> 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 w52006@huawei.com Mon May 4 21:37: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 4B31A28C10B for ; Mon, 4 May 2009 21:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.374 X-Spam-Level: X-Spam-Status: No, score=0.374 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_36=0.6, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] 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 x8z1jqMyKC10 for ; Mon, 4 May 2009 21:37:23 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 92F173A6CE4 for ; Mon, 4 May 2009 21:37:22 -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 <0KJ500DV3M8CTW@szxga03-in.huawei.com> for mext@ietf.org; Tue, 05 May 2009 12:38:37 +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 <0KJ500FJ1M8C5C@szxga03-in.huawei.com> for mext@ietf.org; Tue, 05 May 2009 12:38:36 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ500DDDM8CHM@szxml04-in.huawei.com> for mext@ietf.org; Tue, 05 May 2009 12:38:36 +0800 (CST) Date: Tue, 05 May 2009 12:38:36 +0800 From: Yungui Wang In-reply-to: To: 'Hesham Soliman' , 'George Tsirtsis' Message-id: <000501c9cd3b$5acae260$150ca40a@china.huawei.com> Organization: huawei 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: AcnMk6i94KTeV7lGR3KPWntHJdOk8wAgpdigAAbOdl0AAbEboA== Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 05 May 2009 04:37:24 -0000 > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Tuesday, May 05, 2009 11:28 AM > To: w52006@huawei.com; 'George Tsirtsis' > Cc: mext@ietf.org > Subject: Re: [MEXT] flow binding draft 2 > > > On 5/05/09 10:58 AM, "Yungui Wang" wrote: > > > Hello > > > > I agree with you that "not do the same thing with multiple > > ways". However, I don't think new version of this draft is > > good designed on the REMOVE operation. You could try > > to implement a simple example: > > One MN has added 100 flows to HA. Following one > > additional flow is dynamically to be added, it has to also > > carry the previous 100 flows to HA. > > => No it doesn't, because it only sends the summary option in > addition to the new FID. The issue is not solved. Just make the wasted size reduced to 100*2bytes. Maybe, a wildcard flag can be defined for all the flows of the MN. Then it could only waste 2 byte to patch the hole. Don't you think that all that new features (FID Summary Mobility Option, Inactive state, FID always presented in re-reg BU, etc) introduced in the new version is mainly to get the implicit REMOVE operation? I don't think it is perfect, personally support your old version with explicit REMOVE operation. B.R. Yungui > > Hesham > > > > > >> -----Original Message----- > >> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > >> Sent: Monday, May 04, 2009 4:38 PM > >> To: w52006@huawei.com > >> Cc: Christian Kaas-Petersen; mext@ietf.org > >> Subject: Re: [MEXT] flow binding draft 2 > >> > >> inline > >> > >> On Mon, May 4, 2009 at 8:12 AM, Yungui Wang > wrote: > >>> > >>> Hello > >>> > >>> I do think it is necessary to keep the REMOVE operation. In > >>> my understanding, the explicit REMOVE operation can avoid > >>> that, once a certain flow is added/modified, all the flows have > >>> to be updated. In addition, you mentioned implicit REMOVE > >>> operation (remove FID by not including it in reg-BU) should be > >>> disallowed. > >>> > >> > >> GT> As I already explained in the exchange with Christian, > an explicit > >> REMOVE operation is indeed possible. It is not, however, preferable > >> since it would result in two ways of removing an FID. It > is not good > >> design practice to have multiple ways of doing the same > thing, and in > >> this case there is no reason to do so. > >> > >>> Secondly, from the draft's description and your explanation, > >>> I don't find that the Inactive status is similar meaningful. > >>> It has to be updated to active state if the inactive flow is > >>> enabled to be used. > >>> Maybe the only reason why the Inactive status exists is > >>> the confusion of Remove operation (two ways) you mentioned. > >>> However, I don't think this reason is very good. The general > >>> operation of BID deletion could be: when a BID is being > >>> deleted, MN and HA both should modify its associated > >>> FIDs to refer new BID or delete them. > >>> > >> > >> > >> GT> Again, as I already explained the inactive state is > there for the > >> same reasons i.e., to avoid two ways of doing the same thing. > >> > >> Regards > >> George > >> > >>> > >>> B.R. > >>> Yungui > >>> > >>>> -----Original Message----- > >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >>>> Behalf Of George Tsirtsis > >>>> Sent: Friday, May 01, 2009 8:04 PM > >>>> To: Christian Kaas-Petersen > >>>> Cc: mext@ietf.org > >>>> Subject: Re: [MEXT] flow binding draft 2 > >>>> > >>>> Hi Christian, > >>>> > >>>> Wow, very quick turnaround, and a good review, thanks! > >>>> > >>>> Marcelo, are you counting? :-) > >>>> > >>>> See comments inline... > >>>> > >>>> On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen > >>>> wrote: > >>>>> > >>>>> Having read draft-ietf-mext-flow-binding-02, I should like to be > >>>>> informed about two design rationales. > >>>>> > >>>>> The first is related to the PRO field in the Flow > >>>> Identification Mobility > >>>>> Option. ?The mobile node must explicitly inform if it is > >> an Add or a > >>>>> Modify operation; the mobile node does implicitly inform > >> if it is a > >>>>> delete operation. ?In principle there is no need for the > >> PRO field. > >>>>> There are three cases. > >>>>> > >>>>> (a) If a FID-value is absent in BU and > >>>>> ? ?present in Flow Binding List ? ? ? ?=> remove > >>>>> (b) If a FID-value is present in BU and > >>>>> ? ?absent in Flow Binding List ? ? ? ? => add > >>>>> (c) If a FID-value is present in BU and > >>>>> ? ?present in Flow Binding List ? ? ? ?=> modify > >>>>> > >>>>> With these cases PRO field can be removed. ?Alternatively, > >>>> one could take > >>>>> the other extreme, also explicitly naming the FID-values to > >>>> be removed. > >>>>> > >>>> > >>>> GT> You are right that instead of ADD/MOFIDY we can always > >> overwrite > >>>> existing FID with new FIDs when they already exists and > >> add them when > >>>> the do not exists. ?The reason, however, we left the > >> ADD/MODIFY is to > >>>> make it easier for the MN and HA to catch errors e.g., > >> cases where the > >>>> MN things its adding something new but the FID actually already > >>>> exists. Or the case where the MN thinks its modifying > something but > >>>> the HA has no record of that. > >>>> Unlike ADD and MODIFY, the REMOVE value is creating more > >> trouble than > >>>> it is worth. Given the soft-state nature of the protocol it is > >>>> important to refresh all FIDs in all BUs, so if an FID is > >> not included > >>>> in a BU it MUST be removed. The PRO=REMOVE, then creates > >> two ways of > >>>> doing the same thing (remove FID by not including it in BU, or by > >>>> setting PRO=REMOVE), which is something we wanted to avoid > >>>> > >>>> > >>>> GT>> Again, I think your proposal to drop PRO is not > >> unreasonable, it > >>>> is just that RPO field provides an error detection > >> functions which we > >>>> think could be useful. > >>>> > >>>>> The document has made an in-between choice. ?I'm not > >>>> suggesing a change, > >>>>> I'm looking for an explanation. > >>>>> > >>>> > >>>> GT> I hope the above satisfies you? > >>>> > >>>>> The other item relates to what in section 4.4 is denoted a > >>>> "valid BID". > >>>>> When a BU wants to insert a FID-entry, and this FID-entry > >>>> refers to one > >>>>> or more BID-values, all of those BID values must be found in the > >>>>> BID Entries List, and thus an entry will always achieve the > >>>> Active state. > >>>>> However, at later times BID-entries may be removed, and so > >>>> a state may > >>>>> change to Inactive. ?What is reason for a state not > being allowed > >>>>> Inactive to start with? ?Again, I'm just looking for an > >> explanation. > >>>>> > >>>> > >>>> GT> It is not clear why the MN would create an entry that > >> is inactive > >>>> to begin with. It seems to me that the entry can always > be created > >>>> when the MN actually needs it. The reason Inactive FIDs > >> are defined in > >>>> the draft is to handle the case where BIDs are > >> subsequently removed. > >>>> Without the inactive FID concept this would mean an > >> implicit removal > >>>> of FIDs pointing to the removed BID. That again could > >> cause confusion > >>>> since it would create two ways of removing an FID entries > >> (remove FID > >>>> by not including it in BU, or by removing all of the BIDs > >> associated > >>>> with it) > >>>> > >>>> GT> So, we could allow the MN to add an inactive FID > entry, but the > >>>> added complication does not seem to provide useful flexibility. > >>>> > >>>>> A few minor points. > >>>>> > >>>> > >>>> GT> All of your minor points are welcome and will be > >> corrected in the > >>>> next version of the draft. > >>>> > >>>> > >>>>> ?* Abstract: uses the word "peer" as a short term for > >>>> correspondent node, > >>>>> ? home agent, and mobility anchor point. ?In general, a > >>>> mobile node's > >>>>> ? peers are all the nodes with which it has TCP/UDP > >>>> sessions. ?I think > >>>>> ? the term "peer" has a too wide interpretation. > >>>>> > >>>>> ?* Section 4.1, in the description of BID-PRI field, the > >>>> words "a higher > >>>>> ? number" assumes reading the 7-bit field as an > unsigned integer. > >>>>> > >>>>> ?* Section 4.2, in FID description, 8-bit should be 16-bit. > >>>>> > >>>>> ?* Section 4.2, in 1 Forward, a forward reference for > >>>> Binding Reference > >>>>> ? sub-option would be helpful when reading this document > >> first time. > >>>>> > >>>>> ?* Section 4.3, in Option Type, I think a copy from the > >>>> section 4.2.1. > >>>>> > >>>>> ?* Section 4.4, para 2, one of the words "change" or > >>>> "modify" should be > >>>>> ? enough. > >>>>> > >>>>> ?* Section 4.4, Action bullet: "PRO field" to be replaced with > >>>>> ? "Action field". > >>>>> > >>>>> ?* Section 4.4, para just above Ordered Flow Binding > >>>> Entries, "three flow > >>>>> ? bindings" to become "four flow bindings". > >>>>> > >>>>> Christian > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ? ? ?Find din nye laptop p? kelkoo.dk. Se de gode tilbud > >>>> her - http://dk.yahoo.com/r/pat/mm > >>>>> _______________________________________________ > >>>>> 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 Mon May 4 21:53: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 DFF233A6BF4 for ; Mon, 4 May 2009 21:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, SARE_LWSHORTT=1.24] 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 N5davzX-hQne for ; Mon, 4 May 2009 21:53:52 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 570D83A695B for ; Mon, 4 May 2009 21:53:51 -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 1M1CgR-00031V-TR; Tue, 05 May 2009 14:55:12 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 05 May 2009 14:55:06 +1000 From: Hesham Soliman To: , 'George Tsirtsis' Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnMk6i94KTeV7lGR3KPWntHJdOk8wAgpdigAAbOdl0AAbEboAABWoac In-Reply-To: <000501c9cd3b$5acae260$150ca40a@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] flow binding draft 2 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, 05 May 2009 04:53:55 -0000 >> => No it doesn't, because it only sends the summary option in >> addition to the new FID. > > The issue is not solved. Just make the wasted size reduced > to 100*2bytes. Maybe, a wildcard flag can be defined for all > the flows of the MN. Then it could only waste 2 byte to patch > the hole. > > Don't you think that all that new features (FID Summary > Mobility Option, Inactive state, FID always presented in > re-reg BU, etc) introduced in the new version is mainly > to get the implicit REMOVE operation? => Not at all. The Summary option was introduced to do two things: 1. Save bytes on refreshes 2. Allow for incremental bindings in cases where not all the bindings can be included in the same message. You're suggesting that we simply only add new bindings in the BU and that there is no need to include FID indices in the BU to refresh them. So how do you refresh bindings? What if the MN rebooted and lost all state and became out of sync with the HA? What happens then? > > I don't think it is perfect, personally support your old version > with explicit REMOVE operation. => The explicit remove is not an issue and can be added but it was never intended to replace the function of the summary option. Hesham > > B.R. > Yungui > > >> >> Hesham >> >> >>> >>>> -----Original Message----- >>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >>>> Sent: Monday, May 04, 2009 4:38 PM >>>> To: w52006@huawei.com >>>> Cc: Christian Kaas-Petersen; mext@ietf.org >>>> Subject: Re: [MEXT] flow binding draft 2 >>>> >>>> inline >>>> >>>> On Mon, May 4, 2009 at 8:12 AM, Yungui Wang >> wrote: >>>>> >>>>> Hello >>>>> >>>>> I do think it is necessary to keep the REMOVE operation. In >>>>> my understanding, the explicit REMOVE operation can avoid >>>>> that, once a certain flow is added/modified, all the flows have >>>>> to be updated. In addition, you mentioned implicit REMOVE >>>>> operation (remove FID by not including it in reg-BU) should be >>>>> disallowed. >>>>> >>>> >>>> GT> As I already explained in the exchange with Christian, >> an explicit >>>> REMOVE operation is indeed possible. It is not, however, preferable >>>> since it would result in two ways of removing an FID. It >> is not good >>>> design practice to have multiple ways of doing the same >> thing, and in >>>> this case there is no reason to do so. >>>> >>>>> Secondly, from the draft's description and your explanation, >>>>> I don't find that the Inactive status is similar meaningful. >>>>> It has to be updated to active state if the inactive flow is >>>>> enabled to be used. >>>>> Maybe the only reason why the Inactive status exists is >>>>> the confusion of Remove operation (two ways) you mentioned. >>>>> However, I don't think this reason is very good. The general >>>>> operation of BID deletion could be: when a BID is being >>>>> deleted, MN and HA both should modify its associated >>>>> FIDs to refer new BID or delete them. >>>>> >>>> >>>> >>>> GT> Again, as I already explained the inactive state is >> there for the >>>> same reasons i.e., to avoid two ways of doing the same thing. >>>> >>>> Regards >>>> George >>>> >>>>> >>>>> B.R. >>>>> Yungui >>>>> >>>>>> -----Original Message----- >>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>>>>> Behalf Of George Tsirtsis >>>>>> Sent: Friday, May 01, 2009 8:04 PM >>>>>> To: Christian Kaas-Petersen >>>>>> Cc: mext@ietf.org >>>>>> Subject: Re: [MEXT] flow binding draft 2 >>>>>> >>>>>> Hi Christian, >>>>>> >>>>>> Wow, very quick turnaround, and a good review, thanks! >>>>>> >>>>>> Marcelo, are you counting? :-) >>>>>> >>>>>> See comments inline... >>>>>> >>>>>> On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen >>>>>> wrote: >>>>>>> >>>>>>> Having read draft-ietf-mext-flow-binding-02, I should like to be >>>>>>> informed about two design rationales. >>>>>>> >>>>>>> The first is related to the PRO field in the Flow >>>>>> Identification Mobility >>>>>>> Option. ?The mobile node must explicitly inform if it is >>>> an Add or a >>>>>>> Modify operation; the mobile node does implicitly inform >>>> if it is a >>>>>>> delete operation. ?In principle there is no need for the >>>> PRO field. >>>>>>> There are three cases. >>>>>>> >>>>>>> (a) If a FID-value is absent in BU and >>>>>>> ? ?present in Flow Binding List ? ? ? ?=> remove >>>>>>> (b) If a FID-value is present in BU and >>>>>>> ? ?absent in Flow Binding List ? ? ? ? => add >>>>>>> (c) If a FID-value is present in BU and >>>>>>> ? ?present in Flow Binding List ? ? ? ?=> modify >>>>>>> >>>>>>> With these cases PRO field can be removed. ?Alternatively, >>>>>> one could take >>>>>>> the other extreme, also explicitly naming the FID-values to >>>>>> be removed. >>>>>>> >>>>>> >>>>>> GT> You are right that instead of ADD/MOFIDY we can always >>>> overwrite >>>>>> existing FID with new FIDs when they already exists and >>>> add them when >>>>>> the do not exists. ?The reason, however, we left the >>>> ADD/MODIFY is to >>>>>> make it easier for the MN and HA to catch errors e.g., >>>> cases where the >>>>>> MN things its adding something new but the FID actually already >>>>>> exists. Or the case where the MN thinks its modifying >> something but >>>>>> the HA has no record of that. >>>>>> Unlike ADD and MODIFY, the REMOVE value is creating more >>>> trouble than >>>>>> it is worth. Given the soft-state nature of the protocol it is >>>>>> important to refresh all FIDs in all BUs, so if an FID is >>>> not included >>>>>> in a BU it MUST be removed. The PRO=REMOVE, then creates >>>> two ways of >>>>>> doing the same thing (remove FID by not including it in BU, or by >>>>>> setting PRO=REMOVE), which is something we wanted to avoid >>>>>> >>>>>> >>>>>> GT>> Again, I think your proposal to drop PRO is not >>>> unreasonable, it >>>>>> is just that RPO field provides an error detection >>>> functions which we >>>>>> think could be useful. >>>>>> >>>>>>> The document has made an in-between choice. ?I'm not >>>>>> suggesing a change, >>>>>>> I'm looking for an explanation. >>>>>>> >>>>>> >>>>>> GT> I hope the above satisfies you? >>>>>> >>>>>>> The other item relates to what in section 4.4 is denoted a >>>>>> "valid BID". >>>>>>> When a BU wants to insert a FID-entry, and this FID-entry >>>>>> refers to one >>>>>>> or more BID-values, all of those BID values must be found in the >>>>>>> BID Entries List, and thus an entry will always achieve the >>>>>> Active state. >>>>>>> However, at later times BID-entries may be removed, and so >>>>>> a state may >>>>>>> change to Inactive. ?What is reason for a state not >> being allowed >>>>>>> Inactive to start with? ?Again, I'm just looking for an >>>> explanation. >>>>>>> >>>>>> >>>>>> GT> It is not clear why the MN would create an entry that >>>> is inactive >>>>>> to begin with. It seems to me that the entry can always >> be created >>>>>> when the MN actually needs it. The reason Inactive FIDs >>>> are defined in >>>>>> the draft is to handle the case where BIDs are >>>> subsequently removed. >>>>>> Without the inactive FID concept this would mean an >>>> implicit removal >>>>>> of FIDs pointing to the removed BID. That again could >>>> cause confusion >>>>>> since it would create two ways of removing an FID entries >>>> (remove FID >>>>>> by not including it in BU, or by removing all of the BIDs >>>> associated >>>>>> with it) >>>>>> >>>>>> GT> So, we could allow the MN to add an inactive FID >> entry, but the >>>>>> added complication does not seem to provide useful flexibility. >>>>>> >>>>>>> A few minor points. >>>>>>> >>>>>> >>>>>> GT> All of your minor points are welcome and will be >>>> corrected in the >>>>>> next version of the draft. >>>>>> >>>>>> >>>>>>> ?* Abstract: uses the word "peer" as a short term for >>>>>> correspondent node, >>>>>>> ? home agent, and mobility anchor point. ?In general, a >>>>>> mobile node's >>>>>>> ? peers are all the nodes with which it has TCP/UDP >>>>>> sessions. ?I think >>>>>>> ? the term "peer" has a too wide interpretation. >>>>>>> >>>>>>> ?* Section 4.1, in the description of BID-PRI field, the >>>>>> words "a higher >>>>>>> ? number" assumes reading the 7-bit field as an >> unsigned integer. >>>>>>> >>>>>>> ?* Section 4.2, in FID description, 8-bit should be 16-bit. >>>>>>> >>>>>>> ?* Section 4.2, in 1 Forward, a forward reference for >>>>>> Binding Reference >>>>>>> ? sub-option would be helpful when reading this document >>>> first time. >>>>>>> >>>>>>> ?* Section 4.3, in Option Type, I think a copy from the >>>>>> section 4.2.1. >>>>>>> >>>>>>> ?* Section 4.4, para 2, one of the words "change" or >>>>>> "modify" should be >>>>>>> ? enough. >>>>>>> >>>>>>> ?* Section 4.4, Action bullet: "PRO field" to be replaced with >>>>>>> ? "Action field". >>>>>>> >>>>>>> ?* Section 4.4, para just above Ordered Flow Binding >>>>>> Entries, "three flow >>>>>>> ? bindings" to become "four flow bindings". >>>>>>> >>>>>>> Christian >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ? ? ?Find din nye laptop p? kelkoo.dk. Se de gode tilbud >>>>>> her - http://dk.yahoo.com/r/pat/mm >>>>>>> _______________________________________________ >>>>>>> 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 w52006@huawei.com Mon May 4 23:17: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 9055A3A68AE for ; Mon, 4 May 2009 23:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, SARE_LWSHORTT=1.24] 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 Ky0m71vxlJCD for ; Mon, 4 May 2009 23:17:34 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 05E153A6820 for ; Mon, 4 May 2009 23:17:34 -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 <0KJ500FZQQVIYB@szxga01-in.huawei.com> for mext@ietf.org; Tue, 05 May 2009 14:18:55 +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 <0KJ5008C4QVI71@szxga01-in.huawei.com> for mext@ietf.org; Tue, 05 May 2009 14:18:54 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ500DPXQVIET@szxml06-in.huawei.com> for mext@ietf.org; Tue, 05 May 2009 14:18:54 +0800 (CST) Date: Tue, 05 May 2009 14:18:54 +0800 From: Yungui Wang In-reply-to: To: 'Hesham Soliman' , 'George Tsirtsis' Message-id: <000c01c9cd49$5dbb9150$150ca40a@china.huawei.com> Organization: huawei 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: AcnMk6i94KTeV7lGR3KPWntHJdOk8wAgpdigAAbOdl0AAbEboAABWoacAAGLLpA= Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 05 May 2009 06:17:35 -0000 Please see inline. B.R. Yungui > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Tuesday, May 05, 2009 12:55 PM > To: w52006@huawei.com; 'George Tsirtsis' > Cc: mext@ietf.org > Subject: Re: [MEXT] flow binding draft 2 > > > >> => No it doesn't, because it only sends the summary option in > >> addition to the new FID. > > > > The issue is not solved. Just make the wasted size reduced > > to 100*2bytes. Maybe, a wildcard flag can be defined for all > > the flows of the MN. Then it could only waste 2 byte to patch > > the hole. > > > > Don't you think that all that new features (FID Summary > > Mobility Option, Inactive state, FID always presented in > > re-reg BU, etc) introduced in the new version is mainly > > to get the implicit REMOVE operation? > > => Not at all. The Summary option was introduced to do two things: > 1. Save bytes on refreshes > 2. Allow for incremental bindings in cases where not all the > bindings can be > included in the same message. > > You're suggesting that we simply only add new bindings in the > BU and that > there is no need to include FID indices in the BU to refresh > them. Yes. Further, if flow is not changed, no FID is included in the re-reg BU. > So how do you refresh bindings? We don't need to refresh flow bindings. Since flow have no lifetime and are binding to CoA(BID), it is not necessary to refresh them. We can just refresh CoA(BID). > What if the MN rebooted and lost all > state and became > out of sync with the HA? Since MN reboots, it will re-register all its bindings and flows. Maybe re-using the 'overwrite' flag in the MCoA could eliminate your worry. > > What happens then? > > > > > > I don't think it is perfect, personally support your old version > > with explicit REMOVE operation. > > => The explicit remove is not an issue and can be added but > it was never > intended to replace the function of the summary option. See above. Summary option is not needed yet. > > Hesham > > > > > B.R. > > Yungui > > > > > >> > >> Hesham > >> > >> > >>> > >>>> -----Original Message----- > >>>> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > >>>> Sent: Monday, May 04, 2009 4:38 PM > >>>> To: w52006@huawei.com > >>>> Cc: Christian Kaas-Petersen; mext@ietf.org > >>>> Subject: Re: [MEXT] flow binding draft 2 > >>>> > >>>> inline > >>>> > >>>> On Mon, May 4, 2009 at 8:12 AM, Yungui Wang > >> wrote: > >>>>> > >>>>> Hello > >>>>> > >>>>> I do think it is necessary to keep the REMOVE operation. In > >>>>> my understanding, the explicit REMOVE operation can avoid > >>>>> that, once a certain flow is added/modified, all the flows have > >>>>> to be updated. In addition, you mentioned implicit REMOVE > >>>>> operation (remove FID by not including it in reg-BU) should be > >>>>> disallowed. > >>>>> > >>>> > >>>> GT> As I already explained in the exchange with Christian, > >> an explicit > >>>> REMOVE operation is indeed possible. It is not, however, > preferable > >>>> since it would result in two ways of removing an FID. It > >> is not good > >>>> design practice to have multiple ways of doing the same > >> thing, and in > >>>> this case there is no reason to do so. > >>>> > >>>>> Secondly, from the draft's description and your explanation, > >>>>> I don't find that the Inactive status is similar meaningful. > >>>>> It has to be updated to active state if the inactive flow is > >>>>> enabled to be used. > >>>>> Maybe the only reason why the Inactive status exists is > >>>>> the confusion of Remove operation (two ways) you mentioned. > >>>>> However, I don't think this reason is very good. The general > >>>>> operation of BID deletion could be: when a BID is being > >>>>> deleted, MN and HA both should modify its associated > >>>>> FIDs to refer new BID or delete them. > >>>>> > >>>> > >>>> > >>>> GT> Again, as I already explained the inactive state is > >> there for the > >>>> same reasons i.e., to avoid two ways of doing the same thing. > >>>> > >>>> Regards > >>>> George > >>>> > >>>>> > >>>>> B.R. > >>>>> Yungui > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >>>>>> Behalf Of George Tsirtsis > >>>>>> Sent: Friday, May 01, 2009 8:04 PM > >>>>>> To: Christian Kaas-Petersen > >>>>>> Cc: mext@ietf.org > >>>>>> Subject: Re: [MEXT] flow binding draft 2 > >>>>>> > >>>>>> Hi Christian, > >>>>>> > >>>>>> Wow, very quick turnaround, and a good review, thanks! > >>>>>> > >>>>>> Marcelo, are you counting? :-) > >>>>>> > >>>>>> See comments inline... > >>>>>> > >>>>>> On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen > >>>>>> wrote: > >>>>>>> > >>>>>>> Having read draft-ietf-mext-flow-binding-02, I should > like to be > >>>>>>> informed about two design rationales. > >>>>>>> > >>>>>>> The first is related to the PRO field in the Flow > >>>>>> Identification Mobility > >>>>>>> Option. ?The mobile node must explicitly inform if it is > >>>> an Add or a > >>>>>>> Modify operation; the mobile node does implicitly inform > >>>> if it is a > >>>>>>> delete operation. ?In principle there is no need for the > >>>> PRO field. > >>>>>>> There are three cases. > >>>>>>> > >>>>>>> (a) If a FID-value is absent in BU and > >>>>>>> ? ?present in Flow Binding List ? ? ? ?=> remove > >>>>>>> (b) If a FID-value is present in BU and > >>>>>>> ? ?absent in Flow Binding List ? ? ? ? => add > >>>>>>> (c) If a FID-value is present in BU and > >>>>>>> ? ?present in Flow Binding List ? ? ? ?=> modify > >>>>>>> > >>>>>>> With these cases PRO field can be removed. ?Alternatively, > >>>>>> one could take > >>>>>>> the other extreme, also explicitly naming the FID-values to > >>>>>> be removed. > >>>>>>> > >>>>>> > >>>>>> GT> You are right that instead of ADD/MOFIDY we can always > >>>> overwrite > >>>>>> existing FID with new FIDs when they already exists and > >>>> add them when > >>>>>> the do not exists. ?The reason, however, we left the > >>>> ADD/MODIFY is to > >>>>>> make it easier for the MN and HA to catch errors e.g., > >>>> cases where the > >>>>>> MN things its adding something new but the FID actually already > >>>>>> exists. Or the case where the MN thinks its modifying > >> something but > >>>>>> the HA has no record of that. > >>>>>> Unlike ADD and MODIFY, the REMOVE value is creating more > >>>> trouble than > >>>>>> it is worth. Given the soft-state nature of the protocol it is > >>>>>> important to refresh all FIDs in all BUs, so if an FID is > >>>> not included > >>>>>> in a BU it MUST be removed. The PRO=REMOVE, then creates > >>>> two ways of > >>>>>> doing the same thing (remove FID by not including it > in BU, or by > >>>>>> setting PRO=REMOVE), which is something we wanted to avoid > >>>>>> > >>>>>> > >>>>>> GT>> Again, I think your proposal to drop PRO is not > >>>> unreasonable, it > >>>>>> is just that RPO field provides an error detection > >>>> functions which we > >>>>>> think could be useful. > >>>>>> > >>>>>>> The document has made an in-between choice. ?I'm not > >>>>>> suggesing a change, > >>>>>>> I'm looking for an explanation. > >>>>>>> > >>>>>> > >>>>>> GT> I hope the above satisfies you? > >>>>>> > >>>>>>> The other item relates to what in section 4.4 is denoted a > >>>>>> "valid BID". > >>>>>>> When a BU wants to insert a FID-entry, and this FID-entry > >>>>>> refers to one > >>>>>>> or more BID-values, all of those BID values must be > found in the > >>>>>>> BID Entries List, and thus an entry will always achieve the > >>>>>> Active state. > >>>>>>> However, at later times BID-entries may be removed, and so > >>>>>> a state may > >>>>>>> change to Inactive. ?What is reason for a state not > >> being allowed > >>>>>>> Inactive to start with? ?Again, I'm just looking for an > >>>> explanation. > >>>>>>> > >>>>>> > >>>>>> GT> It is not clear why the MN would create an entry that > >>>> is inactive > >>>>>> to begin with. It seems to me that the entry can always > >> be created > >>>>>> when the MN actually needs it. The reason Inactive FIDs > >>>> are defined in > >>>>>> the draft is to handle the case where BIDs are > >>>> subsequently removed. > >>>>>> Without the inactive FID concept this would mean an > >>>> implicit removal > >>>>>> of FIDs pointing to the removed BID. That again could > >>>> cause confusion > >>>>>> since it would create two ways of removing an FID entries > >>>> (remove FID > >>>>>> by not including it in BU, or by removing all of the BIDs > >>>> associated > >>>>>> with it) > >>>>>> > >>>>>> GT> So, we could allow the MN to add an inactive FID > >> entry, but the > >>>>>> added complication does not seem to provide useful flexibility. > >>>>>> > >>>>>>> A few minor points. > >>>>>>> > >>>>>> > >>>>>> GT> All of your minor points are welcome and will be > >>>> corrected in the > >>>>>> next version of the draft. > >>>>>> > >>>>>> > >>>>>>> ?* Abstract: uses the word "peer" as a short term for > >>>>>> correspondent node, > >>>>>>> ? home agent, and mobility anchor point. ?In general, a > >>>>>> mobile node's > >>>>>>> ? peers are all the nodes with which it has TCP/UDP > >>>>>> sessions. ?I think > >>>>>>> ? the term "peer" has a too wide interpretation. > >>>>>>> > >>>>>>> ?* Section 4.1, in the description of BID-PRI field, the > >>>>>> words "a higher > >>>>>>> ? number" assumes reading the 7-bit field as an > >> unsigned integer. > >>>>>>> > >>>>>>> ?* Section 4.2, in FID description, 8-bit should be 16-bit. > >>>>>>> > >>>>>>> ?* Section 4.2, in 1 Forward, a forward reference for > >>>>>> Binding Reference > >>>>>>> ? sub-option would be helpful when reading this document > >>>> first time. > >>>>>>> > >>>>>>> ?* Section 4.3, in Option Type, I think a copy from the > >>>>>> section 4.2.1. > >>>>>>> > >>>>>>> ?* Section 4.4, para 2, one of the words "change" or > >>>>>> "modify" should be > >>>>>>> ? enough. > >>>>>>> > >>>>>>> ?* Section 4.4, Action bullet: "PRO field" to be replaced with > >>>>>>> ? "Action field". > >>>>>>> > >>>>>>> ?* Section 4.4, para just above Ordered Flow Binding > >>>>>> Entries, "three flow > >>>>>>> ? bindings" to become "four flow bindings". > >>>>>>> > >>>>>>> Christian > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ? ? ?Find din nye laptop p? kelkoo.dk. Se de gode tilbud > >>>>>> her - http://dk.yahoo.com/r/pat/mm > >>>>>>> _______________________________________________ > >>>>>>> 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 Mon May 4 23:22: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 119EA3A68D9 for ; Mon, 4 May 2009 23:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 KNowR3EA-kI9 for ; Mon, 4 May 2009 23:22:17 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 3CEBE3A6820 for ; Mon, 4 May 2009 23:22:16 -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 1M1E42-00005H-Dt; Tue, 05 May 2009 16:23:38 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 05 May 2009 16:23:33 +1000 From: Hesham Soliman To: , 'George Tsirtsis' Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnMk6i94KTeV7lGR3KPWntHJdOk8wAgpdigAAbOdl0AAbEboAABWoacAAGLLpAAAYugag== In-Reply-To: <000c01c9cd49$5dbb9150$150ca40a@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] flow binding draft 2 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, 05 May 2009 06:22:18 -0000 > >> So how do you refresh bindings? > > We don't need to refresh flow bindings. Since flow have no > lifetime and are binding to CoA(BID), it is not > necessary to refresh them. We can just refresh CoA(BID). => Of course they have a lifetime, it's the lifetime of the BU. > >> What if the MN rebooted and lost all >> state and became >> out of sync with the HA? > > Since MN reboots, it will re-register all its bindings and flows. => How?? Are you saying the MN somehow remembers what flows it had before reboot? Even if it did, if a connection no longer exists it won't need a binding. Makes no sense to me. Hesham From kaaspetersen@yahoo.dk Tue May 5 00:05: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 6EF8828C143 for ; Tue, 5 May 2009 00:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 f2AltB1qQDVj for ; Tue, 5 May 2009 00:05:04 -0700 (PDT) Received: from web27805.mail.ukl.yahoo.com (web27805.mail.ukl.yahoo.com [217.146.182.10]) by core3.amsl.com (Postfix) with SMTP id 357CB3A6A70 for ; Tue, 5 May 2009 00:05:04 -0700 (PDT) Received: (qmail 28185 invoked by uid 60001); 5 May 2009 07:06:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1241507188; bh=SEJNJ0FfX2DYTwAfzgU8InOb9HEGBz0MT39sQn17sfc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JAXPlPL1XFn9i0kxLkykvxfpKazppEYSM9WUEFum6O6fgViwSI59EX3Ahyq5gNurl+9hnYAYi+T8wuXarPymovVoU6ziJWuRzv1bpH0ovnkjHPMloIe4OdFPZb5K3p9vpjRizK7oMNhT9gIyqcgP8GiRdktBQav6eN1qaMwYgwg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=M+KdtxuO/Yml71BxZrnPESVrtz5vIi8GD0jvHMWnjZlSQPkdA4NIDA7s/7KUznhbvj4t/6kQjmf0yInSzuZWlAUfBYiMi0LY1Y5B5j0qpB/jgQDq+GwEEG95x+wu8PipR0LZTJaZDVGcVwaciMFCTvUue852DF/+CGNTbR9ggN0=; Message-ID: <29423.26281.qm@web27805.mail.ukl.yahoo.com> X-YMail-OSG: Vwk3xycVM1nXvJNy92HBXQOAJ0X_C1ukL7zCQE9pMwk8zBkPC5Ytoj5kIwvP3fR77upFpuIrePnqzciD7zb3ibW51V6HhlX.7JZ0_HDHJC_wGwD4ZlH2OEVdiu9JJwxL.9imcE14IpAIzvi9Tc8q173NZmsZ0UX.E4jXXvgj.XPjK_b4ZP.5RgXCfALDSC_aUdkIBzg8ybGTVc0qxr0s0egMjWuVE_Ak5m_k1B1XxCh2SLcewBXzbfDtbVnKuD.5XirPxdqq9BK63i.ho3lczzH3M_FKxu71YNvCK8vISCBV8_ND9MNz1fIQxAuqy0Qd0rLdZ14Xll_sbSyurbQBaUcGQbHEMYE62zzD83aufA-- Received: from [193.15.240.60] by web27805.mail.ukl.yahoo.com via HTTP; Tue, 05 May 2009 07:06:27 GMT X-Mailer: YahooMailClassic/5.2.20 YahooMailWebService/0.7.289.1 Date: Tue, 5 May 2009 07:06:27 +0000 (GMT) From: Christian Kaas-Petersen To: w52006@huawei.com, 'George Tsirtsis' , Hesham Soliman MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 05 May 2009 07:05:10 -0000 An example. Assume the mobile node has made the registrations shown in the two tables in the draft (in the Ordered Flow Binding Entries on page 15 and in the Ordered BID Entries on page 16). Now the mobile node returns home in the sense of RFC3775. The mobile node can send a binding update with lifetime zero and include a Flow Identification Summary Mobility Option with all the FIDs included. How is this interpreted by the home agent? As a deletion of all entries? Or rather as a deletion of all BID entries but keeping all Flow Binding Entries (which will now be in state Inactive)? I think the intention is all is removed, but please point to the text in the draft making this clear. Christian --- Den tirs 5/5/09 skrev Hesham Soliman : > Fra: Hesham Soliman > Emne: Re: [MEXT] flow binding draft 2 > Til: w52006@huawei.com, "'George Tsirtsis'" > Cc: mext@ietf.org > Dato: tirsdag 5. maj 2009 08.23 >=20 > >=20 > >> So how do you refresh bindings? > >=20 > > We don't need to refresh flow bindings. Since flow > have no > > lifetime and are binding to CoA(BID), it is not > > necessary to refresh them. We can just refresh > CoA(BID). >=20 > =3D> Of course they have a lifetime, it's the lifetime of > the BU. > >=20 > >> What if the MN rebooted and lost all > >> state and became > >> out of sync with the HA? > >=20 > > Since MN reboots, it will re-register all its bindings > and flows. >=20 > =3D> How?? Are you saying the MN somehow remembers what > flows it had before > reboot? Even if it did, if a connection no longer exists it > won't need a > binding. Makes no sense to me. >=20 > Hesham >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > =0A=0A=0A ________________________________________________________ = =0AAudi, Fiat, Peugeot, Skoda, Porsche, Toyota, Ford - Kelkoo har brugte bi= ler til en hver smag! Klik her for at sammenligne priser.(http://dk.yahoo.c= om/r/pat/mmb) From hesham@elevatemobile.com Tue May 5 01:07: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 BDED23A6BDA for ; Tue, 5 May 2009 01:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 tiCZ36mC3lmq for ; Tue, 5 May 2009 01:07:37 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 8DF843A6E05 for ; Tue, 5 May 2009 01:07:36 -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 1M1Fhv-00041g-I9; Tue, 05 May 2009 18:08:56 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 05 May 2009 18:08:47 +1000 From: Hesham Soliman To: Christian Kaas-Petersen , , 'George Tsirtsis' Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnNWLchgwLeGt9SHEShpfvIpykdrA== In-Reply-To: <29423.26281.qm@web27805.mail.ukl.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 05 May 2009 08:07:38 -0000 On 5/05/09 5:06 PM, "Christian Kaas-Petersen" wrote: > > An example. Assume the mobile node has made the registrations shown > in the two tables in the draft (in the Ordered Flow Binding Entries > on page 15 and in the Ordered BID Entries on page 16). Now the mobile > node returns home in the sense of RFC3775. The mobile node can > send a binding update with lifetime zero and include a Flow > Identification Summary Mobility Option with all the FIDs included. > How is this interpreted by the home agent? As a deletion of > all entries? => It's a deletion of all entries. A dregistration BU removes all bindings and this includes FIDs. Any inactive FIDs are removed with the last binding, just like any other MIP state. Or rather as a deletion of all BID entries but keeping > all Flow Binding Entries (which will now be in state Inactive)? => No, inactive FIDs are not stored permanently, they're only there while a binding exists. > I think the intention is all is removed, but please point to the > text in the draft making this clear. Hesham > > Christian > > > --- Den tirs 5/5/09 skrev Hesham Soliman : > >> Fra: Hesham Soliman >> Emne: Re: [MEXT] flow binding draft 2 >> Til: w52006@huawei.com, "'George Tsirtsis'" >> Cc: mext@ietf.org >> Dato: tirsdag 5. maj 2009 08.23 >> >>> >>>> So how do you refresh bindings? >>> >>> We don't need to refresh flow bindings. Since flow >> have no >>> lifetime and are binding to CoA(BID), it is not >>> necessary to refresh them. We can just refresh >> CoA(BID). >> >> => Of course they have a lifetime, it's the lifetime of >> the BU. >>> >>>> What if the MN rebooted and lost all >>>> state and became >>>> out of sync with the HA? >>> >>> Since MN reboots, it will re-register all its bindings >> and flows. >> >> => How?? Are you saying the MN somehow remembers what >> flows it had before >> reboot? Even if it did, if a connection no longer exists it >> won't need a >> binding. Makes no sense to me. >> >> Hesham >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > ________________________________________________________ > Audi, Fiat, Peugeot, Skoda, Porsche, Toyota, Ford - Kelkoo har brugte biler > til en hver smag! Klik her for at sammenligne > priser.(http://dk.yahoo.com/r/pat/mmb) From arno@natisbad.org Tue May 5 01:14: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 270543A6C34 for ; Tue, 5 May 2009 01:14:28 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 v7o-UthIN+ZX for ; Tue, 5 May 2009 01:14:27 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id AA9BA3A68A8 for ; Tue, 5 May 2009 01:14:26 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M1Foa-0006JG-Mg; Tue, 05 May 2009 10:15:48 +0200 X-Hashcash: 1:20:090505:thierry.ernst@inria.fr::KtNSa4EdERqCX+4X:0000000000000000000000000000000000000008ICf X-Hashcash: 1:20:090505:ryuji.wakikawa@gmail.com::RHb1+6bukivMWQP1:00000000000000000000000000000000000001mUf From: arno@natisbad.org (Arnaud Ebalard) To: Thierry Ernst , Ryuji Wakikawa References: <49EF37D8.2010408@it.uc3m.es> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090505:jari.arkko@piuha.net::LOUzQUm8wPOfv7xN:000000000000000000000000000000000000000001zuq X-Hashcash: 1:20:090505:mext@ietf.org::z04rP3iSLMsE9Upj:00001fBD X-Hashcash: 1:20:090505:marcelo@it.uc3m.es::QkH2F5sCmuPhwM9Y:00000000000000000000000000000000000000000003g5P Date: Tue, 05 May 2009 10:16:36 +0200 Message-ID: <87y6tcx8uz.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jari Arkko , mext Subject: Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-monami6-multihoming-motivation-scenario-03 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, 05 May 2009 08:14:28 -0000 Hi Thierry and Ryuji, Below is a review of draft-ietf-monami6-multihoming-motivation-scenario-03. In the end, these are mostly typos and a few questions / minor changes. As a general comment, the document is easy to read. The numerous high-level scenarios in section 3 provides good examples for the needs and aspects of end-node multihoming, which are then clarified/explained in section 4. Section 6 provides a sufficient overview of the possible issues. IMMO, the doc is ready for WGLC. > 1. Introduction > > New equipments shipped on the market now often integrate several > access technologies (both wired and wireless). The main purpose of > this integration is to federate all means of communications in order > to access the Internet ubiquitously (from everywhere and at any time) > as no single technology can be expected to be deployed everywhere. > Flows may thus be redirected from one interface to the other > following the loss of connectivity or change of the network > conditions in different access mediums. Besides enabling ubiquitous > Interent access, integrating several access technologies also allows s/Interent/Internet/ > increased bandwidth availability and selection of the the most s/the the/the/ > appropriate technology according to the type of flow or choices of > the user, since each access medium has different cost, performance, > bandwidth, access range, and reliability. > > Once multiple accesses are offered, users may want to select the most > appropriate set of network interface(s) depending on the network > environment, particularly in wireless networks which are mutable and > less reliable than wired networks. Users may also want to select the > most appropriate interface per communication type or to combine a set > of interfaces to get sufficient bandwidth. > The purpose of this document is to emphasize the goals and benefits > of multihoming for fixed and mobile hosts and routers in a generic > fashion, i.e. without focusing on issues pertaining to hosts, or > routers, or mobility. There are other documents focusing on these. > issues pertaining to site multihoming in fixed networks are discussed > in [1]. Mobility issues pertaining to mobile nodes and mobile s/Mobility issues/Multihoming issues/ ? > 3.3. Need to Set Up Preferences > > Nami works at home for a publishing company using her connection to > the Internet via a low-speed dial up connection, a public and > unrealiable 802.11b WLAN from the street and her 3G cellular phone. > Since the public WLAN is not secure, and the dial-up connection too > slow, Nami checks her company's email using her 3G phone even though > it is expensive. The WLAN service is used for non-confidential > activities, such as web-browsing and video-conferencing, and the > dial-up connection is moslty used to transmit her completed work s/moslty/mostly/ > securely and synchronizing her file system. s/synchronizing/synchronize/ ? > 5. Analysis > > From the definition of a multihomed node it follows that a multihomed > node has several IPv6 addresses to choose between. In order to > expose the goals and benefits in managing multihomed nodes, we > propose to distinguish two main cases: either the node has only one > interface, or the node has several interfaces. In the former case, > the node is multihomed when multilpe prefixes are advertised on the s/multilpe/multiple/ > link the node is attached to. This distinction is important and > sometimes subtle but the implications are important. > > 5.1. Case 1: One Interface, Multiple Prefixes > > The single-interfaced node is multihomed when several prefixes are > advertised on its interface. The node must therefore configure > several IPv6 addresses. > > A typical example is a node with a 802.11b interface, connected to an > access point. The access point is connected trough an Ethernet link > to two access routers. Each access router is configured to advertise > distinct network prefixes by Router Advertisements on the link and > can be used as default router. Several reasons may lead to configure > two access routers on the same link: for instance, the access points > may be shared between different ISPs, or two access routers may be > used for redundancy or load sharing purposes. The node will then > build two global IPv6 addresses on its interface. > > We now analyse which of the goals detailed in Section 4 can be met > with this configuration. > > o Ubiquitous Access: NO > > Ubiquitous access cannot be guaranteed when the node loses > Internet connectivity through its sole interface (e.g. the node is > going outside the coverage area of its access point). > > o Flow redirection: YES > > The node might need to redirect a flow from one address to another > for several reasons. For example, if one of the IPv6 prefix > becomes unavailable, flows using the address from this prefix > could be redirected to the address obtained on the other prefix. > > o Reliability: MAYBE > > In case of failure of one IPv6 prefix, one of the address of the > node will not be valid anymore. Another available address built > from other prefixes may allow the node to recover this sort of > failure. Bi-casting can be performed to ensure the delivery of > packets on the node. To do so, more than one IPv6 address must be > used simultaneously for one flow. Bi-casting would allow the node > to seamlessly change the address used on the node. > > o Load sharing: YES > > Load Sharing can be performed in the network, according to the > address used by the node. The choice of the address used by the > node and the router selection can be influenced by load sharing > rules. This mostly benefits the network side: if different access > routers or routes can be used to forward the node's traffic, the > traffic load will be shared in the network. > > o Load balancing/Flow Distribution: NO > > Load balancing cannot be performed when the node has only one > interface. Well, strictly speaking (considering load balancing requires different interfaces), the NO is valid. But considering the YES for "load sharing" above and "Preferences" and "Aggregated Bandwidth" below, what prevents load balancing/flow distribution between the addresses, if for some reason it is known that they have different characteristics, let say for instance that they are associated w/ different routers/internet lines or different kinds of addresses (native vs 6to4) ? Note that it is just a general comment, I won't argue to change the NO to sth else.. > 6.1. Address Selection > > The multihomed node has several addresses, which implies the > appropriate address must be chosen when an IPv6 communication is > established (e.g. when a TCP connection is opened). An address > selection mechanism is therefore needed. > > The choice of the address can be influenced by many parameters: user > preferences, ingress filtering, preference flag in Router > Advertisement, destination prefix, type of interface, link > characteristics, etc. would add: type of address (e.g. HoA vs common address) Cheers, a+ From tsirtsis@googlemail.com Tue May 5 01:17: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 9E9FF3A6CFD for ; Tue, 5 May 2009 01:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.151, 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 U8Xf77mc1a46 for ; Tue, 5 May 2009 01:17:55 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 4F73C3A7113 for ; Tue, 5 May 2009 01:17:52 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so2964658rvb.49 for ; Tue, 05 May 2009 01:19:16 -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=w6KCsGVUUNnOuBLAhXmPC1z9LXgNLmFRhBssglKVAIU=; b=viehm4G+bKwSWMLrl7frxHw2eVy5okRyCsnjU1roBqlrelYYiGu+1PuI98BBo0+ahk EIB8Z0QD9F4GRsis7iuR2uCAkPZUsuD0c0w59n8cTFCLFuGbI8utCcmUKASuWmgnCJjo fTnCuKeA8t3IwEE7g1NtbBrVomEmjAFuTT0NE= 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=DHwXAzzMvps0Y4XLXalTrbifgrHbDLpH2seRcosl6Hmrgg6ytTyNK7CAuiZUaDz/Oo 3DIH4bbxQE+MM4VHV4XQ9lJ0aJtDGbdi6yZbi1ZdD8olYojC3wMaz6DSjWuBoXS5f3My YmE7L9Ni5hfupzGmlJ76hJFsahAS1DXeggZxY= MIME-Version: 1.0 Received: by 10.142.187.19 with SMTP id k19mr2476907wff.271.1241511554572; Tue, 05 May 2009 01:19:14 -0700 (PDT) In-Reply-To: References: <29423.26281.qm@web27805.mail.ukl.yahoo.com> Date: Tue, 5 May 2009 09:19:14 +0100 Message-ID: From: George Tsirtsis To: Hesham Soliman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 05 May 2009 08:17:56 -0000 Right, I agree. I think it is a good property to keep across MIP specs i.e., BU with Lifetime=3D0 removes everything, no matter what else is going on. In any case, I think it is worth adding a comment about this in the Flow Bindings draft just to make it very clear for this draft. Thanks George On Tue, May 5, 2009 at 9:08 AM, Hesham Soliman w= rote: > > > > On 5/05/09 5:06 PM, "Christian Kaas-Petersen" wro= te: > >> >> An example. =C2=A0Assume the mobile node has made the registrations show= n >> in the two tables in the draft (in the Ordered Flow Binding Entries >> on page 15 and in the Ordered BID Entries on page 16). =C2=A0Now the mob= ile >> node returns home in the sense of RFC3775. =C2=A0The mobile node can >> send a binding update with lifetime zero and include a Flow >> Identification Summary Mobility Option with all the FIDs included. >> How is this interpreted by the home agent? =C2=A0As a deletion of >> all entries? > > =3D> It's a deletion of all entries. A dregistration BU removes all bindi= ngs > and this includes FIDs. Any inactive FIDs are removed with the last bindi= ng, > just like any other MIP state. > > Or rather as a deletion of all BID entries but keeping >> all Flow Binding Entries (which will now be in state Inactive)? > > =3D> No, inactive FIDs are not stored permanently, they're only there whi= le a > binding exists. > >> I think the intention is all is removed, but please point to the >> text in the draft making this clear. > > Hesham > >> >> Christian >> >> >> --- Den tirs 5/5/09 skrev Hesham Soliman : >> >>> Fra: Hesham Soliman >>> Emne: Re: [MEXT] flow binding draft 2 >>> Til: w52006@huawei.com, "'George Tsirtsis'" >>> Cc: mext@ietf.org >>> Dato: tirsdag 5. maj 2009 08.23 >>> >>>> >>>>> So how do you refresh bindings? >>>> >>>> We don't need to refresh flow bindings. Since flow >>> have no >>>> lifetime and are binding to CoA(BID), it is not >>>> necessary to refresh them. We can just refresh >>> CoA(BID). >>> >>> =3D> Of course they have a lifetime, it's the lifetime of >>> the BU. >>>> >>>>> What if the MN rebooted and lost all >>>>> state and became >>>>> out of sync with the HA? >>>> >>>> Since MN reboots, it will re-register all its bindings >>> and flows. >>> >>> =3D> How?? Are you saying the MN somehow remembers what >>> flows it had before >>> reboot? Even if it did, if a connection no longer exists it >>> won't need a >>> binding. Makes no sense to me. >>> >>> Hesham >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> =C2=A0 =C2=A0 =C2=A0 ___________________________________________________= _____ >> Audi, Fiat, Peugeot, Skoda, Porsche, Toyota, Ford - Kelkoo har brugte bi= ler >> til en hver smag! Klik her for at sammenligne >> priser.(http://dk.yahoo.com/r/pat/mmb) > > > From tsirtsis@googlemail.com Tue May 5 01:27:49 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 19C9C3A687B for ; Tue, 5 May 2009 01:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.148, 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 DaaAl4kKAT9y for ; Tue, 5 May 2009 01:27:48 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 19C0028C0E0 for ; Tue, 5 May 2009 01:27:48 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so2968075rvb.49 for ; Tue, 05 May 2009 01:29:13 -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=4kis74MNtarQeqKslM+kig5ZagTyKW7XQsPjKw6UeFg=; b=KgrlKLBHkrWYaImOQIdmV7XNBRxVrYZyja0qvxZctD4mgedp+YIYe4paq5LpcDX8cy CzWvdDDpUbju4Ky2Rj0SW2YUmRpYHvAUYa9z835ChFWE6AsFzncheFAglgZXaMv/K7Ax QGBi8PiZdHSuyu3wUm8PlWB+KbPNkpMSstYSU= 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=CDz6F2mIJvp35IL2feuaNxQP79rCPxCTKZTESLVBeP/keUPlhIyqSrgD9B6Aqb0XEO 5Gy5QV6LWd+238UDEq6K/GNubQwVsQ3zwz4ZxMnziBzKOkiGVjLuIaeyGTEziSpKW0WB auqD/ZjNwIaoqLw8wyHRUsRZ7cXiyhDL3bVCY= MIME-Version: 1.0 Received: by 10.142.158.3 with SMTP id g3mr2486701wfe.29.1241512153144; Tue, 05 May 2009 01:29:13 -0700 (PDT) In-Reply-To: <860528.4365.qm@web27808.mail.ukl.yahoo.com> References: <860528.4365.qm@web27808.mail.ukl.yahoo.com> Date: Tue, 5 May 2009 09:29:13 +0100 Message-ID: From: George Tsirtsis To: Christian Kaas-Petersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] binary filters draft 0 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, 05 May 2009 08:27:49 -0000 Hi Christian, thanks for the review and for catching these. See comments inline. On Mon, May 4, 2009 at 11:13 AM, Christian Kaas-Petersen wrote: > > A few comments. > > =C2=A0* Flow description and flow descriptor seem to be used interchangea= bly. > =C2=A0 I should like to use flow description for what is presented in the > =C2=A0 draft, and flow descriptor as an index into a table (just like UNI= X > =C2=A0 file descriptor is an index). =C2=A0In MEXT setting there is no ne= ed for > =C2=A0 flow descriptor, as the term flow identifier is used. > GT> OK, makes sense. > =C2=A0* Figure 1 and Figure 3: I count 4 bits for the NxPs field, althoug= h > =C2=A0 the text says they are 3-bit fields. > GT> yes thanks. > =C2=A0* Section 3.1. =C2=A0Hasn't TOS gone out of use, so that DSCP shoul= d be > =C2=A0 used instead? > GT> Yes, you are probably right. Will correct. > =C2=A0* Section 3.1. =C2=A0Address ranges are specified by a single addre= ss and > =C2=A0 a prefix, whereas port ranges are specified from low to high. > =C2=A0 I guess the motivation for this, is that addresses will most often= be > =C2=A0 a single address (MIP) or a prefix (NEMO). =C2=A0I like to have su= ch design > =C2=A0 rationales mentioned in the document. =C2=A0The traffic selectors = of IPsec > =C2=A0 prefer address ranges from low to high value, and this document co= uld > =C2=A0 have followed what IPsec is doing. > GT> The reason for the difference is simply packing efficiency. If we do IP address range with a from/to, we will end up with 2x32 or 2x128 as opposed to 32+1 or 128+1 which is how it is now. For port numbers from/to did not seem that bad since they are only 2bytes each. Does that make sense? > =C2=A0* Section 3.1. =C2=A0In Source Port - High, why not stay firm: If o= nly one port > =C2=A0 is of interest, Source Port - High must be absent. =C2=A0Somewhere= , > =C2=A0 probably in flow binding draft, there will be an error code for > =C2=A0 a malformed flow description. > GT> Good suggestions, thanks. I will do what you say with the ports and I will define a new FID status code in this draft. > Christian > > > > > =C2=A0 =C2=A0 =C2=A0Find din nye laptop p=C3=A5 kelkoo.dk. Se de gode til= bud her - http://dk.yahoo.com/r/pat/mm > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From tsirtsis@googlemail.com Tue May 5 03:17: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 3CA3B3A69A8 for ; Tue, 5 May 2009 03:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.145, 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 Q885QkTN4ZFq for ; Tue, 5 May 2009 03:17:18 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id C58433A682A for ; Tue, 5 May 2009 03:17:17 -0700 (PDT) Received: by fxm2 with SMTP id 2so4465755fxm.37 for ; Tue, 05 May 2009 03:18:41 -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=KS7seo2hid5ud4IhWnGq84xLMwQk4Qz8YADSKtIDzo4=; b=fDmAPzBc6SoGiGPgKVzcnCG54lt/yZsNgTzsxyzl4CG2KIcz22aceBi3C6FgSPKY+5 7PbPZcl1quPGnqBg81wEKzzxFsuLhW/ff10PNE0/RtXMsYytoH2KAY8QtvCyf7HH6r86 RXoxxm+NW+qsxoJgviC4Q1JFM9Bb0nKKAzpng= 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=WA/5h2okkcIPDixxJ+ZDkX732Pz7JPZgFatr8K9KA1YmOPP/ALBN+YRudr4rHL+tsM ORieL41GPyR8RPv+V6GkJpbCYcz/Chq/AUotmGoPEqV200GJ3241x4pbmaiogOmDijZW Qlbgrg1QMouqWfRwlxhaYbyZYzMkMst93G/fQ= MIME-Version: 1.0 Received: by 10.223.117.1 with SMTP id o1mr2959117faq.53.1241518721121; Tue, 05 May 2009 03:18:41 -0700 (PDT) In-Reply-To: References: <860528.4365.qm@web27808.mail.ukl.yahoo.com> Date: Tue, 5 May 2009 11:18:41 +0100 Message-ID: From: George Tsirtsis To: Christian Kaas-Petersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] binary filters draft 0 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, 05 May 2009 10:17:19 -0000 Christian, et.al., As I was implementing the changes discussed earlier, the following issue came up. One of your comments is about renaming the TOS field to DSCP. First of all I noticed we used the term Class of Service (CS) in the IPv6 header which is not correct...instead it is Traffic Class. Looking into this a bit more, however, I remembered that the IPv4 TOS byte as well as the IPv6 TC byte were redefined as 6bit DSfield and 2 bit Currently Unused (CU) fields. One of the CU bits was then used by ECN (see RFC3260 for all this). Since I do not anticipate anyone to be matching the ECN bit for the purpose of Flow Bindings, I suggest we redefine the 8-bit TOS field as an 8bit DSfield, the last 2 bits of which MUST be set to 0 by sender and ignored by the receiver. This way a given DSCP can be matched without getting confused by the ECN bit. If someone really wants to match the ECN bit, (who knows why) of course they still can, by using the offset based pointers defined in the draft. Note that I do not want to make this a 6bit field because that would break byte alignment for the sub-option, when this field is present.. Does this make sense? George On Tue, May 5, 2009 at 9:29 AM, George Tsirtsis w= rote: > Hi Christian, > > thanks for the review and for catching these. See =C2=A0comments inline. > > On Mon, May 4, 2009 at 11:13 AM, Christian Kaas-Petersen > wrote: >> >> A few comments. >> >> =C2=A0* Flow description and flow descriptor seem to be used interchange= ably. >> =C2=A0 I should like to use flow description for what is presented in th= e >> =C2=A0 draft, and flow descriptor as an index into a table (just like UN= IX >> =C2=A0 file descriptor is an index). =C2=A0In MEXT setting there is no n= eed for >> =C2=A0 flow descriptor, as the term flow identifier is used. >> > > GT> OK, makes sense. > >> =C2=A0* Figure 1 and Figure 3: I count 4 bits for the NxPs field, althou= gh >> =C2=A0 the text says they are 3-bit fields. >> > > GT> yes thanks. > >> =C2=A0* Section 3.1. =C2=A0Hasn't TOS gone out of use, so that DSCP shou= ld be >> =C2=A0 used instead? >> > > GT> Yes, you are probably right. Will correct. > >> =C2=A0* Section 3.1. =C2=A0Address ranges are specified by a single addr= ess and >> =C2=A0 a prefix, whereas port ranges are specified from low to high. >> =C2=A0 I guess the motivation for this, is that addresses will most ofte= n be >> =C2=A0 a single address (MIP) or a prefix (NEMO). =C2=A0I like to have s= uch design >> =C2=A0 rationales mentioned in the document. =C2=A0The traffic selectors= of IPsec >> =C2=A0 prefer address ranges from low to high value, and this document c= ould >> =C2=A0 have followed what IPsec is doing. >> > > GT> The reason for the difference is simply packing efficiency. If we > do IP address range with a from/to, we will end up with 2x32 or 2x128 > as opposed to 32+1 or 128+1 which is how it is now. For port numbers > from/to did not seem that bad since they are only 2bytes each. Does > that make sense? > >> =C2=A0* Section 3.1. =C2=A0In Source Port - High, why not stay firm: If = only one port >> =C2=A0 is of interest, Source Port - High must be absent. =C2=A0Somewher= e, >> =C2=A0 probably in flow binding draft, there will be an error code for >> =C2=A0 a malformed flow description. >> > > GT> Good suggestions, thanks. I will do what you say with the ports > and I will define a new FID status code in this draft. > >> Christian >> >> >> >> >> =C2=A0 =C2=A0 =C2=A0Find din nye laptop p=C3=A5 kelkoo.dk. Se de gode ti= lbud her - http://dk.yahoo.com/r/pat/mm >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > From arno@natisbad.org Tue May 5 04:11: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 AA8CD3A7126 for ; Tue, 5 May 2009 04:11:40 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 P3LtPxcfmvdb for ; Tue, 5 May 2009 04:11:38 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 420B93A6D2F for ; Tue, 5 May 2009 04:10:59 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M1IZR-0007SP-1e; Tue, 05 May 2009 13:12:21 +0200 X-Hashcash: 1:20:090505:nicolas.montavont@telecom-bretagne.eu::sHgggqTE+6kZMuB8:0000000000000000000000002F7+ X-Hashcash: 1:20:090505:ryuji.wakikawa@gmail.com::z1a3ev06czhVh7oP:00000000000000000000000000000000000001Qcc From: arno@natisbad.org (Arnaud Ebalard) To: Nicolas Montavont , Ryuji Wakikawa References: <49EF37D8.2010408@it.uc3m.es> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090505:marcelo@it.uc3m.es::1cIC+ROzoTdZE+oW:00000000000000000000000000000000000000000000jov X-Hashcash: 1:20:090505:mext@ietf.org::6LOkA9RobMju2Fsq:000026gN X-Hashcash: 1:20:090505:jari.arkko@piuha.net::URd9vvtF0w0nLhki:000000000000000000000000000000000000000009prI Date: Tue, 05 May 2009 13:13:09 +0200 Message-ID: <87d4anyf96.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jari Arkko , mext Subject: Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-monami6-mipv6-analysis-05 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, 05 May 2009 11:11:40 -0000 Hi Nicolas and Ryuji, Below is a review of draft-ietf-monami6-mipv6-analysis-05. IMO, the draft is ready for WGLC: noblocking questions/comments, it just needs some polishing to remove typos and update "References" section. > 1. Introduction > > With the emergence of performant wireless technologies, nodes are > highly mobile and can change their point of attachment to the > Internet at any time, even during active network connections. To > support such mobility in IPv6, Mobile IPv6 (RFC 3775 [1] and RFC 3776 s/3776/4877/ > [2]) allows mobile nodes to maintain ongoing sessions while changing > their points of attachment to the Internet. > > Additionally, as explained in [3], ubiquitous, permanent, fault- > tolerant and heterogeneous access to the Internet is required. For > doing so, mobile nodes which are prone to failure or sudden lack of > connectivity may be equipped with multiple interfaces. They may also > be connected to multihomed networks. In such a situation, mobile > nodes would be allocated multiple addresses and are said to be > multihomed. These addresses would be assigned to a single interface > or to multiple interfaces. However, the current specification of > Mobile IPv6 lacks support for using multiple addresses > simultaneously. > > Individual solutions have been proposed to extend Mobile IPv6 in such > a way but all issues have not been addressed and not even discussed > in some document. > > This study aims at fulfilling this gap and has two goals. The first > goal is to determine the capabilities required for providing > ubiquitous, permanent, fault-tolerant and heterogeneous access to the > Internet to multihomed mobile nodes operating Mobile IPv6. The > second goal is to define the issues arising when we attempt to > fulfill these requirements. The definition of solutions addressing > these issues is out of scope of this document. > > To understand the foundation of this study, readers should > familiarize themselves with the companion document [3] which outlines > the motivations, the goals and the benefits of multihoming for both > fixed and mobile nodes (i.e. generic IPv6 nodes). Real-life > scenarios as illustrated in that document are the base motivations > for the present study. The reader should also has basic > understanding of the operation of the Mobile IPv6 protocol specified > in RFC3775 [1]. s/in RFC3775 [1]/in RFC3775 and RFC4877/. I think the reader should have in mind that MIPv6 does use IPsec for protection of signaling (and optionally data) when considering multihoming questions. Because this possibly introduce additional difficulties for multihoming when IPsec/IKE enters the game, even if the draft does not covers those aspects, the reader should be aware that it should be taken into account at some points. > 2. Terminology > > o Simultaneously using multiple addresses > > A mobile node is using multiple addresses simultaneously when an > incoming packet with the destination address set to any of these > addresses reaches the mobile node, or when any of these addresses > can be used by the mobile node as the source address of outcoming s/outcoming/outgoing/ > packets. > > o Simultaneously using multiple interfaces > > A mobile node is using multiple interfaces simultaneously when it > can transmit IP packets over any of these interfaces. > > o Bidirectional Tunnel (BT) Mode > > Mobile IPv6 Bidirectional tunnel between the mobile node and its > home agent. What about adding: "It may either be an IPv6-in-IPv6 tunnel or an IPsec tunnel based on security requirements and configuration." > 5. Analysis of Multihoming Configurations > > In this section, we detail all the possible multihoming > configurations. We briefly discuss the current situation with Mobile > IPv6 and we point to issues that will be further detailed in > Section 6.1, Section 6.2 and Section 6.3. > > As it is demonstrated below, we notice that: > > o When the mobile nodes is equipped with multiple interfaces, s/nodes/node/ > reliability, load sharing and flow distribution can be achieved in > all (*,*) cases. Well, at least it is expected they should be. Current technology does not really allow to do that. > o When a single interface is available, none of the goals can be > achieved in the (1,1) case (the mobile node is not multihomed). > In all the other cases, only reliability and load sharing can be > achieved. Can you clarify why flow distribution is not possible with a single interface when case is *not* (1,1)? Maybe the specific meaning of reliability, load sharing and flow distribution should be given when selected as non-overlapping goals at the beginning of section 3. > 5.1. (1,1): 1 HoA, 1 CoA > > A mobile node in this configuration with only a single network > interface is not multihomed. This configuration is the common case > of a mobile node is away from its home link: the node has one home > address and one care-of address which is configured on the foreign > link. None of the multihoming goals are achievable. > > A mobile node in the same configuration but with several interfaces > is multihomed and lead to a special situation where the mobile node s/lead/may lead/ > is connected to both its home link and a foreign link. In order to > use both interfaces simultaneously, the home address would be > Reliability is achievable, but in a limited manner. Although > the mobile node cannot register its care-of address at its home > agent and use its home link at the same time, it could register > the care-of address with selected correspondent nodes (i.e. > route optimization). In this case, the mobile node can enjoy a > better reliability for communications sessions opened with > these corrrespondent nodes. When the care-of address fails, > the mobile node can either bind a new care-of address with its I don't think the use of 'either' makes sense in the sentence: in all cases, it needs a new CoA, even in second case, to tunnel the packets via the home agent. Or are you considering the MN is on its home link in second case. > home address at the correspondent nodes, or remove the binding > and directly get the packets via the home link. > > > What is missing for Mobile IPv6 > > The mobile node cannot register the care-of address configured > on the foreign network with its home address and receive > packets from the home agent via a tunnel to the care-of address > at the same time it receives packet on the home address from > the home link. In addition, if the mobile node looses its > connection on the foreign link, flows that are started by using > the care-of address as a source address must be re-initiated > with another address (either the home address, or a new care-of > address obtained on another foreign link). Fault recovery is > thus only possible without transparency, and Mobile IPv6 > features can only recover the failure of the home address. > This issue is detailed in Section 6.2.2. > > Reliability could also be achieved through bi-casting since the > mobile node has two addresses and should be able to request any > correspondent node to duplicate traffic to both of them. > However, Mobile IPv6 does not allow the mobile node to request > bi-casting on the correspondent node (see Section 6.2.2). > > > o Load Sharing, Flow Distribution > > What Mobile IPv6 can achieve > > The mobile node is able to use both interfaces at the same > time, according to some preference settings on its side to > decide which one to use for which application. Therefore load > sharing and flow distribution can be achieved when sessions are > initiated by the mobile node. When a correspondent node > initiates a session with the mobile node, it would choose the > destination address depending on the available information > about the mobile node (e.g., DNS request). Presently there is > no mechanism allowing the mobile node to indicate on which > interface (i.e., address) a correspondent node may reach it. > If only one address is known by the distant node, load sharing > and flow distribution cannot be achieved. See in Section 6.1.3 > where such path selection issues are discussed. > > What is missing for Mobile IPv6 > > Although the mobile node is able to use both interfaces at the > same time, there is no mechanism that allows the mobile node to > indicate to which interface (i.e., address) a correspondent > node send packets for a particular flow. Section 6.1.3 > discusses such path selection issues. Maybe that paragraph should be updated in order to reference current MCoA and flow binding drafts. Something like: Although the mobile node is able to use both interfaces at the same time, there is no standard mechanism currently specified which would allow the mobile node to indicate to which interface (i.e., address) a correspondent node should send packets for a particular flow. Nonetheless, there are some ongoing efforts ([MCoA], [I-D.draft-ietf-mext-flow-binding-02]) to provide solutions. Section 6.1.3 discusses such path selection issues. > 5.2. (n,1): n HoAs, 1 CoA > > A mobile node in this configuration is multihomed since it has > several home addresses. This case may happen when a node gets access > to the Internet through different home agents (possibly distinct > operators), each offering a Mobile IPv6 service to the node. That > way, the mobile node would have a home address per home agent. > Alternatively, a single home network may be multihomed to the > Internet, leading to the advertisement of multiple prefixes on the > home link. The mobile node would thus have multiple home addresses > on a single home link. > > In either cases, the node would configure a single care-of address on > the visited IPv6 subnet, and bind that single care-of address to all > its home addresses. If the mobile node has multiple interfaces, only > one interface is connected to a foreign network. The other > interfaces are connected to their home links, or are inactive. > > We next analyze if Mobile IPv6 can be used to achieve the following > multihoming benefits: > > o Reliability > > What Mobile IPv6 can achieve > > The care-of address may change when the mobile node has > multiple interfaces and is disconnected from its home link > (e.g. failure of the interface, or movement). In such a > situation, Mobile IPv6 allows transparent redirection of flows > using the old care-of address (i.e. the session was initiated > using the home address) to another care-of address. For > sessions directly opened via the care-of address, the loss of > the address implies a re-initiation of the session. > > What is missing for Mobile IPv6 > > If the home agent fails, the session using the failed home > agent must be restarted since Mobile IPv6 does not provide any > mechanism to hand-over transparently from a home agent to > another one. Fault tolerance cannot be achieved in this case, > since established communications cannot be preserved (unless > mechanism such as [6] is used). See the corresponding > discussion in Section 6.1.4 and Section 6.2.3. > > If one of the home addresses of the mobile node fails, it means > either that the corresponding home agent has failed (which is > the case discussed above), or the home address is no longer > routed to the home agent. In that latter case, sessions using > that HoA would be terminated, since the home address cannot be > changed transparently. > Reliability through bi-casting could also be achieved by > registering two addresses with a single home address. However > Mobile IPv6 does not provide any mechanism to associate more > than one care-of address with one home address. Moreover, in > this particular case, one home address should be used as a should or could? > care-of address bound to the other home address. (see in > Section 6.2.1 and Section 6.3.1). I wonder what would be the point to do that in that specific scenario. What are the benefits? Even after reading 6.3.1, except in very specific cases (when for some reason the first HA is not reachable via the available CoA for instance), I don't see why it would use the HoA as CoA. > 5.3. (1,n): 1 HoA, n CoAs > > A mobile node in this configuration is multihomed since it has > several care-of addresses. This may occur when the mobile node has > multiple interfaces connected to different links, or when the only > interface is connected to a link where multiple IPv6 prefixes are > advertised (i.e. the visited network is multihomed). Note that one > of the interfaces of the mobile node may be connected to its home > link. > > We next analyze if Mobile IPv6 can be used to achieve the following > multihoming benefits: > > o Reliability > > What Mobile IPv6 can achieve > > Reliability support is limited to recover from a failed care-of > address. Fault recovery is achieved in Mobile IPv6 by > associating an alternate care-of address to replace the failed > one. > > What is missing for Mobile IPv6 > > Efficient mechanisms are needed to determine that a care-of > address has failed (see Section 6.1.1), to check reachability > (Section 6.1.2), to determine which care-of address should be > used instead (Section 6.1.3) and to redirect flows to the new > care-of address (Section 6.1.4). > > o Load Sharing and Flow Distribution > > What Mobile IPv6 can achieve > > This configuration allows sharing of the load and setting of > preferences among different paths between the home agent and > the mobile node when bidirectional tunnel mode is used, and > between the correspondent node and the mobile node when route > optimized mode is used. > > What is missing for Mobile IPv6 > > In order to achieve load sharing and flow distribution under > this scenario, the mobile node would need to register several > care-of addresses with its unique home addresses. However, the > present specification of Mobile IPv6 only allows the mobile > node to register a single care-of address per home address. > This is discussed in Section 6.2.1. When a single home address > is bounded to several care-of addresses at the same time, the s/bounded/bound/ > 6.1.2. Path Exploration > > When the mobile node needs to re-home a communication to an > alternative path, a path exploration may take place. The path > exploration is a step that occurs after the failure detection, It may happen before the failure: for instance, a node with multiple interfaces and/or address w/ various preferences on thoses interfaces may be able to invalidate some addresses by probing the reachability of the home agent from that address for a given protocol (say ESP or proto 41). This would allow the node to avoid the possible latency required to perform the path exploration if the duration of the handover is critical. > and > before the path selection. It consists of identifying a set of paths > that are known to provide bidirectional connectivity between the > mobile node and its home agent, and optionally between the mobile > node and its correspondent node. It may be noted that the step of > path exploration may be avoided by selecting a new path, and trying > to re-home the communications on this new path. If the re- homing > fails, a new path is selected until there is no alternate path, or > the re-homing signaling succeed. > > Path exploration requires some signaling between pairs of addresses > to check reachability. An additional protocol may be needed to > perform this task. > > In (1,*), the path exploration consists in checking reachability > between each care-of address and each home agent address. If RO mode > is used, the mobile node may also insure reachability between its > correspondent nodes' address(es) and each care-of address. > > In (n,*), the path exploration consists in checking reachability > between the home address that is used with the session that must be > re-homed and each care-of address (and optionally with the > correspondent nodes' address(es)). In addition, the session may need > to be re-homed to a different home address. In this case, each path > between a pair (HoA, CoA) must to be validated. s/to be validated/be validated/ > 6.1.3. Path Selection > > When there exists multiple paths from and to the mobile node, the > mobile node ends up choosing a source address, and possibly the > interface that should be used. A correspondent node that wants to > establish a communication with such a mobile node may end up by > choosing a destination address for this mobile node. > > o Interface selection > > When the mobile node has multiple available interfaces, the > simultaneous or selective use of several interfaces would allow a > mobile node to spread flows between its different interfaces. > > Each interface could be used differently according to some user > and applications policies and preferences that would define which > flow would be mapped to which interface and/or which flow should > not be used over a given interface. How such preferences would be > set on the mobile node is out of scope of Mobile IPv6 and might be > implementation specific. On the other hand, if the mobile node > wishes to influence how preferences are set on distant nodes > (correspondent node or home agent), mechanisms such as those > proposed in draft-soliman-flow-binding [9] could be used. Reference should be updated to use draft-ietf-mext-flow-binding-02 ? > 6.1.4. Rehoming > > Re-homing takes place after an outage has been detected or an > alternative path has been identified (see previous issues > Section 6.1.1, Section 6.1.2 and Section 6.1.3), therefrom diverting > existing sessions from one path to another. New transport sessions > would have to be established over the alternate path if no mechanism > is provided to redirect flow transparently at layers above layer 3. > The need for re-homing or flow redirection is explained in Appendix A > > The different mechanisms that can be used to provide re-homing can be > split into three categories, depending on the part of the path that > needs to be changed. > > The first category is the care-of address changes : it influences the > path between the mobile node and its home agent, and the path between > the mobile node and its correspondent node in RO mode. This may hold > in case (n, n). > > The second category is when the home address changes (: it influences s/(:/:/ > 6.1.5. Ingress Filtering > > Ingress filtering mechanisms [15][16] may drop the outgoing packets > when multiple bi-directional tunnels end up at different home agents. > This could particularly occur if different prefixes are handled by > different home agents. If a packet with a source address configured > from a specific prefix is tunneled to a home agent that does not > handle that specific prefix, the packet may be discarded either by > the home agent or by a border router in the home network. The > problem of ingress filtering however, is two-fold. It can occur in > the access network as well as the home network. > > Suppose the mobile node selects the interface (which would determine > the care-of address) and the home network (which would determine the > home address): the chosen care-of address may not be registered with > the chosen home address. For instance, consider Figure 2 below. In > the access network, the mobile node MN must use CoA=PA.MN when it > sends packets through AR-A and it must use CoA=PB.MN when it sends a > packet through AR-B. In the home network, it must use HoA=P1.MN when > it tunnels the packet to home agent HA-1, and it must use HoA=P2.MN > when it tunnels the packet to home agent HA-2. To avoid ingress > filtering, the choice is thus limited to a of valid (HoA,CoA) pairs. ^^^^^^^^ > 6.2. MIPv6-specific Issues > > 6.2.1. Binding Multiple CoAs to a given HoA > > In the (1,n) cases, multiple care-of addresses would be available to > the mobile node. In order to use them simultaneously, the mobile > node must be able to bind and register multiple care-of addresses for > a single home address with both the home agent and the correspondent > nodes. The Mobile IPv6 specification is currently lacking such > ability. > > Although in the (n,n) cases, Mobile IPv6 allows the mobile node to > have multiple (HoA,CoA) pairs, the upper layer's choice of using a > particular home address would mean that the mobile node is forced to > use the corresponding care-of address. This constrains the mobile > node from choosing the best (in terms of cost, bandwidth etc) access > link for a particular flow, since care-of address is normally bound > to a particular interface. If the mobile node can register all > available care-of addresses with each home address, this would > completely decouple the home address from the interface, and allow > the mobile node to fully exploit its multihoming capabilities. > > To counter this issue, a solution like [18] may be used. However, [18] points to version 07 of the draft. Current is 13. In general, some of the references in the draft should be updated to point to latest versions. Cheers, a+ From arno@natisbad.org Tue May 5 05:44: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 DBBA73A7199 for ; Tue, 5 May 2009 05:44:18 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 g3zptiJD2HsA for ; Tue, 5 May 2009 05:44:18 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id ED8283A7198 for ; Tue, 5 May 2009 05:44:17 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M1K1j-0007sS-6H; Tue, 05 May 2009 14:45:39 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: George Tsirtsis References: <29423.26281.qm@web27805.mail.ukl.yahoo.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090505:tsirtsis@googlemail.com::BQFiHQrkiEd2UpbK:0000000000000000000000000000000000000004BK X-Hashcash: 1:20:090505:mext@ietf.org::PytFEoWwbTyWGgDy:00004C7K X-Hashcash: 1:20:090505:hesham@elevatemobile.com::KxKYtwem7RqkhZjp:0000000000000000000000000000000000000BC7O Date: Tue, 05 May 2009 14:46:25 +0200 In-Reply-To: (George Tsirtsis's message of "Tue, 5 May 2009 09:19:14 +0100") Message-ID: <874ovzyaxq.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 05 May 2009 12:44:18 -0000 George Tsirtsis writes: > Right, I agree. I think it is a good property to keep across MIP specs > i.e., BU with Lifetime=0 removes everything, no matter what else is > going on. Not arguing at all on that fact; just clarifying this is not the only way to remove a binding (spec-wise): 1) from a receiver (HA, CN) perspective, having the BU lifetime set to 0 is indeed sufficient. *BUT* having the Care-of Address set to the Home Address is *sufficient* too (i would add for clarity 'no matter the value of the lifetime' in the BU) 2) from a sender perspective, the BU is expected to have the Lifetime set to 0 *and* the Care-of address set as the HoA. To avoid the lookup in RFC 3775 are difficult, below are excerpts from the document: In section 6.1.7. of RFC 3775 ('Binding Update Message') : The deletion of a binding can be indicated by setting the Lifetime field to 0 and by setting the care-of address equal to the home address. In deletion, the generation of the binding management key depends exclusively on the home keygen token, as explained in Section 5.2.5. (Note that while the senders are required to set both the Lifetime field to 0 and the care-of address equal to the home address, Section 9.5.1 rules for receivers are more liberal, and interpret either condition as a deletion.) In section 9.5.1. of RFC 3775 (note that this subsection is part of section '9. Correspondent Node Operation' but explicitly direct the reader to section 10.3.2 for processing when the H flag is set): o If the Lifetime specified in the Binding Update is zero or the specified care-of address matches the home address for the binding, then this is a request to delete the cached binding for the home address. In this case, the Binding Update MUST include a valid home nonce index, and the care-of nonce index MUST be ignored by the correspondent node. The generation of the binding management key depends then exclusively on the home keygen token (Section 5.2.5). If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.3.2; otherwise, it is processed according to the procedure specified in Section 9.5.3. Section 10.3.2. (Primary Care-of Address De-Registration) is based on 10.3.1 which is based on 9.5.1. Cheers, a+ From hesham@elevatemobile.com Tue May 5 05: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 569B13A684C for ; Tue, 5 May 2009 05:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 irf+a0gE+7h6 for ; Tue, 5 May 2009 05:47: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 569D33A679C for ; Tue, 5 May 2009 05:47:49 -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 1M1K58-0000HS-0V; Tue, 05 May 2009 22:49:10 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 05 May 2009 22:49:02 +1000 From: Hesham Soliman To: Arnaud Ebalard , George Tsirtsis Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnNf92mXoRDogJIZU+bDW0vtB0UDQ== In-Reply-To: <874ovzyaxq.fsf@small.ssi.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 05 May 2009 12:47:51 -0000 On 5/05/09 10:46 PM, "Arnaud Ebalard" wrote: > > George Tsirtsis writes: > >> Right, I agree. I think it is a good property to keep across MIP specs >> i.e., BU with Lifetime=0 removes everything, no matter what else is >> going on. > > Not arguing at all on that fact; just clarifying this is not the only > way to remove a binding (spec-wise): > > 1) from a receiver (HA, CN) perspective, having the BU lifetime set to 0 > is indeed sufficient. *BUT* having the Care-of Address set to the > Home Address is *sufficient* too (i would add for clarity 'no matter > the value of the lifetime' in the BU) => Unfortunately that's no longer the case. Having the CoA = HoA doesn't remove bindings. > 2) from a sender perspective, the BU is expected to have the Lifetime > set to 0 *and* the Care-of address set as the HoA. > > To avoid the lookup in RFC 3775 are difficult, below are excerpts from > the document: > > In section 6.1.7. of RFC 3775 ('Binding Update Message') : > > The deletion of a binding can be indicated by setting the Lifetime > field to 0 and by setting the care-of address equal to the home > address. In deletion, the generation of the binding management key > depends exclusively on the home keygen token, as explained in Section > 5.2.5. (Note that while the senders are required to set both the > Lifetime field to 0 and the care-of address equal to the home > address, Section 9.5.1 rules for receivers are more liberal, and > interpret either condition as a deletion.) => Yes this is not true anymore. Hesham From tsirtsis@googlemail.com Tue May 5 05:51: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 1B5303A679C for ; Tue, 5 May 2009 05:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.142, 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 3sxpuorfPYsV for ; Tue, 5 May 2009 05:51:38 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 46D343A6A57 for ; Tue, 5 May 2009 05:50:44 -0700 (PDT) Received: by bwz22 with SMTP id 22so1211497bwz.37 for ; Tue, 05 May 2009 05:52:07 -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=6Tl5Ggt2SsmJC4sQJcX7ErUORZlJgOKAEWPgoE+nqaY=; b=EO9paBj16PnDKFpZxlfWMOxnp7uYqqarxusSoZwWSl9foe8bSB/VDTbeMVvEni4Fiz a+gg8y0qFYU2oLX0E1yOhtI/URWV4JqwPfJAiEIUrRmhD6+gaX37y11Wm/iov0ILMtXD DsL+ZqSfdr8lUCp/zrPIp3CJno1FdxDPj7Clg= 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=S/vF0dKg+W1Bsem6jkmK3MQ45aYw3anj7L78TexB0zzB6WKKua4hI+q9CDB8o9hcAK oE+tjQ5H6c1llBj+/9iP60Bd7U1k0C4Wrd3VOelgNXD4txARSwKNMW+zT1lYggPIHraK Kigs5imEKwFBaZlyIXZJtfQZP5h4puH49TEyg= MIME-Version: 1.0 Received: by 10.223.112.130 with SMTP id w2mr29914fap.65.1241527927080; Tue, 05 May 2009 05:52:07 -0700 (PDT) In-Reply-To: <874ovzyaxq.fsf@small.ssi.corp> References: <29423.26281.qm@web27805.mail.ukl.yahoo.com> <874ovzyaxq.fsf@small.ssi.corp> Date: Tue, 5 May 2009 13:52:06 +0100 Message-ID: From: George Tsirtsis To: Arnaud Ebalard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 05 May 2009 12:51:39 -0000 Hesham, responded while I was writing the e-mail below...which I am still sending to make this even clearer. As far as RFC3775 goes you are correct. In draft-ietf-monami6-multiplecoa-13#section-5.6.3, however, we update this to support home link registrations so that: " When the home binding is used, the mobile node MUST send a registering binding update with a Binding Identifier mobility option whith H flag set. The lifetime MUST be set to a non-zero lifetime of the home binding, and the care-of address MUST be set to the home address." George On Tue, May 5, 2009 at 1:46 PM, Arnaud Ebalard wrote: > > George Tsirtsis writes: > >> Right, I agree. I think it is a good property to keep across MIP specs >> i.e., BU with Lifetime=3D0 removes everything, no matter what else is >> going on. > > Not arguing at all on that fact; just clarifying this is not the only > way to remove a binding (spec-wise): > > 1) from a receiver (HA, CN) perspective, having the BU lifetime set to 0 > =C2=A0 is indeed sufficient. *BUT* having the Care-of Address set to the > =C2=A0 Home Address is *sufficient* too (i would add for clarity 'no =C2= =A0matter > =C2=A0 the value of the lifetime' in the BU) > 2) from a sender perspective, the BU is expected to have the Lifetime > =C2=A0 set to 0 *and* the Care-of address set as the HoA. > > To avoid the lookup in RFC 3775 are difficult, below are excerpts from > the document: > > In section 6.1.7. of RFC 3775 ('Binding Update Message') : > > =C2=A0 The deletion of a binding can be indicated by setting the Lifetime > =C2=A0 field to 0 and by setting the care-of address equal to the home > =C2=A0 address. =C2=A0In deletion, the generation of the binding manageme= nt key > =C2=A0 depends exclusively on the home keygen token, as explained in Sect= ion > =C2=A0 5.2.5. =C2=A0(Note that while the senders are required to set both= the > =C2=A0 Lifetime field to 0 and the care-of address equal to the home > =C2=A0 address, Section 9.5.1 rules for receivers are more liberal, and > =C2=A0 interpret either condition as a deletion.) > > In section 9.5.1. of RFC 3775 (note that this subsection is part of > section '9. Correspondent Node Operation' but explicitly direct the > reader to section 10.3.2 for processing when the H flag is set): > > =C2=A0 o =C2=A0If the Lifetime specified in the Binding Update is zero or= the > =C2=A0 =C2=A0 =C2=A0specified care-of address matches the home address fo= r the > =C2=A0 =C2=A0 =C2=A0binding, then this is a request to delete the cached = binding for > =C2=A0 =C2=A0 =C2=A0the home address. =C2=A0In this case, the Binding Upd= ate MUST include a > =C2=A0 =C2=A0 =C2=A0valid home nonce index, and the care-of nonce index M= UST be > =C2=A0 =C2=A0 =C2=A0ignored by the correspondent node. =C2=A0The generati= on of the binding > =C2=A0 =C2=A0 =C2=A0management key depends then exclusively on the home k= eygen token > =C2=A0 =C2=A0 =C2=A0(Section 5.2.5). =C2=A0If the Home Registration (H) b= it is set in the > =C2=A0 =C2=A0 =C2=A0Binding Update, the Binding Update is processed accor= ding to the > =C2=A0 =C2=A0 =C2=A0procedure specified in Section 10.3.2; otherwise, it = is processed > =C2=A0 =C2=A0 =C2=A0according to the procedure specified in Section 9.5.3= . > > Section 10.3.2. (Primary Care-of Address De-Registration) is based on > 10.3.1 which is based on 9.5.1. > > Cheers, > > a+ > From kaaspetersen@yahoo.dk Tue May 5 06:28: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 261783A69DF for ; Tue, 5 May 2009 06:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 7UVDGrjg9p6C for ; Tue, 5 May 2009 06:28:47 -0700 (PDT) Received: from web27806.mail.ukl.yahoo.com (web27806.mail.ukl.yahoo.com [217.146.182.11]) by core3.amsl.com (Postfix) with SMTP id 855803A693F for ; Tue, 5 May 2009 06:28:47 -0700 (PDT) Received: (qmail 55370 invoked by uid 60001); 5 May 2009 13:30:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1241530211; bh=I2my97Q67QbQMn2M6h1XXjDG7HorBsdL6xeMJLwFa2w=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hpkMEdbP0dQ87vN39XmAVH+GvgXs2B4AClYGolhznWc1QMseeA9szUyPcb7w92WX8cIhAwydaetHxaweKB+7o41j2sI0j5zynVtNQxvJIF7chPsl2vPHfKZ69bxXWP4pR2PF7MuNJEWZ29MoMV3rWjpeEHz1PK1M5d6PMetOGko= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5yXB6cSydUkE66IfeMajy7ydRvrX3geCSNgpL2QYfJ0T208u2tsGIIUwquYhX47OPVDJNrW2Gdd/poyYJ2MXGs+xnwTwsIWaI8fjeXPAi0DqmFwlq2h6DEIRk8etR3HWxfhuQlr0E/62z/R89fGNUyjAo6h392x+ljGecuLyfLY=; Message-ID: <623989.54143.qm@web27806.mail.ukl.yahoo.com> X-YMail-OSG: Ab7XO1oVM1nO4aQSmuI1uydA6VzLk5H7SQN46uz45tVJq2zUqVMab5kENXCYgraYvFFrtxRtrUzm7VhSjw7t9ZSjSVH.LAVc83T0QoB6rEVLHjAxqGgk9OTSUnICYJpXtd3BWlXNOwU5lskroat7AcGV.f19YfU9eRcwCoDkclm3XlGsZwo20QbfMjYFo9ixzed_FEFTTbOHET6Xt92PAij7xrp.pETIokkp0gDh_TgX4hXKrBSEqnKd.9Rt2GNDC37m90irZ0RCQufljPknuSSgckJ5xRaFwpyMcCi.iflemsmVaoDNWC.u4l_r5Z1APHTLrgA9OIrJ19D_v0vhZhIceV.emAVN4KFGDcM- Received: from [193.15.240.60] by web27806.mail.ukl.yahoo.com via HTTP; Tue, 05 May 2009 13:30:11 GMT X-Mailer: YahooMailClassic/5.2.20 YahooMailWebService/0.7.289.1 Date: Tue, 5 May 2009 13:30:11 +0000 (GMT) From: Christian Kaas-Petersen To: George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] binary filters draft 0 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, 05 May 2009 13:28:55 -0000 Fine. Please put "packing efficiency" somewhere in the text. Christian --- Den tirs 5/5/09 skrev George Tsirtsis : > Fra: George Tsirtsis > Emne: Re: [MEXT] binary filters draft 0 > Til: "Christian Kaas-Petersen" > Cc: mext@ietf.org > Dato: tirsdag 5. maj 2009 10.29 > > =A0* Section 3.1. =A0Address ranges are specified by a > single address and > > =A0 a prefix, whereas port ranges are specified from > low to high. > > =A0 I guess the motivation for this, is that addresses > will most often be > > =A0 a single address (MIP) or a prefix (NEMO). =A0I like > to have such design > > =A0 rationales mentioned in the document. =A0The traffic > selectors of IPsec > > =A0 prefer address ranges from low to high value, and > this document could > > =A0 have followed what IPsec is doing. > > >=20 > GT> The reason for the difference is simply packing > efficiency. If we > do IP address range with a from/to, we will end up with > 2x32 or 2x128 > as opposed to 32+1 or 128+1 which is how it is now. For > port numbers > from/to did not seem that bad since they are only 2bytes > each. Does > that make sense? >=20 =0A=0A=0A Find din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - = http://dk.yahoo.com/r/pat/mm From arno@natisbad.org Tue May 5 06:59: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 BF88E3A6858 for ; Tue, 5 May 2009 06:59:23 -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=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 1SM7PPbJlT8I for ; Tue, 5 May 2009 06:59:22 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id BCF013A6D11 for ; Tue, 5 May 2009 06:59:22 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M1LCO-0008Ew-8O; Tue, 05 May 2009 16:00:44 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: George Tsirtsis , Hesham Soliman References: <29423.26281.qm@web27805.mail.ukl.yahoo.com> <874ovzyaxq.fsf@small.ssi.corp> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090505:mext@ietf.org::yjHja85u+irjbEo8:00000Kw/ X-Hashcash: 1:20:090505:hesham@elevatemobile.com::x7j7cLMkmNK99bd1:00000000000000000000000000000000000001B0D X-Hashcash: 1:20:090505:tsirtsis@googlemail.com::f7f3Nnb4Y4Ui19te:000000000000000000000000000000000000000MQJ Date: Tue, 05 May 2009 16:01:32 +0200 In-Reply-To: (George Tsirtsis's message of "Tue, 5 May 2009 13:52:06 +0100") Message-ID: <87skjjwsw3.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 05 May 2009 13:59:23 -0000 Hi, > > > > George Tsirtsis writes: > > > >> Right, I agree. I think it is a good property to keep across MIP specs > >> i.e., BU with Lifetime=0 removes everything, no matter what else is > >> going on. > > > > Not arguing at all on that fact; just clarifying this is not the only > > way to remove a binding (spec-wise): > > > > 1) from a receiver (HA, CN) perspective, having the BU lifetime set to 0 > > is indeed sufficient. *BUT* having the Care-of Address set to the > > Home Address is *sufficient* too (i would add for clarity 'no matter > > the value of the lifetime' in the BU) > > => Unfortunately that's no longer the case. Having the CoA = HoA doesn't > remove bindings. > > > 2) from a sender perspective, the BU is expected to have the Lifetime > > set to 0 *and* the Care-of address set as the HoA. > > > > To avoid the lookup in RFC 3775 are difficult, below are excerpts from > > the document: > > > > In section 6.1.7. of RFC 3775 ('Binding Update Message') : > > > > The deletion of a binding can be indicated by setting the Lifetime > > field to 0 and by setting the care-of address equal to the home > > address. In deletion, the generation of the binding management key > > depends exclusively on the home keygen token, as explained in Section > > 5.2.5. (Note that while the senders are required to set both the > > Lifetime field to 0 and the care-of address equal to the home > > address, Section 9.5.1 rules for receivers are more liberal, and > > interpret either condition as a deletion.) > > => Yes this is not true anymore. @hesham: I think you mean this is no more true in the context of MCoA/flow-binding extensions (and not due to some changes introduced in 3775bis which I would have missed). Is that what you meant? If this is correct, is it defined by the paragraph quoted by George below (applying to MN-HA relationship) or are there any other parts of the spec that revisit 3775-defined behavior on that topic? George Tsirtsis writes: > Hesham, responded while I was writing the e-mail below...which I am > still sending to make this even clearer. > > As far as RFC3775 goes you are correct. > > In draft-ietf-monami6-multiplecoa-13#section-5.6.3, however, we update > this to support home link registrations so that: > > " When the home binding is used, the mobile node MUST send a > registering binding update with a Binding Identifier mobility option > whith H flag set. The lifetime MUST be set to a non-zero lifetime of > the home binding, and the care-of address MUST be set to the home > address." @george: well, because the format of the packet as described above (lft!=0, Care-of address set as HoA) explicitly fit the description of a deregistration BU in 3775, I think it might be useful for developers reading the spec to be aware of that w/o having to confront both spec and then wonder about which is right. What do you think? Anyway, our discussion is only for MN-HA exchanges. For MN-CN, the drafts do not alter the weird expectations of 3775 about format of deregistration BU, do they? Cheers, a+ ps: Another possible solution (not that it is in a ps of a mail, so ...) would be to fill a ticket in the context of 3775bis to add a clarification requiring the lft to be set to 0 in dereg BU and remove the weird ability to dereg by having the care-of address set to the HoA. From kaaspetersen@yahoo.dk Tue May 5 07:12: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 747AA3A6CE2 for ; Tue, 5 May 2009 07:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, 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 Qbj95RwNA0v8 for ; Tue, 5 May 2009 07:12:08 -0700 (PDT) Received: from web27804.mail.ukl.yahoo.com (web27804.mail.ukl.yahoo.com [217.146.182.9]) by core3.amsl.com (Postfix) with SMTP id 563513A6A0D for ; Tue, 5 May 2009 07:12:08 -0700 (PDT) Received: (qmail 27135 invoked by uid 60001); 5 May 2009 14:13:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1241532812; bh=8PwDzFvjNHIMu8SLe8PgVDF5PiwbT8g6hOIejhmsgRE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Q2dGQAo+0MBbCcxeJiCDHvkoCff2utZGz2bbtf7rFwEyNwle2nYp/7749wGgM1k4Q9pvkmvhBlt77K6cE89QD0rWEBXathD8n0KC56xZkmxj3V7NyWHVMgFrv3dBgoK7rGxg65XxdaaAYQlwz4WJ6wxXT2Aq0xleceKvrUoc2Tk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IhN/z5pjtpLHB1nb45FjIbgmXtKk/rn4pKmWvtJB/JaLJku8UF7rnX3KmINwVYmMzOur9ix69Q+6LxiUdYd+B5MILKsZ6xFOw9VadWB47xkYEYBsCTy9tWMkMsgCigk6KbCL98oZbCUx0ctyIvqSNyjOjPUoiS38jC6HaErc+LY=; Message-ID: <559691.25805.qm@web27804.mail.ukl.yahoo.com> X-YMail-OSG: i0c_YyAVM1lHgtPfB8D7vwWK3eLDzX5xCnOVgMmi7v.LYZB9MC5lkJCNJ3gcGayXnjBWEnCAIHekIhCiX0tchDlb_7vfJ_xJp2Z6J_C3yRz4Ov2IRDqS10CDHGQcgHHcTh6FCK0Bz5Mh3AhQ6xVB33JmemA7BkYGlNWAwx46bpQNVT3dd7CuckAwdSiHyzqC6TJGWGr1iWmD77XQgtrZTsESE0fLkkUbLM1rETRkpc6vk_T0Kh3B5D3OaxVq3FaJ_3Q7fGFGShVgx.Fhdb3qmjpzunY6EOId2lO3PubAH9lYt2hK_RJnc_qDWEUTUq63X3TepMTACeZPlQn8t9I74RNn6MylhEo2pljBR5Y- Received: from [193.15.240.60] by web27804.mail.ukl.yahoo.com via HTTP; Tue, 05 May 2009 14:13:32 GMT X-Mailer: YahooMailClassic/5.2.20 YahooMailWebService/0.7.289.1 Date: Tue, 5 May 2009 14:13:32 +0000 (GMT) From: Christian Kaas-Petersen To: George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] binary filters draft 0 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, 05 May 2009 14:12:09 -0000 The DSfield is fine. But for the ECN, using the general offset mechanism, the offset is a count of bytes from the beginning of the packet, and the length is a number of bytes, so I cannot see how it should be possible to consider two ECN-bits somewhere in the middle of the packet when the neighboring six bits in general can take any values. Christian =20 --- Den tirs 5/5/09 skrev George Tsirtsis : > Fra: George Tsirtsis > Emne: Re: [MEXT] binary filters draft 0 > Til: "Christian Kaas-Petersen" > Cc: mext@ietf.org > Dato: tirsdag 5. maj 2009 12.18 > Christian, et.al., >=20 > As I was implementing the changes discussed earlier, the > following > issue came up. >=20 > One of your comments is about renaming the TOS field to > DSCP. First of > all I noticed we used the term Class of Service (CS) in the > IPv6 > header which is not correct...instead it is Traffic Class. >=20 > Looking into this a bit more, however, I remembered that > the IPv4 TOS > byte as well as the IPv6 TC byte were redefined as 6bit > DSfield and 2 > bit Currently Unused (CU) fields. One of the CU bits was > then used by > ECN (see RFC3260 for all this). >=20 > Since I do not anticipate anyone to be matching the ECN bit > for the > purpose of Flow Bindings, I suggest we redefine the 8-bit > TOS field as > an 8bit DSfield, the last 2 bits of which MUST be set to 0 > by sender > and ignored by the receiver. This way a given DSCP can be > matched > without getting confused by the ECN bit. >=20 > If someone really wants to match the ECN bit, (who knows > why) of > course they still can, by using the offset based pointers > defined in > the draft. >=20 > Note that I do not want to make this a 6bit field because > that would > break byte alignment for the sub-option, when this field is > present.. >=20 > Does this make sense? >=20 > George >=20 =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig g= ode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From tsirtsis@googlemail.com Tue May 5 07:34: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 9756D3A6D74 for ; Tue, 5 May 2009 07:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.139, 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 BmEDHE+AsllA for ; Tue, 5 May 2009 07:34:04 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 29F713A6FE6 for ; Tue, 5 May 2009 07:34:04 -0700 (PDT) Received: by fxm2 with SMTP id 2so4655655fxm.37 for ; Tue, 05 May 2009 07:35:28 -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=c7NbniHPlcHafe0MqeCXWu7PAlxQbmkwlhMtg9m1aPo=; b=Fwp+6n35rcOdGRIsNaXMTynQviKB9oCX1uFwF2L+euvbS4Z77RegFRXZxK7iBKkts0 kroHBiP/WN0zSLOIgl4+V0PtPoaCh0QmodZv+e1U14EbRJqLYqOEoyNg5TVCNH3+US8K OM6ONcFZbbBqGtODBKJ1igJqyn8Mn81ntAVtQ= 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=FZyUMQcmAN9GqpGbuz5uBD42snwBKMHqhKShWLy6Y8yj6XBbhitwaIh3dAI55V3Xem E+R/OtSFIC66xiEJO3wvoEWswTFweK1BGJlv1or4YiBxFi2yt0iFvBGCr/eDvtcRvxkn dLg9ay8Ok7l4e2T8Znyk6KkL09isNXijmwIlw= MIME-Version: 1.0 Received: by 10.223.106.15 with SMTP id v15mr200501fao.15.1241534127626; Tue, 05 May 2009 07:35:27 -0700 (PDT) In-Reply-To: <559691.25805.qm@web27804.mail.ukl.yahoo.com> References: <559691.25805.qm@web27804.mail.ukl.yahoo.com> Date: Tue, 5 May 2009 15:35:27 +0100 Message-ID: From: George Tsirtsis To: Christian Kaas-Petersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] binary filters draft 0 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, 05 May 2009 14:34:05 -0000 Ooops yes, you are right, So the ECN 2bit field cannot be identified by pointers, as they are currently defined. I still think though that there is no need to ever match on ECN bits for flow bindings...so we are probably OK? I guess the more general question is, do we need the pointer to be bit specific? or byte specific is enough? George On Tue, May 5, 2009 at 3:13 PM, Christian Kaas-Petersen wrote: > > The DSfield is fine. =C2=A0But for the ECN, using the general offset > mechanism, the offset is a count of bytes from the beginning of the > packet, and the length is a number of bytes, so I cannot see how it > should be possible to consider two ECN-bits somewhere in the middle > of the packet when the neighboring six bits in general can take > any values. > > Christian > > > --- Den tirs 5/5/09 skrev George Tsirtsis : > >> Fra: George Tsirtsis >> Emne: Re: [MEXT] binary filters draft 0 >> Til: "Christian Kaas-Petersen" >> Cc: mext@ietf.org >> Dato: tirsdag 5. maj 2009 12.18 >> Christian, et.al., >> >> As I was implementing the changes discussed earlier, the >> following >> issue came up. >> >> One of your comments is about renaming the TOS field to >> DSCP. First of >> all I noticed we used the term Class of Service (CS) in the >> IPv6 >> header which is not correct...instead it is Traffic Class. >> >> Looking into this a bit more, however, I remembered that >> the IPv4 TOS >> byte as well as the IPv6 TC byte were redefined as 6bit >> DSfield and 2 >> bit Currently Unused (CU) fields. One of the CU bits was >> then used by >> ECN (see RFC3260 for all this). >> >> Since I do not anticipate anyone to be matching the ECN bit >> for the >> purpose of Flow Bindings, I suggest we redefine the 8-bit >> TOS field as >> an 8bit DSfield, the last 2 bits of which MUST be set to 0 >> by sender >> and ignored by the receiver. This way a given DSCP can be >> matched >> without getting confused by the ECN bit. >> >> If someone really wants to match the ECN bit, (who knows >> why) of >> course they still can, by using the offset based pointers >> defined in >> the draft. >> >> Note that I do not want to make this a 6bit field because >> that would >> break byte alignment for the sub-option, when this field is >> present.. >> >> Does this make sense? >> >> George >> > > > > =C2=A0 =C2=A0 =C2=A0Tr=C3=A6nger du til at se det store billede? Kelkoo g= iver dig gode tilbud p=C3=A5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd > From arno@natisbad.org Tue May 5 09:12: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 EEE623A6887 for ; Tue, 5 May 2009 09:12:17 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 uWlTsjSgZyli for ; Tue, 5 May 2009 09:12:16 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 2F76B3A68EC for ; Tue, 5 May 2009 09:12:16 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M1NH1-0000uL-A9 for mext@ietf.org; Tue, 05 May 2009 18:13:39 +0200 X-Hashcash: 1:20:090505:mext@ietf.org::/KN7HF46FCs2G/3V:00006y7k From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG ML X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Tue, 05 May 2009 18:14:27 +0200 Message-ID: <87ocu7v864.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [MEXT] Review of draft-ietf-mext-flow-binding-02 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, 05 May 2009 16:12:18 -0000 Hi, Below is a review of draft-ietf-mext-flow-binding-02. I think the document is in pretty good shape and provides a good framework for flow binding feature. The whole thing is bit difficult to read towards the end but I don't think it's an editorial issue: the links and interactions between things requires some attention and this is the end of the day here. In the end, I won't state it would be difficult (or easy) to implement, but it will clearly require to be careful. At the end of the reading, I wondered what will happen on a HA when it will receive the first a BU of a MN that has just rebooted after a crash. More precisely, I just want confirmation that there is no way for some old flow to survive on the HA due to some specific values in the BU (same CoA, BID, ...). Cheers, a+ > 2. Introduction > > Mobile IPv6 [RFC3775], DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] and > Nemo Basic Support [RFC3963] allow a mobile node / mobile router to > manage its mobility using the binding update message, which binds one > care-of address to one home address. The binding update message can > be sent to the home agent. In Mobile IPv6, the binding update can > also be sent to correspondent node or to a mobility anchor point (see > [RFC5380]). What about making one simple sentence from the last two sentences: The Binding Update message can be sent to the home agent, to a correspondent node or to a mobility anchor point (see [RFC5380]). > The semantics of the binding update are limited to care-of address > changes. That is, [RFC3775], ... Would use 'primary care-of address changes' in order for the 'That is' in the next sentence to be logical. > 3. Terminology Christian's proposal to improve that section looked fine. > 4. Mobile IPv6 Extensions > > This section introduces extensions to Mobile IPv6 that are necessary > for supporting the flow binding mechanism described in this document. > > 4.1. Definition Update for Binding Identifier Mobility Option > > This specification updates the definition of the Binding Identifier > Mobility option defined in [I-D.ietf-monami6-multiplecoa], as > follows: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Binding ID (BID) | Status |H| BID-PRI | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ > + + > : IPv4 or IPv6 care-of address (CoA) : > + + > +---------------------------------------------------------------+ > > > > Figure 1: The Binding Identifier Mobility option > > > > BID-PRI > > This is a 7-bit field placing each BID to a relative priority > with other registered BIDs. Value "0" is reserved for > implementation of [I-D.ietf-monami6-multiplecoa] that do not > support this specification. A higher number in this field > indicates lower priority, while BIDs with the same BID-PRI > value have equal priority. I may be missing something, but is there any reason not to use the Value "0"? As a reserved field in draf-ietf-monami6-multiplecoa, it is not expected to be considered by implementations that implement only draf-ietf-monami6-multiplecoa (i.e. do not support flow-binding). > 4.2.1. Binding Reference Sub-option > > This section introduces the Binding Reference sub-option, which may > be included in the Flow identification option. The Binding Reference > sub-option includes one or more BIDs defined in MCoA > [I-D.ietf-monami6-multiplecoa]. When this sub-option is included in > the Flow identification option it associates the flow described with > one or more registered BIDs. > > The binding identifier option, defined in > [I-D.ietf-monami6-multiplecoa], registering a given BID which is then > indicated in the Binding Reference sub-option, MUST be either defined > in the same or earlier BU from the one including the binding > reference sub-option. The Binding Reference sub-option is shown > below. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Sub-opt Type | Sub-Opt Len | BID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BID ........ > +-+-+-+-+-+-+-+-+-+- > > Figure 3: The Binding Reference sub-option > > > Sub-opt Type > > Indicates the Sub-option type. For the Binding Reference sub- > option, this field MUST be set to 1. > > Sub-opt Len > > Indicates the sub-option length in octets. This field includes > the entire length of the sub-option including the Sub-opt Type > and Sub-opt-Len fields. > > BID > > The BID that the mobile node wants to associate with the flow > identification option. One or more BID fields can be included > in this sub-option. Since each BID is 2 byte long, the value > of the Sub-opt Len field indicates the number of BIDs present. > Number of BIDs = (Sub-opt Len-2)/2. > > 4.2.2. Flow Description Sub-option > > The Flow description sub-option(s) include the parameters used to > match packets for a specific flow binding. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Sub-opt Type | Sub-Opt Len | Flow Description ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 4: The Flow Description sub-option > > Sub-opt Type > > Indicates the Sub-option type. For the flow description sub- > option, this field SHOULD be set to one of the FD types defined > below. > > Sub-opt Len > > Indicates the sub-option length in octets. This field includes > the entire length of the sub-option including the Sub-opt Type > and Sub-opt-Len fields. > > Flow Description > > The flow description corresponding to the type indicated by the > Sub-opt Type field. Flow description is out of scope of this > document. > > The following values are reserved for the sub-option Type values are > defined for Flow Description: That sentence looks strange. > 17-32 reserved for Flow Description formats. > 4.3. Flow Identification Summary Mobility Option > > TBD > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option Type | Option Len | FID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | FID ........ > +-+-+-+-+-+-+-+-+-+- > > Figure 5: The Flow Identification Summary Option > > Option Type > > Indicates the Sub-option type. For the Binding Reference sub- > option, this field MUST be set to 1. > > Option Length > > Indicates the sub-option length in octets. This field includes > the entire length of the sub-option including the Sub-opt Type > and Sub-opt-Len fields. > > FID > > A registered FID. One or more FID fields can be included in > this option. Since each FID is 2 bytes long, the value of the > Option Len field indicates the number of FIDs present. Number > of FIDs = (Sub-opt Len-2)/2. This section looks like a copy of 4.2.1. > 4.4. Flow Bindings entries list and its relationship to Binding Cache > > The conceptual mobile IPv6 binding cache was defined in [RFC3775] to > identify the mobile IP state maintained by the mobile node, home > agent, and corresponding node. The binding cache includes, between s/between/among/ > others, the mobile node's home address, the registered care-of > address, and the lifetime of the binding. The binding cache was then > extended by [I-D.ietf-monami6-multiplecoa] to include more than one > care-of addresses and to associate each of them with a Binding > Identifier (BID). > > This specification does not change modify the mobile IPv6 binding ^^^^^^^^^^^^^ > cache any further. > > Flow bindings can be thought of as a conceptual list of entries that > is separate from the binding cache. The flow bindings list contains > an entry for each of the registered flow binding. Flow binding > entries can point to an entry in the binding cache by means of the > BID. Each flow binding entry include the following parameters : includes > 5. Protocol operations > > 5.1. General > > This specification introduces a flow bindings list of entries and an > ordered list of binding identifiers, allowing mobile nodes to > associate flow binding policies with the registered care-of > addresses. > > The flow identification option defines how the mobile node can > control a set of flow binding entries maintained in a home agent, > correspondent node, or mobility anchor points, on its behalf. The > fields of the flow identification option are necessary for ordering > flow identification options, indicating the sort of action that > should be undertaken to the recipient's flow binding list of entries > or for carrying the results of such a petition. > > This specification allows mobile nodes to direct flows to a > particular care-of address. The granularity of what constitutes a > flow depends on the flow descriptor used. As indicated earlier the > flow description itself is defined in another document. As indicated earlier, various flow descriptions are specified in external documents. > 5.2. Mobile Node Considerations > > This specification allows the mobile node to maintain several > bindings in its home agent and to direct packets to different care-of > addresses according to flow bindings. This section details the > mobile node operations necessary to implement this specification. > > The home agent list of flow bindings is manipulated by the mobile > node, via flow identification and flow summary options included in > binding update messages. Each flow binding update can add, modify, > refresh, or delete a given binding. More than one flow > identification options MAY be included in the same binding update but > each of them MUST include a different FID. In other words, two flow > identification options in the same message can not be about the same > flow binding. > > All flow binding state MUST be refreshed in every binding update the > mobile node sends. Any previously registered flow binding that is > not included in a given binding update will be deleted. So, any flow > bindings that are not added or modified by a flow identification > option, but have previously registered and need to be maintained been registered > 5.2.1. Sending BU with BID Options > > This specification (see Section 4.1) updates the definition of the > Binding Identifier option, originally defined in > [I-D.ietf-monami6-multiplecoa]. According to this specification the > BID option includes a BID-PRI field assigning each registered care-of > address a priority, and thus placing them in an ordered list as also > described in Section 4.4. > > Mobile nodes supporting this specification MUST use the BID option > format defined in Section 4.1. Mobiles nodes MUST also register Mobile nodes > 5.2.5. Receiving Binding Acknowledgements > > According to [RFC3775] all nodes are required to silently ignore > mobility options not understood while processing binding updates. As > such a mobile node receiving a Binding Acknowledgement in response to > the transmission of a binding update MUST determine if the Binding > Acknowledgement contains a copy of every flow identification options > included in the binding update. A Binding Acknowledgement without > flow identification option(s), in response to a Binding Update with > flow identification option, would indicate inability (or > unwillingness) on behalf of the source node to support the extensions > presented in this document. > > If a received Binding Acknowledgement contains a copy of of each flow s/of of/of/ > 5.3.2. Receiving BU with Flow Identification Options > > When the home agent receives a binding update which includes at least > one Flow Identification option, it first performs the operation > described in section 10.3.1 of RFC3775. > > Home agents that do not support this specification will ignore the > flow identification options and all their suboption, having no effect > on the operation of the rest of the protocol. > > If the binding update is accepted, and the home agent is willing to > support flow bindings for this MN, the home agent checks the flow > identification options. > > If more than one flow identification option in the same BU, has the s/same BU,/same BU/ Cheers, a+ From nicolas@montavont.net Wed Apr 22 06:23: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 39D9C3A6CA9 for ; Wed, 22 Apr 2009 06:23:42 -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 PigATSN5bhdZ for ; Wed, 22 Apr 2009 06:23:41 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 7FEA03A6BCA for ; Wed, 22 Apr 2009 06:23:40 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so324174eyd.31 for ; Wed, 22 Apr 2009 06:24:56 -0700 (PDT) Received: by 10.210.87.14 with SMTP id k14mr6295741ebb.60.1240406696867; Wed, 22 Apr 2009 06:24:56 -0700 (PDT) Received: from ?192.168.0.10? (lns-bzn-38-82-253-76-118.adsl.proxad.net [82.253.76.118]) by mx.google.com with ESMTPS id 24sm234164eyx.43.2009.04.22.06.24.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Apr 2009 06:24:56 -0700 (PDT) Message-Id: <2008C7DD-3ED4-414C-8CB1-1854A62508D9@montavont.net> From: Nicolas Montavont To: mext In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 15:24:54 +0200 References: X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Tue, 05 May 2009 11:00:39 -0700 Cc: Michael Eriksson Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents 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, 23 Apr 2009 12:45:29 -0000 Ryuji, Just to confirm what Hesham said. I don't know about Koojana's implementation, but ours is still maintained. We are currently working to update it according to the new specification of Flow Binding (that should come out soon). We are using Romain's implementation of MCoA. Nicolas On Apr 22, 2009, at 3:06 AM, Hesham Soliman wrote: > Hi Ryuji, > > There was a long detailed presentation made in monami6 by one of > Koojana's > colleagues (the name escapes me) where he gave detailed feedback > based on > their implementation. Also Nicolas gave some feedback based on their > MR > implementation and use scenarios. The former is in the public domain > and the > latter was part of the discussion for the next rev. > > Hesham > > > On 22/04/09 1:31 AM, "Ryuji Wakikawa" > wrote: > >> Hi Hesham, >> >> I am collecting the implementation info of MCoA or flow binding. >> Which implementation's' are you referring to ? Romain's one? >> Please share the implementations info if you can. >> >> thanks, >> ryuji >> >> On 2009/04/21, at 6:35, Hesham Soliman wrote: >> >>> >>> >>> >>> On 21/04/09 10:29 PM, "Michael Eriksson" >>> >>> wrote: >>> >>>> On Tue, Apr 21, 2009 at 13:03:03 +0200, marcelo bagnulo braun >>>> wrote: >>>>>> Well, now that we are taking a new grip on flow routing, I would >>>>>> like >>>>>> to push draft-eriksson-mext-mipv6-routing-rules-00, which Romain >>>>>> also >>>>>> pointed at. >>>>>> >>>>>> http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing- >>>>>> rules >>>>> >>>>> I understand that we do have a WG document for this and we had >>>>> several >>>>> rounds of reviews which show interest, so i don't see any reason >>>>> to >>>>> revisit the decision of using draft-ietf-flow-binding at this >>>>> point. >>>>> regards, marcelo >>>> >>>> Well, the WG document has had exactly zero progress since the 00 >>>> version was adopted almost a full year ago. It's not like chosing >>>> another way to transfer routing rules would be a last minute stop >>>> to >>>> something that has already been finished. >>> >>> => Nonsense. The WG document has been depending on the progress of >>> MCoA and >>> now that MCoA is done we will have a new near final version by the >>> weekend. >>> This version has already received numerous reviews and some feedback >>> from >>> implementations. We expect this to go to LC before the next meeting. >>> Please >>> get those facts straight. BTW, the 00 version was around for >>> discussions and >>> review for a couple of years as a monami6 WG doc before it was >>> adopted by >>> the MEXT WG. >>> >>> 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 From jiang.xiaowei@zte.com.cn Wed Apr 29 18:54: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 861933A6A38; Wed, 29 Apr 2009 18:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.908 X-Spam-Level: X-Spam-Status: No, score=-100.908 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 bGrS8ZRo1cR1; Wed, 29 Apr 2009 18:54:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 3FDC53A6B81; Wed, 29 Apr 2009 18:54:10 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111642595965004; Thu, 30 Apr 2009 09:44:31 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 47274.2595965004; Thu, 30 Apr 2009 09:51:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n3U1sxQY094951; Thu, 30 Apr 2009 09:54:59 +0800 (CST) (envelope-from jiang.xiaowei@zte.com.cn) To: mext@ietf.org, mip4@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: jiang.xiaowei@zte.com.cn Date: Thu, 30 Apr 2009 09:54:47 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-30 09:52:44, Serialize by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-30 09:52:44, Serialize complete at 2009-04-30 09:52:44, S/MIME Sign failed at 2009-04-30 09:52:44: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-30 09:54:56, Serialize complete at 2009-04-30 09:54:56 Content-Type: multipart/alternative; boundary="=_alternative 000A5279482575A8_=" X-MAIL: mse2.zte.com.cn n3U1sxQY094951 X-Mailman-Approved-At: Tue, 05 May 2009 11:00:39 -0700 Subject: [MEXT] Any previous discussion about host based mobility solution? 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, 30 Apr 2009 01:54:11 -0000 This is a multipart message in MIME format. --=_alternative 000A5279482575A8_= Content-Type: text/plain; charset="US-ASCII" Hello all, After recent research of the current MIP and PMIP solution, I found it a network based tunnel solution. Now I'm wondering if any host based solution ever been proposed and discussed before. So please any body in the IP mobility community provide some clue, thank you! --=_alternative 000A5279482575A8_= Content-Type: text/html; charset="US-ASCII"
Hello all,

After recent research of the current MIP and PMIP solution, I found it a network based tunnel solution.
Now I'm wondering if any host based solution ever been proposed and discussed before.
So please any body in the IP mobility community provide some clue, thank you! --=_alternative 000A5279482575A8_=-- From behcetsarikaya@yahoo.com Tue May 5 11:58: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 543AD28C0F5 for ; Tue, 5 May 2009 11:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-0.234, 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 aRRRDEMpPq3Y for ; Tue, 5 May 2009 11:58:15 -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 C105C3A6BEE for ; Tue, 5 May 2009 11:58:10 -0700 (PDT) Received: from [68.142.230.28] by n7.bullet.re3.yahoo.com with NNFMP; 05 May 2009 18:59:35 -0000 Received: from [67.195.9.83] by t1.bullet.re2.yahoo.com with NNFMP; 05 May 2009 18:59:35 -0000 Received: from [67.195.9.110] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 05 May 2009 18:59:34 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 05 May 2009 18:57:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 618672.23954.bm@omp114.mail.gq1.yahoo.com Received: (qmail 24720 invoked by uid 60001); 5 May 2009 18:59:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241549974; bh=aXXNGiKgNVY2KY2E83br0evwly0bNPC7wZw+QrixkLA=; 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=U89EMLUBSSP9TtmQTswbEM44viBdR+WMPZvUrKETRX3VcP2g9A7chY1SJSC7qBFy4dwoXS6RJmQT0W5EuC+Ea1CxF/3jWid3fCIIZskgVnLPqkN8P6+r9z2876ht4NJYhnoDv55QedbHEMCHlHNaioR0MSnF0UShtn47+1VJRg8= 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=BhYrMKwMcZpay62KHWoghqTLvxGV2XtpX+0HiskEC0OE5x1Srliccy02h8L8UHGFQEL46W8FaYLlhsh/q63xwcFZH/sSB8+jJEp0LFVDXWnda29yFBRChZOalFFaivQ+PIftJi0R8+vH5k/BjffkcfRB9vcTg+cAbKRHtTLeqvk=; Message-ID: <623252.22583.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: 8mHprDYVM1mqw4UKyqpwn12EiSxi_Z.tB8barRETdZvZs6g9SutOukisf0QNksN_JR6SuC1VugjSMkrr53I6cR_94.JEBqfCVjj_IxCTIQm30p5bQJ22_Rv_Y881oeEQBxFK0sWM.tE3KDFnRl_q7.YsbxthWxY4NtakHJjiQZwbL2UT3_xIDhve6eLvDCblg5RlHd_ogCT9Z_JhxvkzBp1q2REbrWxoIJ9Xk.4VrGkRJyDU5YaNf7CvinfXrFIIBsq_hXbcmlrN2SXyubnKiZ.LKkNGlMNlvYRFobqrcUGhmBqa6XUKA4efGjcZlyyppbYw Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Tue, 05 May 2009 11:59:34 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> <375902.20727.qm@web111403.mail.gq1.yahoo.com> <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> <222821.303.qm@web111407.mail.gq1.yahoo.com> <954696.84777.qm@web111411.mail.gq1.yahoo.com> Date: Tue, 5 May 2009 11:59:34 -0700 (PDT) From: Behcet Sarikaya To: Ryuji Wakikawa In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1104874104-1241549974=:22583" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.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: Tue, 05 May 2009 18:58:17 -0000 --0-1104874104-1241549974=:22583 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ryuji,=0A=A0 It seems that MCoA draft uses the H flag defined in the bas= e spec. I don't think that is the right flag to use for the purpose of send= ing a non-deregistration BU at the home link. =0A=0ARegards,=0A=0ABehcet=0A= =0A=0A________________________________=0AFrom: Ryuji Wakikawa =0ATo: Behcet Sarikaya =0ACc: mext =0ASent: Saturday, April 25, 2009 3:32:33 AM=0ASubject: Re: [MEXT] [= Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A=0AHi Behcet,=0A= =0AOn 2009/04/22, at 18:54, Behcet Sarikaya wrote:=0A=0A> Hi Ryuji,=0A>=A0 = So you are going to define a C-Flag?=0A=0AMCoA does not have such flag. Wha= t are you referring to?=0A=0Aregards,=0Aryuji=0A=0A> I am OK with it. But I= don't understand why the only right place is your draft. My idea is that t= he right place for such a thing is 3775bis as this would avoid people with = drafts not related to MCoA having to refer to MCoA draft.=0A> =0A> Regards,= =0A> =0A> Behcet=0A> =0A> From: Ryuji Wakikawa = =0A> To: Behcet Sarikaya =0A> Cc: mext = =0A> Sent: Wednesday, April 22, 2009 5:02:09 PM=0A> Subject: Re: [MEXT] [Fw= d: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> =0A> Hi Behcet,=0A= > =0A> On 2009/04/22, at 17:45, Behcet Sarikaya wrote:=0A> =0A> > Hi Ryuji,= =0A> >=A0 I checked your draft. Again, I could not understand how you are s= ending a registration BU at the home link as only an O-flag is defined in y= our draft which is used for something else.=0A> =0A> Please see section 5.6= ..3=0A> =0A> >=A0 As I mentioned to you, we discussed this related to draft-= premec-homelink and it seems like HA will reject such a BU unless something= is done, I thought you were familiar with the discussions as it relates to= your draft too. I am surprised.=0A> =0A> yes, I follow that discussion.=0A= > RFC3775-bis should not include any additional features like sending BU fr= om the home link.=0A> We should define this in MCoA. Only if needed, draft-= homelink can refer to MCoA for this feature.=0A> =0A> regards,=0A> ryuji=0A= > =0A> =0A> =0A> =0A> =0A> =0A> >=0A> > Regards,=0A> >=0A> > Behcet=0A> >= =0A> > From: Ryuji Wakikawa =0A> > To: Behcet Sa= rikaya =0A> > Cc: George Tsirtsis ; mext =0A> > Sent: Wednesday, April 22, 2009 4:18:28 PM= =0A> > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-= 13.txt]=0A> >=0A> > Hi Behcet,=0A> >=0A> > On 2009/04/22, at 11:31, Behcet = Sarikaya wrote:=0A> >=0A> > >=0A> > >=0A> > > From: George Tsirtsis =0A> > > To: Behcet Sarikaya =0A> > >= Cc: mext =0A> > > Sent: Wednesday, April 22, 2009 10:10:08 = AM=0A> > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiple= coa-13.txt]=0A> > >=0A> > > I do not think that adding home link registrati= on to RFC3775bis is feasible.=0A> > > This requires logic in the MN and HA = that is not directly compatible=0A> > > to RFC3775. The aim of RFC3775bis i= s to make minimal changes for=0A> > > clarification reasons and to correct = errors. Home Link Registration as=0A> > > defined in MCoA is neither.=0A> >= > [behcet] Why not? If it is needed in so many instances, that qualifies i= t to become a base protocol feature, at least to me.=0A> >=0A> > We cannot = add a new feature to 3775. That is the ground rule of -bis. The chairs can = clarify this.=0A> >=0A> > regards,=0A> > ryuji=0A> >=0A> >=0A> >=0A> > >=0A= > > > On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya=0A> > > wrote:=0A> > > > Hi George,=0A> > > >=A0 It seems in my prev= ious reply I replied to this mail of yours which was=0A> > > > unrelated to= the other mail you sent to which I was really replying,=0A> > > > apologie= s.=0A> > > >=A0 Now regarding home link registration, what is the mechanism= MCoA draft=0A> > > > uses? Ryuji mentioned some H bit but I read the draft= and couldn't confirm=0A> > > > it.=0A> > > >=0A> > > >=A0 My suggestion wa= s building on this, i.e. I suggested that whatever you=0A> > > > came up wi= th can be moved to 3775bis so that other people would not have to=0A> > > >= make normative references to your draft.=0A> > > >=0A> > > > That's all.= =0A> > > >=0A> > > > Regards,=0A> > > >=0A> > > > Behcet=0A> > > >=0A> > > = > ________________________________=0A> > > > From: George Tsirtsis =0A> > > > To: Vijay Devarapalli =0A> = > > > Cc: Behcet Sarikaya ; mext =0A> > >= > Sent: Tuesday, April 21, 2009 2:14:55 PM=0A> > > > Subject: Re: [MEXT] [= Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> > > >=0A> > > > = ....also wrt the home link registration, I do not think what you=0A> > > > s= uggest is necessary.=0A> > > >=0A> > > > As far as I see the other document= s are informational, and they do not=0A> > > > yet have a formal standing i= n the WG. If and when they do, as=0A> > > > Informational documents,=A0 the= y should not require normative changes to=0A> > > > anything. They should m= ake sure what they describe (mostly=0A> > > > implementation options in thi= s case) are compatible not only with=0A> > > > RFC3775 but also with extens= ions to it, including Flow Bindings. .=0A> > > >=0A> > > >=0A> > > > Regard= s=0A> > > > George=0A> > > >=0A> > > > On Tue, Apr 21, 2009 at 7:58 PM, Vij= ay Devarapalli =0A> > > > wrote:=0A> > > >> Behcet,=0A>= > > >>=0A> > > >> Behcet Sarikaya wrote:=0A> > > >>>=0A> > > >>> *[behcet]= Yes but each interface will appear to HA as a different device=0A> > > >>>= and HA needs to assign a different HoA. Then MCoA problem disappears.*=0A>= > > >>> *So George is saying that this is avoided by some virtual interfac= es so=0A> > > >>> that HA does not see each interface separately. *=0A> > >= >>> *Is this explained anywhere in the draft?*=0A> > > >>> *If yes then I = am OK.*=0A> > > >>=0A> > > >> The home agent does not care about the multip= le interfaces on the mobile=0A> > > >> node. It only sees the mobile node a= s one entity and allocates a home=0A> > > >> address to it. The multiple ca= re-of addresses that the mobile node has=0A> > > >> will=0A> > > >> be used= by the home agent as tunnel end points. That is all. So there is=0A> > > >= > no=0A> > > >> issue.=0A> > > >>=0A> > > >> Vijay=0A> > > >>=0A> > > >>>= =A0 >=A0 Also I have a question to Ryuji: does this draft send a=0A> > > >>= > non-deregistration BU at the home link? If yes, is he familiar with the= =0A> > > >>> discussion going on on this subject? This is another point of = confusion=0A> > > >>> for=0A> > > >>> me.=0A> > > >>>=0A> > > >>> This has = been discussed for a long time in MEXT.=0A> > > >>> who is familiar with wh= ich discussions? I don't know your concern here.=0A> > > >>>=A0 *[behcet] S= o your answer is yes the draft sends a non-deregistration BU=0A> > > >>> (k= ind of bulk registration) at the home link.*=0A> > > >>> *The discussion I = mentioned was related to=0A> > > >>> draft-premec-mext-extended-home-link. = This draft also sends=0A> > > >>> non-deregistration BU at the home link. S= o does a few more drafts like=0A> > > >>> **draft-devarapalli-mext-mipv6-ho= me-link.*=0A> > > >>>=0A> > > >>> **=0A> > > >>> *[behcet] You mentioned so= me bit is set but I could not understand which.=0A> > > >>> One idea is sin= ce so many drafts need this, why not factor this out and=0A> > > >>> define= whatever the mechanism to enable sending non-deregistration BU in=0A> > > = >>> 3775bis. What do you think about that?*=0A> > > >>>=0A> > > >>> **=0A> = > > >>>=0A> > > >>>=A0 >=A0 Sorry if I am too=A0 much confused=0A> > > >>>= =A0 > Please don't get me wrong, I am not trying to slow down the progress= =0A> > > >>> of=0A> > > >>> this document..=0A> > > >>>=0A> > > >>> sure, b= ut please explain your issue more precisely.=0A> > > >>>=0A> > > >>> thanks= !=0A> > > >>> ryuji=0A> > > >>>=0A> > > >>>=A0 >=0A> > > >>>=A0 > Regards,= =0A> > > >>>=A0 >=0A> > > >>>=A0 > Behcet=0A> > > >>>=A0 > From: marcelo ba= gnulo braun > > >>> >=0A= > > > >>>=A0 > To: mext >; Julien Lag= anier=0A> > > >>> > > >>> >; Jari Arkko=0A> > > >>> >=0A> > > >>>=A0 > Sent: Tuesday, A= pril 21, 2009 11:03:05 AM=0A> > > >>>=A0 > Subject: [MEXT] [Fwd: I-D=0A> > = > >>> Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> > > >>>=A0 >=0A> > = > >>>=A0 > We have this new version of the MCOA document that addresses the= =0A> > > >>> comments received, including IESG review comments..=0A> > > >>= >=A0 > To the best of my knowledge, the IESG is ok with the doc and ready f= or=0A> > > >>> publication..=0A> > > >>>=A0 > I am planning to ask our AD t= o move forward in a week or so, so, if=0A> > > >>> you=0A> > > >>> have com= ments on the document please provide them before the 1st of may.=0A> > > >>= >=A0 >=0A> > > >>>=A0 > Regards, marcelo=0A> > > >>>=A0 > (mcoa doc shepher= d)=0A> > > >>>=A0 >=0A> > > >>>=A0 > -------- Mensaje original --------=0A>= > > >>>=A0 > Asunto:=A0 =A0 [MEXT] I-D Action:draft-ietf-monami6-multiplec= oa-13.txt=0A> > > >>>=A0 > Fecha:=A0 =A0 Mon, 20 Apr 2009 08:30:01 -0700 (P= DT)=0A> > > >>>=A0 > De:=A0 =A0 Internet-Drafts@ietf.org =0A> > > >>>=A0 > Para:=A0 =A0 i-d-announce@ietf.org =0A> > > >>>=A0 > CC:=A0 =A0 mext@ietf.org =0A> > > >>>=A0 >=0A> > > >>>=A0 >=0A> > > >>>=A0 >=0A> > > >>= >=A0 > A New Internet-Draft is available from the on-line Internet-Drafts= =0A> > > >>> directories.=0A> > > >>>=A0 > This draft is a work item of the= Mobility EXTensions for IPv6 Working=0A> > > >>> Group of the IETF.=0A> > = > >>>=A0 >=0A> > > >>>=A0 >=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-13..txt=0A> > > >>>=A0 >=A0 = =A0 Pages=A0 =A0 =A0 =A0 =A0 : 44=0A> > > >>>=A0 >=A0 =A0 Date=A0 =A0 =A0 = =A0 =A0 =A0 : 2009-04-20=0A> > > >>>=A0 >=0A> > > >>>=A0 > According to the= current Mobile IPv6 specification, a mobile node may=0A> > > >>>=A0 > have= several care-of addresses, but only one, called the primary=0A> > > >>>=A0= > care-of address, that can be registered with its home agent and the=0A> = > > >>>=A0 > correspondent nodes.=A0 However, for matters of cost, bandwidt= h, delay,=0A> > > >>>=A0 > etc, it is useful for the mobile node to get Int= ernet access through=0A> > > >>>=A0 > multiple accesses simultaneously, in = which case the mobile node would=0A> > > >>>=A0 > be configured with multip= le active IPv6 care-of addresses..=A0 This=0A> > > >>>=A0 > document propos= es extensions to the Mobile IPv6 protocol to register=0A> > > >>>=A0 > and = use multiple care-of addresses.=A0 The extensions proposed in this=0A> > > = >>>=A0 > document can be used by Mobile Routers using the NEMO (Network=0A>= > > >>>=A0 > Mobility) Basic Support protocol as well.=0A> > > >>>=A0 >=0A= > > > >>>=A0 > A URL for this Internet-Draft is:=0A> > > >>>=A0 >=0A> > > >= >> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.tx= t=0A> > > >>>=A0 >=0A> > > >>>=A0 > Internet-Drafts are also available by a= nonymous FTP at:=0A> > > >>>=A0 > ftp://ftp.ietf.org/internet-drafts/=0A> >= > >>>=A0 >=0A> > > >>>=A0 > Below is the data which will enable a MIME com= pliant mail reader=0A> > > >>>=A0 > implementation to automatically retriev= e the ASCII version of the=0A> > > >>>=A0 > Internet-Draft.=0A> > > >>>=A0 = >=0A> > > >>>=A0 >=0A> > > >>>=A0 >=0A> > > >>>=A0 > ______________________= _________________________=0A> > > >>>=A0 > MEXT mailing list=0A> > > >>>=A0= > MEXT@ietf.org =0A> > > >>>=A0 > https://www.ietf.o= rg/mailman/listinfo/mext=0A> > > >>>=0A> > > >>>=0A> > > >>>=0A> > > >>> --= ----------------------------------------------------------------------=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.o= rg=0A> > > >> https://www.ietf.org/mailman/listinfo/mext=0A> > > >>=0A> > >= >=0A> > > >=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 --0-1104874104-1241549974=:22583 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ryuji,
=0A
  It seems that MCoA draft= uses the H flag defined in the base spec. I don't think that is the right = flag to use for the purpose of sending a non-deregistration BU at the home = link.
=0A
 
=0A
Regards,
=0A
&nb= sp;
=0A
Behcet
=0A
=0A=0AFrom: Ryuji Wa= kikawa <ryuji.wakikawa@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext <mext@ietf.org>
= Sent: Saturday, April 25, 2009= 3:32:33 AM
Subject: Re:= [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
<= BR>Hi Behcet,

On 2009/04/22, at 18:54, Behcet Sarikaya wrote:
> Hi Ryuji,
>  So you are going to define a C-Flag?

M= CoA does not have such flag. What are you referring to?

regards,
= ryuji

> I am OK with it. But I don't understand why the only righ= t place is your draft. My idea is that the right place for such a thing is = 3775bis as this would avoid people with drafts not related to MCoA having t= o refer to MCoA draft.
>
> Regards,
>
> Behcet
>
> = From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
&= gt; To: Behcet Sarikaya <sarikaya@ieee.org>
> Cc: mext <<= A href=3D"mailto:mext@ietf.org" ymailto=3D"mailto:mext@ietf.org">mext@ietf.= org>
> Sent: Wednesday, April 22, 2009 5:02:09 PM
> Subj= ect: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
= >
> Hi Behcet,
>
> On 2009/04/22, at 17:45, Behcet S= arikaya wrote:
>
> > Hi Ryuji,
> >  I checked= your draft. Again, I could not understand how you are sending a registrati= on BU at the home link as only an O-flag is defined in your draft which is = used for something else.
>
> Please see section 5.6.3
>
> >  As I mentioned to you, we discussed this related to dr= aft-premec-homelink and it seems like HA will reject such a BU unless somet= hing is done, I thought you were familiar with the discussions as it relate= s to your draft too. I am surprised.
>
> yes, I follow that di= scussion.
> RFC3775-bis should not include any additional features li= ke sending BU from the home link.
> We should define this in MCoA. On= ly if needed, draft-homelink can refer to MCoA for this feature.
> > regards,
> ryuji
>
>
>
>
> <= BR>>
> >
> > Regards,
> >
> > Behce= t
> >
> > From: Ryuji Wakikawa <ryuji.w= akikawa@gmail..com>
> > To: Behcet Sarikaya <sarikaya@ieee.org>
> >= ; Cc: George Tsirtsis <tsirtsis@googlemail.com>; mext = <mext@= ietf.org>
> > Sent: Wednesday, April 22, 2009 4:18:28 PM> > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiple= coa-13.txt]
> >
> > Hi Behcet,
> >
> > = On 2009/04/22, at 11:31, Behcet Sarikaya wrote:
> >
> > &= gt;
> > >
> > > From: George Tsirtsis <tsirtsis@googlemail.com>
> > > To: Behcet Sarikaya &= lt;sarikaya@ieee..org>
> > > Cc: mext <mext@ietf.o= rg>
> > > Sent: Wednesday, April 22, 2009 10:10:08 AM> > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-mul= tiplecoa-13.txt]
> > >
> > > I do not think that ad= ding home link registration to RFC3775bis is feasible.
> > > Th= is requires logic in the MN and HA that is not directly compatible
> = > > to RFC3775. The aim of RFC3775bis is to make minimal changes for<= BR>> > > clarification reasons and to correct errors. Home Link Re= gistration as
> > > defined in MCoA is neither.
> > &g= t; [behcet] Why not? If it is needed in so many instances, that qualifies i= t to become a base protocol feature, at least to me.
> >
> &= gt; We cannot add a new feature to 3775. That is the ground rule of -bis. T= he chairs can clarify this.
> >
> > regards,
> > ryuji
> >
> >
> >
> > >
>= ; > > On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya
> > &= gt; <behcetsarikaya@yahoo.com> wrote:
> > &= gt; > Hi George,
> > > >  It seems in my previous re= ply I replied to this mail of yours which was
> > > > unrela= ted to the other mail you sent to which I was really replying,
> >= > > apologies.
> > > >  Now regarding home link = registration, what is the mechanism MCoA draft
> > > > uses?= Ryuji mentioned some H bit but I read the draft and couldn't confirm
&g= t; > > > it.
> > > >
> > > >  M= y suggestion was building on this, i.e. I suggested that whatever you
&g= t; > > > came up with can be moved to 3775bis so that other people would not have to
> > > > make normative references = to your draft.
> > > >
> > > > That's all.> > > >
> > > > Regards,
> > > >=
> > > > Behcet
> > > >
> > > >= ; ________________________________
> > > > From: George Tsir= tsis <tsirtsis@googlemail.com>
> > > > = To: Vijay Devarapalli <vijay@wichorus.com>
> > > >= ; Cc: Behcet Sarikaya <sarikaya@ieee.org>; mext <mext@ietf.org>> > > > Sent: Tuesday, April 21, 2009 2:14:55 PM
> >= > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-1= 3.txt]
> > > >
> > > > ...also wrt the home l= ink registration, I do not think what you
> > > > suggest is= necessary.
> > > >
> > > > As far as I see t= he other documents are informational, and they do not
> > > >= ; yet have a formal standing in the WG. If and when they do, as
> >= ; > > Informational documents,  they should not require normativ= e changes to
> > > > anything. They should make sure what th= ey describe (mostly
> > > > implementation options in this c= ase) are compatible not only with
> > > > RFC3775 but also w= ith extensions to it, including Flow Bindings. .
> > > >
= > > > >
> > > > Regards
> > > > G= eorge
> > > >
> > > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli <vijay@wichorus.com>
>= > > > wrote:
> > > >> Behcet,
> > >= >>
> > > >> Behcet Sarikaya wrote:
> > &g= t; >>>
> > > >>> *[behcet] Yes but each inter= face will appear to HA as a different device
> > > >>>= and HA needs to assign a different HoA. Then MCoA problem disappears.*
= > > > >>> *So George is saying that this is avoided by so= me virtual interfaces so
> > > >>> that HA does not se= e each interface separately. *
> > > >>> *Is this expl= ained anywhere in the draft?*
> > > >>> *If yes then I= am OK.*
> > > >>
> > > >> The home age= nt does not care about the multiple interfaces on the mobile
> > > >> node. It only sees the mobile node as one entity and al= locates a home
> > > >> address to it. The multiple care-= of addresses that the mobile node has
> > > >> will
&g= t; > > >> be used by the home agent as tunnel end points. That = is all. So there is
> > > >> no
> > > >>= ; issue.
> > > >>
> > > >> Vijay
>= ; > > >>
> > > >>>  >  Also I= have a question to Ryuji: does this draft send a
> > > >>= ;> non-deregistration BU at the home link? If yes, is he familiar with t= he
> > > >>> discussion going on on this subject? This= is another point of confusion
> > > >>> for
> &= gt; > >>> me.
> > > >>>
> > > = >>> This has been discussed for a long time in MEXT.
> > > >>> who is familiar with which discussion= s? I don't know your concern here.
> > > >>>  *[b= ehcet] So your answer is yes the draft sends a non-deregistration BU
>= ; > > >>> (kind of bulk registration) at the home link.*
= > > > >>> *The discussion I mentioned was related to
&= gt; > > >>> draft-premec-mext-extended-home-link. This draft= also sends
> > > >>> non-deregistration BU at the hom= e link. So does a few more drafts like
> > > >>> **dra= ft-devarapalli-mext-mipv6-home-link.*
> > > >>>
>= ; > > >>> **
> > > >>> *[behcet] You me= ntioned some bit is set but I could not understand which.
> > >= >>> One idea is since so many drafts need this, why not factor th= is out and
> > > >>> define whatever the mechanism to enable sending non-deregistration BU in
> > > >= ;>> 3775bis. What do you think about that?*
> > > >>= ;>
> > > >>> **
> > > >>>
&= gt; > > >>>  >  Sorry if I am too  much co= nfused
> > > >>>  > Please don't get me wrong,= I am not trying to slow down the progress
> > > >>> o= f
> > > >>> this document..
> > > >>= >
> > > >>> sure, but please explain your issue mor= e precisely.
> > > >>>
> > > >>> = thanks!
> > > >>> ryuji
> > > >>>=
> > > >>>  >
> > > >>>&n= bsp; > Regards,
> > > >>>  >
> > &= gt; >>>  > Behcet
> > > >>>  > From: marcelo bagnulo braun <marcelo@it.uc3m.e= s
> > > >>> <mailto:marcelo@it.uc3m.es>= >
> > > >>>  > To: mext <mext@ietf..org <= ;mailto:m= ext@ietf.org>>; Julien Laganier
> > > >>> &l= t;julien.laganier.ietf@googlemail..com=
> > > >>> <mailto:julien.laganier..ietf@googlemail.com>>; Jari Arkko
&g= t; > > >>> <jari.arkko@piuha.net <mailto:jari.arkko@= piuha.net>>
> > > >>>  > Sent: Tuesd= ay, April 21, 2009 11:03:05 AM
> > > >>>  > Su= bject: [MEXT] [Fwd: I-D
> > > >>> Action:draft-ietf-mo= nami6-multiplecoa-13.txt]
> > > >>>  >
>= > > >>>  > We have this new version of the MCOA doc= ument that addresses the
> > > >>> comments received, = including IESG review comments..
> > > >>>  > = To the best of my knowledge, the IESG is ok with the doc and ready for
&= gt; > > >>> publication..
> > > >>>&nbs= p; > I am planning to ask our AD to move forward in a week or so, so, if
> > > >>> you
> > > >>> have = comments on the document please provide them before the 1st of may.
>= > > >>>  >
> > > >>>  >= ; Regards, marcelo
> > > >>>  > (mcoa doc shep= herd)
> > > >>>  >
> > > >>&= gt;  > -------- Mensaje original --------
> > > >>= ;>  > Asunto:    [MEXT] I-D Action:draft-ietf-monami6-= multiplecoa-13.txt
> > > >>>  > Fecha:  &= nbsp; Mon, 20 Apr 2009 08:30:01 -0700 (PDT)
> > > >>>&= nbsp; > De:    Internet-Drafts@ietf.org <m= ailto:Internet-Drafts@ietf.org>
> > > >>>  > Para:    i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
> > > >>= ;>  > CC:    mext@ietf.org <mailto:mext@ietf.org>
>= > > >>>  >
> > > >>>  >= ;
> > > >>>  >
> > > >>>&= nbsp; > A New Internet-Draft is available from the on-line Internet-Draf= ts
> > > >>> directories.
> > > >>&g= t;  > This draft is a work item of the Mobility EXTensions for IPv6= Working
> > > >>> Group of the IETF.
> > >= ; >>>  >
> > > >>>  >
> = > > >>>  >    Title      &n= bsp;   : Multiple Care-of Addresses Registration
> > > >= ;>>  >    Author(s)      : R. Wakika= wa, et al.
> > > >>>  >    Filename&= nbsp;       : draft-ietf-monami6-multiplecoa-13..txt
>= > > >>>  >    Pages      &= nbsp;   : 44
> > > >>>  >    Da= te            : 2009-04-20
> > > = >>>  >
> > > >>>  > According= to the current Mobile IPv6 specification, a mobile node may
> > &= gt; >>>  > have several care-of addresses, but only one, c= alled the primary
> > > >>>  > care-of address, that can be registered with its home agent and the
> > &= gt; >>>  > correspondent nodes.  However, for matters= of cost, bandwidth, delay,
> > > >>>  > etc, = it is useful for the mobile node to get Internet access through
> >= ; > >>>  > multiple accesses simultaneously, in which c= ase the mobile node would
> > > >>>  > be conf= igured with multiple active IPv6 care-of addresses..  This
> >= ; > >>>  > document proposes extensions to the Mobile I= Pv6 protocol to register
> > > >>>  > and use = multiple care-of addresses.  The extensions proposed in this
> &= gt; > >>>  > document can be used by Mobile Routers usi= ng the NEMO (Network
> > > >>>  > Mobility) Ba= sic Support protocol as well.
> > > >>>  >
> > > >>>  > A URL for this Internet-Dra= ft is:
> > > >>>  >
> > > >>= > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.= txt
> > > >>>  >
> > > >>>= ;  > Internet-Drafts are also available by anonymous FTP at:
>= ; > > >>>  > ftp://ftp.ietf.org/internet-drafts/
> &g= t; > >>>  >
> > > >>>  > B= elow is the data which will enable a MIME compliant mail reader
> >= ; > >>>  > implementation to automatically retrieve the= ASCII version of the
> > > >>>  > Internet-Dr= aft.
> > > >>>  >
> > > >>&g= t;  >
> > > >>>  >
> > > >>>  > _____________________________________________= __
> > > >>>  > MEXT mailing list
> >= > >>>  > MEXT@ietf.org <mailto:MEXT@ietf.org>
> >= > >>>  > https://www.ietf.org/mailman/listinfo/mext> > > >>>
> > > >>>
> > &g= t; >>>
> > > >>> ----------------------------= --------------------------------------------
> > > >>>=
> > > >>> ___________________________________________= ____
> > > >>> MEXT mailing list
> > > >= ;>> MEXT@ietf.org
> > > >&= gt;> https://www.ietf.org/mailman/listinfo/mext
> > > >&g= t;
> > > >> _____________________________________________= __
> > > >> MEXT mailing list
> > > >> = MEXT@ietf= ..org
> > > >> https://www.ietf.org/mailman/listinfo/mext<= /A>
> > > >>
> > > >
> > > >= ;
> > >
> > > _____________________________________= __________
> > > MEXT mailing list
> > > MEXT@ietf.org> > > https://www.ietf.org/mailman/listinfo/mext
> >= ;
> >
> >
>
>
>

<= br>=0A=0A=0A=0A --0-1104874104-1241549974=:22583-- From ryuji.wakikawa@gmail.com Tue May 5 12:21: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 A9C0C28C237 for ; Tue, 5 May 2009 12:21:41 -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 mjpldmOWdIQd for ; Tue, 5 May 2009 12:21:39 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id D9BF23A69ED for ; Tue, 5 May 2009 12:20:41 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so3204207rvb.49 for ; Tue, 05 May 2009 12:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=7cM9opuejG0pbo6xvCQ45ipjKYnmJFWiiTUkFo2sgg4=; b=uzW0v14CmnyX85ZBhosC/XzqlrUQP9nJOSwHG69dmQ7gDItcuPdbrhp+rsfdOxi+Pt JMQ+CL0TV0kOfou8EV+gV6oBlE9nuQGBOHoUo4R9DJcIRTyFp3X1wY5FtThy+8+g65wk NWvJhSuKi6V2pA3A73qHiMax1zZA0TlJ90mWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=XpNiUQi7DLoL2WGnoljvMO/UJ+hqBeoiL0xTrEsrXs6qmixj0FWuEdmjDGS4IrqO+F l+4laVlFmDTHRIHXV/lawDffLexaEcr4pjQwvxRQzIywgwOIRSmZfDOnDpoLQMWEvl77 ofry9J7jkjwIEEbtHneJIaq0uB8IPjDzOCOp0= Received: by 10.140.247.11 with SMTP id u11mr27040rvh.247.1241551327200; Tue, 05 May 2009 12:22:07 -0700 (PDT) Received: from ?192.168.110.115? ([206.132.173.18]) by mx.google.com with ESMTPS id g14sm19026892rvb.2.2009.05.05.12.22.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 12:22:06 -0700 (PDT) From: Ryuji Wakikawa To: Behcet Sarikaya In-Reply-To: <623252.22583.qm@web111404.mail.gq1.yahoo.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> <375902.20727.qm@web111403.mail.gq1.yahoo.com> <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> <222821.303.qm@web111407.mail.gq1.yahoo.com> <954696.84777.qm@web111411.mail.gq1.yahoo.com> <623252.22583.qm@web111404.mail.gq1.yahoo.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 5 May 2009 12:21:57 -0700 X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.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: Tue, 05 May 2009 19:21:41 -0000 Hi Behcet, Do you mean we need more general flag across different extensions? (ex. defining flag in BU?) We need H flag for the purpose of MCoA. This is why we have this flag in our mobility option. regards, ryuji On 2009/05/05, at 11:59, Behcet Sarikaya wrote: > Hi Ryuji, > It seems that MCoA draft uses the H flag defined in the base spec. > I don't think that is the right flag to use for the purpose of > sending a non-deregistration BU at the home link. > > Regards, > > Behcet > From: Ryuji Wakikawa > To: Behcet Sarikaya > Cc: mext > Sent: Saturday, April 25, 2009 3:32:33 AM > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > Hi Behcet, > > On 2009/04/22, at 18:54, Behcet Sarikaya wrote: > > > Hi Ryuji, > > So you are going to define a C-Flag? > > MCoA does not have such flag. What are you referring to? > > regards, > ryuji > > > I am OK with it. But I don't understand why the only right place > is your draft. My idea is that the right place for such a thing is > 3775bis as this would avoid people with drafts not related to MCoA > having to refer to MCoA draft. > > > > Regards, > > > > Behcet > > > > From: Ryuji Wakikawa > > To: Behcet Sarikaya > > Cc: mext > > Sent: Wednesday, April 22, 2009 5:02:09 PM > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > Hi Behcet, > > > > On 2009/04/22, at 17:45, Behcet Sarikaya wrote: > > > > > Hi Ryuji, > > > I checked your draft. Again, I could not understand how you are > sending a registration BU at the home link as only an O-flag is > defined in your draft which is used for something else. > > > > Please see section 5.6.3 > > > > > As I mentioned to you, we discussed this related to draft- > premec-homelink and it seems like HA will reject such a BU unless > something is done, I thought you were familiar with the discussions > as it relates to your draft too. I am surprised. > > > > yes, I follow that discussion. > > RFC3775-bis should not include any additional features like > sending BU from the home link. > > We should define this in MCoA. Only if needed, draft-homelink can > refer to MCoA for this feature. > > > > regards, > > ryuji > > > > > > > > > > > > > > > > > > Regards, > > > > > > Behcet > > > > > > From: Ryuji Wakikawa > > > To: Behcet Sarikaya > > > Cc: George Tsirtsis ; mext > > > > Sent: Wednesday, April 22, 2009 4:18:28 PM > > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > > > Hi Behcet, > > > > > > On 2009/04/22, at 11:31, Behcet Sarikaya wrote: > > > > > > > > > > > > > > > From: George Tsirtsis > > > > To: Behcet Sarikaya > > > > Cc: mext > > > > Sent: Wednesday, April 22, 2009 10:10:08 AM > > > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > > > > > I do not think that adding home link registration to > RFC3775bis is feasible. > > > > This requires logic in the MN and HA that is not directly > compatible > > > > to RFC3775. The aim of RFC3775bis is to make minimal changes for > > > > clarification reasons and to correct errors. Home Link > Registration as > > > > defined in MCoA is neither. > > > > [behcet] Why not? If it is needed in so many instances, that > qualifies it to become a base protocol feature, at least to me. > > > > > > We cannot add a new feature to 3775. That is the ground rule of - > bis. The chairs can clarify this. > > > > > > regards, > > > ryuji > > > > > > > > > > > > > > > > > On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya > > > > wrote: > > > > > Hi George, > > > > > It seems in my previous reply I replied to this mail of > yours which was > > > > > unrelated to the other mail you sent to which I was really > replying, > > > > > apologies. > > > > > Now regarding home link registration, what is the mechanism > MCoA draft > > > > > uses? Ryuji mentioned some H bit but I read the draft and > couldn't confirm > > > > > it. > > > > > > > > > > My suggestion was building on this, i.e. I suggested that > whatever you > > > > > came up with can be moved to 3775bis so that other people > would not have to > > > > > make normative references to your draft. > > > > > > > > > > That's all. > > > > > > > > > > Regards, > > > > > > > > > > Behcet > > > > > > > > > > ________________________________ > > > > > From: George Tsirtsis > > > > > To: Vijay Devarapalli > > > > > Cc: Behcet Sarikaya ; mext > > > > > Sent: Tuesday, April 21, 2009 2:14:55 PM > > > > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > > > > > > > ...also wrt the home link registration, I do not think what > you > > > > > suggest is necessary. > > > > > > > > > > As far as I see the other documents are informational, and > they do not > > > > > yet have a formal standing in the WG. If and when they do, as > > > > > Informational documents, they should not require normative > changes to > > > > > anything. They should make sure what they describe (mostly > > > > > implementation options in this case) are compatible not only > with > > > > > RFC3775 but also with extensions to it, including Flow > Bindings. . > > > > > > > > > > > > > > > Regards > > > > > George > > > > > > > > > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli > > > > > > wrote: > > > > >> Behcet, > > > > >> > > > > >> Behcet Sarikaya wrote: > > > > >>> > > > > >>> *[behcet] Yes but each interface will appear to HA as a > different device > > > > >>> and HA needs to assign a different HoA. Then MCoA problem > disappears.* > > > > >>> *So George is saying that this is avoided by some virtual > interfaces so > > > > >>> that HA does not see each interface separately. * > > > > >>> *Is this explained anywhere in the draft?* > > > > >>> *If yes then I am OK.* > > > > >> > > > > >> The home agent does not care about the multiple interfaces > on the mobile > > > > >> node. It only sees the mobile node as one entity and > allocates a home > > > > >> address to it. The multiple care-of addresses that the > mobile node has > > > > >> will > > > > >> be used by the home agent as tunnel end points. That is > all. So there is > > > > >> no > > > > >> issue. > > > > >> > > > > >> Vijay > > > > >> > > > > >>> > Also I have a question to Ryuji: does this draft send a > > > > >>> non-deregistration BU at the home link? If yes, is he > familiar with the > > > > >>> discussion going on on this subject? This is another point > of confusion > > > > >>> for > > > > >>> me. > > > > >>> > > > > >>> This has been discussed for a long time in MEXT. > > > > >>> who is familiar with which discussions? I don't know your > concern here. > > > > >>> *[behcet] So your answer is yes the draft sends a non- > deregistration BU > > > > >>> (kind of bulk registration) at the home link.* > > > > >>> *The discussion I mentioned was related to > > > > >>> draft-premec-mext-extended-home-link. This draft also sends > > > > >>> non-deregistration BU at the home link. So does a few more > drafts like > > > > >>> **draft-devarapalli-mext-mipv6-home-link.* > > > > >>> > > > > >>> ** > > > > >>> *[behcet] You mentioned some bit is set but I could not > understand which. > > > > >>> One idea is since so many drafts need this, why not factor > this out and > > > > >>> define whatever the mechanism to enable sending non- > deregistration BU in > > > > >>> 3775bis. What do you think about that?* > > > > >>> > > > > >>> ** > > > > >>> > > > > >>> > Sorry if I am too much confused > > > > >>> > Please don't get me wrong, I am not trying to slow down > the progress > > > > >>> of > > > > >>> this document.. > > > > >>> > > > > >>> sure, but please explain your issue more precisely. > > > > >>> > > > > >>> thanks! > > > > >>> ryuji > > > > >>> > > > > >>> > > > > > >>> > Regards, > > > > >>> > > > > > >>> > Behcet > > > > >>> > From: marcelo bagnulo braun > > > >>> > > > > > >>> > To: mext >; > Julien Laganier > > > > >>> > > > >>> >; Jari Arkko > > > > >>> > > > > > >>> > Sent: Tuesday, April 21, 2009 11:03:05 AM > > > > >>> > Subject: [MEXT] [Fwd: I-D > > > > >>> Action:draft-ietf-monami6-multiplecoa-13.txt] > > > > >>> > > > > > >>> > We have this new version of the MCOA document that > addresses the > > > > >>> comments received, including IESG review comments.. > > > > >>> > To the best of my knowledge, the IESG is ok with the > doc and ready for > > > > >>> publication.. > > > > >>> > I am planning to ask our AD to move forward in a week > or so, so, if > > > > >>> you > > > > >>> have comments on the document please provide them before > the 1st of may. > > > > >>> > > > > > >>> > Regards, marcelo > > > > >>> > (mcoa doc shepherd) > > > > >>> > > > > > >>> > -------- Mensaje original -------- > > > > >>> > Asunto: [MEXT] I-D Action:draft-ietf-monami6- > multiplecoa-13.txt > > > > >>> > Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > > > > >>> > De: Internet-Drafts@ietf.org > > > > > >>> > Para: i-d-announce@ietf.org > > > > > >>> > CC: mext@ietf.org > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > 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 : Multiple Care-of Addresses > Registration > > > > >>> > Author(s) : R. Wakikawa, et al. > > > > >>> > Filename : draft-ietf-monami6- > multiplecoa-13..txt > > > > >>> > Pages : 44 > > > > >>> > Date : 2009-04-20 > > > > >>> > > > > > >>> > According to the current Mobile IPv6 specification, a > mobile node may > > > > >>> > have several care-of addresses, but only one, called > the primary > > > > >>> > care-of address, that can be registered with its home > agent and the > > > > >>> > correspondent nodes. However, for matters of cost, > bandwidth, delay, > > > > >>> > etc, it is useful for the mobile node to get Internet > access through > > > > >>> > multiple accesses simultaneously, in which case the > mobile node would > > > > >>> > be configured with multiple active IPv6 care-of > addresses.. This > > > > >>> > document proposes extensions to the Mobile IPv6 > protocol to register > > > > >>> > and use multiple care-of addresses. The extensions > proposed in this > > > > >>> > document can be used by Mobile Routers using the NEMO > (Network > > > > >>> > Mobility) Basic Support protocol as well. > > > > >>> > > > > > >>> > A URL for this Internet-Draft is: > > > > >>> > > > > > >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.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. > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > _______________________________________________ > > > > >>> > 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 May 5 12:52: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 E14323A71C8 for ; Tue, 5 May 2009 12:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4GohI0BtuoxY for ; Tue, 5 May 2009 12:52:12 -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 691ED3A6C47 for ; Tue, 5 May 2009 12:52:12 -0700 (PDT) Received: (qmail 82130 invoked by uid 60001); 5 May 2009 19:53:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241553217; bh=LLCmi0Zh+CZQ60e/O245rSiucQ7+YiIk4Mqm0L1JAww=; 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=AQ5MxJDwsEfpbVQQYqdah97lTduHJVKHPZBvgS7oTgcaIat3e07fb5DOJBXiMGpOsJ9Bm7jk4IxO+iSjJE52TCZMPsx3C0vgNXzAuKzSp1c4E72wlDtmmmAYRBUTNFpuj1RHxT0FmALPfq7+lLLeaXU4Ba8XHP99IvAsTlqxfzE= 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=Ob0/NaeRGnCa9x6yKBQrFhYI2f1qOsOOuXpk5NF4rbSTc2WzVDzgLjE1jjZ4AWH8XiCZCaISueiZ2hV9n0VsBMTr2hFnwJNxSH3GLhBt9/CYyume7KMyY2KTSdbj9JX9CvxojabDEc4s+eZP5BPfnkxi/dS0IPZp7PAbwzG9Sh4=; Message-ID: <473265.14909.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: IOwMJyIVM1mvtXvf3KPtFxLjJFtowF.34aeUs2AMzEpJN2rSTIN7FEBIQfht5UdAlEYfym02pehFDzL0zq6mdpbnvDeHIDS6FXuBNl1uuFs7Rx2whCcG45oO8l0DKNyZ1uA46_X1XsSw6JhgFuiAYsLUjCv2sNgNdsKl1kz370Uq7GA_IJlKCSlMslTX.hQ7SNaLvW7iBYdghi3Fx3pO4Kjaz6wTTeZFT8L5bsXyDqSliVzxK9LW9DUTCPZrQtbCC3vsQ.79EW6GAa8- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 05 May 2009 12:53:37 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> <375902.20727.qm@web111403.mail.gq1.yahoo.com> <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> <222821.303.qm@web111407.mail.gq1.yahoo.com> <954696.84777.qm@web111411.mail.gq1.yahoo.com> <623252.22583.qm@web111404.mail.gq1.yahoo.com> Date: Tue, 5 May 2009 12:53:37 -0700 (PDT) From: Behcet Sarikaya To: Ryuji Wakikawa In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1915641658-1241553217=:14909" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.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: Tue, 05 May 2009 19:52:15 -0000 --0-1915641658-1241553217=:14909 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ryuji,=0APls see inline.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A__________= ______________________=0A=0AFrom: Ryuji Wakikawa = =0ATo: Behcet Sarikaya =0ACc: mext =0ASen= t: Tuesday, May 5, 2009 2:21:57 PM=0ASubject: Re: [MEXT] [Fwd: I-D Action:d= raft-ietf-monami6-multiplecoa-13.txt]=0A=0A=0A[behcet] Yes, I think so. Tha= t's why I suggested RFC 3775bis.=0A=0A=0AWe need H flag for the purpose of = MCoA. This is why we have this flag in our mobility option.=0A=0A[behcet] I= n Sec. 4.2 you show 10 flags but the only new one is the O flag. I think th= is is quite confusing. I suggest showing only the new flags. Otherwise it c= an be misunderstood like I first thought all 10 flags were being defined in= MCoA draft.=0A=0A=0Aregards,=0Aryuji=0A=0A=0AOn 2009/05/05, at 11:59, Behc= et Sarikaya wrote:=0A=0A> Hi Ryuji,=0A>=A0 It seems that MCoA draft uses th= e H flag defined in the base spec. I don't think that is the right flag to = use for the purpose of sending a non-deregistration BU at the home link.=0A= > =0A> Regards,=0A> =0A> Behcet=0A> From: Ryuji Wakikawa =0A> To: Behcet Sarikaya =0A> Cc: mext =0A> Sent: Saturday, April 25, 2009 3:32:33 AM=0A> Subject: Re: [MEXT= ] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> =0A> Hi Behce= t,=0A> =0A> On 2009/04/22, at 18:54, Behcet Sarikaya wrote:=0A> =0A> > Hi R= yuji,=0A> >=A0 So you are going to define a C-Flag?=0A> =0A> MCoA does not = have such flag. What are you referring to?=0A> =0A> regards,=0A> ryuji=0A> = =0A> > I am OK with it. But I don't understand why the only right place is = your draft. My idea is that the right place for such a thing is 3775bis as = this would avoid people with drafts not related to MCoA having to refer to = MCoA draft.=0A> >=0A> > Regards,=0A> >=0A> > Behcet=0A> >=0A> > From: Ryuji= Wakikawa =0A> > To: Behcet Sarikaya =0A> > Cc: mext =0A> > Sent: Wednesday, April 22, 200= 9 5:02:09 PM=0A> > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-= multiplecoa-13.txt]=0A> >=0A> > Hi Behcet,=0A> >=0A> > On 2009/04/22, at 17= :45, Behcet Sarikaya wrote:=0A> >=0A> > > Hi Ryuji,=0A> > >=A0 I checked yo= ur draft. Again, I could not understand how you are sending a registration = BU at the home link as only an O-flag is defined in your draft which is use= d for something else.=0A> >=0A> > Please see section 5.6.3=0A> >=0A> > >=A0= As I mentioned to you, we discussed this related to draft-premec-homelink = and it seems like HA will reject such a BU unless something is done, I thou= ght you were familiar with the discussions as it relates to your draft too.= I am surprised.=0A> >=0A> > yes, I follow that discussion.=0A> > RFC3775-b= is should not include any additional features like sending BU from the home= link.=0A> > We should define this in MCoA. Only if needed, draft-homelink = can refer to MCoA for this feature.=0A> >=0A> > regards,=0A> > ryuji=0A> >= =0A> >=0A> >=0A> >=0A> >=0A> >=0A> > >=0A> > > Regards,=0A> > >=0A> > > Beh= cet=0A> > >=0A> > > From: Ryuji Wakikawa =0A> > = > To: Behcet Sarikaya =0A> > > Cc: George Tsirtsis ; mext =0A> > > Sent: Wednesday, April 2= 2, 2009 4:18:28 PM=0A> > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-= monami6-multiplecoa-13.txt]=0A> > >=0A> > > Hi Behcet,=0A> > >=0A> > > On 2= 009/04/22, at 11:31, Behcet Sarikaya wrote:=0A> > >=0A> > > >=0A> > > >=0A>= > > > From: George Tsirtsis =0A> > > > To: Behcet= Sarikaya =0A> > > > Cc: mext =0A> > > >= Sent: Wednesday, April 22, 2009 10:10:08 AM=0A> > > > Subject: Re: [MEXT] = [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> > > >=0A> > > >= I do not think that adding home link registration to RFC3775bis is feasibl= e.=0A> > > > This requires logic in the MN and HA that is not directly comp= atible=0A> > > > to RFC3775. The aim of RFC3775bis is to make minimal chang= es for=0A> > > > clarification reasons and to correct errors. Home Link Reg= istration as=0A> > > > defined in MCoA is neither.=0A> > > > [behcet] Why n= ot? If it is needed in so many instances, that qualifies it to become a bas= e protocol feature, at least to me.=0A> > >=0A> > > We cannot add a new fea= ture to 3775. That is the ground rule of -bis. The chairs can clarify this.= =0A> > >=0A> > > regards,=0A> > > ryuji=0A> > >=0A> > >=0A> > >=0A> > > >= =0A> > > > On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya=0A> > > > wrote:=0A> > > > > Hi George,=0A> > > > >=A0 It seems= in my previous reply I replied to this mail of yours which was=0A> > > > >= unrelated to the other mail you sent to which I was really replying,=0A> >= > > > apologies.=0A> > > > >=A0 Now regarding home link registration, what= is the mechanism MCoA draft=0A> > > > > uses? Ryuji mentioned some H bit b= ut I read the draft and couldn't confirm=0A> > > > > it.=0A> > > > >=0A> > = > > >=A0 My suggestion was building on this, i.e. I suggested that whatever= you=0A> > > > > came up with can be moved to 3775bis so that other people = would not have to=0A> > > > > make normative references to your draft.=0A> = > > > >=0A> > > > > That's all.=0A> > > > >=0A> > > > > Regards,=0A> > > > = >=0A> > > > > Behcet=0A> > > > >=0A> > > > > ______________________________= __=0A> > > > > From: George Tsirtsis =0A> > > > > = To: Vijay Devarapalli =0A> > > > > Cc: Behcet Sarikaya = ; mext =0A> > > > > Sent: Tuesday, April = 21, 2009 2:14:55 PM=0A> > > > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-= ietf-monami6-multiplecoa-13.txt]=0A> > > > >=0A> > > > > ...also wrt the ho= me link registration, I do not think what you=0A> > > > > suggest is necess= ary.=0A> > > > >=0A> > > > > As far as I see the other documents are inform= ational, and they do not=0A> > > > > yet have a formal standing in the WG. = If and when they do, as=0A> > > > > Informational documents,=A0 they should= not require normative changes to=0A> > > > > anything. They should make su= re what they describe (mostly=0A> > > > > implementation options in this ca= se) are compatible not only with=0A> > > > > RFC3775 but also with extensio= ns to it, including Flow Bindings. .=0A> > > > >=0A> > > > >=0A> > > > > Re= gards=0A> > > > > George=0A> > > > >=0A> > > > > On Tue, Apr 21, 2009 at 7:= 58 PM, Vijay Devarapalli =0A> > > > > wrote:=0A> > > > = >> Behcet,=0A> > > > >>=0A> > > > >> Behcet Sarikaya wrote:=0A> > > > >>>= =0A> > > > >>> *[behcet] Yes but each interface will appear to HA as a diff= erent device=0A> > > > >>> and HA needs to assign a different HoA. Then MCo= A problem disappears.*=0A> > > > >>> *So George is saying that this is avoi= ded by some virtual interfaces so=0A> > > > >>> that HA does not see each i= nterface separately. *=0A> > > > >>> *Is this explained anywhere in the dra= ft?*=0A> > > > >>> *If yes then I am OK.*=0A> > > > >>=0A> > > > >> The hom= e agent does not care about the multiple interfaces on the mobile=0A> > > >= >> node. It only sees the mobile node as one entity and allocates a home= =0A> > > > >> address to it. The multiple care-of addresses that the mobile= node has=0A> > > > >> will=0A> > > > >> be used by the home agent as tunne= l end points. That is all. So there is=0A> > > > >> no=0A> > > > >> issue.= =0A> > > > >>=0A> > > > >> Vijay=0A> > > > >>=0A> > > > >>>=A0 >=A0 Also I = have a question to Ryuji: does this draft send a=0A> > > > >>> non-deregist= ration BU at the home link? If yes, is he familiar with the=0A> > > > >>> d= iscussion going on on this subject? This is another point of confusion=0A> = > > > >>> for=0A> > > > >>> me.=0A> > > > >>>=0A> > > > >>> This has been d= iscussed for a long time in MEXT.=0A> > > > >>> who is familiar with which = discussions? I don't know your concern here.=0A> > > > >>>=A0 *[behcet] So = your answer is yes the draft sends a non-deregistration BU=0A> > > > >>> (k= ind of bulk registration) at the home link.*=0A> > > > >>> *The discussion = I mentioned was related to=0A> > > > >>> draft-premec-mext-extended-home-li= nk. This draft also sends=0A> > > > >>> non-deregistration BU at the home l= ink. So does a few more drafts like=0A> > > > >>> **draft-devarapalli-mext-= mipv6-home-link.*=0A> > > > >>>=0A> > > > >>> **=0A> > > > >>> *[behcet] Yo= u mentioned some bit is set but I could not understand which.=0A> > > > >>>= One idea is since so many drafts need this, why not factor this out and=0A= > > > > >>> define whatever the mechanism to enable sending non-deregistrat= ion BU in=0A> > > > >>> 3775bis. What do you think about that?*=0A> > > > >= >>=0A> > > > >>> **=0A> > > > >>>=0A> > > > >>>=A0 >=A0 Sorry if I am too= =A0 much confused=0A> > > > >>>=A0 > Please don't get me wrong, I am not tr= ying to slow down the progress=0A> > > > >>> of=0A> > > > >>> this document= ..=0A> > > > >>>=0A> > > > >>> sure, but please explain your issue more pre= cisely.=0A> > > > >>>=0A> > > > >>> thanks!=0A> > > > >>> ryuji=0A> > > > >= >>=0A> > > > >>>=A0 >=0A> > > > >>>=A0 > Regards,=0A> > > > >>>=A0 >=0A> > = > > >>>=A0 > Behcet=0A> > > > >>>=A0 > From: marcelo bagnulo braun > > > >>> >=0A> > > > >>>=A0 > T= o: mext >; Julien Laganier=0A> > > > = >>> > > > >>> >; Jari Arkko=0A> > > > >>> >=0A> > > > >>>=A0 > Sent: Tuesday, April 21,= 2009 11:03:05 AM=0A> > > > >>>=A0 > Subject: [MEXT] [Fwd: I-D=0A> > > > >>= > Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> > > > >>>=A0 >=0A> > > = > >>>=A0 > We have this new version of the MCOA document that addresses the= =0A> > > > >>> comments received, including IESG review comments..=0A> > > = > >>>=A0 > To the best of my knowledge, the IESG is ok with the doc and rea= dy for=0A> > > > >>> publication..=0A> > > > >>>=A0 > I am planning to ask = our AD to move forward in a week or so, so, if=0A> > > > >>> you=0A> > > > = >>> have comments on the document please provide them before the 1st of may= .=0A> > > > >>>=A0 >=0A> > > > >>>=A0 > Regards, marcelo=0A> > > > >>>=A0 >= (mcoa doc shepherd)=0A> > > > >>>=A0 >=0A> > > > >>>=A0 > -------- Mensaje= original --------=0A> > > > >>>=A0 > Asunto:=A0 =A0 [MEXT] I-D Action:draf= t-ietf-monami6-multiplecoa-13.txt=0A> > > > >>>=A0 > Fecha:=A0 =A0 Mon, 20 = Apr 2009 08:30:01 -0700 (PDT)=0A> > > > >>>=A0 > De:=A0 =A0 Internet-Drafts= @ietf.org =0A> > > > >>>=A0 > Para:=A0 =A0= i-d-announce@ietf.org =0A> > > > >>>=A0 > CC= :=A0 =A0 mext@ietf.org =0A> > > > >>>=A0 >=0A> > > > = >>>=A0 >=0A> > > > >>>=A0 >=0A> > > > >>>=A0 > A New Internet-Draft is avai= lable from the on-line Internet-Drafts=0A> > > > >>> directories.=0A> > > >= >>>=A0 > This draft is a work item of the Mobility EXTensions for IPv6 Wor= king=0A> > > > >>> Group of the IETF.=0A> > > > >>>=A0 >=0A> > > > >>>=A0 >= =0A> > > > >>>=A0 >=A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : Multiple Care-of Addr= esses Registration=0A> > > > >>>=A0 >=A0 =A0 Author(s)=A0 =A0 =A0 : R. Waki= kawa, et al.=0A> > > > >>>=A0 >=A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf= -monami6-multiplecoa-13..txt=0A> > > > >>>=A0 >=A0 =A0 Pages=A0 =A0 =A0 =A0= =A0 : 44=0A> > > > >>>=A0 >=A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2009-04-2= 0=0A> > > > >>>=A0 >=0A> > > > >>>=A0 > According to the current Mobile IPv= 6 specification, a mobile node may=0A> > > > >>>=A0 > have several care-of = addresses, but only one, called the primary=0A> > > > >>>=A0 > care-of addr= ess, that can be registered with its home agent and the=0A> > > > >>>=A0 > = correspondent nodes.=A0 However, for matters of cost, bandwidth, delay,=0A>= > > > >>>=A0 > etc, it is useful for the mobile node to get Internet acces= s through=0A> > > > >>>=A0 > multiple accesses simultaneously, in which cas= e the mobile node would=0A> > > > >>>=A0 > be configured with multiple acti= ve IPv6 care-of addresses..=A0 This=0A> > > > >>>=A0 > document proposes ex= tensions to the Mobile IPv6 protocol to register=0A> > > > >>>=A0 > and use= multiple care-of addresses.=A0 The extensions proposed in this=0A> > > > >= >>=A0 > document can be used by Mobile Routers using the NEMO (Network=0A> = > > > >>>=A0 > Mobility) Basic Support protocol as well.=0A> > > > >>>=A0 >= =0A> > > > >>>=A0 > A URL for this Internet-Draft is:=0A> > > > >>>=A0 >=0A= > > > > >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiple= coa-13.txt=0A> > > > >>>=A0 >=0A> > > > >>>=A0 > Internet-Drafts are also a= vailable by anonymous FTP at:=0A> > > > >>>=A0 > ftp://ftp.ietf.org/interne= t-drafts/=0A> > > > >>>=A0 >=0A> > > > >>>=A0 > Below is the data which wil= l enable a MIME compliant mail reader=0A> > > > >>>=A0 > implementation to = automatically retrieve the ASCII version of the=0A> > > > >>>=A0 > Internet= -Draft.=0A> > > > >>>=A0 >=0A> > > > >>>=A0 >=0A> > > > >>>=A0 >=0A> > > > = >>>=A0 > _______________________________________________=0A> > > > >>>=A0 >= MEXT mailing list=0A> > > > >>>=A0 > MEXT@ietf.org = =0A> > > > >>>=A0 > https://www.ietf.org/mailman/listinfo/mext=0A> > > > >>= >=0A> > > > >>>=0A> > > > >>>=0A> > > > >>> -------------------------------= -----------------------------------------=0A> > > > >>>=0A> > > > >>> _____= __________________________________________=0A> > > > >>> MEXT mailing list= =0A> > > > >>> MEXT@ietf.org=0A> > > > >>> https://www.ietf.org/mailman/lis= tinfo/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> > > > 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=0A=0AHi Behcet,=0A=0ADo you mean we need more general = flag across different extensions? (ex. defining flag in BU?)=0A=0A=0A --0-1915641658-1241553217=:14909 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ryuji,
=0A
Pls see inline.
=0A
&n= bsp;
=0A
Regards,
=0A
 
=0A
Behcet
=0A

=0A
=0A
=0A
= =0A
From: Ryuji Wakikawa <= ryuji.wakikawa@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext <mext@ietf.org>
Sent: Tuesday, May 5, 2009 2:21:57 PM
= Subject: Re: [MEXT] [Fwd: I= -D Action:draft-ietf-monami6-multiplecoa-13.txt]

Hi Behcet,
Do you mean we need more general flag across different extensions? (e= x. defining flag in BU?)
=0A
 
=0A
[behcet] Yes, I think so. That's why I suggested RFC 3775bis.
=0A
 
=0A

We need H flag for the purpose of MCoA. This i= s why we have this flag in our mobility option.
=0A
[behcet] In Sec. 4.2 you show 10 flags but the only new one i= s the O flag. I think this is quite confusing. I suggest showing only the n= ew flags. Otherwise it can be misunderstood like I first thought all 10 fla= gs were being defined in MCoA draft.
=0A
 
=0A=
<= BR>regards,
ryuji


On 2009/05/05, at 11:59, Behcet Sarikaya wr= ote:

> Hi Ryuji,
>  It seems that MCoA draft uses the = H flag defined in the base spec. I don't think that is the right flag to us= e for the purpose of sending a non-deregistration BU at the home link.
&= gt;
> Regards,
>
> Behcet
> From: Ryuji Wakikawa = <ryuji.wakikawa@gmail.com>
> To: Behcet Sarika= ya <sarikaya@ieee.org>
> Cc: mext <mext@ietf.org>
> S= ent: Saturday, April 25, 2009 3:32:33 AM
> Subject: Re: [MEXT] [Fwd: = I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>
> Hi Behcet,
>
> On 2009/04/22, at 18:54, Behcet Sarikaya wrote:>
> > Hi Ryuji,
> >  So you are going to defin= e a C-Flag?
>
> MCoA does not have such flag. What are you ref= erring to?
>
> regards,
> ryuji
>
> > I = am OK with it. But I don't understand why the only right place is your draf= t. My idea is that the right place for such a thing is 3775bis as this woul= d avoid people with drafts not related to MCoA having to refer to MCoA draf= t.
> >
> > Regards,
> >
> > Behcet
&= gt; >
> > From: Ryuji Wakikawa <ryuji.wakikawa@= gmail.com>
> > To: Behcet Sarikaya <sarikaya@ieee.org= >
> > Cc: mext <mext@ietf.org>
> > Sent: = Wednesday, April 22, 2009 5:02:09 PM
> > Subject: Re: [MEXT] [Fwd:= I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
> >
> >= ; Hi Behcet,
> >
> > On 2009/04/22, at 17:45, Behcet Sari= kaya wrote:
> >
> > > Hi Ryuji,
> > > = ; I checked your draft. Again, I could not understand how you are sending a= registration BU at the home link as only an O-flag is defined in your draf= t which is used for something else.
> >
> > Please see se= ction 5.6.3
> >
> > >  As I mentioned to you, we = discussed this related to draft-premec-homelink and it seems like HA will r= eject such a BU unless something is done, I thought you were familiar with = the discussions as it relates to your draft too. I am surprised.
> &g= t;
> > yes, I follow that discussion.
> > RFC3775-bis should not include any additional features like sending BU fro= m the home link.
> > We should define this in MCoA. Only if needed= , draft-homelink can refer to MCoA for this feature.
> >
> &= gt; regards,
> > ryuji
> >
> >
> >
&= gt; >
> >
> >
> > >
> > > Rega= rds,
> > >
> > > Behcet
> > >
> &= gt; > From: Ryuji Wakikawa <ryuji.wakikawa@gmail..com<= /A>>
> > > To: Behcet Sarikaya <sarikaya@ieee.org><= BR>> > > Cc: George Tsirtsis <tsirtsis@googlemail.co= m>; mext <mext@ietf.org>
> > > S= ent: Wednesday, April 22, 2009 4:18:28 PM
> > > Subject: Re: [M= EXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
> > &= gt;
> > > Hi Behcet,
> > >
> > > On 200= 9/04/22, at 11:31, Behcet Sarikaya wrote:
> > >
> > &g= t; >
> > > >
> > > > From: George Tsirtsis= <tsirtsis@googlemail.com>
> > > > To: = Behcet Sarikaya <sarikaya@ieee..org>
> > > > Cc: = mext <= mext@ietf.org>
> > > > Sent: Wednesday, April 22, 200= 9 10:10:08 AM
> > > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
> > > >
&g= t; > > > I do not think that adding home link registration to RFC3= 775bis is feasible.
> > > > This requires logic in the MN an= d HA that is not directly compatible
> > > > to RFC3775. The= aim of RFC3775bis is to make minimal changes for
> > > > cl= arification reasons and to correct errors. Home Link Registration as
>= ; > > > defined in MCoA is neither.
> > > > [behcet= ] Why not? If it is needed in so many instances, that qualifies it to becom= e a base protocol feature, at least to me.
> > >
> > &= gt; We cannot add a new feature to 3775. That is the ground rule of -bis. T= he chairs can clarify this.
> > >
> > > regards,> > > ryuji
> > >
> > >
> > >=
> > > >
> > > > On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya
> > > > <behcet= sarikaya@yahoo.com> wrote:
> > > > > Hi George,> > > > >  It seems in my previous reply I replied to = this mail of yours which was
> > > > > unrelated to the o= ther mail you sent to which I was really replying,
> > > > &= gt; apologies.
> > > > >  Now regarding home link re= gistration, what is the mechanism MCoA draft
> > > > > us= es? Ryuji mentioned some H bit but I read the draft and couldn't confirm> > > > > it.
> > > > >
> > >= > >  My suggestion was building on this, i.e. I suggested that = whatever you
> > > > > came up with can be moved to 3775b= is so that other people would not have to
> > > > > make normative references to your draft.
> > > > >
&g= t; > > > > That's all.
> > > > >
> >= > > > Regards,
> > > > >
> > > >= > Behcet
> > > > >
> > > > > ______= __________________________
> > > > > From: George Tsirtsi= s <tsirtsis@googlemail.com>
> > > > >= ; To: Vijay Devarapalli <vijay@wichorus.com>
> > >= > > Cc: Behcet Sarikaya <sarikaya@ieee.org>; mext <mext@ietf.org<= /A>>
> > > > > Sent: Tuesday, April 21, 2009 2:14:55 P= M
> > > > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami= 6-multiplecoa-13.txt]
> > > > >
> > > > &g= t; ...also wrt the home link registration, I do not think what you
> = > > > > suggest is necessary.
> > > > >
&g= t; > > > > As far as I see the other documents are informationa= l, and they do not
> > > > > yet have a formal standing i= n the WG. If and when they do, as
> > > > > Informational= documents,  they should not require normative changes to
> >= > > > anything. They should make sure what they describe (mostly<= BR>> > > > > implementation options in this case) are compat= ible not only with
> > > > > RFC3775 but also with extens= ions to it, including Flow Bindings. .
> > > > >
> = > > > >
> > > > > Regards
> > > > > George
> > > > >
> > > > &= gt; On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli <vijay@wichorus.= com>
> > > > > wrote:
> > > > >&= gt; Behcet,
> > > > >>
> > > > >>= Behcet Sarikaya wrote:
> > > > >>>
> > &g= t; > >>> *[behcet] Yes but each interface will appear to HA as = a different device
> > > > >>> and HA needs to assi= gn a different HoA. Then MCoA problem disappears.*
> > > > &= gt;>> *So George is saying that this is avoided by some virtual inter= faces so
> > > > >>> that HA does not see each inte= rface separately. *
> > > > >>> *Is this explained = anywhere in the draft?*
> > > > >>> *If yes then I am OK.*
> > > > >>
> > > > >> = The home agent does not care about the multiple interfaces on the mobile> > > > >> node. It only sees the mobile node as one ent= ity and allocates a home
> > > > >> address to it. The= multiple care-of addresses that the mobile node has
> > > >= >> will
> > > > >> be used by the home agent as= tunnel end points. That is all. So there is
> > > > >>= ; no
> > > > >> issue.
> > > > >>=
> > > > >> Vijay
> > > > >>
&= gt; > > > >>>  >  Also I have a question to = Ryuji: does this draft send a
> > > > >>> non-dereg= istration BU at the home link? If yes, is he familiar with the
> >= > > >>> discussion going on on this subject? This is another point of confusion
> > > > >>> for
>= > > > >>> me.
> > > > >>>
>= ; > > > >>> This has been discussed for a long time in ME= XT.
> > > > >>> who is familiar with which discussi= ons? I don't know your concern here.
> > > > >>>&nb= sp; *[behcet] So your answer is yes the draft sends a non-deregistration BU=
> > > > >>> (kind of bulk registration) at the hom= e link.*
> > > > >>> *The discussion I mentioned wa= s related to
> > > > >>> draft-premec-mext-extended= -home-link. This draft also sends
> > > > >>> non-d= eregistration BU at the home link. So does a few more drafts like
> &= gt; > > >>> **draft-devarapalli-mext-mipv6-home-link.*
&g= t; > > > >>>
> > > > >>> **
> > > > >>> *[behcet] You mentioned some bit is= set but I could not understand which.
> > > > >>> = One idea is since so many drafts need this, why not factor this out and
= > > > > >>> define whatever the mechanism to enable se= nding non-deregistration BU in
> > > > >>> 3775bis.= What do you think about that?*
> > > > >>>
>= > > > >>> **
> > > > >>>
>= > > > >>>  >  Sorry if I am too  much = confused
> > > > >>>  > Please don't get me= wrong, I am not trying to slow down the progress
> > > > &g= t;>> of
> > > > >>> this document..
> &= gt; > > >>>
> > > > >>> sure, but pl= ease explain your issue more precisely.
> > > > >>>
> > > > >>> thanks!
> > >= > >>> ryuji
> > > > >>>
> > &= gt; > >>>  >
> > > > >>>  = > Regards,
> > > > >>>  >
> > &= gt; > >>>  > Behcet
> > > > >>>=   > From: marcelo bagnulo braun <marcelo@it.uc3m.es
>= > > > >>> <mailto:marcelo@it.uc3m.es>>
= > > > > >>>  > To: mext <mext@ietf..org <ma= ilto:mext= @ietf.org>>; Julien Laganier
> > > > >>> = <julien.laganier.ietf@googlemail..com=
> > > > >>> <mailto:julien.laganier..ietf@googlemail.com>>; Jari Arkko
&= gt; > > > >>> <jari.arkko@piuha.net <mailt= o:jari.arkko@piuha.net>>
> > > > >>>=   > Sent: Tuesday, April 21, 2009 11:03:05 AM
> > > >= ; >>>  > Subject: [MEXT] [Fwd: I-D
> > > > = >>> Action:draft-ietf-monami6-multiplecoa-13.txt]
> > >= ; > >>>  >
> > > > >>>  &g= t; We have this new version of the MCOA document that addresses the
> >= > > >>> comments received, including IESG review comments..=
> > > > >>>  > To the best of my knowledge= , the IESG is ok with the doc and ready for
> > > > >>= > publication..
> > > > >>>  > I am plan= ning to ask our AD to move forward in a week or so, so, if
> > >= ; > >>> you
> > > > >>> have comments o= n the document please provide them before the 1st of may.
> > >= > >>>  >
> > > > >>>  >= ; Regards, marcelo
> > > > >>>  > (mcoa doc= shepherd)
> > > > >>>  >
> > >= > >>>  > -------- Mensaje original --------
> &g= t; > > >>>  > Asunto:    [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt
> > > > >&g= t;>  > Fecha:    Mon, 20 Apr 2009 08:30:01 -0700 (PDT)=
> > > > >>>  > De:    Internet-Drafts@ietf.org <mailto:Internet-Drafts@iet= f.org>
> > > > >>>  > Para:  &n= bsp; i-d-announce@ietf.org <mailto:i-d-announce@ietf.o= rg>
> > > > >>>  > CC:    = mext@ietf= .org <mailto:mext@ietf.org>
> > > &= gt; >>>  >
> > > > >>>  ><= BR>> > > > >>>  >
> > > > >&= gt;>  > A New Internet-Draft is available from the on-line Inter= net-Drafts
> > > > >>> directories.
> > &g= t; > >>>  > This draft is a work item of the Mobility E= XTensions for IPv6 Working
> > > > >>> Group of the= IETF.
> > > > >>>  >
> > > >= ; >>>  >
> > > > >>>  >&nb= sp;   Title          : Multiple Care-of Addre= sses Registration
> > > > >>>  >  &nbs= p; Author(s)      : R. Wakikawa, et al.
> > > &g= t; >>>  >    Filename        : draft-ietf-monami6-multiplecoa-13..txt
> > > > >= ;>>  >    Pages          := 44
> > > > >>>  >    Date  =           : 2009-04-20
> > > > >= >>  >
> > > > >>>  > Accordin= g to the current Mobile IPv6 specification, a mobile node may
> > = > > >>>  > have several care-of addresses, but only = one, called the primary
> > > > >>>  > care= -of address, that can be registered with its home agent and the
> >= ; > > >>>  > correspondent nodes.  However, for= matters of cost, bandwidth, delay,
> > > > >>>&nbs= p; > etc, it is useful for the mobile node to get Internet access throug= h
> > > > >>>  > multiple accesses simultaneously, in which case the mobile node would
> > > >= >>>  > be configured with multiple active IPv6 care-of ad= dresses..  This
> > > > >>>  > documen= t proposes extensions to the Mobile IPv6 protocol to register
> > = > > >>>  > and use multiple care-of addresses. = The extensions proposed in this
> > > > >>>  = > document can be used by Mobile Routers using the NEMO (Network
>= > > > >>>  > Mobility) Basic Support protocol as= well.
> > > > >>>  >
> > > >= ; >>>  > A URL for this Internet-Draft is:
> > &g= t; > >>>  >
> > > > >>> http://= www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt
> = > > > >>>  >
> > > > >>>  > Internet-Drafts are also available by anonymous FT= P at:
> > > > >>>  > ftp://ftp.ietf.org/internet-draft= s/
> > > > >>>  >
> > > >= ; >>>  > Below is the data which will enable a MIME compli= ant mail reader
> > > > >>>  > implementati= on to automatically retrieve the ASCII version of the
> > > >= ; >>>  > Internet-Draft.
> > > > >>&g= t;  >
> > > > >>>  >
> > &= gt; > >>>  >
> > > > >>>  = > _______________________________________________
> > > >= >>>  > MEXT mailing list
> > > > >>&= gt;  > MEXT@ietf.org <mailto:MEXT@ietf.org>=
> > > > >>>  > https://www.ietf.org/mailman/li= stinfo/mext
> > > > >>>
> > > > = >>>
> > > > >>>
> > > > >= ;>> -----------------------------------------------------------------= -------
> > > > >>>
> > > > >>= > _______________________________________________
> > > >= >>> MEXT mailing list
> > > > >>> MEXT@ietf.org
> > > > >>> https://www.ietf.org/mailman/listinfo/mext
> >= ; > > >>
> > > > >> ______________________= _________________________
> > > > >> MEXT mailing list=
> > > > >> MEXT@ietf..org
> > > > >&g= t; h= ttps://www.ietf.org/mailman/listinfo/mext
> > > > >&g= t;
> > > > >
> > > > >
> > >= ; >
> > > > _____________________________________________= __
> > > > MEXT mailing list
> > > > MEXT@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/mext
>= > >
> > >
> > >
> >
> >
>= >
>
>
>


=0A=0A=0A=0A = --0-1915641658-1241553217=:14909-- From tsirtsis@googlemail.com Tue May 5 13:24:59 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 39A4D3A6B45 for ; Tue, 5 May 2009 13:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.54 X-Spam-Level: X-Spam-Status: No, score=-1.54 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=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 3xX44Cu5hHz3 for ; Tue, 5 May 2009 13:24:57 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id AD6A83A6940 for ; Tue, 5 May 2009 13:24:56 -0700 (PDT) Received: by fxm2 with SMTP id 2so4954290fxm.37 for ; Tue, 05 May 2009 13:26:19 -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=C7COHY1/bwO8h3oPwabMoJgL2el8vMAh6ud+H4KrSI8=; b=vDKigOpbh9BLe/FCn5fBXD4x1U5JNfF9rK0GyNVOqkgXIlD/QpDtIY/3mCHXJwtYgJ LaZscVoS8G343Ic7p4IBbpSUcAfi41ovfZxzJKyn0PWayrgfGEkrC3+a+hJSv2usTmVJ n/q7Kld7YfFXiScInjrz24n5ZCgxvF4Ji2tW8= 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=sE3W4/5yEw+YhvdXKbTHMl0sAW9KkM55+X2AI9jMt5TBiFZQ7PUSrLOk8UmbTHqMUI JQf+G2plrcJ0t+GJBTfUtbrBsMMZfoQ8/M71QsdVJzVBhF8tX9kPk3rcDHRdLkB3R+ej jqloYszZLioW7q63jfM9P3vUkfMy57kl4IcDw= MIME-Version: 1.0 Received: by 10.223.126.69 with SMTP id b5mr115929fas.54.1241555178779; Tue, 05 May 2009 13:26:18 -0700 (PDT) In-Reply-To: <87ocu7v864.fsf@small.ssi.corp> References: <87ocu7v864.fsf@small.ssi.corp> Date: Tue, 5 May 2009 21:26:18 +0100 Message-ID: From: George Tsirtsis To: Arnaud Ebalard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF MEXT WG ML Subject: Re: [MEXT] Review of draft-ietf-mext-flow-binding-02 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, 05 May 2009 20:24:59 -0000 Hi Arnaud, Thanks for the review. I will look at your comments in more detail tomorrow when i will have more time but I wanted to respond to one thing below...see inline. On Tue, May 5, 2009 at 5:14 PM, Arnaud Ebalard wrote: > Hi, > > Below is a review of draft-ietf-mext-flow-binding-02. I think the > document is in pretty good shape and provides a good framework for flow > binding feature. > > The whole thing is bit difficult to read towards the end but I don't > think it's an editorial issue: the links and interactions between things > requires some attention and this is the end of the day here. In the end, > I won't state it would be difficult (or easy) to implement, but it will > clearly require to be careful. > > At the end of the reading, I wondered what will happen on a HA when it > will receive the first a BU of a MN that has just rebooted after a > crash. More precisely, I just want confirmation that there is no way for > some old flow to survive on the HA due to some specific values in the BU > (same CoA, BID, ...). > GT> I am not sure section 5.2 (last para) and 5.2.3 can be any clearer on t= his. According to these the MN MUST include all FIDs it wants to maintain in every BU, either as FID options or as part of an FIDSummary option. An MN that just rebooted will start from scratch and will not remember any of the FIDs it established earlier. A BU without any flow binding options will remove all FID state from the HA. Also note that RFC3775 discusses various issues WRT reboots and while RFC3775 is not specific about it, it does indicate that a combination of the seq.num and IPSEC state can be used to detect such cases. In any case for the purpose of this draft we are being very clear. If an MN "forgets" its FID state for any reason it will fail to refresh it appropriately and so it will be removed from the HA/CN. I hope this makes sense George > Cheers, > > a+ > >> 2. =C2=A0Introduction >> >> =C2=A0 =C2=A0Mobile IPv6 [RFC3775], DSMIPv6 [I-D.ietf-mext-nemo-v4traver= sal] and >> =C2=A0 =C2=A0Nemo Basic Support [RFC3963] allow a mobile node / mobile r= outer to >> =C2=A0 =C2=A0manage its mobility using the binding update message, which= binds one >> =C2=A0 =C2=A0care-of address to one home address. =C2=A0The binding upda= te message can >> =C2=A0 =C2=A0be sent to the home agent. =C2=A0In Mobile IPv6, the bindin= g update can >> =C2=A0 =C2=A0also be sent to correspondent node or to a mobility anchor = point (see >> =C2=A0 =C2=A0[RFC5380]). > > What about making one simple sentence from the last two sentences: > > =C2=A0 =C2=A0 The Binding Update message can be sent to the home agent, t= o a > =C2=A0 =C2=A0 correspondent node or to a mobility anchor point (see [RFC5= 380]). > >> =C2=A0 The semantics of the binding update are limited to =C2=A0care-of = address >> =C2=A0 changes. That is, [RFC3775], ... > > Would use 'primary care-of address changes' in order for the 'That is' > in the next sentence to be logical. > >> 3. =C2=A0Terminology > > Christian's proposal to improve that section looked fine. > >> 4. =C2=A0Mobile IPv6 Extensions >> >> =C2=A0 =C2=A0This section introduces extensions to Mobile IPv6 that are = necessary >> =C2=A0 =C2=A0for supporting the flow binding mechanism described in this= document. >> >> 4.1. =C2=A0Definition Update for Binding Identifier Mobility Option >> >> =C2=A0 =C2=A0This specification updates the definition of the Binding Id= entifier >> =C2=A0 =C2=A0Mobility option defined in [I-D.ietf-monami6-multiplecoa], = as >> =C2=A0 =C2=A0follows: >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 3 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 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 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 Type =3D TBD =C2=A0| =C2=A0 =C2=A0 Length =C2=A0 =C2=A0| >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 Binding ID (BID) =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 Status =C2=A0 =C2=A0|H| =C2=A0 BID-= PRI =C2=A0 | >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------= -------------------+ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 + >> =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 IPv4 or IPv6 care-of address (CoA) =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 + >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------------------------------------= -------------------+ >> >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 1: The Binding Id= entifier Mobility option >> >> >> >> =C2=A0 =C2=A0 =C2=A0 BID-PRI >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is a 7-bit field placing each BID= to a relative priority >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with other registered BIDs. =C2=A0Valu= e "0" is reserved for >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation of [I-D.ietf-monami6-mu= ltiplecoa] that do not >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0support this specification. =C2=A0A hi= gher number in this field >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0indicates lower priority, while BIDs w= ith the same BID-PRI >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value have equal priority. > > I may be missing something, but is there any reason not to use the Value > "0"? As a reserved field in draf-ietf-monami6-multiplecoa, it is not > expected to be considered by implementations that implement only > draf-ietf-monami6-multiplecoa (i.e. do not support flow-binding). > >> 4.2.1. =C2=A0Binding Reference Sub-option >> >> =C2=A0 =C2=A0This section introduces the Binding Reference sub-option, w= hich may >> =C2=A0 =C2=A0be included in the Flow identification option. =C2=A0The Bi= nding Reference >> =C2=A0 =C2=A0sub-option includes one or more BIDs defined in MCoA >> =C2=A0 =C2=A0[I-D.ietf-monami6-multiplecoa]. =C2=A0When this sub-option = is included in >> =C2=A0 =C2=A0the Flow identification option it associates the flow descr= ibed with >> =C2=A0 =C2=A0one or more registered BIDs. >> >> =C2=A0 =C2=A0The binding identifier option, defined in >> =C2=A0 =C2=A0[I-D.ietf-monami6-multiplecoa], registering a given BID whi= ch is then >> =C2=A0 =C2=A0indicated in the Binding Reference sub-option, MUST be eith= er defined >> =C2=A0 =C2=A0in the same or earlier BU from the one including the bindin= g >> =C2=A0 =C2=A0reference sub-option. =C2=A0The Binding Reference sub-optio= n is shown >> =C2=A0 =C2=A0below. >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 3 >> =C2=A0 =C2=A0 =C2=A0 =C2=A00 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 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0|Sub-opt Type =C2=A0 | =C2=A0Sub-Opt Len =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BID =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 BID =C2=A0........ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+- >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 3: The Bi= nding Reference sub-option >> >> >> =C2=A0 =C2=A0 =C2=A0 Sub-opt Type >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Indicates the Sub-option type. =C2=A0F= or the Binding Reference sub- >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option, this field MUST be set to 1. >> >> =C2=A0 =C2=A0 =C2=A0 Sub-opt Len >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Indicates the sub-option length in oct= ets. =C2=A0This field includes >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the entire length of the sub-option in= cluding the Sub-opt Type >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Sub-opt-Len fields. >> >> =C2=A0 =C2=A0 =C2=A0 BID >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The BID that the mobile node wants to = associate with the flow >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identification option. =C2=A0One or mo= re BID fields can be included >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in this sub-option. =C2=A0Since each B= ID is 2 byte long, the value >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the Sub-opt Len field indicates the= number of BIDs present. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Number of BIDs =3D (Sub-opt Len-2)/2. >> >> 4.2.2. =C2=A0Flow Description Sub-option >> >> =C2=A0 =C2=A0The Flow description sub-option(s) include the parameters u= sed to >> =C2=A0 =C2=A0match packets for a specific flow binding. >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 3 >> =C2=A0 =C2=A0 =C2=A0 =C2=A00 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 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0|Sub-opt Type =C2=A0 | =C2=A0Sub-Opt Len =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0Flow Description ... >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+ >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 4: = The Flow Description sub-option >> >> =C2=A0 =C2=A0 =C2=A0 Sub-opt Type >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Indicates the Sub-option type. =C2=A0F= or the flow description sub- >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option, this field SHOULD be set to on= e of the FD types defined >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0below. >> >> =C2=A0 =C2=A0 =C2=A0 Sub-opt Len >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Indicates the sub-option length in oct= ets. =C2=A0This field includes >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the entire length of the sub-option in= cluding the Sub-opt Type >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Sub-opt-Len fields. >> >> =C2=A0 =C2=A0 =C2=A0 Flow Description >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The flow description corresponding to = the type indicated by the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sub-opt Type field. =C2=A0Flow descrip= tion is out of scope of this >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0document. >> >> =C2=A0 =C2=A0The following values are reserved for the sub-option Type v= alues are >> =C2=A0 =C2=A0defined for Flow Description: > > =C2=A0 =C2=A0 That sentence looks strange. > >> =C2=A0 =C2=A0 =C2=A0 17-32 reserved for Flow Description formats. > >> 4.3. =C2=A0Flow Identification Summary Mobility Option >> >> =C2=A0 =C2=A0TBD >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 3 >> =C2=A0 =C2=A0 =C2=A0 =C2=A00 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 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0| Option Type =C2=A0 | =C2=A0Option Len =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FID =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 FID =C2=A0........ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+- >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 5: The Flow Ident= ification Summary Option >> >> =C2=A0 =C2=A0 =C2=A0 Option Type >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Indicates the Sub-option type. =C2=A0F= or the Binding Reference sub- >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option, this field MUST be set to 1. >> >> =C2=A0 =C2=A0 =C2=A0 Option Length >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Indicates the sub-option length in oct= ets. =C2=A0This field includes >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the entire length of the sub-option in= cluding the Sub-opt Type >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Sub-opt-Len fields. >> >> =C2=A0 =C2=A0 =C2=A0 FID >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A registered FID. =C2=A0One or more FI= D fields can be included in >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this option. =C2=A0Since each FID is 2= bytes long, the value of the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Option Len field indicates the number = of FIDs present. =C2=A0Number >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of FIDs =3D (Sub-opt Len-2)/2. > > This section looks like a copy of 4.2.1. > >> 4.4. =C2=A0Flow Bindings entries list and its relationship to Binding Ca= che >> >> =C2=A0 =C2=A0The conceptual mobile IPv6 binding cache was defined in [RF= C3775] to >> =C2=A0 =C2=A0identify the mobile IP state maintained by the mobile node,= home >> =C2=A0 =C2=A0agent, and corresponding node. =C2=A0The binding cache incl= udes, between > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s/between/among/ > >> =C2=A0 =C2=A0others, the mobile node's home address, the registered care= -of >> =C2=A0 =C2=A0address, and the lifetime of the binding. =C2=A0The binding= cache was then >> =C2=A0 =C2=A0extended by [I-D.ietf-monami6-multiplecoa] to include more = than one >> =C2=A0 =C2=A0care-of addresses and to associate each of them with a Bind= ing >> =C2=A0 =C2=A0Identifier (BID). >> >> =C2=A0 =C2=A0This specification does not change modify the mobile IPv6 b= inding > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^ >> =C2=A0 =C2=A0cache any further. >> >> =C2=A0 =C2=A0Flow bindings can be thought of as a conceptual list of ent= ries that >> =C2=A0 =C2=A0is separate from the binding cache. =C2=A0The flow bindings= list contains >> =C2=A0 =C2=A0an entry for each of the registered flow binding. =C2=A0Flo= w binding >> =C2=A0 =C2=A0entries can point to an entry in the binding cache by means= of the >> =C2=A0 =C2=A0BID. =C2=A0Each flow binding entry include the following pa= rameters : > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 includes > >> 5. =C2=A0Protocol operations >> >> 5.1. =C2=A0General >> >> =C2=A0 =C2=A0This specification introduces a flow bindings list of entri= es and an >> =C2=A0 =C2=A0ordered list of binding identifiers, allowing mobile nodes = to >> =C2=A0 =C2=A0associate flow binding policies with the registered care-of >> =C2=A0 =C2=A0addresses. >> >> =C2=A0 =C2=A0The flow identification option defines how the mobile node = can >> =C2=A0 =C2=A0control a set of flow binding entries maintained in a home = agent, >> =C2=A0 =C2=A0correspondent node, or mobility anchor points, on its behal= f. =C2=A0The >> =C2=A0 =C2=A0fields of the flow identification option are necessary for = ordering >> =C2=A0 =C2=A0flow identification options, indicating the sort of action = that >> =C2=A0 =C2=A0should be undertaken to the recipient's flow binding list o= f entries >> =C2=A0 =C2=A0or for carrying the results of such a petition. >> >> =C2=A0 =C2=A0This specification allows mobile nodes to direct flows to a >> =C2=A0 =C2=A0particular care-of address. =C2=A0The granularity of what c= onstitutes a >> =C2=A0 =C2=A0flow depends on the flow descriptor used. =C2=A0As indicate= d earlier the >> =C2=A0 =C2=A0flow description itself is defined in another document. > > =C2=A0 =C2=A0 As indicated earlier, various flow descriptions are specifi= ed in > =C2=A0 =C2=A0 external documents. > >> 5.2. =C2=A0Mobile Node Considerations >> >> =C2=A0 =C2=A0This specification allows the mobile node to maintain sever= al >> =C2=A0 =C2=A0bindings in its home agent and to direct packets to differe= nt care-of >> =C2=A0 =C2=A0addresses according to flow bindings. =C2=A0This section de= tails the >> =C2=A0 =C2=A0mobile node operations necessary to implement this specific= ation. >> >> =C2=A0 =C2=A0The home agent list of flow bindings is manipulated by the = mobile >> =C2=A0 =C2=A0node, via flow identification and flow summary options incl= uded in >> =C2=A0 =C2=A0binding update messages. =C2=A0Each flow binding update can= add, modify, >> =C2=A0 =C2=A0refresh, or delete a given binding. =C2=A0More than one flo= w >> =C2=A0 =C2=A0identification options MAY be included in the same binding = update but >> =C2=A0 =C2=A0each of them MUST include a different FID. =C2=A0In other w= ords, two flow >> =C2=A0 =C2=A0identification options in the same message can not be about= the same >> =C2=A0 =C2=A0flow binding. >> >> =C2=A0 =C2=A0All flow binding state MUST be refreshed in every binding u= pdate the >> =C2=A0 =C2=A0mobile node sends. =C2=A0Any previously registered flow bin= ding that is >> =C2=A0 =C2=A0not included in a given binding update will be deleted. =C2= =A0So, any flow >> =C2=A0 =C2=A0bindings that are not added or modified by a flow identific= ation >> =C2=A0 =C2=A0option, but have previously registered and need to be maint= ained > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 been registered > >> 5.2.1. =C2=A0Sending BU with BID Options >> >> =C2=A0 =C2=A0This specification (see Section 4.1) updates the definition= of the >> =C2=A0 =C2=A0Binding Identifier option, originally defined in >> =C2=A0 =C2=A0[I-D.ietf-monami6-multiplecoa]. =C2=A0According to this spe= cification the >> =C2=A0 =C2=A0BID option includes a BID-PRI field assigning each register= ed care-of >> =C2=A0 =C2=A0address a priority, and thus placing them in an ordered lis= t as also >> =C2=A0 =C2=A0described in Section 4.4. >> >> =C2=A0 =C2=A0Mobile nodes supporting this specification MUST use the BID= option >> =C2=A0 =C2=A0format defined in Section 4.1. =C2=A0Mobiles nodes MUST als= o register > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mobile nodes > >> 5.2.5. =C2=A0Receiving Binding Acknowledgements >> >> =C2=A0 =C2=A0According to [RFC3775] all nodes are required to silently i= gnore >> =C2=A0 =C2=A0mobility options not understood while processing binding up= dates. =C2=A0As >> =C2=A0 =C2=A0such a mobile node receiving a Binding Acknowledgement in r= esponse to >> =C2=A0 =C2=A0the transmission of a binding update MUST determine if the = Binding >> =C2=A0 =C2=A0Acknowledgement contains a copy of every flow identificatio= n options >> =C2=A0 =C2=A0included in the binding update. =C2=A0A Binding Acknowledge= ment without >> =C2=A0 =C2=A0flow identification option(s), in response to a Binding Upd= ate with >> =C2=A0 =C2=A0flow identification option, would indicate inability (or >> =C2=A0 =C2=A0unwillingness) on behalf of the source node to support the = extensions >> =C2=A0 =C2=A0presented in this document. >> >> =C2=A0 =C2=A0If a received Binding Acknowledgement contains a copy of of= each flow > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0s/of of/of/ > >> 5.3.2. =C2=A0Receiving BU with Flow Identification Options >> >> =C2=A0 =C2=A0When the home agent receives a binding update which include= s at least >> =C2=A0 =C2=A0one Flow Identification option, it first performs the opera= tion >> =C2=A0 =C2=A0described in section 10.3.1 of RFC3775. >> >> =C2=A0 =C2=A0Home agents that do not support this specification will ign= ore the >> =C2=A0 =C2=A0flow identification options and all their suboption, having= no effect >> =C2=A0 =C2=A0on the operation of the rest of the protocol. >> >> =C2=A0 =C2=A0If the binding update is accepted, and the home agent is wi= lling to >> =C2=A0 =C2=A0support flow bindings for this MN, the home agent checks th= e flow >> =C2=A0 =C2=A0identification options. >> >> =C2=A0 =C2=A0If more than one flow identification option in the same BU,= has the > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0s/same BU,/same BU/ > > > Cheers, > > a+ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From arno@natisbad.org Tue May 5 14:13: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 8E6313A6BAD for ; Tue, 5 May 2009 14:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-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 MY64zAZrh+Pz for ; Tue, 5 May 2009 14:13:55 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 8FC013A68FA for ; Tue, 5 May 2009 14:13:55 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M1Ryw-0003Bn-V4; Tue, 05 May 2009 23:15:19 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: George Tsirtsis References: <87ocu7v864.fsf@small.ssi.corp> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090505:tsirtsis@googlemail.com::MYwcJzt+NWPVPqBo:000000000000000000000000000000000000000B9r X-Hashcash: 1:20:090505:mext@ietf.org::lIGhalmxCFNyEVyi:00001qWR Date: Tue, 05 May 2009 23:16:05 +0200 In-Reply-To: (George Tsirtsis's message of "Tue, 5 May 2009 21:26:18 +0100") Message-ID: <87ljpb8d4a.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IETF MEXT WG ML Subject: Re: [MEXT] Review of draft-ietf-mext-flow-binding-02 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, 05 May 2009 21:13:56 -0000 Hi George, George Tsirtsis writes: > Thanks for the review. I will look at your comments in more detail > tomorrow when i will have more time but I wanted to respond to one > thing below...see inline. Ack. > On Tue, May 5, 2009 at 5:14 PM, Arnaud Ebalard wrote: >> Hi, >> >> Below is a review of draft-ietf-mext-flow-binding-02. I think the >> document is in pretty good shape and provides a good framework for flow >> binding feature. >> >> The whole thing is bit difficult to read towards the end but I don't >> think it's an editorial issue: the links and interactions between things >> requires some attention and this is the end of the day here. In the end, >> I won't state it would be difficult (or easy) to implement, but it will >> clearly require to be careful. >> >> At the end of the reading, I wondered what will happen on a HA when it >> will receive the first a BU of a MN that has just rebooted after a >> crash. More precisely, I just want confirmation that there is no way for >> some old flow to survive on the HA due to some specific values in the BU >> (same CoA, BID, ...). >> > > GT> I am not sure section 5.2 (last para) and 5.2.3 can be any clearer on this. > According to these the MN MUST include all FIDs it wants to maintain > in every BU, either as FID options or as part of an FIDSummary option. > An MN that just rebooted will start from scratch and will not remember > any of the FIDs it established earlier. A BU without any flow binding > options will remove all FID state from the HA. I was more thinking about a MN rebooting on the same network, with high probability to send its first BU with the same kind of content as the one he sent before dying. > Also note that RFC3775 discusses various issues WRT reboots and while > RFC3775 is not specific about it, it does indicate that a combination > of the seq.num and IPSEC state can be used to detect such cases. Well, IPsec will not help. Nothing prevents a MN to rekey at some point. The HA will not act upon that kind of stimulus. It will possibly not even be warned. As for the sequence number, if I am not mistaken, the HA is expected to warn the MN about that using a BA with status code 135 (seq num out of window). In the end, the MN will not have to reconsider the content of its first BU when receiving that BA (say create a new one w/ the correct sequence number *and* that flushes everything just in case): it can *safely* resend previous one w/ an updated sequence number, without bothering about cleaning previous states. The anwser below clarified that: BU will delete old states either by overwriting things (Add) or not specifying existing ones that the HA has. In the end, this will work because the MN is not expected to send Modify in its first BU (only Add). > In any case for the purpose of this draft we are being very clear. If > an MN "forgets" its FID state for any reason it will fail to refresh > it appropriately and so it will be removed from the HA/CN. This is what I thought from my reading but I wanted to be sure I did not miss something. Thanks for your answer. Cheers, a+ From julien.laganier.ietf@googlemail.com Wed May 6 08:11: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 2F3D83A657C for ; Wed, 6 May 2009 08:11:12 -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 CeHistLjg7RU for ; Wed, 6 May 2009 08:11:05 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 97C473A6F24 for ; Wed, 6 May 2009 08:09:24 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so969055fgb.18 for ; Wed, 06 May 2009 08:10:48 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=VhJW6R+l8DB3WYZmVRWqeWa0MQo+4kDKrQ6linHz7Gg=; b=KMoxqgMJhGLiX+I+e/9kC0zYysBvNYiz9AHjZqp17kfznGj/RVRXiLXFYnfaPTAaKN 8A/OnDaChVT/mmcMwz5R/iW2uU+ev6fVb1F5d248J3cFGaKBKh1Vi3xBMLvmadUaiIMQ t29oDr/ygOfsHYFzzcktnnj7Vym+cAKaOsrLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=HG/53a4BkcvaEqDk/y3XIWn8QXGvr2v2d/NmmiWC1KWSXCiwj32Tld3roQ5d6NVUnq OaBScKDoetdNtOoEimhQhSP9kWsACALHVb3dIx0iwMsU27xoeeGfeN0D3LzdZ5RQEIS9 x/5/+5UD2IJo/do0bcy8JiQvLh9uz2S9eJgko= Received: by 10.86.1.1 with SMTP id 1mr1421085fga.0.1241622648812; Wed, 06 May 2009 08:10:48 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id e11sm10761315fga.11.2009.05.06.08.10.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 06 May 2009 08:10:47 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Wed, 6 May 2009 17:10:46 +0200 User-Agent: KMail/1.9.10 References: <559691.25805.qm@web27804.mail.ukl.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905061710.47336.julien.laganier.IETF@googlemail.com> Subject: Re: [MEXT] binary filters draft 0 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, 06 May 2009 15:11:12 -0000 Hello George, On Tuesday 05 May 2009, George Tsirtsis wrote: > > I guess the more general question is, do we need the pointer to be > bit specific? or byte specific is enough? If doable, I think it would make sense to be able to match pointer on=20 bit-boundaries rather than byte-boundaries. Another thing that could=20 make sense is the ability to specify the value of pointers in terms of=20 ranges. What do you think? =46WIW a strawman pointer could then look like: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Length | Start Value ...=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Value ... +-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Pointer Offset The Offset field identifies an integer number of bits from the beginning of the IP header. It points to the beginning of the field of interest in the packet. R (Range) The R flag indicates whether the pointer is to a value (unset,=20 zero) or a range of values (set, one.) Value Length The Value Length field identifies the length in bits of the field of interest in the packet. Start Value If the R flag is unset the variable length Start Value field identifies the value to be matched at the point identified by this Pointer.=20 If the R flag is set the variable length Start Value field identifies the first value of the range to be matched at the point identified by this Pointer.=20 The length in bits of the Start Value field is as indicated by the value Length field. End Value The variable length End Value field is only present if the R flag is set and identifies the last value of the range to be matched at the point identified by this Pointer.=20 The length in bits of the End Value field is as indicated by the value Length field. =2D-julien > On Tue, May 5, 2009 at 3:13 PM, Christian Kaas-Petersen > > wrote: > > The DSfield is fine. =C2=A0But for the ECN, using the general offset > > mechanism, the offset is a count of bytes from the beginning of the > > packet, and the length is a number of bytes, so I cannot see how it > > should be possible to consider two ECN-bits somewhere in the middle > > of the packet when the neighboring six bits in general can take > > any values. > > > > Christian > > > > --- Den tirs 5/5/09 skrev George Tsirtsis : > >> Fra: George Tsirtsis > >> Emne: Re: [MEXT] binary filters draft 0 > >> Til: "Christian Kaas-Petersen" > >> Cc: mext@ietf.org > >> Dato: tirsdag 5. maj 2009 12.18 > >> Christian, et.al., > >> > >> As I was implementing the changes discussed earlier, the > >> following > >> issue came up. > >> > >> One of your comments is about renaming the TOS field to > >> DSCP. First of > >> all I noticed we used the term Class of Service (CS) in the > >> IPv6 > >> header which is not correct...instead it is Traffic Class. > >> > >> Looking into this a bit more, however, I remembered that > >> the IPv4 TOS > >> byte as well as the IPv6 TC byte were redefined as 6bit > >> DSfield and 2 > >> bit Currently Unused (CU) fields. One of the CU bits was > >> then used by > >> ECN (see RFC3260 for all this). > >> > >> Since I do not anticipate anyone to be matching the ECN bit > >> for the > >> purpose of Flow Bindings, I suggest we redefine the 8-bit > >> TOS field as > >> an 8bit DSfield, the last 2 bits of which MUST be set to 0 > >> by sender > >> and ignored by the receiver. This way a given DSCP can be > >> matched > >> without getting confused by the ECN bit. > >> > >> If someone really wants to match the ECN bit, (who knows > >> why) of > >> course they still can, by using the offset based pointers > >> defined in > >> the draft. > >> > >> Note that I do not want to make this a 6bit field because > >> that would > >> break byte alignment for the sub-option, when this field is > >> present.. > >> > >> Does this make sense? > >> > >> George > > > > =C2=A0 =C2=A0 =C2=A0Tr=C3=A6nger du til at se det store billede? Kelkoo= giver dig > > gode tilbud p=C3=A5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext =2D-=20 =2D-julien From tsirtsis@googlemail.com Wed May 6 08:25: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 6F92D3A6E51 for ; Wed, 6 May 2009 08:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.140, 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 ePcp6bBt0Zny for ; Wed, 6 May 2009 08:25:13 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 905C03A6A72 for ; Wed, 6 May 2009 08:22:24 -0700 (PDT) Received: by bwz22 with SMTP id 22so189965bwz.37 for ; Wed, 06 May 2009 08:23:49 -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=BQ/QL17KUUzLqSGpNhGr9XOoj3PfoGCcEkopxlwTbmE=; b=uhFlpaEpZONWBs+CGYElfjIRxaVpe3aEVqTCrdu5XEpUlmBhHoKCX29zlLYvntH7kv vBFZdYHyNd+dNnVPciW2r7diN8t84ZrMpe+z1dVs2TUOx8ANdTi44JsAelIK8nAC6fAg l+cOZISvgAhh4LD+0+PoVF6zV2fyRPtZaQZS8= 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=sNWxfaYI4SUF6pAL3AgZyUEex0/Xo4+agdRrdH+q9xw12214yZsXMa0ZRnetmIK4Og Fb8usI3/oNvSc0W2S6a7oKIEasgECSDAvSQY7/tVNOO6rX3wchnp8DuylXXXCaI9dPGt GXC4He+SNlKpF8OgEdINN++2SI/LF28GpKYzo= MIME-Version: 1.0 Received: by 10.223.126.69 with SMTP id b5mr554801fas.54.1241623429068; Wed, 06 May 2009 08:23:49 -0700 (PDT) In-Reply-To: <200905061710.47336.julien.laganier.IETF@googlemail.com> References: <559691.25805.qm@web27804.mail.ukl.yahoo.com> <200905061710.47336.julien.laganier.IETF@googlemail.com> Date: Wed, 6 May 2009 16:23:49 +0100 Message-ID: From: George Tsirtsis To: Julien Laganier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] binary filters draft 0 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, 06 May 2009 15:25:26 -0000 Hi Julien, This is not a bad idea. We are increasing complexity though. One thing that bothers me with bit based pointers is byte alignment, which can no longer be assured. I think we should be careful not to go crazy with these. Pointers, in their current simple form, already give increased flexibility to the binary filters. If this flexibility proves insufficient some time in the future, we can always come back and define another flow description sub-option that it either allows for more complex pointers or offers more flexibility in some other way. For now, I would prefer to keep it relatively simple. Thoughts? George On Wed, May 6, 2009 at 4:10 PM, Julien Laganier wrote: > Hello George, > > On Tuesday 05 May 2009, George Tsirtsis wrote: >> >> I guess the more general question is, do we need the pointer to be >> bit specific? or byte specific is enough? > > If doable, I think it would make sense to be able to match pointer on > bit-boundaries rather than byte-boundaries. Another thing that could > make sense is the ability to specify the value of pointers in terms of > ranges. What do you think? > > FWIW a strawman pointer could then look like: > > =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 > =C2=A0 =C2=A0 =C2=A00 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 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Offset =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|R| > =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+ > =C2=A0 =C2=A0 | Value Length =C2=A0| =C2=A0 =C2=A0 Start Value ... > =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | End Value ... > =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+ > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Figure 2: Pointer > > =C2=A0 Offset > > =C2=A0 =C2=A0 =C2=A0The Offset field identifies an integer number of bits= from the > =C2=A0 =C2=A0 =C2=A0beginning of the IP header. =C2=A0It points to the be= ginning of the > =C2=A0 =C2=A0 =C2=A0field of interest in the packet. > > =C2=A0 R (Range) > > =C2=A0 =C2=A0 =C2=A0The R flag indicates whether the pointer is to a valu= e (unset, > =C2=A0 =C2=A0 =C2=A0zero) or a range of values (set, one.) > > =C2=A0 Value Length > > =C2=A0 =C2=A0 =C2=A0The Value Length field identifies the length in bits = of the field > =C2=A0 =C2=A0 =C2=A0of interest in the packet. > > =C2=A0 Start Value > > =C2=A0 =C2=A0 =C2=A0If the R flag is unset the variable length Start Valu= e field > =C2=A0 =C2=A0 =C2=A0identifies the value to be matched at the point ident= ified by this > =C2=A0 =C2=A0 =C2=A0Pointer. > =C2=A0 =C2=A0 =C2=A0If the R flag is set the variable length Start Value = field > =C2=A0 =C2=A0 =C2=A0identifies the first value of the range to be matched= at the point > =C2=A0 =C2=A0 =C2=A0identified by this Pointer. > =C2=A0 =C2=A0 =C2=A0The length in bits of the Start Value field is as ind= icated by the > =C2=A0 =C2=A0 =C2=A0value Length field. > > =C2=A0 End Value > > =C2=A0 =C2=A0 =C2=A0The variable length End Value field is only present i= f the R flag > =C2=A0 =C2=A0 =C2=A0is set and identifies the last value of the range to = be matched at > =C2=A0 =C2=A0 =C2=A0the point identified by this Pointer. > =C2=A0 =C2=A0 =C2=A0The length in bits of the End Value field is as indic= ated by the > =C2=A0 =C2=A0 =C2=A0value Length field. > > --julien > >> On Tue, May 5, 2009 at 3:13 PM, Christian Kaas-Petersen >> >> wrote: >> > The DSfield is fine. =C3=82=C2=A0But for the ECN, using the general of= fset >> > mechanism, the offset is a count of bytes from the beginning of the >> > packet, and the length is a number of bytes, so I cannot see how it >> > should be possible to consider two ECN-bits somewhere in the middle >> > of the packet when the neighboring six bits in general can take >> > any values. >> > >> > Christian >> > >> > --- Den tirs 5/5/09 skrev George Tsirtsis : >> >> Fra: George Tsirtsis >> >> Emne: Re: [MEXT] binary filters draft 0 >> >> Til: "Christian Kaas-Petersen" >> >> Cc: mext@ietf.org >> >> Dato: tirsdag 5. maj 2009 12.18 >> >> Christian, et.al., >> >> >> >> As I was implementing the changes discussed earlier, the >> >> following >> >> issue came up. >> >> >> >> One of your comments is about renaming the TOS field to >> >> DSCP. First of >> >> all I noticed we used the term Class of Service (CS) in the >> >> IPv6 >> >> header which is not correct...instead it is Traffic Class. >> >> >> >> Looking into this a bit more, however, I remembered that >> >> the IPv4 TOS >> >> byte as well as the IPv6 TC byte were redefined as 6bit >> >> DSfield and 2 >> >> bit Currently Unused (CU) fields. One of the CU bits was >> >> then used by >> >> ECN (see RFC3260 for all this). >> >> >> >> Since I do not anticipate anyone to be matching the ECN bit >> >> for the >> >> purpose of Flow Bindings, I suggest we redefine the 8-bit >> >> TOS field as >> >> an 8bit DSfield, the last 2 bits of which MUST be set to 0 >> >> by sender >> >> and ignored by the receiver. This way a given DSCP can be >> >> matched >> >> without getting confused by the ECN bit. >> >> >> >> If someone really wants to match the ECN bit, (who knows >> >> why) of >> >> course they still can, by using the offset based pointers >> >> defined in >> >> the draft. >> >> >> >> Note that I do not want to make this a 6bit field because >> >> that would >> >> break byte alignment for the sub-option, when this field is >> >> present.. >> >> >> >> Does this make sense? >> >> >> >> George >> > >> > =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0Tr=C3=83=C5=A0nger du til at se = det store billede? Kelkoo giver dig >> > gode tilbud p=C3=83=C2=A5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > > -- > --julien > From julien.laganier.ietf@googlemail.com Thu May 7 02:31: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 81F813A6E22 for ; Thu, 7 May 2009 02:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 vsutG6oSMSQF for ; Thu, 7 May 2009 02:31:38 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 460783A6B9C for ; Thu, 7 May 2009 02:31:12 -0700 (PDT) Received: by ewy24 with SMTP id 24so894381ewy.37 for ; Thu, 07 May 2009 02:32:38 -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:content-transfer-encoding :content-disposition:message-id; bh=F6ubR/yaVyXsxxuxuYraDN4DjMc87ImTyUrgAiEEvI0=; b=ZYCoGPZhQWUva1rsDxb8WUowXp6+p11TEv6mEWyqHcaDp4OVGcfILkUwmWW3COIKHJ V4dBuLwhfhnIHNiDF4VM4DjuHuOLC7GTzOQrMc9T0Ts8guJw6J0tvq90jhSl0OtNqSvi BPJLRWY0C8fSyzsC+Ut+t280kKO/GjBTwqraI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=FMAI01n2X164PxKWnLBsqtu/XcOps8vugTsTATJ06TYDZJC73frWwmvk3ywFtyw2vA XFJ0sYjNLIG5jgy9PcUdBgdhMfzg/DMYmipHuprIY3icPIWoJpiAgAEl/ba08FID2zL1 tlefseiNo/pf/Cv2eyLigffU37xwYKOb+aE6M= Received: by 10.216.16.212 with SMTP id h62mr1077845weh.201.1241688758149; Thu, 07 May 2009 02:32:38 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id j8sm10285295gvb.11.2009.05.07.02.32.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 02:32:37 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Thu, 7 May 2009 11:32:35 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905071132.36973.julien.laganier.IETF@googlemail.com> Subject: [MEXT] 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: Thu, 07 May 2009 09:31:39 -0000 Folks, I have reviewed the draft as a document shepherd and I believe it would be ready for IESG provided the comments below are addressed. Throughout the document ----------------------- => Inconsitent usage of capitalized/uncapitalized Mobile IPv6 and Proxy Mobile IPv6. I think everything should be capitalized. => Inconsistent use of abbreviation and expanded forms in the text, e.g. MAG vs. mobile access gateway in the same sentence. I think you should choose, either define those upfront (e.g. by pointing to RFC5213) and stick to the abbreviation in rest of the text, or use the developped form everywhere. Includes MAG, LMA, BRI, BRA... In 3.2 ------ This mechanism enables the home domain to dynamically allow the user to act upon the revocation message in order to recover its interrupted mobile IPv6 services. => How about: This mechanism enables the user to react to the revocation, e.g., reinstate its interrupted Mobile IPv6 services. In 3.4 ------ Since the Mobile node does not participate in the mobility mechanism in the case of PMIPv6, there are many scenarios where Binding Revocation mechanism is needed to clean resources and make sure that the mobility entities, e.g. MAG and LMA, are always synchronized => Should be i.e. instead of e.g. In 3.4.1. --------- In this case, the MAG could send a Router Advertisement message to the MN with the home network prefix lifetime set to zero. => the PIO for the home network prefix has two lifetime, here I think you're talking about the valid lifetime. If so, please fix. In 4. ----- Additionally, in the case when the LMA receives a BRI which indicates a bulk termination where the (G) bit is set and the Revocation Trigger field is set to "Per-Peer Policy", the LMA MUST verify that the MAG sending the binding revocation indication message is authorized to invoke Global revocation. => What sort of authorization do you have in mind here? Do you mean the LMA MUST verify that the MAG sending the binding revocation indication message is the one who currently owns the binding as per the BCE? If so better to be spelled out. In 6.1. ------- Reserved and Per-MN Revocation Trigger: 0 Reserved 1 Unspecified 2 Administrative Reason 3 Inter-MAG Handover 4 User Initiated Session(s) Termination 5 Access Network Session(s) Termination 6 Possible Out-of Sync BCE State => What is Possible Out-of Sync BCE State? The others are self-explaining, but this one I am unclear when it shall be sent, neither what it mean when I receive... Could we be more precise? Global Revocation Trigger: 128 Per-Peer Policy 129 Revoking Mobility Node Local Policy => I find the names of these triggers confusing. I've looked at the descriptive text in the following section and I found it difficult to get a clear picture of what they are about. If I'm the only one confused I don't insist on any changes, but if not, maybe we could try to improve the description of global revocation... In 7. ----- 7. Binding Revocation Process Considerations The following subsections describe the details of the binding revocation generic process by the different mobility entities. => I do not like the title, the subsections contain normative text, thus these are everything but "considerations". Please change to something straightforward and relevant: "Generic Mobile Entity Operation" or sthg else. In 7.1. ------- When sending a Binding Revocation message, the sending mobility node, initiator, constructs the packet as it would any other Mobility Header with the exception of setting the MH Type field to . => but later it says: When a mobility entity initiates the binding revocation process by sending a Binding Revocation Indication message, the initiator MUST construct the BRI message as described in Section 6.1. => and: However, when the responder acknowledges the BRI message by sending a BRA, the responder MUST construct the Binding Revocation Acknowledgement as described in Section 6.2. => so which one is it, as any other mobity header, or as per 6.1 and 6.2? The mobility entity which initiates the revocation process MUST use the underlying security association, e.g., IPsec SA, that has been used to secure the mobile node binding registration signaling in securing the BRI and BRA messages transmission with the responding mobility entity. => Why do you restrict to "which initiates the revocation process"? Does it mean the responder uses no security association?! I think what we want to say is: "A mobility entity MUST secure BRI and BRA message with the same underlying security association, e.g., IPsec SA, that has been used to secure the mobile node binding registration signaling." No? In 7.2. ------- Upon receiving a packet carrying a Binding Revocation Indication, the receiving mobility entity, responder, validates that the packet was received protected with the security association that already has been established with the mobility entity, initiator, and used during the registration signaling phase, e.g., IPsec SA. => As above I think we'd get a clearer wording if we do not use responder neither initiator. Also the text doesn't cover the BRA. How about: "Upon receiving a packet carrying a BRI or BRA, the receiving mobility entity verifies that the packet was received protected with the security association that has been used during the binding registration signaling phase, e.g., an IPsec SA." In 14. ------ However, in the case when the MAG sends a BRI message with the Global (G) bit is set and the Revocation Trigger field is set to "Per-Peer policy", the LMA MUST verify that the MAG is authorized to use Per- Peer Global Revocation. => Again I'd appreciate a better scoping of authorization in the above. Hope that helps to improve the document before it hits IESG. --julien From arno@natisbad.org Thu May 7 02:44: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 606D928C11A for ; Thu, 7 May 2009 02:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 92nAUEn8+Cl8 for ; Thu, 7 May 2009 02:44:23 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 728B23A6AF5 for ; Thu, 7 May 2009 02:44:22 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M20Ah-0005pY-Mb; Thu, 07 May 2009 11:45:44 +0200 X-Hashcash: 1:20:090507:ryuji.wakikawa@gmail.com::brVOwM3womnMuIfk:00000000000000000000000000000000000000KM0 X-Hashcash: 1:20:090507:vijay@wichorus.com::lNipDFBaxZNOTxfQ:00000000000000000000000000000000000000000000S5L X-Hashcash: 1:20:090507:tsirtsis@googlemail.com::ULJAiv7WCZhZpGga:000000000000000000000000000000000000005bK7 X-Hashcash: 1:20:090507:thierry.ernst@inria.fr::ZUEYJEGYz7rGFm4y:0000000000000000000000000000000000000000sr5 X-Hashcash: 1:20:090507:hesham@elevatemobile.com::M5FaK0/dCLFwQKSs:00000000000000000000000000000000000000rMi X-Hashcash: 1:20:090507:marcelo@it.uc3m.es::7gl3563jr22Pb/Kj:00000000000000000000000000000000000000000000XWN X-Hashcash: 1:20:090507:mext@ietf.org::i+sVc9bkjp4YrIjb:00000EG2 From: arno@natisbad.org (Arnaud Ebalard) To: Ryuji Wakikawa , Vijay Devarapalli , George Tsirtsis , Thierry Ernst , X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Thu, 07 May 2009 11:46:31 +0200 Message-ID: <878wl95jpk.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IETF MEXT WG ML Subject: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals 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, 07 May 2009 09:44:26 -0000 Hi, I reviewed draft-ietf-monami6-multiplecoa-13. The comments are below on an inline version of the draft. Many are simple to handle, some are just typos. The comments in section 9 (Compatibility w/ IPsec tunnel mode) are more substantial. But there is a specific topic that I would like to discuss in more details: the home return as defined in section 5.6 (Simultaneous Home and Visited Link Operation) If the following has already been proposed or discussed before, just tell me. While reading the draft, I got puzzled by the content of section 5.6. First I thought proposed solution was extremely complicated. Then, I reread the section multiple times to precisely understand what kind of difficult problem required such a complicated solution. In the end, if I am not mistaken, the idea is for the MN to be able to both directly receive traffic at its HoA with one of its interface connected to the home network and still be registered with the HA in order to be able to have it tunnel some parts of the traffic towards some of its CoA. I would call that route-unoptimization. Why? Well, the MN is at home, directly connected to its HA, exactly where it should be to get the traffic to its HoA in the most efficient way. And the draft complicates everythings with more than 3 pages of additions in order to avoid uisng that *direct* connection between the HA and the MN, and replace it by tunneling to the CoA from the HA. And there is not even an argument in the draft to support that need! If the MN-HA connection on the home network is so bad and it is so important for the MN to be able to maintain bindings with the HA from its Home Network to keep the ability to prevent traffic to be sent directly to it and make it be tunneled to it at its CoAs, then a simple solution is to let the MN consider its home network as another foreign network and configure a CoA on the associated interface to register it with the HA. (sorry for that long sentence) That way, it will still have the ability to have the HA redirect traffic to other CoAs. What I am arguing for is to simply follow RFC 3775 and let the MN get back ownership of its HoA when it is at home, i.e. remove the H flag in the Binding Identifier Mobility Option, the "MCOA RETURNHOME WO/ NDP error value, content of section 5.6 (that's 3 pages and 5 subsections, with unhealthy L2/L3 tricks), some parts of 6.3, ... Note that I do not argue against the ability for the MN to have bindings with CN using its CoAs when one of its interface is connected to the home network. In fact, I would like to propose an extension: what about using BID 0 as a specific BID referencing the HoA? Yes, the HoA. The idea would be to provide the ability for a MN to tell a CN that some specific flow should be sent directly to the HoA. At the moment, it is not possible (I may have missed something) for a MN that has binding with CN to specify that some flow should be sent directly to the HoA. This would be useful when the node is at home, for instance. But there may be other cases where the node would prefer having the traffic be routed by the HA: for instance because the HA-MN tunnel is IPsec protected whereas the route-optimized communications between the MN and a CN is not protected on the MN's foreign network. What do you think? > 3. Protocol Overview > > A new extension called the Binding identification number (BID) is > introduced to distinguish between multiple bindings pertaining to the > same home address. If a mobile node configures several IPv6 global > addresses on one or more of its interfaces, it can register these > addresses with its home agent as care-of addresses. If the mobile > node wants to register multiple bindings, it MUST generate a BID for > each care-of address and store the BID in the binding update list. A > mobile node can manipulate each binding independently by using the > BIDs. The mobile node then registers its care-of addresses by > sending a Binding Update with a Binding Identifier mobility option. > The BID is included in the Binding Identifier mobility option. After > receiving the Binding Update with a Binding Identifier mobility > option, the home agent MUST copy the BID from the Binding Identifier > mobility option to the corresponding field in the binding cache > entry. If there is an existing binding cache entry for the mobile > node, and if the BID in the Binding Update does not match the one > with the existing entry, the home agent MUST create a new binding > cache entry for the new care-of address and BID. The mobile node can > register multiple care-of addresses either independently in > individual Binding Updates or multiple at once in a single Binding > Update. > > If the mobile host wishes to register its binding with a > correspondent node, it must perform return routability operations as > described in [RFC-3775]. This includes managing a Care-of Keygen > token per care-of address and exchanging Care-of Test Init and > Care-of Test message with the correspondent node for each care-of > address. The mobile node MAY use the same BID that it used with the > home agent for a particular care-of address. For protocol > simplicity, bulk registration to correspondent nodes is not supported > in this document. This is because the Return Routability mechanism > introduced in [RFC-3775] cannot be easily extended to verify multiple > care-of addresses stored in a single Binding Update. > > Figure 1 illustrates the configuration where the mobile node obtains > multiple care-of addresses at foreign links. The mobile node can > utilize all the care-of addresses. In Figure 1, the home address of > the mobile node (MN) is 2001:db8::EUI. The mobile node has 3 > different interfaces and possibly acquires care-of addresses 1-3 > (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to > each care-of address. > > +----+ > | CN | > +--+-+ > | > +---+------+ +----+ > +------+ Internet |----------+ HA | > | +----+---+-+ +--+-+ > CoA2| | | | Home Link > +--+--+ | | ------+------ > | MN +--------+ | > +--+--+ CoA1 | > CoA3| | > +---------------+ > > Binding Cache Database: > home agent's binding (Proxy neighbor advertisement is active) > binding [2001:db8::EUI BID1 care-of address1] > binding [2001:db8::EUI BID2 care-of address2] > binding [2001:db8::EUI BID3 care-of address3] > correspondent node's binding > binding [2001:db8::EUI BID1 care-of address1] > binding [2001:db8::EUI BID2 care-of address2] > binding [2001:db8::EUI BID3 care-of address3] > > Figure 1: Multiple Care-of Address Registration > > If the mobile node decides to act as a regular mobile node compliant > with [RFC-3775], it sends a Binding Update without any Binding > Identifier mobility options. The receiver of the Binding Update > deletes all the bindings registering with a BID and registers only s/registering/registered/ > single binding for the mobile node. Note that the mobile node can > continue using the BID even if it has only a single binding that is > active. > > Binding cache lookup is done based on the home address and BID > information if a BID is available. This is different from RFC 3775, > where only the home address is used for binding cache lookup. > Binding cache lookup is operated for either protocol signaling and > data packets. For the protocol signaling such as a Binding Update, > BID should be always carried by a BID sub-option in a protocol > signaling. Therefore, a correspondent binding cache that matches the > specified BID MUST be found from the binding cache database. On the > other hand, for the data packets, no BID information is carried in a > packet. The binding cache lookup may involve policy or flow filters > to retrieve a correspondent BID per packet in cases where some policy > or flow filters are used to direct a certain packet or flow to a > particular care-of address. However, the binding cache lookup using > policy or flow filters is out of scope for this document. If no such > mechanism is available and no BID is found for a packet, a node > SHOULD use the binding which was last verified by receiving data > packets or signaling from the mobile node. In case the binding cache > lookup for data packets, using the combination of home address and > BID, does not return a valid binding cache entry, the home agent > SHOULD perform the lookup based on only the home address as described > in [RFC-3775]. > > In any case, to avoid problems with upper layer protocols and TCP in > particular, a single packet flow as identified by the 5-tuple SHOULD > only be sent to a single care-of address at a time. > > The mobile node may return to the home link through one of its > interfaces. There are two options possible for the mobile node when > its returns home. Section 5.6 and Section 5.5.1 describe the > returning home procedures in more detail. > > 1. The mobile node uses only the interface with which it attaches to > the home link. I think that first sentence is a bit misleading w.r.t. the content of the paragraph. The whole idea of option 1) is just that the MN de-registers all bindings with the HA and takes back full ownership of its HoA. Binding with CN may remain in place. What about (just a proposal) saying just that, i.e. use the following to describe that setup: 1. The mobile node de-registers all bindings with the HA related to all care-of addresses it has and takes back full ownership of its HoA on the home link. The net effect of this de-registration is that it no more receives any encapsulated traffic from the Home Agent on any of its interfaces. In parallel, the mobile node can still use the interfaces attached to foreign networks for route-optimized communications with correspondent nodes (from/to CoA1 and CoA2). This setup is illustrated in Figure 2. This is while rewriting this paragraph that I thought it would be a good idea for the MN to be able to express to CN the fact that some flows should be directly sent to the HoA. Hence, the idea of asosciating BID 0 to that feature. > > +----+ > | CN | > +--+-+ > | > +---+------+ +----+ > +------+ Internet |----------+ HA | > | +----+-----+ +--+-+ > CoA2| | | Home Link > +--+--+ | --+---+------ > | MN +--------+ | > +--+--+ CoA1 | > | | > +---------------------------+ > > Binding Cache Database: > home agent's binding > none > correspondent node's binding > binding [2001:db8::EUI BID1 care-of address1] > binding [2001:db8::EUI BID2 care-of address2] > > Figure 2: Using only Interface Attached to Home Link > > 2. The mobile node may simultaneously use both the interface > attached to the home link and the interfaces still attached to > the visited link(s) as shown in Figure 3. There are two possible > topologies depending on whether the home agent is the only router > on the home link or not. The operation of Neighbor Discovery > [RFC-4861] is different in the two topologies. More details can > be found in Section 5.6. The home agent and the correspondent > node have the binding entries listed in Figure 3 in their binding > cache database in both topologies. The home agent also knows > that the mobile node is attached to the home link. All the > traffic from the Internet is intercepted by the home agent first > and routed to either the interface attached to the home link or > the one of the foreign links. How the home agent decides to > route a particular flow to the interface attached to the home > link or foreign link is out of scope in this document. I expected to find some rationales supporting case 2 and all the complicated thngs it adds to the draft. >From my perspective, the home link is: - a specific link in MIPv6 architectures - the location where the MN is the closest to the HA - the location where packets sent to the home prefix are routed Considering those (fair) hypothesis, what are the specific network architectures where it is expected to be beneficial to support having the hop just before the MN on its home link *tunnel* the traffic to a remote CoA on another interface? In the end, the question is: what do we lose (in term of feature and support) if we remove case 2 and have the MN takes back ownership of its HoA when back home? In fact, let me consider things in a different way: let say a MN connected to its home network does explicitly configure an address which is not its HoA on this specific interface. Then, the war between the HA and the MN for the HoA on the link is over and the MN can simply consider its Home Link as a common foreign network and keep all the bindings it wants with its HA, i.e. have some flow routed to other CoA on the HA. The only (IMHO, very small) drawback of this proposal is that the traffic between the HA and the MN will be tunneled. > 4.2. Binding Update Message > > This specification extends the Binding Update message with a new > flag. The flag is shown and described below. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 4: Binding Update message > > Overwrite (O) flag > > When this flag is set, all the binding cache entries for a mobile > node are replaced by new entries registering with this Binding > Update message. This flag is only used when BID Mobility Option > is carried with Binding Update. > > Reserved > > 6 bits Reserved field. @ryuji: that section 4.2 seems pretty explicit to me. referencing already consumed flags in the Figure is IMO a good idea. > 4.3. Binding Identifier Mobility Option > > The Binding Identifier mobility option is included in the Binding > Update, Binding Acknowledgement, Binding Refresh Request, and Care-of > Test Init and Care-of Test message. The Binding Identifier Mobility > Option has an alignment requirement of 2n if the Care-of Address > field is not present. Otherwise, it has the alignment requirement of > 8n + 2. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Binding ID (BID) | Status |H| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ > + + > : IPv4 or IPv6 care-of address (CoA) : > + + > +---------------------------------------------------------------+ > > Figure 5: BID Mobility Option > > Type > > Type value for Binding Identifier is TBD > > Length > > 8-bit unsigned integer. Length of the option, in octets, > excluding the Type and Length fields. It MUST be set to either 4, > 8, or 20 depending on the care-of address field. When the care-of > address is not carried by this option, the length value MUST be > set to 4. If the IPv4 care-of address is stored in the care-of > address field, the length MUST be 8. Otherwise, the Length value > MUST be set to 20 for IPv6 care-of address. > > Binding ID (BID) > > The BID which is assigned to the binding indicated by the care-of > address in the Binding Update or the Binding Identifier mobility > option. The BID is a 16-bit unsigned integer. The value of zero > is reserved and MUST NOT be used. The value MUST NOT be used. 2 questions: - maybe the rationale for that decision could be provided - what if a peer receives a BID with that value. What behavior is specified in that case and what will it allow if at some point that reserved value needs to be used? > Status > > The Status field is an 8-bit unsigned integer. When the Binding > Identifier mobility option is included in a Binding > Acknowledgement, this field overwrites the status field in the > Binding Acknowledgement only for this BID. If this field is set > to zero, the receiver ignores this field and uses the registration > status stored in the Binding Acknowledgement message. The > receiver MUST ignore this field if the Binding Identifier mobility > option is not carried within either the Binding Acknowledgement or > the Care-of Test messages. The possible status codes are the same > as the status codes of Binding Acknowledgement. This Status field > is also used to carry error information related to the care-of > address test in the Care-of Test message. > > Simultaneous Home and Foreign Binding (H) flag > > This flag indicates that the mobile node registers multiple > bindings to the home agent while is attached to the home link. while it is attached > This flag is valid only for a Binding Update sent to the home > agent. > > Reserved > > 7 bits Reserved field. The value MUST be initialized to zero by > the sender, and SHOULD be ignored by the receiver. Why not a MUST for the receiver? > Care-of Address > > If a Binding Identifier mobility option is included in a Binding > Update for the home registration, either IPv4 or IPv6 care-of > address for the corresponding BID can be stored in this field. > For the binding registration to correspondent nodes (i.e. route > optimization), only IPv6 care-of address can be stored in this > field. If no address is specified in this field, the length of > this field MUST be zero (i.e. not appeared in the option). If the > option is included in any other messages than a Binding Update, > the length of this field MUST be also zero. > > 4.4. New Status Values for Binding Acknowledgement > > New status values for the status field in a Binding Acknowledgement > are defined for handling the multiple Care-of Addresses registration: > > MCOA NOTCOMPLETE (TBD less than 128) > > > > > > > Wakikawa (Ed.), et al. Expires October 22, 2009 [Page 15] > > Internet-Draft MCoA April 2009 > > > In bulk registration, not all the binding identifier mobility > options were successfully registered. Some of them were rejected. > The error status value of the failed mobility option is > individually stored in the status field of the binding identifier > mobility option. > > MCOA RETURNHOME WO/NDP (TBD less than 128) > > When a mobile node returns home, it MUST NOT use Neighbor > Discovery Protocol (NDP) for the home address on the home link. > This is explained in more detail in Section 5.6 > > MCOA MALFORMED (TBD more than 128) > > Registration failed because Binding Identifier mobility option was > not formatted correctly. This value is used in the following > cases. > > * when the wrong length value is specified (neither 4, 8 nor 20) > in the length field of the Binding Identifier mobility option. > > * when a unicast routable address is not specified in the care-of > address field of the Binding Identifier mobility option. > > * when a care-of address is not appeared in the care-of address s/is not appeared/does not appear/ > field of the Binding Identifier mobility option stored in an > IPsec ESP protected Binding Update. > 5.3. Bulk Registration > > Bulk registration is an optimization for binding multiple care-of > addresses to a home address using a single Binding Update. This is > very useful if the mobile node, for instance, does not want to send a > lot of signaling messages through an interface where the bandwidth is > scarce. This document specifies bulk registration only for the > mobile node's home registration. A mobile node performing bulk > registration with a correspondent node is out of scope. > > To use bulk registration, the mobile node includes a Binding > Identifier Mobility option for each BID it wants to register in the > same Binding Update message. As with single registrations (see > Section 5.1), the care of address field is included for BID Care-of Address > 5.4. Binding De-Registration > > When a mobile node decides to delete all the bindings for its home > address, it sends a regular de-registration Binding Update with > lifetime set to zero as defined in [RFC-3775]. The Binding > Identifier mobility option is not required. > > If a mobile node wants to delete a particular binding(s) from its > home agent and correspondent nodes, the mobile node sends a Binding > Update with lifetime set to zero and includes a Binding Identifier > mobility option(s) with the BID(s) it wants to de-register. The > receiver will remove only the care-of address(es) that match(es) the > specified BID(s). Since de-registration attempts to remove a BID > that already exists, the care-of addresses field in each binding > identifier option can be omitted by the sender as defined in > Section 5.1. why not change the last 'can' to a MUST then? > 5.5. Returning Home: Using Single Interface The title of this subsection is not very explicit, is it? > The mobile node may return to the home link, by attaching to the home > link through one of its interfaces. When the mobile node wants to > return home, it should be configured with information on what > interface it needs to use. > > 5.5.1. Using only Interface attached to the Home Link > > The mobile node returns home and de-registers all the bindings as > shown in Figure 2 and as defined in [RFC-3775]. Should be more explicit: "The mobile node returns home and de-registers all the bindings it has with the home agent as shown in Figure 2 and as defined in [RFC-3775]." > After the de-registration step, all the packets routed by the home > agent are only forwarded to the interface attached to the home > link, even if there are other active interfaces attached to the > visited link(s). While the mobile node de-registers all the > bindings from the home agent, it may continue registering bindings > for interface(s) attached to visited link(s) to the correspondent > node as shown in Figure 2. > > 5.5.2. Using only Interface attached to the Visited Link > > The mobile node returns home physically but shuts down the interface > attached to the home link. As a result, a mobile node does not > return home even though it attaches to the home link by one of > interfaces. Before shutting down the interface, any binding for the > care-of address previously associated with the interface should be > deleted as defined in . this sentence ends badly ... > In this scenario, despite the fact that the mobile node is connected > to its home link, all of its traffic is sent and received via the > home agent and its foreign links. After reading those two paragraph, this "functionality" seems weird, to say the least. Can someone provide any rationale? or network architecture where it is beneficial to do that? In that case, would it not be better to consider the MN is never at home, i.e. has no home network instead of that trick? > 5.6. Returning Home: Simultaneous Home and Visited Link Operation > > 5.6.1. Problems of Simultaneous Home and Foreign Attachments > > The mobile node returns home and continues using all the interfaces > attached to both foreign and home links as shown in Figure 3. > > In [RFC-3775], the home agent intercepts packets meant for the mobile > node using Proxy Neighbor Discovery [RFC-4861] while the mobile node > is away from the home link. When the mobile node returns home, the > home agent deletes the binding cache and stops proxying for the home > address so that a mobile node can configure its home address on the > interface attached to the home link. In this specification, a mobile > node may return home, configure the home address on the interface > attached to the home link, but still use the interfaces attached to > the foreign links. In this case, a possible conflict arises when the s/when the/when/ > both the home agent and the mobile node try to defend the home > address. If the home agent stops proxying for the home address, the > packets are always routed to the interface attached to the home link > and are never routed to the interfaces attached to the visited links. > It is required to avoid the conflict between the home agent and the > mobile node, while still allowing the simultaneous use of home and > foreign links. The following describes the mechanism for achieving > this. > > 5.6.2. Overview and Approach > > The home agent MUST intercept all the packets meant for the mobile > node whether the mobile node is attached to the home link or not and > decide whether to send the traffic directly to the home address on > the link or tunnel to the care-of address. > > Two scenarios are illustrated in Figure 3, depending on whether the > Home Agent is the only router at the home link or not. The > difference is on who defends the home address by (Proxy) Neighbor > Discovery on the home link. > > 1. Mobile node defends the home address by the regular Neighbor > Discovery Protocol (illustrated as topology-a in Figure 3). The > home agent is the only router on the home link. Therefore the > home agent is capable of intercepting packets without relying on > the proxy Neighbor Discovery protocol and the mobile node can > manage the Neighbor Cache entry of the home address on the home > link as a regular IPv6 node. However, there is one limitation of > this scenario. If a correspondent node is located at the home > link, the home agent may not intercept the packets destined to > the mobile node. These packets are routed only via the home > link, but this is the most optimal path for the mobile node to > communicate with nodes on the home link. > > 2. If there are other routers on the home link apart from the home > agent, then it cannot be guaranteed that all packets meant for > the mobile node are routed to the home agent. In this case, the > mobile node MUST NOT operate the Neighbor Discovery protocol for > the home address on the home link. This allows the home agent to > keep using proxy neighbor discovery and thus it keeps receiving > all the packets sent to the mobile node's home address. If the > home agent, according to its local policy, needs to deliver > packets to the mobile node over the home link, an issue arises > with respect to how the home agent discovers the mobile node's > link local address. This specification uses the Mobility Header > Link-layer Address Option defined in [RFC-5268] in order to carry > the mobile node's link-layer address in the Binding Update. > Likewise, the mobile node would also know the link-layer address > of the default router address to send packets from the home link > without Neighbor Discovery. The link-layer address is used to > transmit packets from and to the mobile node on the home link. > The packets are transmitted without the Neighbor Discovery > protocol by constructing the link-layer header manually. This > operation is similar to Mobile IPv6 [RFC-3775] when a mobile node > sends a deregistration binding update to the home agent's link- > layer address in the operation for returning home. > > 5.6.3. Home Binding Support > > When the home binding is used, the mobile node MUST send a > registering binding update with a Binding Identifier mobility option > whith H flag set. The lifetime MUST be set to a non-zero lifetime of > the home binding, and the care-of address MUST be set to the home > address. as discussed 2 days ago on the list, it may be good to explicitly states the fact that this specific format of a de-registration BU in 3775 and that the draft changes that behavior. > 6.5. Receiving Packets from Mobile Node > > When a node receives packets with a Home Address destination option > from a mobile node, it MUST check that the care-of address that > appears in the source address field of the IPv6 header MUST be equal s/MUST/is/ > to one of the care-of addresses in the binding cache entry. If no > binding is found, the packets MUST be discarded. The node MUST also > send a Binding Error message as specified in [RFC-3775]. This > verification MUST NOT be done for a Binding Update. > > 8. DSMIPv6 Applicability I skipped section 8. > 9. IPsec and IKEv2 interaction > > Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the > use of IPsec to protect signaling messages including Binding Updates, > Binding Acknowledgement and return routability messages. IPsec may > also be used protect all tunneled data traffic. The Mobile IPv6- > IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to > setup the required IPsec security associations. The following > assumptions were made in [RFC-3775], [RFC-3963] and [RFC-4877] with > respect to the use of IKEv2 and IPsec. > > o There is only one primary care-of address per mobile node. > > o The primary care-of address is stored in the IPsec database for > tunnel encapsulation and decapsulation. > > o When the home agent receives a packet from the mobile node, the > source address is verified against the care-of address in the > corresponding binding cache entry. If the packet is a reverse > tunneled packet from the mobile node, the care-of address check is > done against the source address on the outer IPv6 header. The > reverse tunnel packet could either be a tunneled Home Test Init > message or tunneled data traffic to the correspondent node. > > o The mobile node runs IKEv2 (or IKEv1) with the home agent using > the care-of address. The IKE SA is based on the care-of address > of the mobile node. > > The above assumptions may not be valid when multiple care-of > addresses are used by the mobile node. In the following sections, > the main issues with the use of multiple care-of address with IPsec > are addressed. Good overview. > 9.1. Use of Care-of Address in the IKEv2 exchange > > For each home address the mobile node sets up security associations > with the home agent, the mobile node must pick one care-of address > and use that as the source address for all IKEv2 messages exchanged > to create and maintain the IPsec security associations associated > with the home address. The resultant IKEv2 security association is > created based on this care-of address. > > If the mobile node needs to change the care-of address, it just sends > a Binding Update with the care-of address it wants to use, with the > corresponding Binding Identifier mobility option, and with the 'K' > bit set. This will force the home agent to update the IKEv2 security > association to use the new care-of address. If the 'K' bit is not > supported on the mobile node or the home agent, the mobile node MUST > re-establish the IKEv2 security association with the new care-of > address. This will also result in new IPsec security associations > being setup for the home address. If I understand those two paragraphs correctly, the new CoA to be used by IKE upon movement is announced to the HA by sending a BU with K bit set and a single Binding Identifier mobility option. So, can you confirm the following: - until the HA receives such a BU with the K bit set, it considers that the IKE module on the MN does not support dynamic update of IKE_SA. - the MN cannot send multiple BID in a BU with the K bit set which means that multiple BU will be needed when the IKE module on the MN supports update. Instead of doing that, I think it would be easier and more efficient to consume a flag in the Binding Identifier Mobility option in order to express which CoA should be used for IKE communication with the remote IKE module. That way a perfectly sane MIPv6/IKE implementation (i.e. supporting IKE_SA update) would not need to send multiple BU just to express the IKE address to be used. In that paragraph, it should also be stated explicitly that the pointed CoA should be used for all the IKE exchanges between the MN and the HA, i.e. that it should also be used for the IKE packet sent from the HA for things related to tunnel mode SAs (even if that is probably expected). > 9.2. Transport Mode IPsec protected messages > > For Mobile IPv6 signaling message protected using IPsec in transport > mode, the use of a particular care-of address among multiple care-of > addresses does not matter for IPsec processing. > > The home agent processes Mobile Prefix Discovery messages with the > same rules of data packets described in Section 6.5. ok. > 9.3. Tunnel Mode IPsec protected messages > > The use of IPsec in tunnel mode with multiple care-of address > introduces a few issues that require changes to how the mobile node > and the home agent send and receive tunneled traffic. The route > optimization mechanism described in [RFC-3775] mandates the use of > IPsec protection in tunnel mode for the Home Test Init and Home Test > messages. The mobile node and the home agent may also choose to > protect all reverse tunneled payload traffic with IPsec in tunnel > mode. The following sections address multiple care-of address > support for these two types of messages. ok. > 9.3.1. Tunneled Home Test Init and Home Test messages > > The mobile node MAY use the same care-of address for all Home Test > Init messages sent reverse tunneled through the home agent. The > mobile node may use the same care-of address irrespective of which > correspondent node the Home Test Init message is being sent. RFC > 3775 requires the home agent to verify that the mobile node is using > the care-of address that is in the binding cache entry, when it > receives a reverse tunneled Home Test Init message. If a different > address is used as the source address, the message is silently > dropped by the home agent. This document requires the home agent > implementation to decapsulate and forward the Home Test Init message > as long as the source address is one of the care-of addresses in the > binding cache entry for the mobile node. > > When the home agent tunnels a Home Test message to the mobile node, > the care-of address used in the outer IPv6 header is not relevant to > the Home Test message. So regular IPsec tunnel encapsulation with > the care-of address known to the IPsec implementation on the home > agent is sufficient. > > 9.3.2. Tunneled Payload Traffic > > When the mobile sends and receives multiple traffic flows protected > by IPsec to different care-of addresses, the use of the correct > care-of address for each flow becomes important. Support for this > requires the following two considerations on the home agent. > > o When the home agent receives a reverse tunneled payload message > protected by IPsec in tunnel mode, the source address used in the > outer IPv6 header is irrelevant to IPsec, since the tunnel mode > security association is based on the addresses in the inner IPv6 > header. Therefore, the same IPsec security association can be > used for payload traffic tunneled from any of the care-of > addresses. Note that the care-of address used in the reverse > tunneld traffic can be different from the care-of address used tunneled > as the source address in the IKEv2 exchange. However, this does > not cause an issue due to the above mentioned reason. > > o For tunneled IPsec traffic from the home agent to the mobile node, > the IPsec implementation on the home agent will not be aware of > which care-of address to use when performing IPsec tunnel > encapsulation. The IPsec tunnel encapsulation is done based on the installed security policies. Either there is no security policy whose selectors match the traffic or there is a tunnel mode SP (whose selectors reflects a specific flow binding) in order for matching traffic to be sent securely to the peer *at a given CoA*. In any case, the tunnel SP will reference the given CoA as tunnel endpoints. The point being that this SP will require a specific SA with the CoA as destination and will never (at least w/o modifications to the IPsec stack) use another SA that reference another CoA. Simply put, you will be able to reuse a SA for various flow towards a given CoA but you will have to negotiate as many SA as CoA (in fact twice that value to cope with both directions). > The Mobile IP stack on the home agent, based on the binding > cache entries created by the mobile node, knows which care-of > address the packet belonging to a particular flow needs to > be tunneled to. Agree that it knows that but this is of no help ... > The destination address for the outer IP header > must either by conveyed dynamically per packet to the IPsec stack > when it performs the encapsulation seems quite a change to current IPsec processing if done in the IPsec stack. The problem will also remain at the receiver (the MN), because it will not have a matching SA. > or the Mobile IPv6 stack must get access to the packet after > IPsec processing is done and modify the destination address. Like the remapping rules I have in my IRO draft. Those changes to an IPsec stack are not easy to do. > The first option requires changes to the IPsec implementation. > In the second option, there is a need for special processing in > the forwarding function to replace the destination address on > the outer header with the correct care-of address. The same kind of thing is needed on the receiver too in order for the (destination) address to be remapped to that of the SA. > The exact technique to achieve the above is implementation > specific. Well, the clean way to do that is to setup one IPsec tunnel per CoA and do the same thing as usual when a CoA changes (update all associated SPs and the associated SA). As per RFC 3775 requirements, the IPsec stack is expected to support that kind of update (for instance, using MIGRATE/KMADDRESS mechanism). As for the negotiation of those tunnel SA, the usual way is to use the local endpoint address for the negotiation on the MN but I think it may be beneficial to avoid doing that and specifically use the address used by the already existing IKE_SA set up for the nego of the transport mode SA (if another IKE_SA is needed). More precisely, I think it would be good to decide and state that the IKE negotiation of the tunnel mode SA should be done using the CoA pointed by the "I" flag. Cheers, a+ ps: some authors of flow-binding draft are in the recipients to get there feedback on the proposals. From kuntz@lsiit.u-strasbg.fr Thu May 7 04:12: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 C4B2B3A65A5 for ; Thu, 7 May 2009 04:12:41 -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 KZ-meVRDwcNH for ; Thu, 7 May 2009 04:12:40 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.154]) by core3.amsl.com (Postfix) with ESMTP id 776133A67A8 for ; Thu, 7 May 2009 04:12:40 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n47BCp2s052603 for ; Thu, 7 May 2009 13:12:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 08421BCECD6 for ; Thu, 7 May 2009 13:12:51 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9CAZ8JDMw6Z for ; Thu, 7 May 2009 13:12:50 +0200 (CEST) Received: from frynet.u-strasbg.fr (frynet.u-strasbg.fr [130.79.91.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kuntz) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 211B0BCECC7 for ; Thu, 7 May 2009 13:12:50 +0200 (CEST) Message-Id: From: Romain KUNTZ To: mext In-Reply-To: <87hc0157z1.fsf@small.ssi.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 7 May 2009 13:12:48 +0200 References: <49EF37D8.2010408@it.uc3m.es> <49FAC1A2.7060206@it.uc3m.es> <87hc0157z1.fsf@small.ssi.corp> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [130.79.200.154]); Thu, 07 May 2009 13:12:51 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9339/Thu May 7 09:30:50 2009 on mr4.u-strasbg.fr X-Virus-Status: Clean Subject: Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-mip6-hareliability-04 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, 07 May 2009 11:12:41 -0000 Hi, On 2009/05/04, at 15:10, Arnaud Ebalard wrote: > That been said, at some point during the reading, I started > considering > that the most interesting review would be (as usual) from someone that > would have tried implementing *and testing* the protocol. Ryuji, are > you > aware of some tentative implementation or is it only a pure spec at > the > moment? I know there is an implementation of RFC5142 and draft-ietf-mip6- hareliability-04 for UMIP 0.4 for Linux. It was implemented as part of a project I joined. I think I can ask whether the code can be disclosed or not, if someone has interest. Cheers, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr LSIIT - Networks and Protocols Team http://clarinet.u-strasbg.fr/~kuntz/ From arno@natisbad.org Thu May 7 04:21: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 ED1523A67B6 for ; Thu, 7 May 2009 04:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 UuxpRp3heyVS for ; Thu, 7 May 2009 04:21:41 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 229213A6B20 for ; Thu, 7 May 2009 04:21:41 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M21gv-0006k5-UA; Thu, 07 May 2009 13:23:06 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Romain KUNTZ References: <49EF37D8.2010408@it.uc3m.es> <49FAC1A2.7060206@it.uc3m.es> <87hc0157z1.fsf@small.ssi.corp> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090507:kuntz@lsiit.u-strasbg.fr::KihWxbGlKpNvYkqx:00000000000000000000000000000000000003JJD X-Hashcash: 1:20:090507:mext@ietf.org::jcpO6gp+ti0ObDzy:00007tTw Date: Thu, 07 May 2009 13:23:53 +0200 In-Reply-To: (Romain KUNTZ's message of "Thu, 7 May 2009 13:12:48 +0200") Message-ID: <87skjh40mu.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext Subject: Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-mip6-hareliability-04 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, 07 May 2009 11:21:42 -0000 Hi Romain, Romain KUNTZ writes: > I know there is an implementation of RFC5142 and draft-ietf-mip6- > hareliability-04 for UMIP 0.4 for Linux. It was implemented as part of > a project I joined. I think I can ask whether the code can be > disclosed or not, if someone has interest. I'd be interested to look at it and possibly (depending on the size) maintain it (if it is not done already) with the other patches I have for UMIP. Do you happen to know how far the IKE/IPsec support goes in the pacth? Cheers, a+ From julien.laganier.ietf@googlemail.com Thu May 7 05:51: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 0AE5B3A69D6 for ; Thu, 7 May 2009 05:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmjYPqaNiR+9 for ; Thu, 7 May 2009 05:51:37 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id AF52A28C294 for ; Thu, 7 May 2009 05:51:15 -0700 (PDT) Received: by fxm2 with SMTP id 2so762949fxm.37 for ; Thu, 07 May 2009 05:52:41 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=TFotKJ22OPyPeLDr6AsyJ8WMkd8jStU190BLKLEAdd8=; b=Rva2V/u5WGcA1KswGvklgeUHDtrHhL/coHTgjqCvER7agnG1vA28goiiU2BU6SjTBz k6vJehiUBEPo6KF4VeSoKG3HMp91dG7hpibxSBJnlBKGGOel6TDi7vhG3wSR8DDSpAtq GFGez+kGNzcEK0zlaC0qfPJ+ExHe258VLvVaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=LUNKwKbKIGbt6E9gn5BJ0AFGdegpWf2JuP7pc7TBg3CH/4y8vWbbrYezyaRDFVhHj5 LVBMK/QLV2QTEnyu0cLcO5Pxr7NNZrla3nnkS9YUGFILI41dbSL6LhRdMB/DrnXSRrGC jFOMiJ25sbtQ8exA++R58SMTEwXtiRZ3g2N90= Received: by 10.204.53.1 with SMTP id k1mr2399480bkg.50.1241700761015; Thu, 07 May 2009 05:52:41 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id y15sm34898fkd.3.2009.05.07.05.52.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 05:52:39 -0700 (PDT) From: Julien Laganier To: George Tsirtsis Date: Thu, 7 May 2009 14:52:42 +0200 User-Agent: KMail/1.9.10 References: <559691.25805.qm@web27804.mail.ukl.yahoo.com> <200905061710.47336.julien.laganier.IETF@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905071452.43067.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] binary filters draft 0 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, 07 May 2009 12:51:41 -0000 > Hi Julien, > > This is not a bad idea. We are increasing complexity though. One > thing that bothers me with bit based pointers is byte alignment, > which can no longer be assured. > > I think we should be careful not to go crazy with these. Pointers, in > their current simple form, already give increased flexibility to the > binary filters. > > If this flexibility proves insufficient some time in the future, we > can always come back and define another flow description sub-option > that it either allows for more complex pointers or offers more > flexibility in some other way. > > For now, I would prefer to keep it relatively simple. > > Thoughts? > > George Hello Georges, You're right - this one-size-fits-all pointer is way too complex. How about defining two pointers, a "bit pattern" to match on some bits on a byte boundary, and a "byte-word-range" one to match some byte-aligned field on a range basis. Rough strawmans would look like: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | End Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2a: Byte Word Range Pointer 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset | Pattern | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2b: Bit pattern Pointer Thoughts? --julien From brian.haley@hp.com Thu May 7 07:00:59 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 472883A7029 for ; Thu, 7 May 2009 07:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 wJ6OpJmCAxt3 for ; Thu, 7 May 2009 07:00:58 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by core3.amsl.com (Postfix) with ESMTP id 76CF73A6BC1 for ; Thu, 7 May 2009 07:00:38 -0700 (PDT) Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141]) by g1t0028.austin.hp.com (Postfix) with ESMTP id F1E181C83E; Thu, 7 May 2009 14:02:05 +0000 (UTC) Received: from [192.168.1.102] (squirrel.fc.hp.com [15.11.146.57]) by g5t0029.atlanta.hp.com (Postfix) with ESMTP id 4110910098; Thu, 7 May 2009 14:01:55 +0000 (UTC) Message-ID: <4A02E9C8.8070301@hp.com> Date: Thu, 07 May 2009 10:01:44 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Romain KUNTZ References: <49EF37D8.2010408@it.uc3m.es> <49FAC1A2.7060206@it.uc3m.es> <87hc0157z1.fsf@small.ssi.corp> <87skjh40mu.fsf@small.ssi.corp> In-Reply-To: <87skjh40mu.fsf@small.ssi.corp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-mip6-hareliability-04 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, 07 May 2009 14:00:59 -0000 Arnaud Ebalard wrote: > Hi Romain, > > Romain KUNTZ writes: > >> I know there is an implementation of RFC5142 and draft-ietf-mip6- >> hareliability-04 for UMIP 0.4 for Linux. It was implemented as part of >> a project I joined. I think I can ask whether the code can be >> disclosed or not, if someone has interest. > > I'd be interested to look at it and possibly (depending on the size) > maintain it (if it is not done already) with the other patches I have > for UMIP. I'd be interested as well since I was implementing this for Linux since I didn't see it in the mipv6-daemon git repo. Thanks, -Brian From julien.laganier.ietf@googlemail.com Thu May 7 07:14: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 4FCCE28C0F1 for ; Thu, 7 May 2009 07:14:12 -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 cRcJk1pch9Gv for ; Thu, 7 May 2009 07:14:11 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id BEDF43A6C9B for ; Thu, 7 May 2009 07:14:10 -0700 (PDT) Received: by fxm2 with SMTP id 2so814000fxm.37 for ; Thu, 07 May 2009 07:15:36 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=6lq6DdT7AG1GnFf0g2RMnKOZq+75COcpiiyvl/3V1j4=; b=emDwq+996BO2veaiyzbYYqXSthyeM2HvsNGW492aDQOSScnEMp03XRSEmDJ4ZqjHTE YofPeOifZn5hiFX0CPnrnqJSwPcywYHaSeqpLmn44NHVF5paMOml2P4Jb+iH3BMypgwq CpcvmGlYAOBipe+/DUt2qWQAfqnbGoFrOjm8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=BXkGiQ8l++UBUh8dl9UvVa1zBeCw810tNGWLC8haCZXIOLmLTvFd4Uf5h10V4Ca+xW UCJBIdvKZ6/rVHufbatq8xpMIqNOLNnCADQNk+TXodcEXrKl2AvFoymDVY8inl/SZBgd 9eBE5OtLFZ+7varZMfFjD+n3Bel90O24drLO4= Received: by 10.86.65.18 with SMTP id n18mr2609405fga.25.1241705736024; Thu, 07 May 2009 07:15:36 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id d6sm229344fga.12.2009.05.07.07.15.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 07:15:35 -0700 (PDT) From: Julien Laganier To: George Tsirtsis Date: Thu, 7 May 2009 16:15:38 +0200 User-Agent: KMail/1.9.10 References: <559691.25805.qm@web27804.mail.ukl.yahoo.com> <200905071452.43067.julien.laganier.IETF@googlemail.com> In-Reply-To: <200905071452.43067.julien.laganier.IETF@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905071615.39029.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] binary filters draft 0 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, 07 May 2009 14:14:12 -0000 On Thursday 07 May 2009, Julien Laganier wrote: > > Hi Julien, > > > > This is not a bad idea. We are increasing complexity though. One > > thing that bothers me with bit based pointers is byte alignment, > > which can no longer be assured. > > > > I think we should be careful not to go crazy with these. Pointers, > > in their current simple form, already give increased flexibility to > > the binary filters. > > > > If this flexibility proves insufficient some time in the future, we > > can always come back and define another flow description sub-option > > that it either allows for more complex pointers or offers more > > flexibility in some other way. > > > > For now, I would prefer to keep it relatively simple. > > > > Thoughts? > > > > George > > Hello Georges, > > You're right - this one-size-fits-all pointer is way too complex. How > about defining two pointers, a "bit pattern" to match on some bits on > a byte boundary, and a "byte-word-range" one to match some > byte-aligned field on a range basis. > > Rough strawmans would look like: Of course I messed up the second one for bit mattern, see an update=20 below. =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 =A0 =A0 =A0 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 Offset =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Length =A0 =A0 | =A0 =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =A0 =A0 =A0| =A0 =A0 =A0Start Value ... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 End Value ... =A0 =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Figure 2a: Byte = Word Range Pointer =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 =A0 =A0 =A0 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 Offset =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Mask =A0 =A0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Figure 2b: Bit p= attern Pointer =2D-julien From julien.laganier.ietf@googlemail.com Thu May 7 07:55: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 2DE7F3A70E1 for ; Thu, 7 May 2009 07:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VF8v14QoCRX for ; Thu, 7 May 2009 07:55:17 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id D22253A6F6A for ; Thu, 7 May 2009 07:55:16 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so103469fga.18 for ; Thu, 07 May 2009 07:56:41 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=rOMi+55h60j2Dk+4iLS0Rxo+TcKtBa+tS0UFnZJN1YQ=; b=NJP2lM/Vv3zM4SP37843slzpcLn/LXzupYmdjThmS1B3o4/zjVAYzhOI0buYXdccui RB/KxFWWkw3PgUfCP3w9qbikMaF0DidmWigzBvajjOungBARLroA5EX2GhkOzYe/r9FD dFO8rCmvkhHXXLUYAPvwrde+ALEtnBDEl+dOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=YgXiNTLZImfw4PRB3+ik2QoZFqyOnaTrYnZWKA01ZabhO6zbqvvuDii2zTuulaGpdX /fv/MN1SAzuOklpQAI9Cy4gyp1xtgdiN+KPzjQZ+8qiLGoMgMthp/h/BSeP3CO+IwW6l opuxnnnxRqxWNdsTbjent8bN3jIheBWaHaqiM= Received: by 10.86.79.6 with SMTP id c6mr2558970fgb.52.1241708201320; Thu, 07 May 2009 07:56:41 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 12sm302996fgg.0.2009.05.07.07.56.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 07:56:40 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Thu, 7 May 2009 16:56:43 +0200 User-Agent: KMail/1.9.10 References: <296286.77052.qm@web27801.mail.ukl.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905071656.43806.julien.laganier.IETF@googlemail.com> Subject: Re: [MEXT] flow binding draft 2 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, 07 May 2009 14:55:18 -0000 Hello George, I looked at the draft and it is in very good shape. I have a quick question regarding the FID Priority: FID-PRI This is an 8-bit priority field to indicate the priority of a particular option. This field is needed in cases where two different flow descriptions in two different options overlap. The priority field decides which policy should be in those cases. A lower number in this field indicates a higher priority. Shouldn't we made explicit that each FID is assigned a unique priority? --julien From julien.laganier.ietf@googlemail.com Thu May 7 08:20: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 E083C3A6FF5 for ; Thu, 7 May 2009 08:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-SxhJznPK57 for ; Thu, 7 May 2009 08:20:17 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 338A33A7002 for ; Thu, 7 May 2009 08:20:17 -0700 (PDT) Received: by fxm2 with SMTP id 2so855988fxm.37 for ; Thu, 07 May 2009 08:21:41 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=XfODl3w22a7wHZSPQwNYKYgYl0JIdj8V+jEa8hcXpcs=; b=NW1aoWFvtGyDJQSs3KDcUJd/tpPFoZ5izq7K6Q7vY/fOwYomkO54DU4pDag7afAFK6 +C5lGbKO8SSmBCkOR4L5t2ox9kKUN8AZO/AvE//eCBcjHdJikLxET6qKYw2d7yhzn3Kp KCQT6NKmXKWOw9sPf0pqzJ2NIMJCWPLTZ9KLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=B/755fnwCAsF66aWS+04Z3tfRbFP6pJV9T5DFdWWSOMdITyCF4DdCzGP63uu0TQkrV TDPt95SvQ9E92q0usl9GvP0FmbDz80ahOPQAhPgCKiHnYtFgfru5qZbDyxKy+SWWtC0k ctda+7qHD7Z/COvD9XJb97GbhGN6Lx9sTIP/4= Received: by 10.86.80.5 with SMTP id d5mr2650096fgb.6.1241709701254; Thu, 07 May 2009 08:21:41 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id d6sm344453fga.22.2009.05.07.08.21.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 08:21:40 -0700 (PDT) From: Julien Laganier To: George Tsirtsis Date: Thu, 7 May 2009 17:21:37 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905071721.38234.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 07 May 2009 15:20:19 -0000 On Thursday 07 May 2009, George Tsirtsis wrote: > Hey Julien, > > I think what you propose is still difficult. > This is already a very complex option given that all fields are > optional and their presence is indicated by flags. > Then at the end of the option we have pointers of which we can have > many. Calculating the length of each of these is already tricky, but > adding a 2nd type of pointer makes it even harder. > How do you know which type of pointer it is?=20 Two solutions, either 1) a pointer is typed with the first bit=20 indicating its type (0 is byte-word-range, 1 is bit-pattern), or 2) we=20 include two fields in the base header to indicate the number of=20 byte-word-range pointers, and another to indicate the number of=20 bit-pattern pointers. =20 > and how do you know the length of the 2nd one given your format? The 2nd one has a fixed length since it only indicates matching on a=20 pattern on one byte: 2(offset) + 1(mask) + 1 (value) =3D 4. > Do you really think any of this is necessary or did the pointers idea > just excited your imagination? :-) Am I allowed to reply "both" :-) Since I do not see the above as overly complex it could make sense to=20 allow for possible future usages. But I would not insist if nobody=20 thinks it's useful (and see below) I've been searching and I found one that might or might not look=20 realistic :-)=20 Suppose we have an SCTP assocation running a multiple streams running=20 inside, I'd like to be able to n-cast only the SCTP packets that=20 contains only unordered data chunks, as indicated by the U bit within a=20 data chunk: The (U)nordered bit, if set to '1', indicates that this is an unordered DATA chunk, and there is no Stream Sequence Number assigned to this DATA chunk. Therefore, the receiver MUST ignore the Stream Sequence Number field. > To be honest, the pointers are probably just a 'cool' thing that is > likely to be used *very* infrequently. The only reason I came up with > it is to remove the perception that binary filters are inflexible, > when compared to Conny's text based filters. Should we remove the pointers all together then? =2D-julien > On Thu, May 7, 2009 at 3:15 PM, Julien Laganier > > wrote: > > On Thursday 07 May 2009, Julien Laganier wrote: > >> > Hi Julien, > >> > > >> > This is not a bad idea. We are increasing complexity though. One > >> > thing that bothers me with bit based pointers is byte alignment, > >> > which can no longer be assured. > >> > > >> > I think we should be careful not to go crazy with these. > >> > Pointers, in their current simple form, already give increased > >> > flexibility to the binary filters. > >> > > >> > If this flexibility proves insufficient some time in the future, > >> > we can always come back and define another flow description > >> > sub-option that it either allows for more complex pointers or > >> > offers more flexibility in some other way. > >> > > >> > For now, I would prefer to keep it relatively simple. > >> > > >> > Thoughts? > >> > > >> > George > >> > >> Hello Georges, > >> > >> You're right - this one-size-fits-all pointer is way too complex. > >> How about defining two pointers, a "bit pattern" to match on some > >> bits on a byte boundary, and a "byte-word-range" one to match some > >> byte-aligned field on a range basis. > >> > >> Rough strawmans would look like: > > > > Of course I messed up the second one for bit mattern, see an update > > below. > > > > =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 > > 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 =C2= =A0 =C2=A0 =C2=A0 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Offset =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 > > =C2=A0Length =C2=A0 =C2=A0 | =C2=A0 =C2=A0 > > =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0Start Value ... =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 > > =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = | =C2=A0 =C2=A0 =C2=A0 =C2=A0 End Value ... =C2=A0 =C2=A0 > > =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2a: Byte Word > > Range Pointer > > > > =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 > > 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 =C2= =A0 =C2=A0 =C2=A0 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Offset =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 > > =C2=A0Mask =C2=A0 =C2=A0=C2=A0 =C2=A0| =C2=A0 =C2=A0 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > =C2=A0 =C2=A0 | =C2=A0 Value =C2=A0 =C2=A0 =C2=A0 | > > =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+ > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2b: Bit pattern > > Pointer > > > > --julien =2D-=20 =2D-julien From tsirtsis@googlemail.com Thu May 7 08:53: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 6B6D83A711D for ; Thu, 7 May 2009 08:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.137, 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 VBpz1t2cu7Fp for ; Thu, 7 May 2009 08:53:37 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 99D9D3A7121 for ; Thu, 7 May 2009 08:53:03 -0700 (PDT) Received: by fxm2 with SMTP id 2so875889fxm.37 for ; Thu, 07 May 2009 08:54:29 -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=D8wMvaEaPDwN66YGlR3LqFO/Cpwas1YAAfenQI7HtMs=; b=LNpRzn+S0/nOMRtzU625JogR6GwYIzoKuhn6bR0dq0z6rFQM/5VZMECgTRan6nVBWg 6nC6uaIYglSlIUMGNduzgePW8C6MBclGXJEbkMfKRxC+K8MpKRC5VBps0P2z7iQ52n7g fa8UnjEYIIhvDnO+YVlU3UlVLq83wuib5v+rg= 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=BvXHmfGiE8VOPPfKaJokYDOfmThO3CD+4uWkZQI6wXeTX/b/6i4FeGRHPAh0UmSMdB lhiJJVWK27KC0CxsOqHyc1tAnQJLQDawwtCpvxjlivLjuviqyFpIm1yQ8ytoMwKf1P4M xmedF80ylfINA0HXZ+Nq1+hTsrKCxm8s+1RfU= MIME-Version: 1.0 Received: by 10.223.105.72 with SMTP id s8mr1718893fao.41.1241711668974; Thu, 07 May 2009 08:54:28 -0700 (PDT) In-Reply-To: <200905071721.38234.julien.laganier.IETF@googlemail.com> References: <200905071721.38234.julien.laganier.IETF@googlemail.com> Date: Thu, 7 May 2009 16:54:28 +0100 Message-ID: From: George Tsirtsis To: Julien Laganier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 07 May 2009 15:53:38 -0000 Julien already assured me he is not in the habit of forwarding private e-mails back to the public list :-) In any case, I took this off line to see if I can resolve the issues directly with Julien before coming back to the list so, no harm done. It seems that the granularity of pointers needs to be discussed further which is fine. We also need to discuss whether the granularity of the pointers described in the draft provide sufficient flexibility, in which case I believe that text based flow description offers little further advantage. I maintain that such flexibility, whether provided by pointers or by other means, is something that is not often going to be needed. At least pointers, and the fact that multiple of them can be present in the binary flow description, provide a powerful way of matching virtually any field in the packet, in the rare case this is necessary; while limitting verbosity in all cases. Thoughts? George On Thu, May 7, 2009 at 4:21 PM, Julien Laganier wrote: > On Thursday 07 May 2009, George Tsirtsis wrote: >> Hey Julien, >> >> I think what you propose is still difficult. >> This is already a very complex option given that all fields are >> optional and their presence is indicated by flags. >> Then at the end of the option we have pointers of which we can have >> many. Calculating the length of each of these is already tricky, but >> adding a 2nd type of pointer makes it even harder. >> How do you know which type of pointer it is? > > Two solutions, either 1) a pointer is typed with the first bit > indicating its type (0 is byte-word-range, 1 is bit-pattern), or 2) we > include two fields in the base header to indicate the number of > byte-word-range pointers, and another to indicate the number of > bit-pattern pointers. > >> and how do you know the length of the 2nd one given your format? > > The 2nd one has a fixed length since it only indicates matching on a > pattern on one byte: 2(offset) + 1(mask) + 1 (value) =3D 4. > >> Do you really think any of this is necessary or did the pointers idea >> just excited your imagination? :-) > > Am I allowed to reply "both" :-) > > Since I do not see the above as overly complex it could make sense to > allow for possible future usages. But I would not insist if nobody > thinks it's useful (and see below) > > I've been searching and I found one that might or might not look > realistic :-) > > Suppose we have an SCTP assocation running a multiple streams running > inside, I'd like to be able to n-cast only the SCTP packets that > contains only unordered data chunks, as indicated by the U bit within a > data chunk: > > =C2=A0 =C2=A0 =C2=A0The (U)nordered bit, if set to '1', indicates that th= is is an > =C2=A0 =C2=A0 =C2=A0unordered DATA chunk, and there is no Stream Sequence= Number > =C2=A0 =C2=A0 =C2=A0assigned to this DATA chunk. =C2=A0Therefore, the rec= eiver MUST ignore > =C2=A0 =C2=A0 =C2=A0the Stream Sequence Number field. > >> To be honest, the pointers are probably just a 'cool' thing that is >> likely to be used *very* infrequently. The only reason I came up with >> it is to remove the perception that binary filters are inflexible, >> when compared to Conny's text based filters. > > Should we remove the pointers all together then? > > --julien > >> On Thu, May 7, 2009 at 3:15 PM, Julien Laganier >> >> wrote: >> > On Thursday 07 May 2009, Julien Laganier wrote: >> >> > Hi Julien, >> >> > >> >> > This is not a bad idea. We are increasing complexity though. One >> >> > thing that bothers me with bit based pointers is byte alignment, >> >> > which can no longer be assured. >> >> > >> >> > I think we should be careful not to go crazy with these. >> >> > Pointers, in their current simple form, already give increased >> >> > flexibility to the binary filters. >> >> > >> >> > If this flexibility proves insufficient some time in the future, >> >> > we can always come back and define another flow description >> >> > sub-option that it either allows for more complex pointers or >> >> > offers more flexibility in some other way. >> >> > >> >> > For now, I would prefer to keep it relatively simple. >> >> > >> >> > Thoughts? >> >> > >> >> > George >> >> >> >> Hello Georges, >> >> >> >> You're right - this one-size-fits-all pointer is way too complex. >> >> How about defining two pointers, a "bit pattern" to match on some >> >> bits on a byte boundary, and a "byte-word-range" one to match some >> >> byte-aligned field on a range basis. >> >> >> >> Rough strawmans would look like: >> > >> > Of course I messed up the second one for bit mattern, see an update >> > below. >> > >> > =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 0 =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 = =C3=82=C2=A0 1 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82= =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82 >> > 2 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 3 =C3=82=C2=A0 =C3=82=C2= =A0 =C3=82=C2=A0 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 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82= =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0 =C3=82 >> > =C3=82=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =C3=82= =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82 >> > =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0| =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0= Offset =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 = =C3=82=C2=A0 =C3=82=C2=A0| =C3=82 >> > =C3=82=C2=A0Length =C3=82=C2=A0 =C3=82=C2=A0 | =C3=82=C2=A0 =C3=82 >> > =C3=82=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >> > =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0| =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0Start Value ... =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2= =A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82= =C2=A0 =C3=82 >> > =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0| =C3=82=C2=A0= =C3=82 >> > =C3=82=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >> > =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0| =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 | =C3=82=C2= =A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 End Value ... =C3=82=C2=A0 =C3= =82 >> > =C3=82=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > >> > =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 = =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0Figure 2a: Byte Word >> > Range Pointer >> > >> > =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 0 =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 = =C3=82=C2=A0 1 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82= =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82 >> > 2 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 3 =C3=82=C2=A0 =C3=82=C2= =A0 =C3=82=C2=A0 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 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82= =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0 =C3=82 >> > =C3=82=C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =C3=82= =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82 >> > =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0| =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0= Offset =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 = =C3=82=C2=A0 =C3=82=C2=A0| =C3=82 >> > =C3=82=C2=A0Mask =C3=82=C2=A0 =C3=82=C2=A0=C3=82=C2=A0 =C3=82=C2=A0| = =C3=82=C2=A0 =C3=82 >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > =C3=82=C2=A0 =C3=82=C2=A0 | =C3=82=C2=A0 Value =C3=82=C2=A0 =C3=82=C2= =A0 =C3=82=C2=A0 | >> > =C3=82=C2=A0 =C3=82=C2=A0 +-+-+-+-+-+-+-+-+ >> > >> > =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3= =82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 = =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0Figure 2b: Bit pattern >> > Pointer >> > >> > --julien > > > > -- > --julien > From tsirtsis@googlemail.com Thu May 7 09:17: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 58A533A70F5 for ; Thu, 7 May 2009 09:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.135, 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 twxEFVNBLehT for ; Thu, 7 May 2009 09:17:56 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id D1E5B28C16F for ; Thu, 7 May 2009 09:15:59 -0700 (PDT) Received: by fxm2 with SMTP id 2so890229fxm.37 for ; Thu, 07 May 2009 09:17:25 -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=Mhu3qsGswE0eiKBJA30pDgYr8jhckBDd6QrtyQ/ZFFU=; b=o2Db/Ls697/Rl9wSDZtKJ9q1LA068dlR/Jco7MgOqev2/ev851I+JBje92/nabSTrp QLnIoTA+Y4cc/tXfYhI0ijOiKI/453nDBRzzQCBAmNJpa9I7e66wfr77Z9Nw+7YiSHvb AdbGjNAp1HSQ9Ys5DDr3kssC9YCukEL/Zthu4= 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=ArRjFex8zuWg/o7tnNpgl76YURmMCv2t04WJ54ZPyhYny6rWpyd7Dp/49Qr2yS5wct Ol+L8QbfHfr/k3DiqMNa8srvIE/sS9sNaNNluGsUSPvwmuOdKy9p6hEA6GMB8fY9WCWT K8XefYOjxxg5tWmChkf7TLaDmrYnHctG8idOU= MIME-Version: 1.0 Received: by 10.223.108.75 with SMTP id e11mr1281737fap.97.1241713045298; Thu, 07 May 2009 09:17:25 -0700 (PDT) In-Reply-To: <200905071656.43806.julien.laganier.IETF@googlemail.com> References: <296286.77052.qm@web27801.mail.ukl.yahoo.com> <200905071656.43806.julien.laganier.IETF@googlemail.com> Date: Thu, 7 May 2009 17:17:25 +0100 Message-ID: From: George Tsirtsis To: Julien Laganier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 07 May 2009 16:17:57 -0000 Two FIDs can have the same FID-PRI as long as they do not overlap. If one rules says match all UDP and the other says match all TCP, then the rules do not overlap and the can have the same FID-PRI since the result will be the same no matter which order they are looked at. If two rules overlap, however, they need different FID-PRI since then the MN needs to define which one to be looked at first. e.g., one rules is match all UDP and the other is match sourceAddr=3DIPx then the rules overlap since there might be packets that are UDP and also have sourceAddr=3DIPx. In this case the order is important so the FID-PRI should be different. If the FID-PRI is the same then it means that the rules will be put in whatever order the received decide (which could be random). If this is not well described in the draft we can probably expand on it...I have the sense I wrote again about this recently but I cannot remember if it was on the mailing list or in some other context; my brain's efficiency goes down as the week progresses :-/ George On Thu, May 7, 2009 at 3:56 PM, Julien Laganier wrote: > Hello George, > > I looked at the draft and it is in very good shape. I have a quick > question regarding the FID Priority: > > =C2=A0 =C2=A0 =C2=A0FID-PRI > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is an 8-bit priority field to indicate t= he priority of a > =C2=A0 =C2=A0 =C2=A0 =C2=A0 particular option. =C2=A0This field is needed= in cases where two > =C2=A0 =C2=A0 =C2=A0 =C2=A0 different flow descriptions in two different = options overlap. > =C2=A0 =C2=A0 =C2=A0 =C2=A0 The priority field decides which policy shoul= d be in those > =C2=A0 =C2=A0 =C2=A0 =C2=A0 cases. =C2=A0A lower number in this field ind= icates a higher > =C2=A0 =C2=A0 =C2=A0 =C2=A0 priority. > > Shouldn't we made explicit that each FID is assigned a unique priority? > > --julien > From nicolas@montavont.net Thu May 7 09:26:49 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 869983A6D91 for ; Thu, 7 May 2009 09:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 gdpaKxqeK69t for ; Thu, 7 May 2009 09:26:48 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 27E8028C21F for ; Thu, 7 May 2009 09:25:51 -0700 (PDT) Received: by ewy24 with SMTP id 24so1206441ewy.37 for ; Thu, 07 May 2009 09:27:12 -0700 (PDT) Received: by 10.210.114.15 with SMTP id m15mr2406838ebc.46.1241713632764; Thu, 07 May 2009 09:27:12 -0700 (PDT) Received: from dhcp-salsa-i163.rennes.enst-bretagne.fr (pat39-intra.rennes.enst-bretagne.fr [192.44.77.39]) by mx.google.com with ESMTPS id 10sm573136eyz.41.2009.05.07.09.27.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 May 2009 09:27:12 -0700 (PDT) Message-Id: <5625D158-7A0C-4296-BDA8-1010604CDC31@montavont.net> From: Nicolas Montavont To: George Tsirtsis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 7 May 2009 18:27:04 +0200 References: <296286.77052.qm@web27801.mail.ukl.yahoo.com> <200905071656.43806.julien.laganier.IETF@googlemail.com> X-Mailer: Apple Mail (2.930.3) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 07 May 2009 16:26:49 -0000 George, Julien, How can you make sure that two rules won't overlap? In the example you mention it is obvious, but if you are going into more complicated rule, I am not sure we can always know which rule can overlap. I think we should avoid to have the same FID-PRI for different FIDs just to make sure (and then clarify it in the draft). Nicolas On May 7, 2009, at 6:17 PM, George Tsirtsis wrote: > Two FIDs can have the same FID-PRI as long as they do not overlap. If > one rules says match all UDP and the other says match all TCP, then > the rules do not overlap and the can have the same FID-PRI since the > result will be the same no matter which order they are looked at. > > If two rules overlap, however, they need different FID-PRI since then > the MN needs to define which one to be looked at first. e.g., one > rules is match all UDP and the other is match sourceAddr=IPx then the > rules overlap since there might be packets that are UDP and also have > sourceAddr=IPx. In this case the order is important so the FID-PRI > should be different. If the FID-PRI is the same then it means that the > rules will be put in whatever order the received decide (which could > be random). > > If this is not well described in the draft we can probably expand on > it...I have the sense I wrote again about this recently but I cannot > remember if it was on the mailing list or in some other context; my > brain's efficiency goes down as the week progresses :-/ > > George > > On Thu, May 7, 2009 at 3:56 PM, Julien Laganier > wrote: >> Hello George, >> >> I looked at the draft and it is in very good shape. I have a quick >> question regarding the FID Priority: >> >> FID-PRI >> >> This is an 8-bit priority field to indicate the priority of a >> particular option. This field is needed in cases where two >> different flow descriptions in two different options overlap. >> The priority field decides which policy should be in those >> cases. A lower number in this field indicates a higher >> priority. >> >> Shouldn't we made explicit that each FID is assigned a unique >> priority? >> >> --julien >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From tsirtsis@googlemail.com Thu May 7 09:35: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 11E693A70EE for ; Thu, 7 May 2009 09:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.133, 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 mbDj-GcsRuCk for ; Thu, 7 May 2009 09:35:28 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 4DED53A70F5 for ; Thu, 7 May 2009 09:34:11 -0700 (PDT) Received: by fxm2 with SMTP id 2so900736fxm.37 for ; Thu, 07 May 2009 09:35:35 -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=ZT+ezhg+xSSFB/d4OuxVpLSlI1g/wnE2ZF1pNEh+dPU=; b=JoW1ZBbKvbDW8wF8zGnPOjh8P8nlaLfS/mS7uUqYKMqkdCe694bRJB/jxjmpvNhCDS /gYLd0cXAc/FrxEGkLpRWYzmX4Wg0myrRz9llf8rR5B5nQhEzhPbma+6bnJgRCbkNa/R eUT84MFpu5tBNnNKFjqRZB/TlF82qPI4gS1K4= 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=Oi3pH6yJTH0RmVakIxzUxFQQks+O63N/LPdUnjXulqjdRMwCiXsxPyx1fw6R/4bBPV nta6B314ojQHATNsV3eEaaKg1BezEMLkMoXPeAjorU0YC4rJMlb/dyYjSXzezEsKxlba OoL2Yf5bL8WYq4Yr9DW+7fqqXlQLtJ9S4IuR0= MIME-Version: 1.0 Received: by 10.223.126.1 with SMTP id a1mr1730309fas.78.1241714135248; Thu, 07 May 2009 09:35:35 -0700 (PDT) In-Reply-To: <5625D158-7A0C-4296-BDA8-1010604CDC31@montavont.net> References: <296286.77052.qm@web27801.mail.ukl.yahoo.com> <200905071656.43806.julien.laganier.IETF@googlemail.com> <5625D158-7A0C-4296-BDA8-1010604CDC31@montavont.net> Date: Thu, 7 May 2009 17:35:35 +0100 Message-ID: From: George Tsirtsis To: Nicolas Montavont Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 07 May 2009 16:35:36 -0000 Hmmm, We could require different FID-PRI for each rule but all the classifiers I know of (in several different OSs) allow such priorities to be the same for the reasons I described. I am not sure why we would want to do this differently. It would likely confuse people familiar with classifiers without any reason. George On Thu, May 7, 2009 at 5:27 PM, Nicolas Montavont w= rote: > George, Julien, > > How can you make sure that two rules won't overlap? > In the example you mention it is obvious, but if you are going into more > complicated rule, I am not sure we can always know which rule can overlap= . > > I think we should avoid to have the same FID-PRI for different FIDs just = to > make sure (and then clarify it in the draft). > > Nicolas > > On May 7, 2009, at 6:17 PM, George Tsirtsis wrote: > >> Two FIDs can have the same FID-PRI as long as they do not overlap. If >> one rules says match all UDP and the other says match all TCP, then >> the rules do not overlap and the can have the same FID-PRI since the >> result will be the same no matter which order they are looked at. >> >> If two rules overlap, however, they need different FID-PRI since then >> the MN needs to define which one to be looked at first. e.g., one >> rules is match all UDP and the other is match sourceAddr=3DIPx then the >> rules overlap since there might be packets that are UDP and also have >> sourceAddr=3DIPx. In this case the order is important so the FID-PRI >> should be different. If the FID-PRI is the same then it means that the >> rules will be put in whatever order the received decide (which could >> be random). >> >> If this is not well described in the draft we can probably expand on >> it...I have the sense I wrote again about this recently but I cannot >> remember if it was on the mailing list or in some other context; my >> brain's efficiency goes down as the week progresses :-/ >> >> George >> >> On Thu, May 7, 2009 at 3:56 PM, Julien Laganier >> wrote: >>> >>> Hello George, >>> >>> I looked at the draft and it is in very good shape. I have a quick >>> question regarding the FID Priority: >>> >>> =C2=A0 =C2=A0FID-PRI >>> >>> =C2=A0 =C2=A0 =C2=A0 This is an 8-bit priority field to indicate the pr= iority of a >>> =C2=A0 =C2=A0 =C2=A0 particular option. =C2=A0This field is needed in c= ases where two >>> =C2=A0 =C2=A0 =C2=A0 different flow descriptions in two different optio= ns overlap. >>> =C2=A0 =C2=A0 =C2=A0 The priority field decides which policy should be = in those >>> =C2=A0 =C2=A0 =C2=A0 cases. =C2=A0A lower number in this field indicate= s a higher >>> =C2=A0 =C2=A0 =C2=A0 priority. >>> >>> Shouldn't we made explicit that each FID is assigned a unique priority? >>> >>> --julien >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > From AMUHANNA@nortel.com Thu May 7 12:49: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 981F63A6CF4 for ; Thu, 7 May 2009 12:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 uIwJy8RIK2Sa for ; Thu, 7 May 2009 12:49:47 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id ED5D63A6898 for ; Thu, 7 May 2009 12:49:46 -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 n47Joug16216; Thu, 7 May 2009 19:50:56 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, 7 May 2009 14:50:52 -0500 Message-ID: In-Reply-To: <200905071132.36973.julien.laganier.IETF@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Binding Revocation almost ready for IESG Thread-Index: AcnO9sVR9cTLMTwdQ1GgPu1FD+lnTAAEbwpw References: <200905071132.36973.julien.laganier.IETF@googlemail.com> From: "Ahmad Muhanna" To: "Julien Laganier" , Subject: Re: [MEXT] 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: Thu, 07 May 2009 19:49:48 -0000 Hello Julien, Thanks for the review. Please see comments inline. Regards, Ahmad > -----Original Message----- > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com]=20 > Sent: Thursday, May 07, 2009 4:33 AM > To: mext@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10); marcelo bagnulo braun > Subject: Binding Revocation almost ready for IESG >=20 > Folks, >=20 > I have reviewed the draft as a document shepherd and I=20 > believe it would be ready for IESG provided the comments=20 > below are addressed.=20 >=20 > Throughout the document > ----------------------- >=20 > =3D> Inconsitent usage of capitalized/uncapitalized Mobile IPv6=20 > and Proxy Mobile IPv6. I think everything should be capitalized. [Ahmad] Sure. >=20 > =3D> Inconsistent use of abbreviation and expanded forms in the=20 > text, e.g.=20 > MAG vs. mobile access gateway in the same sentence. I think=20 > you should choose, either define those upfront (e.g. by=20 > pointing to RFC5213) and stick to the abbreviation in rest of=20 > the text, or use the developped form everywhere. Includes=20 > MAG, LMA, BRI, BRA... [Ahmad] Will follow what RFC5213 and other IP mobility RFCs by using the expanded form. >=20 > In 3.2 > ------ >=20 > This mechanism enables the home domain to dynamically allow > the user to act upon the revocation message in order to recover its > interrupted mobile IPv6 services. >=20 > =3D> How about: >=20 > This mechanism enables the user to react to the revocation, e.g., =20 > reinstate its interrupted Mobile IPv6 services. [Ahmad] That is good. Will use that. >=20 > In 3.4 > ------ >=20 > Since the Mobile node does not participate in the mobility=20 > mechanism > in the case of PMIPv6, there are many scenarios where Binding > Revocation mechanism is needed to clean resources and make=20 > sure that > the mobility entities, e.g. MAG and LMA, are always synchronized >=20 > =3D> Should be i.e. instead of e.g. >=20 [Ahmad] Ok. > In 3.4.1. > --------- >=20 > In this case, the MAG could send a Router Advertisement message to > the MN with the home network prefix lifetime set to zero. >=20 > =3D> the PIO for the home network prefix has two lifetime, here=20 > I think you're talking about the valid lifetime. If so, please fix.=20 [Ahmad] Sure. >=20 > In 4. > ----- >=20 > Additionally, in the case when the LMA receives a BRI=20 > which indicates > a bulk termination where the (G) bit is set and the Revocation > Trigger field is set to "Per-Peer Policy", the LMA MUST verify that > the MAG sending the binding revocation indication message is > authorized to invoke Global revocation. >=20 > =3D> What sort of authorization do you have in mind here? Do=20 > you mean the LMA MUST verify that the MAG sending the binding=20 > revocation indication message is the one who currently owns=20 > the binding as per the BCE? If so better to be spelled out. > [Ahmad] That is given, a MAG which does not have or previously had created a BCE for the MN is allowed to send a BRI for that MN. However, what is meant here: is that MAG allowed to participate in Bulk revocation? We discussed this on the ML quite a bit and agreed that for a MAG to issue a global revocation which presumably impacts all sessions between the MAG and the LMA is something needs authorization and agreement between the two nodes. =20 > In 6.1. > ------- >=20 > Reserved and Per-MN Revocation Trigger: > 0 Reserved > 1 Unspecified > 2 Administrative Reason > 3 Inter-MAG Handover > 4 User Initiated Session(s) Termination > 5 Access Network Session(s) Termination > 6 Possible Out-of Sync BCE State >=20 > =3D> What is Possible Out-of Sync BCE State? The others are=20 > self-explaining, but this one I am unclear when it shall be=20 > sent, neither what it mean when I receive... Could we be more precise? [Ahmad] At anytime the LMA suspect that the state of the respected BCE is possibly out-of Sync at the MAG, the LMA sends this BRI to indicate that. One possible scenario that was discussed is when the LMA receives a BU which reference the same BCE. The MAG could either acknowledge, reject the BRI or possibly sends a Binding Lifetime extension PBU. Since we are at this, I would also bring the following: Based on some discussion on the ml before the last update, we collapsed all inter-MAG handoff B. R. Triggers in a single one "Inter-MAG Handover" and forgot that the granularity we had in rev. 04 and earlier is NEEDED for 3GPP2. Therefore, we need to bring those B. R. Triggers back to life, i.e.,=20 3 Inter-MAG Handoff - same Access Types 4 Inter-MAG Handoff - different Access Types 5 Inter-MAG - Unknown Handoff Also, at one point, I believe Joel suggested a more granular Revocation Triggers by classifying the B. R. Triggers as soft vs. Hard. It may be a good idea to adopt that classification where soft Binding Revocation Trigger indicates to the receiving node a possible update or a synchronization of the BCE between the sending node and the receiving one is required while the Hard means the receiving node will remove the BCE.=20 =20 >=20 > Global Revocation Trigger: > 128 Per-Peer Policy > 129 Revoking Mobility Node Local Policy >=20 > =3D> I find the names of these triggers confusing. I've looked=20 > at the descriptive text in the following section and I found=20 > it difficult to get a clear picture of what they are about.=20 > If I'm the only one confused I don't insist on any changes,=20 > but if not, maybe we could try to improve the description of=20 > global revocation... [Ahmad] Sure, we will clarify that a little more. In general, the Per-Peer Policy trigger is used ONLY when the BRI with the (G) bit set impacts all current BCEs between the LMA and the MAG. On the other hand, the Revoking Mobility Node Local Policy is used when the (G) bit is set but the content of the BRI targets only a specific group of BCEs. For example BCEs which share a specific realm in their MN-IDs, etc. >=20 > In 7. > ----- >=20 > 7. Binding Revocation Process Considerations >=20 > The following subsections describe the details of the binding > revocation generic process by the different mobility entities. >=20 > =3D> I do not like the title, the subsections contain normative=20 > text, thus these are everything but "considerations". Please=20 > change to something straightforward and relevant: "Generic=20 > Mobile Entity Operation" or sthg else. [Ahmad] No problem, will do. >=20 > In 7.1. > ------- >=20 > When sending a Binding Revocation message, the sending=20 > mobility node, > initiator, constructs the packet as it would any other Mobility > Header with the exception of setting the MH Type field to=20 > . >=20 > =3D> but later it says: >=20 > When a mobility entity initiates the binding revocation process by > sending a Binding Revocation Indication message, the initiator MUST > construct the BRI message as described in Section 6.1.=20 >=20 > =3D> and: >=20 > However, when the responder acknowledges the BRI message=20 > by sending a > BRA, the responder MUST construct the Binding Revocation > Acknowledgement as described in Section 6.2.=20 >=20 > =3D> so which one is it, as any other mobity header, or as per=20 > 6.1 and 6.2? [Ahmad] I guess we need to have the text tweaked a little. But, the Binding Revocation message is a mobility header and BRI format is defined in section 6.1. and for BRA in section 6.2. so It is built as any other mobility header + following the format specified in 6.1 or 6.2. >=20 > The mobility entity which initiates the revocation process MUST use > the underlying security association, e.g., IPsec SA, that has been > used to secure the mobile node binding registration signaling in > securing the BRI and BRA messages transmission with the responding > mobility entity. >=20 > =3D> Why do you restrict to "which initiates the revocation=20 > process"? Does it mean the responder uses no security=20 > association?! I think what we want to say is: "A mobility=20 > entity MUST secure BRI and BRA message with the same=20 > underlying security association, e.g., IPsec SA, that has=20 > been used to secure the mobile node binding registration=20 > signaling." No? [Ahmad] Perfect. Thanks! >=20 > In 7.2. > ------- >=20 > Upon receiving a packet carrying a Binding Revocation=20 > Indication, the > receiving mobility entity, responder, validates that the packet was > received protected with the security association that already has > been established with the mobility entity, initiator, and=20 > used during > the registration signaling phase, e.g., IPsec SA. >=20 > =3D> As above I think we'd get a clearer wording if we do not=20 > use responder neither initiator. Also the text doesn't cover=20 > the BRA. How > about: "Upon receiving a packet carrying a BRI or BRA, the=20 > receiving mobility entity verifies that the packet was=20 > received protected with the security association that has=20 > been used during the binding registration signaling phase,=20 > e.g., an IPsec SA." >=20 [Ahmad] Thx. Again! > In 14. > ------ >=20 > However, in the case when the MAG sends a BRI message with=20 > the Global > (G) bit is set and the Revocation Trigger field is set to "Per-Peer > policy", the LMA MUST verify that the MAG is authorized to use Per- > Peer Global Revocation. >=20 > =3D> Again I'd appreciate a better scoping of authorization in=20 > the above. >=20 > Hope that helps to improve the document before it hits IESG. [Ahmad] Indeed. Thanks for the comments Julien!=20 I will start working on the update and hopefully will be able to spin a quick one soon. >=20 > --julien >=20 From hesham@elevatemobile.com Thu May 7 19:17: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 B46903A6839 for ; Thu, 7 May 2009 19:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[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 SXOfvwkcRelh for ; Thu, 7 May 2009 19:17:01 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id E08603A69B6 for ; Thu, 7 May 2009 19:16:59 -0700 (PDT) Received: from [115.130.18.35] by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1M2FfL-0006lu-G5; Fri, 08 May 2009 12:18:26 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 08 May 2009 12:18:16 +1000 From: Hesham Soliman To: George Tsirtsis , Julien Laganier Message-ID: Thread-Topic: [MEXT] offline Re: binary filters draft 0 Thread-Index: AcnPgz7qEK21nsg340a/gf8cGvfXyA== 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] offline Re: binary filters draft 0 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, 08 May 2009 02:17:02 -0000 I agree that pointers are not going to be an essential, or frequently used, feature as far as we know today. On the other hand, allowing the capability is not very problematic. All the fields in the filter are optional anyway, so I don't see too much of a problem in allowing this and the worste outcom= e could be that it's never used. I don't have a strong opinion on which form of pointer to allow, but FWIW, the second option that Julien sent makes more sense than the first one he sent :) Hesham On 8/05/09 1:54 AM, "George Tsirtsis" wrote: > Julien already assured me he is not in the habit of forwarding private e-mails > back to the public list :-) In any case, I took this off line to see if I can > resolve the issues directly with Julien before coming back to the list so, no > harm done. It seems that the granularity of pointers needs to be > discussed further which is fine. We also need to discuss whether the > granularity of the pointers described in the draft provide sufficient > flexibility, in which case I believe that text based flow description offers > little further advantage. I maintain that such flexibility, whether provided > by pointers or by other means, is something that is not often going to be > needed. At least pointers, and the fact that multiple of them can be present > in the binary flow description, provide a powerful way of matching virtually > any field in the packet, in the rare case this is necessary; while limitting > verbosity in all cases. Thoughts? George On Thu, May 7, 2009 at 4:21 PM, > Julien Laganier wrote: > On Thursday 07 > May 2009, George Tsirtsis wrote: >> Hey Julien, >> >> I think what you propose > is still difficult. >> This is already a very complex option given that all > fields are >> optional and their presence is indicated by flags. >> Then at > the end of the option we have pointers of which we can have >> many. > Calculating the length of each of these is already tricky, but >> adding a 2nd > type of pointer makes it even harder. >> How do you know which type of pointer > it is? > > Two solutions, either 1) a pointer is typed with the first bit > > indicating its type (0 is byte-word-range, 1 is bit-pattern), or 2) we > > include two fields in the base header to indicate the number of > > byte-word-range pointers, and another to indicate the number of > bit-pattern > pointers. > >> and how do you know the length of the 2nd one given your > format? > > The 2nd one has a fixed length since it only indicates matching on > a > pattern on one byte: 2(offset) + 1(mask) + 1 (value) =3D 4. > >> Do you > really think any of this is necessary or did the pointers idea >> just excited > your imagination? :-) > > Am I allowed to reply "both" :-) > > Since I do not > see the above as overly complex it could make sense to > allow for possible > future usages. But I would not insist if nobody > thinks it's useful (and see > below) > > I've been searching and I found one that might or might not look > > realistic :-) > > Suppose we have an SCTP assocation running a multiple > streams running > inside, I'd like to be able to n-cast only the SCTP packets > that > contains only unordered data chunks, as indicated by the U bit within > a > data chunk: > > =A0 =A0 =A0The (U)nordered bit, if set to '1', indicates that > this is an > =A0 =A0 =A0unordered DATA chunk, and there is no Stream Sequence > Number > =A0 =A0 =A0assigned to this DATA chunk. =A0Therefore, the receiver MUST > ignore > =A0 =A0 =A0the Stream Sequence Number field. > >> To be honest, the > pointers are probably just a 'cool' thing that is >> likely to be used *very* > infrequently. The only reason I came up with >> it is to remove the perception > that binary filters are inflexible, >> when compared to Conny's text based > filters. > > Should we remove the pointers all together then? > > > --julien > >> On Thu, May 7, 2009 at 3:15 PM, Julien Laganier >> >> > wrote: >> > On Thursday 07 May 2009, > Julien Laganier wrote: >> >> > Hi Julien, >> >> > >> >> > This is not a bad > idea. We are increasing complexity though. One >> >> > thing that bothers me > with bit based pointers is byte alignment, >> >> > which can no longer be > assured. >> >> > >> >> > I think we should be careful not to go crazy with > these. >> >> > Pointers, in their current simple form, already give > increased >> >> > flexibility to the binary filters. >> >> > >> >> > If this > flexibility proves insufficient some time in the future, >> >> > we can always > come back and define another flow description >> >> > sub-option that it > either allows for more complex pointers or >> >> > offers more flexibility in > some other way. >> >> > >> >> > For now, I would prefer to keep it relatively > simple. >> >> > >> >> > Thoughts? >> >> > >> >> > George >> >> >> >> Hello > Georges, >> >> >> >> You're right - this one-size-fits-all pointer is way too > complex. >> >> How about defining two pointers, a "bit pattern" to match on > some >> >> bits on a byte boundary, and a "byte-word-range" one to match > some >> >> byte-aligned field on a range basis. >> >> >> >> Rough strawmans > would look like: >> > >> > Of course I messed up the second one for bit > mattern, see an update >> > below. >> > >> > =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2 >> > 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 =C2=A0 =C2=A0 =C2=A0 > 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 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2 >> > =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2 >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Offset =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0| =C2 >> > =C2=A0Length =C2=A0 =C2=A0 | =C2=A0 =C2 >> > > =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > =C2=A0 =C2=A0 > =C2=A0| =C2=A0 =C2=A0 =C2=A0Start Value ... =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2 >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2 >> > > =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > =C2=A0 =C2=A0 > =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 End Value ... =C2=A0 =C2 >> > > =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2a: Byte Word >> > Range Pointer >> > >> > =C2=A0 =C2=A0 =C2=A0 > 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2 >> > 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 =C2=A0 =C2=A0 =C2=A0 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2 >> > > =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2 >> > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Offset =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2 >> > =C2=A0Mask =C2=A0 =C2=A0=C2=A0 > =C2=A0| =C2=A0 =C2 >> >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > =C2=A0 =C2=A0 | > =C2=A0 Value =C2=A0 =C2=A0 =C2=A0 | >> > =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+ >> > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2b: Bit pattern >> > Pointer >> > >> > > --julien > > > > -- > > --julien > _______________________________________________ MEXT mailing > list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Thu May 7 19:20: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 DDFAC28C0EF for ; Thu, 7 May 2009 19:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 fIwxL9A-MMlf for ; Thu, 7 May 2009 19:20:16 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id E34123A6822 for ; Thu, 7 May 2009 19:20:15 -0700 (PDT) Received: from [115.130.18.35] by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1M2FiR-0006uX-D5; Fri, 08 May 2009 12:21:38 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 08 May 2009 12:21:30 +1000 From: Hesham Soliman To: Nicolas Montavont , George Tsirtsis Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnPg7KMiA/SFrPGxUy7ljYpOLAIQg== In-Reply-To: <5625D158-7A0C-4296-BDA8-1010604CDC31@montavont.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 08 May 2009 02:20:16 -0000 You're all correct, but I still don't see the issue, you always need to make sure that the receiver can break a tie, whichever option we choose. So if two rules overlap and have the same PRI (for whatever reason) the receiver just picks one over the other. The counter question to Nicolas' question below is: how can you really be sure, as a sender, that your priorities are always correct? :) you can't. Esepcially if the rule encompasses a lot of connections. Hesham On 8/05/09 2:27 AM, "Nicolas Montavont" wrote: > George, Julien, > > How can you make sure that two rules won't overlap? > In the example you mention it is obvious, but if you are going into > more complicated rule, I am not sure we can always know which rule can > overlap. > > I think we should avoid to have the same FID-PRI for different FIDs > just to make sure (and then clarify it in the draft). > > Nicolas > > On May 7, 2009, at 6:17 PM, George Tsirtsis wrote: > >> Two FIDs can have the same FID-PRI as long as they do not overlap. If >> one rules says match all UDP and the other says match all TCP, then >> the rules do not overlap and the can have the same FID-PRI since the >> result will be the same no matter which order they are looked at. >> >> If two rules overlap, however, they need different FID-PRI since then >> the MN needs to define which one to be looked at first. e.g., one >> rules is match all UDP and the other is match sourceAddr=IPx then the >> rules overlap since there might be packets that are UDP and also have >> sourceAddr=IPx. In this case the order is important so the FID-PRI >> should be different. If the FID-PRI is the same then it means that the >> rules will be put in whatever order the received decide (which could >> be random). >> >> If this is not well described in the draft we can probably expand on >> it...I have the sense I wrote again about this recently but I cannot >> remember if it was on the mailing list or in some other context; my >> brain's efficiency goes down as the week progresses :-/ >> >> George >> >> On Thu, May 7, 2009 at 3:56 PM, Julien Laganier >> wrote: >>> Hello George, >>> >>> I looked at the draft and it is in very good shape. I have a quick >>> question regarding the FID Priority: >>> >>> FID-PRI >>> >>> This is an 8-bit priority field to indicate the priority of a >>> particular option. This field is needed in cases where two >>> different flow descriptions in two different options overlap. >>> The priority field decides which policy should be in those >>> cases. A lower number in this field indicates a higher >>> priority. >>> >>> Shouldn't we made explicit that each FID is assigned a unique >>> priority? >>> >>> --julien >>> >> _______________________________________________ >> 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 w52006@huawei.com Thu May 7 20:31: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 37B923A6A75 for ; Thu, 7 May 2009 20:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 yce0CivJaJEy for ; Thu, 7 May 2009 20:31:41 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4AF2C3A706C for ; Thu, 7 May 2009 20:30:51 -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 <0KJB007BX32V2C@szxga03-in.huawei.com> for mext@ietf.org; Fri, 08 May 2009 11:30:32 +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 <0KJB008CV32VE0@szxga03-in.huawei.com> for mext@ietf.org; Fri, 08 May 2009 11:30:31 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJB00G6F32V2P@szxml04-in.huawei.com> for mext@ietf.org; Fri, 08 May 2009 11:30:31 +0800 (CST) Date: Fri, 08 May 2009 11:30:30 +0800 From: Yungui Wang In-reply-to: To: 'Hesham Soliman' , 'George Tsirtsis' Message-id: <00b501c9cf8d$570edce0$150ca40a@china.huawei.com> Organization: huawei 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: AcnPgz7qEK21nsg340a/gf8cGvfXyAABWQxw Cc: 'Julien Laganier' , mext@ietf.org Subject: [MEXT] new pad sub-option and flow identifier assignment 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: Fri, 08 May 2009 03:31:42 -0000 Hello Two comments. 1.The unit length is 8-octet in the FID mobility option. It is very possible that the real option in BU may be not n*8 octet. Thus, a new pad sub-option may need to be defined in the draft. 2.The FID mobility option is a common mobility option. As discussed before, either MN or HA may initiate the flow binding in a certain case. (Personally I think it is possible for HA to initiate flow binding). That's, either MN or HA may assign FID(s) for different flows. However, in this case, the FID may be overlapped when both MN and HA are initiating different flows. So I think avoiding said collision should be considered. B.R. Yungui From hesham@elevatemobile.com Thu May 7 21:54: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 1CAA53A6B59 for ; Thu, 7 May 2009 21:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 zbx54SVYPfML for ; Thu, 7 May 2009 21:54:54 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 36E393A6A45 for ; Thu, 7 May 2009 21:54:53 -0700 (PDT) Received: from [115.130.42.152] by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1M2I86-0003FU-VS; Fri, 08 May 2009 14:56:17 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 08 May 2009 14:56:06 +1000 From: Hesham Soliman To: , 'George Tsirtsis' Message-ID: Thread-Topic: new pad sub-option and flow identifier assignment Thread-Index: AcnPgz7qEK21nsg340a/gf8cGvfXyAABWQxwAAQqFzg= In-Reply-To: <00b501c9cf8d$570edce0$150ca40a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'Julien Laganier' , mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 08 May 2009 04:54:55 -0000 > > 2.The FID mobility option is a common mobility option. > As discussed before, either MN or HA may initiate the > flow binding in a certain case. => No, only the MN can initiate it. (Personally I think it is > possible for HA to initiate flow binding). That's, either > MN or HA may assign FID(s) for different flows. > However, in this case, the FID may be overlapped > when both MN and HA are initiating different flows. > So I think avoiding said collision should be considered. => The collision is not possible because only the MN initiates it. Hesham > > > B.R. > Yungui > From w52006@huawei.com Fri May 8 00:19: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 2B4463A68B3 for ; Fri, 8 May 2009 00:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 ANVEdCGHQJXq for ; Fri, 8 May 2009 00:19:08 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4402D3A67B4 for ; Fri, 8 May 2009 00:19:08 -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 <0KJB000M8DQ2N3@szxga04-in.huawei.com> for mext@ietf.org; Fri, 08 May 2009 15:20:26 +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 <0KJB00B5XDQ1YX@szxga04-in.huawei.com> for mext@ietf.org; Fri, 08 May 2009 15:20:25 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJB00DUYDQ11V@szxml04-in.huawei.com> for mext@ietf.org; Fri, 08 May 2009 15:20:25 +0800 (CST) Date: Fri, 08 May 2009 15:20:25 +0800 From: Yungui Wang In-reply-to: To: 'Hesham Soliman' , 'George Tsirtsis' Message-id: <00c701c9cfad$7511c340$150ca40a@china.huawei.com> Organization: huawei 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: AcnPgz7qEK21nsg340a/gf8cGvfXyAABWQxwAAQqFzgABIo2YA== Cc: 'Julien Laganier' , mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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: Fri, 08 May 2009 07:19:09 -0000 Hello Please see solution requirement from MEXT charter... '' - 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]. " And some requirements from 3GPP 23.861 for your information. " ... - It should be possible for the operator to enable and control the simultaneous usage of multiple accesses. - It should be possible for the operator to enable and control the flow mobility. ... " Above information makes me believe it is possible that HA may initiate the flow binding. What do you assure that only MN does? B.R. Yungui > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Friday, May 08, 2009 12:56 PM > To: w52006@huawei.com; 'George Tsirtsis' > Cc: mext@ietf.org; 'Julien Laganier' > Subject: Re: new pad sub-option and flow identifier assignment > > > > > > 2.The FID mobility option is a common mobility option. > > As discussed before, either MN or HA may initiate the > > flow binding in a certain case. > > => No, only the MN can initiate it. > > (Personally I think it is > > possible for HA to initiate flow binding). That's, either > > MN or HA may assign FID(s) for different flows. > > However, in this case, the FID may be overlapped > > when both MN and HA are initiating different flows. > > So I think avoiding said collision should be considered. > > => The collision is not possible because only the MN initiates it. > > Hesham > > > > > > > B.R. > > Yungui > > > > From julien.laganier.ietf@googlemail.com Fri May 8 02:22: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 728063A70C5 for ; Fri, 8 May 2009 02:22:30 -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 tKBwZ7zlHKhE for ; Fri, 8 May 2009 02:22:29 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id F256A3A70D9 for ; Fri, 8 May 2009 02:22:28 -0700 (PDT) Received: by ewy24 with SMTP id 24so1681459ewy.37 for ; Fri, 08 May 2009 02:23:55 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=ulSO78b2uXwkWmpwKUHicC8NtQ9SIpsYd9ErMoYqJ30=; b=dmY0B6aSpLGn2gu7T6Kx8YQc+Doa2jbhuwV8GzxH3DoUCh7o68f13EnOuieltdCZTw q642Nc2wQIPXhkiVXIvuwGa4MzIYPApZNylXEQlj6Yu1pJm3VfNpBkiskyBCkoXq2Ke7 M/IhyNKJYdECCN7K8uzCMslTzN5u70smFyID0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=Noi3iw2U5jQWMTbitqZoknkskyPf6bsRvEWXqGmzXnd5aJzHNcsl1bhcf0o6trwuvi AUJ98SLRLyIeeuYIuFRqbVYik3r0LRkAWcIPJH8vTHR9uZfLtdcFdmQGtVTKEyJcoVo9 4E9u/1PTtzqgmbbxvF7kCpojKL18b6NPIqRGA= Received: by 10.216.19.68 with SMTP id m46mr1513905wem.7.1241774634750; Fri, 08 May 2009 02:23:54 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id u14sm1916169gvf.5.2009.05.08.02.23.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 May 2009 02:23:54 -0700 (PDT) From: Julien Laganier To: George Tsirtsis Date: Fri, 8 May 2009 11:23:53 +0200 User-Agent: KMail/1.9.10 References: <296286.77052.qm@web27801.mail.ukl.yahoo.com> <200905071656.43806.julien.laganier.IETF@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905081123.55226.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 08 May 2009 09:22:30 -0000 Hi George, On Thursday 07 May 2009, George Tsirtsis wrote: > Two FIDs can have the same FID-PRI as long as they do not overlap. If > one rules says match all UDP and the other says match all TCP, then > the rules do not overlap and the can have the same FID-PRI since the > result will be the same no matter which order they are looked at. > > If two rules overlap, however, they need different FID-PRI since then > the MN needs to define which one to be looked at first. e.g., one > rules is match all UDP and the other is match sourceAddr=3DIPx then the > rules overlap since there might be packets that are UDP and also have > sourceAddr=3DIPx. In this case the order is important so the FID-PRI > should be different. If the FID-PRI is the same then it means that > the rules will be put in whatever order the received decide (which > could be random). Can agree with the above, but this put a requirement on both ends to be=20 able to determine whether or not there's an overlap for every duple of=20 rules with same priority within the ruleset, and generate an error if=20 there is indeed an overlap. This puts an additional computational=20 burden on the mobile node to provide some flexibility for which I do=20 not see any clear benefit. I thus believe FID priority should be=20 unique. If somebody can come up with a scenario outlining the value of=20 specifying rules with same priority, I am happy to keep that=20 flexibility. =2D-julien > If this is not well described in the draft we can probably expand on > it...I have the sense I wrote again about this recently but I cannot > remember if it was on the mailing list or in some other context; my > brain's efficiency goes down as the week progresses :-/ > > George > > On Thu, May 7, 2009 at 3:56 PM, Julien Laganier > > wrote: > > Hello George, > > > > I looked at the draft and it is in very good shape. I have a quick > > question regarding the FID Priority: > > > > =C2=A0 =C2=A0 =C2=A0FID-PRI > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is an 8-bit priority field to indicate= the > > priority of a =C2=A0 =C2=A0 =C2=A0 =C2=A0 particular option. =C2=A0This= field is needed > > in cases where two =C2=A0 =C2=A0 =C2=A0 =C2=A0 different flow descripti= ons in two > > different options overlap. =C2=A0 =C2=A0 =C2=A0 =C2=A0 The priority fie= ld decides > > which policy should be in those =C2=A0 =C2=A0 =C2=A0 =C2=A0 cases. =C2= =A0A lower number > > in this field indicates a higher =C2=A0 =C2=A0 =C2=A0 =C2=A0 priority. > > > > Shouldn't we made explicit that each FID is assigned a unique > > priority? > > > > --julien =2D-=20 =2D-julien From hesham@elevatemobile.com Fri May 8 02:44: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 BC25028C149 for ; Fri, 8 May 2009 02:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=-0.426, 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 kAj3DsxAZm7m for ; Fri, 8 May 2009 02:44: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 C28C43A6BA9 for ; Fri, 8 May 2009 02:44: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 1M2Me7-0003T5-Ds; Fri, 08 May 2009 19:45:35 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 08 May 2009 19:45:29 +1000 From: Hesham Soliman To: Julien Laganier , George Tsirtsis Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnPwbih6+Okm0AQ+EyMItK6ICBjug== In-Reply-To: <200905081123.55226.julien.laganier.IETF@googlemail.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] flow binding draft 2 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, 08 May 2009 09:44:10 -0000 Julien, > On Thursday 07 May 2009, George Tsirtsis wrote: >> Two FIDs can have the same FID-PRI as long as they do not overlap. If >> one rules says match all UDP and the other says match all TCP, then >> the rules do not overlap and the can have the same FID-PRI since the >> result will be the same no matter which order they are looked at. >>=20 >> If two rules overlap, however, they need different FID-PRI since then >> the MN needs to define which one to be looked at first. e.g., one >> rules is match all UDP and the other is match sourceAddr=3DIPx then the >> rules overlap since there might be packets that are UDP and also have >> sourceAddr=3DIPx. In this case the order is important so the FID-PRI >> should be different. If the FID-PRI is the same then it means that >> the rules will be put in whatever order the received decide (which >> could be random). >=20 > Can agree with the above, but this put a requirement on both ends to be > able to determine whether or not there's an overlap for every duple of > rules with same priority within the ruleset, and generate an error if > there is indeed an overlap. This puts an additional computational > burden on the mobile node to provide some flexibility for which I do > not see any clear benefit. I thus believe FID priority should be > unique. If somebody can come up with a scenario outlining the value of > specifying rules with same priority, I am happy to keep that > flexibility. =3D> Like I said earlier, the graceful way of handling this is for the receiver to break the tie. We need to require this capability anyway for th= e receiver, that's why I don't see a need for unique PRI. Furthermore, there can be cases where the MN simply doesn't care and allows the HA to decide which one goes where. Hesham >=20 > --julien >=20 >> If this is not well described in the draft we can probably expand on >> it...I have the sense I wrote again about this recently but I cannot >> remember if it was on the mailing list or in some other context; my >> brain's efficiency goes down as the week progresses :-/ >>=20 >> George >>=20 >> On Thu, May 7, 2009 at 3:56 PM, Julien Laganier >>=20 >> wrote: >>> Hello George, >>>=20 >>> I looked at the draft and it is in very good shape. I have a quick >>> question regarding the FID Priority: >>>=20 >>> =C2=A0 =C2=A0 =C2=A0FID-PRI >>>=20 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is an 8-bit priority field to indicate the >>> priority of a =C2=A0 =C2=A0 =C2=A0 =C2=A0 particular option. =C2=A0This field is needed >>> in cases where two =C2=A0 =C2=A0 =C2=A0 =C2=A0 different flow descriptions in two >>> different options overlap. =C2=A0 =C2=A0 =C2=A0 =C2=A0 The priority field decides >>> which policy should be in those =C2=A0 =C2=A0 =C2=A0 =C2=A0 cases. =C2=A0A lower number >>> in this field indicates a higher =C2=A0 =C2=A0 =C2=A0 =C2=A0 priority. >>>=20 >>> Shouldn't we made explicit that each FID is assigned a unique >>> priority? >>>=20 >>> --julien >=20 >=20 From hesham@elevatemobile.com Fri May 8 02:51: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 7ABCB3A6D74 for ; Fri, 8 May 2009 02:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 JPWGKtv7HjKK for ; Fri, 8 May 2009 02:51: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 114EC3A6CC1 for ; Fri, 8 May 2009 02:50:46 -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 1M2MkQ-0001CF-VH; Fri, 08 May 2009 19:52:07 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 08 May 2009 19:52:02 +1000 From: Hesham Soliman To: , 'George Tsirtsis' Message-ID: Thread-Topic: new pad sub-option and flow identifier assignment Thread-Index: AcnPgz7qEK21nsg340a/gf8cGvfXyAABWQxwAAQqFzgABIo2YAAFy6Rd In-Reply-To: <00c701c9cfad$7511c340$150ca40a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'Julien Laganier' , mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 08 May 2009 09:51:44 -0000 On 8/05/09 5:20 PM, "Yungui Wang" wrote: > Hello > > Please see solution requirement from MEXT charter... > '' > - 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]. => We're not talking about policies in this draft, we're talking about transporting filters. We discussed this many times. Policies can associate a flow on with a link layer, interface ...etc on a high level. Filters install instances of such policies. It's not the same thing. > " > > And some requirements from 3GPP 23.861 for your information. > " > ... > - It should be possible for the operator to enable and control the > simultaneous usage of multiple accesses. > - It should be possible for the operator to enable and control the > flow mobility. > ... > " => That's fine but: 1. "control" is meaningless to me, and, 2. We are developing a spec for the entire Internet. An operator's HA can communicate policies all day to the MN, but installing filters from the MN to HA is what we define in the spec. Control can mean many things and if by that "control" the HA would reject a BU that doesn't comply to its policies that's fine by me. > > Above information makes me believe it is possible that HA may > initiate the flow binding. What do you assure that only MN does? => This is how MIPv6 works and the right way of doing things if you want them to work in multi-access environments. It's not about what's possible, it's about the best way of doing it. Hesham > > > B.R. > Yungui > > > >> -----Original Message----- >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] >> Sent: Friday, May 08, 2009 12:56 PM >> To: w52006@huawei.com; 'George Tsirtsis' >> Cc: mext@ietf.org; 'Julien Laganier' >> Subject: Re: new pad sub-option and flow identifier assignment >> >> >>> >>> 2.The FID mobility option is a common mobility option. >>> As discussed before, either MN or HA may initiate the >>> flow binding in a certain case. >> >> => No, only the MN can initiate it. >> >> (Personally I think it is >>> possible for HA to initiate flow binding). That's, either >>> MN or HA may assign FID(s) for different flows. >>> However, in this case, the FID may be overlapped >>> when both MN and HA are initiating different flows. >>> So I think avoiding said collision should be considered. >> >> => The collision is not possible because only the MN initiates it. >> >> Hesham >> >>> >>> >>> B.R. >>> Yungui >>> >> >> > From julien.laganier.ietf@googlemail.com Fri May 8 05:08: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 45AE928C26E for ; Fri, 8 May 2009 05:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25FjpU8DisZx for ; Fri, 8 May 2009 05:08:41 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id ABAD828C2A6 for ; Fri, 8 May 2009 05:08:40 -0700 (PDT) Received: by ewy24 with SMTP id 24so1770092ewy.37 for ; Fri, 08 May 2009 05:10:06 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=0THSAygXvvDZvCJe//Zp/vXDuxw275XWGW1uGOknuCQ=; b=oAmQzSpGL+9GIJxg99x4NQAm8Hz8LE6kY2hDNkl/I15DRNM5cegefoXaRBy5nhvaOC Z3GasQ2sRUvaLtWJczWnXcNDmYqcLh8DOv2wiLc70qhlUpg5Gv+4dkPZ05ohg0XWEhhL GYofUIl9QX2zU24roLoP1GkLpzI/XARBU0D9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=Z8UbI3TltBm7BpqdGPLfRCequID+0irddaftm0htB+ulrL/CA5SXVeZE43NGr5xjWt D1OqXEiYVf0kjP2Qz4rKIgRp1gkHK3kNmiWiw0e68Zmht4HdcJ+VUU6NY86T5F7Q+1yG YU3lhqoGP79i3gzUYo0rT616G30mbr/imEee8= Received: by 10.216.17.213 with SMTP id j63mr1518658wej.140.1241784603945; Fri, 08 May 2009 05:10:03 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id g9sm2151473gvc.10.2009.05.08.05.10.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 May 2009 05:10:03 -0700 (PDT) From: Julien Laganier To: Hesham Soliman Date: Fri, 8 May 2009 14:10:04 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905081410.04985.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 08 May 2009 12:08:42 -0000 Hesham, On Friday 08 May 2009, Hesham Soliman wrote: > Julien, > > > On Thursday 07 May 2009, George Tsirtsis wrote: > >> Two FIDs can have the same FID-PRI as long as they do not overlap. > >> If one rules says match all UDP and the other says match all TCP, > >> then the rules do not overlap and the can have the same FID-PRI > >> since the result will be the same no matter which order they are > >> looked at. > >> > >> If two rules overlap, however, they need different FID-PRI since > >> then the MN needs to define which one to be looked at first. e.g., > >> one rules is match all UDP and the other is match sourceAddr=IPx > >> then the rules overlap since there might be packets that are UDP > >> and also have sourceAddr=IPx. In this case the order is important > >> so the FID-PRI should be different. If the FID-PRI is the same > >> then it means that the rules will be put in whatever order the > >> received decide (which could be random). > > > > Can agree with the above, but this put a requirement on both ends > > to be able to determine whether or not there's an overlap for every > > duple of rules with same priority within the ruleset, and generate > > an error if there is indeed an overlap. This puts an additional > > computational burden on the mobile node to provide some flexibility > > for which I do not see any clear benefit. I thus believe FID > > priority should be unique. If somebody can come up with a scenario > > outlining the value of specifying rules with same priority, I am > > happy to keep that flexibility. > > => Like I said earlier, the graceful way of handling this is for the > receiver to break the tie. We need to require this capability anyway > for the receiver, that's why I don't see a need for unique PRI. I could live with a tie break mechanism but, as a sender I wouldn't like to believe the tie was broke left while the sender actually broke it right. Thus if we rely on tie break, I'd rather have us specify how that works, which in turns imply that we define a sub-order among rules with same priority. I do not see the point but... The simplest sub-ordering scheme I can come up with is, for every set of rules with same priority: the earliest rule established prevails on other, while rule A is earlier than rule B if 1) rule A in is a BU send before the BU that contains rule B, or 2) rule A is placed before rule B in the same BU. To me this is more complex while the end result is not that different from rules with unique priorities, since in both case we do define a total order amongst rules. In one case (tie break) the total order depends on the combination of a tie break mechanism and the ruleset, while in the other case (unique priorities) the total order depends uniquely on the ruleset. Thus I'd favor the later since it is explicit and I highly value expliciteness in protocol designs. Maybe this only me... If anyone has a clear benefit of tie break in mind, could he speak up? > Furthermore, there can be cases where the MN simply doesn't care and > allows the HA to decide which one goes where. I do not understand why would the MN put forth two overlapping rules in the first place if it doesn't care... --julien From julien.laganier.ietf@googlemail.com Fri May 8 05:53: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 2EC033A7152 for ; Fri, 8 May 2009 05:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6HzMGbr3vq0 for ; Fri, 8 May 2009 05:53:44 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id B71183A695E for ; Fri, 8 May 2009 05:53:43 -0700 (PDT) Received: by fxm2 with SMTP id 2so1379287fxm.37 for ; Fri, 08 May 2009 05:55:09 -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:content-transfer-encoding :content-disposition:message-id; bh=xasckJ5TjRMICGIYoc0q+hUmPg9168h3NCeoY/Wopqc=; b=A9HOCrcmAILtWCp6Wu4TJ8g6chvB01IQWFvMKqllHFIXHd2ivSx/702wHNv5BeXTSm WMBUSH8a/mnHoR8A4nuVZ6Cznce+jG+nJvjsRPwZo1PmLfUTxMqXt6UVITfpzOthyBqB +g5y+QoO0sN3/vI6lumjawy7KnrJPV8sqqN7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=ZXiq1A/o9neMQXIUDiIoEHV8WRHO/ESaXDBIEkH9Y+Li8VGMco+ymRewTJDSbYbhR9 3KVvYS2ZA8DQGuLhcu9kaJoA2BGjTLlfaNO3k9uDSVHOVZV1BoJAuYcmpF5EiKYeobUY u96NhJssSRXAZ6D5ivugOSwY+E9QBR4WzVA8A= Received: by 10.204.71.68 with SMTP id g4mr3548824bkj.135.1241787309709; Fri, 08 May 2009 05:55:09 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id p17sm1252310fka.15.2009.05.08.05.55.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 08 May 2009 05:55:09 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Fri, 8 May 2009 14:55:17 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905081455.17546.julien.laganier.IETF@googlemail.com> Subject: [MEXT] round-robin action for flow binding rules 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, 08 May 2009 12:53:45 -0000 Folks, One of my colleague has suggested the idea of adding a round-robin action to a rule in addition to the existing ones: > 1 Forward. This value indicates a request to forward a flow to > the address indicated in the Binding Reference sub-option. A > single BID MUST be associated with this Action. > > 2 Discard. This value indicates a request to discard all > packets in the flow described by the option. No BIDs are > associated with this Action. > > 3 n-cast. This value indicates a request to replicate the flow > to several addresses indicated in the Binding Reference > sub-option. One or more BIDs MUST be associated with this > Action. 4 round-robin. This value indicates a request to forward packets from a flow in a round-robin fashion to several addresses indicated in the Binding Reference sub-option. One or more BIDs MUST be associated with this Action. This could be used to load balance some type of traffics amongst two different links. What do you think? --julien From hesham@elevatemobile.com Fri May 8 06:02: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 6CDBD3A710A for ; Fri, 8 May 2009 06:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 M9ZRd3f5tnsm for ; Fri, 8 May 2009 06:02: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 86AD53A6B06 for ; Fri, 8 May 2009 06:02: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 1M2Pjx-0000LY-AF; Fri, 08 May 2009 23:03:49 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 08 May 2009 23:03:44 +1000 From: Hesham Soliman To: Julien Laganier , Message-ID: Thread-Topic: [MEXT] round-robin action for flow binding rules Thread-Index: AcnP3WqaVry2YzXlg0SVFoHWIrPaBQ== In-Reply-To: <200905081455.17546.julien.laganier.IETF@googlemail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MEXT] round-robin action for flow binding rules 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, 08 May 2009 13:02:25 -0000 Hi Julien, On 8/05/09 10:55 PM, "Julien Laganier" wrote: > Folks, > > One of my colleague has suggested the idea of adding a round-robin > action to a rule in addition to the existing ones: > >> 1 Forward. This value indicates a request to forward a flow to >> the address indicated in the Binding Reference sub-option. A >> single BID MUST be associated with this Action. >> >> 2 Discard. This value indicates a request to discard all >> packets in the flow described by the option. No BIDs are >> associated with this Action. >> >> 3 n-cast. This value indicates a request to replicate the flow >> to several addresses indicated in the Binding Reference >> sub-option. One or more BIDs MUST be associated with this >> Action. > > 4 round-robin. This value indicates a request to forward > packets from a flow in a round-robin fashion to several > addresses indicated in the Binding Reference sub-option. One or > more BIDs MUST be associated with this Action. > > This could be used to load balance some type of traffics amongst two > different links. > > What do you think? => This was actually in an older version and we removed it due to the dnager of load balancing on a per-packet basis. I have pretty strong opnions against this because it breaks TCP or any secure traffic where sequence numbers are used for replay attacks. And in many cases there is not enough information at the MIP level alone or in upper layers alone to make this decision. Per-packet balancing can be very bad in many cases. There are extremely limited scenarios (can't think of any) where this adds value. I don't think we know enough to add this at this stage. Perhaps later when work on multi-path TCP becomes a reality this action can be added in an extension RFC. Hesham > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Fri May 8 06:03: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 1CEC63A714E for ; Fri, 8 May 2009 06:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 nMmMXuyL-ONK for ; Fri, 8 May 2009 06:03:22 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 2CF013A69C8 for ; Fri, 8 May 2009 06:03: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 1M2Pkv-00038w-HN; Fri, 08 May 2009 23:04:49 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 08 May 2009 23:04:46 +1000 From: Hesham Soliman To: Julien Laganier Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnP3Y+OCul8rdPg60KONM5NlS3xMA== In-Reply-To: <200905081410.04985.julien.laganier.IETF@googlemail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 08 May 2009 13:03:23 -0000 >> => Like I said earlier, the graceful way of handling this is for the >> receiver to break the tie. We need to require this capability anyway >> for the receiver, that's why I don't see a need for unique PRI. > > I could live with a tie break mechanism but, as a sender I wouldn't like > to believe the tie was broke left while the sender actually broke it > right. Thus if we rely on tie break, I'd rather have us specify how > that works, which in turns imply that we define a sub-order among rules > with same priority. I do not see the point but... => I agree there would be no point in doing that but the question is why is the sender sending the same priority? May be it doesn't care. So what if they broke the tie differently? > > The simplest sub-ordering scheme I can come up with is, for every set of > rules with same priority: the earliest rule established prevails on > other, while rule A is earlier than rule B if 1) rule A in is a BU send > before the BU that contains rule B, or 2) rule A is placed before rule > B in the same BU. > > To me this is more complex while the end result is not that different > from rules with unique priorities, since in both case we do define a > total order amongst rules. => I think if we have to make it unique then unique PRI is the way to do it. But my point is that doesn't eliminate the need for a tie breaker as a graceful fallback. I can't see the harm in a different tie break at either end. What am I missing? > >> Furthermore, there can be cases where the MN simply doesn't care and >> allows the HA to decide which one goes where. > > I do not understand why would the MN put forth two overlapping rules in > the first place if it doesn't care... => Because it's installing the rule and it doesn't care *now*. May be later it will change it. I don't have a concrete example but given that this is done by upper layers I'd rather err on the side of flexibility provided that no harm is done. So my question to you is: What harm do you see? Hesham > > --julien From kuntz@lsiit.u-strasbg.fr Sat May 9 07:31: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 3D0693A6910 for ; Sat, 9 May 2009 07:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 eNsSssYh45ub for ; Sat, 9 May 2009 07:31:21 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.158]) by core3.amsl.com (Postfix) with ESMTP id 3220F3A68BB for ; Sat, 9 May 2009 07:31:21 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n49EVRY7090533 ; Sat, 9 May 2009 16:31:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 33888BD7FF9; Sat, 9 May 2009 16:31:27 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8-ajStf7J7P; Sat, 9 May 2009 16:31:26 +0200 (CEST) Received: from [192.168.0.10] (bro67-5-88-177-196-175.fbx.proxad.net [88.177.196.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kuntz) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 91E2FBD7FEA; Sat, 9 May 2009 16:31:26 +0200 (CEST) Message-Id: <5B180C5A-3C7E-42A3-A362-FDD18BE4C622@lsiit.u-strasbg.fr> From: Romain KUNTZ To: Brian Haley In-Reply-To: <4A02E9C8.8070301@hp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 9 May 2009 16:31:24 +0200 References: <49EF37D8.2010408@it.uc3m.es> <49FAC1A2.7060206@it.uc3m.es> <87hc0157z1.fsf@small.ssi.corp> <87skjh40mu.fsf@small.ssi.corp> <4A02E9C8.8070301@hp.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [130.79.200.158]); Sat, 09 May 2009 16:31:30 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9349/Sat May 9 13:17:56 2009 on mr8.u-strasbg.fr X-Virus-Status: Clean Cc: mext Subject: Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-mip6-hareliability-04 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, 09 May 2009 14:31:22 -0000 Hi, On 2009/05/07, at 16:01, Brian Haley wrote: > Arnaud Ebalard wrote: >> Hi Romain, >> >> Romain KUNTZ writes: >> >>> I know there is an implementation of RFC5142 and draft-ietf-mip6- >>> hareliability-04 for UMIP 0.4 for Linux. It was implemented as >>> part of >>> a project I joined. I think I can ask whether the code can be >>> disclosed or not, if someone has interest. >> >> I'd be interested to look at it and possibly (depending on the size) >> maintain it (if it is not done already) with the other patches I have >> for UMIP. > > I'd be interested as well since I was implementing this for Linux > since I didn't > see it in the mipv6-daemon git repo. I've contacted the person in charge of the code. I'll get back to you as soon as I get an answer. romain From kuntz@lsiit.u-strasbg.fr Sat May 9 09:56: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 058003A6E7F for ; Sat, 9 May 2009 09:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=0.745, 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 im5P5PuRUeXV for ; Sat, 9 May 2009 09:56:40 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.154]) by core3.amsl.com (Postfix) with ESMTP id A7B7C3A6E2A for ; Sat, 9 May 2009 09:56:39 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n49GupnH024463 for ; Sat, 9 May 2009 18:56:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id AE99DBD9857 for ; Sat, 9 May 2009 18:56:51 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAe7JAMjSwfG for ; Sat, 9 May 2009 18:56:51 +0200 (CEST) Received: from [192.168.0.10] (bro67-5-88-177-196-175.fbx.proxad.net [88.177.196.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kuntz) by clarinet.u-strasbg.fr (Postfix) with ESMTP id EF293BD9848 for ; Sat, 9 May 2009 18:56:50 +0200 (CEST) Message-Id: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> From: Romain KUNTZ To: mext Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 9 May 2009 18:56:48 +0200 X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [130.79.200.154]); Sat, 09 May 2009 18:56:52 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9349/Sat May 9 13:17:56 2009 on mr4.u-strasbg.fr X-Virus-Status: Clean Subject: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 09 May 2009 16:56:41 -0000 Hi, Some comments on draft-ietf-monami6-multiplecoa-13. First, I'd like to express that I support Arnaud's opinion about section 5.6 (Simultaneous Home and Visited Link Operation). I also don't see what is the motivation to re-route and tunnel traffic from the HA to one of the MN's CoA, while the MN is only one hop from the HA. Even if there is a specific use-case, at the time this topology was suggested, a simple solution that came out was to configure a CoA on the Home link and use a tunnel via the home link. I don't think the little overhead of this solution justifies the complexity of the one proposed in the draft. Another concern I have is about the use of route optimized traffic between the MN and the HA. I've already raised this problem long time ago and I don't think it was addressed in the draft (excuse me if I skipped the text), so I'll try to explain it in short again: RFC 3775 says in section 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. So a MN may include an HOA dest. option in the packets destinated to the HA instead of reverse-tunneling them. The source address of the packet would thus be the CoA of the interface from which the packet is sent. At the Home Agent side (still in section 9.3.1): [...] the currently registered care-of address MUST be equal to the source address of the packet. These tests MUST NOT be done for packets that contain a Home Address option and a Binding Update. The MCoA draft does not say anything about the behavior the HA should have in that case. As packets do not contain any information about the BID binded to the CoA used to send the packet, the HA at this time would have, for each packet, to check if the source address of the packet is equal to *one of the CoA registered for the corresponding BCE*, thus to parse the list of all the CoA registered for the node. However I have some doubts about the efficiency of such tests if the number of CoA registered of each node is great and if there is a lot of traffic. One solution could be to use reverse tunneling rather than HOA dest. option when the node uses MCoA and wants to send packets (other than Mobility Headers) to its HA. Then, when the HA replies, it must put a RTH2 in the reply instead of reverse-tunneling the packet. How does the HA select the source address to put in the RTH2? As the RTH2 is included once the IP packet is forged by upper layers, the HA has no way to maintain a state for each packet received from a node to know which address to include in the RTH2 of the reply. Picking up one randomly may result in a non- symmetric path between the MN and the HA. For that reason I would suggest to add some text stating that traffic from the MN to the HA (except for the mobility signaling messages) must not be route optimized. Two other minor comments on the draft below: - Section 6.2 (Processing Binding Update) * If the 'O' flag is set in the Binding Update, the home agent removes all the existing bindings and registers the received binding(s). It is not explicitly said that the MN can use the O flag with a CN. I think nothing prevents the MN to use it, so we should replace "home agent" with "receiving node". If all the above operations are successfully completed, a Binding Acknowledgement containing the Binding Identifier mobility options MUST be sent to the mobile node. The BAck must be sent only if the 'A' flag was set in the BU, right? or does the MCoA spec mandates sending BAck in all cases? Cheers, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr LSIIT - Networks and Protocols Team http://clarinet.u-strasbg.fr/~kuntz/ From kuntz@lsiit.u-strasbg.fr Sat May 9 10:15: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 F05CD3A6E6F for ; Sat, 9 May 2009 10:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.372, 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 shkArAtmD7Qy for ; Sat, 9 May 2009 10:15:31 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.156]) by core3.amsl.com (Postfix) with ESMTP id DA7723A6DD1 for ; Sat, 9 May 2009 10:15:30 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n49HFh1X081684 for ; Sat, 9 May 2009 19:15:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id AEE65BD9911 for ; Sat, 9 May 2009 19:15:43 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF9wbEsO93sn for ; Sat, 9 May 2009 19:15:43 +0200 (CEST) Received: from [192.168.0.10] (bro67-5-88-177-196-175.fbx.proxad.net [88.177.196.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kuntz) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 17F49BD9904 for ; Sat, 9 May 2009 19:15:42 +0200 (CEST) Message-Id: From: Romain KUNTZ To: mext In-Reply-To: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 9 May 2009 19:15:23 +0200 References: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [130.79.200.156]); Sat, 09 May 2009 19:15:43 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9349/Sat May 9 13:17:56 2009 on mr6.u-strasbg.fr X-Virus-Status: Clean Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 09 May 2009 17:15:32 -0000 One more comment inline: On 2009/05/09, at 18:56, Romain KUNTZ wrote: > So a MN may include an HOA dest. option in the packets destinated to > the HA instead of reverse-tunneling them. The source address of the > packet would thus be the CoA of the interface from which the packet > is sent. At the Home Agent side (still in section 9.3.1): > > [...] the currently registered care-of address MUST be equal to > the source address of the packet. These tests MUST NOT be done for > packets that contain a Home Address option and a Binding Update. > > The MCoA draft does not say anything about the behavior the HA > should have in that case. My mistake, actually it does say something, in section 6.5 (Receiving Packets from Mobile Node): When a node receives packets with a Home Address destination option from a mobile node, it MUST check that the care-of address that appears in the source address field of the IPv6 header MUST be equal to one of the care-of addresses in the binding cache entry. If no binding is found, the packets MUST be discarded. [...] But my comment on the efficiency (especially at the HA side) still holds, in addition to the other issue related to the RHT2. Cheers, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr LSIIT - Networks and Protocols Team http://clarinet.u-strasbg.fr/~kuntz/ From tsirtsis@googlemail.com Sun May 10 05:35: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 313DD3A6BB9 for ; Sun, 10 May 2009 05:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_PRIOR=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 7Zx9DTmd0WJd for ; Sun, 10 May 2009 05:35:28 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id B6B8A3A65A5 for ; Sun, 10 May 2009 05:35:27 -0700 (PDT) Received: by fxm2 with SMTP id 2so2192248fxm.37 for ; Sun, 10 May 2009 05:36:54 -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=DevycEOIdpYy8/hA/DTJfpnjuQjDrWUNkPNS/vrhqW4=; b=UTi9MXEgNPY9V/NXesX9Oh1QzPCuuXTLRUSIzZO3Xkq2Pv/t0eby5ceSmIH63jmEGp DrUCxFYnApD6sdrOOCs50sK9ofw7Zb/EHCp9qmXSxxIz/bVjDLcYqq2fBzgqusOSieEL Dj/9fjiZBiRB5ic9raX+U7n+mvFI2E2hKxC+c= 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=muYOHKgpOckhdu80tANfAEOKTz8az6XfgJuNuwjibSIaSUmCcEyj2EMXrYzLeAOYT7 g/gT8nbQ6V3WrLeZupVQiHc0IuUBWbJQZa+qjt4Ggdl8GpmT/kYwnGlXafG40m4kLqlT sBKtV2jv8uyzFSW2vgn/Wh+8L30A4w0CrPcC4= MIME-Version: 1.0 Received: by 10.223.126.145 with SMTP id c17mr2890122fas.102.1241959014510; Sun, 10 May 2009 05:36:54 -0700 (PDT) In-Reply-To: References: <200905081410.04985.julien.laganier.IETF@googlemail.com> Date: Sun, 10 May 2009 13:36:54 +0100 Message-ID: From: George Tsirtsis To: Hesham Soliman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 10 May 2009 12:35:29 -0000 Julien, One thing to note is that there is no way you can put together a classifier without knowing exactly what order the rules need to be placed in the list and without understanding which ones overlap and which are not. The MN MUST be able to do this, otherwise there is no way to impose the desired behaviour. Now also consider that whether we require a unique PRI or not, the MN again will have to know the above. If you require unique PRI, the MN will have to decide the order of overlapping rules. If we allow more than one rule to have the same PRI, the MN will have to decide which rules are not overlapping and thus they can take the same value. So, either way, it makes no difference to the complexity of the MN. On the HA side it is also easy either way. Rules are ordered according to PRI. Rules with the same PRI will be placed in a random order between them, since it makes no difference. And just for fun, here is an example of the value of allowing rules with same PRI. Say you have 3 rules with PRI 1, 2, and 3. Now you want to add a rule which needs to be placed between 1 and 3, and does not overlap with 2. If you require unique PRIs, you will have to renumber 3 to 4 and add the new rule as a new 3; ending up with PRI 1, 2, 3, and 4. If you allow for non-unique PRIs you just add the new rule with PRI 2, resulting in 1, 2, 2, 3. Again, I am not saying the above presents a significant advantage but only that this is how all classifiers work in existing implementations and thus we should not do something different unless we have a really good reason, which IMO we do not. Does this help? George On Fri, May 8, 2009 at 2:04 PM, Hesham Soliman wrote: > >>> => Like I said earlier, the graceful way of handling this is for the >>> receiver to break the tie. We need to require this capability anyway >>> for the receiver, that's why I don't see a need for unique PRI. >> >> I could live with a tie break mechanism but, as a sender I wouldn't like >> to believe the tie was broke left while the sender actually broke it >> right. Thus if we rely on tie break, I'd rather have us specify how >> that works, which in turns imply that we define a sub-order among rules >> with same priority. I do not see the point but... > > => I agree there would be no point in doing that but the question is why is > the sender sending the same priority? May be it doesn't care. So what if > they broke the tie differently? > >> >> The simplest sub-ordering scheme I can come up with is, for every set of >> rules with same priority: the earliest rule established prevails on >> other, while rule A is earlier than rule B if 1) rule A in is a BU send >> before the BU that contains rule B, or 2) rule A is placed before rule >> B in the same BU. >> >> To me this is more complex while the end result is not that different >> from rules with unique priorities, since in both case we do define a >> total order amongst rules. > > => I think if we have to make it unique then unique PRI is the way to do it. > But my point is that doesn't eliminate the need for a tie breaker as a > graceful fallback. I can't see the harm in a different tie break at either > end. What am I missing? > >> >>> Furthermore, there can be cases where the MN simply doesn't care and >>> allows the HA to decide which one goes where. >> >> I do not understand why would the MN put forth two overlapping rules in >> the first place if it doesn't care... > > => Because it's installing the rule and it doesn't care *now*. May be later > it will change it. I don't have a concrete example but given that this is > done by upper layers I'd rather err on the side of flexibility provided that > no harm is done. So my question to you is: What harm do you see? > > Hesham > >> >> --julien > > > From w52006@huawei.com Sun May 10 18:03: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 C452F3A6A2B for ; Sun, 10 May 2009 18:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_24=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 I5-SN7-bU+uc for ; Sun, 10 May 2009 18:03:22 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BCFDD3A6774 for ; Sun, 10 May 2009 18:03:16 -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 <0KJG00L6AGBOGT@szxga04-in.huawei.com> for mext@ietf.org; Mon, 11 May 2009 09:04:36 +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 <0KJG00AFJGBO5R@szxga04-in.huawei.com> for mext@ietf.org; Mon, 11 May 2009 09:04:36 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJG0017NGBN5B@szxml04-in.huawei.com> for mext@ietf.org; Mon, 11 May 2009 09:04:36 +0800 (CST) Date: Mon, 11 May 2009 09:04:35 +0800 From: Yungui Wang In-reply-to: To: 'Hesham Soliman' , 'George Tsirtsis' Message-id: <008c01c9d1d4$73b9fb10$150ca40a@china.huawei.com> Organization: huawei 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: AcnPgz7qEK21nsg340a/gf8cGvfXyAABWQxwAAQqFzgABIo2YAAFy6RdAIKdSWA= Cc: 'Julien Laganier' , mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 11 May 2009 01:03:22 -0000 Hello > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Friday, May 08, 2009 5:52 PM > To: w52006@huawei.com; 'George Tsirtsis' > Cc: mext@ietf.org; 'Julien Laganier' > Subject: Re: new pad sub-option and flow identifier assignment > > > > > On 8/05/09 5:20 PM, "Yungui Wang" wrote: > > > Hello > > > > Please see solution requirement from MEXT charter... > > '' > > - 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]. > > => We're not talking about policies in this draft, we're talking about > transporting filters. We discussed this many times. Policies > can associate a > flow on with a link layer, interface ...etc on a high level. > Filters install > instances of such policies. It's not the same thing. > Thanks for your explanation, you are very good at basic accept. Of course, policy is not flow filter. However, flow filter can be generated based on policy. For example, in 3GPP, when PCC rules(policy) are downloaded to HA from PCRF, HA can generate flow filters. What I adduced was blow point > > A "Flow/binding policies exchange" solution for an exchange of > > policies from ... and from the > > Home Agent to the mobile host/router influencing the choice of the > > Care-of Address and Home Agent address. for I was doubting your point "only the MN can initiate it(flow binding)". > > " > > > > And some requirements from 3GPP 23.861 for your information. > > " > > ... > > - It should be possible for the operator to enable and control the > > simultaneous usage of multiple accesses. > > - It should be possible for the operator to enable and control the > > flow mobility. > > ... > > " > > => That's fine but: > 1. "control" is meaningless to me, and, > 2. We are developing a spec for the entire Internet. > Yeah, I agree you 'We are developing a spec for the entire Internet.' However, if this spec can't address the basic requirements, I don't think it is mature. Here, HA initiating flow binding/handover is the just one of the basic requirements. > An operator's HA can communicate policies all day to the MN, > but installing > filters from the MN to HA is what we define in the spec. We should meet requirement from Charater and actual operation. Obviously, according to Charter and actual operation, installing flow filters from HA to MN should be addressed too. > Control can mean > many things and if by that "control" the HA would reject a BU > that doesn't > comply to its policies that's fine by me. That's your personal understanding. In my mind, here "Control" means that HA can not only reject a BU, but also initiate a flow binding/handover based on policy, etc. B.R. Yungui > > > > > Above information makes me believe it is possible that HA may > > initiate the flow binding. What do you assure that only MN does? > > => This is how MIPv6 works and the right way of doing things > if you want > them to work in multi-access environments. It's not about > what's possible, > it's about the best way of doing it. > > Hesham > > > > > > > B.R. > > Yungui > > > > > > > >> -----Original Message----- > >> From: Hesham Soliman [mailto:hesham@elevatemobile.com] > >> Sent: Friday, May 08, 2009 12:56 PM > >> To: w52006@huawei.com; 'George Tsirtsis' > >> Cc: mext@ietf.org; 'Julien Laganier' > >> Subject: Re: new pad sub-option and flow identifier assignment > >> > >> > >>> > >>> 2.The FID mobility option is a common mobility option. > >>> As discussed before, either MN or HA may initiate the > >>> flow binding in a certain case. > >> > >> => No, only the MN can initiate it. > >> > >> (Personally I think it is > >>> possible for HA to initiate flow binding). That's, either > >>> MN or HA may assign FID(s) for different flows. > >>> However, in this case, the FID may be overlapped > >>> when both MN and HA are initiating different flows. > >>> So I think avoiding said collision should be considered. > >> > >> => The collision is not possible because only the MN initiates it. > >> > >> Hesham > >> > >>> > >>> > >>> B.R. > >>> Yungui > >>> > >> > >> > > > > From kaaspetersen@yahoo.dk Mon May 11 01:07: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 9A82528C0ED for ; Mon, 11 May 2009 01:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[AWL=-1.036, 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 R5r8PbuU4pQc for ; Mon, 11 May 2009 01:07:41 -0700 (PDT) Received: from web27803.mail.ukl.yahoo.com (web27803.mail.ukl.yahoo.com [217.146.182.8]) by core3.amsl.com (Postfix) with SMTP id 930A428C0E9 for ; Mon, 11 May 2009 01:07:41 -0700 (PDT) Received: (qmail 39317 invoked by uid 60001); 11 May 2009 08:09:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1242029349; bh=UusL3iosGLLNUN4IwFmQotDK5bRX8QD3DP0u16vL3Rs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=krVc4HqI4xFEpBQFqqKV7qc7zFqIPEVdpCcJe3jIMzJqZQPDE8T+/0sDHhhoyAQJ083TVUb12g7JuD4bUsjEYjSXNcz40kGTSLiL1/tINx+SMpZwvbPTbF5UA2HYs6Oa4EgqsocOOyasB3UR7JbVUi8kqDfLk7WpkraWQb0HLzg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FitwmiIyP792AaJE//WDhyQoQEbBv7+riJvelKy+EEI+r3zvhboPqpdpxgyvTJGndk/HULvSB+4MFYftzEVx0MkDiP0ElIcTfiwllNgsCeiOzrOwvnNhnC26cp7erelaVA0ehT+yz4CD95yIvQItB1/ompRcwIelEuGhrWYd+8Q=; Message-ID: <781710.38785.qm@web27803.mail.ukl.yahoo.com> X-YMail-OSG: Y04RgL4VM1noNB26eso_1glR3a5_eqMLzgqVnwHbPnkQEh41_6U36SqyXRZJjEd9QOEh31mYL7hkaPoLb5pO1TZZLjzlXqxRdgE5cgzOD902isAn6RmIBY3G7dR1a9Jzk.QkGHIVZhxXVushgRgZPefRaEL1hN1Ys_zU55WZZm8IC8g8AHatG0cy0OE4xV_8LJiH6iG_d0AgPvDirncgmpU1cd4.pe6RwtXiWjV5CCPbTyiyWLNhmN73v.9Tlcef9eHJIPVo1PzzugNHcwm8Bk9cROozGifGlB5cWHWzDbI.HpAD90jCT0qA4B4Qh57g7cUzbBCO6wWwZApy3NONMeJaCisCMLeqVdkGvYA- Received: from [193.15.240.60] by web27803.mail.ukl.yahoo.com via HTTP; Mon, 11 May 2009 08:09:09 GMT X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.1 Date: Mon, 11 May 2009 08:09:09 +0000 (GMT) From: Christian Kaas-Petersen To: mext , Romain KUNTZ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 08:07:42 -0000 When the mobile node is a 3GPP mobile phone, the mobile phone is at home when it uses its 3GPP radio link. The mobile phone may have roamed to another operator's network. In this case, IP packets take one IP hop, but doing this one IP hop means traversing many GTP, PMIP, or other tunnels, before the final stretch may be a low-bandwidth radio link. Assuming the 3GPP mobile phone also has wireless LAN, and wireless LAN is available, then the mobile phone can have its traffic delivered on the wireless LAN at a much higher bandwidth. IP packets will take many IP hops, but the final stretch is a high-bandwidth radio link. In this analysis, only the bandwidth on the radio link is considered a limiting factor.=20 This is the use case I have in mind. As I understand the CoA-on-the-home-link approach, this approach is still making use of the low-bandwidth radio link. To good question is, how often will a user be in a situation with a low-bandwidth 3GPP radio link and at the same time having=20 high-bandwidth wireless LAN access. Christian --- Den l=F8r 9/5/09 skrev Romain KUNTZ : > Fra: Romain KUNTZ > Emne: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 > Til: "mext" > Dato: l=F8rdag 9. maj 2009 18.56 > Hi, >=20 > Some comments on draft-ietf-monami6-multiplecoa-13. >=20 > First, I'd like to express that I support Arnaud's opinion > about section 5.6 (Simultaneous Home and Visited Link > Operation). I also don't see what is the motivation to > re-route and tunnel traffic from the HA to one of the MN's > CoA, while the MN is only one hop from the HA. Even if there > is a specific use-case, at the time this topology was > suggested, a simple solution that came out was to configure > a CoA on the Home link and use a tunnel via the home link. I > don't think the little overhead of this solution justifies > the complexity of the one proposed in the draft. >=20 =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig g= ode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From arno@natisbad.org Mon May 11 01:47: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 7640C3A6B79 for ; Mon, 11 May 2009 01:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 Ouk4zfkD3XhZ for ; Mon, 11 May 2009 01:47:36 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 85C7F3A68B4 for ; Mon, 11 May 2009 01:47:36 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M3RC3-0005H2-Na; Mon, 11 May 2009 10:49:03 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Christian Kaas-Petersen References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090511:mext@ietf.org::7TbM1uB+Fe/D6v27:00001laf X-Hashcash: 1:20:090511:kaaspetersen@yahoo.dk::gl0z4N0yWjeZxoHC:00000000000000000000000000000000000000007p4N X-Hashcash: 1:20:090511:kuntz@lsiit.u-strasbg.fr::ZY0ir+rCNa4RbDJ7:0000000000000000000000000000000000000BVvL Date: Mon, 11 May 2009 10:49:47 +0200 In-Reply-To: <781710.38785.qm@web27803.mail.ukl.yahoo.com> (Christian Kaas-Petersen's message of "Mon, 11 May 2009 08:09:09 +0000 (GMT)") Message-ID: <87tz3srplg.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 08:47:37 -0000 Hi, Christian Kaas-Petersen writes: > When the mobile node is a 3GPP mobile phone, the mobile phone is at > home when it uses its 3GPP radio link. The mobile phone may have > roamed to another operator's network. In this case, IP packets take > one IP hop, but doing this one IP hop means traversing > many GTP, PMIP, or other tunnels, before the final stretch may be > a low-bandwidth radio link. Assuming the 3GPP mobile phone also has > wireless LAN, and wireless LAN is available, then the mobile phone > can have its traffic delivered on the wireless > LAN at a much higher bandwidth. IP packets will take many IP hops, > but the final stretch is a high-bandwidth radio link. In this analysis, > only the bandwidth on the radio link is considered a limiting factor. > This is the use case I have in mind. Thanks for describing that use case, Christian. Someone also briefly commented to me off-list that the content of section 5.6 was needed to support 3GPP specific needs. > As I understand the CoA-on-the-home-link approach, > this approach is still making use of the low-bandwidth radio link. Well, no. The MN considers the Home Link (3GPP link) as a foreing link. It has other more efficient connection means (CoA2 on wifi iface, ...) and configure a CoA on the 3GPP radio link (say CoA1), i.e. does not deregister with the HA. This allows it to have the HA send the traffic to CoA2. > To good question is, how often will a user be in a situation with > a low-bandwidth 3GPP radio link and at the same time having > high-bandwidth wireless LAN access. At home or in a corporate network, chances are very high it will have access to a high bandwidth WLAN. When moving, access to an WLAN depends on many factors (country, location in the country, ...). In the end, it's difficult to provide a common answer. I am not familiar with 3GPP architectures so following comment is probably stupid: if the 3GPP access is bad compared to another simultaneous access I have, why not just switch off the 3GPP link in order not to use it and simply use the other access as a common foreign network (configure a CoA, register it to the HA, ...) ? Cheers, a+ From kaaspetersen@yahoo.dk Mon May 11 02:21: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 D6DD23A6AE1 for ; Mon, 11 May 2009 02:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, MANGLED_PRIOR=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 5A0pDV2JR-Dw for ; Mon, 11 May 2009 02:21:15 -0700 (PDT) Received: from web27803.mail.ukl.yahoo.com (web27803.mail.ukl.yahoo.com [217.146.182.8]) by core3.amsl.com (Postfix) with SMTP id 5793C3A6CA0 for ; Mon, 11 May 2009 02:21:09 -0700 (PDT) Received: (qmail 92603 invoked by uid 60001); 11 May 2009 09:22:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1242033758; bh=1XK9KZdTJRhLhJtXfqkNiriZuZGIonjNnHZCY7JvQLA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MqJSsZ/Vvp3n51+c+OC92yqAXzuByWPYq7TAC9wW+t4ZeO1een5JL7G5/mpG5ld6Wtw+DjEGRNp8tUqzQPCLTkzsDFnpOGQl3SiytQ2xQJYMK3hR6JXqjnXLC0ZlzAUlZoSqM2iJjrpoK0ViupfVUNQLwKSroKRRUiZFS0cLWYk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qxNDeL/7G2i3HzYJN7Hnls/RgTYZ4HoX621BLtvORTckso0fQSynCwbuYFbbtMSMIk99iNgc1ehKKiAq3z9wZ9K1cAMMjRvXEOvLJ0vOwNJ2OhnvAkJj5kAAcvRmiYrR2t1H3AaomHnRN82QIfctAaoQmi55KmzYDH6Ncy26OJI=; Message-ID: <983318.92443.qm@web27803.mail.ukl.yahoo.com> X-YMail-OSG: 1OnuwwIVM1nglS7UPkJgMORo2VRG3oVk85kgpY1bE3z.uN06zGsfL34P_9T7ideAEIMyyIcKqa95iwMAc5gsnGCcXLHVo8Vby_NpnnacYIeBx3usMkxnE6ROSa3fROcrg1sGXlztgKnZVNURdWi_t.YqjFxl1ZcsatInjziWE6PJEN05Wlqy3P3.EmZ7sQq1ES4RSgcfdEbL_coIwr8sIRtty1rwCs3e0Gj56IRTy_P_fmftGl3O6JGBLvdtI1UWgW5cuoYiISetE1IEmnWaP6ZdzuBb99nNcFRrbhMSJQ5FAGDtaGDXy5DXa9Uxeq9dPYjjT7u1F8IlXacfbn7KiHpJFdH6BkhA6.nAC3g- Received: from [193.15.240.60] by web27803.mail.ukl.yahoo.com via HTTP; Mon, 11 May 2009 09:22:37 GMT X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.1 Date: Mon, 11 May 2009 09:22:37 +0000 (GMT) From: Christian Kaas-Petersen To: Hesham Soliman , George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 11 May 2009 09:21:16 -0000 If two rules can have the same PRI, then a kind of=20 hierarchical classifier is constructed: At the top level the PRI is used, at the bottom level a yet unspecified mechanism is=20 used to select amongst the rules with the same PRI. Decisions about which rules overlap and which don't will become more and more complex over time when the "language" for expressing the rules become more and more complex. Binary filters is one such language, but other languages have been mentioned. Unless there is a good use case describing the need for two or more rules with the same PRI, as an implementer I should like to stick to the simplest case of uniqueness of PRI values, and in case a new rule is sent using a PRI already assigned to another rule, such a rule should not be installed, and an error code should be returned to the mobile node. Christian --- Den s=F8n 10/5/09 skrev George Tsirtsis : > Fra: George Tsirtsis > Emne: Re: [MEXT] flow binding draft 2 > Til: "Hesham Soliman" > Cc: "Julien Laganier" , mext@ietf.or= g > Dato: s=F8ndag 10. maj 2009 14.36 > Julien, >=20 > One thing to note is that there is no way you can put > together a > classifier without knowing exactly what order the rules > need to be > placed in the list and without understanding which ones > overlap and > which are not. The MN MUST be able to do this, otherwise > there is no > way to impose the desired behaviour. >=20 > Now also consider that whether we require a unique PRI or > not, the MN > again will have to know the above. If you require unique > PRI, the MN > will have to decide the order of overlapping rules. If we > allow more > than one rule to have the same PRI, the MN will have to > decide which > rules are not overlapping and thus they can take the same > value. >=20 > So, either way, it makes no difference to the complexity of > the MN. >=20 > On the HA side it is also easy either way. Rules are > ordered according > to PRI. Rules with the same PRI will be placed in a random > order > between them, since it makes no difference. >=20 > And just for fun, here is an example of the value of > allowing rules > with same PRI. Say you have 3 rules with PRI 1, 2, and 3. > Now you want > to add a rule which needs to be placed between 1 and 3, and > does not > overlap with 2. > If you require unique=A0 PRIs, you will have to renumber > 3 to 4 and add > the new rule as a new 3; ending up with PRI 1, 2, 3, and 4. > If you > allow for non-unique PRIs you just add the new rule with > PRI 2, > resulting in 1, 2, 2, 3. >=20 > Again, I am not saying the above presents a significant > advantage but > only that this is how all classifiers work in existing > implementations > and thus we should not do something different unless we > have a really > good reason, which IMO we do not. >=20 > Does this help? >=20 > George >=20 >=20 > On Fri, May 8, 2009 at 2:04 PM, Hesham Soliman > wrote: > > > >>> =3D> Like I said earlier, the graceful way of > handling this is for the > >>> receiver to break the tie. We need to require > this capability anyway > >>> for the receiver, that's why I don't see a > need for unique PRI. > >> > >> I could live with a tie break mechanism but, as a > sender I wouldn't like > >> to believe the tie was broke left while the sender > actually broke it > >> right. Thus if we rely on tie break, I'd rather > have us specify how > >> that works, which in turns imply that we define a > sub-order among rules > >> with same priority. I do not see the point but... > > > > =3D> I agree there would be no point in doing that > but the question is why is > > the sender sending the same priority? May be it > doesn't care. So what if > > they broke the tie differently? > > > >> > >> The simplest sub-ordering scheme I can come up > with is, for every set of > >> rules with same priority: the earliest rule > established prevails on > >> other, while rule A is earlier than rule B if 1) > rule A in is a BU send > >> before the BU that contains rule B, or 2) rule A > is placed before rule > >> B in the same BU. > >> > >> To me this is more complex while the end result is > not that different > >> from rules with unique priorities, since in both > case we do define a > >> total order amongst rules. > > > > =3D> I think if we have to make it unique then unique > PRI is the way to do it. > > But my point is that doesn't eliminate the need for a > tie breaker as a > > graceful fallback. I can't see the harm in a different > tie break at either > > end. What am I missing? > > > >> > >>> Furthermore, there can be cases where the MN > simply doesn't care and > >>> allows the HA to decide which one goes where. > >> > >> I do not understand why would the MN put forth two > overlapping rules in > >> the first place if it doesn't care... > > > > =3D> Because it's installing the rule and it doesn't > care *now*. May be later > > it will change it. I don't have a concrete example but > given that this is > > done by upper layers I'd rather err on the side of > flexibility provided that > > no harm is done. So my question to you is: What harm > do you see? > > > > Hesham > > > >> > >> --julien > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > =0A=0A=0A __________________________________________________________= =0AFind din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - http://dk.y= ahoo.com/r/pat/mm From julien.laganier.ietf@googlemail.com Mon May 11 02:39:27 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 CDFAA3A6BA8 for ; Mon, 11 May 2009 02:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_PRIOR=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 RpBE1MXEdttw for ; Mon, 11 May 2009 02:39:26 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 28E353A6A8B for ; Mon, 11 May 2009 02:39:25 -0700 (PDT) Received: by ewy24 with SMTP id 24so3290255ewy.37 for ; Mon, 11 May 2009 02:40:54 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=Gkf+c3fizWRYnmBG++Pb9x4UeYFbASp5o3bmc8m9dys=; b=LNCFS/2UzsU9od34howDhzV+0+2K7ACs7SYDlx/FwjjK/PrT8L8g5d8ZsOhpHUGRPb /a0doYsxTb5jrA6tFtyQbsH6hj9u66j1Y+BEu+BIlAwXRwbzTvRLe2OsdJQskYK4Fgf3 3Trn3LzLNBhw5ct1K6RY4sb47A9pot+3Y9V/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=dGwXVIMhfixbT7KAUCuJm07Fvr0xmaOanTZBRcysNfgESc2JwHVbxlnwSGwaej2kBw cPV6eOibZVuKRakmnhGmsBLaMFSzYlZY0SakfM2C01ivfSmLeFDYnRpFprlRvS2V/wbK LCTDLJ0yq54/5UXRRylxECKeZG6VFkc6SNEAE= Received: by 10.216.0.73 with SMTP id 51mr3223365wea.52.1242034853748; Mon, 11 May 2009 02:40:53 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id t2sm12929926gve.0.2009.05.11.02.40.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 02:40:53 -0700 (PDT) From: Julien Laganier To: George Tsirtsis Date: Mon, 11 May 2009 11:40:47 +0200 User-Agent: KMail/1.9.10 References: <200905081410.04985.julien.laganier.IETF@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905111140.48600.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 11 May 2009 09:39:27 -0000 Hi George, On Sunday 10 May 2009, George Tsirtsis wrote: > Julien, > > One thing to note is that there is no way you can put together a > classifier without knowing exactly what order the rules need to be > placed in the list and without understanding which ones overlap and > which are not. The MN MUST be able to do this, otherwise there is no > way to impose the desired behaviour. You can build a classifier in which rules are ordered and the classifier needs not to determine overlaps, which is incidentaly what IPsec does, see this excerpt from 4301: The SPD is an ordered database, consistent with the use of Access Control Lists (ACLs) or packet filters in firewalls, routers, etc. The ordering requirement arises because entries often will overlap due to the presence of (non-trivial) ranges as values for selectors. Thus, a user or administrator MUST be able to order the entries to express a desired access control policy. There is no way to impose a general, canonical order on SPD entries, because of the allowed use of wildcards for selector values and because the different types of selectors are not hierarchically related. In that sense the priority is just a way to express within the MN - HA signalling, and the priority needs not to be exposed to ULPs. > Now also consider that whether we require a unique PRI or not, the MN > again will have to know the above. If you require unique PRI, the MN > will have to decide the order of overlapping rules. If we allow more > than one rule to have the same PRI, the MN will have to decide which > rules are not overlapping and thus they can take the same value. As above, overlapping is irrelevant once we require ordered rules. > So, either way, it makes no difference to the complexity of the MN. I disagree. Ordered list is just simple since I do not need to determine overlaps b/w rules. > On the HA side it is also easy either way. Rules are ordered > according to PRI. Rules with the same PRI will be placed in a random > order between them, since it makes no difference. Hmmm... makes no difference with what? with another random order? > And just for fun, here is an example of the value of allowing rules > with same PRI. Say you have 3 rules with PRI 1, 2, and 3. Now you > want to add a rule which needs to be placed between 1 and 3, and does > not overlap with 2. > If you require unique PRIs, you will have to renumber 3 to 4 and add > the new rule as a new 3; ending up with PRI 1, 2, 3, and 4. If you > allow for non-unique PRIs you just add the new rule with PRI 2, > resulting in 1, 2, 2, 3. For a start one would use rule numbered 10, 20 and 30, then if you need a new rule b/w 10 and 30, you pick 15, or 25, depending whether you want to prioritize over 20 or not. If you ever end up with a full interval [10-20] then you can start to renumber. Note that all of these priorities can be kept entirely internal to MIPv6 and hidden from ULPs if an appropriate API is devised. The ULP needs not to care about which priority is in use, it only cares about the order. A strawman API could look like: get_ordered_ruleset(ruleset *rs); insert_rule_in_ruleset(ruleset *rs, rule *rule_below, rule *new_rule); modify_rule_in_ruleset(ruleset *rs, rule *old_rule, rule *new_rule); delete_rule_in_ruleset(ruleset *rs, rule *rule); > Again, I am not saying the above presents a significant advantage but > only that this is how all classifiers work in existing > implementations and thus we should not do something different unless > we have a really good reason, which IMO we do not. Some classifiers may work as you say, but others (including IPsec and some firewalls) do not, thus I disagree we would be doing something different by requiring a priority to be unique, i.e., requiring the ruleset to be ordered. As to the reason to do ordered ruleset, we have one: simplicity. --julien > On Fri, May 8, 2009 at 2:04 PM, Hesham Soliman wrote: > >>> => Like I said earlier, the graceful way of handling this is for > >>> the receiver to break the tie. We need to require this capability > >>> anyway for the receiver, that's why I don't see a need for unique > >>> PRI. > >> > >> I could live with a tie break mechanism but, as a sender I > >> wouldn't like to believe the tie was broke left while the sender > >> actually broke it right. Thus if we rely on tie break, I'd rather > >> have us specify how that works, which in turns imply that we > >> define a sub-order among rules with same priority. I do not see > >> the point but... > > > > => I agree there would be no point in doing that but the question > > is why is the sender sending the same priority? May be it doesn't > > care. So what if they broke the tie differently? > > > >> The simplest sub-ordering scheme I can come up with is, for every > >> set of rules with same priority: the earliest rule established > >> prevails on other, while rule A is earlier than rule B if 1) rule > >> A in is a BU send before the BU that contains rule B, or 2) rule A > >> is placed before rule B in the same BU. > >> > >> To me this is more complex while the end result is not that > >> different from rules with unique priorities, since in both case we > >> do define a total order amongst rules. > > > > => I think if we have to make it unique then unique PRI is the way > > to do it. But my point is that doesn't eliminate the need for a tie > > breaker as a graceful fallback. I can't see the harm in a different > > tie break at either end. What am I missing? > > > >>> Furthermore, there can be cases where the MN simply doesn't care > >>> and allows the HA to decide which one goes where. > >> > >> I do not understand why would the MN put forth two overlapping > >> rules in the first place if it doesn't care... > > > > => Because it's installing the rule and it doesn't care *now*. May > > be later it will change it. I don't have a concrete example but > > given that this is done by upper layers I'd rather err on the side > > of flexibility provided that no harm is done. So my question to you > > is: What harm do you see? > > > > Hesham > > > >> --julien From julien.laganier.ietf@googlemail.com Mon May 11 03:54: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 11F023A6B3F for ; Mon, 11 May 2009 03:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 aXLOGdN5r7VU for ; Mon, 11 May 2009 03:54:18 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 10C823A69FB for ; Mon, 11 May 2009 03:54:17 -0700 (PDT) Received: by ewy24 with SMTP id 24so3327067ewy.37 for ; Mon, 11 May 2009 03:55:46 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=MwkH2GBL+RMjZJvej7kk7coUV09Q045Zj0RQQ7VUe+Q=; b=Zv/iAChxU82OV8gPiGPAB2KWBX2/oKl3NXYwtDyci05MnW8Dqq9L0XD+zPOPfIGQbe 4fD4bZd3nRO423jakiOv2NmL/cpF5IKIzMzY51VE5iDoGzixb9M6cY9F0WUwFfzUuLI2 L6d8jCLg9ME7bC3G0Bn72QAa0CAi8MIvQNX2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=e7HonOECfOLAG5lpC4ampZS7VM2Luc+Baq4YnCTtHvnkHa32EAjWfUpnY5uLdT5K67 /w2XzpDUA5nSA7mhx7DL1YxPfEGGfmdWyGuJzA0yvcuAWlH+FRzkZfT8Ojdl1vYm9cov T8EmfYx7Svw4DJYjox/XJC8ZqB9gJ4r0Xr0cw= Received: by 10.216.28.193 with SMTP id g43mr3245212wea.192.1242039345959; Mon, 11 May 2009 03:55:45 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id j8sm13031413gvb.23.2009.05.11.03.55.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 03:55:45 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Mon, 11 May 2009 12:55:42 +0200 User-Agent: KMail/1.9.10 References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <87tz3srplg.fsf@small.ssi.corp> In-Reply-To: <87tz3srplg.fsf@small.ssi.corp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905111255.43046.julien.laganier.IETF@googlemail.com> Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 10:54:19 -0000 Hello Arnaud, On Monday 11 May 2009, Arnaud Ebalard wrote: > I am not familiar with 3GPP architectures so following comment is > probably stupid: if the 3GPP access is bad compared to another > simultaneous access I have, why not just switch off the 3GPP link in > order not to use it and simply use the other access as a common > foreign network (configure a CoA, register it to the HA, ...) ? The 3GPP access may be worse than the WLAN in some aspects (e.g. bandwidth) but better in other aspects (e.g. latency, packet loss), thus it makes sense to allow to receive some traffic (say VoIP) on the home link (3GPP access) while diverting some other traffic (say bulk data transfer) on the foreign link (non-3GPP access, e.g. a WLAN). --julien From julien.laganier.ietf@googlemail.com Mon May 11 03:57: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 2D4253A6C81 for ; Mon, 11 May 2009 03:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 pOxEfdZIkYpO for ; Mon, 11 May 2009 03:57:54 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 28BCB3A6C57 for ; Mon, 11 May 2009 03:57:53 -0700 (PDT) Received: by ewy24 with SMTP id 24so3328745ewy.37 for ; Mon, 11 May 2009 03:59:21 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=u2VVgfFdpV5yAT5MEKoHy/EOfhqpn/kz3Q+hc2y1kcY=; b=O+Rz+i/DmZq4j8eRXIIQ6PaQN7vKvD07lV6T6OxW7jyKhtGiKEieqVsgzt0uJyrwy2 e8XigAGWiNCp7FlgoQw4/umOd7yYhDq8n4Xcwz7FMUt76fx3UQAdY61wcWsgvD925Mvo 2442fpnVCddmzzTHmv2ljEpduQEDXNuUfLNWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=QyGGhFbmEK6tlYN1djonPML7MmAGrvam8oqLVBgdc4RUSI/XYCu4ffqypi0RcUQkXX E9vuuQFFW52cgo6wVU3oU8B1YC5+iowckxepGkThvpF5d3iF9SjmHcrdDpGeNsmK5d/o UdOR4pPQxCJSupg1FTNXRTqaDsdZsQZbfiJyA= Received: by 10.216.72.207 with SMTP id t57mr3271084wed.158.1242039561710; Mon, 11 May 2009 03:59:21 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id u14sm12292078gvf.17.2009.05.11.03.59.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 03:59:21 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Mon, 11 May 2009 12:59:15 +0200 User-Agent: KMail/1.9.10 References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <87tz3srplg.fsf@small.ssi.corp> In-Reply-To: <87tz3srplg.fsf@small.ssi.corp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905111259.15171.julien.laganier.IETF@googlemail.com> Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 10:57:55 -0000 On Monday 11 May 2009, Arnaud Ebalard wrote: > > As I understand the CoA-on-the-home-link approach, > > this approach is still making use of the low-bandwidth radio link. > > Well, no. The MN considers the Home Link (3GPP link) as a foreing > link. It has other more efficient connection means (CoA2 on wifi > iface, ...) and configure a CoA on the 3GPP radio link (say CoA1), > i.e. does not deregister with the HA. This allows it to have the HA > send the traffic to CoA2. In 3GPP it isn't up to the MN to consider where is the home link, it is an architectural choice that was made. The home link _is_ the 3GPP access. --julien From arno@natisbad.org Mon May 11 04:07: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 B93393A6D74 for ; Mon, 11 May 2009 04:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 PG395NNPCVmk for ; Mon, 11 May 2009 04:07:32 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id DCC1B3A6BF8 for ; Mon, 11 May 2009 04:07:31 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M3TNO-0006YW-5Z; Mon, 11 May 2009 13:08:54 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Julien Laganier References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <87tz3srplg.fsf@small.ssi.corp> <200905111255.43046.julien.laganier.IETF@googlemail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090511:julien.laganier.ietf@googlemail.com::Af3xu+j847QL3Ef8:000000000000000000000000000Rek X-Hashcash: 1:20:090511:mext@ietf.org::tRIAxyPh0W5GIqTK:00001E88 X-Hashcash: 1:20:090511:kaaspetersen@yahoo.dk::cxJbkWB9ZFXYY3hL:00000000000000000000000000000000000000004IMa Date: Mon, 11 May 2009 13:09:37 +0200 In-Reply-To: <200905111255.43046.julien.laganier.IETF@googlemail.com> (Julien Laganier's message of "Mon, 11 May 2009 12:55:42 +0200") Message-ID: <878wl3sxou.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 11:07:32 -0000 Hi Julien, Julien Laganier writes: > On Monday 11 May 2009, Arnaud Ebalard wrote: >> I am not familiar with 3GPP architectures so following comment is >> probably stupid: if the 3GPP access is bad compared to another >> simultaneous access I have, why not just switch off the 3GPP link in >> order not to use it and simply use the other access as a common >> foreign network (configure a CoA, register it to the HA, ...) ? > > The 3GPP access may be worse than the WLAN in some aspects (e.g. > bandwidth) but better in other aspects (e.g. latency, packet loss), > thus it makes sense to allow to receive some traffic (say VoIP) on the > home link (3GPP access) while diverting some other traffic (say bulk > data transfer) on the foreign link (non-3GPP access, e.g. a WLAN). Well, that makes sense. Even if I don't like the solution in term of complexity, I understand the motivation based on your argument and the explanation from Christian. Thanks. Considering the example you give, maybe you have some comment (in the context of MCoA) on the current inability for a MN that has a binding with a CN to tell that CN that it should route some flows to the HoA of the MN instead of sending those to the CoA. Cheers, a+ From julien.laganier.ietf@googlemail.com Mon May 11 04: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 6A85A3A6A9F for ; Mon, 11 May 2009 04:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 Pd8G0BncNYzS for ; Mon, 11 May 2009 04:19:32 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 4573A3A6911 for ; Mon, 11 May 2009 04:19:31 -0700 (PDT) Received: by ewy24 with SMTP id 24so3340253ewy.37 for ; Mon, 11 May 2009 04:20:59 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=54Qdk7Acmm5XFqVkXdQf72uQjbeSUtkecaWx+U6+qjg=; b=tqTRLakh257ugv0QebraS8NHNFaCtGKQwT8r4aBcVoWn6wpxK3hp7mmCsfer+KCKWJ 3CaFKTPG2g7EGIAKHR52daoUitkCQGeONN0CNbXWXDnzyHV9NwvzNhS3CxaSn67zmvdR CX5bm0mHTB/9D7tGnyiyO3Z/VRg9MAeFadu6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=Wg+Nx2UfdTkj42ql5Xkqy+ufqwWypkMs71y3vsa9pEdz44X3W43xCsVofnLHpl8y/N F/KRpZcjCDk/NlNqCiTunH2KXC7L5VBAGt93cBJmu5HemV1oGJVlWvwP08Jef6OFfA41 qB/edNk/T1eczuW6QqLCJ1hJFrLzXPvno+OMo= Received: by 10.216.29.80 with SMTP id h58mr3320984wea.159.1242040859065; Mon, 11 May 2009 04:20:59 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id j8sm232750gvb.11.2009.05.11.04.20.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 04:20:57 -0700 (PDT) From: Julien Laganier To: Arnaud Ebalard Date: Mon, 11 May 2009 13:20:54 +0200 User-Agent: KMail/1.9.10 References: <49AF10F3.8080403__23090.1656010703$1236210023$gmane$org@earthlink.net> <87zlf8mx6h.fsf@small.ssi.corp> In-Reply-To: <87zlf8mx6h.fsf@small.ssi.corp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905111320.54733.julien.laganier.IETF@googlemail.com> Cc: IETF MEXT WG ML Subject: Re: [MEXT] Potential new issues for rfc3775bis 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, 11 May 2009 11:19:33 -0000 Arnaud, Sorry that I'm coming back late with this. See below: On Thursday 26 March 2009, Arnaud Ebalard wrote: > > "Charles E. Perkins" writes: > > Hello folks, > > > > During and after the last IETF meeting, there were several more > > topics raised as potential issues to be addressed during the > > refinement of rfc3775bis. Here are the ones I have identified > > from looking through the mail archives: > > > > 1. BU de-registration race condition, depending on exactly > > when the security information for the mobile node is discarded. > > > > 2. Malicious Router Advertisement can cause mobile node > > deregistration on foreign network > > I was not in SF but expected this issue (2.) to raise some concerns > and discussions. I was told it was finally dropped at the end of the > session with the argument that it is considered a NDP issue. Don't > hesitate to correct me if that summary is incorrect. > > AFAICT, NDP was known as an insecure mechanism (just like ARP is) > when RFC 3775 was written. The Home Link Detection mechanism > specified in section 11.5.4 of RFC 3775 is based on that insecure > information. [...] > The conclusion could be that this is not a 3775 problem, but a > 3776/4877 one. Anyway, I think it is a MIPv6 security issue which > should be considered, clarified and solved in the context of the WG. > > Marcelo and Julien, can you provide your chairs' thoughts on previous > paragraph? There is no issue at all, and in particular no issue w.r.t. Mobile IPv6. It is a given that NDP alone is insecure, and the IETF has a solution: Secure Neighbor Discovery (SEND) [RFC3971]. --julien From arno@natisbad.org Mon May 11 04: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 CE3F53A6BF1 for ; Mon, 11 May 2009 04:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 I6Ja5PHccx8c for ; Mon, 11 May 2009 04:38:37 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 7E62A3A6D96 for ; Mon, 11 May 2009 04:38:37 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M3Tqz-0006dd-TL; Mon, 11 May 2009 13:39:30 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Julien Laganier References: <49AF10F3.8080403__23090.1656010703$1236210023$gmane$org@earthlink.net> <87zlf8mx6h.fsf@small.ssi.corp> <200905111320.54733.julien.laganier.IETF@googlemail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090511:marcelo@it.uc3m.es::SHEwgFPz3ghY2ciX:000000000000000000000000000000000000000000003XL X-Hashcash: 1:20:090511:mext@ietf.org::wDyMa0DJLlbjeMpa:00003OBf X-Hashcash: 1:20:090511:julien.laganier.ietf@googlemail.com::rcegK03emBZ/grPs:0000000000000000000000000050cx X-Hashcash: 1:20:090511:charles.perkins@earthlink.net::qy+rGdUOBbmcSSdq:000000000000000000000000000000004lZ5 Date: Mon, 11 May 2009 13:40:12 +0200 In-Reply-To: <200905111320.54733.julien.laganier.IETF@googlemail.com> (Julien Laganier's message of "Mon, 11 May 2009 13:20:54 +0200") Message-ID: <87hbzrrhpf.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IETF MEXT WG ML Subject: Re: [MEXT] Potential new issues for rfc3775bis 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, 11 May 2009 11:38:38 -0000 Hi Julien, Julien Laganier writes: > Sorry that I'm coming back late with this. See below: No problem. But see below >> The conclusion could be that this is not a 3775 problem, but a >> 3776/4877 one. Anyway, I think it is a MIPv6 security issue which >> should be considered, clarified and solved in the context of the WG. >> >> Marcelo and Julien, can you provide your chairs' thoughts on previous >> paragraph? > > There is no issue at all, and in particular no issue w.r.t. Mobile IPv6. > > It is a given that NDP alone is insecure, and the IETF has a solution: > Secure Neighbor Discovery (SEND) [RFC3971]. The mail you quote is almost 7 weeks old. Meanwhile (less than 2 weeks ago), I took the time to make a draft which *precisely* explains the issues (NDP as a trigger, BU/BA formatting, lose description of expected processing in RFC 3775, ...) and implementing attacks against a MIPv6 implementation. I understand you may have a limited amount of time but just nacking the issues with the 'SEND' magical keyword is a bit easy I think (just my opinion). If you find the time to just read the draft and still have the same opinion, then you get my word I won't bother you directly with with that again. You may even find the draft entertaining ... Cheers, a+ The mail I sent recently: > Hello, > > I have just submitted a draft describing possible attacks (implemented > for demonstration against an existing implementation) associated w/ the > Home Link Detection mechanism and the Home Return procedure. > > If some among you find some interest in the topic, I'd be interested by > some feedback (questions, comments). > > Link to the document: > > http://www.ietf.org/internet-drafts/draft-ebalard-mext-hld-security-00.txt > > Cheers, > > a+ > > IETF I-D Submission Tool writes: > >> A new version of I-D, draft-ebalard-mext-hld-security-00.txt has been >> successfuly submitted by Arnaud Ebalard and posted to the IETF >> repository. >> >> Filename: draft-ebalard-mext-hld-security >> Revision: 00 >> Title: Mobile IPv6 Home Link Detection Mechanism Security considerations >> Creation_date: 2009-04-30 >> WG ID: Independent Submission >> Number_of_pages: 32 >> >> Abstract: >> >> MIPv6 defines the concept of Home Network for a MN, in opposition to >> the foreign network where this entity may find itself. A ``Home Link >> Detection'' mechanism is also specified to allow the MN to detect >> when it is at home. >> >> MIPv6 specification mandates the use of IPsec for protecting main >> signaling traffic and also defines how IPsec can be used to protect >> data traffic between the MN and its HA. Even if optional, it is >> expected that many deployments of MIPv6 will use it by default for MN >> which may roam outside a trusted infrastructure (e.g. outside a >> mobile operator network). >> >> When a MN detects it is at home, it is expected to stop IPsec >> protection for data traffic exchanged with its Home Agent. That >> event is the result of the Home Return procedure, triggered by the >> Home Link Detection mechanism. >> >> This document discusses the possible threats and security impacts >> associated with the use of this insecure NDP-based mechanism as a >> trigger to drop IPsec protection of data traffic for the MN. It also >> provides some results on the implementation of the attacks against an >> existing MIPv6 module. Possible solutions are suggested. From mer@kafka.verkstad.net Mon May 11 04:42: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 A1B3C3A6EBC for ; Mon, 11 May 2009 04:42: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 opoLkRPt8esv for ; Mon, 11 May 2009 04:42:01 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id C4D5F3A69A8 for ; Mon, 11 May 2009 04:42:00 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 68322710B81; Mon, 11 May 2009 13:43:28 +0200 (CEST) Date: Mon, 11 May 2009 13:43:28 +0200 From: Michael Eriksson To: George Tsirtsis Message-ID: <20090511114328.GB15035@kafka.verkstad.net> References: <200905071721.38234.julien.laganier.IETF@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 11 May 2009 11:42:01 -0000 On Thu, May 07, 2009 at 16:54:28 +0100, George Tsirtsis wrote: > We also need to discuss whether the granularity of the pointers > described in the draft provide sufficient flexibility, in which case I > believe that text based flow description offers little further > advantage. Well, a text format has a number of advantages: - It is easier to generate (think printf). - It is less complex (cf. your bit vector). - Static flow rules are simple, just edit them the with your favorite text editor. - It is easier to debug. IETF has a history of text protocols (SMTP, NNTP, HTTP, SIP, ...), and that is for a good reason. - It is easier to extend. On the other hand, what advantages would you say a binary format has? The only one that I can think of is that it may save a few bytes in some cases, but I fail to see any reasonable use case where this would matter at all. Regards, Michael From julien.laganier.ietf@googlemail.com Mon May 11 05:11: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 B4B9E3A6930 for ; Mon, 11 May 2009 05:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 EHFPrMLDv9VP for ; Mon, 11 May 2009 05:11:08 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 641703A6B67 for ; Mon, 11 May 2009 05:11:08 -0700 (PDT) Received: by ewy24 with SMTP id 24so3368268ewy.37 for ; Mon, 11 May 2009 05:12:36 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=WkjsQ5Hub5U0Se+1iC2d/1syPK5rLVDDnr7ORajhLlE=; b=x3EH9FKdGV+ASu/FyDUm8qOADQqILGxO6zpZ2KfPCRyPU35q3htkiOYn9iF0vTHC7R u+riV0+ht+zoc+qEmggaGEQxxeDu7g85qyL6TjvnggICc8rZoH13FiAh5QsQywT3iIUM 2rkodtcAPVaLB7vw2N2s5IWTKB/mypmRz26Sk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=ip73g2q/T0RNZeoZM5ROR5jZqdlWkOSTnDe9McjVV4DTKxQdw0fXSY8d5gWqjqnoLM XXjUWXwbR8f8Ej2JUBErItQoKoYAWnaC/WFzhihLlcbN2Rja4u5UQNNy+WUYFdQcjsNJ Cf+HgyuL3Gfo6WslTVEFyI0Cn9yXLV5d8rw6Y= Received: by 10.216.36.209 with SMTP id w59mr3366849wea.67.1242043956444; Mon, 11 May 2009 05:12:36 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id x6sm12586279gvf.21.2009.05.11.05.12.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 05:12:35 -0700 (PDT) From: Julien Laganier To: Michael Eriksson Date: Mon, 11 May 2009 14:12:25 +0200 User-Agent: KMail/1.9.10 References: <20090511114328.GB15035@kafka.verkstad.net> In-Reply-To: <20090511114328.GB15035@kafka.verkstad.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905111412.26321.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 11 May 2009 12:11:09 -0000 Hello Michael, On Monday 11 May 2009, Michael Eriksson wrote: > On Thu, May 07, 2009 at 16:54:28 +0100, George Tsirtsis wrote: > > We also need to discuss whether the granularity of the pointers > > described in the draft provide sufficient flexibility, in which > > case I believe that text based flow description offers little > > further advantage. > > Well, a text format has a number of advantages: > > - It is easier to generate (think printf). In my view this is a blanket statement. IMHO memcpy() et al. are simpler than printf. > - It is less complex (cf. your bit vector). Again, IMHO a blanket statement. I'd rather parse a well defined simple binary format than text. The bit and byte vector I proposed are straightforward and simple in my view. > - Static flow rules are simple, just edit them the with your favorite > text editor. The average user is never going to edit any flow rules, thus I do not think that the ability to edit them with a text editor is key (My mom doesn't know what text is -- she uses Word :-). Even if it was, one can simply build a tool that takes binary and output text and vice versa. > - It is easier to debug. IETF has a history of text protocols (SMTP, > NNTP, HTTP, SIP, ...), and that is for a good reason. To me this looks like comparing apple and oranges. The protocols you're citing above are all application layer protocol. We are talking here about a network layer protocol. Do you know many network layer (or even transport) IETF protocols that use text encoding? > - It is easier to extend. Again, IMHO a blanket statememt, and YMMV. > On the other hand, what advantages would you say a binary format has? > The only one that I can think of is that it may save a few bytes in > some cases, but I fail to see any reasonable use case where this > would matter at all. See above, I disagree with you that a text format is at advantages over a binary format. In my view the binary format only has advantages, it is simpler to generate, to parse, it conforms to the way IETF builds network layer protocols, and as you note, has a more bandwidth efficient encoding. --julien From tsirtsis@googlemail.com Mon May 11 06:24: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 B11963A6F21 for ; Mon, 11 May 2009 06:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_PRIOR=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 rZJBaj2X5ae7 for ; Mon, 11 May 2009 06:24:55 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 25C223A6929 for ; Mon, 11 May 2009 06:24:54 -0700 (PDT) Received: by bwz22 with SMTP id 22so2625376bwz.37 for ; Mon, 11 May 2009 06:26: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=DlFnTxrTkoM3G/DHBqVh0qVmUIhFEZry398LvExYxJY=; b=mgUC0QOh8dgatPs+bxmWGHbnBEB/JaoubwR983MkBzmQ3UAVdUdAEf6IsDa+izD7Tv MLdX0QYoTM007mGIAaZNcxwdswGwcRpTyUFvZe8aq7bhWn+07KoSPN1Y1H1bC48ysnUQ NT45oft+OmTiIjC9ry2w7wd2ofdi2gNUJ0n/E= 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=S5AO2muEwfolEYC75xqiYYJGaG3sa94DsZY/mXKoyDV/9ICdTF4YRs6e1Rk98JFt4I 80ytJNgpiOFUT/omsOFBqmop0U9IqTpQsbO6VwU4wn/aFUzyByr8DxWh688mhK6H8TrP 22E4OIqYl4RkcaQ78YyD2ZHal7qUJCP/JL3Rw= MIME-Version: 1.0 Received: by 10.223.110.200 with SMTP id o8mr3679540fap.56.1242048382805; Mon, 11 May 2009 06:26:22 -0700 (PDT) In-Reply-To: <200905111140.48600.julien.laganier.IETF@googlemail.com> References: <200905081410.04985.julien.laganier.IETF@googlemail.com> <200905111140.48600.julien.laganier.IETF@googlemail.com> Date: Mon, 11 May 2009 14:26:22 +0100 Message-ID: From: George Tsirtsis To: Julien Laganier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 11 May 2009 13:24:56 -0000 On Mon, May 11, 2009 at 10:40 AM, Julien Laganier wrote: > Hi George, > > On Sunday 10 May 2009, George Tsirtsis wrote: >> Julien, >> >> One thing to note is that there is no way you can put together a >> classifier without knowing exactly what order the rules need to be >> placed in the list and without understanding which ones overlap and >> which are not. The MN MUST be able to do this, otherwise there is no >> way to impose the desired behaviour. > > You can build a classifier in which rules are ordered and the classifier > needs not to determine overlaps, which is incidentaly what IPsec does, > see this excerpt from 4301: > > =C2=A0 The SPD is an ordered database, consistent with the use of Access > =C2=A0 Control Lists (ACLs) or packet filters in firewalls, routers, etc. > =C2=A0 The ordering requirement arises because entries often will overlap > =C2=A0 due to the presence of (non-trivial) ranges as values for selector= s. > =C2=A0 Thus, a user or administrator MUST be able to order the entries to > =C2=A0 express a desired access control policy. =C2=A0There is no way to = impose a > =C2=A0 general, canonical order on SPD entries, because of the allowed us= e > =C2=A0 of wildcards for selector values and because the different types o= f > =C2=A0 selectors are not hierarchically related. > > In that sense the priority is just a way to express within the MN - HA > signalling, and the priority needs not to be exposed to ULPs. > GT> I am sure I lost your point because what I understand from the text you quote exactly the same point I am making i.e., when you put together a classifier you need to understand when rules overlap. What do ULPs have to do with anything? >> Now also consider that whether we require a unique PRI or not, the MN >> again will have to know the above. If you require unique PRI, the MN >> will have to decide the order of overlapping rules. If we allow more >> than one rule to have the same PRI, the MN will have to decide which >> rules are not overlapping and thus they can take the same value. > > As above, overlapping is irrelevant once we require ordered rules. > >> So, either way, it makes no difference to the complexity of the MN. > > I disagree. Ordered list is just simple since I do not need to determine > overlaps b/w rules. > GT> I think we are getting horribly confused. What I propose is that rules are ordered. Overlapping rules should have different PRI to indicate the order. It is non-overlapping rules that are next to each other that do not need different PRIs since the order does not matter. >> On the HA side it is also easy either way. Rules are ordered >> according to PRI. Rules with the same PRI will be placed in a random >> order between them, since it makes no difference. > > Hmmm... makes no difference with what? with another random order? > GT> It makes no different whether all rules have different PRIs or some have the same PRI. >> And just for fun, here is an example of the value of allowing rules >> with same PRI. Say you have 3 rules with PRI 1, 2, and 3. Now you >> want to add a rule which needs to be placed between 1 and 3, and does >> not overlap with 2. >> If you require unique =C2=A0PRIs, you will have to renumber 3 to 4 and a= dd >> the new rule as a new 3; ending up with PRI 1, 2, 3, and 4. If you >> allow for non-unique PRIs you just add the new rule with PRI 2, >> resulting in 1, 2, 2, 3. > > For a start one would use rule numbered 10, 20 and 30, then if you need > a new rule b/w 10 and 30, you pick 15, or 25, depending whether you > want to prioritize over 20 or not. > GT> of course, it was just an example. > If you ever end up with a full interval [10-20] then you can start to > renumber. > > Note that all of these priorities can be kept entirely internal to MIPv6 > and hidden from ULPs if an appropriate API is devised. The ULP needs > not to care about which priority is in use, it only cares about the > order. > > A strawman API could look like: > > =C2=A0get_ordered_ruleset(ruleset *rs); > =C2=A0insert_rule_in_ruleset(ruleset *rs, rule *rule_below, rule *new_rul= e); > =C2=A0modify_rule_in_ruleset(ruleset *rs, rule *old_rule, rule *new_rule)= ; > =C2=A0delete_rule_in_ruleset(ruleset *rs, rule *rule); > >> Again, I am not saying the above presents a significant advantage but >> only that this is how all classifiers work in existing >> implementations and thus we should not do something different unless >> we have a really good reason, which IMO we do not. > > Some classifiers may work as you say, but others (including IPsec and > some firewalls) do not, thus I disagree we would be doing something > different by requiring a priority to be unique, i.e., requiring the > ruleset to be ordered. As to the reason to do ordered ruleset, we have > one: simplicity. > GT> Julien, there is no difference at the level of simplicity that I can see. Lets put this differently. Do you agree that for the receiver i.e., the HA/CN whether some rules have the same PRI or not it makes no difference? i.e., it is no simpler or complicated to implement that HA/CN part of this? If yes, then it is up to the implementer of the MN to decide whether he/she wants to use the same PRI for non-overlapping rules (as the draft suggests) or if all rules have different PRIs (as you/Christian seem to prefer). This way we leave it flexible without hurting interoperability. > --julien > >> On Fri, May 8, 2009 at 2:04 PM, Hesham Soliman > wrote: >> >>> =3D> Like I said earlier, the graceful way of handling this is for >> >>> the receiver to break the tie. We need to require this capability >> >>> anyway for the receiver, that's why I don't see a need for unique >> >>> PRI. >> >> >> >> I could live with a tie break mechanism but, as a sender I >> >> wouldn't like to believe the tie was broke left while the sender >> >> actually broke it right. Thus if we rely on tie break, I'd rather >> >> have us specify how that works, which in turns imply that we >> >> define a sub-order among rules with same priority. I do not see >> >> the point but... >> > >> > =3D> I agree there would be no point in doing that but the question >> > is why is the sender sending the same priority? May be it doesn't >> > care. So what if they broke the tie differently? >> > >> >> The simplest sub-ordering scheme I can come up with is, for every >> >> set of rules with same priority: the earliest rule established >> >> prevails on other, while rule A is earlier than rule B if 1) rule >> >> A in is a BU send before the BU that contains rule B, or 2) rule A >> >> is placed before rule B in the same BU. >> >> >> >> To me this is more complex while the end result is not that >> >> different from rules with unique priorities, since in both case we >> >> do define a total order amongst rules. >> > >> > =3D> I think if we have to make it unique then unique PRI is the way >> > to do it. But my point is that doesn't eliminate the need for a tie >> > breaker as a graceful fallback. I can't see the harm in a different >> > tie break at either end. What am I missing? >> > >> >>> Furthermore, there can be cases where the MN simply doesn't care >> >>> and allows the HA to decide which one goes where. >> >> >> >> I do not understand why would the MN put forth two overlapping >> >> rules in the first place if it doesn't care... >> > >> > =3D> Because it's installing the rule and it doesn't care *now*. May >> > be later it will change it. I don't have a concrete example but >> > given that this is done by upper layers I'd rather err on the side >> > of flexibility provided that no harm is done. So my question to you >> > is: What harm do you see? >> > >> > Hesham >> > >> >> --julien > From tsirtsis@googlemail.com Mon May 11 06:39: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 0131128C105 for ; Mon, 11 May 2009 06:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.163, 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 hoVGYH75-lqo for ; Mon, 11 May 2009 06:39:10 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 88BC83A6CFD for ; Mon, 11 May 2009 06:39:09 -0700 (PDT) Received: by bwz22 with SMTP id 22so2638461bwz.37 for ; Mon, 11 May 2009 06:40:37 -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=Q9FXgjPCz7qk/Dv3oiXOKPH0XjiCUvRMpmIaa2lY2WI=; b=pAoDRsc2OCEuqkziRpmdRCRcVDzQYCVMhTTG2hWcg++ioJmD4abquSPJ/jXP3v1jtB VBXHALP2YvAUgqUQ0kXRkSj7wpxJPSgrRjgjKI98r2QqB2mkOtpqDTd2ELPFP6bmd9g6 RZegWeDBBnQaMHPLBg/t/bk7I3XKgznosBcbY= 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=nHD1Hu0Zq8lu/HQxZKR1dxIrCYUNe6M5yvM0zjHyf8CvpNqs9qPweFKwFoQks168Fe RzjZct6bBTBdbGk63XhOdFTTKoexRo+CD1zW3Ly26Ki5/h4yl3y6Y9tXgtUfIiO/QSYW Adyf2aSjHIGHQW6TrUupdDWhckfTONd20gpPM= MIME-Version: 1.0 Received: by 10.223.113.9 with SMTP id y9mr3583313fap.61.1242049237589; Mon, 11 May 2009 06:40:37 -0700 (PDT) In-Reply-To: <200905111412.26321.julien.laganier.IETF@googlemail.com> References: <20090511114328.GB15035@kafka.verkstad.net> <200905111412.26321.julien.laganier.IETF@googlemail.com> Date: Mon, 11 May 2009 14:40:37 +0100 Message-ID: From: George Tsirtsis To: Julien Laganier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Michael Eriksson , mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 11 May 2009 13:39:11 -0000 I second Julien on this. You seem to be thinking of this as some user level protocol where the user will take his mobile device and start punching in flow descriptors by hand. This is far from reality in the use cases I am looking at. Instead, Mobile IP is a low level protocol that has more to do with routing protocols than HTTP and SIP. I think there is merit in a text based classifier and as I have said before I am not opposed to such flow descriptors be optionally supported. I would consider using such a flow descriptor in some scenarios, e.g., semi-stable connectivity scenarios (i.e, multihoming, rather than full mobility), where I also happen to want high flexibility and regular user input. But this cannot be the default usecase for MIP. MIP is a mobility protocol that should allow fast handoffs changing situations using a small set of possible links/accesses and a limitted number of apps. In this case I want binary format to handle a small number of rules as efficiently as possible. George On Mon, May 11, 2009 at 1:12 PM, Julien Laganier wrote: > Hello Michael, > > On Monday 11 May 2009, Michael Eriksson wrote: >> On Thu, May 07, 2009 at 16:54:28 +0100, George Tsirtsis wrote: >> > We also need to discuss whether the granularity of the pointers >> > described in the draft provide sufficient flexibility, in which >> > case I believe that text based flow description offers little >> > further advantage. >> >> Well, a text format has a number of advantages: >> >> - It is easier to generate (think printf). > > In my view this is a blanket statement. IMHO memcpy() et al. are simpler > than printf. > >> - It is less complex (cf. your bit vector). > > Again, IMHO a blanket statement. I'd rather parse a well defined simple > binary format than text. The bit and byte vector I proposed are > straightforward and simple in my view. > >> - Static flow rules are simple, just edit them the with your favorite >> =C2=A0 text editor. > > The average user is never going to edit any flow rules, thus I do not > think that the ability to edit them with a text editor is key (My mom > doesn't know what text is -- she uses Word :-). Even if it was, one can > simply build a tool that takes binary and output text and vice versa. > >> - It is easier to debug. IETF has a history of text protocols (SMTP, >> =C2=A0 NNTP, HTTP, SIP, ...), and that is for a good reason. > > To me this looks like comparing apple and oranges. The protocols you're > citing above are all application layer protocol. We are talking here > about a network layer protocol. Do you know many network layer (or even > transport) IETF protocols that use text encoding? > >> - It is easier to extend. > > Again, IMHO a blanket statememt, and YMMV. > >> On the other hand, what advantages would you say a binary format has? >> The only one that I can think of is that it may save a few bytes in >> some cases, but I fail to see any reasonable use case where this >> would matter at all. > > See above, I disagree with you that a text format is at advantages over > a binary format. > > In my view the binary format only has advantages, it is simpler to > generate, to parse, it conforms to the way IETF builds network layer > protocols, and as you note, has a more bandwidth efficient encoding. > > --julien > From julien.laganier.ietf@googlemail.com Mon May 11 06:41: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 CC58C3A695E for ; Mon, 11 May 2009 06:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 Z-ISm5nKp2td for ; Mon, 11 May 2009 06:41:13 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 221733A6CB5 for ; Mon, 11 May 2009 06:40:53 -0700 (PDT) Received: by fxm2 with SMTP id 2so2686063fxm.37 for ; Mon, 11 May 2009 06:42:21 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=G6hNxQZwCE2djhip38bqUKX0LwoAZ3PRQ0QYEhNKnZk=; b=cL0o5JdW6UxWVNak8+tqq7kRi+hov5Y4MtyAeAfbSWVykMpsocixCB1oC0pcifjDx/ 0E6A59MDxvP4zyiwJKBgqS9HTpJ/J+QQnfwqebiO70P4MgYFs7sT/VogjR6NbpSIhGAU OnudTq88CfKRNm+kPpnyY6ov0yPgqnmaKpktY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=pQ2fbDqldK3HAclxJbfeJkD5O9WvKIwMGNX2VjRzlBRKpKudsrvp3pz1NYoOAzz+D7 IVncAXVdgAb4QFbR9h5ZWdevBPRxjzgphq3EbtVEUZlyx8R8cSE9/ozERJNCFmfWqm7T JRrbv4DvBJxAm9BDcQvinLGoJLu/PNl7LyYVA= Received: by 10.86.70.12 with SMTP id s12mr6474738fga.69.1242049341737; Mon, 11 May 2009 06:42:21 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 12sm6774514fgg.15.2009.05.11.06.42.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 06:42:18 -0700 (PDT) From: Julien Laganier To: Arnaud Ebalard Date: Mon, 11 May 2009 15:42:04 +0200 User-Agent: KMail/1.9.10 References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <200905111255.43046.julien.laganier.IETF@googlemail.com> <878wl3sxou.fsf@small.ssi.corp> In-Reply-To: <878wl3sxou.fsf@small.ssi.corp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905111542.04553.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 13:41:13 -0000 On Monday 11 May 2009, Arnaud Ebalard wrote: > Hi Julien, > > Julien Laganier writes: > > On Monday 11 May 2009, Arnaud Ebalard wrote: > >> I am not familiar with 3GPP architectures so following comment is > >> probably stupid: if the 3GPP access is bad compared to another > >> simultaneous access I have, why not just switch off the 3GPP link > >> in order not to use it and simply use the other access as a common > >> foreign network (configure a CoA, register it to the HA, ...) ? > > > > The 3GPP access may be worse than the WLAN in some aspects (e.g. > > bandwidth) but better in other aspects (e.g. latency, packet loss), > > thus it makes sense to allow to receive some traffic (say VoIP) on > > the home link (3GPP access) while diverting some other traffic (say > > bulk data transfer) on the foreign link (non-3GPP access, e.g. a > > WLAN). > > Well, that makes sense. Even if I don't like the solution in term of > complexity, I understand the motivation based on your argument and > the explanation from Christian. Thanks. > > Considering the example you give, maybe you have some comment (in the > context of MCoA) on the current inability for a MN that has a binding > with a CN to tell that CN that it should route some flows to the HoA > of the MN instead of sending those to the CoA. Without my WG chair hat: Since route optimization is in my view a central piece of the MIPv6 design, I would consider that inability as a flaw. --julien From arno@natisbad.org Mon May 11 06:58: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 9B4253A6CFC for ; Mon, 11 May 2009 06:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 0Ixb24BwF2sp for ; Mon, 11 May 2009 06:58:00 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id BCBD13A6B9B for ; Mon, 11 May 2009 06:58:00 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M3W2Q-0007tr-Ru; Mon, 11 May 2009 15:59:26 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Julien Laganier References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <200905111255.43046.julien.laganier.IETF@googlemail.com> <878wl3sxou.fsf@small.ssi.corp> <200905111542.04553.julien.laganier.IETF@googlemail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090511:mext@ietf.org::qHuxyMSOUKDBl3eD:00000JFw X-Hashcash: 1:20:090511:julien.laganier.ietf@googlemail.com::xjrbZGD/FiQePmxx:000000000000000000000000001aNq X-Hashcash: 1:20:090511:kaaspetersen@yahoo.dk::CwfWD88cCRhz2CSg:00000000000000000000000000000000000000002CVN Date: Mon, 11 May 2009 16:00:09 +0200 In-Reply-To: <200905111542.04553.julien.laganier.IETF@googlemail.com> (Julien Laganier's message of "Mon, 11 May 2009 15:42:04 +0200") Message-ID: <87prefpwnq.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 13:58:01 -0000 Hi, Julien Laganier writes: >> > The 3GPP access may be worse than the WLAN in some aspects (e.g. >> > bandwidth) but better in other aspects (e.g. latency, packet loss), >> > thus it makes sense to allow to receive some traffic (say VoIP) on >> > the home link (3GPP access) while diverting some other traffic (say >> > bulk data transfer) on the foreign link (non-3GPP access, e.g. a >> > WLAN). >> >> Well, that makes sense. Even if I don't like the solution in term of >> complexity, I understand the motivation based on your argument and >> the explanation from Christian. Thanks. >> >> Considering the example you give, maybe you have some comment (in the >> context of MCoA) on the current inability for a MN that has a binding >> with a CN to tell that CN that it should route some flows to the HoA >> of the MN instead of sending those to the CoA. > > Without my WG chair hat: Since route optimization is in my view a > central piece of the MIPv6 design, I would consider that inability as a > flaw. Thanks for that straight answer, Julien. Initially in my review, I proposed to use the specific BID #0 (reserved at the moment but I don't know precisely why) to reference the HoA. I'll have to investigate that but this may possibly provide a simple and efficient solution. Well, I thought it was worth mentioning if you had missed that specific email. Cheers, a+ From julien.laganier.ietf@googlemail.com Mon May 11 07: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 CE82128C104 for ; Mon, 11 May 2009 07:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 r9Pe8sRGa-7V for ; Mon, 11 May 2009 07:15:22 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 98AB43A6C34 for ; Mon, 11 May 2009 07:15:22 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so856400fge.18 for ; Mon, 11 May 2009 07:16:50 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=tVfmMmt0f9X/MRVD3BmoZoeSTC0fwJgZHUGEhG7rdz0=; b=Ayr93hh7F1o3S1vSyJVs9TDHI7yi9J2x87XixQbE4PWc8javCFPRNVcuhDrb3UHYdA L4jOzverVrJth4kr2WnY+AXmGkXzprnj9ISvV8Y+kC+Km2ij425pUqiSY9IC4G+F8pOq L4IW2TldpXWncbrHzKuP1Hj6VcrUb65u/amaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=t5HC2pYV7Mysm514Ptm0iThYmWurd08591DkWiQYRqsN6VXjHB+pR5U6kj6wp5sFNu TxYvA0ZZfcbVjRBt7LolvZ3fjnooUnCj1MlNb1WRR3AmAeD/33f0m1GHT4xdymqodjcT ZMiKix+UqEmF2/cluhdYBKTZRHyDwknnCVqGw= Received: by 10.86.68.1 with SMTP id q1mr6493524fga.10.1242051410769; Mon, 11 May 2009 07:16:50 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 4sm6843761fgg.13.2009.05.11.07.16.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 07:16:50 -0700 (PDT) From: Julien Laganier To: Arnaud Ebalard Date: Mon, 11 May 2009 16:16:49 +0200 User-Agent: KMail/1.9.10 References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <200905111542.04553.julien.laganier.IETF@googlemail.com> <87prefpwnq.fsf@small.ssi.corp> In-Reply-To: <87prefpwnq.fsf@small.ssi.corp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905111616.49553.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 14:15:23 -0000 On Monday 11 May 2009, Arnaud Ebalard wrote: > Hi, > > Julien Laganier writes: > >> > The 3GPP access may be worse than the WLAN in some aspects (e.g. > >> > bandwidth) but better in other aspects (e.g. latency, packet > >> > loss), thus it makes sense to allow to receive some traffic (say > >> > VoIP) on the home link (3GPP access) while diverting some other > >> > traffic (say bulk data transfer) on the foreign link (non-3GPP > >> > access, e.g. a WLAN). > >> > >> Well, that makes sense. Even if I don't like the solution in term > >> of complexity, I understand the motivation based on your argument > >> and the explanation from Christian. Thanks. > >> > >> Considering the example you give, maybe you have some comment (in > >> the context of MCoA) on the current inability for a MN that has a > >> binding with a CN to tell that CN that it should route some flows > >> to the HoA of the MN instead of sending those to the CoA. > > > > Without my WG chair hat: Since route optimization is in my view a > > central piece of the MIPv6 design, I would consider that inability > > as a flaw. > > Thanks for that straight answer, Julien. > > Initially in my review, I proposed to use the specific BID #0 > (reserved at the moment but I don't know precisely why) to reference > the HoA. I'll have to investigate that but this may possibly provide > a simple and efficient solution. It seems to me that BID #0 isn't required to support the usecase we're discussing -- Wouldn't it be sufficient that the MN use the BID 'H' flags with the CN in a fashion similar to what is done with the HA? > Well, I thought it was worth mentioning if you had missed that > specific email. I had, thanks for the pointer. --julien From arno@natisbad.org Mon May 11 07:45: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 7E73C28C150 for ; Mon, 11 May 2009 07:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 TQmrox3sfl3A for ; Mon, 11 May 2009 07:45:18 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 8D78528C148 for ; Mon, 11 May 2009 07:45:18 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M3Wm9-0008Fb-Vs; Mon, 11 May 2009 16:46:42 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Julien Laganier References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <200905111542.04553.julien.laganier.IETF@googlemail.com> <87prefpwnq.fsf@small.ssi.corp> <200905111616.49553.julien.laganier.IETF@googlemail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090511:kaaspetersen@yahoo.dk::Y04xe2cu1o/nZlCX:00000000000000000000000000000000000000000Gh0 X-Hashcash: 1:20:090511:mext@ietf.org::2Qu6/bxIRHWvd/ay:00000rg2 X-Hashcash: 1:20:090511:julien.laganier.ietf@googlemail.com::ysMmLehMKH74poWB:000000000000000000000000001VyD Date: Mon, 11 May 2009 16:47:24 +0200 In-Reply-To: <200905111616.49553.julien.laganier.IETF@googlemail.com> (Julien Laganier's message of "Mon, 11 May 2009 16:16:49 +0200") Message-ID: <87ab5jpugz.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 14:45:19 -0000 Hi, Julien Laganier writes: >> Initially in my review, I proposed to use the specific BID #0 >> (reserved at the moment but I don't know precisely why) to reference >> the HoA. I'll have to investigate that but this may possibly provide >> a simple and efficient solution. > > It seems to me that BID #0 isn't required to support the usecase we're > discussing -- Wouldn't it be sufficient that the MN use the BID 'H' > flags with the CN in a fashion similar to what is done with the HA? I think it may be possible to do it that way, yes. I would just be reluctant (again, just my opinion) to base that feature on things that may possibly not be in all implementation (content of section 5.6 and associated structures, i.e. 'H' flag). Another reason would be that -- even if I have the Home Network case in mind -- I did not limited the routing of flows to the HoA by CN only to the case where the MN is at home. Which is the case covered by section 5.6 and H flag. In the end, BID #0 or reuse of 'H' flag are both sufficient marks in the BID to tell the peer we are speaking about the HoA. Cheers, a+ From julien.laganier.ietf@googlemail.com Mon May 11 08:55: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 50EDD3A6F9A for ; Mon, 11 May 2009 08:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_00=-2.599, MANGLED_PRIOR=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 5OMpwDLXkEj5 for ; Mon, 11 May 2009 08:55:31 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id BD6433A6F8A for ; Mon, 11 May 2009 08:55:30 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so875172fge.18 for ; Mon, 11 May 2009 08:56:59 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=g7U44HJLQe/yojoa5B9maFECis211Q8SUyEA6+3I2Hs=; b=QYmQb908n9UYDNz4Jpumhbz2qMnMOvxvz8GTh+2aq8jpMjcKLQAcC43+5S1DCYQHaa iH2UF1/UiJQPM3CFo5rjdTx24qKY3XFTyuTZ1SQ7BuPCQnOfkwdXYZo4x70/pFJ5X00O 8zJKurONecap5FQZ952+E6AogNE04pUv38P98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=eZxo9JKzuGEFKZsldolWDcr9oOnea5Q8XbZ/bWg2Zm2a3APhx6KKnjvBVI98gfkFyV is6gHbGZgSy49Mf8TvXMmg5ipaTAhNieWfFA7bqUZe0ueq48o8IaCqtdEAy3lcTF+vG5 GDsaG6F9WZDjvekeDUUBsJok+D5+ArLfDfGkQ= Received: by 10.86.93.17 with SMTP id q17mr6571807fgb.75.1242057419326; Mon, 11 May 2009 08:56:59 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 4sm4688603fge.3.2009.05.11.08.56.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 08:56:58 -0700 (PDT) From: Julien Laganier To: George Tsirtsis Date: Mon, 11 May 2009 17:56:57 +0200 User-Agent: KMail/1.9.10 References: <200905081410.04985.julien.laganier.IETF@googlemail.com> <200905111140.48600.julien.laganier.IETF@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905111756.57335.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 11 May 2009 15:55:32 -0000 Hi George, On Monday 11 May 2009, George Tsirtsis wrote: > On Mon, May 11, 2009 at 10:40 AM, Julien Laganier > > wrote: > > Hi George, > > > > On Sunday 10 May 2009, George Tsirtsis wrote: > >> Julien, > >> > >> One thing to note is that there is no way you can put together a > >> classifier without knowing exactly what order the rules need to be > >> placed in the list and without understanding which ones overlap > >> and which are not. The MN MUST be able to do this, otherwise there > >> is no way to impose the desired behaviour. > > > > You can build a classifier in which rules are ordered and the > > classifier needs not to determine overlaps, which is incidentaly > > what IPsec does, see this excerpt from 4301: > > > > =C2=A0 The SPD is an ordered database, consistent with the use of > > Access =C2=A0 Control Lists (ACLs) or packet filters in firewalls, > > routers, etc. =C2=A0 The ordering requirement arises because entries > > often will overlap =C2=A0 due to the presence of (non-trivial) ranges > > as values for selectors. =C2=A0 Thus, a user or administrator MUST be > > able to order the entries to =C2=A0 express a desired access control > > policy. =C2=A0There is no way to impose a =C2=A0 general, canonical ord= er > > on SPD entries, because of the allowed use =C2=A0 of wildcards for > > selector values and because the different types of =C2=A0 selectors are > > not hierarchically related. > > > > In that sense the priority is just a way to express within the MN - > > HA signalling, and the priority needs not to be exposed to ULPs. > > GT> I am sure I lost your point because what I understand from the > text you quote exactly the same point I am making i.e., when you put > together a classifier you need to understand when rules overlap. What > do ULPs have to do with anything? (Sorry, forget the ULPs) When I read the 4301 excerpt, it says *all* rules are ordered=20 (overlapping or not), precisely to avoid issues with what to do when=20 there's an overlap. Thus there's no need for an implementation to=20 determine whether or not there's an overlap because the ordering solve=20 the issues. More below: > >> Now also consider that whether we require a unique PRI or not, the > >> MN again will have to know the above. If you require unique PRI, > >> the MN will have to decide the order of overlapping rules. If we > >> allow more than one rule to have the same PRI, the MN will have to > >> decide which rules are not overlapping and thus they can take the > >> same value. > > > > As above, overlapping is irrelevant once we require ordered rules. > > > >> So, either way, it makes no difference to the complexity of the > >> MN. > > > > I disagree. Ordered list is just simple since I do not need to > > determine overlaps b/w rules. > > GT> I think we are getting horribly confused. What I propose is that > rules are ordered.=20 So it seems we both agree that rules are ordered, but... > Overlapping rules should have different PRI to=20 > indicate the order. It is non-overlapping rules that are next to each > other that do not need different PRIs since the order does not > matter. then you're saying non-overlapping rules need not to be ordered because=20 it does not matter. So three things: 1. To me this is in contradiction with the fact that rules are ordered.=20 What you're saying is that there's a partial order only. 2. It means you need a way to determine whether rules are overlapping or=20 not, otherwise how do you enforce that different PRIs are assigned to=20 overlapping rules? Or you do not enforce it at all? I'm confused. 3. I disagree that it doesn not matter that rules have same priority=20 when rules are not overlapping because the MN and HA might end up with=20 different way of breaking the tie (as Hesham put it IIRC), thus MN and=20 HA will have different ordered list. If the MN request a specific=20 ordered ruleset, the HA should have the same ordered ruleset, not a=20 different one that you pretend is equivalent... > >> On the HA side it is also easy either way. Rules are ordered > >> according to PRI. Rules with the same PRI will be placed in a > >> random order between them, since it makes no difference. > > > > Hmmm... makes no difference with what? with another random order? > > GT> It makes no different whether all rules have different PRIs or > some have the same PRI. See above - I believe there's a difference. [...] > >> Again, I am not saying the above presents a significant advantage > >> but only that this is how all classifiers work in existing > >> implementations and thus we should not do something different > >> unless we have a really good reason, which IMO we do not. > > > > Some classifiers may work as you say, but others (including IPsec > > and some firewalls) do not, thus I disagree we would be doing > > something different by requiring a priority to be unique, i.e., > > requiring the ruleset to be ordered. As to the reason to do ordered > > ruleset, we have one: simplicity. > > GT> Julien, there is no difference at the level of simplicity that I > can see. Lets put this differently. Do you agree that for the > receiver i.e., the HA/CN whether some rules have the same PRI or not > it makes no difference? i.e., it is no simpler or complicated to > implement that HA/CN part of this? If yes, then it is up to the > implementer of the MN to decide whether he/she wants to use the same > PRI for non-overlapping rules (as the draft suggests) or if all rules > have different PRIs (as you/Christian seem to prefer). This way we > leave it flexible without hurting interoperability. I do not agree it makes no difference because 1) you need to detect=20 overlapping rules to pop-up an error when they are set-up, and 2) for=20 non-overlapping rules, the MN cannot determine in a deterministic way=20 in which way they are ordered by the HA/CN, and vice versa. This is a=20 key difference I'd need to highlight with what happens on a local=20 classifier (e.g. a firewall) w.r.t priorities, in which case there's no=20 ambiguity on the order in which rule with same priorities are=20 handled -- they are handled in the order in which they were added.=20 Quoting from ipfw(8) "Multiple rules can have the same number, in which=20 case they are checked (and listed) according to the order in which they=20 have been added." Does that help? Or are we indeed standing by antipodes? =2D-julien From hesham@elevatemobile.com Mon May 11 09:00: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 4725D3A6F55 for ; Mon, 11 May 2009 09:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 GgeRTGduVy8Z for ; Mon, 11 May 2009 09:00:04 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 45EFC3A6993 for ; Mon, 11 May 2009 09:00:03 -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 1M3XwS-0000YV-Sj; Tue, 12 May 2009 02:01:25 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 12 May 2009 02:01:21 +1000 From: Hesham Soliman To: Julien Laganier , George Tsirtsis Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnSUbnodVMpHyoEqEuKP48ujBEP3Q== In-Reply-To: <200905111756.57335.julien.laganier.IETF@googlemail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 11 May 2009 16:00:05 -0000 > I do not agree it makes no difference because 1) you need to detect > overlapping rules to pop-up an error when they are set-up, and 2) for > non-overlapping rules, the MN cannot determine in a deterministic way > in which way they are ordered by the HA/CN, and vice versa. This is a > key difference I'd need to highlight with what happens on a local > classifier (e.g. a firewall) w.r.t priorities, in which case there's no > ambiguity on the order in which rule with same priorities are > handled => You didn't answer my question about the harm done when the tie is broken differently on either side. What harm do you see? Hesham -- they are handled in the order in which they were added. > Quoting from ipfw(8) "Multiple rules can have the same number, in which > case they are checked (and listed) according to the order in which they > have been added." > > Does that help? Or are we indeed standing by antipodes? > > --julien From julien.laganier.ietf@googlemail.com Mon May 11 09:06: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 907433A67F0 for ; Mon, 11 May 2009 09:06:35 -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 0aiT+61y3fPZ for ; Mon, 11 May 2009 09:06:34 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 369CB3A6845 for ; Mon, 11 May 2009 09:06:34 -0700 (PDT) Received: by fxm2 with SMTP id 2so2782458fxm.37 for ; Mon, 11 May 2009 09:08:01 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=tuy29PQU7+VA1TEmPWf0Pia2HcqdVfbxO0MRSIPGPes=; b=sWlUvMntPb52JQbrh9xGMEV2n42xp3u53djrc9Wx7eZIUVrv5j11pkmZpAmA8bv8zl gqWEGBbS4/QVy2qNrqpd3r38yKnKcPy5kMVExjkv73C9cXf6vpE0xJGdXcG4QQen4WI9 +PmqUABH+E61GtdA8cNDJ8+89hWgsI+BHmFN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=KT3N0+6hWT1ahUFUGL3cuftQoXk4aKum1DfQq0P0I0JU7MGdxf5/JVlVJwxUzwM1JG MaowmorIinwg/PDUFl/ufZockiMWV450hd+pZkMlBZ/MuSsbiRlFVhaIW1hZ/SMHG8Kz lUv58ZrUVvLSNNr/Q87u3Xu85y3Iz9y/kaiew= Received: by 10.86.53.8 with SMTP id b8mr6592819fga.32.1242058081698; Mon, 11 May 2009 09:08:01 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 4sm7042705fgg.28.2009.05.11.09.08.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 09:08:01 -0700 (PDT) From: Julien Laganier To: Hesham Soliman Date: Mon, 11 May 2009 18:07:59 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905111807.59396.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 11 May 2009 16:06:35 -0000 On Monday 11 May 2009, Hesham Soliman wrote: > > I do not agree it makes no difference because 1) you need to detect > > overlapping rules to pop-up an error when they are set-up, and 2) > > for non-overlapping rules, the MN cannot determine in a > > deterministic way in which way they are ordered by the HA/CN, and > > vice versa. This is a key difference I'd need to highlight with > > what happens on a local classifier (e.g. a firewall) w.r.t > > priorities, in which case there's no ambiguity on the order in > > which rule with same priorities are handled > > => You didn't answer my question about the harm done when the tie is > broken differently on either side. Sorry Hesham, overlooked that. > What harm do you see? It is not deterministic and not explicit. An implementor could suppose that the order in which he breaks the tie is the logical one (e.g. first rule added prevails as often) and expect that order to be followed by its peer implementation. --julien From julien.laganier.ietf@googlemail.com Mon May 11 09: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 EE3FF3A67E1 for ; Mon, 11 May 2009 09:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 KCJ4ePqOOcYR for ; Mon, 11 May 2009 09:11:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id C3F473A6859 for ; Mon, 11 May 2009 09:11:19 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so877747fge.18 for ; Mon, 11 May 2009 09:12:47 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=5TPO0wdeTyab//7pYs7Wg4cFsorAmUC83Hphy7rtqdo=; b=r6XgitZjXG0fmGR849jXLCE8wU45BgdhVV0wArQNIRgS3crW+nLD9RbLiWsJZLkD0S ZH0AE3sICMCE/51PX/ebZDPZQNA7BMlfmOeURRi7s+ybqrD0mhAGvVSXQuctlw5DDf6R 9oVQT1gZjqxWvNAX3WNJgdSQ6zrQCpSSr/kvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=k+2/kmGaTeS3h7h0Fa/mlEeKBkuTTlEuyQYcTI7BMd17jyk2+Aj9gFXT++Yw57Ri3H J7VOxUiWR2rlBkAWvH4txZFu4cnz34XL6HbU+fv5qihvOJ5rn47uPak8/Y+wPpevkZy0 66ANRjLS09TYh2yCg+Ec7zu2+ivQI9K7ZahOY= Received: by 10.86.65.9 with SMTP id n9mr6655982fga.43.1242058367817; Mon, 11 May 2009 09:12:47 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id d6sm7088333fga.12.2009.05.11.09.12.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 09:12:47 -0700 (PDT) From: Julien Laganier To: Hesham Soliman Date: Mon, 11 May 2009 18:12:46 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905111812.46765.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 11 May 2009 16:11:21 -0000 On Monday 11 May 2009, Hesham Soliman wrote: > > I do not agree it makes no difference because 1) you need to detect > > overlapping rules to pop-up an error when they are set-up, and 2) > > for non-overlapping rules, the MN cannot determine in a > > deterministic way in which way they are ordered by the HA/CN, and > > vice versa. This is a key difference I'd need to highlight with > > what happens on a local classifier (e.g. a firewall) w.r.t > > priorities, in which case there's no ambiguity on the order in > > which rule with same priorities are handled > > => You didn't answer my question about the harm done when the tie is > broken differently on either side. What harm do you see? Silly to reply to myself, but I after more thinking I concluded there is no harm indeed. Sorry that it took me so long to get that point. So 2) above no longers hold. How about 1)... do you agree that overlapping rules requires an implementation to take all duple of rule with same priority and check whether they overlap or not? --julien From hesham@elevatemobile.com Mon May 11 09:13:47 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 37E833A696E for ; Mon, 11 May 2009 09:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 KEW45u109py4 for ; Mon, 11 May 2009 09:13:46 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 5FF1F3A680E for ; Mon, 11 May 2009 09:13:45 -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 1M3Y9o-0006kE-K8; Tue, 12 May 2009 02:15:12 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 12 May 2009 02:15:06 +1000 From: Hesham Soliman To: Julien Laganier Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnSU6WlJwayv4HNnkqyeIU+55yZzA== In-Reply-To: <200905111807.59396.julien.laganier.IETF@googlemail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 11 May 2009 16:13:47 -0000 On 12/05/09 2:07 AM, "Julien Laganier" wrote: > On Monday 11 May 2009, Hesham Soliman wrote: >>> I do not agree it makes no difference because 1) you need to detect >>> overlapping rules to pop-up an error when they are set-up, and 2) >>> for non-overlapping rules, the MN cannot determine in a >>> deterministic way in which way they are ordered by the HA/CN, and >>> vice versa. This is a key difference I'd need to highlight with >>> what happens on a local classifier (e.g. a firewall) w.r.t >>> priorities, in which case there's no ambiguity on the order in >>> which rule with same priorities are handled >> >> => You didn't answer my question about the harm done when the tie is >> broken differently on either side. > > Sorry Hesham, overlooked that. > >> What harm do you see? > > It is not deterministic and not explicit. An implementor could suppose > that the order in which he breaks the tie is the logical one (e.g. > first rule added prevails as often) and expect that order to be > followed by its peer implementation. => Yes I understand that this may well happen, but what's the consequence of that? What you describe above is not in itself harmful. Hesham > > --julien From hesham@elevatemobile.com Mon May 11 09:17: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 3A29E3A68B4 for ; Mon, 11 May 2009 09:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 GL0uizEJfJCg for ; Mon, 11 May 2009 09:17:22 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 3E2843A6BA9 for ; Mon, 11 May 2009 09:16:35 -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 1M3YCb-0006nd-Ac; Tue, 12 May 2009 02:18:05 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 12 May 2009 02:17:59 +1000 From: Hesham Soliman To: Julien Laganier Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnSVAzDkNnaV3wbI0mRFxNgiY+6yg== In-Reply-To: <200905111812.46765.julien.laganier.IETF@googlemail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 11 May 2009 16:17:23 -0000 On 12/05/09 2:12 AM, "Julien Laganier" wrote: > On Monday 11 May 2009, Hesham Soliman wrote: >>> I do not agree it makes no difference because 1) you need to detect >>> overlapping rules to pop-up an error when they are set-up, and 2) >>> for non-overlapping rules, the MN cannot determine in a >>> deterministic way in which way they are ordered by the HA/CN, and >>> vice versa. This is a key difference I'd need to highlight with >>> what happens on a local classifier (e.g. a firewall) w.r.t >>> priorities, in which case there's no ambiguity on the order in >>> which rule with same priorities are handled >> >> => You didn't answer my question about the harm done when the tie is >> broken differently on either side. What harm do you see? > > Silly to reply to myself, but I after more thinking I concluded there is > no harm indeed. Sorry that it took me so long to get that point. So 2) > above no longers hold. > > How about 1)... do you agree that overlapping rules requires an > implementation to take all duple of rule with same priority and check > whether they overlap or not? => Yes, I agree with that. However, I agree with George that you will have to do that anyway to avoid giving the wrong PRIs for overlapping rules. I mean, if there is overlap then you need to prioritise what happens to the traffic falling in that overlap. And you cant do that without determining that an overlap exists. Does that make sense? Hesham > > --julien From mer@kafka.verkstad.net Mon May 11 11:52: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 C1C683A6978 for ; Mon, 11 May 2009 11:52:55 -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 stO4kZqEyOVi for ; Mon, 11 May 2009 11:52:54 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 7064A3A682A for ; Mon, 11 May 2009 11:52:54 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 964AF710B81; Mon, 11 May 2009 20:54:24 +0200 (CEST) Date: Mon, 11 May 2009 20:54:24 +0200 From: Michael Eriksson To: Julien Laganier Message-ID: <20090511185424.GA2445@kafka.verkstad.net> References: <20090511114328.GB15035@kafka.verkstad.net> <200905111412.26321.julien.laganier.IETF@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905111412.26321.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 11 May 2009 18:52:55 -0000 On Mon, May 11, 2009 at 14:12:25 +0200, Julien Laganier wrote: > On Monday 11 May 2009, Michael Eriksson wrote: > > On Thu, May 07, 2009 at 16:54:28 +0100, George Tsirtsis wrote: > > > We also need to discuss whether the granularity of the pointers > > > described in the draft provide sufficient flexibility, in which > > > case I believe that text based flow description offers little > > > further advantage. > > > > Well, a text format has a number of advantages: > > > > - It is easier to generate (think printf). > > In my view this is a blanket statement. IMHO memcpy() et al. are simpler > than printf. I can't see how this is simpler than printf. With printf you normally just need one single statement to output a complete rule. > > - It is less complex (cf. your bit vector). > > Again, IMHO a blanket statement. I'd rather parse a well defined simple > binary format than text. The bit and byte vector I proposed are > straightforward and simple in my view. There are well established methods for parsing text with formal grammars (e.g., by using lex and yacc). Binary parsing is ad hoc, hand coded and rather error prone. If you want more arguments for why the binary format is more complex, see the ongoing discussion on how the HA should select between overlapping binary rules. For the text format, this is trivial: The rules are evaluated in strict order. > > - Static flow rules are simple, just edit them the with your favorite > > text editor. > > The average user is never going to edit any flow rules, thus I do not > think that the ability to edit them with a text editor is key (My mom > doesn't know what text is -- she uses Word :-). Even if it was, one can > simply build a tool that takes binary and output text and vice versa. OK, I don't expect your mother to edit her flow rules :-). But maybe trained experts will. In your case, you would have to start with defining the text format. And then develop and debug the tool. Doesn't that seem a bit awkward? > > - It is easier to debug. IETF has a history of text protocols (SMTP, > > NNTP, HTTP, SIP, ...), and that is for a good reason. > > To me this looks like comparing apple and oranges. The protocols you're > citing above are all application layer protocol. We are talking here > about a network layer protocol. Do you know many network layer (or even > transport) IETF protocols that use text encoding? No, exchanging flow rules is not a network layer protocol! It is a network control protocol, and is done on the "application" layer (or the control plane, as it is called in other architectures). > > - It is easier to extend. > > Again, IMHO a blanket statememt, and YMMV. No, compare the versions -00 and -01 of draft-larsson-mext-flow-distribution-rules for instance. We added support for IPv4 in -01, with very minimal changes to the language. Your binary format, on the other hand, has two completely separate formats for IPv4 and IPv6 rules. > > On the other hand, what advantages would you say a binary format has? > > The only one that I can think of is that it may save a few bytes in > > some cases, but I fail to see any reasonable use case where this > > would matter at all. > > See above, I disagree with you that a text format is at advantages over > a binary format. > > In my view the binary format only has advantages, it is simpler to > generate, to parse, it conforms to the way IETF builds network layer > protocols, and as you note, has a more bandwidth efficient encoding. I obviously disagree with most of these views (and even object to your reasoning regarding the "network layer protocol"). The binary format may at times be somewhat more compact, but I still fail to see any reasonable use cases where this would matter at all. Regards, Michael From mer@kafka.verkstad.net Mon May 11 12:43: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 72AFF3A6F8B for ; Mon, 11 May 2009 12:43:28 -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 TeHk5HYiRzNX for ; Mon, 11 May 2009 12:43:27 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 2F8153A6F72 for ; Mon, 11 May 2009 12:43:27 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id D8E4D710BCF; Mon, 11 May 2009 21:44:57 +0200 (CEST) Date: Mon, 11 May 2009 21:44:57 +0200 From: Michael Eriksson To: George Tsirtsis Message-ID: <20090511194457.GB2445@kafka.verkstad.net> References: <20090511114328.GB15035@kafka.verkstad.net> <200905111412.26321.julien.laganier.IETF@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 11 May 2009 19:43:28 -0000 On Mon, May 11, 2009 at 14:40:37 +0100, George Tsirtsis wrote: > I second Julien on this. You seem to be thinking of this as some user > level protocol where the user will take his mobile device and start > punching in flow descriptors by hand. This is far from reality in the > use cases I am looking at. > Instead, Mobile IP is a low level protocol that has more to do with > routing protocols than HTTP and SIP. No, I think that there are (mainly) two cases: - A Connection Manager determines the rules to use. This of course takes some high level "intelligence", and it can be easier for such a module to output its decisions in a high level text format (with printf) than to intermix decision making with bitfiddling. - A semi-static case, where rules are hardcoded by humans. Of course not the end users (unless they are certified nerds), but by someone who is managing the network connectivity of the device. For both these cases, a text format is more suitable. > I think there is merit in a text based classifier and as I have said > before I am not opposed to such flow descriptors be optionally > supported. I would consider using such a flow descriptor in some > scenarios, e.g., semi-stable connectivity scenarios (i.e, multihoming, > rather than full mobility), where I also happen to want high > flexibility and regular user input. It's nice that you see that the text format does have its merits. I agree that we should start with just one rule format, but shouldn't that be the most useful one? > But this cannot be the default usecase for MIP. MIP is a mobility > protocol that should allow fast handoffs changing situations using a > small set of possible links/accesses and a limitted number of apps. > In this case I want binary format to handle a small number of rules > as efficiently as possible. We are trying to define a control protocol. It is used at the "application" level (or control plane as it is called in other architectures). I think you are vastly suboptimizing when arguing that a binary format is "more efficient". Some questions: - How often do you think that these flow routing rules will be updated? - How much bandwidth is available between the rule updates? That is, how much of the available bandwidth will be used for rule updates? - How much higher (if any) do you think the cost is to encode and parse a text format compared to a binary format? What is the relation between this cost and the cost to determine (at MN) and install (at HA) these rules? If you really want to be more efficient, I think that you should focus on separating the rule updates from the binding updates. Resending/refreshing all rules, whether in binary or text format, at every handover is wasteful -- both in terms of transmitted bytes and computing effort. Regards, Michael From tsirtsis@googlemail.com Mon May 11 13:18: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 ABB2B3A6FB6 for ; Mon, 11 May 2009 13:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_63=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 8Y9KxgMo-IJp for ; Mon, 11 May 2009 13:18:12 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 0BC5D3A6FAF for ; Mon, 11 May 2009 13:18:11 -0700 (PDT) Received: by fxm2 with SMTP id 2so2933223fxm.37 for ; Mon, 11 May 2009 13:19:27 -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=6qtUTKLnDD1nNKM1yQSUaZjUlNU52g26GLjjTQlcokg=; b=k8N1lGYWcqcBJlhYHSWrIGDtCmy/hzPqUIePmysTp2RqYFpr8/D2xY2bJr4YPK+reh h17oo2BMQUS0ZLscaubQRl2y3TBZEnb0EEq+r1ft1o4l+LP3/46ijD4tgtXacVT4BkU8 kxyqsFjQSfi58tim3wNjgp9i4MqcmavhLXBaw= 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=MXbx88pQGBro5lfLbvBOWx8Gw3x+UNkSeaPTM5ZFxYKH0SD/iVNlF+GFsY9Dga9Lmc CiUb4HzpgqA1YWNev2PkaNMfVbTka0G9sQVBDiDi1GeCwniMbGPAeeZdPrQnw/HEXbHZ JX+meq/Hqe3hdHfrCX4Bc1fB/bio8rX6BmFTo= MIME-Version: 1.0 Received: by 10.223.103.207 with SMTP id l15mr4109978fao.2.1242073167116; Mon, 11 May 2009 13:19:27 -0700 (PDT) In-Reply-To: <20090511185424.GA2445@kafka.verkstad.net> References: <20090511114328.GB15035@kafka.verkstad.net> <200905111412.26321.julien.laganier.IETF@googlemail.com> <20090511185424.GA2445@kafka.verkstad.net> Date: Mon, 11 May 2009 21:19:27 +0100 Message-ID: From: George Tsirtsis To: Michael Eriksson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 11 May 2009 20:18:13 -0000 On Mon, May 11, 2009 at 7:54 PM, Michael Eriksson wrote: > On Mon, May 11, 2009 at 14:12:25 +0200, Julien Laganier wrote: >> On Monday 11 May 2009, Michael Eriksson wrote: >> > On Thu, May 07, 2009 at 16:54:28 +0100, George Tsirtsis wrote: >> > > We also need to discuss whether the granularity of the pointers >> > > described in the draft provide sufficient flexibility, in which >> > > case I believe that text based flow description offers little >> > > further advantage. >> > >> > Well, a text format has a number of advantages: >> > >> > - It is easier to generate (think printf). >> >> In my view this is a blanket statement. IMHO memcpy() et al. are simpler >> than printf. > > I can't see how this is simpler than printf. With printf you normally > just need one single statement to output a complete rule. > >> > - It is less complex (cf. your bit vector). >> >> Again, IMHO a blanket statement. I'd rather parse a well defined simple >> binary format than text. The bit and byte vector I proposed are >> straightforward and simple in my view. > > There are well established methods for parsing text with formal > grammars (e.g., by using lex and yacc). Binary parsing is ad hoc, hand > coded and rather error prone. > > If you want more arguments for why the binary format is more complex, > see the ongoing discussion on how the HA should select between > overlapping binary rules. For the text format, this is trivial: The > rules are evaluated in strict order. > GT> It is good to have a debate about this but please take some care with your arguments so we can converge one of these days. The discussion about ordering rules is independent from the binary vs text based debate. The PRI field is part of the FID option and will apply equally to binary and text filter rules which will be in sub-options. Ordering of such rules has the same issues no matter what you do to code them. e,g, if your aim is to have a rule that matches all TCP flows and another rule to match all flows from IPAddr=IPx, these rules will overlap and thus their relative order will matter, whether you code them in text or in binary. George From ryuji.wakikawa@gmail.com Mon May 11 13:59: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 607EA28C180 for ; Mon, 11 May 2009 13:59:38 -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 e-ZsDj8pj3Jc for ; Mon, 11 May 2009 13:59:37 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id ECC4C28C17F for ; Mon, 11 May 2009 13:59:36 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so1262934waf.5 for ; Mon, 11 May 2009 14:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=Z7jhD8QqWiKgqdtsK1G2DP1EKe51IZHQy4p9lWkJEdE=; b=dA+r5HEywQNMFYuaimntxhkF2Qe7tOWW1iJUrMK2rgnvRMMoSTZSsWsrCvnFsbD1GR YLdXRyd8zyf99C88QQ3Sxbur/3m4S/rlCpXoWz7oCj34oWA3zDulNJBOA+cbrbGIkO0b s5jc72UYqaI9Ohl508LtvRBi+f93Mv2cwNjfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=pNi8aBeRmRMWEW1novATTdF12TV0fFRNobT3P2+7zQyHFoD5zudY4dlWsGRL7dwwFC 7dFL/7j22MUpJf/xMdfQ1akaJPvf48ToPE0mYDMOj/J56Zc5v/e3oas8CMgp90h9GN33 wqoDHA9a9IRw4t04GMcG0PUJGiK1GKW510/Cw= Received: by 10.114.92.18 with SMTP id p18mr5536423wab.45.1242075665742; Mon, 11 May 2009 14:01:05 -0700 (PDT) Received: from ?192.168.18.112? (adsl-99-49-9-50.dsl.pltn13.sbcglobal.net [99.49.9.50]) by mx.google.com with ESMTPS id k37sm6559266waf.42.2009.05.11.13.59.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 14:01:04 -0700 (PDT) From: Ryuji Wakikawa To: Romain KUNTZ In-Reply-To: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> References: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> Message-Id: <20149D5A-EAFA-459B-A76E-5190856FD4B6@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 11 May 2009 13:59:33 -0700 X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 20:59:38 -0000 Hi Romain, On 2009/05/09, at 9:56, Romain KUNTZ wrote: > Hi, > > Some comments on draft-ietf-monami6-multiplecoa-13. > > First, I'd like to express that I support Arnaud's opinion about > section 5.6 (Simultaneous Home and Visited Link Operation). I also > don't see what is the motivation to re-route and tunnel traffic from > the HA to one of the MN's CoA, while the MN is only one hop from the > HA. Even if there is a specific use-case, at the time this topology > was suggested, a simple solution that came out was to configure a > CoA on the Home link and use a tunnel via the home link. I don't > think the little overhead of this solution justifies the complexity > of the one proposed in the draft. This was discussed at WG. We agreed to have this feature at the end. I understand the complexity, but this is how WG agreed. It is not possible to change the consensus at this moment. We passed all last call. > Another concern I have is about the use of route optimized traffic > between the MN and the HA. I've already raised this problem long > time ago and I don't think it was addressed in the draft (excuse me > if I skipped the text), so I'll try to explain it in short again: > > RFC 3775 says in section 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. > > So a MN may include an HOA dest. option in the packets destinated to > the HA instead of reverse-tunneling them. The source address of the > packet would thus be the CoA of the interface from which the packet > is sent. At the Home Agent side (still in section 9.3.1): > [...] the currently registered care-of address MUST be equal to > the source address of the packet. These tests MUST NOT be done for > packets that contain a Home Address option and a Binding Update. > > The MCoA draft does not say anything about the behavior the HA > should have in that case. As packets do not contain any information > about the BID binded to the CoA used to send the packet, the HA at > this time would have, for each packet, to check if the source > address of the packet is equal to *one of the CoA registered for the > corresponding BCE*, thus to parse the list of all the CoA registered > for the node. > > However I have some doubts about the efficiency of such tests if the > number of CoA registered of each node is great and if there is a lot > of traffic. One solution could be to use reverse tunneling rather > than HOA dest. option when the node uses MCoA and wants to send > packets (other than Mobility Headers) to its HA. > This is the case when the destination is HA. The recursive check is not for all the traffics from MNs, but for the traffic between MN and HA. We have texts in Section 6.5 > Then, when the HA replies, it must put a RTH2 in the reply instead > of reverse-tunneling the packet. How does the HA select the source > address to put in the RTH2? As the RTH2 is included once the IP > packet is forged by upper layers, the HA has no way to maintain a > state for each packet received from a node to know which address to > include in the RTH2 of the reply. Picking up one randomly may result > in a non-symmetric path between the MN and the HA. This is not MCoA stuff, but it's flow filtering matter. > For that reason I would suggest to add some text stating that > traffic from the MN to the HA (except for the mobility signaling > messages) must not be route optimized. I don't see any modification is required for this. > Two other minor comments on the draft below: > > - Section 6.2 (Processing Binding Update) > > * If the 'O' flag is set in the Binding Update, the home agent > removes all the existing bindings and registers the received > binding(s). > > It is not explicitly said that the MN can use the O flag with a CN. > I think nothing prevents the MN to use it, so we should replace > "home agent" with "receiving node". > > If all the above operations are successfully completed, a Binding > Acknowledgement containing the Binding Identifier mobility options > MUST be sent to the mobile node. > > The BAck must be sent only if the 'A' flag was set in the BU, right? > or does the MCoA spec mandates sending BAck in all cases? BA is sent only A flag is set. I will update this to > If all the above operations are successfully completed, a Binding > Acknowledgement containing the Binding Identifier mobility options > MUST be sent to the mobile node if 'A' flag is set in the > received Binding Update. Please let me know if you have further comments on this. thanks Romain, ryuji > > Cheers, > -- > Romain KUNTZ > kuntz@lsiit.u-strasbg.fr > LSIIT - Networks and Protocols Team > http://clarinet.u-strasbg.fr/~kuntz/ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Mon May 11 14:00: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 E3B693A6F84 for ; Mon, 11 May 2009 14:00:28 -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 Lx2MO96Ipkxo for ; Mon, 11 May 2009 14:00:28 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 1A0893A6F7B for ; Mon, 11 May 2009 14:00:28 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so2045209rvb.49 for ; Mon, 11 May 2009 14:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=8zT2JRnYt1QnuBl8cWCARPYNKeEM8ck0Gzgs2wKp+eo=; b=aH7fgHpjSafcsCKXGRg6B3Mb57DakJbgSamfsp0mEiAN9MHf6o+vTDP1/2KhB0igli FOVFvnnF49+GvU8oXR48ZgbaxoyDO6BEA8/PR4Pk+NhhWX9e9pS3Zzx3mEka1HRA3a1i kHbkn8JbF7oEXW+llmLIk4VZrYA2g22W2zn9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=phuOa7W9NxZ0wl30hF45sKd9AmqbowaXjJ84xcejjB4yw84txYuvJw9lTG/YvyR4Dh Wt6a1Nd1kLzVtDAuGcW5wxi0O9lYnHiymSmrYy1Z/ftgjWQKZVzi+yo4qBJkmf0VqQXm Zq4zBYX6CdFV82s68C3q2kVNFlSjMqVMqyhuw= Received: by 10.114.175.16 with SMTP id x16mr5815714wae.134.1242075717274; Mon, 11 May 2009 14:01:57 -0700 (PDT) Received: from ?192.168.18.112? (adsl-99-49-9-50.dsl.pltn13.sbcglobal.net [99.49.9.50]) by mx.google.com with ESMTPS id k37sm6559266waf.42.2009.05.11.14.01.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 14:01:56 -0700 (PDT) From: Ryuji Wakikawa To: Romain KUNTZ In-Reply-To: References: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 11 May 2009 14:01:27 -0700 X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 21:00:29 -0000 Hi Romain, On 2009/05/09, at 10:15, Romain KUNTZ wrote: > One more comment inline: > > On 2009/05/09, at 18:56, Romain KUNTZ wrote: >> So a MN may include an HOA dest. option in the packets destinated >> to the HA instead of reverse-tunneling them. The source address of >> the packet would thus be the CoA of the interface from which the >> packet is sent. At the Home Agent side (still in section 9.3.1): >> >> [...] the currently registered care-of address MUST be equal to >> the source address of the packet. These tests MUST NOT be done for >> packets that contain a Home Address option and a Binding Update. >> >> The MCoA draft does not say anything about the behavior the HA >> should have in that case. > > My mistake, actually it does say something, in section 6.5 > (Receiving Packets from Mobile Node): > > When a node receives packets with a Home Address destination option > from a mobile node, it MUST check that the care-of address that > appears in the source address field of the IPv6 header MUST be equal > to one of the care-of addresses in the binding cache entry. If no > binding is found, the packets MUST be discarded. [...] > > But my comment on the efficiency (especially at the HA side) still > holds, in addition to the other issue related to the RHT2. I have answered to this. This situation is only for the traffic between MN and HA. The same rule apply to the traffic between MN and CN. The issue of RHT2 is not MCoA matter. It is solved by flow binding. thanks ryuji > > > Cheers, > -- > Romain KUNTZ > kuntz@lsiit.u-strasbg.fr > LSIIT - Networks and Protocols Team > http://clarinet.u-strasbg.fr/~kuntz/ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Mon May 11 14:11: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 B863C3A6A8C for ; Mon, 11 May 2009 14:11:38 -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 rfrAyjM6iAW0 for ; Mon, 11 May 2009 14:11:37 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 4ECA63A68AE for ; Mon, 11 May 2009 14:10:43 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so2047383rvb.49 for ; Mon, 11 May 2009 14:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=8iTKVpSUGUM8mFDC2K1U1enAwhC5e1b9mUDXifcME+g=; b=kN1WdHaulOUOioLV0ysOmrV7E1UiZQvose0nHEa5CNU7e0jBJ/8Mmecba+ZfNqorUM vZySXGEbXHCUftULWnpEw0hRCQn5WhTKLgr0TVbIP1VAqTOct5xvVqDbTUw7p3YH+AXR bo+rKRA0fCW9Pa3fzGoR/zdVEDYvkjmhgapz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=orduHhwCMMn7w8xcn0X0Cae/kG7qW3uvYFXkvw3f8Ad4uVKVlhQ+oyMwtwvOSCTwod myuzMNheXD63bzNkCwE3dfIzsZYF8Rj630ekjp/nSwx6cT+kFrxt44ZyQHSjdGc7aa4s OKHzruZdpHZ4SbNJL43zvgimNmTKIFhzlZHL8= Received: by 10.140.201.8 with SMTP id y8mr3064760rvf.129.1242076329849; Mon, 11 May 2009 14:12:09 -0700 (PDT) Received: from ?192.168.18.112? (adsl-99-49-9-50.dsl.pltn13.sbcglobal.net [99.49.9.50]) by mx.google.com with ESMTPS id g22sm12098009rvb.16.2009.05.11.14.11.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 14:12:06 -0700 (PDT) From: Ryuji Wakikawa To: Arnaud Ebalard In-Reply-To: <87y6tcx8uz.fsf@small.ssi.corp> References: <49EF37D8.2010408@it.uc3m.es> <87y6tcx8uz.fsf@small.ssi.corp> Message-Id: <97057A64-D60B-44EE-B618-CC1C3503C8DE@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 11 May 2009 14:11:26 -0700 X-Mailer: Apple Mail (2.930.3) Cc: Jari Arkko , mext Subject: Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-monami6-multihoming-motivation-scenario-03 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, 11 May 2009 21:11:38 -0000 Hi Arnaud, Thanks for detailed comments, please fine my comments inline. On 2009/05/05, at 1:16, Arnaud Ebalard wrote: > Hi Thierry and Ryuji, > > Below is a review of draft-ietf-monami6-multihoming-motivation- > scenario-03. > In the end, these are mostly typos and a few questions / minor > changes. > > As a general comment, the document is easy to read. The numerous > high-level scenarios in section 3 provides good examples for the > needs and aspects of end-node multihoming, which are then > clarified/explained in section 4. Section 6 provides a sufficient > overview of the possible issues. > > IMMO, the doc is ready for WGLC. great! >> 1. Introduction >> >> New equipments shipped on the market now often integrate several >> access technologies (both wired and wireless). The main purpose of >> this integration is to federate all means of communications in >> order >> to access the Internet ubiquitously (from everywhere and at any >> time) >> as no single technology can be expected to be deployed everywhere. >> Flows may thus be redirected from one interface to the other >> following the loss of connectivity or change of the network >> conditions in different access mediums. Besides enabling >> ubiquitous >> Interent access, integrating several access technologies also >> allows > > s/Interent/Internet/ > >> increased bandwidth availability and selection of the the most > > s/the the/the/ > >> appropriate technology according to the type of flow or choices of >> the user, since each access medium has different cost, performance, >> bandwidth, access range, and reliability. >> >> Once multiple accesses are offered, users may want to select the >> most >> appropriate set of network interface(s) depending on the network >> environment, particularly in wireless networks which are mutable >> and >> less reliable than wired networks. Users may also want to select >> the >> most appropriate interface per communication type or to combine a >> set >> of interfaces to get sufficient bandwidth. > >> The purpose of this document is to emphasize the goals and benefits >> of multihoming for fixed and mobile hosts and routers in a generic >> fashion, i.e. without focusing on issues pertaining to hosts, or >> routers, or mobility. There are other documents focusing on these. >> issues pertaining to site multihoming in fixed networks are >> discussed >> in [1]. Mobility issues pertaining to mobile nodes and mobile > > s/Mobility issues/Multihoming issues/ ? > >> 3.3. Need to Set Up Preferences >> >> Nami works at home for a publishing company using her connection to >> the Internet via a low-speed dial up connection, a public and >> unrealiable 802.11b WLAN from the street and her 3G cellular phone. >> Since the public WLAN is not secure, and the dial-up connection too >> slow, Nami checks her company's email using her 3G phone even >> though >> it is expensive. The WLAN service is used for non-confidential >> activities, such as web-browsing and video-conferencing, and the >> dial-up connection is moslty used to transmit her completed work > > s/moslty/mostly/ > >> securely and synchronizing her file system. > > s/synchronizing/synchronize/ ? > >> 5. Analysis >> >> From the definition of a multihomed node it follows that a >> multihomed >> node has several IPv6 addresses to choose between. In order to >> expose the goals and benefits in managing multihomed nodes, we >> propose to distinguish two main cases: either the node has only one >> interface, or the node has several interfaces. In the former case, >> the node is multihomed when multilpe prefixes are advertised on the > > s/multilpe/multiple/ > >> link the node is attached to. This distinction is important and >> sometimes subtle but the implications are important. we will correct all the typos and errors here. >> >> >> 5.1. Case 1: One Interface, Multiple Prefixes >> >> The single-interfaced node is multihomed when several prefixes are >> advertised on its interface. The node must therefore configure >> several IPv6 addresses. >> >> A typical example is a node with a 802.11b interface, connected >> to an >> access point. The access point is connected trough an Ethernet >> link >> to two access routers. Each access router is configured to >> advertise >> distinct network prefixes by Router Advertisements on the link and >> can be used as default router. Several reasons may lead to >> configure >> two access routers on the same link: for instance, the access >> points >> may be shared between different ISPs, or two access routers may be >> used for redundancy or load sharing purposes. The node will then >> build two global IPv6 addresses on its interface. >> >> We now analyse which of the goals detailed in Section 4 can be met >> with this configuration. >> >> o Ubiquitous Access: NO >> >> Ubiquitous access cannot be guaranteed when the node loses >> Internet connectivity through its sole interface (e.g. the >> node is >> going outside the coverage area of its access point). >> >> o Flow redirection: YES >> >> The node might need to redirect a flow from one address to >> another >> for several reasons. For example, if one of the IPv6 prefix >> becomes unavailable, flows using the address from this prefix >> could be redirected to the address obtained on the other prefix. >> >> o Reliability: MAYBE >> >> In case of failure of one IPv6 prefix, one of the address of the >> node will not be valid anymore. Another available address built >> from other prefixes may allow the node to recover this sort of >> failure. Bi-casting can be performed to ensure the delivery of >> packets on the node. To do so, more than one IPv6 address >> must be >> used simultaneously for one flow. Bi-casting would allow the >> node >> to seamlessly change the address used on the node. >> >> o Load sharing: YES >> >> Load Sharing can be performed in the network, according to the >> address used by the node. The choice of the address used by the >> node and the router selection can be influenced by load sharing >> rules. This mostly benefits the network side: if different >> access >> routers or routes can be used to forward the node's traffic, the >> traffic load will be shared in the network. >> >> o Load balancing/Flow Distribution: NO >> >> Load balancing cannot be performed when the node has only one >> interface. > > Well, strictly speaking (considering load balancing requires different > interfaces), the NO is valid. But considering the YES for "load > sharing" > above and "Preferences" and "Aggregated Bandwidth" below, what > prevents > load balancing/flow distribution between the addresses, if for some > reason it is known that they have different characteristics, let say > for > instance that they are associated w/ different routers/internet > lines or > different kinds of addresses (native vs 6to4) ? Note that it is just a > general comment, I won't argue to change the NO to sth else.. I agree on your points. However, from the MN point of view, it is hard to detect the quality of path or the performance of default router. We can have some additional notes on this. Do you have any proposed text? > > >> 6.1. Address Selection >> >> The multihomed node has several addresses, which implies the >> appropriate address must be chosen when an IPv6 communication is >> established (e.g. when a TCP connection is opened). An address >> selection mechanism is therefore needed. >> >> The choice of the address can be influenced by many parameters: >> user >> preferences, ingress filtering, preference flag in Router >> Advertisement, destination prefix, type of interface, link >> characteristics, etc. > > would add: type of address (e.g. HoA vs common address) got it. thanks! ryuji > > > Cheers, > > a+ From ryuji.wakikawa@gmail.com Mon May 11 14:52: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 1934A3A6AFC for ; Mon, 11 May 2009 14:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83vSXDnnN1aw for ; Mon, 11 May 2009 14:52:46 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id B7D353A68C0 for ; Mon, 11 May 2009 14:52:46 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so2055946rvb.49 for ; Mon, 11 May 2009 14:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=YH/SSeS9oucH+A2NX/nszBHv71XmKYXZCP590LblOqc=; b=qUcNlGJ7C3303ly/gc7hGFK6kx+7ILMOlpV4NWVJj6BUI/ZtSSFdyJFkZRjJZf+Spy TdQ/BsYE3Pcq2QJJnCg/pbFeGiWo0q47UGl4nflCIidHXBpbk71CDwW0xt+l1JRvtg++ Dgq8o6DotBXY+C4xSYP2VtsW95Lr8yiD+Jkao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=nnqZ/EVPZk5wxFem7MwJw7gGChX7e0ws08WUqOyF3bPvUKISS+xGMPPHFkdkSiWecs DyrKypoXxxMyUcMWfXdTcciP+ph1ufFzIaTj0DSTuJ+7TE+dmkWhT2lBdUP4Za5f+Xz0 qiwbd3PCTmu8ZfevhUlep70+Pp29094RCWQJs= Received: by 10.114.184.7 with SMTP id h7mr6028332waf.151.1242078856278; Mon, 11 May 2009 14:54:16 -0700 (PDT) Received: from ?192.168.18.112? (adsl-99-49-9-50.dsl.pltn13.sbcglobal.net [99.49.9.50]) by mx.google.com with ESMTPS id j31sm6617519waf.27.2009.05.11.14.54.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 14:54:14 -0700 (PDT) From: Ryuji Wakikawa To: Arnaud Ebalard In-Reply-To: <878wl95jpk.fsf@small.ssi.corp> References: <878wl95jpk.fsf@small.ssi.corp> Message-Id: <3DEFD3B0-507E-482E-8219-9FA831008412@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 11 May 2009 14:54:11 -0700 X-Mailer: Apple Mail (2.930.3) Cc: IETF MEXT WG ML Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals 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, 11 May 2009 21:52:48 -0000 Hi Arnaud, On 2009/05/07, at 2:46, Arnaud Ebalard wrote: >> >> The mobile node may return to the home link through one of its >> interfaces. There are two options possible for the mobile node >> when >> its returns home. Section 5.6 and Section 5.5.1 describe the >> returning home procedures in more detail. >> >> 1. The mobile node uses only the interface with which it >> attaches to >> the home link. > > I think that first sentence is a bit misleading w.r.t. the content of > the paragraph. The whole idea of option 1) is just that the MN > de-registers all bindings with the HA and takes back full ownership of > its HoA. Binding with CN may remain in place. What about (just a > proposal) saying just that, i.e. use the following to describe that > setup: > > 1. The mobile node de-registers all bindings with the HA related > to > all care-of addresses it has and takes back full ownership of > its HoA on the home link. The net effect of this de- > registration > is that it no more receives any encapsulated traffic from the > Home Agent on any of its interfaces. In parallel, the mobile > node can still use the interfaces attached to foreign networks > for route-optimized communications with correspondent nodes > (from/to CoA1 and CoA2). This setup is illustrated in Figure 2. > > > This is while rewriting this paragraph that I thought it would be a > good > idea for the MN to be able to express to CN the fact that some flows > should be directly sent to the HoA. Hence, the idea of asosciating > BID 0 > to that feature. Thanks for texts. However, I would limit the number of changes in the doc at this stage. I slightly modify the text according to your points. 1. The mobile node uses only the interface with which it attaches to the home link and takes back full ownership of its HoA on the home link. This is illustrated in Figure 2. It de-registers all bindings with the home agent related to all care-of addresses. The interfaces still attached to the visited link(s) are no longer going to be receiving any encapsulated traffic from the home agent. On the other hand, the mobile node can continue communicating with the correspondent node from the other interfaces attached to foreign links by using route optimization. Even if the mobile node is attached to the home link, it can still send Binding Updates for other active care-of addresses (CoA1 and CoA2) to correspondent nodes. Since the correspondent node has bindings, packets are routed from and to each Care-of Addresses directly. >> Binding ID (BID) >> >> The BID which is assigned to the binding indicated by the care- >> of >> address in the Binding Update or the Binding Identifier mobility >> option. The BID is a 16-bit unsigned integer. The value of >> zero >> is reserved and MUST NOT be used. > > The value MUST NOT be used. 2 questions: > - maybe the rationale for that decision could be provided > - what if a peer receives a BID with that value. What behavior is > specified in that case and what will it allow if at some point that > reserved value needs to be used? This is actually SHOULD NOT. This is error when I updated the document. In section 5.1, we've had the update texts. "A mobile node assigns a BID to each care-of address when it wants to register them simultaneously with its home address. The BID MUST be unique for a given home address. The value is an integer between 1 and 65535. Zero value SHOULD NOT be used as BIDs. If a mobile node has only one care-of address, the assignment of a BID is not needed until it has multiple care-of addresses to register with, at which time all of the care-of addresses MUST be mapped to BIDs." Any future document can overwrite this spec. As for MCoA, we don't use zero value. There is background story here. The flow binding document needs default binding. We had used zero value to specify the default binding in MCoA. After the long discussion in WG, we agreed not to have this value in MCoA. The default binding should be defined in the flow binding. >> This flag is valid only for a Binding Update sent to the home >> agent. >> >> Reserved >> >> 7 bits Reserved field. The value MUST be initialized to zero by >> the sender, and SHOULD be ignored by the receiver. > > Why not a MUST for the receiver? This is error, too. It should be MUST >> If a mobile node wants to delete a particular binding(s) from its >> home agent and correspondent nodes, the mobile node sends a Binding >> Update with lifetime set to zero and includes a Binding Identifier >> mobility option(s) with the BID(s) it wants to de-register. The >> receiver will remove only the care-of address(es) that match(es) >> the >> specified BID(s). Since de-registration attempts to remove a BID >> that already exists, the care-of addresses field in each binding >> identifier option can be omitted by the sender as defined in >> Section 5.1. > > why not change the last 'can' to a MUST then? This is just optimization. It's up to MN whether saving bits or not. > >> 5.5. Returning Home: Using Single Interface > > The title of this subsection is not very explicit, is it? any proposal? > >> The mobile node may return to the home link, by attaching to the >> home >> link through one of its interfaces. When the mobile node wants to >> return home, it should be configured with information on what >> interface it needs to use. >> >> 5.5.1. Using only Interface attached to the Home Link >> >> The mobile node returns home and de-registers all the bindings as >> shown in Figure 2 and as defined in [RFC-3775]. > > Should be more explicit: "The mobile node returns home and de- > registers > all the bindings it has with the home agent as shown in Figure 2 and > as > defined in [RFC-3775]." ok, fixed. >> 5.5.2. Using only Interface attached to the Visited Link >> >> The mobile node returns home physically but shuts down the >> interface >> attached to the home link. As a result, a mobile node does not >> return home even though it attaches to the home link by one of >> interfaces. Before shutting down the interface, any binding for >> the >> care-of address previously associated with the interface should be >> deleted as defined in . > > this sentence ends badly ... right, there was typo at xml tag. >> In this scenario, despite the fact that the mobile node is >> connected >> to its home link, all of its traffic is sent and received via the >> home agent and its foreign links. > > After reading those two paragraph, this "functionality" seems weird, > to > say the least. Can someone provide any rationale? or network > architecture where it is beneficial to do that? In that case, would it > not be better to consider the MN is never at home, i.e. has no home > network instead of that trick? again, this was also discussed. Please check my slide at IETF 67 monami's WG meeting at 2006 Nov. http://www.ietf.org/proceedings/06nov/slides/monami6-0.pdf If you were there, we might beat this simultaneous things:-p At that time, I was alone to be against this. >> >> 5.6.3. Home Binding Support >> >> When the home binding is used, the mobile node MUST send a >> registering binding update with a Binding Identifier mobility >> option >> whith H flag set. The lifetime MUST be set to a non-zero >> lifetime of >> the home binding, and the care-of address MUST be set to the home >> address. > > as discussed 2 days ago on the list, it may be good to explicitly > states > the fact that this specific format of a de-registration BU in 3775 and > that the draft changes that behavior. The de-registration BU is obvious from the spec. I don't know we should have all the possible packet formats. Specially this packet is somehow clear from the texts. We did the same for binding update. The differences are same for both BUs (registering/de-registering). Thanks for the detailed comment! regards, ryuji From charles.perkins@earthlink.net Mon May 11 16:07: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 291CF3A6845 for ; Mon, 11 May 2009 16:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 MiZUvE4QIx0B for ; Mon, 11 May 2009 16:07:40 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 5E5F03A6807 for ; Mon, 11 May 2009 16:07:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=d/9iad2Rfrf3z3mNlGpcSB6zY2XBi+LpETcaHeZLcvjIXbl/2fa8ZvmIsrCF5ikH; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.122.206] (helo=[192.168.1.108]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1M3ecR-0008CY-6p for mext@ietf.org; Mon, 11 May 2009 19:09:11 -0400 Message-ID: <4A08B016.90608@earthlink.net> Date: Mon, 11 May 2009 16:09:10 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5214c4bd878734f6626fda346ede60dfa9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.122.206 Subject: [MEXT] rfc3775bis ticket #19: "Binding Update Race condition" 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, 11 May 2009 23:07:41 -0000 Hello folks, I have created a new ticket #19 for the Binding Update Race condition issue and collected together quite a bit of the pertinent discussion. Here is the URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/19 I have also updated the Internet Draft for rfc3775bis with the agreed-upon text. Regards, Charlie P. From behcetsarikaya@yahoo.com Mon May 11 16:24: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 80DE13A67DA for ; Mon, 11 May 2009 16:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, 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 5u3KgFmQRjBd for ; Mon, 11 May 2009 16:24:19 -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 7AA673A67D7 for ; Mon, 11 May 2009 16:24:19 -0700 (PDT) Received: from [68.142.230.29] by n9.bullet.re3.yahoo.com with NNFMP; 11 May 2009 23:25:48 -0000 Received: from [67.195.9.83] by t2.bullet.re2.yahoo.com with NNFMP; 11 May 2009 23:25:48 -0000 Received: from [67.195.9.108] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 11 May 2009 23:25:48 -0000 Received: from [127.0.0.1] by omp112.mail.gq1.yahoo.com with NNFMP; 11 May 2009 23:25:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 428592.19662.bm@omp112.mail.gq1.yahoo.com Received: (qmail 96459 invoked by uid 60001); 11 May 2009 23:25:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242084348; bh=G1Thce76OFxtw8BBvG0VkeTeNbIIcABMnKDI33zxCDM=; 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=QQ1E3zKkVBdxxojqlm3p8kWHvCAbaC/VAWaNjMiekUH4THVZyNVNk15pmqNRInWkFVSKl9+PxyLw+L19J8+ezACTS1ws6vZKuHB6uJyMb83NkmEF5SOvt+65taPxAFPHZppU+zw3rqUvOMDdyuVMH2hP7TjO2QoyLQQqcI0r7VQ= 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=2mIVLnD4/cWcYeqvmentSPDICYkLJLbAmizoYhv8CL/e6+Hj/xqOdxkBKQTxJVUFfYFGBf7gqszWIQf6jcE7LNLTbdFwTTpCUtGQcqlQ1raSMYzunW0yC5sWBwFxAPv1t8wnF8otPLfd0MvA9Ojo95mqxoKFrTJu7UVbszF2Muk=; Message-ID: <15697.96251.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: rpl8RvkVM1n2_UVnCowGnTBgKEViACiqSe1SM5yDXbEgC7BCK8TJnmY4nNd6NqKXBVxN4cO8SsP.Xl4WIFypZg0uOMUda3Y2c0cwVcXIPgreurrbA8vRsWS4mvp3WWub4MW7Tsff0LbxKMU_AGN6VpE4U5EMuArEgaeVpLNRAvuFSy1GbcNn4fRBdyRf08VZyMJp98T3qy9YwBYam.6vhNC.K0ycN9BcjzGdIp8nr8RImzp49eIQI1qb8d6c.Zzr0hVOu0.eMrQE5J8wmgm3r2qqe8k39._synpmEQ-- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Mon, 11 May 2009 16:25:47 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <20090511114328.GB15035@kafka.verkstad.net> <200905111412.26321.julien.laganier.IETF@googlemail.com> <20090511194457.GB2445@kafka.verkstad.net> Date: Mon, 11 May 2009 16:25:47 -0700 (PDT) From: Behcet Sarikaya To: Michael Eriksson , George Tsirtsis In-Reply-To: <20090511194457.GB2445@kafka.verkstad.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2032376065-1242084347=:96251" Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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: Mon, 11 May 2009 23:24:20 -0000 --0-2032376065-1242084347=:96251 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,=0A=0A=0AI think you are vastly suboptimizing when arguing that = a binary format=0Ais "more efficient". Some questions:=0A=0A- How often do = you think that these flow routing rules will be=0A=A0 updated?=0A=0A- How m= uch bandwidth is available between the rule updates? That is,=0A=A0 how muc= h of the available bandwidth will be used for rule updates?=0A=0A- How much= higher (if any) do you think the cost is to encode and=0A=A0 parse a text = format compared to a binary format? What is the=0A=A0 relation between this= cost and the cost to determine (at MN) and=0A=A0 install (at HA) these rul= es?=0A=0A=0AIf you really want to be more efficient, I think that you shoul= d focus=0Aon separating the rule updates from the binding updates.=0AResend= ing/refreshing all rules, whether in binary or text format, at=0Aevery hand= over is wasteful -- both in terms of transmitted bytes and=0Acomputing effo= rt.=0A=0A[behcet] I think you have draft-eriksson-mext-mipv6-routing-rules-= 00.txt in mind here. They are used to transport the routing language senten= ces used to establish the flows. Doing this for every handoff could be wast= eful, I agree but flow bindings as in draft-ietf-mext-flow-binding-02.txt= =A0need to refreshed=A0for every handoff. Even the rules for which the CoA = has changed may need to be retransported.=0A=A0=0ARegards,=0A=A0=0ABehcet= =0A=0A=0A --0-2032376065-1242084347=:96251 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,
=0A

I think you are vastly suboptimizing when arguing that a binary format=
is "more efficient". Some questions:

- How often do you think th= at these flow routing rules will be
  updated?

- How much ba= ndwidth is available between the rule updates? That is,
  how much = of the available bandwidth will be used for rule updates?

- How much= higher (if any) do you think the cost is to encode and
  parse a t= ext format compared to a binary format? What is the
  relation betw= een this cost and the cost to determine (at MN) and
  install (at H= A) these rules?


If you really want to be more efficient, I think= that you should focus
on separating the rule updates from the binding u= pdates.
Resending/refreshing all rules, whether in binary or text format= , at
every handover is wasteful -- both in terms of transmitted bytes an= d
computing effort.

[behcet] I think you have draft-eriksson-mext-mipv= 6-routing-rules-00.txt in mind here. They are used to transport the routing= language sentences used to establish the flows. Doing this for every hando= ff could be wasteful, I agree but flow bindings as in draft-ietf-mext-flow-binding-02.txt need to refreshed for every handoff. Even the rules for which the CoA has changed m= ay need to be retransported.
=0A
 
=0A
Regards,
=0A
 
=0A
Behcet

=0A=0A --0-2032376065-1242084347=:96251-- From ryuji.wakikawa@gmail.com Mon May 11 16:43: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 F29983A68E0 for ; Mon, 11 May 2009 16:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WecFFMYrCOef for ; Mon, 11 May 2009 16:43:22 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 28A853A67D7 for ; Mon, 11 May 2009 16:43:22 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so2075423rvb.49 for ; Mon, 11 May 2009 16:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=BjuqOGKhnJK8WPgtLJ+cdwzEFA+6lUAPgg6tcK3ONyk=; b=OhucMmr0dGi/DCX4jr5ztiY+1cElZWbnl3a7erqi1wOTyxP2SiOvpF8DKGHTAYb3Xc KLmc0N3aX8jU6zIUuqsKNO5DrtaqYRMquT4nh/wB7gw3Km12OD7nYKOg+YAR05KkoDoy la1o64OAnZlqzfSRs25Zln1ySrKvYZCZRhXsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=v8RwiRgksDKSOuGsbP4Qpx3Gf2vF95oMeb8RmGG2B56iaKEC9v64Qxv6KvY06hX3t0 niNSQRzFSLwpIdQ1iO3SFdezhWVeSIAf7zQpuZNmoCFTdMSz8EG+QTuwlBB6daho/ZRc c5yuu9q/B7/OdU876nR28pCMC5GfXYrPi9E2I= Received: by 10.141.45.16 with SMTP id x16mr2919262rvj.290.1242085492006; Mon, 11 May 2009 16:44:52 -0700 (PDT) Received: from ?192.168.110.115? ([206.132.173.18]) by mx.google.com with ESMTPS id f42sm12299880rvb.1.2009.05.11.16.44.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 16:44:51 -0700 (PDT) From: Ryuji Wakikawa To: Julien Laganier In-Reply-To: <200905111542.04553.julien.laganier.IETF@googlemail.com> References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <200905111255.43046.julien.laganier.IETF@googlemail.com> <878wl3sxou.fsf@small.ssi.corp> <200905111542.04553.julien.laganier.IETF@googlemail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 11 May 2009 16:44:49 -0700 X-Mailer: Apple Mail (2.930.3) Cc: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 11 May 2009 23:43:23 -0000 Hi Arnaud and Julien, On 2009/05/11, at 6:42, Julien Laganier wrote: > On Monday 11 May 2009, Arnaud Ebalard wrote: >> Hi Julien, >> >> Julien Laganier writes: >>> On Monday 11 May 2009, Arnaud Ebalard wrote: >>>> I am not familiar with 3GPP architectures so following comment is >>>> probably stupid: if the 3GPP access is bad compared to another >>>> simultaneous access I have, why not just switch off the 3GPP link >>>> in order not to use it and simply use the other access as a common >>>> foreign network (configure a CoA, register it to the HA, ...) ? >>> >>> The 3GPP access may be worse than the WLAN in some aspects (e.g. >>> bandwidth) but better in other aspects (e.g. latency, packet loss), >>> thus it makes sense to allow to receive some traffic (say VoIP) on >>> the home link (3GPP access) while diverting some other traffic (say >>> bulk data transfer) on the foreign link (non-3GPP access, e.g. a >>> WLAN). >> >> Well, that makes sense. Even if I don't like the solution in term of >> complexity, I understand the motivation based on your argument and >> the explanation from Christian. Thanks. >> >> Considering the example you give, maybe you have some comment (in the >> context of MCoA) on the current inability for a MN that has a binding >> with a CN to tell that CN that it should route some flows to the HoA >> of the MN instead of sending those to the CoA. > > Without my WG chair hat: Since route optimization is in my view a > central piece of the MIPv6 design, I would consider that inability > as a > flaw. This isn't a flow. In Mobile IPv6, when MN registers its binding to CN, MN cannot tell some flow is sent without RO. It is same here in MCoA. For the binding management, we don't offer any solution for this. This is more like flow handling matter which is out of scope in the MCoA. You can use flow binding spec to direct some of flow to bypass the RO. regards, ryuji > > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From mer@kafka.verkstad.net Mon May 11 23:13: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 A2EE73A67B7 for ; Mon, 11 May 2009 23:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 pxj6-aMfFddg for ; Mon, 11 May 2009 23:13:57 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id B59123A6986 for ; Mon, 11 May 2009 23:13:57 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 19533710A94; Tue, 12 May 2009 08:15:28 +0200 (CEST) Date: Tue, 12 May 2009 08:15:28 +0200 From: Michael Eriksson To: George Tsirtsis Message-ID: <20090512061528.GB8612@kafka.verkstad.net> References: <20090511114328.GB15035@kafka.verkstad.net> <200905111412.26321.julien.laganier.IETF@googlemail.com> <20090511185424.GA2445@kafka.verkstad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 12 May 2009 06:13:58 -0000 On Mon, May 11, 2009 at 22:19:27 +0200, George Tsirtsis wrote: > On Mon, May 11, 2009 at 7:54 PM, Michael Eriksson > > If you want more arguments for why the binary format is more complex, > > see the ongoing discussion on how the HA should select between > > overlapping binary rules. For the text format, this is trivial: The > > rules are evaluated in strict order. > > GT> It is good to have a debate about this but please take some care > with your arguments so we can converge one of these days. OK, I'll try to be careful. But I do appreciate an open and unrestricted debate with technical arguments. Previously, some objections to the old solution got quite weak counter arguments like "[...] departures from the current agreement", "in theory there is nothing preventing us from [...], except from the fact that some of us might disagree..." and "Instead of trying to reinvent the wheel, which will likely be futile, ...". With the technical arguments on the table, and a good understanding of all the alternative solutions, we can try to make the best possible choice of solution. I could live with a binary format, if that is what people really want when they understand the alternatives. > The discussion about ordering rules is independent from the binary > vs text based debate. The PRI field is part of the FID option and > will apply equally to binary and text filter rules which will be in > sub-options. No, it is not -- or at least we don't want it to be. We have already flagged that: The format in the flow-binding draft is very complex, and difficult to adapt to other rule formats than what it was originally designed for. http://www.ietf.org/mail-archive/web/mext/current/msg03054.html We could probably live with the flow-binding draft, but we want the handling of individual rules to be specific to each flow rule format, and not be specified in the flow-binding draft which should specify an OPEN transport format. > Ordering of such rules has the same issues no matter what you do to > code them. e,g, if your aim is to have a rule that matches all TCP > flows and another rule to match all flows from IPAddr=IPx, these > rules will overlap and thus their relative order will matter, > whether you code them in text or in binary. The binary rules transmitted with the flow-binding mechanism has no inherent order, unless you start to use the PRI field as some kind of line number (this gives me severe BASIC flashbacks :-)). The rules in the text format, on the other hand, are inherently strictly ordered. Regards, Michael From mer@kafka.verkstad.net Mon May 11 23:23: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 52B2F3A6405 for ; Mon, 11 May 2009 23:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 VxGGvSOTxSTE for ; Mon, 11 May 2009 23:23:18 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 356163A67B7 for ; Mon, 11 May 2009 23:23:18 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 3EFC6710A94; Tue, 12 May 2009 08:24:49 +0200 (CEST) Date: Tue, 12 May 2009 08:24:49 +0200 From: Michael Eriksson To: Hesham Soliman Message-ID: <20090512062449.GA15792@kafka.verkstad.net> References: <00c701c9cfad$7511c340$150ca40a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 12 May 2009 06:23:19 -0000 On Fri, May 08, 2009 at 19:52:02 +1000, Hesham Soliman wrote: > On 8/05/09 5:20 PM, "Yungui Wang" wrote: > > Please see solution requirement from MEXT charter... > > '' > > - 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]. > > => We're not talking about policies in this draft, we're talking about > transporting filters. We discussed this many times. Policies can associate a > flow on with a link layer, interface ...etc on a high level. Filters install > instances of such policies. It's not the same thing. Hesham, you keep repeating this, but I think that you are playing with words. I think that the use of the word "policies" in the charter is a "vocabulary slip". There has been a lot of confusion between policies, rules and similar terms. I claim that the charter was meant to say "flow routing rules" where it says "policies" above. Some observations: - One of the WG chairs says that the flow-binding and routing rules drafts are meant for the charter item above. http://www.ietf.org/mail-archive/web/mext/current/msg03032.html - The flow-binding draft has been accepted as WG document. What charter item would you say motivates this? - No other work on "policies" has been initiated, even though it is on the WG charter. > > Above information makes me believe it is possible that HA may > > initiate the flow binding. What do you assure that only MN does? > > => This is how MIPv6 works and the right way of doing things if you want > them to work in multi-access environments. It's not about what's possible, > it's about the best way of doing it. No, it is how YOU think that MIPv6 should work. Numerous people are asking for support to transfer rules from HA to MN, and it is also specified in the charter. Regards, Michael From mer@kafka.verkstad.net Mon May 11 23:28:27 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 9B6643A68B2 for ; Mon, 11 May 2009 23:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 SP9ySxwyikmq for ; Mon, 11 May 2009 23:28:26 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id B838F3A67B7 for ; Mon, 11 May 2009 23:28:26 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id C30D2710A94; Tue, 12 May 2009 08:29:57 +0200 (CEST) Date: Tue, 12 May 2009 08:29:57 +0200 From: Michael Eriksson To: Hesham Soliman Message-ID: <20090512062957.GB15792@kafka.verkstad.net> References: <200905081455.17546.julien.laganier.IETF@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: julien.laganier.ietf@googlemail.com, mext@ietf.org Subject: Re: [MEXT] round-robin action for flow binding rules 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, 12 May 2009 06:28:27 -0000 On Fri, May 08, 2009 at 23:03:44 +1000, Hesham Soliman wrote: > On 8/05/09 10:55 PM, "Julien Laganier" > wrote: > > One of my colleague has suggested the idea of adding a round-robin > > action to a rule in addition to the existing ones: > > > > [...] > > > > This could be used to load balance some type of traffics amongst two > > different links. > > > > What do you think? > > => This was actually in an older version and we removed it due to the dnager > of load balancing on a per-packet basis. I have pretty strong opnions > against this because it breaks TCP or any secure traffic where sequence > numbers are used for replay attacks. And in many cases there is not enough > information at the MIP level alone or in upper layers alone to make this > decision. Per-packet balancing can be very bad in many cases. There are > extremely limited scenarios (can't think of any) where this adds value. I > don't think we know enough to add this at this stage. Perhaps later when > work on multi-path TCP becomes a reality this action can be added in an > extension RFC. One interresting case for "per-packet" round-robin transmission is an RTP media flow (say HD TV) that doesn't fit on any of the available accesses. Regards, Michael From hesham@elevatemobile.com Mon May 11 23:33: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 2F4873A6986 for ; Mon, 11 May 2009 23:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 i5N38JLxva1l for ; Mon, 11 May 2009 23:33:41 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 2B6F53A67B7 for ; Mon, 11 May 2009 23:33:40 -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 1M3lZw-0003ja-Si; Tue, 12 May 2009 16:35:05 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 12 May 2009 16:34:57 +1000 From: Hesham Soliman To: Michael Eriksson Message-ID: Thread-Topic: [MEXT] new pad sub-option and flow identifier assignment Thread-Index: AcnSy8RHwxIAW+C/AkaNO/LQKy4v/w== In-Reply-To: <20090512062449.GA15792@kafka.verkstad.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 12 May 2009 06:33:42 -0000 On 12/05/09 4:24 PM, "Michael Eriksson" wrote: > On Fri, May 08, 2009 at 19:52:02 +1000, Hesham Soliman wrote: >> On 8/05/09 5:20 PM, "Yungui Wang" wrote: >>> Please see solution requirement from MEXT charter... >>> '' >>> - 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]. >> >> => We're not talking about policies in this draft, we're talking about >> transporting filters. We discussed this many times. Policies can associate a >> flow on with a link layer, interface ...etc on a high level. Filters install >> instances of such policies. It's not the same thing. > > Hesham, you keep repeating this, but I think that you are playing with > words. I think that the use of the word "policies" in the charter is a > "vocabulary slip". There has been a lot of confusion between policies, > rules and similar terms. I claim that the charter was meant to say > "flow routing rules" where it says "policies" above. => Please be careful with making such claims. You have zero evidence that this was the intention in the charter. What works against your interpretation is a couple of things: 1. The meaning of the word policy and how it's used 2. The fact that this charter was written based on monami6, nemo and mip6 charters and it was intended to inherit their WG docs. So, you can interpret things as you see fit but I suggest you check those facts before making strange accusations. > > Some observations: > > - One of the WG chairs says that the flow-binding and routing rules > drafts are meant for the charter item above. > > http://www.ietf.org/mail-archive/web/mext/current/msg03032.html > > - The flow-binding draft has been accepted as WG document. What > charter item would you say motivates this? => Please read the above. This was taken out of nemo and the charter was written to accommodate the exact same docs that were WG items then. > > - No other work on "policies" has been initiated, even though it is on > the WG charter. => So what? You can start that. >> >> => This is how MIPv6 works and the right way of doing things if you want >> them to work in multi-access environments. It's not about what's possible, >> it's about the best way of doing it. > > No, it is how YOU think that MIPv6 should work. => It's pretty easy to verify how it works from RFC 3775. I'm not going to debate a fact. Numerous people are > asking for support to transfer rules from HA to MN, and it is also > specified in the charter. => The charter says POLICIES not rules. I don't know why you read that as rules. Hesham > > > Regards, > Michael From hesham@elevatemobile.com Mon May 11 23:46: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 4BCCF3A6B90 for ; Mon, 11 May 2009 23:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 J8Cof+ASqB6I for ; Mon, 11 May 2009 23:46:56 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 664323A6B76 for ; Mon, 11 May 2009 23:46:55 -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 1M3lT2-0003Mh-KG; Tue, 12 May 2009 16:27:56 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 12 May 2009 16:27:48 +1000 From: Hesham Soliman To: Michael Eriksson , George Tsirtsis Message-ID: Thread-Topic: [MEXT] offline Re: binary filters draft 0 Thread-Index: AcnSysSTik4CbmFbjEOkXDHMp3bRsA== In-Reply-To: <20090512061528.GB8612@kafka.verkstad.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 12 May 2009 06:46:57 -0000 On Mon, May 11, 2009 at 22:19:27 +0200, George Tsirtsis wrote: > On Mon, May 11, 2009 at 7:54 PM, Michael Eriksson > > If you want more arguments for why the binary format is more complex, > > see the ongoing discussion on how the HA should select between > > overlapping binary rules. For the text format, this is trivial: The > > rules are evaluated in strict order. > > GT> It is good to have a debate about this but please take some care > with your arguments so we can converge one of these days. OK, I'll try to be careful. But I do appreciate an open and unrestricted debate with technical arguments. Previously, some objections to the old solution got quite weak counter arguments like "[...] departures from the current agreement", "in theory there is nothing preventing us from [...], except from the fact that some of us might disagree..." and "Instead of trying to reinvent the wheel, which will likely be futile, ...". => FWIW, that discussion was not about flow formats, it was about the flow bindings draft. We had many technical arguments on it from all points of view. Like in any project, unless new reasons comes up, we shouldn't change decisions used as fundamental assumptions. > > The binary rules transmitted with the flow-binding mechanism has no > inherent order, unless you start to use the PRI field as some kind of > line number (this gives me severe BASIC flashbacks :-)). > > The rules in the text format, on the other hand, are inherently > strictly ordered. => But the ordering discussion was about find the order for routing purposes especially for overlapping flows. It doesn't matter what format the flow is in, the ordering needs to be done based on 1) determining whether an overlap exists and 2) how the flows within such overlap get forwarded. I don't understand how line order comes into this. Regardless of the format used, this function has to be done. Hesham > > > Regards, > Michael > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From mer@kafka.verkstad.net Mon May 11 23:58: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 B411A3A6A0A for ; Mon, 11 May 2009 23:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, 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 QF+YZJmbrAtq for ; Mon, 11 May 2009 23:58:07 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id BB7DA3A6965 for ; Mon, 11 May 2009 23:58:07 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id CB8BC710A94; Tue, 12 May 2009 08:59:38 +0200 (CEST) Date: Tue, 12 May 2009 08:59:38 +0200 From: Michael Eriksson To: Hesham Soliman Message-ID: <20090512065938.GA20880@kafka.verkstad.net> References: <20090512062449.GA15792@kafka.verkstad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 12 May 2009 06:58:08 -0000 On Tue, May 12, 2009 at 16:34:57 +1000, Hesham Soliman wrote: > > Hesham, you keep repeating this, but I think that you are playing with > > words. I think that the use of the word "policies" in the charter is a > > "vocabulary slip". There has been a lot of confusion between policies, > > rules and similar terms. I claim that the charter was meant to say > > "flow routing rules" where it says "policies" above. > > => Please be careful with making such claims. You have zero evidence that > this was the intention in the charter. What works against your > interpretation is a couple of things: > 1. The meaning of the word policy and how it's used > 2. The fact that this charter was written based on monami6, nemo and mip6 > charters and it was intended to inherit their WG docs. > > So, you can interpret things as you see fit but I suggest you check those > facts before making strange accusations. I don't think that it is interesting or relevant to be an archaeologist and try to determine what was chartered in monami6 and other concluded WGs. I am focused on the current working group and its charter. > > Some observations: > > > > - One of the WG chairs says that the flow-binding and routing rules > > drafts are meant for the charter item above. > > > > http://www.ietf.org/mail-archive/web/mext/current/msg03032.html This is pretty obvious evidence of how the charter is interpreted by the WG chair. Doesn't that matter? > > - The flow-binding draft has been accepted as WG document. What > > charter item would you say motivates this? > > => Please read the above. This was taken out of nemo and the charter was > written to accommodate the exact same docs that were WG items then. Forget about NEMO, it is no longer active. The flow-binding draft was accepted as a /mext/ draft. What mext charter item would you say motivates this? > >> => This is how MIPv6 works and the right way of doing things if you want > >> them to work in multi-access environments. It's not about what's possible, > >> it's about the best way of doing it. > > > > No, it is how YOU think that MIPv6 should work. > > => It's pretty easy to verify how it works from RFC 3775. I'm not going to > debate a fact. Come on, we are trying to extend MIPv6. Pointing at the current specification is not really relevant, is it? > Numerous people are > > asking for support to transfer rules from HA to MN, and it is also > > specified in the charter. > > => The charter says POLICIES not rules. I don't know why you read that as > rules. You are playing with words, Hesham. Try to read the intended meaning instead, which is obviously what the WG chairs and most other people are doing. Regards, Michael From arno@natisbad.org Mon May 11 23:59: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 813313A6C2E for ; Mon, 11 May 2009 23:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 j1L4qukaeJfA for ; Mon, 11 May 2009 23:59:37 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 9C2CB3A6C0D for ; Mon, 11 May 2009 23:59:37 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M3lz7-0000xJ-R2; Tue, 12 May 2009 09:01:05 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Ryuji Wakikawa References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <200905111255.43046.julien.laganier.IETF@googlemail.com> <878wl3sxou.fsf@small.ssi.corp> <200905111542.04553.julien.laganier.IETF@googlemail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090512:julien.laganier.ietf@googlemail.com::EGdpmiio24VozL6C:000000000000000000000000000VFu X-Hashcash: 1:20:090512:ryuji.wakikawa@gmail.com::Inp4TEZIfZrsHWsI:000000000000000000000000000000000000034sf X-Hashcash: 1:20:090512:mext@ietf.org::uH3TU+Qhr24rgmVQ:00006DBq Date: Tue, 12 May 2009 09:01:49 +0200 In-Reply-To: (Ryuji Wakikawa's message of "Mon, 11 May 2009 16:44:49 -0700") Message-ID: <87y6t2dcte.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 12 May 2009 06:59:38 -0000 Hi Ryuji, Ryuji Wakikawa writes: >>> Considering the example you give, maybe you have some comment (in the >>> context of MCoA) on the current inability for a MN that has a binding >>> with a CN to tell that CN that it should route some flows to the HoA >>> of the MN instead of sending those to the CoA. >> >> Without my WG chair hat: Since route optimization is in my view a >> central piece of the MIPv6 design, I would consider that inability >> as a >> flaw. > > This isn't a flow. > > In Mobile IPv6, when MN registers its binding to CN, MN cannot tell > some flow is sent without RO. That's correct but MIPv6 was restricted to a single binding and route for communications bewteen MN-HA and MN-CN. Because MCoA removes that restriction, I don't see your point about citing a missing feature of MIPv6 as an argument not to have it in MCoA. IMHO, MCoA is the place where all the possible destination should be handled, including the HoA. > It is same here in MCoA. For the binding management, we don't offer > any solution for this. >From my perspective, MCoA *is* about binding management. > This is more like flow handling matter which is out of scope in the > MCoA. The thing is that at the moment the MCoA draft is the one providing information about the address to which the traffic is expected to go (via the content of the BID). If you cannot express the direction is the HoA with what is in the draft, next documents will have to modify the semantic of the BID, instead of simply use it. Or do I fail to understand how you want that to be handled? > You can use flow binding spec to direct some of flow to bypass the RO. See above. Cheers, a+ From arno@natisbad.org Tue May 12 00:19: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 C5D4B3A6C85 for ; Tue, 12 May 2009 00:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 B+yPSQ5+oFAb for ; Tue, 12 May 2009 00:19:00 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 8D7243A6CEE for ; Tue, 12 May 2009 00:19:00 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M3mHf-0001HS-2k; Tue, 12 May 2009 09:20:15 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Ryuji Wakikawa References: <49EF37D8.2010408@it.uc3m.es> <87y6tcx8uz.fsf@small.ssi.corp> <97057A64-D60B-44EE-B618-CC1C3503C8DE@gmail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090512:mext@ietf.org::wlKCoL4lQ5xxnlgD:00000Jan X-Hashcash: 1:20:090512:thierry.ernst@inria.fr::OeTUptZ8qHVAYOBU:0000000000000000000000000000000000000000W8Z X-Hashcash: 1:20:090512:ryuji.wakikawa@gmail.com::2zMd0xfBbYu0pBt6:00000000000000000000000000000000000001jKs X-Hashcash: 1:20:090512:jari.arkko@piuha.net::4UyOQQ7yq4lXS0C0:0000000000000000000000000000000000000000025A0 X-Hashcash: 1:20:090512:marcelo@it.uc3m.es::TeSOgE3Bmm2TsyPI:00000000000000000000000000000000000000000009om/ Date: Tue, 12 May 2009 09:20:57 +0200 In-Reply-To: <97057A64-D60B-44EE-B618-CC1C3503C8DE@gmail.com> (Ryuji Wakikawa's message of "Mon, 11 May 2009 14:11:26 -0700") Message-ID: <87tz3qdbxi.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jari Arkko , mext Subject: Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-monami6-multihoming-motivation-scenario-03 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, 12 May 2009 07:19:01 -0000 Hi, Ryuji Wakikawa writes: >>> o Reliability: MAYBE >>> >>> In case of failure of one IPv6 prefix, one of the address of the >>> node will not be valid anymore. Another available address built >>> from other prefixes may allow the node to recover this sort of >>> failure. Bi-casting can be performed to ensure the delivery of >>> packets on the node. To do so, more than one IPv6 address >>> must be >>> used simultaneously for one flow. Bi-casting would allow the >>> node >>> to seamlessly change the address used on the node. >>> >>> o Load sharing: YES >>> >>> Load Sharing can be performed in the network, according to the >>> address used by the node. The choice of the address used by the >>> node and the router selection can be influenced by load sharing >>> rules. This mostly benefits the network side: if different >>> access >>> routers or routes can be used to forward the node's traffic, the >>> traffic load will be shared in the network. >>> >>> o Load balancing/Flow Distribution: NO >>> >>> Load balancing cannot be performed when the node has only one >>> interface. >> >> Well, strictly speaking (considering load balancing requires different >> interfaces), the NO is valid. But considering the YES for "load >> sharing" >> above and "Preferences" and "Aggregated Bandwidth" below, what >> prevents >> load balancing/flow distribution between the addresses, if for some >> reason it is known that they have different characteristics, let say >> for >> instance that they are associated w/ different routers/internet >> lines or >> different kinds of addresses (native vs 6to4) ? Note that it is just a >> general comment, I won't argue to change the NO to sth else.. > > I agree on your points. However, from the MN point of view, it is hard > to detect the quality of path or the performance of default router. > We can have some additional notes on this. > Do you have any proposed text? Well, we could add something like the following: "Note that if the node has multiple addresses (native, 6to4, ...) configured on its interface or various access routers available on the subnet it would still be technically possible to distribute traffic between those addresses or those routers." but your argument is valid. And because the document gathers scenarios and motivations, and do not restrict things anyway, expanding it to cover all weird cases does not probably makes sense. Let's just keep things as they are. Cheers, a+ From hesham@elevatemobile.com Tue May 12 00:24: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 632FB28C0FA for ; Tue, 12 May 2009 00:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 CjU8sPSYFolD for ; Tue, 12 May 2009 00:23:59 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 6E20028C0F5 for ; Tue, 12 May 2009 00:23:58 -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 1M3mMg-00060i-DB; Tue, 12 May 2009 17:25:26 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 12 May 2009 17:25:20 +1000 From: Hesham Soliman To: Michael Eriksson Message-ID: Thread-Topic: [MEXT] new pad sub-option and flow identifier assignment Thread-Index: AcnS0s4gNEA0bKA4cUWrLrPxNrapsg== In-Reply-To: <20090512065938.GA20880@kafka.verkstad.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 12 May 2009 07:24:00 -0000 >> >> => Please be careful with making such claims. You have zero evidence that >> this was the intention in the charter. What works against your >> interpretation is a couple of things: >> 1. The meaning of the word policy and how it's used >> 2. The fact that this charter was written based on monami6, nemo and mip6 >> charters and it was intended to inherit their WG docs. >> >> So, you can interpret things as you see fit but I suggest you check those >> facts before making strange accusations. > > I don't think that it is interesting or relevant to be an > archaeologist and try to determine what was chartered in monami6 and > other concluded WGs. > > I am focused on the current working group and its charter. => You seem to want to interpret meanings as you see fit so sometimes I think it's important to understand how things ended up the way they are before drawing conclusions about other people's motives. > >>> Some observations: >>> >>> - One of the WG chairs says that the flow-binding and routing rules >>> drafts are meant for the charter item above. >>> >>> http://www.ietf.org/mail-archive/web/mext/current/msg03032.html > > This is pretty obvious evidence of how the charter is interpreted by > the WG chair. Doesn't that matter? => Did you read the message?? It says: "For this deliverable we have: draft-ietf-mext-flow-binding-01.txt defines the format part of the last sentence in the paragraph above. draft-larsson-mext-flow-distribution-rules and the other binary encoding (we don't have a draft for this yet, right?) defines the policy format of the last sentence of the charter paragraph above. We all agree? Regards, marcelo" And yes we all agreed! Yes it includes the flow descriptions in draft-larsson and the transport in draft-ietf-mext-flow-binding. What exactly are you against in this message? Or what do you think I disagree with? I'm really confused by this discussion... >>> No, it is how YOU think that MIPv6 should work. >> >> => It's pretty easy to verify how it works from RFC 3775. I'm not going to >> debate a fact. > > Come on, we are trying to extend MIPv6. Pointing at the current > specification is not really relevant, is it? => You need to understand the spec in order to extend it! Of course it's relevant. If you really understood the spec you would see that it's not possible for the HA to initiate a binding. Let alone being able to know what interfaces work on the MN. That's why I keep saying that the HA can send policies all day long to the MN, but in the end, the MN has to decide what instances it needs and install those on the HA's BC. Again, we had this discussion at least twice already in monami6. Just because the WG was merged doesn't mean the arguments should be forgotten. > >> Numerous people are >>> asking for support to transfer rules from HA to MN, and it is also >>> specified in the charter. >> >> => The charter says POLICIES not rules. I don't know why you read that as >> rules. > > You are playing with words, Hesham. Try to read the intended meaning > instead, which is obviously what the WG chairs and most other people > are doing. => FYI, I'm not going to respond to future remarks like this one. This is the second time you make this hollow comment. Hesham > > > Regards, > Michael From w52006@huawei.com Tue May 12 00:30: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 CC2753A67FD for ; Tue, 12 May 2009 00:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 ixjSoRTyx5hS for ; Tue, 12 May 2009 00:30:31 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 445E628C100 for ; Tue, 12 May 2009 00:30:31 -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 <0KJI0093USX3U4@szxga04-in.huawei.com> for mext@ietf.org; Tue, 12 May 2009 15:31:52 +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 <0KJI00I3NSX3LF@szxga04-in.huawei.com> for mext@ietf.org; Tue, 12 May 2009 15:31:51 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJI00B53SX3M9@szxml06-in.huawei.com> for mext@ietf.org; Tue, 12 May 2009 15:31:51 +0800 (CST) Date: Tue, 12 May 2009 15:31:51 +0800 From: Yungui Wang In-reply-to: <20090512065938.GA20880@kafka.verkstad.net> To: 'Michael Eriksson' , 'Hesham Soliman' Message-id: <007301c9d2d3$b776fa10$150ca40a@china.huawei.com> Organization: huawei 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: AcnSz0XtZCcXLyKoRAmVkfv+2rEw6wAAMxaQ Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 12 May 2009 07:30:32 -0000 Hello > > => The charter says POLICIES not rules. I don't know why > > you read that as rules. > > You are playing with words, Hesham. Try to read the intended meaning > instead, which is obviously what the WG chairs and most other people > are doing. > At this point, I do think so too. In my understanding, below charter text should be just effecting on flow binding, although I also agree policies are not rules. Is it a misunderstanding text? Maybe the writer can give a note here. "- 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]. " B.R. Yungui From w52006@huawei.com Tue May 12 00:38:47 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 958CC3A6965 for ; Tue, 12 May 2009 00:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.528 X-Spam-Level: X-Spam-Status: No, score=-0.528 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 ZaQtpN1+spDn for ; Tue, 12 May 2009 00:38:46 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 54E3F3A67FD for ; Tue, 12 May 2009 00:38: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 <0KJI001K6TAQ6K@szxga04-in.huawei.com> for mext@ietf.org; Tue, 12 May 2009 15:40:02 +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 <0KJI00MIFTAQZF@szxga04-in.huawei.com> for mext@ietf.org; Tue, 12 May 2009 15:40:02 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJI00530TAQ55@szxml04-in.huawei.com> for mext@ietf.org; Tue, 12 May 2009 15:40:02 +0800 (CST) Date: Tue, 12 May 2009 15:40:02 +0800 From: Yungui Wang In-reply-to: <007301c9d2d3$b776fa10$150ca40a@china.huawei.com> To: 'Michael Eriksson' , 'Hesham Soliman' Message-id: <007701c9d2d4$dc22fcf0$150ca40a@china.huawei.com> Organization: huawei 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: AcnSz0XtZCcXLyKoRAmVkfv+2rEw6wAAMxaQAAEC6FA= Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 12 May 2009 07:38:47 -0000 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Yungui Wang > Sent: Tuesday, May 12, 2009 3:32 PM > To: 'Michael Eriksson'; 'Hesham Soliman' > Cc: mext@ietf.org > Subject: Re: [MEXT] new pad sub-option and flow identifier assignment > > Hello > > > > => The charter says POLICIES not rules. I don't know why > > > you read that as rules. > > > > You are playing with words, Hesham. Try to read the intended meaning > > instead, which is obviously what the WG chairs and most other people > > are doing. > > > > At this point, I do think so too. Sorry, maybe misunderstanding. Here I just agree the last sentence. I am not agreeing that "You are playing with words, Hesham." On the contrary, I think, Hesham is very good at basis concept as said before. :) > In my understanding, below > charter text > should be just effecting on flow binding, although I also > agree policies > are not rules. Is it a misunderstanding text? Maybe the > writer can give > a note here. > "- 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]. > " > > B.R. > Yungui > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From yuri.ismailov@ericsson.com Tue May 12 00:44: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 30E7C3A69B5 for ; Tue, 12 May 2009 00:44:55 -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 DlIMxrWn1HLQ for ; Tue, 12 May 2009 00:44:54 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A761A3A6830 for ; Tue, 12 May 2009 00:44:53 -0700 (PDT) X-AuditID: c1b4fb3c-b7b7fae0000015ab-45-4a09290e91d7 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E8.B1.05547.E09290A4; Tue, 12 May 2009 09:45:18 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 May 2009 09:45:17 +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, 12 May 2009 09:45:16 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] new pad sub-option and flow identifier assignment Thread-Index: AcnS0s4gNEA0bKA4cUWrLrPxNrapsgAAmkkg References: <20090512065938.GA20880@kafka.verkstad.net> From: "Yuri Ismailov" To: "Hesham Soliman" , "Michael Eriksson" X-OriginalArrivalTime: 12 May 2009 07:45:17.0719 (UTC) FILETIME=[98065A70:01C9D2D5] X-Brightmail-Tracker: AAAAAA== Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 12 May 2009 07:44:55 -0000 Hi all, This discussion looks quite strange sinse there is a room for different interpretations of the charter. Once this is the case, should we sort out the charter so that there will be a single interpretation of what is meant by policies, rules, etc.? /yuri =20 -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Hesham Soliman Sent: Tuesday, May 12, 2009 9:25 AM To: Michael Eriksson Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment >>=20 >> =3D> Please be careful with making such claims. You have zero = evidence=20 >> that this was the intention in the charter. What works against your=20 >> interpretation is a couple of things: >> 1. The meaning of the word policy and how it's used 2. The fact that=20 >> this charter was written based on monami6, nemo and mip6 charters and >> it was intended to inherit their WG docs. >>=20 >> So, you can interpret things as you see fit but I suggest you check=20 >> those facts before making strange accusations. >=20 > I don't think that it is interesting or relevant to be an=20 > archaeologist and try to determine what was chartered in monami6 and=20 > other concluded WGs. >=20 > I am focused on the current working group and its charter. =3D> You seem to want to interpret meanings as you see fit so sometimes = I think it's important to understand how things ended up the way they are before drawing conclusions about other people's motives. >=20 >>> Some observations: >>>=20 >>> - One of the WG chairs says that the flow-binding and routing rules >>> drafts are meant for the charter item above. >>>=20 >>> http://www.ietf.org/mail-archive/web/mext/current/msg03032.html >=20 > This is pretty obvious evidence of how the charter is interpreted by=20 > the WG chair. Doesn't that matter? =3D> Did you read the message?? It says: "For this deliverable we have: draft-ietf-mext-flow-binding-01.txt defines the format part of the last sentence in the paragraph above. draft-larsson-mext-flow-distribution-rules and the other binary encoding (we don't have a draft for this yet, right?) defines the policy format of the last sentence of the charter paragraph above. We all agree? Regards, marcelo" And yes we all agreed! Yes it includes the flow descriptions in draft-larsson and the transport in draft-ietf-mext-flow-binding. What exactly are you against in this message? Or what do you think I disagree with? I'm really confused by this discussion... >>> No, it is how YOU think that MIPv6 should work. >>=20 >> =3D> It's pretty easy to verify how it works from RFC 3775. I'm not=20 >> going to debate a fact. >=20 > Come on, we are trying to extend MIPv6. Pointing at the current=20 > specification is not really relevant, is it? =3D> You need to understand the spec in order to extend it! Of course = it's relevant. If you really understood the spec you would see that it's not possible for the HA to initiate a binding. Let alone being able to know what interfaces work on the MN. That's why I keep saying that the HA can send policies all day long to the MN, but in the end, the MN has to decide what instances it needs and install those on the HA's BC. Again, we had this discussion at least twice already in monami6. Just because the WG was merged doesn't mean the arguments should be forgotten. >=20 >> Numerous people are >>> asking for support to transfer rules from HA to MN, and it is also=20 >>> specified in the charter. >>=20 >> =3D> The charter says POLICIES not rules. I don't know why you read=20 >> that as rules. >=20 > You are playing with words, Hesham. Try to read the intended meaning=20 > instead, which is obviously what the WG chairs and most other people=20 > are doing. =3D> FYI, I'm not going to respond to future remarks like this one. This is the second time you make this hollow comment. Hesham >=20 >=20 > Regards, > Michael _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From arno@natisbad.org Tue May 12 01:18: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 5B4813A6A48 for ; Tue, 12 May 2009 01:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 KRfLPUsoms4S for ; Tue, 12 May 2009 01:18:39 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id E18C13A69ED for ; Tue, 12 May 2009 01:18:38 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M3nDZ-00020f-QK; Tue, 12 May 2009 10:20:05 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Ryuji Wakikawa References: <878wl95jpk.fsf@small.ssi.corp> <3DEFD3B0-507E-482E-8219-9FA831008412@gmail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090512:thierry.ernst@inria.fr::ue9jAb8Sj1K8yki1:0000000000000000000000000000000000000000hce X-Hashcash: 1:20:090512:tsirtsis@googlemail.com::zu/g/yR3k0eszPT/:000000000000000000000000000000000000000h08 X-Hashcash: 1:20:090512:vijay@wichorus.com::G591gUADKTWwlL8Z:000000000000000000000000000000000000000000044g3 X-Hashcash: 1:20:090512:ryuji.wakikawa@gmail.com::nGW/Q3NZqTF5iL9C:00000000000000000000000000000000000005yLd X-Hashcash: 1:20:090512:mext@ietf.org::U9/5qqpNbpKpcaQD:00000iku X-Hashcash: 1:20:090512:hesham@elevatemobile.com::yceoSSF0zaoenbUo:00000000000000000000000000000000000004Izp X-Hashcash: 1:20:090512:marcelo@it.uc3m.es::yyOhUaPLW+8wj7xf:00000000000000000000000000000000000000000009D2I Date: Tue, 12 May 2009 10:20:48 +0200 In-Reply-To: <3DEFD3B0-507E-482E-8219-9FA831008412@gmail.com> (Ryuji Wakikawa's message of "Mon, 11 May 2009 14:54:11 -0700") Message-ID: <87iqk6d95r.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IETF MEXT WG ML Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals 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, 12 May 2009 08:18:40 -0000 Hi, Ryuji Wakikawa writes: > Thanks for texts. However, I would limit the number of changes in the > doc at this stage. > I slightly modify the text according to your points. > > 1. The mobile node uses only the interface with which it attaches > to the home link and takes back full ownership of its HoA on > the home link. This is illustrated in Figure 2. It > de-registers all bindings with the home agent related to all > care-of addresses. The interfaces still attached to the visited > link(s) are no longer going to be receiving any encapsulated > traffic from the home agent. On the other hand, the mobile > node can continue communicating with the correspondent node s/node/nodes/ > from the other interfaces attached to foreign links by using > route optimization. Even if the mobile node is attached to the > home link, it can still send Binding Updates for other active > care-of addresses (CoA1 and CoA2) to correspondent nodes. > Since the correspondent node has bindings, packets are routed > from and to each Care-of Addresses directly. Fine with me (would just change "node" into "nodes"). >>> Binding ID (BID) >>> >>> The BID which is assigned to the binding indicated by the >>> care- >>> of >>> address in the Binding Update or the Binding Identifier mobility >>> option. The BID is a 16-bit unsigned integer. The value of >>> zero >>> is reserved and MUST NOT be used. >> >> The value MUST NOT be used. 2 questions: >> - maybe the rationale for that decision could be provided >> - what if a peer receives a BID with that value. What behavior is >> specified in that case and what will it allow if at some point that >> reserved value needs to be used? > > This is actually SHOULD NOT. > This is error when I updated the document. Ack. > In section 5.1, we've had the update texts. > "A mobile node assigns a BID to each care-of address when it wants > to > register them simultaneously with its home address. The BID MUST be > unique for a given home address. The value is an integer between 1 > and 65535. Zero value SHOULD NOT be used as BIDs. If a mobile node > has only one care-of address, the assignment of a BID is not needed > until it has multiple care-of addresses to register with, at which > time all of the care-of addresses MUST be mapped to BIDs." > > Any future document can overwrite this spec. > As for MCoA, we don't use zero value. > > There is background story here. The flow binding document needs > default binding. > We had used zero value to specify the default binding in MCoA. > > After the long discussion in WG, we agreed not to have this value in > MCoA. > The default binding should be defined in the flow binding. Ok, thanks for the background. That's what I was looking for. >>> This flag is valid only for a Binding Update sent to the home >>> agent. >>> >>> Reserved >>> >>> 7 bits Reserved field. The value MUST be initialized to zero by >>> the sender, and SHOULD be ignored by the receiver. >> >> Why not a MUST for the receiver? > > This is error, too. It should be MUST Ack. >>> If a mobile node wants to delete a particular binding(s) from its >>> home agent and correspondent nodes, the mobile node sends a Binding >>> Update with lifetime set to zero and includes a Binding Identifier >>> mobility option(s) with the BID(s) it wants to de-register. The >>> receiver will remove only the care-of address(es) that match(es) >>> the >>> specified BID(s). Since de-registration attempts to remove a BID >>> that already exists, the care-of addresses field in each binding >>> identifier option can be omitted by the sender as defined in >>> Section 5.1. >> >> why not change the last 'can' to a MUST then? > > This is just optimization. It's up to MN whether saving bits or not. I have not checked if this is specified but what will the peer do if the address (if provided, obviously) is not the current one? If the address is not used for the deletion and can just create trouble, a MUST would just help. >>> 5.5. Returning Home: Using Single Interface >> >> The title of this subsection is not very explicit, is it? > > any proposal? - Returning Home with complete ownerhsip of the HoA or - Returning Home with full de-registration with the HA something like that, which explains what really happens. >>> In this scenario, despite the fact that the mobile node is >>> connected >>> to its home link, all of its traffic is sent and received via the >>> home agent and its foreign links. >> >> After reading those two paragraph, this "functionality" seems weird, >> to >> say the least. Can someone provide any rationale? or network >> architecture where it is beneficial to do that? In that case, would it >> not be better to consider the MN is never at home, i.e. has no home >> network instead of that trick? > > again, this was also discussed. > Please check my slide at IETF 67 monami's WG meeting at 2006 Nov. > http://www.ietf.org/proceedings/06nov/slides/monami6-0.pdf Thanks for the pointer. Interesting slides. > If you were there, we might beat this simultaneous things:-p > At that time, I was alone to be against this. Too bad, indeed. I was writing a comment about the impact of 3GPP architecture in the spec, but I just erased it. It's in fact pointless to discuss that here :-| >>> 5.6.3. Home Binding Support >>> >>> When the home binding is used, the mobile node MUST send a >>> registering binding update with a Binding Identifier mobility >>> option >>> whith H flag set. The lifetime MUST be set to a non-zero >>> lifetime of >>> the home binding, and the care-of address MUST be set to the home >>> address. >> >> as discussed 2 days ago on the list, it may be good to explicitly >> states >> the fact that this specific format of a de-registration BU in 3775 and >> that the draft changes that behavior. > > The de-registration BU is obvious from the spec. > I don't know we should have all the possible packet formats. > Specially this packet is somehow clear from the texts. > We did the same for binding update. The differences are same for both > BUs (registering/de-registering). MCoA is clear on the expected format. I just say that you reuse a packet format which in 3775 expresses just the reverse. Cheers, a+ From mer@kafka.verkstad.net Tue May 12 01:38: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 604A93A6A7E for ; Tue, 12 May 2009 01:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.027, 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 VSjWCsuqr+ac for ; Tue, 12 May 2009 01:38:51 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 60C073A6A76 for ; Tue, 12 May 2009 01:38:51 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 76459710A94; Tue, 12 May 2009 10:40:22 +0200 (CEST) Date: Tue, 12 May 2009 10:40:22 +0200 From: Michael Eriksson To: Hesham Soliman Message-ID: <20090512084022.GB20880@kafka.verkstad.net> References: <20090512065938.GA20880@kafka.verkstad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 12 May 2009 08:38:52 -0000 On Tue, May 12, 2009 at 17:25:20 +1000, Hesham Soliman wrote: > >>> - One of the WG chairs says that the flow-binding and routing rules > >>> drafts are meant for the charter item above. > >>> > >>> http://www.ietf.org/mail-archive/web/mext/current/msg03032.html > > > > This is pretty obvious evidence of how the charter is interpreted by > > the WG chair. Doesn't that matter? > > => Did you read the message?? It says: > > "For this deliverable we have: > > draft-ietf-mext-flow-binding-01.txt defines the format part of the last > sentence in the paragraph above. > > draft-larsson-mext-flow-distribution-rules and the other binary encoding (we > don't have a draft for this yet, right?) defines the policy format of the > last sentence of the charter paragraph above. > > We all agree? > > Regards, marcelo" > > And yes we all agreed! Yes it includes the flow descriptions in > draft-larsson and the transport in draft-ietf-mext-flow-binding. What > exactly are you against in this message? Or what do you think I disagree > with? I'm really confused by this discussion... How can you agree that the flow-binding draft is relevant for this charter item, while you are also saying that the draft handles RULES and the charter talks about POLICIES? You also forgot to answer this question: The flow-binding draft was accepted as a /mext/ draft. What mext charter item would you say motivates this? > > Come on, we are trying to extend MIPv6. Pointing at the current > > specification is not really relevant, is it? > > => You need to understand the spec in order to extend it! Of course it's > relevant. But where in the spec does it say that the HA can't send rules to the MN, while it is OK for the MN to send rules to the HA? > If you really understood the spec you would see that it's not > possible for the HA to initiate a binding. Let alone being able to > know what interfaces work on the MN. That's why I keep saying that > the HA can send policies all day long to the MN, but in the end, the > MN has to decide what instances it needs and install those on the > HA's BC. Again, we had this discussion at least twice already in > monami6. Just because the WG was merged doesn't mean the arguments > should be forgotten. I actually happen to think that I understand the spec, thanks for your warm consideration... It is correct that the CoA bindings are unidirectional. But the HA can of course know what interfaces are working on the MN: It only has to look in the binding cache! The MN will unregister any non-working CoA. Regards, Michael From julien.laganier.ietf@googlemail.com Tue May 12 05:32: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 038D83A694A for ; Tue, 12 May 2009 05:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 0U3+X1WL5iDe for ; Tue, 12 May 2009 05:32:10 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 6FD0F3A691B for ; Tue, 12 May 2009 05:32:10 -0700 (PDT) Received: by fxm2 with SMTP id 2so3291983fxm.37 for ; Tue, 12 May 2009 05:33:38 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=J1Z1QkXPutOwKZvsR84mFbNcObUbJAH5pJB3e0q+eEM=; b=ZwV1IdBxGpfxhG5JHaKOL6z5cbaAzvtjLmsqJ6vCARHq9ReGzEyveFNFhfBVdTWgm9 06M5io8xvl1pLEAGiPsbcdVOIswBsqEWrgo/ocNqGPe6trWq0bowvb3MfUcWPSSgHasX pqhKGCg9Y2pmzvKawz5T9R81YWpg2qlhgKSC8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=tVsbh85s7HRs2JpHi+5qBArzXIwsY0W6U8ubjnIo3YIl7s5fXj9KJGRGazbiwdjUDK wBlCCpiVm8IAeO805fu0eucmLFXQbJzjMYYEvG6B7R8/LoSzm8FDbWqjJdh1LUo65sYG 7imJc07F1rUiQxAaAUQYXY+u3TiEwwBp/HsQU= Received: by 10.204.50.195 with SMTP id a3mr8028820bkg.94.1242131618404; Tue, 12 May 2009 05:33:38 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 12sm9584776fks.7.2009.05.12.05.33.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 May 2009 05:33:37 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 12 May 2009 14:33:38 +0200 User-Agent: KMail/1.9.10 References: <878wl95jpk.fsf@small.ssi.corp> <3DEFD3B0-507E-482E-8219-9FA831008412@gmail.com> In-Reply-To: <3DEFD3B0-507E-482E-8219-9FA831008412@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905121433.38751.julien.laganier.IETF@googlemail.com> Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals 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, 12 May 2009 12:32:12 -0000 Hello Ryuji, Cutting thru quite a bit: On Monday 11 May 2009, Ryuji Wakikawa wrote: > > [...] > >> Binding ID (BID) > >> > >> The BID which is assigned to the binding indicated by the > >> care- of > >> address in the Binding Update or the Binding Identifier > >> mobility option. The BID is a 16-bit unsigned integer. The value > >> of zero > >> is reserved and MUST NOT be used. > > > > The value MUST NOT be used. 2 questions: > > - maybe the rationale for that decision could be provided > > - what if a peer receives a BID with that value. What behavior is > > specified in that case and what will it allow if at some point > > that reserved value needs to be used? > > This is actually SHOULD NOT. > This is error when I updated the document. > > In section 5.1, we've had the update texts. > "A mobile node assigns a BID to each care-of address when it > wants to > register them simultaneously with its home address. The BID MUST > be unique for a given home address. The value is an integer between > 1 and 65535. Zero value SHOULD NOT be used as BIDs. If a mobile > node has only one care-of address, the assignment of a BID is not > needed until it has multiple care-of addresses to register with, at > which time all of the care-of addresses MUST be mapped to BIDs." > > Any future document can overwrite this spec. > As for MCoA, we don't use zero value. > > There is background story here. The flow binding document needs > default binding. > We had used zero value to specify the default binding in MCoA. > > After the long discussion in WG, we agreed not to have this value in > MCoA. > The default binding should be defined in the flow binding. Sorry to jump in the discussion, but IMHO what you want to achieve would actually be better reflected with the following than by a "value zero SHOULD not be used": In 4.3. ------- Binding ID (BID) The BID which is assigned to the binding indicated by the care-of address in the Binding Update or the Binding Identifier mobility option. The BID is a 16-bit unsigned integer. The value of zero is reserved and MUST NOT be set by the sender and MUST be treated as an error by the receiver (MCOA MALFORMED). In 5.1. ------- A mobile node assigns a BID to each care-of address when it wants to register them simultaneously with its home address. For a given home address, the assigned BID MUST be a unique integer between 1 and 65535. The BID value zero MUST NOT be assigned, MUST NOT be sent in a Binding Identifier Mobility Option, and MUST be treated as an error (MCOA MALFORMED) by the receiver of a Binding Identifier Mobility Option. If a mobile node has only one care-of address, the assignment of a BID is not needed until it has multiple care-of addresses to register with, at which time all of the care-of addresses MUST be mapped to BIDstoo. What do you think? --julien From julien.laganier.ietf@googlemail.com Tue May 12 05:51: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 C9A803A69A0 for ; Tue, 12 May 2009 05:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 DyxAZUKj+YYc for ; Tue, 12 May 2009 05:51:58 -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 781013A6A16 for ; Tue, 12 May 2009 05:51:56 -0700 (PDT) Received: by bwz22 with SMTP id 22so3250362bwz.37 for ; Tue, 12 May 2009 05:53:17 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=xs73Irl5oX1l9Ftpx2xs3m32/9bZSfQydLkH1IgQly4=; b=WlHArYGjrhpt9VQTSX8Vhn2eMMOI8xBn6CAuUBE5kxtLDeSryuR01iFUXcfURQSmm0 L/G/ByxtkAHaM4KQ1YOZZ0JDZbQ/thaHLTDfg8PzL0ipTySoUdiK10nG/Klfrrzzp9w8 oqUk/TfnCsT4miYrjA8F/B5jPrcQ8kTATX4lU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=dPMuO9vVK+dqjFaU6QodAFeVqH04yf+HBMX9AZ9rLXGPQSF+PrF9nMUFmuWZkTApR3 ELQlRuacg0+8nHKY21fGaJnao+iI+ic5ZSM0X9qGiHt5VKiz03kCCdwKALz1mR9cUTX7 mWsrUdj1aJ0mvG3ScFdvBO45DjBeWsdYhGGHI= Received: by 10.204.116.69 with SMTP id l5mr8138713bkq.52.1242132797586; Tue, 12 May 2009 05:53:17 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id p17sm9592622fka.35.2009.05.12.05.53.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 May 2009 05:53:16 -0700 (PDT) From: Julien Laganier To: Hesham Soliman Date: Tue, 12 May 2009 14:53:18 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905121453.18612.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 12 May 2009 12:51:58 -0000 Hi Hesham, On Monday 11 May 2009, Hesham Soliman wrote: > On 12/05/09 2:12 AM, "Julien Laganier" > > > wrote: > > On Monday 11 May 2009, Hesham Soliman wrote: > >>> I do not agree it makes no difference because 1) you need to > >>> detect overlapping rules to pop-up an error when they are set-up, > >>> and 2) for non-overlapping rules, the MN cannot determine in a > >>> deterministic way in which way they are ordered by the HA/CN, and > >>> vice versa. This is a key difference I'd need to highlight with > >>> what happens on a local classifier (e.g. a firewall) w.r.t > >>> priorities, in which case there's no ambiguity on the order in > >>> which rule with same priorities are handled > >> > >> => You didn't answer my question about the harm done when the tie > >> is broken differently on either side. What harm do you see? > > > > Silly to reply to myself, but I after more thinking I concluded > > there is no harm indeed. Sorry that it took me so long to get that > > point. So 2) above no longers hold. > > > > How about 1)... do you agree that overlapping rules requires an > > implementation to take all duple of rule with same priority and > > check whether they overlap or not? > > => Yes, I agree with that. However, I agree with George that you will > have to do that anyway to avoid giving the wrong PRIs for overlapping > rules. I mean, if there is overlap then you need to prioritise what > happens to the traffic falling in that overlap. And you cant do that > without determining that an overlap exists. Does that make sense? It seems we're making progress. I agree that the overlap needs to be determined at some level, but I think we disagree on the level. I think the choice of a specific ordering of overlapping rules doesn't belong to the MIPv6 layer. In my view it is a policy problem and has to be sorted by a much more complex machinery than the MIPv6 stack, maybe a human being and common sense are required. The MIPv6 layer should simply have to deal with an ordered set of rules, which might overlap or not, not the problem of the MIPv6 layer since they are ordered. The situation would then be similar to that of a firewall or an IPsec SPD. The administrator has to determine an order for rules based on a given policy, then the stack simply enforces it. Am I making any sense? --julien From julien.laganier.ietf@googlemail.com Tue May 12 06:04: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 0F9F628C0F0 for ; Tue, 12 May 2009 06:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 NGz3VZhfwlmw for ; Tue, 12 May 2009 06:04:10 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id A66413A6DE0 for ; Tue, 12 May 2009 06:04:09 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so1028822fge.18 for ; Tue, 12 May 2009 06:05:38 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=M03q9LAXG1w91DkVFGZRrAfbZKOyPjIRKUGqKGPYqUI=; b=e5lZ8JDiw9+qR5+Cx4GHDoJSAKTCVQg+RDZ+76MNocI3TouACQDRyXJr3meZmbYyKu vR5VxIJjHLUHJwYjaPPjUHNyHPjzLiZqTSj6LVpDR/VtAOgqs9GNvz9qkhWils5ePAUN zAYnqklFNGL+8gaq/kQ9VV0G3sCwwaCA7O2pI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=mGD3IlKYyECJLVr/tDLfpnReHfkPxpyPWn65ynTkIsuula3DCsCvw0PHkoiBbzpPjK +O0XKbVs8m+8ss+zmpeh7XxvaNdIom9fWgt2Ar5iyFMhcC2h/VyoOg4oKLCzbIg+on+e 2OcCVIIcskOnQw+DS5LEXmHSTkSG2qplY/wJc= Received: by 10.86.59.18 with SMTP id h18mr7751868fga.71.1242133538448; Tue, 12 May 2009 06:05:38 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id e11sm940981fga.11.2009.05.12.06.05.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 May 2009 06:05:37 -0700 (PDT) From: Julien Laganier To: Michael Eriksson Date: Tue, 12 May 2009 15:05:39 +0200 User-Agent: KMail/1.9.10 References: <200905111412.26321.julien.laganier.IETF@googlemail.com> <20090511185424.GA2445@kafka.verkstad.net> In-Reply-To: <20090511185424.GA2445@kafka.verkstad.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905121505.39235.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 12 May 2009 13:04:11 -0000 Hi Michael, On Monday 11 May 2009, Michael Eriksson wrote: > On Mon, May 11, 2009 at 14:12:25 +0200, Julien Laganier wrote: > > On Monday 11 May 2009, Michael Eriksson wrote: > > > On Thu, May 07, 2009 at 16:54:28 +0100, George Tsirtsis wrote: > > > > We also need to discuss whether the granularity of the pointers > > > > described in the draft provide sufficient flexibility, in which > > > > case I believe that text based flow description offers little > > > > further advantage. > > > > > > Well, a text format has a number of advantages: > > > > > > - It is easier to generate (think printf). > > > > In my view this is a blanket statement. IMHO memcpy() et al. are > > simpler than printf. > > I can't see how this is simpler than printf. With printf you normally > just need one single statement to output a complete rule. and how many statements do you need to parse and validate? Also note that the number of statements is pretty much irrelevant since in the end what matters is that you have to move words in memory and there the printf will not do less... > > > - It is less complex (cf. your bit vector). > > > > Again, IMHO a blanket statement. I'd rather parse a well defined > > simple binary format than text. The bit and byte vector I proposed > > are straightforward and simple in my view. > > There are well established methods for parsing text with formal > grammars (e.g., by using lex and yacc). Binary parsing is ad hoc, > hand coded and rather error prone. I do no think a network layer stack implementation is the place to implement formal grammars, parse and validate regular expressions. > If you want more arguments for why the binary format is more complex, > see the ongoing discussion on how the HA should select between > overlapping binary rules. For the text format, this is trivial: The > rules are evaluated in strict order. I do not see the relevance of the rule ordering in this discussion. > > > - Static flow rules are simple, just edit them the with your > > > favorite text editor. > > > > The average user is never going to edit any flow rules, thus I do > > not think that the ability to edit them with a text editor is key > > (My mom doesn't know what text is -- she uses Word :-). Even if it > > was, one can simply build a tool that takes binary and output text > > and vice versa. > > OK, I don't expect your mother to edit her flow rules :-). But maybe > trained experts will. In your case, you would have to start with > defining the text format. And then develop and debug the tool. > Doesn't that seem a bit awkward? I don't think it is awkward, that sort of tool exist for IP routing, IPsec, firewalls, etc. and they work nicely everyday in the hand of experts. > > > - It is easier to debug. IETF has a history of text protocols > > > (SMTP, NNTP, HTTP, SIP, ...), and that is for a good reason. > > > > To me this looks like comparing apple and oranges. The protocols > > you're citing above are all application layer protocol. We are > > talking here about a network layer protocol. Do you know many > > network layer (or even transport) IETF protocols that use text > > encoding? > > No, exchanging flow rules is not a network layer protocol! It is a > network control protocol, and is done on the "application" layer (or > the control plane, as it is called in other architectures). control plane, application... what are talking about? How are these flow rules different from an IPsec Traffic Selector? Does IKE uses text to transfer Traffic Selectors on-the-wire? --julien From hesham@elevatemobile.com Tue May 12 06: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 243633A6D36 for ; Tue, 12 May 2009 06:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 uvUMq6zBkpcS for ; Tue, 12 May 2009 06:09:43 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 3663C3A6BB7 for ; Tue, 12 May 2009 06:09:42 -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 1M3rlH-0003hl-Fu; Tue, 12 May 2009 23:11:11 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 12 May 2009 23:11:07 +1000 From: Hesham Soliman To: Julien Laganier Message-ID: Thread-Topic: [MEXT] flow binding draft 2 Thread-Index: AcnTAxxNkIKsd/QYzkuRxMhwVu8AuA== In-Reply-To: <200905121453.18612.julien.laganier.IETF@googlemail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 12 May 2009 13:09:44 -0000 Hi Julien, > > It seems we're making progress. > > I agree that the overlap needs to be determined at some level, but I > think we disagree on the level. > > I think the choice of a specific ordering of overlapping rules doesn't > belong to the MIPv6 layer. In my view it is a policy problem and has to > be sorted by a much more complex machinery than the MIPv6 stack, maybe > a human being and common sense are required. => I'm not sure about a human being :) but I agree with you that it's done on a higher layer. MIPv6 doesn't know what policies are needed by the apps ...etc > > The MIPv6 layer should simply have to deal with an ordered set of rules, > which might overlap or not, not the problem of the MIPv6 layer since > they are ordered. => Agreed. > > The situation would then be similar to that of a firewall or an IPsec > SPD. The administrator has to determine an order for rules based on a > given policy, then the stack simply enforces it. > > Am I making any sense? => Yes. The question is related to how MIPv6 translates the order that it was given by others. I'm happy with the logic above, however, I always get stuck on (potentially silly?) corner cases. For instance, we were discussing mobile routers when we were updating the draft and how in some cases they can potentially send policies for a very large group of MNs. Now, it is possible that the PRI field runs out of space in those cases. It is also very likely that the rules don't overlap across different MNs. So, in a scenario like that it is worth reusing the PRI field for rules that don't overlap. We can also make it very large I suppose. In any case, I agree with your functional breakdown above and don't see a problem with making it unique except for the problem above. Do you think it's an issue? If others can think of any other scenarios please let us know. Absent that, I was going to suggest that _at least_ overlapping rules must have unique PRIs. It's a but difficult to be concrete about scenarios when we don't have an API to a policy engine to work with. Either way, I think we need to make this requirement, or context clear in the draft (I mean where the filters are created and ordered ...etc). Hesham > > --julien From julien.laganier.ietf@googlemail.com Tue May 12 06:34: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 3993E3A69A1 for ; Tue, 12 May 2009 06:34:15 -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 xPU-wYsuaSp4 for ; Tue, 12 May 2009 06:34:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id CB7203A6784 for ; Tue, 12 May 2009 06:34:14 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so1034562fge.18 for ; Tue, 12 May 2009 06:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:cc :content-disposition:from:date:mime-version:content-type :content-transfer-encoding:message-id; bh=Dxq/+to/CjQYIvy1wC3OvNgzLS34YrSxXBiEA712SHs=; b=CA5mzgjfLHUkfMWyM7ZQK+LYA3VpDb5rHUs7Pud4tJhnaIJhATjkaA9wcUkeqn3gEc hi6xmeMobZnux9Q9iKd/TkrMyu/j7OGa36FtRkA5ztPhLEuh32UpC1zHLARISfNqp+R/ eYNl0y2EJntAdGBkjcxrruMjmg3wtiI7ohkXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:cc:content-disposition:from:date:mime-version :content-type:content-transfer-encoding:message-id; b=VrKiZsUepxPjEiKIM+kMgayM2t5em3pEpHD9FrsrRJcK17CXhDDKoCG5YmjobFU3EY /CvrcqrHGacxdsaxwLW9HHUUaEexGfSae2VCf//6MpjUFvV4Tn7iDq8Jog4HcCsNMDgZ qJFGe0fM1Q01ET+oThLxb47GonYN5WMOQw9zY= Received: by 10.86.3.11 with SMTP id 11mr7653027fgc.11.1242135344097; Tue, 12 May 2009 06:35:44 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id l19sm1012197fgb.12.2009.05.12.06.35.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 May 2009 06:35:43 -0700 (PDT) To: "Ahmad Muhanna" Content-Disposition: inline From: Julien Laganier Date: Tue, 12 May 2009 15:35:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200905121535.44991.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] 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, 12 May 2009 13:34:15 -0000 Hello Ahmad, On Thursday 07 May 2009, Ahmad Muhanna wrote: > Hello Julien, > Thanks for the review. Please see comments inline. [...] > I will start working on the update and hopefully will be able to spin > a quick one soon. Sounds good, Ahmad. Looking forward to it. Thank you. --julien From wesley.m.eddy@nasa.gov Tue May 12 06:58: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 B55FD3A6E1A for ; Tue, 12 May 2009 06:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 5KqlzoX9MhnB for ; Tue, 12 May 2009 06:58:32 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id E55FD3A6DAD for ; Tue, 12 May 2009 06:58:31 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 808B4A8844; Tue, 12 May 2009 08:59:54 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n4CDxsSW001403; Tue, 12 May 2009 08:59:54 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Tue, 12 May 2009 08:59:54 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: Julien Laganier , Michael Eriksson Date: Tue, 12 May 2009 08:59:52 -0500 Thread-Topic: [MEXT] offline Re: binary filters draft 0 Thread-Index: AcnTAmPlWFv0A0HxRY2injxajmNPlgABnaOw Message-ID: References: <200905111412.26321.julien.laganier.IETF@googlemail.com> <20090511185424.GA2445@kafka.verkstad.net> <200905121505.39235.julien.laganier.IETF@googlemail.com> In-Reply-To: <200905121505.39235.julien.laganier.IETF@googlemail.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-05-12_08:2009-04-28, 2009-05-12, 2009-05-12 signatures=0 Cc: "mext@ietf.org" Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 12 May 2009 13:58:32 -0000 >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >Julien Laganier >Sent: Tuesday, May 12, 2009 9:06 AM > > ... > >How are these flow rules different from an IPsec Traffic Selector? Does >IKE uses text to transfer Traffic Selectors on-the-wire? I'm in agreement with Julien's position that we deal with binary formats on the wire and text in the UI just fine in many routing protocol and security configurations, and that the advantages of a binary format are stronger than those of text. The question about how flow rules differ from the IPsec TS is one that occurred to me immediately when this discussion first began, and I can see little/no difference myself, so this further motivates binary to me, as it is more consistent with the other current practice near this layer. Though perhaps being IKE-like isn't a good general goal ... :). --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From kuntz@lsiit.u-strasbg.fr Tue May 12 14:08: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 8DDF43A69EE for ; Tue, 12 May 2009 14:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.248, 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 myjl9qPAcOhf for ; Tue, 12 May 2009 14:08:19 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.157]) by core3.amsl.com (Postfix) with ESMTP id 71A1E3A67A3 for ; Tue, 12 May 2009 14:08:19 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n4CL8WRH005817 ; Tue, 12 May 2009 23:08:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 014BFBEAFA4; Tue, 12 May 2009 23:08:32 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaQj8g9ersxG; Tue, 12 May 2009 23:08:31 +0200 (CEST) Received: from [192.168.0.10] (bro67-5-88-177-196-175.fbx.proxad.net [88.177.196.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kuntz) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 5200CBEAF95; Tue, 12 May 2009 23:08:31 +0200 (CEST) Message-Id: From: Romain KUNTZ To: Ryuji Wakikawa In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 12 May 2009 23:08:28 +0200 References: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [130.79.200.157]); Tue, 12 May 2009 23:08:32 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9355/Tue May 12 19:42:46 2009 on mr7.u-strasbg.fr X-Virus-Status: Clean Cc: mext Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 12 May 2009 21:08:20 -0000 Hi Ryuji, On 2009/05/11, at 23:01, Ryuji Wakikawa wrote: >> My mistake, actually it does say something, in section 6.5 >> (Receiving Packets from Mobile Node): >> >> When a node receives packets with a Home Address destination option >> from a mobile node, it MUST check that the care-of address that >> appears in the source address field of the IPv6 header MUST be equal >> to one of the care-of addresses in the binding cache entry. If no >> binding is found, the packets MUST be discarded. [...] >> >> But my comment on the efficiency (especially at the HA side) still >> holds, in addition to the other issue related to the RHT2. > > I have answered to this. > > This situation is only for the traffic between MN and HA. The same > rule apply to the traffic between MN and CN. Right, and I was especially concerned about the HA because it may have more MN to handle than a CN. I thought it could be a problem if there are lots of MNs-HA communications (but on the other hand, I can't think of an use-case where MN-HA communications would be frequent). If you think it would not cause possible performance issues, I'll trust you on that. > The issue of RHT2 is not MCoA matter. It is solved by flow binding. Well, yes it could be solved by flow binding. I had in mind a case where only MCoA would be used. But I was already told here that everything related to flow distribution should be handled by some flow filtering mechanism, and not MCoA itself only, so I'll stop arguing on that. Cheers, romain From kuntz@lsiit.u-strasbg.fr Tue May 12 14:08: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 7A7C128C189 for ; Tue, 12 May 2009 14:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 voRB6MFpzVT3 for ; Tue, 12 May 2009 14:08:21 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.156]) by core3.amsl.com (Postfix) with ESMTP id 5B0B73A67A3 for ; Tue, 12 May 2009 14:08:21 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n4CL8ZcH044762 ; Tue, 12 May 2009 23:08:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id F01F1BEAFB6; Tue, 12 May 2009 23:08:35 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq5uO9qubniG; Tue, 12 May 2009 23:08:35 +0200 (CEST) Received: from [192.168.0.10] (bro67-5-88-177-196-175.fbx.proxad.net [88.177.196.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kuntz) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 4D4FDBEAFA7; Tue, 12 May 2009 23:08:35 +0200 (CEST) Message-Id: From: Romain KUNTZ To: Ryuji Wakikawa In-Reply-To: <20149D5A-EAFA-459B-A76E-5190856FD4B6@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 12 May 2009 23:08:35 +0200 References: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> <20149D5A-EAFA-459B-A76E-5190856FD4B6@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [130.79.200.156]); Tue, 12 May 2009 23:08:36 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9355/Tue May 12 19:42:46 2009 on mr6.u-strasbg.fr X-Virus-Status: Clean Cc: mext Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 12 May 2009 21:08:22 -0000 Hi Ryuji, On 2009/05/11, at 22:59, Ryuji Wakikawa wrote: >> First, I'd like to express that I support Arnaud's opinion about >> section 5.6 (Simultaneous Home and Visited Link Operation). I also >> don't see what is the motivation to re-route and tunnel traffic >> from the HA to one of the MN's CoA, while the MN is only one hop >> from the HA. Even if there is a specific use-case, at the time this >> topology was suggested, a simple solution that came out was to >> configure a CoA on the Home link and use a tunnel via the home >> link. I don't think the little overhead of this solution justifies >> the complexity of the one proposed in the draft. > > This was discussed at WG. We agreed to have this feature at the end. > I understand the complexity, but this is how WG agreed. > > It is not possible to change the consensus at this moment. We passed > all last call. Ok, this has also been extensively discussed in another thread - I'll follow the WG agreement then. >> Two other minor comments on the draft below: >> >> - Section 6.2 (Processing Binding Update) >> >> * If the 'O' flag is set in the Binding Update, the home agent >> removes all the existing bindings and registers the received >> binding(s). >> >> It is not explicitly said that the MN can use the O flag with a CN. >> I think nothing prevents the MN to use it, so we should replace >> "home agent" with "receiving node". You didn't ack the above comment, did you skip it by mistake? >> If all the above operations are successfully completed, a Binding >> Acknowledgement containing the Binding Identifier mobility options >> MUST be sent to the mobile node. >> >> The BAck must be sent only if the 'A' flag was set in the BU, >> right? or does the MCoA spec mandates sending BAck in all cases? > > BA is sent only A flag is set. > I will update this to > >> If all the above operations are successfully completed, a Binding >> Acknowledgement containing the Binding Identifier mobility options >> MUST be sent to the mobile node if 'A' flag is set in the >> received Binding Update. > > Please let me know if you have further comments on this. Looks fine with me! Thanks, romain From mer@kafka.verkstad.net Wed May 13 02:32: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 0082C3A6EA1 for ; Wed, 13 May 2009 02:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 P9gIaV3L8rYw for ; Wed, 13 May 2009 02:31:20 -0700 (PDT) Received: from kafka.verkstad.net (kafka.verkstad.net [192.71.20.153]) by core3.amsl.com (Postfix) with ESMTP id AFF9B3A6F85 for ; Wed, 13 May 2009 02:30:57 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 0CCC8710B81; Wed, 13 May 2009 11:31:56 +0200 (CEST) Date: Wed, 13 May 2009 11:31:56 +0200 From: Michael Eriksson To: Julien Laganier Message-ID: <20090513093156.GA3476@kafka.verkstad.net> References: <200905111412.26321.julien.laganier.IETF@googlemail.com> <20090511185424.GA2445@kafka.verkstad.net> <200905121505.39235.julien.laganier.IETF@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905121505.39235.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 09:32:16 -0000 On Tue, May 12, 2009 at 15:05:39 +0200, Julien Laganier wrote: > On Monday 11 May 2009, Michael Eriksson wrote: > > I can't see how this is simpler than printf. With printf you normally > > just need one single statement to output a complete rule. > > and how many statements do you need to parse and validate? Also note > that the number of statements is pretty much irrelevant since in the > end what matters is that you have to move words in memory and there the > printf will not do less... OK, counting the number of statements isn't the best argument :-). With "simple" I don't mean "more efficient", I mean that it is better (easier) when developing, debugging and maintaining the system. Saving a few CPU cycles or bytes just isn't relevant anymore, at least not for control functions. In my view, dynamic flow rules will not be generated by the "MIP stack" itself. They will be determined by a higher level function, e.g, a connection manager. The connection manager shouldn't even have to care about what mobility solution is used (MIPv6, shim6, MOBIKE, ...). One of the ideas and explicit goals with our text-based rule language is that it is mobility mechanism agnostic. The connection manager will do reasoning at an abstract level. For that, text output is better. Having it output a MIP-specific binary format is not very elegant. Some observations: - The Android phone does all its network control logic in Java, which I think is a very reasonable design. An Android connection manager would thus be written in Java, and text output is suitable. - For a research project, we did a connection manager in Python, which is a rather high level language. The connection manager did reasoning about what access to use for each flow at an abstract and powerful level, and then easily presented the result in the text-based flow rules language that we are suggesting. > > > > - It is less complex (cf. your bit vector). > > > > > > Again, IMHO a blanket statement. I'd rather parse a well defined > > > simple binary format than text. The bit and byte vector I proposed > > > are straightforward and simple in my view. > > > > There are well established methods for parsing text with formal > > grammars (e.g., by using lex and yacc). Binary parsing is ad hoc, > > hand coded and rather error prone. > > I do no think a network layer stack implementation is the place to > implement formal grammars, parse and validate regular expressions. Why not? Because it is not "efficient" enough? Please note that most (all?) MIP signaling implementations are user space programs, and are not involved in packet forwarding. Also, see my comment above regarding that the rules will not be generated by the "MIP stack" itself. > > If you want more arguments for why the binary format is more complex, > > see the ongoing discussion on how the HA should select between > > overlapping binary rules. For the text format, this is trivial: The > > rules are evaluated in strict order. > > I do not see the relevance of the rule ordering in this discussion. Well, I think that the rule format used is actually connected to the issue of rule ordering. In this regard, the text format has two advantages: 1. The rule order is well defined. 2. The action to be taken at a rule match is given inline. Thus, rules in the text format are completely self contained. Your binary format can't be used by itself, it is meant to be used together with the current flow-binding mechanism. In a sense, it is guilty by association (sorry). I am just trying to show that the aspiration for (suboptimal) "efficiency" leads to complex solutions. > > > > - Static flow rules are simple, just edit them the with your > > > > favorite text editor. > > > > > > The average user is never going to edit any flow rules, thus I do > > > not think that the ability to edit them with a text editor is key > > > (My mom doesn't know what text is -- she uses Word :-). Even if it > > > was, one can simply build a tool that takes binary and output text > > > and vice versa. > > > > OK, I don't expect your mother to edit her flow rules :-). But maybe > > trained experts will. In your case, you would have to start with > > defining the text format. And then develop and debug the tool. > > Doesn't that seem a bit awkward? > > I don't think it is awkward, that sort of tool exist for IP routing, > IPsec, firewalls, etc. and they work nicely everyday in the hand of > experts. OK. I will just note that you will need yet another tool. > > No, exchanging flow rules is not a network layer protocol! It is a > > network control protocol, and is done on the "application" layer (or > > the control plane, as it is called in other architectures). > > control plane, application... what are talking about? The TCP/IP stack has four layers: Link, Internet, Transport and Application. In that sense, the exchange of flow rules is done at the application layer (with MH being the transport protocol, of course). Other architectures (GSM/3GPP for instance) separates user data from control data in different vertical planes, the user plane and the control plane. In such an architecture, MH and rule exchange would be control plane protocols. What I am really after is that exchanging rules isn't a network layer function, it is a control function. Thus the balance between compressing away the last bit and other aspects changes, compared to a (user plane) network layer protocol. > How are these flow rules different from an IPsec Traffic Selector? Does > IKE uses text to transfer Traffic Selectors on-the-wire? The fact that IKE is still using a binary format is just a historic mistake. IKEv3 will be text based when people realize that the 1970's ended some 30 years ago :-). Regards, Michael From gerardog@qualcomm.com Wed May 13 02:53: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 0972D3A6B3D for ; Wed, 13 May 2009 02:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.317 X-Spam-Level: X-Spam-Status: No, score=-103.317 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, 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 O7SLHU2cnCzz for ; Wed, 13 May 2009 02:53:09 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id AA8553A6DAC for ; Wed, 13 May 2009 02:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1242208482; x=1273744482; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Michael=20Eriksson=20,=0D=0A=20=20=20=20=20=20=20=20Julien=20Laganier=0D=0A =09|CC:=20"mext@ietf .org"=20|Date:=20Wed,=2013=20May=202009=20 02:54:27=20-0700|Subject:=20RE:=20[MEXT]=20offline=20Re: =20=20binary=20filters=20draft=200|Thread-Topic:=20[MEXT] =20offline=20Re:=20=20binary=20filters=20draft=200 |Thread-Index:=20AcnTrfkLf1SfgSSyRI2skBcMK+6OFwAAp2xQ |Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3A3EBD82729@ NASANEXMB08.na.qualcomm.com>|References:=20=0D=0A=09<2 00905111412.26321.julien.laganier.IETF@googlemail.com>=0D =0A=09<20090511185424.GA2445@kafka.verkstad.net>=0D=0A=09 <200905121505.39235.julien.laganier.IETF@googlemail.com> =0D=0A=20<20090513093156.GA3476@kafka.verkstad.net> |In-Reply-To:=20<20090513093156.GA3476@kafka.verkstad.net >|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5613"=3B=20a=3D"18111553"; bh=euc/VJCca8zzEy6yYH3JihrvvgqFVF/uubeNsw3d6fA=; b=wWdrGJYHhj0Q8UGqyeBfEP/MMyI05z/sE7FsS7z4694eXk/b+G+m10/B 5fKY7rp7jXyOpSIE1RrqQZ+rwOKc4+pn6d3xwwng73Pa5Z1wUcrO9Qr8L 5pPebCUDOXrfeU1BsnOgC1qgFQagdoXQGpNYllZeVrpf3azeoxuv0tpen 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5613"; a="18111553" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2009 02:54:41 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4D9sff3016188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 May 2009 02:54:41 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4D9seHA011793 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 May 2009 02:54:41 -0700 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Wed, 13 May 2009 02:54:40 -0700 From: "Giaretta, Gerardo" To: Michael Eriksson , Julien Laganier Date: Wed, 13 May 2009 02:54:27 -0700 Thread-Topic: [MEXT] offline Re: binary filters draft 0 Thread-Index: AcnTrfkLf1SfgSSyRI2skBcMK+6OFwAAp2xQ Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3EBD82729@NASANEXMB08.na.qualcomm.com> References: <200905111412.26321.julien.laganier.IETF@googlemail.com> <20090511185424.GA2445@kafka.verkstad.net> <200905121505.39235.julien.laganier.IETF@googlemail.com> <20090513093156.GA3476@kafka.verkstad.net> In-Reply-To: <20090513093156.GA3476@kafka.verkstad.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: "mext@ietf.org" Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 09:53:11 -0000 Hi Michael, One question below > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Michael Eriksson > Sent: Wednesday, May 13, 2009 12:32 PM > To: Julien Laganier > Cc: mext@ietf.org > Subject: Re: [MEXT] offline Re: binary filters draft 0 >=20 > On Tue, May 12, 2009 at 15:05:39 +0200, Julien Laganier wrote: > > On Monday 11 May 2009, Michael Eriksson wrote: > > > I can't see how this is simpler than printf. With printf you normally > > > just need one single statement to output a complete rule. > > > > and how many statements do you need to parse and validate? Also note > > that the number of statements is pretty much irrelevant since in the > > end what matters is that you have to move words in memory and there the > > printf will not do less... >=20 > OK, counting the number of statements isn't the best argument :-). >=20 > With "simple" I don't mean "more efficient", I mean that it is better > (easier) when developing, debugging and maintaining the system. Saving > a few CPU cycles or bytes just isn't relevant anymore, at least not > for control functions. >=20 > In my view, dynamic flow rules will not be generated by the "MIP > stack" itself. They will be determined by a higher level function, > e.g, a connection manager. The connection manager shouldn't even have > to care about what mobility solution is used (MIPv6, shim6, MOBIKE, > ...). One of the ideas and explicit goals with our text-based rule > language is that it is mobility mechanism agnostic. >=20 > The connection manager will do reasoning at an abstract level. For > that, text output is better. Having it output a MIP-specific binary > format is not very elegant. >=20 Are you talking about the coding of the API between the connection manager = and the MIP stack? I don't this is the point here. The point is how the MN via the MIP protocol delivers the rules to the HA. = This has nothing to do with internal API in the MN. Thanks Gerardo=20 > Some observations: >=20 > - The Android phone does all its network control logic in Java, which > I think is a very reasonable design. An Android connection manager > would thus be written in Java, and text output is suitable. >=20 > - For a research project, we did a connection manager in Python, which > is a rather high level language. The connection manager did > reasoning about what access to use for each flow at an abstract and > powerful level, and then easily presented the result in the > text-based flow rules language that we are suggesting. >=20 >=20 > > > > > - It is less complex (cf. your bit vector). > > > > > > > > Again, IMHO a blanket statement. I'd rather parse a well defined > > > > simple binary format than text. The bit and byte vector I proposed > > > > are straightforward and simple in my view. > > > > > > There are well established methods for parsing text with formal > > > grammars (e.g., by using lex and yacc). Binary parsing is ad hoc, > > > hand coded and rather error prone. > > > > I do no think a network layer stack implementation is the place to > > implement formal grammars, parse and validate regular expressions. >=20 > Why not? Because it is not "efficient" enough? Please note that most > (all?) MIP signaling implementations are user space programs, and are > not involved in packet forwarding. >=20 > Also, see my comment above regarding that the rules will not be > generated by the "MIP stack" itself. >=20 > > > If you want more arguments for why the binary format is more complex, > > > see the ongoing discussion on how the HA should select between > > > overlapping binary rules. For the text format, this is trivial: The > > > rules are evaluated in strict order. > > > > I do not see the relevance of the rule ordering in this discussion. >=20 > Well, I think that the rule format used is actually connected to the > issue of rule ordering. >=20 > In this regard, the text format has two advantages: >=20 > 1. The rule order is well defined. > 2. The action to be taken at a rule match is given inline. >=20 > Thus, rules in the text format are completely self contained. >=20 > Your binary format can't be used by itself, it is meant to be used > together with the current flow-binding mechanism. In a sense, it is > guilty by association (sorry). I am just trying to show that the > aspiration for (suboptimal) "efficiency" leads to complex solutions. >=20 > > > > > - Static flow rules are simple, just edit them the with your > > > > > favorite text editor. > > > > > > > > The average user is never going to edit any flow rules, thus I do > > > > not think that the ability to edit them with a text editor is key > > > > (My mom doesn't know what text is -- she uses Word :-). Even if it > > > > was, one can simply build a tool that takes binary and output text > > > > and vice versa. > > > > > > OK, I don't expect your mother to edit her flow rules :-). But maybe > > > trained experts will. In your case, you would have to start with > > > defining the text format. And then develop and debug the tool. > > > Doesn't that seem a bit awkward? > > > > I don't think it is awkward, that sort of tool exist for IP routing, > > IPsec, firewalls, etc. and they work nicely everyday in the hand of > > experts. >=20 > OK. I will just note that you will need yet another tool. >=20 > > > No, exchanging flow rules is not a network layer protocol! It is a > > > network control protocol, and is done on the "application" layer (or > > > the control plane, as it is called in other architectures). > > > > control plane, application... what are talking about? >=20 > The TCP/IP stack has four layers: Link, Internet, Transport and > Application. In that sense, the exchange of flow rules is done at the > application layer (with MH being the transport protocol, of course). >=20 > Other architectures (GSM/3GPP for instance) separates user data from > control data in different vertical planes, the user plane and the > control plane. In such an architecture, MH and rule exchange would be > control plane protocols. >=20 > What I am really after is that exchanging rules isn't a network layer > function, it is a control function. Thus the balance between > compressing away the last bit and other aspects changes, compared to a > (user plane) network layer protocol. >=20 > > How are these flow rules different from an IPsec Traffic Selector? Does > > IKE uses text to transfer Traffic Selectors on-the-wire? >=20 > The fact that IKE is still using a binary format is just a historic > mistake. IKEv3 will be text based when people realize that the 1970's > ended some 30 years ago :-). >=20 >=20 > Regards, > Michael > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From mer@kafka.verkstad.net Wed May 13 02:57: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 2A7843A68BE for ; Wed, 13 May 2009 02:57:37 -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 hekfy0iOS+M9 for ; Wed, 13 May 2009 02:57:36 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 3131A3A6D1B for ; Wed, 13 May 2009 02:57:36 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 02DA37111D4; Wed, 13 May 2009 11:59:07 +0200 (CEST) Date: Wed, 13 May 2009 11:59:07 +0200 From: Michael Eriksson To: Hesham Soliman Message-ID: <20090513095906.GB3476@kafka.verkstad.net> References: <20090512061528.GB8612@kafka.verkstad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 09:57:37 -0000 On Tue, May 12, 2009 at 08:27:48 +0200, Hesham Soliman wrote: > But I do appreciate an open and unrestricted debate with technical > arguments. Previously, some objections to the old solution got quite > weak counter arguments like "[...] departures from the current > agreement", "in theory there is nothing preventing us from [...], > except from the fact that some of us might disagree..." and "Instead > of trying to reinvent the wheel, which will likely be futile, ...". > > => FWIW, that discussion was not about flow formats, it was about the flow > bindings draft. We had many technical arguments on it from all points of > view. Like in any project, unless new reasons comes up, we shouldn't change > decisions used as fundamental assumptions. The flow-binding draft (unfortunately) currently only suits a binary format similar to what was in your first draft. Thus, I see them as one solution. Discussing new ideas and solutions with people who have already made up there minds (since years back) is not very fruitful. > > The binary rules transmitted with the flow-binding mechanism has no > > inherent order, unless you start to use the PRI field as some kind of > > line number (this gives me severe BASIC flashbacks :-)). > > > > The rules in the text format, on the other hand, are inherently > > strictly ordered. > > => But the ordering discussion was about find the order for routing purposes > especially for overlapping flows. It doesn't matter what format the flow is > in, the ordering needs to be done based on 1) determining whether an overlap > exists and 2) how the flows within such overlap get forwarded. I don't > understand how line order comes into this. Regardless of the format used, > this function has to be done. The procedure you describe above, determining the correct rule order, would have to be done at the MN. The result of this is an ordered list of rules. To get the binary flow rules evaluated in the correct order at the HA, the MN would have to number every rule by using the PRI field, which will then be used as a rule counter. (Sorry for the BASIC joke, but BASIC numbers statements in exactly the same way.) To avoid using the PRI field for a particular rule, you would have to determine that the rule doesn't overlap with any other rule, and that the evaluation order therefore doesn't matter for that particular rule. Doing this overlap check is not trivial. The text format, on the other hand, does not need to have the rules numbered when they are transmitted to the HA, since the order is inherent. Regards, Michael From hesham@elevatemobile.com Wed May 13 03:33: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 C825D3A6E47 for ; Wed, 13 May 2009 03:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 EM3+cvDOmdkN for ; Wed, 13 May 2009 03:33: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 CD5F33A6A24 for ; Wed, 13 May 2009 03:33:53 -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 1M4Bny-0002k1-VQ; Wed, 13 May 2009 20:35:19 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 13 May 2009 20:35:12 +1000 From: Hesham Soliman To: Michael Eriksson Message-ID: Thread-Topic: [MEXT] offline Re: binary filters draft 0 Thread-Index: AcnTtn6z9BEc2GttIEavGt4bkDr5FA== In-Reply-To: <20090513095906.GB3476@kafka.verkstad.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 10:33:55 -0000 On 13/05/09 7:59 PM, "Michael Eriksson" wrote: > On Tue, May 12, 2009 at 08:27:48 +0200, Hesham Soliman wrote: >> But I do appreciate an open and unrestricted debate with technical >> arguments. Previously, some objections to the old solution got quite >> weak counter arguments like "[...] departures from the current >> agreement", "in theory there is nothing preventing us from [...], >> except from the fact that some of us might disagree..." and "Instead >> of trying to reinvent the wheel, which will likely be futile, ...". >> >> => FWIW, that discussion was not about flow formats, it was about the flow >> bindings draft. We had many technical arguments on it from all points of >> view. Like in any project, unless new reasons comes up, we shouldn't change >> decisions used as fundamental assumptions. > > The flow-binding draft (unfortunately) currently only suits a binary > format similar to what was in your first draft. Thus, I see them as > one solution. => That's not true. It is orthogonal to the flow descriptor format. Although, after reading Julien's response earlier I can't see any benefit for the text format in terms of use or implementation. Probably easier on the eye to design and spec but I can't see any other benefit. >> => But the ordering discussion was about find the order for routing purposes >> especially for overlapping flows. It doesn't matter what format the flow is >> in, the ordering needs to be done based on 1) determining whether an overlap >> exists and 2) how the flows within such overlap get forwarded. I don't >> understand how line order comes into this. Regardless of the format used, >> this function has to be done. > > The procedure you describe above, determining the correct rule order, > would have to be done at the MN. The result of this is an ordered list > of rules. To get the binary flow rules evaluated in the correct order > at the HA, the MN would have to number every rule by using the PRI > field, which will then be used as a rule counter. (Sorry for the BASIC > joke, but BASIC numbers statements in exactly the same way.) > > To avoid using the PRI field for a particular rule, you would have to > determine that the rule doesn't overlap with any other rule, and that > the evaluation order therefore doesn't matter for that particular > rule. Doing this overlap check is not trivial. > > The text format, on the other hand, does not need to have the rules > numbered when they are transmitted to the HA, since the order is > inherent. => I don't think you're talking about the same thing we were discussing before. Actually, I don't know what you're talking about. Determining overlap has to happen whatever format you use. The ordering is a forwarding priority and has *nothing* to do with the way the rule is written, it's an inter-rule ordering not intra-rule ordering. Hesham From mer@kafka.verkstad.net Wed May 13 04:51:47 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 1FA083A6955 for ; Wed, 13 May 2009 04:51:47 -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 GNPm6opakW-L for ; Wed, 13 May 2009 04:51:46 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 3A7143A692F for ; Wed, 13 May 2009 04:51:46 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 0D1F4710B81; Wed, 13 May 2009 13:53:18 +0200 (CEST) Date: Wed, 13 May 2009 13:53:18 +0200 From: Michael Eriksson To: "Giaretta, Gerardo" Message-ID: <20090513115318.GA10312@kafka.verkstad.net> References: <200905111412.26321.julien.laganier.IETF@googlemail.com> <20090511185424.GA2445@kafka.verkstad.net> <200905121505.39235.julien.laganier.IETF@googlemail.com> <20090513093156.GA3476@kafka.verkstad.net> <057632CE4CE10D45A1A3D6D19206C3A3EBD82729@NASANEXMB08.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3EBD82729@NASANEXMB08.na.qualcomm.com> Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 11:51:47 -0000 On Wed, May 13, 2009 at 02:54:27 -0700, Giaretta, Gerardo wrote: > > In my view, dynamic flow rules will not be generated by the "MIP > > stack" itself. They will be determined by a higher level function, > > e.g, a connection manager. The connection manager shouldn't even have > > to care about what mobility solution is used (MIPv6, shim6, MOBIKE, > > ...). One of the ideas and explicit goals with our text-based rule > > language is that it is mobility mechanism agnostic. > > > > The connection manager will do reasoning at an abstract level. For > > that, text output is better. Having it output a MIP-specific binary > > format is not very elegant. > > Are you talking about the coding of the API between the connection > manager and the MIP stack? I don't this is the point here. > > The point is how the MN via the MIP protocol delivers the rules to > the HA. This has nothing to do with internal API in the MN. It is of course an advantage that the same format is used by the connection manager as in the MIP protocol. The connection manager will create an array of bytes (the flow rules in ASCII format). All that the MIP daemon needs to do is to put an MH transport header on this byte array and send it to the HA. The MIP daemon does not need to do complex binary packing of invidual rules, it will just transfer a byte vector. Trivial to implement! Regards, Michael From gerardog@qualcomm.com Wed May 13 04:54: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 A99C63A6955 for ; Wed, 13 May 2009 04:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.257 X-Spam-Level: X-Spam-Status: No, score=-105.257 tagged_above=-999 required=5 tests=[AWL=1.342, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 LEl4eZTCJBo4 for ; Wed, 13 May 2009 04:54:07 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id BE09A28C0FF for ; Wed, 13 May 2009 04:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1242215740; x=1273751740; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Michael=20Eriksson=20|CC:=20"mext@ietf.org"=20|Date:=20Wed, =2013=20May=202009=2004:55:32=20-0700|Subject:=20RE:=20[M EXT]=20offline=20Re:=20=20binary=20filters=20draft=200 |Thread-Topic:=20[MEXT]=20offline=20Re:=20=20binary=20fil ters=20draft=200|Thread-Index:=20AcnTwXfDg7UlanpDQbqnMZxT pAu4DAAABJCA|Message-ID:=20<057632CE4CE10D45A1A3D6D19206C 3A3EBD8272C@NASANEXMB08.na.qualcomm.com>|References:=20=0D=0A=20<200905111412.26321.julien.laganier.IETF@google mail.com>=0D=0A=20<20090511185424.GA2445@kafka.verkstad.n et>=0D=0A=20<200905121505.39235.julien.laganier.IETF@goog lemail.com>=0D=0A=20<20090513093156.GA3476@kafka.verkstad .net>=0D=0A=20<057632CE4CE10D45A1A3D6D19206C3A3EBD82729@N ASANEXMB08.na.qualcomm.com>=0D=0A=20<20090513115318.GA103 12@kafka.verkstad.net>|In-Reply-To:=20<20090513115318.GA1 0312@kafka.verkstad.net>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5613"=3B=20a=3D"18115222"; bh=fZh6K+ZVWrzKWqroaYj+mQGlAwsVjq7d1Scu9NoMvJE=; b=JOR/guhwAT/NbGo0Wv721OoBEB5FcZ+Mzh74RQSDNSdIw4OT7lbTnkMn BaQvaF5KfLNd2LUHoe6BQiW343i1XJrbwUEN+T4V/iNty9/Wg8nva539k W3S7p85t1QFPcPqXBnCvQ2cIn+gZtzfHpFg4ufvyaah7WufetIfC/N3mQ 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5613"; a="18115222" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2009 04:55:36 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4DBtavq015331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 May 2009 04:55:36 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4DBtZeo028258 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 May 2009 04:55:36 -0700 (PDT) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Wed, 13 May 2009 04:55:36 -0700 From: "Giaretta, Gerardo" To: Michael Eriksson Date: Wed, 13 May 2009 04:55:32 -0700 Thread-Topic: [MEXT] offline Re: binary filters draft 0 Thread-Index: AcnTwXfDg7UlanpDQbqnMZxTpAu4DAAABJCA Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3EBD8272C@NASANEXMB08.na.qualcomm.com> References: <200905111412.26321.julien.laganier.IETF@googlemail.com> <20090511185424.GA2445@kafka.verkstad.net> <200905121505.39235.julien.laganier.IETF@googlemail.com> <20090513093156.GA3476@kafka.verkstad.net> <057632CE4CE10D45A1A3D6D19206C3A3EBD82729@NASANEXMB08.na.qualcomm.com> <20090513115318.GA10312@kafka.verkstad.net> In-Reply-To: <20090513115318.GA10312@kafka.verkstad.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: "mext@ietf.org" Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 11:54:08 -0000 You are assuming an API which is not standardized so I could claim that oth= er systems use different encoding in the internal communication. I don't think this should be consider as a differentiating point between th= e solutions as this is clearly not generic enough and only based on your pe= rsonal assumptions. Gerardo > -----Original Message----- > From: Michael Eriksson [mailto:michael.eriksson@ericsson.com] > Sent: Wednesday, May 13, 2009 2:53 PM > To: Giaretta, Gerardo > Cc: mext@ietf.org > Subject: Re: [MEXT] offline Re: binary filters draft 0 >=20 > On Wed, May 13, 2009 at 02:54:27 -0700, Giaretta, Gerardo wrote: > > > In my view, dynamic flow rules will not be generated by the "MIP > > > stack" itself. They will be determined by a higher level function, > > > e.g, a connection manager. The connection manager shouldn't even have > > > to care about what mobility solution is used (MIPv6, shim6, MOBIKE, > > > ...). One of the ideas and explicit goals with our text-based rule > > > language is that it is mobility mechanism agnostic. > > > > > > The connection manager will do reasoning at an abstract level. For > > > that, text output is better. Having it output a MIP-specific binary > > > format is not very elegant. > > > > Are you talking about the coding of the API between the connection > > manager and the MIP stack? I don't this is the point here. > > > > The point is how the MN via the MIP protocol delivers the rules to > > the HA. This has nothing to do with internal API in the MN. >=20 > It is of course an advantage that the same format is used by the > connection manager as in the MIP protocol. The connection manager will > create an array of bytes (the flow rules in ASCII format). All that > the MIP daemon needs to do is to put an MH transport header on this > byte array and send it to the HA. >=20 > The MIP daemon does not need to do complex binary packing of invidual > rules, it will just transfer a byte vector. Trivial to implement! >=20 >=20 > Regards, > Michael From mer@kafka.verkstad.net Wed May 13 05:16: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 675D13A6C3E for ; Wed, 13 May 2009 05:16:35 -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 ZOjXbmJ0UgvP for ; Wed, 13 May 2009 05:16:34 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 605873A69E6 for ; Wed, 13 May 2009 05:16:34 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 532BB7111D4; Wed, 13 May 2009 14:18:06 +0200 (CEST) Date: Wed, 13 May 2009 14:18:06 +0200 From: Michael Eriksson To: Hesham Soliman Message-ID: <20090513121806.GB10312@kafka.verkstad.net> References: <20090513095906.GB3476@kafka.verkstad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 12:16:35 -0000 On Wed, May 13, 2009 at 20:35:12 +1000, Hesham Soliman wrote: > On 13/05/09 7:59 PM, "Michael Eriksson" > wrote: > > The flow-binding draft (unfortunately) currently only suits a binary > > format similar to what was in your first draft. Thus, I see them as > > one solution. > > => That's not true. It is orthogonal to the flow descriptor format. As a co-designer of an alternative flow rule format, I must unfortunately disagree: the flow-binding draft is not orthogonal to the rule format, even though it should be. The text-based rule format doesn't need any of the fields that are described in the flow-binding draft. All it needs is to get a self contained byte array (the rules in ASCII format) transferred from MN to HA. The text format inherently contains information about: - Rule ordering - What action to take for a rule match Handling that in the transport format, which the flow-binding draft does 1. Makes the wrong assumptions about the flow rule format 2. Does things at the wrong "layer" > > The procedure you describe above, determining the correct rule order, > > would have to be done at the MN. The result of this is an ordered list > > of rules. To get the binary flow rules evaluated in the correct order > > at the HA, the MN would have to number every rule by using the PRI > > field, which will then be used as a rule counter. (Sorry for the BASIC > > joke, but BASIC numbers statements in exactly the same way.) > > > > To avoid using the PRI field for a particular rule, you would have to > > determine that the rule doesn't overlap with any other rule, and that > > the evaluation order therefore doesn't matter for that particular > > rule. Doing this overlap check is not trivial. > > > > The text format, on the other hand, does not need to have the rules > > numbered when they are transmitted to the HA, since the order is > > inherent. > > => I don't think you're talking about the same thing we were discussing > before. Actually, I don't know what you're talking about. > > Determining overlap has to happen whatever format you use. The ordering is a > forwarding priority and has *nothing* to do with the way the rule is > written, it's an inter-rule ordering not intra-rule ordering. You are mixing up: 1. Determining the order of the rules. This is done at the MN, and is independent of the how the rules are expressed (binary or text). Determining whether the rules overlap or not is not necessary, as long as you sort them in priority order. 2. Transfering the ORDERED list of rules from the MN to the HA. This is where there is a difference between the text rules and binary rules transferred in the flow-binding format. - For the text format, this is trivial: Just append them in order. - For the binary format, you have two choices: - Send them unordered (FID-PRI=0). Not a good idea, since it is most likely that the wrong rule will match some flows. - Enumerate the rules by using the FID-PRI field as a rule numerator (hence my BASIC remark). In practice, you will always have to enumerate the rules with the FID-PRI field. This is not very elegant, and adds complexity. For instance, the rules would have to be sorted according to their FID-PRI value after reception, while in the text format they always arrives in correct order. Regards, Michael From julien.laganier.ietf@googlemail.com Wed May 13 05:33: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 57FF83A6B3D for ; Wed, 13 May 2009 05:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 dIAqbLXBRuZy for ; Wed, 13 May 2009 05:32:59 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 46C1C3A6782 for ; Wed, 13 May 2009 05:32:59 -0700 (PDT) Received: by ewy24 with SMTP id 24so731466ewy.37 for ; Wed, 13 May 2009 05:34:27 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=/YnPUa8O5JiWDCcZ+vGKWuWWdms53tPto6otgAT6Zgo=; b=Ueis69HzNkH9fptX4mTdmlf04bUm2ov9F5RkYw8HdkvF4klSzkGWc55AjPSEKwZBMi WgW7UGgfwQmsPMxJ7oAqAO7uNn8oxzNllK1SgjnkvULTxRSg6WXEXtiK/XmOqjQzEz0Y wTdTxtm7sK8vTJITFr3Nv4YlqdfFt/xFtBZmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=tUQNoznJJIBVkZI/Dq+KlmAoFzWMY8j0dFoIapV6Wsmym6xl2LSgfZ1pPQTeSv3UQb n0ZQ5wlKt7QE4JyDnjpZrwc6xfjy8hDB8o5fUpoDE7Mj2w82k4O8KIPiUAVyuP9o9dDZ c89x21mLPlyI0TFiK510tiww4DcyHVmU+ayS0= Received: by 10.216.53.12 with SMTP id f12mr390299wec.72.1242218067321; Wed, 13 May 2009 05:34:27 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id g11sm3217427gve.1.2009.05.13.05.34.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 May 2009 05:34:26 -0700 (PDT) From: Julien Laganier To: Michael Eriksson Date: Wed, 13 May 2009 14:34:30 +0200 User-Agent: KMail/1.9.10 References: <200905121505.39235.julien.laganier.IETF@googlemail.com> <20090513093156.GA3476@kafka.verkstad.net> In-Reply-To: <20090513093156.GA3476@kafka.verkstad.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905131434.30760.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 12:33:01 -0000 Hi Michael, On Wednesday 13 May 2009, Michael Eriksson wrote: > On Tue, May 12, 2009 at 15:05:39 +0200, Julien Laganier wrote: > > On Monday 11 May 2009, Michael Eriksson wrote: > > > I can't see how this is simpler than printf. With printf you > > > normally just need one single statement to output a complete > > > rule. > > > > and how many statements do you need to parse and validate? Also > > note that the number of statements is pretty much irrelevant since > > in the end what matters is that you have to move words in memory > > and there the printf will not do less... > > OK, counting the number of statements isn't the best argument :-). Ok - let's not use it then. > With "simple" I don't mean "more efficient", I mean that it is better > (easier) when developing, debugging and maintaining the system. FWIW I don't think it would be reasonable to run in a production environment code written by someone who doesn't know how to code a byte-and-bit parser :-) > Saving a few CPU cycles or bytes just isn't relevant anymore, at > least not for control functions. It is not because it isn't the number one goal that it is not relevant. > In my view, dynamic flow rules will not be generated by the "MIP > stack" itself. They will be determined by a higher level function, > e.g, a connection manager. The connection manager shouldn't even have > to care about what mobility solution is used (MIPv6, shim6, MOBIKE, > ...). One of the ideas and explicit goals with our text-based rule > language is that it is mobility mechanism agnostic. You can very well have a mobility protocol agnostic language to describe you rules in your implementation. What we're talking about here is how the rules are transmitted by MIPv6, not how they are transmitted by the Agnostic Protocol. > The connection manager will do reasoning at an abstract level. For > that, text output is better. Having it output a MIP-specific binary > format is not very elegant. Again you can do reasoning in your connection manager at an abstract level using text, ideograms or XML. That doesn't translate into the need to carry that same text in the MIPv6 protocol. > Some observations: > > - The Android phone does all its network control logic in Java, which > I think is a very reasonable design. An Android connection manager > would thus be written in Java, and text output is suitable. > > - For a research project, we did a connection manager in Python, > which is a rather high level language. The connection manager did > reasoning about what access to use for each flow at an abstract and > powerful level, and then easily presented the result in the > text-based flow rules language that we are suggesting. See above, there's no contradiction b/w coding in a high level language and manipulating text and transporting information in a binary format. > > > > > - It is less complex (cf. your bit vector). > > > > > > > > Again, IMHO a blanket statement. I'd rather parse a well > > > > defined simple binary format than text. The bit and byte vector > > > > I proposed are straightforward and simple in my view. > > > > > > There are well established methods for parsing text with formal > > > grammars (e.g., by using lex and yacc). Binary parsing is ad hoc, > > > hand coded and rather error prone. > > > > I do no think a network layer stack implementation is the place to > > implement formal grammars, parse and validate regular expressions. > > Why not? Because it is not "efficient" enough? Please note that most > (all?) MIP signaling implementations are user space programs, and are > not involved in packet forwarding. Why? Because that's how things are done. What I recommend is that you find out 1) what is most deployed network layer protocol, and 2) which encodings its use. Once you've done the exercise, compare the situation with RFC 3252. On my side I do not know any implementation of RFC 3252 in wide use. > Also, see my comment above regarding that the rules will not be > generated by the "MIP stack" itself. That's internal to your implementation. I am talking about bits-on-the-wire. Yes, bits! > > > If you want more arguments for why the binary format is more > > > complex, see the ongoing discussion on how the HA should select > > > between overlapping binary rules. For the text format, this is > > > trivial: The rules are evaluated in strict order. > > > > I do not see the relevance of the rule ordering in this discussion. > > Well, I think that the rule format used is actually connected to the > issue of rule ordering. > > In this regard, the text format has two advantages: > > 1. The rule order is well defined. Same can be done with a binary format. Order of IPsec TS in IKE is well defined. > 2. The action to be taken at a rule match is given inline. Same can be done with a binary format. > Thus, rules in the text format are completely self contained. Same can be done with a binary format. > Your binary format can't be used by itself, it is meant to be used > together with the current flow-binding mechanism. In a sense, it is > guilty by association (sorry). I am just trying to show that the > aspiration for (suboptimal) "efficiency" leads to complex solutions. I respectfully disagree. > > > > > - Static flow rules are simple, just edit them the with your > > > > > favorite text editor. > > > > > > > > The average user is never going to edit any flow rules, thus I > > > > do not think that the ability to edit them with a text editor > > > > is key (My mom doesn't know what text is -- she uses Word :-). > > > > Even if it was, one can simply build a tool that takes binary > > > > and output text and vice versa. > > > > > > OK, I don't expect your mother to edit her flow rules :-). But > > > maybe trained experts will. In your case, you would have to start > > > with defining the text format. And then develop and debug the > > > tool. Doesn't that seem a bit awkward? > > > > I don't think it is awkward, that sort of tool exist for IP > > routing, IPsec, firewalls, etc. and they work nicely everyday in > > the hand of experts. > > OK. I will just note that you will need yet another tool. Exactly as you need another tool to crunch, resolve, save, edit your text rules! > > > No, exchanging flow rules is not a network layer protocol! It is > > > a network control protocol, and is done on the "application" > > > layer (or the control plane, as it is called in other > > > architectures). > > > > control plane, application... what are talking about? > > The TCP/IP stack has four layers: Link, Internet, Transport and > Application. In that sense, the exchange of flow rules is done at the > application layer (with MH being the transport protocol, of course). MH is not a transport protocol. It is a network layer mobility (or routing) protocol. > Other architectures (GSM/3GPP for instance) separates user data from > control data in different vertical planes, the user plane and the > control plane. In such an architecture, MH and rule exchange would be > control plane protocols. Thanks for explaining the difference b/w user plane and control plane, I am sure this will be useful to many of us. As you're mentionning 3GPP I will simply note that the control plane for the network mobility core (GTP-C) does not use text encoding. It uses binary, because it is network layer control protocols. > What I am really after is that exchanging rules isn't a network layer > function, it is a control function. Thus the balance between > compressing away the last bit and other aspects changes, compared to > a (user plane) network layer protocol. Exchanging mobility routing rules is both a control and a network protocol thus I do not know what you're after. > > How are these flow rules different from an IPsec Traffic Selector? > > Does IKE uses text to transfer Traffic Selectors on-the-wire? > > The fact that IKE is still using a binary format is just a historic > mistake. IKEv3 will be text based when people realize that the 1970's > ended some 30 years ago :-). Do you mean that RFC 2460 will eventually be superseded by RFC 3252? Cheers - --julien From julien.laganier.ietf@googlemail.com Wed May 13 05:44:31 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 5B7213A6903 for ; Wed, 13 May 2009 05:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 5Hgc9oAB00A1 for ; Wed, 13 May 2009 05:44:30 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id C92283A68D9 for ; Wed, 13 May 2009 05:44:29 -0700 (PDT) Received: by fxm2 with SMTP id 2so623067fxm.37 for ; Wed, 13 May 2009 05:45:59 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=6qqWWGR/igH9wnizjUAltdzYxImAGD44kTKHzc5IhLY=; b=KVj3AF04L0oLwd2tDU75zibjtNSQeMxe0+3CPkpY/3je3u2vG4Dk7DKLWWIlm2u3wb CvNN+UmutggzfU8ME9Ic2VueUzFX7T3ThWyVVZVE8c8+uWmACzM1XD0vo8zEYHeNiUpU CYx6UnvNqB3+jNGuBk2H357woIltGMo7t2+cI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=XJ7m2MkGWV5Zhxkp8Iru5Xl8PLOm22YDABK8dbpomsSL37FMP1DANV++e3nCx6702P hOLgtt7MuiXZ6z54mz8q2OCFQMh9P8Z90B0Id2hcFPnDh8pG9josBhwk4/bvSLlwb66f EKAP3G6e4FYIWbwPITWWQm3usu2Uo5oh4ErjI= Received: by 10.86.70.3 with SMTP id s3mr1182822fga.16.1242218759762; Wed, 13 May 2009 05:45:59 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 4sm3140265fge.3.2009.05.13.05.45.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 May 2009 05:45:59 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Wed, 13 May 2009 14:46:04 +0200 User-Agent: KMail/1.9.10 References: <20090513095906.GB3476@kafka.verkstad.net> <20090513121806.GB10312@kafka.verkstad.net> In-Reply-To: <20090513121806.GB10312@kafka.verkstad.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905131446.04338.julien.laganier.IETF@googlemail.com> Cc: Michael Eriksson Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 12:44:31 -0000 Michael, On Wednesday 13 May 2009, Michael Eriksson wrote: > [...] > You are mixing up: OTOH, I have the impression that you are mixing things up quite a bit here. See below - > 1. Determining the order of the rules. This is done at the MN, and is > independent of the how the rules are expressed (binary or text). > Determining whether the rules overlap or not is not necessary, as > long as you sort them in priority order. > > 2. Transfering the ORDERED list of rules from the MN to the HA. This > is where there is a difference between the text rules and binary > rules transferred in the flow-binding format. > > - For the text format, this is trivial: Just append them in order. Exactly the same can be done with the binary format: Just append them in order in a single BU. Defining a priority field is an optimization that allows not sending the full ruleset in each BU, thus making it possible to order rules that were sent in different BUs. You would need exactly the same for your text format were you going to provide the same optimization. > - For the binary format, you have two choices: > > - Send them unordered (FID-PRI=0). Not a good idea, since it is > most likely that the wrong rule will match some flows. > > - Enumerate the rules by using the FID-PRI field as a rule > numerator (hence my BASIC remark). > > In practice, you will always have to enumerate the rules with > the FID-PRI field. This is not very elegant, and adds complexity. For > instance, the rules would have to be sorted according to their > FID-PRI value after reception, while in the text format they always > arrives in correct order. See above the point that FID-PRI is required only because there's the optimization of sending the full ruleset in each BU. --julien From julien.laganier.ietf@googlemail.com Wed May 13 06:06: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 855753A6FAC for ; Wed, 13 May 2009 06:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 hP+YvjduilJe for ; Wed, 13 May 2009 06:06:21 -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 F01A73A6DB0 for ; Wed, 13 May 2009 06:06:16 -0700 (PDT) Received: by bwz22 with SMTP id 22so632537bwz.37 for ; Wed, 13 May 2009 06:07:46 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=OdR4Q9yYRojoJN9GPBHdNAx2v8Q42SXkidaKinPNcLI=; b=fH/YVZS4kegMk6KKUvtq/0EF4oTgTgdqfc5fUrPS4dG/6BAhED/a2H7eEeAjbanfqG Pw58Fz2QXTsmJUFEfR9X5yR4eDV3RgghpZl30tqv+YT6rS8Lpq/Y6XPC880HD0xEYbdc C31jdY+1xLVqmFMoteQOj3LZeiCQHTTvRURWs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=HRTJoqZYXPUdz5/AXO2N0O/BPWCvDosN1hKTnd0l+7uk2DlwXfoe5aiDXz0iJopK60 VrJNGQqE1SRXSmfEWV+Vv82SUh2nReTQfYslYvUc0tN3nmNl+5gh6k4w8ARxUnQXPWou ZxyA+KCr3NGuOuY8tJK4hkZVNx+6OtPLWaFzg= Received: by 10.204.117.141 with SMTP id r13mr887931bkq.207.1242220066516; Wed, 13 May 2009 06:07:46 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 28sm1670776fkx.28.2009.05.13.06.07.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 May 2009 06:07:43 -0700 (PDT) From: Julien Laganier To: Hesham Soliman Date: Wed, 13 May 2009 15:07:48 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905131507.48903.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] flow binding draft 2 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, 13 May 2009 13:06:22 -0000 Hi Hesham, On Tuesday 12 May 2009, Hesham Soliman wrote: > Hi Julien, > > > It seems we're making progress. > > > > I agree that the overlap needs to be determined at some level, but > > I think we disagree on the level. > > > > I think the choice of a specific ordering of overlapping rules > > doesn't belong to the MIPv6 layer. In my view it is a policy > > problem and has to be sorted by a much more complex machinery than > > the MIPv6 stack, maybe a human being and common sense are required. > > => I'm not sure about a human being :) but I agree with you that it's > done on a higher layer. MIPv6 doesn't know what policies are needed > by the apps ...etc > > > The MIPv6 layer should simply have to deal with an ordered set of > > rules, which might overlap or not, not the problem of the MIPv6 > > layer since they are ordered. > > => Agreed. > > > The situation would then be similar to that of a firewall or an > > IPsec SPD. The administrator has to determine an order for rules > > based on a given policy, then the stack simply enforces it. > > > > Am I making any sense? > > => Yes. The question is related to how MIPv6 translates the order > that it was given by others. I'm happy with the logic above, however, > I always get stuck on (potentially silly?) corner cases. For > instance, we were discussing mobile routers when we were updating the > draft and how in some cases they can potentially send policies for a > very large group of MNs. Now, it is possible that the PRI field runs > out of space in those cases. It is also very likely that the rules > don't overlap across different MNs. So, in a scenario like that it is > worth reusing the PRI field for rules that don't overlap. We can also > make it very large I suppose. Thanks for pointing out the usecase, I see now. > In any case, I agree with your functional breakdown above and don't > see a problem with making it unique except for the problem above. Do > you think it's an issue? If others can think of any other scenarios > please let us know. Absent that, I was going to suggest that _at > least_ overlapping rules must have unique PRIs. > It's a but difficult to be concrete about scenarios when we don't > have an API to a policy engine to work with. The part that disturb me is the fact that if you say "overlapping rules must have unique PRIs" then I somehow need to be able to determine the overlaps so that I know what to do with the priorities. I'd prefer that we make it all or nothing, that is: 1. Rules (overlapping or not) have unique PRIs, or 2. Rules (overlapping or not) can have same PRIs, rule with priority P established earlier prevail over rules with same priority P established latter. In this way an implementation would not be required to determine whether there's an overlap or not. That would of course not preclude the operator, administrator, application or MIP stack to determine whether there's an overlap and what to do with it. > Either way, I think we need to make this requirement, or context > clear in the draft (I mean where the filters are created and ordered > ...etc). Sounds like a plan. Thanks for discussion Hesham. --julien From tsirtsis@googlemail.com Wed May 13 06:49: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 EFB293A6FAC for ; Wed, 13 May 2009 06:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.163, 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 bk6T8aagH5L5 for ; Wed, 13 May 2009 06:49:48 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 7109C3A6DB0 for ; Wed, 13 May 2009 06:49:48 -0700 (PDT) Received: by fxm2 with SMTP id 2so662413fxm.37 for ; Wed, 13 May 2009 06:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ndYmtNLygroUdawYw4Sf8WHH7P/ae+mz4FU13/9x6VU=; b=ey6u98iab5oB99o/UgqLV5HX5M/UFPwWsCRwOMIbs5kt7DG8i/xj7w/Lh94rFBAjLY 47PlV8GC4t6IaMjeQ/LDSDzGN8yz19pq7PwRqz+HIbVz0iVNLCyRtXDUf+lJ1cIpseXh 2K5L/DOSFWnzlheCJ8PogvPf0Txxpx9szSmkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=g5a7cWD4Q7A4H8ISmzgYWqEdEFeXLLR4vHW9H5ljBsoRSSZDWMxQg6pSMiAmzSAor3 UaBxUefaTKV30aJJ61bW6y9Oo1+gqIeWouXS5wbt2UfCq2o1B/oC82+ztF+hGte0EpVH v7Ild7nwVOBgzHXpVs0Qh8h5r5o+RAnfRWd0s= MIME-Version: 1.0 Received: by 10.223.123.129 with SMTP id p1mr894388far.0.1242222678218; Wed, 13 May 2009 06:51:18 -0700 (PDT) Date: Wed, 13 May 2009 09:51:18 -0400 Message-ID: From: George Tsirtsis To: Michael Eriksson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: [MEXT] Binary Filters and the nature of MIP Re: binary filters draft 0 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, 13 May 2009 13:49:50 -0000 Michael, Trying to navigate through this thread, on one handle I am puzzled by the PRI discussion so I am going to ignore it for now, but on the other hand I now realize a fundamental issue which possibly causes the difference of opinion on the subject. You seem to think of MIP and even of Connectivity Managers as a high level applications that live at user level. This viewpoint alone pretty much defines your opinion. It is of course true that a lot of public and research-type implementations of such functions are at user level, possibly using high level programming languages. In the real commercial world, however, things are much different. To put any of this in a real world wireless, highly integrated device (think of iPhones, BBerrys, other smart phones and even netbooks etc) Connectivity Managers and Mobile IP will be highly optimized, low level application in C or even in Assembly. MIPv4 has been integrated in phones by Nextel as part of the Direct Connect system, and I have personally been involved in one assembly implementation of Mobile IP during my Flarion years, and am now involved with another such low level implementation in my current company. I hope this helps you understand where I (and probably others) come from when they are interested in binary filter rules, and why I keep saying that it is fine to have text filters too if people really want them but they cannot possibly be the default format. George On Wed, May 13, 2009 at 8:46 AM, Julien Laganier wrote: > Michael, > > On Wednesday 13 May 2009, Michael Eriksson wrote: >> [...] >> You are mixing up: > > OTOH, I have the impression that you are mixing things up quite a bit > here. See below - > >> 1. Determining the order of the rules. This is done at the MN, and is >> =C2=A0 =C2=A0independent of the how the rules are expressed (binary or t= ext). >> =C2=A0 =C2=A0Determining whether the rules overlap or not is not necessa= ry, as >> =C2=A0 =C2=A0long as you sort them in priority order. >> >> 2. Transfering the ORDERED list of rules from the MN to the HA. This >> =C2=A0 =C2=A0is where there is a difference between the text rules and b= inary >> =C2=A0 =C2=A0rules transferred in the flow-binding format. >> >> =C2=A0 =C2=A0- For the text format, this is trivial: Just append them in= order. > > Exactly the same can be done with the binary format: Just append them in > order in a single BU. > > Defining a priority field is an optimization that allows not sending the > full ruleset in each BU, thus making it possible to order rules that > were sent in different BUs. You would need exactly the same for your > text format were you going to provide the same optimization. > >> =C2=A0 =C2=A0- For the binary format, you have two choices: >> >> =C2=A0 =C2=A0 =C2=A0- Send them unordered (FID-PRI=3D0). Not a good idea= , since it is >> =C2=A0 =C2=A0 =C2=A0 =C2=A0most likely that the wrong rule will match so= me flows. >> >> =C2=A0 =C2=A0 =C2=A0- Enumerate the rules by using the FID-PRI field as = a rule >> =C2=A0 =C2=A0 =C2=A0 =C2=A0numerator (hence my BASIC remark). >> >> =C2=A0 =C2=A0 =C2=A0In practice, you will always have to enumerate the r= ules with >> the FID-PRI field. This is not very elegant, and adds complexity. For >> instance, the rules would have to be sorted according to their >> FID-PRI value after reception, while in the text format they always >> arrives in correct order. > > See above the point that FID-PRI is required only because there's the > optimization of sending the full ruleset in each BU. > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From mer@kafka.verkstad.net Wed May 13 06:51: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 4E6B43A6DB0 for ; Wed, 13 May 2009 06:51:41 -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 bJtXJK-uTh7y for ; Wed, 13 May 2009 06:51:40 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id C08A828C1E5 for ; Wed, 13 May 2009 06:51:06 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id B6658710B81; Wed, 13 May 2009 15:52:37 +0200 (CEST) Date: Wed, 13 May 2009 15:52:37 +0200 From: Michael Eriksson To: "Giaretta, Gerardo" Message-ID: <20090513135237.GA2493@kafka.verkstad.net> References: <200905111412.26321.julien.laganier.IETF@googlemail.com> <20090511185424.GA2445@kafka.verkstad.net> <200905121505.39235.julien.laganier.IETF@googlemail.com> <20090513093156.GA3476@kafka.verkstad.net> <057632CE4CE10D45A1A3D6D19206C3A3EBD82729@NASANEXMB08.na.qualcomm.com> <20090513115318.GA10312@kafka.verkstad.net> <057632CE4CE10D45A1A3D6D19206C3A3EBD8272C@NASANEXMB08.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3EBD8272C@NASANEXMB08.na.qualcomm.com> Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 13:51:41 -0000 On Wed, May 13, 2009 at 04:55:32 -0700, Giaretta, Gerardo wrote: > > It is of course an advantage that the same format is used by the > > connection manager as in the MIP protocol. The connection manager will > > create an array of bytes (the flow rules in ASCII format). All that > > the MIP daemon needs to do is to put an MH transport header on this > > byte array and send it to the HA. > > > > The MIP daemon does not need to do complex binary packing of invidual > > rules, it will just transfer a byte vector. Trivial to implement! > > You are assuming an API which is not standardized so I could claim > that other systems use different encoding in the internal > communication. By using a text format, you have the /possibility/ to have the same format between the connection manager and the MIP daemon as in the MIP signaling. This makes simple but powerful implementations possible, but you are of course free to use any API you want between the connection manager and the MIP daemon. I still think that it is elegant and a relevant advantage that the rules are expressed in a "high level" text language that is easy for the connection manager to generate, and that the MIP daemon only have to do very little to transfer the rules to the MN. > I don't think this should be consider as a differentiating point > between the solutions as this is clearly not generic enough and only > based on your personal assumptions. I can't see how my "personal assumptions" comes into this. I only show that a text format can nicely tie together a connection manager with MIP (or any other mobility mechanism). Regards, Michael From Hannes.Tschofenig@gmx.net Wed May 13 07:01: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 DA1E43A67A6 for ; Wed, 13 May 2009 07:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 zXPO2FU8rcMy for ; Wed, 13 May 2009 07:01:22 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 78C7D3A68FE for ; Wed, 13 May 2009 07:01:21 -0700 (PDT) Received: (qmail invoked by alias); 13 May 2009 14:02:52 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp071) with SMTP; 13 May 2009 16:02:52 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+EZBsjWy+EAO5Phcs9Z+0IVVOIcK8inLP0QdeGnV UBHevwAHMq+gPA From: "Hannes Tschofenig" To: "'George Tsirtsis'" , "'Michael Eriksson'" References: Date: Wed, 13 May 2009 17:04:30 +0300 Message-ID: <00b601c9d3d3$bd8eeab0$3143a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnT0ef1FgWC1i8ZShSyGEgbFp6JkAAAVa/Q X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: mext@ietf.org Subject: Re: [MEXT] Binary Filters and the nature of MIP Re: binary filtersdraft 0 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, 13 May 2009 14:01:23 -0000 I would like to remind that the representation on the wire has very = little todo with the internal implementations of all sorts of filters.=20 Packet filter implementations are very likely to use an virtual machine alike syntax. A more classical example can be found with the BPF packet filter: http://download.at.kde.org/pub/tcpdump/papers/bpf-usenix93.pdf Ciao Hannes >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 >Behalf Of George Tsirtsis >Sent: 13 May, 2009 16:51 >To: Michael Eriksson >Cc: mext@ietf.org >Subject: [MEXT] Binary Filters and the nature of MIP Re:=20 >binary filtersdraft 0 > >Michael, > >Trying to navigate through this thread, on one handle I am=20 >puzzled by the PRI discussion so I am going to ignore it for=20 >now, but on the other hand I now realize a fundamental issue=20 >which possibly causes the difference of opinion on the subject. > >You seem to think of MIP and even of Connectivity Managers as=20 >a high level applications that live at user level. This=20 >viewpoint alone pretty much defines your opinion. It is of=20 >course true that a lot of public and research-type=20 >implementations of such functions are at user level, possibly=20 >using high level programming languages. > >In the real commercial world, however, things are much=20 >different. To put any of this in a real world wireless, highly=20 >integrated device (think of iPhones, BBerrys, other smart=20 >phones and even netbooks etc) Connectivity Managers and Mobile=20 >IP will be highly optimized, low level application in C or=20 >even in Assembly. MIPv4 has been integrated in phones by=20 >Nextel as part of the Direct Connect system, and I have=20 >personally been involved in one assembly implementation of=20 >Mobile IP during my Flarion years, and am now involved with=20 >another such low level implementation in my current company. > >I hope this helps you understand where I (and probably others)=20 >come from when they are interested in binary filter rules, and=20 >why I keep saying that it is fine to have text filters too if=20 >people really want them but they cannot possibly be the default format. > >George > >On Wed, May 13, 2009 at 8:46 AM, Julien Laganier=20 > wrote: >> Michael, >> >> On Wednesday 13 May 2009, Michael Eriksson wrote: >>> [...] >>> You are mixing up: >> >> OTOH, I have the impression that you are mixing things up=20 >quite a bit=20 >> here. See below - >> >>> 1. Determining the order of the rules. This is done at the=20 >MN, and is >>> =A0 =A0independent of the how the rules are expressed (binary or = text). >>> =A0 =A0Determining whether the rules overlap or not is not = necessary, as >>> =A0 =A0long as you sort them in priority order. >>> >>> 2. Transfering the ORDERED list of rules from the MN to the HA. This >>> =A0 =A0is where there is a difference between the text rules and = binary >>> =A0 =A0rules transferred in the flow-binding format. >>> >>> =A0 =A0- For the text format, this is trivial: Just append them=20 >in order. >> >> Exactly the same can be done with the binary format: Just=20 >append them=20 >> in order in a single BU. >> >> Defining a priority field is an optimization that allows not sending=20 >> the full ruleset in each BU, thus making it possible to order rules=20 >> that were sent in different BUs. You would need exactly the same for=20 >> your text format were you going to provide the same optimization. >> >>> =A0 =A0- For the binary format, you have two choices: >>> >>> =A0 =A0 =A0- Send them unordered (FID-PRI=3D0). Not a good idea, = since it is >>> =A0 =A0 =A0 =A0most likely that the wrong rule will match some = flows. >>> >>> =A0 =A0 =A0- Enumerate the rules by using the FID-PRI field as a = rule >>> =A0 =A0 =A0 =A0numerator (hence my BASIC remark). >>> >>> =A0 =A0 =A0In practice, you will always have to enumerate the rules = with=20 >>> the FID-PRI field. This is not very elegant, and adds=20 >complexity. For=20 >>> instance, the rules would have to be sorted according to their=20 >>> FID-PRI value after reception, while in the text format they always=20 >>> arrives in correct order. >> >> See above the point that FID-PRI is required only because=20 >there's the=20 >> optimization of sending the full ruleset in each BU. >> >> --julien >> _______________________________________________ >> 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 Wed May 13 07:03: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 8003C3A68FE for ; Wed, 13 May 2009 07:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[AWL=0.160, 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 ka5TEydtuqXl for ; Wed, 13 May 2009 07:03:49 -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 1D4F23A67B5 for ; Wed, 13 May 2009 07:03:48 -0700 (PDT) Received: by bwz22 with SMTP id 22so667017bwz.37 for ; Wed, 13 May 2009 07:05:19 -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=f014dNflkwMdpGR53Wvo1WlOxFfqHJGBDakREglJ2Xs=; b=avxsl2xcy3D2pmVh3YunxuzYbGgrSJ1g7X8gPjiLyxngEBrju0NpXEjbK+hKCvvGqw SgDMc7ffy+EY9bH1gd5X/kMbTv4Wgy+dqNMCoJZYwvhwf+L0OpDY7Kkx34IgfO5KAvYY 6AgYJ2yGrc6olRNu/wxihstr9eVI7ZLfrD9Rk= 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=UwO9/pSOsJ5YVrDZ2KDrFx9/8Y0bg0uQG4kky7feEGSflA1jwpsZDzvz66Vwn854yi KMmkwpNHijSELl7rBBv8akr5DDyx5bLOjXnYQl39s+L4KWfhV3Kogmm7Il+ZDEITMxkb rZoio1U0Ntmwj+zaE1/Mq6XNDiF21+hyHX8e4= MIME-Version: 1.0 Received: by 10.223.114.135 with SMTP id e7mr836125faq.89.1242223519234; Wed, 13 May 2009 07:05:19 -0700 (PDT) In-Reply-To: <00b601c9d3d3$bd8eeab0$3143a20a@nsnintra.net> References: <00b601c9d3d3$bd8eeab0$3143a20a@nsnintra.net> Date: Wed, 13 May 2009 10:05:19 -0400 Message-ID: From: George Tsirtsis To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Michael Eriksson , mext@ietf.org Subject: Re: [MEXT] Binary Filters and the nature of MIP Re: binary filtersdraft 0 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, 13 May 2009 14:03:50 -0000 Hannes, Just to make sure I am not missing your point this is an argument for the fact that one can do text based filters at user API level but still send them binary over the air, right? George On Wed, May 13, 2009 at 10:04 AM, Hannes Tschofenig wrote: > I would like to remind that the representation on the wire has very littl= e > todo with the internal implementations of all sorts of filters. > > Packet filter implementations are very likely to use an virtual machine > alike syntax. A more classical example can be found with the BPF packet > filter: > http://download.at.kde.org/pub/tcpdump/papers/bpf-usenix93.pdf > > Ciao > Hannes > > >>-----Original Message----- >>From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>Behalf Of George Tsirtsis >>Sent: 13 May, 2009 16:51 >>To: Michael Eriksson >>Cc: mext@ietf.org >>Subject: [MEXT] Binary Filters and the nature of MIP Re: >>binary filtersdraft 0 >> >>Michael, >> >>Trying to navigate through this thread, on one handle I am >>puzzled by the PRI discussion so I am going to ignore it for >>now, but on the other hand I now realize a fundamental issue >>which possibly causes the difference of opinion on the subject. >> >>You seem to think of MIP and even of Connectivity Managers as >>a high level applications that live at user level. This >>viewpoint alone pretty much defines your opinion. It is of >>course true that a lot of public and research-type >>implementations of such functions are at user level, possibly >>using high level programming languages. >> >>In the real commercial world, however, things are much >>different. To put any of this in a real world wireless, highly >>integrated device (think of iPhones, BBerrys, other smart >>phones and even netbooks etc) Connectivity Managers and Mobile >>IP will be highly optimized, low level application in C or >>even in Assembly. MIPv4 has been integrated in phones =C2=A0by >>Nextel as part of the Direct Connect system, and I have >>personally been involved in one assembly implementation of >>Mobile IP during my Flarion years, and am now involved with >>another such low level implementation in my current company. >> >>I hope this helps you understand where I (and probably others) >>come from when they are interested in binary filter rules, and >>why I keep saying that it is fine to have text filters too if >>people really want them but they cannot possibly be the default format. >> >>George >> >>On Wed, May 13, 2009 at 8:46 AM, Julien Laganier >> wrote: >>> Michael, >>> >>> On Wednesday 13 May 2009, Michael Eriksson wrote: >>>> [...] >>>> You are mixing up: >>> >>> OTOH, I have the impression that you are mixing things up >>quite a bit >>> here. See below - >>> >>>> 1. Determining the order of the rules. This is done at the >>MN, and is >>>> =C2=A0 =C2=A0independent of the how the rules are expressed (binary or= text). >>>> =C2=A0 =C2=A0Determining whether the rules overlap or not is not neces= sary, as >>>> =C2=A0 =C2=A0long as you sort them in priority order. >>>> >>>> 2. Transfering the ORDERED list of rules from the MN to the HA. This >>>> =C2=A0 =C2=A0is where there is a difference between the text rules and= binary >>>> =C2=A0 =C2=A0rules transferred in the flow-binding format. >>>> >>>> =C2=A0 =C2=A0- For the text format, this is trivial: Just append them >>in order. >>> >>> Exactly the same can be done with the binary format: Just >>append them >>> in order in a single BU. >>> >>> Defining a priority field is an optimization that allows not sending >>> the full ruleset in each BU, thus making it possible to order rules >>> that were sent in different BUs. You would need exactly the same for >>> your text format were you going to provide the same optimization. >>> >>>> =C2=A0 =C2=A0- For the binary format, you have two choices: >>>> >>>> =C2=A0 =C2=A0 =C2=A0- Send them unordered (FID-PRI=3D0). Not a good id= ea, since it is >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0most likely that the wrong rule will match = some flows. >>>> >>>> =C2=A0 =C2=A0 =C2=A0- Enumerate the rules by using the FID-PRI field a= s a rule >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0numerator (hence my BASIC remark). >>>> >>>> =C2=A0 =C2=A0 =C2=A0In practice, you will always have to enumerate the= rules with >>>> the FID-PRI field. This is not very elegant, and adds >>complexity. For >>>> instance, the rules would have to be sorted according to their >>>> FID-PRI value after reception, while in the text format they always >>>> arrives in correct order. >>> >>> See above the point that FID-PRI is required only because >>there's the >>> optimization of sending the full ruleset in each BU. >>> >>> --julien >>> _______________________________________________ >>> 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 mer@kafka.verkstad.net Wed May 13 07:41: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 0F20D3A6B2A for ; Wed, 13 May 2009 07:41:44 -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 O6AJUl4Gp++o for ; Wed, 13 May 2009 07:41:43 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id A507D3A68B6 for ; Wed, 13 May 2009 07:41:42 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 0F828710B81; Wed, 13 May 2009 16:43:14 +0200 (CEST) Date: Wed, 13 May 2009 16:43:14 +0200 From: Michael Eriksson To: Julien Laganier Message-ID: <20090513144314.GA21117@kafka.verkstad.net> References: <200905121505.39235.julien.laganier.IETF@googlemail.com> <20090513093156.GA3476@kafka.verkstad.net> <200905131434.30760.julien.laganier.IETF@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905131434.30760.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 14:41:44 -0000 On Wed, May 13, 2009 at 14:34:30 +0200, Julien Laganier wrote: > On Wednesday 13 May 2009, Michael Eriksson wrote: > > With "simple" I don't mean "more efficient", I mean that it is better > > (easier) when developing, debugging and maintaining the system. > > FWIW I don't think it would be reasonable to run in a production > environment code written by someone who doesn't know how to code a > byte-and-bit parser :-) I, on the other hand, don't think it would be reasonable to run in a production environment code written by someone who only knows how to code a byte-and-bit parser :-) > > In my view, dynamic flow rules will not be generated by the "MIP > > stack" itself. They will be determined by a higher level function, > > e.g, a connection manager. The connection manager shouldn't even have > > to care about what mobility solution is used (MIPv6, shim6, MOBIKE, > > ...). One of the ideas and explicit goals with our text-based rule > > language is that it is mobility mechanism agnostic. > > You can very well have a mobility protocol agnostic language to describe > you rules in your implementation. > > What we're talking about here is how the rules are transmitted by MIPv6, > not how they are transmitted by the Agnostic Protocol. But then you would have to translate the rules from text to a binary format before transmission. Are the few saved bits (if any) really worth the cost in added complexity? Have you done any ballbark calculations: How many bytes would a binary format really save? How many percents of the available bandwidth? > > > I do no think a network layer stack implementation is the place to > > > implement formal grammars, parse and validate regular expressions. > > > > Why not? Because it is not "efficient" enough? Please note that most > > (all?) MIP signaling implementations are user space programs, and are > > not involved in packet forwarding. > > Why? > > Because that's how things are done. What I recommend is that you find > out 1) what is most deployed network layer protocol, and 2) which > encodings its use. That was one of the weakest arguments I have ever heard! :-) (sorry) Unfortunately, it is all too common. How could we possibly advance out of the 1970's if everybody argued like that? > > Also, see my comment above regarding that the rules will not be > > generated by the "MIP stack" itself. > > That's internal to your implementation. I am talking about > bits-on-the-wire. See my reply to Gerardo on why it is nice to use a rule format suitable for the connection manager all the way to the HA. > > In this regard, the text format has two advantages: > > > > 1. The rule order is well defined. > > Same can be done with a binary format. Order of IPsec TS in IKE is well > defined. I agree, but as I said before: Your are guilty by association with the flow-binding draft, since that is what your binary format targets. When you define a better transport format (please, please, please do that!), I will disregard this argument. > > 2. The action to be taken at a rule match is given inline. > > Same can be done with a binary format. > > > Thus, rules in the text format are completely self contained. > > Same can be done with a binary format. I agree again. Please, please, please design a better transport format where this would fit! > > OK. I will just note that you will need yet another tool. > > Exactly as you need another tool to crunch, resolve, save, edit your > text rules! Oh, you mean Emacs. Fortunately, rms developed that already in the 80's :-). > MH is not a transport protocol. It is a network layer mobility (or > routing) protocol. We can argue about that, but I don't think it is important. The thing is that it is not used to transfer user data, and thus it is a suboptimization to compress out the last bit at the cost of added complexity. > > > control plane, application... what are talking about? > > > > Other architectures (GSM/3GPP for instance) separates user data from > > control data in different vertical planes, the user plane and the > > control plane. In such an architecture, MH and rule exchange would be > > control plane protocols. > > Thanks for explaining the difference b/w user plane and control plane, I > am sure this will be useful to many of us. Well, you did ask! > As you're mentionning 3GPP I will simply note that the control plane for > the network mobility core (GTP-C) does not use text encoding. It uses > binary, because it is network layer control protocols. See my comment above about weak arguments :-). I am trying to teach my kids that "everybody else does that" is not a good excuse for bad behavior... > > What I am really after is that exchanging rules isn't a network layer > > function, it is a control function. Thus the balance between > > compressing away the last bit and other aspects changes, compared to > > a (user plane) network layer protocol. > > Exchanging mobility routing rules is both a control and a network > protocol thus I do not know what you're after. Again: I am after that it is more important to be bit efficient for "user traffic", of which there is a lot. For control traffic, it is not very important. Reduced complexity is much more important. Regards, Michael From behcetsarikaya@yahoo.com Wed May 13 07:49: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 EEC953A6D5D for ; Wed, 13 May 2009 07:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, 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 RNWAVqhuKoTe for ; Wed, 13 May 2009 07:49:11 -0700 (PDT) Received: from n76.bullet.mail.sp1.yahoo.com (n76.bullet.mail.sp1.yahoo.com [98.136.44.48]) by core3.amsl.com (Postfix) with SMTP id 0CE0F3A6E98 for ; Wed, 13 May 2009 07:49:11 -0700 (PDT) Received: from [216.252.122.217] by n76.bullet.mail.sp1.yahoo.com with NNFMP; 13 May 2009 14:50:41 -0000 Received: from [67.195.9.81] by t2.bullet.sp1.yahoo.com with NNFMP; 13 May 2009 14:50:41 -0000 Received: from [67.195.9.108] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 13 May 2009 14:50:41 -0000 Received: from [127.0.0.1] by omp112.mail.gq1.yahoo.com with NNFMP; 13 May 2009 14:50:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 687192.86201.bm@omp112.mail.gq1.yahoo.com Received: (qmail 87777 invoked by uid 60001); 13 May 2009 14:50:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242226241; bh=qMR4RZTMXhyuL4oztxrwGY0D1HItNhlirH17ZmEwi4g=; 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=CaGyrgHmGwELwc6i8xKOuXm3VktcLOZ+dLyb6qK3s2Ji3pNZmOqNbCBpVqZT5K9ahFCVAbCU6RO6lPc4uhz3hhEFc+qOXMEAv8N/BRftYPkukAvV4eudgoIRej0hPUqeY/J4hV/pAyhN+hp+/wh7FgYGAUOwaGsrcyB3xXUPnsE= 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=zX7kVbIQRFK27nRXPsJChYub7NvEF5Fs/JqlJhCHjQ1q4Lj3DNrMzVSS8JIVR8RTHXijGs8zBs4HTl+aIX8I/sz7+kNKzMvHDf9etvMblxF1cF2jzDkz+ikHudx0TjYsFjG2Snj/CfzYgCgjVCP75v1mWUcNAg8KUY5IwqZEpRg=; Message-ID: <500466.87600.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: HXbJo8UVM1kgamXQ6Eo6PWab.hNizxNQMkRWDaC04lfa6z.R528_NFY0Q5tX9SM8lpHFT0jLLF3GZ8LMGKr8ejfZQSV8eXvNg1Cw_5zvRE4RJivmgDRv2YoY75SaAt3d6KeXgfpxQFp9ji5z5f1yTeYuAgrxx73Dq8f6SXpLdO4DDlrdwYkPJgzFHHBRV0FuYRcEGt8yXMNAh3bOcdoKOtxK4RJiwbX7E0xcw7f2GT2WjVWklaVJ2ooLwhNfL_KsIF1HmNwFo_nfLtaMrJ7TyUjAmygDYhmz9Wp854.H5xftwPApodkPmlg4xZ9BXgLOOzXwJ4_A8BA- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Wed, 13 May 2009 07:50:41 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <20090512061528.GB8612@kafka.verkstad.net> <20090513095906.GB3476@kafka.verkstad.net> Date: Wed, 13 May 2009 07:50:41 -0700 (PDT) From: Behcet Sarikaya To: Michael Eriksson , Hesham Soliman In-Reply-To: <20090513095906.GB3476@kafka.verkstad.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2105691940-1242226241=:87600" Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 14:49:12 -0000 --0-2105691940-1242226241=:87600 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=0A=A0 I have the same concern as Michael nicely stated below.=0AI w= as reading draft-ietf-monami6-mipv6-analysis which provides the basis for a= ll this work. It dates back 2005 or even before. Maybe at that time multiho= ming was understood as a laptop with two PCMCIA cards. =0A=A0 Can we say th= e same now in view of new user devices that come with several wireless inte= rfaces including Wi-Fi? Can we treat Wi-Fi the same as a cellular interface= ? =0A=A0 We have now a mif WG which is going to study what is available in = the current OSes before doing any protocol development.=0A=A0 Also I don't = understand the relationship between this discussion and IKE traffic selecto= rs. IKE is basically Diffie-Hellman protocol and I am not sure if my IPhone= uses it?=0A=A0 =0A=A0 My suggestion is to have a new overall look at this = problem that mext inherited, maybe discuss it in IETF-75 in hopes of a refo= rmulation before moving ahead with the current draft.=0A=0ARegards,=0A=0ABe= hcet=A0=0A=0A=0A=0A________________________________=0AFrom: Michael Eriksso= n =0ATo: Hesham Soliman =0ACc: mext@ietf.org=0ASent: Wednesday, May 13, 2009 4:59:07 AM=0ASub= ject: Re: [MEXT] offline Re: binary filters draft 0=0A=0A=0ADiscussing new = ideas and solutions with people who have already made=0Aup there minds (sin= ce years back) is not very fruitful.=0A=0A=0A --0-2105691940-1242226241=:87600 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=0A
  I have the same concern as= Michael nicely stated below.
=0A
I was reading draft-ietf-monami6= -mipv6-analysis which provides the basis for all this work. It dates back 2= 005 or even before. Maybe at that time multihoming was understood as a lapt= op with two PCMCIA cards.
=0A
  Can we say the same now in v= iew of new user devices that come with several wireless interfaces includin= g Wi-Fi? Can we treat Wi-Fi the same as a cellular interface?
=0A  We have now a mif WG which is going to study what is available in t= he current OSes before doing any protocol development.
=0A
  = Also I don't understand the relationship between this discussion and IKE tr= affic selectors. IKE is basically Diffie-Hellman protocol and I am not sure= if my IPhone uses it?
=0A
 
=0A
  My suggesti= on is to have a new overall look at this problem that mext inherited, maybe= discuss it in IETF-75 in hopes of a reformulation before moving ahead with= the current draft.
=0A
 
=0A
Regards,
=0A
=  
=0A
Behcet 
=0A

=0A
=0A
=0AFrom: Michael Eriksson <michael.eriksson@ericsson.com>
To: Hesham Soliman <hesham@eleva= temobile.com>
Cc: mex= t@ietf.org
Sent: Wednesd= ay, May 13, 2009 4:59:07 AM
Subject= : Re: [MEXT] offline Re: binary filters draft 0

Discussing new ideas and solutions with people who have already made
u= p there minds (since years back) is not very fruitful.

<= /div>
=0A=0A --0-2105691940-1242226241=:87600-- From mer@kafka.verkstad.net Wed May 13 07:59: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 34D453A65A5 for ; Wed, 13 May 2009 07:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 4JmEbZuAbXl9 for ; Wed, 13 May 2009 07:59:33 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 458C93A67A7 for ; Wed, 13 May 2009 07:59:33 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 3A304710B81; Wed, 13 May 2009 17:01:05 +0200 (CEST) Date: Wed, 13 May 2009 17:01:05 +0200 From: Michael Eriksson To: George Tsirtsis Message-ID: <20090513150105.GB21117@kafka.verkstad.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] Binary Filters and the nature of MIP Re: binary filters draft 0 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, 13 May 2009 14:59:34 -0000 On Wed, May 13, 2009 at 09:51:18 -0400, George Tsirtsis wrote: > You seem to think of MIP and even of Connectivity Managers as a high > level applications that live at user level. This viewpoint alone > pretty much defines your opinion. It is of course true that a lot of > public and research-type implementations of such functions are at user > level, possibly using high level programming languages. > > In the real commercial world, however, things are much different. To > put any of this in a real world wireless, highly integrated device > (think of iPhones, BBerrys, other smart phones and even netbooks etc) > Connectivity Managers and Mobile IP will be highly optimized, low > level application in C or even in Assembly. MIPv4 has been integrated > in phones by Nextel as part of the Direct Connect system, and I have > personally been involved in one assembly implementation of Mobile IP > during my Flarion years, and am now involved with another such low > level implementation in my current company. > > I hope this helps you understand where I (and probably others) come > from when they are interested in binary filter rules, and why I keep > saying that it is fine to have text filters too if people really want > them but they cannot possibly be the default format. At last some reasonable arguments! As I have written before, I could live with binary rules. I just want people to understand that a text-based rule language does have its advantages. Some random thoughts: - I think that we must lift ourselves from native and portable assembler (aka C). As I wrote previously, the Android phone (very much a commercial product) is already doing all its logic in Java, which is a good start. I can understand that there are cost reduced products, where things have to be done in C. On the other hand, I think that only advanced terminals will do flow mobility, and they will/should have the power to use better programming languages. - I think that you are vastly overestimating the implementation cost of parsing a text rule format. Lex and yacc compiles a lexical scanner and a language grammar into C code, which can then be compiled and linked into the final program. My complete (nonoptimized) lex+yacc parser for the text format, as specified in draft-larsson, is a total of 268 non-empty lines of source code, which compile into a total of 10476 bytes of i386 object code. Sure you have room for that in your target devices? Regards, Michael From julien.laganier.ietf@googlemail.com Wed May 13 08:44: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 AA5703A6915 for ; Wed, 13 May 2009 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 SykkR9ZikyoO for ; Wed, 13 May 2009 08:44:11 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 703453A6971 for ; Wed, 13 May 2009 08:44:10 -0700 (PDT) Received: by fxm2 with SMTP id 2so734466fxm.37 for ; Wed, 13 May 2009 08:45:41 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=jmyyFq7tebWpg4r2HzFH7U7fasT6jh3IjQdi3ZGxzIc=; b=b1v4ky8L5GRUygzd+pHCU3NfJ/KBR7qUvBLjvgOlCEf7fuAoMlQQ0aRKBQyLmMxjyV j//olGwJuUWJoMwkIshx3Dj+bwrlKYqM3SzvvAKwpmmUbtGTTHTHhtPUBN5f6iUlvyRc ElJ7HU7Qk2f2xg5WA/fnrp/SLdwlSE8ZpBXS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=aZp4OfFrDpT97A5k4oN6XP+YTmMamyxUghhXkDfRENCfj9lxSkiMas2zX/vXk2/Na6 5P8Ks5TLr3X4djJcY3C4GXNgO4IJqPGR5YvXASFZsOHBt/BtoSWbAC9paNxwAcO+lWok Uw/7o/23o3Qj73hW+6j0FQTg1TkIrlRRYI7ys= Received: by 10.86.98.10 with SMTP id v10mr1391621fgb.36.1242229541626; Wed, 13 May 2009 08:45:41 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id e20sm3448479fga.15.2009.05.13.08.45.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 May 2009 08:45:41 -0700 (PDT) From: Julien Laganier To: Michael Eriksson Date: Wed, 13 May 2009 17:45:45 +0200 User-Agent: KMail/1.9.10 References: <200905131434.30760.julien.laganier.IETF@googlemail.com> <20090513144314.GA21117@kafka.verkstad.net> In-Reply-To: <20090513144314.GA21117@kafka.verkstad.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905131745.45256.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 15:44:12 -0000 On Wednesday 13 May 2009, Michael Eriksson wrote: > > > > In my view, dynamic flow rules will not be generated by the "MIP > > > stack" itself. They will be determined by a higher level > > > function, e.g, a connection manager. The connection manager > > > shouldn't even have to care about what mobility solution is used > > > (MIPv6, shim6, MOBIKE, ...). One of the ideas and explicit goals > > > with our text-based rule language is that it is mobility > > > mechanism agnostic. > > > > You can very well have a mobility protocol agnostic language to > > describe you rules in your implementation. > > > > What we're talking about here is how the rules are transmitted by > > MIPv6, not how they are transmitted by the Agnostic Protocol. > > But then you would have to translate the rules from text to a binary > format before transmission. Are the few saved bits (if any) really > worth the cost in added complexity? Since in order to match actual packets the MIPv6 stack will _anyway_ have to deal with binary representation of IP addresses, protocol numbers, flow labels, port numbers, ICMP types and codes, IPsec SPIs, you will have to pick these elements out of your text rules and translate them to binary _anyway_ thus I do not see where is the added complexity. And yes it saves bits. It's not because a resource is cheap that we should consume it without regards. For an illustration, see Fallacy #3 in . > Have you done any ballbark calculations: How many bytes would a > binary format really save? How many percents of the available > bandwidth? I do not have the charge of the proof since I propose to follow the current practice of using binary encoding for network layer protocols. You are on the other hand free to compute how much complexity is saved by translating text to binary in the MIPv6 stack (as pointed out above is implied by your proposal) rather than in your connexion manager (as I argue you could do if you really want a text based language). > > > > I do no think a network layer stack implementation is the place > > > > to implement formal grammars, parse and validate regular > > > > expressions. > > > > > > Why not? Because it is not "efficient" enough? Please note that > > > most (all?) MIP signaling implementations are user space > > > programs, and are not involved in packet forwarding. > > > > Why? > > > > Because that's how things are done. What I recommend is that you > > find out 1) what is most deployed network layer protocol, and 2) > > which encodings its use. > > That was one of the weakest arguments I have ever heard! :-) (sorry) > > Unfortunately, it is all too common. How could we possibly advance > out of the 1970's if everybody argued like that? Is this your argument? Mind you, many bright principles originates in the 70's and are still valid today. It's the right thing to do to follow past design principles unless better ones are found. So far you have not provided any valid evidence that motivate the need to use text encoding in a network layer protocol. You keep insisting on the "complexity" of "translat[ing] the rules from text to a binary format before transmission" while it is clear that, as soon as you introduce a text rule language, translating between binary and text is required to match actual packets no matter what rule encoding we choose for on-the-wire protocol encoding . Or do you think everybody will start encode packets following IPoXML [RFC3252] so that your MIPv6 stack can match packets using yacc and lex too, without translating text rules to binary at all?! I will not add any more "weak" arguments to this discussion as I believe you have used them all already. Thank you. --julien From hesham@elevatemobile.com Wed May 13 09:05: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 98BD13A6E0A for ; Wed, 13 May 2009 09:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 r2HMSHKjUFyg for ; Wed, 13 May 2009 09:05: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 B692D3A6DFF for ; Wed, 13 May 2009 09:05:32 -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 1M4Gyy-000054-V5; Thu, 14 May 2009 02:07:01 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 14 May 2009 02:06:54 +1000 From: Hesham Soliman To: Michael Eriksson Message-ID: Thread-Topic: [MEXT] new pad sub-option and flow identifier assignment Thread-Index: AcnT5NU4b288dq1mvkWujyY7mumB1w== In-Reply-To: <20090512084022.GB20880@kafka.verkstad.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 13 May 2009 16:05:34 -0000 > >> If you really understood the spec you would see that it's not >> possible for the HA to initiate a binding. Let alone being able to >> know what interfaces work on the MN. That's why I keep saying that >> the HA can send policies all day long to the MN, but in the end, the >> MN has to decide what instances it needs and install those on the >> HA's BC. Again, we had this discussion at least twice already in >> monami6. Just because the WG was merged doesn't mean the arguments >> should be forgotten. > > I actually happen to think that I understand the spec, thanks for your > warm consideration... > > It is correct that the CoA bindings are unidirectional. But the HA can > of course know what interfaces are working on the MN: It only has to > look in the binding cache! The MN will unregister any non-working CoA. => Oh of course if an entry is in the binding cache then the corresponding interface, base station, cell load, app preferences and end to end reachability must all be valid for the lifetime of the binding...makes perfect sense...These things just don't change once the CoA is in the binding cache. Of course the binding cache also includes the corresponding link layer properties associated with the CoA, which also never change. The all-knowing omnipresent HA can then direct traffic as it sees fit. Hesham > > > Regards, > Michael From Hannes.Tschofenig@gmx.net Wed May 13 09:37: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 959AF3A6BC1 for ; Wed, 13 May 2009 09:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, 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 I0zrX3trAm-5 for ; Wed, 13 May 2009 09:37:17 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E80C13A6906 for ; Wed, 13 May 2009 09:37:16 -0700 (PDT) Received: (qmail invoked by alias); 13 May 2009 16:38:46 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp036) with SMTP; 13 May 2009 18:38:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/V3vAh7VzV8uUbm40/k8JfqWIX6udgYoIsTDJ+g7 v+V88SddKU53bI From: "Hannes Tschofenig" To: "'George Tsirtsis'" References: <00b601c9d3d3$bd8eeab0$3143a20a@nsnintra.net> Date: Wed, 13 May 2009 19:40:26 +0300 Message-ID: <00cf01c9d3e9$854b11e0$3143a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnT09moslggqMltSjGSQwgQyPSYfAAEvNzQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: 'Michael Eriksson' , mext@ietf.org Subject: Re: [MEXT] Binary Filters and the nature of MIP Re: binary filtersdraft 0 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, 13 May 2009 16:37:18 -0000 Sorry to be unclear.=20 There are two aspects:=20 1) How do you encode filters on the wire, i.e., when carried in your favorite mobility protocol (or other protocol; does not really matter = that much). 2) How are these filters implemented in a particular node?=20 Now, for item (2) folks have come up with quite sophisticated mechanisms (typically dedicated languages that have an assembler like syntax) over = time that are (a) highly efficient and (b) quite compact in the encoding. I provide a reference to the BSD packet filter system but the work = obviously did not stop in 1992.=20 Now, ideally you would want to select a format for (1) that allows easy conversion to the format used with (2). The problem now is that different implementations use different = languages. So, it is quite likely that you will have to convert the stuff you get = via (1) anyway to (2).=20 So, my conclusion is that the format for (1) does not really matter = unless you get to pick a format that is extremely close or equal to the format = used by (2) for most of the implementations.=20 This only matters if the translation from (1) to (2) is performance-wise = an issue. I am not sure it really is and in that case you could as well = toss a coin since it does not matter at all for the format for (1) is.=20 Does this description make any sense?=20 Ciao Hannes PS: Whatever you do it would be nice to have a reference library at the = end that folks could use in their implementation.=20 >-----Original Message----- >From: George Tsirtsis [mailto:tsirtsis@googlemail.com]=20 >Sent: 13 May, 2009 17:05 >To: Hannes Tschofenig >Cc: Michael Eriksson; mext@ietf.org >Subject: Re: [MEXT] Binary Filters and the nature of MIP Re:=20 >binary filtersdraft 0 > >Hannes, > >Just to make sure I am not missing your point this is an=20 >argument for the fact that one can do text based filters at=20 >user API level but still send them binary over the air, right? > >George > >On Wed, May 13, 2009 at 10:04 AM, Hannes Tschofenig=20 > wrote: >> I would like to remind that the representation on the wire has very=20 >> little todo with the internal implementations of all sorts=20 >of filters. >> >> Packet filter implementations are very likely to use an virtual=20 >> machine alike syntax. A more classical example can be found with the=20 >> BPF packet >> filter: >> http://download.at.kde.org/pub/tcpdump/papers/bpf-usenix93.pdf >> >> Ciao >> Hannes >> >> >>>-----Original Message----- >>>From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf=20 >>>Of George Tsirtsis >>>Sent: 13 May, 2009 16:51 >>>To: Michael Eriksson >>>Cc: mext@ietf.org >>>Subject: [MEXT] Binary Filters and the nature of MIP Re: >>>binary filtersdraft 0 >>> >>>Michael, >>> >>>Trying to navigate through this thread, on one handle I am=20 >puzzled by=20 >>>the PRI discussion so I am going to ignore it for now, but on the=20 >>>other hand I now realize a fundamental issue which possibly=20 >causes the=20 >>>difference of opinion on the subject. >>> >>>You seem to think of MIP and even of Connectivity Managers as a high=20 >>>level applications that live at user level. This viewpoint alone=20 >>>pretty much defines your opinion. It is of course true that a lot of=20 >>>public and research-type implementations of such functions=20 >are at user=20 >>>level, possibly using high level programming languages. >>> >>>In the real commercial world, however, things are much different. To=20 >>>put any of this in a real world wireless, highly integrated device=20 >>>(think of iPhones, BBerrys, other smart phones and even=20 >netbooks etc)=20 >>>Connectivity Managers and Mobile IP will be highly optimized, low=20 >>>level application in C or even in Assembly. MIPv4 has been=20 >integrated=20 >>>in phones =A0by Nextel as part of the Direct Connect system,=20 >and I have=20 >>>personally been involved in one assembly implementation of Mobile IP=20 >>>during my Flarion years, and am now involved with another such low=20 >>>level implementation in my current company. >>> >>>I hope this helps you understand where I (and probably others) come=20 >>>from when they are interested in binary filter rules, and why I keep=20 >>>saying that it is fine to have text filters too if people=20 >really want=20 >>>them but they cannot possibly be the default format. >>> >>>George >>> >>>On Wed, May 13, 2009 at 8:46 AM, Julien Laganier=20 >>> wrote: >>>> Michael, >>>> >>>> On Wednesday 13 May 2009, Michael Eriksson wrote: >>>>> [...] >>>>> You are mixing up: >>>> >>>> OTOH, I have the impression that you are mixing things up >>>quite a bit >>>> here. See below - >>>> >>>>> 1. Determining the order of the rules. This is done at the >>>MN, and is >>>>> =A0 =A0independent of the how the rules are expressed (binary=20 >or text). >>>>> =A0 =A0Determining whether the rules overlap or not is not = necessary,=20 >>>>> as >>>>> =A0 =A0long as you sort them in priority order. >>>>> >>>>> 2. Transfering the ORDERED list of rules from the MN to the HA.=20 >>>>> This >>>>> =A0 =A0is where there is a difference between the text rules=20 >and binary >>>>> =A0 =A0rules transferred in the flow-binding format. >>>>> >>>>> =A0 =A0- For the text format, this is trivial: Just append them >>>in order. >>>> >>>> Exactly the same can be done with the binary format: Just >>>append them >>>> in order in a single BU. >>>> >>>> Defining a priority field is an optimization that allows=20 >not sending=20 >>>> the full ruleset in each BU, thus making it possible to=20 >order rules=20 >>>> that were sent in different BUs. You would need exactly=20 >the same for=20 >>>> your text format were you going to provide the same optimization. >>>> >>>>> =A0 =A0- For the binary format, you have two choices: >>>>> >>>>> =A0 =A0 =A0- Send them unordered (FID-PRI=3D0). Not a good idea, = since it=20 >>>>> is >>>>> =A0 =A0 =A0 =A0most likely that the wrong rule will match some = flows. >>>>> >>>>> =A0 =A0 =A0- Enumerate the rules by using the FID-PRI field as a = rule >>>>> =A0 =A0 =A0 =A0numerator (hence my BASIC remark). >>>>> >>>>> =A0 =A0 =A0In practice, you will always have to enumerate the=20 >rules with=20 >>>>> the FID-PRI field. This is not very elegant, and adds >>>complexity. For >>>>> instance, the rules would have to be sorted according to their=20 >>>>> FID-PRI value after reception, while in the text format=20 >they always=20 >>>>> arrives in correct order. >>>> >>>> See above the point that FID-PRI is required only because >>>there's the >>>> optimization of sending the full ruleset in each BU. >>>> >>>> --julien >>>> _______________________________________________ >>>> 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 mer@kafka.verkstad.net Wed May 13 13:00: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 C934F28C208 for ; Wed, 13 May 2009 13:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 x0RGOH7YDpbb for ; Wed, 13 May 2009 13:00:14 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 0D86D28C1FD for ; Wed, 13 May 2009 13:00:13 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 9511F7111D4; Wed, 13 May 2009 22:01:45 +0200 (CEST) Date: Wed, 13 May 2009 22:01:45 +0200 From: Michael Eriksson To: Julien Laganier Message-ID: <20090513200145.GA25647@kafka.verkstad.net> References: <200905131434.30760.julien.laganier.IETF@googlemail.com> <20090513144314.GA21117@kafka.verkstad.net> <200905131745.45256.julien.laganier.IETF@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905131745.45256.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] offline Re: binary filters draft 0 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, 13 May 2009 20:00:15 -0000 First, Julien, please excuse me if I offended you with my last mail. That was not my intention. I think that our discussion had a sound dose of tounge-in-cheek (which I appreciated), and I thought that you wouldn't mind a rude joke. I am sincerely sorry. On Wed, May 13, 2009 at 17:45:45 +0200, Julien Laganier wrote: > On Wednesday 13 May 2009, Michael Eriksson wrote: > > But then you would have to translate the rules from text to a binary > > format before transmission. Are the few saved bits (if any) really > > worth the cost in added complexity? > > Since in order to match actual packets the MIPv6 stack will _anyway_ > have to deal with binary representation of IP addresses, protocol > numbers, flow labels, port numbers, ICMP types and codes, IPsec SPIs, > you will have to pick these elements out of your text rules and > translate them to binary _anyway_ thus I do not see where is the added > complexity. Yes, the text will have to be parsed somewhere. But the beatiful thing with doing it at the HA is that you can completely avoid to encode and decode the message to and from an ad hoc binary format just for the MN to HA transport! > And yes it saves bits. It's not because a resource is cheap that we > should consume it without regards. For an illustration, see Fallacy #3 > in . I think that it is funny that you want to save some bytes in a signaling message that is sent maybe once a minute (at most), when MIPv6 tunnels every user data packet... If you really want to save bytes, I think that you should focus on separating the rule updates from the binding updates. Resending/refreshing all rules, whether in binary or text format, at every handover is wasteful -- both in terms of transmitted bytes and complexity. The same goes for refreshing all bindings just because you change the rules. > > Have you done any ballbark calculations: How many bytes would a > > binary format really save? How many percents of the available > > bandwidth? > > I do not have the charge of the proof since I propose to follow the > current practice of using binary encoding for network layer protocols. It is your argument that the text protocol is too verbose, and that a binary format is needed. > You are on the other hand free to compute how much complexity is saved > by translating text to binary in the MIPv6 stack (as pointed out above > is implied by your proposal) rather than in your connexion manager (as > I argue you could do if you really want a text based language). It would save exactly the complexity of encoding and decoding to and from a binary format. Given the existing suggested binary rule and transport formats, I would say that that is quite a lot... > > Unfortunately, it is all too common. How could we possibly advance > > out of the 1970's if everybody argued like that? > > Is this your argument? > > Mind you, many bright principles originates in the 70's and are still > valid today. OK, I should have added one or two smileys, but I thought that was obvious. But I actually think that I do have a point about the tendency to always do things as they have always been done. That is not the way to make real progress. More of the same is not always the best thing. In this particular case, the available bandwidth have increased with about 2 to 3 decimal magnitudes (i.e., a factor of 100 to 1000) in the 13 years that have passed since draft-ietf-mobileip-ipv6-00 was published in January 1996. Back then we used 28.8 kbps modems and the 9.6 kbps GSM circuit switch data service. Today, we use 8000-100000 kbps fixed accesses at home, and 3G HSPA with 7200 kbps. > It's the right thing to do to follow past design principles unless > better ones are found. So far you have not provided any valid evidence > that motivate the need to use text encoding in a network layer > protocol. I am arguing that the text format is a better design. I happen to think that I actually have put forward some reasonable arguments. > You keep insisting on the "complexity" of "translat[ing] the rules from > text to a binary format before transmission" while it is clear that, as > soon as you introduce a text rule language, translating between binary > and text is required to match actual packets no matter what rule > encoding we choose for on-the-wire protocol encoding . I think I replied to a similar remark above. Regards, Michael From mer@kafka.verkstad.net Wed May 13 13:09: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 15CEB3A6BCD for ; Wed, 13 May 2009 13:09:04 -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.043, 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 G2aQpC7Ucau4 for ; Wed, 13 May 2009 13:09:03 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id F08983A6AC1 for ; Wed, 13 May 2009 13:09:02 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 284917111D4; Wed, 13 May 2009 22:10:35 +0200 (CEST) Date: Wed, 13 May 2009 22:10:35 +0200 From: Michael Eriksson To: Hesham Soliman Message-ID: <20090513201035.GB25647@kafka.verkstad.net> References: <20090512084022.GB20880@kafka.verkstad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 13 May 2009 20:09:04 -0000 On Thu, May 14, 2009 at 02:06:54 +1000, Hesham Soliman wrote: > > It is correct that the CoA bindings are unidirectional. But the HA can > > of course know what interfaces are working on the MN: It only has to > > look in the binding cache! The MN will unregister any non-working CoA. > > => Oh of course if an entry is in the binding cache then the corresponding > interface, base station, cell load, app preferences and end to end > reachability must all be valid for the lifetime of the binding...makes > perfect sense...These things just don't change once the CoA is in the > binding cache. Of course the binding cache also includes the corresponding > link layer properties associated with the CoA, which also never change. The > all-knowing omnipresent HA can then direct traffic as it sees fit. Hesham, to me it is plain obvious that the MN can keep the HA in sync regarding all its knowledge about the status of its interfaces by sending binding updates. If the MN gets new status information, it will do a binding update. I will let your reasoning above pass with merciful silence... - o - I also note that you are not answering this question, which was in the same mail: How can you agree that the flow-binding draft is relevant for this charter item, while you are also saying that the draft handles RULES and the charter talks about POLICIES? I hope that means that you will no longer keep saying that "policies" means "rules" when you want it to, but not otherwise (playing with words, as I irreverently called it). Regards, Michael From hesham@elevatemobile.com Wed May 13 13:30: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 7E5AC3A6B87 for ; Wed, 13 May 2009 13:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 IdJ6486ro1V3 for ; Wed, 13 May 2009 13:30: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 4013828C0D9 for ; Wed, 13 May 2009 13:30: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 1M4L7G-0003PZ-Gf; Thu, 14 May 2009 06:31:50 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 14 May 2009 06:31:45 +1000 From: Hesham Soliman To: Michael Eriksson Message-ID: Thread-Topic: [MEXT] new pad sub-option and flow identifier assignment Thread-Index: AcnUCdT+N2yZbizvZEupEYsPFJRIew== In-Reply-To: <20090513201035.GB25647@kafka.verkstad.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 13 May 2009 20:30:23 -0000 On 14/05/09 6:10 AM, "Michael Eriksson" wrote: > On Thu, May 14, 2009 at 02:06:54 +1000, Hesham Soliman wrote: >>> It is correct that the CoA bindings are unidirectional. But the HA can >>> of course know what interfaces are working on the MN: It only has to >>> look in the binding cache! The MN will unregister any non-working CoA. >> >> => Oh of course if an entry is in the binding cache then the corresponding >> interface, base station, cell load, app preferences and end to end >> reachability must all be valid for the lifetime of the binding...makes >> perfect sense...These things just don't change once the CoA is in the >> binding cache. Of course the binding cache also includes the corresponding >> link layer properties associated with the CoA, which also never change. The >> all-knowing omnipresent HA can then direct traffic as it sees fit. > > Hesham, to me it is plain obvious that the MN can keep the HA in sync > regarding all its knowledge about the status of its interfaces by > sending binding updates. If the MN gets new status information, it > will do a binding update. > > I will let your reasoning above pass with merciful silence... => Yes sounds like a reliable way of doing things (of course not). > > - o - > > I also note that you are not answering this question, which was in the > same mail: > > How can you agree that the flow-binding draft is relevant for this > charter item, while you are also saying that the draft handles RULES > and the charter talks about POLICIES? => No I didn't because life is too short and I'm under too much time pressure to keep repeating myself. My use of the words hasn't changed and you seem to like quoting what proves your point and ignoring all other quotes that don't. The draft didn't just sneak into the WG without people and the chairs knowing full well what it did (and it's not policies it's transfer of rules). So, I think the (only?) point you may have in this discussion is that the charter is not worded carefully about the use of transport of rules. But for that you should address the chairs/AD as it's not my job. > > I hope that means that you will no longer keep saying that "policies" > means "rules" when you want it to, but not otherwise (playing with > words, as I irreverently called it). => There is a difference between irreverent and rude. But I think you'll disagree with me on that too Hesham > > > Regards, > Michael From ryuji.wakikawa@gmail.com Wed May 13 15:28: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 333243A6D16 for ; Wed, 13 May 2009 15:28:51 -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 kumVLjPWwF4s for ; Wed, 13 May 2009 15:28:50 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 244D63A6C2C for ; Wed, 13 May 2009 15:28:50 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so872932qwe.31 for ; Wed, 13 May 2009 15:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wyg3XVacx1RxGnZYf5iqjcNMsCSQDWM5o4GQOl+qKZA=; b=q/NmYIcq7ZZduoFkN0BpqbugIoeM+Kpfq2eNcnRIjXmzik5smYBgKmK5L1liyeAuYe Iqx6rSGaCgSPzT5wcxEJx6r3YmdYECFcQKZsEjgCkp4AuScBUFmtBQJt8Dgaw7dA9RlK XZqUbJLOy8ia0NfqoLSlER6/svW+OVO+EG87A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=jM8rxRdnGug8bQUZiCxgHe7UfcdIQpFSFgYnajZKtdVO0HO6PYP73M7n7ZD/a9sH+b s+hNRAt/jKqE9Sai7GG6alTHB0I3NcmgORnCBG8S2e7IZ6nWzWgcwn7Z8WvEGP4CNUxH PBe0jSFQ2b8oJ7M/IPq+fNVT5EpQc6IryHkLA= MIME-Version: 1.0 Received: by 10.224.37.141 with SMTP id x13mr2005108qad.13.1242253820798; Wed, 13 May 2009 15:30:20 -0700 (PDT) In-Reply-To: <87y6t2dcte.fsf@small.ssi.corp> References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <200905111255.43046.julien.laganier.IETF@googlemail.com> <878wl3sxou.fsf@small.ssi.corp> <200905111542.04553.julien.laganier.IETF@googlemail.com> <87y6t2dcte.fsf@small.ssi.corp> Date: Wed, 13 May 2009 15:30:20 -0700 Message-ID: <84840efa0905131530o2ba6b33w1e22cae23ec31246@mail.gmail.com> From: Ryuji Wakikawa To: Arnaud Ebalard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryuji@sfc.wide.ad.jp List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 22:28:51 -0000 Hi Arnaud, 2009/5/12 Arnaud Ebalard : > Hi Ryuji, > > Ryuji Wakikawa writes: > >>>> Considering the example you give, maybe you have some comment (in the >>>> context of MCoA) on the current inability for a MN that has a binding >>>> with a CN =A0to tell that CN that it should route some flows to the Ho= A >>>> of the MN instead of sending those to the CoA. >>> >>> Without my WG chair hat: Since route optimization is in my view a >>> central piece of the MIPv6 design, I would consider that inability >>> as a >>> flaw. >> >> This isn't a flow. >> >> In Mobile IPv6, when MN registers its binding to CN, MN cannot tell >> some flow is sent without RO. > > That's correct but MIPv6 was restricted to a single binding and route > for communications bewteen MN-HA and MN-CN. Because MCoA removes that > restriction, I don't see your point about citing a missing feature of > MIPv6 as an argument not to have it in MCoA. IMHO, MCoA is the place > where all the possible destination should be handled, including the > HoA. > >> It is same here in MCoA. For the binding management, we don't offer >> any solution for this. > > From my perspective, MCoA *is* about binding management. >From the protocol point of view, we have two choices here. - having special binding for the HoA destination - having flow management to skip RO Since RO is not so important at this point, we should go with the minimal spec which mean the second option. You can put all the possible features in the MCoA, but the draft is not discussed in that direction at this stage. We can always revisit the spec once we "really need" such extension. >> This is more like flow handling matter which is out of scope in the >> MCoA. > > The thing is that at the moment the MCoA draft is the one providing > information about the address to which the traffic is expected to go > (via the content of the BID). If you cannot express the direction is the Before the binding, we need to have additional mechanism to the binding selection. > HoA with what is in the draft, next documents will have to modify the > semantic of the BID, instead of simply use it. Or do I fail to > understand how you want that to be handled? We shouldn't change the semantics of BID for this. We can't modify the spec after completing WG/IETF/IESG LC, but we only accept minor changes for clarification and editorial errors. Otherwise, we will get into endless cycles. Anyway, IMO, your feature can be achieved with the current MCoA spec with flow binding. regards, ryuji >> You can use flow binding spec to direct some of flow to bypass the RO. > > See above. > > Cheers, > > a+ > > From ryuji.wakikawa@gmail.com Wed May 13 15:31: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 1E3FE28C0D6 for ; Wed, 13 May 2009 15:31:13 -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 kIvBBK8XL8o8 for ; Wed, 13 May 2009 15:31:12 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 7AB703A6ADD for ; Wed, 13 May 2009 15:31:10 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so873911qwe.31 for ; Wed, 13 May 2009 15:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=58nbqeaUDP/eA7QNouY0TJgqhk2EpE7vyj0XLenG4r0=; b=p4lbBl8RpAWRjMmdO3zeCUfQ43PU1GXSkPYk4OsVS9Skp7NezdrC7/Byzb20ODE82c aEo45933/0QmLvlhK2nKMKvy9CkJlJCgU/RegBW8J+e7y5Vt5EjD7UaEi63OMEK2FTKr U1iZU49gaXusCC6RtGpgUt53wkiSkDHfhECck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=QkrLHEub8JyjpMIxKUkYg2H53/5gJtXC/nrPHyaI1df37ZBbbrW91Oc4+exHNxdQJd qV85snP+zFl3qzAAn7p2bkm8LJxcOdmiiXuSvo3/uZJnzaFn/I/mnTYw9hxc5yIwTdGr DF9PiznHNM3SDfuqSeBp6S0JbBq0esWhI+9C8= MIME-Version: 1.0 Received: by 10.224.2.131 with SMTP id 3mr1934316qaj.302.1242253960802; Wed, 13 May 2009 15:32:40 -0700 (PDT) In-Reply-To: References: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> Date: Wed, 13 May 2009 15:32:40 -0700 Message-ID: <84840efa0905131532g218b7800h6a2771b2a16d9112@mail.gmail.com> From: Ryuji Wakikawa To: Romain KUNTZ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryuji@sfc.wide.ad.jp List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 22:31:13 -0000 Hi Romain, 2009/5/12 Romain KUNTZ : > Hi Ryuji, > > On 2009/05/11, at 23:01, Ryuji Wakikawa wrote: >>> >>> My mistake, actually it does say something, in section 6.5 (Receiving >>> Packets from Mobile Node): >>> >>> =A0When a node receives packets with a Home Address destination option >>> =A0from a mobile node, it MUST check that the care-of address that >>> =A0appears in the source address field of the IPv6 header MUST be equal >>> =A0to one of the care-of addresses in the binding cache entry. =A0If no >>> =A0binding is found, the packets MUST be discarded. =A0[...] >>> >>> But my comment on the efficiency (especially at the HA side) still hold= s, >>> in addition to the other issue related to the RHT2. >> >> I have answered to this. >> >> This situation is only for the traffic between MN and HA. The same rule >> apply to the traffic between MN and CN. > > Right, and I was especially concerned about the HA because it may have mo= re > MN to handle than a CN. I thought it could be a problem if there are lots= of > MNs-HA communications (but on the other hand, I can't think of an use-cas= e > where MN-HA communications would be frequent). ok. From the MIP6 protocol, there is only protocol signaling exchange between MN and HA. As you said, there isn't use-case of MN-HA data communication. We don't need to bother the data traffic between MN and HA. > > If you think it would not cause possible performance issues, I'll trust y= ou > on that. > > >> The issue of RHT2 is not MCoA matter. It is solved by flow binding. > > Well, yes it could be solved by flow binding. I had in mind a case where > only MCoA would be used. But I was already told here that everything rela= ted > to flow distribution should be handled by some flow filtering mechanism, = and > not MCoA itself only, so I'll stop arguing on that. OK thanks, ryuji > Cheers, > romain > From marcelo@it.uc3m.es Wed May 13 16:13: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 A273528C204 for ; Wed, 13 May 2009 16:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_50=0.001, 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 JGe+Ac9akAHN for ; Wed, 13 May 2009 16:13:31 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A1DC73A6ADD for ; Wed, 13 May 2009 16:13:30 -0700 (PDT) Received: from r190-135-32-7.dialup.adsl.anteldata.net.uy (r190-135-32-7.dialup.adsl.anteldata.net.uy [190.135.32.7]) by smtp01.uc3m.es (Postfix) with ESMTP id C07F3B70A11 for ; Thu, 14 May 2009 01:14:58 +0200 (CEST) Message-ID: <4A0B546F.2090804@it.uc3m.es> Date: Thu, 14 May 2009 01:14: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-16640.002 Subject: [MEXT] MEXT meeting at 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: Wed, 13 May 2009 23:13:32 -0000 Hi, We need to request the slots for IETF75, so please let us know what topics you want to discuss in Stockholm. Regards, marcelo From w52006@huawei.com Wed May 13 20:19: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 9BF8F3A68CF for ; Wed, 13 May 2009 20:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 MlItqQgQiKHP for ; Wed, 13 May 2009 20:18:59 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 71BC03A6876 for ; Wed, 13 May 2009 20:18:59 -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 <0KJM008HJ6LXD5@szxga03-in.huawei.com> for mext@ietf.org; Thu, 14 May 2009 11:20:21 +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 <0KJM00JYC6LX0F@szxga03-in.huawei.com> for mext@ietf.org; Thu, 14 May 2009 11:20:21 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJM00EV16LWYB@szxml04-in.huawei.com> for mext@ietf.org; Thu, 14 May 2009 11:20:21 +0800 (CST) Date: Thu, 14 May 2009 11:20:20 +0800 From: Yungui Wang In-reply-to: To: 'Hesham Soliman' , 'marcelo bagnulo braun' Message-id: <007101c9d442$e9d06ad0$150ca40a@china.huawei.com> Organization: huawei 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: AcnUCdT+N2yZbizvZEupEYsPFJRIewAIBDKAAAK2rxoAATILkA== Cc: 'mext' Subject: Re: [MEXT] new pad sub-option and flow identifier assignment 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, 14 May 2009 03:19:00 -0000 Hello Thanks. I support the flow binding draft for rules exchanges, and I agree policies and rules are not the same thing. However, I think that the charter text 'policies exchange' is implicitly to state that rules (mask of policies) are transported between MN and HA at bi-direction, NOT both policies and rules are transported. If possible, please chairman gives a note on below Charter text. Does 'policies exchange' mean that policies only, rules only or both are transported between MN and HA? "- 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]. " B.R. Yungui > -----Original Message----- > From: Hesham Soliman [mailto:hesham@elevatemobile.com] > Sent: Thursday, May 14, 2009 9:39 AM > To: w52006@huawei.com > Subject: Re: [MEXT] new pad sub-option and flow identifier assignment > > > > > On 14/05/09 10:42 AM, "Yungui Wang" wrote: > > > > > Hello > > > >>> - o - > >>> > >>> I also note that you are not answering this question, which > >> was in the > >>> same mail: > >>> > >>> How can you agree that the flow-binding draft is > >> relevant for this > >>> charter item, while you are also saying that the draft > >> handles RULES > >>> and the charter talks about POLICIES? > >> > >> => No I didn't because life is too short and I'm under too > much time > >> pressure to keep repeating myself. My use of the words hasn't > >> changed and > >> you seem to like quoting what proves your point and > ignoring all other > >> quotes that don't. The draft didn't just sneak into the WG > >> without people > >> and the chairs knowing full well what it did (and it's not > >> policies it's > >> transfer of rules). So, I think the (only?) point you may > have in this > >> discussion is that the charter is not worded carefully about > >> the use of > >> transport of rules. But for that you should address the > >> chairs/AD as it's > >> not my job. > >> > > > > I still can't get your real viewpoint. (Maybe that's the reason why > > you are asked to repeat yourself once again. :) ) > > Do you agree the charter is also talking about flow/binding rules > > exchange, not policies? > > If yes, the charter had clearly stated that rules (instead > of policies) > > exchange is bi-directional. > > => I believe that the charter intended (judging by the text > in it and the > discussions at the time) to support both policies and rule > transport. > The bidirectionality is related to policies and not the rules. > There were many > emails and meeting discussions about the difference between rules and > policies. We need to at least agree that they're not the same > thing. > Chairs feel free to correct me on this. > But the mere fact that we > have a 2-year old > draft about to go to LC on rule transport should give you a > pretty clear > hint about the intention and concensus at the time. Otherwise > we would not > have slpit the draft into two and discussed draft-larsson as a way of > defining filters. > > I even recall a recent thread where someone suggested doing > policy transfer > in another WG because it was not specific to mobility but I > don't remember > how that was resolved. You can check the archives I guess. > > Hesham > > > That's, only MN initiating flow binding is > > not the just point. Yes or No? > > > > B.R. > > Yungui > > > > From gwz@net-zen.net Wed May 13 21:03: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 78CB93A68AF for ; Wed, 13 May 2009 21:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 mKtfBGJSV3aO for ; Wed, 13 May 2009 21:03:23 -0700 (PDT) Received: from smtpauth18.prod.mesa1.secureserver.net (smtpauth18.prod.mesa1.secureserver.net [64.202.165.31]) by core3.amsl.com (Postfix) with SMTP id 117E23A6A90 for ; Wed, 13 May 2009 21:03:22 -0700 (PDT) Received: (qmail 14905 invoked from network); 14 May 2009 03:58:08 -0000 Received: from unknown (124.120.218.67) by smtpauth18.prod.mesa1.secureserver.net (64.202.165.31) with ESMTP; 14 May 2009 03:58:07 -0000 From: "Glen Zorn" To: "'Hannes Tschofenig'" , "'George Tsirtsis'" References: <00b601c9d3d3$bd8eeab0$3143a20a@nsnintra.net> <00cf01c9d3e9$854b11e0$3143a20a@nsnintra.net> In-Reply-To: <00cf01c9d3e9$854b11e0$3143a20a@nsnintra.net> Date: Thu, 14 May 2009 10:57:04 +0700 Organization: Network Zen Message-ID: <000001c9d448$0e6df1f0$2b49d5d0$@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: AcnT09moslggqMltSjGSQwgQyPSYfAAEvNzQABdJIgA= Content-Language: en-us Cc: 'Michael Eriksson' , mext@ietf.org Subject: Re: [MEXT] Binary Filters and the nature of MIP Re: binary filtersdraft 0 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, 14 May 2009 04:03:24 -0000 Hannes Tschofenig [mailto://Hannes.Tschofenig@gmx.net] writes: > Sorry to be unclear. > > There are two aspects: > > 1) How do you encode filters on the wire, i.e., when carried in your > favorite mobility protocol (or other protocol; does not really matter > that > much). > > 2) How are these filters implemented in a particular node? > > Now, for item (2) folks have come up with quite sophisticated > mechanisms > (typically dedicated languages that have an assembler like syntax) over > time > that are (a) highly efficient and (b) quite compact in the encoding. I > provide a reference to the BSD packet filter system but the work > obviously > did not stop in 1992. > > Now, ideally you would want to select a format for (1) that allows easy > conversion to the format used with (2). > > The problem now is that different implementations use different > languages. > So, it is quite likely that you will have to convert the stuff you get > via > (1) anyway to (2). > > So, my conclusion is that the format for (1) does not really matter > unless > you get to pick a format that is extremely close or equal to the format > used > by (2) for most of the implementations. > > This only matters if the translation from (1) to (2) is performance- > wise an > issue. I am not sure it really is and in that case you could as well > toss a > coin since it does not matter at all for the format for (1) is. > > Does this description make any sense? Total sense. I'd just add that if we are to worry about performance issues at all they should be issues that we have some control over (i.e., efficiency on the wire) rather than those we do not (for example, the algorithms used at either end to create or process the filters). ... From arno@natisbad.org Thu May 14 00:29: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 2F1043A6F07 for ; Thu, 14 May 2009 00:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 FRAw2er1kcRI for ; Thu, 14 May 2009 00:29:11 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 468F73A6DD4 for ; Thu, 14 May 2009 00:29:11 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M4VOo-0000ER-GC; Thu, 14 May 2009 09:30:38 +0200 X-Hashcash: 1:20:090514:tsirtsis@googlemail.com::VSNiyh+VVyvs7XLI:000000000000000000000000000000000000007ESI From: arno@natisbad.org (Arnaud Ebalard) To: ryuji@sfc.wide.ad.jp References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <200905111255.43046.julien.laganier.IETF@googlemail.com> <878wl3sxou.fsf@small.ssi.corp> <200905111542.04553.julien.laganier.IETF@googlemail.com> <87y6t2dcte.fsf@small.ssi.corp> <84840efa0905131530o2ba6b33w1e22cae23ec31246@mail.gmail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090514:julien.laganier.ietf@googlemail.com::1rOA7NnQ4HGgk6fL:000000000000000000000000003qXW X-Hashcash: 1:20:090514:mext@ietf.org::2e4X22YeDFvevV0V:00003pYg X-Hashcash: 1:20:090514:ryuji@sfc.wide.ad.jp::OvnjxkpuLewYi5wr:00000000000000000000000000000000000000000G5li Date: Thu, 14 May 2009 09:31:21 +0200 In-Reply-To: <84840efa0905131530o2ba6b33w1e22cae23ec31246@mail.gmail.com> (Ryuji Wakikawa's message of "Wed, 13 May 2009 15:30:20 -0700") Message-ID: <878wl087jq.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 14 May 2009 07:29:12 -0000 Hi, Ryuji Wakikawa writes: >> From my perspective, MCoA *is* about binding management. > > From the protocol point of view, we have two choices here. > - having special binding for the HoA destination > - having flow management to skip RO > > Since RO is not so important at this point, we should go with the > minimal spec which mean the second option. >From my perspective, RO is important. > You can put all the possible features in the MCoA, but the draft is > not discussed in that direction at this stage. Julien, George, what do you think? Is the feature a simple and logical addition for the flow-inding draft? If not, I fail to see how it can be specified in an external document extending both (MCoA and flow-binding). > We can always revisit the spec once we "really need" such extension. > >>> This is more like flow handling matter which is out of scope in the >>> MCoA. >> >> The thing is that at the moment the MCoA draft is the one providing >> information about the address to which the traffic is expected to go >> (via the content of the BID). If you cannot express the direction is the > > Before the binding, we need to have additional mechanism to the > binding selection. > >> HoA with what is in the draft, next documents will have to modify the >> semantic of the BID, instead of simply use it. Or do I fail to >> understand how you want that to be handled? > > We shouldn't change the semantics of BID for this. > We can't modify the spec after completing WG/IETF/IESG LC, but we only > accept minor changes for clarification and editorial errors. > Otherwise, we will get into endless cycles. > > Anyway, IMO, your feature can be achieved with the current MCoA spec > with flow binding. I'll let the final word to Julien and George. Cheers, a+ From arno@natisbad.org Thu May 14 01:01: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 EEDB83A6C8E for ; Thu, 14 May 2009 01:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 RJw25sNszupF for ; Thu, 14 May 2009 01:01:53 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 188E53A686D for ; Thu, 14 May 2009 01:01:53 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M4VuU-0000Y4-NX; Thu, 14 May 2009 10:03:22 +0200 X-Hashcash: 1:20:090514:julien.laganier.ietf@googlemail.com::itF5KM8t3GfcVfei:000000000000000000000000000oom X-Hashcash: 1:20:090514:vijay@wichorus.com::aSl4QHxAEkI0DIGM:00000000000000000000000000000000000000000001eT/ From: arno@natisbad.org (Arnaud Ebalard) To: marcelo bagnulo braun , Julien Laganier References: <4A0B546F.2090804@it.uc3m.es> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090514:marcelo@it.uc3m.es::27O9Zs2iP4sV4xee:00000000000000000000000000000000000000000000QRR X-Hashcash: 1:20:090514:mext@ietf.org::ERiYRkV0dqXRnjni:00004BNA Date: Thu, 14 May 2009 10:04:05 +0200 In-Reply-To: <4A0B546F.2090804@it.uc3m.es> (marcelo bagnulo braun's message of "Thu, 14 May 2009 01:14:55 +0200") Message-ID: <87vdo46rgq.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext Subject: Re: [MEXT] MEXT meeting at 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: Thu, 14 May 2009 08:01:54 -0000 Hi, marcelo bagnulo braun writes: > We need to request the slots for IETF75, so please let us know what > topics you want to discuss in Stockholm. I will not be in Stockholm, so I won't be able to discuss [i.e. to bother anyone with this ;-) ] the issues documented in [1], even if I think they are worth discussing. Marcelo, Julien, can one of you just read the document and either ack or nack the need to do something (in the context of 3775bis or another context) about the issues it raises? Vijay, I may be wrong but the content of section 5.3 may be of interest to you. Obviously, I am not asking for any kind of thorough review of the doc. Cheers, a+ [1]: http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00 From julien.laganier.ietf@googlemail.com Thu May 14 02:52: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 448453A69C9 for ; Thu, 14 May 2009 02:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 3QbCm5bnOoXv for ; Thu, 14 May 2009 02:52:04 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 063833A68EF for ; Thu, 14 May 2009 02:52:03 -0700 (PDT) Received: by ewy24 with SMTP id 24so1461998ewy.37 for ; Thu, 14 May 2009 02:53:34 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=NoQoiOM3mlFxTrYBs71rfqZp6OcTq6U54JT+bRktDYk=; b=IOh3SGuNDjlws4Xz79Y936tqSqSguFMXb2/zr2JJzUlQcT3zHVJKpk5exgOuZwbk1i 2Vr1jQHlLvlVRQZHwa6Zd4UOz+wd6BLv4//ig7qDh0QYdlYkzD2nFIA235NRKviN9pYD vUs0Z9qsVO3qpB9lKLU6hpitQOHuVLV0qMvsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=Y7guuDVyLYYDDIosMfche5mah5/UZDBiHaf76oVsX4xWdaPhgjQvsNHx67MjG3KYOt AhxvmnXYHA2uqTbYaH4yCE5e/stQSu73BbQ7QlpRENIFIDy6mh1nKZkxJKOlIZbMdMvx 0LTChE1JAwwggFwSpmfohMKli3iw8yvf/BKB8= Received: by 10.216.29.72 with SMTP id h50mr779165wea.137.1242294814535; Thu, 14 May 2009 02:53:34 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id j8sm2208513gvb.11.2009.05.14.02.53.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 14 May 2009 02:53:33 -0700 (PDT) From: Julien Laganier To: Arnaud Ebalard Date: Thu, 14 May 2009 11:53:40 +0200 User-Agent: KMail/1.9.10 References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <84840efa0905131530o2ba6b33w1e22cae23ec31246@mail.gmail.com> <878wl087jq.fsf@small.ssi.corp> In-Reply-To: <878wl087jq.fsf@small.ssi.corp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905141153.41155.julien.laganier.IETF@googlemail.com> Cc: ryuji@sfc.wide.ad.jp, mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 14 May 2009 09:52:05 -0000 Hello all, On Thursday 14 May 2009, Arnaud Ebalard wrote: > Hi, > > Ryuji Wakikawa writes: > >> From my perspective, MCoA *is* about binding management. > > > > From the protocol point of view, we have two choices here. > > - having special binding for the HoA destination > > - having flow management to skip RO I am sympathetic to the view that MCoA is about multiple binding management. It is also my understanding that it would not make sense to create a special binding for the HoA: a MIPv6 binding is between a HoA and another address, the CoA. It would not make sense to bind the HoA to itself. Thus, I think the functionality we've talking about can be implemented in a semantically clean way by "having flow management to skip RO" as Ryuji puts it. > > Since RO is not so important at this point, we should go with the > > minimal spec which mean the second option. > > From my perspective, RO is important. I agree it is, but as I try to point out above, diverting some of the traffic to the HoA while other traffic goes to (one of) the CoA is in my view a flow management issue and has nothing to do with multiple binding management. > > You can put all the possible features in the MCoA, but the draft is > > not discussed in that direction at this stage. > > Julien, George, what do you think? Is the feature a simple and > logical addition for the flow-inding draft? If not, I fail to see how > it can be specified in an external document extending both (MCoA and > flow-binding). I happen to believe that it's reasonable simple to add the feature to the flow binding draft (one possibility would be to use BID set to zero in a FID to indicate that forwarding to HoA is desired, as I believe you proposed earlier.) > [...] > > > We shouldn't change the semantics of BID for this. > > We can't modify the spec after completing WG/IETF/IESG LC, but we > > only accept minor changes for clarification and editorial errors. > > Otherwise, we will get into endless cycles. > > > > Anyway, IMO, your feature can be achieved with the current MCoA > > spec with flow binding. > > I'll let the final word to Julien and George. Agree with Ryuji on this. --julien From arno@natisbad.org Thu May 14 04:08:49 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 531843A6CB1 for ; Thu, 14 May 2009 04:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 F1fh7fuzi3zt for ; Thu, 14 May 2009 04:08:48 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 82ED43A6BD6 for ; Thu, 14 May 2009 04:08:48 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M4YpN-0003Rf-G9; Thu, 14 May 2009 13:10:17 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Julien Laganier References: <781710.38785.qm@web27803.mail.ukl.yahoo.com> <84840efa0905131530o2ba6b33w1e22cae23ec31246@mail.gmail.com> <878wl087jq.fsf@small.ssi.corp> <200905141153.41155.julien.laganier.IETF@googlemail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090514:julien.laganier.ietf@googlemail.com::kjaVHHTsxN3vzJW5:000000000000000000000000000C6/ X-Hashcash: 1:20:090514:tsirtsis@googlemail.com::l2i4OJL6d9R8zfKg:000000000000000000000000000000000000001Kn1 X-Hashcash: 1:20:090514:ryuji@sfc.wide.ad.jp::lj95YX+Ys/HfoLPN:000000000000000000000000000000000000000009aRn X-Hashcash: 1:20:090514:mext@ietf.org::bPzjgU42AEQXxcaj:0000ASxv Date: Thu, 14 May 2009 13:10:59 +0200 In-Reply-To: <200905141153.41155.julien.laganier.IETF@googlemail.com> (Julien Laganier's message of "Thu, 14 May 2009 11:53:40 +0200") Message-ID: <87vdo4djng.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ryuji@sfc.wide.ad.jp, mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 14 May 2009 11:08:49 -0000 Hi, Julien Laganier writes: >> > You can put all the possible features in the MCoA, but the draft is >> > not discussed in that direction at this stage. >> >> Julien, George, what do you think? Is the feature a simple and >> logical addition for the flow-inding draft? If not, I fail to see how >> it can be specified in an external document extending both (MCoA and >> flow-binding). > > I happen to believe that it's reasonable simple to add the feature to > the flow binding draft (one possibility would be to use BID set to zero > in a FID to indicate that forwarding to HoA is desired, as I believe > you proposed earlier.) If you mean for instance by extending the description of BID field in section 4.2.1 of flow-binding draft (4.2.1. Binding Reference Sub-option) to associate value 0 to the HoA, then it's ok for me. >> > Anyway, IMO, your feature can be achieved with the current MCoA >> > spec with flow binding. >> >> I'll let the final word to Julien and George. > > Agree with Ryuji on this. Ack. Cheers, a+ From tsirtsis@googlemail.com Thu May 14 06:42: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 7602A3A6CB3 for ; Thu, 14 May 2009 06:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.158, 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 gyW4iJYBK6KC for ; Thu, 14 May 2009 06:42:16 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 300A43A6C53 for ; Thu, 14 May 2009 06:42:15 -0700 (PDT) Received: by bwz22 with SMTP id 22so1298748bwz.37 for ; Thu, 14 May 2009 06:43:46 -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=VhjmxIQb/5dkCl9SYl+8YSul0Tvdc4pY5zII/zm8VUk=; b=iolVsBstyZ9ftwKfRN4RBgLq/uN0wTKP6l4e9Mqc/IUD/mY4ST9IOECwZ/zV1hyI1q EbuWfrOaWHY5RbglZ/uLJSsLrBXD4wX5aJp9IczqHKBRm8T/u/7x0KLmWg2J8GxINg2d 3kexzai52fNbkfFzOLD1wbN9N5KyCqI1Rixy0= 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=cLZOQXGsOwJed86GlYncBr0PPNyukOhB+L/8y6ZA0tUmq17nmT1D8BcmA/EVsbMpjD Qe/0/yDWR3CwHFFOZ1Cev1AwfnF5pbw42O1A/KoaHislCPewgN1D5AosFcw8XnK94khK Z9DXN3jGI2/YYnTZOAAhfWTluLJq5I0XrQVdU= MIME-Version: 1.0 Received: by 10.223.114.135 with SMTP id e7mr1635316faq.89.1242308625536; Thu, 14 May 2009 06:43:45 -0700 (PDT) In-Reply-To: <000001c9d448$0e6df1f0$2b49d5d0$@net> References: <00b601c9d3d3$bd8eeab0$3143a20a@nsnintra.net> <00cf01c9d3e9$854b11e0$3143a20a@nsnintra.net> <000001c9d448$0e6df1f0$2b49d5d0$@net> Date: Thu, 14 May 2009 09:43:45 -0400 Message-ID: From: George Tsirtsis To: Glen Zorn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hannes Tschofenig , Michael Eriksson , mext@ietf.org Subject: Re: [MEXT] Binary Filters and the nature of MIP Re: binary filtersdraft 0 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, 14 May 2009 13:42:19 -0000 Agreed, which is again why binary makes sense as the default. George On Wed, May 13, 2009 at 11:57 PM, Glen Zorn wrote: > Hannes Tschofenig [mailto://Hannes.Tschofenig@gmx.net] writes: > >> Sorry to be unclear. >> >> There are two aspects: >> >> 1) How do you encode filters on the wire, i.e., when carried in your >> favorite mobility protocol (or other protocol; does not really matter >> that >> much). >> >> 2) How are these filters implemented in a particular node? >> >> Now, for item (2) folks have come up with quite sophisticated >> mechanisms >> (typically dedicated languages that have an assembler like syntax) over >> time >> that are (a) highly efficient and (b) quite compact in the encoding. I >> provide a reference to the BSD packet filter system but the work >> obviously >> did not stop in 1992. >> >> Now, ideally you would want to select a format for (1) that allows easy >> conversion to the format used with (2). >> >> The problem now is that different implementations use different >> languages. >> So, it is quite likely that you will have to convert the stuff you get >> via >> (1) anyway to (2). >> >> So, my conclusion is that the format for (1) does not really matter >> unless >> you get to pick a format that is extremely close or equal to the format >> used >> by (2) for most of the implementations. >> >> This only matters if the translation from (1) to (2) is performance- >> wise an >> issue. I am not sure it really is and in that case you could as well >> toss a >> coin since it does not matter at all for the format for (1) is. >> >> Does this description make any sense? > > Total sense. =C2=A0I'd just add that if we are to worry about performance= issues > at all they should be issues that we have some control over (i.e., > efficiency on the wire) rather than those we do not (for example, the > algorithms used at either end to create or process the filters). > > ... > > > From kaaspetersen@yahoo.dk Thu May 14 07:44: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 4872A28C12D for ; Thu, 14 May 2009 07:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 JNH9nl1EHc3H for ; Thu, 14 May 2009 07:44:22 -0700 (PDT) Received: from web27805.mail.ukl.yahoo.com (web27805.mail.ukl.yahoo.com [217.146.182.10]) by core3.amsl.com (Postfix) with SMTP id 1BC0D3A6D2D for ; Thu, 14 May 2009 07:44:21 -0700 (PDT) Received: (qmail 21359 invoked by uid 60001); 14 May 2009 14:45:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1242312352; bh=ZymNfZojq2y2UzX5zrfZWkebDebFOzGvaHsLZFOeflg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ITLmJFTJpyQkbyKpiV0Nsr/Vquibz89uY7b7MM8XbSJc4DKUGus/JeAi8ENahq3MX0i+nYHCZXJSOCiHs8bIQaG2ZGFIEnd7HXAZRbZOfHdWUw5/fl50bztfedL9NuIOvQb9wttkKeuXGGYm5HZ60by82HzN97Wwj4sHNbGIGhk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zecsUhGtgtMGDa1p6tGqhmK848Mr8yPsUBBDIjZTA0MEeVXut8wRi92U992FkDxJ7OjSx9LYYBil8nw9TjGu6Z7G3/7eNcTuIMfKq6t3weoeLpZcoIL8oM0mngq5hDFjJhMVeELVc1D3J4KBi8iZet52bgRyraO47OWUK+Hufe8=; Message-ID: <817975.21017.qm@web27805.mail.ukl.yahoo.com> X-YMail-OSG: WWlcyL4VM1lSB9Nad1gRJ3fQPn4DiQgVmS33.Zczr2_zlrBXGuNOOD3A17LFtlIe5cw5hMN0ofNnfKh1ngjzaTE7tczcFqZZ0BKQ8V4qQMh4nRzkylzqW4wLQGcW_YmVUID2HMxuQdQ6l.aGqiHDUH0QM5qdXbM.LY6Cz4HfSl7Js.rr9jr8MmVCCXbxxFyL3bYlnykywtQg4UGNXyhLGGj5b6N1QcJFmFIMXlmhayc_Ow5CZJI0oLa6Sp3JNWLewKl4YJmAlJzC4IzhP4Dbn0IBENvB.cADS31BTCsTzyhvaz6uMf6UzRhZqLN7CpESwZw5bUAJ.UujFmVR2nqFTdvPRzTUxJmhPno1Qf0DqDMIR96e Received: from [193.15.240.60] by web27805.mail.ukl.yahoo.com via HTTP; Thu, 14 May 2009 14:45:52 GMT X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.10 Date: Thu, 14 May 2009 14:45:52 +0000 (GMT) From: Christian Kaas-Petersen To: Glen Zorn , George Tsirtsis MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hannes Tschofenig , Michael Eriksson , mext@ietf.org Subject: Re: [MEXT] Binary Filters and the nature of MIP Re: binary filtersdraft 0 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, 14 May 2009 14:44:23 -0000 Another perspective ... hope it makes sense. The binary format on the wire can be chosen to save bytes on the wire. But the binary format on the wire is in general not the binary format used in the receiving node, and so a translation will have be made from the wire-binary format to the node-binary format. (Hannes's argument) My concern about sending text description is not the wire and not the conversion. It is the scale. Allow me to draw in an example from routing. A router does no longer dump its routing table to its peers whenever there is a change, instead it sends increments of specific changes. If the future of flow bindings is the exchange of many bindings, scalability becomes an issue and sending individual flow rules with a priority seems best. If instead the future is expected to be only a few rules because that is all a mobile node will care about, all rules can be sent when there is a change. Christian --- Den tors 14/5/09 skrev George Tsirtsis : Fra: George Tsirtsis Emne: Re: [MEXT] Binary Filters and the nature of MIP Re: binary filtersdra= ft 0 Til: "Glen Zorn" Cc: "Hannes Tschofenig" , "Michael Eriksson" , mext@ietf.org Dato: torsdag 14. maj 2009 15.43 Agreed, which is again why binary makes sense as the default. George On Wed, May 13, 2009 at 11:57 PM, Glen Zorn wrote: > Hannes Tschofenig [mailto://Hannes.Tschofenig@gmx.net] writes: > >> Sorry to be unclear. >> >> There are two aspects: >> >> 1) How do you encode filters on the wire, i.e., when carried in your >> favorite mobility protocol (or other protocol; does not really matter >> that >> much). >> >> 2) How are these filters implemented in a particular node? >> >> Now, for item (2) folks have come up with quite sophisticated >> mechanisms >> (typically dedicated languages that have an assembler like syntax) over >> time >> that are (a) highly efficient and (b) quite compact in the encoding. I >> provide a reference to the BSD packet filter system but the work >> obviously >> did not stop in 1992. >> >> Now, ideally you would want to select a format for (1) that allows easy >> conversion to the format used with (2). >> >> The problem now is that different implementations use different >> languages. >> So, it is quite likely that you will have to convert the stuff you get >> via >> (1) anyway to (2). >> >> So, my conclusion is that the format for (1) does not really matter >> unless >> you get to pick a format that is extremely close or equal to the format >> used >> by (2) for most of the implementations. >> >> This only matters if the translation from (1) to (2) is performance- >> wise an >> issue. I am not sure it really is and in that case you could as well >> toss a >> coin since it does not matter at all for the format for (1) is. >> >> Does this description make any sense? > > Total sense. =A0I'd just add that if we are to worry about performance is= sues > at all they should be issues that we have some control over (i.e., > efficiency on the wire) rather than those we do not (for example, the > algorithms used at either end to create or process the filters). > > ... > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig g= ode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From root@core3.amsl.com Fri May 15 01:30:02 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 1A3713A6C74; Fri, 15 May 2009 01: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: <20090515083002.1A3713A6C74@core3.amsl.com> Date: Fri, 15 May 2009 01:30:02 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-06.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, 15 May 2009 08: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-06.txt Pages : 38 Date : 2009-05-15 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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15011808.I-D@ietf.org> --NextPart-- From AMUHANNA@nortel.com Fri May 15 01:48: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 201113A6C13 for ; Fri, 15 May 2009 01:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 VWpCK7uThNtU for ; Fri, 15 May 2009 01:48:09 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0FF063A68E0 for ; Fri, 15 May 2009 01:48:08 -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 n4F8mSQ26018; Fri, 15 May 2009 08:48:28 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: Fri, 15 May 2009 03:45:42 -0500 Message-ID: In-Reply-To: <200905121535.44991.julien.laganier.IETF@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Binding Revocation almost ready for IESG Thread-Index: AcnTBpGU76vbD+fpT8ufd7uGz1fW7wCL3/LQ References: <200905121535.44991.julien.laganier.IETF@googlemail.com> From: "Ahmad Muhanna" To: "Julien Laganier" Cc: mext@ietf.org Subject: Re: [MEXT] 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: Fri, 15 May 2009 08:48:10 -0000 Hello Julien and All, Sorry for the delay, We have updated the Binding Revocation draft per your comments and has been published. please let us know if you have any comments. Regards, Ahmad =20 ++++++++++++++++++++++ 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-06.txt Pages : 38 Date : 2009-05-15 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-0 6.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ > -----Original Message----- > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com]=20 > Sent: Tuesday, May 12, 2009 6:36 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org; marcelo bagnulo braun; Vijay Devarapalli;=20 > Joel Hortelius; sgundave@cisco.com > Subject: Re: Binding Revocation almost ready for IESG >=20 > Hello Ahmad, >=20 > On Thursday 07 May 2009, Ahmad Muhanna wrote: > > Hello Julien, > > Thanks for the review. Please see comments inline. >=20 > [...] >=20 > > I will start working on the update and hopefully will be=20 > able to spin=20 > > a quick one soon. >=20 > Sounds good, Ahmad. Looking forward to it. Thank you. >=20 > --julien >=20 From julien.laganier.ietf@googlemail.com Fri May 15 05:41: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 411EF3A6837 for ; Fri, 15 May 2009 05:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 iVVJIqkRdjk1 for ; Fri, 15 May 2009 05:41:16 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 015963A6BF4 for ; Fri, 15 May 2009 05:41:01 -0700 (PDT) Received: by fxm2 with SMTP id 2so1899506fxm.37 for ; Fri, 15 May 2009 05:42:33 -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:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=GKrS28wnX0JL3hnNlJMgmchbFxHSTcrFIopxrqXZOPI=; b=QgtqK4DnwHy4zSt1cVElhB6EMJf500dGiL1LPCP2UqJ0kQP/i0wlk45WmznahjxDoU c7N5Y+oqcl0b/eDYfqZTWH7faIk+b62HHyNPz1utR7nVyk3cu5Tn6YXA/wxrfZd8wtS9 5qMz0ZlFL3IMIRJcbxade9vPaqIsMjTNEietY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=j4t0TheYMDTC4H9bZYj6JtQd9gMwXRrxN2uSzepOsoRQMeZjau0v4yhCwXLPamImGJ r4VT+DZxPsvv9iqcI1CDupab5nZ5rG0RhYCGoT6PigPJY+bLtzNwBDEpJQrvZTJG2dnu 5XvBI3Zg1t6z7TQBdx93aTXE8rERTkbaYszpY= Received: by 10.86.51.2 with SMTP id y2mr3658659fgy.3.1242391353378; Fri, 15 May 2009 05:42:33 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 4sm2107770fgg.23.2009.05.15.05.42.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 15 May 2009 05:42:32 -0700 (PDT) From: Julien Laganier To: "Ahmad Muhanna" Date: Fri, 15 May 2009 14:42:44 +0200 User-Agent: KMail/1.9.10 References: <200905121535.44991.julien.laganier.IETF@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905151442.45142.julien.laganier.IETF@googlemail.com> Cc: mext@ietf.org Subject: Re: [MEXT] 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: Fri, 15 May 2009 12:41:17 -0000 Hello Ahmad, On Friday 15 May 2009, Ahmad Muhanna wrote: > Hello Julien and All, > > Sorry for the delay, We have updated the Binding Revocation draft per > your comments and has been published. please let us know if you have > any comments. Be serious, in IETF time units the delay was null :-) Thanks for updating the draft quickly. At this point at this point I consider the draft ready to be sent to IESG and I'm working on the PROTO write-up, which as you might guess implies I'll be serving as the document shepherd thru IESG submission and RFC Editor processing. Best, --julien > ++++++++++++++++++++++ > > 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-06.txt > Pages : 38 > Date : 2009-05-15 > > 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-revocatio >n-0 6.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > -----Original Message----- > > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com] > > Sent: Tuesday, May 12, 2009 6:36 AM > > To: Muhanna, Ahmad (RICH1:2H10) > > Cc: mext@ietf.org; marcelo bagnulo braun; Vijay Devarapalli; > > Joel Hortelius; sgundave@cisco.com > > Subject: Re: Binding Revocation almost ready for IESG > > > > Hello Ahmad, > > > > On Thursday 07 May 2009, Ahmad Muhanna wrote: > > > Hello Julien, > > > Thanks for the review. Please see comments inline. > > > > [...] > > > > > I will start working on the update and hopefully will be > > > > able to spin > > > > > a quick one soon. > > > > Sounds good, Ahmad. Looking forward to it. Thank you. > > > > --julien From AMUHANNA@nortel.com Fri May 15 08:10: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 C2A733A691E for ; Fri, 15 May 2009 08:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 TmUyzAnsRHZx for ; Fri, 15 May 2009 08:10:37 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A58B63A68C5 for ; Fri, 15 May 2009 08:10:36 -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 n4FFAuQ04686; Fri, 15 May 2009 15:10:56 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: Fri, 15 May 2009 10:11:52 -0500 Message-ID: In-Reply-To: <200905151442.45142.julien.laganier.IETF@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Binding Revocation almost ready for IESG Thread-Index: AcnVWqN5su9cq6ZbT26td3yHtj4PDwAFH+RQ References: <200905121535.44991.julien.laganier.IETF@googlemail.com> <200905151442.45142.julien.laganier.IETF@googlemail.com> From: "Ahmad Muhanna" To: "Julien Laganier" Cc: mext@ietf.org Subject: Re: [MEXT] 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: Fri, 15 May 2009 15:10:37 -0000 > Subject: Re: Binding Revocation almost ready for IESG >=20 > Hello Ahmad,=20 >=20 > On Friday 15 May 2009, Ahmad Muhanna wrote: > > Hello Julien and All, > > > > Sorry for the delay, We have updated the Binding Revocation=20 > draft per=20 > > your comments and has been published. please let us know if=20 > you have=20 > > any comments. >=20 > Be serious, in IETF time units the delay was null :-) [Ahmad] :-) >=20 > Thanks for updating the draft quickly. At this point at this=20 > point I consider the draft ready to be sent to IESG and I'm=20 > working on the PROTO write-up, which as you might guess=20 > implies I'll be serving as the document shepherd thru IESG=20 > submission and RFC Editor processing.=20 [Ahmad] Sure. Thanks! Best Regards, Ahmad >=20 > Best, >=20 > --julien=20 >=20 > > ++++++++++++++++++++++ > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the Mobility EXTensions for=20 > IPv6 Working=20 > > Group of the IETF. > > > > > > Title : Binding Revocation for IPv6 Mobility > > Author(s) : A. Muhanna, et al. > > Filename : draft-ietf-mext-binding-revocation-06.txt > > Pages : 38 > > Date : 2009-05-15 > > > > This document defines a binding revocation mechanism to terminate a=20 > > mobile node's mobility session and the associated resources. These=20 > > semantics are generic enough and can be used by mobility=20 > entities in=20 > > the case of Mobile IPv6 and its extensions. This mechanism=20 > allows the=20 > > mobility entity which initiates the revocation procedure to request=20 > > its corresponding one to terminate either one, multiple or all=20 > > specified binding cache entries. > > > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocatio > >n-0 6.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > -----Original Message----- > > > From: Julien Laganier [mailto:julien.laganier.ietf@googlemail.com] > > > Sent: Tuesday, May 12, 2009 6:36 AM > > > To: Muhanna, Ahmad (RICH1:2H10) > > > Cc: mext@ietf.org; marcelo bagnulo braun; Vijay Devarapalli; Joel=20 > > > Hortelius; sgundave@cisco.com > > > Subject: Re: Binding Revocation almost ready for IESG > > > > > > Hello Ahmad, > > > > > > On Thursday 07 May 2009, Ahmad Muhanna wrote: > > > > Hello Julien, > > > > Thanks for the review. Please see comments inline. > > > > > > [...] > > > > > > > I will start working on the update and hopefully will be > > > > > > able to spin > > > > > > > a quick one soon. > > > > > > Sounds good, Ahmad. Looking forward to it. Thank you. > > > > > > --julien >=20 >=20 >=20 From marcelo@it.uc3m.es Fri May 15 16:44: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 A70E128C1B8 for ; Fri, 15 May 2009 16:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 tagged_above=-999 required=5 tests=[AWL=1.149, 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 7tCcbgEoBfZo for ; Fri, 15 May 2009 16:44:56 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 24E2428C192 for ; Fri, 15 May 2009 16:44:56 -0700 (PDT) Received: from r190-135-70-238.dialup.adsl.anteldata.net.uy (r190-135-70-238.dialup.adsl.anteldata.net.uy [190.135.70.238]) by smtp01.uc3m.es (Postfix) with ESMTP id 65872B4EC21; Sat, 16 May 2009 01:46:23 +0200 (CEST) Message-ID: <4A0DFECC.7030102@it.uc3m.es> Date: Sat, 16 May 2009 01:46:20 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Tsirtsis, George" , Hesham Soliman , 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-16644.003 Subject: [MEXT] about 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, 15 May 2009 23:44:57 -0000 Hi, Please find my comments about draft-ietf-mext-flow-binding-02.txt. Flow binding: An entry in the list of flow binding associated with a given mobile node. circular definition, please rephrase. BID-PRI This is a 7-bit field placing each BID to a relative priority with other registered BIDs. Value "0" is reserved for implementation of [I-D.ietf-monami6-multiplecoa] that do not support this specification. A higher number in this field indicates lower priority, Why is that? Is there a reason for having the higher value of a field called BID PRI to mean _lower_ priority or are we just trying hard to be counter intuitive? same comment applies to: FID-PRI This is an 8-bit priority field to indicate the priority of a particular option. This field is needed in cases where two different flow descriptions in two different options overlap. The priority field decides which policy should be in those cases. A lower number in this field indicates a higher priority. Later the drafts reads: The following values are reserved for the PRO field in this option: 0 Add a flow binding 1 Modify a flow binding I haven't read the whole draft yet, but wouldn't make sense to avoid this option. I mean, if the FID is new, then we create a new binding and if the FID already exists, then it is a modification. I mean, the problem with doing the approach described is that it has the potential of creating contradictory situations... for instance what happens if we receive an option with a value of 0 in the PRO field but there is no existing binding with the BID? (I mean, i understand that the flow binding messages are atomic i.e. that each time w new one is received it not an incremental change from the previous one, but it contains the complete information about the binding, correct? If that is the case, we better simply create a new one, even if the sender thinks this is a modifciation, since the msg actually provides all the information for the creation of the flow binding, correct?) later on the draft reads: 1 Forward. This value indicates a request to forward a flow to the address indicated in the Binding Reference sub-option. A single BID MUST be associated with this Action. ... 3 n-cast. This value indicates a request to replicate the flow to several addresses indicated in the Binding Reference sub-option. One or more BIDs MUST be associated with this Action. What is the difference between a n-cast value with a single BID and a Forward option? couldn't we just live with the n-cast option? (if it has only one BID, it has the same behaviour as the forward option? LAter on it reads: It should be noted that per-packet load balancing may have negative impacts on TCP congestion avoidance mechanisms as it is desirable to maintain order between packets belonging to the same TCP connection. This behaviour is specified in RFC2702 [RFC2702]. Other negative impacts are also foreseen for other types of real time connections due to the potential variations in RTT between packets. Hence per- packet load balancing is not currently supported in this extension. I fully agree with this, but i fail to see why this is the correct place to mention this. It probably belongs to somewhere else. Probably, we should make even a stronger statement, i.e. the flow bindings separating the packets of a TCP connection SHOULD NOT be used. The binding identifier option, defined in [I-D.ietf-monami6-multiplecoa], registering a given BID which is then indicated in the Binding Reference sub-option, MUST be either defined in the same or earlier BU from the one including the binding reference sub-option. I think what this sentence means, but I fail to parse it properly. I would suggest rephrasing 4.3. Flow Identification Summary Mobility Option TBD I guess more text is needed here... later on... The BIDs included in a given entry point to a corresponding entry in the binding cache for the purpose of identifying a care-of address. is there a verb missing in this sentence? later on Depending on the Action parameter in a given entry a valid BID is required to make the entry "active". How is that dependent of the action paramter? The text tha follows, seem to imply that an entry is active or inactvie depending on the BID not on the actions... later on... BID-PRI BID CoA --------- --- --- 20 1 IP1 30 3 IP2 30 2 IP3 Ordered BID Entries I would suggest moving this table right after the table describing the Ordered Flow Binding Entries 5.2. Mobile Node Considerations This specification allows the mobile node to maintain several bindings in its home agent and to direct packets to different care-of addresses according to flow bindings. I understnad that not only the HA maintains the bidnings but also the CN and the MAPs, so i think this should be included here. The home agent list of flow bindings is manipulated by the mobile node, via flow identification and flow summary options included in binding update messages. similar comment here. It is not only the HA list of bindings, but also the CN and MAP list of bindings, right? All flow binding state MUST be refreshed in every binding update the mobile node sends. Any previously registered flow binding that is not included in a given binding update will be deleted. So, any flow bindings that are not added or modified by a flow identification option, but have previously registered and need to be maintained MUST be included in a flow summary option. Only one flow summary option can be included in a given binding update. So, i really fail to see why we need the PRO bits. I mean, if every tome we sent a BU it will contain all the info about all the bindings, it is irrelevant if the binding is being created or modified in the options, since we are including all the information anyway. Note that any inactive flow bindings, i.e., flow bindings without associated BIDs that are marked as Inactive in the list of flow binding entries (see Section 4.4, MUST also be refreshed, or modified, to be maintained. If they are not included in a BU they will be removed. closing bracket missing 5.2.4. Removing flow bindings Removal of flow binging entries is performed implicitly by omission of a given FID from a binding update. To remove a flow binding the MN simply sends a binding update that includes flow identification and flow summary options for all the FIDs that need to be refreshed, modified, or added, and simply omits any FIDs that need to be removed. what if the MN sneds a BUt wihtout the Flow binding option? are all the flow bidings removed? - if the Action indicates 'n-cast', If the Binding reference sub-option is not included, the home agent MUST reject this flow binding add request by copying the flow identification option in the BA, and setting the Status field to 129 (Flow identification option poorly formed). If the Binding Reference sub-option is present and includes BIDs that are not present in the binding cache of the mobile node the home agent MUST reject this flow binding add request by copying the flow identification option in the BA, and setting the Status field to TBD (BID not known). If the Binding Reference sub-option is present and includes one or more BIDs, and the BIDs exist in the mobile node's binding cache, all the bods must exist? what if some exists and some don't? later on... If the value of any of the FID fields included in the flow summary option is not present in the list of flow binding entries for this mobile node, the home agent MUST reject this flow binding modify request is this option only carried in a modify request? I understood that also could be carried in an add request, correct? From hesham@elevatemobile.com Fri May 15 20:58: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 C21CE3A6B01 for ; Fri, 15 May 2009 20:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 3cZFuDIkXYun for ; Fri, 15 May 2009 20:58:28 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 1F4C33A6A53 for ; Fri, 15 May 2009 20:58:26 -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 1M5B3t-0001FN-Ca; Sat, 16 May 2009 13:59:50 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sat, 16 May 2009 13:58:26 +1000 From: Hesham Soliman To: marcelo bagnulo braun , "Tsirtsis, George" , mext Message-ID: Thread-Topic: about draft-ietf-mext-flow-binding-02.txt Thread-Index: AcnV2pB1Mw1lzVvkjUekTLpSMGMtVg== In-Reply-To: <4A0DFECC.7030102@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MEXT] about 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, 16 May 2009 03:58:29 -0000 Thanks for the detailed review. Some answers inline On 16/05/09 9:46 AM, "marcelo bagnulo braun" wrote: > Hi, > > Please find my comments about draft-ietf-mext-flow-binding-02.txt. > > > > Flow binding: An entry in the list of flow binding associated with > a given mobile node. > > circular definition, please rephrase. => ok. > > BID-PRI > > This is a 7-bit field placing each BID to a relative priority > with other registered BIDs. Value "0" is reserved for > implementation of [I-D.ietf-monami6-multiplecoa] that do not > support this specification. A higher number in this field > indicates lower priority, > > Why is that? Is there a reason for having the higher value of a field > called BID PRI to mean _lower_ priority or are we just trying hard to be > counter intuitive? => I think George added this in a way to be consistent with the PRI field, which you comment on below. Why is the PRI field that way? I don't know :) I guess I did that one day when I was feeling counter intuitive. We can reverse this > > same comment applies to: > > FID-PRI > > This is an 8-bit priority field to indicate the priority of a > particular option. This field is needed in cases where two > different flow descriptions in two different options overlap. > The priority field decides which policy should be in those > cases. A lower number in this field indicates a higher > priority. > > Later the drafts reads: > > The following values are reserved for the PRO field in this option: > > 0 Add a flow binding > > 1 Modify a flow binding > > I haven't read the whole draft yet, but wouldn't make sense to avoid > this option. I mean, if the FID is new, then we create a new binding and > if the FID already exists, then it is a modification. I mean, the > problem with doing the approach described is that it has the potential > of creating contradictory situations... for instance what happens if we > receive an option with a value of 0 in the PRO field but there is no > existing binding with the BID? => I think you mean 1 not 0. It would be an error, which illustrates the advantage of this, i.e. It catches any mismatch between the MN and HA. (I mean, i understand that the flow > binding messages are atomic i.e. that each time w new one is received it > not an incremental change from the previous one, but it contains the > complete information about the binding, correct? If that is the case, we > better simply create a new one, even if the sender thinks this is a > modifciation, since the msg actually provides all the information for > the creation of the flow binding, correct?) => It can be done this way if we don't care about catching mismatches. This orginally contained explicit deletes as well, which we removed. I know that it now seems redundant with only those two operations. > > > later on the draft reads: > > 1 Forward. This value indicates a request to forward a flow to > the address indicated in the Binding Reference sub-option. A > single BID MUST be associated with this Action. > ... > > 3 n-cast. This value indicates a request to replicate the flow to > several addresses indicated in the Binding Reference sub-option. > One or more BIDs MUST be associated with this Action. > > > What is the difference between a n-cast value with a single BID and a > Forward option? couldn't we just live with the n-cast option? (if it has > only one BID, it has the same behaviour as the forward option? => Yes we could. > > LAter on it reads: > > It should be noted that per-packet load balancing may have negative > impacts on TCP congestion avoidance mechanisms as it is desirable to > maintain order between packets belonging to the same TCP connection. > This behaviour is specified in RFC2702 [RFC2702]. Other negative > impacts are also foreseen for other types of real time connections > due to the potential variations in RTT between packets. Hence per- > packet load balancing is not currently supported in this extension. > > I fully agree with this, but i fail to see why this is the correct place > to mention this. It probably belongs to somewhere else. Probably, we > should make even a stronger statement, i.e. the flow bindings separating > the packets of a TCP connection SHOULD NOT be used. => Ok about placement. SHOULD NOT? I think this is a MUST NOT. Also, it affects any secure traffic with replay attack prevention. So it's not just TCP. That's why the entire option is not allowed in the draft. > > > The binding identifier option, defined in > [I-D.ietf-monami6-multiplecoa], registering a given BID which is then > indicated in the Binding Reference sub-option, MUST be either defined > in the same or earlier BU from the one including the binding > reference sub-option. > > I think what this sentence means, but I fail to parse it properly. I > would suggest rephrasing => ok. > > 4.3. Flow Identification Summary Mobility Option > > TBD > > I guess more text is needed here... > > later on... > > The BIDs included in a given entry point to a corresponding entry in > the binding cache for the purpose of identifying a care-of address. > > is there a verb missing in this sentence? => Yup needs rewording. > > later on > > Depending on the Action parameter in a given entry a valid BID is > required to make the entry "active". > > How is that dependent of the action paramter? > The text tha follows, seem to imply that an entry is active or inactvie > depending on the BID not on the actions... => Agreed, this is left over and erroneous. > > later on... > > BID-PRI BID CoA > --------- --- --- > 20 1 IP1 > 30 3 IP2 > 30 2 IP3 > > Ordered BID Entries > > I would suggest moving this table right after the table describing the > Ordered Flow Binding Entries => ok. > > 5.2. Mobile Node Considerations > > This specification allows the mobile node to maintain several > bindings in its home agent and to direct packets to different care-of > addresses according to flow bindings. > > I understnad that not only the HA maintains the bidnings but also the CN > and the MAPs, so i think this should be included here. => Agreed. > > The home agent list of flow bindings is manipulated by the mobile > node, via flow identification and flow summary options included in > binding update messages. > > similar comment here. It is not only the HA list of bindings, but also > the CN and MAP list of bindings, right? => Yes. > > All flow binding state MUST be refreshed in every binding update the > mobile node sends. Any previously registered flow binding that is > not included in a given binding update will be deleted. So, any flow > bindings that are not added or modified by a flow identification > option, but have previously registered and need to be maintained MUST > be included in a flow summary option. Only one flow summary option > can be included in a given binding update. > > So, i really fail to see why we need the PRO bits. I mean, if every tome > we sent a BU it will contain all the info about all the bindings, it is > irrelevant if the binding is being created or modified in the options, > since we are including all the information anyway. => Yeah, I think you have a point about this. Like I said earlier, it used to work different and contain more actions but I think you're right. > > Note that any inactive flow bindings, i.e., flow bindings without > associated BIDs that are marked as Inactive in the list of flow > binding entries (see Section 4.4, MUST also be refreshed, or > modified, to be maintained. If they are not included in a BU they > will be removed. > > closing bracket missing > > 5.2.4. Removing flow bindings > > Removal of flow binging entries is performed implicitly by omission > of a given FID from a binding update. > > To remove a flow binding the MN simply sends a binding update that > includes flow identification and flow summary options for all the > FIDs that need to be refreshed, modified, or added, and simply omits > any FIDs that need to be removed. > > what if the MN sneds a BUt wihtout the Flow binding option? are all the > flow bidings removed? => Without any FIDs? Yes they're all removed. > > - if the Action indicates 'n-cast', > > If the Binding reference sub-option is not included, the home > agent MUST reject this flow binding add request by copying the > flow identification option in the BA, and setting the Status field > to 129 (Flow identification option poorly formed). > > If the Binding Reference sub-option is present and includes BIDs > that are not present in the binding cache of the mobile node the > home agent MUST reject this flow binding add request by copying > the flow identification option in the BA, and setting the Status > field to TBD (BID not known). > > If the Binding Reference sub-option is present and includes one or > more BIDs, and the BIDs exist in the mobile node's binding cache, > > all the bods must exist? what if some exists and some don't? => What do you mean? You mean on a per FID or on aggregate? > > later on... > > If the value of any of the FID fields included in the flow summary > option is not present in the list of flow binding entries for this > mobile node, the home agent MUST reject this flow binding modify > request > > is this option only carried in a modify request? I understood that also > could be carried in an add request, correct? => Yes. Hesham > From marcelo@it.uc3m.es Sat May 16 04:57: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 BDD323A677D for ; Sat, 16 May 2009 04:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 EtpkjT2D3jFP for ; Sat, 16 May 2009 04:57:47 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id DF2CD3A6C6F for ; Sat, 16 May 2009 04:57:45 -0700 (PDT) Received: from r190-135-12-105.dialup.adsl.anteldata.net.uy (r190-135-12-105.dialup.adsl.anteldata.net.uy [190.135.12.105]) by smtp02.uc3m.es (Postfix) with ESMTP id 96CE865743D; Sat, 16 May 2009 13:59:15 +0200 (CEST) Message-ID: <4A0EAA92.5040505@it.uc3m.es> Date: Sat, 16 May 2009 13:59: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-16644.007 Cc: "Tsirtsis, George" , mext Subject: Re: [MEXT] about 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, 16 May 2009 11:57:48 -0000 Hesham Soliman escribió: > Thanks for the detailed review. Some answers inline > > > On 16/05/09 9:46 AM, "marcelo bagnulo braun" wrote: > > >> Hi, >> >> Please find my comments about draft-ietf-mext-flow-binding-02.txt. >> >> >> >> Flow binding: An entry in the list of flow binding associated with >> a given mobile node. >> >> circular definition, please rephrase. >> > > => ok. > > >> BID-PRI >> >> This is a 7-bit field placing each BID to a relative priority >> with other registered BIDs. Value "0" is reserved for >> implementation of [I-D.ietf-monami6-multiplecoa] that do not >> support this specification. A higher number in this field >> indicates lower priority, >> >> Why is that? Is there a reason for having the higher value of a field >> called BID PRI to mean _lower_ priority or are we just trying hard to be >> counter intuitive? >> > > => I think George added this in a way to be consistent with the PRI field, > which you comment on below. Why is the PRI field that way? I don't know :) I > guess I did that one day when I was feeling counter intuitive. We can > reverse this > > i would prefer that >> same comment applies to: >> >> FID-PRI >> >> This is an 8-bit priority field to indicate the priority of a >> particular option. This field is needed in cases where two >> different flow descriptions in two different options overlap. >> The priority field decides which policy should be in those >> cases. A lower number in this field indicates a higher >> priority. >> >> Later the drafts reads: >> >> The following values are reserved for the PRO field in this option: >> >> 0 Add a flow binding >> >> 1 Modify a flow binding >> >> I haven't read the whole draft yet, but wouldn't make sense to avoid >> this option. I mean, if the FID is new, then we create a new binding and >> if the FID already exists, then it is a modification. I mean, the >> problem with doing the approach described is that it has the potential >> of creating contradictory situations... for instance what happens if we >> receive an option with a value of 0 in the PRO field but there is no >> existing binding with the BID? >> > > => I think you mean 1 not 0. It would be an error, which illustrates the > advantage of this, i.e. It catches any mismatch between the MN and HA. > > :-) but one would expect people implementing this are smarter than me Anyway, i see below that you are fine with this, so > (I mean, i understand that the flow > >> binding messages are atomic i.e. that each time w new one is received it >> not an incremental change from the previous one, but it contains the >> complete information about the binding, correct? If that is the case, we >> better simply create a new one, even if the sender thinks this is a >> modifciation, since the msg actually provides all the information for >> the creation of the flow binding, correct?) >> > > => It can be done this way if we don't care about catching mismatches. This > orginally contained explicit deletes as well, which we removed. I know that > it now seems redundant with only those two operations. > > >> later on the draft reads: >> >> 1 Forward. This value indicates a request to forward a flow to >> the address indicated in the Binding Reference sub-option. A >> single BID MUST be associated with this Action. >> ... >> >> 3 n-cast. This value indicates a request to replicate the flow to >> several addresses indicated in the Binding Reference sub-option. >> One or more BIDs MUST be associated with this Action. >> >> >> What is the difference between a n-cast value with a single BID and a >> Forward option? couldn't we just live with the n-cast option? (if it has >> only one BID, it has the same behaviour as the forward option? >> > > => Yes we could. > > Again, if there is not special value in having the forward and n-cast separated, i would simplify it and have a single option for these, since it seems simpler >> LAter on it reads: >> >> It should be noted that per-packet load balancing may have negative >> impacts on TCP congestion avoidance mechanisms as it is desirable to >> maintain order between packets belonging to the same TCP connection. >> This behaviour is specified in RFC2702 [RFC2702]. Other negative >> impacts are also foreseen for other types of real time connections >> due to the potential variations in RTT between packets. Hence per- >> packet load balancing is not currently supported in this extension. >> >> I fully agree with this, but i fail to see why this is the correct place >> to mention this. It probably belongs to somewhere else. Probably, we >> should make even a stronger statement, i.e. the flow bindings separating >> the packets of a TCP connection SHOULD NOT be used. >> > > => Ok about placement. SHOULD NOT? I think this is a MUST NOT. don't have a strong opinion about this. > Also, it > affects any secure traffic with replay attack prevention. right so we need a statement not only about TCP. how would we scope the statement then? > So it's not just > TCP. That's why the entire option is not allowed in the draft. > > that makes sense to me, just that in the case of TCP, the performance is worse, so i am dubious if we need to use a MUST NOT or simply a SHOULD NOT >> The binding identifier option, defined in >> [I-D.ietf-monami6-multiplecoa], registering a given BID which is then >> indicated in the Binding Reference sub-option, MUST be either defined >> in the same or earlier BU from the one including the binding >> reference sub-option. >> >> I think what this sentence means, but I fail to parse it properly. I >> would suggest rephrasing >> > > => ok. > > >> 4.3. Flow Identification Summary Mobility Option >> >> TBD >> >> I guess more text is needed here... >> >> later on... >> >> The BIDs included in a given entry point to a corresponding entry in >> the binding cache for the purpose of identifying a care-of address. >> >> is there a verb missing in this sentence? >> > > => Yup needs rewording. > > >> later on >> >> Depending on the Action parameter in a given entry a valid BID is >> required to make the entry "active". >> >> How is that dependent of the action paramter? >> The text tha follows, seem to imply that an entry is active or inactvie >> depending on the BID not on the actions... >> > > => Agreed, this is left over and erroneous. > > >> later on... >> >> BID-PRI BID CoA >> --------- --- --- >> 20 1 IP1 >> 30 3 IP2 >> 30 2 IP3 >> >> Ordered BID Entries >> >> I would suggest moving this table right after the table describing the >> Ordered Flow Binding Entries >> > > => ok. > > >> 5.2. Mobile Node Considerations >> >> This specification allows the mobile node to maintain several >> bindings in its home agent and to direct packets to different care-of >> addresses according to flow bindings. >> >> I understnad that not only the HA maintains the bidnings but also the CN >> and the MAPs, so i think this should be included here. >> > > => Agreed. > > >> The home agent list of flow bindings is manipulated by the mobile >> node, via flow identification and flow summary options included in >> binding update messages. >> >> similar comment here. It is not only the HA list of bindings, but also >> the CN and MAP list of bindings, right? >> > > => Yes. > > >> All flow binding state MUST be refreshed in every binding update the >> mobile node sends. Any previously registered flow binding that is >> not included in a given binding update will be deleted. So, any flow >> bindings that are not added or modified by a flow identification >> option, but have previously registered and need to be maintained MUST >> be included in a flow summary option. Only one flow summary option >> can be included in a given binding update. >> >> So, i really fail to see why we need the PRO bits. I mean, if every tome >> we sent a BU it will contain all the info about all the bindings, it is >> irrelevant if the binding is being created or modified in the options, >> since we are including all the information anyway. >> > > => Yeah, I think you have a point about this. Like I said earlier, it used > to work different and contain more actions but I think you're right. > > ok >> Note that any inactive flow bindings, i.e., flow bindings without >> associated BIDs that are marked as Inactive in the list of flow >> binding entries (see Section 4.4, MUST also be refreshed, or >> modified, to be maintained. If they are not included in a BU they >> will be removed. >> >> closing bracket missing >> >> 5.2.4. Removing flow bindings >> >> Removal of flow binging entries is performed implicitly by omission >> of a given FID from a binding update. >> >> To remove a flow binding the MN simply sends a binding update that >> includes flow identification and flow summary options for all the >> FIDs that need to be refreshed, modified, or added, and simply omits >> any FIDs that need to be removed. >> >> what if the MN sneds a BUt wihtout the Flow binding option? are all the >> flow bidings removed? >> > > => Without any FIDs? Yes they're all removed. > > ok, it may be useful to state this (if nto already there and i missed it) >> - if the Action indicates 'n-cast', >> >> If the Binding reference sub-option is not included, the home >> agent MUST reject this flow binding add request by copying the >> flow identification option in the BA, and setting the Status field >> to 129 (Flow identification option poorly formed). >> >> If the Binding Reference sub-option is present and includes BIDs >> that are not present in the binding cache of the mobile node the >> home agent MUST reject this flow binding add request by copying >> the flow identification option in the BA, and setting the Status >> field to TBD (BID not known). >> >> If the Binding Reference sub-option is present and includes one or >> more BIDs, and the BIDs exist in the mobile node's binding cache, >> >> all the bods must exist? what if some exists and some don't? >> > > => What do you mean? You mean on a per FID or on aggregate? > > I mean i the last paragraph quoted above, it reads: If the Binding Reference sub-option is present and includes one or more BIDs, and the BIDs exist in the mobile node's binding cache, What if some BID exist and some other BIDs don't, how is the option processed? Regards, marcelo >> later on... >> >> If the value of any of the FID fields included in the flow summary >> option is not present in the list of flow binding entries for this >> mobile node, the home agent MUST reject this flow binding modify >> request >> >> is this option only carried in a modify request? I understood that also >> could be carried in an add request, correct? >> > > => Yes. > > Hesham > > > > > > From marcelo@it.uc3m.es Sat May 16 16:45: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 BFC223A6AF9 for ; Sat, 16 May 2009 16:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.365 X-Spam-Level: X-Spam-Status: No, score=-5.365 tagged_above=-999 required=5 tests=[AWL=1.234, 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 77KUx43KojCz for ; Sat, 16 May 2009 16:45:44 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1C0FF3A6DE9 for ; Sat, 16 May 2009 16:45:43 -0700 (PDT) Received: from r190-135-6-214.dialup.adsl.anteldata.net.uy (r190-135-6-214.dialup.adsl.anteldata.net.uy [190.135.6.214]) by smtp02.uc3m.es (Postfix) with ESMTP id 1AAF46C1490 for ; Sun, 17 May 2009 01:47:14 +0200 (CEST) Message-ID: <4A0F507E.5070204@it.uc3m.es> Date: Sun, 17 May 2009 01:47:10 +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-16646.003 Subject: [MEXT] weird idea about 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: Sat, 16 May 2009 23:45:45 -0000 Hi, Here goes a weird idea about how to do the flow bindings. What about if we only identify flows using the flow label? I mean, that instead of having to define a format to describe the flows, we simply include the flow label value of the specific flow in the flow bindings rules. This would imply basically that the MN host has the policy configured about which flow will flow through each CoA. the first packet of each flow will be received through the primary CoA (the one with highest priority). Upon the reception of the flow, if the MN wants to divert the flow through an alternative CoA, it sends a BU with the Flow binding option, including the Flow label value of the flow and the BID associated to the CoA it wants to use for this flow. The main drawbacks of this approach afaict is that the first packets will flow through the primary CoA, but i guess these should not be too many packets and that there is a need to send a BU per each flow that will be sent through a CoA other than the primary one. Maybe these are not too many, don't know. The nice thing is that this is fully extensible since we never have to encode bits refering to the upper layer headers in the BU. Anyway, i thought it may be good to bring this up for discussion. Regards, marcelo From tsirtsis@googlemail.com Sat May 16 18:19: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 502053A6938 for ; Sat, 16 May 2009 18:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=0.155, 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 SYxr1U+oxFde for ; Sat, 16 May 2009 18:19:08 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id EA3743A68A3 for ; Sat, 16 May 2009 18:19:07 -0700 (PDT) Received: by fxm2 with SMTP id 2so2616114fxm.37 for ; Sat, 16 May 2009 18:20:39 -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=h2ZuvvlhIbc3L6JGQLaVGEqPVzGn+GCn+SV7IvJXLRg=; b=mpJ5s8nJUN9yRMCW10dvhAPP/UkrS+YmoRwhoSWxetaVmIbs9JQRxafAWR7fxpVi0Q vSC0/MpO/Df59lct88Hs1Vys6anf6crm+fpnBCm5LlUqAWU7m34cD0ZFqeWpMKEjJJ2y tVfeIMdX9K255P7b/O9K08caTIxOQcY7TQZBA= 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=e6ZivliTK7GgQhqBW1Wr8EomDNjP9VdHeJXdzbpD4KWzRI3RSS+zl/B5HvdMjv0ajY E1eOvKmpkb7X+E/nd0MDsNqhBuvAy0CnF1/73kad5I0Ecuh64vIt7wTPsdArz7KU02iS eHs8/vkRDYsMmEQ41dILgZH2sn4oQf6N4gij8= MIME-Version: 1.0 Received: by 10.223.115.80 with SMTP id h16mr3614992faq.94.1242523239863; Sat, 16 May 2009 18:20:39 -0700 (PDT) In-Reply-To: <4A0F507E.5070204@it.uc3m.es> References: <4A0F507E.5070204@it.uc3m.es> Date: Sat, 16 May 2009 21:20:39 -0400 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001636c5b352565526046a117cdd Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 01:19:09 -0000 --001636c5b352565526046a117cdd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I am not sure I fully understand what you propose. If I understand correctly your scheme seems to assume the following: 1) what constitutes a "flow" is something fixed and is understood by both the MN and the HA. 2) "flows" start one at a time giving enough time to the MN, to send a BU to the HA to label (and optionally redirect) each one, before the next starts. These are far from safe assumptions, but maybe I did not understand your proposal in the first place. George On Sat, May 16, 2009 at 7:47 PM, marcelo bagnulo braun wrote: > Hi, > > Here goes a weird idea about how to do the flow bindings. > What about if we only identify flows using the flow label? > I mean, that instead of having to define a format to describe the flows, we > simply include the flow label value of the specific flow in the flow > bindings rules. > > This would imply basically that the MN host has the policy configured about > which flow will flow through each CoA. > the first packet of each flow will be received through the primary CoA (the > one with highest priority). > Upon the reception of the flow, if the MN wants to divert the flow through > an alternative CoA, it sends a BU with the Flow binding option, including > the Flow label value of the flow and the BID associated to the CoA it wants > to use for this flow. > > The main drawbacks of this approach afaict is that the first packets will > flow through the primary CoA, but i guess these should not be too many > packets and that there is a need to send a BU per each flow that will be > sent through a CoA other than the primary one. Maybe these are not too many, > don't know. > > The nice thing is that this is fully extensible since we never have to > encode bits refering to the upper layer headers in the BU. > > Anyway, i thought it may be good to bring this up for discussion. > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --001636c5b352565526046a117cdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am not sure I fully understand what you propose.

If I = understand correctly your scheme seems to assume the following:
<= br>
1) what constitutes a "flow" is something fixed and= is understood by both the MN and the HA.=C2=A0

2) "flows" start one at a time giving enough = time to the MN, to send a BU to the HA to label (and optionally redirect) e= ach one, before the next starts.

These are far fro= m safe assumptions, but maybe I did not understand your proposal in the fir= st place.

George


On Sat, May 16, 2009 at 7:47 PM, marcelo bagnulo braun <marcelo@it.uc3m.es><= /span> wrote:
Hi,

Here goes a weird idea about how to do the flow bindings.
What about if we only identify flows using the flow label?
I mean, that instead of having to define a format to describe the flows, we= simply include the flow label value of the specific flow in the flow bindi= ngs rules.

This would imply basically that the MN host has the policy configured about= which flow will flow through each CoA.
the first packet of each flow will be received through the primary CoA (the= one with highest priority).=C2=A0

Upon the reception of the flow, if the MN wants to divert the flow through = an alternative CoA, =C2=A0it sends a BU with the Flow binding option, inclu= ding the Flow label value of the flow and the BID associated to the CoA it = wants to use for this flow.

The main drawbacks of this approach afaict is that the first packets will f= low through the primary CoA, but i guess these should not be too many packe= ts and that there is a need to send a BU per each flow that will be sent th= rough a CoA other than the primary one. Maybe these are not too many, don&#= 39;t know.

The nice thing is that this is fully extensible since we never have to enco= de bits refering to the upper layer headers in the BU.

Anyway, i thought it may be good to bring this up for discussion.

Regards, marcelo

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

--001636c5b352565526046a117cdd-- From hesham@elevatemobile.com Sat May 16 20:33:03 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 F1FA43A6A59 for ; Sat, 16 May 2009 20:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 3EJ54lz4qsSR for ; Sat, 16 May 2009 20:33:01 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id EE1253A693E for ; Sat, 16 May 2009 20:32:59 -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 1M5X8w-0001DE-BE; Sun, 17 May 2009 13:34:30 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sun, 17 May 2009 13:34:20 +1000 From: Hesham Soliman To: marcelo bagnulo braun , mext Message-ID: Thread-Topic: [MEXT] weird idea about flow bindings Thread-Index: AcnWoFz9qInTVhKwwE6TXmeMwi2q4Q== In-Reply-To: <4A0F507E.5070204@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MEXT] weird idea about 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, 17 May 2009 03:33:03 -0000 The flow label should be part of any filter descriptor anyway. So at anytime A MN can send a BU specifying that packets with flow label X should be directed to CoA1. I'm not sure how your proposal changes/adds to this. As a general issue, the flow label is unlikely to be used for this purpose until we resolve it's mutability issues and until it is actually _used_ in the API. At least until recently no one was using it. But in any case, it should be in any flow descriptor for IPv6. We did have it in the initial draft. But having that is not mutually exclusive with having upper layer information IMO. Nor does it replace generic rules based on IP addresses/prefixes. Hesham On 17/05/09 9:47 AM, "marcelo bagnulo braun" wrote: > Hi, > > Here goes a weird idea about how to do the flow bindings. > What about if we only identify flows using the flow label? > I mean, that instead of having to define a format to describe the flows, > we simply include the flow label value of the specific flow in the flow > bindings rules. > > This would imply basically that the MN host has the policy configured > about which flow will flow through each CoA. > the first packet of each flow will be received through the primary CoA > (the one with highest priority). > Upon the reception of the flow, if the MN wants to divert the flow > through an alternative CoA, it sends a BU with the Flow binding option, > including the Flow label value of the flow and the BID associated to the > CoA it wants to use for this flow. > > The main drawbacks of this approach afaict is that the first packets > will flow through the primary CoA, but i guess these should not be too > many packets and that there is a need to send a BU per each flow that > will be sent through a CoA other than the primary one. Maybe these are > not too many, don't know. > > The nice thing is that this is fully extensible since we never have to > encode bits refering to the upper layer headers in the BU. > > Anyway, i thought it may be good to bring this up for discussion. > The flow > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Sat May 16 21:59: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 2F6413A6811 for ; Sat, 16 May 2009 21:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.502 X-Spam-Level: X-Spam-Status: No, score=-5.502 tagged_above=-999 required=5 tests=[AWL=1.097, 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 DIY6vXCV7ddM for ; Sat, 16 May 2009 21:59:39 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 2BF513A67FF for ; Sat, 16 May 2009 21:59:38 -0700 (PDT) Received: from r190-135-9-68.dialup.adsl.anteldata.net.uy (r190-135-9-68.dialup.adsl.anteldata.net.uy [190.135.9.68]) by smtp02.uc3m.es (Postfix) with ESMTP id 456046BA89B; Sun, 17 May 2009 07:01:07 +0200 (CEST) Message-ID: <4A0F9A11.8010702@it.uc3m.es> Date: Sun, 17 May 2009 07:01:05 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Tsirtsis References: <4A0F507E.5070204@it.uc3m.es> 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-16646.004 Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 04:59:46 -0000 George Tsirtsis escribió: > I am not sure I fully understand what you propose. > > If I understand correctly your scheme seems to assume the following: > > 1) what constitutes a "flow" is something fixed and is understood by > both the MN and the HA. i don't think i am assuming that I assume that the initiator of a flow will set the flow label and keep it unchanged for the duration of the flow > > 2) "flows" start one at a time giving enough time to the MN, to send a > BU to the HA to label (and optionally redirect) each one, before the > next starts. > no, i am assuming that the flow starts and upon the reception of the first packet of the flow, the MN redirects it to the correct CoA using a BU message. Basically, i am assuming that most of the flows that i care about are longer than one RTT between the MN and the HA. Is this safe? Regards, marcelo > These are far from safe assumptions, but maybe I did not understand > your proposal in the first place. > > George > > > On Sat, May 16, 2009 at 7:47 PM, marcelo bagnulo braun > > wrote: > > Hi, > > Here goes a weird idea about how to do the flow bindings. > What about if we only identify flows using the flow label? > I mean, that instead of having to define a format to describe the > flows, we simply include the flow label value of the specific flow > in the flow bindings rules. > > This would imply basically that the MN host has the policy > configured about which flow will flow through each CoA. > the first packet of each flow will be received through the primary > CoA (the one with highest priority). > > > Upon the reception of the flow, if the MN wants to divert the flow > through an alternative CoA, it sends a BU with the Flow binding > option, including the Flow label value of the flow and the BID > associated to the CoA it wants to use for this flow. > > The main drawbacks of this approach afaict is that the first > packets will flow through the primary CoA, but i guess these > should not be too many packets and that there is a need to send a > BU per each flow that will be sent through a CoA other than the > primary one. Maybe these are not too many, don't know. > > The nice thing is that this is fully extensible since we never > have to encode bits refering to the upper layer headers in the BU. > > Anyway, i thought it may be good to bring this up for discussion. > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From marcelo@it.uc3m.es Sat May 16 22:03: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 1D6A13A6A1E for ; Sat, 16 May 2009 22:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.612 X-Spam-Level: X-Spam-Status: No, score=-5.612 tagged_above=-999 required=5 tests=[AWL=0.987, 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 rDe4kOvRB1Lh for ; Sat, 16 May 2009 22:02:58 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id D51EF3A6B60 for ; Sat, 16 May 2009 22:02:57 -0700 (PDT) Received: from r190-135-9-68.dialup.adsl.anteldata.net.uy (r190-135-9-68.dialup.adsl.anteldata.net.uy [190.135.9.68]) by smtp03.uc3m.es (Postfix) with ESMTP id 9318172E4EB; Sun, 17 May 2009 07:04:29 +0200 (CEST) Message-ID: <4A0F9ADB.50605@it.uc3m.es> Date: Sun, 17 May 2009 07:04:27 +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-16646.004 Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 05:03:05 -0000 Hesham Soliman escribió: > The flow label should be part of any filter descriptor anyway. So at anytime > A MN can send a BU specifying that packets with flow label X should be > directed to CoA1. I'm not sure how your proposal changes/adds to this. > what i am saying is that you don't need anything else other than this > As a general issue, the flow label is unlikely to be used for this purpose > until we resolve it's mutability issues what mutability issues are you referring to? AFAIU, the flow label is set randomly b the source and remains unchanged e2e and for the duration of the flow. > and until it is actually _used_ in > the API. At least until recently no one was using it. > why do we need to have it in the API? It is only imporntat the the source sets it to a random value and keep it unchenged e2e and for the duration of the flow. I understand that these conditions are met today, right? > But in any case, it should be in any flow descriptor for IPv6. We did have > it in the initial draft. But having that is not mutually exclusive with > having upper layer information IMO. Nor does it replace generic rules based > on IP addresses/prefixes. > > that is exactly my point, if you use the flow label (and the source address) you don't need to use anything else and in partiuclar you don't need to embed upper layer information in the MIP BU signalling. Regards, marcelo > Hesham > > On 17/05/09 9:47 AM, "marcelo bagnulo braun" wrote: > > >> Hi, >> >> Here goes a weird idea about how to do the flow bindings. >> What about if we only identify flows using the flow label? >> I mean, that instead of having to define a format to describe the flows, >> we simply include the flow label value of the specific flow in the flow >> bindings rules. >> >> This would imply basically that the MN host has the policy configured >> about which flow will flow through each CoA. >> the first packet of each flow will be received through the primary CoA >> (the one with highest priority). >> Upon the reception of the flow, if the MN wants to divert the flow >> through an alternative CoA, it sends a BU with the Flow binding option, >> including the Flow label value of the flow and the BID associated to the >> CoA it wants to use for this flow. >> >> The main drawbacks of this approach afaict is that the first packets >> will flow through the primary CoA, but i guess these should not be too >> many packets and that there is a need to send a BU per each flow that >> will be sent through a CoA other than the primary one. Maybe these are >> not too many, don't know. >> >> The nice thing is that this is fully extensible since we never have to >> encode bits refering to the upper layer headers in the BU. >> >> Anyway, i thought it may be good to bring this up for discussion. >> The flow >> Regards, marcelo >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > > From hesham@elevatemobile.com Sun May 17 02:26:31 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 B8F6B3A6C51 for ; Sun, 17 May 2009 02:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 J5X+abUijBdv for ; Sun, 17 May 2009 02:26: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 79A443A6C63 for ; Sun, 17 May 2009 02:26:26 -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 1M5cez-00026g-OT; Sun, 17 May 2009 19:27:57 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sun, 17 May 2009 19:27:51 +1000 From: Hesham Soliman To: marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] weird idea about flow bindings Thread-Index: AcnW0b+7aAbXAUsfnUi2AJHz/BnNhw== In-Reply-To: <4A0F9ADB.50605@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 09:26:31 -0000 On 17/05/09 3:04 PM, "marcelo bagnulo braun" wrote: > Hesham Soliman escribi=F3: >> The flow label should be part of any filter descriptor anyway. So at any= time >> A MN can send a BU specifying that packets with flow label X should be >> directed to CoA1. I'm not sure how your proposal changes/adds to this. >> =20 >=20 > what i am saying is that you don't need anything else other than this =3D> see below >> As a general issue, the flow label is unlikely to be used for this purpo= se >> until we resolve it's mutability issues >=20 > what mutability issues are you referring to? > AFAIU, the flow label is set randomly b the source and remains unchanged > e2e and for the duration of the flow. =3D> I thought RFC 3697 talked about it being changed en route then changed back before it hits the destination. But I just scanned it and I can't find this text. Maybe it was never included. >> and until it is actually _used_ in >> the API. At least until recently no one was using it. >> =20 >=20 > why do we need to have it in the API? It is only imporntat the the > source sets it to a random value and keep it unchenged e2e and for the > duration of the flow. I understand that these conditions are met today, > right? =3D> But are you saying the src MIP6 module overwrites the potential flow label set in the API? Because it is possible that an app sets the flow label. RFC 3697 assumes the presence of an e2e mechanism to negotiate the flow label. If not then how do you make sure it's always unique? And how do you make sure that the CN echoes back the same value in the flow label? And what if the CN initiated the connection? Hesham From marcelo@it.uc3m.es Sun May 17 05:56: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 10A2E3A6A39 for ; Sun, 17 May 2009 05:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.092 X-Spam-Level: X-Spam-Status: No, score=-5.092 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 wDtdHGWjIPkj for ; Sun, 17 May 2009 05:56:31 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id BF8F73A69C9 for ; Sun, 17 May 2009 05:56:29 -0700 (PDT) Received: from r190-135-43-164.dialup.adsl.anteldata.net.uy (r190-135-43-164.dialup.adsl.anteldata.net.uy [190.135.43.164]) by smtp01.uc3m.es (Postfix) with ESMTP id 00CE8B49FD8; Sun, 17 May 2009 14:58:00 +0200 (CEST) Message-ID: <4A1009D8.4060703@it.uc3m.es> Date: Sun, 17 May 2009 14:58:00 +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-16646.007 Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 12:56:32 -0000 ok, let me try again because it seems i am failing miserably to communicate what i want to say (or it simply so broken that people cannot believe what they are reading :-) Let's try with an example. We have the MN who has two CoAs, CoA1 and CoA2. The MN has a policy that says that it wants flows from app1 to be exchanged through CoA1 (well, the policy would say that they should be received by the interfece in which CoA1 is configured) and that flows from app2 to be exchanged through CoA2 (same comment about the interface applies here) In addition, MN has defined CoA1 to be the primary CoA i.e. the CoA with highest priority. So, we have two different situations. Either the MN starts the communication or the CN starts the communication. Actually, this is pretty irrelevant, cause the two directions of a connections are handled independently. the MN will send packets from app1 through CoA1 and packets from app2 through CoA2 and it doesn't need any additional actions from the HA for outgoing packets. Now, the difficulty is with incoming packets. the MN needs to inform the HA about which CoA it wants to use to receive any flow. Suppose that the HA has no flow bindings for the MN so far. So, suppose that the app1 in CN starts a flow to the MN. The HA will receive the packet and will send it though the CoA1 cause it is the one with higher priority. the MN is happy and there is no need to do anything else. Suppose now that the app2 in the CN starts a flow to the MN. According to RFC3697, the CN SHOULD assign a different flow label to the packets belonging to this flow e.g. to this TCP connection. Let's assume it is actually a TCP connection to make the example more concrete. So, app2 opens a TCP connection to MN. CN then sends the TCP SYN to the MN. The HA receives the TCP SYN and since there is no flow binding state for this flow it forwards it through the CoA1 (the one with highest priority) The MN receives the TCP SYN through CoA1 and it realizes that this is not compliant with its flow policy. So, it extracts the flow label value, the src address and the dest address and it sends a BU to the HA stating that the flow identified by the flow label, src add and dest add needs to be bound to the CoA2. Simultaneously, it also sends the TCP SYN+ACK back to the CN. The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives the ACk and will forward it based on the flow binding, i.e. through the CoA. the result is a method that never looks into higher layer information for setting the flows. makes sense? Regards, marcelo Hesham Soliman escribió: > > On 17/05/09 3:04 PM, "marcelo bagnulo braun" wrote: > > >> Hesham Soliman escribió: >> >>> The flow label should be part of any filter descriptor anyway. So at anytime >>> A MN can send a BU specifying that packets with flow label X should be >>> directed to CoA1. I'm not sure how your proposal changes/adds to this. >>> >>> >> what i am saying is that you don't need anything else other than this >> > > => see below > > >>> As a general issue, the flow label is unlikely to be used for this purpose >>> until we resolve it's mutability issues >>> >> what mutability issues are you referring to? >> AFAIU, the flow label is set randomly b the source and remains unchanged >> e2e and for the duration of the flow. >> > > => I thought RFC 3697 talked about it being changed en route then changed > back before it hits the destination. But I just scanned it and I can't find > this text. Maybe it was never included. > > >>> and until it is actually _used_ in >>> the API. At least until recently no one was using it. >>> >>> >> why do we need to have it in the API? It is only imporntat the the >> source sets it to a random value and keep it unchenged e2e and for the >> duration of the flow. I understand that these conditions are met today, >> right? >> > > => But are you saying the src MIP6 module overwrites the potential flow > label set in the API? Because it is possible that an app sets the flow > label. RFC 3697 assumes the presence of an e2e mechanism to negotiate the > flow label. If not then how do you make sure it's always unique? And how do > you make sure that the CN echoes back the same value in the flow label? > And what if the CN initiated the connection? > > Hesham > > > > > From tsirtsis@googlemail.com Sun May 17 06:15: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 8694C3A6C49 for ; Sun, 17 May 2009 06:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 vH4JB325pu4f for ; Sun, 17 May 2009 06:15:02 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 0A67E3A6BF1 for ; Sun, 17 May 2009 06:15:01 -0700 (PDT) Received: by bwz22 with SMTP id 22so2743876bwz.37 for ; Sun, 17 May 2009 06:16: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; bh=3WkBMW8aNXipKAi6Dy9geL6GxC64ubQ6S9yE7QQ/1yg=; b=pdSshoWqZb3TkoHouaoIyvwyKuWqNhCwmjZ6AumBuvU7kigR/Ytd13XCkBMksCi13g hidbD6mOurYfVe7UgLj6baILZBIhzfuS5VUZPEiZFYYbCyorXOUrSKUJuLplBpi+x3ay D9e7WuH4i4gnDTEp+NHVMIEyT1D/C9y6mrxVc= 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=JcQVbWvN+CDifClzcongC17CE2fSX9JcKU8NRIyrbOEIkKkbWclkJqew4h5vvV2mTJ /gi4zQK/bxEgSLSKCtvfUD0EUh4xSaeuo+PY6wf8f5MB2NEKiCGCv1pj3L+1Yd2kMQ47 0qKIfgINaOYTUC5K1zsl+RFha6+xLpH0OxNLc= MIME-Version: 1.0 Received: by 10.223.109.19 with SMTP id h19mr3750411fap.20.1242566194148; Sun, 17 May 2009 06:16:34 -0700 (PDT) In-Reply-To: <4A1009D8.4060703@it.uc3m.es> References: <4A1009D8.4060703@it.uc3m.es> Date: Sun, 17 May 2009 09:16:34 -0400 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001636c5adf49cb875046a1b7c9f Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 13:15:10 -0000 --001636c5adf49cb875046a1b7c9f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Marcelo, I now understand what you propose better. and it makes more sense than I initially thought. Two issues, though: 1) this requires the CN to cooperate i.e., make proper use of flow labels. It is not clear to me that even if all nodes populated the flow label (whic= h I think is not even true), its use would be universally consistent in a way that would ensure that the setting of the flow label by the CN would be inline with what the MN would like to identify as a flow. 2) This does not work for IPv4 traffic. Thoughts? George On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun wrote: > ok, let me try again because it seems i am failing miserably to communica= te > what i want to say (or it simply so broken that people cannot believe wha= t > they are reading :-) > > Let's try with an example. > > We have the MN who has two CoAs, CoA1 and CoA2. > > The MN has a policy that says that it wants flows from app1 to be exchang= ed > through CoA1 (well, the policy would say that they should be received by = the > interfece in which CoA1 is configured) and that flows from app2 to be > exchanged through CoA2 (same comment about the interface applies here) > > In addition, MN has defined CoA1 to be the primary CoA i.e. the CoA with > highest priority. > > So, we have two different situations. Either the MN starts the > communication or the CN starts the communication. Actually, this is prett= y > irrelevant, cause the two directions of a connections are handled > independently. the MN will send packets from app1 through CoA1 and packet= s > from app2 through CoA2 and it doesn't need any additional actions from th= e > HA for outgoing packets. > > Now, the difficulty is with incoming packets. the MN needs to inform the = HA > about which CoA it wants to use to receive any flow. > > Suppose that the HA has no flow bindings for the MN so far. > > So, suppose that the app1 in CN starts a flow to the MN. The HA will > receive the packet and will send it though the CoA1 cause it is the one w= ith > higher priority. the MN is happy and there is no need to do anything else= . > > Suppose now that the app2 in the CN starts a flow to the MN. According to > RFC3697, the CN SHOULD assign a different flow label to the packets > belonging to this flow e.g. to this TCP connection. Let's assume it is > actually a TCP connection to make the example more concrete. > So, app2 opens a TCP connection to MN. CN then sends the TCP SYN to the M= N. > The HA receives the TCP SYN and since there is no flow binding state for > this flow it forwards it through the CoA1 (the one with highest priority) > The MN receives the TCP SYN through CoA1 and it realizes that this is not > compliant with its flow policy. So, it extracts the flow label value, the > src address and the dest address and it sends a BU to the HA stating that > the flow identified by the flow label, src add and dest add needs to be > bound to the CoA2. > Simultaneously, it also sends the TCP SYN+ACK back to the CN. > The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives t= he > ACk and will forward it based on the flow binding, i.e. through the CoA. > > the result is a method that never looks into higher layer information for > setting the flows. > > makes sense? > > Regards, marcelo > > > Hesham Soliman escribi=C3=B3: > > >> On 17/05/09 3:04 PM, "marcelo bagnulo braun" wrote: >> >> >> >>> Hesham Soliman escribi=C3=B3: >>> >>> >>>> The flow label should be part of any filter descriptor anyway. So at >>>> anytime >>>> A MN can send a BU specifying that packets with flow label X should be >>>> directed to CoA1. I'm not sure how your proposal changes/adds to this. >>>> >>>> >>> what i am saying is that you don't need anything else other than this >>> >>> >> >> =3D> see below >> >> >> >>> As a general issue, the flow label is unlikely to be used for this >>>> purpose >>>> until we resolve it's mutability issues >>>> >>>> >>> what mutability issues are you referring to? >>> AFAIU, the flow label is set randomly b the source and remains unchange= d >>> e2e and for the duration of the flow. >>> >>> >> >> =3D> I thought RFC 3697 talked about it being changed en route then chan= ged >> back before it hits the destination. But I just scanned it and I can't >> find >> this text. Maybe it was never included. >> >> >> >>> and until it is actually _used_ in >>>> the API. At least until recently no one was using it. >>>> >>>> >>> why do we need to have it in the API? It is only imporntat the the >>> source sets it to a random value and keep it unchenged e2e and for the >>> duration of the flow. I understand that these conditions are met today, >>> right? >>> >>> >> >> =3D> But are you saying the src MIP6 module overwrites the potential flo= w >> label set in the API? Because it is possible that an app sets the flow >> label. RFC 3697 assumes the presence of an e2e mechanism to negotiate th= e >> flow label. If not then how do you make sure it's always unique? And how >> do >> you make sure that the CN echoes back the same value in the flow label? >> And what if the CN initiated the connection? >> >> Hesham >> >> >> >> >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --001636c5adf49cb875046a1b7c9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Marcelo, I now understand what you propose better. and it makes more sen= se than I initially thought.

Two issues, though:

1) this requires the CN to cooperate i.e., make proper us= e of flow labels. It is not clear to me that even if all nodes populated th= e flow label (which I think is not even true), its use would be=C2=A0univer= sally consistent=C2=A0in a way that would ensure that the setting of the fl= ow label by the CN would be inline with what the MN would like to identify = as a flow.=C2=A0

2) This does not work for IPv4 traffic.

<= /div>
Thoughts?
George=C2=A0

On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun = <marcelo@it.uc3m.es>= wrote:
ok, let me try again because it seems i am = failing miserably to communicate what i want to say (or it simply so broken= that people cannot believe what they are reading :-)

Let's try with an example.

We have the MN who has two CoAs, CoA1 and CoA2.

The MN has a policy that says that it wants flows from app1 to be exchanged= through CoA1 (well, the policy would say that they should be received by t= he interfece in which CoA1 is configured) and that flows from app2 to be ex= changed through CoA2 (same comment about the interface applies here)

In addition, MN has defined CoA1 to be the primary CoA i.e. the CoA with hi= ghest priority.

So, we have two different situations. Either the MN starts the communicatio= n or the CN starts the communication. Actually, this is pretty irrelevant, = cause the two directions of a connections are handled independently. the MN= will send packets from app1 through CoA1 and packets from app2 through CoA= 2 and it doesn't need any additional actions from the HA for outgoing p= ackets.

Now, the difficulty is with incoming packets. the MN needs to inform the HA= about which CoA it wants to use to receive any flow.

Suppose that the HA has no flow bindings for the MN so far.

So, suppose that the app1 in CN starts a flow to the MN. The HA will receiv= e the packet and will send it though the CoA1 cause it is the one with high= er priority. the MN is happy and there is no need to do anything else.

Suppose now that the app2 in the CN starts a flow to the MN. According to R= FC3697, the CN SHOULD assign a different flow label to the packets belongin= g to this flow e.g. to this TCP connection. Let's assume it is actually= a TCP connection to make the example more concrete.
So, app2 opens a TCP connection to MN. CN then sends the TCP SYN to the MN.=
The HA receives the TCP SYN and since there is no flow binding state for th= is flow it forwards it through the CoA1 (the one with highest priority)
The MN receives the TCP SYN through CoA1 and it realizes that this is not c= ompliant with its flow policy. So, it extracts the flow label value, the sr= c address and the dest address and it sends a BU to the HA stating that the= flow identified by the flow label, src add and dest add needs to be bound = to the CoA2.
Simultaneously, it also sends the TCP SYN+ACK back to the CN.
The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives the= ACk and will forward it based on the flow binding, i.e. through the CoA.
the result is a method that never looks into higher layer information for s= etting the flows.

makes sense?

Regards, marcelo


Hesham Soliman escribi=C3=B3:


On 17/05/09 3:04 PM, "marcelo bagnulo braun" <marcelo@it.uc3m.es> wrote:
=C2=A0
Hesham Soliman escribi=C3=B3:
=C2=A0 =C2=A0
The flow label should be part of any filter descriptor anyway. So at anytim= e
A MN can send a BU specifying that packets with flow label X should be
directed to CoA1. I'm not sure how your proposal changes/adds to this.<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0
what i am saying is that you don't need anything else other than this =C2=A0 =C2=A0

=3D> see below

=C2=A0
As a general issue, the flow label is unlikely to be used for this purpose<= br> until we resolve it's mutability issues
=C2=A0 =C2=A0 =C2=A0
what mutability issues are you referring to?
AFAIU, the flow label is set randomly b the source and remains unchanged e2e and for the duration of the flow.
=C2=A0 =C2=A0

=3D> I thought RFC 3697 talked about it being changed en route then chan= ged
back before it hits the destination. But I just scanned it and I can't = find
this text. Maybe it was never included.

=C2=A0
=C2=A0and until it is actually _used_ in
the API. At least until recently no one was using it.
=C2=A0 =C2=A0 =C2=A0 =C2=A0
why do we need to have it in the API? It is only imporntat the the
source sets it to a random value and keep it unchenged e2e and for the
duration of the flow. I understand that these conditions are met today,
right?
=C2=A0 =C2=A0

=3D> But are you saying the src MIP6 module overwrites the potential flo= w
label set in the API? Because it is possible that an app sets the flow
label. RFC 3697 assumes the presence of an e2e mechanism to negotiate the flow label. If not then how do you make sure it's always unique? And ho= w do
you make sure that the CN echoes back the same value in the flow label?
And what if the CN initiated the connection?

Hesham




=C2=A0

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

--001636c5adf49cb875046a1b7c9f-- From hesham@elevatemobile.com Sun May 17 06:22: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 5D48B3A6C3C for ; Sun, 17 May 2009 06:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, J_CHICKENPOX_33=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 OpfY3PF7lyfi for ; Sun, 17 May 2009 06:22:25 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4BCF828C0DB for ; Sun, 17 May 2009 06:22:24 -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 1M5gLK-0001Mb-Tc; Sun, 17 May 2009 23:23:55 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sun, 17 May 2009 23:23:48 +1000 From: Hesham Soliman To: marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] weird idea about flow bindings Thread-Index: AcnW8rX2eqElsPSZA0eInBW5c8rb2A== In-Reply-To: <4A1009D8.4060703@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 13:22:32 -0000 Thanks fpr the long version! Yes it works of course. That's why I agree tha= t it should be in every filter descriptor. However, since it's not currently used at all, I don't think we can remove upper layer information. We need t= o allow both to exist until the flow label is actually used. So, to summarise= : yes by all means we have to make sure it's in every spec defining filters (which this draft is not btw), but not the only way of defining filters. We should also make sure the SPI is one of those parameters for instance. Hesham On 17/05/09 10:58 PM, "marcelo bagnulo braun" wrote: > ok, let me try again because it seems i am failing miserably to > communicate what i want to say (or it simply so broken that people > cannot believe what they are reading :-) >=20 > Let's try with an example. >=20 > We have the MN who has two CoAs, CoA1 and CoA2. >=20 > The MN has a policy that says that it wants flows from app1 to be > exchanged through CoA1 (well, the policy would say that they should be > received by the interfece in which CoA1 is configured) and that flows > from app2 to be exchanged through CoA2 (same comment about the interface > applies here) >=20 > In addition, MN has defined CoA1 to be the primary CoA i.e. the CoA with > highest priority. >=20 > So, we have two different situations. Either the MN starts the > communication or the CN starts the communication. Actually, this is > pretty irrelevant, cause the two directions of a connections are handled > independently. the MN will send packets from app1 through CoA1 and > packets from app2 through CoA2 and it doesn't need any additional > actions from the HA for outgoing packets. >=20 > Now, the difficulty is with incoming packets. the MN needs to inform the > HA about which CoA it wants to use to receive any flow. >=20 > Suppose that the HA has no flow bindings for the MN so far. >=20 > So, suppose that the app1 in CN starts a flow to the MN. The HA will > receive the packet and will send it though the CoA1 cause it is the one > with higher priority. the MN is happy and there is no need to do > anything else. >=20 > Suppose now that the app2 in the CN starts a flow to the MN. According > to RFC3697, the CN SHOULD assign a different flow label to the packets > belonging to this flow e.g. to this TCP connection. Let's assume it is > actually a TCP connection to make the example more concrete. > So, app2 opens a TCP connection to MN. CN then sends the TCP SYN to the M= N. > The HA receives the TCP SYN and since there is no flow binding state for > this flow it forwards it through the CoA1 (the one with highest priority) > The MN receives the TCP SYN through CoA1 and it realizes that this is > not compliant with its flow policy. So, it extracts the flow label > value, the src address and the dest address and it sends a BU to the HA > stating that the flow identified by the flow label, src add and dest add > needs to be bound to the CoA2. > Simultaneously, it also sends the TCP SYN+ACK back to the CN. > The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives > the ACk and will forward it based on the flow binding, i.e. through the C= oA. >=20 > the result is a method that never looks into higher layer information > for setting the flows. >=20 > makes sense? >=20 > Regards, marcelo >=20 >=20 > Hesham Soliman escribi=F3: >>=20 >> On 17/05/09 3:04 PM, "marcelo bagnulo braun" wrote: >>=20 >> =20 >>> Hesham Soliman escribi=F3: >>> =20 >>>> The flow label should be part of any filter descriptor anyway. So at >>>> anytime >>>> A MN can send a BU specifying that packets with flow label X should be >>>> directed to CoA1. I'm not sure how your proposal changes/adds to this. >>>> =20 >>>> =20 >>> what i am saying is that you don't need anything else other than this >>> =20 >>=20 >> =3D> see below >>=20 >> =20 >>>> As a general issue, the flow label is unlikely to be used for this pur= pose >>>> until we resolve it's mutability issues >>>> =20 >>> what mutability issues are you referring to? >>> AFAIU, the flow label is set randomly b the source and remains unchange= d >>> e2e and for the duration of the flow. >>> =20 >>=20 >> =3D> I thought RFC 3697 talked about it being changed en route then change= d >> back before it hits the destination. But I just scanned it and I can't f= ind >> this text. Maybe it was never included. >>=20 >> =20 >>>> and until it is actually _used_ in >>>> the API. At least until recently no one was using it. >>>> =20 >>>> =20 >>> why do we need to have it in the API? It is only imporntat the the >>> source sets it to a random value and keep it unchenged e2e and for the >>> duration of the flow. I understand that these conditions are met today, >>> right? >>> =20 >>=20 >> =3D> But are you saying the src MIP6 module overwrites the potential flow >> label set in the API? Because it is possible that an app sets the flow >> label. RFC 3697 assumes the presence of an e2e mechanism to negotiate th= e >> flow label. If not then how do you make sure it's always unique? And how= do >> you make sure that the CN echoes back the same value in the flow label? >> And what if the CN initiated the connection? >>=20 >> Hesham >>=20 >>=20 >>=20 >>=20 >> =20 >=20 From arno@natisbad.org Sun May 17 06:24: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 06CC83A6DAE for ; Sun, 17 May 2009 06:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 5F1TxsxHC51w for ; Sun, 17 May 2009 06:24:18 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 0F43C3A6BF1 for ; Sun, 17 May 2009 06:24:18 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M5gNA-00040V-Lh; Sun, 17 May 2009 15:25:49 +0200 X-Hashcash: 1:20:090517:charliep@wichorus.com::1q/ZfTHLjmXP4eY7:00000000000000000000000000000000000000000lIw X-Hashcash: 1:20:090517:mext@ietf.org::FQUEzs0troLlZjyk:00004cTO From: arno@natisbad.org (Arnaud Ebalard) To: "Charles E. Perkins" X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Sun, 17 May 2009 15:26:26 +0200 Message-ID: <87zldbvp19.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IETF MEXT WG ML Subject: [MEXT] RFC 3775 clarification on MPS emission when receiving MPA 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, 17 May 2009 13:24:25 -0000 Hi Charles, The issue described below was reported by an user of UMIP on nautilus6 mailing list. I was trying to address it in the code but thought the expected behavior was not very explicit in RFC 3775. Hence the request for clarification. A MN sends a MPS to its HA, the RTT between the HA and the MN is a bit more than the INITIAL_SOLICIT_TIMER value of 3 seconds which implies that the MN will receive the MPA from the HA, just after sending a new one. In that case (just like it is expected and done for Binding Update sequence number), the reemitted MPS has been sent by UMIP with a new random ICMPv6 identifier. Because the received MPA obviously did not arrive in time and so does not match expected ICMPv6 identifier, we end up section 11.4.3 of RFC 3775 (not modified in 3775bis, AFAICT), which contains the following: When a mobile node receives a Mobile Prefix Advertisement, it MUST validate it according to the following test: o The Source Address of the IP packet carrying the Mobile Prefix Advertisement is the same as the home agent address to which the mobile node last sent an accepted home registration Binding Update to register its primary care-of address. Otherwise, if no such registrations have been made, it SHOULD be the mobile node's stored home agent address, if one exists. Otherwise, if the mobile node has not yet discovered its home agent's address, it MUST NOT accept Mobile Prefix Advertisements. o The packet MUST have a type 2 routing header and SHOULD be protected by an IPsec header as described in Section 5.4 and Section 6.8. o If the ICMP Identifier value matches the ICMP Identifier value of the most recently sent Mobile Prefix Solicitation and no other advertisement has yet been received for this value, then the advertisement is considered to be solicited and will be processed further. Otherwise, the advertisement is unsolicited, and MUST be discarded. In this case the mobile node SHOULD send a Mobile Prefix Solicitation. Any received Mobile Prefix Advertisement not meeting these tests MUST be silently discarded. I am interested in the content of the last item of the list and the final sentence, i.e. how they should be understood in the following situation. At the moment, UMIP follows the content of the second part of last bullet, i.e. considers the advertisement is unsolicited, discards it but *sends a MPS* (following the SHOULD). The timeout value being set to INITIAL_SOLICIT_TIMER for that new MPS, the exact same thing happens again when receiving the response from the HA. Having read the content of following sections of RFC 3775: - 6.7. ICMP Mobile Prefix Solicitation Message Format - 11.4.2. Sending Mobile Prefix Solicitations - 11.4.3. Receiving Mobile Prefix Advertisements - 11.8. Retransmissions and Rate Limiting i am under the impression that the good way to go is to randomize ICMPv6 identifier in MPS *only when sending* the MPS for the first time and keep that value for reemissions. Or am I missing something? Thanks in advance for your comments, Cheers, a+ From marcelo@it.uc3m.es Sun May 17 07:02: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 B53103A682B for ; Sun, 17 May 2009 07:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.116 X-Spam-Level: X-Spam-Status: No, score=-5.116 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 vsQmicO2Bf54 for ; Sun, 17 May 2009 07:02:03 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1CA993A6CF6 for ; Sun, 17 May 2009 07:02:02 -0700 (PDT) Received: from r190-135-43-164.dialup.adsl.anteldata.net.uy (r190-135-43-164.dialup.adsl.anteldata.net.uy [190.135.43.164]) by smtp02.uc3m.es (Postfix) with ESMTP id 68D2B65A41E; Sun, 17 May 2009 16:03:33 +0200 (CEST) Message-ID: <4A101933.6060504@it.uc3m.es> Date: Sun, 17 May 2009 16:03:31 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Tsirtsis References: <4A1009D8.4060703@it.uc3m.es> 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-16646.007 Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 14:02:04 -0000 George Tsirtsis escribió: > Hi Marcelo, I now understand what you propose better. and it makes > more sense than I initially thought. > > Two issues, though: > > 1) this requires the CN to cooperate i.e., make proper use of flow labels. according to RFC3697: To enable Flow Label based classification, source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow. ... To enable applications and transport protocols to define what packets constitute a flow, the source node MUST provide means for the applications and transport protocols to specify the Flow Label values to be used with their flows. The use of the means to specify Flow Label values is subject to appropriate privileges (see section 5.1). The source node SHOULD be able to select unused Flow Label values for flows not requesting a specific value to be used. So, yes but node should do this if they expect things to work properly > It is not clear to me that even if all nodes populated the flow label > (which I think is not even true) does anybody has information about the support of RFC3697 in current OSes? > , its use would be universally consistent in a way that would ensure > that the setting of the flow label by the CN would be inline with what > the MN would like to identify as a flow. > that would determine the granularity of the method I am not sure the spectrum of choices is so big that this can be a problem could you think of some very different criteria to define what a flow is that this would be an issue? > 2) This does not work for IPv4 traffic. > i don't buy this argument. If we apply this argument, then we could never use the flow label for anything, since it doesn't work for IPv4. Reagrds, marcelo > Thoughts? > George > > On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun > > wrote: > > ok, let me try again because it seems i am failing miserably to > communicate what i want to say (or it simply so broken that people > cannot believe what they are reading :-) > > Let's try with an example. > > We have the MN who has two CoAs, CoA1 and CoA2. > > The MN has a policy that says that it wants flows from app1 to be > exchanged through CoA1 (well, the policy would say that they > should be received by the interfece in which CoA1 is configured) > and that flows from app2 to be exchanged through CoA2 (same > comment about the interface applies here) > > In addition, MN has defined CoA1 to be the primary CoA i.e. the > CoA with highest priority. > > So, we have two different situations. Either the MN starts the > communication or the CN starts the communication. Actually, this > is pretty irrelevant, cause the two directions of a connections > are handled independently. the MN will send packets from app1 > through CoA1 and packets from app2 through CoA2 and it doesn't > need any additional actions from the HA for outgoing packets. > > Now, the difficulty is with incoming packets. the MN needs to > inform the HA about which CoA it wants to use to receive any flow. > > Suppose that the HA has no flow bindings for the MN so far. > > So, suppose that the app1 in CN starts a flow to the MN. The HA > will receive the packet and will send it though the CoA1 cause it > is the one with higher priority. the MN is happy and there is no > need to do anything else. > > Suppose now that the app2 in the CN starts a flow to the MN. > According to RFC3697, the CN SHOULD assign a different flow label > to the packets belonging to this flow e.g. to this TCP connection. > Let's assume it is actually a TCP connection to make the example > more concrete. > So, app2 opens a TCP connection to MN. CN then sends the TCP SYN > to the MN. > The HA receives the TCP SYN and since there is no flow binding > state for this flow it forwards it through the CoA1 (the one with > highest priority) > The MN receives the TCP SYN through CoA1 and it realizes that this > is not compliant with its flow policy. So, it extracts the flow > label value, the src address and the dest address and it sends a > BU to the HA stating that the flow identified by the flow label, > src add and dest add needs to be bound to the CoA2. > Simultaneously, it also sends the TCP SYN+ACK back to the CN. > The CN receives the TCP SYN+ACK and sends the Ack back. the HA > receives the ACk and will forward it based on the flow binding, > i.e. through the CoA. > > the result is a method that never looks into higher layer > information for setting the flows. > > makes sense? > > Regards, marcelo > > > Hesham Soliman escribió: > > > On 17/05/09 3:04 PM, "marcelo bagnulo braun" > > wrote: > > > > Hesham Soliman escribió: > > > The flow label should be part of any filter descriptor > anyway. So at anytime > A MN can send a BU specifying that packets with flow > label X should be > directed to CoA1. I'm not sure how your proposal > changes/adds to this. > > > what i am saying is that you don't need anything else > other than this > > > > => see below > > > > As a general issue, the flow label is unlikely to be > used for this purpose > until we resolve it's mutability issues > > > what mutability issues are you referring to? > AFAIU, the flow label is set randomly b the source and > remains unchanged > e2e and for the duration of the flow. > > > > => I thought RFC 3697 talked about it being changed en route > then changed > back before it hits the destination. But I just scanned it and > I can't find > this text. Maybe it was never included. > > > > and until it is actually _used_ in > the API. At least until recently no one was using it. > > > why do we need to have it in the API? It is only imporntat > the the > source sets it to a random value and keep it unchenged e2e > and for the > duration of the flow. I understand that these conditions > are met today, > right? > > > > => But are you saying the src MIP6 module overwrites the > potential flow > label set in the API? Because it is possible that an app sets > the flow > label. RFC 3697 assumes the presence of an e2e mechanism to > negotiate the > flow label. If not then how do you make sure it's always > unique? And how do > you make sure that the CN echoes back the same value in the > flow label? > And what if the CN initiated the connection? > > Hesham > > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From marcelo@it.uc3m.es Sun May 17 07:13:59 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 2260528C0F7 for ; Sun, 17 May 2009 07:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.979 X-Spam-Level: X-Spam-Status: No, score=-4.979 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619, SARE_MILLIONSOF=0.315] 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 9rohpXQSTHDC for ; Sun, 17 May 2009 07:13:58 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A64103A6DC0 for ; Sun, 17 May 2009 07:13:57 -0700 (PDT) Received: from r190-135-43-164.dialup.adsl.anteldata.net.uy (r190-135-43-164.dialup.adsl.anteldata.net.uy [190.135.43.164]) by smtp03.uc3m.es (Postfix) with ESMTP id 54CA47F04FB; Sun, 17 May 2009 16:15:29 +0200 (CEST) Message-ID: <4A101BFF.2030903@it.uc3m.es> Date: Sun, 17 May 2009 16:15:27 +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-16646.007 Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 14:13:59 -0000 Hesham Soliman escribió: > Thanks fpr the long version! Yes it works of course. That's why I agree that > it should be in every filter descriptor. However, since it's not currently > used at all, i woudl actually like to get data about this assertion. Are you certain that current OSes don't implement RFC3697? > I don't think we can remove upper layer information. We need to > allow both to exist until the flow label is actually used. So, to summarise: > yes by all means we have to make sure it's in every spec defining filters > (which this draft is not btw), but not the only way of defining filters. > We should also make sure the SPI is one of those parameters for instance. > Ok, this is where i come from. I don't have any problem whatsoever with using any IP layer information as a flow descriptor. So, SPIs are perfectly ok to me. I have a little problem with using transport layer information. Especially cause if the traffic is encrypted, we need to fall back to something else. In any case, there are a few transports, that are pretty stable and we can rely on hardcoding where to look inside the packet to determine what is a flow (modulo the encrypted packets) I do have a big problem with using application layer information as a flow descriptor. I mean, there are millions of different apps and new apps are defined everyday and a not so limited number become widely used. I think using app bits in MIP signalling is simply a very bad idea. For example, let's take for instance an app protocol that it is propietary and it is widely used (skype for instance). You have no certainty which bits to look. So, my preference here would be to: - use IP header info in any way you want (recommended approach, especially since the flow label approach can discriminate every flow) - maybe use transport info - don not use application layer information in any case. Makes sense? Regards, marcelo > Hesham > > > On 17/05/09 10:58 PM, "marcelo bagnulo braun" wrote: > > >> ok, let me try again because it seems i am failing miserably to >> communicate what i want to say (or it simply so broken that people >> cannot believe what they are reading :-) >> >> Let's try with an example. >> >> We have the MN who has two CoAs, CoA1 and CoA2. >> >> The MN has a policy that says that it wants flows from app1 to be >> exchanged through CoA1 (well, the policy would say that they should be >> received by the interfece in which CoA1 is configured) and that flows >> from app2 to be exchanged through CoA2 (same comment about the interface >> applies here) >> >> In addition, MN has defined CoA1 to be the primary CoA i.e. the CoA with >> highest priority. >> >> So, we have two different situations. Either the MN starts the >> communication or the CN starts the communication. Actually, this is >> pretty irrelevant, cause the two directions of a connections are handled >> independently. the MN will send packets from app1 through CoA1 and >> packets from app2 through CoA2 and it doesn't need any additional >> actions from the HA for outgoing packets. >> >> Now, the difficulty is with incoming packets. the MN needs to inform the >> HA about which CoA it wants to use to receive any flow. >> >> Suppose that the HA has no flow bindings for the MN so far. >> >> So, suppose that the app1 in CN starts a flow to the MN. The HA will >> receive the packet and will send it though the CoA1 cause it is the one >> with higher priority. the MN is happy and there is no need to do >> anything else. >> >> Suppose now that the app2 in the CN starts a flow to the MN. According >> to RFC3697, the CN SHOULD assign a different flow label to the packets >> belonging to this flow e.g. to this TCP connection. Let's assume it is >> actually a TCP connection to make the example more concrete. >> So, app2 opens a TCP connection to MN. CN then sends the TCP SYN to the MN. >> The HA receives the TCP SYN and since there is no flow binding state for >> this flow it forwards it through the CoA1 (the one with highest priority) >> The MN receives the TCP SYN through CoA1 and it realizes that this is >> not compliant with its flow policy. So, it extracts the flow label >> value, the src address and the dest address and it sends a BU to the HA >> stating that the flow identified by the flow label, src add and dest add >> needs to be bound to the CoA2. >> Simultaneously, it also sends the TCP SYN+ACK back to the CN. >> The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives >> the ACk and will forward it based on the flow binding, i.e. through the CoA. >> >> the result is a method that never looks into higher layer information >> for setting the flows. >> >> makes sense? >> >> Regards, marcelo >> >> >> Hesham Soliman escribió: >> >>> On 17/05/09 3:04 PM, "marcelo bagnulo braun" wrote: >>> >>> >>> >>>> Hesham Soliman escribió: >>>> >>>> >>>>> The flow label should be part of any filter descriptor anyway. So at >>>>> anytime >>>>> A MN can send a BU specifying that packets with flow label X should be >>>>> directed to CoA1. I'm not sure how your proposal changes/adds to this. >>>>> >>>>> >>>>> >>>> what i am saying is that you don't need anything else other than this >>>> >>>> >>> => see below >>> >>> >>> >>>>> As a general issue, the flow label is unlikely to be used for this purpose >>>>> until we resolve it's mutability issues >>>>> >>>>> >>>> what mutability issues are you referring to? >>>> AFAIU, the flow label is set randomly b the source and remains unchanged >>>> e2e and for the duration of the flow. >>>> >>>> >>> => I thought RFC 3697 talked about it being changed en route then changed >>> back before it hits the destination. But I just scanned it and I can't find >>> this text. Maybe it was never included. >>> >>> >>> >>>>> and until it is actually _used_ in >>>>> the API. At least until recently no one was using it. >>>>> >>>>> >>>>> >>>> why do we need to have it in the API? It is only imporntat the the >>>> source sets it to a random value and keep it unchenged e2e and for the >>>> duration of the flow. I understand that these conditions are met today, >>>> right? >>>> >>>> >>> => But are you saying the src MIP6 module overwrites the potential flow >>> label set in the API? Because it is possible that an app sets the flow >>> label. RFC 3697 assumes the presence of an e2e mechanism to negotiate the >>> flow label. If not then how do you make sure it's always unique? And how do >>> you make sure that the CN echoes back the same value in the flow label? >>> And what if the CN initiated the connection? >>> >>> Hesham >>> >>> >>> >>> >>> >>> > > > > From tsirtsis@googlemail.com Sun May 17 08:12: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 4D3723A6D2D for ; Sun, 17 May 2009 08:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_LOLITA1=1.865, J_CHICKENPOX_33=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 pHQyA8-QYJRb for ; Sun, 17 May 2009 08:12:11 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 3E9F73A6CFC for ; Sun, 17 May 2009 08:12:09 -0700 (PDT) Received: by bwz22 with SMTP id 22so2776456bwz.37 for ; Sun, 17 May 2009 08:13:42 -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=RnTTKzmlmk/6uFwuRDg5DI27mO0wOYSMkFVp3jOi/j8=; b=YOLTvUuqxNELPFcU1OYilhdDhzLc8qAsM2usQ++5/RyfJ8c/OvHoitrS8IpbgL9ksw bTLpqX47vOe6IqdQNhHuWS8gDcnCEz1eSV1RiCWSpl80VQgamVp6nQkZg7yroYkiz7o4 lDizmLPhpCOjD/Pvf9AVRx0QYBbsxXoqsNN24= 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=xNywi8TkYtr65XOEuS6ed/nPK5YVuCluObHnfiwRVjti4QTIGOGawQPxnWBuBsW7/6 42dAKDUCiwONbhtT893ZG/4wAMt+V37l9ZiqvKXLXZxSyNeMA3pzEKCfFk/fCrwoxvsN CC0deVIiAgfqUFXxGr03a88c98Ya97Km5V+4c= MIME-Version: 1.0 Received: by 10.223.121.6 with SMTP id f6mr3796828far.77.1242573222523; Sun, 17 May 2009 08:13:42 -0700 (PDT) In-Reply-To: <4A101933.6060504@it.uc3m.es> References: <4A1009D8.4060703@it.uc3m.es> <4A101933.6060504@it.uc3m.es> Date: Sun, 17 May 2009 11:13:42 -0400 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 15:12:12 -0000 Marcelo, Flow Movement is supposed to work in combination with DSMIPv6.=C2=A0Are you suggesting the flow bindings should only work for IPv6 traffic then? why would we place such a restriction? BTW, as far as I know flow label is the least well defined aspect of IPv6. How does the MN know whether a given CN marks each relevant flow with a different flow label? Also note that flow labels are source address specific so the flow label by itself is not sufficient. Also the binary format (http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00) in fact allows for a very simple MN implementation if the only thing you want to classify is flow labels. An implementation could only allow the flow label to be set resulting in the following flow descriptor: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0|0|0|0|0|M| 0000 | (M) Flow Label +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FB (cont) | +-+-+-+-+-+-+-+ Or actually something like the above but including the source address too (flag C), do me more correct.. If an MN implementation does not want to deal with any of the other fields, it does not need to implement them. In that sense multiple compatible implementations are allowed as long as the HA implements the flow descriptors in their full complexity. Finally note that what constitutes a "flow" could be something like "ALL TCP Traffic", no matter which source address and what flow label is used. How would the MN be able to say push all TCP to one CoA and all UDP to another based on your scheme? George On Sun, May 17, 2009 at 10:03 AM, marcelo bagnulo braun wrote: > > George Tsirtsis escribi=C3=B3: >> >> Hi Marcelo, I now understand what you propose better. and it makes more = sense than I initially thought. >> >> Two issues, though: >> >> 1) this requires the CN to cooperate i.e., make proper use of flow label= s. > > according to RFC3697: > > =C2=A0To enable Flow Label based classification, source nodes SHOULD assi= gn > =C2=A0each unrelated transport connection and application data stream to = a > =C2=A0new flow. > ... > > =C2=A0To enable applications and transport protocols to define what packe= ts > =C2=A0constitute a flow, the source node MUST provide means for the > =C2=A0applications and transport protocols to specify the Flow Label valu= es > =C2=A0to be used with their flows. =C2=A0The use of the means to specify = Flow > =C2=A0Label values is subject to appropriate privileges (see section 5.1)= . > =C2=A0The source node SHOULD be able to select unused Flow Label values f= or > =C2=A0flows not requesting a specific value to be used. > > So, yes but node should do this if they expect things to work properly > >> It is not clear to me that even if all nodes populated the flow label (w= hich I think is not even true) > > does anybody has information about the support of RFC3697 in current OSes= ? > >> , its use would be universally consistent in a way that would ensure tha= t the setting of the flow label by the CN would be inline with what the MN = would like to identify as a flow. > > that would determine the granularity of the method > I am not sure the spectrum of choices is so big that this can be a proble= m > could you think of some very different criteria to define what a flow is = that this would be an issue? >> >> 2) This does not work for IPv4 traffic. >> > i don't buy this argument. If we apply this argument, then we could never= use the flow label for anything, since it doesn't work for IPv4. > > Reagrds, marcelo > >> Thoughts? >> George >> On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun > wrote: >> >> =C2=A0 =C2=A0ok, let me try again because it seems i am failing miserabl= y to >> =C2=A0 =C2=A0communicate what i want to say (or it simply so broken that= people >> =C2=A0 =C2=A0cannot believe what they are reading :-) >> >> =C2=A0 =C2=A0Let's try with an example. >> >> =C2=A0 =C2=A0We have the MN who has two CoAs, CoA1 and CoA2. >> >> =C2=A0 =C2=A0The MN has a policy that says that it wants flows from app1= to be >> =C2=A0 =C2=A0exchanged through CoA1 (well, the policy would say that the= y >> =C2=A0 =C2=A0should be received by the interfece in which CoA1 is config= ured) >> =C2=A0 =C2=A0and that flows from app2 to be exchanged through CoA2 (same >> =C2=A0 =C2=A0comment about the interface applies here) >> >> =C2=A0 =C2=A0In addition, MN has defined CoA1 to be the primary CoA i.e.= the >> =C2=A0 =C2=A0CoA with highest priority. >> >> =C2=A0 =C2=A0So, we have two different situations. Either the MN starts = the >> =C2=A0 =C2=A0communication or the CN starts the communication. Actually,= this >> =C2=A0 =C2=A0is pretty irrelevant, cause the two directions of a connect= ions >> =C2=A0 =C2=A0are handled independently. the MN will send packets from ap= p1 >> =C2=A0 =C2=A0through CoA1 and packets from app2 through CoA2 and it does= n't >> =C2=A0 =C2=A0need any additional actions from the HA for outgoing packet= s. >> >> =C2=A0 =C2=A0Now, the difficulty is with incoming packets. the MN needs = to >> =C2=A0 =C2=A0inform the HA about which CoA it wants to use to receive an= y flow. >> >> =C2=A0 =C2=A0Suppose that the HA has no flow bindings for the MN so far. >> >> =C2=A0 =C2=A0So, suppose that the app1 in CN starts a flow to the MN. Th= e HA >> =C2=A0 =C2=A0will receive the packet and will send it though the CoA1 ca= use it >> =C2=A0 =C2=A0is the one with higher priority. the MN is happy and there = is no >> =C2=A0 =C2=A0need to do anything else. >> >> =C2=A0 =C2=A0Suppose now that the app2 in the CN starts a flow to the MN= . >> =C2=A0 =C2=A0According to RFC3697, the CN SHOULD assign a different flow= label >> =C2=A0 =C2=A0to the packets belonging to this flow e.g. to this TCP conn= ection. >> =C2=A0 =C2=A0Let's assume it is actually a TCP connection to make the ex= ample >> =C2=A0 =C2=A0more concrete. >> =C2=A0 =C2=A0So, app2 opens a TCP connection to MN. CN then sends the TC= P SYN >> =C2=A0 =C2=A0to the MN. >> =C2=A0 =C2=A0The HA receives the TCP SYN and since there is no flow bind= ing >> =C2=A0 =C2=A0state for this flow it forwards it through the CoA1 (the on= e with >> =C2=A0 =C2=A0highest priority) >> =C2=A0 =C2=A0The MN receives the TCP SYN through CoA1 and it realizes th= at this >> =C2=A0 =C2=A0is not compliant with its flow policy. So, it extracts the = flow >> =C2=A0 =C2=A0label value, the src address and the dest address and it se= nds a >> =C2=A0 =C2=A0BU to the HA stating that the flow identified by the flow l= abel, >> =C2=A0 =C2=A0src add and dest add needs to be bound to the CoA2. >> =C2=A0 =C2=A0Simultaneously, it also sends the TCP SYN+ACK back to the C= N. >> =C2=A0 =C2=A0The CN receives the TCP SYN+ACK and sends the Ack back. the= HA >> =C2=A0 =C2=A0receives the ACk and will forward it based on the flow bind= ing, >> =C2=A0 =C2=A0i.e. through the CoA. >> >> =C2=A0 =C2=A0the result is a method that never looks into higher layer >> =C2=A0 =C2=A0information for setting the flows. >> >> =C2=A0 =C2=A0makes sense? >> >> =C2=A0 =C2=A0Regards, marcelo >> >> >> =C2=A0 =C2=A0Hesham Soliman escribi=C3=B3: >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0On 17/05/09 3:04 PM, "marcelo bagnulo braun" >> =C2=A0 =C2=A0 =C2=A0 =C2=A0> wrote: >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hesham Soliman escribi=C3=B3: >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The flow label sh= ould be part of any filter descriptor >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anyway. So at any= time >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A MN can send a B= U specifying that packets with flow >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0label X should be >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0directed to CoA1.= I'm not sure how your proposal >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0changes/adds to t= his. >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0what i am saying is that you do= n't need anything else >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other than this >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> see below >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As a general issu= e, the flow label is unlikely to be >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0used for this pur= pose >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until we resolve = it's mutability issues >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0what mutability issues are you = referring to? >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AFAIU, the flow label is set ra= ndomly b the source and >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0remains unchanged >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e2e and for the duration of the= flow. >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> I thought RFC 3697 talked about it being= changed en route >> =C2=A0 =C2=A0 =C2=A0 =C2=A0then changed >> =C2=A0 =C2=A0 =C2=A0 =C2=A0back before it hits the destination. But I ju= st scanned it and >> =C2=A0 =C2=A0 =C2=A0 =C2=A0I can't find >> =C2=A0 =C2=A0 =C2=A0 =C2=A0this text. Maybe it was never included. >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and until it is = actually _used_ in >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the API. At least= until recently no one was using it. >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0why do we need to have it in th= e API? It is only imporntat >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0source sets it to a random valu= e and keep it unchenged e2e >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and for the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0duration of the flow. I underst= and that these conditions >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are met today, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0right? >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> But are you saying the src MIP6 module o= verwrites the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0potential flow >> =C2=A0 =C2=A0 =C2=A0 =C2=A0label set in the API? Because it is possible = that an app sets >> =C2=A0 =C2=A0 =C2=A0 =C2=A0the flow >> =C2=A0 =C2=A0 =C2=A0 =C2=A0label. RFC 3697 assumes the presence of an e2= e mechanism to >> =C2=A0 =C2=A0 =C2=A0 =C2=A0negotiate the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0flow label. If not then how do you make sure = it's always >> =C2=A0 =C2=A0 =C2=A0 =C2=A0unique? And how do >> =C2=A0 =C2=A0 =C2=A0 =C2=A0you make sure that the CN echoes back the sam= e value in the >> =C2=A0 =C2=A0 =C2=A0 =C2=A0flow label? >> =C2=A0 =C2=A0 =C2=A0 =C2=A0And what if the CN initiated the connection? >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Hesham >> >> >> >> >> >> >> =C2=A0 =C2=A0_______________________________________________ >> =C2=A0 =C2=A0MEXT mailing list >> =C2=A0 =C2=A0MEXT@ietf.org >> =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/mext >> >> > From hesham@elevatemobile.com Sun May 17 08:31: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 76FC83A6B64 for ; Sun, 17 May 2009 08:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_QP_LONG_LINE=1.396, SARE_MILLIONSOF=0.315] 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 jR2fGnyo2mQ2 for ; Sun, 17 May 2009 08:31:13 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id B1D4C3A6E49 for ; Sun, 17 May 2009 08:31: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 1M5iLt-0007Qf-1J; Mon, 18 May 2009 01:32:37 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 18 May 2009 01:32:30 +1000 From: Hesham Soliman To: marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] weird idea about flow bindings Thread-Index: AcnXBLChIgMNEiu1kkK+trxUsvjYhg== In-Reply-To: <4A101BFF.2030903@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 15:31:20 -0000 On 18/05/09 12:15 AM, "marcelo bagnulo braun" wrote: > Hesham Soliman escribi=F3: >> Thanks fpr the long version! Yes it works of course. That's why I agree = that >> it should be in every filter descriptor. However, since it's not current= ly >> used at all, > i woudl actually like to get data about this assertion. Are you certain > that current OSes don't implement RFC3697? =3D> RFC3697 mainly states requirements. Last time I checked there was no one using the flow label in the API and there were no flow label negotiations except, say SIP. But it would be interesting to see if anyone is actually using it. The point is, even if 80% of implementations are using it, we can't make it the only was of defining flows. >=20 >> I don't think we can remove upper layer information. We need to >> allow both to exist until the flow label is actually used. So, to summar= ise: >> yes by all means we have to make sure it's in every spec defining filter= s >> (which this draft is not btw), but not the only way of defining filters. >> We should also make sure the SPI is one of those parameters for instance= . >> =20 > Ok, this is where i come from. > I don't have any problem whatsoever with using any IP layer information > as a flow descriptor. So, SPIs are perfectly ok to me. > I have a little problem with using transport layer information. > Especially cause if the traffic is encrypted, we need to fall back to > something else.=20 =3D> Sure. Like SPI for example :) In any case, there are a few transports, that are pretty > stable and we can rely on hardcoding where to look inside the packet to > determine what is a flow (modulo the encrypted packets) > I do have a big problem with using application layer information as a > flow descriptor. I mean, there are millions of different apps and new > apps are defined everyday and a not so limited number become widely > used. I think using app bits in MIP signalling is simply a very bad > idea. For example, let's take for instance an app protocol that it is > propietary and it is widely used (skype for instance). You have no > certainty which bits to look. =3D> I don't advocate the use of app information either. >=20 > So, my preference here would be to: > - use IP header info in any way you want (recommended approach, > especially since the flow label approach can discriminate every flow) > - maybe use transport info > - don not use application layer information in any case. >=20 > Makes sense? =3D> Makes sense to recommend that, but of course the spec needs to offer bot= h options for the reasons above. Hesham >=20 > Regards, marcelo >=20 >> Hesham >>=20 >>=20 >> On 17/05/09 10:58 PM, "marcelo bagnulo braun" wrote= : >>=20 >> =20 >>> ok, let me try again because it seems i am failing miserably to >>> communicate what i want to say (or it simply so broken that people >>> cannot believe what they are reading :-) >>>=20 >>> Let's try with an example. >>>=20 >>> We have the MN who has two CoAs, CoA1 and CoA2. >>>=20 >>> The MN has a policy that says that it wants flows from app1 to be >>> exchanged through CoA1 (well, the policy would say that they should be >>> received by the interfece in which CoA1 is configured) and that flows >>> from app2 to be exchanged through CoA2 (same comment about the interfac= e >>> applies here) >>>=20 >>> In addition, MN has defined CoA1 to be the primary CoA i.e. the CoA wit= h >>> highest priority. >>>=20 >>> So, we have two different situations. Either the MN starts the >>> communication or the CN starts the communication. Actually, this is >>> pretty irrelevant, cause the two directions of a connections are handle= d >>> independently. the MN will send packets from app1 through CoA1 and >>> packets from app2 through CoA2 and it doesn't need any additional >>> actions from the HA for outgoing packets. >>>=20 >>> Now, the difficulty is with incoming packets. the MN needs to inform th= e >>> HA about which CoA it wants to use to receive any flow. >>>=20 >>> Suppose that the HA has no flow bindings for the MN so far. >>>=20 >>> So, suppose that the app1 in CN starts a flow to the MN. The HA will >>> receive the packet and will send it though the CoA1 cause it is the one >>> with higher priority. the MN is happy and there is no need to do >>> anything else. >>>=20 >>> Suppose now that the app2 in the CN starts a flow to the MN. According >>> to RFC3697, the CN SHOULD assign a different flow label to the packets >>> belonging to this flow e.g. to this TCP connection. Let's assume it is >>> actually a TCP connection to make the example more concrete. >>> So, app2 opens a TCP connection to MN. CN then sends the TCP SYN to the= MN. >>> The HA receives the TCP SYN and since there is no flow binding state fo= r >>> this flow it forwards it through the CoA1 (the one with highest priorit= y) >>> The MN receives the TCP SYN through CoA1 and it realizes that this is >>> not compliant with its flow policy. So, it extracts the flow label >>> value, the src address and the dest address and it sends a BU to the HA >>> stating that the flow identified by the flow label, src add and dest ad= d >>> needs to be bound to the CoA2. >>> Simultaneously, it also sends the TCP SYN+ACK back to the CN. >>> The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives >>> the ACk and will forward it based on the flow binding, i.e. through the= CoA. >>>=20 >>> the result is a method that never looks into higher layer information >>> for setting the flows. >>>=20 >>> makes sense? >>>=20 >>> Regards, marcelo >>>=20 >>>=20 >>> Hesham Soliman escribi=F3: >>> =20 >>>> On 17/05/09 3:04 PM, "marcelo bagnulo braun" wrot= e: >>>>=20 >>>> =20 >>>> =20 >>>>> Hesham Soliman escribi=F3: >>>>> =20 >>>>> =20 >>>>>> The flow label should be part of any filter descriptor anyway. So at >>>>>> anytime >>>>>> A MN can send a BU specifying that packets with flow label X should = be >>>>>> directed to CoA1. I'm not sure how your proposal changes/adds to thi= s. >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>> what i am saying is that you don't need anything else other than this >>>>> =20 >>>>> =20 >>>> =3D> see below >>>>=20 >>>> =20 >>>> =20 >>>>>> As a general issue, the flow label is unlikely to be used for this >>>>>> purpose >>>>>> until we resolve it's mutability issues >>>>>> =20 >>>>>> =20 >>>>> what mutability issues are you referring to? >>>>> AFAIU, the flow label is set randomly b the source and remains unchan= ged >>>>> e2e and for the duration of the flow. >>>>> =20 >>>>> =20 >>>> =3D> I thought RFC 3697 talked about it being changed en route then chan= ged >>>> back before it hits the destination. But I just scanned it and I can't= find >>>> this text. Maybe it was never included. >>>>=20 >>>> =20 >>>> =20 >>>>>> and until it is actually _used_ in >>>>>> the API. At least until recently no one was using it. >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>> why do we need to have it in the API? It is only imporntat the the >>>>> source sets it to a random value and keep it unchenged e2e and for th= e >>>>> duration of the flow. I understand that these conditions are met toda= y, >>>>> right? >>>>> =20 >>>>> =20 >>>> =3D> But are you saying the src MIP6 module overwrites the potential flo= w >>>> label set in the API? Because it is possible that an app sets the flow >>>> label. RFC 3697 assumes the presence of an e2e mechanism to negotiate = the >>>> flow label. If not then how do you make sure it's always unique? And h= ow do >>>> you make sure that the CN echoes back the same value in the flow label= ? >>>> And what if the CN initiated the connection? >>>>=20 >>>> Hesham >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> =20 >>>> =20 >>=20 >>=20 >>=20 >> =20 >=20 From marcelo@it.uc3m.es Sun May 17 08:33: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 DD01028C0F1 for ; Sun, 17 May 2009 08:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FRT_LOLITA1=1.865, J_CHICKENPOX_33=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 99NC5rFZvxHr for ; Sun, 17 May 2009 08:32:55 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id F1A0A28C143 for ; Sun, 17 May 2009 08:32:54 -0700 (PDT) Received: from r190-135-59-75.dialup.adsl.anteldata.net.uy (r190-135-59-75.dialup.adsl.anteldata.net.uy [190.135.59.75]) by smtp03.uc3m.es (Postfix) with ESMTP id 50B9072C3EE; Sun, 17 May 2009 17:34:26 +0200 (CEST) Message-ID: <4A102E80.5030301@it.uc3m.es> Date: Sun, 17 May 2009 17:34:24 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Tsirtsis References: <4A1009D8.4060703@it.uc3m.es> <4A101933.6060504@it.uc3m.es> 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-16648.000 Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 15:33:01 -0000 George Tsirtsis escribió: > Marcelo, > > Flow Movement is supposed to work in combination with DSMIPv6. Are you > suggesting the flow bindings should only work for IPv6 traffic then? > no, i ma suggesting that for IPv6 traffic, we should use the flow label for ipv4, we certainly need to use something else What i am not buying is that we cannot build a method that relies in the flow label cause IPv4 doesn't support it. In other words, i think it is perfeclty ok to build our reccomended method relying on the usage of the flow label, and define some other hacks to support ipv4. > why would we place such a restriction? > > BTW, as far as I know flow label is the least well defined aspect of > IPv6. but that is not the porblem of IPv6, but it is an inherent problem of defining a flow. The IP layer has a problem cause it is agonstic to flows. So, only the application knows what really a flow is. And IPv6 does provide the means for the application to signal the packets that belong to flow to the IP layer i.e. the flow label. In other words, this is a fundamental problem: IP does not knows about flows and we are trying that MIP which is in the IP layer to discriminate flows. We can either try the IP layer to guess what are the common bits of a flow or we can leverage on the explicit definition of a flow, which is what the flow label is for. > How does the MN know whether a given CN marks each relevant flow > with a different flow label? becuase it needs to be compliant with RFC3697? > Also note that flow labels are source > address specific so the flow label by itself is not sufficient. > > sure, the flow description is src add, dst add and flow label > Also the binary format > (http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00) in > fact allows for a very simple MN implementation if the only thing you > want to classify is flow labels. An implementation could only allow > the flow label to be set resulting in the following flow descriptor: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0|0|0|0|0|0|0|0|0|0|0|M| 0000 | (M) Flow Label > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > FB (cont) | > +-+-+-+-+-+-+-+ > > Or actually something like the above but including the source address > too (flag C), do me more correct.. > > If an MN implementation does not want to deal with any of the other > fields, it does not need to implement them. > In that sense multiple compatible implementations are allowed as long > as the HA implements the flow descriptors in their full complexity. > > this is my problem. I don't want to impose the HAs to be able to parse arbitrary bits in the application data. I think this is not the right way to do it. I don't think the IP layer should be snooping into application data bits > Finally note that what constitutes a "flow" could be something like > "ALL TCP Traffic", no matter which source address and what flow label > is used. How would the MN be able to say push all TCP to one CoA and > all UDP to another based on your scheme? > well, you can do this based on the protocol field of the IP header As i stated in my earlier reply to Hesham, i don't have a problem with using any IP header fields as flow descriptors and i may be ok with sing the transport header bits (not what i would preffer, but hey, you can't always get what you want) My problem is with supporting application data bits as part of the flow description, which i really think is broken Makes sense? Regards, marcelo > George > > > On Sun, May 17, 2009 at 10:03 AM, marcelo bagnulo braun > wrote: > >> George Tsirtsis escribió: >> >>> Hi Marcelo, I now understand what you propose better. and it makes more sense than I initially thought. >>> >>> Two issues, though: >>> >>> 1) this requires the CN to cooperate i.e., make proper use of flow labels. >>> >> according to RFC3697: >> >> To enable Flow Label based classification, source nodes SHOULD assign >> each unrelated transport connection and application data stream to a >> new flow. >> ... >> >> To enable applications and transport protocols to define what packets >> constitute a flow, the source node MUST provide means for the >> applications and transport protocols to specify the Flow Label values >> to be used with their flows. The use of the means to specify Flow >> Label values is subject to appropriate privileges (see section 5.1). >> The source node SHOULD be able to select unused Flow Label values for >> flows not requesting a specific value to be used. >> >> So, yes but node should do this if they expect things to work properly >> >> >>> It is not clear to me that even if all nodes populated the flow label (which I think is not even true) >>> >> does anybody has information about the support of RFC3697 in current OSes? >> >> >>> , its use would be universally consistent in a way that would ensure that the setting of the flow label by the CN would be inline with what the MN would like to identify as a flow. >>> >> that would determine the granularity of the method >> I am not sure the spectrum of choices is so big that this can be a problem >> could you think of some very different criteria to define what a flow is that this would be an issue? >> >>> 2) This does not work for IPv4 traffic. >>> >>> >> i don't buy this argument. If we apply this argument, then we could never use the flow label for anything, since it doesn't work for IPv4. >> >> Reagrds, marcelo >> >> >>> Thoughts? >>> George >>> On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun > wrote: >>> >>> ok, let me try again because it seems i am failing miserably to >>> communicate what i want to say (or it simply so broken that people >>> cannot believe what they are reading :-) >>> >>> Let's try with an example. >>> >>> We have the MN who has two CoAs, CoA1 and CoA2. >>> >>> The MN has a policy that says that it wants flows from app1 to be >>> exchanged through CoA1 (well, the policy would say that they >>> should be received by the interfece in which CoA1 is configured) >>> and that flows from app2 to be exchanged through CoA2 (same >>> comment about the interface applies here) >>> >>> In addition, MN has defined CoA1 to be the primary CoA i.e. the >>> CoA with highest priority. >>> >>> So, we have two different situations. Either the MN starts the >>> communication or the CN starts the communication. Actually, this >>> is pretty irrelevant, cause the two directions of a connections >>> are handled independently. the MN will send packets from app1 >>> through CoA1 and packets from app2 through CoA2 and it doesn't >>> need any additional actions from the HA for outgoing packets. >>> >>> Now, the difficulty is with incoming packets. the MN needs to >>> inform the HA about which CoA it wants to use to receive any flow. >>> >>> Suppose that the HA has no flow bindings for the MN so far. >>> >>> So, suppose that the app1 in CN starts a flow to the MN. The HA >>> will receive the packet and will send it though the CoA1 cause it >>> is the one with higher priority. the MN is happy and there is no >>> need to do anything else. >>> >>> Suppose now that the app2 in the CN starts a flow to the MN. >>> According to RFC3697, the CN SHOULD assign a different flow label >>> to the packets belonging to this flow e.g. to this TCP connection. >>> Let's assume it is actually a TCP connection to make the example >>> more concrete. >>> So, app2 opens a TCP connection to MN. CN then sends the TCP SYN >>> to the MN. >>> The HA receives the TCP SYN and since there is no flow binding >>> state for this flow it forwards it through the CoA1 (the one with >>> highest priority) >>> The MN receives the TCP SYN through CoA1 and it realizes that this >>> is not compliant with its flow policy. So, it extracts the flow >>> label value, the src address and the dest address and it sends a >>> BU to the HA stating that the flow identified by the flow label, >>> src add and dest add needs to be bound to the CoA2. >>> Simultaneously, it also sends the TCP SYN+ACK back to the CN. >>> The CN receives the TCP SYN+ACK and sends the Ack back. the HA >>> receives the ACk and will forward it based on the flow binding, >>> i.e. through the CoA. >>> >>> the result is a method that never looks into higher layer >>> information for setting the flows. >>> >>> makes sense? >>> >>> Regards, marcelo >>> >>> >>> Hesham Soliman escribió: >>> >>> >>> On 17/05/09 3:04 PM, "marcelo bagnulo braun" >>> > wrote: >>> >>> >>> Hesham Soliman escribió: >>> >>> The flow label should be part of any filter descriptor >>> anyway. So at anytime >>> A MN can send a BU specifying that packets with flow >>> label X should be >>> directed to CoA1. I'm not sure how your proposal >>> changes/adds to this. >>> >>> what i am saying is that you don't need anything else >>> other than this >>> >>> >>> => see below >>> >>> >>> As a general issue, the flow label is unlikely to be >>> used for this purpose >>> until we resolve it's mutability issues >>> >>> what mutability issues are you referring to? >>> AFAIU, the flow label is set randomly b the source and >>> remains unchanged >>> e2e and for the duration of the flow. >>> >>> >>> => I thought RFC 3697 talked about it being changed en route >>> then changed >>> back before it hits the destination. But I just scanned it and >>> I can't find >>> this text. Maybe it was never included. >>> >>> >>> and until it is actually _used_ in >>> the API. At least until recently no one was using it. >>> >>> why do we need to have it in the API? It is only imporntat >>> the the >>> source sets it to a random value and keep it unchenged e2e >>> and for the >>> duration of the flow. I understand that these conditions >>> are met today, >>> right? >>> >>> >>> => But are you saying the src MIP6 module overwrites the >>> potential flow >>> label set in the API? Because it is possible that an app sets >>> the flow >>> label. RFC 3697 assumes the presence of an e2e mechanism to >>> negotiate the >>> flow label. If not then how do you make sure it's always >>> unique? And how do >>> you make sure that the CN echoes back the same value in the >>> flow label? >>> And what if the CN initiated the connection? >>> >>> Hesham >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> > > From marcelo@it.uc3m.es Sun May 17 08:47: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 A82C93A684E for ; Sun, 17 May 2009 08:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.269 X-Spam-Level: X-Spam-Status: No, score=-5.269 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 AvRhCqsINrrM for ; Sun, 17 May 2009 08:47:10 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id DFA2928C130 for ; Sun, 17 May 2009 08:47:09 -0700 (PDT) Received: from r190-135-59-75.dialup.adsl.anteldata.net.uy (r190-135-59-75.dialup.adsl.anteldata.net.uy [190.135.59.75]) by smtp02.uc3m.es (Postfix) with ESMTP id 8D1A0656C10; Sun, 17 May 2009 17:48:41 +0200 (CEST) Message-ID: <4A1031D7.9000206@it.uc3m.es> Date: Sun, 17 May 2009 17:48:39 +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-16648.000 Cc: mext Subject: Re: [MEXT] weird idea about 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, 17 May 2009 15:47:11 -0000 Hesham Soliman escribió: > > On 18/05/09 12:15 AM, "marcelo bagnulo braun" wrote: > > >> Hesham Soliman escribió: >> >>> Thanks fpr the long version! Yes it works of course. That's why I agree that >>> it should be in every filter descriptor. However, since it's not currently >>> used at all, >>> >> i woudl actually like to get data about this assertion. Are you certain >> that current OSes don't implement RFC3697? >> > > => RFC3697 mainly states requirements. Last time I checked there was no one > using the flow label in the API and there were no flow label negotiations > except, say SIP. but we don't need negotiation for this right? the only thing that we need is that the CN sets different flow label values for different flows. for isntnace if each socket uses a different flow label, then we are ok i think > But it would be interesting to see if anyone is actually > using it. right, i would like to find out how current OSes set the flow label. For instance, if for each socket a different flow label value is used, then we should be ok, i think > The point is, even if 80% of implementations are using it, we > can't make it the only was of defining flows. > > >>> I don't think we can remove upper layer information. We need to >>> allow both to exist until the flow label is actually used. So, to summarise: >>> yes by all means we have to make sure it's in every spec defining filters >>> (which this draft is not btw), but not the only way of defining filters. >>> We should also make sure the SPI is one of those parameters for instance. >>> >>> >> Ok, this is where i come from. >> I don't have any problem whatsoever with using any IP layer information >> as a flow descriptor. So, SPIs are perfectly ok to me. >> I have a little problem with using transport layer information. >> Especially cause if the traffic is encrypted, we need to fall back to >> something else. >> > > => Sure. Like SPI for example :) > > right, which is perfect cause it IP layer info. I mean, i rather use the SPI than the transport information > In any case, there are a few transports, that are pretty > >> stable and we can rely on hardcoding where to look inside the packet to >> determine what is a flow (modulo the encrypted packets) >> I do have a big problem with using application layer information as a >> flow descriptor. I mean, there are millions of different apps and new >> apps are defined everyday and a not so limited number become widely >> used. I think using app bits in MIP signalling is simply a very bad >> idea. For example, let's take for instance an app protocol that it is >> propietary and it is widely used (skype for instance). You have no >> certainty which bits to look. >> > > => I don't advocate the use of app information either. > > >> So, my preference here would be to: >> - use IP header info in any way you want (recommended approach, >> especially since the flow label approach can discriminate every flow) >> - maybe use transport info >> - don not use application layer information in any case. >> >> Makes sense? >> > > => Makes sense to recommend that, but of course the spec needs to offer both > options for the reasons above. > > mmm, i am not sure i understand what you suggest we need to support in the spec. I think that we could simply support flow descriptors as follows: MUST support flow descriptors based on IP header MAY support flow descriptors based on transport header I would be silent about other flow descriptors. In particular, i would not define in the spec means to use app data bits as flow descriptors. would that make sense to you? Regards, marcelo > Hesham > > >> Regards, marcelo >> >> >>> Hesham >>> >>> >>> On 17/05/09 10:58 PM, "marcelo bagnulo braun" wrote: >>> >>> >>> >>>> ok, let me try again because it seems i am failing miserably to >>>> communicate what i want to say (or it simply so broken that people >>>> cannot believe what they are reading :-) >>>> >>>> Let's try with an example. >>>> >>>> We have the MN who has two CoAs, CoA1 and CoA2. >>>> >>>> The MN has a policy that says that it wants flows from app1 to be >>>> exchanged through CoA1 (well, the policy would say that they should be >>>> received by the interfece in which CoA1 is configured) and that flows >>>> from app2 to be exchanged through CoA2 (same comment about the interface >>>> applies here) >>>> >>>> In addition, MN has defined CoA1 to be the primary CoA i.e. the CoA with >>>> highest priority. >>>> >>>> So, we have two different situations. Either the MN starts the >>>> communication or the CN starts the communication. Actually, this is >>>> pretty irrelevant, cause the two directions of a connections are handled >>>> independently. the MN will send packets from app1 through CoA1 and >>>> packets from app2 through CoA2 and it doesn't need any additional >>>> actions from the HA for outgoing packets. >>>> >>>> Now, the difficulty is with incoming packets. the MN needs to inform the >>>> HA about which CoA it wants to use to receive any flow. >>>> >>>> Suppose that the HA has no flow bindings for the MN so far. >>>> >>>> So, suppose that the app1 in CN starts a flow to the MN. The HA will >>>> receive the packet and will send it though the CoA1 cause it is the one >>>> with higher priority. the MN is happy and there is no need to do >>>> anything else. >>>> >>>> Suppose now that the app2 in the CN starts a flow to the MN. According >>>> to RFC3697, the CN SHOULD assign a different flow label to the packets >>>> belonging to this flow e.g. to this TCP connection. Let's assume it is >>>> actually a TCP connection to make the example more concrete. >>>> So, app2 opens a TCP connection to MN. CN then sends the TCP SYN to the MN. >>>> The HA receives the TCP SYN and since there is no flow binding state for >>>> this flow it forwards it through the CoA1 (the one with highest priority) >>>> The MN receives the TCP SYN through CoA1 and it realizes that this is >>>> not compliant with its flow policy. So, it extracts the flow label >>>> value, the src address and the dest address and it sends a BU to the HA >>>> stating that the flow identified by the flow label, src add and dest add >>>> needs to be bound to the CoA2. >>>> Simultaneously, it also sends the TCP SYN+ACK back to the CN. >>>> The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives >>>> the ACk and will forward it based on the flow binding, i.e. through the CoA. >>>> >>>> the result is a method that never looks into higher layer information >>>> for setting the flows. >>>> >>>> makes sense? >>>> >>>> Regards, marcelo >>>> >>>> >>>> Hesham Soliman escribió: >>>> >>>> >>>>> On 17/05/09 3:04 PM, "marcelo bagnulo braun" wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hesham Soliman escribió: >>>>>> >>>>>> >>>>>> >>>>>>> The flow label should be part of any filter descriptor anyway. So at >>>>>>> anytime >>>>>>> A MN can send a BU specifying that packets with flow label X should be >>>>>>> directed to CoA1. I'm not sure how your proposal changes/adds to this. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> what i am saying is that you don't need anything else other than this >>>>>> >>>>>> >>>>>> >>>>> => see below >>>>> >>>>> >>>>> >>>>> >>>>>>> As a general issue, the flow label is unlikely to be used for this >>>>>>> purpose >>>>>>> until we resolve it's mutability issues >>>>>>> >>>>>>> >>>>>>> >>>>>> what mutability issues are you referring to? >>>>>> AFAIU, the flow label is set randomly b the source and remains unchanged >>>>>> e2e and for the duration of the flow. >>>>>> >>>>>> >>>>>> >>>>> => I thought RFC 3697 talked about it being changed en route then changed >>>>> back before it hits the destination. But I just scanned it and I can't find >>>>> this text. Maybe it was never included. >>>>> >>>>> >>>>> >>>>> >>>>>>> and until it is actually _used_ in >>>>>>> the API. At least until recently no one was using it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> why do we need to have it in the API? It is only imporntat the the >>>>>> source sets it to a random value and keep it unchenged e2e and for the >>>>>> duration of the flow. I understand that these conditions are met today, >>>>>> right? >>>>>> >>>>>> >>>>>> >>>>> => But are you saying the src MIP6 module overwrites the potential flow >>>>> label set in the API? Because it is possible that an app sets the flow >>>>> label. RFC 3697 assumes the presence of an e2e mechanism to negotiate the >>>>> flow label. If not then how do you make sure it's always unique? And how do >>>>> you make sure that the CN echoes back the same value in the flow label? >>>>> And what if the CN initiated the connection? >>>>> >>>>> Hesham >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > > From marcelo@it.uc3m.es Sun May 17 12:27: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 D69043A6B32 for ; Sun, 17 May 2009 12:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.752 X-Spam-Level: X-Spam-Status: No, score=-5.752 tagged_above=-999 required=5 tests=[AWL=0.847, 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 CIixgoWYcEsv for ; Sun, 17 May 2009 12:27:25 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id EC6943A6DFC for ; Sun, 17 May 2009 12:27:24 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (r190-135-60-41.dialup.adsl.anteldata.net.uy [190.135.60.41]) by smtp01.uc3m.es (Postfix) with ESMTP id 0898EB49C9A for ; Sun, 17 May 2009 21:28:55 +0200 (CEST) Message-ID: <4A106574.8040107@it.uc3m.es> Date: Sun, 17 May 2009 21:28:52 +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-16648.001 Subject: [MEXT] implications for draft-tsirtsis-mext-binary-filters-00.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, 17 May 2009 19:27:25 -0000 So, basically, the usage of the flow label that i was suggesting has the following implications for draft-tsirtsis-mext-binary-filters-00.txt. Basically, the N number of ponters options would go away (a least for IPv4). The rest could be unchanged. I would probably explain how to use flow bindings using the flow label as described in my previous email in order to achieve higher granularity. One more comments about the draft: (G)Source Port - Low This field identifies the lowest source port number within a range of port numbers that will be used in data packets, as seen by the home agent. (H)Source Port - High This field identifies the highest source port number within a range of port numbers that will be used in data packets, as seen by the home agent. If a single port is indicated then this field SHOULD NOT be included. If it is included it SHOULD be set to the value of the Source Port - Low field. (I)Destination Port - Low This field identifies the lowest destination port number within a range of port numbers that will be used in data packets as seen by the home agent. (K)Destination Port - High This field identifies the highest destination port number within a range of port numbers that will be used in data packets as seen by the home agent. If a single port is indicated then this field SHOULD NOT be included. If it is included it SHOULD be set to the value of the Dst Port - Low field. question: all these options can be present only if the (B)Protocol option is present, correct? From marcelo@it.uc3m.es Sun May 17 12:39: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 4B58528C249 for ; Sun, 17 May 2009 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.802 X-Spam-Level: X-Spam-Status: No, score=-5.802 tagged_above=-999 required=5 tests=[AWL=0.797, 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 6OFxCjwm37HM for ; Sun, 17 May 2009 12:39:38 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A680928C244 for ; Sun, 17 May 2009 12:39:38 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (r190-135-60-41.dialup.adsl.anteldata.net.uy [190.135.60.41]) by smtp01.uc3m.es (Postfix) with ESMTP id 58B04B49C9A for ; Sun, 17 May 2009 21:41:09 +0200 (CEST) Message-ID: <4A106852.3050002@it.uc3m.es> Date: Sun, 17 May 2009 21:41:06 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext References: <4A106574.8040107@it.uc3m.es> In-Reply-To: <4A106574.8040107@it.uc3m.es> 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-16648.001 Subject: Re: [MEXT] implications for draft-tsirtsis-mext-binary-filters-00.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, 17 May 2009 19:39:44 -0000 marcelo bagnulo braun escribió: > So, basically, the usage of the flow label that i was suggesting has > the following implications for draft-tsirtsis-mext-binary-filters-00.txt. > Basically, the N number of ponters options would go away (a least for > IPv4) sigh, for ipv6 i mean > . The rest could be unchanged. > I would probably explain how to use flow bindings using the flow label > as described in my previous email in order to achieve higher granularity. > > One more comments about the draft: > > (G)Source Port - Low > > This field identifies the lowest source port number within a range > of port numbers that will be used in data packets, as seen by the > home agent. > > (H)Source Port - High > > This field identifies the highest source port number within a > range of port numbers that will be used in data packets, as seen > by the home agent. If a single port is indicated then this field > SHOULD NOT be included. If it is included it SHOULD be set to the > value of the Source Port - Low field. > > (I)Destination Port - Low > > This field identifies the lowest destination port number within a > range of port numbers that will be used in data packets as seen by > the home agent. > > > (K)Destination Port - High > > This field identifies the highest destination port number within a > range of port numbers that will be used in data packets as seen by > the home agent. If a single port is indicated then this field > SHOULD NOT be included. If it is included it SHOULD be set to the > value of the Dst Port - Low field. > > > question: all these options can be present only if the (B)Protocol > option is present, correct? > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From hesham@elevatemobile.com Sun May 17 17:10: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 599603A6B0B for ; Sun, 17 May 2009 17:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, J_CHICKENPOX_33=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 Q7TcruT4p-DT for ; Sun, 17 May 2009 17:10:28 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 010693A6D51 for ; Sun, 17 May 2009 17:10: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 1M5qST-0000Ua-2I; Mon, 18 May 2009 10:11:57 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 18 May 2009 10:11:50 +1000 From: Hesham Soliman To: marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] weird idea about flow bindings Thread-Index: AcnXTT1wr0xI3EmwlkWn4qVO67H8rw== In-Reply-To: <4A1031D7.9000206@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext Subject: Re: [MEXT] weird idea about 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, 18 May 2009 00:10:29 -0000 On 18/05/09 1:48 AM, "marcelo bagnulo braun" wrote: > Hesham Soliman escribi=F3: >>=20 >> On 18/05/09 12:15 AM, "marcelo bagnulo braun" wrote= : >>=20 >> =20 >>> Hesham Soliman escribi=F3: >>> =20 >>>> Thanks fpr the long version! Yes it works of course. That's why I agre= e >>>> that >>>> it should be in every filter descriptor. However, since it's not curre= ntly >>>> used at all, >>>> =20 >>> i woudl actually like to get data about this assertion. Are you certain >>> that current OSes don't implement RFC3697? >>> =20 >>=20 >> =3D> RFC3697 mainly states requirements. Last time I checked there was no = one >> using the flow label in the API and there were no flow label negotiation= s >> except, say SIP. > but we don't need negotiation for this right? > the only thing that we need is that the CN sets different flow label > values for different flows. for isntnace if each socket uses a different > flow label, then we are ok i think =3D> Yes I understand, I was responding to the comment about RFC 3697. The other point is, the CNs didn't set that field at all (last time I checked). Until that happens, no one can use it for anything. It would be good to kno= w if that behaviour has changed. >>=20 >> =3D> Makes sense to recommend that, but of course the spec needs to offer = both >> options for the reasons above. >>=20 >> =20 > mmm, i am not sure i understand what you suggest we need to support in > the spec. >=20 > I think that we could simply support flow descriptors as follows: > MUST support flow descriptors based on IP header > MAY support flow descriptors based on transport header >=20 > I would be silent about other flow descriptors. In particular, i would > not define in the spec means to use app data bits as flow descriptors. >=20 > would that make sense to you? =3D> Yes that works for me but I suspect that people will treat the MAY above in the same way as a MUST when it comes to implementation. Hesham >=20 > Regards, marcelo >=20 >> Hesham >>=20 >> =20 >>> Regards, marcelo >>>=20 >>> =20 >>>> Hesham >>>>=20 >>>>=20 >>>> On 17/05/09 10:58 PM, "marcelo bagnulo braun" wro= te: >>>>=20 >>>> =20 >>>> =20 >>>>> ok, let me try again because it seems i am failing miserably to >>>>> communicate what i want to say (or it simply so broken that people >>>>> cannot believe what they are reading :-) >>>>>=20 >>>>> Let's try with an example. >>>>>=20 >>>>> We have the MN who has two CoAs, CoA1 and CoA2. >>>>>=20 >>>>> The MN has a policy that says that it wants flows from app1 to be >>>>> exchanged through CoA1 (well, the policy would say that they should b= e >>>>> received by the interfece in which CoA1 is configured) and that flows >>>>> from app2 to be exchanged through CoA2 (same comment about the interf= ace >>>>> applies here) >>>>>=20 >>>>> In addition, MN has defined CoA1 to be the primary CoA i.e. the CoA w= ith >>>>> highest priority. >>>>>=20 >>>>> So, we have two different situations. Either the MN starts the >>>>> communication or the CN starts the communication. Actually, this is >>>>> pretty irrelevant, cause the two directions of a connections are hand= led >>>>> independently. the MN will send packets from app1 through CoA1 and >>>>> packets from app2 through CoA2 and it doesn't need any additional >>>>> actions from the HA for outgoing packets. >>>>>=20 >>>>> Now, the difficulty is with incoming packets. the MN needs to inform = the >>>>> HA about which CoA it wants to use to receive any flow. >>>>>=20 >>>>> Suppose that the HA has no flow bindings for the MN so far. >>>>>=20 >>>>> So, suppose that the app1 in CN starts a flow to the MN. The HA will >>>>> receive the packet and will send it though the CoA1 cause it is the o= ne >>>>> with higher priority. the MN is happy and there is no need to do >>>>> anything else. >>>>>=20 >>>>> Suppose now that the app2 in the CN starts a flow to the MN. Accordin= g >>>>> to RFC3697, the CN SHOULD assign a different flow label to the packet= s >>>>> belonging to this flow e.g. to this TCP connection. Let's assume it i= s >>>>> actually a TCP connection to make the example more concrete. >>>>> So, app2 opens a TCP connection to MN. CN then sends the TCP SYN to t= he >>>>> MN. >>>>> The HA receives the TCP SYN and since there is no flow binding state = for >>>>> this flow it forwards it through the CoA1 (the one with highest prior= ity) >>>>> The MN receives the TCP SYN through CoA1 and it realizes that this is >>>>> not compliant with its flow policy. So, it extracts the flow label >>>>> value, the src address and the dest address and it sends a BU to the = HA >>>>> stating that the flow identified by the flow label, src add and dest = add >>>>> needs to be bound to the CoA2. >>>>> Simultaneously, it also sends the TCP SYN+ACK back to the CN. >>>>> The CN receives the TCP SYN+ACK and sends the Ack back. the HA receiv= es >>>>> the ACk and will forward it based on the flow binding, i.e. through t= he >>>>> CoA. >>>>>=20 >>>>> the result is a method that never looks into higher layer information >>>>> for setting the flows. >>>>>=20 >>>>> makes sense? >>>>>=20 >>>>> Regards, marcelo >>>>>=20 >>>>>=20 >>>>> Hesham Soliman escribi=F3: >>>>> =20 >>>>> =20 >>>>>> On 17/05/09 3:04 PM, "marcelo bagnulo braun" wr= ote: >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>>> Hesham Soliman escribi=F3: >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>> The flow label should be part of any filter descriptor anyway. So = at >>>>>>>> anytime >>>>>>>> A MN can send a BU specifying that packets with flow label X shoul= d be >>>>>>>> directed to CoA1. I'm not sure how your proposal changes/adds to t= his. >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> what i am saying is that you don't need anything else other than th= is >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>> =3D> see below >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>>>> As a general issue, the flow label is unlikely to be used for this >>>>>>>> purpose >>>>>>>> until we resolve it's mutability issues >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> what mutability issues are you referring to? >>>>>>> AFAIU, the flow label is set randomly b the source and remains unch= anged >>>>>>> e2e and for the duration of the flow. >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>> =3D> I thought RFC 3697 talked about it being changed en route then ch= anged >>>>>> back before it hits the destination. But I just scanned it and I can= 't >>>>>> find >>>>>> this text. Maybe it was never included. >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>>>> and until it is actually _used_ in >>>>>>>> the API. At least until recently no one was using it. >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>> why do we need to have it in the API? It is only imporntat the the >>>>>>> source sets it to a random value and keep it unchenged e2e and for = the >>>>>>> duration of the flow. I understand that these conditions are met to= day, >>>>>>> right? >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>> =3D> But are you saying the src MIP6 module overwrites the potential f= low >>>>>> label set in the API? Because it is possible that an app sets the fl= ow >>>>>> label. RFC 3697 assumes the presence of an e2e mechanism to negotiat= e the >>>>>> flow label. If not then how do you make sure it's always unique? And= how >>>>>> do >>>>>> you make sure that the CN echoes back the same value in the flow lab= el? >>>>>> And what if the CN initiated the connection? >>>>>>=20 >>>>>> Hesham >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>=20 >>>> =20 >>>> =20 >>=20 >>=20 >>=20 >> =20 >=20 From hesham@elevatemobile.com Sun May 17 18:03: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 9C7AE3A6E33 for ; Sun, 17 May 2009 18:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, 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 4BnBwyu4wBL6 for ; Sun, 17 May 2009 18:03:32 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id A3D133A6819 for ; Sun, 17 May 2009 18:03: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 1M5rHt-000390-13; Mon, 18 May 2009 11:05:05 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 18 May 2009 11:05:02 +1000 From: Hesham Soliman To: marcelo bagnulo braun , mext Message-ID: Thread-Topic: [MEXT] implications for draft-tsirtsis-mext-binary-filters-00.txt Thread-Index: AcnXVKwEiJnk7ZGdSEG1qfAD9gMyaw== In-Reply-To: <4A106574.8040107@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [MEXT] implications for draft-tsirtsis-mext-binary-filters-00.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: Mon, 18 May 2009 01:03:33 -0000 > One more comments about the draft: > > (G)Source Port - Low > > This field identifies the lowest source port number within a range > of port numbers that will be used in data packets, as seen by the > home agent. > > (H)Source Port - High > > This field identifies the highest source port number within a > range of port numbers that will be used in data packets, as seen > by the home agent. If a single port is indicated then this field > SHOULD NOT be included. If it is included it SHOULD be set to the > value of the Source Port - Low field. > > (I)Destination Port - Low > > This field identifies the lowest destination port number within a > range of port numbers that will be used in data packets as seen by > the home agent. > > > (K)Destination Port - High > > This field identifies the highest destination port number within a > range of port numbers that will be used in data packets as seen by > the home agent. If a single port is indicated then this field > SHOULD NOT be included. If it is included it SHOULD be set to the > value of the Dst Port - Low field. > > > question: all these options can be present only if the (B)Protocol > option is present, correct? => I don't see why. You should be able to specify port that span transport protocols if you want. Of course, in practice all the well-known ports are allocated to both TCP and UDP anyway. Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From tsirtsis@googlemail.com Mon May 18 09:16: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 E8CAE3A6ED3 for ; Mon, 18 May 2009 09:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_LOLITA1=1.865, J_CHICKENPOX_33=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 nFGkznUKz4N8 for ; Mon, 18 May 2009 09:16:16 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id DC1513A6BC4 for ; Mon, 18 May 2009 09:15:54 -0700 (PDT) Received: by fxm2 with SMTP id 2so3340592fxm.37 for ; Mon, 18 May 2009 09:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+LkzCNcD/jOr4jE71FfzTUSZRSDWyAB2XLUjH2glPHo=; b=XNX136rOd2+etnv2MZS/n084vP0rtNTXq+WIPoTznBQXd4ng5cCPi2tElEILRRW3Z1 SBAvo7jg3ib/11fXnqTg+2OpJqqjFDaS9mrNPzwpAQwA6gP5Baww2k+0upgpLeQ/4Hc3 TziOYSl/HePFi7T7m8BjfTl01NgkbVa79U64k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IKkAI7fByJcBRpXbiSYAlPo+I4Xty//phVxUhya3y0XrKENjgxtpq2aarWt2fh7r4Z 7X0MOa1BghWGI0Lnex6Rv1UPVP8967imIARdYXAHepRhRQfXNUlSeg7XSdaH8Id5KW+3 ivtfg8mCE0FO6cFP+ponLqOOGC6Wtswyc+2uc= MIME-Version: 1.0 Received: by 10.223.108.15 with SMTP id d15mr4470289fap.105.1242663447165; Mon, 18 May 2009 09:17:27 -0700 (PDT) Date: Mon, 18 May 2009 12:17:26 -0400 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: [MEXT] about the nature of "flows" Re: weird idea about 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, 18 May 2009 16:16:18 -0000 Marcelo, It might be useful to step back a bit to understand better what the issue i= s. I think one issue in this discussion is that the use of the term "flow" in flow bindings in the flow bindings and flow description drafts, is currently a bit wider than that used in flow labels. Flow bindings, with any of the filter description formats discussed (text or binary) should be more accurately described as "packet filter rule binding". In other words, all our filter descriptions so far, have taken the view that the MN should have as much flexibility in identifying "flows" (or more accurately "filter rules") as a regular packet classifier e.g., firewall. You seem to think this is a bad idea and that only IP layer (and possibly transport layer?) fields should be used in the context of flow bindings. Am I right so far? I think that in the extreme, one could go further and say that packet routing should really be ONLY based on IP Addresses. Anything else is mostly broken since it can never scale and it is not compatible with regular IP routing. I am actually sympathetic to this view of the world in which it requires that the MN uses a different source address for every "flow" it wants to be able to route separately. Then flow bindings are simply implemented by redirecting the various MN addresses used to the different CoAs of the MN. The flow label, however, is IMO mostly an inadequate field to use for flow bindings. This is because a given MN has no control over when and how a given CN uses the flow label. Flow Bindings allow the MN to affect the 'last hop routing' of packets going from the HA to itself. It makes no sense to me for the MN to have to rely on the use of what is basically an optional field by random 3rd party nodes. In contrast, the flexibility provided by the binary flow description as you know is mostly about IP layer and Transport Layer fields, which I think are the minimum required to provide effecting flow binding capabilities. The recent addition of the Pointer idea simply expanded the capabilities to random upper layer field matching, I believe very elegantly and powerfully, if you do not mind me saying so ;-) Still, I think it is valid to question whether such higher layer matching capability is a good thing architecturally. As of yet, however, I am not sure I see what the issue is with providing such capability, beyond a somewhat academic issue of regular IP routing compatibility. As a side note, I have no problem whatsoever requiring that HAs perform deep packet inspection as the binary flow description draft requires. Commercial HAs are able to perform packet filter inspection, and are actually expected to do so, for other needs already (firewalling, lawful interception, value-add bells and whistles etc) so I do not see any issue there. Note that the use of Pointers for such deep header inspection is trivial compared to other methods since it does not require that the HA understands the upper layer header formats. It simply moves to byte X and matches Y number of bytes. On the MN side things are different and as I explained the complexity on the MN side is implementation specific. George On Sun, May 17, 2009 at 11:34 AM, marcelo bagnulo braun wrote: > George Tsirtsis escribi=C3=B3: >> >> Marcelo, >> >> Flow Movement is supposed to work in combination with DSMIPv6. Are you >> suggesting the flow bindings should only work for IPv6 traffic then? >> > > no, i ma suggesting that for IPv6 traffic, we should use the flow label > for ipv4, we certainly need to use something else > What i am not buying is that we cannot build a method that relies in the > flow label cause IPv4 doesn't support it. In other words, i think it is > perfeclty ok to build our reccomended method relying on the usage of the > flow label, and define some other hacks to support ipv4. >> >> why would we place such a restriction? >> >> BTW, as far as I know flow label is the least well defined aspect of >> IPv6. > > but that is not the porblem of IPv6, but it is an inherent problem of > defining a flow. The IP layer has a problem cause it is agonstic to flows= . > So, only the application knows what really a flow is. And IPv6 does provi= de > the means for the application to signal the packets that belong to flow t= o > the IP layer i.e. the flow label. > In other words, this is a fundamental problem: IP does not knows about fl= ows > and we are trying that MIP which is in the IP layer to discriminate flows= . > We can either try the IP layer to guess what are the common bits of a flo= w > or we can leverage on the explicit definition of a flow, which is what th= e > flow label is for. >> >> =C2=A0How does the MN know whether a given CN marks each relevant flow >> with a different flow label? > > becuase it needs to be compliant with RFC3697? >> >> Also note that flow labels are source >> address specific so the flow label by itself is not sufficient. >> >> > > sure, the flow description is src add, dst add and flow label > >> Also the binary format >> (http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00) in >> fact allows for a very simple MN implementation if the only thing you >> want to classify is flow labels. An implementation could only allow >> the flow label to be set resulting in the following flow descriptor: >> >> =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 >> =C2=A0 =C2=A0 =C2=A00 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 >> =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >> =C2=A0 =C2=A0 |0|0|0|0|0|0|0|0|0|0|0|0|M| 0000 | =C2=A0 =C2=A0 =C2=A0 (M= ) =C2=A0 Flow Label >> =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 FB (cont) =C2=A0 =C2=A0 | >> =C2=A0 =C2=A0 +-+-+-+-+-+-+-+ >> >> Or actually something like the above but including the source address >> too (flag C), do me more correct.. >> >> If an MN implementation does not want to deal with any of the other >> fields, it does not need to implement them. >> In that sense multiple compatible implementations are allowed as long >> as the HA implements the flow descriptors in their full complexity. >> >> > > this is my problem. I don't want to impose the HAs to be able to parse > arbitrary bits in the application data. I think this is not the right way= to > do it. I don't think the IP layer should be snooping into application dat= a > bits > >> Finally note that what constitutes a "flow" could be something like >> "ALL TCP Traffic", no matter which source address and what flow label >> is used. How would the MN be able to say push all TCP to one CoA and >> all UDP to another based on your scheme? >> > > well, you can do this based on the protocol field of the IP header > As i stated in my earlier reply to Hesham, i don't have a problem with us= ing > any IP header fields as flow descriptors and i may be ok with sing the > transport header bits (not what i would preffer, but hey, you can't alway= s > get what you want) > My problem is with supporting application data bits as part of the flow > description, which i really think is broken > > Makes sense? > > Regards, marcelo > > >> George >> >> >> On Sun, May 17, 2009 at 10:03 AM, marcelo bagnulo braun >> wrote: >> >>> >>> George Tsirtsis escribi=C3=B3: >>> >>>> >>>> Hi Marcelo, I now understand what you propose better. and it makes mor= e >>>> sense than I initially thought. >>>> >>>> Two issues, though: >>>> >>>> 1) this requires the CN to cooperate i.e., make proper use of flow >>>> labels. >>>> >>> >>> according to RFC3697: >>> >>> =C2=A0To enable Flow Label based classification, source nodes SHOULD as= sign >>> =C2=A0each unrelated transport connection and application data stream t= o a >>> =C2=A0new flow. >>> ... >>> >>> =C2=A0To enable applications and transport protocols to define what pac= kets >>> =C2=A0constitute a flow, the source node MUST provide means for the >>> =C2=A0applications and transport protocols to specify the Flow Label va= lues >>> =C2=A0to be used with their flows. =C2=A0The use of the means to specif= y Flow >>> =C2=A0Label values is subject to appropriate privileges (see section 5.= 1). >>> =C2=A0The source node SHOULD be able to select unused Flow Label values= for >>> =C2=A0flows not requesting a specific value to be used. >>> >>> So, yes but node should do this if they expect things to work properly >>> >>> >>>> >>>> It is not clear to me that even if all nodes populated the flow label >>>> (which I think is not even true) >>>> >>> >>> does anybody has information about the support of RFC3697 in current >>> OSes? >>> >>> >>>> >>>> , its use would be universally consistent in a way that would ensure >>>> that the setting of the flow label by the CN would be inline with what= the >>>> MN would like to identify as a flow. >>>> >>> >>> that would determine the granularity of the method >>> I am not sure the spectrum of choices is so big that this can be a >>> problem >>> could you think of some very different criteria to define what a flow i= s >>> that this would be an issue? >>> >>>> >>>> 2) This does not work for IPv4 traffic. >>>> >>>> >>> >>> i don't buy this argument. If we apply this argument, then we could nev= er >>> use the flow label for anything, since it doesn't work for IPv4. >>> >>> Reagrds, marcelo >>> >>> >>>> >>>> Thoughts? >>>> George >>>> On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun >>>> > wrote: >>>> >>>> =C2=A0 ok, let me try again because it seems i am failing miserably to >>>> =C2=A0 communicate what i want to say (or it simply so broken that peo= ple >>>> =C2=A0 cannot believe what they are reading :-) >>>> >>>> =C2=A0 Let's try with an example. >>>> >>>> =C2=A0 We have the MN who has two CoAs, CoA1 and CoA2. >>>> >>>> =C2=A0 The MN has a policy that says that it wants flows from app1 to = be >>>> =C2=A0 exchanged through CoA1 (well, the policy would say that they >>>> =C2=A0 should be received by the interfece in which CoA1 is configured= ) >>>> =C2=A0 and that flows from app2 to be exchanged through CoA2 (same >>>> =C2=A0 comment about the interface applies here) >>>> >>>> =C2=A0 In addition, MN has defined CoA1 to be the primary CoA i.e. the >>>> =C2=A0 CoA with highest priority. >>>> >>>> =C2=A0 So, we have two different situations. Either the MN starts the >>>> =C2=A0 communication or the CN starts the communication. Actually, thi= s >>>> =C2=A0 is pretty irrelevant, cause the two directions of a connections >>>> =C2=A0 are handled independently. the MN will send packets from app1 >>>> =C2=A0 through CoA1 and packets from app2 through CoA2 and it doesn't >>>> =C2=A0 need any additional actions from the HA for outgoing packets. >>>> >>>> =C2=A0 Now, the difficulty is with incoming packets. the MN needs to >>>> =C2=A0 inform the HA about which CoA it wants to use to receive any fl= ow. >>>> >>>> =C2=A0 Suppose that the HA has no flow bindings for the MN so far. >>>> >>>> =C2=A0 So, suppose that the app1 in CN starts a flow to the MN. The HA >>>> =C2=A0 will receive the packet and will send it though the CoA1 cause = it >>>> =C2=A0 is the one with higher priority. the MN is happy and there is n= o >>>> =C2=A0 need to do anything else. >>>> >>>> =C2=A0 Suppose now that the app2 in the CN starts a flow to the MN. >>>> =C2=A0 According to RFC3697, the CN SHOULD assign a different flow lab= el >>>> =C2=A0 to the packets belonging to this flow e.g. to this TCP connecti= on. >>>> =C2=A0 Let's assume it is actually a TCP connection to make the exampl= e >>>> =C2=A0 more concrete. >>>> =C2=A0 So, app2 opens a TCP connection to MN. CN then sends the TCP SY= N >>>> =C2=A0 to the MN. >>>> =C2=A0 The HA receives the TCP SYN and since there is no flow binding >>>> =C2=A0 state for this flow it forwards it through the CoA1 (the one wi= th >>>> =C2=A0 highest priority) >>>> =C2=A0 The MN receives the TCP SYN through CoA1 and it realizes that t= his >>>> =C2=A0 is not compliant with its flow policy. So, it extracts the flow >>>> =C2=A0 label value, the src address and the dest address and it sends = a >>>> =C2=A0 BU to the HA stating that the flow identified by the flow label= , >>>> =C2=A0 src add and dest add needs to be bound to the CoA2. >>>> =C2=A0 Simultaneously, it also sends the TCP SYN+ACK back to the CN. >>>> =C2=A0 The CN receives the TCP SYN+ACK and sends the Ack back. the HA >>>> =C2=A0 receives the ACk and will forward it based on the flow binding, >>>> =C2=A0 i.e. through the CoA. >>>> >>>> =C2=A0 the result is a method that never looks into higher layer >>>> =C2=A0 information for setting the flows. >>>> >>>> =C2=A0 makes sense? >>>> >>>> =C2=A0 Regards, marcelo >>>> >>>> >>>> =C2=A0 Hesham Soliman escribi=C3=B3: >>>> >>>> >>>> =C2=A0 =C2=A0 =C2=A0 On 17/05/09 3:04 PM, "marcelo bagnulo braun" >>>> =C2=A0 =C2=A0 =C2=A0 > = wrote: >>>> >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hesham Soliman escribi=C3=B3: >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The flow label should= be part of any filter descriptor >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 anyway. So at anytime >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A MN can send a BU sp= ecifying that packets with flow >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 label X should be >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 directed to CoA1. I'm= not sure how your proposal >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 changes/adds to this. >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 what i am saying is that you don't = need anything else >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 other than this >>>> >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =3D> see below >>>> >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 As a general issue, t= he flow label is unlikely to be >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used for this purpose >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 until we resolve it's= mutability issues >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 what mutability issues are you refe= rring to? >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AFAIU, the flow label is set random= ly b the source and >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 remains unchanged >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e2e and for the duration of the flo= w. >>>> >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =3D> I thought RFC 3697 talked about it being cha= nged en route >>>> =C2=A0 =C2=A0 =C2=A0 then changed >>>> =C2=A0 =C2=A0 =C2=A0 back before it hits the destination. But I just s= canned it and >>>> =C2=A0 =C2=A0 =C2=A0 I can't find >>>> =C2=A0 =C2=A0 =C2=A0 this text. Maybe it was never included. >>>> >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and until it is= actually _used_ in >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the API. At least unt= il recently no one was using it. >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 why do we need to have it in the AP= I? It is only imporntat >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the the >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 source sets it to a random value an= d keep it unchenged e2e >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and for the >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 duration of the flow. I understand = that these conditions >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are met today, >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 right? >>>> >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =3D> But are you saying the src MIP6 module overw= rites the >>>> =C2=A0 =C2=A0 =C2=A0 potential flow >>>> =C2=A0 =C2=A0 =C2=A0 label set in the API? Because it is possible that= an app sets >>>> =C2=A0 =C2=A0 =C2=A0 the flow >>>> =C2=A0 =C2=A0 =C2=A0 label. RFC 3697 assumes the presence of an e2e me= chanism to >>>> =C2=A0 =C2=A0 =C2=A0 negotiate the >>>> =C2=A0 =C2=A0 =C2=A0 flow label. If not then how do you make sure it's= always >>>> =C2=A0 =C2=A0 =C2=A0 unique? And how do >>>> =C2=A0 =C2=A0 =C2=A0 you make sure that the CN echoes back the same va= lue in the >>>> =C2=A0 =C2=A0 =C2=A0 flow label? >>>> =C2=A0 =C2=A0 =C2=A0 And what if the CN initiated the connection? >>>> >>>> =C2=A0 =C2=A0 =C2=A0 Hesham >>>> >>>> >>>> >>>> >>>> >>>> >>>> =C2=A0 _______________________________________________ >>>> =C2=A0 MEXT mailing list >>>> =C2=A0 MEXT@ietf.org >>>> =C2=A0 https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> >> >> > > From behcetsarikaya@yahoo.com Mon May 18 09:19: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 44AFF3A6B96 for ; Mon, 18 May 2009 09:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 1uFpjTDqrVJl for ; Mon, 18 May 2009 09:19:36 -0700 (PDT) Received: from n64.bullet.mail.sp1.yahoo.com (n64.bullet.mail.sp1.yahoo.com [98.136.44.189]) by core3.amsl.com (Postfix) with SMTP id 2743C3A6996 for ; Mon, 18 May 2009 09:19:36 -0700 (PDT) Received: from [69.147.84.145] by n64.bullet.mail.sp1.yahoo.com with NNFMP; 18 May 2009 16:21:09 -0000 Received: from [67.195.9.81] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 18 May 2009 16:21:09 -0000 Received: from [67.195.9.111] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 18 May 2009 16:21:08 -0000 Received: from [127.0.0.1] by omp115.mail.gq1.yahoo.com with NNFMP; 18 May 2009 16:21:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 268485.66706.bm@omp115.mail.gq1.yahoo.com Received: (qmail 42426 invoked by uid 60001); 18 May 2009 16:21:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242663668; bh=Lrkdwcj3fKDemSTmq5BBqj8JaRvuda1KHDKcP6MIlnM=; 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=3yhuIlDzwO9wOBYZ17dzBm8XYdgpDzrh/Ry3pivbrLfPN7RLwLOjKmWom7IudKJmohy5aU1GYcCvAhp/sYUu2A+CvLf3gF0LChdEDg+5Y8mx8swzp1Tm1tNbtd3O0i5h/yXsHAyvz92vQtk89p6BvZehkOi3MnEPBQj8oDGdknw= 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=w3OVEv8LKXLFKfLa90Klq2L8pTTxP15GYOXAXz34MGcwa0U5ix7ELT7AlZZXVNDXDGGwIQJl47kLngMlqCP1hRcMou8i/23eniBlFgiEaOGMkiANI+PXaAUvJqrHsYP++Is/hIT+RcuEFycFQHZaVMyoOUHc8BsKX9aRJ+DkHl0=; Message-ID: <588986.40970.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: QSKI9G0VM1lU2AuMLE2Gbmurt_aPuiOCXJ.z0KQUaeu2Tk0ha8qAUvE44mZMCk1MwPugNlmLfd8CbeLp0K114mpBTSrqx6xf57NuBRP.kuU9kE8wb.VAP0M_r0nyDAZnvzmdYdnTsZB5GJQh3dP97f70v7bSC.yFJpZ638.F7FjiqpGF6RjUlgdnLtDWQkhCy8QFOquDtgDPH0BziwR9WZthKplrEF0ClERcHjmOkgfqXiq7NptNL8OiAfK4YTyA4gMq02W5chXDCL14sJW.LSmku4Fi__jcunCiBOOT9euNufvx9IICk.FbD066y9ng4Q-- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Mon, 18 May 2009 09:21:08 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <4A1009D8.4060703@it.uc3m.es> Date: Mon, 18 May 2009 09:21:08 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun In-Reply-To: <4A1009D8.4060703@it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1021620265-1242663668=:40970" Cc: mext Subject: Re: [MEXT] weird idea about 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: Mon, 18 May 2009 16:19:37 -0000 --0-1021620265-1242663668=:40970 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marcelo,=0A=0A=A0 I support your proposal, I think it is inline with my = previous call for a new look into this problem.=0A=A0 My only comment is on= the BID. Why should MN send a BID? Since HA trusts MN, MN sending CoA for = the first time should register this CoA. This would make things even simple= r.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A________________________________=0AFro= m: marcelo bagnulo braun =0ATo: Hesham Soliman =0ACc: mext =0ASent: Sunday, May 17, 2009 = 7:58:00 AM=0ASubject: Re: [MEXT] weird idea about flow bindings=0A=0Aok, le= t me try again because it seems i am failing miserably to communicate what = i want to say (or it simply so broken that people cannot believe what they = are reading :-)=0A=0ALet's try with an example.=0A=0AWe have the MN who has= two CoAs, CoA1 and CoA2.=0A=0AThe MN has a policy that says that it wants = flows from app1 to be exchanged through CoA1 (well, the policy would say th= at they should be received by the interfece in which CoA1 is configured) an= d that flows from app2 to be exchanged through CoA2 (same comment about the= interface applies here)=0A=0AIn addition, MN has defined CoA1 to be the pr= imary CoA i.e. the CoA with highest priority.=0A=0ASo, we have two differen= t situations. Either the MN starts the communication or the CN starts the c= ommunication. Actually, this is pretty irrelevant, cause the two directions= of a connections are handled independently. the MN will send packets from = app1 through CoA1 and packets from app2 through CoA2 and it doesn't need an= y additional actions from the HA for outgoing packets.=0A=0ANow, the diffic= ulty is with incoming packets. the MN needs to inform the HA about which Co= A it wants to use to receive any flow.=0A=0ASuppose that the HA has no flow= bindings for the MN so far.=0A=0ASo, suppose that the app1 in CN starts a = flow to the MN. The HA will receive the packet and will send it though the = CoA1 cause it is the one with higher priority. the MN is happy and there is= no need to do anything else.=0A=0ASuppose now that the app2 in the CN star= ts a flow to the MN. According to RFC3697, the CN SHOULD assign a different= flow label to the packets belonging to this flow e.g. to this TCP connecti= on. Let's assume it is actually a TCP connection to make the example more c= oncrete.=0ASo, app2 opens a TCP connection to MN. CN then sends the TCP SYN= to the MN.=0AThe HA receives the TCP SYN and since there is no flow bindin= g state for this flow it forwards it through the CoA1 (the one with highest= priority)=0AThe MN receives the TCP SYN through CoA1 and it realizes that = this is not compliant with its flow policy. So, it extracts the flow label = value, the src address and the dest address and it sends a BU to the HA sta= ting that the flow identified by the flow label, src add and dest add needs= to be bound to the CoA2.=0ASimultaneously, it also sends the TCP SYN+ACK b= ack to the CN.=0AThe CN receives the TCP SYN+ACK and sends the Ack back. th= e HA receives the ACk and will forward it based on the flow binding, i.e. t= hrough the CoA.=0A=0Athe result is a method that never looks into higher la= yer information for setting the flows.=0A=0Amakes sense?=0A=0ARegards, marc= elo=0A=0A=0A --0-1021620265-1242663668=:40970 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marcelo,
=0A
  I support you= r proposal, I think it is inline with my previous call for a new look into = this problem.
=0A
  My only comment is on the BID. Why s= hould MN send a BID? Since HA trusts MN, MN sending CoA for the first time = should register this CoA. This would make things even simpler.
=0A 
=0A
Regards,
=0A
 
=0ABehcet
=0A
=0A
=0A<= B>From: marcelo bagnulo braun = <marcelo@it.uc3m.es>
To: Hesham Soliman <hesham@elevatemobile.com>
Cc: mext <mext@ietf.org>
Sent: Sunday, May 17, 2009 7:58:00 AM=
Subject: Re: [MEXT] wei= rd idea about flow bindings

ok, let me try again because it s= eems i am failing miserably to communicate what i want to say (or it simply= so broken that people cannot believe what they are reading :-)

Let'= s try with an example.

We have the MN who has two CoAs, CoA1 and CoA= 2.

The MN has a policy that says that it wants flows from app1 to be= exchanged through CoA1 (well, the policy would say that they should be rec= eived by the interfece in which CoA1 is configured) and that flows from app= 2 to be exchanged through CoA2 (same comment about the interface applies her= e)

In addition, MN has defined CoA1 to be the primary CoA i.e. the C= oA with highest priority.

So, we have two different situations. Eith= er the MN starts the communication or the CN starts the communication. Actu= ally, this is pretty irrelevant, cause the two directions of a connections = are handled independently. the MN will send packets from app1 through CoA1 = and packets from app2 through CoA2 and it doesn't need any additional actio= ns from the HA for outgoing packets.

Now, the difficulty is with inc= oming packets. the MN needs to inform the HA about which CoA it wants to us= e to receive any flow.

Suppose that the HA has no flow bindings for = the MN so far.

So, suppose that the app1 in CN starts a flow to the = MN. The HA will receive the packet and will send it though the CoA1 cause i= t is the one with higher priority. the MN is happy and there is no need to do anything else.

Suppose now that the app2 in the CN start= s a flow to the MN. According to RFC3697, the CN SHOULD assign a different = flow label to the packets belonging to this flow e.g. to this TCP connectio= n. Let's assume it is actually a TCP connection to make the example more co= ncrete.
So, app2 opens a TCP connection to MN. CN then sends the TCP SYN= to the MN.
The HA receives the TCP SYN and since there is no flow bindi= ng state for this flow it forwards it through the CoA1 (the one with highes= t priority)
The MN receives the TCP SYN through CoA1 and it realizes tha= t this is not compliant with its flow policy. So, it extracts the flow labe= l value, the src address and the dest address and it sends a BU to the HA s= tating that the flow identified by the flow label, src add and dest add nee= ds to be bound to the CoA2.
Simultaneously, it also sends the TCP SYN+AC= K back to the CN.
The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives the ACk and will forward it based on the flow bi= nding, i.e. through the CoA.

the result is a method that never looks= into higher layer information for setting the flows.

makes sense?
Regards, marcelo

=0A=0A=0A=0A --0-1021620265-1242663668=:40970-- From marcelo@it.uc3m.es Mon May 18 09:37: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 957F93A6825 for ; Mon, 18 May 2009 09:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.295 X-Spam-Level: X-Spam-Status: No, score=-4.295 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, FRT_LOLITA1=1.865, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 7JZtSrspN6ha for ; Mon, 18 May 2009 09:37:06 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 62D923A6BA1 for ; Mon, 18 May 2009 09:37:06 -0700 (PDT) Received: from r190-135-23-167.dialup.adsl.anteldata.net.uy (r190-135-23-167.dialup.adsl.anteldata.net.uy [190.135.23.167]) by smtp01.uc3m.es (Postfix) with ESMTP id 46179B49FE2; Mon, 18 May 2009 18:38:33 +0200 (CEST) Message-ID: <4A118F06.1040905@it.uc3m.es> Date: Mon, 18 May 2009 18:38:30 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Tsirtsis References: 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-16650.000 Cc: mext Subject: Re: [MEXT] about the nature of "flows" Re: weird idea about 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, 18 May 2009 16:37:08 -0000 George Tsirtsis escribió: > Marcelo, > > It might be useful to step back a bit to understand better what the issue is. > > I think one issue in this discussion is that the use of the term > "flow" in flow bindings in the flow bindings and flow description > drafts, is currently a bit wider than that used in flow labels. Flow > bindings, with any of the filter description formats discussed (text > or binary) should be more accurately described as "packet filter rule > binding". > > In other words, all our filter descriptions so far, have taken the > view that the MN should have as much flexibility in identifying > "flows" (or more accurately "filter rules") as a regular packet > classifier e.g., firewall. You seem to think this is a bad idea and > that only IP layer (and possibly transport layer?) fields should be > used in the context of flow bindings. > > Am I right so far? > correct > I think that in the extreme, one could go further and say that packet > routing should really be ONLY based on IP Addresses. not really, the flow label is explcitly there to provide special treatment to flows. Same with the traffci class bits. It is perfectly ok to use those a part of the routing decisions imho > Anything else is > mostly broken since it can never scale and it is not compatible with > regular IP routing. I am actually sympathetic to this view of the > world in which it requires that the MN uses a different source address > for every "flow" it wants to be able to route separately. Then flow > bindings are simply implemented by redirecting the various MN > addresses used to the different CoAs of the MN. > > The flow label, however, is IMO mostly an inadequate field to use for > flow bindings. This is because a given MN has no control over when and > how a given CN uses the flow label.Flow Bindings allow the MN to > > affect the 'last hop routing' of packets going from the HA to itself. > It makes no sense to me for the MN to have to rely on the use of what > is basically an optional field by random 3rd party nodes. > > I think we are focusing in different ways of splitting the problem. IMHO, the IP layer does not know what an application flow is. It doens't knwo how the application set different bits and what it is more it doesn't have to know. The flow label is a handle for the IP layer to know what a flow is. Making the IP layer second guess what a flow is, is not the best idea. So, while you see the division MN/CN, i am concerned in the divsion IP layer/app layer > In contrast, the flexibility provided by the binary flow description > as you know is mostly about IP layer and Transport Layer fields, which > I think are the minimum required to provide effecting flow binding > capabilities. The recent addition of the Pointer idea simply expanded > the capabilities to random upper layer field matching, I believe very > elegantly and powerfully, if you do not mind me saying so ;-) > well, i do mind. as defined in the draft Offset The Offset field identifies an integer number of bytes from the beginning of the IP header. It points to the beginning of the field of interest in the packet. So, suppose that the idea is to use application layer bits. Now what happens if the IP layer adds an extension header or an option inside a header? What happens if the TCP inserts one option? What happens with applications that we don't know the format (such as skype)? > Still, I think it is valid to question whether such higher layer > matching capability is a good thing architecturally. As of yet, > however, I am not sure I see what the issue is with providing such > capability, beyond a somewhat academic issue of regular IP routing > compatibility. > > well, here i guess we disagree. including application data bit pattern in mip signalling doesn't seem the best architecture to me. Layer violation seems at least one issue here Regards, marcelo > As a side note, I have no problem whatsoever requiring that HAs > perform deep packet inspection as the binary flow description draft > requires. Commercial HAs are able to perform packet filter inspection, > and are actually expected to do so, for other needs already > (firewalling, lawful interception, value-add bells and whistles etc) > so I do not see any issue there. Note that the use of Pointers for > such deep header inspection is trivial compared to other methods since > it does not require that the HA understands the upper layer header > formats. It simply moves to byte X and matches Y number of bytes. On > the MN side things are different and as I explained the complexity on > the MN side is implementation specific. > > George > > > On Sun, May 17, 2009 at 11:34 AM, marcelo bagnulo braun > wrote: > >> George Tsirtsis escribió: >> >>> Marcelo, >>> >>> Flow Movement is supposed to work in combination with DSMIPv6. Are you >>> suggesting the flow bindings should only work for IPv6 traffic then? >>> >>> >> no, i ma suggesting that for IPv6 traffic, we should use the flow label >> for ipv4, we certainly need to use something else >> What i am not buying is that we cannot build a method that relies in the >> flow label cause IPv4 doesn't support it. In other words, i think it is >> perfeclty ok to build our reccomended method relying on the usage of the >> flow label, and define some other hacks to support ipv4. >> >>> why would we place such a restriction? >>> >>> BTW, as far as I know flow label is the least well defined aspect of >>> IPv6. >>> >> but that is not the porblem of IPv6, but it is an inherent problem of >> defining a flow. The IP layer has a problem cause it is agonstic to flows. >> So, only the application knows what really a flow is. And IPv6 does provide >> the means for the application to signal the packets that belong to flow to >> the IP layer i.e. the flow label. >> In other words, this is a fundamental problem: IP does not knows about flows >> and we are trying that MIP which is in the IP layer to discriminate flows. >> We can either try the IP layer to guess what are the common bits of a flow >> or we can leverage on the explicit definition of a flow, which is what the >> flow label is for. >> >>> How does the MN know whether a given CN marks each relevant flow >>> with a different flow label? >>> >> becuase it needs to be compliant with RFC3697? >> >>> Also note that flow labels are source >>> address specific so the flow label by itself is not sufficient. >>> >>> >>> >> sure, the flow description is src add, dst add and flow label >> >> >>> Also the binary format >>> (http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00) in >>> fact allows for a very simple MN implementation if the only thing you >>> want to classify is flow labels. An implementation could only allow >>> the flow label to be set resulting in the following flow descriptor: >>> >>> 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 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0|0|0|0|0|0|0|0|0|0|0|0|M| 0000 | (M) Flow Label >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> FB (cont) | >>> +-+-+-+-+-+-+-+ >>> >>> Or actually something like the above but including the source address >>> too (flag C), do me more correct.. >>> >>> If an MN implementation does not want to deal with any of the other >>> fields, it does not need to implement them. >>> In that sense multiple compatible implementations are allowed as long >>> as the HA implements the flow descriptors in their full complexity. >>> >>> >>> >> this is my problem. I don't want to impose the HAs to be able to parse >> arbitrary bits in the application data. I think this is not the right way to >> do it. I don't think the IP layer should be snooping into application data >> bits >> >> >>> Finally note that what constitutes a "flow" could be something like >>> "ALL TCP Traffic", no matter which source address and what flow label >>> is used. How would the MN be able to say push all TCP to one CoA and >>> all UDP to another based on your scheme? >>> >>> >> well, you can do this based on the protocol field of the IP header >> As i stated in my earlier reply to Hesham, i don't have a problem with using >> any IP header fields as flow descriptors and i may be ok with sing the >> transport header bits (not what i would preffer, but hey, you can't always >> get what you want) >> My problem is with supporting application data bits as part of the flow >> description, which i really think is broken >> >> Makes sense? >> >> Regards, marcelo >> >> >> >>> George >>> >>> >>> On Sun, May 17, 2009 at 10:03 AM, marcelo bagnulo braun >>> wrote: >>> >>> >>>> George Tsirtsis escribió: >>>> >>>> >>>>> Hi Marcelo, I now understand what you propose better. and it makes more >>>>> sense than I initially thought. >>>>> >>>>> Two issues, though: >>>>> >>>>> 1) this requires the CN to cooperate i.e., make proper use of flow >>>>> labels. >>>>> >>>>> >>>> according to RFC3697: >>>> >>>> To enable Flow Label based classification, source nodes SHOULD assign >>>> each unrelated transport connection and application data stream to a >>>> new flow. >>>> ... >>>> >>>> To enable applications and transport protocols to define what packets >>>> constitute a flow, the source node MUST provide means for the >>>> applications and transport protocols to specify the Flow Label values >>>> to be used with their flows. The use of the means to specify Flow >>>> Label values is subject to appropriate privileges (see section 5.1). >>>> The source node SHOULD be able to select unused Flow Label values for >>>> flows not requesting a specific value to be used. >>>> >>>> So, yes but node should do this if they expect things to work properly >>>> >>>> >>>> >>>>> It is not clear to me that even if all nodes populated the flow label >>>>> (which I think is not even true) >>>>> >>>>> >>>> does anybody has information about the support of RFC3697 in current >>>> OSes? >>>> >>>> >>>> >>>>> , its use would be universally consistent in a way that would ensure >>>>> that the setting of the flow label by the CN would be inline with what the >>>>> MN would like to identify as a flow. >>>>> >>>>> >>>> that would determine the granularity of the method >>>> I am not sure the spectrum of choices is so big that this can be a >>>> problem >>>> could you think of some very different criteria to define what a flow is >>>> that this would be an issue? >>>> >>>> >>>>> 2) This does not work for IPv4 traffic. >>>>> >>>>> >>>>> >>>> i don't buy this argument. If we apply this argument, then we could never >>>> use the flow label for anything, since it doesn't work for IPv4. >>>> >>>> Reagrds, marcelo >>>> >>>> >>>> >>>>> Thoughts? >>>>> George >>>>> On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun >>>>> > wrote: >>>>> >>>>> ok, let me try again because it seems i am failing miserably to >>>>> communicate what i want to say (or it simply so broken that people >>>>> cannot believe what they are reading :-) >>>>> >>>>> Let's try with an example. >>>>> >>>>> We have the MN who has two CoAs, CoA1 and CoA2. >>>>> >>>>> The MN has a policy that says that it wants flows from app1 to be >>>>> exchanged through CoA1 (well, the policy would say that they >>>>> should be received by the interfece in which CoA1 is configured) >>>>> and that flows from app2 to be exchanged through CoA2 (same >>>>> comment about the interface applies here) >>>>> >>>>> In addition, MN has defined CoA1 to be the primary CoA i.e. the >>>>> CoA with highest priority. >>>>> >>>>> So, we have two different situations. Either the MN starts the >>>>> communication or the CN starts the communication. Actually, this >>>>> is pretty irrelevant, cause the two directions of a connections >>>>> are handled independently. the MN will send packets from app1 >>>>> through CoA1 and packets from app2 through CoA2 and it doesn't >>>>> need any additional actions from the HA for outgoing packets. >>>>> >>>>> Now, the difficulty is with incoming packets. the MN needs to >>>>> inform the HA about which CoA it wants to use to receive any flow. >>>>> >>>>> Suppose that the HA has no flow bindings for the MN so far. >>>>> >>>>> So, suppose that the app1 in CN starts a flow to the MN. The HA >>>>> will receive the packet and will send it though the CoA1 cause it >>>>> is the one with higher priority. the MN is happy and there is no >>>>> need to do anything else. >>>>> >>>>> Suppose now that the app2 in the CN starts a flow to the MN. >>>>> According to RFC3697, the CN SHOULD assign a different flow label >>>>> to the packets belonging to this flow e.g. to this TCP connection. >>>>> Let's assume it is actually a TCP connection to make the example >>>>> more concrete. >>>>> So, app2 opens a TCP connection to MN. CN then sends the TCP SYN >>>>> to the MN. >>>>> The HA receives the TCP SYN and since there is no flow binding >>>>> state for this flow it forwards it through the CoA1 (the one with >>>>> highest priority) >>>>> The MN receives the TCP SYN through CoA1 and it realizes that this >>>>> is not compliant with its flow policy. So, it extracts the flow >>>>> label value, the src address and the dest address and it sends a >>>>> BU to the HA stating that the flow identified by the flow label, >>>>> src add and dest add needs to be bound to the CoA2. >>>>> Simultaneously, it also sends the TCP SYN+ACK back to the CN. >>>>> The CN receives the TCP SYN+ACK and sends the Ack back. the HA >>>>> receives the ACk and will forward it based on the flow binding, >>>>> i.e. through the CoA. >>>>> >>>>> the result is a method that never looks into higher layer >>>>> information for setting the flows. >>>>> >>>>> makes sense? >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> Hesham Soliman escribió: >>>>> >>>>> >>>>> On 17/05/09 3:04 PM, "marcelo bagnulo braun" >>>>> > wrote: >>>>> >>>>> >>>>> Hesham Soliman escribió: >>>>> >>>>> The flow label should be part of any filter descriptor >>>>> anyway. So at anytime >>>>> A MN can send a BU specifying that packets with flow >>>>> label X should be >>>>> directed to CoA1. I'm not sure how your proposal >>>>> changes/adds to this. >>>>> >>>>> what i am saying is that you don't need anything else >>>>> other than this >>>>> >>>>> >>>>> => see below >>>>> >>>>> >>>>> As a general issue, the flow label is unlikely to be >>>>> used for this purpose >>>>> until we resolve it's mutability issues >>>>> >>>>> what mutability issues are you referring to? >>>>> AFAIU, the flow label is set randomly b the source and >>>>> remains unchanged >>>>> e2e and for the duration of the flow. >>>>> >>>>> >>>>> => I thought RFC 3697 talked about it being changed en route >>>>> then changed >>>>> back before it hits the destination. But I just scanned it and >>>>> I can't find >>>>> this text. Maybe it was never included. >>>>> >>>>> >>>>> and until it is actually _used_ in >>>>> the API. At least until recently no one was using it. >>>>> >>>>> why do we need to have it in the API? It is only imporntat >>>>> the the >>>>> source sets it to a random value and keep it unchenged e2e >>>>> and for the >>>>> duration of the flow. I understand that these conditions >>>>> are met today, >>>>> right? >>>>> >>>>> >>>>> => But are you saying the src MIP6 module overwrites the >>>>> potential flow >>>>> label set in the API? Because it is possible that an app sets >>>>> the flow >>>>> label. RFC 3697 assumes the presence of an e2e mechanism to >>>>> negotiate the >>>>> flow label. If not then how do you make sure it's always >>>>> unique? And how do >>>>> you make sure that the CN echoes back the same value in the >>>>> flow label? >>>>> And what if the CN initiated the connection? >>>>> >>>>> Hesham >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>>> >>>>> >>> >> > > From Michael.G.Williams@nokia.com Mon May 18 10:05: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 2FB5B28C289 for ; Mon, 18 May 2009 10:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.306 X-Spam-Level: X-Spam-Status: No, score=-5.306 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_00=-2.599, FRT_LOLITA1=1.865, J_CHICKENPOX_33=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 0ZlyQQKjHZRw for ; Mon, 18 May 2009 10:05:20 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 28A693A6935 for ; Mon, 18 May 2009 10:05:20 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4IH6Z6P024302; Mon, 18 May 2009 12:06:51 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 20:06:42 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 20:06:34 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 18 May 2009 19:06:33 +0200 From: To: , Date: Mon, 18 May 2009 19:06:28 +0200 Thread-Topic: [MEXT] about the nature of "flows" Re: weird idea about flow bindings Thread-Index: AcnX1EfnvpaF++Z1T4mgg2lP+ggH7AAAmr9g Message-ID: References: In-Reply-To: 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-OriginalArrivalTime: 18 May 2009 17:06:34.0382 (UTC) FILETIME=[FF5BD2E0:01C9D7DA] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] about the nature of "flows" Re: weird idea about 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, 18 May 2009 17:05:22 -0000 Isn't the HA strictly routing and signaling, not verifying packets belong t= o a flow? Other functions handle that duty already. If so, the HA flows sho= uld be within scope of L3 routing, and the HA's signaling plane. Kind Regards, Michael -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of ext= George Tsirtsis Sent: 18 May, 2009 17:17 To: marcelo bagnulo braun Cc: mext Subject: [MEXT] about the nature of "flows" Re: weird idea about flow bindi= ngs Marcelo, It might be useful to step back a bit to understand better what the issue i= s. I think one issue in this discussion is that the use of the term "flow" in = flow bindings in the flow bindings and flow description drafts, is currentl= y a bit wider than that used in flow labels. Flow bindings, with any of the= filter description formats discussed (text or binary) should be more accur= ately described as "packet filter rule binding". In other words, all our filter descriptions so far, have taken the view tha= t the MN should have as much flexibility in identifying "flows" (or more ac= curately "filter rules") as a regular packet classifier e.g., firewall. You= seem to think this is a bad idea and that only IP layer (and possibly tran= sport layer?) fields should be used in the context of flow bindings. Am I right so far? I think that in the extreme, one could go further and say that packet routi= ng should really be ONLY based on IP Addresses. Anything else is mostly bro= ken since it can never scale and it is not compatible with regular IP routi= ng. I am actually sympathetic to this view of the world in which it require= s that the MN uses a different source address for every "flow" it wants to = be able to route separately. Then flow bindings are simply implemented by r= edirecting the various MN addresses used to the different CoAs of the MN. The flow label, however, is IMO mostly an inadequate field to use for flow = bindings. This is because a given MN has no control over when and how a giv= en CN uses the flow label. Flow Bindings allow the MN to affect the 'last h= op routing' of packets going from the HA to itself. It makes no sense to me for the MN to have to rely on the use of what is ba= sically an optional field by random 3rd party nodes. In contrast, the flexibility provided by the binary flow description as you= know is mostly about IP layer and Transport Layer fields, which I think ar= e the minimum required to provide effecting flow binding capabilities. The = recent addition of the Pointer idea simply expanded the capabilities to ran= dom upper layer field matching, I believe very elegantly and powerfully, if= you do not mind me saying so ;-) Still, I think it is valid to question whether such higher layer matching c= apability is a good thing architecturally. As of yet, however, I am not sur= e I see what the issue is with providing such capability, beyond a somewhat= academic issue of regular IP routing compatibility. As a side note, I have no problem whatsoever requiring that HAs perform dee= p packet inspection as the binary flow description draft requires. Commerci= al HAs are able to perform packet filter inspection, and are actually expec= ted to do so, for other needs already (firewalling, lawful interception, va= lue-add bells and whistles etc) so I do not see any issue there. Note that = the use of Pointers for such deep header inspection is trivial compared to = other methods since it does not require that the HA understands the upper l= ayer header formats. It simply moves to byte X and matches Y number of byte= s. On the MN side things are different and as I explained the complexity on= the MN side is implementation specific. George On Sun, May 17, 2009 at 11:34 AM, marcelo bagnulo braun wrote: > George Tsirtsis escribi=F3: >> >> Marcelo, >> >> Flow Movement is supposed to work in combination with DSMIPv6. Are >> you suggesting the flow bindings should only work for IPv6 traffic then? >> > > no, i ma suggesting that for IPv6 traffic, we should use the flow > label for ipv4, we certainly need to use something else What i am not > buying is that we cannot build a method that relies in the flow label > cause IPv4 doesn't support it. In other words, i think it is perfeclty > ok to build our reccomended method relying on the usage of the flow > label, and define some other hacks to support ipv4. >> >> why would we place such a restriction? >> >> BTW, as far as I know flow label is the least well defined aspect of >> IPv6. > > but that is not the porblem of IPv6, but it is an inherent problem of > defining a flow. The IP layer has a problem cause it is agonstic to flows= . > So, only the application knows what really a flow is. And IPv6 does > provide the means for the application to signal the packets that > belong to flow to the IP layer i.e. the flow label. > In other words, this is a fundamental problem: IP does not knows about > flows and we are trying that MIP which is in the IP layer to discriminate= flows. > We can either try the IP layer to guess what are the common bits of a > flow or we can leverage on the explicit definition of a flow, which is > what the flow label is for. >> >> How does the MN know whether a given CN marks each relevant flow >> with a different flow label? > > becuase it needs to be compliant with RFC3697? >> >> Also note that flow labels are source address specific so the flow >> label by itself is not sufficient. >> >> > > sure, the flow description is src add, dst add and flow label > >> Also the binary format >> (http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00) in >> fact allows for a very simple MN implementation if the only thing you >> want to classify is flow labels. An implementation could only allow >> the flow label to be set resulting in the following flow descriptor: >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0|0|0|0|0|0|0|0|0|0|0|0|M| 0000 | (M) Flow Label >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> FB (cont) | >> +-+-+-+-+-+-+-+ >> >> Or actually something like the above but including the source address >> too (flag C), do me more correct.. >> >> If an MN implementation does not want to deal with any of the other >> fields, it does not need to implement them. >> In that sense multiple compatible implementations are allowed as long >> as the HA implements the flow descriptors in their full complexity. >> >> > > this is my problem. I don't want to impose the HAs to be able to parse > arbitrary bits in the application data. I think this is not the right > way to do it. I don't think the IP layer should be snooping into > application data bits > >> Finally note that what constitutes a "flow" could be something like >> "ALL TCP Traffic", no matter which source address and what flow label >> is used. How would the MN be able to say push all TCP to one CoA and >> all UDP to another based on your scheme? >> > > well, you can do this based on the protocol field of the IP header As > i stated in my earlier reply to Hesham, i don't have a problem with > using any IP header fields as flow descriptors and i may be ok with > sing the transport header bits (not what i would preffer, but hey, you > can't always get what you want) My problem is with supporting > application data bits as part of the flow description, which i really > think is broken > > Makes sense? > > Regards, marcelo > > >> George >> >> >> On Sun, May 17, 2009 at 10:03 AM, marcelo bagnulo braun >> wrote: >> >>> >>> George Tsirtsis escribi=F3: >>> >>>> >>>> Hi Marcelo, I now understand what you propose better. and it makes >>>> more sense than I initially thought. >>>> >>>> Two issues, though: >>>> >>>> 1) this requires the CN to cooperate i.e., make proper use of flow >>>> labels. >>>> >>> >>> according to RFC3697: >>> >>> To enable Flow Label based classification, source nodes SHOULD >>> assign >>> each unrelated transport connection and application data stream to >>> a >>> new flow. >>> ... >>> >>> To enable applications and transport protocols to define what >>> packets >>> constitute a flow, the source node MUST provide means for the >>> applications and transport protocols to specify the Flow Label >>> values >>> to be used with their flows. The use of the means to specify Flow >>> Label values is subject to appropriate privileges (see section 5.1). >>> The source node SHOULD be able to select unused Flow Label values >>> for >>> flows not requesting a specific value to be used. >>> >>> So, yes but node should do this if they expect things to work >>> properly >>> >>> >>>> >>>> It is not clear to me that even if all nodes populated the flow >>>> label (which I think is not even true) >>>> >>> >>> does anybody has information about the support of RFC3697 in current >>> OSes? >>> >>> >>>> >>>> , its use would be universally consistent in a way that would >>>> ensure that the setting of the flow label by the CN would be inline >>>> with what the MN would like to identify as a flow. >>>> >>> >>> that would determine the granularity of the method I am not sure the >>> spectrum of choices is so big that this can be a problem could you >>> think of some very different criteria to define what a flow is that >>> this would be an issue? >>> >>>> >>>> 2) This does not work for IPv4 traffic. >>>> >>>> >>> >>> i don't buy this argument. If we apply this argument, then we could >>> never use the flow label for anything, since it doesn't work for IPv4. >>> >>> Reagrds, marcelo >>> >>> >>>> >>>> Thoughts? >>>> George >>>> On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun >>>> > wrote: >>>> >>>> ok, let me try again because it seems i am failing miserably to >>>> communicate what i want to say (or it simply so broken that >>>> people >>>> cannot believe what they are reading :-) >>>> >>>> Let's try with an example. >>>> >>>> We have the MN who has two CoAs, CoA1 and CoA2. >>>> >>>> The MN has a policy that says that it wants flows from app1 to be >>>> exchanged through CoA1 (well, the policy would say that they >>>> should be received by the interfece in which CoA1 is configured) >>>> and that flows from app2 to be exchanged through CoA2 (same >>>> comment about the interface applies here) >>>> >>>> In addition, MN has defined CoA1 to be the primary CoA i.e. the >>>> CoA with highest priority. >>>> >>>> So, we have two different situations. Either the MN starts the >>>> communication or the CN starts the communication. Actually, this >>>> is pretty irrelevant, cause the two directions of a connections >>>> are handled independently. the MN will send packets from app1 >>>> through CoA1 and packets from app2 through CoA2 and it doesn't >>>> need any additional actions from the HA for outgoing packets. >>>> >>>> Now, the difficulty is with incoming packets. the MN needs to >>>> inform the HA about which CoA it wants to use to receive any flow. >>>> >>>> Suppose that the HA has no flow bindings for the MN so far. >>>> >>>> So, suppose that the app1 in CN starts a flow to the MN. The HA >>>> will receive the packet and will send it though the CoA1 cause it >>>> is the one with higher priority. the MN is happy and there is no >>>> need to do anything else. >>>> >>>> Suppose now that the app2 in the CN starts a flow to the MN. >>>> According to RFC3697, the CN SHOULD assign a different flow label >>>> to the packets belonging to this flow e.g. to this TCP connection. >>>> Let's assume it is actually a TCP connection to make the example >>>> more concrete. >>>> So, app2 opens a TCP connection to MN. CN then sends the TCP SYN >>>> to the MN. >>>> The HA receives the TCP SYN and since there is no flow binding >>>> state for this flow it forwards it through the CoA1 (the one with >>>> highest priority) >>>> The MN receives the TCP SYN through CoA1 and it realizes that >>>> this >>>> is not compliant with its flow policy. So, it extracts the flow >>>> label value, the src address and the dest address and it sends a >>>> BU to the HA stating that the flow identified by the flow label, >>>> src add and dest add needs to be bound to the CoA2. >>>> Simultaneously, it also sends the TCP SYN+ACK back to the CN. >>>> The CN receives the TCP SYN+ACK and sends the Ack back. the HA >>>> receives the ACk and will forward it based on the flow binding, >>>> i.e. through the CoA. >>>> >>>> the result is a method that never looks into higher layer >>>> information for setting the flows. >>>> >>>> makes sense? >>>> >>>> Regards, marcelo >>>> >>>> >>>> Hesham Soliman escribi=F3: >>>> >>>> >>>> On 17/05/09 3:04 PM, "marcelo bagnulo braun" >>>> > wrote: >>>> >>>> >>>> Hesham Soliman escribi=F3: >>>> >>>> The flow label should be part of any filter >>>> descriptor >>>> anyway. So at anytime >>>> A MN can send a BU specifying that packets with flow >>>> label X should be >>>> directed to CoA1. I'm not sure how your proposal >>>> changes/adds to this. >>>> >>>> what i am saying is that you don't need anything else >>>> other than this >>>> >>>> >>>> =3D> see below >>>> >>>> >>>> As a general issue, the flow label is unlikely to be >>>> used for this purpose >>>> until we resolve it's mutability issues >>>> >>>> what mutability issues are you referring to? >>>> AFAIU, the flow label is set randomly b the source and >>>> remains unchanged >>>> e2e and for the duration of the flow. >>>> >>>> >>>> =3D> I thought RFC 3697 talked about it being changed en route >>>> then changed >>>> back before it hits the destination. But I just scanned it >>>> and >>>> I can't find >>>> this text. Maybe it was never included. >>>> >>>> >>>> and until it is actually _used_ in >>>> the API. At least until recently no one was using it. >>>> >>>> why do we need to have it in the API? It is only >>>> imporntat >>>> the the >>>> source sets it to a random value and keep it unchenged >>>> e2e >>>> and for the >>>> duration of the flow. I understand that these conditions >>>> are met today, >>>> right? >>>> >>>> >>>> =3D> But are you saying the src MIP6 module overwrites the >>>> potential flow >>>> label set in the API? Because it is possible that an app sets >>>> the flow >>>> label. RFC 3697 assumes the presence of an e2e mechanism to >>>> negotiate the >>>> flow label. If not then how do you make sure it's always >>>> unique? And how do >>>> you make sure that the CN echoes back the same value in the >>>> flow label? >>>> And what if the CN initiated the connection? >>>> >>>> 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 From tsirtsis@googlemail.com Mon May 18 10:05:31 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 E36FD28C325 for ; Mon, 18 May 2009 10:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_LOLITA1=1.865, J_CHICKENPOX_33=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 xHYgM8bqqzkY for ; Mon, 18 May 2009 10:05:23 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id AD7AF3A6935 for ; Mon, 18 May 2009 10:05:22 -0700 (PDT) Received: by fxm2 with SMTP id 2so3368016fxm.37 for ; Mon, 18 May 2009 10:06: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=70BRzmltGPCqeoIc58dYpRL8TLi6ml5mA7VfKgMJPrY=; b=WQ0FL1//HRIEKCrHBJ9a4SmkkCkNykMIFcQGUK0qmU5wQzlaNIUakVgT84SzjhHKlI QNpXew03w21RoAef8zGymBNVfNxxAHAYA2w0qNLHDE8h9YLHjMTFkjL/9zi0KegsJGW1 U3VwGjRpyXOhfa2ZmjotQyUX9n+lRAkk9o5aQ= 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=uMTzq4DD7ypxSw9unOfpMabnu4P0Ybc0xMfr6uJzQzJF+ogoDs12CMuMO3GC9KLg56 JQ5K7leV0cA+zI9v3/UwhEuG9CL90cCNpCx69tGPdz3ZpGorM1gZgXN6dCywBWY/OHeC j4oFPH+8Dham3H9nx7WIcLXrZRB/B1JfK8aZ4= MIME-Version: 1.0 Received: by 10.223.125.144 with SMTP id y16mr4505350far.93.1242666410892; Mon, 18 May 2009 10:06:50 -0700 (PDT) In-Reply-To: <4A118F06.1040905@it.uc3m.es> References: <4A118F06.1040905@it.uc3m.es> Date: Mon, 18 May 2009 13:06:50 -0400 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] about the nature of "flows" Re: weird idea about 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, 18 May 2009 17:05:32 -0000 inline... On Mon, May 18, 2009 at 12:38 PM, marcelo bagnulo braun wrote: > George Tsirtsis escribi=C3=B3: >> >> Marcelo, >> >> It might be useful to step back a bit to understand better what the issu= e >> is. >> >> I think one issue in this discussion is that the use of the term >> "flow" in flow bindings in the flow bindings and flow description >> drafts, is currently a bit wider than that used in flow labels. Flow >> bindings, with any of the filter description formats discussed (text >> or binary) should be more accurately described as "packet filter rule >> binding". >> >> In other words, all our filter descriptions so far, have taken the >> view that the MN should have as much flexibility in identifying >> "flows" (or more accurately "filter rules") as a regular packet >> classifier e.g., firewall. You seem to think this is a bad idea and >> that only IP layer (and possibly transport layer?) fields should be >> used in the context of flow bindings. >> >> Am I right so far? >> > > correct GT> Just to make sure we are on the same page, do you agree that flow label is not sufficient, and that other IP and transport layer fields need to be used too? i.e., are you only against adding the Pointers to binary filter rules? or you want to limit the fields used further? >> >> I think that in the extreme, one could go further and say that packet >> routing should really be ONLY based on IP Addresses. > > not really, the flow label is explcitly there to provide special treatmen= t > to flows. Same with the traffci class bits. It is perfectly ok to use tho= se > a part of the routing decisions imho GT> classification is different from routing. Do you know many routers (beyond lab experiments on QoS routing) that use Flow Labels or even DSCPs for routing? In any case I was making an "extreme" argument. Of course I think it is ok to use flow labels for routing .... but I think it needs to be combined with other fields too. >> >> =C2=A0Anything else is >> mostly broken since it can never scale and it is not compatible with >> regular IP routing. I am actually sympathetic to this view of the >> world in which it requires that the MN uses a different source address >> for every "flow" it wants to be able to route separately. Then flow >> bindings are simply implemented by redirecting the various MN >> addresses used to the different CoAs of the MN. >> >> The flow label, however, is IMO mostly an inadequate field to use for >> flow bindings. This is because a given MN has no control over when and >> how a given CN uses the flow label.Flow Bindings allow the MN to >> =C2=A0affect the 'last hop routing' of packets going from the HA to itse= lf. >> It makes no sense to me for the MN to have to rely on the use of what >> is basically an optional field by random 3rd party nodes. >> >> > > I think we are focusing in different ways of splitting the problem. > IMHO, the IP layer does not know what an application flow is. It doens't > knwo how the application set different bits and what it is more it doesn'= t > have to know. > The flow label is a handle for the IP layer to know what a flow is. Makin= g > the IP layer second guess what a flow is, is not the best idea. > So, while you see the division MN/CN, i am concerned in the divsion IP > layer/app layer > GT> I agree. All this, however, is supposed to become known to the MIP layer via an API...no one expects the MIP engine itself to figure these things out. >> In contrast, the flexibility provided by the binary flow description >> as you know is mostly about IP layer and Transport Layer fields, which >> I think are the minimum required to provide effecting flow binding >> capabilities. The recent addition of the Pointer idea simply expanded >> the capabilities to random upper layer field matching, I believe very >> elegantly and powerfully, if you do not mind me saying so ;-) >> > > well, i do mind. > GT> OK, shameless self-promotion did not pan-out :-) > as defined in the draft > > =C2=A0Offset > > =C2=A0 =C2=A0 The Offset field identifies an integer number of bytes from= the > =C2=A0 =C2=A0 beginning of the IP header. =C2=A0It points to the beginnin= g of the > =C2=A0 =C2=A0 field of interest in the packet. > > So, suppose that the idea is to use application layer bits. > Now what happens if the IP layer adds an extension header or an option > inside a header? GT> It is a matter of identifying the start of the offset at an appropriate place e.g., at the end of IP header and all options. > What happens if the TCP inserts one option? GT> OK, maybe the offset should start at the end of the transport layer header :-) Joking aside, this is trivial; I remind you that these offset-based pointers have been used in packet classifiers in the field for many years....not really my idea. The only case it does not work is when e2e security is used (e.g. IPSEC), in which case of course only IP layer fields can be used for classification. > What happens with applications that we don't know the format (such as > skype)? GT> But that's the whole point of the Pointers. You do not have to know! It is the Skype app that would have to use the API to set-up an appropriate Pointer. > > >> Still, I think it is valid to question whether such higher layer >> matching capability is a good thing architecturally. As of yet, >> however, I am not sure I see what the issue is with providing such >> capability, beyond a somewhat academic issue of regular IP routing >> compatibility. >> >> > > well, here i guess we disagree. including application data bit pattern in > mip signalling doesn't seem the best architecture to me. Layer violation > seems at least one issue here > GT> As I said, I think you are making a valid argument for discussion. I would in fact be willing to consider dropping the Pointers from the binary flow description draft as long as "flexibility" is not used as an argument when comparing it to text based flow description; remember this was the main reason the Pointers where added to the draft in the first place. George > Regards, marcelo > > >> As a side note, I have no problem whatsoever requiring that HAs >> perform deep packet inspection as the binary flow description draft >> requires. Commercial HAs are able to perform packet filter inspection, >> and are actually expected to do so, for other needs already >> (firewalling, lawful interception, value-add bells and whistles etc) >> so I do not see any issue there. Note that the use of Pointers for >> such deep header inspection is trivial compared to other methods since >> it does not require that the HA understands the upper layer header >> formats. It simply moves to byte X and matches Y number of bytes. On >> the MN side things are different and as I explained the complexity on >> the MN side is implementation specific. >> >> George >> >> >> On Sun, May 17, 2009 at 11:34 AM, marcelo bagnulo braun >> wrote: >> >>> >>> George Tsirtsis escribi=C3=B3: >>> >>>> >>>> Marcelo, >>>> >>>> Flow Movement is supposed to work in combination with DSMIPv6. Are you >>>> suggesting the flow bindings should only work for IPv6 traffic then? >>>> >>>> >>> >>> no, i ma suggesting that for IPv6 traffic, we should use the flow label >>> for ipv4, we certainly need to use something else >>> What i am not buying is that we cannot build a method that relies in th= e >>> flow label cause IPv4 doesn't support it. In other words, i think it is >>> perfeclty ok to build our reccomended method relying on the usage of th= e >>> flow label, and define some other hacks to support ipv4. >>> >>>> >>>> why would we place such a restriction? >>>> >>>> BTW, as far as I know flow label is the least well defined aspect of >>>> IPv6. >>>> >>> >>> but that is not the porblem of IPv6, but it is an inherent problem of >>> defining a flow. The IP layer has a problem cause it is agonstic to >>> flows. >>> So, only the application knows what really a flow is. And IPv6 does >>> provide >>> the means for the application to signal the packets that belong to flow >>> to >>> the IP layer i.e. the flow label. >>> In other words, this is a fundamental problem: IP does not knows about >>> flows >>> and we are trying that MIP which is in the IP layer to discriminate >>> flows. >>> We can either try the IP layer to guess what are the common bits of a >>> flow >>> or we can leverage on the explicit definition of a flow, which is what >>> the >>> flow label is for. >>> >>>> >>>> =C2=A0How does the MN know whether a given CN marks each relevant flow >>>> with a different flow label? >>>> >>> >>> becuase it needs to be compliant with RFC3697? >>> >>>> >>>> Also note that flow labels are source >>>> address specific so the flow label by itself is not sufficient. >>>> >>>> >>>> >>> >>> sure, the flow description is src add, dst add and flow label >>> >>> >>>> >>>> Also the binary format >>>> (http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00) in >>>> fact allows for a very simple MN implementation if the only thing you >>>> want to classify is flow labels. An implementation could only allow >>>> the flow label to be set resulting in the following flow descriptor: >>>> >>>> =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 >>>> =C2=A0 =C2=A0 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 >>>> =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ >>>> =C2=A0 =C2=A0|0|0|0|0|0|0|0|0|0|0|0|0|M| 0000 | =C2=A0 =C2=A0 =C2=A0 (= M) =C2=A0 Flow Label >>>> =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+ >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0FB (cont) =C2=A0 =C2=A0 | >>>> =C2=A0 =C2=A0+-+-+-+-+-+-+-+ >>>> >>>> Or actually something like the above but including the source address >>>> too (flag C), do me more correct.. >>>> >>>> If an MN implementation does not want to deal with any of the other >>>> fields, it does not need to implement them. >>>> In that sense multiple compatible implementations are allowed as long >>>> as the HA implements the flow descriptors in their full complexity. >>>> >>>> >>>> >>> >>> this is my problem. I don't want to impose the HAs to be able to parse >>> arbitrary bits in the application data. I think this is not the right w= ay >>> to >>> do it. I don't think the IP layer should be snooping into application >>> data >>> bits >>> >>> >>>> >>>> Finally note that what constitutes a "flow" could be something like >>>> "ALL TCP Traffic", no matter which source address and what flow label >>>> is used. How would the MN be able to say push all TCP to one CoA and >>>> all UDP to another based on your scheme? >>>> >>>> >>> >>> well, you can do this based on the protocol field of the IP header >>> As i stated in my earlier reply to Hesham, i don't have a problem with >>> using >>> any IP header fields as flow descriptors and i may be ok with sing the >>> transport header bits (not what i would preffer, but hey, you can't >>> always >>> get what you want) >>> My problem is with supporting application data bits as part of the flow >>> description, which i really think is broken >>> >>> Makes sense? >>> >>> Regards, marcelo >>> >>> >>> >>>> >>>> George >>>> >>>> >>>> On Sun, May 17, 2009 at 10:03 AM, marcelo bagnulo braun >>>> wrote: >>>> >>>> >>>>> >>>>> George Tsirtsis escribi=C3=B3: >>>>> >>>>> >>>>>> >>>>>> Hi Marcelo, I now understand what you propose better. and it makes >>>>>> more >>>>>> sense than I initially thought. >>>>>> >>>>>> Two issues, though: >>>>>> >>>>>> 1) this requires the CN to cooperate i.e., make proper use of flow >>>>>> labels. >>>>>> >>>>>> >>>>> >>>>> according to RFC3697: >>>>> >>>>> =C2=A0To enable Flow Label based classification, source nodes SHOULD = assign >>>>> =C2=A0each unrelated transport connection and application data stream= to a >>>>> =C2=A0new flow. >>>>> ... >>>>> >>>>> =C2=A0To enable applications and transport protocols to define what p= ackets >>>>> =C2=A0constitute a flow, the source node MUST provide means for the >>>>> =C2=A0applications and transport protocols to specify the Flow Label = values >>>>> =C2=A0to be used with their flows. =C2=A0The use of the means to spec= ify Flow >>>>> =C2=A0Label values is subject to appropriate privileges (see section = 5.1). >>>>> =C2=A0The source node SHOULD be able to select unused Flow Label valu= es for >>>>> =C2=A0flows not requesting a specific value to be used. >>>>> >>>>> So, yes but node should do this if they expect things to work properl= y >>>>> >>>>> >>>>> >>>>>> >>>>>> It is not clear to me that even if all nodes populated the flow labe= l >>>>>> (which I think is not even true) >>>>>> >>>>>> >>>>> >>>>> does anybody has information about the support of RFC3697 in current >>>>> OSes? >>>>> >>>>> >>>>> >>>>>> >>>>>> , its use would be universally consistent in a way that would ensure >>>>>> that the setting of the flow label by the CN would be inline with wh= at >>>>>> the >>>>>> MN would like to identify as a flow. >>>>>> >>>>>> >>>>> >>>>> that would determine the granularity of the method >>>>> I am not sure the spectrum of choices is so big that this can be a >>>>> problem >>>>> could you think of some very different criteria to define what a flow >>>>> is >>>>> that this would be an issue? >>>>> >>>>> >>>>>> >>>>>> 2) This does not work for IPv4 traffic. >>>>>> >>>>>> >>>>>> >>>>> >>>>> i don't buy this argument. If we apply this argument, then we could >>>>> never >>>>> use the flow label for anything, since it doesn't work for IPv4. >>>>> >>>>> Reagrds, marcelo >>>>> >>>>> >>>>> >>>>>> >>>>>> Thoughts? >>>>>> George >>>>>> On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun >>>>>> > wrote: >>>>>> >>>>>> =C2=A0ok, let me try again because it seems i am failing miserably t= o >>>>>> =C2=A0communicate what i want to say (or it simply so broken that pe= ople >>>>>> =C2=A0cannot believe what they are reading :-) >>>>>> >>>>>> =C2=A0Let's try with an example. >>>>>> >>>>>> =C2=A0We have the MN who has two CoAs, CoA1 and CoA2. >>>>>> >>>>>> =C2=A0The MN has a policy that says that it wants flows from app1 to= be >>>>>> =C2=A0exchanged through CoA1 (well, the policy would say that they >>>>>> =C2=A0should be received by the interfece in which CoA1 is configure= d) >>>>>> =C2=A0and that flows from app2 to be exchanged through CoA2 (same >>>>>> =C2=A0comment about the interface applies here) >>>>>> >>>>>> =C2=A0In addition, MN has defined CoA1 to be the primary CoA i.e. th= e >>>>>> =C2=A0CoA with highest priority. >>>>>> >>>>>> =C2=A0So, we have two different situations. Either the MN starts the >>>>>> =C2=A0communication or the CN starts the communication. Actually, th= is >>>>>> =C2=A0is pretty irrelevant, cause the two directions of a connection= s >>>>>> =C2=A0are handled independently. the MN will send packets from app1 >>>>>> =C2=A0through CoA1 and packets from app2 through CoA2 and it doesn't >>>>>> =C2=A0need any additional actions from the HA for outgoing packets. >>>>>> >>>>>> =C2=A0Now, the difficulty is with incoming packets. the MN needs to >>>>>> =C2=A0inform the HA about which CoA it wants to use to receive any f= low. >>>>>> >>>>>> =C2=A0Suppose that the HA has no flow bindings for the MN so far. >>>>>> >>>>>> =C2=A0So, suppose that the app1 in CN starts a flow to the MN. The H= A >>>>>> =C2=A0will receive the packet and will send it though the CoA1 cause= it >>>>>> =C2=A0is the one with higher priority. the MN is happy and there is = no >>>>>> =C2=A0need to do anything else. >>>>>> >>>>>> =C2=A0Suppose now that the app2 in the CN starts a flow to the MN. >>>>>> =C2=A0According to RFC3697, the CN SHOULD assign a different flow la= bel >>>>>> =C2=A0to the packets belonging to this flow e.g. to this TCP connect= ion. >>>>>> =C2=A0Let's assume it is actually a TCP connection to make the examp= le >>>>>> =C2=A0more concrete. >>>>>> =C2=A0So, app2 opens a TCP connection to MN. CN then sends the TCP S= YN >>>>>> =C2=A0to the MN. >>>>>> =C2=A0The HA receives the TCP SYN and since there is no flow binding >>>>>> =C2=A0state for this flow it forwards it through the CoA1 (the one w= ith >>>>>> =C2=A0highest priority) >>>>>> =C2=A0The MN receives the TCP SYN through CoA1 and it realizes that = this >>>>>> =C2=A0is not compliant with its flow policy. So, it extracts the flo= w >>>>>> =C2=A0label value, the src address and the dest address and it sends= a >>>>>> =C2=A0BU to the HA stating that the flow identified by the flow labe= l, >>>>>> =C2=A0src add and dest add needs to be bound to the CoA2. >>>>>> =C2=A0Simultaneously, it also sends the TCP SYN+ACK back to the CN. >>>>>> =C2=A0The CN receives the TCP SYN+ACK and sends the Ack back. the HA >>>>>> =C2=A0receives the ACk and will forward it based on the flow binding= , >>>>>> =C2=A0i.e. through the CoA. >>>>>> >>>>>> =C2=A0the result is a method that never looks into higher layer >>>>>> =C2=A0information for setting the flows. >>>>>> >>>>>> =C2=A0makes sense? >>>>>> >>>>>> =C2=A0Regards, marcelo >>>>>> >>>>>> >>>>>> =C2=A0Hesham Soliman escribi=C3=B3: >>>>>> >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0On 17/05/09 3:04 PM, "marcelo bagnulo braun" >>>>>> =C2=A0 =C2=A0 =C2=A0>= wrote: >>>>>> >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hesham Soliman escribi=C3=B3: >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The flow label shoul= d be part of any filter descriptor >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anyway. So at anytim= e >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A MN can send a BU s= pecifying that packets with flow >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0label X should be >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0directed to CoA1. I'= m not sure how your proposal >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0changes/adds to this= . >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0what i am saying is that you don't= need anything else >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other than this >>>>>> >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0=3D> see below >>>>>> >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As a general issue, = the flow label is unlikely to be >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0used for this purpos= e >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until we resolve it'= s mutability issues >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0what mutability issues are you ref= erring to? >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AFAIU, the flow label is set rando= mly b the source and >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0remains unchanged >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e2e and for the duration of the fl= ow. >>>>>> >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0=3D> I thought RFC 3697 talked about it being ch= anged en route >>>>>> =C2=A0 =C2=A0 =C2=A0then changed >>>>>> =C2=A0 =C2=A0 =C2=A0back before it hits the destination. But I just = scanned it and >>>>>> =C2=A0 =C2=A0 =C2=A0I can't find >>>>>> =C2=A0 =C2=A0 =C2=A0this text. Maybe it was never included. >>>>>> >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and until it is act= ually _used_ in >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the API. At least un= til recently no one was using it. >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0why do we need to have it in the A= PI? It is only imporntat >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the the >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0source sets it to a random value a= nd keep it unchenged e2e >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and for the >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0duration of the flow. I understand= that these conditions >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are met today, >>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0right? >>>>>> >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0=3D> But are you saying the src MIP6 module over= writes the >>>>>> =C2=A0 =C2=A0 =C2=A0potential flow >>>>>> =C2=A0 =C2=A0 =C2=A0label set in the API? Because it is possible tha= t an app sets >>>>>> =C2=A0 =C2=A0 =C2=A0the flow >>>>>> =C2=A0 =C2=A0 =C2=A0label. RFC 3697 assumes the presence of an e2e m= echanism to >>>>>> =C2=A0 =C2=A0 =C2=A0negotiate the >>>>>> =C2=A0 =C2=A0 =C2=A0flow label. If not then how do you make sure it'= s always >>>>>> =C2=A0 =C2=A0 =C2=A0unique? And how do >>>>>> =C2=A0 =C2=A0 =C2=A0you make sure that the CN echoes back the same v= alue in the >>>>>> =C2=A0 =C2=A0 =C2=A0flow label? >>>>>> =C2=A0 =C2=A0 =C2=A0And what if the CN initiated the connection? >>>>>> >>>>>> =C2=A0 =C2=A0 =C2=A0Hesham >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =C2=A0_______________________________________________ >>>>>> =C2=A0MEXT mailing list >>>>>> =C2=A0MEXT@ietf.org >>>>>> =C2=A0https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >>> >> >> > > From ryuji.wakikawa@gmail.com Mon May 18 10:13: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 D497E3A6E4A for ; Mon, 18 May 2009 10:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u7C8YMIdm9C for ; Mon, 18 May 2009 10:13:29 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id E69503A6DB6 for ; Mon, 18 May 2009 10:13:28 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1434053rvb.49 for ; Mon, 18 May 2009 10:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=Y0kJn0aFs+OTlN2cOOR0un63AOv7vWHiDVZ36Olqmzk=; b=N3DMtK7J+/2BDNiuh1TQZ3w4mnryHZulLZl4bZ4QU+tVTwgX2OjnyzMsPLp8vTSB/c J7aUg8BnuddqFqL/IJklSMIEAzcMqiDQT0GUQAhoRVo1b3UB9TFL087d8MTDnvgNLwES PirxfflT11w5m4JUNeDsC/B3TxaCG1LFL0XBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=kG2Pt2YTVPPo7JCe3EDxc4IUv4rBbqCQ6pR1z8LZniV3xT3caLYtgXglw+1Y0fjjTk RBb0SD5WmS0p29592NLKVX7UUKe/7JUQq8k0t/IaG7NJsFeasNv/XEpSlkJowA6tlf7P JYThHU0L9NU0szxtEZf13nHPJt/F7jPKSWOwA= Received: by 10.141.168.16 with SMTP id v16mr2396200rvo.233.1242666903270; Mon, 18 May 2009 10:15:03 -0700 (PDT) Received: from ?192.168.110.115? ([206.132.173.18]) by mx.google.com with ESMTPS id f42sm13788739rvb.31.2009.05.18.10.15.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 10:15:01 -0700 (PDT) From: Ryuji Wakikawa To: Romain KUNTZ In-Reply-To: References: <14008519-2F77-45BC-B9F4-AA449A1627B5@lsiit.u-strasbg.fr> <20149D5A-EAFA-459B-A76E-5190856FD4B6@gmail.com> Message-Id: <8E4F20F0-4D14-4B27-A615-1E067A2A0809@gmail.com> 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, 18 May 2009 10:14:58 -0700 X-Mailer: Apple Mail (2.935.3) Cc: mext Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13 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, 18 May 2009 17:13:35 -0000 Hi Romain, On 2009/05/12, at 14:08, Romain KUNTZ wrote: > Hi Ryuji, > > On 2009/05/11, at 22:59, Ryuji Wakikawa wrote: >>> First, I'd like to express that I support Arnaud's opinion about >>> section 5.6 (Simultaneous Home and Visited Link Operation). I also >>> don't see what is the motivation to re-route and tunnel traffic >>> from the HA to one of the MN's CoA, while the MN is only one hop >>> from the HA. Even if there is a specific use-case, at the time >>> this topology was suggested, a simple solution that came out was >>> to configure a CoA on the Home link and use a tunnel via the home >>> link. I don't think the little overhead of this solution justifies >>> the complexity of the one proposed in the draft. >> >> This was discussed at WG. We agreed to have this feature at the end. >> I understand the complexity, but this is how WG agreed. >> >> It is not possible to change the consensus at this moment. We >> passed all last call. > > Ok, this has also been extensively discussed in another thread - > I'll follow the WG agreement then. > >>> Two other minor comments on the draft below: >>> >>> - Section 6.2 (Processing Binding Update) >>> >>> * If the 'O' flag is set in the Binding Update, the home agent >>> removes all the existing bindings and registers the received >>> binding(s). >>> >>> It is not explicitly said that the MN can use the O flag with a >>> CN. I think nothing prevents the MN to use it, so we should >>> replace "home agent" with "receiving node". > > You didn't ack the above comment, did you skip it by mistake? I've already replaced it :-) thanks! ryuji > > > >>> If all the above operations are successfully completed, a Binding >>> Acknowledgement containing the Binding Identifier mobility options >>> MUST be sent to the mobile node. >>> >>> The BAck must be sent only if the 'A' flag was set in the BU, >>> right? or does the MCoA spec mandates sending BAck in all cases? >> >> BA is sent only A flag is set. >> I will update this to >> >>> If all the above operations are successfully completed, a Binding >>> Acknowledgement containing the Binding Identifier mobility options >>> MUST be sent to the mobile node if 'A' flag is set in the >>> received Binding Update. >> >> Please let me know if you have further comments on this. > > Looks fine with me! > > Thanks, > romain > From marcelo@it.uc3m.es Mon May 18 12:03: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 D294028C30A for ; Mon, 18 May 2009 12:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.567 X-Spam-Level: X-Spam-Status: No, score=-4.567 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, FRT_LOLITA1=1.865, J_CHICKENPOX_33=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 jODirGXt7XYs for ; Mon, 18 May 2009 12:03:09 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 3D4CE3A6DB6 for ; Mon, 18 May 2009 12:01:19 -0700 (PDT) Received: from r190-135-76-193.dialup.adsl.anteldata.net.uy (r190-135-76-193.dialup.adsl.anteldata.net.uy [190.135.76.193]) by smtp03.uc3m.es (Postfix) with ESMTP id 19BEA731003; Mon, 18 May 2009 21:02:45 +0200 (CEST) Message-ID: <4A11B0D1.2060301@it.uc3m.es> Date: Mon, 18 May 2009 21:02:41 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Tsirtsis References: <4A118F06.1040905@it.uc3m.es> 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-16650.001 Cc: mext Subject: Re: [MEXT] about the nature of "flows" Re: weird idea about 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, 18 May 2009 19:03:11 -0000 George Tsirtsis escribió: > inline... > > On Mon, May 18, 2009 at 12:38 PM, marcelo bagnulo braun > wrote: > >> George Tsirtsis escribió: >> >>> Marcelo, >>> >>> It might be useful to step back a bit to understand better what the issue >>> is. >>> >>> I think one issue in this discussion is that the use of the term >>> "flow" in flow bindings in the flow bindings and flow description >>> drafts, is currently a bit wider than that used in flow labels. Flow >>> bindings, with any of the filter description formats discussed (text >>> or binary) should be more accurately described as "packet filter rule >>> binding". >>> >>> In other words, all our filter descriptions so far, have taken the >>> view that the MN should have as much flexibility in identifying >>> "flows" (or more accurately "filter rules") as a regular packet >>> classifier e.g., firewall. You seem to think this is a bad idea and >>> that only IP layer (and possibly transport layer?) fields should be >>> used in the context of flow bindings. >>> >>> Am I right so far? >>> >>> >> correct >> > > GT> Just to make sure we are on the same page, do you agree that flow > label is not sufficient, flow label is clearly not sufficient since at least the src and dst address are also needed but i am ok with using any IP layer information I am not so comfortable with transport information, but as is stated earlier, i guess i can live with that > and that other IP and transport layer fields > need to be used too? i.e., are you only against adding the Pointers to > binary filter rules? or you want to limit the fields used further? > > just the pointers >>> I think that in the extreme, one could go further and say that packet >>> routing should really be ONLY based on IP Addresses. >>> >> not really, the flow label is explcitly there to provide special treatment >> to flows. Same with the traffci class bits. It is perfectly ok to use those >> a part of the routing decisions imho >> > > GT> classification is different from routing. Do you know many routers > (beyond lab experiments on QoS routing) that use Flow Labels or even > DSCPs for routing? In any case I was making an "extreme" argument. Of > course I think it is ok to use flow labels for routing .... but I > think it needs to be combined with other fields too. > > >>> Anything else is >>> mostly broken since it can never scale and it is not compatible with >>> regular IP routing. I am actually sympathetic to this view of the >>> world in which it requires that the MN uses a different source address >>> for every "flow" it wants to be able to route separately. Then flow >>> bindings are simply implemented by redirecting the various MN >>> addresses used to the different CoAs of the MN. >>> >>> The flow label, however, is IMO mostly an inadequate field to use for >>> flow bindings. This is because a given MN has no control over when and >>> how a given CN uses the flow label.Flow Bindings allow the MN to >>> affect the 'last hop routing' of packets going from the HA to itself. >>> It makes no sense to me for the MN to have to rely on the use of what >>> is basically an optional field by random 3rd party nodes. >>> >>> >>> >> I think we are focusing in different ways of splitting the problem. >> IMHO, the IP layer does not know what an application flow is. It doens't >> knwo how the application set different bits and what it is more it doesn't >> have to know. >> The flow label is a handle for the IP layer to know what a flow is. Making >> the IP layer second guess what a flow is, is not the best idea. >> So, while you see the division MN/CN, i am concerned in the divsion IP >> layer/app layer >> >> > > GT> I agree. All this, however, is supposed to become known to the MIP > layer via an API...no one expects the MIP engine itself to figure > these things out. > > >>> In contrast, the flexibility provided by the binary flow description >>> as you know is mostly about IP layer and Transport Layer fields, which >>> I think are the minimum required to provide effecting flow binding >>> capabilities. The recent addition of the Pointer idea simply expanded >>> the capabilities to random upper layer field matching, I believe very >>> elegantly and powerfully, if you do not mind me saying so ;-) >>> >>> >> well, i do mind. >> >> > > GT> OK, shameless self-promotion did not pan-out :-) > > >> as defined in the draft >> >> Offset >> >> The Offset field identifies an integer number of bytes from the >> beginning of the IP header. It points to the beginning of the >> field of interest in the packet. >> >> So, suppose that the idea is to use application layer bits. >> Now what happens if the IP layer adds an extension header or an option >> inside a header? >> > > GT> It is a matter of identifying the start of the offset at an > appropriate place e.g., at the end of IP header and all options. > > >> What happens if the TCP inserts one option? >> > > GT> OK, maybe the offset should start at the end of the transport > layer header :-) > Joking aside, this is trivial; i don't know if i would call it trivial. I tcan certainly be done, (and it is done in DPI) but that doesn't make it easy or a good idea. Making the IP layer to understand the trasnport options and app data bit patterns still doesn't sound like a good idea to me > I remind you that these offset-based > pointers have been used in packet classifiers in the field for many > years....not really my idea. The only case it does not work is when > e2e security is used (e.g. IPSEC), in which case of course only IP > layer fields can be used for classification. > > >> What happens with applications that we don't know the format (such as >> skype)? >> > > GT> But that's the whole point of the Pointers. You do not have to > know! It is the Skype app that would have to use the API to set-up an > appropriate Pointer. > > mmm, i don't follow this. suppose i own a PDA and i want that the skype traffic is routed through my GPRS link. How do i configure my PDA to do so? Skype won't do it for me. So we have two options. Wait for skype to support the flow binding API or wait for te OS to properly set a random flow label. I really think the second is more reasonable. >> >>> Still, I think it is valid to question whether such higher layer >>> matching capability is a good thing architecturally. As of yet, >>> however, I am not sure I see what the issue is with providing such >>> capability, beyond a somewhat academic issue of regular IP routing >>> compatibility. >>> >>> >>> >> well, here i guess we disagree. including application data bit pattern in >> mip signalling doesn't seem the best architecture to me. Layer violation >> seems at least one issue here >> >> > > GT> As I said, I think you are making a valid argument for discussion. > I would in fact be willing to consider dropping the Pointers from the > binary flow description draft as long as "flexibility" is not used as > an argument when comparing it to text based flow description; remember > this was the main reason the Pointers where added to the draft in the > first place. > > mmm, i have even more issues with any other flow language descriptors that enter even more into the app land. Regards, marcelo > George > > >> Regards, marcelo >> >> >> >>> As a side note, I have no problem whatsoever requiring that HAs >>> perform deep packet inspection as the binary flow description draft >>> requires. Commercial HAs are able to perform packet filter inspection, >>> and are actually expected to do so, for other needs already >>> (firewalling, lawful interception, value-add bells and whistles etc) >>> so I do not see any issue there. Note that the use of Pointers for >>> such deep header inspection is trivial compared to other methods since >>> it does not require that the HA understands the upper layer header >>> formats. It simply moves to byte X and matches Y number of bytes. On >>> the MN side things are different and as I explained the complexity on >>> the MN side is implementation specific. >>> >>> George >>> >>> >>> On Sun, May 17, 2009 at 11:34 AM, marcelo bagnulo braun >>> wrote: >>> >>> >>>> George Tsirtsis escribió: >>>> >>>> >>>>> Marcelo, >>>>> >>>>> Flow Movement is supposed to work in combination with DSMIPv6. Are you >>>>> suggesting the flow bindings should only work for IPv6 traffic then? >>>>> >>>>> >>>>> >>>> no, i ma suggesting that for IPv6 traffic, we should use the flow label >>>> for ipv4, we certainly need to use something else >>>> What i am not buying is that we cannot build a method that relies in the >>>> flow label cause IPv4 doesn't support it. In other words, i think it is >>>> perfeclty ok to build our reccomended method relying on the usage of the >>>> flow label, and define some other hacks to support ipv4. >>>> >>>> >>>>> why would we place such a restriction? >>>>> >>>>> BTW, as far as I know flow label is the least well defined aspect of >>>>> IPv6. >>>>> >>>>> >>>> but that is not the porblem of IPv6, but it is an inherent problem of >>>> defining a flow. The IP layer has a problem cause it is agonstic to >>>> flows. >>>> So, only the application knows what really a flow is. And IPv6 does >>>> provide >>>> the means for the application to signal the packets that belong to flow >>>> to >>>> the IP layer i.e. the flow label. >>>> In other words, this is a fundamental problem: IP does not knows about >>>> flows >>>> and we are trying that MIP which is in the IP layer to discriminate >>>> flows. >>>> We can either try the IP layer to guess what are the common bits of a >>>> flow >>>> or we can leverage on the explicit definition of a flow, which is what >>>> the >>>> flow label is for. >>>> >>>> >>>>> How does the MN know whether a given CN marks each relevant flow >>>>> with a different flow label? >>>>> >>>>> >>>> becuase it needs to be compliant with RFC3697? >>>> >>>> >>>>> Also note that flow labels are source >>>>> address specific so the flow label by itself is not sufficient. >>>>> >>>>> >>>>> >>>>> >>>> sure, the flow description is src add, dst add and flow label >>>> >>>> >>>> >>>>> Also the binary format >>>>> (http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00) in >>>>> fact allows for a very simple MN implementation if the only thing you >>>>> want to classify is flow labels. An implementation could only allow >>>>> the flow label to be set resulting in the following flow descriptor: >>>>> >>>>> 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 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |0|0|0|0|0|0|0|0|0|0|0|0|M| 0000 | (M) Flow Label >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> FB (cont) | >>>>> +-+-+-+-+-+-+-+ >>>>> >>>>> Or actually something like the above but including the source address >>>>> too (flag C), do me more correct.. >>>>> >>>>> If an MN implementation does not want to deal with any of the other >>>>> fields, it does not need to implement them. >>>>> In that sense multiple compatible implementations are allowed as long >>>>> as the HA implements the flow descriptors in their full complexity. >>>>> >>>>> >>>>> >>>>> >>>> this is my problem. I don't want to impose the HAs to be able to parse >>>> arbitrary bits in the application data. I think this is not the right way >>>> to >>>> do it. I don't think the IP layer should be snooping into application >>>> data >>>> bits >>>> >>>> >>>> >>>>> Finally note that what constitutes a "flow" could be something like >>>>> "ALL TCP Traffic", no matter which source address and what flow label >>>>> is used. How would the MN be able to say push all TCP to one CoA and >>>>> all UDP to another based on your scheme? >>>>> >>>>> >>>>> >>>> well, you can do this based on the protocol field of the IP header >>>> As i stated in my earlier reply to Hesham, i don't have a problem with >>>> using >>>> any IP header fields as flow descriptors and i may be ok with sing the >>>> transport header bits (not what i would preffer, but hey, you can't >>>> always >>>> get what you want) >>>> My problem is with supporting application data bits as part of the flow >>>> description, which i really think is broken >>>> >>>> Makes sense? >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> >>>>> George >>>>> >>>>> >>>>> On Sun, May 17, 2009 at 10:03 AM, marcelo bagnulo braun >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> George Tsirtsis escribió: >>>>>> >>>>>> >>>>>> >>>>>>> Hi Marcelo, I now understand what you propose better. and it makes >>>>>>> more >>>>>>> sense than I initially thought. >>>>>>> >>>>>>> Two issues, though: >>>>>>> >>>>>>> 1) this requires the CN to cooperate i.e., make proper use of flow >>>>>>> labels. >>>>>>> >>>>>>> >>>>>>> >>>>>> according to RFC3697: >>>>>> >>>>>> To enable Flow Label based classification, source nodes SHOULD assign >>>>>> each unrelated transport connection and application data stream to a >>>>>> new flow. >>>>>> ... >>>>>> >>>>>> To enable applications and transport protocols to define what packets >>>>>> constitute a flow, the source node MUST provide means for the >>>>>> applications and transport protocols to specify the Flow Label values >>>>>> to be used with their flows. The use of the means to specify Flow >>>>>> Label values is subject to appropriate privileges (see section 5.1). >>>>>> The source node SHOULD be able to select unused Flow Label values for >>>>>> flows not requesting a specific value to be used. >>>>>> >>>>>> So, yes but node should do this if they expect things to work properly >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> It is not clear to me that even if all nodes populated the flow label >>>>>>> (which I think is not even true) >>>>>>> >>>>>>> >>>>>>> >>>>>> does anybody has information about the support of RFC3697 in current >>>>>> OSes? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> , its use would be universally consistent in a way that would ensure >>>>>>> that the setting of the flow label by the CN would be inline with what >>>>>>> the >>>>>>> MN would like to identify as a flow. >>>>>>> >>>>>>> >>>>>>> >>>>>> that would determine the granularity of the method >>>>>> I am not sure the spectrum of choices is so big that this can be a >>>>>> problem >>>>>> could you think of some very different criteria to define what a flow >>>>>> is >>>>>> that this would be an issue? >>>>>> >>>>>> >>>>>> >>>>>>> 2) This does not work for IPv4 traffic. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> i don't buy this argument. If we apply this argument, then we could >>>>>> never >>>>>> use the flow label for anything, since it doesn't work for IPv4. >>>>>> >>>>>> Reagrds, marcelo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Thoughts? >>>>>>> George >>>>>>> On Sun, May 17, 2009 at 8:58 AM, marcelo bagnulo braun >>>>>>> > wrote: >>>>>>> >>>>>>> ok, let me try again because it seems i am failing miserably to >>>>>>> communicate what i want to say (or it simply so broken that people >>>>>>> cannot believe what they are reading :-) >>>>>>> >>>>>>> Let's try with an example. >>>>>>> >>>>>>> We have the MN who has two CoAs, CoA1 and CoA2. >>>>>>> >>>>>>> The MN has a policy that says that it wants flows from app1 to be >>>>>>> exchanged through CoA1 (well, the policy would say that they >>>>>>> should be received by the interfece in which CoA1 is configured) >>>>>>> and that flows from app2 to be exchanged through CoA2 (same >>>>>>> comment about the interface applies here) >>>>>>> >>>>>>> In addition, MN has defined CoA1 to be the primary CoA i.e. the >>>>>>> CoA with highest priority. >>>>>>> >>>>>>> So, we have two different situations. Either the MN starts the >>>>>>> communication or the CN starts the communication. Actually, this >>>>>>> is pretty irrelevant, cause the two directions of a connections >>>>>>> are handled independently. the MN will send packets from app1 >>>>>>> through CoA1 and packets from app2 through CoA2 and it doesn't >>>>>>> need any additional actions from the HA for outgoing packets. >>>>>>> >>>>>>> Now, the difficulty is with incoming packets. the MN needs to >>>>>>> inform the HA about which CoA it wants to use to receive any flow. >>>>>>> >>>>>>> Suppose that the HA has no flow bindings for the MN so far. >>>>>>> >>>>>>> So, suppose that the app1 in CN starts a flow to the MN. The HA >>>>>>> will receive the packet and will send it though the CoA1 cause it >>>>>>> is the one with higher priority. the MN is happy and there is no >>>>>>> need to do anything else. >>>>>>> >>>>>>> Suppose now that the app2 in the CN starts a flow to the MN. >>>>>>> According to RFC3697, the CN SHOULD assign a different flow label >>>>>>> to the packets belonging to this flow e.g. to this TCP connection. >>>>>>> Let's assume it is actually a TCP connection to make the example >>>>>>> more concrete. >>>>>>> So, app2 opens a TCP connection to MN. CN then sends the TCP SYN >>>>>>> to the MN. >>>>>>> The HA receives the TCP SYN and since there is no flow binding >>>>>>> state for this flow it forwards it through the CoA1 (the one with >>>>>>> highest priority) >>>>>>> The MN receives the TCP SYN through CoA1 and it realizes that this >>>>>>> is not compliant with its flow policy. So, it extracts the flow >>>>>>> label value, the src address and the dest address and it sends a >>>>>>> BU to the HA stating that the flow identified by the flow label, >>>>>>> src add and dest add needs to be bound to the CoA2. >>>>>>> Simultaneously, it also sends the TCP SYN+ACK back to the CN. >>>>>>> The CN receives the TCP SYN+ACK and sends the Ack back. the HA >>>>>>> receives the ACk and will forward it based on the flow binding, >>>>>>> i.e. through the CoA. >>>>>>> >>>>>>> the result is a method that never looks into higher layer >>>>>>> information for setting the flows. >>>>>>> >>>>>>> makes sense? >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>> Hesham Soliman escribió: >>>>>>> >>>>>>> >>>>>>> On 17/05/09 3:04 PM, "marcelo bagnulo braun" >>>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> Hesham Soliman escribió: >>>>>>> >>>>>>> The flow label should be part of any filter descriptor >>>>>>> anyway. So at anytime >>>>>>> A MN can send a BU specifying that packets with flow >>>>>>> label X should be >>>>>>> directed to CoA1. I'm not sure how your proposal >>>>>>> changes/adds to this. >>>>>>> >>>>>>> what i am saying is that you don't need anything else >>>>>>> other than this >>>>>>> >>>>>>> >>>>>>> => see below >>>>>>> >>>>>>> >>>>>>> As a general issue, the flow label is unlikely to be >>>>>>> used for this purpose >>>>>>> until we resolve it's mutability issues >>>>>>> >>>>>>> what mutability issues are you referring to? >>>>>>> AFAIU, the flow label is set randomly b the source and >>>>>>> remains unchanged >>>>>>> e2e and for the duration of the flow. >>>>>>> >>>>>>> >>>>>>> => I thought RFC 3697 talked about it being changed en route >>>>>>> then changed >>>>>>> back before it hits the destination. But I just scanned it and >>>>>>> I can't find >>>>>>> this text. Maybe it was never included. >>>>>>> >>>>>>> >>>>>>> and until it is actually _used_ in >>>>>>> the API. At least until recently no one was using it. >>>>>>> >>>>>>> why do we need to have it in the API? It is only imporntat >>>>>>> the the >>>>>>> source sets it to a random value and keep it unchenged e2e >>>>>>> and for the >>>>>>> duration of the flow. I understand that these conditions >>>>>>> are met today, >>>>>>> right? >>>>>>> >>>>>>> >>>>>>> => But are you saying the src MIP6 module overwrites the >>>>>>> potential flow >>>>>>> label set in the API? Because it is possible that an app sets >>>>>>> the flow >>>>>>> label. RFC 3697 assumes the presence of an e2e mechanism to >>>>>>> negotiate the >>>>>>> flow label. If not then how do you make sure it's always >>>>>>> unique? And how do >>>>>>> you make sure that the CN echoes back the same value in the >>>>>>> flow label? >>>>>>> And what if the CN initiated the connection? >>>>>>> >>>>>>> Hesham >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> > > From hesham@elevatemobile.com Mon May 18 16:22: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 27E453A6928 for ; Mon, 18 May 2009 16:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 IKMl+2SRuz2u for ; Mon, 18 May 2009 16:22:31 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 64B283A691E for ; Mon, 18 May 2009 16:22:30 -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 1M6CBd-0000v6-MZ; Tue, 19 May 2009 09:24:01 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 19 May 2009 09:23:53 +1000 From: Hesham Soliman To: George Tsirtsis , marcelo bagnulo braun Message-ID: Thread-Topic: about the nature of "flows" Re: [MEXT] weird idea about flow bindings Thread-Index: AcnYD7UGdqJHt8eckESCGnQsZpwFZA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext Subject: Re: [MEXT] about the nature of "flows" Re: weird idea about 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, 18 May 2009 23:22:32 -0000 George, One comment here. >> >> correct > > GT> Just to make sure we are on the same page, do you agree that flow > label is not sufficient, and that other IP and transport layer fields > need to be used too? i.e., are you only against adding the Pointers to > binary filter rules? or you want to limit the fields used further? => The only reason IMO the flow label is not sufficient on its own for a spec right now is that it's not used. If it were used as specified then it would in fact replace upper layer information. That's what it is designed to do. Hesham From root@core3.amsl.com Mon May 18 16:30:02 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 4B0943A691E; Mon, 18 May 2009 16: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: <20090518233002.4B0943A691E@core3.amsl.com> Date: Mon, 18 May 2009 16:30:02 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D ACTION:draft-ietf-mext-firewall-admin-01.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: Mon, 18 May 2009 23: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 : Guidelines for firewall administrators regarding MIPv6 traffic Author(s) : S. Krishnan, N. Steinleitner, Q. Ying, G. Bajko Filename : draft-ietf-mext-firewall-admin-01.txt Pages : 12 Date : 2009-5-19 This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-firewall-admin-01.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-firewall-admin-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-5-18162630.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon May 18 16:30:02 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 53CE43A69A1; Mon, 18 May 2009 16: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: <20090518233002.53CE43A69A1@core3.amsl.com> Date: Mon, 18 May 2009 16:30:02 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D ACTION:draft-ietf-mext-firewall-vendor-01.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: Mon, 18 May 2009 23: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 : Guidelines for firewall vendors regarding MIPv6 traffic Author(s) : S. Krishnan, Y. Sheffer, N. Steinleitner, G. Bajko Filename : draft-ietf-mext-firewall-vendor-01.txt Pages : 9 Date : 2009-5-18 This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-firewall-vendor-01.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-firewall-vendor-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-5-18162859.I-D@ietf.org> --NextPart-- From suresh.krishnan@ericsson.com Tue May 19 15:38: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 A05DF3A6C21 for ; Tue, 19 May 2009 15:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 2V+wtbyUXpUa for ; Tue, 19 May 2009 15:38:00 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id E511C3A6868 for ; Tue, 19 May 2009 15:37:59 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n4JMnwip021825; Tue, 19 May 2009 17:49:59 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 17:38:43 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 17:38:42 -0500 Message-ID: <4A1334AD.5050109@ericsson.com> Date: Tue, 19 May 2009 18:37:33 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4A1009D8.4060703@it.uc3m.es> In-Reply-To: <4A1009D8.4060703@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2009 22:38:43.0015 (UTC) FILETIME=[9029A570:01C9D8D2] Cc: mext Subject: Re: [MEXT] weird idea about 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, 19 May 2009 22:38:00 -0000 Hi Marcelo, On 17/05/09 08:58 AM, marcelo bagnulo braun wrote: > ok, let me try again because it seems i am failing miserably to > communicate what i want to say (or it simply so broken that people > cannot believe what they are reading :-) I think it is a cool idea but it is very hard to realize in practice since it needs CNs to be changed. > Suppose now that the app2 in the CN starts a flow to the MN. According > to RFC3697, the CN SHOULD assign a different flow label to the packets > belonging to this flow e.g. to this TCP connection. This is the crux of the issue. Almost every implementation I have seen sets the flow label to zero. This falls under the category "A source node which does not assign traffic to flows MUST set the Flow Label to zero.". Add to this the fact that compliance to RFC3697 is completely optional (it is not even mentioned in RFC4294), and this task quickly becomes pretty improbable. Thanks Suresh From charles.perkins@earthlink.net Tue May 19 15:49: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 B5C333A6BD3 for ; Tue, 19 May 2009 15:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 eeMuHWKv14v0 for ; Tue, 19 May 2009 15:49:03 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id BD22E3A6BBE for ; Tue, 19 May 2009 15:49:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=pc95OT2l4O3RkUoXcnoag8GeeNmav2kcYyb5VwjU5U1JmshYWS0LgbzY8u/vWQwk; 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 [38.96.10.141] (helo=[192.168.1.100]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1M6Y8s-0000ZQ-QY; Tue, 19 May 2009 18:50:39 -0400 Message-ID: <4A1337B9.5070809@earthlink.net> Date: Tue, 19 May 2009 15:50:33 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Suresh Krishnan References: <4A1009D8.4060703@it.uc3m.es> <4A1334AD.5050109@ericsson.com> In-Reply-To: <4A1334AD.5050109@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f521464014efe3a11c2008f26bac79f6450350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.96.10.141 Cc: mext Subject: Re: [MEXT] weird idea about 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, 19 May 2009 22:49:04 -0000 Hello folks, I've been following some of this discussion from afar, please excuse if I am not up to speed... Suresh Krishnan wrote: > Hi Marcelo, > > On 17/05/09 08:58 AM, marcelo bagnulo braun wrote: >> ok, let me try again because it seems i am failing miserably to >> communicate what i want to say (or it simply so broken that people >> cannot believe what they are reading :-) > > I think it is a cool idea but it is very hard to realize in practice > since it needs CNs to be changed. Right. This seems very much the point. If we are going to enable the use of flow labels, CNs need to be changed. The application that wants to have flows will have to run on the mobile and on the CN. But this seems perfectly fine, even desirable, to me. Am I missing something? For an application that wants to make a flow happen that doesn't use the flow label, is it somehow imagined that the application will not have to run on the CN? > >> Suppose now that the app2 in the CN starts a flow to the MN. >> According to RFC3697, the CN SHOULD assign a different flow label to >> the packets belonging to this flow e.g. to this TCP connection. > > This is the crux of the issue. Almost every implementation I have seen > sets the flow label to zero. This falls under the category "A source > node which does not assign traffic to flows MUST set the Flow Label to > zero.". Add to this the fact that compliance to RFC3697 is completely > optional (it is not even mentioned in RFC4294), and this task quickly > becomes pretty improbable. Implementation of what? Implementation of Mobile IP? Implementation of IPv6? I guess the application would have to use something to indicate that the flow label should NOT be zero. I still am not really seeing what's wrong with that. In brief, since applications today do not use the flow label, I don't see what's wrong with the flow label being zero. When applications are built that need to use the flow label, they'll have to have operating systems support to do it. Thanks for any light you can shed on this. Regards, Charlie P. From marcelo@it.uc3m.es Tue May 19 17:35: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 89C1C3A6951 for ; Tue, 19 May 2009 17:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.47 X-Spam-Level: X-Spam-Status: No, score=-5.47 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 EHsH9M51ACef for ; Tue, 19 May 2009 17:35:08 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id AA1753A6868 for ; Tue, 19 May 2009 17:35:08 -0700 (PDT) Received: from r190-135-31-182.dialup.adsl.anteldata.net.uy (r190-135-31-182.dialup.adsl.anteldata.net.uy [190.135.31.182]) by smtp02.uc3m.es (Postfix) with ESMTP id F371B6C25CB; Wed, 20 May 2009 02:36:37 +0200 (CEST) Message-ID: <4A13508E.4010500@it.uc3m.es> Date: Wed, 20 May 2009 02:36:30 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Suresh Krishnan References: <4A1009D8.4060703@it.uc3m.es> <4A1334AD.5050109@ericsson.com> In-Reply-To: <4A1334AD.5050109@ericsson.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-16652.003 Cc: mext Subject: Re: [MEXT] weird idea about 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, 20 May 2009 00:35:09 -0000 Suresh Krishnan escribió: > Hi Marcelo, > > On 17/05/09 08:58 AM, marcelo bagnulo braun wrote: >> ok, let me try again because it seems i am failing miserably to >> communicate what i want to say (or it simply so broken that people >> cannot believe what they are reading :-) > > I think it is a cool idea but it is very hard to realize in practice > since it needs CNs to be changed. > >> Suppose now that the app2 in the CN starts a flow to the MN. >> According to RFC3697, the CN SHOULD assign a different flow label to >> the packets belonging to this flow e.g. to this TCP connection. > > This is the crux of the issue. Almost every implementation I have seen > sets the flow label to zero. This falls under the category "A source > node which does not assign traffic to flows MUST set the Flow Label to > zero.". Add to this the fact that compliance to RFC3697 is completely > optional (it is not even mentioned in RFC4294), and this task quickly > becomes pretty improbable. right i am slowly understanding this is the case I think we should update rfc3697 to obtain a better use of the flow label, but i agree that its usage for flow bindings can not be immediate (i.e. with current implementations) Regards, marcelo > > Thanks > Suresh > > From wassim.haddad@ericsson.com Tue May 19 20:41: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 5A1B73A692A for ; Tue, 19 May 2009 20:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.107 X-Spam-Level: X-Spam-Status: No, score=-5.107 tagged_above=-999 required=5 tests=[AWL=1.492, 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 7uV+avXZAjI2 for ; Tue, 19 May 2009 20:41:37 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 60F743A657C for ; Tue, 19 May 2009 20:41:37 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n4K3rpxU002073; Tue, 19 May 2009 22:53:51 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 22:42:37 -0500 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, 19 May 2009 22:42:36 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF04C40E96@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] weird idea about flow bindings Thread-Index: AcnY1Eb5a3899HHgQOW0gl4E4JPWLAAJ7udY References: <4A1009D8.4060703@it.uc3m.es> <4A1334AD.5050109@ericsson.com> <4A1337B9.5070809@earthlink.net> From: "Wassim Haddad" To: "Charles E. Perkins" , "Suresh Krishnan" X-OriginalArrivalTime: 20 May 2009 03:42:37.0258 (UTC) FILETIME=[049E52A0:01C9D8FD] Cc: Wassim Haddad , mext Subject: Re: [MEXT] weird idea about 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, 20 May 2009 03:41:44 -0000 Hi, > On 17/05/09 08:58 AM, marcelo bagnulo braun wrote: >> ok, let me try again because it seems i am failing miserably to=20 >> communicate what i want to say (or it simply so broken that people=20 >> cannot believe what they are reading :-) > > I think it is a cool idea but it is very hard to realize in practice=20 > since it needs CNs to be changed. Right. This seems very much the point. If we are going to enable the = use of flow labels, CNs need to be changed. The application that wants to have flows will have to run on the mobile and on the CN. But this seems perfectly fine, even desirable, to me. =20 =3D> Me too. Regards, Wassim H. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From AMUHANNA@nortel.com Tue May 19 23:00: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 516DE3A6A59 for ; Tue, 19 May 2009 23:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 79XaLtSEmWhu for ; Tue, 19 May 2009 23:00:35 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 4ACFB3A6893 for ; Tue, 19 May 2009 23:00:35 -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 n4K613Q11150; Wed, 20 May 2009 06:01:03 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: Wed, 20 May 2009 01:01:56 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Binding Revocation almost ready for IESG Thread-Index: AcnO9sVR9cTLMTwdQ1GgPu1FD+lnTAAEbwpwAnKQ7sQADhwpEA== References: From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: Julien Laganier , mext Subject: Re: [MEXT] 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, 20 May 2009 06:00:36 -0000 Hi Vijay, Please see inline. Regards, Ahmad > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 > Sent: Tuesday, May 19, 2009 5:40 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext; Julien Laganier > Subject: Re: Binding Revocation almost ready for IESG >=20 > Hi Ahmad, >=20 > I have a couple of comments on version 10 >=20 > You explained to me that 3GPP2 wants to differentiate between=20 > the two following triggers. >=20 > 3 Inter-MAG Handover - same Access Type > 4 Inter-MAG Handover - different Access Type > =20 > That's fine.=20 [Ahmad] Thanks for agreeing on adding these two back! :) > But what should the MAG behavior be when it=20 > receives the following trigger? >=20 > 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". > Instead, I suggest going with just two values >=20 > 3 Inter-MAG Handover > 4 Inter-MAG Handover - different access types >=20 > '3' implicitly means it is the same access type. PMIPv6 after=20 > all is supposed to be used for local mobility. :) > [Ahmad] :) No need to restate the definition of PMIP domain.=20 I thought that you are the one who championed drafting that text:) =20 > On authorization for bulk revocation, we need some text that=20 > explains how the LMA is supposed to check if a particular MAG=20 > is authorized to perform bulk revocation. Is this list of=20 > "MAGS-authorized-for-bulk-revocation" > manually created on the LMA? If not, how is this populated? >=20 > (FWIW, I still think this authorization check should be=20 > removed from the draft). [Ahmad] I think we keep coming back to this point:) It is based on the home domain policy.=20 1. Some home domain probably wont allow this across different domain period. Example: only between MAG(s) and LMA(s) that belong to the same operator. 2. It could be as simple as all MAGs which IDs matches a simple string of "wildcard@xyz.com" 3. It could be as simple as "every MAG which is able to establish an IPsec SA for protecting PMIP signaling is authorized for Global revocation; I guess this matches your views to some extent. 4. etc. Leaving the details out of scope gives the flexibility for the home domain to enforce its own policy freely. I hope this address your concern. Cheers!=20 >=20 > Vijay >=20 >=20 From arno@natisbad.org Wed May 20 04:17: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 3ADC93A711E for ; Wed, 20 May 2009 04:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 kGn3bKj12c-5 for ; Wed, 20 May 2009 04:17:39 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 0FE3B3A7122 for ; Wed, 20 May 2009 04:17:39 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M6jpF-0005fS-M8; Wed, 20 May 2009 13:19:09 +0200 X-Hashcash: 1:20:090520:mext@ietf.org::8YnXcJZw7C1w8irj:00007acQ From: arno@natisbad.org (Arnaud Ebalard) To: Ryuji Wakikawa References: <87eiusx1s6.fsf@small.ssi.corp> <2D50B653-C7B4-4FDF-93A0-D7F0AE2BEEDC@gmail.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090520:hesham@elevatemobile.com::URpb42xjA+tR5QKj:000000000000000000000000000000000000001yz X-Hashcash: 1:20:090520:tsirtsis@googlemail.com::p08A/+O2jXXR/uK2:000000000000000000000000000000000000000++Q X-Hashcash: 1:20:090520:marcelo@it.uc3m.es::T6FI37llF9syHdVc:00000000000000000000000000000000000000000002Ll7 X-Hashcash: 1:20:090520:vijay@wichorus.com::YyI28Wyqh92V50GG:00000000000000000000000000000000000000000000Nda X-Hashcash: 1:20:090520:ryuji.wakikawa@gmail.com::NsY90kjwy8X17moq:00000000000000000000000000000000000001Rdq X-Hashcash: 1:20:090520:thierry.ernst@inria.fr::geHlOnscybOJK+3e:000000000000000000000000000000000000000Kwae Date: Wed, 20 May 2009 13:19:47 +0200 Message-ID: <87ws8cnhrg.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IETF MEXT WG ML Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals 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, 20 May 2009 11:17:40 -0000 Hi Ryuji, >From the 4 main points I raised in my review, 3 have been clarified. 1 is IMHO still open. It is discussed after a summary of closed items (for the records): - Section 5.6, i.e. complex Home Link scenario w/o *explicit* rationale : 3GPP use case, described by Christian and Julien. - No ability to have traffic routed to the HoA : will be handled in flow-binding document. - Reuse of a single IPsec tunnel mode SA for traffic for all CoA: the hack is certainly difficult to implement but easier on RFC 4301 compliant implementations. Thanks to Vijay for having coped w/ me on that one. The last point regarding the reuse of K bit was still open so I took a new look at what is in the draft. I'd like to clarify the expected behavior for the common case. The idea developed in section 9.1 of the draft is that the MN sends a BU with K bit set *and* a single BID mobility option to update the CoA which must be used by IKE. The HA receiving that BU will inform the IKE daemon on its side with the CoA with the BID. The thing is that if the IKE module on the MN supports movement, K bit will be set in all BU. It would not make sense ("MCoA keeps backward compatible with 3775") but it is probably worth asking the question before going further: does MCoA draft change that behavior? Now, let's consider a MN whose IKE module supports movement (its HA too). It will have K-bit set in all its BU. Let's say the MN currently has two CoA on different interfaces: CoA1 and CoA2 registered with its HA. Each one is associated with a given BID. Let's consider CoA1 is currently used for IKE traffic to the HA. Now, due to a handover, the MN configures a new address instead of CoA2. CoA1 had not been modified so the MN does not have to request an update of IKE address to the HA. But the MN needs to warn its HA about the address change. It cannot send a BU with K bit set and only the BID mobility option with the updated CoA2 value. How is this handled? Cheers, a+ From marcelo@it.uc3m.es Wed May 20 06:02:47 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 0320A28C38B for ; Wed, 20 May 2009 06:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.802 X-Spam-Level: X-Spam-Status: No, score=-5.802 tagged_above=-999 required=5 tests=[AWL=0.797, 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 B3CY34Cu01FD for ; Wed, 20 May 2009 06:02:46 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 432AC3A7135 for ; Wed, 20 May 2009 06:01:10 -0700 (PDT) Received: from r190-135-51-54.dialup.adsl.anteldata.net.uy (r190-135-51-54.dialup.adsl.anteldata.net.uy [190.135.51.54]) by smtp03.uc3m.es (Postfix) with ESMTP id AFCF47F2C68; Wed, 20 May 2009 15:02:38 +0200 (CEST) Message-ID: <4A13FF6E.7010803@it.uc3m.es> Date: Wed, 20 May 2009 15:02:38 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A1009D8.4060703@it.uc3m.es> <4A1334AD.5050109@ericsson.com> <4A1337B9.5070809@earthlink.net> In-Reply-To: <4A1337B9.5070809@earthlink.net> 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-16652.007 Cc: mext Subject: Re: [MEXT] weird idea about 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, 20 May 2009 13:02:47 -0000 Charles E. Perkins escribió: > > Implementation of what? Implementation of Mobile IP? Implementation > of IPv6? > I guess the application would have to use something to indicate that > the flow > label should NOT be zero. I still am not really seeing what's wrong > with that. > > In brief, since applications today do not use the flow label, I don't > see what's > wrong with the flow label being zero. When applications are built > that need to > use the flow label, they'll have to have operating systems support to > do it. > I agree that if the application wants to define a flow i.e. set the flow label, that should be honored. So no argument here. The question is whether a lower part of the stack could also have an idea of what a flow is. My suggestion is that packets belonging to a connected socket (either TCP or UDP) by default form a flow. So, i would like to change rfc3697 in the follwoing way: If the application sets the flow label, then it must be honored. If the application does not set the flow label, then the stack assign a rando flow label value for each connected socket and packets from that socket must carry the selected flow label. would that make sense to you? Regards, marcelo > Thanks for any light you can shed on this. > > Regards, > Charlie P. > > From marcelo@it.uc3m.es Wed May 20 06:03: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 0C2C43A6822 for ; Wed, 20 May 2009 06:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.835 X-Spam-Level: X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=0.764, 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 QTuaF+Ii7mNg for ; Wed, 20 May 2009 06:03:11 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2BD3C28C3A7 for ; Wed, 20 May 2009 06:03:03 -0700 (PDT) Received: from r190-135-51-54.dialup.adsl.anteldata.net.uy (r190-135-51-54.dialup.adsl.anteldata.net.uy [190.135.51.54]) by smtp01.uc3m.es (Postfix) with ESMTP id 6175DBA4FE8; Wed, 20 May 2009 15:04:37 +0200 (CEST) Message-ID: <4A13FFE5.2050804@it.uc3m.es> Date: Wed, 20 May 2009 15:04:37 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> In-Reply-To: <200905200757.24445.julien.laganier.IETF@googlemail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16652.007 Cc: Jari Arkko , Julien Laganier Subject: [MEXT] About the flow binding charter item 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, 20 May 2009 13:03:12 -0000 Hi, There seems to be some discrepancies about the MEXT charter item regarding the work on flow bindings. Since the charter is the guide for our work, it would be important to clarify it, so we can have a unified interpretation of the charter. Please note that what it is in the charter is not cast in stone, but it seems to reflect previous consensus and we need good reasons to change it. So, the current charter item about flow bindings reads: - 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]. The first problem with this text is the use and interpretation of the word policy. Since the policy word may have a broad interpretation. it would be important to make the charter more explicit about the expected work. We understand that it is the WG consensus that what need to be exchanged is a solution for the exchange of flow binding rules. So, we understand that it would be more explicit to replace the usage of the expression Flow/binding policies exchange by Flow Binding rules exchange. Would that reflect with the WG interpretation? Second, the current charter item explicitly mentions that the proposed approach must support sending flow binding information from the MN to the HA and also from the HA to the MN. Moreover, the current charter talks about influencing not only the selection of the CoA but also the selection of the HA address. However, our current WG document does not supports sending information from the HA and it does not cover the possibility of influencing the HA address. So, one possible interpretation of the charter would be that the MN sends flow binding information to influence the CoA selection and the HA sends flow binding information to influence the HA address selection. Other interpretation is that both the MN and the HA send information regarding both the HA address and the CoA selection. So, we would like that the WG express their opinion on both items mentioned above: 1- whether we should replace Flow/binding policies exchange by Flow Binding rules exchange in the charter 2- whether the information should be sent from the MN to the HA only or it should also be sent from the HA to the MN and if the information exchanged in each direction should affect the CoA and/or the HA address. Regards, Julien and marcelo From hesham@elevatemobile.com Wed May 20 06:18: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 CD4BA3A6D62 for ; Wed, 20 May 2009 06:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 4673txe0tVgb for ; Wed, 20 May 2009 06:18:20 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id AECD03A6A39 for ; Wed, 20 May 2009 06:18:19 -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 1M6li3-0004Es-Dz; Wed, 20 May 2009 23:19:51 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 20 May 2009 23:19:43 +1000 From: Hesham Soliman To: marcelo bagnulo braun , mext Message-ID: Thread-Topic: [MEXT] About the flow binding charter item Thread-Index: AcnZTaMrXPLnLtwTv0WirVwKc4gSeQ== In-Reply-To: <4A13FFE5.2050804@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Julien Laganier , Jari Arkko Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 13:18:21 -0000 > Second, the current charter item explicitly mentions that the > proposed approach must support sending flow binding information from > the MN to the HA and also from the HA to the MN. Moreover, the > current charter talks about influencing not only the selection of the > CoA but also the selection of the HA address. However, our current WG > document does not supports sending information from the HA and it > does not cover the possibility of influencing the HA address. So, one > possible interpretation of the charter would be that the MN sends > flow binding information to influence the CoA selection and the HA > sends flow binding information to influence the HA address selection. > Other interpretation is that both the MN and the HA send information > regarding both the HA address and the CoA selection. => I just noticed the but about influencing the HA address selection actually. I don't even know what that means or why it's there. > > So, we would like that the WG express their opinion on both items > mentioned above: > > 1- whether we should replace Flow/binding policies exchange by Flow > Binding rules exchange in the charter => Agree. > > 2- whether the information should be sent from the MN to the HA only > or it should also be sent from the HA to the MN and if the > information exchanged in each direction should affect the CoA and/or > the HA address. => As a charter, I don't think it needs to describe how something should be solved. It should talk about _what_ needs to be solved, i.e. The problem and not how to solve it. So I would say "exchange filter rules between the mobile node and HA". Implicit in that statement is the use of MIP, which should be non-controversial given the WG's role. Hesham > > Regards, Julien and marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From thierry.ernst@inria.fr Wed May 20 06:20: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 0D3D33A6D62 for ; Wed, 20 May 2009 06:20:19 -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_FR=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 xQOVOCmIdlh6 for ; Wed, 20 May 2009 06:20:17 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 35C783A6949 for ; Wed, 20 May 2009 06:20:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,221,1241388000"; d="vcf'?scan'208";a="26505102" Received: from dhcp-rocq-96.inria.fr ([128.93.62.96]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 May 2009 15:21:52 +0200 Message-ID: <4A1403EF.4020104@inria.fr> Date: Wed, 20 May 2009 15:21:51 +0200 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> In-Reply-To: <4A13FFE5.2050804@it.uc3m.es> Content-Type: multipart/mixed; boundary="------------030607080003060406020603" Cc: Nicolas Montavont , Julien Laganier , Jari Arkko , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 13:20:19 -0000 This is a multi-part message in MIME format. --------------030607080003060406020603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Marcelo, Let me reply since this part of the MEXT charter was taken from MonAmi6 charter which Nicolas and I wrote with the help of other people (including ADs). > > > There seems to be some discrepancies about the MEXT charter item > regarding the work on flow bindings. > Since the charter is the guide for our work, it would be important to > clarify it, so we can have a unified interpretation of the charter. > Please note that what it is in the charter is not cast in stone, but > it seems to reflect previous consensus and we need good reasons to > change it. > > So, the current charter item about flow bindings reads: > > - 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]. > > The first problem with this text is the use and interpretation of the > word policy. Since the policy word may have a broad interpretation. > it would be important to make the charter more explicit about the > expected work. We understand that it is the WG consensus that what > need to be exchanged is a solution for the exchange of flow binding > rules. > > So, we understand that it would be more explicit to replace the usage > of the expression Flow/binding policies exchange by Flow Binding > rules exchange. Would that reflect with the WG interpretation? Yes. At the time there was no controversy when using the former wording. > > Second, the current charter item explicitly mentions that the > proposed approach must support sending flow binding information from > the MN to the HA and also from the HA to the MN. Moreover, the > current charter talks about influencing not only the selection of the > CoA but also the selection of the HA address. However, our current WG > document does not supports sending information from the HA and it > does not cover the possibility of influencing the HA address. So, one > possible interpretation of the charter would be that the MN sends > flow binding information to influence the CoA selection and the HA > sends flow binding information to influence the HA address selection. > Other interpretation is that both the MN and the HA send information > regarding both the HA address and the CoA selection. > > So, we would like that the WG express their opinion on both items > mentioned above: > > 1- whether we should replace Flow/binding policies exchange by Flow > Binding rules exchange in the charter Yes. > > 2- whether the information should be sent from the MN to the HA only > or it should also be sent from the HA to the MN and if the > information exchanged in each direction should affect the CoA and/or > the HA address. I would recommend to rephrase the question in 2.a and 2.b 2.a.: Unidirectional exchange or bidirectional ? In MonAmi6 times, we definitely wanted to have a bidirectional exchange of rules and I think we should stick to it. It will be required in some usage scenarios. 2.b. Affect CoA only, and/or HA address ? and we wanted to influence the choice of the HoA too though this was not agreed for setting up MonAmi6 as a group so this was rephrased and HA address appeared instead, as a compromise. I wish we keep the possibility to influence the choice of the HA address. Now, this said, the current drafts may or may not address all of these (they may not if this would bring them to square one as we need these draft to be published), but these shall be kept in the charter, definitely. Regards, Thierry > > Regards, Julien and marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --------------030607080003060406020603 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------030607080003060406020603-- From suresh.krishnan@ericsson.com Wed May 20 06:29:59 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 A21A13A6B51 for ; Wed, 20 May 2009 06:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 ph1DPkZX+gCd for ; Wed, 20 May 2009 06:29:58 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id AF0763A6C92 for ; Wed, 20 May 2009 06:29:58 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n4KDVYMs010268; Wed, 20 May 2009 08:31:34 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 08:30:22 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 08:30:21 -0500 Message-ID: <4A1405A7.8010207@ericsson.com> Date: Wed, 20 May 2009 09:29:11 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A1009D8.4060703@it.uc3m.es> <4A1334AD.5050109@ericsson.com> <4A1337B9.5070809@earthlink.net> In-Reply-To: <4A1337B9.5070809@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 May 2009 13:30:22.0073 (UTC) FILETIME=[20160E90:01C9D94F] Cc: mext Subject: Re: [MEXT] weird idea about 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, 20 May 2009 13:29:59 -0000 Hi Charlie, Always good to hear from you :-) On 19/05/09 06:50 PM, Charles E. Perkins wrote: > > Hello folks, > > I've been following some of this discussion from afar, please excuse > if I am not up to speed... > > Suresh Krishnan wrote: >> Hi Marcelo, >> >> On 17/05/09 08:58 AM, marcelo bagnulo braun wrote: >>> ok, let me try again because it seems i am failing miserably to >>> communicate what i want to say (or it simply so broken that people >>> cannot believe what they are reading :-) >> >> I think it is a cool idea but it is very hard to realize in practice >> since it needs CNs to be changed. > > Right. This seems very much the point. If we are going to enable the use > of flow labels, CNs need to be changed. The application that wants to > have flows will have to run on the mobile and on the CN. > > But this seems perfectly fine, even desirable, to me. Am I missing > something? Yep. While I agree this is desirable and possible in the MNs, we are talking about the CNs. > > For an application that wants to make a flow happen that doesn't > use the flow label, is it somehow imagined that the application will > not have to run on the CN? This is not the point. If the application sets the flow label, the OS will honor it (at least in all the cases I have seen), but the point here is that the IPv6 stack needs to AUTOMATICALLY set the flow label for each new flow. i.e. every new connect() results in a new NON-ZERO flow label. > >> >>> Suppose now that the app2 in the CN starts a flow to the MN. >>> According to RFC3697, the CN SHOULD assign a different flow label to >>> the packets belonging to this flow e.g. to this TCP connection. >> >> This is the crux of the issue. Almost every implementation I have seen >> sets the flow label to zero. This falls under the category "A source >> node which does not assign traffic to flows MUST set the Flow Label to >> zero.". Add to this the fact that compliance to RFC3697 is completely >> optional (it is not even mentioned in RFC4294), and this task quickly >> becomes pretty improbable. > > Implementation of what? Implementation of Mobile IP? Implementation of > IPv6? IPv6. Again, we are talking about CNs here. I do not see issues with the MN being updated to support this concept. > I guess the application would have to use something to indicate that the > flow > label should NOT be zero. I still am not really seeing what's wrong > with that. Nothing. Except that we are not talking about flow aware applications. We are talking about flow aware OSs automatically assigning flow labels. > > In brief, since applications today do not use the flow label, I don't > see what's > wrong with the flow label being zero. When applications are built that > need to > use the flow label, they'll have to have operating systems support to do > it. > > Thanks for any light you can shed on this. Hope that clarifies my position. Thanks Suresh From arno@natisbad.org Wed May 20 06:32: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 684B328C37B for ; Wed, 20 May 2009 06:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 HvfanYrKICQm for ; Wed, 20 May 2009 06:32:55 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 7B1AB3A6BFF for ; Wed, 20 May 2009 06:32:55 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M6lwC-0006RQ-MS; Wed, 20 May 2009 15:34:28 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: marcelo bagnulo braun References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090520:jari.arkko@piuha.net::1bCC0OdQwgcGvq5r:000000000000000000000000000000000000000003Wzz X-Hashcash: 1:20:090520:marcelo@it.uc3m.es::MObilcMI690akSxz:00000000000000000000000000000000000000000005695 X-Hashcash: 1:20:090520:julien.laganier.ietf@googlemail.com::/Vjwps5plE6YBimV:000000000000000000000000007Khi X-Hashcash: 1:20:090520:mext@ietf.org::7oRcNjNQhWXp2ZvY:00009iLb Date: Wed, 20 May 2009 15:35:06 +0200 In-Reply-To: <4A13FFE5.2050804@it.uc3m.es> (marcelo bagnulo braun's message of "Wed, 20 May 2009 15:04:37 +0200") Message-ID: <87d4a3oq2d.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Julien Laganier , Jari Arkko , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 13:32:56 -0000 Hi, marcelo bagnulo braun writes: > So, we would like that the WG express their opinion on both items > mentioned above: > > 1- whether we should replace Flow/binding policies exchange by Flow > Binding rules exchange in the charter Maybe it would be easier to define both terms before asking for an opinion. I think the whole discussion started because people did not agree on the definitions of "policy" and "rule". > 2- whether the information should be sent from the MN to the HA only > or it should also be sent from the HA to the MN and if the > information exchanged in each direction should affect the CoA and/or > the HA address. I don't see any specific scenario in which it would be useful for the HA to influence the MN on flow binding. So I am in favour of keeping current focus on the MN to HA side. The reverse direction could be treated in external documents and if there are useful use cases and momentum, that scenario could be reconsidered later. For the HA@ question, I don't see what you have in mind. Usually, the MN has a single address for the HA. Are you considering the ability for the HA to be accessible at various addresses by the MN? If that is the case, I think working on the flow binding betwenn CoAs (and possibly HoA via RO bypass case) is the thing to do. Cheers, a+ From arno@natisbad.org Wed May 20 06:42: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 8E6F83A6BFF for ; Wed, 20 May 2009 06:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 CDRurqE5Nc9m for ; Wed, 20 May 2009 06:42:43 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id A9B853A6906 for ; Wed, 20 May 2009 06:42:43 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M6m5h-0006Rx-FI; Wed, 20 May 2009 15:44:17 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Thierry Ernst References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> <4A1403EF.4020104@inria.fr> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090520:thierry.ernst@inria.fr::mGNVLTgC3/zpfZbO:0000000000000000000000000000000000000003QYS X-Hashcash: 1:20:090520:julien.laganier.ietf@googlemail.com::a3wpuFdJP3ivgy2V:000000000000000000000000003Uw3 X-Hashcash: 1:20:090520:jari.arkko@piuha.net::pSYHqNB7IN/kn/uQ:000000000000000000000000000000000000000003Alm X-Hashcash: 1:20:090520:marcelo@it.uc3m.es::kqHYP8z0VPmG5I1w:00000000000000000000000000000000000000000005wq2 X-Hashcash: 1:20:090520:mext@ietf.org::eABcMfa50Dnh0pae:00008P7J X-Hashcash: 1:20:090520:nicolas.montavont@telecom-bretagne.eu::2Gj7SzNEApgv89d+:0000000000000000000000006pos Date: Wed, 20 May 2009 15:44:55 +0200 Message-ID: <871vqjopm0.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nicolas Montavont , Jari Arkko , Julien Laganier , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 13:42:44 -0000 Hi Thierry, Thierry Ernst writes: >> 2- whether the information should be sent from the MN to the HA only >> or it should also be sent from the HA to the MN and if the >> information exchanged in each direction should affect the CoA and/or >> the HA address. > I would recommend to rephrase the question in 2.a and 2.b > > 2.a.: Unidirectional exchange or bidirectional ? > > In MonAmi6 times, we definitely wanted to have a bidirectional > exchange of rules and I think we should stick to it. It will be > required in some usage scenarios. Can you quickly describe those scenarios. > 2.b. Affect CoA only, and/or HA address ? > > and we wanted to influence the choice of the HoA too though this was > not agreed for setting up MonAmi6 as a group so this was rephrased and > HA address appeared instead, as a compromise. I wish we keep the > possibility to influence the choice of the HA address. > > Now, this said, the current drafts may or may not address all of these > (they may not if this would bring them to square one as we need these > draft to be published), but these shall be kept in the charter, > definitely. When you say "influence the choice of the HoA", you mean provide the ability for the MN using the flow binding solution with a CN to have traffic routed to the HoA instead of some CoA, i.e. bypass RO. Or sth else? Cheers, a+ From marcelo@it.uc3m.es Wed May 20 06:44: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 681D93A6BFF for ; Wed, 20 May 2009 06:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=0.733, 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 apEfXjstV6no for ; Wed, 20 May 2009 06:43:59 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 845F53A6B62 for ; Wed, 20 May 2009 06:43:59 -0700 (PDT) Received: from r190-135-51-54.dialup.adsl.anteldata.net.uy (r190-135-51-54.dialup.adsl.anteldata.net.uy [190.135.51.54]) by smtp03.uc3m.es (Postfix) with ESMTP id BC3DB7F2C7A; Wed, 20 May 2009 15:45:25 +0200 (CEST) Message-ID: <4A140974.3000707@it.uc3m.es> Date: Wed, 20 May 2009 15:45:24 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Arnaud Ebalard References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> <87d4a3oq2d.fsf@small.ssi.corp> In-Reply-To: <87d4a3oq2d.fsf@small.ssi.corp> 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-16652.007 Cc: Julien Laganier , Jari Arkko , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 13:44:00 -0000 Arnaud Ebalard escribió: > Hi, > > marcelo bagnulo braun writes: > > >> So, we would like that the WG express their opinion on both items >> mentioned above: >> >> 1- whether we should replace Flow/binding policies exchange by Flow >> Binding rules exchange in the charter >> > > Maybe it would be easier to define both terms before asking for an > opinion. I think the whole discussion started because people did not > agree on the definitions of "policy" and "rule". > are you suggesting we include a definition of policy or rule in the charter? I am not sure this is the best approach. What i would like to to have some words in the charter that are non controversial (in their interpretation) I was thinking that policy was a controversial word (with multiple interpretations) while rule wasn't, hence the proposal to change it. > >> 2- whether the information should be sent from the MN to the HA only >> or it should also be sent from the HA to the MN and if the >> information exchanged in each direction should affect the CoA and/or >> the HA address. >> > > I don't see any specific scenario in which it would be useful for the HA > to influence the MN on flow binding. So I am in favour of keeping > current focus on the MN to HA side. The reverse direction could be > treated in external documents and if there are useful use cases and > momentum, that scenario could be reconsidered later. > > For the HA@ question, I don't see what you have in mind. i don't have anything in mind (really, it is pure vacuum lately) I am just refering to the charter as it is currently written and i want to understand where the WG stands on these topics. so feel free to make any interpretation and explain what you think makes sense. Let's see if we can reach a common understanding of what is the work that we should do. that is the basic goal here. Regards, marcelo > Usually, the MN > has a single address for the HA. Are you considering the ability for the > HA to be accessible at various addresses by the MN? If that is the case, > I think working on the flow binding betwenn CoAs (and possibly HoA via > RO bypass case) is the thing to do. > > Cheers, > > a+ > > From arno@natisbad.org Wed May 20 06:52: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 AB6613A6C61 for ; Wed, 20 May 2009 06:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 02dnXRFJRJ+E for ; Wed, 20 May 2009 06:52:04 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 45DC33A6C56 for ; Wed, 20 May 2009 06:52:03 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M6mEi-0006T0-Ih; Wed, 20 May 2009 15:53:36 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: marcelo bagnulo braun References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> <87d4a3oq2d.fsf@small.ssi.corp> <4A140974.3000707@it.uc3m.es> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090520:marcelo@it.uc3m.es::609Gk1JjobghGNPI:00000000000000000000000000000000000000000000n4q X-Hashcash: 1:20:090520:jari.arkko@piuha.net::harwJgHr882SC/Xu:000000000000000000000000000000000000000001fzd X-Hashcash: 1:20:090520:julien.laganier.ietf@googlemail.com::UAjbNjg16aNJH0kZ:0000000000000000000000000071QN X-Hashcash: 1:20:090520:mext@ietf.org::I+OezlPbJS+YoACu:00008MAN Date: Wed, 20 May 2009 15:54:14 +0200 In-Reply-To: <4A140974.3000707@it.uc3m.es> (marcelo bagnulo braun's message of "Wed, 20 May 2009 15:45:24 +0200") Message-ID: <87skiznam1.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , Jari Arkko , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 13:52:05 -0000 Hello, marcelo bagnulo braun writes: > Arnaud Ebalard escribi=C3=B3: >> Hi, >> >> marcelo bagnulo braun writes: >> >>=20=20=20 >>> So, we would like that the WG express their opinion on both items >>> mentioned above: >>> >>> 1- whether we should replace Flow/binding policies exchange by Flow >>> Binding rules exchange in the charter >>>=20=20=20=20=20 >> >> Maybe it would be easier to define both terms before asking for an >> opinion. I think the whole discussion started because people did not >> agree on the definitions of "policy" and "rule". >>=20=20=20 > are you suggesting we include a definition of policy or rule in the > charter? no, just provide the definitions of both words on the list and then decide based on those. >>> 2- whether the information should be sent from the MN to the HA only >>> or it should also be sent from the HA to the MN and if the >>> information exchanged in each direction should affect the CoA and/or >>> the HA address. >>>=20=20=20=20=20 >> >> I don't see any specific scenario in which it would be useful for the HA >> to influence the MN on flow binding. So I am in favour of keeping >> current focus on the MN to HA side. The reverse direction could be >> treated in external documents and if there are useful use cases and >> momentum, that scenario could be reconsidered later. >> >> For the HA@ question, I don't see what you have in mind.=20 > i don't have anything in mind (really, it is pure vacuum lately) ;-) > I am just refering to the charter as it is currently written and i > want to understand where the WG stands on these topics. > so feel free to make any interpretation and explain what you think > makes sense. Let's see if we can reach a common understanding of what > is the work that we should do. that is the basic goal here. Based on previous comments from Thierry, the "HA address" thing needs to be clarified. Cheers, a+ From tsirtsis@googlemail.com Wed May 20 07:03: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 C2CEE3A710C for ; Wed, 20 May 2009 07:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.200, 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 xyfjG-ghS7w8 for ; Wed, 20 May 2009 07:03:55 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by core3.amsl.com (Postfix) with ESMTP id 4C9A03A7111 for ; Wed, 20 May 2009 07:03:55 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so209369fkq.5 for ; Wed, 20 May 2009 07:05:29 -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=l7W4qXNrKMPKyXm2TcVRfu9k+Kh+ar8TkvUfBir9Xxg=; b=t2kKLqXPF7S/oUoLqM1WH0jOYTmNIM+l4qMV2ioq9qcs2ddW1ha7+BnSExO8+1/ba+ aSIT9/eA8pYpKfHq1lnUZWapV2VHC35e3fD8rYbDt5BqUyY7MNepiSQgsBMttCSgwgOt qbzyOxXmXo7zOhzJfk6oHYENQM34g4s6qmgA0= 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=xxlwSU8QBGuaQw8ohOfkSuxSw95ltCRve95DlCS6ifLcAM2orZvfnuK4s49oorIGTA YO892GffgZ5xBrSgAUw0HcfKYfK4xqq+61llLiRvIupbVvpySbgpjou2j5cwA3+fKShO BKt/cDkz6pKF0gXRxn3LiNA9rbMp5eq5LKfko= MIME-Version: 1.0 Received: by 10.223.126.145 with SMTP id c17mr986119fas.16.1242828329509; Wed, 20 May 2009 07:05:29 -0700 (PDT) In-Reply-To: <4A1403EF.4020104@inria.fr> References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> <4A1403EF.4020104@inria.fr> Date: Wed, 20 May 2009 15:05:29 +0100 Message-ID: From: George Tsirtsis To: Thierry Ernst Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Nicolas Montavont , Jari Arkko , Julien Laganier , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 14:03:56 -0000 2009/5/20 Thierry Ernst : > Dear Marcelo, > > Let me reply since this part of the MEXT charter was taken from MonAmi6 > charter which Nicolas and I wrote with the help of other people (including > ADs). >> >> >> There seems to be some discrepancies about the MEXT charter item >> regarding the work on flow bindings. >> Since the charter is the guide for our work, it would be important to >> clarify it, so we can have a unified interpretation of the charter. >> Please note that what it is in the charter is not cast in stone, but >> it seems to reflect previous consensus and we need good reasons to >> change it. >> >> So, the current charter item about flow bindings reads: >> >> - 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]. >> >> The first problem with this text is the use and interpretation of the >> word policy. Since the policy word may have a broad interpretation. >> it would be important to make the charter more explicit about the >> expected work. We understand that it is the WG consensus that what >> need to be exchanged is a solution for the exchange of flow binding >> rules. >> >> So, we understand that it would be more explicit to replace the usage >> of the expression Flow/binding policies exchange by Flow Binding >> rules exchange. Would that reflect with the WG interpretation? > > Yes. > At the time there was no controversy when using the former wording. >> >> Second, the current charter item explicitly mentions that the >> proposed approach must support sending flow binding information from >> the MN to the HA and also from the HA to the MN. Moreover, the >> current charter talks about influencing not only the selection of the >> CoA but also the selection of the HA address. However, our current WG >> document does not supports sending information from the HA and it >> does not cover the possibility of influencing the HA address. So, one >> possible interpretation of the charter would be that the MN sends >> flow binding information to influence the CoA selection and the HA >> sends flow binding information to influence the HA address selection. >> Other interpretation is that both the MN and the HA send information >> regarding both the HA address and the CoA selection. >> >> So, we would like that the WG express their opinion on both items >> mentioned above: >> >> 1- whether we should replace Flow/binding policies exchange by Flow >> Binding rules exchange in the charter > > Yes. >> >> 2- whether the information should be sent from the MN to the HA only >> or it should also be sent from the HA to the MN and if the >> information exchanged in each direction should affect the CoA and/or >> the HA address. > > I would recommend to rephrase the question in 2.a and 2.b > > 2.a.: Unidirectional exchange or bidirectional ? > > In MonAmi6 times, we definitely wanted to have a bidirectional exchange of > rules and I think we should stick to it. It will be required in some usage > scenarios. > GT> What scenarios are you referring to? All the practical scenarios I am aware of use broad guidelines from the network to the end node (802.21, ANDSF etc) and they do not try to micromanage the MN. I thought this became part of MIPSHOP. > 2.b. Affect CoA only, and/or HA address ? > GT> Could someone elaborate on the "HA address" part? what is this all about? > > and we wanted to influence the choice of the HoA too though this was not > agreed for setting up MonAmi6 as a group so this was rephrased and HA > address appeared instead, as a compromise. I wish we keep the possibility to > influence the choice of the HA address. > > Now, this said, the current drafts may or may not address all of these (they > may not if this would bring them to square one as we need these draft to be > published), but these shall be kept in the charter, definitely. > > Regards, > Thierry >> >> Regards, Julien and marcelo >> >> >> _______________________________________________ >> 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 May 20 07:11: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 49EE83A6C5A for ; Wed, 20 May 2009 07:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 l0Nwqr+xgAVm for ; Wed, 20 May 2009 07:11:43 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 660A33A6B5A for ; Wed, 20 May 2009 07:11:42 -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 1M6mXX-00056P-Nf; Thu, 21 May 2009 00:13:03 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 21 May 2009 00:12:54 +1000 From: Hesham Soliman To: George Tsirtsis , Thierry Ernst Message-ID: Thread-Topic: [MEXT] About the flow binding charter item Thread-Index: AcnZVREnvw8qYvzrM0KC/Egq+nn5iQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Nicolas Montavont , Julien Laganier , Jari Arkko , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 14:11:44 -0000 > >> 2.b. Affect CoA only, and/or HA address ? >> > > GT> Could someone elaborate on the "HA address" part? what is this all about? => Historically monami6 was trying to allow for multihoming of both HoA and CoA. There was no concensus/IESG approval for such WG in paris but everyone agreed that we can start with CoA multihoming but do an analsysis doc for both. I assume this "left-over" wording about HA address selection is a really bad attempt to preserve something from the multiple HoA sceanrio. But I think it's at best confusing to have such text and when you actually try to read this sentence and see what it means you discover it makes no sense at all. Hesham > >> >> and we wanted to influence the choice of the HoA too though this was not >> agreed for setting up MonAmi6 as a group so this was rephrased and HA >> address appeared instead, as a compromise. I wish we keep the possibility to >> influence the choice of the HA address. >> >> Now, this said, the current drafts may or may not address all of these (they >> may not if this would bring them to square one as we need these draft to be >> published), but these shall be kept in the charter, definitely. >> >> Regards, >> Thierry >>> >>> Regards, Julien and marcelo >>> >>> >>> _______________________________________________ >>> 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 Wed May 20 07:13: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 75D6A28C2B7 for ; Wed, 20 May 2009 07:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.198, 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 ue0McEZ1Ksob for ; Wed, 20 May 2009 07:13:53 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 47E6D28C0DF for ; Wed, 20 May 2009 07:13:53 -0700 (PDT) Received: by fxm2 with SMTP id 2so447453fxm.37 for ; Wed, 20 May 2009 07:15:27 -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=5VwpaWSpOq7JtaS1AA94af7UOsIDexnjzH8tNk1GAVQ=; b=sWdL4/huY5iTfo1T8OQl5e9XS0lCrUYm8j8O0SoAav9P7yFtEGtNymUy2MUC+I/G8I GN83PewEe2TOCoRdRL/Pc9xn6zdc/vSz3MAVowDep5wvK/Spm9OxoOPiG9EXpK//NRuZ T7y1uY8wIHNECMCDaA1xbWnns1QdA5qfeislU= 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=WGOXLjcQ6p+3wIBxh1/eqil+7hjrMgyCYXju9xpvoEq4cccV8WVf1InXDtk/L3iXqx Io2edoeON3HCFF1onvTz+aj/eOcWaL5ggotDkY7yWf77QuOI7JHyczko9MPSzYzaADj/ iGtUqjLRjm1sSot8LIVL75kv/YGGhLKUJvEms= MIME-Version: 1.0 Received: by 10.223.107.68 with SMTP id a4mr954285fap.104.1242828927304; Wed, 20 May 2009 07:15:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 May 2009 15:15:27 +0100 Message-ID: From: George Tsirtsis To: Hesham Soliman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Nicolas Montavont , Julien Laganier , Jari Arkko , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 14:13:54 -0000 But is this about multiple HoAs belonging to a given MN, on the same HA? On Wed, May 20, 2009 at 3:12 PM, Hesham Soliman wrote: > > >> >>> 2.b. Affect CoA only, and/or HA address ? >>> >> >> GT> Could someone elaborate on the "HA address" part? what is this all about? > > => Historically monami6 was trying to allow for multihoming of both HoA and > CoA. There was no concensus/IESG approval for such WG in paris but everyone > agreed that we can start with CoA multihoming but do an analsysis doc for > both. > I assume this "left-over" wording about HA address selection is a really bad > attempt to preserve something from the multiple HoA sceanrio. But I think > it's at best confusing to have such text and when you actually try to read > this sentence and see what it means you discover it makes no sense at all. > > Hesham > >> >>> >>> and we wanted to influence the choice of the HoA too though this was not >>> agreed for setting up MonAmi6 as a group so this was rephrased and HA >>> address appeared instead, as a compromise. I wish we keep the possibility to >>> influence the choice of the HA address. >>> >>> Now, this said, the current drafts may or may not address all of these (they >>> may not if this would bring them to square one as we need these draft to be >>> published), but these shall be kept in the charter, definitely. >>> >>> Regards, >>> Thierry >>>> >>>> Regards, Julien and marcelo >>>> >>>> >>>> _______________________________________________ >>>> 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 May 20 07:17: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 214CC28C395 for ; Wed, 20 May 2009 07:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 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 Tkd3L0x378je for ; Wed, 20 May 2009 07:17:32 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 3CC9528C367 for ; Wed, 20 May 2009 07:17:32 -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 1M6mdG-0005l8-Ar; Thu, 21 May 2009 00:18:58 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 21 May 2009 00:18:53 +1000 From: Hesham Soliman To: George Tsirtsis Message-ID: Thread-Topic: [MEXT] About the flow binding charter item Thread-Index: AcnZVeciNIKKgM7XS0mzRC8auWuQSA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Nicolas Montavont , Julien Laganier , Jari Arkko , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 14:17:33 -0000 On 21/05/09 12:15 AM, "George Tsirtsis" wrote: > But is this about multiple HoAs belonging to a given MN, on the same HA? => same or different HA. That was the initial discussion. But as I said, in Paris it was agreed that monami6 will only work on PS docs for CoA multihoming. Hesham > > On Wed, May 20, 2009 at 3:12 PM, Hesham Soliman > wrote: >> >> >>> >>>> 2.b. Affect CoA only, and/or HA address ? >>>> >>> >>> GT> Could someone elaborate on the "HA address" part? what is this all >>> about? >> >> => Historically monami6 was trying to allow for multihoming of both HoA and >> CoA. There was no concensus/IESG approval for such WG in paris but everyone >> agreed that we can start with CoA multihoming but do an analsysis doc for >> both. >> I assume this "left-over" wording about HA address selection is a really bad >> attempt to preserve something from the multiple HoA sceanrio. But I think >> it's at best confusing to have such text and when you actually try to read >> this sentence and see what it means you discover it makes no sense at all. >> >> Hesham >> >>> >>>> >>>> and we wanted to influence the choice of the HoA too though this was not >>>> agreed for setting up MonAmi6 as a group so this was rephrased and HA >>>> address appeared instead, as a compromise. I wish we keep the possibility >>>> to >>>> influence the choice of the HA address. >>>> >>>> Now, this said, the current drafts may or may not address all of these >>>> (they >>>> may not if this would bring them to square one as we need these draft to be >>>> published), but these shall be kept in the charter, definitely. >>>> >>>> Regards, >>>> Thierry >>>>> >>>>> Regards, Julien and marcelo >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Wed May 20 07:43: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 9A25E28C10E for ; Wed, 20 May 2009 07:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.732 X-Spam-Level: X-Spam-Status: No, score=-0.732 tagged_above=-999 required=5 tests=[AWL=-0.237, 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 0IS06noqP2WI for ; Wed, 20 May 2009 07:43:27 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 35FB43A67A5 for ; Wed, 20 May 2009 07:43:27 -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 <0KJY00AVY699B6@szxga04-in.huawei.com> for mext@ietf.org; Wed, 20 May 2009 22:43:58 +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 <0KJY0042G699FP@szxga04-in.huawei.com> for mext@ietf.org; Wed, 20 May 2009 22:43:57 +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 <0KJY00F0O6976F@szxml04-in.huawei.com> for mext@ietf.org; Wed, 20 May 2009 22:43:57 +0800 (CST) Date: Wed, 20 May 2009 09:43:54 -0500 From: Frank Xia To: marcelo bagnulo braun , mext Message-id: <008f01c9d959$67dad080$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: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> Cc: Julien Laganier , Jari Arkko Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 14:43:28 -0000 Hi Marcelo Texts are copied here for simplification: > 2- whether the information should be sent from the MN to the HA only > or it should also be sent from the HA to the MN and if the > information exchanged in each direction should affect the CoA and/or > the HA address. IMHO, we should define operation from HA to MN. A very simple analogy, there is "Binding Revocation for IPv6 Mobility", and I think there are the same reasons to have ""Flow Binding Revocation for IPv6 Mobility" In 3GPP network, operators always tend to control the networks. We have some details in our draft http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt. BR Frank ----- Original Message ----- From: "marcelo bagnulo braun" To: "mext" Cc: "Jari Arkko" ; "Julien Laganier" Sent: Wednesday, May 20, 2009 8:04 AM Subject: [MEXT] About the flow binding charter item > Hi, > > There seems to be some discrepancies about the MEXT charter item > regarding the work on flow bindings. > Since the charter is the guide for our work, it would be important to > clarify it, so we can have a unified interpretation of the charter. > Please note that what it is in the charter is not cast in stone, but > it seems to reflect previous consensus and we need good reasons to > change it. > > So, the current charter item about flow bindings reads: > > - 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]. > > The first problem with this text is the use and interpretation of the > word policy. Since the policy word may have a broad interpretation. > it would be important to make the charter more explicit about the > expected work. We understand that it is the WG consensus that what > need to be exchanged is a solution for the exchange of flow binding > rules. > > So, we understand that it would be more explicit to replace the usage > of the expression Flow/binding policies exchange by Flow Binding > rules exchange. Would that reflect with the WG interpretation? > > Second, the current charter item explicitly mentions that the > proposed approach must support sending flow binding information from > the MN to the HA and also from the HA to the MN. Moreover, the > current charter talks about influencing not only the selection of the > CoA but also the selection of the HA address. However, our current WG > document does not supports sending information from the HA and it > does not cover the possibility of influencing the HA address. So, one > possible interpretation of the charter would be that the MN sends > flow binding information to influence the CoA selection and the HA > sends flow binding information to influence the HA address selection. > Other interpretation is that both the MN and the HA send information > regarding both the HA address and the CoA selection. > > So, we would like that the WG express their opinion on both items > mentioned above: > > 1- whether we should replace Flow/binding policies exchange by Flow > Binding rules exchange in the charter > > 2- whether the information should be sent from the MN to the HA only > or it should also be sent from the HA to the MN and if the > information exchanged in each direction should affect the CoA and/or > the HA address. > > Regards, Julien and marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From behcetsarikaya@yahoo.com Wed May 20 08:25: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 894183A6C9E for ; Wed, 20 May 2009 08:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, 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 b11x2KkbjG-Q for ; Wed, 20 May 2009 08:25:00 -0700 (PDT) Received: from n77.bullet.mail.sp1.yahoo.com (n77.bullet.mail.sp1.yahoo.com [98.136.44.45]) by core3.amsl.com (Postfix) with SMTP id ADDEA3A6AC1 for ; Wed, 20 May 2009 08:25:00 -0700 (PDT) Received: from [216.252.122.217] by n77.bullet.mail.sp1.yahoo.com with NNFMP; 20 May 2009 15:26:36 -0000 Received: from [67.195.9.82] by t2.bullet.sp1.yahoo.com with NNFMP; 20 May 2009 15:26:36 -0000 Received: from [67.195.9.110] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 20 May 2009 15:26:36 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 20 May 2009 15:24:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 437988.72438.bm@omp114.mail.gq1.yahoo.com Received: (qmail 89724 invoked by uid 60001); 20 May 2009 15:26:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242833196; bh=DiIfsW3VVOFRw6hCp0dgT/KfhCTa/CDfbq9eOhWw0us=; 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=Q71YKaL37ewF+An2BlJLWwvdEAxiU5xoCt2gT6xDgZCtCzjPOn1BS6vmz2Xm9sMCdseVWhfttrWa9g0jqkThWwYNkUJp2upq6YjlA0nhrtGmkhBPPy76lwZ9RwtTVrvKB+j/hV8ln/uW67PuBBdSPVwNYlOhF+ZRwzFAtTwSHS8= 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=tWcB6YfHtV9bMQF34+/AQOx2ni02+xXwcflZPYZcTTz0Y0DLpGxDyb2qSWNGLHEu7AXUDCwuN1NFn0IcbyB3M/qEVsTMVusk6r/fkGSHscBjkZqFNxTJ54xoQnewQZ/Z7gvhVQoBBZXHsvRmkDmOvMZhMTFFt0E1K5ey9kziTJM=; Message-ID: <235278.87793.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: OxDediMVM1kmvaa9EWFuUsnkYLCNpMSiV5x7UzcumfgFGkom_vIETTh_FVfhTWG0ijwF0Iq3BilhDRdUUw35NxdbhONcRBkmbOhthwSEYXVHBCuFRxQHymZHXaCCxhbxwiVzr6Kp75pVOoULKRYVZ4Y104t0N4FjFKBzR_rBCmBfrdWelawhpyUBYPgPBSJx9Mpj8VD_QuE43WU7smpepwbBo.yHwpzeALyylsaclNW8jUdRbYK8Yndf.bHvMq5uFHE8p5ACz4itl9nQZt0Yiana3dMKJWNiaszWUaRLttO9hA.ihGz6wd__KMdrnMhHYeDg Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Wed, 20 May 2009 08:26:36 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <4A1009D8.4060703@it.uc3m.es> <4A1334AD.5050109@ericsson.com> <4A1337B9.5070809@earthlink.net> <4A13FF6E.7010803@it.uc3m.es> Date: Wed, 20 May 2009 08:26:36 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun , "Charles E. Perkins" In-Reply-To: <4A13FF6E.7010803@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] weird idea about 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: Wed, 20 May 2009 15:25:01 -0000 Hi Marcelo,=0A=A0 The problem with 3697 seems to be not its contents but it= s deployment status.=0AI would agree with your proposed modification but ho= w do we address the problem of getting it used? In mobile environments?=0A= =0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0AFrom: marc= elo bagnulo braun =0ATo: Charles E. Perkins =0ACc: mext =0ASent: Wednesday, May 20, = 2009 8:02:38 AM=0ASubject: Re: [MEXT] weird idea about flow bindings=0A=0AC= harles E. Perkins escribi=F3:=0A> =0A> Implementation of what?=A0 Implement= ation of Mobile IP?=A0 Implementation of IPv6?=0A> I guess the application = would have to use something to indicate that the flow=0A> label should NOT = be zero.=A0 I still am not really seeing what's wrong with that.=0A> =0A> I= n brief, since applications today do not use the flow label, I don't see wh= at's=0A> wrong with the flow label being zero.=A0 When applications are bui= lt that need to=0A> use the flow label, they'll have to have operating syst= ems support to do it.=0A> =0A=0AI agree that if the application wants to de= fine a flow i.e. set the flow label, that should be honored. So no argument= here.=0A=0AThe question is whether a lower part of the stack could also ha= ve an idea of what a flow is.=0A=0AMy suggestion is that packets belonging = to a connected socket (either TCP or UDP) by default form a flow.=0A=0ASo, = i would like to change rfc3697 in the follwoing way:=0AIf the application s= ets the flow label, then it must be honored.=0AIf the application does not = set the flow label, then the stack assign a rando flow label value for each= connected socket and packets from that socket must carry the selected flow= label.=0A=0Awould that make sense to you?=0A=0ARegards, marcelo=0A=0A=0A> = Thanks for any light you can shed on this.=0A> =0A> Regards,=0A> Charlie P.= =0A> =0A> =0A=0A_______________________________________________=0AMEXT mail= ing list=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mext=0A=0A= =0A=0A From hesham@elevatemobile.com Wed May 20 09:12: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 D0CDA3A69B5 for ; Wed, 20 May 2009 09:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 mPDasfyJrBsC for ; Wed, 20 May 2009 09:12:35 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 9663B3A694F for ; Wed, 20 May 2009 09:12:34 -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 1M6oQS-0006xU-Ff; Thu, 21 May 2009 02:13:52 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 21 May 2009 02:13:44 +1000 From: Hesham Soliman To: Frank Xia , marcelo bagnulo braun , mext Message-ID: Thread-Topic: [MEXT] About the flow binding charter item Thread-Index: AcnZZfJ9/G4ex1P8UUyUkmrxzx0RWg== In-Reply-To: <008f01c9d959$67dad080$3e0c7c0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Jari Arkko , Julien Laganier Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 16:12:36 -0000 On 21/05/09 12:43 AM, "Frank Xia" wrote: > Hi Marcelo > > Texts are copied here for simplification: >> 2- whether the information should be sent from the MN to the HA only >> or it should also be sent from the HA to the MN and if the >> information exchanged in each direction should affect the CoA and/or >> the HA address. > > IMHO, we should define operation from HA to MN. > > A very simple analogy, there is "Binding Revocation > for IPv6 Mobility", and I think there are the same reasons > to have ""Flow Binding Revocation for IPv6 Mobility" => There is nothing in common between a binding revocation message which tells the MN that it needs to remove a binding maintained by the sender (the HA), and a message that tells the MN to use a particular address for one or more flows where the HA knows nothing about the conditions of the interface associated with such address. I don't understand how one can draw the analogy above. In one case the HA knows everything there is to know, in the other the HA knows nothing. > We have some details in our draft > http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt. => It's not about creating messages, it's how they would be used. Creating messages is easy. Hesham > > BR > Frank > > ----- Original Message ----- > From: "marcelo bagnulo braun" > To: "mext" > Cc: "Jari Arkko" ; "Julien Laganier" > > Sent: Wednesday, May 20, 2009 8:04 AM > Subject: [MEXT] About the flow binding charter item > > >> Hi, >> >> There seems to be some discrepancies about the MEXT charter item >> regarding the work on flow bindings. >> Since the charter is the guide for our work, it would be important to >> clarify it, so we can have a unified interpretation of the charter. >> Please note that what it is in the charter is not cast in stone, but >> it seems to reflect previous consensus and we need good reasons to >> change it. >> >> So, the current charter item about flow bindings reads: >> >> - 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]. >> >> The first problem with this text is the use and interpretation of the >> word policy. Since the policy word may have a broad interpretation. >> it would be important to make the charter more explicit about the >> expected work. We understand that it is the WG consensus that what >> need to be exchanged is a solution for the exchange of flow binding >> rules. >> >> So, we understand that it would be more explicit to replace the usage >> of the expression Flow/binding policies exchange by Flow Binding >> rules exchange. Would that reflect with the WG interpretation? >> >> Second, the current charter item explicitly mentions that the >> proposed approach must support sending flow binding information from >> the MN to the HA and also from the HA to the MN. Moreover, the >> current charter talks about influencing not only the selection of the >> CoA but also the selection of the HA address. However, our current WG >> document does not supports sending information from the HA and it >> does not cover the possibility of influencing the HA address. So, one >> possible interpretation of the charter would be that the MN sends >> flow binding information to influence the CoA selection and the HA >> sends flow binding information to influence the HA address selection. >> Other interpretation is that both the MN and the HA send information >> regarding both the HA address and the CoA selection. >> >> So, we would like that the WG express their opinion on both items >> mentioned above: >> >> 1- whether we should replace Flow/binding policies exchange by Flow >> Binding rules exchange in the charter >> >> 2- whether the information should be sent from the MN to the HA only >> or it should also be sent from the HA to the MN and if the >> information exchanged in each direction should affect the CoA and/or >> the HA address. >> >> Regards, Julien and marcelo >> >> >> _______________________________________________ >> 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 ietf@montavont.net Wed May 20 09:17: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 9BB0F3A684E for ; Wed, 20 May 2009 09:17:56 -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 Mcth8rmzdvEh for ; Wed, 20 May 2009 09:17:55 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 350DF3A6CB1 for ; Wed, 20 May 2009 09:17:55 -0700 (PDT) Received: by ewy24 with SMTP id 24so627915ewy.37 for ; Wed, 20 May 2009 09:19:30 -0700 (PDT) Received: by 10.210.79.3 with SMTP id c3mr1930823ebb.50.1242836370276; Wed, 20 May 2009 09:19:30 -0700 (PDT) Received: from dhcp-salsa-i178.rennes.enst-bretagne.fr (pat39-intra.rennes.enst-bretagne.fr [192.44.77.39]) by mx.google.com with ESMTPS id 7sm2184295eyg.47.2009.05.20.09.19.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 May 2009 09:19:29 -0700 (PDT) From: Nicolas Montavont To: Frank Xia In-Reply-To: <008f01c9d959$67dad080$3e0c7c0a@china.huawei.com> X-Priority: 3 References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> <008f01c9d959$67dad080$3e0c7c0a@china.huawei.com> Message-Id: <756ABF87-88CD-4487-B437-49B05933FF93@montavont.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 20 May 2009 18:19:14 +0200 X-Mailer: Apple Mail (2.930.3) Cc: Jari Arkko , Julien Laganier , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 16:17:56 -0000 Hi, On May 20, 2009, at 4:43 PM, Frank Xia wrote: > Hi Marcelo > > Texts are copied here for simplification: >> 2- whether the information should be sent from the MN to the HA only >> or it should also be sent from the HA to the MN and if the >> information exchanged in each direction should affect the CoA and/or >> the HA address. > > IMHO, we should define operation from HA to MN. I disagree: the HA has no way to know about which address is allocated to which interface. For me, Flow Binding in MIPv6 should only define the final mapping of flows on current CoAs. How these policies are set up is out of scope of MIPv6. If the HA (or more probably some other entity in the network) wants to install rules on the interface usage of a mobile node, it can use another protocol that has no reason to be part of MIPv6. Nicolas > > > A very simple analogy, there is "Binding Revocation > for IPv6 Mobility", and I think there are the same reasons > to have ""Flow Binding Revocation for IPv6 Mobility" > > In 3GPP network, operators always tend to control > the networks. > > We have some details in our draft > http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt. > > BR > Frank > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "mext" > Cc: "Jari Arkko" ; "Julien Laganier" > > Sent: Wednesday, May 20, 2009 8:04 AM > Subject: [MEXT] About the flow binding charter item > > >> Hi, >> >> There seems to be some discrepancies about the MEXT charter item >> regarding the work on flow bindings. >> Since the charter is the guide for our work, it would be important to >> clarify it, so we can have a unified interpretation of the charter. >> Please note that what it is in the charter is not cast in stone, but >> it seems to reflect previous consensus and we need good reasons to >> change it. >> >> So, the current charter item about flow bindings reads: >> >> - 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]. >> >> The first problem with this text is the use and interpretation of the >> word policy. Since the policy word may have a broad interpretation. >> it would be important to make the charter more explicit about the >> expected work. We understand that it is the WG consensus that what >> need to be exchanged is a solution for the exchange of flow binding >> rules. >> >> So, we understand that it would be more explicit to replace the usage >> of the expression Flow/binding policies exchange by Flow Binding >> rules exchange. Would that reflect with the WG interpretation? >> >> Second, the current charter item explicitly mentions that the >> proposed approach must support sending flow binding information from >> the MN to the HA and also from the HA to the MN. Moreover, the >> current charter talks about influencing not only the selection of the >> CoA but also the selection of the HA address. However, our current WG >> document does not supports sending information from the HA and it >> does not cover the possibility of influencing the HA address. So, one >> possible interpretation of the charter would be that the MN sends >> flow binding information to influence the CoA selection and the HA >> sends flow binding information to influence the HA address selection. >> Other interpretation is that both the MN and the HA send information >> regarding both the HA address and the CoA selection. >> >> So, we would like that the WG express their opinion on both items >> mentioned above: >> >> 1- whether we should replace Flow/binding policies exchange by Flow >> Binding rules exchange in the charter >> >> 2- whether the information should be sent from the MN to the HA only >> or it should also be sent from the HA to the MN and if the >> information exchanged in each direction should affect the CoA and/or >> the HA address. >> >> Regards, Julien and marcelo >> >> >> _______________________________________________ >> 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 ietf@montavont.net Wed May 20 09:35: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 7A1103A6B64 for ; Wed, 20 May 2009 09:35:41 -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 7ZX+P1QKNvxi for ; Wed, 20 May 2009 09:35:40 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 0D9833A6855 for ; Wed, 20 May 2009 09:35:39 -0700 (PDT) Received: by ewy24 with SMTP id 24so640394ewy.37 for ; Wed, 20 May 2009 09:37:14 -0700 (PDT) Received: by 10.210.58.17 with SMTP id g17mr1943823eba.65.1242837434275; Wed, 20 May 2009 09:37:14 -0700 (PDT) Received: from dhcp-salsa-i178.rennes.enst-bretagne.fr (pat39-intra.rennes.enst-bretagne.fr [192.44.77.39]) by mx.google.com with ESMTPS id 23sm2680438eya.49.2009.05.20.09.37.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 May 2009 09:37:13 -0700 (PDT) Message-Id: From: Nicolas Montavont To: marcelo bagnulo braun In-Reply-To: <4A13FFE5.2050804@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 v930.3) Date: Wed, 20 May 2009 18:37:02 +0200 References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> X-Mailer: Apple Mail (2.930.3) Cc: Julien Laganier , Jari Arkko , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 16:35:41 -0000 On May 20, 2009, at 3:04 PM, marcelo bagnulo braun wrote: > Hi, > > There seems to be some discrepancies about the MEXT charter item > regarding the work on flow bindings. > Since the charter is the guide for our work, it would be important to > clarify it, so we can have a unified interpretation of the charter. > Please note that what it is in the charter is not cast in stone, but > it seems to reflect previous consensus and we need good reasons to > change it. > > So, the current charter item about flow bindings reads: > > - 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]. > > The first problem with this text is the use and interpretation of the > word policy. Since the policy word may have a broad interpretation. > it would be important to make the charter more explicit about the > expected work. We understand that it is the WG consensus that what > need to be exchanged is a solution for the exchange of flow binding > rules. > > So, we understand that it would be more explicit to replace the usage > of the expression Flow/binding policies exchange by Flow Binding > rules exchange. Would that reflect with the WG interpretation? > > Second, the current charter item explicitly mentions that the > proposed approach must support sending flow binding information from > the MN to the HA and also from the HA to the MN. Moreover, the > current charter talks about influencing not only the selection of the > CoA but also the selection of the HA address. However, our current WG > document does not supports sending information from the HA and it > does not cover the possibility of influencing the HA address. So, one > possible interpretation of the charter would be that the MN sends > flow binding information to influence the CoA selection and the HA > sends flow binding information to influence the HA address selection. > Other interpretation is that both the MN and the HA send information > regarding both the HA address and the CoA selection. > > So, we would like that the WG express their opinion on both items > mentioned above: > > 1- whether we should replace Flow/binding policies exchange by Flow > Binding rules exchange in the charter Yes - this is a good idea > > > 2- whether the information should be sent from the MN to the HA only > or it should also be sent from the HA to the MN and if the > information exchanged in each direction should affect the CoA and/or > the HA address. Unidirectional from the MN to the HA. As far as I remember the HA address thing was the situation where your HA is multihomed and reachable through multiple addresses. As we may want to implement a selection algorithm for one end of the tunnel (the CoA), it seems natural to also provide means to select the other end of the tunnel, ie, the selection of the HA address. I am not sure though that we need a MIPv6 specific mechanism to indicate which HA address to use. Nicolas > > > Regards, Julien and marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From xiayangsong@huawei.com Wed May 20 10:11:27 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 B4E4B3A7147 for ; Wed, 20 May 2009 10:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.212, 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 vDvBK8cx2ljE for ; Wed, 20 May 2009 10:11:26 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 28F9128C3D2 for ; Wed, 20 May 2009 10:11:13 -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 <0KJY009JWD4J2P@szxga03-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 01:12:19 +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 <0KJY005Y3D4IXK@szxga03-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 01:12:18 +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 <0KJY00FBQD4GQA@szxml06-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 01:12:18 +0800 (CST) Date: Wed, 20 May 2009 12:12:13 -0500 From: Frank Xia To: Nicolas Montavont Message-id: <001001c9d96e$1fe7e190$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: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> <008f01c9d959$67dad080$3e0c7c0a@china.huawei.com> <756ABF87-88CD-4487-B437-49B05933FF93@montavont.net> Cc: Jari Arkko , Julien Laganier , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 17:11:27 -0000 Hi Nicolas Does this make sense? MN installs a flow binding to HA, and HA revokes the flow binding later because of acounting, mainteance and other reasons. BR Frank ----- Original Message ----- From: "Nicolas Montavont" To: "Frank Xia" Cc: "marcelo bagnulo braun" ; "mext" ; "Julien Laganier" ; "Jari Arkko" Sent: Wednesday, May 20, 2009 11:19 AM Subject: Re: [MEXT] About the flow binding charter item > Hi, > > On May 20, 2009, at 4:43 PM, Frank Xia wrote: > >> Hi Marcelo >> >> Texts are copied here for simplification: >>> 2- whether the information should be sent from the MN to the HA only >>> or it should also be sent from the HA to the MN and if the >>> information exchanged in each direction should affect the CoA and/or >>> the HA address. >> >> IMHO, we should define operation from HA to MN. > > I disagree: the HA has no way to know about which address is allocated to > which interface. > For me, Flow Binding in MIPv6 should only define the final mapping of > flows on current CoAs. How these policies are set up is out of scope of > MIPv6. If the HA (or more probably some other entity in the network) > wants to install rules on the interface usage of a mobile node, it can > use another protocol that has no reason to be part of MIPv6. > > Nicolas > >> >> >> A very simple analogy, there is "Binding Revocation >> for IPv6 Mobility", and I think there are the same reasons >> to have ""Flow Binding Revocation for IPv6 Mobility" >> >> In 3GPP network, operators always tend to control >> the networks. >> >> We have some details in our draft >> http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt. >> >> BR >> Frank >> >> ----- Original Message ----- From: "marcelo bagnulo braun" >> > > >> To: "mext" >> Cc: "Jari Arkko" ; "Julien Laganier" >> > > >> Sent: Wednesday, May 20, 2009 8:04 AM >> Subject: [MEXT] About the flow binding charter item >> >> >>> Hi, >>> >>> There seems to be some discrepancies about the MEXT charter item >>> regarding the work on flow bindings. >>> Since the charter is the guide for our work, it would be important to >>> clarify it, so we can have a unified interpretation of the charter. >>> Please note that what it is in the charter is not cast in stone, but >>> it seems to reflect previous consensus and we need good reasons to >>> change it. >>> >>> So, the current charter item about flow bindings reads: >>> >>> - 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]. >>> >>> The first problem with this text is the use and interpretation of the >>> word policy. Since the policy word may have a broad interpretation. >>> it would be important to make the charter more explicit about the >>> expected work. We understand that it is the WG consensus that what >>> need to be exchanged is a solution for the exchange of flow binding >>> rules. >>> >>> So, we understand that it would be more explicit to replace the usage >>> of the expression Flow/binding policies exchange by Flow Binding >>> rules exchange. Would that reflect with the WG interpretation? >>> >>> Second, the current charter item explicitly mentions that the >>> proposed approach must support sending flow binding information from >>> the MN to the HA and also from the HA to the MN. Moreover, the >>> current charter talks about influencing not only the selection of the >>> CoA but also the selection of the HA address. However, our current WG >>> document does not supports sending information from the HA and it >>> does not cover the possibility of influencing the HA address. So, one >>> possible interpretation of the charter would be that the MN sends >>> flow binding information to influence the CoA selection and the HA >>> sends flow binding information to influence the HA address selection. >>> Other interpretation is that both the MN and the HA send information >>> regarding both the HA address and the CoA selection. >>> >>> So, we would like that the WG express their opinion on both items >>> mentioned above: >>> >>> 1- whether we should replace Flow/binding policies exchange by Flow >>> Binding rules exchange in the charter >>> >>> 2- whether the information should be sent from the MN to the HA only >>> or it should also be sent from the HA to the MN and if the >>> information exchanged in each direction should affect the CoA and/or >>> the HA address. >>> >>> Regards, Julien and marcelo >>> >>> >>> _______________________________________________ >>> 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 Wed May 20 10:19: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 E37013A6D67 for ; Wed, 20 May 2009 10:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 FKe7Eobohktp for ; Wed, 20 May 2009 10:19:51 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8DA093A6CC1 for ; Wed, 20 May 2009 10:19:51 -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 <0KJY00FPCDJI34@szxga03-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 01:21:18 +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 <0KJY003YJDJIMO@szxga03-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 01:21:18 +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 <0KJY00FP9DJFQJ@szxml06-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 01:21:18 +0800 (CST) Date: Wed, 20 May 2009 12:21:14 -0500 From: Frank Xia To: Hesham Soliman , marcelo bagnulo braun , mext Message-id: <001b01c9d96f$623f6990$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: Jari Arkko , Julien Laganier Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 17:19:53 -0000 Hi Hesham Please see my inline response... BR Frank ----- Original Message ----- From: "Hesham Soliman" To: "Frank Xia" ; "marcelo bagnulo braun" ; "mext" Cc: "Julien Laganier" ; "Jari Arkko" Sent: Wednesday, May 20, 2009 11:13 AM Subject: Re: [MEXT] About the flow binding charter item > > > > On 21/05/09 12:43 AM, "Frank Xia" wrote: > >> Hi Marcelo >> >> Texts are copied here for simplification: >>> 2- whether the information should be sent from the MN to the HA only >>> or it should also be sent from the HA to the MN and if the >>> information exchanged in each direction should affect the CoA and/or >>> the HA address. >> >> IMHO, we should define operation from HA to MN. >> >> A very simple analogy, there is "Binding Revocation >> for IPv6 Mobility", and I think there are the same reasons >> to have ""Flow Binding Revocation for IPv6 Mobility" > > => There is nothing in common between a binding revocation message which > tells the MN that it needs to remove a binding maintained by the sender > (the > HA), and a message that tells the MN to use a particular address for one > or > more flows where the HA knows nothing about the conditions of the > interface > associated with such address. I don't understand how one can draw the > analogy above. In one case the HA knows everything there is to know, in > the > other the HA knows nothing. Frank=>I am sorry because I am the one draw the analogy :-) Just I said before, HA can run Flow Binding based on previous MN flow binding operation. HA initiated operation is just complimentary to your draft which is MN initiated. > > >> We have some details in our draft >> http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt. > > => It's not about creating messages, it's how they would be used. Creating > messages is easy. Frank=>You are right. However, BU/BA solution is tied to MN->HA way operation which seems to have some limitation in some scenario I tried to explain. > > Hesham > > >> >> BR >> Frank >> >> ----- Original Message ----- >> From: "marcelo bagnulo braun" >> To: "mext" >> Cc: "Jari Arkko" ; "Julien Laganier" >> >> Sent: Wednesday, May 20, 2009 8:04 AM >> Subject: [MEXT] About the flow binding charter item >> >> >>> Hi, >>> >>> There seems to be some discrepancies about the MEXT charter item >>> regarding the work on flow bindings. >>> Since the charter is the guide for our work, it would be important to >>> clarify it, so we can have a unified interpretation of the charter. >>> Please note that what it is in the charter is not cast in stone, but >>> it seems to reflect previous consensus and we need good reasons to >>> change it. >>> >>> So, the current charter item about flow bindings reads: >>> >>> - 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]. >>> >>> The first problem with this text is the use and interpretation of the >>> word policy. Since the policy word may have a broad interpretation. >>> it would be important to make the charter more explicit about the >>> expected work. We understand that it is the WG consensus that what >>> need to be exchanged is a solution for the exchange of flow binding >>> rules. >>> >>> So, we understand that it would be more explicit to replace the usage >>> of the expression Flow/binding policies exchange by Flow Binding >>> rules exchange. Would that reflect with the WG interpretation? >>> >>> Second, the current charter item explicitly mentions that the >>> proposed approach must support sending flow binding information from >>> the MN to the HA and also from the HA to the MN. Moreover, the >>> current charter talks about influencing not only the selection of the >>> CoA but also the selection of the HA address. However, our current WG >>> document does not supports sending information from the HA and it >>> does not cover the possibility of influencing the HA address. So, one >>> possible interpretation of the charter would be that the MN sends >>> flow binding information to influence the CoA selection and the HA >>> sends flow binding information to influence the HA address selection. >>> Other interpretation is that both the MN and the HA send information >>> regarding both the HA address and the CoA selection. >>> >>> So, we would like that the WG express their opinion on both items >>> mentioned above: >>> >>> 1- whether we should replace Flow/binding policies exchange by Flow >>> Binding rules exchange in the charter >>> >>> 2- whether the information should be sent from the MN to the HA only >>> or it should also be sent from the HA to the MN and if the >>> information exchanged in each direction should affect the CoA and/or >>> the HA address. >>> >>> Regards, Julien and marcelo >>> >>> >>> _______________________________________________ >>> 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 vijay@wichorus.com Wed May 20 15: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 7E45F3A6C57 for ; Wed, 20 May 2009 15:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.768 X-Spam-Level: * X-Spam-Status: No, score=1.768 tagged_above=-999 required=5 tests=[AWL=4.367, 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 Xe2E0JbbP-gx for ; Wed, 20 May 2009 15:00:47 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id A19EE3A6ED0 for ; Wed, 20 May 2009 15:00:46 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id tr0z1b00E16AWCUA9y2Rwl; Wed, 20 May 2009 22:02:25 +0000 Received: from [10.166.254.150] ([38.96.10.141]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id ty1w1b00B32awWW8Sy24Wt; Wed, 20 May 2009 22:02:22 +0000 Message-ID: <4A147DD0.1030109@wichorus.com> Date: Wed, 20 May 2009 15:01:52 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Arnaud Ebalard References: <87eiusx1s6.fsf@small.ssi.corp> <2D50B653-C7B4-4FDF-93A0-D7F0AE2BEEDC@gmail.com> <87ws8cnhrg.fsf@small.ssi.corp> In-Reply-To: <87ws8cnhrg.fsf@small.ssi.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF MEXT WG ML Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals 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, 20 May 2009 22:00:56 -0000 Hi Arnaud, Arnaud Ebalard wrote: > The last point regarding the reuse of K bit was still open so I took a > new look at what is in the draft. I'd like to clarify the expected > behavior for the common case. > > The idea developed in section 9.1 of the draft is that the MN sends a > BU with K bit set *and* a single BID mobility option to update the CoA > which must be used by IKE. The HA receiving that BU will inform the IKE > daemon on its side with the CoA with the BID. > > The thing is that if the IKE module on the MN supports movement, K bit > will be set in all BU. It would not make sense ("MCoA keeps backward > compatible with 3775") but it is probably worth asking the question > before going further: does MCoA draft change that behavior? With MCoA draft, the 'K' bit is set in a BU only if there is a change in the "primary CoA", i.e., the CoA with which the IKEv2 SA was created. All other BUs sent by the mobile node can have the 'K' bit unset. Even in RFC 3775, a mobile node can clear the 'K' bit in a BU sent for a binding refresh when there is no change in CoA. When the CoA changes, the MN can set the 'K' bit in the BU sent to update the CoA. > Now, let's consider a MN whose IKE module supports movement (its HA > too). It will have K-bit set in all its BU. Let's say the MN currently > has two CoA on different interfaces: CoA1 and CoA2 registered with its > HA. Each one is associated with a given BID. Let's consider CoA1 is > currently used for IKE traffic to the HA. Now, due to a handover, the MN > configures a new address instead of CoA2. CoA1 had not been modified so > the MN does not have to request an update of IKE address to the HA. But > the MN needs to warn its HA about the address change. It cannot send a > BU with K bit set and only the BID mobility option with the updated CoA2 > value. How is this handled? It would send a BU with the 'K' bit unset, CoA2 information and the BID associated with CoA2. It can also include CoA1 information and the BID associated with CoA1 in the BU. From the beginning our goal was to avoid creating a new mechanism to update the care-of address information in the IKEv2 and IPsec SAs. We are trying to re-use what is there in RFC 3775. Vijay From ryuji.wakikawa@gmail.com Wed May 20 15:55: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 2B3783A6ED6 for ; Wed, 20 May 2009 15:55:12 -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 58+NxWvI1+x8 for ; Wed, 20 May 2009 15:55:11 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 322063A6A44 for ; Wed, 20 May 2009 15:55:10 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so207477rvb.49 for ; Wed, 20 May 2009 15:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=VZl7A/ioWPMxA6zzhwUvHr2og/Ns8Y/yAY/VHmu2bwo=; b=UzZ7x5a3OsuwUaFH24r/mkE6Nya1isDxD7ZvUqml9om4lzLs4QnXsaE8MR//S5Wkum /5FODp/lwlRYSev37sjABIFFuNSbwD2H4BTWQKUb9kEpl7DgpIRYw0pskmapdtx7Dpeb Zng3uFlB5wMjIbJSDTKsjB/dKdDTJNLXwE+VY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=pO40OVDq0v8QajIj8CEcVo3Hpi1q9Hwtzn8vRDgrj+iw9TNb6fRwaFsH3hMlN/B2y+ DA5JBEOteRq0NMHUbbqyA6n+tJx7pq206Rol5dvZ+n+JXxtV6vM6SqZQRZklh6YkWjmA TH3NeMqLUWtL2nswnFZ9BsXHtOAWbjnQ+TkAQ= Received: by 10.140.201.8 with SMTP id y8mr849897rvf.160.1242860206763; Wed, 20 May 2009 15:56:46 -0700 (PDT) Received: from ?192.168.110.115? ([206.132.173.18]) by mx.google.com with ESMTPS id k37sm5018331rvb.18.2009.05.20.15.56.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 May 2009 15:56:45 -0700 (PDT) From: Ryuji Wakikawa To: marcelo bagnulo braun In-Reply-To: <4A13FFE5.2050804@it.uc3m.es> References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> Message-Id: <43A962C8-9072-423F-B3FC-CBDAC6627407@gmail.com> 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: Wed, 20 May 2009 15:56:41 -0700 X-Mailer: Apple Mail (2.935.3) Cc: Julien Laganier , Jari Arkko , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 22:55:12 -0000 Hi Marcelo, On 2009/05/20, at 6:04, marcelo bagnulo braun wrote: > Hi, > > There seems to be some discrepancies about the MEXT charter item > regarding the work on flow bindings. > Since the charter is the guide for our work, it would be important to > clarify it, so we can have a unified interpretation of the charter. > Please note that what it is in the charter is not cast in stone, but > it seems to reflect previous consensus and we need good reasons to > change it. > > So, the current charter item about flow bindings reads: > > - 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]. > > The first problem with this text is the use and interpretation of the > word policy. Since the policy word may have a broad interpretation. > it would be important to make the charter more explicit about the > expected work. We understand that it is the WG consensus that what > need to be exchanged is a solution for the exchange of flow binding > rules. > > So, we understand that it would be more explicit to replace the usage > of the expression Flow/binding policies exchange by Flow Binding > rules exchange. Would that reflect with the WG interpretation? > > Second, the current charter item explicitly mentions that the > proposed approach must support sending flow binding information from > the MN to the HA and also from the HA to the MN. Moreover, the > current charter talks about influencing not only the selection of the > CoA but also the selection of the HA address. However, our current WG > document does not supports sending information from the HA and it > does not cover the possibility of influencing the HA address. So, one > possible interpretation of the charter would be that the MN sends > flow binding information to influence the CoA selection and the HA > sends flow binding information to influence the HA address selection. > Other interpretation is that both the MN and the HA send information > regarding both the HA address and the CoA selection. > > So, we would like that the WG express their opinion on both items > mentioned above: > > 1- whether we should replace Flow/binding policies exchange by Flow > Binding rules exchange in the charter agree > 2- whether the information should be sent from the MN to the HA only > or it should also be sent from the HA to the MN and if the > information exchanged in each direction should affect the CoA and/or > the HA address. I want to support both direction. There is a case where an operator wants to install rules to MN. The FID option is a mobility option and should be carried by other MH message. Ex. If FID option can be carried in generic notification message, we can easily support both directions. I don't see much difficulty to support both direction. We just relax to use other MH message to carry FID options. btw, There is other reason that I want to decouple FID from BU. - Updating two different status (binding and flow rules) by single message can optimize the # of signaling in some sense. However, even if only one of status change, the other status must be updated, too. Even though binding information is unchanged, MN need to send BU to refresh the rules. If MN changes the rules frequently, HA overhead might be increased. regards, ryuji > > > Regards, Julien and marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Wed May 20 16:07: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 1F3B43A6F07 for ; Wed, 20 May 2009 16:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 E1Wk4OROreds for ; Wed, 20 May 2009 16:07:04 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id D3E623A698C for ; Wed, 20 May 2009 16:07:03 -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 1M6utm-00065X-Tg; Thu, 21 May 2009 09:08:35 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 21 May 2009 09:08:26 +1000 From: Hesham Soliman To: Frank Xia , marcelo bagnulo braun , mext Message-ID: Thread-Topic: [MEXT] About the flow binding charter item Thread-Index: AcnZn+FRbgYekV+vp0e6fYw3j1P5oQ== In-Reply-To: <001b01c9d96f$623f6990$3e0c7c0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Jari Arkko , Julien Laganier Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 23:07:05 -0000 >> => There is nothing in common between a binding revocation message which >> tells the MN that it needs to remove a binding maintained by the sender >> (the >> HA), and a message that tells the MN to use a particular address for one >> or >> more flows where the HA knows nothing about the conditions of the >> interface >> associated with such address. I don't understand how one can draw the >> analogy above. In one case the HA knows everything there is to know, in >> the >> other the HA knows nothing. > > Frank=>I am sorry because I am the one draw the analogy :-) > Just I said before, HA can run Flow Binding based on > previous MN flow binding operation. HA initiated operation > is just complimentary to your draft which is MN initiated. => But in the email you're referring to you were talking about the HA revoking a flow binding. That's already possible today with the binding revocation message. Rejecting/revoking something is different from initiating the installation of a filter rule. Hesham > >> >> >>> We have some details in our draft >>> http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt. >> >> => It's not about creating messages, it's how they would be used. Creating >> messages is easy. > Frank=>You are right. However, BU/BA solution is tied to > MN->HA way operation which seems to have some limitation > in some scenario I tried to explain. > >> >> Hesham >> >> >>> >>> BR >>> Frank >>> >>> ----- Original Message ----- >>> From: "marcelo bagnulo braun" >>> To: "mext" >>> Cc: "Jari Arkko" ; "Julien Laganier" >>> >>> Sent: Wednesday, May 20, 2009 8:04 AM >>> Subject: [MEXT] About the flow binding charter item >>> >>> >>>> Hi, >>>> >>>> There seems to be some discrepancies about the MEXT charter item >>>> regarding the work on flow bindings. >>>> Since the charter is the guide for our work, it would be important to >>>> clarify it, so we can have a unified interpretation of the charter. >>>> Please note that what it is in the charter is not cast in stone, but >>>> it seems to reflect previous consensus and we need good reasons to >>>> change it. >>>> >>>> So, the current charter item about flow bindings reads: >>>> >>>> - 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]. >>>> >>>> The first problem with this text is the use and interpretation of the >>>> word policy. Since the policy word may have a broad interpretation. >>>> it would be important to make the charter more explicit about the >>>> expected work. We understand that it is the WG consensus that what >>>> need to be exchanged is a solution for the exchange of flow binding >>>> rules. >>>> >>>> So, we understand that it would be more explicit to replace the usage >>>> of the expression Flow/binding policies exchange by Flow Binding >>>> rules exchange. Would that reflect with the WG interpretation? >>>> >>>> Second, the current charter item explicitly mentions that the >>>> proposed approach must support sending flow binding information from >>>> the MN to the HA and also from the HA to the MN. Moreover, the >>>> current charter talks about influencing not only the selection of the >>>> CoA but also the selection of the HA address. However, our current WG >>>> document does not supports sending information from the HA and it >>>> does not cover the possibility of influencing the HA address. So, one >>>> possible interpretation of the charter would be that the MN sends >>>> flow binding information to influence the CoA selection and the HA >>>> sends flow binding information to influence the HA address selection. >>>> Other interpretation is that both the MN and the HA send information >>>> regarding both the HA address and the CoA selection. >>>> >>>> So, we would like that the WG express their opinion on both items >>>> mentioned above: >>>> >>>> 1- whether we should replace Flow/binding policies exchange by Flow >>>> Binding rules exchange in the charter >>>> >>>> 2- whether the information should be sent from the MN to the HA only >>>> or it should also be sent from the HA to the MN and if the >>>> information exchanged in each direction should affect the CoA and/or >>>> the HA address. >>>> >>>> Regards, Julien and marcelo >>>> >>>> >>>> _______________________________________________ >>>> 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 Wed May 20 16:18: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 706DB3A6D49 for ; Wed, 20 May 2009 16:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.860, 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 iLp+o40Fg8tk for ; Wed, 20 May 2009 16:18:08 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 1BB293A6EF4 for ; Wed, 20 May 2009 16:18:08 -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 <0KJY002SQU4WYZ@szxga02-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 07:19:44 +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 <0KJY0022PU4WD6@szxga02-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 07:19:44 +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 <0KJY00A6DU4T6Q@szxml04-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 07:19:43 +0800 (CST) Date: Wed, 20 May 2009 18:19:40 -0500 From: Frank Xia To: Ryuji Wakikawa , marcelo bagnulo braun Message-id: <007501c9d9a1$75226440$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: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> <43A962C8-9072-423F-B3FC-CBDAC6627407@gmail.com> Cc: Jari Arkko , Julien Laganier , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 23:18:09 -0000 Hi Ryuji Here is my comment on your comments Full two-way flow binding operation is not necessary. E.g, it seems to be unnecessary for CN to initiate flow binding operation to MN BR Frank ----- Original Message ----- From: "Ryuji Wakikawa" To: "marcelo bagnulo braun" Cc: "Julien Laganier" ; "Jari Arkko" ; "mext" Sent: Wednesday, May 20, 2009 5:56 PM Subject: Re: [MEXT] About the flow binding charter item > Hi Marcelo, > > On 2009/05/20, at 6:04, marcelo bagnulo braun wrote: > >> Hi, >> >> There seems to be some discrepancies about the MEXT charter item >> regarding the work on flow bindings. >> Since the charter is the guide for our work, it would be important to >> clarify it, so we can have a unified interpretation of the charter. >> Please note that what it is in the charter is not cast in stone, but >> it seems to reflect previous consensus and we need good reasons to >> change it. >> >> So, the current charter item about flow bindings reads: >> >> - 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]. >> >> The first problem with this text is the use and interpretation of the >> word policy. Since the policy word may have a broad interpretation. >> it would be important to make the charter more explicit about the >> expected work. We understand that it is the WG consensus that what >> need to be exchanged is a solution for the exchange of flow binding >> rules. >> >> So, we understand that it would be more explicit to replace the usage >> of the expression Flow/binding policies exchange by Flow Binding >> rules exchange. Would that reflect with the WG interpretation? >> >> Second, the current charter item explicitly mentions that the >> proposed approach must support sending flow binding information from >> the MN to the HA and also from the HA to the MN. Moreover, the >> current charter talks about influencing not only the selection of the >> CoA but also the selection of the HA address. However, our current WG >> document does not supports sending information from the HA and it >> does not cover the possibility of influencing the HA address. So, one >> possible interpretation of the charter would be that the MN sends >> flow binding information to influence the CoA selection and the HA >> sends flow binding information to influence the HA address selection. >> Other interpretation is that both the MN and the HA send information >> regarding both the HA address and the CoA selection. >> >> So, we would like that the WG express their opinion on both items >> mentioned above: >> >> 1- whether we should replace Flow/binding policies exchange by Flow >> Binding rules exchange in the charter > > agree > >> 2- whether the information should be sent from the MN to the HA only >> or it should also be sent from the HA to the MN and if the >> information exchanged in each direction should affect the CoA and/or >> the HA address. > > I want to support both direction. > There is a case where an operator wants to install rules to MN. > > The FID option is a mobility option and should be carried by other MH > message. > Ex. If FID option can be carried in generic notification message, we can > easily support both directions. > I don't see much difficulty to support both direction. We just relax to > use other MH message to carry FID options. > > btw, There is other reason that I want to decouple FID from BU. > > - Updating two different status (binding and flow rules) by single > message can optimize the # of signaling in some sense. > However, even if only one of status change, the other status must be > updated, too. > Even though binding information is unchanged, MN need to send BU to > refresh the rules. > If MN changes the rules frequently, HA overhead might be increased. > > regards, > ryuji > > > > > > > > >> >> >> Regards, Julien and marcelo >> >> >> _______________________________________________ >> 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 ryuji.wakikawa@gmail.com Wed May 20 16:20: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 C424A28C0F1 for ; Wed, 20 May 2009 16:20:36 -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 y+GibHKxwkF4 for ; Wed, 20 May 2009 16:20:35 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id BA2DB28C0F6 for ; Wed, 20 May 2009 16:20:35 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so209977rvb.49 for ; Wed, 20 May 2009 16:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :x-priority:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; bh=0g2xU2EWK7zPaox8KBh5oVMINiPUuIIItdmHBaHYgiU=; b=WhS9iuLLPVY5rzU+0+hsqreDG0kBNQ8/KB5Diy/zcETgIeuYpfKlgOhwdXcG9MG+oN TP6IbNFUH5frbGWMkzfXQhlXdRFOepBdjwCmzUfrgokiGCoXwjcXuPfCNFlHH7p9G3Jj 747Y+8XPyEKE/66rJbb94UTDRPZ0fDBCD/1aQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:x-priority:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc :x-mailer; b=POq64WGN9fgtCZw+a6vFE92PXMTM1PSyYE6epJr/DOS8QkMHEWprdTu3KQ2Zzyi2Hj ulplok9+MLOr04TL4i2C+99fBGURrRINEbgwXtki2lqtGkLRE0W3IZrGL7TVfOO7l6OS uItj/pm//WzuYtyy3Q3EzCE8PMMI+l44L687s= Received: by 10.141.12.15 with SMTP id p15mr858062rvi.281.1242861731436; Wed, 20 May 2009 16:22:11 -0700 (PDT) Received: from ?192.168.110.115? ([206.132.173.18]) by mx.google.com with ESMTPS id b8sm4861734rvf.4.2009.05.20.16.22.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 May 2009 16:22:10 -0700 (PDT) From: Ryuji Wakikawa To: Frank Xia In-Reply-To: <007501c9d9a1$75226440$3e0c7c0a@china.huawei.com> X-Priority: 3 References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> <43A962C8-9072-423F-B3FC-CBDAC6627407@gmail.com> <007501c9d9a1$75226440$3e0c7c0a@china.huawei.com> Message-Id: <53E219F0-EF97-4F81-819D-4BA6BEF440AA@gmail.com> 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: Wed, 20 May 2009 16:22:07 -0700 X-Mailer: Apple Mail (2.935.3) Cc: Jari Arkko , Julien Laganier , mext Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 23:20:36 -0000 Hi Frank I meant flow binding operation from HA to MN. ryuji On 2009/05/20, at 16:19, Frank Xia wrote: > Hi Ryuji > > Here is my comment on your comments > > Full two-way flow binding operation is not necessary. > E.g, it seems to be unnecessary for CN to initiate flow > binding operation to MN > > BR > Frank > > ----- Original Message ----- From: "Ryuji Wakikawa" > > To: "marcelo bagnulo braun" > Cc: "Julien Laganier" ; "Jari > Arkko" ; "mext" > Sent: Wednesday, May 20, 2009 5:56 PM > Subject: Re: [MEXT] About the flow binding charter item > > >> Hi Marcelo, >> >> On 2009/05/20, at 6:04, marcelo bagnulo braun wrote: >> >>> Hi, >>> >>> There seems to be some discrepancies about the MEXT charter item >>> regarding the work on flow bindings. >>> Since the charter is the guide for our work, it would be important >>> to >>> clarify it, so we can have a unified interpretation of the charter. >>> Please note that what it is in the charter is not cast in stone, but >>> it seems to reflect previous consensus and we need good reasons to >>> change it. >>> >>> So, the current charter item about flow bindings reads: >>> >>> - 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]. >>> >>> The first problem with this text is the use and interpretation of >>> the >>> word policy. Since the policy word may have a broad interpretation. >>> it would be important to make the charter more explicit about the >>> expected work. We understand that it is the WG consensus that what >>> need to be exchanged is a solution for the exchange of flow binding >>> rules. >>> >>> So, we understand that it would be more explicit to replace the >>> usage >>> of the expression Flow/binding policies exchange by Flow Binding >>> rules exchange. Would that reflect with the WG interpretation? >>> >>> Second, the current charter item explicitly mentions that the >>> proposed approach must support sending flow binding information from >>> the MN to the HA and also from the HA to the MN. Moreover, the >>> current charter talks about influencing not only the selection of >>> the >>> CoA but also the selection of the HA address. However, our current >>> WG >>> document does not supports sending information from the HA and it >>> does not cover the possibility of influencing the HA address. So, >>> one >>> possible interpretation of the charter would be that the MN sends >>> flow binding information to influence the CoA selection and the HA >>> sends flow binding information to influence the HA address >>> selection. >>> Other interpretation is that both the MN and the HA send information >>> regarding both the HA address and the CoA selection. >>> >>> So, we would like that the WG express their opinion on both items >>> mentioned above: >>> >>> 1- whether we should replace Flow/binding policies exchange by Flow >>> Binding rules exchange in the charter >> >> agree >> >>> 2- whether the information should be sent from the MN to the HA only >>> or it should also be sent from the HA to the MN and if the >>> information exchanged in each direction should affect the CoA and/or >>> the HA address. >> >> I want to support both direction. >> There is a case where an operator wants to install rules to MN. >> >> The FID option is a mobility option and should be carried by other >> MH message. >> Ex. If FID option can be carried in generic notification message, >> we can easily support both directions. >> I don't see much difficulty to support both direction. We just >> relax to use other MH message to carry FID options. >> >> btw, There is other reason that I want to decouple FID from BU. >> >> - Updating two different status (binding and flow rules) by single >> message can optimize the # of signaling in some sense. >> However, even if only one of status change, the other status must >> be updated, too. >> Even though binding information is unchanged, MN need to send BU >> to refresh the rules. >> If MN changes the rules frequently, HA overhead might be increased. >> >> regards, >> ryuji >> >> >> >> >> >> >> >> >>> >>> >>> Regards, Julien and marcelo >>> >>> >>> _______________________________________________ >>> 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 Wed May 20 16:25:03 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 CFE013A6C0C for ; Wed, 20 May 2009 16:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 sdd+R0Pe2Mdz for ; Wed, 20 May 2009 16:25:02 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 98F563A6858 for ; Wed, 20 May 2009 16:25:02 -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 <0KJY006XDUG5ES@szxga04-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 07:26:30 +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 <0KJY0021XUG5HX@szxga04-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 07:26:29 +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 <0KJY00AP9UG36Q@szxml04-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 07:26:29 +0800 (CST) Date: Wed, 20 May 2009 18:26:26 -0500 From: Frank Xia To: Hesham Soliman , marcelo bagnulo braun , mext Message-id: <007c01c9d9a2$67085b20$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: Jari Arkko , Julien Laganier Subject: Re: [MEXT] About the flow binding charter item 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, 20 May 2009 23:25:03 -0000 Hi Hesham Please check my reply.. BR Frank ----- Original Message ----- From: "Hesham Soliman" To: "Frank Xia" ; "marcelo bagnulo braun" ; "mext" Cc: "Julien Laganier" ; "Jari Arkko" Sent: Wednesday, May 20, 2009 6:08 PM Subject: Re: [MEXT] About the flow binding charter item > > > >>> => There is nothing in common between a binding revocation message which >>> tells the MN that it needs to remove a binding maintained by the sender >>> (the >>> HA), and a message that tells the MN to use a particular address for one >>> or >>> more flows where the HA knows nothing about the conditions of the >>> interface >>> associated with such address. I don't understand how one can draw the >>> analogy above. In one case the HA knows everything there is to know, in >>> the >>> other the HA knows nothing. >> >> Frank=>I am sorry because I am the one draw the analogy :-) >> Just I said before, HA can run Flow Binding based on >> previous MN flow binding operation. HA initiated operation >> is just complimentary to your draft which is MN initiated. > > => But in the email you're referring to you were talking about the HA > revoking a flow binding. That's already possible today with the binding > revocation message. Rejecting/revoking something is different from > initiating the installation of a filter rule. Frank=>Binding revocation message does not support flow operation. Please check. Flow binding revocation is a typical use case I figured out. Surely, I will investigate more on other use cases regarding installation of a rule. > > Hesham > >> >>> >>> >>>> We have some details in our draft >>>> http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt. >>> >>> => It's not about creating messages, it's how they would be used. >>> Creating >>> messages is easy. >> Frank=>You are right. However, BU/BA solution is tied to >> MN->HA way operation which seems to have some limitation >> in some scenario I tried to explain. >> >>> >>> Hesham >>> >>> >>>> >>>> BR >>>> Frank >>>> >>>> ----- Original Message ----- >>>> From: "marcelo bagnulo braun" >>>> To: "mext" >>>> Cc: "Jari Arkko" ; "Julien Laganier" >>>> >>>> Sent: Wednesday, May 20, 2009 8:04 AM >>>> Subject: [MEXT] About the flow binding charter item >>>> >>>> >>>>> Hi, >>>>> >>>>> There seems to be some discrepancies about the MEXT charter item >>>>> regarding the work on flow bindings. >>>>> Since the charter is the guide for our work, it would be important to >>>>> clarify it, so we can have a unified interpretation of the charter. >>>>> Please note that what it is in the charter is not cast in stone, but >>>>> it seems to reflect previous consensus and we need good reasons to >>>>> change it. >>>>> >>>>> So, the current charter item about flow bindings reads: >>>>> >>>>> - 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]. >>>>> >>>>> The first problem with this text is the use and interpretation of the >>>>> word policy. Since the policy word may have a broad interpretation. >>>>> it would be important to make the charter more explicit about the >>>>> expected work. We understand that it is the WG consensus that what >>>>> need to be exchanged is a solution for the exchange of flow binding >>>>> rules. >>>>> >>>>> So, we understand that it would be more explicit to replace the usage >>>>> of the expression Flow/binding policies exchange by Flow Binding >>>>> rules exchange. Would that reflect with the WG interpretation? >>>>> >>>>> Second, the current charter item explicitly mentions that the >>>>> proposed approach must support sending flow binding information from >>>>> the MN to the HA and also from the HA to the MN. Moreover, the >>>>> current charter talks about influencing not only the selection of the >>>>> CoA but also the selection of the HA address. However, our current WG >>>>> document does not supports sending information from the HA and it >>>>> does not cover the possibility of influencing the HA address. So, one >>>>> possible interpretation of the charter would be that the MN sends >>>>> flow binding information to influence the CoA selection and the HA >>>>> sends flow binding information to influence the HA address selection. >>>>> Other interpretation is that both the MN and the HA send information >>>>> regarding both the HA address and the CoA selection. >>>>> >>>>> So, we would like that the WG express their opinion on both items >>>>> mentioned above: >>>>> >>>>> 1- whether we should replace Flow/binding policies exchange by Flow >>>>> Binding rules exchange in the charter >>>>> >>>>> 2- whether the information should be sent from the MN to the HA only >>>>> or it should also be sent from the HA to the MN and if the >>>>> information exchanged in each direction should affect the CoA and/or >>>>> the HA address. >>>>> >>>>> Regards, Julien and marcelo >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 May 20 17:25: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 12BB63A6CCA for ; Wed, 20 May 2009 17:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.984, 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 cR5nzjnvckLm for ; Wed, 20 May 2009 17:25: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 893193A69BD for ; Wed, 20 May 2009 17:25:30 -0700 (PDT) Received: from [115.130.1.62] by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1M6w7i-0001Fc-Gb; Thu, 21 May 2009 10:27:04 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 21 May 2009 10:26:49 +1000 From: Hesham Soliman To: Frank Xia , marcelo bagnulo braun , mext Message-ID: Thread-Topic: [MEXT] About the flow binding charter item Thread-Index: AcnZqtSGv0bMsN6fG0mwMTK7YzrSUA== In-Reply-To: <007c01c9d9a2$67085b20$3e0c7c0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Jari Arkko , Julien Laganier Subject: Re: [MEXT] About the flow binding charter item 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, 21 May 2009 00:25:33 -0000 >> => But in the email you're referring to you were talking about the HA >> revoking a flow binding. That's already possible today with the binding >> revocation message. Rejecting/revoking something is different from >> initiating the installation of a filter rule. > Frank=>Binding revocation message does not support > flow operation. Please check. => It doesn't matter, you can easily extend it if that's what you want to do. My point is that this is different from installing filters in the MN by the HA. Hesham Flow binding revocation is > a typical use case I figured out. Surely, I will investigate > more on other use cases regarding installation of a rule. > >> >> Hesham >> >>> >>>> >>>> >>>>> We have some details in our draft >>>>> http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt. >>>> >>>> => It's not about creating messages, it's how they would be used. >>>> Creating >>>> messages is easy. >>> Frank=>You are right. However, BU/BA solution is tied to >>> MN->HA way operation which seems to have some limitation >>> in some scenario I tried to explain. >>> >>>> >>>> Hesham >>>> >>>> >>>>> >>>>> BR >>>>> Frank >>>>> >>>>> ----- Original Message ----- >>>>> From: "marcelo bagnulo braun" >>>>> To: "mext" >>>>> Cc: "Jari Arkko" ; "Julien Laganier" >>>>> >>>>> Sent: Wednesday, May 20, 2009 8:04 AM >>>>> Subject: [MEXT] About the flow binding charter item >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> There seems to be some discrepancies about the MEXT charter item >>>>>> regarding the work on flow bindings. >>>>>> Since the charter is the guide for our work, it would be important to >>>>>> clarify it, so we can have a unified interpretation of the charter. >>>>>> Please note that what it is in the charter is not cast in stone, but >>>>>> it seems to reflect previous consensus and we need good reasons to >>>>>> change it. >>>>>> >>>>>> So, the current charter item about flow bindings reads: >>>>>> >>>>>> - 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]. >>>>>> >>>>>> The first problem with this text is the use and interpretation of the >>>>>> word policy. Since the policy word may have a broad interpretation. >>>>>> it would be important to make the charter more explicit about the >>>>>> expected work. We understand that it is the WG consensus that what >>>>>> need to be exchanged is a solution for the exchange of flow binding >>>>>> rules. >>>>>> >>>>>> So, we understand that it would be more explicit to replace the usage >>>>>> of the expression Flow/binding policies exchange by Flow Binding >>>>>> rules exchange. Would that reflect with the WG interpretation? >>>>>> >>>>>> Second, the current charter item explicitly mentions that the >>>>>> proposed approach must support sending flow binding information from >>>>>> the MN to the HA and also from the HA to the MN. Moreover, the >>>>>> current charter talks about influencing not only the selection of the >>>>>> CoA but also the selection of the HA address. However, our current WG >>>>>> document does not supports sending information from the HA and it >>>>>> does not cover the possibility of influencing the HA address. So, one >>>>>> possible interpretation of the charter would be that the MN sends >>>>>> flow binding information to influence the CoA selection and the HA >>>>>> sends flow binding information to influence the HA address selection. >>>>>> Other interpretation is that both the MN and the HA send information >>>>>> regarding both the HA address and the CoA selection. >>>>>> >>>>>> So, we would like that the WG express their opinion on both items >>>>>> mentioned above: >>>>>> >>>>>> 1- whether we should replace Flow/binding policies exchange by Flow >>>>>> Binding rules exchange in the charter >>>>>> >>>>>> 2- whether the information should be sent from the MN to the HA only >>>>>> or it should also be sent from the HA to the MN and if the >>>>>> information exchanged in each direction should affect the CoA and/or >>>>>> the HA address. >>>>>> >>>>>> Regards, Julien and marcelo >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 w52006@huawei.com Wed May 20 18:02: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 6B6103A6946 for ; Wed, 20 May 2009 18:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 xlAW3RtW3fAJ for ; Wed, 20 May 2009 18:02:34 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 9A2233A6839 for ; Wed, 20 May 2009 18:02:34 -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 <0KJY00IXWYYO0K@szxga03-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 09:04:00 +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 <0KJY00HCSYYOW6@szxga03-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 09:04:00 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY00G0LYYN5O@szxml06-in.huawei.com> for mext@ietf.org; Thu, 21 May 2009 09:04:00 +0800 (CST) Date: Thu, 21 May 2009 09:03:59 +0800 From: Yungui Wang In-reply-to: <4A13FFE5.2050804@it.uc3m.es> To: 'marcelo bagnulo braun' , 'mext' Message-id: <004701c9d9b0$06a68e60$150ca40a@china.huawei.com> Organization: huawei 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: AcnZS9LZ8Va/nGdvS8uGE4tofXqUfAAYW3BQ Cc: 'Julien Laganier' , 'Jari Arkko' Subject: Re: [MEXT] About the flow binding charter item 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, 21 May 2009 01:02:35 -0000 Hello > So, we would like that the WG express their opinion on both items > mentioned above: > > 1- whether we should replace Flow/binding policies exchange by Flow > Binding rules exchange in the charter Agree. > > 2- whether the information should be sent from the MN to the HA only > or it should also be sent from the HA to the MN Support two-direction. I do think it is useful for HA initiating flow binding. For example, when HA receives indication of link layer overload/failure, it can initiate flow binding to handoff MN's flows from one CoA to another. B.R. Yungui > and if the > information exchanged in each direction should affect the CoA and/or > the HA address. > > Regards, Julien and marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From arno@natisbad.org Thu May 21 02:30: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 30CAB3A6C66 for ; Thu, 21 May 2009 02:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 NsDe6z9TeZD8 for ; Thu, 21 May 2009 02:30:09 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 3E0AC28C0CF for ; Thu, 21 May 2009 02:30:09 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M74cm-0008JV-Bl; Thu, 21 May 2009 11:31:40 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Vijay Devarapalli References: <87eiusx1s6.fsf@small.ssi.corp> <2D50B653-C7B4-4FDF-93A0-D7F0AE2BEEDC@gmail.com> <87ws8cnhrg.fsf@small.ssi.corp> <4A147DD0.1030109@wichorus.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090521:mext@ietf.org::wFO7XaxC54W762L4:00000FEL X-Hashcash: 1:20:090521:tsirtsis@googlemail.com::YvcArqZkFyVPznMX:000000000000000000000000000000000000000O+f X-Hashcash: 1:20:090521:marcelo@it.uc3m.es::WFq2p4Byl4E9fycv:00000000000000000000000000000000000000000001yZO X-Hashcash: 1:20:090521:ryuji.wakikawa@gmail.com::BZ+LIXLk5+eOg/Ba:00000000000000000000000000000000000002t76 X-Hashcash: 1:20:090521:vijay@wichorus.com::RdI16laqYweHl9od:00000000000000000000000000000000000000000006zvV X-Hashcash: 1:20:090521:hesham@elevatemobile.com::E9k2j0q3nduJW4zi:00000000000000000000000000000000000007qw+ X-Hashcash: 1:20:090521:thierry.ernst@inria.fr::M9aDjROsViEyUA2M:0000000000000000000000000000000000000007x3U Date: Thu, 21 May 2009 11:32:15 +0200 Message-ID: <87octmpzs0.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IETF MEXT WG ML Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals 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, 21 May 2009 09:30:10 -0000 Hi Vijay, Vijay Devarapalli writes: > Arnaud Ebalard wrote: > >> The last point regarding the reuse of K bit was still open so I took a >> new look at what is in the draft. I'd like to clarify the expected >> behavior for the common case. >> >> The idea developed in section 9.1 of the draft is that the MN sends a >> BU with K bit set *and* a single BID mobility option to update the CoA >> which must be used by IKE. The HA receiving that BU will inform the IKE >> daemon on its side with the CoA with the BID. >> >> The thing is that if the IKE module on the MN supports movement, K bit >> will be set in all BU. It would not make sense ("MCoA keeps backward >> compatible with 3775") but it is probably worth asking the question >> before going further: does MCoA draft change that behavior? > > With MCoA draft, the 'K' bit is set in a BU only if there is a change > in the "primary CoA", i.e., the CoA with which the IKEv2 SA was > created. All other BUs sent by the mobile node can have the 'K' bit > unset. At least, this clarifies the expectations of MCoA draft on the topic. IMHO, this would have been better to state that explicitly but considering previous discussions, I guess it is too late now :-b > Even in RFC 3775, a mobile node can clear the 'K' bit in a BU sent for > a binding refresh when there is no change in CoA. When the CoA > changes, the MN can set the 'K' bit in the BU sent to update the CoA. Rereading Section 10.3.1 of RFC 3775, the binding refresh case when there is no change of CoA does not exist. As usual, the content of a new BU basically replace the content of the previous one in the BCE. In section 10.3.1, the processing performed by the HA is done *only* based on the value of the K bit it sets *in its BA* (section 10.3.1). When the K bit is 0, the action is to "discard the key management connections, if any, to the old care-of address" (the one in the BCE). What I say is that an implementation which *strictly* follows what is in section 10.3.1 will just discard the key management connections to the old CoA. Nonetheless, I think what you describe is valid and it makes sense to consider that *in all cases* implementations specifically handle the binding refresh with no change of CoA (and not even look at K bit value in that specific case). Thanks for your thoughts, Cheers, a+ From vijay@wichorus.com Thu May 21 13:47: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 C8FB93A6ABF for ; Thu, 21 May 2009 13:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.676 X-Spam-Level: X-Spam-Status: No, score=0.676 tagged_above=-999 required=5 tests=[AWL=3.275, 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 1AEjWVdM1aTs for ; Thu, 21 May 2009 13:47:28 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id CCA7B3A6A72 for ; Thu, 21 May 2009 13:47:27 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA06.westchester.pa.mail.comcast.net with comcast id uCFl1b00Z0EZKEL56Lp6A2; Thu, 21 May 2009 20:49:06 +0000 Received: from [10.166.254.150] ([38.96.10.141]) by OMTA01.westchester.pa.mail.comcast.net with comcast id uLoM1b00V32awWW3MLoWlG; Thu, 21 May 2009 20:48:49 +0000 Message-ID: <4A15BE1F.9040305@wichorus.com> Date: Thu, 21 May 2009 13:48:31 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Arnaud Ebalard References: <87eiusx1s6.fsf@small.ssi.corp> <2D50B653-C7B4-4FDF-93A0-D7F0AE2BEEDC@gmail.com> <87ws8cnhrg.fsf@small.ssi.corp> <4A147DD0.1030109@wichorus.com> <87octmpzs0.fsf@small.ssi.corp> In-Reply-To: <87octmpzs0.fsf@small.ssi.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF MEXT WG ML Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals 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, 21 May 2009 20:47:28 -0000 Hi Arnaud, Arnaud Ebalard wrote: >> Even in RFC 3775, a mobile node can clear the 'K' bit in a BU sent for >> a binding refresh when there is no change in CoA. When the CoA >> changes, the MN can set the 'K' bit in the BU sent to update the CoA. > > Rereading Section 10.3.1 of RFC 3775, the binding refresh case when > there is no change of CoA does not exist. No. The mobile node would send a BU to refresh an existing binding if the lifetime is about to expire, even if there is no change in CoA. Maybe this is not explicitly pointed out in section 10.3.1. Section 11.7.1 says Also, if the mobile node wants the services of the home agent beyond the current registration period, the mobile node should send a new Binding Update to it well before the expiration of this period, even if it is not changing its primary care-of address. > As usual, the content of a new > BU basically replace the content of the previous one in the BCE. In > section 10.3.1, the processing performed by the HA is done *only* based > on the value of the K bit it sets *in its BA* (section 10.3.1). When the > K bit is 0, the action is to "discard the key management connections, if > any, to the old care-of address" (the one in the BCE). > > What I say is that an implementation which *strictly* follows what is in > section 10.3.1 will just discard the key management connections to the > old CoA. > > Nonetheless, I think what you describe is valid and it makes sense to > consider that *in all cases* implementations specifically handle the > binding refresh with no change of CoA (and not even look at K bit value > in that specific case). So I am going to conclude that there is no need for any change in the MCoA document on this issue. > Thanks for your thoughts, No problem. Your detailed reviews are always welcome. Vijay From koo@comnets.uni-bremen.de Thu May 21 13:57: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 227DB3A700C for ; Thu, 21 May 2009 13:57:26 -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_DE=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 rRizCCI6uH11 for ; Thu, 21 May 2009 13:57:25 -0700 (PDT) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by core3.amsl.com (Postfix) with ESMTP id 413E93A7007 for ; Thu, 21 May 2009 13:57:25 -0700 (PDT) Received: from koojanalaptop (unknown [10.8.0.42]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTP id 0C92D24EE47 for ; Thu, 21 May 2009 22:59:01 +0200 (CEST) From: "Koojana Kuladinithi" To: "'mext'" References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> In-Reply-To: <4A13FFE5.2050804@it.uc3m.es> Date: Thu, 21 May 2009 22:59:09 +0200 Message-ID: <000001c9da56$fd6d6f60$f8484e20$@uni-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnZS6uCWRESWN9WQSiQ2GIpi0jwjABCa1iQ Content-Language: en-us Subject: Re: [MEXT] About the flow binding charter item 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, 21 May 2009 20:57:26 -0000 Hi >So, we would like that the WG express their opinion on both items >mentioned above: >1- whether we should replace Flow/binding policies exchange by Flow >Binding rules exchange in the charter Agree >2- whether the information should be sent from the MN to the HA only >or it should also be sent from the HA to the MN and if the >information exchanged in each direction should affect the CoA and/or >the HA address. Are there any convincing scenarios, where HA can take a decision on behalf of the MN? This leads to address several issues such as how does HA know about the status of the interfaces of the MN, whether HA has the right to enforce the rules without informing the MN, what is the negotiation to handle conflicting rules and so on. I am not sure whether we should extend MIPv6 to handle above issues. Regards Koojana >Regards, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From arno@natisbad.org Thu May 21 15:02:31 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 A6A563A7013 for ; Thu, 21 May 2009 15:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 UEFLFIrdZWml for ; Thu, 21 May 2009 15:02:29 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 359EE3A6C1B for ; Thu, 21 May 2009 15:00:44 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M7GKr-0002Ly-Hu; Fri, 22 May 2009 00:01:57 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Vijay Devarapalli References: <87eiusx1s6.fsf@small.ssi.corp> <2D50B653-C7B4-4FDF-93A0-D7F0AE2BEEDC@gmail.com> <87ws8cnhrg.fsf@small.ssi.corp> <4A147DD0.1030109@wichorus.com> <87octmpzs0.fsf@small.ssi.corp> <4A15BE1F.9040305@wichorus.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090521:thierry.ernst@inria.fr::4HXmH+/sTp7H/CIp:0000000000000000000000000000000000000001tMB X-Hashcash: 1:20:090521:tsirtsis@googlemail.com::EHrb82mcYD1nuFtB:000000000000000000000000000000000000000J0Q X-Hashcash: 1:20:090521:marcelo@it.uc3m.es::Yx6Cm/aOElXwvmKo:00000000000000000000000000000000000000000000o4r X-Hashcash: 1:20:090521:ryuji.wakikawa@gmail.com::nq15SNr3ti10BpGs:00000000000000000000000000000000000000icj X-Hashcash: 1:20:090521:vijay@wichorus.com::VCnblBADIq7y2VTx:00000000000000000000000000000000000000000003M5w X-Hashcash: 1:20:090521:mext@ietf.org::Av0D0yuhsJznoLWJ:00001ziy X-Hashcash: 1:20:090521:hesham@elevatemobile.com::FUwtVSiy8BX+JK5T:00000000000000000000000000000000000009aSj Date: Fri, 22 May 2009 00:02:32 +0200 In-Reply-To: <4A15BE1F.9040305@wichorus.com> (Vijay Devarapalli's message of "Thu, 21 May 2009 13:48:31 -0700") Message-ID: <87vdnunmh3.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IETF MEXT WG ML Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals 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, 21 May 2009 22:02:31 -0000 Hi, Vijay Devarapalli writes: > Arnaud Ebalard wrote: > >>> Even in RFC 3775, a mobile node can clear the 'K' bit in a BU sent for >>> a binding refresh when there is no change in CoA. When the CoA >>> changes, the MN can set the 'K' bit in the BU sent to update the CoA. >> >> Rereading Section 10.3.1 of RFC 3775, the binding refresh case when >> there is no change of CoA does not exist. > > No. The mobile node would send a BU to refresh an existing binding if > the lifetime is about to expire, even if there is no change in > CoA. Maybe this is not explicitly pointed out in section > 10.3.1. Section 11.7.1 says > > Also, if the mobile node wants the services of the home agent beyond > the current registration period, the mobile node should send a new > Binding Update to it well before the expiration of this period, even > if it is not changing its primary care-of address. Sorry, I meant "the specific 'K' bit processing you describe for a refresh w/o CoA change" does not exist. The processing (including K bit one) is described for all kinds of BU, no matter if they create or refresh a binding. I obviously did not mean binding refresh is not defined. >> As usual, the content of a new >> BU basically replace the content of the previous one in the BCE. In >> section 10.3.1, the processing performed by the HA is done *only* based >> on the value of the K bit it sets *in its BA* (section 10.3.1). When the >> K bit is 0, the action is to "discard the key management connections, if >> any, to the old care-of address" (the one in the BCE). >> >> What I say is that an implementation which *strictly* follows what is in >> section 10.3.1 will just discard the key management connections to the >> old CoA. >> >> Nonetheless, I think what you describe is valid and it makes sense to >> consider that *in all cases* implementations specifically handle the >> binding refresh with no change of CoA (and not even look at K bit value >> in that specific case). > > So I am going to conclude that there is no need for any change in the > MCoA document on this issue. Right. Cheers, a+ From vijay@wichorus.com Thu May 21 16:26: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 4F8C43A67B3 for ; Thu, 21 May 2009 16:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.055 X-Spam-Level: * X-Spam-Status: No, score=1.055 tagged_above=-999 required=5 tests=[AWL=1.587, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 JnHEHw2uTSqz for ; Thu, 21 May 2009 16:26:24 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 2F7A63A681C for ; Thu, 21 May 2009 16:26:24 -0700 (PDT) Received: from 38.96.10.141 ([38.96.10.141]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 May 2009 23:28:02 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 21 May 2009 16:28:01 -0700 From: Vijay Devarapalli To: Ahmad Muhanna Message-ID: Thread-Topic: Binding Revocation almost ready for IESG Thread-Index: AcnO9sVR9cTLMTwdQ1GgPu1FD+lnTAAEbwpwAnKQ7sQADhwpEABYJJDJ In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Julien Laganier , mext Subject: Re: [MEXT] 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: Thu, 21 May 2009 23:26:25 -0000 Hi Ahmad, On 5/19/09 11:01 PM, "Ahmad Muhanna" wrote: >> I have a couple of comments on version 10 >> >> You explained to me that 3GPP2 wants to differentiate between >> the two following triggers. >> >> 3 Inter-MAG Handover - same Access Type >> 4 Inter-MAG Handover - different Access Type >> >> That's fine. > [Ahmad] > Thanks for agreeing on adding these two back! :) > >> 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. >> On authorization for bulk revocation, we need some text that >> explains how the LMA is supposed to check if a particular MAG >> is authorized to perform bulk revocation. Is this list of >> "MAGS-authorized-for-bulk-revocation" >> manually created on the LMA? If not, how is this populated? >> >> (FWIW, I still think this authorization check should be >> removed from the draft). > > [Ahmad] > I think we keep coming back to this point:) > It is based on the home domain policy. > > 1. Some home domain probably wont allow this across different domain > period. Example: only between MAG(s) and LMA(s) that belong to the same > operator. > > 2. It could be as simple as all MAGs which IDs matches a simple string > of "wildcard@xyz.com" > > 3. It could be as simple as "every MAG which is able to establish an > IPsec SA for protecting PMIP signaling is authorized for Global > revocation; I guess this matches your views to some extent. > > 4. etc. > > Leaving the details out of scope gives the flexibility for the home > domain to enforce its own policy freely. > > I hope this address your concern. No, it doesn't. In general, you can't require some behavior on the LMA and then not specify how the LMA is supposed to implement it. Here is another suggestion. Remove all text related to the authorization check when the MAG sends a bulk revocation message in the draft. Instead, add the following text to the Security Considerations sections An LMA implementation should be careful in processing bulk revocation messages from the MAGs. Bulk revocation, when used inappropriately, can deny mobility service to a large number of mobile nodes. Therefore the LMA should check if the MAG is authorized to send a bulk revocation message before processing the message. To implement this check, the LMA should be configured with the information about which MAGs are allowed to perform bulk revocation. For example, all the MAGs in a particular PMIPv6 domain can be authorized for bulk revocation, while othes are not. If the LMA decides to reject the bulk revocation message from the MAG, it should send a BRA message with status set to '130' (Global Revocation NOT Authorized). Feel free to modify the above text. In section 3.1, delete When the local mobility anchor receives such Binding Revocation Indication message, it ensures that the mobile access gateway is authorized to send such bulk termination message and then processes the Binding Revocation Indication message accordingly. In section 3.4.2, replace When the local mobility anchor receives a Binding Revocation Indication message with the (G) bit is set from a specified mobile access gateway, the local mobility anchor first checks if the mobile access gateway is authorized to use global revocations and then responds with the appropriate status code by sending a Binding Revocation Acknowledgement message as in Section 9.2.2. With When the local mobility anchor receives a Binding Revocation Indication message with the (G) bit set from a specified mobile access gateway, the local mobility anchor first processes the message and then responds with the appropriate status code by sending a Binding Revocation Acknowledgement message as in Section 9.2.2. In section 4, delete Additionally, in the case when the local mobility anchor receives a Binding Revocation Indication which indicates a bulk termination where the (G) bit is set and the Revocation Trigger field is set to "Per-Peer Policy", the local mobility anchor MUST verify that the mobile access gateway sending the binding revocation indication message is authorized to invoke global revocation. In section 9.2.1, delete The local mobility anchor MUST verify that the identified mobile access gateway as per the value in the MN-ID option is authorized to use the Global revocation. The mechanism the local mobility anchor uses to verify the mobile access gateway authorization is out of scope of this document. Hope this works for you.. Vijay From AMUHANNA@nortel.com Fri May 22 08:30: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 784CC3A704C for ; Fri, 22 May 2009 08:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 AUuZLm+cF8v4 for ; Fri, 22 May 2009 08:30:34 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 03DC43A7052 for ; Fri, 22 May 2009 08:30: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 n4MFV0n29138; Fri, 22 May 2009 15:31:01 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: Fri, 22 May 2009 10:31:48 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Binding Revocation almost ready for IESG Thread-Index: AcnO9sVR9cTLMTwdQ1GgPu1FD+lnTAAEbwpwAnKQ7sQADhwpEABYJJDJAAUQ66A= References: From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: Julien Laganier , mext Subject: Re: [MEXT] 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: Fri, 22 May 2009 15:30:35 -0000 Hi Vijay, Regards, Ahmad > -----Original Message----- > Hi Ahmad, >=20 > On 5/19/09 11:01 PM, "Ahmad Muhanna" wrote: >=20 > >> I have a couple of comments on version 10 > >>=20 > >> You explained to me that 3GPP2 wants to differentiate=20 > between the two=20 > >> following triggers. > >>=20 > >> 3 Inter-MAG Handover - same Access Type > >> 4 Inter-MAG Handover - different Access Type > >> =20 > >> That's fine.=20 > > [Ahmad] > > Thanks for agreeing on adding these two back! :) > >=20 > >> But what should the MAG behavior be when it receives the following=20 > >> trigger? > >>=20 > >> 5 Inter-MAG Handover - Unknown > >>=20 > > [Ahmad] > > The MAG will reject the BRI with code "MN still attached"=20 > :) I mean,=20 > > the MAG is supposed to check whether the mobile node is attached or=20 > > not and based on its finding, it should reply back either=20 > success or=20 > > failure, e.g., "MN still attached". >=20 > Ok. >=20 > So what does the LMA do now? The new MAG is saying the MN=20 > attached to it and the handoff state is "unknown". The old=20 > MAG is saying the MN is still attached? Shouldn't this result=20 > in a new mobility session being setup for the attachment=20 > through the new MAG? It won't be treated as a handover=20 > anymore. This probably needs to be explained. >=20 [Ahmad] The LMA does nothing other than what is documented in RFC5213.=20 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. > >> On authorization for bulk revocation, we need some text=20 > that explains=20 > >> how the LMA is supposed to check if a particular MAG is=20 > authorized to=20 > >> perform bulk revocation. Is this list of=20 > >> "MAGS-authorized-for-bulk-revocation" > >> manually created on the LMA? If not, how is this populated? > >>=20 > >> (FWIW, I still think this authorization check should be=20 > removed from=20 > >> the draft). > >=20 > > [Ahmad] > > I think we keep coming back to this point:) It is based on the home=20 > > domain policy. > >=20 > > 1. Some home domain probably wont allow this across=20 > different domain=20 > > period. Example: only between MAG(s) and LMA(s) that belong to the=20 > > same operator. > >=20 > > 2. It could be as simple as all MAGs which IDs matches a=20 > simple string=20 > > of "wildcard@xyz.com" > >=20 > > 3. It could be as simple as "every MAG which is able to=20 > establish an=20 > > IPsec SA for protecting PMIP signaling is authorized for Global=20 > > revocation; I guess this matches your views to some extent. > >=20 > > 4. etc. > >=20 > > Leaving the details out of scope gives the flexibility for the home=20 > > domain to enforce its own policy freely. > >=20 > > I hope this address your concern. >=20 > No, it doesn't. In general, you can't require some behavior=20 > on the LMA and then not specify how the LMA is supposed to=20 > implement it.=20 [Ahmad] Vijay, This behavior is NO different than what is currently required in RFC5213. I believe we discussed this offline before and now we are going back again. :) What I meant by out of scope is: out-of-scope of this document because RFC5213 contains very similar requirement already. Why it is NOT an issue in RFC5213 when the LMA needs to ensure that the MAG is authorized to send a PBU on behalf of the mobile node and a specific prefix? This is exactly similar.=20 If you like, I could cut and paste the text from RFC5213 and include it this draft or add a pointer to section 4.0 of RFC5213. Here the related text: " ...................................... Therefore, the local mobility anchor MUST restrict the creation and manipulation of proxy bindings to specifically authorized mobile access gateways and prefixes. The local mobility anchor MUST be locally configurable to authorize such specific combinations. Additional mechanisms, such as a policy store or Authentication, Authorization, and Accounting (AAA) may be employed, but these are outside the scope of this specification. " > Here is another suggestion. Remove all text=20 > related to the authorization check when the MAG sends a bulk=20 > revocation message in the draft.=20 [Ahmad] No. Again, this is no different than what is mentioned above. No. 1.=20 No. 2. This functionality has been in the draft since day one and all of a sudden it becomes a problem without a clear reason. > Instead, add the following=20 > text to the Security Considerations sections >=20 > An LMA implementation should be careful in processing bulk=20 > revocation > messages from the MAGs. Bulk revocation, when used=20 > inappropriately, can > deny mobility service to a large number of mobile nodes.=20 [Ahmad] This is an interesting statement to add in the security section! If you admit there is a problem why removing the solution to start with? If you have a problem handling this, then you probably have a problem with RFC5213. > Therefore the > LMA should check if the MAG is authorized to send a bulk revocation > message before processing the message. To implement this=20 > check, the LMA > should be configured with the information about which MAGs=20 > are allowed to > perform bulk revocation. For example, all the MAGs in a particular > PMIPv6 domain can be authorized for bulk revocation, while=20 > othes are not. > If the LMA decides to reject the bulk revocation message=20 > from the MAG, > it should send a BRA message with status set to '130'=20 > (Global Revocation > NOT Authorized). >=20 > Feel free to modify the above text. >=20 > In section 3.1, delete > =20 > When the local mobility anchor > receives such Binding Revocation Indication message, it=20 > ensures that > the mobile access gateway is authorized to send such bulk=20 > termination > message and then processes the Binding Revocation=20 > Indication message > accordingly.=20 >=20 > In section 3.4.2, replace >=20 > When the local mobility anchor > receives a Binding Revocation Indication message with the=20 > (G) bit is > set from a specified mobile access gateway, the local=20 > mobility anchor > first checks if the mobile access gateway is authorized to=20 > use global > revocations and then responds with the appropriate status code by > sending a Binding Revocation Acknowledgement message as in > Section 9.2.2. >=20 > With >=20 > When the local mobility anchor > receives a Binding Revocation Indication message with the (G) bit > set from a specified mobile access gateway, the local=20 > mobility anchor > first processes the message and then responds with the appropriate > status code by sending a Binding Revocation Acknowledgement message > as in Section 9.2.2. >=20 > In section 4, delete >=20 > Additionally, in the case when the local mobility anchor receives a > Binding Revocation Indication which indicates a bulk termination > where the (G) bit is set and the Revocation Trigger field is set to > "Per-Peer Policy", the local mobility anchor MUST verify that the > mobile access gateway sending the binding revocation indication > message is authorized to invoke global revocation. >=20 > In section 9.2.1, delete >=20 > The local mobility anchor MUST verify that > the identified mobile access gateway as per the value=20 > in the MN-ID > option is authorized to use the Global revocation. The=20 > mechanism > the local mobility anchor uses to verify the mobile=20 > access gateway > authorization is out of scope of this document. >=20 > Hope this works for you.. >=20 > Vijay >=20 >=20 From behcetsarikaya@yahoo.com Fri May 22 08:57: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 AC95F3A6C1C for ; Fri, 22 May 2009 08:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[AWL=-0.258, 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 B0Cv28OgVsQr for ; Fri, 22 May 2009 08:57:11 -0700 (PDT) Received: from n58.bullet.mail.sp1.yahoo.com (n58.bullet.mail.sp1.yahoo.com [98.136.44.46]) by core3.amsl.com (Postfix) with SMTP id AC47E3A6A6D for ; Fri, 22 May 2009 08:57:11 -0700 (PDT) Received: from [216.252.122.216] by n58.bullet.mail.sp1.yahoo.com with NNFMP; 22 May 2009 15:58:49 -0000 Received: from [67.195.9.82] by t1.bullet.sp1.yahoo.com with NNFMP; 22 May 2009 15:58:49 -0000 Received: from [67.195.9.110] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 22 May 2009 15:58:48 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 22 May 2009 15:56:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 40842.84542.bm@omp114.mail.gq1.yahoo.com Received: (qmail 3279 invoked by uid 60001); 22 May 2009 15:58:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243007928; bh=feSQ4ZV2THa50DVmcB5EAQ9pDC0s8Rqug/n0jI7hmmI=; 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=Epc8+hsXBn3P28L4INeWd6rg0OzkFl2wbu9FmPhxkamtyMvENAu39vbr3eTw/QZPEOBgHQMciJebZyFQXF/ye3i3qwePL7OXV5ILMrYg4wLXMo98MUigDmGKd5GQokkxMNPaueQAPdwPOkpkZkFdQrX2eQtMDm2NNDscFYcbtjE= 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=gofqDknMVu/gSpFEk7s2nfs5u3EJUVN5WfkrnpkUTkBzEytjD73Fv0oiLh7XW3vRtKQASDpikp/Vg84EIsqiSxnhZgWihaWjQGhKoSGDHFt3irYl6JcXOBj/EHcXAOvsl0ots/xw8RkZKaciK0ELmT+XDZlcIWAXv0eY1eRuAQY=; Message-ID: <687207.3222.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: 1.ipw2YVM1n.HhAvyBxZx7.li2rCs1bjwo56vWH2zCdHOmVboEWmmb955y6ivh5U36UWa8s_zqI0gPm34Y7AipbwdyoOkpEw296MiiLpILD3JbUpcWk_eHBHCxk7CY5kh2KhAgEaFHvt.i1PsU5QjH4m4d1YlKQ1oa6Gf3mu20WxFU.90rM0WCaMvNmM6ctlCXOQikNWwk6ums5KN6yqr0WJanbp2Rvxid5iGGqY5kjTFXUf1tgpOaqQTogv.a6PFh7ZqN5LStJdSPLzXiy5YmJHx95ShlTchipZbG8J8PcrGchUFhZYJLe8ExJuolfIVp.w Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Fri, 22 May 2009 08:58:48 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> Date: Fri, 22 May 2009 08:58:48 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun , mext In-Reply-To: <4A13FFE5.2050804@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , Jari Arkko Subject: Re: [MEXT] About the flow binding charter item 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, 22 May 2009 15:57:12 -0000 Hi Marcelo,=0A=A0 Pls see my choices below.=0A=0ARegards,=0A=0ABehcet=0A=0A= =0A=0A----- Original Message ----=0AFrom: marcelo bagnulo braun =0ATo: mext =0ACc: Jari Arkko ; Julien Laganier =0ASent: Wednesday,= May 20, 2009 8:04:37 AM=0ASubject: [MEXT] About the flow binding charter i= tem=0A=0AHi,=0A=0AThere seems to be some discrepancies about the MEXT chart= er item=0Aregarding the work on flow bindings.=0ASince the charter is the g= uide for our work, it would be important to=0Aclarify it, so we can have a = unified interpretation of the charter.=0APlease note that what it is in the= charter is not cast in stone, but=0Ait seems to reflect previous consensus= and we need good reasons to=0Achange it.=0A=0ASo, the current charter item= about flow bindings reads:=0A=0A- A "Flow/binding policies exchange" solut= ion for an exchange of=0Apolicies from the mobile host/router to the Home A= gent and from the=0AHome Agent to the mobile host/router influencing the ch= oice of the=0ACare-of Address and Home Agent address. The solution involves= two=0Aspecifications, one for the policy format and another for its=0Atran= sport [both Standard Track].=0A=0AThe first problem with this text is the u= se and interpretation of the=0Aword policy. Since the policy word may have = a broad interpretation.=0Ait would be important to make the charter more ex= plicit about the=0Aexpected work. We understand that it is the WG consensus= that what=0Aneed to be exchanged is a solution for the exchange of flow bi= nding=0Arules.=0A=0ASo, we understand that it would be more explicit to rep= lace the usage=0Aof the expression Flow/binding policies exchange by Flow B= inding=0Arules exchange. Would that reflect with the WG interpretation?=0A= =0ASecond, the current charter item explicitly mentions that the=0Aproposed= approach must support sending flow binding information from=0Athe MN to th= e HA and also from the HA to the MN. Moreover, the=0Acurrent charter talks = about influencing not only the selection of the=0ACoA but also the selectio= n of the HA address. However, our current WG=0Adocument does not supports s= ending information from the HA and it=0Adoes not cover the possibility of i= nfluencing the HA address. So, one=0Apossible interpretation of the charter= would be that the MN sends=0Aflow binding information to influence the CoA= selection and the HA=0Asends flow binding information to influence the HA = address selection.=0AOther interpretation is that both the MN and the HA se= nd information=0Aregarding both the HA address and the CoA selection.=0A=0A= So, we would like that the WG express their opinion on both items=0Amention= ed above:=0A=0A1- whether we should replace Flow/binding policies exchange = by Flow=0ABinding rules exchange in the charter=0A=0A[behcet] Agreed.=0A=0A= 2- whether the information should be sent from the MN to the HA only=0Aor i= t should also be sent from the HA to the MN and if the=0Ainformation exchan= ged in each direction should affect the CoA and/or=0Athe HA address.=0A=0A[= behcet] I think that the information should be sent both ways. We have curr= ently two drafts one on each, so we progress both of them.=0ARegarding CoA = and or the HA address, some people said HA address was supposed to be the H= oA.=0AI think both drafts are only using CoA.=A0So we should probably go wi= th the CoA.=0A=0A=0A=0A From vijay@wichorus.com Fri May 22 10:55:03 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 F1E5F3A6A5F for ; Fri, 22 May 2009 10:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[AWL=2.356, 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 XljCiRBrEf5i for ; Fri, 22 May 2009 10:55:03 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 0B9DC3A698F for ; Fri, 22 May 2009 10:55:02 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id ubmo1b0060cQ2SLA1hwi2Q; Fri, 22 May 2009 17:56:42 +0000 Received: from [10.166.254.150] ([38.96.10.141]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id uhwQ1b00c32awWW8WhwWA7; Fri, 22 May 2009 17:56:40 +0000 Message-ID: <4A16E743.5010400@wichorus.com> Date: Fri, 22 May 2009 10:56:19 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ahmad Muhanna References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julien Laganier , mext Subject: [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: Fri, 22 May 2009 17:55:04 -0000 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. How can these two be compatible? 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. Vijay From vijay@wichorus.com Fri May 22 11:03:49 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 A452F3A6A11 for ; Fri, 22 May 2009 11:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.58 X-Spam-Level: X-Spam-Status: No, score=-0.58 tagged_above=-999 required=5 tests=[AWL=2.019, 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 Ju+wbeQ2IF5h for ; Fri, 22 May 2009 11:03:48 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 6BE053A68B9 for ; Fri, 22 May 2009 11:03:48 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA07.westchester.pa.mail.comcast.net with comcast id uZxZ1b0030vyq2s57i4s9x; Fri, 22 May 2009 18:04:52 +0000 Received: from [10.166.254.150] ([38.96.10.141]) by OMTA05.westchester.pa.mail.comcast.net with comcast id ui5E1b00T32awWW3Ri5GfK; Fri, 22 May 2009 18:05:26 +0000 Message-ID: <4A16E955.3040504@wichorus.com> Date: Fri, 22 May 2009 11:05:09 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ahmad Muhanna References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julien Laganier , mext Subject: [MEXT] Authorization check for bulk revocation (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: Fri, 22 May 2009 18:03:49 -0000 Hi Ahmad, Now to the other issue... Ahmad Muhanna wrote: >>>> On authorization for bulk revocation, we need some text >> that explains >>>> how the LMA is supposed to check if a particular MAG is >> authorized to >>>> perform bulk revocation. Is this list of >>>> "MAGS-authorized-for-bulk-revocation" >>>> manually created on the LMA? If not, how is this populated? >>>> >>>> (FWIW, I still think this authorization check should be >> removed from >>>> the draft). >>> [Ahmad] >>> I think we keep coming back to this point:) It is based on the home >>> domain policy. >>> >>> 1. Some home domain probably wont allow this across >> different domain >>> period. Example: only between MAG(s) and LMA(s) that belong to the >>> same operator. >>> >>> 2. It could be as simple as all MAGs which IDs matches a >> simple string >>> of "wildcard@xyz.com" >>> >>> 3. It could be as simple as "every MAG which is able to >> establish an >>> IPsec SA for protecting PMIP signaling is authorized for Global >>> revocation; I guess this matches your views to some extent. >>> >>> 4. etc. >>> >>> Leaving the details out of scope gives the flexibility for the home >>> domain to enforce its own policy freely. >>> >>> I hope this address your concern. >> No, it doesn't. In general, you can't require some behavior >> on the LMA and then not specify how the LMA is supposed to >> implement it. > > [Ahmad] > Vijay, > > This behavior is NO different than what is currently required in > RFC5213. I believe we discussed this offline before and now we are going > back again. :) We never resolved this, though. :) > What I meant by out of scope is: out-of-scope of this document because > RFC5213 contains very similar requirement already. Why it is NOT an > issue in RFC5213 when the LMA needs to ensure that the MAG is authorized > to send a PBU on behalf of the mobile node and a specific prefix? This > is exactly similar. > If you like, I could cut and paste the text from RFC5213 and include it > this draft or add a pointer to section 4.0 of RFC5213. > > Here the related text: > " > ...................................... Therefore, the local mobility > anchor MUST restrict the creation and manipulation of proxy bindings > to specifically authorized mobile access gateways and prefixes. The > local mobility anchor MUST be locally configurable to authorize such > specific combinations. Additional mechanisms, such as a policy store > or Authentication, Authorization, and Accounting (AAA) may be > employed, but these are outside the scope of this specification. > " The above text addresses very specific issue - that of a MAG modifying the routing state for a mobile node. One of the concerns that was brought up at the time of RFC 5213 standardization was that the MAG could be modifying the routing state for a Mobile IPv6 mobile node. So we had to add explicit text about the LMA checking if the MAG is authorized to create/delete/modify the binding for a mobile node. This text was a result of extensive discussions, basically a sort of compromise... I am not going to agree to using this for adding more specification text along these lines... Having something like the above in RFC 5213 does not justify adding more similar authorization checks in the binding revocation document. >> Here is another suggestion. Remove all text >> related to the authorization check when the MAG sends a bulk >> revocation message in the draft. > > [Ahmad] > No. > > Again, this is no different than what is mentioned above. No. 1. > No. 2. This functionality has been in the draft since day one and all of > a sudden it becomes a problem without a clear reason. Sorry, you can't use the text in RFC 5213 to justify the authorization check for bulk revocation. >> Instead, add the following >> text to the Security Considerations sections >> >> An LMA implementation should be careful in processing bulk >> revocation >> messages from the MAGs. Bulk revocation, when used >> inappropriately, can >> deny mobility service to a large number of mobile nodes. > > [Ahmad] > This is an interesting statement to add in the security section! If you > admit there is a problem why removing the solution to start with? If you > have a problem handling this, then you probably have a problem with > RFC5213. Mandating something on the LMA is different from describing a possible security threat in the security considerations section and suggesting solutions to mitigate that threat. They are *NOT* the same. Vijay From AMUHANNA@nortel.com Sat May 23 05:21: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 B609C3A6B82 for ; Sat, 23 May 2009 05:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 OhTBDNdGMpru for ; Sat, 23 May 2009 05:21:14 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A292B3A686D for ; Sat, 23 May 2009 05:20:49 -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 n4NCMMD04143; Sat, 23 May 2009 12:22:23 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: Sat, 23 May 2009 07:22:21 -0500 Message-ID: In-Reply-To: <4A16E743.5010400@wichorus.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: AcnbBqtShaCG5PysRhOVaN77t7TyZgAmEnNw References: <4A16E743.5010400@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: Julien Laganier , 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: Sat, 23 May 2009 12:21:15 -0000 Hi Vijay, Regards, Ahmad > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 > 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) >=20 > Hi Ahmad, >=20 > I am going to split the emails into two, since we are dealing=20 > with two issues. >=20 > Ahmad Muhanna wrote: >=20 > >>>> But what should the MAG behavior be when it receives the=20 > following=20 > >>>> trigger? > >>>> > >>>> 5 Inter-MAG Handover - Unknown > >>>> > >>> [Ahmad] > >>> The MAG will reject the BRI with code "MN still attached"=20 > >> :) I mean, > >>> the MAG is supposed to check whether the mobile node is=20 > attached or=20 > >>> 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=20 > attached to=20 > >> it and the handoff state is "unknown". The old MAG is=20 > saying the MN=20 > >> is still attached? Shouldn't this result in a new 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 be explained. > >> > > [Ahmad] > > The LMA does nothing other than what is documented in RFC5213.=20 > > This is exactly the same case as if the LMA did not receive a=20 > > de-registration from the previous MAG and the timer=20 > expired. I do not=20 > > think it is necessary to add anything, but we could add a pointer to > > RFC5213 for this specific case when handling the AD comments. >=20 > This doesn't make sense. RFC 5213 says if the LMA receives a=20 > PBU with HI set to "handoff state unknown", it should wait=20 > for MaxDelayBeforeNewBCEAssign amount of time for a=20 > deregistration PBU from the old MAG. If there is no such=20 > deregistration message from the old MAG, it would create a=20 > new mobility session. >=20 > The Binding revocation document suggests that the LMA must=20 > send a binding revocation message with the trigger set to=20 > "handoff state unknown". If the MN is still attached, the old=20 > MAG would reject the binding revocation. Then the LMA would=20 > 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"? >=20 > How can these two be compatible? >=20 [Ahmad] We can debate this offlist, I guess:) Please see below. > IMO, the binding revocation document should say that it is=20 > updating RFC > 5213 when it comes to the LMA behavior when it receives a PBU=20 > with HI set to "handoff state unknown". If the LMA and the=20 > MAG implement binding revocation, they should follow the=20 > mechanism described in the binding revocation document rather=20 > 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? >=20 > Vijay >=20 From AMUHANNA@nortel.com Sat May 23 06:36: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 3734C3A67F7 for ; Sat, 23 May 2009 06:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 gnLIlHFLs+Xz for ; Sat, 23 May 2009 06:36:18 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CCD5B3A6C02 for ; Sat, 23 May 2009 06:36:17 -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 n4NDbpD10556; Sat, 23 May 2009 13:37:52 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: Sat, 23 May 2009 08:37:35 -0500 Message-ID: In-Reply-To: <4A16E955.3040504@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Authorization check for bulk revocation (was Re: Binding Revocation almost ready for IESG) Thread-Index: AcnbB+OtndOKa9cbRDq+o8RQjAQHMQAniiLg References: <4A16E955.3040504@wichorus.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" Cc: Julien Laganier , mext Subject: Re: [MEXT] Authorization check for bulk revocation (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: Sat, 23 May 2009 13:36:19 -0000 Hi Vijay, > Subject: Authorization check for bulk revocation (was Re:=20 > Binding Revocation almost ready for IESG) >=20 > Hi Ahmad, >=20 > Now to the other issue... [Ahmad] Yes; indeed:) >=20 > Ahmad Muhanna wrote: >=20 > >>>> On authorization for bulk revocation, we need some text > >> that explains > >>>> how the LMA is supposed to check if a particular MAG is > >> authorized to > >>>> perform bulk revocation. Is this list of=20 > >>>> "MAGS-authorized-for-bulk-revocation" > >>>> manually created on the LMA? If not, how is this populated? > >>>> > >>>> (FWIW, I still think this authorization check should be > >> removed from > >>>> the draft). > >>> [Ahmad] > >>> I think we keep coming back to this point:) It is based=20 > on the home=20 > >>> domain policy. > >>> > >>> 1. Some home domain probably wont allow this across > >> different domain > >>> period. Example: only between MAG(s) and LMA(s) that=20 > belong to the=20 > >>> same operator. > >>> > >>> 2. It could be as simple as all MAGs which IDs matches a > >> simple string > >>> of "wildcard@xyz.com" > >>> > >>> 3. It could be as simple as "every MAG which is able to > >> establish an > >>> IPsec SA for protecting PMIP signaling is authorized for Global=20 > >>> revocation; I guess this matches your views to some extent. > >>> > >>> 4. etc. > >>> > >>> Leaving the details out of scope gives the flexibility=20 > for the home=20 > >>> domain to enforce its own policy freely. > >>> > >>> I hope this address your concern. > >> No, it doesn't. In general, you can't require some behavior on the=20 > >> LMA and then not specify how the LMA is supposed to implement it. > >=20 > > [Ahmad] > > Vijay, > >=20 > > This behavior is NO different than what is currently required in=20 > > RFC5213. I believe we discussed this offline before and now we are=20 > > going back again. :) >=20 > We never resolved this, though. :) >=20 > > What I meant by out of scope is: out-of-scope of this=20 > document because > > RFC5213 contains very similar requirement already. Why it is NOT an=20 > > issue in RFC5213 when the LMA needs to ensure that the MAG is=20 > > authorized to send a PBU on behalf of the mobile node and a=20 > specific=20 > > prefix? This is exactly similar. > > If you like, I could cut and paste the text from RFC5213=20 > and include=20 > > it this draft or add a pointer to section 4.0 of RFC5213. > >=20 > > Here the related text: > > " > > ...................................... Therefore, the=20 > local mobility > > anchor MUST restrict the creation and manipulation of=20 > proxy bindings > > to specifically authorized mobile access gateways and=20 > prefixes. The > > local mobility anchor MUST be locally configurable to=20 > authorize such > > specific combinations. Additional mechanisms, such as a=20 > policy store > > or Authentication, Authorization, and Accounting (AAA) may be > > employed, but these are outside the scope of this specification. > > " >=20 > The above text addresses very specific issue - that of a MAG=20 > modifying the routing state for a mobile node. One of the=20 > concerns that was brought up at the time of RFC 5213=20 > standardization was that the MAG could be modifying the=20 > routing state for a Mobile IPv6 mobile node. So we had to add=20 > explicit text about the LMA checking if the MAG is authorized=20 > to create/delete/modify the binding for a mobile node. This=20 > text was a result of extensive discussions, basically a sort=20 > of compromise... >=20 > I am not going to agree to using this for adding more=20 > specification text along these lines... Having something like=20 > the above in RFC 5213 does not justify adding more similar=20 > authorization checks in the binding revocation document. [Ahmad] I absolutely understand where you are coming from, Although, I do not recall being part of that discussion or remembering if it was on the mailing list, but I could be wrong and that is not the point. RFC5213 is NOW a standard specification and most of implementations will NOT remember or pay attention to what was the discussion which took place before adopting a specific requirement NOR people care who compromised what. Implementers read what in the RFC and try their best to comply with its content and implement it. Having said that, I believe the following (some of this may have been said before): 1. Bulk revocation potentially impacts all sessions between a pair MAG-LMA and consequently needs to be handled carefully and addressed properly. 2. If we do not specify a mechanism for this, we will end up with two models:=20 2.1. Some deployment will disable this feature completely and hence as if we did not add this functionality to start with. But let us remember, this was added from day one because there was a need for it. 2.2. some deployment may not pay enough attention and allow this to happen without the proper validation and they properly will realize its negative impact after they go through a major problem and then start looking for patching or disabling a good functionality that they need or looking for a quick solution after the fact which is very painful! 3. Since, RFC5213 already has a mechanism similar to this, why NOT we point to that mechanism and move on. 4. You started by saying that we can not define a function which impact the LMA behavior and NOT specify how the LMA will be able to do it. I understand that part; But, when we moved to specify a default mechanism by pointing to what is already documented in RFC5213, now you are saying NO way to specify a default mechanism or add anything to specify how the LMA could do it! Do not you think that is a recipe and a proposal for preventing any conclusion on this issue? >=20 > >> Here is another suggestion. Remove all text related to the=20 > >> authorization check when the MAG sends a bulk revocation=20 > message in=20 > >> the draft. > >=20 > > [Ahmad] > > No. > >=20 > > Again, this is no different than what is mentioned above. No. 1.=20 > > No. 2. This functionality has been in the draft since day=20 > one and all=20 > > of a sudden it becomes a problem without a clear reason. >=20 > Sorry, you can't use the text in RFC 5213 to justify the=20 > authorization check for bulk revocation. >=20 > >> Instead, add the following > >> text to the Security Considerations sections > >> > >> An LMA implementation should be careful in processing bulk=20 > >> revocation > >> messages from the MAGs. Bulk revocation, when used=20 > inappropriately,=20 > >> can > >> deny mobility service to a large number of mobile nodes.=20 > >=20 > > [Ahmad] > > This is an interesting statement to add in the security section! If=20 > > you admit there is a problem why removing the solution to=20 > start with?=20 > > If you have a problem handling this, then you probably have=20 > a problem=20 > > with RFC5213. >=20 > Mandating something on the LMA is different from describing a=20 > possible security threat in the security considerations=20 > section and suggesting solutions to mitigate that threat.=20 > They are *NOT* the same. [Ahmad] Hmmm.. Well, if we follow this logic, we could live without ever mandating or specifying any solution and turn this specification to a big fat security section! while letting people figure a way to solve it. Not only that, but at the end we also claim that we have a standard specification. The key question here: Is this functionality needed to be part of this specification or NOT? My reading for all of your reasoning on this threat, is yes you agree and you want us to specify a default mechanism to handle it. Sure; We have one that is supposed to be already in place. Regards, Ahmad >=20 > Vijay >=20 From kuntz@lsiit.u-strasbg.fr Mon May 25 09:28: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 AEA0F3A6EC3 for ; Mon, 25 May 2009 09:28:21 -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 NT3WRBUGD1PM for ; Mon, 25 May 2009 09:28:20 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.152]) by core3.amsl.com (Postfix) with ESMTP id 3AF7A3A6DB9 for ; Mon, 25 May 2009 09:28:19 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n4PGSeqp009433 ; Mon, 25 May 2009 18:28:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 2E6C7C2B725; Mon, 25 May 2009 18:28:40 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxZVRXguJC+k; Mon, 25 May 2009 18:28:39 +0200 (CEST) Received: from frynet.u-strasbg.fr (frynet.u-strasbg.fr [130.79.91.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kuntz) by clarinet.u-strasbg.fr (Postfix) with ESMTP id B7A4FC2B716; Mon, 25 May 2009 18:28:39 +0200 (CEST) Message-Id: <84EE1DB1-1A19-45E0-83A1-4AC3994A7936@lsiit.u-strasbg.fr> From: Romain KUNTZ To: Brian Haley In-Reply-To: <5B180C5A-3C7E-42A3-A362-FDD18BE4C622@lsiit.u-strasbg.fr> 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, 25 May 2009 18:28:39 +0200 References: <49EF37D8.2010408@it.uc3m.es> <49FAC1A2.7060206@it.uc3m.es> <87hc0157z1.fsf@small.ssi.corp> <87skjh40mu.fsf@small.ssi.corp> <4A02E9C8.8070301@hp.com> <5B180C5A-3C7E-42A3-A362-FDD18BE4C622@lsiit.u-strasbg.fr> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [130.79.200.152]); Mon, 25 May 2009 18:28:40 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9390/Mon May 25 14:49:36 2009 on mr2.u-strasbg.fr X-Virus-Status: Clean Cc: mext Subject: Re: [MEXT] Moving forward with MEXT documents - review of draft-ietf-mip6-hareliability-04 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, 25 May 2009 16:28:21 -0000 Hi, On 2009/05/09, at 16:31, Romain KUNTZ wrote: >>>> I know there is an implementation of RFC5142 and draft-ietf-mip6- >>>> hareliability-04 for UMIP 0.4 for Linux. It was implemented as >>>> part of >>>> a project I joined. I think I can ask whether the code can be >>>> disclosed or not, if someone has interest. >>> >>> I'd be interested to look at it and possibly (depending on the size) >>> maintain it (if it is not done already) with the other patches I >>> have >>> for UMIP. >> >> I'd be interested as well since I was implementing this for Linux >> since I didn't >> see it in the mipv6-daemon git repo. > > I've contacted the person in charge of the code. I'll get back to > you as soon as I get an answer. The code has been released. It's an open source implementation (GPLv2) for UMIP 0.4 by Thales Communications. You can get more information and download the package on this page : http://software.nautilus6.org/HAHA/ Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr LSIIT - Networks and Protocols Team http://clarinet.u-strasbg.fr/~kuntz/ From charles.perkins@earthlink.net Tue May 26 10:03: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 8939528C226 for ; Tue, 26 May 2009 10:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.452 X-Spam-Level: X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_05=-1.11] 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 KeKmk6F3AwE3 for ; Tue, 26 May 2009 10:03:33 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id CCA5F28C257 for ; Tue, 26 May 2009 10:03:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=E7hLQdFIdODpI3RrmfL6ULMWwzZuy4trTNDpygiYZB7T6l2JE4IIEoVp+WFwYoCR; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.96.10.141] (helo=[10.166.254.133]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1M9059-0007eq-6O for mext@ietf.org; Tue, 26 May 2009 13:04:55 -0400 Message-ID: <4A1C2135.10009@earthlink.net> Date: Tue, 26 May 2009 10:04:53 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52fcb68d6a62bfb0697df197ddc0157773350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.96.10.141 Subject: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP 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, 26 May 2009 17:03:34 -0000 Hello folks, Last month, issue #18 showed up without any fanfare on the issues tracker list: http://trac.tools.ietf.org/wg/mext/trac/ticket/18 I'd like to initiate discussion on the points raised as part of issue #18. There are three main points, which can be discussed separately. In this note, I transcribe the discussion about the second of the three points. ============================================= Receiving ICMP Errors 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. ============================================= Please submit comments on the above discussion and proposal. If consensus is reached soon, I will incorporate the consensus text in a revision of rfc3775bis to be released before the next IETF. Regards, Charlie P. From charles.perkins@earthlink.net Tue May 26 10:12: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 3D48F3A6A70 for ; Tue, 26 May 2009 10:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 bGWlMRLfEXuz for ; Tue, 26 May 2009 10:12:19 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 12E933A69A7 for ; Tue, 26 May 2009 10:12:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HrwIDhSp01HlgfJLDW0lvSEHEOxasRY0lEIclC3ennWRLlAqQpATWMwTrQNYpkQt; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.96.10.141] (helo=[10.166.254.133]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1M8zx9-0003nS-6h for mext@ietf.org; Tue, 26 May 2009 12:56:39 -0400 Message-ID: <4A1C1F46.3000609@earthlink.net> Date: Tue, 26 May 2009 09:56:38 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f9169cb2b9330160e07fefab42814fa3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.96.10.141 Subject: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 1 of 3: "Receiving Home Address Destination Option" 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, 26 May 2009 17:12:20 -0000 Hello folks, Last month, issue #18 showed up without any fanfare on the issues tracker list: http://trac.tools.ietf.org/wg/mext/trac/ticket/18 I'd like to initiate discussion on the points raised as part of issue #18. There are three main points, which can be discussed separately. In this note, I transcribe the discussion about the first of the three points. ============================================= Receiving Home Address Destination Option 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 (RFC 2460, Section 4): "The contents and semantics of each extension header determine whether or not to proceed to the next header. Therefore, extension headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones." Especially when using IPsec with a non-null encryption for communication with the Home Agent, it would be required to process the ESP header to find out, if the packet contains a Binding Update. Proposal: Use the value in the Next Header field to determine, if a corresponding Binding Cache entry is required. That is, if the Next Header value is one of {50 (ESP), 51 (AH), 135 (Mobility Header)} normal processing of the next header should be done, else, it MUST be dropped, if there is no corresponding Binding Cache entry. The first two occur in Binding Updates to the Home Agent and are secured by IPSec, the third in Binding Updates to Correspondent Nodes which are secured by the Binding Key. 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. ============================================= Please submit comments on the above proposal. If consensus is reached soon, I will incorporate the consensus text in a revision of rfc3775bis to be released before the next IETF. Regards, Charlie P. From charles.perkins@earthlink.net Tue May 26 10:18: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 446D73A711B for ; Tue, 26 May 2009 10:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 z8cLwcoMlKb4 for ; Tue, 26 May 2009 10:18:11 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4F2473A6FDF for ; Tue, 26 May 2009 10:18:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Eac7TdwBeTG/F81r6g2EeDEdSqOk/+XZtP2RjVhpt0yDGYPePoflY5OQlKb67Oru; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.96.10.141] (helo=[10.166.254.133]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1M90JI-0008Uc-6J for mext@ietf.org; Tue, 26 May 2009 13:19:32 -0400 Message-ID: <4A1C24A2.8080503@earthlink.net> Date: Tue, 26 May 2009 10:19:30 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5266a09dda348dd158f7806773c31331df350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.96.10.141 Subject: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 3 of 3: "Receiving 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, 26 May 2009 17:18:12 -0000 Hello folks, Last month, issue #18 showed up without any fanfare on the issues tracker list: http://trac.tools.ietf.org/wg/mext/trac/ticket/18 I'd like to initiate discussion on the points raised as part of issue #18. There are three main points, which can be discussed separately. In this note, I transcribe the discussion about the third of the three points. ============================================= Receiving Binding Errors 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]. It is only defined that: "If the mobile node has no upper layer progress information, it MUST remove the (Binding Update List) entry (from the Correspondent Node) and route further communications through the home agent. It MAY also optionally start a return routability procedure (see Section 5.2)." 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. Proposal: 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. ============================================= Please submit comments on the above discussion and proposal. If consensus is reached soon, I will incorporate the consensus text in a revision of rfc3775bis to be released before the next IETF. Regards, Charlie P. From brian.haley@hp.com Tue May 26 19:55: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 640B43A6819 for ; Tue, 26 May 2009 19:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 2X3ztYn+tq+V for ; Tue, 26 May 2009 19:55:15 -0700 (PDT) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id 753123A69CD for ; Tue, 26 May 2009 19:55:15 -0700 (PDT) Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141]) by g4t0014.houston.hp.com (Postfix) with ESMTP id 09A7324425; Wed, 27 May 2009 02:56:56 +0000 (UTC) Received: from [192.168.1.102] (squirrel.fc.hp.com [15.11.146.57]) by g5t0029.atlanta.hp.com (Postfix) with ESMTP id 6DF0410030; Wed, 27 May 2009 02:56:55 +0000 (UTC) Message-ID: <4A1CABF6.6070005@hp.com> Date: Tue, 26 May 2009 22:56:54 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A1C2135.10009@earthlink.net> In-Reply-To: <4A1C2135.10009@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP 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: Wed, 27 May 2009 02:55:16 -0000 Hi Charlie, Charles E. Perkins wrote: > > Hello folks, > > Last month, issue #18 showed up without any fanfare on the > issues tracker list: > http://trac.tools.ietf.org/wg/mext/trac/ticket/18 > I'd like to initiate discussion on the points raised as part > of issue #18. There are three main points, which can be > discussed separately. In this note, I transcribe the > discussion about the second of the three points. > > ============================================= > > Receiving ICMP Errors > > 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,..." This text seems to be referring to Section 11.3.5. - Receiving ICMP Error Messages, not 11.3.6. > 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. What about ICMP Parameter Problem, Code 0? Those can be sent when either the Payload Proto field or MH header len are invalid, so I'm not sure this text is correct. Home Agent Section 10.2 refers back to Correspondent Node Section 9.2, which is where this text is. > 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. I would agree there could be a problem here, but not with this new text, I think it would actually cause a test failure with the current TAHI tests. Since the BU to the HA is using IPsec ESP, I'm not sure an attacker will be able to snoop on the traffic to reply with this "fake" ICMP while there's an outstanding BUL entry, will it? -Brian From brian.haley@hp.com Tue May 26 20:13: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 862B53A6CCA for ; Tue, 26 May 2009 20:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 WYqOa0r4blva for ; Tue, 26 May 2009 20:13:40 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by core3.amsl.com (Postfix) with ESMTP id 917CE3A6C71 for ; Tue, 26 May 2009 20:13:40 -0700 (PDT) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0027.austin.hp.com (Postfix) with ESMTP id 742D938501; Wed, 27 May 2009 03:15:15 +0000 (UTC) Received: from [192.168.1.102] (squirrel.fc.hp.com [15.11.146.57]) by g1t0039.austin.hp.com (Postfix) with ESMTP id E3AC834029; Wed, 27 May 2009 03:15:14 +0000 (UTC) Message-ID: <4A1CB042.4000007@hp.com> Date: Tue, 26 May 2009 23:15:14 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A1C1F46.3000609@earthlink.net> In-Reply-To: <4A1C1F46.3000609@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 1 of 3: "Receiving Home Address Destination Option" 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, 27 May 2009 03:13:41 -0000 Hi Charlie, Charles E. Perkins wrote: > > Hello folks, > > Last month, issue #18 showed up without any fanfare on the > issues tracker list: > http://trac.tools.ietf.org/wg/mext/trac/ticket/18 > I'd like to initiate discussion on the points raised as part > of issue #18. There are three main points, which can be > discussed separately. In this note, I transcribe the > discussion about the first of the three points. > > ============================================= > > Receiving Home Address Destination Option > > 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 (RFC 2460, Section 4): > "The contents and semantics of each extension header determine > whether or not to proceed to the next header. Therefore, extension > headers must be processed strictly in the order they appear in > the packet; a receiver must not, for example, scan through a > packet looking for a particular kind of extension header and > process that header prior to processing all preceding ones." 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. -Brian > Especially when using IPsec with a non-null encryption for > communication with the Home Agent, it would be required to > process the ESP header to find out, if the packet contains > a Binding Update. > > Proposal: Use the value in the Next Header field to determine, > if a corresponding Binding Cache entry is required. That is, > if the Next Header value is one of {50 (ESP), 51 (AH), 135 > (Mobility Header)} normal processing of the next header should > be done, else, it MUST be dropped, if there is no corresponding > Binding Cache entry. The first two occur in Binding Updates to > the Home Agent and are secured by IPSec, the third in Binding > Updates to Correspondent Nodes which are secured by the Binding > Key. 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. > > ============================================= > > Please submit comments on the above proposal. If consensus is > reached soon, I will incorporate the consensus text in a revision > of rfc3775bis to be released before the next IETF. > > Regards, > Charlie P. > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From brian.haley@hp.com Tue May 26 20:36: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 7CDD23A6D5C for ; Tue, 26 May 2009 20:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Z-G7jCFBQKDe for ; Tue, 26 May 2009 20:36:25 -0700 (PDT) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id D6AE73A6BF7 for ; Tue, 26 May 2009 20:35:54 -0700 (PDT) Received: from g4t0018.houston.hp.com (g4t0018.houston.hp.com [16.234.32.27]) by g4t0014.houston.hp.com (Postfix) with ESMTP id CF3A624209; Wed, 27 May 2009 03:37:36 +0000 (UTC) Received: from [192.168.1.102] (squirrel.fc.hp.com [15.11.146.57]) by g4t0018.houston.hp.com (Postfix) with ESMTP id 4BDD71002B; Wed, 27 May 2009 03:37:36 +0000 (UTC) Message-ID: <4A1CB57F.1000004@hp.com> Date: Tue, 26 May 2009 23:37:35 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A1C24A2.8080503@earthlink.net> In-Reply-To: <4A1C24A2.8080503@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 3 of 3: "Receiving 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: Wed, 27 May 2009 03:36:26 -0000 Hi Charlie, I might as well comment on all three of these :) Charles E. Perkins wrote: > > Hello folks, > > Last month, issue #18 showed up without any fanfare on the > issues tracker list: > http://trac.tools.ietf.org/wg/mext/trac/ticket/18 > I'd like to initiate discussion on the points raised as part > of issue #18. There are three main points, which can be > discussed separately. In this note, I transcribe the > discussion about the third of the three points. > > ============================================= > > Receiving Binding Errors > > 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]. It is only defined that: > "If the mobile node has no upper layer progress information, > it MUST remove the (Binding Update List) entry (from the > Correspondent Node) and route further communications through > the home agent. It MAY also optionally start a return > routability procedure (see Section 5.2)." > > 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. Will this actually ever happen? A MN should only ever get a Binding Error from it's HA in response to a BU, which might have Status set to 2. Otherwise, packets are being sent in the MN-HA tunnel, which doesn't use a HAO, which is what Status value 1 is for, which is what Section 11.3.6 is referring to. > Proposal: 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. I *guess* that's ok, depending on how it's inserted in this section, maybe the reporter can explain this issue better? -Brian From f1mauchl@hsr.ch Wed May 27 01:36:31 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 0796B28C0DE for ; Wed, 27 May 2009 01:36:31 -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 Cd5RPp0vH5le for ; Wed, 27 May 2009 01:36:30 -0700 (PDT) Received: from hsrmx1.hsr.ch (hsrmx1.hsr.ch [152.96.36.50]) by core3.amsl.com (Postfix) with ESMTP id D95953A6E5F for ; Wed, 27 May 2009 01:36:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by hsrmx1.hsr.ch (Postfix) with ESMTP id CC3B0210611; Wed, 27 May 2009 10:38:10 +0200 (CEST) Received: from hsrmx1.hsr.ch ([127.0.0.1]) by localhost (hsrmx1.hsr.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JW8uBu5GfwMV; Wed, 27 May 2009 10:37:53 +0200 (CEST) Received: from sid00102.hsr.ch (sid00101.hsr.ch [152.96.21.160]) by hsrmx1.hsr.ch (Postfix) with ESMTP id 364E6210593; Wed, 27 May 2009 10:37:51 +0200 (CEST) Received: from sid00100.hsr.ch (152.96.22.100) by sid00102.hsr.ch (152.96.21.160) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 27 May 2009 10:37:51 +0200 Received: from fabiannbneu (152.96.233.22) by smtp.hsr.ch (152.96.22.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 27 May 2009 10:37:51 +0200 From: Fabian Mauchle To: "'Brian Haley'" , "'Charles E. Perkins'" References: <4A1C24A2.8080503@earthlink.net> <4A1CB57F.1000004@hp.com> In-Reply-To: <4A1CB57F.1000004@hp.com> Date: Wed, 27 May 2009 10:37:37 +0200 Message-ID: <000901c9dea6$64a19be0$2de4d3a0$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnefKA4x+KB9Wb2RHKNzdfDQmtfUAAIbLgw Content-Language: de-ch Cc: 'mext' Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 3 of 3: "Receiving 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: Wed, 27 May 2009 08:36:31 -0000 -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von Brian Haley Gesendet: Mittwoch, 27. Mai 2009 05:38 An: Charles E. Perkins Cc: mext Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 3 of 3: "Receiving Binding Errors" Hi Charlie, I might as well comment on all three of these :) Charles E. Perkins wrote: >=20 > Hello folks, >=20 > Last month, issue #18 showed up without any fanfare on the > issues tracker list: > http://trac.tools.ietf.org/wg/mext/trac/ticket/18 > I'd like to initiate discussion on the points raised as part > of issue #18. There are three main points, which can be > discussed separately. In this note, I transcribe the > discussion about the third of the three points. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Receiving Binding Errors >=20 > 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]. It is only defined that: > "If the mobile node has no upper layer progress information, > it MUST remove the (Binding Update List) entry (from the > Correspondent Node) and route further communications through > the home agent. It MAY also optionally start a return > routability procedure (see Section 5.2)." >=20 > 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. Will this actually ever happen? A MN should only ever get a Binding = Error from it's HA in response to a BU, which might have Status set to 2. = Otherwise, packets are being sent in the MN-HA tunnel, which doesn't use a HAO, = which is what Status value 1 is for, which is what Section 11.3.6 is referring = to. > Proposal: 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. I *guess* that's ok, depending on how it's inserted in this section, = maybe the reporter can explain this issue better? -Brian ------------------------------------------ I will try to: - 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. Fabian From f1mauchl@hsr.ch Wed May 27 06: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 E497D3A6A1E for ; Wed, 27 May 2009 06:53: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 zCSesDTYNTYX for ; Wed, 27 May 2009 06:53:02 -0700 (PDT) Received: from hsrmx1.hsr.ch (hsrmx1.hsr.ch [152.96.36.50]) by core3.amsl.com (Postfix) with ESMTP id 9DD863A67FD for ; Wed, 27 May 2009 06:53:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by hsrmx1.hsr.ch (Postfix) with ESMTP id 8367D2105EA; Wed, 27 May 2009 15:42:13 +0200 (CEST) Received: from hsrmx1.hsr.ch ([127.0.0.1]) by localhost (hsrmx1.hsr.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oqiqzh-taGpK; Wed, 27 May 2009 15:41:50 +0200 (CEST) Received: from sid00102.hsr.ch (sid00101.hsr.ch [152.96.21.160]) by hsrmx1.hsr.ch (Postfix) with ESMTP id 1AD91210795; Wed, 27 May 2009 15:41:42 +0200 (CEST) Received: from sid00100.hsr.ch (152.96.22.100) by sid00102.hsr.ch (152.96.21.160) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 27 May 2009 15:41:43 +0200 Received: from fabiannbneu (152.96.233.22) by smtp.hsr.ch (152.96.22.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 27 May 2009 15:41:42 +0200 From: Fabian Mauchle To: "'Brian Haley'" , "'Charles E. Perkins'" References: <4A1C2135.10009@earthlink.net> <4A1CABF6.6070005@hp.com> In-Reply-To: <4A1CABF6.6070005@hp.com> Date: Wed, 27 May 2009 15:41:28 +0200 Message-ID: <000001c9ded0$d735c940$85a15bc0$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcneduFwkfJZBuzwSN2EA7mRr5yKUQAT6DMA Content-Language: de-ch Cc: 'mext' Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP 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: Wed, 27 May 2009 13:53:03 -0000 -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von Brian Haley Gesendet: Mittwoch, 27. Mai 2009 04:57 An: Charles E. Perkins Cc: mext Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP Errors" Hi Charlie, Charles E. Perkins wrote: >=20 > Hello folks, >=20 > Last month, issue #18 showed up without any fanfare on the > issues tracker list: > http://trac.tools.ietf.org/wg/mext/trac/ticket/18 > I'd like to initiate discussion on the points raised as part > of issue #18. There are three main points, which can be > discussed separately. In this note, I transcribe the > discussion about the second of the three points. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Receiving ICMP Errors >=20 > 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,..." This text seems to be referring to Section 11.3.5. - Receiving ICMP = Error Messages, not 11.3.6. > The following situations are not clear or problematic: >=20 > 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? >=20 > 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. What about ICMP Parameter Problem, Code 0? Those can be sent when = either the Payload Proto field or MH header len are invalid, so I'm not sure this = text is correct. Home Agent Section 10.2 refers back to Correspondent Node = Section 9.2, which is where this text is. > 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. I would agree there could be a problem here, but not with this new text, = I think it would actually cause a test failure with the current TAHI tests. = Since the BU to the HA is using IPsec ESP, I'm not sure an attacker will be able = to snoop on the traffic to reply with this "fake" ICMP while there's an = outstanding BUL entry, will it? -Brian ------------------------------------------- What do to with ICMP Parameter Problem, Code 0, is not defined in = RFC3775, is it? (Maybe it should be defined?) I think snooping the BU is possible since it is allowed to use a null-encryption algorithm. But even if encryption is used, the IP-header = and HAO are still transmitted clear. Maybe using IPsec ESP also for the ICMP traffic between the MN and HA = would help? Fabian From ietf@montavont.net Wed May 27 08:01: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 2006C3A6C00 for ; Wed, 27 May 2009 08:01:34 -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 swwF8W-CGxrW for ; Wed, 27 May 2009 08:01:33 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id A2BE03A6B2B for ; Wed, 27 May 2009 08:01:32 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so1104342eyd.31 for ; Wed, 27 May 2009 08:02:38 -0700 (PDT) Received: by 10.210.30.10 with SMTP id d10mr50286ebd.39.1243436558542; Wed, 27 May 2009 08:02:38 -0700 (PDT) Received: from ?192.168.1.7? (ARennes-259-1-76-129.w90-59.abo.wanadoo.fr [90.59.227.129]) by mx.google.com with ESMTPS id 7sm6882032eyg.47.2009.05.27.08.02.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 May 2009 08:02:37 -0700 (PDT) From: Nicolas Montavont To: Frank Xia In-Reply-To: <001001c9d96e$1fe7e190$3e0c7c0a@china.huawei.com> X-Priority: 3 References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> <008f01c9d959$67dad080$3e0c7c0a@china.huawei.com> <756ABF87-88CD-4487-B437-49B05933FF93@montavont.net> <001001c9d96e$1fe7e190$3e0c7c0a@china.huawei.com> Message-Id: 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: Wed, 27 May 2009 17:02:34 +0200 X-Mailer: Apple Mail (2.935.3) Cc: mext Subject: Re: [MEXT] About the flow binding charter item 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, 27 May 2009 15:01:34 -0000 Hi Frank, On May 20, 2009, at 7:12 PM, Frank Xia wrote: > Hi Nicolas > > Does this make sense? > > MN installs a flow binding to HA, and > HA revokes the flow binding later because > of acounting, mainteance and other reasons. As said in previous emails in this thread, yes, this is a valid use case IMHO. In the current specification, the HA can refuse to install a flow binding when a MN sends a BU with flow binding options. We might need to define a way for the HA to cancel a flow binding at anytime. But again, this is different from the HA installing rules for the MN. Nicolas > > > BR > Frank > > ----- Original Message ----- From: "Nicolas Montavont" > > To: "Frank Xia" > Cc: "marcelo bagnulo braun" ; "mext" >; "Julien Laganier" ; "Jari > Arkko" > Sent: Wednesday, May 20, 2009 11:19 AM > Subject: Re: [MEXT] About the flow binding charter item > > >> Hi, >> >> On May 20, 2009, at 4:43 PM, Frank Xia wrote: >> >>> Hi Marcelo >>> >>> Texts are copied here for simplification: >>>> 2- whether the information should be sent from the MN to the HA >>>> only >>>> or it should also be sent from the HA to the MN and if the >>>> information exchanged in each direction should affect the CoA and/ >>>> or >>>> the HA address. >>> >>> IMHO, we should define operation from HA to MN. >> >> I disagree: the HA has no way to know about which address is >> allocated to which interface. >> For me, Flow Binding in MIPv6 should only define the final mapping >> of flows on current CoAs. How these policies are set up is out of >> scope of MIPv6. If the HA (or more probably some other entity in >> the network) wants to install rules on the interface usage of a >> mobile node, it can use another protocol that has no reason to be >> part of MIPv6. >> >> Nicolas >> >>> >>> >>> A very simple analogy, there is "Binding Revocation >>> for IPv6 Mobility", and I think there are the same reasons >>> to have ""Flow Binding Revocation for IPv6 Mobility" >>> >>> In 3GPP network, operators always tend to control >>> the networks. >>> >>> We have some details in our draft >>> http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt. >>> >>> BR >>> Frank >>> >>> ----- Original Message ----- From: "marcelo bagnulo braun" >> > >>> To: "mext" >>> Cc: "Jari Arkko" ; "Julien Laganier" >> > >>> Sent: Wednesday, May 20, 2009 8:04 AM >>> Subject: [MEXT] About the flow binding charter item >>> >>> >>>> Hi, >>>> >>>> There seems to be some discrepancies about the MEXT charter item >>>> regarding the work on flow bindings. >>>> Since the charter is the guide for our work, it would be >>>> important to >>>> clarify it, so we can have a unified interpretation of the charter. >>>> Please note that what it is in the charter is not cast in stone, >>>> but >>>> it seems to reflect previous consensus and we need good reasons to >>>> change it. >>>> >>>> So, the current charter item about flow bindings reads: >>>> >>>> - 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]. >>>> >>>> The first problem with this text is the use and interpretation of >>>> the >>>> word policy. Since the policy word may have a broad interpretation. >>>> it would be important to make the charter more explicit about the >>>> expected work. We understand that it is the WG consensus that what >>>> need to be exchanged is a solution for the exchange of flow binding >>>> rules. >>>> >>>> So, we understand that it would be more explicit to replace the >>>> usage >>>> of the expression Flow/binding policies exchange by Flow Binding >>>> rules exchange. Would that reflect with the WG interpretation? >>>> >>>> Second, the current charter item explicitly mentions that the >>>> proposed approach must support sending flow binding information >>>> from >>>> the MN to the HA and also from the HA to the MN. Moreover, the >>>> current charter talks about influencing not only the selection of >>>> the >>>> CoA but also the selection of the HA address. However, our >>>> current WG >>>> document does not supports sending information from the HA and it >>>> does not cover the possibility of influencing the HA address. So, >>>> one >>>> possible interpretation of the charter would be that the MN sends >>>> flow binding information to influence the CoA selection and the HA >>>> sends flow binding information to influence the HA address >>>> selection. >>>> Other interpretation is that both the MN and the HA send >>>> information >>>> regarding both the HA address and the CoA selection. >>>> >>>> So, we would like that the WG express their opinion on both items >>>> mentioned above: >>>> >>>> 1- whether we should replace Flow/binding policies exchange by Flow >>>> Binding rules exchange in the charter >>>> >>>> 2- whether the information should be sent from the MN to the HA >>>> only >>>> or it should also be sent from the HA to the MN and if the >>>> information exchanged in each direction should affect the CoA and/ >>>> or >>>> the HA address. >>>> >>>> Regards, Julien and marcelo >>>> >>>> >>>> _______________________________________________ >>>> 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 root@core3.amsl.com Wed May 27 10:45: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 61D493A6CF6; Wed, 27 May 2009 10:45: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: <20090527174501.61D493A6CF6@core3.amsl.com> Date: Wed, 27 May 2009 10:45:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-14.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: Wed, 27 May 2009 17:45:01 -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 : Multiple Care-of Addresses Registration Author(s) : R. Wakikawa, et al. Filename : draft-ietf-monami6-multiplecoa-14.txt Pages : 44 Date : 2009-05-27 According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-14.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-monami6-multiplecoa-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-27104403.I-D@ietf.org> --NextPart-- From brian.haley@hp.com Wed May 27 11:21: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 BCA263A6892 for ; Wed, 27 May 2009 11:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 fGArU9z+3twJ for ; Wed, 27 May 2009 11:21:52 -0700 (PDT) Received: from g5t0008.atlanta.hp.com (g5t0008.atlanta.hp.com [15.192.0.45]) by core3.amsl.com (Postfix) with ESMTP id 64BB43A6A6F for ; Wed, 27 May 2009 11:21:48 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g5t0008.atlanta.hp.com (Postfix) with ESMTP id F340824469; Wed, 27 May 2009 18:23:29 +0000 (UTC) Received: from [192.168.1.102] (squirrel.fc.hp.com [15.11.146.57]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id AFF9A2402E; Wed, 27 May 2009 18:23:28 +0000 (UTC) Message-ID: <4A1D851F.4090904@hp.com> Date: Wed, 27 May 2009 14:23:27 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Fabian Mauchle References: <4A1C24A2.8080503@earthlink.net> <4A1CB57F.1000004@hp.com> <000901c9dea6$64a19be0$2de4d3a0$@ch> In-Reply-To: <000901c9dea6$64a19be0$2de4d3a0$@ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: 'mext' Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 3 of 3: "Receiving 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: Wed, 27 May 2009 18:21:53 -0000 Fabian Mauchle wrote: > -----Ursprüngliche Nachricht----- > Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von > Brian Haley > Gesendet: Mittwoch, 27. Mai 2009 05:38 > An: Charles E. Perkins > Cc: mext > Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding > errors"], part 3 of 3: "Receiving Binding Errors" > > Hi Charlie, > > I might as well comment on all three of these :) > > Charles E. Perkins wrote: >> Hello folks, >> >> Last month, issue #18 showed up without any fanfare on the >> issues tracker list: >> http://trac.tools.ietf.org/wg/mext/trac/ticket/18 >> I'd like to initiate discussion on the points raised as part >> of issue #18. There are three main points, which can be >> discussed separately. In this note, I transcribe the >> discussion about the third of the three points. >> >> ============================================= >> >> Receiving Binding Errors >> >> 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]. It is only defined that: >> "If the mobile node has no upper layer progress information, >> it MUST remove the (Binding Update List) entry (from the >> Correspondent Node) and route further communications through >> the home agent. It MAY also optionally start a return >> routability procedure (see Section 5.2)." >> >> 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. > > Will this actually ever happen? A MN should only ever get a Binding Error > from > it's HA in response to a BU, which might have Status set to 2. Otherwise, > packets are being sent in the MN-HA tunnel, which doesn't use a HAO, which > is > what Status value 1 is for, which is what Section 11.3.6 is referring to. > >> Proposal: 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. > > I *guess* that's ok, depending on how it's inserted in this section, maybe > the > reporter can explain this issue better? > > -Brian > ------------------------------------------ > > I will try to: > > - 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. But wouldn't the BUL entry show that it's communicating with its HA, so it would use the tunnel? There wouldn't be a HAO inserted in that case. How will it attempt this direct communication? If the MN somehow disables mobility and removes it's home binding, then it won't be inserting a HAO, just using basic IPv6. > - 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. If the MN knows the tunnel is invalid, it should update it's binding at the HA. -Brian From brian.haley@hp.com Wed May 27 11:28: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 9D7C83A6DFD for ; Wed, 27 May 2009 11:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 QVy2FtvXW714 for ; Wed, 27 May 2009 11:28:36 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id 9F7553A6818 for ; Wed, 27 May 2009 11:28:36 -0700 (PDT) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g4t0017.houston.hp.com (Postfix) with ESMTP id C438338443; Wed, 27 May 2009 18:30:18 +0000 (UTC) Received: from [192.168.1.102] (squirrel.fc.hp.com [15.11.146.57]) by g1t0039.austin.hp.com (Postfix) with ESMTP id E67FE3405C; Wed, 27 May 2009 18:30:17 +0000 (UTC) Message-ID: <4A1D86B8.70002@hp.com> Date: Wed, 27 May 2009 14:30:16 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Fabian Mauchle References: <4A1C2135.10009@earthlink.net> <4A1CABF6.6070005@hp.com> <000001c9ded0$d735c940$85a15bc0$@ch> In-Reply-To: <000001c9ded0$d735c940$85a15bc0$@ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: 'mext' Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP 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: Wed, 27 May 2009 18:28:37 -0000 Fabian Mauchle wrote: > -----Ursprüngliche Nachricht----- > Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von > Brian Haley > Gesendet: Mittwoch, 27. Mai 2009 04:57 > An: Charles E. Perkins > Cc: mext > Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding > errors"], part 2 of 3: "Receiving ICMP Errors" > > Hi Charlie, > > Charles E. Perkins wrote: >> Hello folks, >> >> Last month, issue #18 showed up without any fanfare on the >> issues tracker list: >> http://trac.tools.ietf.org/wg/mext/trac/ticket/18 >> I'd like to initiate discussion on the points raised as part >> of issue #18. There are three main points, which can be >> discussed separately. In this note, I transcribe the >> discussion about the second of the three points. >> >> ============================================= >> >> Receiving ICMP Errors >> >> 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,..." > > This text seems to be referring to Section 11.3.5. - Receiving ICMP Error > Messages, not 11.3.6. > >> 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. > > What about ICMP Parameter Problem, Code 0? Those can be sent when either > the > Payload Proto field or MH header len are invalid, so I'm not sure this text > is > correct. Home Agent Section 10.2 refers back to Correspondent Node Section > 9.2, > which is where this text is. > >> 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. > > I would agree there could be a problem here, but not with this new text, I > think > it would actually cause a test failure with the current TAHI tests. Since > the > BU to the HA is using IPsec ESP, I'm not sure an attacker will be able to > snoop > on the traffic to reply with this "fake" ICMP while there's an outstanding > BUL > entry, will it? > > -Brian > ------------------------------------------- > > What do to with ICMP Parameter Problem, Code 0, is not defined in RFC3775, > is it? (Maybe it should be defined?) 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)). If there isn't anyone to notify then it will be dropped. > I think snooping the BU is possible since it is allowed to use a > null-encryption algorithm. But even if encryption is used, the IP-header and > HAO are still transmitted clear. But does an attacker know there's a Mobility Header here? > Maybe using IPsec ESP also for the ICMP traffic between the MN and HA would > help? But this is a failure before processing the Mobility Header, so I think following RFC 4443 rules applies. -Brian From gerardog@qualcomm.com Wed May 27 16:24: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 D2DF93A6D52 for ; Wed, 27 May 2009 16:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.36 X-Spam-Level: X-Spam-Status: No, score=-105.36 tagged_above=-999 required=5 tests=[AWL=1.239, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 tmTAIEnwywBi for ; Wed, 27 May 2009 16:24:55 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 918CD3A6957 for ; Wed, 27 May 2009 16:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1243466798; x=1275002798; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20marcelo=20bagnulo=20braun=20, =20mext=20|CC:=20Jari=20Arkko=20,=0D=0A=20=20=20=20=20=20=20=20Julien=20Lagan ier=0D=0A=09|Date: =20Wed,=2027=20May=202009=2016:25:55=20-0700|Subject:=20R E:=20[MEXT]=20About=20the=20flow=20binding=20charter=20it em|Thread-Topic:=20[MEXT]=20About=20the=20flow=20binding =20charter=20item|Thread-Index:=20AcnZS6ueuw33ZqNZTuCnG02 5MimDoQF1adBA|Message-ID:=20<057632CE4CE10D45A1A3D6D19206 C3A3EE49DEB4@NASANEXMB08.na.qualcomm.com>|References:=20< 4A0E0DE4.9060500@it.uc3m.es>=0D=0A=09<200905191751.39403. julien.laganier.IETF@googlemail.com>=0D=0A=09<4A12F05E.90 004@it.uc3m.es>=0D=0A=09<200905200757.24445.julien.lagani er.IETF@googlemail.com>=0D=0A=20<4A13FFE5.2050804@it.uc3m .es>|In-Reply-To:=20<4A13FFE5.2050804@it.uc3m.es> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5628"=3B=20a=3D"18667771"; bh=wJSVP2Pyfpak7z9VGZBkp3zp2YANEXClnymCiEzbvUQ=; b=CdUzgYys0R8cOCVDzZ0RP1U2gwVzy7as9kVIUnIBW1S+tupLkN975n77 DBZLyxVJ2jE9sZZh1znKs/8IMyWa9rOzvVSn6kS4PWUOvcfmjc32uIY5C GeXH2kPwQEsSUwLlZ7P3Ue4PpSMZVIBx3+cIE7gTDsrwBymY3ep1uXcD+ k=; X-IronPort-AV: E=McAfee;i="5300,2777,5628"; a="18667771" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2009 16:26:38 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4RNQbl8023416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 May 2009 16:26:38 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4RNQWDC004262 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 May 2009 16:26:33 -0700 (PDT) Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.132]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Wed, 27 May 2009 16:26:32 -0700 From: "Giaretta, Gerardo" To: marcelo bagnulo braun , mext Date: Wed, 27 May 2009 16:25:55 -0700 Thread-Topic: [MEXT] About the flow binding charter item Thread-Index: AcnZS6ueuw33ZqNZTuCnG025MimDoQF1adBA Message-ID: <057632CE4CE10D45A1A3D6D19206C3A3EE49DEB4@NASANEXMB08.na.qualcomm.com> References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> In-Reply-To: <4A13FFE5.2050804@it.uc3m.es> 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: Julien Laganier , Jari Arkko Subject: Re: [MEXT] About the flow binding charter item 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, 27 May 2009 23:24:56 -0000 Hi Marcelo, Sorry for the late input due to vacation (yes, we have some vacation also i= n US :-) > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > marcelo bagnulo braun > Sent: Wednesday, May 20, 2009 6:05 AM > To: mext > Cc: Jari Arkko; Julien Laganier > Subject: [MEXT] About the flow binding charter item >=20 > Hi, >=20 > There seems to be some discrepancies about the MEXT charter item > regarding the work on flow bindings. > Since the charter is the guide for our work, it would be important to > clarify it, so we can have a unified interpretation of the charter. > Please note that what it is in the charter is not cast in stone, but > it seems to reflect previous consensus and we need good reasons to > change it. >=20 > So, the current charter item about flow bindings reads: >=20 > - 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]. >=20 > The first problem with this text is the use and interpretation of the > word policy. Since the policy word may have a broad interpretation. > it would be important to make the charter more explicit about the > expected work. We understand that it is the WG consensus that what > need to be exchanged is a solution for the exchange of flow binding > rules. >=20 > So, we understand that it would be more explicit to replace the usage > of the expression Flow/binding policies exchange by Flow Binding > rules exchange. Would that reflect with the WG interpretation? >=20 > Second, the current charter item explicitly mentions that the > proposed approach must support sending flow binding information from > the MN to the HA and also from the HA to the MN. Moreover, the > current charter talks about influencing not only the selection of the > CoA but also the selection of the HA address. However, our current WG > document does not supports sending information from the HA and it > does not cover the possibility of influencing the HA address. So, one > possible interpretation of the charter would be that the MN sends > flow binding information to influence the CoA selection and the HA > sends flow binding information to influence the HA address selection. > Other interpretation is that both the MN and the HA send information > regarding both the HA address and the CoA selection. >=20 > So, we would like that the WG express their opinion on both items > mentioned above: >=20 > 1- whether we should replace Flow/binding policies exchange by Flow > Binding rules exchange in the charter >=20 Agree > 2- whether the information should be sent from the MN to the HA only > or it should also be sent from the HA to the MN and if the > information exchanged in each direction should affect the CoA and/or > the HA address. >=20 >From a protocol point of view it would be easy to allow both but from an ar= chitectural point of view we need to understand if that makes sense. As alr= eady commented there is no other entity in the picture which knows about th= e current application running in the terminal, the accesses available to th= e terminal and their status and characteristics, the resources available to= the terminal than the terminal itself. The HA cannot know any of those ele= ments which are needed to make a consistent flow routing decision. For this= reason I think it should be unidirectional from the MN to HA. What the network can provide are pseudo-static information about how to use= different accesses when they are available based on the environment. This = kind of information is usually provided as configuration information and sh= ould not be carried over Mobile IP (e.g. OMA-DM is a more suitable protocol= to configure such kind of policies in the terminal) Thanks Gerardo=20 > Regards, Julien and marcelo >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From f1mauchl@hsr.ch Thu May 28 00:08: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 A80F83A6BC0 for ; Thu, 28 May 2009 00:08:54 -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 Ahl-FuCNU+-B for ; Thu, 28 May 2009 00:08:53 -0700 (PDT) Received: from hsrmx1.hsr.ch (hsrmx1.hsr.ch [152.96.36.50]) by core3.amsl.com (Postfix) with ESMTP id 696923A6A5D for ; Thu, 28 May 2009 00:08:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by hsrmx1.hsr.ch (Postfix) with ESMTP id E107721079D; Thu, 28 May 2009 09:10:34 +0200 (CEST) Received: from hsrmx1.hsr.ch ([127.0.0.1]) by localhost (hsrmx1.hsr.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WBzH9V-5ZITq; Thu, 28 May 2009 09:10:30 +0200 (CEST) Received: from sid00102.hsr.ch (sid00101.hsr.ch [152.96.21.160]) by hsrmx1.hsr.ch (Postfix) with ESMTP id 3209521086C; Thu, 28 May 2009 09:08:24 +0200 (CEST) Received: from sid00100.hsr.ch (152.96.22.100) by sid00102.hsr.ch (152.96.21.160) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 28 May 2009 09:08:06 +0200 Received: from fabiannbneu (152.96.233.22) by smtp.hsr.ch (152.96.22.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 28 May 2009 09:08:05 +0200 From: Fabian Mauchle To: "'Brian Haley'" References: <4A1C24A2.8080503@earthlink.net> <4A1CB57F.1000004@hp.com> <000901c9dea6$64a19be0$2de4d3a0$@ch> <4A1D851F.4090904@hp.com> In-Reply-To: <4A1D851F.4090904@hp.com> Date: Thu, 28 May 2009 09:07:52 +0200 Message-ID: <000e01c9df63$0476ca20$0d645e60$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acne+G4WBIcD7j2rRJWt1MUAh58TFgAZwcTg Content-Language: de-ch Cc: 'mext' Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 3 of 3: "Receiving 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: Thu, 28 May 2009 07:08:54 -0000 -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von Brian Haley Gesendet: Mittwoch, 27. Mai 2009 20:23 An: Mauchle Fabian (f1mauchl@hsr.ch) Cc: 'mext' Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 3 of 3: "Receiving Binding Errors" Fabian Mauchle wrote: > -----Urspr=FCngliche Nachricht----- > Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag = von > Brian Haley > Gesendet: Mittwoch, 27. Mai 2009 05:38 > An: Charles E. Perkins > Cc: mext > Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding > errors"], part 3 of 3: "Receiving Binding Errors" >=20 > Hi Charlie, >=20 > I might as well comment on all three of these :) >=20 > Charles E. Perkins wrote: >> Hello folks, >> >> Last month, issue #18 showed up without any fanfare on the >> issues tracker list: >> http://trac.tools.ietf.org/wg/mext/trac/ticket/18 >> I'd like to initiate discussion on the points raised as part >> of issue #18. There are three main points, which can be >> discussed separately. In this note, I transcribe the >> discussion about the third of the three points. >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Receiving Binding Errors >> >> 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]. It is only defined that: >> "If the mobile node has no upper layer progress information, >> it MUST remove the (Binding Update List) entry (from the >> Correspondent Node) and route further communications through >> the home agent. It MAY also optionally start a return >> routability procedure (see Section 5.2)." >> >> 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. >=20 > Will this actually ever happen? A MN should only ever get a Binding = Error > from > it's HA in response to a BU, which might have Status set to 2. = Otherwise, > packets are being sent in the MN-HA tunnel, which doesn't use a HAO, = which > is > what Status value 1 is for, which is what Section 11.3.6 is referring = to. >=20 >> Proposal: 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. >=20 > I *guess* that's ok, depending on how it's inserted in this section, = maybe > the > reporter can explain this issue better? >=20 > -Brian > ------------------------------------------ >=20 > I will try to: >=20 > - 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. But wouldn't the BUL entry show that it's communicating with its HA, so = it would use the tunnel? There wouldn't be a HAO inserted in that case. How = will it attempt this direct communication? ------------------------------------------- According to Section 10.4.2 the HA acts as a correspondent node when directly communicating with the MN. I suppose the opposite (MN sending directly to HA) should also apply. Also the conditions for Route Optimization (sending packets directly to the correspondent node, which = is the HA in this case) on p.109 are true for the HA BUL entry. Or is there = a rule I have overseen? ------------------------------------------- If the MN somehow disables mobility and removes it's home binding, then = it won't be inserting a HAO, just using basic IPv6. > - 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. If the MN knows the tunnel is invalid, it should update it's binding at = the HA. -Brian ------------------------------------------- IF it knows. I'm not sure if the MN will recognize that the other tunnel endpoint has failed. Fabian From f1mauchl@hsr.ch Thu May 28 00:39: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 601E43A6C90 for ; Thu, 28 May 2009 00:39:23 -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 t+fW5-N4jsCy for ; Thu, 28 May 2009 00:39:22 -0700 (PDT) Received: from hsrmx2.hsr.ch (hsrmx2.hsr.ch [152.96.36.51]) by core3.amsl.com (Postfix) with ESMTP id EEB5C3A6C79 for ; Thu, 28 May 2009 00:39:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by hsrmx2.hsr.ch (Postfix) with ESMTP id D340D38175; Thu, 28 May 2009 09:41:03 +0200 (CEST) Received: from hsrmx2.hsr.ch ([127.0.0.1]) by localhost (hsrmx2.hsr.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4cmmg1D566Ew; Thu, 28 May 2009 07:41:02 +0000 (UTC) Received: from sid00101.hsr.ch (sid00100.hsr.ch [152.96.20.160]) by hsrmx2.hsr.ch (Postfix) with ESMTP id 6625638167; Thu, 28 May 2009 09:41:02 +0200 (CEST) Received: from sid00100.hsr.ch (152.96.22.100) by sid00101.hsr.ch (152.96.20.160) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 28 May 2009 09:41:02 +0200 Received: from fabiannbneu (152.96.233.22) by smtp.hsr.ch (152.96.22.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 28 May 2009 09:41:02 +0200 From: Fabian Mauchle To: "'Brian Haley'" References: <4A1C2135.10009@earthlink.net> <4A1CABF6.6070005@hp.com> <000001c9ded0$d735c940$85a15bc0$@ch> <4A1D86B8.70002@hp.com> In-Reply-To: <4A1D86B8.70002@hp.com> Date: Thu, 28 May 2009 09:40:49 +0200 Message-ID: <001201c9df67$9eab9400$dc02bc00$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acne+TzEWO05IkKySv6zO6h2MIrOwQAbOBYQ Content-Language: de-ch Cc: 'mext' Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP 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: Thu, 28 May 2009 07:39:23 -0000 -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von Brian Haley Gesendet: Mittwoch, 27. Mai 2009 20:30 An: Mauchle Fabian (f1mauchl@hsr.ch) Cc: 'mext' Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP Errors" Fabian Mauchle wrote: > -----Urspr=FCngliche Nachricht----- > Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag = von > Brian Haley > Gesendet: Mittwoch, 27. Mai 2009 04:57 > An: Charles E. Perkins > Cc: mext > Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding > errors"], part 2 of 3: "Receiving ICMP Errors" >=20 > Hi Charlie, >=20 > Charles E. Perkins wrote: >> Hello folks, >> >> Last month, issue #18 showed up without any fanfare on the >> issues tracker list: >> http://trac.tools.ietf.org/wg/mext/trac/ticket/18 >> I'd like to initiate discussion on the points raised as part >> of issue #18. There are three main points, which can be >> discussed separately. In this note, I transcribe the >> discussion about the second of the three points. >> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Receiving ICMP Errors >> >> 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,..." >=20 > This text seems to be referring to Section 11.3.5. - Receiving ICMP = Error > Messages, not 11.3.6. >=20 >> 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. >=20 > What about ICMP Parameter Problem, Code 0? Those can be sent when = either > the > Payload Proto field or MH header len are invalid, so I'm not sure this text > is > correct. Home Agent Section 10.2 refers back to Correspondent Node Section > 9.2, > which is where this text is. >=20 >> 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. >=20 > I would agree there could be a problem here, but not with this new = text, I > think > it would actually cause a test failure with the current TAHI tests. = Since > the > BU to the HA is using IPsec ESP, I'm not sure an attacker will be able = to > snoop > on the traffic to reply with this "fake" ICMP while there's an = outstanding > BUL > entry, will it? >=20 > -Brian > ------------------------------------------- >=20 > What do to with ICMP Parameter Problem, Code 0, is not defined in = RFC3775, > is it? (Maybe it should be defined?) 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)). If there isn't anyone to notify then it will be dropped. > I think snooping the BU is possible since it is allowed to use a > null-encryption algorithm. But even if encryption is used, the = IP-header and > HAO are still transmitted clear. But does an attacker know there's a Mobility Header here? ------------------------------------ It will only know if null-encryption is used. But when monitoring a = Wireless link, the first packet a MN sends with a HAO is very likely to be a BU. ------------------------------------ > Maybe using IPsec ESP also for the ICMP traffic between the MN and HA would > help? But this is a failure before processing the Mobility Header, so I think following RFC 4443 rules applies. -Brian ------------------------------------ I can' quite follow you. I was thinking of securing all Binding traffic (Binding Update and any method of error reporting including ICMP) Fabian From f1mauchl@hsr.ch Thu May 28 00:46: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 547183A6AC2 for ; Thu, 28 May 2009 00:46:22 -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 ODdDXk8M4XqN for ; Thu, 28 May 2009 00:46:17 -0700 (PDT) Received: from hsrmx2.hsr.ch (hsrmx2.hsr.ch [152.96.36.51]) by core3.amsl.com (Postfix) with ESMTP id B78B13A68D5 for ; Thu, 28 May 2009 00:45:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by hsrmx2.hsr.ch (Postfix) with ESMTP id 6F5C738175; Thu, 28 May 2009 09:47:26 +0200 (CEST) Received: from hsrmx2.hsr.ch ([127.0.0.1]) by localhost (hsrmx2.hsr.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eodyigk7Duxc; Thu, 28 May 2009 07:47:25 +0000 (UTC) Received: from sid00102.hsr.ch (sid00101.hsr.ch [152.96.21.160]) by hsrmx2.hsr.ch (Postfix) with ESMTP id 1A18E38167; Thu, 28 May 2009 09:47:25 +0200 (CEST) Received: from sid00100.hsr.ch (152.96.22.100) by sid00102.hsr.ch (152.96.21.160) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 28 May 2009 09:47:25 +0200 Received: from fabiannbneu (152.96.233.22) by smtp.hsr.ch (152.96.22.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 28 May 2009 09:47:25 +0200 From: Fabian Mauchle To: "'Brian Haley'" , "'Charles E. Perkins'" References: <4A1C1F46.3000609@earthlink.net> <4A1CB042.4000007@hp.com> In-Reply-To: <4A1CB042.4000007@hp.com> Date: Thu, 28 May 2009 09:47:12 +0200 Message-ID: <001401c9df68$82d21a50$88764ef0$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcneeWYIt2f1m6pyRguIYwymB0erfQA7qPGQ Content-Language: de-ch Cc: 'mext' Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 1 of 3: "Receiving Home Address Destination Option" 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, 28 May 2009 07:46:22 -0000 -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von Brian Haley Gesendet: Mittwoch, 27. Mai 2009 05:15 An: Charles E. Perkins Cc: mext Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 1 of 3: "Receiving Home Address Destination Option" Hi Charlie, Charles E. Perkins wrote: >=20 > Hello folks, >=20 > Last month, issue #18 showed up without any fanfare on the > issues tracker list: > http://trac.tools.ietf.org/wg/mext/trac/ticket/18 > I'd like to initiate discussion on the points raised as part > of issue #18. There are three main points, which can be > discussed separately. In this note, I transcribe the > discussion about the first of the three points. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Receiving Home Address Destination Option >=20 > 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." >=20 > 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 (RFC 2460, Section 4): > "The contents and semantics of each extension header determine > whether or not to proceed to the next header. Therefore, extension > headers must be processed strictly in the order they appear in > the packet; a receiver must not, for example, scan through a > packet looking for a particular kind of extension header and > process that header prior to processing all preceding ones." 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. -Brian --------------------------------- Would be interesting how this looks like. Maybe you could post some = (pseudo) code which shows the processing and drop decision of the Home Address Option? Fabian From hesham@elevatemobile.com Thu May 28 03:47: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 483393A6A0E for ; Thu, 28 May 2009 03:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_40=-0.185, 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 yxLdjJ4xOI2q for ; Thu, 28 May 2009 03:47:01 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 193E03A6889 for ; Thu, 28 May 2009 03:47:00 -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 1M9cVm-0002vu-FR for ; Thu, 28 May 2009 20:06:58 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 28 May 2009 20:06:55 +1000 From: Hesham Soliman To: mext Message-ID: Thread-Topic: Important considerations for directionality of flow bindings Thread-Index: AcnffAdoGi/aI6bjOkmHZuHuvPZ68w== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [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: Thu, 28 May 2009 10:47:02 -0000 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 From julien.laganier.ietf@googlemail.com Thu May 28 03:47: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 626963A6A0E for ; Thu, 28 May 2009 03:47:37 -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 gjVXhRNlDgF6 for ; Thu, 28 May 2009 03:47:30 -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 6004F3A6B33 for ; Thu, 28 May 2009 03:47:29 -0700 (PDT) Received: by bwz22 with SMTP id 22so5338340bwz.37 for ; Thu, 28 May 2009 03:48:22 -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=+XFKTOfaEkTCq8uMooJG1retqrHkV3uQTJO9R6WwrIg=; b=KOZRTuFoNjt8WrjmVUuVW0tfvFVFgV58pRK7Bgl7Ozcegg7ExTZbNJrDY4jbZV363c S/iOKben5lvY9IcvPwVemn9EF2INKJ1dxQ2J9Umz9Sq1kpme315akZLEdDqZQ3SK/w1W M4qa76/go24d8ISrZnqUNaRADrR2OEevFI9lY= 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=TwVg4qUFtF87GiZpNjTsipzCy0BjAguCRoAZcEKa93UhR9DlSjSzW3wNIE+HsYHHNH wK0tHAXXXhBKN7wei2eBqzxEMc4HNZHcPStxHV+ucD/PeLPbDpamNrrEozloIBlK3IKS ZklHqdyp2AGd8ual3+JotRkpW1WtPMg69WjMw= MIME-Version: 1.0 Received: by 10.204.62.78 with SMTP id w14mr1084112bkh.13.1243507702493; Thu, 28 May 2009 03:48:22 -0700 (PDT) In-Reply-To: <057632CE4CE10D45A1A3D6D19206C3A3EE49DEB4@NASANEXMB08.na.qualcomm.com> References: <4A0E0DE4.9060500@it.uc3m.es> <200905191751.39403.julien.laganier.IETF@googlemail.com> <4A12F05E.90004@it.uc3m.es> <200905200757.24445.julien.laganier.IETF@googlemail.com> <4A13FFE5.2050804@it.uc3m.es> <057632CE4CE10D45A1A3D6D19206C3A3EE49DEB4@NASANEXMB08.na.qualcomm.com> Date: Thu, 28 May 2009 12:48:22 +0200 Message-ID: <7ad6d6db0905280348q3ba7442y19ed2568961282ca@mail.gmail.com> From: Julien Laganier To: "Giaretta, Gerardo" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jari Arkko , mext Subject: Re: [MEXT] About the flow binding charter item 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, 28 May 2009 10:47:37 -0000 Hello, On Thu, May 28, 2009 at 1:25 AM, Giaretta, Gerardo wrote: > > [...] >> So, we would like that the WG express their opinion on both items >> mentioned above: >> >> 1- whether we should replace Flow/binding policies exchange by Flow >> Binding rules exchange in the charter >> > > Agree +1 >> 2- whether the information should be sent from the MN to the HA only >> or it should also be sent from the HA to the MN and if the >> information exchanged in each direction should affect the CoA and/or >> the HA address. >> > > From a protocol point of view it would be easy to allow both but from an = architectural point of view we need to understand if that makes sense. As a= lready commented there is no other entity in the picture which knows about = the current application running in the terminal, the accesses available to = the terminal and their status and characteristics, the resources available = to the terminal than the terminal itself. The HA cannot know any of those e= lements which are needed to make a consistent flow routing decision. For th= is reason I think it should be unidirectional from the MN to HA. > > What the network can provide are pseudo-static information about how to u= se different accesses when they are available based on the environment. Thi= s kind of information is usually provided as configuration information and = should not be carried over Mobile IP (e.g. OMA-DM is a more suitable protoc= ol to configure such kind of policies in the terminal) > I agree with everything Gerardo said above, so no point in repeating it. I'd like to add one point which in my view is key to this discussion: Functionally, the goal of the flow binding mechanism is to bind a specific flow onto an access whose characteristics (availability, bandwidth, RTT, packet loss, etc. etc.) matches best the requirements of this flow under the constraint of the current MN situation (e.g. characteristics of the other accesses) However here in the MEXT WG we are specifying a flow binding mechanism for Mobile IPv6, and thus the flow binding rules are specified in terms of CoA choice for a given flow -- they are NOT specified in terms of which access to choose. Now on the MN side choosing a CoA equals choosing an access, because the MN knows onto which access a given CoA is configured. Thus, having the MN establishing flow binding rules satisfies the goal of the flow binding mechanism. But if you look on the HA side, the HA has no idea onto which access is a given CoA configured. Thus, having the HA establishing flow binding rules DOES NOT satisfies the goal of the flow binding mechanism, and is thus essentially useless. Thus if someone is interested in having the network being in control of the flow binding mechanism, that can't be done in terms of ruling a specific CoA choice for a given flow, and thus that is unrelated to MIPv6, and by derivation to MEXT. I don't know which place would be more appropriate to tackle that issue, Gerardo mentionned OMA-DM, but I can also see MIF addressing that sort of issue once they have concluded the problem space analysis. Thanks. --julien From behcetsarikaya@yahoo.com Thu May 28 07:34: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 D8E763A6D91 for ; Thu, 28 May 2009 07:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[AWL=1.431, 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 0NTdW4EgPA2j for ; Thu, 28 May 2009 07:34:38 -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 B3FD028C24D for ; Thu, 28 May 2009 07:34:37 -0700 (PDT) Received: from [68.142.237.88] by n10.bullet.re3.yahoo.com with NNFMP; 28 May 2009 14:36:01 -0000 Received: from [67.195.9.81] by t4.bullet.re3.yahoo.com with NNFMP; 28 May 2009 14:36:01 -0000 Received: from [67.195.9.105] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 28 May 2009 14:36:01 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 28 May 2009 14:36:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 101575.24715.bm@omp109.mail.gq1.yahoo.com Received: (qmail 59313 invoked by uid 60001); 28 May 2009 14:36:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243521361; bh=mqcOowQ2Gmgtd7II9vDF30XfGmfakhViuQ3lYb6DMAw=; 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=EEMrZSPDXLuDPtzeH/f9g9cGCn9OMmG46OsJMfrgHWBzpEp8sxw/z9o2daGKn/3MAG08rD55DPhgyqfw5wA8RDsV7IG1YdnZVPp59qZQH6pMHMgj6bfAm6hnVRoqMVPHx9pL1nnQG4t05tV82HYPJnCGx5oI1+35bdk69FMiw8I= 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=a5GzsWSLx8poht00zvjPfGPZyyGNoaUaY9CrVoLUtPycvV+MlLpC7LLxTmVh2WU7dxryPafrZDDCwJ6651//oof2iEzu8Z7xmnK9+oFgExOAXC/IfkVXBaakF4v4N7dymzj3X/rn1gDikKtgS20vUis79t+4gunzsRUU+i+phMk=; Message-ID: <235731.39626.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: ZA6QtH8VM1nKH6tNURTg6a5ReCrqIhf7oAifXPgH769bcteDR4qKBuGWseB_o46r.SS9IRg.MhwTaeLjbp1876.dlghH4GTL9PYA01p8nCGLpV0E4Bt7r_cQAhwDg9R1H0N1mQBii1BdhrXykdr1tNedVHqNNrn433.Xzhu9S9FXf15Ht6Y_.2mcn2s1z_c1fSa6ydHk_1Ql1tvQw80WbmCYaPZ6HT7CvJbUS6cINZWcSCnFY1IRIEABRznIOr7WoHmYOPyY2vWUPBxD79ovNJKQelMEk0aIhqJr0eNT.tlXZf03imEOlhhjnb1Xbb4r5bYu4NOWvuooWxj5wjXei4YhdvCfaaVX5tD0 Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Thu, 28 May 2009 07:36:00 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: Date: Thu, 28 May 2009 07:36:00 -0700 (PDT) From: Behcet Sarikaya To: Hesham Soliman , mext In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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: Thu, 28 May 2009 14:34:44 -0000 Hi Hesham,=0A=A0 To your long message, I have a very short reply: You're sa= ying two things:=0A- you don't want to change your draft,=0A- you admit tha= t you forgot to raise the issue below when monami6 discussed the charter an= d clearly decided to include HA to MN direction.=0A=0ACheers,=0A=0ABehcet= =0A=0A=0A=0A----- Original Message ----=0AFrom: Hesham Soliman =0ATo: mext =0ASent: Thursday, May 28, 2009 5:= 06:55 AM=0ASubject: [MEXT] Important considerations for directionality of f= low bindings=0A=0AHi all, =0A=0AI've always been a fan of the IETF's tradit= ion of rough concensus (as=0Aopposed to voting). To me, this implies that y= ou need to get your point=0Aacross and get other people to see that point o= f view. As opposed to other=0Aorganisations that require their members to v= ote and end up with rigid=0Apolitical positions.=0A=0AThe chairs asked us a= bout the directionality question of the flows bindings.=0AOn the charter qu= estion, I said that the charter doesn't need to mention how=0Aa solution sh= ould work, but rather what problem needs to be solved. Hence,=0Aas far as t= he charter is concerned, I'm fine with transferring rules=0A"between" the M= N and HA without mentioning directions.=0A=0ANevertheless, we still need to= agree on identifying the requirement for the=0Asolution. And when it comes= to this, I'm strongly against voting and I'll=0Apractice this by explainin= g in this email why I think rules can not be=0Atransferred from the HA to t= he MN and that the only direction that makes=0Asense in MIP is MN->HA. I'll= deliberately ignore arguments like "some people=0Awant this" or "an SDO wa= nts this". They fall under the "meaningless words"=0Acategory and I'm incap= able of discussing them because they come with voting=0Aattitudes. They all= need to be justified if the WG wants to have a technical=0A_discussion_. = =0A=0AHere are my reasons:=0A=0A1. The HA does not know whether a CoA is ti= ed to a certain access=0Atechnology. It is one thing for the HA to send a m= essage saying "forward=0Aport 80 traffic on a wifi link" (a policy) and a c= ompletely different thing=0Ato say "forward port 80 traffic using CoA 3ffe:= :1" (a rule).=0A=0A2. You might argue that the HA can be told by the MN tha= t 3ffe::1 is tied to=0Aa wifi access, so what's the problem now? The proble= m is that the HA has no=0Aidea about dynamic changes on that wifi link. It = doesn't know if it's=0Acongested, it doesn't know what application is using= port 80 (it doesn't=0Ahave to be web traffic) or port 8000 for that matter= and doesn't even know=0Aif the AP of that wifi link works at all. Finally,= it doesn't know the=0Auser's policies or other admin policies for that MN.= This type of=0Ainformation needs to be sent regularly because it changes a= ll the time and=0Arequires serious cross layer integration including someti= mes layer 8=0Aintegration! It's completely impractical.=0A=0A3. If the HA i= nstalled rules in the MN, what happens if the MN wants to=0Achange those ru= les. Say the wifi link went down, or the MN's wifi interface=0Awent down an= d it wants to move that traffic to another interface. Would the=0AHA reject= such move? Does the MN have to justify to the HA why it needs to=0Amove tr= affic? Does that involve writing a letter perhaps?=0AIf you say "well in th= at case, the HA should let the MN move the traffic"=0Athen I'll ask you: wh= at's the point of having the HA install this stuff if=0Ait has no authority= and how does it know the reason for the MN's movement of=0Athe flow? =0ATh= e way to control how users do things is to incentivise them with charging= =0Amodels and show them that things work better on certain technologies, no= t by=0Ainstalling rules that can't be followed. It's a broken mindset and w= e've=0Aknown that it's broken for a long time.=0A=0A4. Some people mentione= d that the HA should be able to revoke flows on the=0AMN. I'm perfectly fin= e with that, just extend the binding revocation draft=0Ato handle flows and= the rest is pretty straight forward.=0A=0AFinally, I'll indulge in a true = story that happened to me a few years ago=0Awhen I found that my wifi link = wasn't working in a hotel (no radio) and=0Acalled the help desk. He insiste= d that the link was up an I insisted that it=0Awasn't. When I asked him to = tell me how he knows the link is up he said: I=0Acan ping the AP! Of course= after another 5 minutes of trying to convince him=0Athat pinging the AP do= esn't mean the radio is actually working he sent=0Asomeone to the hotel who= in turn realised that the radio was not working.=0AFor those people who wa= nt rules to be transferred from the HA to the MN,=0Aplease think of your HA= as this help desk person, i.e. it has no clue about=0Awhat's happening at = the other end.=0A=0AI hope this helps with the realisation that decisions c= an't be made here=0Abased on voting and that there is little merit to trans= ferring rules from=0Athe HA to the MN. Policies can be transferred without = any problems, but not=0Arules. =0A=0AHesham=0A=0A=0A=0A=0A=0A______________= _________________________________=0AMEXT mailing list=0AMEXT@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/mext=0A=0A=0A=0A From brian.haley@hp.com Thu May 28 08:08: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 F364728C287 for ; Thu, 28 May 2009 08:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 h9DhyiPb7bIX for ; Thu, 28 May 2009 08:08:31 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by core3.amsl.com (Postfix) with ESMTP id 2A5A128C2D3 for ; Thu, 28 May 2009 08:07:43 -0700 (PDT) Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141]) by g5t0006.atlanta.hp.com (Postfix) with ESMTP id C6A32C0F5; Thu, 28 May 2009 15:09:24 +0000 (UTC) Received: from [192.168.1.102] (squirrel.fc.hp.com [15.11.146.57]) by g5t0029.atlanta.hp.com (Postfix) with ESMTP id 2E02C10018; Thu, 28 May 2009 15:09:23 +0000 (UTC) Message-ID: <4A1EA923.4080001@hp.com> Date: Thu, 28 May 2009 11:09:23 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Fabian Mauchle References: <4A1C1F46.3000609@earthlink.net> <4A1CB042.4000007@hp.com> <001401c9df68$82d21a50$88764ef0$@ch> In-Reply-To: <001401c9df68$82d21a50$88764ef0$@ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'mext' Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 1 of 3: "Receiving Home Address Destination Option" 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, 28 May 2009 15:08:32 -0000 Fabian Mauchle wrote: >> Receiving Home Address Destination Option >> >> 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 (RFC 2460, Section 4): >> "The contents and semantics of each extension header determine >> whether or not to proceed to the next header. Therefore, extension >> headers must be processed strictly in the order they appear in >> the packet; a receiver must not, for example, scan through a >> packet looking for a particular kind of extension header and >> process that header prior to processing all preceding ones." > > 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. > > -Brian > --------------------------------- > > Would be interesting how this looks like. Maybe you could post some (pseudo) > code which shows the processing and drop decision of the Home Address > Option? Since this was done on a proprietary Unix, I'll just try and paraphrase: 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? You know, I might have just not read the proposal correctly. I think the: "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..." text is fine. I don't think any other next header types would be valid. Sorry about any confusion. -Brian From brian.haley@hp.com Thu May 28 08:08: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 EA7D93A6D30 for ; Thu, 28 May 2009 08:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 cgH6YHgVDJMi for ; Thu, 28 May 2009 08:08:32 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id 808BC3A6F14 for ; Thu, 28 May 2009 08:08:04 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g4t0017.houston.hp.com (Postfix) with ESMTP id 7511C3849A; Thu, 28 May 2009 15:09:47 +0000 (UTC) Received: from [192.168.1.102] (squirrel.fc.hp.com [15.11.146.57]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id 4A0AE24076; Thu, 28 May 2009 15:09:37 +0000 (UTC) Message-ID: <4A1EA927.7080408@hp.com> Date: Thu, 28 May 2009 11:09:27 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Fabian Mauchle References: <4A1C2135.10009@earthlink.net> <4A1CABF6.6070005@hp.com> <000001c9ded0$d735c940$85a15bc0$@ch> <4A1D86B8.70002@hp.com> <001201c9df67$9eab9400$dc02bc00$@ch> In-Reply-To: <001201c9df67$9eab9400$dc02bc00$@ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'mext' Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP 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: Thu, 28 May 2009 15:08:33 -0000 Fabian Mauchle wrote: >>> Receiving ICMP Errors >>> >>> 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,..." >> This text seems to be referring to Section 11.3.5. - Receiving ICMP Error >> Messages, not 11.3.6. >> >>> 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. >> What about ICMP Parameter Problem, Code 0? Those can be sent when either >> the >> Payload Proto field or MH header len are invalid, so I'm not sure this > text >> is >> correct. Home Agent Section 10.2 refers back to Correspondent Node > Section >> 9.2, >> which is where this text is. >> >>> 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. >> I would agree there could be a problem here, but not with this new text, I >> think >> it would actually cause a test failure with the current TAHI tests. Since >> the >> BU to the HA is using IPsec ESP, I'm not sure an attacker will be able to >> snoop >> on the traffic to reply with this "fake" ICMP while there's an outstanding >> BUL >> entry, will it? >> >> -Brian >> ------------------------------------------- >> >> What do to with ICMP Parameter Problem, Code 0, is not defined in RFC3775, >> is it? (Maybe it should be defined?) > > 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)). > > If there isn't anyone to notify then it will be dropped. > > >> I think snooping the BU is possible since it is allowed to use a >> null-encryption algorithm. But even if encryption is used, the IP-header > and >> HAO are still transmitted clear. > > But does an attacker know there's a Mobility Header here? > ------------------------------------ > > It will only know if null-encryption is used. But when monitoring a Wireless > link, the first packet a MN sends with a HAO is very likely to be a BU. >From RFC 3776: o When securing Binding Updates, Binding Acknowledgements, and prefix discovery, both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [3] header in transport mode and MUST use a non-null payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection. Null encryption is not allowed according to this. 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, maybe someone else has an opinion on this? > ------------------------------------ >> Maybe using IPsec ESP also for the ICMP traffic between the MN and HA > would >> help? > > But this is a failure before processing the Mobility Header, so I think > following RFC 4443 rules applies. > > -Brian > ------------------------------------ > > I can' quite follow you. I was thinking of securing all Binding traffic > (Binding Update and any method of error reporting including ICMP) Section 9.2 covers processing Mobility Headers for all nodes, the third and fourth checks will send ICMP errors on failure, that's what I was referring to. Protecting ICMP errors would require new IPsec SPDs, which I don't think is feasible. -Brian From brian.haley@hp.com Thu May 28 08:09: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 0D02A3A6F49 for ; Thu, 28 May 2009 08:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 tb+fVdFHdlk7 for ; Thu, 28 May 2009 08:09:22 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by core3.amsl.com (Postfix) with ESMTP id 7468E3A6F14 for ; Thu, 28 May 2009 08:09:22 -0700 (PDT) Received: from g4t0009.houston.hp.com (g4t0009.houston.hp.com [16.234.32.26]) by g1t0027.austin.hp.com (Postfix) with ESMTP id 2AD023856D; Thu, 28 May 2009 15:10:56 +0000 (UTC) Received: from [192.168.1.102] (squirrel.fc.hp.com [15.11.146.57]) by g4t0009.houston.hp.com (Postfix) with ESMTP id 48ADEC051; Thu, 28 May 2009 15:10:56 +0000 (UTC) Message-ID: <4A1EA97F.3010109@hp.com> Date: Thu, 28 May 2009 11:10:55 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Fabian Mauchle References: <4A1C24A2.8080503@earthlink.net> <4A1CB57F.1000004@hp.com> <000901c9dea6$64a19be0$2de4d3a0$@ch> <4A1D851F.4090904@hp.com> <000e01c9df63$0476ca20$0d645e60$@ch> In-Reply-To: <000e01c9df63$0476ca20$0d645e60$@ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'mext' Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 3 of 3: "Receiving 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: Thu, 28 May 2009 15:09:24 -0000 Fabian Mauchle wrote: >>> Receiving Binding Errors >>> >>> 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]. It is only defined that: >>> "If the mobile node has no upper layer progress information, >>> it MUST remove the (Binding Update List) entry (from the >>> Correspondent Node) and route further communications through >>> the home agent. It MAY also optionally start a return >>> routability procedure (see Section 5.2)." >>> >>> 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. >> Will this actually ever happen? A MN should only ever get a Binding Error >> from >> it's HA in response to a BU, which might have Status set to 2. Otherwise, >> packets are being sent in the MN-HA tunnel, which doesn't use a HAO, which >> is >> what Status value 1 is for, which is what Section 11.3.6 is referring to. >> >>> Proposal: 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. >> I *guess* that's ok, depending on how it's inserted in this section, maybe >> the >> reporter can explain this issue better? >> >> -Brian >> ------------------------------------------ >> >> I will try to: >> >> - 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. > > But wouldn't the BUL entry show that it's communicating with its HA, so it > would > use the tunnel? There wouldn't be a HAO inserted in that case. How will it > attempt this direct communication? > ------------------------------------------- > > According to Section 10.4.2 the HA acts as a correspondent node when > directly communicating with the MN. I suppose the opposite (MN sending > directly to HA) should also apply. Also the conditions for Route > Optimization (sending packets directly to the correspondent node, which is > the HA in this case) on p.109 are true for the HA BUL entry. Or is there a > rule I have overseen? Yes, I almost forgot about that paragraph in Section 10.4.2, direct communication between the MN and HA doesn't seem to be explained in the same manner, it's kind-of just inferred from Section 11.1. > ------------------------------------------- > If the MN somehow disables mobility and removes it's home binding, then it > won't > be inserting a HAO, just using basic IPv6. > >> - 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. > > If the MN knows the tunnel is invalid, it should update it's binding at the > HA. > > -Brian > ------------------------------------------- > > IF it knows. I'm not sure if the MN will recognize that the other tunnel > endpoint has failed. I would guess that no forward progress is being made would be the way? Either way, I didn't have any problem inserting this text, I was just curious about the details. Section 10.4.2 provides the reason. Thanks, -Brian From yuri.ismailov@ericsson.com Thu May 28 08:27: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 7432D3A69AE for ; Thu, 28 May 2009 08:27:06 -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 n22pJpIz9jHG for ; Thu, 28 May 2009 08:27:05 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3C1A93A6CCE for ; Thu, 28 May 2009 08:27:04 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-e0-4a1ead9a3479 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 3A.93.30868.A9DAE1A4; Thu, 28 May 2009 17:28:27 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 May 2009 17:12: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 May 2009 15:19:24 +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: AcnffAdoGi/aI6bjOkmHZuHuvPZ68wAFUO+w References: From: "Yuri Ismailov" To: "Hesham Soliman" , "mext" X-OriginalArrivalTime: 28 May 2009 15:12:07.0992 (UTC) FILETIME=[AACD5B80:01C9DFA6] X-Brightmail-Tracker: AAAAAA== 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: Thu, 28 May 2009 15:27:06 -0000 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 need any standardization. In other words, I'm superior of my HA. This situation is not unthinkable, I actually 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. 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,=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. 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_.=20 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?=20 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.=20 Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From behcetsarikaya@yahoo.com Thu May 28 08:52: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 64F173A6F1C for ; Thu, 28 May 2009 08:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=1.418, 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 nlkgQA4GgmDH for ; Thu, 28 May 2009 08:52:08 -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 C8F643A6FC1 for ; Thu, 28 May 2009 08:51:48 -0700 (PDT) Received: from [68.142.237.89] by n9.bullet.re3.yahoo.com with NNFMP; 28 May 2009 15:53:29 -0000 Received: from [67.195.9.81] by t5.bullet.re3.yahoo.com with NNFMP; 28 May 2009 15:53:29 -0000 Received: from [67.195.9.105] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 28 May 2009 15:53:29 -0000 Received: from [127.0.0.1] by omp109.mail.gq1.yahoo.com with NNFMP; 28 May 2009 15:54:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 24732.18749.bm@omp109.mail.gq1.yahoo.com Received: (qmail 12338 invoked by uid 60001); 28 May 2009 15:53:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243526009; bh=qX426Tr2Rqhpt7wowCETRzw7LszF2tjHsqy0EXaIgJQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=qOOJqvJQu3eJhuna93nQF0rEwVnZwNlt5mzuHKTlM/WeGvi5E4Qa85AvbLf+/tKN8OiTF4slh04Bv9gpn+bq0AHyKlw4UHv+sqPb0UF9nVi4mFnwHsR0g9H2GM/Ih01SQiw9hFkVbC/NyIWmR+kgCZEztkNSZbFoTekYpQxi3Ig= 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; b=gzEATP80mznuQEAkwJbB5MoA8PeXN/sNeocZmWrD+vFsvAiIFgQugcBk08VhOpjbhZ2NQf8qeJB66kYhamhrWMs8+1HgSb3KOsov2qqwMjer5mkXxbYLsIxxjakUzQR34SHv8x8oXPEL6A1tTO7ThhOBWpHyrjy2vtb+RCYFW3c=; Message-ID: <165783.11444.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: xCiVtuwVM1loM5_JkK50Hznl4SgIHSQT0ipPJ9UO6wuNT.wNWh2VFB_tFRwjrJZjVZB5U3l9.2FX8hkJDAa_vxBwLBmvl0bfSq4q3YozbGYpWjEAgg0aOzBv_L5lnFyLKme3zK6_9vnpe3LaigW4yxYpKgrqQz7Rn3AaJM20vDtUA4bXNSP4.pIvn5yJAPMhmPBrmHTPKSl64CK6CK3UyMCLGg7sCOIiK4LzbfUSkguU5DaqUCbbsghHuo8tl3v.RaQj_Im6UJeDCaaETSQ0bv2c71QBdibLXD36McYgjmtKJhBQLHFbFO11lJl.9i6XkOGa6LLqfJw- Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Thu, 28 May 2009 08:53:28 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: Date: Thu, 28 May 2009 08:53:28 -0700 (PDT) From: Behcet Sarikaya To: Yuri Ismailov , Hesham Soliman , mext In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Thu, 28 May 2009 15:52:13 -0000 Absolutely. Network control has been a way of life in mobility starting with RFC 3543 which was first written in 2001. When it comes to flows, there will be no network control? Give me break! Regards, Behcet ----- Original Message ---- From: Yuri Ismailov To: Hesham Soliman ; mext Sent: Thursday, May 28, 2009 8:19:24 AM Subject: Re: [MEXT] Important considerations for directionality of flow bindings 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 need any standardization. In other words, I'm superior of my HA. This situation is not unthinkable, I actually 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. 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 From hesham@elevatemobile.com Thu May 28 22:07: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 3C6713A6BCF for ; Thu, 28 May 2009 22:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.779 X-Spam-Level: X-Spam-Status: No, score=-2.779 tagged_above=-999 required=5 tests=[AWL=1.820, 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 Apv5brKIvAGO for ; Thu, 28 May 2009 22:07: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 7BDFA3A6B56 for ; Thu, 28 May 2009 22:07:23 -0700 (PDT) Received: from [115.130.19.217] by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1M9uKu-0006a6-55; Fri, 29 May 2009 15:09:00 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 29 May 2009 15:08:47 +1000 From: Hesham Soliman To: Yuri Ismailov , mext Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flow bindings Thread-Index: AcnffAdoGi/aI6bjOkmHZuHuvPZ68wAFUO+wACKQJm0= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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, 29 May 2009 05:07:26 -0000 > 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 > need any standardization. In other words, I'm superior of my HA. > This situation is not unthinkable, => Oh I completely agree with you that it's a not unthinkable and can/should be possible right now with MIP. I actually think this scenario proves my point. I have three questions for you though: 1. Do you really think you can make your HA know everything I mentioned on my email even if it's just for your own MNs (presumably you'll have more than one MN, you're a researcher :) ) ? I mean, even if it's just for your own household, we're still talking about potentially a dozen MNs. Will you define all apps in the HA that any of your MNs might use and all the requirements for those apps? Let's say one of your children installs a new app on their PC, do they then have to call you at work and tell you about this app and all it's properties? I'm intentionally being simplistic to highlight the issues here. Let's say you (Yuri) are ok with doing all that, how many people do you think can do that? 2. What did doing everything in step 1 actually do for you? I mean, what's the benefit here? You already administer all your MNs and you could run the same policies on all of them. 3. Having the HA under your own administration doesn't mean you will know what's happening at the other end. My help desk incident involved me picking up the phone and calling someone. I think we want things to be done automatically. I actually 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. => Sure. > > Difference between policies and rules is a convertion step. 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. => But the MN knows those conditions at least as well as the HA. So what benefits can the HA add? I'm still talking about your deployment scenario above. Not to mention that the HA can be completely bypassed with RO. > > 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. => So what's the point of having the HA send those rules in the first place if ultimately the MN chooses to do what it sees fit? I still don't see the benefits here. Can you list some of the benefits that you see for sending rules (not policies) from the HA to the MN? > > BTW, what is the numerical representation of "rough consensus"? I assume > is when majority is for, is it so? => Of course it involves majority but I don't know what numbers the chairs have in mind. Best to ask them if it's 70, 80 90 ...etc Hesham > > 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 From f1mauchl@hsr.ch Fri May 29 00:30: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 747E73A6E3A for ; Fri, 29 May 2009 00:30:17 -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=[AWL=0.000, 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 1il3izXnOp9A for ; Fri, 29 May 2009 00:30:14 -0700 (PDT) Received: from hsrmx2.hsr.ch (hsrmx2.hsr.ch [152.96.36.51]) by core3.amsl.com (Postfix) with ESMTP id 380BC3A6EED for ; Fri, 29 May 2009 00:30:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by hsrmx2.hsr.ch (Postfix) with ESMTP id B895138007; Fri, 29 May 2009 09:31:53 +0200 (CEST) Received: from hsrmx2.hsr.ch ([127.0.0.1]) by localhost (hsrmx2.hsr.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bH+--PToYmMI; Fri, 29 May 2009 07:31:52 +0000 (UTC) Received: from sid00102.hsr.ch (sid00101.hsr.ch [152.96.21.160]) by hsrmx2.hsr.ch (Postfix) with ESMTP id CB91D37F56; Fri, 29 May 2009 09:31:52 +0200 (CEST) Received: from sid00100.hsr.ch (152.96.22.100) by sid00102.hsr.ch (152.96.21.160) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 29 May 2009 09:31:53 +0200 Received: from fabiannbneu (152.96.233.22) by smtp.hsr.ch (152.96.22.100) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 29 May 2009 09:31:53 +0200 From: Fabian Mauchle To: "'Brian Haley'" References: <4A1C2135.10009@earthlink.net> <4A1CABF6.6070005@hp.com> <000001c9ded0$d735c940$85a15bc0$@ch> <4A1D86B8.70002@hp.com> <001201c9df67$9eab9400$dc02bc00$@ch> <4A1EA927.7080408@hp.com> In-Reply-To: <4A1EA927.7080408@hp.com> Date: Fri, 29 May 2009 09:31:38 +0200 Message-ID: <001b01c9e02f$81160b00$83422100$@ch> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnfppyqGClJiwOfQ9mLcaefz1EgUwAht/8Q Content-Language: de-ch Cc: 'mext' Subject: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP 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: Fri, 29 May 2009 07:30:17 -0000 -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von Brian Haley Gesendet: Donnerstag, 28. Mai 2009 17:09 An: Mauchle Fabian (f1mauchl@hsr.ch) Cc: 'mext' Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP Errors" Fabian Mauchle wrote: >>> Receiving ICMP Errors >>> >>> 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,..." >> This text seems to be referring to Section 11.3.5. - Receiving ICMP = Error >> Messages, not 11.3.6. >> >>> 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. >> What about ICMP Parameter Problem, Code 0? Those can be sent when = either >> the >> Payload Proto field or MH header len are invalid, so I'm not sure = this > text >> is >> correct. Home Agent Section 10.2 refers back to Correspondent Node > Section >> 9.2, >> which is where this text is. >> >>> 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. >> I would agree there could be a problem here, but not with this new = text, I >> think >> it would actually cause a test failure with the current TAHI tests. Since >> the >> BU to the HA is using IPsec ESP, I'm not sure an attacker will be = able to >> snoop >> on the traffic to reply with this "fake" ICMP while there's an outstanding >> BUL >> entry, will it? >> >> -Brian >> ------------------------------------------- >> >> What do to with ICMP Parameter Problem, Code 0, is not defined in RFC3775, >> is it? (Maybe it should be defined?) >=20 > It's defined in RFC 4443: >=20 > A node receiving this ICMPv6 message MUST notify the upper-layer > process if the relevant process can be identified (see Section 2.4, > (d)). >=20 > If there isn't anyone to notify then it will be dropped. >=20 >=20 >> I think snooping the BU is possible since it is allowed to use a >> null-encryption algorithm. But even if encryption is used, the = IP-header > and >> HAO are still transmitted clear. >=20 > But does an attacker know there's a Mobility Header here? > ------------------------------------ >=20 > It will only know if null-encryption is used. But when monitoring a Wireless > link, the first packet a MN sends with a HAO is very likely to be a = BU. >From RFC 3776: o When securing Binding Updates, Binding Acknowledgements, and prefix discovery, both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [3] header in transport mode and MUST use a non-null payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection. Null encryption is not allowed according to this. --------------------------------------- ESP makes a difference between encryption and authentication (See: RFC = 4303 Section 3.2). Either one may be null (but not both at the same time). = Mobile IPv6 requires non-null authentication, but there is no statement about encryption. Fabian From yuri.ismailov@ericsson.com Fri May 29 00:33: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 C4CA33A6E22 for ; Fri, 29 May 2009 00:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 K5ckWwh9QYUC for ; Fri, 29 May 2009 00:33:29 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 11AB53A6D6C for ; Fri, 29 May 2009 00:33:28 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-94-4a1f902f2a7f Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F7.E0.30868.F209F1A4; Fri, 29 May 2009 09:35:11 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 09:35:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E02F.FEFA8E8E" Date: Fri, 29 May 2009 09:35:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MEXT] Important considerations for directionality of flow bindings Thread-Index: AcngL/7IXlqLIpabSWGhemQe4pAvLQ== From: "Yuri Ismailov" To: "Hesham Soliman" , "mext" X-OriginalArrivalTime: 29 May 2009 07:35:10.0938 (UTC) FILETIME=[FF60ABA0:01C9E02F] X-Brightmail-Tracker: AAAAAA== 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, 29 May 2009 07:33:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E02F.FEFA8E8E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. 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 ------_=_NextPart_001_01C9E02F.FEFA8E8E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hesham,

This is nice story and makes some sense = for the=20 discssion, 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=20 him/her to check access point in some room. Would it be the same = reaction? I=20 assume not. By that I mean that if, for example, I'll install home agent = in my=20 home network, I can make it know anything I want about MN, and more = intresting=20 is that how I will do it, does not require any standardization. In other = words, I'm=20 superior of my HA.

This situation is not unthinkable, = I personally believe that this is much = more=20 efficient way of using HA fnctionality as opposed to big service = providers who=20 will have to fight with scalability and performance. However, one does = not=20 exclude another.

Difference between policies and rules is = a convertion=20 step. Is there any reason to restrict where such convertion takes place? = True=20 that a HA does not know what is going on in the access network, on the = other=20 hand HA may know what is the network condition between HA and = correspondent=20 node. Either of this information is important, if not equally=20 important.

It is not really difficult to let an MN = to reject=20 rules sent by HA, which in my view would be quite natural. This implies = that HA=20 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=20 confirmation.

BTW, what is the numerical representation = of "rough=20 consensus"? I assume is when majority is for, is it so?

Yuri

------_=_NextPart_001_01C9E02F.FEFA8E8E-- From hesham@elevatemobile.com Fri May 29 23:12:59 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 777513A69C8 for ; Fri, 29 May 2009 23:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=0.532, 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 gGBQvCsqcROE for ; Fri, 29 May 2009 23:12:58 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 20E283A696D for ; Fri, 29 May 2009 23:12:56 -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 1MAHq2-0004j5-D8 for ; Sat, 30 May 2009 16:14:38 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sat, 30 May 2009 16:14:34 +1000 From: Hesham Soliman To: mext Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flow bindings Thread-Index: Acnfo/6L/UXLBrmdTUWHc5hR4zjI/wBSeg0n In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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: Sat, 30 May 2009 06:12:59 -0000 It's sad that this is the only thing you can understand from my email. Tragic actually.... >=20 >=20 > On 29/05/09 12:36 AM, "Behcet Sarikaya" wrote: >=20 >>=20 >> Hi Hesham, >> =A0 To your long message, I have a very short reply: You're saying two thi= ngs: >> - you don't want to change your draft, >> - you admit that you forgot to raise the issue below when monami6 discus= sed >> the charter and clearly decided to include HA to MN direction. >>=20 >> Cheers, >>=20 >> Behcet >>=20 >>=20 >>=20 >> ----- Original Message ---- >> From: Hesham Soliman >> To: mext >> Sent: Thursday, May 28, 2009 5:06:55 AM >> Subject: [MEXT] Important considerations for directionality of flow bind= ings >>=20 >> Hi all,=20 >>=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 oth= er >> 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 bindi= ngs. >> 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. Henc= e, >> 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'l= l >> 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 pe= ople >> 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 vot= ing >> attitudes. They all need to be justified if the WG wants to have a techn= ical >> _discussion_.=20 >>=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 th= ing >> 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 tie= d 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 kn= ow >> 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 a= nd >> 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 interf= ace >> 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 movemen= t of >> the flow?=20 >> The way to control how users do things is to incentivise them with charg= ing >> models and show them that things work better on certain technologies, no= t 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 t= he >> MN. I'm perfectly fine with that, just extend the binding revocation dra= ft >> 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 ag= o >> 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 tha= t 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 ab= out >> 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 fro= m >> the HA to the MN. Policies can be transferred without any problems, but = not >> rules.=20 >>=20 >> Hesham >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >>=20 >>=20 >>=20 >>=20 >>=20 ------ End of Forwarded Message From w52006@huawei.com Sat May 30 21:15: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 EB3563A6D8D for ; Sat, 30 May 2009 21:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=2.103, 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 HMdF+hzIQGhr for ; Sat, 30 May 2009 21:15:29 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8FC093A6B79 for ; Sat, 30 May 2009 21:15:29 -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 <0KKH00KBCQKPWU@szxga04-in.huawei.com> for mext@ietf.org; Sun, 31 May 2009 12:17:13 +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 <0KKH00ACZQKPBW@szxga04-in.huawei.com> for mext@ietf.org; Sun, 31 May 2009 12:17:13 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKH00MB0QKO2G@szxml06-in.huawei.com> for mext@ietf.org; Sun, 31 May 2009 12:17:12 +0800 (CST) Date: Sun, 31 May 2009 12:17:14 +0800 From: Yungui Wang In-reply-to: To: 'Hesham Soliman' , 'mext' Message-id: <013901c9e1a6$adb99050$150ca40a@china.huawei.com> Organization: huawei 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: AcnffAdoGi/aI6bjOkmHZuHuvPZ68wCIophw 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: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 04:15:31 -0000 Hello In my understanding, Chairman has initiated the discussion whether the requirement is included in the charter, not how about technical implementation. Below argumentation you mentioned seems using current implementation (e.g. CoA not tie to access tech) to reject the pending requirement. I don't think it is exactly senseful. That's, only if the requirement is supported, below implementation issues 1/2/3 can be further considered. (It may be not difficult to be solved, I think.) However, the requirement may be useful for flow handover, e.g. MN/HA has binding two flows to two BID (CoA) respectively. Based on policies or link overload indication, etc, HA may initiate flow binding to handoff one of MN's flows from one CoA to another. Therefore, personally support two-direction flow binding. B.R. Yungui > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Hesham Soliman > Sent: Thursday, May 28, 2009 6: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 > From hesham@elevatemobile.com Sat May 30 22:46: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 87A4D3A689D for ; Sat, 30 May 2009 22:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=1.222, 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 Lmmw4auz9vHH for ; Sat, 30 May 2009 22:46:19 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id E761C3A6862 for ; Sat, 30 May 2009 22:46: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 1MAdCY-0005iV-GR; Sun, 31 May 2009 15:03:19 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sun, 31 May 2009 15:03:13 +1000 From: Hesham Soliman To: , 'mext' Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flow bindings Thread-Index: AcnffAdoGi/aI6bjOkmHZuHuvPZ68wCIophwAAOh7ZA= In-Reply-To: <013901c9e1a6$adb99050$150ca40a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Sun, 31 May 2009 05:46:20 -0000 On 31/05/09 2:17 PM, "Yungui Wang" wrote: > Hello > > In my understanding, Chairman has initiated the discussion > whether the requirement is included in the charter, not how about > technical implementation. Below argumentation you mentioned > seems using current implementation (e.g. CoA not tie to access > tech) to reject the pending requirement. I don't think it is exactly > senseful. That's, only if the requirement is supported, below > implementation issues 1/2/3 can be further considered. (It may > be not difficult to be solved, I think.) => Yes we're discussing the feasibility of such requirement. I.e., what is the implication of such requirement. If you think it's not difficult to solve then I would encourage you to provide arguments for why it's not difficult to solve or write a draft for example. > > However, the requirement may be useful for flow handover, e.g. > MN/HA has binding two flows to two BID (CoA) respectively. > Based on policies or link overload indication, etc, HA may initiate > flow binding to handoff one of MN's flows from one CoA to another. => How does the HA know this information? Any pointers to specs or current deployments would be useful. Hesham > > Therefore, personally support two-direction flow binding. > > B.R. > Yungui > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Hesham Soliman >> Sent: Thursday, May 28, 2009 6: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 >> > From w52006@huawei.com Sun May 31 00:07: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 CEFE63A6AA6 for ; Sun, 31 May 2009 00:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=0.981, 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 dnfSPDGeo3jy for ; Sun, 31 May 2009 00:07:44 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 71C3C3A6912 for ; Sun, 31 May 2009 00:07:44 -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 <0KKH00BYFYJI5R@szxga01-in.huawei.com> for mext@ietf.org; Sun, 31 May 2009 15:09:19 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKH0087OYJIAT@szxga01-in.huawei.com> for mext@ietf.org; Sun, 31 May 2009 15:09:18 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKH00H7LYJIAP@szxml04-in.huawei.com> for mext@ietf.org; Sun, 31 May 2009 15:09:18 +0800 (CST) Date: Sun, 31 May 2009 15:09:17 +0800 From: Yungui Wang In-reply-to: To: 'Hesham Soliman' , 'mext' Message-id: <013a01c9e1be$b6c6fda0$150ca40a@china.huawei.com> Organization: huawei 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: AcnffAdoGi/aI6bjOkmHZuHuvPZ68wCIophwAAOh7ZAAAUMssA== 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: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 07:07:45 -0000 > > > > In my understanding, Chairman has initiated the discussion > > whether the requirement is included in the charter, not how about > > technical implementation. Below argumentation you mentioned > > seems using current implementation (e.g. CoA not tie to access > > tech) to reject the pending requirement. I don't think it is exactly > > senseful. That's, only if the requirement is supported, below > > implementation issues 1/2/3 can be further considered. (It may > > be not difficult to be solved, I think.) > > => Yes we're discussing the feasibility of such requirement. > I.e., what is > the implication of such requirement. If you think it's not > difficult to > solve then I would encourage you to provide arguments for why it's not > difficult to solve or write a draft for example. > After the requirement is accepted, I'd like to do those works if needed. > > > > However, the requirement may be useful for flow handover, e.g. > > MN/HA has binding two flows to two BID (CoA) respectively. > > Based on policies or link overload indication, etc, HA may initiate > > flow binding to handoff one of MN's flows from one CoA to another. > > => How does the HA know this information? Any pointers to > specs or current > deployments would be useful. > How HA knows this information is out of scope of MIP. For your information, the polcies information could be PCC rules downloaded from PCRF which is defined in 3GPP TS23.203 and TS23.402, etc. For example, network-initiated dynamic PCC pushed to PDN-GW (HA) for traffic flow aggregate may lead to above case - flow handover happens. B.R. Yungui > > Hesham > > > > > Therefore, personally support two-direction flow binding. > > > > B.R. > > Yungui > > > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > >> Behalf Of Hesham Soliman > >> Sent: Thursday, May 28, 2009 6: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 > >> > > > > From hesham@elevatemobile.com Sun May 31 01:20: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 09AA63A6C1C for ; Sun, 31 May 2009 01:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 UXkQyOtHOSy1 for ; Sun, 31 May 2009 01:20:01 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 1F2663A6BE6 for ; Sun, 31 May 2009 01:20: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 1MAgIY-0000Tn-70; Sun, 31 May 2009 18:21:42 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sun, 31 May 2009 18:21:37 +1000 From: Hesham Soliman To: , 'mext' Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flow bindings Thread-Index: AcnffAdoGi/aI6bjOkmHZuHuvPZ68wCIophwAAOh7ZAAAUMssAAFqqkr In-Reply-To: <013a01c9e1be$b6c6fda0$150ca40a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Sun, 31 May 2009 08:20:02 -0000 >> => Yes we're discussing the feasibility of such requirement. >> I.e., what is >> the implication of such requirement. If you think it's not >> difficult to >> solve then I would encourage you to provide arguments for why it's not >> difficult to solve or write a draft for example. >> > > After the requirement is accepted, I'd like to do those works if needed. => Part of accepting requirements is to understand what makes sense. This is a normal discussion for a requirements process. It's not like we're placing requirements on something new that we've never worked with before, this is a well-established technology and is well understood. > >>> >>> However, the requirement may be useful for flow handover, e.g. >>> MN/HA has binding two flows to two BID (CoA) respectively. >>> Based on policies or link overload indication, etc, HA may initiate >>> flow binding to handoff one of MN's flows from one CoA to another. >> >> => How does the HA know this information? Any pointers to >> specs or current >> deployments would be useful. >> > > How HA knows this information is out of scope of MIP. => Huh? If you want the HA to do something in MIP you need to show an implementer how to do it. > For your information, the polcies information could be PCC rules > downloaded from PCRF which is defined in 3GPP TS23.203 > and TS23.402, etc. => I've already said many times that this is not about policies. Hesham From w52006@huawei.com Sun May 31 02:51: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 5D8DD3A6AAD for ; Sun, 31 May 2009 02:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 ymicL+FMc-MK for ; Sun, 31 May 2009 02:51:16 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2F5333A6D0D for ; Sun, 31 May 2009 02:51:00 -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 <0KKI00BVN63I3E@szxga03-in.huawei.com> for mext@ietf.org; Sun, 31 May 2009 17:52:30 +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 <0KKI00D5M63IUA@szxga03-in.huawei.com> for mext@ietf.org; Sun, 31 May 2009 17:52:30 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKI0021W63IZ0@szxml04-in.huawei.com> for mext@ietf.org; Sun, 31 May 2009 17:52:30 +0800 (CST) Date: Sun, 31 May 2009 17:52:29 +0800 From: Yungui Wang In-reply-to: To: 'Hesham Soliman' , 'mext' Message-id: <013b01c9e1d5$82f57da0$150ca40a@china.huawei.com> Organization: huawei 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: AcnffAdoGi/aI6bjOkmHZuHuvPZ68wCIophwAAOh7ZAAAUMssAAFqqkrAACK9MA= 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: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 09:51:17 -0000 Hello > > => Part of accepting requirements is to understand what makes > sense. This is > a normal discussion for a requirements process. It's not like > we're placing > requirements on something new that we've never worked with > before, this is a > well-established technology and is well understood. I think, what I decide to buy a watch is that I want to check time, not the watch is hard/easily made. However, I am attemping to solve your implementation issues 1/2/3 respectively mentioned before. 1. during MCoA registeration, 'access technology type' mobility option which could be re-used from PMIP or re-defined is binding to each BID for flow binding. Then, HA can locally translate "forward port 80 traffic on a wifi link"(a policy) into "forward port 80 traffic using CoA 3ffe::1" (a rule). 2. HA just tracks BID (tieing to ATT) here, not CoA. Then, your issue2 doesn't exist. 3. MN, of course, should be able to initiate flow handover due to link/interface down or something else. I don't think it is an issue. > >>> However, the requirement may be useful for flow handover, e.g. > >>> MN/HA has binding two flows to two BID (CoA) respectively. > >>> Based on policies or link overload indication, etc, HA > may initiate > >>> flow binding to handoff one of MN's flows from one CoA to another. > >> > >> > >> => How does the HA know this information? Any pointers to > >> specs or current > >> deployments would be useful. > >> > > > > How HA knows this information is out of scope of MIP. > > => Huh? If you want the HA to do something in MIP you need to show an > implementer how to do it. > > > For your information, the polcies information could be PCC rules > > downloaded from PCRF which is defined in 3GPP TS23.203 > > and TS23.402, etc. > > => I've already said many times that this is not about policies. > In context of discussion, I thought you asked information is 'policies or link overload indication, etc' of my previous mail. Maybe I misunderstood you. May I know what's the information which you stated in your question 'How does the HA know this information'? B.R. Yungui From hesham@elevatemobile.com Sun May 31 03:19: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 663263A6B6E for ; Sun, 31 May 2009 03:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 rfKtAM8BDdUk for ; Sun, 31 May 2009 03:19:43 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 7727C3A6836 for ; Sun, 31 May 2009 03:19:42 -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 1MAiAP-0002II-6N; Sun, 31 May 2009 20:21:25 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sun, 31 May 2009 20:21:22 +1000 From: Hesham Soliman To: , 'mext' Message-ID: Thread-Topic: [MEXT] Important considerations for directionality of flow bindings Thread-Index: AcnffAdoGi/aI6bjOkmHZuHuvPZ68wCIophwAAOh7ZAAAUMssAAFqqkrAACK9MAAA6OyMQ== In-Reply-To: <013b01c9e1d5$82f57da0$150ca40a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Sun, 31 May 2009 10:19:44 -0000 On 31/05/09 7:52 PM, "Yungui Wang" wrote: > Hello > >> >> => Part of accepting requirements is to understand what makes >> sense. This is >> a normal discussion for a requirements process. It's not like >> we're placing >> requirements on something new that we've never worked with >> before, this is a >> well-established technology and is well understood. > > I think, what I decide to buy a watch is that I want to check time, > not the watch is hard/easily made. > > However, I am attemping to solve your implementation issues > 1/2/3 respectively mentioned before. > 1. during MCoA registeration, 'access technology type' mobility > option which could be re-used from PMIP or re-defined is binding > to each BID for flow binding. Then, HA can locally translate > "forward port 80 traffic on a wifi link"(a policy) into "forward port > 80 traffic using CoA 3ffe::1" (a rule). => But I already mentioned that option in my email and showed why it's not enough due to changes in radio and due to the fact that "port 80" tells you nothing about the application running on that port other than it's using HTTP. > 2. HA just tracks BID (tieing to ATT) here, not CoA. Then, your > issue2 doesn't exist. => Yes it does exist see above and my earlier email. > 3. MN, of course, should be able to initiate flow handover due to > link/interface down or something else. I don't think it is an issue. => Then it's completely redundant for the HA to send such rules. Again see my email. > >>> For your information, the polcies information could be PCC rules >>> downloaded from PCRF which is defined in 3GPP TS23.203 >>> and TS23.402, etc. >> >> => I've already said many times that this is not about policies. >> > > In context of discussion, I thought you asked information is 'policies or > link > overload indication, etc' of my previous mail. Maybe I misunderstood you. > May I know what's the information which you stated in your question 'How > does the HA know this information'? => The HA knows nothing about the app running on any port, knows nothing about changes in the link, nothing about user preferences, nothing about interface failure....etc. That's the information. Hesham > > B.R. > Yungui >