Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO

From: "Julien Laganier" <[email-masked]>
Date: Fri, 21 Sep 2007 11:38:46 +0200

On Thursday 20 September 2007, Alexandru Petrescu wrote:
> Julien Laganier wrote:
> > Alex:
> >
> > I write my messages with great care, and I try to be as articulate
> > as I can.
> >
> > You seem to think that is a problem "we guys" (whoever that
> > includes) "talk DHCP", "don't rely on prototyping or deployment
> > experience", etc. I don't want to argue with you about what I do.
> >
> > Let me just suggest that the main problem could be that *you* do
> > not read carefully enough messages -- for example you are saying
> > below "I don't think we can mandate DHCP in any way in PMIPv6".
> > This is irrelevant since nobody ever said that DHCP should be
> > *mandated*.
> >
> > Hence I think this discussion it unproductive at best and I will
> > not continue it.
>
> Sorry Julien, I may not read carefully all messages - my fault.

Alex, yesterday you posted 17 messages with that subject on the netlmmm
mailing list, which were carefully read by at least some subscribers to
the list.

IMHO it would be fair that you take the necessary time to read carefully
messages of your interlocutors.

Further, let me suggest that if you would do so you might not need to
post as many messages on the topic, and the discussion would be far
more productive.

I do not intend to follow-up anymore on that thread so there's no need
to reply to me.

--julien

> Continuing to debate on whether we should have DHCP working ok with
> PMIPv6 is a good thing IMHO.
>
> I think DHCP over ptp links doesn't make much sense, I think you
> don't either.  If you did you could have said at least that you've
> seen it.
>
> Sorry if any of my phrases look disrespectful about what you do.
>
> Alex
>
> > --julien
> >
> > problem On Thursday 20 September 2007, Alexandru Petrescu wrote:
> >> Alper Yegin wrote:
> >> [...]
> >>
> >>>> And you keep telling me a certain SDO can support everything,
> >>>> this is deceiving.  I know many other SDOs who'll also support
> >>>> everything.
> >>>
> >>> What is the problem? What is your proposal? I'm lost.....
> >>
> >> The problem is that you guys talk DHCP for PMIPv6 because you
> >> think a certain SDO might require it in the future.  The problem
> >> is also that you guys don't rely on prototyping or deployment
> >> experience when you request/reject DHCP presence; you only rely
> >> your claims on what other SDOs want or might want.
> >>
> >> The proposal is to talk a little more implementation and/or
> >> prototyping and see from these experiences how DHCP can fit in.
> >> Is there a prototyping or full deployment experience with a MS
> >> using DHCP over a ptp wireless access link?  (not DSL, not wifi
> >> hotspot).
> >>
> >> Because if there isn't, then I don't think we can mandate DHCP in
> >> any way in PMIPv6.
> >>
> >> Alex
> >>
> >>> Alper
> >>>
> >>>> Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Sep 2007 12:08:19 +0200

Julien Laganier wrote:
>>> I write my messages with great care, and I try to be as 
>>> articulate as I can.
>>> 
> Alex, yesterday you posted 17 messages with that subject on the 
> netlmmm mailing list, which were carefully read by at least some 
> subscribers to the list.
> 
> IMHO it would be fair that you take the necessary time to read 
> carefully messages of your interlocutors.
> 
> I do not intend to follow-up anymore on that thread so there's no 
> need to reply to me.

Julien if you have a problem with too many messages on the mailing list
then please use filters, that's why I adapted the subject and keep it
unchanged.

Or you could count them and report and complain, but don't try to stop
me saying that putting a DHCP Relay on the MAG for the sake of just
doing it makes little sense.

If we were to seriosuly deal with shared links in the PMIP6 spec then
having a DHCP Relay in the MAG would make sense.  And DNA and SeND and
probably more.  But PMIPv6 is not concerned at all about shared links, 
as the current spec reads.

It makes no sense to put a DHCP Relay on the MAG as long as PMIPv6
deals only with point to point wireless access links.

You said previously that DHCP is a std tracks IETF spec and as such in
this WG we should not prevent it.  This is not enough and too evasive:
Have we checked all stds track documents are not prevented by PMIPv6?
For example, L2TP is a nice tunnelling protocol for point to point
links, used sometimes in DSL-like environments: does PMIPv6 support or
prevent its use?  The fact is that nobody tried to use L2TP on a
wireless access link for mobiles, thus it makes no sense to suggest that
MAG would need to run L2TP.

Thanks for your mail,

Alex

>>>> Alper Yegin wrote: [...]
>>>>>> And you keep telling me a certain SDO can support 
>>>>>> everything, this is deceiving.  I know many other SDOs 
>>>>>> who'll also support everything.
>>>> think a certain SDO might require it in the future.  The 
>>>> problem is also that you guys don't rely on prototyping or 
>>>> deployment experience when you request/reject DHCP presence; 
>>>> you only rely your claims on what other SDOs want or might 
>>>> want.
>>>> 
>>>>  using DHCP over a ptp wireless access link?  (not DSL, not 
>>>> wifi hotspot).
>>>> 
>>>> Because if there isn't, then I don't think we can mandate DHCP 
>>>> in any way in PMIPv6.
>>>> 
>>>> Alex
>>>> 
>>>>> Alper
>>>>> 
>>>>>> Alex
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 21 Sep 2007 07:24:31 -0700

> deals only with point to point wireless access links.

Hi Alex,

Its important to note that in PMIP6, we are mostly changing the
topology of the network, by moving the HNP between different
MAG's. Once the prefix is hosted on a given MAG, the DHCP related
flows are consistent with the flows on fixed networks. So, we dont
have any control on mandating not to enable DHCP relay on a
given MN-AR link. Sure, its a p2p link, but its a regular IPv6 
link and DHCP relay can be configured on that link. We are not
defining any extensions are putting any hacks to make this work.
It works naturally, the text is there for offering some minimum
guidance. So, if this configuration maken sense or not, is really
upto the deployment. Some operator may choose to use DHCP for
downloading the address configuration and ther options, and I dont
think, we can disallow that configuration.

Thanks
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Sep 2007 16:56:06 +0200

Sri Gundavelli wrote:
> topology of the network, by moving the HNP between different MAG's. 
> Once the prefix is hosted on a given MAG, the DHCP related flows are 
> consistent with the flows on fixed networks. So, we dont have any 
> control on mandating not to enable DHCP relay on a given MN-AR link. 
> Sure, its a p2p link, but its a regular IPv6 link and DHCP relay can 
> be configured on that link. We are not defining any extensions are 
> putting any hacks to make this work. It works naturally, the text is 
> there for offering some minimum guidance. So, if this configuration 
> maken sense or not, is really upto the deployment. Some operator may 
> choose to use DHCP for downloading the address configuration and ther
>  options, and I dont think, we can disallow that configuration.

Sri, I mainly agree with you and with the intention you describe above.
  I do support having DHCP Relay functionality on MAG.

But your text has a restiction on which I don't agree.  It says:
> 6.11.  Interaction with DHCP Relay Agent
> 
> If Stateful Address Configuration using DHCP is supported on the link
>  where the mobile node is attached, the DHCP relay agent [RFC-3315] 
> needs to be configured on that access link.

Why Relay and not Server too?  I mean why silent about Server?  I think
there may be a case for DHCP Server on the MAG.

And then it has a description which I don't understand:
> When the mobile node sends a DHCPv6 Request message, the DHCP relay 
> agent function on the access link will set the link-address field in
>  the DHCPv6 message to the mobile node's home network prefix, so as
> to provide a prefix hint to the DHCP Server for the address pool 
> selection.

You seem to assume DHCP Relay can use the HNP it received in P-BAck to
put it into the DHCP Request, right?  But I think usually the prefix of
a relay is configured statically at MAG in a configuration file, or in
its routing table.  At DHCP Server that prefix is also configured
statically in the DHCP Server's configuration file.

I don't understand how you assume the HNP can come dynamically to MAG
in the profile and then inserted by MAG as a hint in the DHCP Request
and then delivered back by DHCP Server in the address allocation?

I'm afraid it may be a vicious circle (chicken and egg problem)
especially when the MAG-to-MN interfaces are ptp (each its own prefix)
and ephemeral up/down and possibly one prefix is valid on different MAG
at different times.

Or do you propose to _modify_ the DHCP Relay and Server implementations?

I would like to clarify this, thanks.

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 24 Sep 2007 01:03:30 -0700

Hi Alex,

>   I do support having DHCP Relay functionality on MAG.

Ok. Thanks

> there may be a case for DHCP Server on the MAG.

True, that is another possibility. There are two points here:

- There is a DHCP server in the network. Where, we dont know.
  One of the MAG can be a DHCP server. A mobile on any link goes
  to the DHCP server on that specific MAG.

- There is a DHCP server on each MAG and the mobile always goes
  to the local DHCP server on the link.

The draft covers the general case of a DHCP server in the network.
This is the most common case. It maps to the flows in fixed networks,
where a node always goes to the same DHCP server. The second case
is some what a special case and the draft does not deal with it.

> and ephemeral up/down and possibly one prefix is valid on 

Once a link is configured with an IPv6 prefix, any service can be
enabled on the link. The OS/stack that provides the semantics for the
link/prefix creation will also provide the semantics for the
applications to query this information. This info can be in sysctl,
queried using netlink, associated with the net_device interface entry
or could be in runtime files. The applications, will have the ability
to iterate prefixes on a given interface. This is true with Linux 2.6,
Win32, NETBSD or IOS. Its the basic required programming interface.

Now, when a DHCP relay agent is configured on the interface where the
mobile node's home network prefix is hosted, the DHCP relay agent must
set the prefix hint when forwarding the DHCP requests. How, it obtains
that info is upto the implementation. Even 3315, does not specify how
to obtain that prefix information. 

Not sure, if every implementation queries this from static files. It 
depends on how that UI is for that package. I can check how the WIDE's
wide-dhcpv6-relay obtains the same. But, in any case, the requirement
is as per 3315. 

Thanks
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Sep 2007 10:23:29 +0200

Sri Gundavelli wrote:
[...]
>>> where the mobile node is attached, the DHCP relay agent 
>>> [RFC-3315] needs to be configured on that access link.
>> 
>> Why Relay and not Server too?  I mean why silent about Server?  I 
>> think there may be a case for DHCP Server on the MAG.
>> 
> 
> - There is a DHCP server in the network. Where, we dont know. One of 
> the MAG can be a DHCP server. A mobile on any link goes to the DHCP 
> server on that specific MAG.
> 
> - There is a DHCP server on each MAG and the mobile always goes to 
> the local DHCP server on the link.
> 
>  where a node always goes to the same DHCP server. The second case is
>  some what a special case and the draft does not deal with it.

Sri, I agree there are two cases as you describe.  I think in your first
case the assumption is that only one MAG is Server and other each runs
Relay.

I think there is a third case where all MAGs are Servers and they share
their pools with Load Balancing, and there is no Relay.  ISC DHCP can do
this, I think, and there are specs for this.

I also think there is a fourth case where each MAG is a DHCP Client
simultaneously with being a Server and/or a Relay; Client requests a
prefix with Prefix Delegation protocol.

I think none of these 4 cases is more general than the others, and none
should be prevented by the draft.

>>> And then it has a description which I don't understand: When the 
>>> mobile node sends a DHCPv6 Request message, the DHCP relay agent 
>>> function on the access link will set the link-address field in 
>>> the DHCPv6 message to the mobile node's home network prefix, so 
>>> as to provide a prefix hint to the DHCP Server for the address 
>>> pool selection.
>> 
>> You seem to assume DHCP Relay can use the HNP it received in P-BAck
>>  to put it into the DHCP Request, right?  But I think usually the 
>> prefix of a relay is configured statically at MAG in a 
>> configuration file, or in its routing table.  At DHCP Server that 
>> prefix is also configured statically in the DHCP Server's 
>> configuration file.
>> 
>> I don't understand how you assume the HNP can come dynamically to 
>> MAG in the profile and then inserted by MAG as a hint in the DHCP 
>> Request and then delivered back by DHCP Server in the address 
>> allocation?
>> 
>> especially when the MAG-to-MN interfaces are ptp (each its own 
>> prefix) and ephemeral up/down and possibly one prefix is valid on 
>> different MAG at different times.
>> 
> 
>  or could be in runtime files. The applications, will have the 
> ability to iterate prefixes on a given interface. This is true with 
> Linux 2.6, Win32, NETBSD or IOS. Its the basic required programming 
> interface.

Right, this is in general.

>  mobile node's home network prefix is hosted, the DHCP relay agent 
> must set the prefix hint when forwarding the DHCP requests. How, it 
> obtains that info is upto the implementation. Even 3315, does not 
> specify how to obtain that prefix information.
> 
> depends on how that UI is for that package. I can check how the 
> WIDE's wide-dhcpv6-relay obtains the same. But, in any case, the 
> requirement is as per 3315.

Sri, when I'm trying to make this DHCP behaviour work for PMIPv6 I must
modify the DHCP implementation on the MAG and LMA; I can't do it
otherwise than modifying it.  I'm not sure whether we're on the same
wavelength here.

Alex