Re: [MEXT] MCoA Update [pre07]

[Ryuji Wakikawa <ryuji.wakikawa at gmail.com>]

Hi George,

At Wed, 16 Apr 2008 10:19:56 +0100,
George Tsirtsis wrote:
> 
> 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.

great to have agreement:-)

> 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 :-)

OK, I will work on your comments and will submit it to IETF unless
there are more comments from the MEXT group.

regards,
ryuji

> 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