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

[Zhen Cao <[e-mail]>]

>> 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.

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.

>> 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



-- 
Best regards,
Zhen