Subject: [mif] Summary issues after meeting, draft-ietf-mif-dhcpv6-route-option-04

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Mar 2012 14:36:50 +0200

We discussed on the email list and at the meeting about issues related
to draft-ietf-mif-dhcpv6-route-option-04.

The following issues were presented during the meeting:

> MAC address not configured
>
> Answer: it doesn’t need to be. MAC derived via ND.

This is not what was said on the email list, and even less at the mic.
On the mailing list, the range of comments were from "no MAC" to "maybe
MAC".  To me the latter seemed more agreed.

> Lifetime is 32, not 16 bits
>
> Answer: Does not appear to be a problem, timing calculation is OS
> dependent, but it is done on 32 or 64 bit counters.

In the recent emails on the mailing list there seemed to be convergence.
  But not the way you mention it.

At the mic there seemed to exist as many supportive comments of doing
lifetime (be it 16 or 32) as of doing no lifetime at all.

In addition, the following issues were listed by email, with discussion.

1. Separate specific routes from default routes.
    Authors disagree with me, and Ted agrees with authors.

2. Message size better be smaller.
    Author indicates the length is 30bytes by now.
    But I'd suggest it could be 20bytes if the encoding were not split
    as nexthop-prefixoption (as is now).

3. Only one default route?
    Discussion seems to indicate that maybe the presence of several
    default routes would be in scope here.  And if coupled with a novel
    source address selection scheme may constitute new work maybe 6man.

Alex
PS: Chairs, if you believe I should stop tracking these issues then
     please let me know.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Mar 2012 12:58:36 +0000

Alexandru, I think the major misunderstanding here has to do with your use case.   The route option as it was floated was not originally intended to address your use case, and when it was changed to address your use case, it got a lot less popular.   Thiss was not because there's anything wrong with your use case, but because it came to be perceived as more applicable to use cases where, from an architectural perspective, the IETF would prefer to use RA.   That is, it came to be perceived as a generic replacement for RA, which wasn't what the working group set out to do.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Mar 2012 15:11:56 +0200

Le 30/03/2012 14:58, Ted Lemon a écrit :
> Alexandru, I think the major misunderstanding here has to do with
> your use case.   The route option as it was floated was not
> originally intended to address your use case, and when it was changed
> to address your use case, it got a lot less popular.   Thiss was not
> because there's anything wrong with your use case, but because it
> came to be perceived as more applicable to use cases where, from an
> architectural perspective, the IETF would prefer to use RA.   That
> is, it came to be perceived as a generic replacement for RA, which
> wasn't what the working group set out to do.

It doesnt sound pleasant to me to hear so.

But let's talk in terms of next steps.

I remember having insisted on default routes at a time when 
draft-dec-dhcpv6-route-option-05 was out, or even earlier.

Do you think it is that which may have induced later disapproval?

Would this imply to suggest next steps of route-option without default 
routes?  I would not oppose such way forward.

What would be the possible ways forward?

Alex

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Mar 2012 13:18:21 +0000

> routes?  I would not oppose such way forward.

I think this would be a lot more palatable to the IETF as a whole.    As to the history, remember that it was after WGLC that the IETF as a whole saw this draft, and objections were raised.   Nobody in MIF particularly objected to the default route support, because we understood the use cases for the option, but when it went to the IETF at large, a lot of people read the draft for the first time who didn't understand what motivated it, and so to them it looked like an RA replacement for general use in all networks.   And the draft certainly did nothing to disabuse them of that notion.