>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?
>> 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.
>Except that there is no such concept. RPL Instance ID is the closest we have.
Yes, the concept of RPL domain needs to be defined - either in rpl-terminology
draft or in your draft.
>> 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.
>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.
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.
>> 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.
>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.
Thanks
Mukul
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
