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

From: Julien Laganier <[email-masked]>
Date: Tue, 23 May 2006 14:54:15 +0200

Alex,

Please remember that this thread discuss issue #23 (more below)

On Tuesday 23 May 2006 14:32, Alexandru Petrescu wrote:

(snip)

>
> >> Suggest reading and send comments on:
> >>
> >> http://www.ietf.org/internet-drafts/draft-templin-autoconf-netlm
> >>m-d hcp-0 0.txt
> >
> > I did. You seem to insist that "if DHCP is used then..."
> >
> > What if DHCP is not used? (AFAIK, stateless address autoconf is a
> > MUST for IPv6, while stateful (DHCP) is only a MAY.)
>
> DHCPv6 may indeed be a MAY, compared to stateless autoconf, yet
> it's widely implemented.  For open source it's called Dibbler, may
> be in Debian.  For BSD I think FreeBSD has it too.  Non-open source
> - I think some routers have it too, maybe Windows too.

I don't remember arguing that DHCPv6 is not implemented.

BTW, stateless autoconf is implemented too.

> > So I don't think that DHCP is relevant to this issue.
>
> DHCPv6 may address some of the address uniqueness netlmm concerns.

Issue #23 that Fred brought up is:

> The protocol implies that all of the possibly many ARs should send 
> an UPDATE to the MAP when the MN sends the NS(DAD). Some might view 
> this as being OK, i.e., that it is good to have the extra state in 
> the MAP for the purpose of fault tolerance. But others might view it 
> that having multiple entries for the same MN in the MAP and the 
> extra control traffic represent unnecessary overhead.     

I don't see reference to uniqueness here.

> > So I still think that no text change is needed w.r.t. issue #22.
> > Anyone else with a different opinion?
>
> I lean on using DHCPv6 if it solves some of the netlmm needs.

Fine with me, but the issue we are discussing here (#23) is different. 

Regarding the use of DHCP in NetLMM domains, proposed resolution of 
ticket #24 suggest to add text saying that when DHCP is used, relay 
and server might be collocated (at least interfaced) with AR and MAP. 

--julienone else with a different opinion?
>
> I lean on using DHCPv6 if it solves some of the netlmm needs.

Fine with me, but the issue we are discussing here (#23) is different. 

Regarding the use of DHCP in NetLMM domains, proposed resolution of 
ticket #24 suggest to add text saying that when DHCP is used, relay 
and server might be collocated (at least interfaced) with AR and MAP. 

--julien

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 23 May 2006 15:13:13 +0200

Julien Laganier wrote:
>> http://www.ietf.org/internet-drafts/draft-templin-autoconf-netlmm-d
>>  hcp-0 0.txt
> 
> What if DHCP is not used?

Just one last point.  I mainly agree with minimal modifications on the
mobile.

It is possible that DHCPv6 is not used on mobile's wireless interface.
It is possible that ND is not used either.  Even if stateless autoconf
is a MUST, mobiles don't always run ND on some interfaces on which they
do run IPv6.  Typical case is an IPv6 GPRS connection.  The IPv6 address
is negotiated with a L2 protocol, maybe LCP; ND is not run, neither ARP.
  802.16e seems to have the same sort of link-layer "tunnel" between
mobile and first hop, here ND is not likely to be used either.

Otherwise, I agree that hooking on ND is a good possibility for
triggering netlmm signalling if run on multiple-access media, like LAN.
  DHCP makes sense too in that case.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 23 May 2006 15:18:06 +0200

Julien Laganier wrote:
>>  be in Debian.  For BSD I think FreeBSD has it too.  Non-open
>> source - I think some routers have it too, maybe Windows too.
> 

Yes, I agree both.

>> the MAP for the purpose of fault tolerance. But others might view
>> it that having multiple entries for the same MN in the MAP and the

Sorry, I'll have to find the uniqueness thread.

To me, the whole point of the issue is because if using ND as trigger
then we're somehow forced into DAD, whose goal is address uniqueness.
But I will not insist on it.

> and server might be collocated (at least interfaced) with AR and MAP.
I agree.

> and server might be collocated (at least interfaced) with AR and MAP.
Sounds good, thanks, sorry if interfering.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 May 2006 16:59:45 -0700

Julien,

Cutting down some: 

>> 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. 
>
> I don't see anything incredible here; Do you mean it is incredible to 
> elect one entity out of a finite set?

'Incredible' was an inappropriate use of a superlative on my
part; sorry for that.

>> 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. 
>
> Two points here. 
>
> 1) Regarding the fact that no such protocol is required, well the goal

> of that WG is no design a protocol anyway so I don't see the point in 
> avoiding to have one.
>
> 2) If such election is taken care in the backbone, still the MN can 
> select itself which AR to use. It will simply happen that the MN will 
> respectivelly send and receive packets from the AR _it_ selected, and 
> from the AR elected in the backbone.

I agree that the MN can still select default ARs of its own
choosing, and that these may be different than the AR that was
elected to register the MN's addresses with the MAP.

The point is that when the network does the address registration
based on a MN's NS(DAD) to a solicited-node multicast address, and
there are many ARs on the link, the election process will involve
control message overhead that is not incurred when the address
registration mechanism is unicast-based.

If the MN-AR interface spec were modified to specify that a MN's
NS(DAD) should be sent to a unicast address instead of the
solicited-node multicast address, that would alleviate the
control message overhead when there are many ARs on the link.
But, I realize that that would entail a change to the standard
RFC2461/2 mechanisms.

Fred
[email-masked]