Subject: [Roll] FW: New Version Notification for draft-thubert-6man-reverse-routing-header-00

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Jun 2010 09:57:07 +0200

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:[email-masked]] 
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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Jun 2010 07:47:05 +0200

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)
> <[email-masked]> wrote:
> > Hi:
> >
> > 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.
> > 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.
> >
> > 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
> > [email-masked]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 13 Jun 2010 22:14:19 -0700

Hi Pascal,

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 13 Jun 2010 22:51:26 -0700

Hi Pascal,

> 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?
I agree. That is the reason I would think we should go in for an
application level to do this instead of change the routing header (it
helps us gain a lot of flexibility).

Besides finding paths is a function of an application/ routing layer
and not the data packets and we should not add complexity to the data
path.

I am ok waiting for others to respond and see what they have to say.

Thanks,
Vishwas