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

[Robert Cragie <[e-mail]>]

Hi Jonathan,

Some comments and questions below.

Robert

On 22/12/2011 6:02 PM, Jonathan Hui wrote:
> On Dec 22, 2011, at 9:24 AM, Mukul Goyal wrote:
>
>>> Again, just because you received a message on an interface for which you've enabled RPL doesn't mean you know the message came from a router that is within the same RPL routing domain.  A router not running RPL could have sent you that message.
>> A router not running RPL could have sent me a message carrying SRH?
> Sure.  It could be a host as well.  Part of limiting the scope is to limit the scope of an attack.  See the Security Considerations.
<RCC>I'm not getting this. The use of SRH is for non-storing mode, 
correct? And only for non-storing mode? There is no current definition 
of partial storing mode and stored mode doesn't need SRH. So the source 
routes are created on the DAG root based on transit information obtained 
by DAOs. How can any router outside of the RPL domain initiate a 
source-routed message to a node in the RPL domain? It would be tunneled 
at the point it got to the DAG root. Therefore, by implication, normally 
the source and destination of the message with SRH must be in the RPL 
domain. So we need to check for exceptions - surely the rules Mukul 
stated are sufficient?</RCC>
>
>>>  From Section 3.2.1 of draft-ietf-roll-rpl:
>>    The Objective Function (OF) defines how RPL nodes select and optimize
>>    routes within a RPL Instance.  The OF is identified by an Objective
>>    Code Point (OCP) within the DIO Configuration option.  An OF defines
>>    how nodes translate one or more metrics and constraints, which are
>>    themselves defined in [I-D.ietf-roll-routing-metrics], into a value
>>    called Rank, which approximates the node's distance from a DODAG
>>    root.  An OF also defines how nodes select parents.  Further details
>>    may be found in Section 14, [I-D.ietf-roll-routing-metrics],
>>    [I-D.ietf-roll-of0], and related companion specifications.
>>
>>> As you state, RPL Instance maps to OF which, from the cited text, maps to metrics and route selection.  By transitivity, RPL Instance ID does map to metrics and how routes are formed.
>> The text you quoted no where says that an OF maps to particular metric. OF0 is metrics-independent. OF1 (draft-ietf-roll-minrank-hysteresis-of-04) applies to any additive metric. No RPL doc says that, for a particular LLN, a particular OF maps to a particular metric only.
> Incorrect.  From draft-ietf-roll-routing-metrics-19:
>
>     The set of routing metrics and constraints used by an RPL deployment
>     is signaled along the DAG that is built according to the Objective
>     Function (rules governing how to build a DAG) and the routing metrics
>     and constraints are advertised in the DAG Information Option (DIO)
>     message specified in [I-D.ietf-roll-rpl].
>
> In other words, the combination of the OCP and the metrics identified by the DODAG Root describes how to optimize the routes.  In the case of OF0, the metric is the Rank itself.
>
>> I think the following text clearly specifies what an RPL Instance is. Also, this text clearly says that an RPL Instance ID maps to a particular OF:
>>
>> rpl-19 section 3.1.2:
>>       A RPLInstanceID identifies a set of
>>       one or more Destination Oriented DAGs (DODAGs).  A network may
>>       have multiple RPLInstanceIDs, each of which defines an independent
>>       set of DODAGs, which may be optimized for different Objective
>>       Functions (OFs) and/or applications.  The set of DODAGs identified
>>       by a RPLInstanceID is called a RPL Instance.  All DODAGs in the
>>       same RPL Instance use the same OF.
>>
>> This definition says an RPLInstanceID identifies a set of DAGs with a common OF. No more and no less. A particular LLN may choose to map an OF to a particular metric but there is no such requirement as per RPL specs.
> You never answered my question.  Why bother having a RPL Instance ID if you don't care how the routes are optimized?  Why bother maintaining multiple paths optimized using different OFs and/or metrics?
<RCC>
The source route is determined by the transit options, nothing else. 
There is no processing done at each hop - it simply forwards it to the 
next based on what's in the SRH. So no need for RPL instance (or domain) 
there. You could potentially build up multiple tables for each RPL 
instance but you would just formulate a different SRH based on which 
table you picked. When it gets to the destination, why would the 
OF/metric of whatever DAG it happen to transit through have any bearing 
on where it is subsequently going? I ask this because there is no 
further information based on the domain it has just gone through. The 
message originator would not even be aware of any subsequent RPL domains 
beyond itself; it is bounded by the root and the leaf routers. Unless 
the destination is on path between the DAG root and a leaf router, an 
SRH will always go between the DAG root and a leaf router. I find the 
concept of a partial SRH quite baffling even if it is for the purposes 
of traceroute - even then at the point it emerges someway down the path, 
it will return a time exceeded error.

So basically, I am still failing to understand the need to carry RPL 
instance in the SRH for non-storing mode. I could see its use in partial 
storing mode whereby SRH carries it part of the way and the stored 
information on subsequent routers the rest, but in this case surely you 
would put a RPL option in the inner packet and tunnel? So when it 
emerges from the source-routed tunnel, it is ready to be forwarded using 
RPL.
<RCC>
>
>>>> 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.
>>> See above.  RPL Instance does map to metrics.
>> It need not.
> You are incorrect again!
>
>>> The definition I proposed was simply a collection of routers running RPL under the same administrative domain.  As mentioned above, that does not mean that every router on an interface belongs to a RPL routing domain.
>> I think the definition you provided is sufficient. An RPL domain is a collection of routers running RPL under the same administrative domain. Each router in the RPL domain needs to classify all its interfaces regarding whether they belong to the RPL domain or not.
>>
>> A packet can be assumed to be coming from a router in the RPL domain if it carries an SRH.
>
> Nope.  As I stated before, that would invalidate the Security Considerations section.
<RCC>I agree with Mukul: in normal circumstances a packet with an SRH 
will come from a router in the RPL domain and the rules Mukul stated can 
be used to make sure it doesn't go beyond.</RCC>
>
> --
> Jonathan Hui
>
>