Subject: Re: SV: [6lowpan] WG last call on Format document

From: gabriel montenegro <[email-masked]>
Date: Mon, 15 Jan 2007 13:05:51 -0800 (PST)

Going back to Carsten's 3 options. Now that it's clear that nobody was asking for option 3
below perhaps we can move forward. As I see it, relaxing the order of the headers
as per Option 2 by itself does not help much. How does this next hop know if it is the
sole recipient of all the fragments? Kris eloquently points out that this is a real
problem in a mesh. Perhaps what is needed is some negotiation in addition to merely
relaxing the ordering of the headers (as done, for example, with DTN). If so, I
could change the text as follows:

AFTER:
   When more than one LoWPAN header is used in the same packet, they
   MUST appear in the following order:

      Mesh Addressing Header
      Broadcast Header
      Fragmentation HeaderADD:

    Future revisions of these processes may relax the above header ordering.

So whereas this ordering is currently mandated, we would keep the door open
for future variations to be specified separately.

And to answer Phil's question: this does not contravene
IPv6. Even though the current header format may have been inspired by IPv6,
IPv6 itself is impervious to it as this is hidden under IP. 

Does this work? 

If so, I can prepare a new version of the doc with the above change
as well as some typo and editorial fixes (e.g., delete an outdated "NOTE") 
in preparation for IESG.

-gabriel

----- Original Message ----
From: Carsten Bormann <[email-masked]>
To: gabriel montenegro <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; Schumacher Christian Peter Pii <[email-masked]>; Philip Levis <[email-masked]>; Geoff Mulligan <[email-masked]>; [email-masked]
Sent: Sunday, January 7, 2007 12:09:08 PM
Subject: Re: SV: [6lowpan] WG last call on Format document

> I'd suggest capturing Phil's issue in the writeup used by the
> chairs to advance the document as per:
>
>    http://www.ietf.org/IESG/content/Doc-Writeup.html
>
> That way we can invite discussion from the IESG on this item.

While it is always a good thing to obtain input from the IESG, I  
don't think delegating this issue to the IESG during document  
submission is the right approach here.

The WG is the domain expert on the kind of network we are discussing  
here.
The WG should come to a conclusion.
The IESG can then check that we followed process and that the  
document fits into the wider IETF picture (which is *not* dominated  
by the relevant considerations here).

<wg-chair hat="off">
   On the reassembly issue, I see two approaches:

   1) keep with the reassembly at destination
   2) open up the sequence such that reassembly-before-forwarding  
becomes an alternative, chosen by the sender.
   3) only allow reassembly before forwarding, i.e. forward only full  
datagrams.

   (As far as I can see, nobody argues for 3, that's why I see *two*  
approaches.)

   The advantage of 2 is more options (Philip has explained why this  
can be a good thing).

   The obvious disadvantage of 2 is more options (i.e., increased  
burden on an implementation).
   With 2, the sender gets to decide whether a forwarder has to  
reassemble before forwarding; the forwarder has to play with that  
decision.
   (Reassembly at the forwarder also means different fragments cannot  
choose different paths; maybe a more theoretical consideration.)
</wg-chair>

I'd like to hear more people taking sides on 1 or 2 before we declare  
consensus.

Gruesse, Carsten

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

---

From: Philip Levis <[email-masked]>
Date: Mon, 15 Jan 2007 17:05:43 -0800

> IPv6 itself is impervious to it as this is hidden under IP.

Give that the current proposal allows for new headers to be  
introduced along with their ordering, I think the "may relax"  
statement is not necessary. We can always introduce a new  
fragmentation (or routing) header that switches the order around.

That being said, if you want to hedge your bets, then best to be more  
precise: MUST the ordering on transmit and SHOULD the fact that you  
need to accept either. But of course this is going to make the whole  
thing harder to implement.

I think it's better to leave out the addendum.

Phil