Subject: Re: [Monami6] Comments on draft-soliman-monami6-flow-binding-02

From: Gábor Fekete <[email-masked]>
Date: Wed, 4 Oct 2006 20:56:17 +0300

Hi Hesham,

On Wednesday 04 October 2006 07:05, you wrote:
> 
>  > > => Of course, bulk registration implies the use of [3]. 
>  > This is stated in 
>  > > the motivation for using [3].  
>  > > 
>  > Not for me :)
>  > I think it should be stated more explicitly. Like "to use 
>  > the BID sub-option
>  > this draft MUST be used parallel with [3]."
> 
> => Well, there is no BID if you're not using [3]! The BID is defined 
> in reference to [3]. 
> 
OK. I read Section 2.2 again. It is clear until this:

  "A BID sub-option is not necessarily included in the same BU, but MUST
   be already known to the receiver of the BU.  The BID sub-option is
   shown below."

I think it is not so fortunate to call two different things with the
same name. BID sub-option of [3] and BID sub-option in this draft,
even if [3] would rename it only to "BID option".
Maybe this sub-option should be called "Binding Reference sub-option"
or "BRef sub-option", or anything but not "BID ...".

> 
>  > > => The Default entry is done using [3]. I think we should 
>  > clarify that in the next rev. 
>  > > 
>  > I really don't see anything like "default entry" in [3] :(
> 
> => It's the priority field in the BID option in [3]. 
> 
I see. That was my guess. But only a guess. ;)

>  > > => Well, the BC is intended to be per addressin MIPv6. MIPv6 does 
>  > > not support the BC per prefix and the MN has no way of knowing if 
>  > > the CN is a router. So, while it might be possible, I'm 
>  > reluctant to 
>  > > add it without much further investigation.   
>  > > 
>  > I don't talk about destination address but source address. 
>  > BC entry in RFC 3775 has
>  > nothing to do with source address.
> 
> => Yes it does, think about a multihomed CN and how it would manage packets from 
> different interfaces to the MN.  
> 
No it does not :) The BC entry of RFC 3775 does not have to do anything with
multihomed nodes. If I understand what you mean then I guess you are
talking about the modified BC entry of draft-soliman and not the RFC 3775 one here.

>  > I see no problem in having the same features with regards to 
>  > flow description 
>  > in both HAs and CNs. Do you think about implementation complications?
> 
> => I don't understand your statement, what "same features"?? 
> 
I say, let the CN accept the same kind of flow identification options
as the HA. I see no real value in the restrictions that draft-soliman has
about this. And who knows, maybe the MN knows that the CN is a router,
for example Joe told Jane that his machine is a router.

>  > > => What do you mean by "Mobility Bindings"? We 
>  > consistently refer to it as flow bindings in the doc. 
>  > > 
>  > RFC 3775 calls the (HoA, CoA) binding created by a BU as 
>  > Mobility Binding.
>  > Do you say you refer to Mobility Bindings as flow bindings 
>  > in this draft?
> 
> => No of course not, please re-read the text you quoted:
> 
So you refer to to Mobility Bindings as Flow Bindings 
in this draft?

>  > >  >   "This will cause the home agent to remove all
>  > >  >    Flow Bindings that are linked to the home address, 
>  > >  > including the flow
>  > >  >    bindings."
> 
> => The flaw here is that flow bindings are repeated twice, 
> which is a typo, but replacing the last "flow bindings" 
> with "Mobility Bindings" would not make sense. If "Mobility 
> Bindings" is placed anywhere it should replace the first 
> "flow binding" not the second. But IMO, the easiest way 
> to handle this is to remove "Flow" from the first "Flow Bindings".      
> 
OK! So, just like the "BID sub-option", I also don't like the 
name "Flow Binding", it always confuses me, as you
know it already :)
I understand why you named it like that, from
previous monami6 emails where you had to explain it not once in a long
thread to someone already.

But now I see how it can be solved. Just define "Flow Binding" somewhere.
Like:
Flow            A set of network packets.
Flow Identifier A set of instructions that describe a flow.
Flow Binding	A Mobility Binding extended with a Flow Identifier.

OK ok! It may be too much, but you got my point.
And then the Flow Identification Option becomes "a Mobility Option that
carries a Flow Identifier".

Sorry if I am a bit hard on the uptake!

Regards,
Gabor

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 5 Oct 2006 03:08:34 -0700

> or "BRef sub-option", or anything but not "BID ...".

=> I'm fine with that. We can pick a different name.

 > I see. That was my guess. But only a guess. ;)

=> I understand your concern and I'll fix that in the next rev. 

 > talking about the modified BC entry of draft-soliman and not 

=> Well, when a MN sends a packet to a CN, it checks its BUL based on
the src and dst addresses in the packet. So you do need a separate
binding for each CN address. There was a similar issue for the CN that
we encountered in an interop test and for that reason it was decided
that the BC is per src address (for the CN). That was 6 years ago
though, I need to look it up to give you the exact detail but I remember
it being a significant enough issue that there was concensus on the
solution. Sorry I can't think of it right now. Let me get back to you. 

 > for example Joe told Jane that his machine is a router.

=> Independently of this issue, of course there are other restrictions
on the CN, e.g. prefixes for the src address field (MR's prefix). So I
don't think they'll be the same. I assume you agree with that at least.

 > Flow Binding	A Mobility Binding extended with a Flow Identifier.

=> That's fine. I don't have a problem with that. 

 > Sorry if I am a bit hard on the uptake!

=> No need, you're bringing up useful clarifications to the draft.
Please let me know if you have more comments. 

Hesham