Colleagues,
For information, I thought it would be good to have these minutes at hand.
Paris, March 2012, IETF, MIF WG:
[...]
draft-ietf-mif-dhcpv6-route-option-04 (Chairs&Woj/Tomek, 20 min)
Laurent Thiebaut: What is the authority or source of the
information that's being considered
Margaret Wasserman: The document reads like it is a replacement for
RAs. I don't see it as a replacement for RAs. It's more of an
automated alternative to typing configuration options by hand.
All DHCP configuration data has an implicit lifetime
-- the expiration time of the lease, or upon moving to a new network
Margaret Wasserman: DHCP is the great sysadmin in the sky, typing
commands on your computer
Jouni Korhonen: 3GPP / cellular scenario: what is here that is not
covered by PMIP prefix delegation work that is about to go forward
now?
Hui: PD in PMIP to give address to MAG? Not a route option.
Jouni: what is the problem?
Hui: that one is about assigning a prefix, this is about a
route option.
Lorenzo: why can't we do it with an extra PMIP option?
Hui: PMIP can configure the prefix, but not the route. First, have
to invent a new option, modify the whole network infrastructure.
Too expensive. Second, MAG has to connect to multiple different
operators, option might come from home or visited, that kind of
configuration is impossible.
Lorenzo: it's an option in both cases. Those two operators already
coordinate to hand out the user's prefix
Hui: but they are not coordinated for the routing
Lorenzo: why can't they be?
Woj: pain level is significantly higher. Requires operator
infrastructure, not just endpoints
Lorenzo: it's less that 1B handsets. Second point: some use
cases are real, some are not real. Some are self-referential,
put in at the last minute. Why can't do this with 4191? This
option allows you to provide a complete replacement for ND and RAs.
It needs to go through 6man and be reviewed and approved by 6man.
Has more to do with 6man than with MIF. of the 14 use cases, 11 use
cases refer to hosts with only one interface.
Woj: comments seem to be RA vs. DHCP. There are valid use cases for
routing, RAs require stuff happening on the edge router. If you
want to do this on a per-host basis, it's a pain.
Lorenzo: if this were restricted to CPEs, walled garden deployments,
would have no problem. What happens when there are two ways to do
something, they typically get whittled down to one.
Ted Lemon: why will it come down to DHCP vs. RAs?
Lorenzo: Why is IPv6 not deployed? It is expensive to have multiple
ways of doing things. Over time, we will see two going down to one.
If it's this way, it's less robust.
Eric Klein: T0 when this is published, implementations begin.
T1, an enterprise discovers that it can implement DHCP routes on its
wireless LANs, decides it doesn't need to support RAs. Fact that
you can't bring your device from home & use it is a security f
eature (good thing).
T2, everyone finishes their implementation.
T3: at some point there's a bug in one, support for RAs whithers.
T4: have 9-to-1 ratio of DHCP route option vs. RAs.
No merged network will want to run both.
Ted: we have no way of knowing
Margaret: why don't people do static configuration?
Lorenzo: RA is about 5-10% better, value of having everything use the
same thing is more than that. IPv6 is not getting deployed because
it is epsilon better than IPv4.
Woj: this comes down to RA vs. DHCP. Could be applied to all other
options. Maybe this is better if it fixes pain points. We are
not restricting RAs.
IljitschvB: use case #11, can you explain it to me?
Suggestion made on NANOG list, was not considered a use case. Lose
the fate-sharing that you get with RAs. Other issue: just months
ago, reached a situation where all modern OSs support DHCP.
We will lose that consistency.
Margaret: not all implementations support all options.
Iljitsch: What we could do, instead of saying "this is your router" is
that it is less severe, say "of the list of routers, this is what
you should pick". Agree with Lorenzo, this is similar to the MO
discussions in 6man, people in 6man are the ones who know how to
solve this. Needs to go there.
Bob Hinden: agree with most of what's been said. Have concerns at
different levels. Thought this WG would make it easier for me to
have cable + DSL at home, have multiple interfaces. I don't want
the operators to know that I'm doing this. This requires the
operator or someone to configure a DHCP server with knowledge of
both sides. Administrative model doesn't make any sense. This
draft is not solving what this WG is meant to be solving. Many
of the use cases are weak/have circular logic.
Margaret: use cases section was constructed from lots of input from
different places, wasn't in there during WGLC. This group has 2
major constituencies. Sometimes your laptop at home, sometimes
a cellphone that wants WiFi and 3G at the same time. Operational
models seem to be quite different. 3GPP people are telling us they
want it for reasons that don't apply to the home network case.
Bob Hinden: seems to be building an alternative to RAs as opposed
to solving MIF problems. Many of these problems could be easily
solved with minimal extensions to RAs
(unicast, adding minimal data options)
Woj: how does this address the pain points/use cases?
BH: use cases are vague, don't make a lot of sense, don't seem
logically consistent. We don't have to provide solutions to
everything, some things need to adapt to what we have.
Woj: RAs are broadcast/multicast on a shared medium.
BH: designed to send the same info to everyone, DHCP for other
things. This draft changes that. Like, "who's the router?"
In RAs, the router announces itself and fate-shares. This draft
changes that. Why not extend RAs to do DHCP things? This will be
disruptive to the IPv6 deployment?
Margaret: don't we keep adding options to DHCP because some people
want one model, another people want another model?
BH: IPv6 is not being deployed because it is not perceived as stable.
Woj: it is the RA vs. DHCP
EricKlein: not opposed to DHCP, fine for things above these layers.
RA is for bootstrapping, operation at the link layer. What we
really needed, was a provisioning protocol for routers. Still
problems with document quality. Timers: if NUD fails to router,
needs to re-issue a DHCPv6 request. Wrt this vs. DRLO: (MW: was
taken off the agenda) this is at least better because it doesn't
kill ND. What was rationale for not just including the binary blob
from the RA?
Margaret: point wasn't to send an RA. Point was to send a static
route. What does a lifetime mean in a DHCP configured value?
Why telling you on-link vs. off-link?
EricKlein: need to tell it that
MW: Don't do that in ifconfig?
RalphDroms: we're not proposing here (as has been proposed in the
past) putting the binary blob because of all the potential
incompatibilities between the binary blob and what the DHCP client
is prepared to deal with. It's too hard, takes too many
compromises if we just try to carry a binary blob.
MW: we have this for v4 today, but people use it in obscure situations.
EricKlein: not a good argument for carrying forward in v6.
RD: "just because it's in v4" is not an argument to carry over into
v6. We left that behind. We also decided not to carry all the
options from v4.
Suresh Krishnan: question about basic multi-homed scenario. Where
are the two provisioning domains?
MW: share your concern
SK: DHCP server knowing the link-local address of a router that is
remote is a challenge. How does it keep up to date with failures
& such that RAs handle naturally?
MW: if I can configure a static route today?
Lorenzo: is that a good idea to configure a static route?
MW: it doesn't stop NUD from working
SK: don't agree with that. If you have a v4 router, MAC fails, you
have the same address, fine. In v6, the address is autoconfigured
from MAC address. Things changed, doesn't work anymore.
MW: that is not the way people are deploying v6 right now.
In 3GPP they don't configure the host right now.
Lorenzo: all the deployments don't use this option because it doesn't
exist.
MW: in 3GPP you don't use RAs to discover the default router
SK: yes you do. Also, concerned about how to throw out this
information. Getting something from DHCP, need to put something
in the lifetime. Static route is infinite.
MW: no, DHCP is scoped to while you're on the link.
SK: static routes don't go away, and they can be wrong. Only two
kinds of routes: come from RA, one by hand. Now you are adding
a third thing. Need to put a lifetime or leave it infinite.
If you put a lifetime, what happens if you disconnect?
MW: same as an address. If you configure an address with DHCP,
when you leave that link, DHCP information goes away. Don't
understand what it would mean to apply a different lifetime.
DaveThaler: Two separate sets of comments: 1 about hosts, 1 about
routers. Both these pictures are cases where the DHCP client
is a router. First, start with host. RFC5505: RADAV, principles
of Internet Host Configuration. Says: "minimize the number of host
configuration protocols". Yes, there is both in IPv4, everybody
picked one (DHCP). We don't want to replace RAs. For the host
category of things, don't want to see DHCP. Want to use RAs.
Point 2: routers. What you want is a router configuration protocol.
Could be anything, SNMP, netconf, discussion about a router config
protocol back when DHCP-PD was being discussed. Called it the
Droms-Haberman configuration protocol. Was a router configuration
protocol. For PD, that's fine. As long as you constrain it to be
a router configuration protocol that's fine. If you are going to do
this, say this is applicable to routers only, not hosts, prevents
duplication, won't see it show up in host profiles.
LaurentTebow: Q about hosts vs. routers. Coming back to MIF, is the
information associated with an interface or a node? It is very
important to understand. If it is node scope, need to understand
how router receives 2 conflicting routes, how it resolves the
conflict?
MW: have now been talking about multiple provisioning domains, not
multiple interfaces. So you should say host-wide or provisioning
domain-wide.
LT: if it is one operator with 2 interfaces, no conflict. If there
are 2 provisioning domains, how do we solve it? Scoped routes?
ChrisLewinsky: basic scenario diagram is a nightmare. If these are
two different domains, will get conflicting /0 routes, have no way
of disambiguating them. If using as a way of sucking off walled
garden IPTV to one router, maybe can get away with two separate
DHCP servers. If router goes down, all of IPTV customers go down,
DHCP won't get the new information. If you tell me a more specific
route, directly connected to Router A, can use RAs. If it is
beyond Router A, we should use route protocols with fate sharing.
Should be able to send a list "if you can see this router, please
use it" rather than sending hard routes in DHCP. But generally,
this is a bad idea.
MW: now try to ask some sort of question. Doc has gone through WGLC.
Do we want to send forward or do we want to stop? How many people
think we should continue with this work?
BH: clarifying question: it's more than just fixing a few words, maybe
needs to take a step back and reconsider.
MW: lots of people say we shouldn't do anything like this period.
If we want to stop we should stop.
Jari: it's a good idea to ask the WG how they feel, but it's not just
that you have two options. Third option, go back to thinking about
the problem statement. Maybe there should be a new protocol that
can deal with router configuration, some other work that we could
start.
MW: ok,three questions. Proceed on this draft (with possible changes),
Stop altogether, or start over with a different approach
(maybe in a different WG).
RobertaMaglione: there is a document in the RFC Q with a normative
dependency on this draft.
MW: how many people think we should continue to work on this problem?
Not?
Margaret declares consensus to continue
If we continue, should we start with this draft?
Continue with a DHCPv6 optoin?
Work on a different approach?
ADs can take this under advisement, tell us what to do.
-----
Yours,
Alex
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif
