Subject: 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: Vishwas Manral <[email-masked]>
Date: Sun, 13 Jun 2010 22:14:19 -0700

Hi Pascal,

I just read through your draft and have some basic comments.

It seems like a mechanism similar to the way path finding is/ was done
in the Token ring network. I have some comments however.

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.

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.

3. We should have loop checks whenever we add an address to the list,
to make sure the address is not readded.

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.

Thanks,
Vishwas

On Fri, Jun 11, 2010 at 12:57 AM, Pascal Thubert (pthubert)
<[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

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

> I just read through your draft and have some basic comments.
[Pascal] : )

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

> gets punted to the application at each hop, which in turn adds
[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.

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

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

> Would we want to specify the interface if we are using link-local

[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

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

---

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