Subject: [mif] minutes of last meeting, on the dhcp route discussion

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Jul 2012 18:58:56 +0200

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