Hi Tony,
I disagree with your apparent view that the 3.1 taxonomy is adequate
as it stands:
> Thank you very much for your suggestion. However, section 3.1.3 (and, for
> that matter, all of section 3.1) is much more general than section 3.3.1.4.
> I believe that those two techniques are covered quite adequately there.
I think that if you are to have the 3.1 taxonomy, it should be
extended to cover all the architectures - or that a note be added
that this only covers a subset of the currently proposed
architectures. Unless there is a note to the contrary, readers will
assume that each taxonomy has a place for every one of the architectures.
My understanding of the 3.1 taxonomy is that describes the set of
primary mechanisms by which routing scaling architectures achieve
their goals. I understand these are broad divisions and that other
taxonomies divide the architectures more finely.
The "Modified Header Forwarding" techniques do not fit at all into
your current 3.1 taxonomy. They are not Transport, Translation or
Map & Encap. In many ways these MHF techniques resemble Map & Encap,
but there is no encapsulation, and therefore no overhead or PMTUD
problems.
I think that if you retain the 3.1 taxonomy you should add, at the
bare minimum, something like this:
3.1.4 Map & Forward with Modified Header Forwarding (MHF)
An alternative mechanism to Map & Encap retains the mapping system
and overall structure of tunneling the traffic packet across the
DFZ to a tunnel endpoint device at the RLOC address - which
forwards the packet directly to the destination network. Instead
of encapsulation, Modified Header Forwarding (MHF) alters the IP
header of the original packet to include sufficient bits to
specify part or all of the RLOC address of the tunnel endpoint
device.
These two techniques are described below as strategies A4f and
A4g. They both require upgraded DFZ and other routers but avoid
Map & Encap's problems of encapsulation overhead and Path MTU
Discovery problems.
In the long term, upgrading all the routers is not a problem. The
system could be introduced as Map & Encap and transition later to
using MHF instead. Perhaps, by the time we implement the solution,
it will be practical to upgrade the DFZ routers anyway, and therefore
avoid the PMTUD problems of encapsulation entirely.
I believe that these MHF techniques are by far the best long-term
approach for any core-edge separation architecture. I believe they
should be a part of however many taxonomies which are used in this
document.
I will write in another message some changes I suggest to the 3.3.1
section to better cover Ivip's Map & Encap approaches and "Map &
Forward with Modified Headers".
Regards
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
