Re: [6lo] Fwd: New Version Notification for draft-toutain-6lo-local-extensions-00.txt

["Pascal Thubert (pthubert)" <[e-mail]>]

I agree, Carsten, all the way. 

This text was initially for an answer to you on a 6MAN/ROLL thread on the flow label. But since it was way out of context there I took it off and sent it to 6lo where it belongs.

For the flow label draft, time is of the essence and though it may be a temporary solution, we need something better than HbH and we need it now. 

If new work on routing dispatch takes off then it would be certainly be the long term solution, and I'm willing to contribute make that happen sooner than later.

Note that we do not necessarily bridge a bunch of that onto Ethernet. Stuff related to RFC 6550, IP in IP, RPL option and routing headers are all artifacts that are localized to the LLN.

Mapping an instance onto a VLAN is an admin decision, just as it is today with other forms of VRFs.

For deterministic flow indicators, service chaining, packet redundancy and so on, we'll be following SFC detnet etc...

Cheers,

Pascal


> -----Original Message-----
> From: Carsten Bormann [mailto:[e-mail]]
> Sent: vendredi 1 août 2014 15:45
> To: Pascal Thubert (pthubert)
> Cc: [e-mail]
> Subject: Re: [6lo] Fwd: New Version Notification for draft-toutain-6lo-local-
> extensions-00.txt
> 
> On 01 Aug 2014, at 15:30, Pascal Thubert (pthubert) <[e-mail]>
> wrote:
> 
> > Dear all:
> >
> > After careful thoughts on Laurent's work, I think we really could benefit
> from a 6lowpan 'routing dispatch' with a compression for the RPL option,
> routing headers, and whatever else might be needed to route the original
> packet or any individual fragment within the LLN, enable livelive (PRP),
> chaining (SFC), overlays (NVO3), or whatever else.
> 
> Putting this kind of information at this point is a much better way than
> storing it in the flow label.
> We tried to guess what might be needed with the mesh header in RFC 4944,
> but we failed.
> YAGNI applies, and we couldn't really guess the details right at the time
> anyway.
> 
> The main disadvantage of carrying sub-IP information around in the
> 6LoWPAN headers is that it is hard to move it over to the non-6lo world, say,
> Ethernet-style PLC encapsulation.  But that may not be a big problem,
> because IP-in-IP is much more tolerable in that world.  Also, the 802.3/802.1
> world has its own stack of headers (VLAN tags with 802.1Q priority etc.), so
> there may be another way to handle this.  If that doesn't work, there is
> always a label stack.
> 
> I'm not sure I understand (or agree with) all of the details in Laurent's draft,
> but it sure serves as a wakeup call.
> 
> Grüße, Carsten