Pekka,
>-----Original Message-----
>From: Pekka Savola [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 11, 2008 3:07 PM
>To: [email protected]
>Subject: [Int-area] comments on multi-mtu work
>
>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.
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
[EMAIL PROTECTED]
>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 protected]
>https://www.ietf.org/mailman/listinfo/int-area
>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
