Subject: [MEXT] [mext] #15: BRR sent by HA too, not only by CN [Ahmad Muhanna <[email-masked]>]

From: "mext" <[email-masked]>
Date: Mon, 14 Jul 2008 21:31:16 -0000

Ticket #15: BRR sent by HA too, not only by CN  [Ahmad Muhanna  <[email-masked]>]

 BRR sent by HA too, not only by CN  [Ahmad Muhanna  <[email-masked]>]

 The proposed change is a new functionality that it is not withing the
 scope of RFC3775bis and also requires new software update on the HA.

 On the other hand, I changed the subject again to read as "Applicability
 of sending BRR, BErr by the HA?"

 IMO, you need to separate these two messages (BRR and BErr) and they
 need to be discussed separately.

 Case of BRR message:

 I believe the intention of RFC3775 is to restrict the use of this
 message to the CN ONLY. IMO, it is quite clear that within the scope of
 RFC3775, this message is not applicable to the HA. For the following
 reasons:

 1. RFC3775 defines a protocol to enable a mobile node to register its
 CoA in a foreign network with its home agent in order to be reachable at
 its home address. i.e. create a binding for the MN CoA and its HoA at
 the Home Agent.

 2. RFC3775 developed a mechanism for the MN to refresh its BCE, i.e.
 RFC3775 defined a field in BA which is called lifetime. This field
 indicates to the MN the approved lifetime that the Home Agent agreed to
 honor while offering mobility services to the MN and at the same time
 maintain a BCE for the MN CoA and HoA.

 3. In the contents of RFC3775 the mobile node is quite aware that
 without maintaining a current BCE at its Home agent, i.e. the basic
 fundamental functionality of MIPv6, the Mobile node will loose all of
 its mobility services and its reachability at the foreign network using
 its HoA.

 4. RFC3775 specify that the MN needs to send a new BU message in order
 to refresh or extend the BCE lifetime. This is extremely important
 because a node like the HA, does not need to send a reminder to every
 single MN that it serves and maintains a BCE for.

 5. If the HA needs to send a reminder to every MN about the expiry of
 its BCE, then we are introducing a new functionality which violates the
 basic RFC3775 functionality and a non sense complexity that absolutely
 is not necessary and not within the original intention of RFC3775.

 6. On the other hand, CN maintains a limited number of BCE for specific
 mobile nodes and more importantly if the MN decides NOT to renew its BCE
 with a specific CN, the MN continues to be reachable by other CNs at its
 HoA and CoA via its Home Agent BCE. In other words, a MN binding with
 another CN represent the service (RO) between MN<->CN ONLY, however, in
 the case of HA it represents the MN's MIP6 service and access to the
 whole internet. Which also administratively governed. i.e. if the MN
 does not renew its BCE, then that is a clear indication for the HA to
 delete the MN BCE.

 7. Finally, the fact that RFC3775 mentions that CN could be a HA, does
 not mean that the HA application at such a node need to support BRR.
 IMO, such a node could act as a CN for some MNs and a HA for others.
 Then, it is normal for this CN/HA node to support BRR for those MN which
 is serving as a CN but not a HA.

 ---------------------------------------------------------------------

 Alexandru Petrescu  <[email-masked]>

 Hi Ahmad, I've changed the topic.  Please make another thread, if you
 wish, about applicability and scope.

 Ahmad Muhanna wrote:
 [...]
 > [Ahmad] Hi Alex, The proposed changes is a new functionality
 > that it is not withing the scope of RFC3775bis and also requires
 > new software update on the HA.

 In what does that HA-sends-BRR functionality violate the basic 3775?
 What does it break?

 I see it offering better reliability: even if the critical BU is lost
 the HA requests the BU anew (BRR) and thus reduces the non-bound time
 from the entire lifetime to much less.

 > 6. On the other hand, CN maintains a limited number of BCE for
 >    specific mobile nodes and more importantly if the MN decides
 >    NOT to renew its BCE with a specific CN, the MN continues to
 >    be reachable by other CNs at its HoA and CoA via its Home Agent
 >    BCE. In other words, a MN binding with another CN represent
 >    the service (RO) between MN<->CN ONLY, however, in the case
 >    of HA it represents the MN's MIP6 service and access to the
 >    whole internet. Which also administratively governed. i.e.
 >    if the MN does not renew its BCE, then that is a
 >    clear indication for the HA to delete the MN BCE.

 Not before it sends a BRR and waits for an answer to that.

 > 7. Finally, the fact that RFC3775 mentions that CN could be
 >    a HA, does not mean that the HA application at such a node
 >    need to support BRR.

 That's your reading.  Other implementers read it in the way I said.

 > IMO, such a node could act as a CN for some MNs and a HA for
 > others.  Then, it is normal for this CN/HA node to support BRR
 > for those MN which is serving as a CN but not a HA.

 Is a HA a "CN" when it is the dst field of the BU?

 ---------------------------------------------------------------------

 Ahmad Muhanna  <[email-masked]>

 Okay, then RFC3775 has a mechanism already specified for updating the MN
 BCE at its HA, why do we need another new functionality which, IMO, does
 not scale and may cause a huge problem for the HA?

 > In what does that HA-sends-BRR functionality violate
 > the basic 3775? What does it break?

 [Ahmad]
 I am not sure if what does break is the right question here.
 It is a new functionality which is fundamentally in conflict
 with the original RFC3775 intention of how MIP6 BCE is managed
 at the HA.  However, let me explain what could happen in case
 that the HA implements this new weird functionality:

 {{{
 #!html
 <OL>
 <LI value="1">
  Some of the HA are talking about supporting a million BCE
    simultaneously. Do you understand the impact on the HA when
    these BCEs starts getting close to expiry? and the HA needs
    to send a BRR message and not only that but retransmits those
    messages until a BU is received from each one of these MNs?
 </OL>
 }}}

 {{{
 #!html
 <OL>
 <LI value="3">
  Personally, I wont agree to such functionality because
    Home Agent acts as a server offering a MIP6 mobility service
    to multiple MNs governed by a MIP6 protocol which offers a
    reliable mechanism for updating the MN BCE lifetime at the HA.
 </OL>
 }}}

 {{{
 #!html
 <OL>
 <LI value="4">
  Let us assume for the sake of argument that this new
    functionality is supported by the HA, what is the impact:
 <UL>
 <LI>
 4.1. Can you imagine the unnecessary traffic that is
      generated for no reason?
 <LI>
 4.2. What is going to be the MN processing when it receives
      such a message? All current RFC3775 text talks about a BRR
      coming from the CN.  Is there going to be a difference in there?
 <LI>
 4.3. How MN would recognize that this message is related to
      MN BCE at the HA?
 <LI>
 4.4. Backward compatibility, How, this would work for MN
      which only supports BRR from the CN?
 <LI>
 4.5. Finally, if this procedure is adopted, are we going
      to deprecate the existing one using lifetime field in BA, etc?
 </UL>
 </OL>
 }}}
 > I see it offering better reliability: even if the critical BU
 > is lost the HA requests the BU anew (BRR) and thus reduces
 > the non-bound time from the entire lifetime to much less.

 [Ahmad]
 1. Wow! Are you calling this a better reliability? What is your definition
 of reliability then?

 ---------------------------------------------------------------------

 Marcelo Bagnulo Braun <[email-masked]>

 i am trying to understand the impact of this in rfc3775 update

 I don't think that whether it is a good idea to use BRR from
 the HA is relevant for the discussion of RFC3775 update (it is
 of course relevant for the mext ml but not imho for this
 particular process of updating rfc3775)

 what imho is relavnt for the discussion of updating rfc3775
 is whether rfc3775 is clear enough about whether HAs should
 send BRR or not

 From the text of rfc3775 that Alex sent in his original posting,
 it seems that only CNs should send BRR and BE and not by the HA,
 so, is there any text in rfc3775 that can possibly create
 confusion about HAs using BRR or BEs? Does anyone has interpreted
 rfc3775 in the way that HAs should send BRR and BEs?

 ---------------------------------------------------------------------

 K.Kawaguchi <[email-masked]>

 Couldn't we understand description <of BRR> in RFC3775 as follows?

   CN sends BRR.
       - Section 9.5 described Registration of CN.
         In it, section 9.5.5 described Sending BRR.

   HA does not send BRR.
       - Section 10.3 described Rigistration of HA.
         Although section 9.5.1 and section 9.5.4 were
         referred to, section 9.5.5 wasn't referred to.

----------------------------------------+-----------------------------------
 Reporter:  [email-masked]       |       Owner:  [email-masked]       
     Type:  enhancement                 |      Status:  new                         
 Priority:  minor                       |   Milestone:  milestone1                  
Component:  draft-ietf-mext-rfc3775bis  |     Version:  2.0                         
 Severity:  Active WG Document          |    Keywords:  BRR, Binding Refresh Request
----------------------------------------+-----------------------------------
-- 
Ticket URL: <http://wiki.tools.ietf.org/wg/mext/trac/ticket/15>
mext <http://tools.ietf.org/wg/mext/>
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext