Subject: RE: [netlmm] a couple of high-view questions

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 19 May 2006 11:57:56 -0700

Pekka,

I thought it might be best to capture this thread in an
appendix for 'draft-templin-autoconf-netlmm-dhcp'. Please
check the following and comment:

Fred
[email-masked]

Appendix B.  Failure Cases for Network-Based Signaling

   [I-D.ietf-netlmm-mn-ar-if] presents a signaling specification that is
   network-based and occurs without the explicit participation of the
   MN.  But, this approach can lead to failure cases that are difficult
   to diagnose when control messages are lost due to, e.g., congestion,
   link errors, signal intermittence, receive buffer overflows, etc.

   A particular failure case occurs when a MN first enters a LMMD and
   configures addresses that need to be registered with the MAP and
   tested for uniqueness - see: ([I-D.ietf-netlmm-mn-ar-if], Section
   2.1) and ([RFC2462], Section 5.4).  In that case, if the MN sends
   NS(DAD) but a control message is lost somewhere on the MN<->AR<->MAP
   paths, the MN could wrongly conclude that the tentative address has
   been registered with the MAP and the MN's communications using that
   address will go into a black hole.

   If a control message relating to address registration for a MN's
   tentative address is lost anywhere on the AR<->MAP paths, the AR
   could assume failure after a timeout period and retry the
   registration until an acknowledgement is received.  But, if the
   retries do not occur within RetransTimer msecs the MN could wrongly
   conclude that the tentative address was successfully registered with
   the MAP when in fact it was a duplicate, leading to the black hole
   case as well as confusion for the true owner of the (duplicate)
   address.

   Alternatively, the AR could assume failure after a timeout period and
   send NA(DAD) to defend the address instead of retrying the
   registration.  If NA(DAD) is sent within RetransTimer msecs, the MN
   will wrongly conclude that the tentative address was a duplicate.  If
   the NA is not sent within RetransTimer msecs, then the MN will
   wrongly conclude that the address was successfully registered with
   the MAP and will assign the tentative address to an interface leading
   to the black hole case.

   On the MN side, one possible mitigation is to set
   DupAddrDetectTransmits (see: [RFC2462], Section 5.4) to some value
   greater than 1 at the expense of extra control message overhead,
   extra delay, and at the risk of failing to detect multiple failures
   on the MN<->AR<->MAP paths.  Another possible mitigation is to set
   RetransTimer to some value larger than the default of 1000 msecs, but
   the question becomes how large when the paths between the
   MN<->AR<->MAP may be carried over links with arbitrarily-long delays.
   (Also, this mitigation fails when a control message is lost on the
   MN<->AR paths).

   In the DHCP-based MN-driven model specified in this document, the
   only possible failure case occurs when the MN's DHCP request is
   successfully registered with the MAP's DHCP server, but the DHCP
   reply is lost somewhere on the paths between the MAP->AR->MN.  In
   that case, the MN will retry the DHCP request until a DHCP reply is
   received.  If excessive failures occur and the MN abandons its
   efforts, the DHCP server will have created useless address delegation
   state that will expire after the lease lifetime expires, but the MN
   will never draw a wrong conclusion that could lead to communication
   failures.  The MN is also free to try again using a different AR
   which should eventually lead to successful address registration and
   acknowledgement.

   To summarize, the network-based signaling mechanisms specified in
   [I-D.ietf-netlmm-mn-ar-if] leave opportunity for the MN to draw wrong
   conclusions with potentially disastrous consequences, since the MN
   interprets silence as an indication of successful registration.
   There is no such opportunity for the MN to draw wrong conclusions in
   the DHCP-based MN-driven model.  These observations derive directly
   from the end-to-end principles [E2E]. 

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2006 10:15 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: RE: [netlmm] a couple of high-view questions

On Tue, 16 May 2006, Templin, Fred L wrote:
>>> OK, but when a MN moves to a new AR, an update will still have
>>> to be sent to the MAP (LMA) - right? Were you thinking that the
>>> MN would send the update, or that the AR would send the update
>>> on behalf of the MN?
>>
>> The AR would send the update on behalf of the MN.
>
> What if the update fails?

I'm not sure what you mean by a failing update, probably that it gets 
dropped somewhere...

If the update is not acknowledged within the specified interval (OSPF 
default is 5 seconds if I recall correctly, we've adjusted it to 1 or 
2 seconds in our network), the update will be retransmitted, multiple 
times if necessary.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm