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

[Behcet Sarikaya <[e-mail]>]

Hi Zhen,

See my replies inline.

Regards,

Behcet
On Fri, May 18, 2012 at 2:56 AM, Zhen Cao <[e-mail]> wrote:
> 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.

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.

>
> Then technically, you defined three new options,
> prefix/nexthop/nexthop-w-prefix, first why we need three new instead
> 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
> option if they are used combined.
>

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.

> Thanks and regards,
> Zhen
>
> On Thu, May 17, 2012 at 12:33 AM, Behcet Sarikaya
> <[e-mail]> wrote:
>> Hi Brian,
>>
>> Thank you for your comments.
>> My replies are inline.
>>
>> Behcet
>>
>> On Tue, May 8, 2012 at 4:17 AM, Brian E Carpenter
>> <[e-mail]> wrote:
>>> 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.
>>>
>>
>> Sure. I will. Do you mind offering some text?
>>
>>> 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].
>>
>> OK
>>
>>>
>>> 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.
>>>
>>
>> I agree with this observation. For some time, it has not been possible
>> to have any extensions on RA options.
>>
>>>> 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.
>>>
>>
>> OK
>>
>>> Regards
>>>   Brian Carpenter
>>> _______________________________________________
>>> mif mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mif
>> _______________________________________________
>> mif mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mif