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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Aug 2014 13:30:43 +0000

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. 

What do you think?

Pascal

> -----Original Message-----
> From: 6lo [mailto:[email-masked]] On Behalf Of Ulrich Herberg
> Sent: mardi 1 juillet 2014 20:59
> To: Laurent Toutain
> Cc: [email-masked]
> Subject: Re: [6lo] Fwd: New Version Notification for draft-toutain-6lo-local-
> extensions-00.txt
> 
> Hi Laurent,
> 
> thanks for submitting this draft and announcing it on the list. I
> confirm having received the request for a slot. Samita and I will work
> on the agenda in the next few days and will let you know soon.
> 
> Best regards
> Ulrich
> 
> On Mon, Jun 30, 2014 at 2:41 AM, Laurent Toutain
> <[email-masked]> wrote:
> > Hi,
> >
> > I've submitted a draft on local extensions. The goal is to avoid IPv6
> > tunnelling in LoWPAN by introducing a new dispatch value which will
> describe
> > IPv6 extensions. I would like to know if there is an interest from the
> > working group for such approach and a possibility to present it at Toronto.
> >
> > Thanks
> >
> > Laurent
> >
> > ---------- Forwarded message ----------
> > From: <[email-masked]>
> > Date: Fri, Jun 27, 2014 at 11:12 AM
> > Subject: New Version Notification for
> > draft-toutain-6lo-local-extensions-00.txt
> > To: Laurent Toutain <[email-masked]>
> >
> >
> >
> > A new version of I-D, draft-toutain-6lo-local-extensions-00.txt
> > has been successfully submitted by Laurent Toutain and posted to the
> > IETF repository.
> >
> > Name:           draft-toutain-6lo-local-extensions
> > Revision:       00
> > Title:          6LoWPAN Local Extensions
> > Document date:  2014-06-27
> > Group:          Individual Submission
> > Pages:          5
> > URL:
> > http://www.ietf.org/internet-drafts/draft-toutain-6lo-local-extensions-
> 00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-toutain-6lo-local-extensions/
> > Htmlized:
> > http://tools.ietf.org/html/draft-toutain-6lo-local-extensions-00
> >
> >
> > Abstract:
> >    [RFC2460] defines an extension mechanism to add functionalities to
> >    the basic IPv6 header.  On LoWPAN networks, some extensions are
> >    required to extend routing capabilities.  These specific extensions
> >    should not leak in the global internet.  To optimize encapsulation, a
> >    6LoWPAN dispatch to carry local extensions is defined.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> >
> >
> > --
> > Laurent Toutain
> > +--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
> > | Tel: +33 2 30 96 6312    | Tel: + 33 2 99 12 7026                 | Visit
> > :
> > | Mob: +33 6 800 75 900    |                                        |
> > | Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
> > http://class.touta.in
> > | [email-masked]         | [email-masked]    |
> > +--------------------------+----------------------------------------+
> >
> > _______________________________________________
> > 6lo mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/6lo
> >
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 1 Aug 2014 15:44:45 +0200

> 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…

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Aug 2014 14:07:28 +0000

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

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: vendredi 1 août 2014 15:45
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]
> > 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.
> 
> 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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 2 Aug 2014 00:33:05 +0200

> 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. 

How about this then:

http://datatracker.ietf.org/doc/draft-bormann-6lo-rpl-mesh/

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 3 Aug 2014 13:19:00 +0000

Good start Carsten...

We need to include source routing, talk about fragments etc...

Pascal

> Le 2 août 2014 à 00:33, "Carsten Bormann" <[email-masked]> a écrit :
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 4 Aug 2014 10:45:13 +0200

On 03 Aug 2014, at 15:19, Pascal Thubert (pthubert) <[email-masked]> wrote:

> Good start Carsten…

Thanks!

> We need to include source routing, talk about fragments etc…

Fragments are covered in the current draft.

I didn’t try to include RFC 6554 source routing because I first wanted to cover the functionality of the flow label draft, which is WGLCing over in ROLL/6man.  Obviously, given the dominance of non-storing mode, source routing is important.  Before designing this (probably as a separate dispatch type):

— Are there packet captures available that we could use as a corpus to discuss encoding choices?
— What are values of CmprI and CmprE that we are seeing in real networks (i.e., that this should be optimized for)?
— Do we need the segments left feature, or can we simply discard segments in each forwarding router?
— Can we use the hop limit field of the encapsulated IP packet, or do we need our own hop limit like in the RFC 4944 mesh header?
— How is ICMP error message generation done in real-world RPL implementations?  How much of that needs to be preserved?

This obviously is a bit more work than covering the information in the flow label draft, so I’m not sure it should be done now given the urgency that is being attached to that draft.

Grüße, Carsten