Subject: [mif] Comments on draft-sarikaya-mif-6man-ra-route-01.txt

From: Hui Deng <[email-masked]>
Date: Wed, 18 Jul 2012 16:08:07 +0800

Hello authors,

I recall that there was discussion on this draft, but haven't finished, can
you help to clarify further on this?

http://www.ietf.org/mail-archive/web/mif/current/msg01785.html
Best,

-Hui

2012/7/11 Behcet Sarikaya <[email-masked]>

> A new version of I-D, draft-sarikaya-mif-6man-ra-route-01.txt
> has been successfully submitted by Behcet Sarikaya and posted to the
> IETF repository.
>
> Filename:        draft-sarikaya-mif-6man-ra-route
> Revision:        01
> Title:           IPv6 RA Options for Multiple Interface Next Hop Routes
> Creation date:   2012-07-10
> WG ID:           Individual Submission
> Number of pages: 9
> URL:
> http://www.ietf.org/internet-drafts/draft-sarikaya-mif-6man-ra-route-01.txt
> Status:
> http://datatracker.ietf.org/doc/draft-sarikaya-mif-6man-ra-route
> Htmlized:
> http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01
> Diff:
> http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-mif-6man-ra-route-01
>
> Abstract:
>    This draft defines new Router Advertisement options for configuring
>    next hop routes on the mobile or fixed nodes.  Using these options,
>    an operator can easily configure nodes with multiple interfaces (or
>    otherwise multi-homed) to enable them to select the routes to a
>    destination.  Each option is defined together with definitions of
>    host and router behaviors.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 18 Jul 2012 11:47:18 -0500

Hi Hui,

Please see inline.

> http://www.ietf.org/mail-archive/web/mif/current/msg01785.html

We don't think that there is a problem with RFC 4191.
However, latest developments like the advent of multiple interfaced
smart phones and multi-homed hosts bring the need to add a few new RA
options.
That's all.

Regards,

Behcet

---

From: Hui Deng <[email-masked]>
Date: Fri, 20 Jul 2012 15:34:04 +0800

Hi, Behcet,

I would only like to see the presentation about how 4191 can not solve the
issue about multiple interfaces, not about proposal.
we can discuss it during the preparation time.

thanks

-Hui

