Subject: Re: [mif] I-D Action: draft-sarikaya-mif-6man-ra-route-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 May 2012 10:17:47 +0100

Main comment:

I would like to see some discussion (not standardisation) of the
fact that the proposed new option (not to mention RIO) will need
a central site-wide configuration mechanism. Otherwise the document
will give the false impression that it solves the whole problem.
As we know from the discussion of the DHCP solution, it doesn't.

Minor comments:

> 1.  Introduction
> 
>    IPv6 Neighbor Discovery and IPv6 Stateless Address Autoconfiguration
>    protocols can be used to configure fixed and mobile nodes with
>    various parameters [RFC4861], [RFC4862].

I think RFC 4191 should also be listed here. In fact I would extend the
sentence slightly:

   IPv6 Neighbor Discovery and IPv6 Stateless Address Autoconfiguration
   protocols can be used to configure fixed and mobile nodes with
   various parameters related to addressing and routing [RFC4861],
   [RFC4862], [RFC4191].

And the next sentence:

>    ...DNS Recursive Server
>    Addresses and Domain Name Search Lists are example parameters that
>    can be configured using router advertisements [RFC6106].

Please s/example/additional/. As far as I know, RFC 6106 is the only
extension to RA that is not related to addressing and routing, and
many people objected even to that small extension.

> 5.  Next Hop Address option
...
>    Length: The length of the option (including the type and length
>    fields) in units of 8 octets.  For example, the length for an IPv6
>    address is 3.

Why "for example"?? This is an IPv6 spec. The length is 3, period.

Regards
   Brian Carpenter

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 16 May 2012 11:33:01 -0500

Hi Brian,

Thank you for your comments.
My replies are inline.

Behcet

> As we know from the discussion of the DHCP solution, it doesn't.

Sure. I will. Do you mind offering some text?

>   various parameters related to addressing and routing [RFC4861],

OK

> many people objected even to that small extension.

I agree with this observation. For some time, it has not been possible
to have any extensions on RA options.

> Why "for example"?? This is an IPv6 spec. The length is 3, period.

OK

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

---

From: Zhen Cao <[email-masked]>
Date: Fri, 18 May 2012 15:56:08 +0800

Hi Behcet,

Thanks for the document and I am some questions.

What's the major functionality differences from RFC4191?  I believe
both of 4191 and your draft is about configuring specific routes to
host/router.

Then technically, you defined three new options,
prefix/nexthop/nexthop-w-prefix, first why we need three new instead
of RIO in 4191, and how to relate the prefix option with nexthop
option if they are used combined.

Thanks and regards,
Zhen

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 21 May 2012 17:51:39 -0500

Hi Zhen,

See my replies inline.

Regards,

Behcet
> both of 4191 and your draft is about configuring specific routes to

Basically to define an improved RIO and two other options, for more, see below.
As Brian mentioned, these infos need to be configured on the routers
and advertised to the hosts and can not be obtained from the routing
tables.

> of RIO in 4191,

The first option is slightly modifying RIO of 4191 with the route
metric field and call it the route prefix option (RPO) to stress on
the main info, i.e. the prefix,

so it is defining an improved RIO.

These RPOs are further improved with the second option of Next Hop Address.

The third one simply combines the above two in one.

>  and how to relate the prefix option with nexthop

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.

Hope this clarifies.

---

From: Zhen Cao <[email-masked]>
Date: Wed, 23 May 2012 15:44:54 +0800

> and advertised to the hosts and can not be obtained from the routing

That's not functional difference.  I still understand it as technical
improvement to the RIO.

Then I have to ask what the problem with 4191?

Thank you for discussion.

-- 
Best regards,
Zhen