Subject: [Int-area] comments on multi-mtu work

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2008 00:07:09 +0200 (EET)

Hi,

First, general observation on potential applications of this work:
  1) host <-> host in a LAN setting
  2) host <-> router in a LAN setting
  3) router <-> router in interdomain scenario in a LAN setting (e.g.,
     Ethernet IX); point-to-point scenario is trivial
  4) router <-> router in intradomain cases (as Dino mentioned, IS-IS
     already verifies jumbo-MTUs working in this context, manual
     config is acceptable here)

4) is already problem with 80% solution so I don't think work is 
needed here.  3) seems like the most important issue because it is the 
actual bottleneck for in-the-network tunneling and fragmentation and 
the only thing that needs to be solved for RRG's encap/decap to work 
from MTU perspective. 2) and 1) seem like priority two from my 
perspective at least.

That said, IMHO draft-van-beijnum-multi-mtu-02 is unnecessarily 
complex.  SLOWMTU and SAFEMTU provide only little benefit and are 
largeley useless.  RA message for scenario 2) with just MAXMTU could 
be provided but even this is not required because nodes can probe up 
and discover the limits even if no such thing existed.

The minimum spec would be "Jumbo-ND" and "Jumbo-ARP" where a node does 
per-neighbor based probing with padded packets to discover whether 
large packets work towards that neighbor (the same an on-link host or 
router).  If no RA used, this behaviour should probably be disabled by 
default.

The generic problem with changing MTU based on dynamic information is 
what happends when the state gets lost.  This may result in PMTU 
fluctuation, packet loss and unreliability.  This needs special 
attention in the design phase.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Mar 2008 15:20:48 -0700

The other comment about the multimtu is that it doesn't
completely solve the problems for IPv6-over-(foo)-over-IPv4
tunnels. The NDISC MTU probing aspect of multimtu (which I
have also proposed earlier) only tells you a size >= 1280
that the neighbor can receive, but it does not tell whether
the underlying IPv4 network is fragmenting. (Or, if not
fragmenting presently, it does not detect if fragmentation
ensues at a later time due to routing changes.)

SEAL takes care of this w/o the need for NDISC probing. It
also lets the tunnel use MTUs larger than 1280, which could
be problematic for existing IPv6-over-(foo)-over-IPv4 tunnels.
That said, SEAL can use the RA MTU options specified by
multimtu. The ingress tunnel endpoint can send an RS to an
egress tunnel endpoint to get an RA back with MTU options
telling how large the ETE can receive.

Fred
[email-masked]
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Mar 2008 15:42:33 -0700

Pekka,

>-----Original Message-----
>From: Pekka Savola [mailto:[email-masked]] 
>Sent: Tuesday, March 11, 2008 3:07 PM
>To: [email-masked]
>Subject: [Int-area] comments on multi-mtu work
>
>Hi,
>

I agree with your assessment, and case 3 is exactly the case
SEAL was designed to address. Use cases for router-to-router
tunneling addressed by SEAL include:

  - interdomain routing core
  - MANETs
  - enterprise networks
  - any interdomain routing region bordered by ingress-
    and egress tunnel endpoints

I would welcome your comments:

  http://www.ietf.org/internet-drafts/draft-templin-manet-seal-00.txt

Fred