2012/7/19 Behcet Sarikaya <[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jul 2012 10:13:34 +0100

Wasn't this already answered?

http://www.ietf.org/mail-archive/web/mif/current/msg01784.html

That points out the issues in 4191.

Regards
   Brian

On 20/07/2012 08:34, Hui Deng wrote:
> ------------------------------------------------------------------------
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Jul 2012 11:40:26 +0200

> That points out the issues in 4191.

There may be some point that may have not been discussed.  And that I am 
not sure where it may fit.

This RFC4191 has an implementation where one is free to communicate a 
default route as a particular form of route (radvd.conf 'route ::/0'). 
If this is done, then again there may be an issue with the lifetimes, 
and maybe conflicting with the other way of specifying default routes in RA.

I am not saying to improve this draft in particular, but I wonder in the 
context of which draft could this be discussed.

I requested a slot to present DHCPv6 Default Route and waiting for an 
answer.

Other aspects that may be different - and please don't write drafts 
about it at the speed of light - is that ND may also need to be extended 
to do Prefix Delegation.  If that is done, then the way in which a 
prefix is delegated may need to be accompanied by a default route. 
Which, once again, may be conflictual with the other ways of 
communicating a default route.

Alex

---

From: Zhen Cao <[email-masked]>
Date: Sat, 21 Jul 2012 20:03:14 +0800

> That points out the issues in 4191.

The message only stated that the draft defined improved RIO and two
other options, but did not answer why we need this.

I record and check the Paris meeting minutes when the DHCP route
option draft was discussed. The consensus was the group should
continue to work on this problem, but whether we continue with the
DHCP approach was not resolved.  ND extension may be a potential
approach. But before that I agree with chair that everybody would like
to know why existing approaches do not work.

Regards,
Zhen

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Jul 2012 13:15:20 +0100

Hi Zhen,

> other options, but did not answer why we need this.

Yes it did:

"It is defined exactly for this purpose to clearly indicate the next
hop address associated with the right RPO, to avoid any inconsistency
arising from sending the two in two different options."

My pesronal opinion, fwiw, is that given the strength of opinion
for both RA and DHCPv6 deployment scenarios, we have to define both
solutions, with identical semantics if possible. Probably a single RFC
that specifies both would be the safest way to get the same semantics.

     Brian

---

From: Zhen Cao <[email-masked]>
Date: Mon, 23 Jul 2012 10:49:16 +0800

>> other options, but did not answer why we need this.

I do not think so.

> arising from sending the two in two different options."

I asked why there were three options defined and how to relate them.
The above statement said that defining the "Next Hop Address with
Route Prefix option" can avoid inconsistency arising from sending them
in different options, NOT answering why RIO defined in 4191 cannot
solve the problem in the target scenario.

Regards,
Zhen

-- 
Best regards,
Zhen

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Jul 2012 08:15:38 +0100

Zhen,

> solve the problem in the target scenario.

If you want to argue that the original RIO model cannot cause inconsistency,
that's fine and Behcet can answer you. I was simply pointing out that he
did give a reason. Actually that analysis should be in the draft.

I also want to say that for a normal host, there is no difference between
"next hop" and "default route(r)", for a given prefix. The draft and RFC 4191
are a bit hard to read together since the RFC mainly refers to default
route(r) and the draft mainly refers to next hop. If they used the
same terminology, the discussion would be simpler.

Regards
   Brian

---

From: Zhen Cao <[email-masked]>
Date: Mon, 23 Jul 2012 16:33:12 +0800

> did give a reason. Actually that analysis should be in the draft.

It is important and interesting topic.  But I did not find the
analysis in the draft.  So Hui suggested that the presentation would
talked about that.  I do want to listen to that.

> same terminology, the discussion would be simpler.

We had better also include "specific route"

Regards,
Zhen

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Jul 2012 10:43:12 +0200

Le 23/07/2012 10:33, Zhen Cao a écrit :
>>>> "It is defined exactly for this purpose to clearly indicate the
>>>> next hop address associated with the right RPO, to avoid any
>>>> inconsistency arising from sending the two in two different
>>>> options."
>>>
>>> I asked why there were three options defined and how to relate
>>> them. The above statement said that defining the "Next Hop
>>> Address with Route Prefix option" can avoid inconsistency arising
>>> from sending them in different options, NOT answering why RIO
>>> defined in 4191 cannot solve the problem in the target scenario.
>>
>> If you want to argue that the original RIO model cannot cause
>> inconsistency, that's fine and Behcet can answer you. I was simply
>> pointing out that he did give a reason. Actually that analysis
>> should be in the draft.
>
>> I also want to say that for a normal host, there is no difference
>> between "next hop" and "default route(r)", for a given prefix. The
>> draft and RFC 4191 are a bit hard to read together since the RFC
>> mainly refers to default route(r) and the draft mainly refers to
>> next hop. If they used the same terminology, the discussion would
>> be simpler.
>

IMHO, it would be better to separate the documents: specific routes in
one document and default routes another document.

Reading your email exchanges, and the RFC4191, I see you mean different
things by this word 'default'.

Some meaning is: a 'default' router for a particular prefix.  As to give
preference to one router when there are two for the same destination prefix.

Another meaning: _the_ default router for ::/0.

Alex

>
> Regards, Zhen _______________________________________________ mif
> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/mif
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Jul 2012 17:07:59 +0200

Brian,

In the email below you touch lightly on the discussion about routes with 
DHCP (default or otherwise).

I wonder whether we have a conclusion on that discussion?

My understanding is that at the last F2F meeting in Paris there was 
strong opposition in doing routes with DHCP.  And that on the mailing 
list there is activity that supports both.

A suggestion I received privately is to rather develop Neighbor 
Discovery Prefix Delegation, instead of DHCP default route (if I want to 
save on the number of messages).

I wonder whether draft-ietf-mif-dhcpv6-route-option-04 is going to be 
updated and how?

In the mif agenda of the Vancouver meeting I do not see any presentation 
about this topic.

What

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jul 2012 16:48:49 +0100

Alexandru,

> I wonder whether we have a conclusion on that discussion?

I haven't seen a clear conclusion, and of course it is not a topic
for MIF alone. It really is a cross-WG and cross-Area question.

> list there is activity that supports both.

Indeed. There are certainly people whose preferred deployment scenarios
favour one or the other. That hasn't changed in the last 5 years.

> save on the number of messages).

I think the objective evidence is that the market wants both. Although, as
the editor of RFC 1958, I support its principle "If there are several ways of
doing the same thing, choose one", there are times when this is unrealistic.

> In the mif agenda of the Vancouver meeting I do not see any presentation

What, indeed!

   Brian

>>>>>>> I recall that there was discussion on this draft, but haven't
>>>>>>> finished,
>>>>>> can

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Jul 2012 11:14:04 -0500

Hi Alex,

On Wed, Jul 25, 2012 at 10:07 AM, Alexandru Petrescu
<[email-masked]> wrote:
> My understanding is that at the last F2F meeting in Paris there was strong
> opposition in doing routes with DHCP.  And that on the mailing list there is
> activity that supports both.
>
> A suggestion I received privately is to rather develop Neighbor Discovery
> Prefix Delegation, instead of DHCP default route (if I want to save on the
> number of messages).
>

draft-sarikaya-mif-6man-ra-route
is written out of the discussions in Paris.

Regards,

Behcet

---

From: Zhen Cao <[email-masked]>
Date: Thu, 26 Jul 2012 21:44:43 +0800

> I wonder whether we have a conclusion on that discussion?

In Paris and as the minutes recorded, there is not clear consensus on
this. More people were against of this way, but we have not seen the
AD's formal decision.

> I wonder whether draft-ietf-mif-dhcpv6-route-option-04 is going to be

I guess authors wait for the decision also.

Regards,
C.Z

---

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

> is written out of the discussions in Paris.

YEs Behcet, but was there some indication from an authoritative voice 
that this should be written?  Or is this just one facet of the multiple 
interpretation of that rather heated discussion?

I may have missed some indication, sorry.

And I ask so because I did not understand from the discussion that 
rfc4191-style routes should be improved.  The discussion was mainly 
about DHCP and routes.

Yours,

Alex

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 26 Jul 2012 23:35:44 +0200

> I wonder whether draft-ietf-mif-dhcpv6-route-option-04 is going to be
Alex,
I'm not aware of such plans. After Paris meeting I got the impression
that MIF decided to not continue work on this particular draft, but
chose to continue working on the problem, while not excluding DHCP as
potential delivery mechanism. I must admit that such decision seems
somewhat inconsistent IMHO. If the DHCP is a viable way to solve the
problem, then why this work is abandoned? Or put it the other way
around: if this approach is broken beyond repair, why bother to try
another attempt with DHCP? My perception is that major objections raised
were generic to the whole DHCP protocol, not those specific options
("you can't invalidate the data after server crash", "you don't have any
means of immediately notifying client that don't support reconfigure").

Obviously, the problem touches areas of many WGs, not just MIF.
Therefore I hoped to receive some form of guidance from ADs after Paris,
but sadly that hasn't materialized. At least according to my knowledge.
Please do let me know if I have missed it.

One of the major objections raised by opponents of the DHCP solution was
default route configuration. At one point in time, it was considered if
dropping the ability to configure default route would be a viable
compromise. Sadly, such change would render the solution almost useless
for MIF environment, so probably another adoption would be required. And
there was no clear indication whether RA advocates would accept it in
that form anyway, so the idea was promptly dropped.

Brian's comment about defining both RA and DHCPv6 solutions with
identical semantics seems valid. It would solve two major objections.
First, it would provide a way to invalidate routes in case of router or
DHCP server crash. Second, it would allow to immediately notify the node
of any configuration changes (even those that don't support DHCPv6
reconfigure mechanism). However, I doubt it would change minds of some
RA advocates ("RA and nothing else" approach).

Therefore the answer to your question is quite simple:
It's dead, Jim.

> In the mif agenda of the Vancouver meeting I do not see any
> presentation about this topic.
There won't be any.

Cheers,
Tomek