Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments

["Giaretta, Gerardo" <[e-mail]>]

Hi Ryuji,

> -----Original Message-----
> From: Ryuji Wakikawa [mailto:[e-mail]]
> Sent: Tuesday, December 16, 2008 11:18 PM
> To: Hesham Soliman
> Cc: Giaretta, Gerardo; [e-mail]; [e-mail]
> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some
> comments
> 
> 
> Hi Hesham
> 
> At Sat, 13 Dec 2008 13:06:03 +1100,
> Hesham Soliman wrote:
> >
> > >>
> > >> => But why would the MN want to do that? The scenario you're suggesting
> > >> means that there is effectively one binding, so why do we need to
> allocated
> > >> two BIDs to the same CoA? If there is a reason then I think your proposal
> is
> > >> fine, although it will be tricky to implement. But I'd like to see a
> > >> plausible scenario first.
> > >>
> > >
> > > Suppose the MN is connected to access 1 and access2 and has two flow
> bindings
> > > with two different CoA
> > >
> > > HoA, BID=1, CoA1, FID1, FID4, FID6
> > > HoA, BID=2, CoA2 FID2, FID3, FID5
> > >
> > > When the MN loses access 2 coverage it can do two things to keep the flows
> > > active:
> > > - send a BU with HoA, BID=1, FID2, FID3, FID5 to add those flows to the
> first
> > > binding
> > > - send a BU with HoA, BID=2, CoA1 to update the CoA of the second binding
> > >
> > > The second has advantages in terms of signaling overhead. This is true in
> > > particular if then the MN moves back to access2 and wants to re-establish
> the
> > > flow bindings as previously. In that case just a new CoA update is needed
> > > instead of re-registering the flows again.
> >
> > => That's right, I guessed this is why you and Christian were asking for it.
> > But I think it's strange to have a binding id if it's not unique because
> > it's basically replicating the binding in case we need to change the CoA. It
> > makes things more complex and error prone in the implementation for a small
> > difference of bytes that will be sent. After all, you're not eliminating the
> > need to send another BU, you're just sending a smaller BU. So if you're
> > lucky, you'll save tens of bytes. It's not worth it IMHO.
> 
> From protocol point of view, except for error handling, there are no
> big issues and extentions to the current spec..
> 
> However, this feature is basically proposed for the flow binding optimization.
> 
> Shall we relax this restriction (change MUST to SHOULD) to keep the
> flow binding optimization?
> 

What is exactly the text you propose to change in the draft?

Thanks
Gerardo


> regards,
> ryuji
> 
> > Hesham
> >
> > >
> > > If the second approach is used you will have up giving two different BIDs
> for
> > > which the CoA is the same. But this should not be an issue as the bindings
> are
> > > treated independently, they just happen to point to the same CoA
> > >
> > > Gerardo
> > >
> > >>> Draft 10, section 4.2 (and other places) defines the H flag, which when
> > >>> set means the mobile node wants to use both its home link and one or
> > >>> more of its foreign links.  The H flag is really an instruction to the
> > >>> home agent, that in addition to all the bidings currently defined
> > >>> is shall have an extra binding where packets shall not be tunneled.
> > >>>
> > >>> Proposal:  The mobile node should be able to define a binding saying
> > >>>
> > >>>     HoA BID=0 HoA
> > >>>
> > >>> This is a kind of default binding to be used when any of the other HoA-
> > >>> bindings cannot be used.  I think the H flag is an indirect way of
> > >>> saying there is an extra binding, whereas the binding above is direct.
> > >>> It also avoids continuously setting the H flag when both home link
> > >>> and foreign links are active.
> > >>
> > >> => This is basically asking for a permanent binding. Again, I'd like to
> > >> understand why this is needed, compared to what the draft says now.
> > >>
> > >> Hesham
> > >>
> > >>
> > >> _______________________________________________
> > >> MEXT mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/mext
> >
> >
> > _______________________________________________
> > MEXT mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext