Hi Vishwas: > I just read through your draft and have some basic comments. [Pascal] : )
> > It seems like a mechanism similar to the way path finding is/ was done > in the Token ring network. I have some comments however. [Pascal] You've got a good memory. Yes, the test frame would trace a path through bridges. We'll note that TR would enable duplicate MAC addresses, which was used extensively as a high availability tool. No going that far, there are many examples of source route in IP, LSRR, DSR... > > 1. I think the whole Record route should act as an application of IPv6 > (not the IPv6 Extension header - it gives a lot of flexibility). We > could send packets Hop-by-hop in this case with the information which > gets punted to the application at each hop, which in turn adds > address. > [Pascal] At the moment, the only use case is RPL. So we could have made that a RPL field. But there might be other users, and it seemed that a more generic mechanism could be beneficial to the community. And this spec is a companion for the RH4 spec. So we thought it better like this, but let's see what others think. > 2. The second thing is do we always assume that we have a path from > any device to the Border route is correct. If not we may have to do > flooding and then checks to see that the packet is not getting looped > back. For that we may have some context in the higher layer packet. > [Pascal] If your point is that the gathering of the path is not self-sufficient, I completely agree with you. There needs to be a higher level protocol that decides how the record route gets propagated to one or more successors. RPL is such protocol, and it has its own inconsistency detection mechanism. I agree I could add words on the expectation on the what happens above. > 3. We should have loop checks whenever we add an address to the list, > to make sure the address is not readded. [Pascal] Yes, we could enforce rules similar to that of RH4. Let's see how that settles. > 4. A link local address has context only in scope of an interface. > Would we want to specify the interface if we are using link-local > address in the packet. [Pascal] If the packet gets out a same interface, we could imagine that the mechanism works as described. But if we have to go out a different interface, then we have to formalize what an interface ID is. That might be going too far for a spec like this? Thanks a bunch Vishwas, Pascal > On Fri, Jun 11, 2010 at 12:57 AM, Pascal Thubert (pthubert) > <pthub...@cisco.com> wrote: > > Hi: > > > > This is additional work linked to the RPL effort. > > RPL as a model whereby nodes operate in either source route or stateful > modes. For the source route mode, there is a need for a new routing header, > and that is addressed by draft-hui-6man-rpl-routing-header. > > Additionally, RPL as a Point to Point support in the works. For that P2P, > > RPL > additionally requires a record route operation, on top of the RH4 defined in > Jonathan's draft. > > draft-thubert-6man-reverse-routing-header initiates the record route > piece. > > > > Pascal > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org] > > Sent: Thursday, June 10, 2010 3:21 PM > > To: Pascal Thubert (pthubert) > > Subject: New Version Notification for draft-thubert-6man-reverse-routing- > header-00 > > > > > > A new version of I-D, draft-thubert-6man-reverse-routing-header-00.txt > has been successfully submitted by Pascal Thubert and posted to the IETF > repository. > > > > Filename: draft-thubert-6man-reverse-routing-header > > Revision: 00 > > Title: Reverse Routing Header > > Creation_date: 2010-06-10 > > WG ID: Independent Submission > > Number_of_pages: 24 > > > > Abstract: > > For new classes of devices such as highly constrained nodes, forward and > return Record Route capabilities are required to enable basic forwarding > operations. This memo defines a such a technique for IPv6. > > > > > > > > The IETF Secretariat. > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
