Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed

[Alexandru Petrescu <[e-mail]>]

Le 17/11/2011 14:56, Tomek Mrugalski a écrit :
> Hi, There was a meeting between proponents of this option, most vocal
> opponets, MIF chairs, DHC chairs and two ADs and several other
> knowledgeable people.
>
> The conclusion of this meeting was that to proceed with route option
>  forward, specific use cases are needed. If you need this option,
> please describe your use case.

I pick one use-case I am particularly concerned with: router device with
limited memory and CPU MHz connected to low-rate cellular forced into
using both DHCP and RA software.  It would better use only one software
implementation (not 2), and do a short exchanges of messages (4 messages
instead of 6) to obtain: default route, prefix, address, DNS server.

In this sense, it would be advantageous if DHCP provided a default route
and optionally with a MAC address.

Other use-cases relate to Mobile Routers in vehicular environments, that
one could describe when necessary.

> If you assume that others will raise support for you, you may be in
> for a surprise.
>
> If this does not get enough documented, valid use cases, it seems
> that this option will not be standardized, at least not in IETF.
>
> Aternative solution discussed was to convey this using
> vendor-specific option (possibly within a body other than IETF);
> change the format to explicitly disallow default route. From my
> perspective (DHCP vendor) those approaches makes this solution much
> more difficult to deploy, often even preventing it completely.

I would support a decision where the default route is stripped off of
the route-option draft and where it is given focused consideration in a
single draft.

The reason for this is that default route has a number of particular
characteristics different than a specific (or generic) route: it is
all-zeros prefix 0, its metric in table is typically 1, its lifetime
treatment depends largely on ND, its reliability needs to be properly
ensured by re-requesting coherently with ND, and more.

> To have this list more organized, please assign a number to your
> support voice.

Sorry, please explain?  What number should I assign to my voice?  Do you
want to assign a preference number between:
- vendor-specific option
- document use-cases?

> It will make it easier to explain if comments are made about already
> mentioned use cases or new cases. If you have any specific concerns,
> there's separate thread for that.
>
> My understanding is that it helps if you are representing a large
> ISP, a vendor or someone else who has non-trivial impact on the
> industry. Voice of people, who express their personal opinions still
> count, but to a lesser degree.

I count my voice to count to a lesser degree.

> Here's the initial list of use cases.
>
> 1. http://www.ietf.org/mail-archive/web/mif/current/msg01412.html On
> 11-11-16 08:59, Maglione Roberta wrote:
>> Hello, during the meeting the chairs and many people asked about
>> use cases and motivations for this work: as I quickly mentioned at
>> the mic there is a draft in v6ops
>
> 2. http://www.ietf.org/mail-archive/web/mif/current/msg01428.html On
> 11-11-17 19:14, [e-mail] wrote:
>> +1
>>
>> I have to add I'm now quite confused why we are even having these
>> motivation discussions, as the charter was already agreed quite
>> some time ago. We are actually even late: -- Jun 2011 - Submit
>> DHCPv6 routing configuration option to IESG for publication as a
>> Proposed Standard RFC --
>>
>> We should focus on technical issues to complete the spec, like the
>>  semantics. Not to spend time repeating old discussions.
>
> 3. Regarding motivation for real users, ISC is a DHCP vendor (client,
> server, relay). Our software is installed as a default client and
> server in many Linux and BSD distributions. Many of our customers and
> users request this feature. I can't explain each deployment model,
> but the commonly mentioned reason was simpler deployment and
> manageability. The latest ISC code supports route-option-03, but I'm
> not sure if it does matter or not.
>
> 4. I'm also author and developer of Dibbler, an open source DHCPv6
> implementation (client, server, relay). This code works on Windows,
> Linux, Mac OS X, and most types of BSDs. There are users, who request
> this. Request for routing configuration (default route in particular)
> is the number one question asked througout the years. There is at
> least one ISP in Poland that wants (i.e. "already uses Dibbler and
> requests routing configuration") to deploy this feature. The latest
> version of Dibbler does support this route-option-03, but again I'm
> not sure if it matters or not.
>
> I admit that depending on your perspective this may be considered as
> a valid vendor (Dibbler has been around for 8 years, existing
> community, deployed in some production environments) or not (open
> source project without any real money behind it).
>
> I looked around and found the following other supporting voices. As I
> don't have operational experience, it would be great if the original
> proponents or commenters could go forward and explain their use
> cases.
>
> - Previous attempt to introduce very similar was proposed by Thomas
> Narten and Ralph Droms. Both were present during meeting and if I
> understand correctly, their reason to drop this work was because
> there was no substantial need for it last time (this was around
> 2009). Here's a link to their presentation:
> http://www.ietf.org/proceedings/74/slides/intarea-4.pdf It should be
>  noted that some open issues (slide 8) are now resolved.
>
> - Wojciech Dec (Cisco) provided several usage models. I can't speak
> on behalf of Cisco, but can only assume that they have reasonable
> need for such feature. I'm sure Wojciech will provide detailed usage
> case soon.
>
> - In previous versions of this draft, there were several more use
> cases described:
> http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-01
> http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-02 They
> were removed based on MIF WG feedback.
>
> - This draft is a result of a merge of 3 other drafts
> (draft-sarikaya-mif-dhcpv6solution,
> draft-sun-mif-address-policy-dhcp6 and
> draft-dec-dhcpv6-route-option). Present and former authors represent
>  the following companies: Cisco, Huawei, China Mobile, Orange France
>  Telecom and NTT PF Labs. Previous attempt to introduce similar
> option (draft-droms-dhc-dhcpv6-default-router-00) was undertaken by
> employees of Cisco and IBM. If you are one of authors, it would be
> great if you could step forward and explain your usage models and
> why you need this. Also, if you decided that this work is no longer
> relevant or was dropped, explaining the reasons would be very
> useful.

I am not an author of these drafts.  I am a co-author of 
draft-mouton-mif-dhcpv6-drlo-00.

> There is a draft "IPv6 Multihoming without Network Address
> Translation" in v6ops
> (draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03). It
> recommends use of this option. Again, if you are an author of this
> draft, could you please explain why you need this.
>
> We should also take into consideration people who were physically
> attending in MIF meeting. Significant majority of people (around 20)
>  offered their support for this draft, while only 6 were against it.
>  Similar support was voiced during adoption of this document in MIF.
> If you are one of those people, please express your support now.
>
> To have a balanced discussion on this topic, I will create one more
> thread regarding flaws and possible dangers of finishing this work,
> with comments from two opponents. Feel free to contribute your
> concerns.
>
> On a presonal note, my involvement in this work is on hold until this
> issue is resolved.

Sorry, which issue?  They seem a list of issues?

Alex

>
> Cheers, Tomek Mrugalski ISC
> _______________________________________________ mif mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/mif
>