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

[Mukul Goyal <[e-mail]>]

>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 simplest option would be for the router to decide before hand which of its interfaces belong to "the" RPL domain and which not. The SRH need not have any RPL domain field. The router would drop the packet if received over an interface not in "the" RPL domain. If the packet was received over an interface in the RPL domain, it wont be forwarded down the interfaces not in the RPL domain.

A more complicated scheme would be to allow for multiple RPL domains and list the RPL Domain ID in the SRH. The router would know which RPL domains its interfaces belong to and would treat the packet accordingly.

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

I am trying to say that RPL Instance ID does not give that information to the tunnel exit point. As per RPL spec, RPL Instance ID would have a mapping to the OF. It nowhere says that RPL Instance ID also has a mapping to metrics in use.
 
> Again, the whole purpose of RPL Instances is to allow multiple paths optimized with different OFs towards the same destination.

OF is just a way to calculate the rank. OF does not imply the use of particular routing metrics. Since RPL Instance ID does not identify the routing metrics in use, it can not tell what kind of route is being used to forward a packet.

> If a forwarding device has no idea of what path to choose, then why bother with a RPL Instance?

RPL Instance is the top level identifier of the DAGs that can be used to forward the packet. It also maps to a particular OF. In my opinion and as per RPL spec, RPL instance has no other significance.

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

Lets assume that RPL domain is defined as you suggested some time back to be analogous to the routing domain definition in RFC 1195 (section 1.2). I interpret it to mean that the RPL router would characterize its interfaces as either belonging to the RPL domain or outside the RPL domain.

With this interpretation of RPL domain in mind, the following processing rules would replace the rules 2 and 3 on page 13 of your draft:

2.  Datagrams, carrying an SRH and received on an interface not belonging to the RPL domain, will be dropped with no further processing.

3.  Datagrams, carrying an SRH and destined to be forwarded along interfaces outside the RPL domain, are dropped with no further processing.

Thanks
Mukul




--
Jonathan Hui