Subject: Re: [Monami6] Changes needed to MCoA draft?

From: Gábor Fekete <[email-masked]>
Date: Sat, 1 Apr 2006 18:41:17 +0300

Hi Ryuji,

On Tuesday 28 March 2006 19:00, Ryuji Wakikawa wrote:
> Hi Heikki again
> 
> On 2006/03/23, at 23:25, Heikki Mahkonen wrote:
> 
> > Hi Ryuji,
> >     What I think is that the MCoA draft is a good draft and it  
> > definitely should be monami6 WG draft as the monami6 charter also  
> > specifies. As I write this, I'm not awere of any decisions people  
> > have made in the monemi6 WG meeting held on tuesday about making  
> > this draft a WG draft. However, I also think that the MCoA draft  
> > needs some additional work to bring a optimal solution for the MCoA  
> > problem space.
> 
> We are waiting for the WG decision. I believe WG chairs should do  
> something now.
> 
> >     I think that the draft should solve two separate problem  
> > scenarios. First, it should enable MIPv6 MNs to bind more than one  
> > CoA to a single HoA. Second, it should specify a optimal way of  
> > delivering these bindings to HAs and CNs. Optimal way in this  
> > context meaning that the signaling overhead should be minimized (BU  
> > packet size and the number of BUs sent should be optimal).
> >
> > 1. Problems which the current draft solves:
> >
> >     The current version of the MCoA draft solves the problem of  
> > binding multiple CoAs to a single HoA for HAs and CNs by  
> > introducing a BID for the bindings. This is a good and optimal  
> > solution for the first problem scenario and I don't think this  
> > needs to be changed.
> >
> >     In addition the current draft specifies a BID option to deliver  
> > these BID's for the bindings in a BU message. This is also good  
> > solution when each CoA is sent in a single BU (either as source  
> > address or in a ACoA option). This BID option is in this case valid  
> > for HAs as well as any CNs.
> 
> OK so far.
> 
> > 2. Problems with the current draft:
> >
> >     The problems I can see with the current MCoA draft are with the  
> > second problem scenario which deals with a way of delivering the  
> > BIDs to other nodes from the MN. This should be done in a optimal  
> > way and I think that sending one BU for each CoA to HAs and CNs is  
> > not an optimal way. My opinion is that the MCoA draft should offer  
> > a way of piggy baging more than one CoA into a BU message destined  
> > to HAs and CNs. As I see it, the current mechanism defined in the  
> > MCoA draft does not enable MNs to send multiple CoAs in a single BU  
> > at least not to CNs. My opinion is that a new mechanism should be  
> > defined which is used to deliver multiple CoAs in single BU  
> > message. This new mechanism is defined in addition to the mechanism  
> > defined in the current MCoA draft which now enables delivering of  
> > CoAs one by one to HAs and CNs. So if the MN chooses to use one or  
> > the other solution it is up to the implementation to decide which  
> > is the better mechanism in any situation.
> 
> Again, as i said in previous mail, bulk registration is realistic  
> only for the initial BUs. When a MN first register its binding to CNs.
> Simultaneous CoAs changes are not so often occurred.
> 
> Anyway, I agree that the current draft is not complete solution for  
> bulk registartion to CN.
> 
> >
> >     In addition, I think that both of the mechanisms (the current  
> > and the new mechanism) should also work with legacy MIPv6 nodes  
> > which do not support the MCoA funtionality. This means that there  
> > might be constraints when sending a BU with multiple ACoA options  
> > which is the way specified in the draft now.
> 
> well, i can agree and disagree. For CN registration, CN will not  
> reply BA. Therefore, MN cannot know whether CN register multiple CoAs  
> or just single CoA.
> You may set Ack bit for MCoA registration all the time to check this.

True, if there is no BA the MN won't be able to know whether the bulk
registration succeeded or not, but it's the case with pure rfc3775 too,
or not? If there is no BA the MN does not know about the success or
failure of a BU regardless it was bulk or not bulk, MCoA BU or RFC3775 BU.
I see no difference here. What is your point?

> 
> >     Also, when sending a BU message which includes more than one  
> > CoA which the MN whishes to register (with a HA or CN), the binding  
> > lifetime  for each CoA must be delivered for each CoA in the BU  
> > message. This is not currently done in the MCoA draft.
> 
> no specification for bulk registartion.

Hmm... What about the last paragraph of Section 5.2 of the latest (05)
MCoA draft? Is not that about bulk registration?

> 
> > 3. Solutions to the problem of delivering multiple BIDs and CoAs in  
> > a ingle BU message:
> >
> >     There are two solutions for the second problem scenario. First  
> > solution is to define a variable length BID option. Second solution  
> > is to define three (two new) BID option types.
> >
> >     It should be defined that MN must always adds one CoA to the BU  
> > message as a source address or in the ACoA option and it is used in  
> > the normal RFC 3775 way. For this CoA the MN includes a BID option  
> > which is formatted as specified in the current MCoA draft. This is  
> > a valid way of delivering one of the CoAs to HAs and when the BU is  
> > sent to the CN a normal BAD option is used to authorize this CoA.  
> > In addition the binding lifetime for this CoA comes from the  
> > lifetime field in the BU option header. This enables a binding with  
> > a legacy MIPv6 nodes (which simply ignore the unknown options in  
> > the BU) as well.
> >
> >     When a MN is sending multiple CoAs to a HA in a single BU  
> > message, it will add the other CoAs (other than the one in the  
> > source address field or in the ACoA option) into a new variable  
> > length BID option. Each CoA is added into one BID option. Now this  
> > option would have the same fields currently defined in the MCoA  
> > option and in addition a field for the valid binding lifetime and a  
> > field for the CoA itself. The second solution is to add the binding  
> > lifetime and other CoAs into a new BID otion which looks like the  
> > BID option in the first case but would have different type code.
> >
> >     When a MN is sending multiple CoAs to a CN in a single BU  
> > message, it will add the other CoAs (other than the one in the  
> > source address field or in the ACoA option) into a new variable  
> > length BID option. Each CoA is added into one BID option. Now this  
> > option would have the same fields currently defined in the MCoA  
> > option and in addition a field for the valid binding lifetime, a  
> > field for the CoA itself, and fields for the nonces and binding  
> > authorization data. The second solution also in this case is to add  
> > the lifetime, the other CoAs, and the nonce and authorization data  
> > into a new BID otion which looks like the BID option in the first  
> > case but would have different type code.
> >
> > Any thoughts?
> 
> You solution can be possible. However, in Monami6 WG at dallas, the  
> base specification should be simple.
> The optimization is always good, but complication is not.

I think the proposal of Martti is quite simple even for implementers
and as shown in
http://www1.ietf.org/mail-archive/web/monami6/current/msg00498.html
its logic is quite clear (which means it is easy for implementers ;)).
What's more, it would make the whole draft more simple to
understand than the current draft-wakikawa-mobileip-multiplecoa-05.txt.
Questions like e.g. "so does bulk registration mean multiple ACoAs?"
are solved.
And it seems to work also with RFC3775 only CN/HA without any
implementation specific "hmmm, i wonder if the CN will choose the last or
first ACoA..." issues.
I like it :)

> 
> I think Hesham gave comments that we can initially support bulk  
> registartion for HA and not for CN.
> you can check the minutes of Monami6 WG meeting.

Do you mean the 2nd WG meeting in Dallas?
Could you please point me at the place where it is accessible?

Thank You,
Gabor Fekete

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

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 11 Apr 2006 12:17:26 +0300

> 
> One idea is that we can separate bulk registration into separate document.
> I can remove the texts and move to the new document which will contain 
> your inputs, too.
> 
> However, before doing that, the draft must be WG document.
> This draft is still individual draft and not WG one.
> 
> I want to solicit the comments from WG chairs  first !!!
> 
> ryuji

Hello,

I think that the best way forward would be to split the current draft 
into two drafts. This first would be the current draft without the bulk 
option and the second a bulk extension to the first draft. Although it 
makes a lot of sense to support a bulk registration, because it saves a 
lot of bytes and more importantly signaling bytes, but it is still in 
essence just an optimization to the basic idea of inserting the BID option.

