Subject: [Roll] Fwd: draft-previdi-6man-segment-routing-header

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 15 Nov 2014 06:16:48 +0000

This also relates to our discussion on whether a RH or a RPL option can be inserted or cause an extra  IPinIP encapsulation. Certainly the rule is to encapsulate.

This is where the Flow Label technique was of particular interest.

Now if we could go along the path of a routing dispatch where all the LLN routing artifacts are stored prior to the compressed packet we could probably make things innocuous.

Cheers,

Pascal

Début du message transféré :

Expéditeur: Erik Nordmark <[email-masked]<mailto:[email-masked]>>
Date: 14 novembre 2014 15:24:44 UTC−10
Destinataire: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>, 6man <[email-masked]<mailto:[email-masked]>>
Objet: Rép : draft-previdi-6man-segment-routing-header

On 11/14/14 12:03 PM, Brian E Carpenter wrote:
Hi,

1. I simply don't understand one aspect of this proposal. Whenever I have
looked for it in RFC 2640, I have failed to find anything that allows
extension headers to be inserted in packets en route. But this draft
seems to require an ingress router to insert a header and an egress
router to remove it. Is that even allowed? And are we sure it has no
unintended side effects?

Doesn't work - breaks PMTUD (the origin receives a PTB which says MTU=X but sending packets of length X still fails due to the added headers). This should be in the "IP protocol FAQ" - I can't remember how many times Steve Deering had to correct this.

IPv6 extension headers can only be added together with an outer IPv6 header. That ensure that any ICMP errors are sent to the encapsulators, that can regenerate a ICMP error which will have the correct MTU value for the original sender.

  Erik

2. There is no mention of MTU size or fragmentation. What happens if
the user packet plus the added header exceeds the network's MTU?

3. I think this model is completely orthogonal to the problem presented
by Behcet in draft-sarikaya-6man-sadr-overview.

     Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Sun, 16 Nov 2014 00:48:26 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > This also relates to our discussion on whether a RH or a RPL option can
    > be inserted or cause an extra IPinIP encapsulation. Certainly the rule
    > is to encapsulate.

    > This is where the Flow Label technique was of particular interest.

So you are saying that in order for us to add the RFC6553 header (no matter
how compressed it is), we have to encapsulate all external traffic.
I forgot that part in our excitement to come to consensus.
This really sucks for RPL over things that don't need/want 6loHC (802.11*
links, ethernet)... it sucks because it means screwing up the end to end MTU.

Are you saying you want to re-open the flow-label discussion?

    > Now if we could go along the path of a routing dispatch where all the
    > LLN routing artifacts are stored prior to the compressed packet we
    > could probably make things innocuous.

I don't understand this part.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 16 Nov 2014 06:59:19 +0000

Hello Michael

> So you are saying that in order for us to add the RFC6553 header (no matter how

> compressed it is), we have to encapsulate all external traffic.

> This really sucks for RPL over things that don't need/want 6loHC (802.11* links,

> ethernet)... it sucks because it means screwing up the end to end MTU.

[PT] Yes, I insisted on it again at the 6lo presentation I made on the subject

My slide 3 was like:

*        Flow Label compresses RPI down to 20 bits

*        Flow label avoids IP-in-IP encapsulation

*        Flow Label needs 6MAN approval

*        6lo/NHC is unambiguous about RPI

*        6lo/NHC allows to compress 2-byte rank

*        6lo/NHC is a compressed form of RFC 6553 as opposed to a new format

I presented at 6MAN, with the following asks

1) the right for a source in the LLN not to set the flow label

2) the right for the LLN border router to reset the LLN for packets coming in the LLN

3) as an extension of 2) the right for the LLN border router to set the LLN that it just rest to a new value

4) as an extension to 3) the right for any router in the LLN to update the flow label

Noting that:

4) is what we need to use the flow label for RPL.

3) is what we need to maintain ISA100.11a legit.

1) and 2) are meant to save energy in the LLN.

> Are you saying you want to re-open the flow-label discussion?

[PT] I suggest we keep exploring 6lo solutions. At the moment we do not have a conclusion there.

So it is safe that at the same time try to remove the 6MAN-related arguments against the flow label approach so we have free hands ultimately.

[PT] This is something I hinted at the 6TiSCH call.

There is a third way that places all the LLN routing artifacts, including RH3 and RPI, in a routing dispatch, prior to the compressed packet.

A dispatch for the RPI only was overkill, but a routing dispatch can be a good idea that seems to alleviate the need for IP in IP.

Let me write that down so everyone can make his own opinion.

Cheers,

Pascal

> Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works  -=

> IPv6 IoT consulting =-