Re: [MEXT] [mext] #11: De-registration when returning home [Vijay Devarapalli <vijay at wichorus.com>]

["Vijay Devarapalli" <vijay at wichorus.com>]

Hi Charlie,

I am going to try addressing this issue once more. First lets look at
the requirements.

1. Allow a mobile node with one home address and one care-of address to
be able to send/receive packets when it attaches to the home link

2. Allow a mobile node with one home address and multiple care-of
addresses to decide whether it wants to send/receive packets from the
home or the visited link.

IMO, RFC 3775 addresses the first case. The second one is addressed by
the multiple CoA draft. The multiple CoA draft infact describes the
mobile node and the home agent behavior for three cases when the mobile
node is simultaneously attached to the home and visited links. See
section 5.6 of draft-ietf-monami6-multiplecoa-08.txt. It allows the
mobile node to use the home link, the visited link or both and indicate
the same to the home agent.

So here is my proposal for the text.

OLD:

   A mobile node detects that it has returned to its home link through
   the movement detection algorithm in use (Section 11.5.1), when the
   mobile node detects that its home subnet prefix is again on-link.
   The mobile node SHOULD then send a Binding Update to its home agent,
   to instruct its home agent to no longer intercept or tunnel packets
   for it.  

NEW:

   A mobile node detects that it has returned to its home link through
   the movement detection algorithm in use (Section 11.5.1), when the
   mobile node detects that its home subnet prefix is again on-link.
   In case the mobile node has only one care-of address associated with
   the home address, it MUST send a Binding Update to its home agent,
   to instruct its home agent to no longer intercept or tunnel packets
   for it.  In case the mobile node has more than one interface and
   can bind more than one care-of address to the home address, the 
   mobile MAY send a Binding Update to its home agent, to instruct its 
   home agent to no longer intercept or tunnel packets for it. For more
   information on the mobile node returning home procedure when there 
   are multiple care-of addresses, see [MCOA].

In the Informative references add,

   [MCOA] Wakikawa, S., Devarapalli, V., Ernst, T., and K. Nagami, 
          "Multiple Care-of Addresses Registration", Work in 
          Progress, May 2008.
   
Hope this acceptable to all.

Vijay

> -----Original Message-----
> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On 
> Behalf Of Charles E. Perkins
> Sent: Tuesday, July 08, 2008 3:12 PM
> To: mext at ietf.org
> Subject: Re: [MEXT] [mext] #11: De-registration when 
> returning home [Vijay Devarapalli <vijay at wichorus.com>]
> 
> 
> Hello folks,
> 
> As noted, I have posted issue #11 to the [mext] issue tracker.
> 
> There were well over 50 messages on this topic, and I plowed
> through every single one of them.  I tried to extract the major
> thoughts and collect them for the issue background, but if I
> managed to miss something please let me know.
> 
> I'm satisfied that the proposal as shown after the other
> discussion in the issue description is a reasonable consensus
> resolution for the issue, but I'll wait to see if there is
> any dissent first.
> 
> Regards,
> Charlie P.
> 
> 
> mext wrote:
> > Ticket #11: De-registration when returning home  [Vijay Devarapalli
> > <vijay at wichorus.com>]
> > 
> >  RFC 3775 currently says the mobile node "SHOULD" send a 
> de-registration
> >  BU when it returns home. This is kind of odd because, without the
> >  de-registration BU, the home agent continues defending the 
> mobile node's
> >  home address and keeps tunneling the packets to the last 
> known care-of
> >  address. The BCE must be deleted for the mobile node to be 
> able to send/
> >  receive packets from the home link. I am not sure why we went with
> >  "SHOULD" in the first place.
> > 
> >  From the interop events I have attended, I know that all 
> mobile node
> >  implementations send a de-registration BU as soon as they 
> detect they
> >  are on the home link. The use of "SHOULD" instead of 
> "MUST" caused some
> >  confusion during the PMIPv6-MIPv6 interactions discussion. 
> So we need to
> >  fix this.
> > 
> >  Here is the proposed change.
> > 
> >  OLD:
> > 
> >      A mobile node detects that it has returned to its home 
> link through
> >      the movement detection algorithm in use (Section 
> 11.5.1), when the
> >      mobile node detects that its home subnet prefix is 
> again on-link.
> >      The mobile node SHOULD then send a Binding Update to 
> its home agent,
> >      to instruct its home agent to no longer intercept or 
> tunnel packets
> >      for it.
> > 
> >  NEW:
> > 
> >      A mobile node detects that it has returned to its home 
> link through
> >      the movement detection algorithm in use (Section 
> 11.5.1), when the
> >      mobile node detects that its home subnet prefix is 
> again on-link.
> >      The mobile node MUST then send a Binding Update to its 
> home agent,
> >      to instruct its home agent to no longer intercept or 
> tunnel packets
> >      for it.
> > 
> > 
> >  
> ---------------------------------------------------------------------
> > 
> >  Gerardo Giaretta <gerardog at qualcomm.com>
> > 
> >  This was discussed also in Philadelphia and in general I agree a
> >  MUST is more appropriate.
> > 
> >  However we should make clear that the MN MUST send the 
> deregistration
> >  BU only when it wants the HA to stop intercepting packets and
> >  forwarding them to the CoA.
> > 
> >  Let's assume for example the MN has two active interfaces, 
> it is using
> >  interface with CoA1 registered at the HA. Then it switches 
> interface2
> >  on and detects interfaces2 is connected to the home link. 
> This should
> >  not immediately trigger the MN to send the BU, unless the 
> MN wants all
> >  traffic destined to the HoA routed to interface2 (the MN may still
> >  want to have the traffic destined to interface1).
> > 
> >  
> ---------------------------------------------------------------------
> > 
> >  Sri Gundavelli <sgundave at cisco.com>
> > 
> >  We discussed this issue in the last meeting and I thought
> >  the conclusion there was, if the mobile node attaches to
> >  the home link and *if* it decides to use the home address
> >  i.e., defend the home address on the home link, then it
> >  MUST send a dereg BU. This will avoid the Proxy ND contention.
> >  Note that it is possible the MN is attached to the home,
> >  but may choose to send the dereg bit later. So, the wording
> >  has to reflect this aspect.
> > 
> >  
> ---------------------------------------------------------------------
> > 
> >  Ahmad Muhanna  <amuhanna at nortel.com>
> > 
> >  IMO, the best for RFC3775 and RFC3775bis is to maintain 
> "SHOULD" because
> >  my understanding of "SHOULD" is that the MN MUST send 
> de-registration
> >  UNLESS there is a condition that makes it impossible on 
> the MN to send
> >  de-registration, e.g. MN lost coverage, or lost power, etc.
> > 
> >  The usefulness of SHOULD in base RFC3775 that it can be 
> become "MUST"
> >  in a specific scenario where that is possibly described in 
> a different
> >  doc, like the case that Gerardo mentioned. IMO, that 
> "MUST" should be
> >  captured in the Multi-CoA doc not in RFC3775bis.
> > 
> >  On the other hand, the latest change defeats the original 
> purpose of
> >  RFC3775, because RFC3775 mandates on the MN to send 
> de-registration,
> >  however, the last change, proposed here, makes it based on the MN
> >  discretion and that is very dangerous.
> > 
> >  I disagree with this change and I favor maintaining "SHOULD" in
> >  the base document and if "MUST" is needed in a specific scenarios
> >  let us capture that in the respected document.
> > 
> >  
> ---------------------------------------------------------------------
> > 
> >  George Tsirtsis  <tsirtsis at googlemail.com>
> > 
> >  ... it does not make sense to require
> >  that the MN sends a dereg BU when it connects to its home link.
> >  Instead this is a MIPv6 layer decision that has nothing to do with
> >  whether the MN has connection only to the home link or to 
> one or more
> >  other links at the same time.
> > 
> >  
> ---------------------------------------------------------------------
> > 
> >  Sri Gundavelli <sgundave at cisco.com>
> > 
> >  ...I'm ok leaving the initial SHOULD
> >  wording, however, the technical issue that I see and as I
> >  said before is that we should clearly document and state
> >  that the MN MUST send a dereg message before it can start
> >  using its hoa on the home link and that will avoid any ND
> >  contentions between the HA and the MN. This is not implicit
> >  and cannot be left to the reader and so must be documented.
> > 
> >  Generally, it can be stated the MN must send a dereg. But,
> >  the issue related to power down ...etc. ..etc are probably
> >  valid and there may be valid reasons as why MN may not be
> >  able to send a dereg message. So, we can always qualify
> >  that requirement and state that the MN must send a dereg
> >  before it can start using its home address on the home link
> >  and also leave the option for it not to send any dereg
> >  message in some situations and when it has no need to use
> >  its HoA.
> > 
> >  Bottom line:
> > 
> >  - Leave the SHOULD as a strong recommendation for the MN
> >  to send dereg, as it is currently written.
> > 
> >  - Add additional text and state the MN MUST send a dereg
> >  before it can use its hoa on the home link.
> > 
> >  
> ---------------------------------------------------------------------
> > 
> >  George Tsirtsis  <tsirtsis at googlemail.com>
> > 
> >  Sri/Ben, IMHO combining SHOULDs/MAYs and MUSTs with "if" statements
> >  does not result in good specs. For example, the MUST in 
> Ben's proposal
> >  is to be followed only if the MN *intends* to  get its 
> traffic to flow
> >  on the home link and, not following the MUST does not 
> really break the
> >  protocol. In any case, *intentions* are not easy to evaluate during
> >  interoperability testing.  So, maybe we should simply try 
> to clarify
> >  the SHOULD. Here is a proposal:
> > 
> >  OLD Text:
> > 
> >     A mobile node detects that it has returned to its home 
> link through
> >     the movement detection algorithm in use (Section 
> 11.5.1), when the
> >     mobile node detects that its home subnet prefix is 
> again on-link.
> >     The mobile node SHOULD then send a Binding Update to 
> its home agent,
> >     to instruct its home agent to no longer intercept or 
> tunnel packets
> >     for it.
> > 
> >  NEW Text:
> > 
> >     A mobile node detects that it has returned to its home 
> link through
> >     the movement detection algorithm in use (Section 
> 11.5.1), when the
> >     mobile node detects that its home subnet prefix is 
> again on-link.
> >     The mobile node SHOULD then send a Binding Update to 
> its home agent,
> >     to instruct its home agent to no longer intercept or 
> tunnel packets
> >     for it. Until the mobile node sends a de-registration 
> Binding Update,
> >     it will not be able to send and receive packets using its home
> >     address from the home link. The home agent will 
> continue to intercept
> >     all packets sent to the mobile's home address and tunnel to the
> >     previously registered care-of address.
> > 
> > 
> > 
> ----------------------------------------+---------------------
> --------------
> >  Reporter:  charliep at computer.org       |       Owner:  
> charliep at computer.org
> >      Type:  defect                      |      Status:  new 
>                  
> >  Priority:  minor                       |   Milestone:      
>                  
> > Component:  draft-ietf-mext-rfc3775bis  |     Version:      
>                  
> >  Severity:  Active WG Document          |    Keywords:      
>                  
> > 
> ----------------------------------------+---------------------
> --------------
> 
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
> 
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext