Subject: Re: [netlmm] DHCP Scenarios in draft-ietf-netlmm-pmip6-ipv4-support

From: Julien Laganier <[email-masked]>
Date: Thu, 27 Nov 2008 08:41:58 +0100

Folks,

I'm following up on this since I forgot to make one important point 
during our last meeting.

I do not understand why we need to treat differently IPv4 and IPv6 
w.r.t. to DHCP mode. RFC 5213 does only specify a mode where the MAG is 
a DHCPv6 relay. 

Why should we make it different for the IPv4 support and DHCPv4?

Specifying the MAG as a DHCPv4 relay only would treat IPv4 and IPv6 in a 
way that is architecturally and functionally consistent.

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

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 27 Nov 2008 11:30:55 +0200

Julien, folks,

If we are talking about only allowing "DHCP relay" and prohibiting "DHCP
proxy" model, then having that approach in both RFC 5213 and pmip6-ipv4 I-D
makes two wrongs, not one right.

In the context of specifying a "protocol", talking about "architecture" of
how this and many other protocols interwork together is fine, as long as we
do not try to be exhaustive (not possible!) and arbitrarily eliminate
different cases. For example, I should be able to use RFC 5213 in an
architecture where host configuration is performed through written messages
carried by pigeons.

Getting into strong normative language while defining just the crust of an
"architecture" does not serve the purpose people were seeking, and becomes
harmful (unnecessarily limiting).

For example, people are under the impression that they can achieve full
interop with DHCP relay because it is so well defined. Not so:

RFC 5213

   o  For supporting Stateful Address Configuration using DHCP, the DHCP
      relay agent [RFC3315] service MUST be supported on all the mobile
      access gateways in the Proxy Mobile IPv6 domain.  Further, as
      specified in Section 20 of [RFC3315], the DHCP relay agent should
      be configured to use a list of destination addresses, which MAY
      include unicast addresses, the All_DHCP_Servers multicast address,
      or other addresses as required in a given deployment.

In a large roaming domain where there are multiple operator networks, how do
you expect the MAG to maintain list of DHCP servers from each operator? 

	DHCP-based address configuration is
      not recommended for deployments in which the local mobility anchor
      and the mobile access gateway are located in different
      administrative domains.

In roaming case they are always in different administrative domains. 

I'm not seeking for people to make a complete architecture document in our
specs. This is a difficult task. My point is, let's not get too
authoritative when it comes to defining architectures around our protocols
and make arbitrary limitations.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Julien Laganier
> Sent: Thursday, November 27, 2008 9:42 AM
> To: [email-masked]
> Subject: Re: [netlmm] DHCP Scenarios in draft-ietf-netlmm-pmip6-ipv4-
> support
> 
> Folks,
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 27 Nov 2008 10:52:36 +0100

Alper,

Just to clarify - 

I am not looking at prohibiting one model.

I'm looking at the IETF spec outlining only one model instead of two or 
more so that someone taking that IETF RFC and trying to build a system 
out of it has reasonable chances of getting something that both works 
and interoperate w/o relying on configuration. 

Then if there's a desire from someone to specify a different model in a 
specific architecture, I've got nothing against it and surely I don't 
want to prohibit it. But surely I don't want that specific draft to 
document all of the possible models that someone might want. From what 
you wrote we seem to be in agreement, you don't want to prohibit models 
neither to document them exhaustively either.

As to the pigeon-based transport for host configuration within a PMIPv6 
domain that you're outlining in your note, this looks quite promising. 
How about writing a draft describing the idea in more depth ? :-D

--julien

On Thursday 27 November 2008, Alper Yegin wrote:
> Julien, folks,
>
> If we are talking about only allowing "DHCP relay" and prohibiting
> "DHCP proxy" model, then having that approach in both RFC 5213 and
> pmip6-ipv4 I-D makes two wrongs, not one right.
>
> In the context of specifying a "protocol", talking about
> "architecture" of how this and many other protocols interwork
> together is fine, as long as we do not try to be exhaustive (not
> possible!) and arbitrarily eliminate different cases. For example, I
> should be able to use RFC 5213 in an architecture where host
> configuration is performed through written messages carried by
> pigeons.
>
> Getting into strong normative language while defining just the crust
> of an "architecture" does not serve the purpose people were seeking,
> and becomes harmful (unnecessarily limiting).
>
> For example, people are under the impression that they can achieve
> full interop with DHCP relay because it is so well defined. Not so:
>
> RFC 5213
>
>    o  For supporting Stateful Address Configuration using DHCP, the
> DHCP relay agent [RFC3315] service MUST be supported on all the
> mobile access gateways in the Proxy Mobile IPv6 domain.  Further, as
> specified in Section 20 of [RFC3315], the DHCP relay agent should be
> configured to use a list of destination addresses, which MAY include
> unicast addresses, the All_DHCP_Servers multicast address, or other
> addresses as required in a given deployment.
>
> In a large roaming domain where there are multiple operator networks,
> how do you expect the MAG to maintain list of DHCP servers from each
> operator?
>
>       not recommended for deployments in which the local mobility
> anchor and the mobile access gateway are located in different
> administrative domains.
>
> I'm not seeking for people to make a complete architecture document
> in our specs. This is a difficult task. My point is, let's not get
> too authoritative when it comes to defining architectures around our
> protocols and make arbitrary limitations.
>
> Alper
>
> > Subject: Re: [netlmm] DHCP Scenarios in
> > draft-ietf-netlmm-pmip6-ipv4- support
> >
> > Folks,
> >
> > w.r.t. to DHCP mode. RFC 5213 does only specify a mode where the
> > MAG is a DHCPv6 relay.
> >

