Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Jan 2011 15:46:44 +0100

Hi Skip

"this" is  a bit vague. This discussion was about 1 DAG vs. 2 DAGs vs. n
DAGs. My argument is that 1 DAG for asymmetrical links will be more
complex and less efficient than 2, whereas n DAGs address a different
problem where all n nodes are destinations for traffic from the other
nodes.

WRTthe problem of the first hop link metric that you raise here, we
enter  another discussion which is not dependent on how many DAGs we
decide to build. In a general manner, a DIO indicates what its sender
sees and does not depend on the receiver. Thus, the specific information
about the link to the receiver is not present in the L3 information.
Yes, we discussed that as well, and yes, we need information about the
link that had to be obtained by some link specific method.

What I gather from this discussion is that:
1) the metrics draft could have a field indicating if a given metric is
up, down or bidirectional
2) the metrics draft could have words about the first hop link metrics,
what can be expected from RPL and what is needed from more L2 triggers.

Happy New Year!

Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: Skip Ashton [mailto:[email-masked]]
> Sent: Saturday, December 25, 2010 4:12 AM
> To: Pascal Thubert (pthubert); Don Sturek; Yoav Ben-Yehezkel
> Cc: ROLL WG
> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt
> 
> We have discussed this before and it does not work properly.  The DAG
> represents the metric back to the root and in this case we need to
know the
> link quality between two adjacent devices.  Knowing the aggregate cost
to
> the root does not give you enough information on if this link is
suitable.
> 
> Skip
> 
> 
> On 12/24/10 7:14 AM, "Pascal Thubert (pthubert)" <[email-masked]>
> wrote:
> 
> > Hi Don:
> >
> > My proposal is 2 set up 2 DAGS, one DIO only for upward traffic, and
> > one
> > DIO+DAO for downward traffic.
> > The first DAG would be established using metrics that describe the
> > upward direction of the link, while the other would be established
> > with downwards metrics.
> > The resulting topology is roughly equivalent to having a single DAG
> > with an OF that could read metrics for both directions. In any case,
> > you end up with 2 sets of parents.
> >
> > From your response, it is quite probable that you misunderstood that
> > proposal, and quite probable that you interpreted my words as a DAG
> > per destination.
> > If so, please reconsider...
> >
> > Merry Xmas yall!
> >
> > Pascal
> > http://www.xtranormal.com/watch/7011357/
> >
> >
> >> -----Original Message-----
> >> From: Don Sturek [mailto:[email-masked]]
> >> Sent: Saturday, December 18, 2010 4:47 PM
> >> To: Yoav Ben-Yehezkel
> >> Cc: Pascal Thubert (pthubert); ROLL WG
> >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt
> >>
> >> Hi yoav,
> >>
> >> True, however then you need some OF to handle asymmetric links.   I
> > think
> >> pascal proposes separate DAGs to handle that.
> >>
> >> Don
> >>
> >> Sent from my iPad
> >>
> >> On Dec 18, 2010, at 6:25 AM, Yoav Ben-Yehezkel <[email-masked]>
> > wrote:
> >>
> >>> My understanding WRT a solution to the asymmetric links was that
> > that
> >>> RPL can settle with just one DAG by use of DAO messages that
allows
> > a
> >>> bi-directional downwards route creation.
> >>>
> >>> Can that be considered a legit solution to asymmetric links a
well?
> >>>
> >>> Regards,
> >>> Yoav
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: [email-masked] [mailto:[email-masked]] On
Behalf
> >>> Of Don Sturek
> >>> Sent: Saturday, December 18, 2010 4:19 PM
> >>> To: Pascal Thubert (pthubert)
> >>> Cc: ROLL WG
> >>> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt
> >>>
> >>> Hi pascal,
> >>>
> >>> What you wrote below in the last paragraph is wrong.  In fact, it
is
> >>> not 2 Dags that must be created but an order n number of Dags to
> > cover
> >>> any of the return paths to any of the nodes which could have
> > generated a
> >> request.
> >>>
> >>> Don
> >>>
> >>>
> >>> Sent from my iPad
> >>>
> >>> On Dec 18, 2010, at 4:38 AM, "Pascal Thubert (pthubert)"
> >>> <[email-masked]> wrote:
> >>>
> >>>> Again you've got your logic reversed. RPL was designed for LLNs,
> > does
> >>>> not mean that it has to be limited to anything as long as it
works
> >>>> fine there too.
> >>>>
> >>>> Second you'll find more and more low power  / constrained devices
> > in
> >>>> both wired and wireless space, because as a trend we are
> > controlling
> >>>> more and wasting less.
> >>>>
> >>>> Third, RPL by construction is a good routing protocol for certain
> >>>> topologies that are inherently based on hub and spoke. I listed a
> >>>> number in this thread already. Think dynamic overlays like VPNs
> > for one.
> >>>>
> >>>> Finally, OF0 may apply to asymmetric links if people are willing
to
> >>>> run
> >>>> 2 DAGs, one for the traffic up and one for the traffic down.
Mixing
> >>>> problems is a source of confusion.
> >>>>
> >>>> Pascal
> >>>> http://www.xtranormal.com/watch/7011357/
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Philip Levis [mailto:[email-masked]]
> >>>>> Sent: Friday, December 17, 2010 10:32 PM
> >>>>> To: Pascal Thubert (pthubert)
> >>>>> Cc: Don Sturek; ROLL WG
> >>>>> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt
> >>>>>
> >>>>>
> >>>>> On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote:
> >>>>>
> >>>>>> Don:
> >>>>>>
> >>>>>> I listed a number of examples and none of them is PLC actually.
> >>>>>> RPL is a routing protocol. There is no point in preventing its
> >>>>>> usage
> >>>> on wired
> >>>>> lines.
> >>>>>>
> >>>>>
> >>>>> https://datatracker.ietf.org/wg/roll/charter/:
> >>>>>
> >>>>> The Working Group is focused on routing issues for LLN.
> >>>>>
> >>>>> Can you give me an example of a wired network that's an LLN
where
> >>>>> OF0
> >>>> is
> >>>>> useful?
> >>>>>
> >>>>> Phil
> >>> _______________________________________________
> >>> Roll mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/roll
> > _______________________________________________
> > Roll mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/roll