Subject: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of

From: "roll issue tracker" <[email-masked]>
Date: Tue, 05 Oct 2010 14:48:24 -0000

#80: RPL across Multiple PHY/MAC: comment received during WG Last Call of
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |       Owner:  jpv@…        
     Type:  defect           |      Status:  new          
 Priority:  major            |   Milestone:               
Component:  routing-metrics  |     Version:               
 Severity:  In WG Last Call  |    Keywords:               
-----------------------------+----------------------------------------------
 Here is the original email (see archives for the details):

 Email sent September 19:

 "[my summary: it is worth clarifying (1) whether RPL runs in a single
 PHY or multiple PHY network, and (2) whether metrics for RPL should be
 understood in RPL network only or more universal like across the
 Internet.  There are also points about whether Rx link energy is as
 important as Tx link energy and its usability overall.]

 Hi Colin,

 It does make sense to clarify the usage model first, especially the
 assumptions of whether or not RPL runs exclusively on networks made of
 single PHY, or multiple PHYs.

 I consider IP kind of work (do we say IPv6? 'router'?) is needed only if
 we consider multiple kinds of PHYs in the same network.  Otherwise
 bridges, range extenders and other L2 tools are better appropriate than
 IP routers.

 During RPL comments we commented whether RPL draft text should say
 _only_ 802.15.4 or would it include PLC too.  I think RPL draft text
 saying _only_ 802.15.4 would make subsequent metrics and security text
 much easier.  However, it was insisted PLC should be there in the draft.
 So I am in that perspective now.

 But does that mean that RPL runs only on a network consisting of PLC
 devices, and on another network of 15.4 devices (separated by an Edge
 Router)?  Or does it mean RPL runs in a network mixing 15.4 devices
 with PLC devices each being an RPL router?

 This was never clear.

 Alex Petrescu"

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/80>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Tue, 05 Oct 2010 14:49:14 -0000

Comment(by jpv@…):

 Email from Yoav Ben-Yehezkel (September 19)

 Thanks Alex/Colin for bringing this up for discussion.

 My two cents:

 I always saw the ability to operate at multiple media as one of the
 strongest points in favor of RPL (and L3 routing protocols) over specific
 L1/2 bridging techniques.

 The smart grid will most probably need to operate using both PLC or
 wireless media for the same utility owned networks in some cases.

 Consider the typical Multiple Dwelling Unit (MDU) use case where wireless
 meters reside outside apartments in sealed cabinets, and in-home displays
 are installed inside the apartments.  RF cannot pass thick walls, so a
 selection of an L3 router via a PLC node is a natural (from the cabinet to
 the home).

 Another use case is of course to connect a wireless battery operated
 sensor (say on the ceiling) with a PLC device that needs the sensor inputs
 (such as PCTs).

 These smart-grid devices "belong" to the same utility network or
 sub-network (though using different medias sometimes)...

 RPL (or any L3 routing protocol as I understand it) supported by multiple
 PHY layers seems to me like an excellent choice for covering these use
 cases while inherently taking the routing metric into consideration when
 choosing which media is the most suitable for the next transmission to the
 final destination.

 I am seeking for WG confirmation that these use cases are covered well by
 RPL (as a route over media and link layer agnostic protocol). Otherwise, I
 think this is a significant short-coming of the protocol.

 The WG thoughts are very much appreciated.

 Best regards,
 Yoav

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/80#comment:1>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Tue, 05 Oct 2010 14:50:15 -0000

#80: RPL across Multiple PHY/MAC: comment received during WG Last Call of draft-
ietf-roll-routing-metrics-09.txt
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |       Owner:  jpv@…        
     Type:  defect           |      Status:  new          
 Priority:  major            |   Milestone:               
Component:  routing-metrics  |     Version:               
 Severity:  In WG Last Call  |    Keywords:               
-----------------------------+----------------------------------------------

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/80#comment:2>
roll <http://tools.ietf.org/wg/roll/>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Oct 2010 13:35:25 -0400

>>>>> "roll" == roll issue tracker <[email-masked]> writes:
    roll>  I am seeking for WG confirmation that these use cases are
    roll> covered well by RPL (as a route over media and link layer
    roll> agnostic protocol). Otherwise, I think this is a significant
    roll> short-coming of the protocol.

As far as I'm concerned, these scenarios were always in scope.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 6 Oct 2010 06:05:23 +0200

> As far as I'm concerned, these scenarios were always in scope.

They are (even in the charter !) but I wanted to close one ticket per item raised during WG LC.
We'll now close the tickets.

Thanks.

JP.

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Colin O'Flynn" <[email-masked]>
Date: Wed, 6 Oct 2010 09:50:43 +0100

Hello,

> As far as I'm concerned, these scenarios were always in scope.

The original issue was only about if the routing metrics would work across
multiple MAC/PHY. The issue was quickly blown out of context to become about
RPL in general, which of course will work across multiple MAC/PHY.

But it wasn't a real issue anyway, just some discussion.

Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JP
Vasseur
Sent: October 6, 2010 5:05 AM
To: Michael Richardson
Cc: [email-masked]
Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple
PHY/MAC: comment received during WG Last Call of

> As far as I'm concerned, these scenarios were always in scope.

They are (even in the charter !) but I wanted to close one ticket per item
raised during WG LC.
We'll now close the tickets.

Thanks.

JP.

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Wed, 6 Oct 2010 10:53:27 +0200

I agree with Colin
This ticket misses the essence of the real issue which Colin and Alex
discussed, as Colin clarified in one of his responses to my below concern.

Regards,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Colin O'Flynn
Sent: Wednesday, October 06, 2010 10:51 AM
To: 'JP Vasseur'; 'Michael Richardson'
Cc: [email-masked]
Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple
PHY/MAC: comment received during WG Last Call of

Hello,

The original issue was only about if the routing metrics would work across
multiple MAC/PHY. The issue was quickly blown out of context to become
about
RPL in general, which of course will work across multiple MAC/PHY.

Regards,

  -Colin

-----Original Message-----

Thanks.

JP.

>   Kyoto Plus: watch the video
<http://www.youtube.com/watch?v=kzx1ycLXQSE>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 6 Oct 2010 12:03:44 +0200

I think that the title capture the topic. I'll update and propose a resolution to close.
Cheers.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Oct 2010 15:31:02 +0200

> I think that the title capture the topic. I'll update and propose a

JP, when closing this issue, please clarify:

- every RPL message has src and dst address scoped as _link_ local,
   i.e. a single link, a single PHY/MAC.  This contradicts the multiple
   PHY/MAC perspective, because a single link can't be connecting
   interfaces using different MAC/PHY.

I am not sure I am clear...

The metric part: some metrics, such as ETX and LQL, are for a single
link and PHY/MAC, by their design.

I may be wrong but that's how I see it.

Alex

