Hi Bill,
You wrote:
> There are also forms of strategy A that can evolve into strategy B
> over the long term. Architect your ITR so that the pushed data load
> doesn't render it unreasonable to place the ITR on the end-user's PC
> and then build the ETR dumb. With the session knowledge not available
> to the network ITR, the host ITR can make a better decision. Over time
> it becomes a standard part of the stack.
What you describe is similar to Ivip's ITFH (ITR Function in Host).
However:
1 - ITFH is not intended to become a standard part of the stack of
all hosts. It is purely an option which may be used when:
a - The host is not behind NAT. (ITRs need to be easily reachable
by their upstream query server when the query server sends
the ITR an update to some mapping. This could be done with
the ITFH host behind NAT, but it is not part of the current
plan.)
b - The host has sufficient RAM and CPU resources to perform the
ITR functions. (This is a lot easier with forwarding,
than with encapsulation, since with forwarding there are no
PMTUD problems to solve).
c - In the case of forwarding, the internal routers of the
end-user network and ISP are all capable of handling the
modified IPv4 or IPv6 headers.
d - The extra management traffic - mapping requests, replies
and mapping updates - is not a problem. This makes it
generally undesirable to make any host an ITFH host if
it is on a slow, unreliable, costly link, as are most
devices operating over a radio link.
2 - The current plan is for the ITFH function to be quite independent
of the IP stack, applications etc. In the non-Ivip core-edge
separation schemes, it may be helpful for the ITR to know
something about these in terms of multihoming service restoration
and TE. However, with Ivip, the ITR makes no decisions at all -
the mapping contains only a single IP address. So I can't see
a reason why the ITFH function would benefit from any knowledge
of what is happening in the IP stack or applications.
So Ivip, which is the proposal which most closely resembles what you
describe, does not involve a migration to a host-based solution which
resembles Strategy B.
Maybe TRRP, APT or LISP might have similar provisions for moving the
ITR function to the sending host, but I don't think they currently
involve changing the functions of *all* hosts to include the ITR
function, or to an elimination of new multihoming etc. functionality
in the network - both of which are distinguishing characteristics of
Strategy A.
- Robin
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
