Subject: Re: [Roll] [6lowpan] New charter for 6lowpan

From: JP Vasseur <[email-masked]>
Date: Thu, 29 May 2008 11:48:15 -0400

Hi Phil and Carles,

On 5/28/08 1:38 AM, "Philip Levis" <[email-masked]> wrote:

> On May 27, 2008, at 2:29 AM, Carles Gomez Montenegro wrote:
>> 
>> At least, there are the following items listed in the routing
>> requirements
>> draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt)
>> that route-over approach cannot provide or would provide only in a
>> limited
>> way:
> 
> I disagree wholeheartedly.

So do I.

I think there is a big confusion here
> between a protocol specification and a protocol implementation.
> 
> These are all arguments for cross-layer design, that tightly
> integrating routing and the link layer will lead to a better solution.
> Practice has shown us otherwise;

Indeed, "practice" being "The Internet".

only by clearly separating concerns
> do you give a protocol the flexibility needed to evolve over time.
> What happens when a new low power link layer emerges? Having N
> different solutions, each with their own details, which somehow need
> to be made to work well together, seems like a path of brittle and
> difficult to manage networks. Switches are good, to a point; there's a
> reason you have routers.
> 
> The purpose of a protocol specification, IMO, is to specify what is
> needed for interoperability; there should, in theory, be multiple
> possible implementations (and by that, I mean power saving approaches)
> that can all interoperate.

Indeed. 

Carles, we're not saying that L3 should not take into account the specific
characteristics of L2. This is why we have the following WG item:
"- Specification of routing metrics used in path calculation. This
includes static and dynamic link/node attributes required for routing in
LLNs."

There are a few cases where cross-layer "collaboration" may be quite
powerful but we need to be very careful at what we're doing here.

Thanks.

JP.

> 
> Phil
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

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

---

From: "Miguel Sanchez" <[email-masked]>
Date: Fri, 30 May 2008 20:18:13 +0200

Hi JP,

> Indeed, "practice" being "The Internet".
There are a couple of topics that seem to be cross-layer by nature. One of
them seems to be power awareness. The other seems to be routing involving
wireless links.

That is why I am not so sure that "practice" (done mostly with wired links
and without power constraints) is very relevant here. That is why IETF MANET
group was created; not because current routing on the Internet was wrong but
because a new type of problem was being addressed (mobile ad-hoc
networking).

I do not see how MAC feedback can be bad, as not being a mandatory feature
network layer can always just ignore it. However I can see how such a
feedback can avoid repeating operations already performed at the link layer
(i.e. link quality estimation).

Just my two cents,

Miguel Sánchez

---

From: JP Vasseur <[email-masked]>
Date: Sat, 31 May 2008 14:50:51 +0200

Hi Miguel,

On 5/30/08 8:18 PM, "Miguel Sanchez" <[email-masked]> wrote:

> JP> I¹m not against cross-layer if we know what we¹re doing. You¹re quite
> right that some issues benefit from cross-layer (e.g. Deep packet inspection,
> even sometime dataware routing, ...).
> 
> That is why I am not so sure that "practice" (done mostly with wired links and
> without power constraints) is very relevant here. That is why IETF MANET group
> was created; not because current routing on the Internet was wrong but because
> a new type of problem was being addressed (mobile ad-hoc networking).
> 
> JP> And this is also why ROLL was created, because we had to work on a
> different set of issues, constraints, ... See the BOF slides.
> 
> network layer can always just ignore it. However I can see how such a feedback
> can avoid repeating operations already performed at the link layer (i.e. link
> quality estimation).
> 
> JP> Surely but the original email was going much further in term of layer
> violation ...
> 
> Thanks.
> 
> JP.
> 
> Just my two cents,
> 
> Miguel Sánchez
> 
>