The current way of including the bulk possibility produces a lot of 
questions that the MCoA draft fails to answer clear enough. Moreover, 
the current draft's bulk registration works only with HAs and not with 
CNs, which is a situation that should be avoided. In my opinion the 
mechanism should work coherently among the target nodes. Being a 
separate draft, bulk registration issues would be easier to work on 
without needlessly stalling the MCoA draft.

-- 
Tero Kauppinen                                 Tel: +358 9 299 3057
Research Scientist, NomadicLab, IP Networks,   Fax: +358 9 299 5055
Ericsson Research, Corporate Unit.             Mobile: +358 40 590 7560
Oy L M Ericsson Ab
mailto:[email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 11 Apr 2006 14:07:28 +0300

Hi all,

El 11/04/2006, a las 12:17, Tero Kauppinen (JO/LMF) escribió:

>> I can remove the texts and move to the new document which will 
>> contain your inputs, too.
> into two drafts. This first would be the current draft without the 
> bulk option and the second a bulk extension to the first draft. 
> Although it makes a lot of sense to support a bulk registration, 
> because it saves a lot of bytes and more importantly signaling bytes, 
> but it is still in essence just an optimization to the basic idea of 
> inserting the BID option.
>

i am sorry but i fail to see the logic behind this line of reasoning.

I mean, whether we think that bulk registration is important or we don't

if we don't think it is important, we just drop it

if we think it is important, i guess we need to do it from day one. I 
mean, i don't see the point in doing one spec that is incomplete and 
lacks and important feature and 6 months later do a new spec with the 
additional feature. I think that we need to do it once and do it right 
with all the important features. I mean, i guess we don't want to have 
to write first implementations with mcoa support version one (without 
bulk registration) and then another implementation of mcoa version 2 
(with bulk registration) and make the version 2 with bulk registration 
compatible with the mcoa version 1 (without bulk implementation)

This is even more critical in the case that you point out that the 
current mcoa draft doens't seems to cleanly support the bulk 
registration and the additional stuff will be needed for bulk 
registration with CN. Do we know that the future bulk extensions can be 
created starting from the current mcoa draft that lacks of bulk 
registration? or we may end up with two different mechanisms one 
without bullk and another for bulk registration?

I think we need to make just one mechanism that provides all the 
features that are needed and do it right in the first time

In addition, we are only chartered to do one MCOA docuemnts, not a 
basic support and then MCOAs support optimizations, so i guess that we 
would need to recharter in order to this MCOA optimization support 
draft, right?

So, my suggestion is to first figure out if bulk registration is needed 
or not.
If it is needed, produce a single spec (and a single implementation) 
that supports all the desired features.

regards, marcelo

---

From: Gábor Fekete <[email-masked]>
Date: Tue, 11 Apr 2006 15:20:57 +0300

Hi Marcelo and list,

> additional feature. I think that we need to do it once and do it right 

I don't think Tero meant creating a "new spec". I guess it'd be more
like an addition. At least I hope.

I don't think it is a problem to have two separate drafts (they are
only drafts anyway). In that case, the basic MCoA draft should drop all
the "bulk registration" related text.

But I would suggest someone taking the MCoA draft and rewrite it with
bulk in mind from scratch and just see how it shapes up. I don't think
it would hurt. E.g. Martti Kuparinen had quite nice ideas...

> compatible with the mcoa version 1 (without bulk implementation)

If bulk-reg is an add-on draft then I think it is no problem.
By add-on I mean that mcoa can be easily extended to support bulk-reg.
In this case I see one complication in the error handling, e.g.
"What if a bulk-mcoa MN talks to a non-bulk-mcoa implementer CN?"

> So, my suggestion is to first figure out if bulk registration is needed 

IMO, bulk-reg reduces signaling overhead. The problem is currently
there are no services (at least I am not aware) deployed using mipv6
and not many ipv6 sites. At first glance Bulk-reg is good on e.g. boot up
and if you have multiple CoAs on a single interface. But in the latter case
will it be common in the future to have ipv6 subnets with multiple network
prefixes? So for me it's a bit like planning blind and whether we need it
or not may not be that clear at this point. Or am I saying bull?

I say, just create a draft for bulk (either rewrite mcoa or create a 
separate draft and drop bulk-reg from mcoa) and
see if the result is over-complicated or simple and clean.

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Tue, 11 Apr 2006 15:41:02 +0300

Gábor Fekete wrote:
>>...

IMO, it is an optimization because the protocol works without it. I 
would not say that the spec would be "incomplete and lack an important 
feature", but that is just my opinion.

> like an addition. At least I hope.

You got my point.

> or not may not be that clear at this point. Or am I saying bull?

I don't think you're "saying bull". It is a good question that I have 
also tried to find an answer for ... not succeeding that much, though. I 
would say that reducing signaling overhead is a pretty strong argument 
that justifies the existence of bulk-reg.

Regz,
Tero

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 11 Apr 2006 16:06:59 +0300

Hi,

> like an addition. At least I hope.

but we don't know if the addition would fit in the existent MCOA draft, 
don't we? I mean, there seems to be several issues with adding bulk 
registration support to the mcoa draft right? if this is so, it is not 
clear to me at this point that it would be straightforward to extend 
the current mcoa draft to support bulk registration and solve all the 
issues.

Moreover, i don't think it is a good strategy. I mean, if we know now 
that bulk registration is an important feature, then why to first adopt 
a mcoa draft that has not bulk registration and later figure out if we 
can fit in this draft the bulk registration stuff.... it doesn't make 
sense to me... If we are designing the mcoa support now and we consider 
that bulk registration is needed, we better design the mcoa support 
with this in mind and make sure that the basic mcoa support provides 
the features that we need.... I mean i understand making hacks in 
implementaions and specs when unforseen requirements appear, but this 
is already here and we haven't defined the solution yet, so i don't 
think that the best approach would be to ignore future features and see 
how they fit in later...

> the "bulk registration" related text.

but what is the point in having two draft?

my point is that we need to figure out how this bulk registration stuff 
fits in the mcoa support anyway in order to do it right so, i guess we 
can do it once and for all

> it would hurt. E.g. Martti Kuparinen had quite nice ideas...

yes, this is the approach that i would suggest, try to figure out how a 
mechanism to support mcoa registration and bulk registration would look 
like

> By add-on I mean that mcoa can be easily extended to support bulk-reg.

but we don't know that at this point, since we haven't figured out how 
to address the issues that were brought up about bulk registration in 
the current mcoa draft right?

so maybe we accept this mcoa draft as the first solution and then we 
need to do nasty hacks to include the bulk registration stuff... this 
doesn't seems to me a good strategy for protocol design. we need to 
figure out the big picture and define a solutions that are extensible 
to deal with all the features that we consider important

so, if we know now that we want this, then we should do it since the 
begining...

> "What if a bulk-mcoa MN talks to a non-bulk-mcoa implementer CN?"

this is just one of the issues that may appear....
i mean since day one we will have multiple vrsions of the mcoa 
registration support.... i don't think this is the best approach

> and if you have multiple CoAs on a single interface.

Do you think that bulk registration will only be usefull for multiple 
coas in a single interface? why is that?

>  But in the latter case
> prefixes?

well, multihomed networks are expected to have multiple prefixes (at 
least in several cases) so i guess this may be pretty common (just 
guessing of course)

>  So for me it's a bit like planning blind and whether we need it

> see if the result is over-complicated or simple and clean.

fully agree, but this is needed before taking on the work in the 
current mcoa draft in the wg, so that we can figure out if a mcoa 
mechanism that supports bulk registration is compatible or not with the 
current mcoa draft... agree?

regards, marcelo

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 13 Apr 2006 12:36:31 +0900

Marcelo

At Tue, 11 Apr 2006 14:07:28 +0300,
> compatible with the mcoa version 1 (without bulk implementation)

diagree. MIP6/NEMO base specs are also updated. If we try to support
complete feature of MIP6/NEMO, we can not start anything. (because
base feature is not completed!)

BTW, we've implemented MCoA in several times and I knew several groups did also.
Our implementation also confirms interoperability with different implemenattion, too.

> without bullk and another for bulk registration?

The current situation is that MCoA does support bulk registration for HA, but not for CN.
Some proposal are introduced in ML, but most are based on RR. 
Then, how many operators will use RR? There is another way to do RO which is CN IPsec.
So, bulk registration for CN needs more discussion whether it's really need. 
If yes, which RO mechanism we should support? 

> features that are needed and do it right in the first time

diagree, again. see above.

> would need to recharter in order to this MCOA optimization support 

if we separate document,  yes.

> that supports all the desired features.

I would like to support bulk registration to HA, but not to CN at this point.
RO mechanism is not completed yet, except for RR. If we exclude bulk registation to CN, 
we can produce signle document

regards
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 13 Apr 2006 12:43:08 +0900

Hi Gábor

At Tue, 11 Apr 2006 15:20:57 +0300,
> or not may not be that clear at this point. Or am I saying bull?

I mostly agree. 

For home registartion, MN must update all CoAs to keep the lifetime
update.  Therefore, bulk registration may be useful.  MN can update
all binding lifetimes periodically at the same time, regardless of
lifetime expiration timing.

However, MN does not need to send all CoAs to CN. It just sends CoA
which needs to use for communication with the CN. And binding
registration to CN is continued only while MN is communicating.  So, I
am not so positive to support bulk registartion to CN, which requires
additional protocol modification to RR. And I also want to see how many
operators want to use RR, too.

regards
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 13 Apr 2006 12:48:38 +0900

Hi Tero

At Tue, 11 Apr 2006 15:41:02 +0300,
> that justifies the existence of bulk-reg.

I agree that reducing signaling is quite important.
But, RR brings certain signaling overhead. 
Reducing the number of BUs doesn't mean much if we assume RR.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 13 Apr 2006 13:06:38 +0900

Hi Marcelo

At Tue, 11 Apr 2006 16:06:59 +0300,
marcelo bagnulo braun wrote:
> registration support to the mcoa draft right? 

Can you list up the several issues of MCoA?? I only catch the issue of
CoA authentication for bulk registartion to CN.

> if this is so, it is not 

I don't understand your statement here. There are several ideas to solve the issue on ML.
The discusson here is whether we merge the idea into the base spec, or split into two documents.

> but what is the point in having two draft?

Since most of MCoA spec is mature, we can continue to discuss RO case in prallel.

> the current mcoa draft right?

Why? We have had discussions on ML? Why we need to re-start the discussion again??

> to deal with all the features that we consider important

So, your problem is that proposed idea to support bulk registartion to
CN is nasty extension??

> registration support.... i don't think this is the best approach

This shouldn't happend.

> coas in a single interface? why is that?

Not limited to, but the timing of movement is different.

> least in several cases) so i guess this may be pretty common (just 

I'm not sure:-p

ryuji

---

From: Martti Kuparinen <[email-masked]>
Date: Thu, 13 Apr 2006 11:23:30 +0300

>From the bytes-sent-between-the-nodes point of view bulk registration is really
beneficial and makes a lot sense.

We have made some performance analysis on the bulk registration so you (=this
list) can expect a draft next week...

> we can produce signle document

Personally I'm fine with this (to get things started) but I also would like to
see the BIDA option in the draft so we can correctly see what CoAs were
successfully registered and which not.

Binding Unique Identifier Acknowledgement sub-option (BIDA)

    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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Binding Unique ID (BID)   |  Status       |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Binding Unique ID (BID)   |  Status       |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And while suggesting things, I think we really should not reuse the ACoA option
when doing bulk registration (which could confuse legacy HAs/CNs) but have these
two options instead of your proposed BID option:

Home Binding Unique Identifier sub-option (HBID)

    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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Binding Unique ID (BID)   |  Priority     |C|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                        Care-of Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Correspondent Binding Unique Identifier sub-option (CBID)

    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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Binding Unique ID (BID)   |  Priority     |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Later, when we come up with a solution for the CN bulk registration we can
modify the CBID option and not mess with the HBID option.

Martti

---

From: Heikki Mahkonen <[email-masked]>
Date: Thu, 13 Apr 2006 11:28:01 +0300

Hi Ryuji,

> CoA authentication for bulk registartion to CN.

Issues with bulk registration with HA in the current MCoA draft:

1. No legacy HA support in the bulk registration. It is not only a 
problem of choosing the right ACoA option if you have many. Legacy 
support is also a problem if the MN has just two interfaces (2 CoAs) and 
tries a bulk registration with legacy HA. In this case it might add one 
of the CoAs to the source field of the BU message and the other CoA into 
the ACoA option. Now, if this message is received by a legacy HA it 
takes the CoA from tha ACoA option and replies BA (status = 0). So the 
outcome is that the MN has a valid binding but with the other interface 
it was intending to register in the first place.

2. You cannot say that it is a bulk registration if in some cases you 
have to send more than one BU to the HA. In the other mail I specified a 
scenario (don't know how unlikly you think it is) where the MN cannot 
update all the BIDs/CoAs with a single BU. In this case the opinion was 
to send one or more BUs to remove not needed BIDs and one or more BU 
messages to update some of the BIDs. This is not a bulk registration... 
There could be several solutions for this using the lifetime field in 
the BID option, adding a remove flag to the BID option etc...

3. No support for different binding lifetimes for different home 
ragistrations. This I quess is just a minor issue?

I think if you want to have the bulk registration in the base MCoA draft 
for HA you MUST fix the first issue and SHOULD fix the second (so in 
some cases you don't have to resort to sending multiple BUs) and SHOULD 
also consider if it would be wise to have the binding lifetime in the 
BID option.

-Heikki

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 13 Apr 2006 17:40:51 +0900

Hello Martti

At Thu, 13 Apr 2006 11:23:30 +0300,
> list) can expect a draft next week...

Yes, i'll wait for that.

> successfully registered and which not.

agree.

How about HA include BIDA option only when there is an error.
When an error is occurred, BA looks like
+---------------------+---------------+----------------+
|BA (status=Bulk fail)|BIDA(BID,Error)| BIDA(BID,Error)| 
+---------------------+---------------+----------------+

Otherwise, HA replies with
+------------------------+
|BA (status=Bulk success)|
+------------------------+

This can save certain bits.

> Binding Unique Identifier Acknowledgement sub-option (BIDA)

THis is useful only when bulk Reg is used. When MN does separate registration,
128bit is useless, since CoA is in IPv6 header.
So I want to go with a new CoA option instead of ACoA option, which
format should be same as ACoA except for type value.

> Correspondent Binding Unique Identifier sub-option (CBID)

I prefer using the same option for both HA and CN. We can carrry more
infromation by defining a new sub-option if necessary.

ryuji

---

From: Martti Kuparinen <[email-masked]>
Date: Thu, 13 Apr 2006 11:45:14 +0300

> When an error is occurred, BA looks like

Sounds reasonable.

> format should be same as ACoA except for type value.

And that's why there is the C flag which tells if the CoA is included or not. In
other words, this is variable length option (either 6 or 22 bytes).

Martti

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 13 Apr 2006 17:47:07 +0900

At Thu, 13 Apr 2006 11:28:01 +0300,
> it was intending to register in the first place.

MIP6 spec does not say to check the source address of BA with the sent CoA.
OK, this can be easily fixed. I will fix this in next revision.

> the BID option, adding a remove flag to the BID option etc...

MN can update all binding by sending single BU, because BID is kept
same when binding is updated. 
I think I've already replied to your previous mail.

> ragistrations. This I quess is just a minor issue?

Can you elaborate this? 

> also consider if it would be wise to have the binding lifetime in the 

For issue1, I will fix that. 
I think you mis-interpret the draft for the issue2. 
For issue3, i'll wait for your reply:-)

thanks,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 13 Apr 2006 17:49:08 +0900

At Thu, 13 Apr 2006 11:45:14 +0300,
> other words, this is variable length option (either 6 or 22 bytes).

Ah, OK. It looks fine. 

I'll fix the draft according to this.

thanks
ryuji