Subject: Re: [v6ops] I-D Action: draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Mar 2021 13:57:39 +1300

>    Initial SRv6 implementations that trespassed safe limit in 220B are
>    the reason for recent activities in MTU problem research.

I don't understand that motivation. Since SRV6 is explicitly limited to a specific domain, as stated in Section 2 of RFC8402, it is reasonable to expect that the domain is designed with a large enough MTU to allow the expected extra headers for SRV6, and that will include any tunnel end points within the domain knowing how to support packets longer than 1280 bytes if that is needed. An obvious design goal would be to make both PMTUD and PLPMTUD unnecessary within the domain.

Regards
   Brian Carpenter

On 20-Mar-21 09:06, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : IPv6 Oversized Packets Analysis
>         Authors         : Eduard Vasilenko
>                           Xiao Xipeng
>                           Dmitriy Khaustov
> 	Filename        : draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
> 	Pages           : 19
> 	Date            : 2021-03-19
> 
> Abstract:
>    The IETF has many new initiatives relying on IPv6 Enhanced Headers
>    added in transit: SRv6, SFC, BIERv6, iOAM. Additionally, some recent
>    developments are overlays (SRv6, VxLAN) over IPv6. It could create
>    oversized packets that need to be dealt with. This document analyzes
>    available standards for the resolution of oversized packet drops.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-vasilenko-v6ops-ipv6-oversized-analysis/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-vasilenko-v6ops-ipv6-oversized-analysis-00
> https://datatracker.ietf.org/doc/html/draft-vasilenko-v6ops-ipv6-oversized-analysis-00
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 23 Mar 2021 09:48:03 +0000

Hi Brian,
Yes, it is better not to have the problem in the first place.
And if the network should have redesign for SRv6 anyway then why not increase MTU at the same time?
Very logical. Hence, the draft has started the solution section from this solution - the best one.
But it is not always possible (discussed in section 3.1):
- SRv6 is positioned for the case when upgrade could be slow enough (node-by-node), then some nodes would be just plain IPv6 in transit - no changes assumed for these nodes
- some links could be rented - no possibility to change MTU in principle
- DC-to-DC could generate 9k that is not possible to accommodate in principle
- middleboxes (security, load balancing) could be on the path event for the final design. Middleboxes have their own refreshment cycle (with the budget from different department)
- low-cost routing platforms may not be capable to share buffers between many packets (1 packet = 1 buffer) then 9kB buffer would be given for any 100B packet. MTU increase for such platforms effectively decrease buffer capacity in ms to make it negligible and not acceptable.
- link could be not Ethernet - it may not support 9k

The net result is activities like:
draft-zhu-idr-bgp-ls-path-mtu
draft-li-idr-sr-policy-path-mtu
draft-li-pce-pcep-pmtu
draft-hu-lsr-isis-path-mtu
to control the situation in the way that we call "frugal headers usage" in the draft.

Our assumption that is better to fix PMTUD. But it does not preclude other mechanisms development.
PLPMTUD is probably too much to ask from SRv6 tunnel end.
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, March 23, 2021 3:58 AM
To: IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt

Regards
   Brian Carpenter

On 20-Mar-21 09:06, [email-masked] wrote:
> 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.
> 
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops