Subject: Re: [netlmm] Re: Issue #22 (Was: Re: Issues #22 and #23)

From: Julien Laganier <[email-masked]>
Date: Thu, 1 Jun 2006 10:32:38 +0200

Fred,

I'll do my best to write down the text on DHCP asap.

Regarding the applicability statement, IMHO if we produce one it 
should not be restricted to only one component of NetLMM but rather 
consider the entire system because that's what will be 
applied/deployed in the end. So yes, it seems out-of-scope of the 
mn-ar-if doc.

Thanks.

--julien

On Wednesday 31 May 2006 23:15, you wrote:
> Julien,
>
> I see the point about complementary approaches and am OK with
> the proposed resolution based on the text you produce. About
> applicability, I would still like to see this group produce
> something that will give an analysis of host-based and
> network-based alternatives for various use cases but I guess
> that would be outside the scope of the MN-AR interface spec?
>
> Thanks - Fred
> [email-masked]
>
> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]]
> Sent: Wednesday, May 31, 2006 10:35 AM
> To: Templin, Fred L
> Cc: [email-masked]; Chakeres, Ian D
> Subject: [netlmm] Re: Issue #22 (Was: Re: Issues #22 and #23)
>
> Fred,
>
> [Sorry for the lag, I'm currently very busy]
>
> Regarding your point on DHCP, the proposed resolution for issue #24
> is to add text specifying how to integrate NetLMM and DHCP
> deployments. I did not have time yet to write down the actual text
> but I have already an idea of what I'm going to write (AFAICS
> there's no hard issue there.)
>
> So we do not need to oppose a DHCP-based triggering of NetLMM to
> the ND-based one. I see them as complimentary. In a network using
> stateless autoconf ND is appropriate. *If* the deployment has DHCP
> I'm fine with it and the MN-AR interface will soon describe that.
>
> Regarding the need for an applicability statement I don't have a
> strong opinion on that matter. I have the feeling that the people
> who will develop NetLMM implementations will understand enough the
> technology to apply it where necessary and documents their
> implementation/product so that end-users know where to use it best.
>
> Best,
>
> --julien
>
> On Friday 26 May 2006 01:36, Templin, Fred L wrote:
> > Julien,
> >
> > I discussed this in detail with my colleagues at Boeing, and
> > our conclusion was that there may be issues for control message
> > loss in certain scenarios (e.g., IEEE 802.11 unreliable
> > multicast) but the comparative analysis needs to be more balanced
> > (see below).
> >
> > The main point is that we believe the DHCP approach may be more
> > widely applicable but the network-based approach may be suitable
> > for certain use cases, e.g., if the DHCP client is seen as too
> > much complexity for constrained MNs and the network is robust
> > enough to avoid control message loss issues.
> >
> > As such, we believe an applicability analysis and statement for
> > NETLMM is necessary. Please see below for more details and send
> > comments.
> >
> > Fred
> > [email-masked]
> >
> > Appendix B.  Control Message Loss Implications for NETLMM
> >
> >    [I-D.ietf-netlmm-mn-ar-if] specifies a network-based mechanism
> > that uses a MN's duplicate address detection procedure to
> > implicitly trigger address registration signaling between the AR
> > and the MAP, while this document specifies a host-based mechanism
> > that uses a MNs DHCP requests to explicitly trigger address
> > registration signaling between the MN and the MAP.  Control
> > message loss implications for both scenarios are analyzed in the
> > following sections:
> >
> > B.1.  Implications for Network-Based Signaling
> >
> >    In the network-based signaling method specified in
> > [I-D.ietf-netlmm- mn-ar-if], if the MN configures a tentative
> > address and sends a Neighbor Solicitation (NS) message to the
> > solicited-node multicast address (see: [RFC2462], Section 5.4.2),
> > but a control message is lost somewhere on the MN<->AR<->MAP
> > paths, the MN could incorrectly conclude that its tentative
> > address was both unique and successfully registered with the MAP.
> >  The following scenarios can occur:
> >
> >    1.  If the MN's multicast NS message is lost on the MN->AR
> > path, the AR will not perform address registration and the MN
> > will receive no indication that address registration failed.  The
> > MN will then incorrectly assign the tentative address to an
> > interface after RetransTimer msecs (see: [RFC2462], Section 5.4).
> >
> >    2.  If the AR attempts to register a MN's tentative address
> > with the MAP and the MAP returns an indication that the address
> > was a duplicate, the AR will defend the MN's tentative address by
> > sending a Neighbor Advertisement (NA) message to the all-nodes
> > multicast address on the AR->MN path as specified in ([RFC2461],
> > Section 7.2.4).  If the NA message is lost, the MN will
> > incorrectly assign the tentative address to an interface after
> > RetransTimer msecs.
> >
> >    3.  If a control message is lost on the AR<->MAP paths, the AR
> > can assume loss after a timeout period and retry the registration
> > until an acknowledgement is received.  If the retries are not
> > completed within RetransTimer msecs and the address registration
> > fails (due to address duplication or excessive retries), the MN
> > will incorrectly assign the tentative address to an interface.
> >
> >    One possible mitigation is for the MN to set
> > DupAddrDetectTransmits (see: [RFC2462], Section 5.4) to some
> > value greater than 1 at the expense of extra control message
> > overhead and extra delay, but this mitigation can fail when more
> > than DupAddrDetectTransmits control messages are lost.  A
> > complementary mitigation is for the AR to set its retry timer to
> > some value smaller than RetransTimer/N (where N is the desired
> > number of retries) and/or for the MN to set RetransTimer to some
> > value larger than the default of 1000 msecs.  But, since the
> > MN<->AR<->MAP paths may be carried over links with
> > arbitrarily-long delays, selecting appropriate timer values may
> > be problematic in some use cases. Also, this mitigation can fail
> > when a NS/NA message is lost on the MN<->AR paths.
> >
> > B.2.  Implications for Host-based Signaling
> >
> >    In the DHCP-based MN-driven case specified in this document,
> > if a control message is lost on the MN<->AR<->MAP paths, 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 may have created useless address delegation state
> > that will expire after the lease lifetime expires but the MN will
> > not incorrectly assign an address to an interface.  The MN is
> > also free to try again using different ARs which should lead to
> > successful address registration and acknowledgement.
> >
> >    DHCPv4 requests encode a Transaction ID ('xid') used by the
> > client to match incoming messages with pending requests, and
> > ([RFC2131], Section 4.1) states that: "Selecting a new 'xid' for
> > each retransmission is an implementation decision.  A client may
> > choose to reuse the same 'xid' or select a new 'xid' for each
> > retransmitted message.".  DHCPv6 requests likewise encode a
> > Transaction ID ('transaction-id'), but ([RFC3315], Section 15.1)
> > states that: "A client MUST leave the transaction ID unchanged in
> > retransmissions of a message.".
> >
> >    So, for MNs that implement a DHCPv4 client that selects a new
> > 'xid' for each retransmission, address registration may fail even
> > after successive retries if the delay across the MN<->AR<->MAP
> > paths is longer than the retransmission time.  For MNs that
> > implement a DHCPv4/DHCPv6 client that uses the same Transaction
> > ID for successive retries, address registration should succeed
> > since any DHCP reply will complete the (retransmitted) DHCP
> > request.
> >
> > B.3.  Summary
> >
> >    The network-based signaling mechanisms specified in
> > [I-D.ietf-netlmm- mn-ar-if] leave opportunity for the MN to
> > incorrectly assign an address to an interface, while the
> > host-based signaling mechanisms specified in this document do
> > not.  Therefore, applicability of the network-based model must be
> > carefully analyzed for specific use cases and compared against MN
> > complexity in the host-based method.
> >
> >
> >
> > -----Original Message-----
> > From: Julien Laganier [mailto:[email-masked]]
> > Sent: Tuesday, May 23, 2006 3:34 AM
> > To: [email-masked]
> > Cc: Templin, Fred L; Russert, Steven W; Chakeres, Ian D
> > Subject: Issue #22 (Was: Re: Issues #22 and #23)
> >
> > On Thursday 11 May 2006 19:38, Templin, Fred L wrote:
> > > Repost to include dhc wg; comments to the list:
> >
> > [ Not sure this is relevant to DHCWG list. Removed it. ]
> >
> > > Some comments on resolutions for issues #22 and #23:
> > > > Issue #22: Multicast IPv6 ND triggers do not provide MN with
> > > > confirmation of MAP registration success/failure.
> > > > <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/22>
> > >
> > > Agree with cases 1) and 2), but there is also another case:
> > > 3) AR fails to reach the MAP due to packet loss caused by
> > > temporal congestion, signal intermittence, etc. In that
> > > case, the AR has to wait for a timeout period before either
> > > trying again or returning a false negative to the MN.
> > >
> > > If the AR takes too much time in retrying, the MN will
> > > wrongly conclude that its address has been registered with
> > > the MAP and its communications using that address will go
> > > into a black hole.
> >
> > I fail to see how the situation you describe is specific to
> > NetLMM.
> >
> > What if a plain host (not mobile, not in a NetLMM domain) selects
> > an AR, but it happens that because of "packet loss caused by
> > temporal congestion, signal intermittence, etc." that the IGP on
> > that AR does not run properly preventing it to deliver packets...
> >
> > It would send to the MN a ICMP destination unreachable and
> > hopefully the MN would select another AR if there's one.
> >
> > > If the AR returns a false negative (i.e.,
> > > a solicited NA), the MN will wrongly conclude that its
> > > proposed address is a duplicate. Neither of these anomalous
> > > conditions would occur if MAP registrations were driven by
> > > the MN itself instead of the AR, e.g., when the MN/AR/MAP
> > > are configured as DHCP client/server/relay.
> >
> > I already expressed my opinion about DHCP: What if DHCP is not
> > there? In the absence of DHCP, because our charter assume no host
> > involvevement w.r.t. NetLMM how can the MN drive the MAP
> > registration itself?
> >
> > It sends a NS (as part of DAD) or a RS (as part of DNA). I said
> > all of that already so I'll try to refrain from posting the same
> > arguments again here. If anyone else has an opinion please speak
> > up.
> >
> > --julien
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Jun 2006 09:56:18 -0700

> I'll do my best to write down the text on DHCP asap.

OK.

> applied/deployed in the end. So yes, it seems out-of-scope of the 

Agree with a systems-view. From what I know now, if I were to write
such an applicability analysis I would probably say something to the
effect that a host-based solution (most likely DHCP-based) may be more
widely applicable across a broad range of use-cases but a network-based
solution may be appropriate for low-end systems in relatively robust
networks. I also believe the latter may be a much broader category than
the terminology implies, e.g., a "low-end system" could be anything from
a cell phone to a dust spec with a radio transceiver, and a "relatively
robust network" could be anything that gives reasonable assurance of
control message delivery.

Fred

Thanks.

--julien