Re: [Roll] draft-ietf-6man-rpl-routing-header-07

[Jonathan Hui <[e-mail]>]

On Dec 21, 2011, at 6:10 PM, Mukul Goyal wrote:

> Just the knowledge that the router is part of a particular RPL instance via a particular interface is no guarantee that all the neighbors reachable via that interface belong to the same RPL instance. On the other hand, a router would clearly know whether its particular interface belongs to the RPL domain or not. A packet wont be sent down an interface if that interface is not part of the RPL domain. Here, I am assuming that the RPL domain is defined in the manner you had suggested (analogous to the definition of a routing domain in Section 1.2 of RFC 1195).

And by the same logic, when forwarding a message, there is no guarantee that all neighboring nodes reachable via an interface belong to the same RPL routing domain.

>> Remember that the original purpose of the RPL Instance is to support MTR.  The RPL Instance identifies what routing topology to use.  This is important especially if the SRH does not specify the entire path to the destination.  How does the tunnel exit-point know what routing topology to use to reach the destination?
> 
> There is no mention of MTR in the RPL specs. As far as RPL spec goes, an RPL Instance is simply a group of DAGs using the same OF. You can not assume that a tunnel exit-point would get any information from RPL Instance ID regarding how to reach the ultimate destination of the packet. That information would probably come from the routing table (which may be getting information via several routing protocols).

The *entire* point of the RPL Instance concept is to support MTR.  The RPL Instance is used to distinguish between different DODAGs from the same root.  It gives you the ability to have multiple different routes to the same destination (e.g. one that minimizes latency vs. one that minimizes energy consumption).  If you don't have the RPL Instance information when forwarding a packet, how do you know whether to forward along the path that minimizes latency vs. the path that minimizes energy?

See slide 18 of http://www.iab.org/wp-content/IAB-uploads/2011/04/Vasseur.pdf if you want one such reference of MTR and RPL Instances.

>> The lack of and need for the RPL Instance identifier was raised during IESG review.  The options are (1) to require inclusion a RPL Option in addition to the RPL routing header or (2) add a RPL Instance field in the RPL routing header itself.  I doubt that you would prefer option 1.
> 
> I will try to go back and find the IESG review you have mentioned. If you could quickly direct me to right place, that will be helpful. But, at the moment, it is truly mind-boggling for me that RPL instance id is required to be specified in the source routing header. 

Not so mind boggling if you consider MTR.

>> If the RPL router has no idea of the RPL Instance when forwarding, it can choose to forward the packet along anyway.
> 
> Doing that would break the rules in SRH draft.

Of course.  I was making a proposal that we could relax the processing rules to end-points of the SRH.

>> At the very least, the tunnel exit-point should enforce the use of the RPL Instance.  Surely the end-points of a source route should at least know what RPL Instance they are in...
> 
> Yes, this RPL Instance is a local instance which has no significance associated. I think you are trying to assign a meaning to RPL Instance ID which it does not currently have under RPL core spec.


As I mentioned above, the RPL Instance allows you to have multiple distinct paths towards the same destination.  The RPL hop-by-hop option includes a RPL Instance ID so that a forwarding node knows which routing topology to use.  If RPL did not allow multiple routes to the same destination, then why bother having a RPL Instance?  You would only need the DODAGID to uniquely identify a DODAG (whereas the existing definition is the "tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG".

--
Jonathan Hui