From: Tony Li [mailto:[EMAIL PROTECTED] >In some ways (and I admit that this is an imperfect >analogy), map-&-encap asks our hosts to trust their >transport to a technology that they can no longer >interact with. How do we manage the underlying network? >What happens when a host needs some exceptional >service from the network? This seems problematic >and complicated, when the root architecture of the >network must be truly simple and elegant.
How can hosts make requests of the network today? The only direct mechanism that I am aware of is QoS. The only other mechanisms that come to my mind are out-of-band systems such as application-layer admission control systems -- the latter often rely on ECN reporting. Cumulatively these systems rely on the TOS-byte of the IPv4 header and the IPv6 equivalent. What am I missing? How does anything change with map-and-encaps? To my mind, there is no change. What are you seeing that I am apparently missing? For example, if your reply to my first query (above) mentions MPLS then we will disagree -- I know of no host based systems that use MPLS. I am only aware of network services using it (e.g., L3VPN). It wouldn't surprise me if people try to create host services that use MPLS. The problem with doing that is that it doesn't scale. More to the point, such systems create configuration headaches for the large end user, which is A Bad Thing. I've also seen deployments try to use the IP header's source route option (e.g., to differentiate between gateways). That's another technique that doesn't scale. Yet even so, both approaches (MPLS, Source Route) don't change with map-and-encaps because they can only know about their own recursive instance (i.e., our hosts are not be aware that our ISPs (note the plural) internally convey our traffic across their infrastructures using MPLS). _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