-- 
--julien

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

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 27 Nov 2008 16:12:43 +0200

Julien,

DHCP proxy is already an adopted approach by the industry. We are not
talking about documenting "all possible" cases. We are talking about
documenting two equally possible/used models. Given that and also the fact
that it is already part of the I-D, I don't see what justifies its removal. 

Regarding "w/o relying on configuration", as I pointed out in my earlier
email, DHCP relay needs a configuration as well. 

> How about writing a draft describing the idea in more depth ? :-D

RFC 1149. Happy reading :)

Alper

> From: Julien Laganier [mailto:[email-masked]]
> Sent: Thursday, November 27, 2008 11:53 AM
> To: Alper Yegin
> Cc: [email-masked]

---

From: Julien Laganier <[email-masked]>
Date: Thu, 27 Nov 2008 15:35:20 +0100

Alper,

If we're going with two DHCP mode (proxy and relay) in the IETF draft 
then, as I proposed in the meeting, we should define a "DHCP Mode" 
option sent from the LMA to the MAG to instruct the MAG about which 
DHCP mode it should operate w.r.t. a MN attached via this LMA. 
Otherwise we'll run into interop problems.

As to RFC 1149, it seems I have misunderstood your proposal and I 
apologize for this. I thought you were proposing to carry host 
configuration over raw pigeons. RFC 1149 is obviously sufficient if 
host configuration is carried via DHCP over UDP over IP :-D

--julien

On Thursday 27 November 2008, Alper Yegin wrote:
> documenting two equally possible/used models. Given that and also the
> fact that it is already part of the I-D, I don't see what justifies
> its removal.
>
> Regarding "w/o relying on configuration", as I pointed out in my
> earlier email, DHCP relay needs a configuration as well.
>
> > As to the pigeon-based transport for host configuration within a
> > PMIPv6 domain that you're outlining in your note, this looks quite
> > promising. How about writing a draft describing the idea in more
> > depth ? :-D
>
> > I'm looking at the IETF spec outlining only one model instead of
> > two or more so that someone taking that IETF RFC and trying to
> > build a system out of it has reasonable chances of getting
> > something that both works and interoperate w/o relying on
> > configuration.
> >
> > Then if there's a desire from someone to specify a different model
> > in a specific architecture, I've got nothing against it and surely
> > I don't want to prohibit it. But surely I don't want that specific
> > draft to document all of the possible models that someone might
> > want. From what you wrote we seem to be in agreement, you don't
> > want to prohibit models neither to document them exhaustively
> > either.
> >
> > As to the pigeon-based transport for host configuration within a
> > PMIPv6 domain that you're outlining in your note, this looks quite
> > promising. How about writing a draft describing the idea in more
> > depth ? :-D
> >
> > --julien
> >
> > > If we are talking about only allowing "DHCP relay" and
> > > prohibiting "DHCP proxy" model, then having that approach in both
> > > RFC 5213 and pmip6-ipv4 I-D makes two wrongs, not one right.
> > >
> > > possible!) and arbitrarily eliminate different cases. For
> > > example, I should be able to use RFC 5213 in an architecture
> > > where host configuration is performed through written messages
> > > carried by pigeons.
> > >
> > > Getting into strong normative language while defining just the
> > > crust of an "architecture" does not serve the purpose people were
> > > seeking, and becomes harmful (unnecessarily limiting).
> > >
> > > For example, people are under the impression that they can
> > > achieve full interop with DHCP relay because it is so well
> > > defined. Not so:
> > >
> > > RFC 5213
> > >
> > >    o  For supporting Stateful Address Configuration using DHCP,
> > > the DHCP relay agent [RFC3315] service MUST be supported on all
> > > the mobile access gateways in the Proxy Mobile IPv6 domain. 
> > > Further, as specified in Section 20 of [RFC3315], the DHCP relay
> > > agent should be configured to use a list of destination
> > > addresses, which MAY include unicast addresses, the
> > > All_DHCP_Servers multicast address, or other addresses as
> > > required in a given deployment.
> > >
> > > In a large roaming domain where there are multiple operator
> > > networks, how do you expect the MAG to maintain list of DHCP
> > > servers from each operator?
> > >
> > > I'm not seeking for people to make a complete architecture
> > > document in our specs. This is a difficult task. My point is,
> > > let's not get too authoritative when it comes to defining
> > > architectures around our protocols and make arbitrary
> > > limitations.
> > >
> > > Alper
> > >
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > On Behalf Of Julien Laganier
> > > > I'm following up on this since I forgot to make one important
> > > > point during our last meeting.
> > > >
> > > > I do not understand why we need to treat differently IPv4 and
> > > > IPv6 w.r.t. to DHCP mode. RFC 5213 does only specify a mode
> > > > where the MAG is a DHCPv6 relay.
> > > >

-- 
--julien

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 27 Nov 2008 17:05:24 +0200

Julien,

> Otherwise we'll run into interop problems.

I understand the objective of interop. 
But I don't think it is a good idea to utilize PMIPv6 signaling for this
non-PMIP issue. 
DHCP proxy vs relay model was there before PMIPv6 came along. It is already
used for PMIPv4. It can also be used for non-MIP systems. IMO a better
solution is to handle this "system parameter negotiation" is out-of band
with PMIPv6 (e.g., using AAA). If there are reasons it cannot be done for
some systems and piggybacking on PMIPv6 is the only venue, I'd not have
strong objections. Though this may take PMIPv6 down some unintended path.

Alper