Subject: Re: [Monami6] some comments on draft-ietf-monami6-multiplecoa-00.txt

From: Jari Arkko <[email-masked]>
Date: Sat, 04 Nov 2006 17:59:21 +0200

Ryuji,
>
>> Handwaving. What does "not delivered correctly" mean? Who tracks
>> this and how? Is upper layer protocol feedback involved? What if
>> there is no current ULP traffic? Will you always believe an ICMP
>> error, or attempt some sort of verification.
>
> This is just an example usage of MCoA.
> We assume some other mechanism to detect failure.
Ok. But then we have some work to do here.
Its not clear that we have a complete protocol
until the spec talks about what other mechanism
is used, or explains how it can operate in a
limited fashion without one.
> Ideally, MN should check the availability of old bindings.
>
> However, RFC3775 does not specify when the MN crashed and boots up.
> MN does not need to check the old bindings, but it simply overwrite
> the old binding by sending BU.
> However, there is no way to know the old binding of CNs, unless it
> sends a BU to CN or it waits for BC expiration at CN.
>
> One way to avoid this scenario is that MN must sends the first BU with
> MCoA options in bulk registration mode.
> In bulk registration mode, the HA can replace the old bindings with
> the new bindings.
> For correspondent node, the MN still need to wait to expire the old
> bindings.
This is not very desirable.

I wonder if there's a way to do this better. It
does not seem to be such a hard problem.
E.g., the "Add-on Binding" bit could be
defined that is on when the MN knowingly
adds new bindings rather than setting up
the first.
>
>
>>>    Priority
>>>
>>>       MUST be set if the priority field of a Binding Unique Identifier
>>>       is valid.
>>>
>> How much do you want to specify about priorities
>> or lack thereof? Wouldn't the real benefit from
>> multiple registrations come from either (a) having
>> a mechanism to know which registration actually
>> works currently and/or (b) flow specifications that
>> map to registrations?
>
> I am not sure about a).
> When multiple bindings are registered, MN can use both of binding
> simultaneously. (Not necessary always to use both)
Sure. But you are not answering to my question,
which was how useful priorities are. Presumably,
the flow draft will specify the fine grained mechanism
that says what binding is preferred for what flow.
Do we need something else?

>>>    Removable (R) flag: TBD
>>>
>>>       When this flag is set, a mobile node request a Home Agent to
>>>       remove the binding correspondent to BID, even if the binding
>>>       update is not for de-registration.  This flag is valid only when
>>>       bulk registration is used (C flag is set).  This option may be
>>>       obsolete in the future revision.
>>>
>> Seems complicated. Do not optimize prematurely.
>
> In bulk registration, multiple CoAs are updated by a single BU.
> There is the request from WG that removing a CoA can be piggybacked to
> a home registration BU.
> MN does not need to send two BU: one for CoA registration and another
> for de-registration.
Hmm.. Ok. But this may be related to how
you define the semantics of bulk registration.
I thought it was always "this is the FULL list
of coas". So it would implicitly overwrite others.
>>
>>>    A Correspondent Node basically learns the BID when it receives a
>>>    Binding Unique Identifier sub-option.  At the time, the
>>> Correspondent
>>>    Node MUST look up its binding cache database with the Home Address
>>>    and the BID retrieved from Binding Update.  If the Correspondent
>>> Node
>>>    does not know the BID, it searches for a binding with only a Home
>>>    Address as performed in Mobile IPv6.  In such case, the first
>>> matched
>>>    binding is found.  But which binding entry is returned for the
>>> normal
>>>    search depends on implementations.  If the Correspondent Node does
>>>    not desire to use multiple bindings for a mobile node, it can simply
>>>    ignore the BID.
>>>
>> Is there a mechanism to know if the correspondent supports
>> this extension? If I have a very good interface/address and
>> a backup very bad interface/address, I probably want to know
>> if the correspondent supports this extension. If it just
>> ignores the extension, I may end up registering the
>> wrong interface/address.
>
> This can be solved by setting A flag in BU.
> In BA, MCoA expects to carry a MCoA option in BA.
Ok. But you need text in the spec to explain
that. Presumably, you'd want to do that at least
in the first BU sent to a particular CN.
>>> But assigning a single Home Address to a given
>>>    network interface is more advantageous than assigning multiple Home
>>>    Addresses because applications do not need to be aware of the
>>>    multiplicity of Home Addresses.
>> Home addresses assigned to an interface?
>
> This is wording problem. We will fix this.
> We want to say that "Multiple home addresses assigned to a node".
Right.
>>
>>>    If the mobile node wishes to register its binding with a
>>>    Correspondent Node, it MUST start return routability operations
>>>    before sending a Binding Update.  The mobile node MUST sends CoTI
>>> for
>>>    each Care-of Addresses and MUST receive CoT for each Care-of
>>>    Addresses.  The mobile node also uses a BID generated for the home
>>>    registration to register them as individual bindings.
>> It appears unnecessary to start *all* RR operations
>> before sending *any* BU. Or are you planning to
>> bind the different addresses together somehow?
>> I'm not sure that is necessary.
>
> If old Care-of/Home keygen are valid, MN can skip those.
Not only that, I don't see why you would have to
register all bindings at the same time. So you
could do, for instance,

rr coa1
bu coa1
rr coa2
bu coa2
...
>
>> Also, I don't see the above changing at all the rules in
>> RFC 3775 -- do not respecify if there's no change.
>>>  The
>>>    registration step is the same as for the home registration except
>>> for
>>>    calculating authenticator by using Binding Unique Identifier sub-
>>>    option as well as the other sub-options specified in RFC 3775. 
>>> Since
>>>    return routability cannot be verified with multiple care-of
>>> addresses
>>>    in a binding update, bulk registration is not supported with
>>>    Correspondent Nodes in this document.
>>>
>> If you really wanted, you *could* design a scheme which
>> allows you to carry all the required care-of tokens and
>> the one home token, and define the way that the
>> MAC needs to be calculated. Probably not worth it.
>
> WG have decided not to support bulk registration for CNs.
Good. I was just making an observation.

--Jari

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

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 7 Nov 2006 06:15:33 +0900

Hi Jari

> limited fashion without one.

OK, it makes sense to investigate
how other approach can be operated with MCoA.

> adds new bindings rather than setting up

I think this works. It's not big change on the spec.

ryuji

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 7 Nov 2006 07:05:16 +0900

Hello Jari

I didn't reply to all your comments.

> Do we need something else?

The priority is used by flow filtering draft.
They need default binding to route the flow which does not have any  
policy.
See section 3.3 of draft-soliman-monami6-flow-binding-02.txt.

The priority is also used when no flow filtering mechanism is used.
In this case, the MN can use this priority to pick one CoA for  
sending/receiving flow.

Right.

> of coas". So it would implicitly overwrite others.

Your definition is simpler.
The question is how much we want to reduce the size of BU.

> in the first BU sent to a particular CN.

I will fix this.

> register all bindings at the same time. So you

Right. I have to fix the texts.

> Good. I was just making an observation.

Thanks for comments again.
I will discuss all the issues you raised in the ML and the WG meeting.

Thanks
ryuji