Zhen, On 23/07/2012 03:49, Zhen Cao wrote: > On Sat, Jul 21, 2012 at 8:15 PM, Brian E Carpenter > <brian.e.carpen...@gmail.com> wrote: >> Hi Zhen, >> >> On 21/07/2012 13:03, Zhen Cao wrote: >>> On Fri, Jul 20, 2012 at 5:13 PM, Brian E Carpenter >>> <brian.e.carpen...@gmail.com> wrote: >>>> Wasn't this already answered? >>>> >>>> http://www.ietf.org/mail-archive/web/mif/current/msg01784.html >>>> >>>> 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. >> Yes it did: > > I do not think so. > >> "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. Regards Brian > > Regards, > Zhen >> 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 >> >>> 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 >>>>> 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 <sarikaya2...@gmail.com> >>>>> >>>>>> Hi Hui, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> On Wed, Jul 18, 2012 at 3:08 AM, Hui Deng <denghu...@gmail.com> wrote: >>>>>>> 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 >>>>>>> >>>>>> 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 >>>>>>> Best, >>>>>>> >>>>>>> -Hui >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2012/7/11 Behcet Sarikaya <sarikaya2...@gmail.com> >>>>>>>> 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 >>>>>>>> mif@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mif >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> mif mailing list >>>>> mif@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mif >>>> _______________________________________________ >>>> mif mailing list >>>> mif@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mif > > > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
