Subject: draft-previdi-6man-segment-routing-header-07 and path mtu discovery

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jul 2015 10:34:00 +0200

I don't see any discussion in this draft about the path MTU discovery 
that was brought up in Dallas.
I think the document needs to specify how this is handled. Are SR nodes 
expected to 1) send ICMP errors with a lower MTU (adjusted for the added 
headers) or 2) are SR ingress/egress routers expected to adjust the MTU 
in an ICMP packet too big error as part of forwarding it outside of the 
SR "domain"? Something else?

I'm separately concerned with the IPR statement 
(https://datatracker.ietf.org/ipr/2421/). I can't recall any claimed IPR 
the core IPv6 standards with such vague implications. For instance, the 
statement uses the term " Cisco's affiliates" without defining it. I 
don't know if I'm the only individual concerned about this. I much 
prefer if the narrow waist of the Internet Architecture is populated 
with protocols without known claimed IPR.

Regards,
    Erik

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 23 Jul 2015 18:49:11 +0000

On Jul 23, 2015, at 10:34 AM, Erik Nordmark <[email-masked]> wrote:
> I don't see any discussion in this draft about the path MTU discovery that was brought up in Dallas.
> I think the document needs to specify how this is handled. Are SR nodes expected to 1) send ICMP errors with a lower MTU (adjusted for the added headers) or 2) are SR ingress/egress routers expected to adjust the MTU in an ICMP packet too big error as part of forwarding it outside of the SR "domain"? Something else?

the MTU issue is not related to the SRH proposal per se but rather to any mechanism that allow a network to increase the size of the packet while transiting (i.e.: all cases where the originator of the packet is not the one adding headers).

Examples of these are GRE or MPLS when used in operators networks (typically a packet at ingress get's labeled or GRE encapsulated).

So, in that respect SRH is the same and how did we handle the GRE and MPLS cases ? Well, operator's networks don't have small MTUs in their infrastructure and that's why such issue has never been reported so far.

I realize that something is maybe not clear enough in the draft and which consists of the typical deployment model where the segment routing is used within a controlled domain and NOT end to end. Obviously, the technology allows any sort of deployments but it is also not in the strategy/plans of operators to allow SRH packets at ingress. This also relates to the security of the SRH.

> I'm separately concerned with the IPR statement (https://datatracker.ietf.org/ipr/2421/). I can't recall any claimed IPR the core IPv6 standards with such vague implications. For instance, the statement uses the term " Cisco's affiliates" without defining it. I don't know if I'm the only individual concerned about this. I much prefer if the narrow waist of the Internet Architecture is populated with protocols without known claimed IPR.

Cisco has contributed substantially to IETF and with the same IPR policy so I'm a bit surprised to see your concern (which, btw, has never been raised in any other WG).

However, it's way out of my league so I'd suggest you to get in touch with the experts in the area and feel free to contact our legal services.

s.

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

---

From: Jen Linkova <[email-masked]>
Date: Fri, 24 Jul 2015 00:43:44 +0200

> the MTU issue is not related to the SRH proposal per se but rather to any mechanism that allow a network to increase the size of the packet while transiting (i.e.: all cases where the originator of…

However I believe Erik made a valid point (the same issue has been
discussed today offline..)
What definitely needs to be clarified is what happens if/when an
intermediate router has to send ICMP error back.  In particular, what
MTU value for ICMP Packet Too Big and what happens to the extension
header (is it included/removed and if yes, by which device?).
As the router sending back ICMP Packet Too Big might not be even
SR-capable node.

To be honest, I'd not expect anything issues with SR and MTU in
foreseeable future (not until we get MTU on end hosts above 1500) but
you never know..

-- 
SY, Jen Linkova aka Furry

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 24 Jul 2015 10:29:45 +0200

> Examples of these are GRE or MPLS when used in operators networks (typically a packet at ingress get's labeled or GRE encapsulated).
Stefano,

I think GRE over IPv4 packets can be fragmented and reassembled.
IPv6 has this 1280 minimum size which limits the ability to fragment, 
which means you probably need to look at this with more care than for IPv4.

If the host sends a 1280 byte packet and the added headers for SR pushes 
the packet size above the MTU of the SR part of the path, then you have 
little choice but have the SR ingress fragment the packet.
That might mean that there are some limits (such as 1500-1280=220) which 
it would be helpful to capture.

This doesn't mean that there will be problems in practice, but the 
standard should be reasonably complete. And since the draft is proposing 
something unusual and unique I would expect it to discuss these matters.
> I realize that something is maybe not clear enough in the draft and which consists of the typical deployment model where the segment routing is used within a controlled domain and NOT end to end. O…
At a minimum the draft needs to document those assumptions in some form 
of intended applicability statement.

It would also be helpful to add some text to indicate what happens 
should ICMP packet too big be generated, since that is helpful should 
this be deployed where your assumptions are not valid. As Jen said, 
specify what happens to those ICMP errors.

The draft is the only specification which inserts IPv6 extension headers 
along the path, thus you need to add sufficient description of how this 
interacts with things like path MTU discovery. Part of the reason for 
doing that work is that successful protocols tend to be deployed outside 
of their initial environment, hence capturing both the 
assumptions/applicability and what happens when those are violated is 
quite helpful.

Thanks,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 24 Jul 2015 11:09:25 +0200

Stefano,

Slide 55 in the newcomers slide set 
(https://www.ietf.org/meeting/92/tutorials/92newcomers.pdf) refers to 
RFC 3669, which has very useful information for the WG to consider when 
evaluating technology with claimed IPR.
Since the 6man WG has not handle many (if any) documents with IPR claims 
I strongly recommend that the WG participants review that RFC.

The WG participants can consider claimed IPR (and associated licensing 
terms, if known) at different times in the WG process including when to 
decide whether to adopt a WG document, and during WG last call.

And a proponent of some particular technology/draft can increase the 
likelihood of adoption and standardization by making the licensing terms 
attractive to the WG participants.

I'm just one voice in the working group, but I want to make sure the WG 
makes informed decisions and not accidentally go down a path which might 
have negative impact on the implementation and deployment of the core 
IPv6 technology.

So please review this carefully.

Regards,
     Erik

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 24 Jul 2015 09:16:22 +0000

On Jul 24, 2015, at 11:09 AM, Erik Nordmark <[email-masked]>
 wrote:

> Slide 55 in the newcomers slide set (https://www.ietf.org/meeting/92/tutorials/92newcomers.pdf) refers to RFC 3669, which has very useful information for the WG to consider when evaluating technology with claimed IPR.
> Since the 6man WG has not handle many (if any) documents with IPR claims I strongly recommend that the WG participants review that RFC.
> 
> The WG participants can consider claimed IPR (and associated licensing terms, if known) at different times in the WG process including when to decide whether to adopt a WG document, and during WG last call.
> 
> And a proponent of some particular technology/draft can increase the likelihood of adoption and standardization by making the licensing terms attractive to the WG participants.
> 
> I'm just one voice in the working group, but I want to make sure the WG makes informed decisions and not accidentally go down a path which might have negative impact on the implementation and deployment of the core IPv6 technology.

absolutely and I also encourage the WG to read the slides you pointed out and, in addition, I'd also suggest to have a look at what happens in terms of contributions and IPR in other WGs.

Thanks.
s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 24 Jul 2015 09:17:18 +0000

> foreseeable future (not until we get MTU on end hosts above 1500) but

indeed. Probably a section on this matter would help in the draft.

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 24 Jul 2015 21:28:21 +0000

> I think GRE over IPv4 packets can be fragmented and reassembled.

I don't think there are much routers that will ever reassemble a fragmented GRE packet...

> IPv6 has this 1280 minimum size which limits the ability to fragment, which means you probably need to look at this with more care than for IPv4.
> 
> If the host sends a 1280 byte packet and the added headers for SR pushes the packet size above the MTU of the SR part of the path, then you have little choice but have the SR ingress fragment the packet.

sure but from a practical perspective, looking at operators networks, the mtu in the infrastructure is way over the usual 1500. This is one of the reason why GRE or MPLS or whatever other encapsulation has never been seen as a real/practical problem. SRH is no different here.

Now, having said that, this needs to be documented anyway and we'll make sure it's going to be in the SRH draft.

> That might mean that there are some limits (such as 1500-1280=220) which it would be helpful to capture.
> 
> This doesn't mean that there will be problems in practice, but the standard should be reasonably complete. And since the draft is proposing something unusual and unique I would expect it to discuss these matters.

I agree.

> At a minimum the draft needs to document those assumptions in some form of intended applicability statement.

yes.

> It would also be helpful to add some text to indicate what happens should ICMP packet too big be generated, since that is helpful should this be deployed where your assumptions are not valid. As Jen said, specify what happens to those ICMP errors.
> 
> The draft is the only specification which inserts IPv6 extension headers along the path, thus you need to add sufficient description of how this interacts with things like path MTU discovery. Part of the reason for doing that work is that successful protocols tend to be deployed outside of their initial environment, hence capturing both the assumptions/applicability and what happens when those are violated is quite helpful.

I agree.

thanks.
s.