Re: [MEXT] MCoA Update [pre07]

["George Tsirtsis" <tsirtsis at googlemail.com>]

Hi Ryuji,

I think what you propose wrt de-registration BU with H-flag set,
works. I have a slight preference in viewing this as a registration
but my preference is based on semantics and I do not think it
technically impacts the solution.

For this reason I say that we go with your proposal, so after fixing
the final set of minor comments I think you should publish the draft.
Time for a proper WGLC ...at least from my side :-)

Regards
George

On Wed, Apr 16, 2008 at 10:05 AM, Ryuji Wakikawa
<ryuji.wakikawa at gmail.com> wrote:
> Hi George,
>
>
>  On 2008/04/16, at 18:00, George Tsirtsis wrote:
>
> > Hi Ryuji,
> >
> > Yes, most of my comments are now minor so, good job!.
> >
>
>  Great! thanks.
>
>
>
> > The only issue that bothers me a little is whether the BU with H flag
> > set over the home link should be viewed as registration or
> > de-registration. I think either way works, but I need to think this
> > through just in case there is some implication that we do not see at
> > the moment.
> >
>
>  OK, please find my comments inline.
>
>
>
>
> > See some comments inline.
> >
> > Regards
> > George
> >
> > 2008/4/16 Ryuji Wakikawa <ryuji.wakikawa at gmail.com>:
> >
> > > Hello George,
> > >
> > > Thanks for comments!
> > >
> > > It looks like your comments are more editorial one.
> > > Can I assume you mostly agree on the changes?
> > > I will revise the document quickly and post it again to MEXT.
> > >
> > >
> > >
> > > On 2008/04/15, at 21:29, George Tsirtsis wrote:
> > >
> > ..
> >
> > >
> > >
> > > >
> > > >
> > > >
> > > >                   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    |
> > > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > >    +                                                               +
> > > >    :                        Link Layer address                     :
> > > >    +                                                               +
> > > >    +---------------------------------------------------------------+
> > > >
> > > >                    Figure 6: BID Mobility Option
> > > >
> > > >
> > > > GT> Figure caption seems wrong. Also, has such option never been
> > > > defined for MIPv6 before? I see that PMIPv6 draft also defined the
> > > > same option. I would hope that only one such option is needed for all
> > > > flavors of MIPv6?
> > > >
> > > >
> > >
> > > Do you mean the interface identifier option of PMIP6?
> > > If that interface identifier is always LL address, we will reuse that
> > > option.
> > > Or we can overwrite the sub-option spec. to carry the LL address always
> for
> > > MCoA in this spec.
> > > I will discuss this with Sri.
> > >
> > >
> > >
> >
> > GT2> Yes, I think it would be nice to coordinate with Sri, but  I am
> > not sure what you mean by "we can overwrite the sub-option spec...."
> >
>
>  I mean the MCoA spec clearly states to carry only LL address in this
> option.
>
>
>
> >
> > >
> > > >
> > > >
> > > > [Sending Deregistration Binding Update]
> > > >
> > > >
> > > > o  As soon as a mobile node returns home, it sends a de-registration
> > > >   Binding Update to the home agent from the interface attached to
> > > >   the home link.
> > > >
> > > > GT> I think throughout the description of this mode of operation the
> > > > MN sends a *registration* not a *de-registration*. In fact you should
> > > > add somewhere that "A BU with H flag set MUST have a non-zero
> > > > Lifetime"
> > > >
> > > >
> > >
> > > I think MN can use the zero lifetime and de-register the BU.
> > > MN continues setting the H flag for BUs to other interfaces attached to
> > > foreign link,
> > > because MN attached to both foreign and home link.
> > >
> > > MN sends BU from the interface attached to the home link just once.
> > > After that BU, MN sends BU with H flag set from the other interfaces
> while
> > > it is at home link.
> > >
> > > MN should not send BU from the home link multiple times..
> > > That's why we said dregistration BU here.
> > >
> > > What do you think?
> > >
> > >
> >
> > GT2> Hmmm, I guess that could work too. Let's think about this a
> > minute. The way you are thinking about this, can the MN send a BU over
> > a foreign link with the H flag set, without having send the dereg BU
> > with H flag set first?
> >
>
>  MN sends only one dereg-BU with H flag set and zero lifetime to HA from the
> home link.
>
>  After that deregistration, MN sends BU with H flag set from the foreign
> link to HA.
>  This tells HA that MN is still at the home link.
>  Once MN leaves from the home link, MN unset the H flag in BU so that HA can
> detect the MN's leaving.
>
>
>
> >
> > >
> > > > o  According to [RFC-3775], the mobile node MUST start responding to
> > > >   Neighbor Solicitation for its home address right after it sends
> > > >
> > > >
> > > >
> > > > Wakikawa (Editor), et al.  Expires October 17, 2008            [Page
> 22]
> > > >
> > > > Internet-Draft                    MCoA                        April
> 2008
> > > >
> > > >
> > > >   the deregistration Binding Update to the home agent.  However, in
> > > >   this specification, the mobile node MUST NOT respond to Neighbor
> > > >   Solicitation before receiving a Binding Acknowledgement, since the
> > > >   home agent may continue proxying for the home address.
> > > >
> > > > GT> the MN must not respond to NS messages before and *after*
> > > > receiving the BA, right?
> > > >
> > > >
> > >
> > > This isn't such clear.
> > > If HA returns [MCOARETURNHOME WO/NDP], MN MUST NOT respond to NS after
> the
> > > BA.
> > > Otherwise, MN should answer to NS.
> > >
> > >
> > >
> >
> > GT2> OK, some clarification maybe useful to indicate that what happens
> > after the BA depends on how the HA responds i.e., the BA's status
> > field.
> >
>
>
>  Right. I will update this.
>
>  regards,
>  ryuji
>
>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext