Re: [Monami6] MCoA vs Flow Bindings: Solving same problem?

Gábor Fekete <feketgai@index.hu> Thu, 29 June 2006 15:21 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvyL2-0000Kl-H7; Thu, 29 Jun 2006 11:21:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvyL0-0000Bo-MH for monami6@ietf.org; Thu, 29 Jun 2006 11:21:50 -0400
Received: from posti5.jyu.fi ([130.234.4.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvyKz-00089z-6p for monami6@ietf.org; Thu, 29 Jun 2006 11:21:50 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by posti5.jyu.fi (8.13.6/8.13.6) with ESMTP id k5TFLllI020124 for <monami6@ietf.org>; Thu, 29 Jun 2006 18:21:47 +0300
Received: from posti5.jyu.fi ([127.0.0.1]) by localhost (posti5.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19959-10 for <monami6@ietf.org>; Thu, 29 Jun 2006 18:21:46 +0300 (EEST)
Received: from b19c.mylly.jyu.fi (b19c.mylly.jyu.fi [130.234.196.146]) by posti5.jyu.fi (8.13.6/8.13.6) with ESMTP id k5TFLien020119 for <monami6@ietf.org>; Thu, 29 Jun 2006 18:21:46 +0300
From: Gábor Fekete <feketgai@index.hu>
To: Monami6 WG <monami6@ietf.org>
Subject: Re: [Monami6] MCoA vs Flow Bindings: Solving same problem?
Date: Thu, 29 Jun 2006 18:15:43 +0300
User-Agent: KMail/1.9.3
References: <7EB20EA0938B4D42A2D82689365C9B7A07CB0B@NAEX14.na.qualcomm.com>
In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A07CB0B@NAEX14.na.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200606291815.44341.feketgai@index.hu>
X-Virus-Scanned: amavisd-new at cc.jyu.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
X-BeenThere: monami6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Monami6 WG <monami6@ietf.org>
List-Id: Monami6 WG <monami6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/monami6>, <mailto:monami6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/monami6>
List-Post: <mailto:monami6@ietf.org>
List-Help: <mailto:monami6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/monami6>, <mailto:monami6-request@ietf.org?subject=subscribe>
Errors-To: monami6-bounces@ietf.org

Hi Hesham,

On Thursday 29 June 2006 16:08, Soliman, Hesham wrote:
> 
>  > According to section "6.2.  Receiving Binding Update" of
>  > draft-wakikawa-mobileip-multiplecoa-05, it is allowed to have such
>  > a BC:
>  > HoA1 -> CoA1, BID=1
>  > HoA1 -> CoA2, BID=2
>  > HoA1 -> CoA2, BID=3
> 
> => I'm not sure how this helps in the flow binding case. I think 
> there is a simple point and people seem to be talking past it: 
> In the flow binding case we are binding *flows* therefore we need 
> to identify *flows* therefore we have a flow id in the flow id 
> option; exactly where it belongs. The MCoA draft binds *addresses* 
> to each other, therefore their bindings identify *addresses* and 
> that's what the BID does.       
> In other words we bind flows to a CoA. In doing that, we can't 
> help but bind the CoA to the HoA because that's the nature of 
> the BU. But we don't need a BID on the address level, because we 
> don't care about that. The MCoA draft binds CoAs to HoAs. How 
> are you suggesting we use that? And please be specific: what is 
> the use of the BID in the BU sent in the flow binding draft?      
> 
OK, thanks! I see your point. So you did not want to build on MCoA
because it would have made the design less efficient?

Regards,
Gabor

PS: Anyway, just to answer your question...

The BID can be used for the same purpose as the FID.
There is issue only if you allow multiple Flow Identification
options carried in the same BU.
The flow-binding draft currently handles this case by registering multiple
BC entries resulting in:

HoA1 -> CoA1, FID=1, default
HoA1 -> CoA2, FID=2, port 22
HoA1 -> CoA2, FID=3, port 443

Please, correct me if I am wrong!

But if it built on top of MCoA then it could associate each Flow
Identification option to the BID in the BU,
and therefore to the same BC/BUL entry. So you would end up with:

HoA1 -> CoA1, BID=1, default
HoA1 -> CoA2, BID=2, FlowOpt(port 22) or FlowOpt(port 443)

And here is where I see your point. Managing the Flow Identification
options (remove/update) independently is tricky this way if you don't
have separate IDs for each Flow Id option.

_______________________________________________
Monami6 mailing list
Monami6@ietf.org
https://www1.ietf.org/mailman/listinfo/monami6