Hello Ahmad,
Thank you for your clarification.
As you said, when MN uses BID, I also think de-registration
of a specific BC
should be available. I could understand the approach by
Suresh for this process.
In this case, after HA de-registers that BC, the forwarding
destination
would be only another BC entry based on RFC3775, so after
de-registration,
no new HA behavior.
And then H-flag is used to allow HA to know MN's request to
create the home binding as well as another BC. This flag is
valid for
Registration, Deregistration and bulk registration as
described
in the current draft. I think this may be just Registration
because
it creates the home binding.
Regards,
Keigo
On Thu, 26 Jul 2007 06:23:56 -0500
"Ahmad Muhanna" <amuhanna nortel.com> wrote:
> Hi all,
>
> Since when RFC3775 mention de-registration, it
associate that with two
> cases:
> 1. returning home, and since returning home means that
MN binding is
> gone with all CoAs.
> 2. de-registering Primary Care of Address, or as
RFC3775 captures it,
> the MN no longer has any CoA in the visited network.
>
> Then de-registration based on RFC3775 means
de-registration for the MN
> binding with all CoA.
>
> "
> 10.3.2. Primary Care-of Address De-Registration
>
> A binding may need to be de-registered when the
mobile node returns
> home or when the mobile node knows that it will not
have any care-of
> addresses in the visited network.
> "
>
> However, since we are addressing the extension of MIPv6
to support
> multiple binding with clear BID, I guess both solutions
should work:
>
> 1. A clear indication by setting the "H" bit
in the BID option:
> This requires a new definition of the HA behavior.
Which is already
> done.
>
> 2. The second approach by Suresh should work too:
> In this case, the new HA behavior is not according to
RFC3775 but to be
> also defined as Suresh mentioned. The de-registration
carries a specific
> BID option and the HA should only de-register that
one.
>
> In the case that the MN would like to de-register all
BIDs, then the
> process as per RFC3775 should suffice.
>
>
> Regards,
> Ahmad
>
>
> > -----Original Message-----
> > From: Keigo Aso [mailto:asou.keigojp.panasonic.com]
> > Sent: Wednesday, July 25, 2007 5:40 PM
> > To: Suresh Krishnan
> > Cc: Monami6 WG
> > Subject: Re: [Monami6] H flag and no NDP
> >
> > Hi Suresh,
> >
> > I can not understand why this work.
> > How does HA know MN's intention, whether MN wants
to utilize
> > both interface or only the interface attached to
home link or
> > only the interface attached to foreign link at one
time ?
> >
> > Regards,
> > Keigo
> >
> > On Wed, 25 Jul 2007 15:33:01 -0400
> > Suresh Krishnan <suresh.krishnanericsson.com> wrote:
> >
> > > Hi Folks,
> > > I believe that the problem Ryuji was
addressing is real and it
> > > needs to be addressed. I do not agree though
that a
> > protocol extension
> > > is necessary to do this.
> > > I have an alternate mechanism to propose.
Let's say an MN has 2
> > > interfaces (both on a foreign link). The HA
has two bindings
> > > 1) HoA to CoA1
> > > 2) HoA to CoA2
> > >
> > > Now let's say one of the interfaces returns
home. The MN will
> > > deregister on this interface. When the HA
removes this binding, it
> > > MUST check for other bindings for this HoA
and flag them
> > with a "No PROXY NDP" flag.
> > >
> > > I think this will solve the problem without
any protocol
> > modifications
> > > and only behavior modifications on the HA.
> > >
> > > Cheers
> > > Suresh
> > >
> > >
_______________________________________________
> > > Monami6 mailing list
> > > Monami6ietf.org
> > > https:
//www1.ietf.org/mailman/listinfo/monami6
> >
> >
> >
> > _______________________________________________
> > Monami6 mailing list
> > Monami6ietf.org
> > https:
//www1.ietf.org/mailman/listinfo/monami6
> >
>
> _______________________________________________
> Monami6 mailing list
> Monami6ietf.org
> https:
//www1.ietf.org/mailman/listinfo/monami6
_______________________________________________
Monami6 mailing list
Monami6ietf.org
https:
//www1.ietf.org/mailman/listinfo/monami6
|