>> I agree with Colin This ticket misses the essence of the real
>> issue which Colin and Alex discussed, as Colin clarified in one of
>> his responses to my below concern.
>>
>>
>> Regards, Yoav
>>
>>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Colin O'Flynn Sent:
>> Wednesday, October 06, 2010 10:51 AM To: 'JP Vasseur'; 'Michael
>> Richardson' Cc: [email-masked] Subject: Re: [Roll] [roll]
>> routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment
>> received during WG Last Call of
>>
>> Hello,
>>
>> The original issue was only about if the routing metrics would
>> work across multiple MAC/PHY. The issue was quickly blown out of
>> context to become about RPL in general, which of course will work
>> across multiple MAC/PHY.
>>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of JP Vasseur Sent:
>> October 6, 2010 5:05 AM To: Michael Richardson Cc: [email-masked]
>> Subject: Re: [Roll] [roll] routing-metrics #80 (new): RPL across
>> Multiple PHY/MAC: comment received during WG Last Call of
>>
>>
>>>>>>>> "roll" == roll issue tracker<[email-masked]>
>>>>>>>> writes:
>>> roll>  agnostic protocol). Otherwise, I think this is a
>>> significant roll>  short-coming of the protocol.
>>>
>> They are (even in the charter !) but I wanted to close one ticket
>> per item raised during WG LC. We'll now close the tickets.
>>
>> Thanks.
>>
>> JP.
>>
>>>
>>> -- ]       He who is tired of Weird Al is tired of life! |
>> firewalls  [
>>> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON
>>> |net
>> architect[
>>> ] [email-masked] http://www.sandelman.ottawa.on.ca/
>>> |device
>> driver[
>>> _______________________________________________ Roll mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 6 Oct 2010 19:55:18 +0200

Hi Alex,

> I am not sure I am clear...

I am not clear about your question ... why is it different from all other L3
routing ?

> link and PHY/MAC, by their design.

No, they are not. LQL for example is also used by many deployed PLC (proprietary)
solutions, even if they use a different name. So LQL could be used for several types
of "lossy" links, it is not specific to a particular PHY/MAC. Same reasoning applies to 
ETX. Now, note that the metric ID does not mandate for all RPL networks to support 
all of the specified metrics of course. Further, one may decide to specify a RPL metric 
that is relevant for a specific PHY/MAC: RPL specifies what a node is supposed to 
do when it does not understand/support a metric (leaf node). This is a deployment 
issue. This is very similar to what is done with other routing protocols.

Hope that helps.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Oct 2010 23:18:13 +0200

Le 06/10/2010 19:55, JP Vasseur a écrit :
>> - every RPL message has src and dst address scoped as _link_
>> local, i.e. a single link, a single PHY/MAC.  This contradicts the
>>  multiple PHY/MAC perspective, because a single link can't be
>> connecting interfaces using different MAC/PHY.
>>
> I am not clear about your question ... why is it different from all
> other L3 routing ?

Hi JP - I see what you mean, I remember you already said that, sorry.

Yes, other routing protocosl sending their flooding messages on
link-scoped multicast addresses (RIP, OSPF) are implemented on routers
having multiple interfaces, thus possibly multiple PHY/MAC, originating
new flooding messages with another src address topologically valid
on that link.

Should I understand that RPL router doing multiple PHY/MAC has at least
two interfaces?    Should I understand that most RPL Routers have at
least two interfaces?  If so, is the phrase RPL-12 "Although there may
typically be only one interface in most application scenarios..." a
little bit wrong?

And that when receiving a DAO message on one interface RPL Router may
generate another DAO with a different link-local source address on
another interface?

Or are the DAO messages propagated without modifying the src address?

RPL-12 says "If the D flag is cleared then the source address of the
IPv6 packet MUST be the DODAGID...The DODAGID in this case will be the
reachable IPv6 address of node A" - sounds as if there is _only_ one
address of node A?  But a node with multiple interfaces has multiple
link-local addresses.

Or is a same link-local address assigned to multiple interfaces of an
RPL router?

I will have to check wireshark dumps about this.

>> The metric part: some metrics, such as ETX and LQL, are for a
>> single link and PHY/MAC, by their design.
>>
>
> No, they are not. LQL for example is also used by many deployed PLC
> (proprietary) solutions, even if they use a different name. So LQL
> could be used for several types of "lossy" links, it is not specific
>  to a particular PHY/MAC.

Yes, I agree, it could.

> Same reasoning applies to ETX. Now, note that the metric ID does not
>  mandate for all RPL networks to support all of the specified metrics
>  of course. Further, one may decide to specify a RPL metric that is
> relevant for a specific PHY/MAC: RPL specifies what a node is
> supposed to do when it does not understand/support a metric (leaf
> node). This is a deployment issue. This is very similar to what is
> done with other routing protocols.

In this sense, I think further work is needed on the common metrics to
support multiple PHY/MACs.

Alex

>>>> issue which Colin and Alex discussed, as Colin clarified in one
>>>> of his responses to my below concern.
>>>>
>>>>
>>>> Regards, Yoav
>>>>
>>>>
>>>> [mailto:[email-masked]] On Behalf Of Colin O'Flynn
>>>> Sent: Wednesday, October 06, 2010 10:51 AM To: 'JP Vasseur';
>>>> 'Michael Richardson' Cc: [email-masked] Subject: Re: [Roll]
>>>> [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC:
>>>> comment received during WG Last Call of
>>>>
>>>> Hello,
>>>>
>>>> work across multiple MAC/PHY. The issue was quickly blown out
>>>> of context to become about RPL in general, which of course will
>>>> work across multiple MAC/PHY.
>>>>
>>>> October 6, 2010 5:05 AM To: Michael Richardson Cc:
>>>> [email-masked] Subject: Re: [Roll] [roll] routing-metrics #80
>>>> (new): RPL across Multiple PHY/MAC: comment received during WG
>>>>  Last Call of
>>>>
>>>>
>>>>> roll>    I am seeking for WG confirmation that these use
>>>>> cases are roll>   covered well by RPL (as a route over media
>>>>>  and link layer roll>   agnostic protocol). Otherwise, I
>>>>> think this is a significant roll>   short-coming of the
>>>>> protocol.
>>>>>
>>>> They are (even in the charter !) but I wanted to close one
>>>> ticket per item raised during WG LC. We'll now close the
>>>> tickets.
>>>>
>>>> Thanks.
>>>>
>>>> JP.
>>>>
>>>>>
>>>>> ] [email-masked]
>>>>> http://www.sandelman.ottawa.on.ca/ |device
>>>> driver[
>>>>> _______________________________________________ Roll mailing
>>>>>  list [email-masked]
>>>> _______________________________________________ Roll mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>>>
>>>> _______________________________________________ Roll mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>>
>>> _______________________________________________ Roll mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>>
>>
>>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 7 Oct 2010 20:10:23 +0200

On Oct 6, 2010, at 11:18 PM, Alexandru Petrescu wrote:

> two interfaces?    

Yes

> Should I understand that most RPL Routers have at
> least two interfaces?  

Not sure we can say "most" RPL router have at least two interfaces but the 
point here is that RPL can be used in networks with multiple PHY/MAC. In 
this case, some of the routers obviously have multiple interfaces.

> If so, is the phrase RPL-12 "Although there may

There is no issue there. Similar to other IPv6 routing protocols.

> address of node A?  But a node with multiple interfaces has multiple

Depends where you DAG goes ...

> support multiple PHY/MACs.

The statement is way too vague to help. As you can see all of the metrics proposed can be used
for various "lossy" PHY/MAC. Nothing PHY/MAC specific.

Hope this helps.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 7 Oct 2010 20:12:18 +0200

Dear all,

Answers have been provided to the mailing list: 

"Summary of replies provided by JP on the list

RPL is a L3 routing protocol, which by itself answers (hopefully) your
first question. Further, this is clearly stated in the charter. With regards to your second question, these metrics are RPL metrics.

Answering the second question, “How different is it from other L3 routing protocol such as OSPF with regards to the routing metrics in a routing domain that comprises different PHY/MAC”. It is not. Consider an ISIS L2 for example. As you probably know, you have routing metrics and in most cases a number of PHY/MAC (SDH, optical, Ethernet, ATM, ...). You still use a metric for ISIS that reflects a link characteristic."

Metrics are applicable to all PHY/MAC.

Ticket will be closed with the text above.

Thanks.

JP.

---

From: "roll issue tracker" <[email-masked]>
Date: Thu, 07 Oct 2010 18:12:59 -0000

#80: RPL across Multiple PHY/MAC: comment received during WG Last Call of draft-
ietf-roll-routing-metrics-09.txt
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |        Owner:  jpv@…        
     Type:  defect           |       Status:  closed       
 Priority:  major            |    Milestone:               
Component:  routing-metrics  |      Version:               
 Severity:  In WG Last Call  |   Resolution:  fixed        
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 RPL is a L3 routing protocol, which by itself answers (hopefully) your
 first question. Further, this is clearly stated in the charter. With
 regards to your second question, these metrics are RPL metrics.

 Answering the second question, “How different is it from other L3 routing
 protocol such as OSPF with regards to the routing metrics in a routing
 domain that comprises different PHY/MAC”. It is not. Consider an ISIS L2
 for example. As you probably know, you have routing metrics and in most
 cases a number of PHY/MAC (SDH, optical, Ethernet, ATM, ...). You still
 use a metric for ISIS that reflects a link characteristic."

 Closes the ticket.

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/80#comment:3>
roll <http://tools.ietf.org/wg/roll/>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Oct 2010 20:41:55 +0200

JP - I adapt the subject line to reflect one RPL issue (not metrics):
multiple PHY/MAC interfaces and the Hop Limit value.

Le 07/10/2010 20:10, JP Vasseur a écrit :
>>>> local, i.e. a single link, a single PHY/MAC.  This contradicts
>>>> the multiple PHY/MAC perspective, because a single link can't
>>>> be connecting interfaces using different MAC/PHY.
>>>>
>>> I am not clear about your question ... why is it different from
>>> all other L3 routing ?
>>
>> link-scoped multicast addresses (RIP, OSPF) are implemented on
>> routers having multiple interfaces, thus possibly multiple
>> PHY/MAC, originating new flooding messages with another src
>> address topologically valid on that link.
>>
>> Should I understand that RPL router doing multiple PHY/MAC has at
>> least two interfaces?
>
> Yes

Ok.

Then, does RPL forward an RPL packet between two interfaces?

I suppose it does not, because the src address is link-local address
(except DAO in non-storing mode).

>> Should I understand that most RPL Routers have at least two
>> interfaces?
>
> Not sure we can say "most" RPL router have at least two interfaces
> but the point here is that RPL can be used in networks with multiple
> PHY/MAC. In this case, some of the routers obviously have multiple
> interfaces.

YEs, I agree with this view: some of the RPL routers obviously have
multiple interfaces.  Those who have should say when they generate new
RPL messages, what they use as src and dst address, because RPL
link-scoped addressed messages wouldn't be forwarded between interfaces.

>> If so, is the phrase RPL-12 "Although there may typically be only
>> one interface in most application scenarios..." a little bit
>> wrong?
>>
>> And that when receiving a DAO message on one interface RPL Router
>> may generate another DAO with a different link-local source
>> address on another interface?
>

One RPL issue here: RPL-12 does not specify the value for the Hop Limit.

Other IPv6 routing protocol using link-scoped addresses as src and dst
(OSPF) does not forward rt protocol packets across interfaces, and the
spec explicitely requires to set the Hop Limit to 1.

ND spec sets the Hop Limit to 255 and requires the receiver to check it
to be 255.

RPL-12 is silent about the value for the Hop Limit.  It only says its
value should be decremented when forwarding (which is good for a typical
router, rt protocol or not); but RPL link-scoped packets aren't
typically forwarded.  So it should say what it does about the Hop Limit
- the default value?  Does the receiver do anything special when
receiving a certain value of the Hop Limit?

Wireshark dumps of RPL show it as 255, which may be too big knowing
these packets are never forwarded.

If we want it 255 then it makes sense to write down that the receiver
checks it to be 255 ensuring the packet wasn't forwarded (avoid attacks).

IF we want it 1 then it makes sense to require originators to set it to
1, and the well behaving intermediate routers will drop it, again avoid
attacks.

>> RPL-12 says "If the D flag is cleared then the source address of
>> the IPv6 packet MUST be the DODAGID...The DODAGID in this case
>> will be the reachable IPv6 address of node A" - sounds as if there
>> is _only_ one address of node A?  But a node with multiple
>> interfaces has multiple link-local addresses.
>

WEll a DAG goes several directions.

Alex

[...]
>>> Same reasoning applies to ETX. Now, note that the metric ID does
>>> not mandate for all RPL networks to support all of the specified
>>> metrics of course. Further, one may decide to specify a RPL
>>> metric that is relevant for a specific PHY/MAC: RPL specifies
>>> what a node is supposed to do when it does not
>>> understand/support a metric (leaf node). This is a deployment
>> In this sense, I think further work is needed on the common
>> metrics to support multiple PHY/MACs.
>
> The statement is way too vague to help. As you can see all of the
> metrics proposed can be used for various "lossy" PHY/MAC. Nothing
> PHY/MAC specific.
>
> Hope this helps.
>
> Thanks.
>
> JP.
>
>>
>> Alex
>>
>>>
>>> Hope that helps.
>>>
>>> JP.
>>>
>>>>>> I agree with Colin This ticket misses the essence of the
>>>>>> real issue which Colin and Alex discussed, as Colin
>>>>>> clarified in one of his responses to my below concern.
>>>>>>
>>>>>>
>>>>>> Regards, Yoav
>>>>>>
>>>>>>
>>>>>> Sent: Wednesday, October 06, 2010 10:51 AM To: 'JP
>>>>>> Vasseur'; 'Michael Richardson' Cc: [email-masked] Subject:
>>>>>> Re: [Roll] [roll] routing-metrics #80 (new): RPL across
>>>>>> The original issue was only about if the routing metrics
>>>>>> would work across multiple MAC/PHY. The issue was quickly
>>>>>> blown out of context to become about RPL in general, which
>>>>>> of course will work across multiple MAC/PHY.
>>>>>>
>>>>>> [mailto:[email-masked]] On Behalf Of JP Vasseur
>>>>>> Sent: October 6, 2010 5:05 AM To: Michael Richardson Cc:
>>>>>> [email-masked] Subject: Re: [Roll] [roll] routing-metrics
>>>>>> #80 (new): RPL across Multiple PHY/MAC: comment received
>>>>>> during WG Last Call of
>>>>>>
>>>>>>
>>>>>>>>>>>> "roll" == roll issue
>>>>>>>>>>>> tracker<[email-masked]> writes:
>>>>>>> cases are roll>    covered well by RPL (as a route over
>>>>>>> media and link layer roll>    agnostic protocol).
>>>>>>> Otherwise, I think this is a significant roll>
>>>>>>> short-coming of the protocol.
>>>>>>>
>>>>>>> ]   Michael Richardson, Sandelman Software Works,
>>>>>>> Ottawa, ON |net
>>>>>> architect[
>>>>>>> _______________________________________________ Roll
>>>>>>> mailing list [email-masked]
>>>>>> _______________________________________________ Roll
>>>>>> mailing list [email-masked]
>>>>>> _______________________________________________ Roll
>>>>>> mailing list [email-masked]

---

From: JP Vasseur <[email-masked]>
Date: Thu, 7 Oct 2010 20:45:32 +0200

Begin forwarded message:

> From: Alexandru Petrescu <[email-masked]>
> Date: October 7, 2010 8:41:55 PM GMT+02:00
> To: JP Vasseur <[email-masked]>
> Cc: [email-masked]
> Subject: Re: RPL multiple PHY/MAC and Hop Limit field (was: [Roll] [roll] routing-metrics #80 (new): RPL across Multiple PHY/MAC: comment received during WG Last Call of)
>