Issues #22 and #23 (was: RE: New Issues #22, #23, #24, #25, #26 and #27)

Repost to include dhc wg; comments to the list:

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. 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.   

> Issue #23: Multicast IPv6 ND triggers cause many ARs to
send UPDATEs 
> when there are many ARs on the link.
> <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/23>

The proposed solution assumes a NETLMM backbone protocol
in which potentially many ARs engage in a decision process
as to which one(s) should register the MNs address with the
MAP. Such a backbone protocol would need to be incredibly
well coordinated and agile. When the MN/AR/MAP are
configured
as DHCP client/relay/server there is no such backbone
protocol
required, since the MN itself selects which AR(s) to use.

Suggest reading and send comments on:

http://www.ietf.org/internet-drafts/draf
t-templin-autoconf-netlmm-dhcp-0
0.txt  

Fred
fred.l.templinboeing.com

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg