[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] MTU/fragmentation AGAIN
Templin, Fred L wrote:
About MTU changes due to path changes, that is a problem
that needs to be dealt with in any case and not just the
map-and-encaps case. The two ways of detecting this are
to begin receiving packet-too-bigs when none were
received previously, or to proactively probe the path,
or both. (In the map-and-encaps case, sprite-mtu probing
can be used for proactive probing by the ITR.)
FWIW, some might suggest that another way to deal with
this is to set DF=0 in all packets after the path has
been probed and just let it fragment if an MTU restriction
due to a path change occurs. But, RFC4963 presents some
sobering insights as to why that would be a bad idea.
I've been thinking about a variation of the map-and-encaps style of LISP.
(Obviously the control plane and data plane are orthogonal, and don't
share much
other than the need for the control plane and EID->RLOC mapping.)
I was thinking about this at the last IETF, and think I have a better
handle on LISP now.
(Thanks, Dino.)
(The following is, finally, a way to put the "pure math" part of my
degree to work. :-))
There's two kinds of "mapping" in math that are interesting: "1:1", and
"onto".
What we conventionally think of as "1:1", is, technically, "1:1 *and* onto".
I bring this up because of an interesting observation. Regardless of
RLOC used,
if mappings are looked up by xTR's in both directions, RLOC->EID at the ETR
is completely deterministic.
So, let's consider an interesting scenario, most feasible in IPv6
because of address scarcity in IPv4.
What if the EIDs were (assigned | issued) as PI address blocks?
Specifically, PI blocks not routed into the DFZ,
per se (but potentially available as an "upgrade path"), as an
alternative to ULA or ULA-{C|G}.
The concept is to "map-and-map", from PI-EID to PA-RLOCs, via 1:1
mapping(s).
The reverse mappings are likewise 1:1, reasonably trivial, and
essentially unchanging regardless of RLOCs in use.
The real benefit is that, like SIIT, it is feasible to do ICMP
transliteration, thus support PMTUD and similar activities.
That, and not affecting the PMTU itself in the first place. :-)
The map-and-map effectively becomes NAT + SNAT, without any port mangling.
The only substantial difference I can think of, is the RLOC reachability
bit vector.
The main question I have is, is there any obvious way to maintain the
benefit of that bit vector without having to go all the way to
encapsulation?
Brian Dickson
P.S. The mechanisms might even support non-LISP-to-LISP connectivity,
presuming LISP-aware host stacks.)
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg