Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-00

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Apr 2009 09:30:59 +0200

Hi Phil:

This is a neat thing to consider adding. What I fail to understand is
the relationship with the text you mention. 

The text is about building the tree that sets the reference structure
though it might not be used a lot for forwarding (forwarding metrics are
used).

Specifically, that part of the text is about switching the default
routing topology and is designed to make the merge of 2 large topologies
smoother. The tree hop timer makes it so that when 2 trees collide, the
merge spreads like a wave from the collision point into the tree that is
being absorbed starting as high in the absorbing tree as possible.

CC'ing the list since the topic might interest a larger community.

Pascal

>-----Original Message-----
>From: Philip Levis [mailto:[email-masked]]
>Sent: mardi 31 mars 2009 23:14
>To: Pascal Thubert (pthubert)
>Subject: Re: [Roll] FW: New Version Notification for
draft-thubert-roll-fundamentals-00
>
>OK, I skimmed the draft.
>
>The issue is this:
>
>"A LLN Router may move from its current tree into any different
>        tree at any time and whatever the depth it reaches in the new
>        tree but, before it can do so, it may have to wait for a Tree
>Hop
>        Timer to elapse."
>
>This idea of sequence numbering based on a timer ignores the possibly
>highly dynamic nature of wireless communication. Instead, what you see
>LLN protocols doing today is putting some topology information into
>the datapath in order to detect loops. In particular, a data packet
>contains the transmitter's believed hop count (or some other
>gradient). If you're asked to forward a data packet whose hop count is
><= your own, then you think there might be a loop and try to repair
>the problem.
>
>This approach, using the datapath to validate the topology, allows
>protocols to quickly adapt without imposing a large overhead.
>
>Phil
>
>
>On Mar 31, 2009, at 2:05 PM, Pascal Thubert (pthubert) wrote:
>
>> Dear Rollers,
>>
>> This is to announce that we just posted a draft that details the
>> approach I proposed in the broad lines at the ROLL WG meeting in SFO
>> last week:
>>
>>
http://www.ietf.org/internet-drafts/draft-thubert-roll-fundamentals-00.t
xt
>>
>> The authors expect to provide a refined refresher sometime soon but
>> the 00 already provides a rather clear view on our approach.
>>
>> Comments appreciated as usual,
>>
>> Pascal
>>
>> -----Original Message-----
>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>> Sent: mardi 31 mars 2009 23:00
>> To: Pascal Thubert (pthubert)
>> Cc: [email-masked]; [email-masked];
[email-masked]
>> Subject: New Version Notification for draft-thubert-roll-
>> fundamentals-00
>>
>>
>> A new version of I-D, draft-thubert-roll-fundamentals-00.txt has
>> been successfuly submitted by Pascal Thubert and posted to the IETF
>> repository.
>>
>> Filename:	 draft-thubert-roll-fundamentals
>> Revision:	 00
>> Title:		 LLN Routing Fundamentals
>> Creation_date:	 2009-03-31
>> WG ID:		 Independent Submission
>> Number_of_pages: 33
>>
>> Abstract:
>> This document describes a basic set of fundamental mechanisms for
>> routing on a Low-power and Lossy Network (LLN).  It does not intend
>> to specify a full-blown protocol.  It is rather offered as a basis to
>> support the discussion while designing the ROLL protocol.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>> _______________________________________________
>> Roll mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/roll

---

From: Zach Shelby <[email-masked]>
Date: Wed, 01 Apr 2009 10:58:43 +0300

Hi,

I believe Phil, you are referring to piggybacking a metric (or depth) on 
data packets as used in e.g. the TinyOS CTP protocol?

With regard to ROLL this can be thought of as an alternative method for 
carrying tree discovery information as a hop-by-hop option with data in 
addition to ND traffic. What you are saying is that this can be used to 
detect loops or better default routers faster. In general I agree that 
this can be useful in highly dynamic networks.

However a timer is still needed even in that case. When a problem is 
detected (using ND or data piggybacked info) and a node needs to change 
its default router there should still be a timer to make tree collision 
smoother. This timer may be very, very small as appropriate for dynamic 
networks, and can be set for the whole LLN in the TIO option.

So these things are orthogonal. Definitely needs to be discussed in -01 
of this draft.

- Zach

-- 
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Apr 2009 10:46:35 +0200

IPR related to ROLL Fundamentals?

Pascal, what is the IPR status of the Tree Discovery described in
draft-thubert-roll-fundamentals-00.txt section 2.1. Overview "LLN Tree
Discovery..." and e.g. the tree-based topologies for mobile adhoc
networks described in various IPRs, among which e.g.

"DIRECTED ACYCLIC GRAPH DISCOVERY AND NETWORK PREFIX INFORMATION
DISTRIBUTION RELATIVE TO A CLUSTERHEAD IN AN AD HOC MOBILE NETWORK"
EP1897295

"ARRANGEMENT FOR PROVIDING OPTIMIZED CONNECTIONS BETWEEN PEER ROUTERS IN
A TREE-BASED AD HOC MOBILE NETWORK"
EP1867104

Have the Chairs received any notification about potential IPR with
respect to Tree Discovery document?

It is good to have this settled right from the start.

Alex

Pascal Thubert (pthubert) a écrit :
> http://www.ietf.org/internet-drafts/draft-thubert-roll-fundamentals-00.txt
> 
> 
> -----Original Message----- From: IETF I-D Submission Tool
> [mailto:[email-masked]] Sent: mardi 31 mars 2009 23:00 To:
> Pascal Thubert (pthubert) Cc: [email-masked];
> [email-masked]; [email-masked] Subject: New
> Version Notification for draft-thubert-roll-fundamentals-00
> 
> 
> A new version of I-D, draft-thubert-roll-fundamentals-00.txt has been
> successfuly submitted by Pascal Thubert and posted to the IETF
> repository.
> 
> Filename:	 draft-thubert-roll-fundamentals Revision:	 00 Title:		 LLN
> Routing Fundamentals Creation_date:	 2009-03-31 WG ID:		 Independent
> Submission Number_of_pages: 33
> 
> Abstract: This document describes a basic set of fundamental
> mechanisms for routing on a Low-power and Lossy Network (LLN).  It
> does not intend to specify a full-blown protocol.  It is rather
> offered as a basis to support the discussion while designing the ROLL
> protocol.
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________ Roll mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Apr 2009 11:00:54 +0200

Hi Richard:

>If a Router receives a TIO with a more recent sequence number
>than previously seen, isn't it safe for it to pick the sender
>of the TIO as a new parent regardless of the Router's current
>depth?  The sender's path back to the root must all have
>sequence numbers more recent than the Router's and thus
>cannot include it.  Allowing this could improve the speed
>with which the network reacts to topography changes.

Great point. The case might effectively happen and your proposal seems
safe. In particular if the parent is dead and we do not know it yet,
some time might pass during which we actually receive such TIOs from
deeper with a newer sequence.

At the moment the text ignores TIOs from deeper. In fact, we could store
them if the sequence is newer, and that could allow a node to move
deeper within the tree without the freezing transition. That
optimization could be used if the node memory permits but is not
necessary for the operation. I do like it.

>Is it necessary to have separate mechanisms for disseminating
>upwards and downwards unicast routes?  It looks to me as if
>the main reason for needing both is that currently all trees
>have a border router as the root.  If other destinations were
>allowed to be roots then all routes could be upwards and
>there would be no need for route dissemination.  Having only
>one mechanism would be simpler.

But would cost a lot, lot more signaling. 

The spec does not prevent all nodes to keep building their own tree, a
tree being a topology. We can add some text that the node could install
a route towards the treeID (address or prefix in case of a backbone) via
the parent. So in a given deployment you could do just what you say. But
the spec does not require all nodes to participate to all those
topologies either. 

Sending the RIO up the tree costs a lot less in terms of traffic and
states, but you only get what you paid for, source/sink routes along the
tree, which is what the req drafts ask us to optimize for in the first
place.

Finally you can use only one tree and source routing on the way back.
The cool thing is that when you have RIO basde states that RPF match the
source path, then you do not need to add to the record route so the size
of the source route information can be dynamically adjusted depending on
whether nodes support RIO or not.

>
>Multicasts would still need to be handled somehow, but
>perhaps using a multicast-specific protocol would have its
>own benefits.

Could be. We propose one way that has a very minimum overhead since the
signaling is merged with the unicast signaling and benefits from the
tree that's already there for source/sink. 

We'll probably submit a 01 real soon including some text to include your
first proposal. But then the DT work will start and I'll have to focus
on that.

Thanks a bunch, Richard, for your excellent remarks.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Apr 2009 18:02:15 +0200

Hi Richard,

Richard> 
For control traffic, which version is less costly depends on
the details.  For example, if there are few enough unique
destinations** that all of the tree data can be piggy-backed
on the router advertisements, then just using the trees has
less overhead because it doesn't require route
dissemination.  As the number of unique destinations rises,
the only-tree version does require more control traffic.

Pascal>

RIO is optional and I still think the RIO makes sense is many
destinations are to be reached and mostly from the sink.

Only destinations that need to be reached from the sink  need to send
RIOs.  So same thing here. 

But a tree rooted at a destination would be propagated to a lot more
nodes then just the parents up the tree. 

So more control is what I'm saying. ROI for control is another
discussion though.

For data traffic the all-tree version requires much less
signalling, as all messages take an optimized path, rather
than just messages to or from the border router.  If the
average depth of a tree is D, then the all-tree version
averages D hops per message.  Using route dissemination the
average is D hops per message to or from the border router
and 2D hops for other messages.  Worse, the extra hops are
not distributed evenly.  The border router and its children
pay most of the cost.

If there's a tree routed at the destination then you get an optimized
path from all sources in the tree that's true.

You get value for your extra control as long as there is traffic that
justifies it. So it's fair to say that for very special destinations it
might be worth spawning a tree if many nodes in the LLN need to reach
that very special destination. If none or only a few need so then it
might be better to use a more on-demand mechanism such as offline or
aodv (we have text about that already).

Given that there is going to be a lot more data traffic than
control traffic, using only trees will be considerably more
efficient if there is a significant amount of traffic
between non-border-router nodes.

Any to any is not what the requirements ask to optimize for. But I agree
with you that it can be worth spawning additional topologies. There is
text for that in the second half of the document but nothing for special
(worthy) destinations so I can add some text there. 

Would that be what you're asking for?

Pascal

From: Richard Kelsey [mailto:[email-masked]] 
Sent: vendredi 3 avril 2009 17:40
To: Richard Kelsey; Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: RE: [Roll] FW: New Version Notification
fordraft-thubert-roll-fundamentals-00

[Re-sent due to an email problem which prevented this from getting
to the ROLL list.  -Richard Kelsey]

   Date: Fri, 3 Apr 2009 11:00:54 +0200
   From: "Pascal Thubert (pthubert)" <[email-masked]>

It seems to me that it would cost a lot less signalling.

For control traffic, which version is less costly depends on
the details.  For example, if there are few enough unique
destinations** that all of the tree data can be piggy-backed
on the router advertisements, then just using the trees has
less overhead because it doesn't require route
dissemination.  As the number of unique destinations rises,
the only-tree version does require more control traffic.

For data traffic the all-tree version requires much less
signalling, as all messages take an optimized path, rather
than just messages to or from the border router.  If the
average depth of a tree is D, then the all-tree version
averages D hops per message.  Using route dissemination the
average is D hops per message to or from the border router
and 2D hops for other messages.  Worse, the extra hops are
not distributed evenly.  The border router and its children
pay most of the cost.

Given that there is going to be a lot more data traffic than
control traffic, using only trees will be considerably more
efficient if there is a significant amount of traffic
between non-border-router nodes.

                                       -Richard Kelsey

** I have not found a definition of 'unique destination'.
The routing protocol survey makes it clear that most nodes
are not unique destinations, but doesn't define the term.

----------------
This message and the information it contains are the proprietary
and confidential property of Ember Corporation and may be privileged.
If you are not the intended recipient, please do not read, copy,
disclose or distribute its contents to any party, and notify the
sender immediately.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 6 Apr 2009 09:39:03 +0200

Hi Richard:

Richard>

Pascal, while I agree with you in general, I don't see how
this fits the requirements.  As spelled out in the protocol
survey document, routing state should be bounded by O(D),

Pascal> 

The difference we are talking about is whether a destination in the LLN
needs to be reachable from all other nodes in the LLN or only/mostly
from the sink and whatever's behind the sink. Whether you do new trees
or RIO, only the destinations that need to be reachable need to
advertise themselves so you get your o (or O or Omega or ?) of D. It's
more a matter of whether an assembly is overkill or insufficient for a
given use case.

RIO only advertise along a unicast path towards the sink that's already
there as part of the tree, so that's the minimum control.

Building a tree to LLN destinations would require maintaining and
flooding new topological information and metrics to all and that's a lot
more, one thing we do not seem to agree upon but that's fine.

The intermediate approach to build on demand constrained routes is also
discussed in the draft. 

The question is whether one of those 3 approaches fits it all and I
don't think so. 

So we'll have to sort out what's mandatory and what's optional, based on
common value I guess.

Thus there is a set of special (worthy) destinations, which
get special consideration.  These clearly include any border
routers, and may include other routers.  For example, the
industrial requirements document says:

   Most of the traffic over the LLN is publish/subscribe of
   sensor data from the field device towards a sink that can
   be a backbone router, a gateway, or a controller/manager.

The controller/managers seem likely candidates for special
destinations.

For all examples I know of, those devices are either the sinks or
attached to a backbone via the sink. 

So the default route is enough to reach these devices and TD/RIO fits
the bill.

I would like multiple trees to be explictly
supported by the text, including trees that are not rooted
at border routers.  As it stands, while not explicitly
prohibited, the text is somewhat ambiguous as to whether
additional trees are allowed and exactly how they should
work.

Will do. There is text in multiple topologies about that but after this
discussion, it is clear that some addition would be required. . Note
that we're getting close a classical DV if we follow that path too far
and I do not think that this is the general direction we're taking.

I need to make sure that the text is clear that the default route is
only installed when the G bit is set, that there can be only one tree
with the G bit set (unless some Multi topology routing is in place). I
can also indicate that nodes might belong to multiple non-g trees; and
that nodes install a route to the tree ID over the corresponding tree.

I plan to submit by Wednesday. If you have a suggestion for text to
add/modify/remove you're certainly welcome J

Best,

Pascal

From: Richard Kelsey [mailto:[email-masked]] 
Sent: vendredi 3 avril 2009 21:11
To: Pascal Thubert (pthubert)
Cc: [email-masked]; [email-masked]
Subject: RE: [Roll] FW: New Version Notification
fordraft-thubert-roll-fundamentals-00

   Date: Fri, 3 Apr 2009 18:02:15 +0200
   From: "Pascal Thubert (pthubert)" <[email-masked]>

      Date: Fri, 3 Apr 2009 11:40:15 -0400
      From: "Richard Kelsey" <[email-masked]>

Pascal, while I agree with you in general, I don't see how
this fits the requirements.  As spelled out in the protocol
survey document, routing state should be bounded by O(D),
where D is the number of "unique destinations".  This term
is not defined, but the document states that it scales at
less than O(N), where N is the number of nodes.

Thus there is a set of special (worthy) destinations, which
get special consideration.  These clearly include any border
routers, and may include other routers.  For example, the
industrial requirements document says:

   Most of the traffic over the LLN is publish/subscribe of
   sensor data from the field device towards a sink that can
   be a backbone router, a gateway, or a controller/manager.

The controller/managers seem likely candidates for special
destinations.

Given the O(D) bound on routing state, only a small subset
of routers can be destinations for RIO routes.  My point is
that that same subset of routers could just as well be roots
of trees.  This wouldn't make sense if D were proportional
to N, but the requirements make it clear that this isn't the
case.

The O(D) bound means that the situation you mention, where
there are many destinations to be reached and mostly from
the sink, needs to be handled through some other means,
presumably by using source routing.

   But a tree rooted at a destination would be propagated to
   a lot more nodes then just the parents up the tree.

Yes, but that doesn't mean that it takes a lot more effort.
A single message from A to B can propogate information about
as many trees as will fit in the message.  Seeing as how at
least one tree needs to be maintained, no additional
messages may be needed at all, depending on the number of
unique/special destinations.

   Any to any is not what the requirements ask to optimize
   for.  But I agree with you that it can be worth spawning
   additional topologies. There is text for that in the
   second half of the document but nothing for special
   (worthy) destinations so I can add some text there.

Not really.  I would like multiple trees to be explictly
supported by the text, including trees that are not rooted
at border routers.  As it stands, while not explicitly
prohibited, the text is somewhat ambiguous as to whether
additional trees are allowed and exactly how they should
work.

Because I think that using multiple trees is a better fit
with the requirements than using RIO, I want to raise the
possibility of removing the RIO section.  While RIO is
optional, having it does make the document more complicated.
I fully understand that you may not agree with me on this.

Thanks for listening.

                                -Richard Kelsey
----------------

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Apr 2009 17:53:35 +0200

Hi Richard:

I'm working on changes to accommodate multiple trees. The trouble I have
is for the default route.
Whether the tree is Grounded or not, there can be only one tree used for
default route, unless you enter MTR and flow labels. But the default is
useful even if the tree is Floating. 

The way I see it, we end up with a new bit, "default" and a node can
only belong to one default tree. It'd better select a Grounded one. If a
node belongs to 2 trees where the parent advertise default, the router
will have to abandon the default on one of them as it propagates the
TIO.

I think we can easily describe that but I'm unsure whether that goes in
the main text or in 6.5.

What do you think?

Pascal

>From: Richard Kelsey [mailto:[email-masked]]
>Sent: lundi 6 avril 2009 20:17
>Subject: Re: [Roll] FW: New Version Notification
>
>[Resending in the hopes that my mailing list problems
>have finally been solved.  Pascal, I apologize for the
>duplicates.  -RK]
>
>
>   Date: Mon, 6 Apr 2009 09:39:03 +0200
>   The difference we are talking about is whether a
>   destination in the LLN needs to be reachable from all
>   other nodes in the LLN or only/mostly from the sink and
>   whatever's behind the sink.
>
>I thought we were disagreeing about the requirement for
>routing state, which is not allowed to scale linearly with
>the size of the network or with the size a node's
>neighborhood.  It seems to me that to meet this requirement
>the RIO state can only contain information about a small
>subset of the nodes in a network.
>
>This is not the case for smart energy.  An electric meter is
>a data sink and has a backhaul connection, but it is very
>unlikely that a utility will allow non-utility traffic onto
>its backhaul network.  The meter won't act as a border router.
>
>I'll try to get you something today.
>
>                                    -Richard Kelsey
>
>----------------

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 7 Apr 2009 12:17:27 -0400

Date: Tue, 7 Apr 2009 17:53:35 +0200
   From: "Pascal Thubert (pthubert)" <[email-masked]>

   I'm working on changes to accommodate multiple trees. The trouble I
   have is for the default route.  Whether the tree is Grounded or
   not, there can be only one tree used for default route, unless you
   enter MTR and flow labels. But the default is useful even if the
   tree is Floating.

Makes sense.

   The way I see it, we end up with a new bit, "default" and a node
   can only belong to one default tree. It'd better select a Grounded
   one. If a node belongs to 2 trees where the parent advertise
   default, the router will have to abandon the default on one of them
   as it propagates the TIO.

   I think we can easily describe that but I'm unsure whether that
   goes in the main text or in 6.5.

   What do you think?

Moving between trees is discussed in item 6 in 2.1, so I
think it needs to mentioned there.  Perhaps that item should
be moved to 6.5?
                                    -Richard Kelsey

----------------

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 9 Apr 2009 09:58:56 +0200

Hi Pascal,

For multiple trees (DAGs) and efficient routing without default routes / MTR
/ flow labels, you could check Border Router Discovery Protocol and related
BRDP based routing:
http://tools.ietf.org/html/draft-boot-autoconf-brdp
http://tools.ietf.org/html/draft-boot-brdp-based-routing

BRDP provides DAGs to attachment points, called Border Router. There is no
TIO (no Tree) but BRIO (Border Router).

The sub-DAG tree identifier is the Border Router address. Nodes can use
source addresses based on advertized BR prefixes. This enables using these
addresses as locators. 

BRDP / BRDP based routing use a routing protocol for reachability to the
backbone: next-hop to the Border Router. BRDP has its history in MANET /
Autoconf. It is easy to add paths to the backbone, learned from BRDP (path
to BR) or towards nodes (explicit messages, routing header and / or
snooping). Routing to the backbone uses the source addresses, when
destination is not in routing table. The requirement is that nexthop towards
BR is in the routing table.

Check also loop prevention, I use this for building DAGs for BRIO
distribution. It can be reused for loop-free routing. BRDP uses hop-count
and metrics, with seq.no. and thresholds for loop prevention.

For now, BRDP is IPv6. I planned to add IPv4 support in next version.
Address generation is not possible (possibility for duplicates to large for
skipping DAD). Routing v4 over the DAGs (including SA based routing to
backbone) is no problem.

I have some ideas on using BRIO information for SA selection. Each node has
information on the best path to the backbone (or Internet default free
zone), and a corresponding SA should be used for nodes not listed in the
routing table.

Regards, Teco

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens Richard
|Kelsey
|Verzonden: dinsdag 7 april 2009 18:17
|Aan: [email-masked]
|CC: [email-masked]
|Onderwerp: Re: [Roll] FW: New Version Notification fordraft-thubert-
|roll-fundamentals-00
|
|   Date: Tue, 7 Apr 2009 17:53:35 +0200
|   From: "Pascal Thubert (pthubert)" <[email-masked]>
|
|   I'm working on changes to accommodate multiple trees. The trouble I
|   have is for the default route.  Whether the tree is Grounded or
|   not, there can be only one tree used for default route, unless you
|   enter MTR and flow labels. But the default is useful even if the
|   tree is Floating.
|
|Makes sense.
|
|   The way I see it, we end up with a new bit, "default" and a node
|   can only belong to one default tree. It'd better select a Grounded
|   one. If a node belongs to 2 trees where the parent advertise
|   default, the router will have to abandon the default on one of them
|   as it propagates the TIO.
|
|   I think we can easily describe that but I'm unsure whether that
|   goes in the main text or in 6.5.
|
|   What do you think?
|
|Moving between trees is discussed in item 6 in 2.1, so I
|think it needs to mentioned there.  Perhaps that item should
|be moved to 6.5?
|                                    -Richard Kelsey
|
|----------------
|This message and the information it contains are the proprietary
|and confidential property of Ember Corporation and may be privileged.
|If you are not the intended recipient, please do not read, copy,
|disclose or distribute its contents to any party, and notify the
|sender immediately.
|_______________________________________________
|Roll mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Apr 2009 14:09:41 +0200

Hi Teco,

Please note that the tree formation in draft 01 incorporates your
suggestion (Richard had the same) about allowing to attach to a deeper
parent if the sequence is newer :) 

>TIO (no Tree) but BRIO (Border Router).

Makes sense. Note that for 6LoWPAN backbone, the backbone owns the
prefix and is the virtual root of the aggregated tree.

>source addresses based on advertized BR prefixes. This enables using
these

Added something similar in 01 from (again) Richard's suggestion

>BR is in the routing table.

As you know I like explicit messages but all 3 types of methods to route
towards node seem to have their own support. What's not totally clear to
me in the BRDP draft is the link / dependence to a MANET routing
protocol. Is there any? I mean when you say MANET router could we try
LLN router and get the same result?
 
>and metrics, with seq.no. and thresholds for loop prevention.
Will do. You know that I do not like using UPM for loop prevention and I
prefer the depth.

The depth is a guaranteed Esperanto whereas the metric might be hardly
comparable over heterogeneous hops.

Also the roll-fundamentals draft enables forwarding along the best
metric while keeping the tree intact for a while, so we manage to get
similar benefit in terms of path metrics with a better topological
stability while using common sense depth as the base loop avoidance
method.

>zone), and a corresponding SA should be used for nodes not listed in
the
Makes sense

Cheers,

Pascal

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 9 Apr 2009 21:42:19 +0200

Hi Pascal,

|>BRDP / BRDP based routing use a routing protocol for reachability to
|the
|>backbone: next-hop to the Border Router. BRDP has its history in MANET
|/
|>Autoconf. It is easy to add paths to the backbone, learned from BRDP
|(path
|>to BR) or towards nodes (explicit messages, routing header and / or
|>snooping). Routing to the backbone uses the source addresses, when
|>destination is not in routing table. The requirement is that nexthop
|towards
|>BR is in the routing table.
|
|As you know I like explicit messages but all 3 types of methods to route
|towards node seem to have their own support. What's not totally clear to
|me in the BRDP draft is the link / dependence to a MANET routing
|protocol. Is there any? I mean when you say MANET router could we try
|LLN router and get the same result?

There is no dependency. BRDP does not provide paths, that is up to routing.
But the upstream node advertizing the BRIO could be used as next hop to that
BR. Maybe we need a flag for this, indicating all nodes to the BR have the
next hop. Or just define this as mandatory.

|>Check also loop prevention, I use this for building DAGs for BRIO
|>distribution. It can be reused for loop-free routing. BRDP uses
|hop-count
|>and metrics, with seq.no. and thresholds for loop prevention.
|Will do. You know that I do not like using UPM for loop prevention and I
|prefer the depth.
|
|The depth is a guaranteed Esperanto whereas the metric might be hardly
|comparable over heterogeneous hops.

The metric is for the path, not for the link. Lower metric as the threshold
means guaranteed loop-free. No difference with depth.
You know I dislike the hop-count protocols :-) Anyway, I use both. This
beats your proposal.

Teco.