Re: [Monami6] Changes needed to MCoA draft?

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
Monami6@ietf.org
https://www1.ietf.org/mailman/listinfo/monami6