Re: [Roll] Comments on draft-dt-roll-p2p-rpl-01

[JP Vasseur <[e-mail]>]

Hi,

As promised here is some text wrt the trade-off on on-demand routing.

"As pointed out in this document, RPL does provide support of P2P  
routes via a common
ancestor. Using the mechanism described in this document, more optimal  
routes with
regards to some metrics may be discovered but it is worth pointing out  
that this comes
at the price of additional control messages in the network since the  
discovery process
requires sending additional routing control plane messages. The gain  
in terms of path
optimality may vary with the network topology and networking  
conditions. Thus network
designer may want to take into account the trade-off between the  
potential discovery of a
more optimal route and the associated cost in terms of network and  
node resources.
Note that on-demand routing also offers the benefit of not having to  
maintains states
as with proactive routing."

Thanks.

JP.

On Jun 16, 2010, at 12:00 PM, JP Vasseur wrote:

> Dear authors,
>
> Since I had a number of comments I inserted them in the ID itself.  
> As you will notice:
> 1) Some of them are purely editorial
> 2) Others are more fundamental and may require just clarifications,  
> more discussion on the mailing list, ... In this case, feel free to  
> start a separate thread (note that ticket cannot be assigned to non  
> WG document).
> 3) I also suggested new sections
>
> Internet Engineering Task Force                            M. Goyal,  
> Ed.
> Internet-Draft                         University of Wisconsin  
> Milwaukee
> Intended status: Informational                          E. Baccelli,  
> Ed.
> JP> Are you sure that you want to make it informational ?
>
> Expires: December 16, 2010                                          
> INRIA
>                                                                P2P.  
> Team
>                                                            June 14,  
> 2010
>
>
>    Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
>                                 Networks
>                         draft-dt-roll-p2p-rpl-01
>
> Abstract
>
>    This document describes a mechanism to discover and establish "on
>    demand" one or more routes between two routers in a low power and
>    lossy network.
>
> JP> Needs a bit more details + explicitly refer to IPv6 in the  
> abstract
> and introduction.
>  Status of this Memo    This Internet-Draft is submitted to IETF in  
> full conformance with the   provisions of BCP 78 and BCP 79.     
> Internet-Drafts are working documents of the Internet Engineering    
> Task Force (IETF).  Note that other groups may also distribute    
> working documents as Internet-Drafts.  The list of current  
> Internet-   Drafts is at http://datatracker.ietf.org/drafts/ 
> current/.    Internet-Drafts are draft documents valid for a maximum  
> of six months   and may be updated, replaced, or obsoleted by other  
> documents at any   time.  It is inappropriate to use Internet-Drafts  
> as reference   material or to cite them other than as "work in  
> progress."    This Internet-Draft will expire on December 16, 2010.  
> Copyright Notice    Copyright (c) 2010 IETF Trust and the persons  
> identified as the   document authors.  All rights reserved.    This  
> document is subject to BCP 78 and the IETF Trust's Legal    
> Provisions Relating to IETF Documents   (http://trustee.ietf.org/license-info 
> ) in effect on the date of   publication of this document.  Please  
> review these documents   carefully, as they describe your rights and  
> restrictions with respect   to this document.  Code Components  
> extracted from this document must   include Simplified BSD License  
> text as described in Section 4.e of   the Trust Legal Provisions and  
> are provided without warranty as Goyal, et al.           Expires  
> December 16, 2010               [Page 1]  Internet-Draft          dra 
> ft-dt-roll-p2p-rpl-01               June 2010    described in the  
> Simplified BSD License. Table of Contents    1.   
> Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3    
> 2.  Targeted Use Cases . . . . . . . . . . . . . . . . . . . . . .   
> 4   3.   
> Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4    
> 4.  Functional Overview  . . . . . . . . . . . . . . . . . . . . .   
> 5   5.  Propagation of Discovery  
> Messages  . . . . . . . . . . . . . .  7     5.1.  The Route  
> Discovery Option . . . . . . . . . . . . . . . .  7     5.2.   
> Setting a DIO Carrying a Route Discovery Option  . . . . .  9      
> 5.3.  Processing of a DIO Carrying a Route Discovery  
> Option           At An Intermediate  
> Node  . . . . . . . . . . . . . . . . . 10     5.4.  Processing of a  
> DIO Carrying a Route Discovery Option           At The Target  
> Router . . . . . . . . . . . . . . . . . . . 12   6.  Propagation of  
> Discovery Reply Messages  . . . . . . . . . . . 13     6.1.  The  
> Discovery Reply Object (DRO) . . . . . . . . . . . . . 13        
> 6.1.1.  The Source Route Option  . . . . . . . . . . . . . . .  
> 15     6.2.  DRO as Acknowledgement for Backward Source  
> Routes  . . . . 16     6.3.  DRO as Carrier of Forward/Bidirectional  
> Source Routes  . . 17     6.4.  Establishing Hop-by-hop Routes Via  
> DRO . . . . . . . . . . 17   7.  Security  
> Considerations  . . . . . . . . . . . . . . . . . . . 18   8.  IANA  
> Considerations  . . . . . . . . . . . . . . . . . . . . . 18   9.   
> Authors and Contributors . . . . . . . . . . . . . . . . . . . 18    
> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  
> 18     10.1. Normative  
> References . . . . . . . . . . . . . . . . . . . 18     10.2.  
> Informative References . . . . . . . . . . . . . . . . . . 18    
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  
> 19 Goyal, et al.           Expires December 16, 2010                
> [Page 2]  Internet-Draft          draft-dt-roll-p2p-rpl-01            
>     June 2010 1.  Introduction    RPL [I-D.ietf-roll-rpl] provides  
> multipoint-to-point (MP2P) routes   from routers in a low power and  
> lossy network (LLN) to a sink router   by organizing the routers  
> along a Directed Acyclic Graph (DAG) rooted   at the sink.
> JP> low power and lossy .... Low Power and Lossy
> JP> RPL provides P2MP, MP2P and P2P routes too.
>
> The DAG root initiates the DAG formation by originating
>    a DODAG Information Object (DIO) message.  The DIO message is sent
>    via link-local multicast and carries information about the
>    originating router's position (the "rank") in the DAG.  On  
> receiving
>    DIO messages sent by its neighbors, a router determines its own
>    "rank" in the DAG and originates its own DIO message.
> JP> Without going too much in the details, you may just want to add
> that a node decides to join a DODAG according to a number of  
> parameters
> (identity of the DODAG, OF, routing/constraints a specified in the  
> metric-ID,...).
>    RPL enables point-to-multipoint (P2MP) routing from a router to its
>    descendants in the DAG by allowing a router to send a Destination
>    Advertisement Object (DAO) upwards along the DAG.  The DAO carries
>    the aggregated
> JP> Potentially "aggregated"
> information regarding the descendants (and other local
>    prefixes) reachable through the originating router.
>
>    RPL also provides mechanisms for point-to-point (P2P) routing  
> between
>    any two routers in the DAG.
> JP> Yes.
> If the destination is within the
>    source's "range", the source may directly send packets to the
>    destination.  Otherwise, if the destination is a DAG descendant and
>    the source maintains "downwards" routing state about this  
> descendant,
>    it can forward the packet along this route.  Otherwise, the source
>    sends the packet to a DAG parent, which then applies the same set  
> of
>    rules to forward the packet further.  Thus, a packet travels up the
>    DAG until it reaches a router that knows of the downwards route to
>    the destination and then it travels down the DAG towards its
>    destination.  A router may or may not maintain routing state  
> about a
>    descendant depending on whether its immediate children send it such
>    information in their DAOs and whether the router can store this
>    information.  Thus, in the best case scenario, the "upwards"  
> segment
>    of the P2P route between a source and a destination ends at the  
> first
>    common ancestor of the source and the destination.  In the worst
>    case, the "upwards" segment would extend all the way to the DAG's
>    root.  If the destination did not originate a DAO, the packet will
>    travel all the way to the DAG's root, where it will be dropped.
>
> JP> This may require to be a bit more accurate here. If there is no  
> DAO,
> there RPL is used for MP2P routing only (that is not a protocol design
> characteristic though).
>    The P2P routing functionality available in RPL suffers from several
>    shortcomings [I-D.brandt-roll-rpl-applicability-home-building]:
>
> JP> "suffering from several shortcomings" is a bit strong though.  
> You may
> want to say that additional mechanisms may be required to address  
> specific
> situation and list them.
>    o  The need to maintain routes "proactively", i.e. every possible
>       destination in the DAG must originate a DAO.
>
>    o  The constraint to route only along a DAG potentialy leading to
>       significantly suboptimal P2P routes and traffic congestion near
>       the DAG root.
> JP>
> First bullet: you can mention that this requires to pro-actively  
> advertise the
> route and to keep refreshing the state accordingly
> Second bullet: just to be very accurate, mention that the route may  
> be sub-optimal.
> This is highly network topology / OF dependent.
>  Goyal, et al.           Expires December 16, 2010                
> [Page 3]  Internet-Draft          draft-dt-roll-p2p-rpl-01            
>     June 2010    These shortcomings are not compatible with the home  
> and commercial   building domain application requirements described  
> in [RFC5826] and   [I-D.ietf-roll-building-routing-reqs].
> JP> Again, to be accurate, there are no MUST requirements listed in
> these ID that are not satisfied by RPL (with regards to the  
> aforementioned
> issues). I am NOT saying that the proposed mechanism is not useful
> (by all means), just that the statement above is not correct.
>
> Such applications require a
>    mechanism providing source-initiated discovery of P2P routes that  
> are
>    not along a DAG.
> JP> In some cases, it may be desirable to make use of source- 
> initiated ...
>
> This document thus describes such a mechanism,
>    complementary to the basic RPL specification.
>
>    The specified scheme is based on a reactive on-demand approach,  
> which
>    enables a router to discover one or more "good-enough" routes in
>    either direction between itself and another router in the LLN  
> without
>    any constraints regarding the existing DAG-membership of the links
>    that such routes may use.
> JP> This will be an aspect triggering some discussion. How "good" is
> "good enough" ? You will need some text to elaborate here or point
> to another section explaining what is meant by "good enough"
> Such routes may be source-routes or hop-
>    by-hop ones.
> JP> Just terminology: instead of referring to hop-by-hop routes, you  
> may
> want to say that once a route has been computed between two nodes in
> the network, IPv6 packet may be forward using a source routing  
> mechanism
> as specified in [XX] or in a hop by hop fashion.
> A complementary functionality, necessary to help decide
>    whether to initiate a route discovery, is a mechanism to measure  
> the
>    end-to-end cost of an existing route.
> JP> s/cost/path cost
> Such functionality will be
>    described in a separate document.
>
> JP> But its use is described in this document ?
>  2.  Targeted Use Cases    The mechanisms described in this document  
> are intended to be employed   as complementary to RPL in specific  
> scenarios that need point-to-   point (P2P) routes between arbitrary  
> routers.    One target use case, common in a home environment,  
> involves a remote   control (or a motion sensor) that suddenly needs  
> to communicate with   a lamp module, whose network address it knows  
> apriori.  In this case,   the source of data (the remote control or  
> the motion sensor) must be   able to discover a route to the  
> destination (the lamp module) "on   demand".    Another target use  
> case, common in a large commercial building   environment, involves  
> a large LLN deployment where P2P communication   along a particular  
> DAG among hundreds (or thousands) of routers   creates severe  
> traffic congestion near that DAG's root, and thus   routes across  
> this DAG are desirable.    Targeted use cases also include scenarios  
> where energy or delay   constraints are not satisfied by the P2P  
> routes along a DAG because   they involve traversing many more  
> intermediate routers than necessary   to reach the destination.
> JP> What I would suggest is to summarize it, put in the introduction,
> and detail the use case in the applicability statement.
> 3.  Terminology
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",  
> and
>    "OPTIONAL" in this document are to be interpreted as described in
>
>
>
> Goyal, et al.           Expires December 16, 2010                
> [Page 4]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
>    [RFC2119].
>
>    Additionally, this document uses terminology from
>    [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl], and introduces
>    the following terminology:
>
>    Origin Router: The router initiating the route discovery.  The  
> origin
>    router acts as one end point of the routes to be discovered.
>
>    Target Router: The other end point of the routes to be discovered.
>
>    Intermediate Router: A router that is neither the origin nor the
>    target.
>
>    Forward Route: A route from the origin router to the target router.
>
>    Backward Route: A route from the target router to the origin  
> router.
>
>    Bidirectional Route: A route that can be used in both directions:
>    from the origin router to the target router and vice versa.
>
>    Source Route: A complete and ordered list of routers that can be  
> used
>    by a packet to travel from a source to a destination.  Such source
>    routes can be carried by a packet in a proposed Type 4 Routing  
> Header
>    [I-D.hui-6man-rpl-routing-header].
>
>    Hop-by-hop Route: A route from a source to a destination where each
>    router in the route knows only the address of the next hop on the
>    route.
> JP> I would suggest to change the definition for "routing paradigm
> whereby packets are routed from their source to destination by
> on a hop by hop basis where the packets is routed by a set of routers
> along the path according to the routing table stored by each router
> along the path".
>    In this document, the term 'router' refers to any LLN device that  
> can
>    forward packets generated at other devices.
>
>
> 4.  Functional Overview
>
>    Router A originates a "Discovery" message listing router B as the
>    target.  Node A also indicates in the message:
>
>    o  The nature of the routing cost, the method for accumulating the
>       end-to-end cost
> JP> This may de detailed hereafter but I guess that you will point to
> the metric-ID for the metric used?
>
> and the criteria used to determine if a route is
>       "good enough";
>
>    o  The direction (forward: router A to router B; backward: router B
>       to router A; or both) of the route being discovered;
>
>    o  The desired number of routes;
>
>
>
>
> Goyal, et al.           Expires December 16, 2010                
> [Page 5]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
>    o  Whether the route is a source-route or a hop-by-hop one; and
>
>    o  A limit on the "distance" the Discovery message may travel.
>
> JP> Need to define the term "distance": is it a max path cost,  
> number of
> hops, ... ?
>     The Discovery message propagates via link-local multicast
> JP> Indicate "IPv6"
> with each
>    receiving router making the decision regarding whether to forward  
> the
>    message further based on the "distance" (from router A) that this
>    particular copy of the message has already traveled.  Note that  
> this
>    document does not require a receiving router to use the "good  
> enough"
>    criteria to make the forwarding decision.  This is because the
>    evaluation of such criteria may be too complex for a constrained
>    intermediate router to perform for each received copy of the
>    Discovery message.
> JP> So I guess that you define later what to do in both cases (the  
> node
> cannot process the "good enough" criteria or it can process it) ?
> The calculation of the "distance" that a copy of
>    the Discovery message has already travelled should be simple enough
>    for a constrained router to perform.
> JP> Again it is hard to tell from what you wrote if this can  
> reasonably be
> achieved; it depends on the definition of the term "distance".
> A router may optionally decide
>    not to forward a copy of the Discovery message further because the
>    aggregated cost of the route so far fails the "good enough"  
> criteria.
> JP> You will nee to be more specific here. Is it a "may" or a "MAY".
> Define what happens in this case. You may provide more details later
> in the document.
>    The underlying mechanism being used to propagate the Discovery
>    message may put further restrictions on its propagation.  A router
>    should not propagate the Discovery message further if hop-by-hop
>    routes are desired and the router can not store state for this  
> route.
>
>    As a copy of the Discovery message travels towards router B, it
>    accumulates the relevant forward/backward costs as well as the  
> route
>    it takes.  When router B receives a copy of the Discovery  
> message, it
>    determines whether the route traveled by the message meets the  
> "good
>    enough" criteria.
> JP> I think that you already mentioned this.
>    If router A had requested the discovery of backward source-routes,
> JP> Didn't you mean "forward" ?
>    router B caches one or more good enough source-routes it  
> identifies.
>    Additionally, router B sends one or more "Discovery Reply"  
> message to
>    router A to acknowledge the discovery of these routes.  These
>    acknowledgements allow router A to judge the success of the route
>    discovery.  The Discovery Reply messages can travel towards  
> router A
>    in any manner chosen by router B. For example, router B may source-
>    route the messages or send them towards router A along a DAG.
>
>    If router A had requested the discovery of "n" forward source- 
> routes,
>    router B sends the "n" good enough source-routes it identifies to
>    router A in one or more Discovery Reply messages.  Again, these
>    Discovery Reply messages can travel towards router A in any manner
>    chosen by router B.
> JP> What if the DAG is "broken": retry from A after expiration of a  
> local
> timer ?
>    If router A had requested the discovery of "n" bidirectional  
> source-
>    routes, router B caches the "n" good enough source-routes it
>    identifies and also sends these routes to router A in one or more
>    Discovery Reply messages.  These Discovery Reply messages can  
> travel
>    towards router A in any manner chosen by router B.
>
>
>
> Goyal, et al.           Expires December 16, 2010                
> [Page 6]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
>    If router A had requested the discovery of "n" forward/backward/
>    bidirectional hop-by-hop routes, router B sends out a Discovery  
> Reply
>    message to router A for each one of the "n" good enough routes it
>    identifies.
> JP> Do you need one "Discovery Reply message" per route or next-hop
> in this case?
> The Discovery Reply message travels towards router A
>    using the source-route accumulated by the Discovery message.
> JP> In the case of hop-by-hop routes, source routes, both ?
> As this
>    message travels towards router A, it establishes appropriate  
> forward/
>    backward routing state in the en-route routers.  This "non DAG"
>    routing state should be specially marked to associate it with the
>    routing metrics
> JP> Refer to metric ID ?
> used to discover the route and to distinguish such
>    state from other DAG-specific routing state the router may have.
> JP> Not sure that you need to distinguish the state. Suppose that you
> discover a hop-by-hop route (not a big fan of that terms as pointed  
> out
> above but let's continue to use it for the time being), a storing node
> may indeed have two routes for the same destination: do you want to
> state that it should always use the P2P routes discovered by this
> mechanism or let it choose the best one according to the metric in
> use?
> JP> What if there are two routes using different metrics?
>
> 5.  Propagation of Discovery Messages
>
>    RPL uses DIO message propagation to build a DAG.  The DIO message
>    travels via link-local multicast.
> JP> Add everywhere "IPv6 link-local multicast addresses"
>
> Each router joining the DAG
>    determines a rank for itself and ignores the subsequent DIO  
> messages
>    received from lower (higher in numerical value) ranked neighbors.
>    Thus, the DIO messages propagate outwards rather than return  
> inwards
>    towards the DAG root.
> JP> I would suggest to align to the RPL terminology. Inward/outward
> are not used anymore.
>
> The DIO message generation at a router is
>    further controlled by a trickle timer that allows a router to avoid
>    generating unnecessary messages.
> JP> Add a reference to the Trickle ID
>
> The link-local multicast based
>    propagation, trickle-controlled generation and the rank-based
>    poisoning of messages traveling in the wrong direction (towards the
>    DAG root) provide powerful incentives to use the DIO message as the
>    Discovery message and propagate the DIO/Discovery message by  
> creating
>    a "temporary" DAG.
>
> 5.1.  The Route Discovery Option
>
>        0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9  
> 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>        |   Type = 9    | Option Length | D |S|  N  | L |O|  Max  
> Rank   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>         
> |                                                               |
>        |                       Target  
> Address                          |
>         
> |                                                               |
>         
> |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>        |              OCP              |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>               Figure 1: Format of the Route Discovery Option
>
>    In order to be used as a Discovery message, a DIO MUST carry a  
> "Route
>    Discovery" option illustrated in Figure 1.  A DIO MUST NOT carry  
> more
>
>
>
> Goyal, et al.           Expires December 16, 2010                
> [Page 7]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
>    than one Route Discovery options.
> JP> Explain what you do if more than one is present:
> 	* Ignore the second one?
> 	* Ignore the entire message?
>
> A Route Discovery option consists
>    of the following fields:
>
>    o  Option Type = 0x09 (to be confirmed by IANA).
>
>    o  Option Length = 20 or 22 octets depending on whether the OCP  
> field
>       is included or not.
>
>    o  D: A 2-bit field that indicates the direction of the desired
>       routes:
>
>       *  D = 0x00: Forward;
>
>       *  D = 0x01: Backward;
>
>       *  D = 0x02: Bidirectional.
>
>    o  S: A flag that indicates whether source routes are desired.  The
>       flag is set if the source routes are desired.  The flag is clear
>       if hop-by-hop routes are desired.
>
>    o  N: A 3-bit unsigned integer indicating the number of routes
>       desired.
>
>    o  L: A 2-bit field indicating the minimum "Life Time" of the
>       temporary DAG, i.e., the minimum duration a router joining the
>       temporary DAG must maintain its membership in the DAG:
>
>       *  L = 0x00: Minimum life time is 5 seconds;
>
>       *  L = 0x01: Minimum life time is 10 seconds;
>
>       *  L = 0x02: Minimum life time is 1 minute;
>
>       *  L = 0x03: Minimum life time is 10 minutes.
>
> JP> Placeholder ... indicate what happens if a node cannot store that
> additional state (add a manageability section).
>    o  O: A flag that indicates whether the same OCP is used for route
>       discovery as well as temporary DAG formation.  If this flag is
>       clear, the OCP contained in the DODAG Configuration option in  
> the
>       DIO is used for route discovery as well.  Otherwise, the OCP
>       specified in the Route Discovery option is used for route
>       selection
> JP> s/route selection/route discovery
>
> and the metrics/constraints used for route selection are
>       carried in a Metrics Container option immediately following the
>       Route Discovery option.
> JP> Since OF is decoupled from metrics, you always need to indicate
> the metric in use. That said, I do not see your point here. Indeed,  
> the
> temporary DAG is built according to some OF and metrics so the
> resulting routes will inherit these metrics?
>    o  Max Rank: A 7-bit unsigned integer that indicates the maximum  
> rank
>       allowed in the temporary DAG advertised by the DIO message.   
> This
>       upper limit on the DAG rank serves as the "distance" referred to
>
>
>
> Goyal, et al.           Expires December 16, 2010                
> [Page 8]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
>       in Section 4 and provides a control over how far the Route
>       Discovery option contained in the DODAG Configuration option in
>       the DIO message may travel.
> JP> You may discuss it later in this document ... but the distance  
> is tied
> to how you compute the rank.
> A router MUST not
> JP> s/MUST not/MUST NOT
> join the temporary
>       DAG if its rank in the DAG will exceed this limit.  Later  
> versions
>       of this draft will map the 128 value space available in this  
> field
>       to 16-bit long limits on the DAG rank.
>
>    o  Target Address: The IPv6 address of the target router.
>
>    o  OCP: 16 bit unsigned integer.  An optional field, present only  
> if
>       the O flag is set, that indicates the objective code point (OCP)
>       to be used for route selection.
>
> 5.2.  Setting a DIO Carrying a Route Discovery Option
>
>    A DIO message that carries a Route Discovery option MUST set the  
> Base
>    Object, described in [I-D.ietf-roll-rpl], in the following manner:
>
>    o  RPLInstanceID: RPLInstanceID MUST be a local value as  
> described in
>       Section 4.1 of [I-D.ietf-roll-rpl].
>
>    o  Grounded (G) Flag: MUST be clear since the objective of DAG
>       formation is the propagation of Route Discovery option.  This  
> DAG
>       is temporary in nature and is not used for routing purpose.
>
>    o  Destination Advertisement Supported (A) Flag: MUST be clear for
>       same reasons as described above.
>
>    o  Destination Advertisement Trigger (T) Flag: MUST be clear.
>
>    o  Mode of Operation (MOP): Since the temporary DAG is not to be  
> used
>       for routing purposes, the value of this field is immaterial.  To
>       allow constrained routers to join the DAG, the MOP field  
> SHOULD be
>       set to 00 (non-storing).
>
> JP> I'd rather suggest to specify a new MOP value (0x02)
>    o  DODAGPreference (Prf): TBD
>
>    o  Destination Advertisement Trigger Sequence Number (DTSN): TBD
>
> JP> To be discussed on the mailing list ?
>    o  DODAGID: IPv6 address of the router initiating the route
>       discovery.
>
> JP> Origin router.
>    The other fields in the Base Object are set as per the rules
>    described in [I-D.ietf-roll-rpl].
>
>    The DODAG Configuration option, carried in the DIO message,  
> specifies
>    the parameters for the trickle timer operation that governs the
>    generation of DIO messages by the routers joining the temporary  
> DAG.
>
> JP> Also according to RPL ID or would you recommend different
> default values ? Default values for RPL are TBD but we could easily
> think of different values in this case. To be revisited in the future.
>
>
> Goyal, et al.           Expires December 16, 2010                
> [Page 9]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
>    The other fields defined in the DODAG Configuration option are  
> set as
>    follows:
>
>    o  The MaxRankIncrease field MUST be set to 0 to disable local  
> repair
>       of the temporary DAG.
>
>    o  This document RECOMMENDS a value 1 for the MinHopRankInc field.
>
>    o  Objective Code Point (OCP): The OCP to be used for temporary DAG
>       formation.  This document RECOMMENDS RPL Objective Function 0,  
> as
>       defined in [I-D.ietf-roll-of0], for use as the objective  
> function
>       for the formation of the temporary DAG.
>
>    A DIO, that contains a Route Discovery option with O flag set, MUST
>    also contain a Metric Container option immediately following the
>    Route Discovery option.  This Metric Container option carries the
>    values for the routing metrics as well as the constraints
>    (constituting the "good enough" criteria) used for route selection.
> JP> This is confusing: the metric and constraint carried within the  
> Metric
> Container are used for the DODAG formation. Do you want to use them
> for a different purpose ? At this point, you have not yet defined  
> the use of
> the good enough criteria but one can guess that you would use the good
> enough metrics to control the flooding and the metric/OF to  
> effectively
> build the temporary DAG and discover the routes. If so, the good  
> enough
> metrics are of different use.
>    Note that if O flag in the Route Discovery option is clear, the OCP
>    and Metric Container used for temporary DAG formation are used for
>    route selection as well.
>
>    A DIO, carrying a Route Discovery option, MUST not carry any Route
> JP> s/MUST not/MUST NOT
>    Information or Prefix Information options described in
>    [I-D.ietf-roll-rpl].
>
> 5.3.  Processing of a DIO Carrying a Route Discovery Option At An
>       Intermediate Node
>
>    The rules for DIO processing and transmission, described in  
> Section 7
>    of RPL [I-D.ietf-roll-rpl], apply to DIOs carrying a Route  
> Discovery
>    option as well except as modified in this document.
>
>    When an intermediate router joins a temporary DAG advertized by a  
> DIO
>    carrying the Route Discovery option, it MUST maintain its  
> membership
>    in the DAG for the Minimum Life Time duration listed in the Route
>    Discovery option.
> JP> What if it cannot ? Just not join the DAG and log an error ?
> Maintaining membership in the DAG implies
>    remembering:
>
>    o  The RPLInstanceID, the DODAGID and the DODAGVersionNumber for  
> the
>       temporary DAG;
>
>    o  The router's rank in the temporary DAG;
>
>    o  The best Metric Container,
> JP> you mean the best path cost?
> along with the associated source route
>       from the initiator of route discovery till this router  
> (carried in
>       a Record Route IPv6 Extension Header proposed in
>       [I-D.thubert-6man-reverse-routing-header]), for the Route
>
>
>
> Goyal, et al.           Expires December 16, 2010              [Page  
> 10]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
>       Discovery option being propagated by the temporary DAG.  If the
>       router can not compare Metric Containers, it MUST remember the
>       latest Metric Container it has received, along with the  
> associated
>       source route.
> JP> Requires clarification on what you mean by "compare"
>    A router belonging to a temporary DAG need not remember the  
> identity
>    of its DAG parents since the temporary DAG is not used for routing.
> JP> Are you sure ? What is a hop-by-hop route is needed ? Don't you
> need to remember your parent, or do you still record the route ?
>    The main purpose of a temporary DAG's existence is to facilitate  
> the
>    propagation of the Route Discovery option.
>
>    The router does not process a Route Discovery option, contained in
>    the received DIO, any further if any of the following conditions  
> are
>    true:
>
>    o  The router does not support the objective function
> JP> and/or metrics
> being used for
>       route discovery
>
>    o  The router does not have sufficient information to calculate the
>       relevant routing metrics/constraints in the right direction (as
>       specified by the D field).
>
>    o  The S field is clear, i.e. hop-by-hop routes are desired, but  
> the
>       router can not participate in a hop-by-hop route.
>
>    o  The router is an intermediate router and the router's rank in  
> the
>       temporary DAG, calculated on the basis of the rank and objective
>       function carried in the Base Object in the DIO, exceeds the Max
>       Rank value specified in the Route Discovery option.
>
>    A router MUST discard the DIO if the Route Discovery option  
> contained
>    in the message does not need further processing.
> JP> Log an error ?
> Otherwise, the
>    Route Discovery option is processed as follows.
>
>    The router updates the Metrics Container associated with the  
> received
>    Route Discovery option as per the specified objective function.
> JP> And routing metrics
>
> The
>    router may optionally check the Metric Container to determine if  
> the
>    aggregated values for the routing metrics meet all the constraints
>    listed in the Metric Container.
> JP> The aggregated values are for the metrics. Constraints are used to
> prune potential path.
> If not, the Route Discovery option
>    is discarded
> JP> You mean the DIO message.
> without further processing.  Otherwise, the router
>    updates its in-memory copy of the latest/best Metric Container for
>    this Route Discovery option along with the associated source route
>    updated in the correct direction (based on the D field of the Route
>    Discovery option).  Any change in the in-memory copy also requires
>    resetting the trickle timer and generating a new DIO carrying the
>    Route Discovery option, the updated latest/best Metric Container  
> and
>    the associated source route (in a Record Route IPv6 extension  
> header
>    proposed in [I-D.thubert-6man-reverse-routing-header]) when the  
> timer
>    fires.
> JP> If the changes occur during the lifetime window.
> Note that the Metric Container MUST immediately follow the
>
>
>
> Goyal, et al.           Expires December 16, 2010              [Page  
> 11]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
>    Route Discovery option if the O flag in the Route Discovery  
> option is
>    set.
>
> 5.4.  Processing of a DIO Carrying a Route Discovery Option At The
>       Target Router
>
>    When the target router joins the temporary DAG advertized by a DIO
>    carrying the Route Discovery option, it MUST maintain its  
> membership
>    in the DAG for the Minimum Life Time duration listed in the Route
>    Discovery option.  Maintaining membership in the DAG implies
>    remembering:
>
>    o  The RPLInstanceID, the DODAGID and the DODAGVersionNumber for  
> the
>       temporary DAG;
>
>    o  The router's rank in the temporary DAG;
>
>    The target router does not process a Route Discovery option,
>    contained in the received DIO, any further if any of the following
>    conditions are true:
>
>    o  The router does not support the objective function used for  
> route
>       discovery
>
>    o  The router does not have sufficient information to calculate the
>       relevant routing metrics/constraints in the right direction (as
>       specified by the D field).
>
> JP> or does not support the metric.
>    The target router MUST discard the DIO if the Route Discovery  
> option   contained in the message does not need further processing.
> JP> ? How does it knows (simply because it reaches the destination) ?
>    Otherwise, the Route Discovery option is processed as follows.
>
>    The target router updates the Metrics Container associated with the
>    received Route Discovery option as per the specified objective
>    function.
> JP> and routing metrics (remember they are decoupled).
>
> The target router then checks the Metric Container to
>    determine if the aggregated values for the routing metrics meet all
>    the constraints listed in the Metric Container.
> JP> See previous comments.
>
> If not, the Route
>    Discovery option is discarded without further processing.   
> Otherwise,
>    the router MAY select the source route accumulated by the received
>    DIO as one of the discovered routes.
> JP> "MAY" ? When ?
> The target router MUST send one
>    or more RPL Control Messages carrying a Discovery Reply Object
>    (defined in the next section) back to the origin router (identified
>    by the DODAGID field in the DIO Base Object) as discussed in the
>    following sections.
>
>    The target router MUST NOT forward a DIO carrying a Route Discovery
>    option that lists one of its own addresses as the Target Address.
>
>
>
>
> Goyal, et al.           Expires December 16, 2010              [Page  
> 12]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
> 6.  Propagation of Discovery Reply Messages
>
> 6.1.  The Discovery Reply Object (DRO)
>
>        0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9  
> 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>        | RPLInstanceID |    Version    | D |S|  N  |      
> Reserved      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>         
> |                                                               |
>        |                         DODAGID                           |
>         
> |                                                               |
>         
> |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>         
> |                                                               |
>        |                       Target  
> Address                          |
>         
> |                                                               |
>         
> |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>        | Option(s)...
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
>
>
>            Figure 2: Format of the Discovery Reply Object (DRO)
>
>    This document defines a new RPL Control Message type, the Discovery
>    Reply Object (DRO) with code 0x04 (to be confirmed by IANA), that
>    serves the following functions:
>
>    o  An acknowledgement from the target router to the origin router
>       regarding the successful discovery of backward source routes;
> JP> ACK of routes from the origin to the target: you may not have  
> routes
> in the opposite direction.
>    o  Carries one or more forward/bidirectional source routes from the
>       target to the origin router;
>
>    o  Establishes a hop-by-hop forward/backward/bidirectional route as
>       it travels from the target to the origin router.
>
>    The format for a Discovery Reply Object (DRO) is shown in Figure 2.
>    A DRO consists of the following fields:
>
>    o  RPLInstanceID: The RPLInstanceID of the temporary DAG used for
>       route discovery.
>
>    o  Version: The Version of the temporary DAG used for route
>       discovery.
>
>
>
>
>
> Goyal, et al.           Expires December 16, 2010              [Page  
> 13]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
>    o  DODAGID: The DODAGID of the temporary DAG used for route
>       discovery.  The DODAGID also identifies the origin router.  The
>       RPLInstanceID, the Version and the DODAGID together uniquely
>       identify the temporary DAG used for route discovery and can be
>       copied from the Base Object of the DIO advertizing the temporary
>       DAG.
>
>    o  D: A 2-bit field that indicates the direction of the discovered
>       routes:
>
>       *  D = 0x00: Forward;
>
>       *  D = 0x01: Backward;
>
>       *  D = 0x02: Bidirectional.
>
>       This field has the same value as the corresponding field in the
>       Route Discovery option.
>
>    o  S: A flag that is clear if the Discovery Reply Object is
>       establishing an hop-by-hop route.  The flag is set if the
>       Discovery Reply Object carries (or is an acknowledgement for the
>       discovery of) one or more source routes.
>
>    o  N: A 3-bit field that indicates the number of source routes
>       carried or acknowledged in the Discovery Reply Object.
>
>    o  Target Address: The IPv6 address of the target router  
> originating
>       the Discovery Reply Object.
>
>    o  Reserved: These bits are reserved for future use.  These bits  
> MUST
>       be set to zero on transmission and MUST be ignored on reception.
>
>    o  Options: The Discovery Reply Object MAY carry up to 7 Source  
> Route
>       options (defined in the next section) with each such option
>       carrying a complete forward/bidirectional source route and
>       optionally followed by a Metric Container option that lists the
>       aggregated values for the routing metrics for the source route.
> JP> This may not be an aggregated value but recorded metric too.
>  Goyal, et al.           Expires December 16, 2010               
> [Page 14]  Internet-Draft          draft-dt-roll-p2p-rpl-01           
>      June 2010 6.1.1.  The Source Route Option         
> 0                   1                   2                   3         
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0  
> 1       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+-+       |   Type = 10   | Option Length | Compr |  Pad  |      
> Resvd     |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+-+-+-+-+-+-+        
> |                                                                
> |       .                       
> Addresses 
> [1 
> ..n 
> ]                          .       .                                                               .       | 
>                                                                 
> |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+-+                 Figure 3: Format of the Source Route Option     
> The Source Route option, illustrated in Figure 3, carries a  
> complete   forward/bidirectional source route from the target router  
> to the   origin router.  A Source Route option can only be a part of  
> the   Discovery Reply Object and MAY be immediately followed by a  
> Metric   Container option that contains the aggregated values of the  
> routing   metrics for this source route.    A Route Discovery option  
> consists of the following fields:    o  Option Type = 0x0A (to be  
> confirmed by IANA).    o  Option Length = Variable, depending on the  
> size of the Addresses      vector.    o  Compr: 4-bit unsigned  
> interger indicating the number of prefix      octets that are elided  
> from each address.  For example, Compr      value will be 0 if full  
> IPv6 addresses are carried in the      Addresses vector.    o  Pad:  
> 4-bit unsigned integer.  Number of octets that are used for       
> padding between Address[n] and the end of the Source Route  
> option.    o  Address[1..n]: Vector of addresses, numbered 1 to n.   
> Each vector      element has size (16 - Compr) octets.    A common  
> network configuration for an RPL domain is that all routers   within  
> an LLN share a common prefix.  The Source Route option uses   the  
> Compr field to allow compaction of the Addresses[1..n] vector   when  
> all entries share the same prefix as the DODAGID or the Target    
> Address of the encapsulating Discovery Reply Object.  The shared    
> prefix octets are not carried within the Source Route option and  
> each   entry in Address[1..n] has size (16 - Compr) octets.  When  
> Compr is Goyal, et al.           Expires December 16,  
> 2010              [Page 15]  Internet-Draft          draft-dt-roll-p2 
> p-rpl-01               June 2010    non-zero, there may exist unused  
> octets between the last entry,   Address[n], and the end of the  
> Source Route option.  The Pad field   indicates the number of unused  
> octets that are used for padding.   Note that when Compr is 0, Pad  
> MUST be null and carry a value 0.    The Source Route option MUST  
> NOT specify a path that visits a router   more than once.  When  
> generating a Source Route option, the target   router may not know  
> the mapping between IPv6 addresses and routers.   Minimally, the  
> target router MUST ensure that:    o  The IPv6 Addresses do not  
> appear more than once;    o  The IPv6 addresses of the origin and  
> the target routers do not      appear in the Address vector;    o   
> The Address vector represents a source route in forward  
> direction      with Address[1] being the next hop for the origin  
> router.    Multicast addresses MUST NOT appear in a Source Route  
> option.
> JP> you may want to add a ref to RH4 since the format is very similar.
> 6.2.  DRO as Acknowledgement for Backward Source Routes
>
>    When a target router discovers a backward source route,
> JP> I have an issue with your terminology. When the target receives  
> the
> DIO with route discovery option, what is discovered is a forward  
> route ?
>
> it sends a
>    DRO message to the origin router as an acknowlegement for the
>    discovered route.  Optionally, a target router MAY send a DRO
>    acknowledgement to the origin router after discovering multiple
>    backward source routes.  A DRO, serving as an acknowledgement for
>    backward source route discovery, has its D field set to 0x01
>    (indicating backward) while the S flag is set to 1 (indicating  
> source
>    route).  The N field is set to indicate the number of discovered
>    backward source routes being acknowledged.  Such a DRO message MUST
>    NOT contain any option.
>
>    This document does not require a particular method for sending  
> such a
>    DRO message to the origin router.  The target router MAY send the  
> DRO
>    message to the origin router in any fashion, including:
>
>    o  Using a source route carried in a Type 4 Routing header
>       [I-D.hui-6man-rpl-routing-header];
>
>    o  Along any DAG connecting the target and the origin routers;
>
>    o  Along the temporary DAG created for route discovery, provided  
> that
>       the target router is reasonably sure that the DAG's life time is
>       sufficiently long and the routers in the DAG do remember one or
>       more of their parents in the DAG.
> JP> You may want to explain a bit more why you the origin router
> would be interested in receiving an ACK without the route itself (case
> 6.3): hop-by-hop routes.
>  Goyal, et al.           Expires December 16, 2010               
> [Page 16]  Internet-Draft          draft-dt-roll-p2p-rpl-01           
>      June 2010 6.3.  DRO as Carrier of Forward/Bidirectional Source  
> Routes    When a target router discovers a forward source route,
> JP> Here, I agree that this is a forward route.
> it sends a DRO
>    message to the origin router carrying the discovered source route
>    inside a Source Route option.  Similarly, when a target router
>    discovers a bidirectional source route, it caches the route for its
>    own use and then sends a DRO message to the origin router carrying
>    the discovered route inside a Source Route option.  Rather than
>    immediately sending a discovered route back to the origin router, a
>    target router MAY optionally send one DRO message after discovering
>    multiple forward/bidirectional source routes with the sent DRO
>    carrying the discovered source routes (in multiple Source Route
>    options).
> JP> Note that the algorithm for "best route" selection is outside  
> the scope
> of this document, so does the use of a timer on the target side to  
> determine
> how much time to wait before answering, ...
>     A DRO message carrying one or more Source Route options MUST  
> have its   D field set to 0x00 (for forward routes) or 0x02 (for  
> bidirectional   routes).  The S flag MUST be set to 1 and the N  
> field MUST indicate   the number of Source Route options in the  
> message.  A Source Route   option MAY immediately be followed by a  
> Metric Container option that   carries the aggregated
> JP> or recorded
> values of the routing metrics for this source
>    route.  The target router may send this DRO message to the origin
>    router in any fashion it desires including the options listed in
>    Section 6.2.
>
> 6.4.  Establishing Hop-by-hop Routes Via DRO
>
>    In order to establish a hop-by-hop route, the target router sends a
>    DRO message along the reverse of the discovered route (via a Type 4
>    Routing Header specified in [I-D.hui-6man-rpl-routing-header]).   
> The
>    D field of the message is set to convey the route's direction
>    (forward/backward/bidirectional) and the S flag MUST be clear
>    (indicating hop-by-hop).  The N field MUST be set to 1.  Such a DRO
>    MUST NOT contain any option.
>
>    A router receiving such a DRO message SHOULD establish hop-by-hop
>    state in the right direction corresponding to the route carried in
>    the Type 4 Routing Header of the DRO message.  If a router does not
>    establish such state, it MUST drop the DRO message.  Otherwise, it
>    MUST forward the DRO message along the source route contained in  
> Type
>    4 Routing Header of the received message.
>
> JP> Any error log if it does not ? (optional) ICMP sent to the  
> target node?
>    A router SHOULD associate the hop-by-hop routing state, thus
>    established, with the objective function and metrics used for route
>    discovery.
>
>
>
>
>
>
>
> Goyal, et al.           Expires December 16, 2010              [Page  
> 17]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
> JP> New section to indicate how to clean-up the temporary DAG ?
> 7.  Security Considerations
>
>    TBA
>
>
> 8.  IANA Considerations
>
>    TBA
>
>
> 9.  Authors and Contributors
>
>    In addition to the editor, the authors of this document include the
>    following individuals (listed in alphabetical order).
>
>    Anders Brandt, Sigma Designs, Emdrupvej 26A, 1., Copenhagen,  
> Dk-2100,
>    Denmark.  Phone: [phone]; Email: [e-mail]
>
>    Robert Cragie, Gridmerge Ltd, 89 Greenfield Crescent, Wakefieldm  
> WF4
>    4WA, UK.  Phone: [phone]; Email: [e-mail]
>
>    Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA.   
> Phone:
>    [phone]; Email:[e-mail]
>
>    Charles Perkins, Tellabs Inc., USA.  Email:[e-mail]
>
>    Authors gratefully acknowledge the contributions of Richard Kelsey
>    and Zach Shelby in the development of this document.
>
>
> 10.  References
>
> 10.1.  Normative References
>
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>
> 10.2.  Informative References
>
>    [I-D.brandt-roll-rpl-applicability-home-building]
>               Brandt, A., Baccelli, E., and R. Cragie, "Applicability
>               Statement: The use of RPL in Building and Home
>               Environments",
>               draft-brandt-roll-rpl-applicability-home-building-00  
> (work
>               in progress), April 2010.
>
>    [I-D.hui-6man-rpl-routing-header]
>               Hui, J., Vasseur, J., and D. Culler, "A Source Routing
>
>
>
> Goyal, et al.           Expires December 16, 2010              [Page  
> 18]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
>               Header for RPL", draft-hui-6man-rpl-routing-header-00
>               (work in progress), May 2010.
>
>    [I-D.ietf-roll-building-routing-reqs]
>               Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
>               "Building Automation Routing Requirements in Low Power  
> and
>               Lossy Networks", draft-ietf-roll-building-routing- 
> reqs-09
>               (work in progress), January 2010.
>
>    [I-D.ietf-roll-of0]
>               Thubert, P., "RPL Objective Function 0",
>               draft-ietf-roll-of0-02 (work in progress), June 2010.
>
>    [I-D.ietf-roll-routing-metrics]
>               Vasseur, J., Kim, M., Networks, D., and H. Chong,  
> "Routing
>               Metrics used for Path Calculation in Low Power and Lossy
>               Networks", draft-ietf-roll-routing-metrics-07 (work in
>               progress), June 2010.
>
>    [I-D.ietf-roll-rpl]
>               Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
>               Protocol for Low power and Lossy Networks",
>               draft-ietf-roll-rpl-09 (work in progress), June 2010.
>
>    [I-D.ietf-roll-terminology]
>               Vasseur, J., "Terminology in Low power And Lossy
>               Networks", draft-ietf-roll-terminology-03 (work in
>               progress), March 2010.
>
>    [I-D.thubert-6man-reverse-routing-header]
>               Thubert, P., "Reverse Routing Header",
>               draft-thubert-6man-reverse-routing-header-00 (work in
>               progress), June 2010.
>
>    [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
>               Routing Requirements in Low-Power and Lossy Networks",
>               RFC 5826, April 2010.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Goyal, et al.           Expires December 16, 2010              [Page  
> 19]
> 
> Internet-Draft          draft-dt-roll-p2p-rpl-01               June  
> 2010
>
>
> Authors' Addresses
>
>    Mukul Goyal (editor)
>    University of Wisconsin Milwaukee
>    3200 N Cramer St
>    Milwaukee, WI  53211
>    USA
>
>    Phone: [phone]
>    Email: [e-mail]
>
>
>    Emmanuel Baccelli (editor)
>    INRIA
>
>    Phone: [phone]
>    Email: [e-mail]
>    URI:   http://www.emmanuelbaccelli.org/
>
>
>    P2P Team
>
> JP> Remove P2P Team unless you list the people.
>  Goyal, et al.           Expires December 16, 2010               
> [Page 20] 
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll