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

[Jonathan Hui <[e-mail]>]

On Dec 22, 2011, at 7:04 AM, Mukul Goyal wrote:

>> 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.
> 
> The receiving router could check if it belongs to the RPL domain listed in the SRH. If not, it can drop the packet.

And what information does the SRH provide that indicates what RPL routing domain it is coming from?  A node now has to know what neighbors are in its RPL routing domain?

>> 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?
> 
> Suppose a tunnel exit point knows that the SRH that carried the packet so far had RPL Instance ID 'x' which happens to be associated with OF0. What information does that give to the tunnel exit point? Is OF0 associated with minimizing of latency or of energy? What is preventing this particular RPL Instance ID 'x' with OF0 to be associated with two different DAGs - one minimizing latency and the other minimizing energy?

The tunnel exit-point knows what kind of paths the tunnel entry-point is forwarding the packet along.  Again, the whole purpose of RPL Instances is to allow multiple paths optimized with different OFs towards the same destination.  If a forwarding device has no idea of what path to choose, then why bother with a RPL Instance?

>> 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.
> 
>> 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".
> 
> All this discussion is really besides the point. If we could just have the RPL domain and not the RPL Instance as the scope for an SRH, that will solve my problem.


Limiting to a RPL Instance is well-defined.  Limiting to a RPL routing domain requires a little more thought.  Can you propose the exact processing rules that would clearly limit a routing header to a RPL routing domain?

--
Jonathan Hui