Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering

From: [email-masked] (Noel Chiappa)
Date: Sun, 31 Dec 2006 08:45:49 -0500 (EST)

> From: Roland Dobbins <[email-masked]>

    > it seems to me that by mandating that each endpoint in a multihomed
    > network have multiple IP addresses from multiple provider-assigned
    > netblocks and that each endpoint then make a determination as to
    > which of its multiple IP addresses is utilized as the source IP for
    > each packet it emits, that this is in essence giving each endpoint
    > a say in the initial path selection for the traffic it originates.

Well, yes, it allows hosts at multi-homed sites to select using the link to
ISP P, as opposed to the connection to ISP Q. But if the link to ISP P is
down, you'd *better* be able to select using the link to ISP Q, or your packet
isn't going to get very far, is it?

The thing is that SHIM6, by itself, is not a complete solution to
fault-tolerant multi-homing (of the many different reasons there are to
multihome); it needs some mechanism to tell the average host (which isn't
monitoring the routing, to know that the link to P is down) which
routing-name to put in its packets. But it's a start...

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Roland Dobbins <[email-masked]>
Date: Sun, 31 Dec 2006 07:03:08 -0800

> isn't going to get very far, is it?

[Firstly, it's important that we remember that packets aren't always  
destined for the global Internet; they're quite often (especially in  
the case of large enterprise-type organizations, who are the folks  
who do the vast majority of multihoming today and who will probably  
continue to do the vast majority of multihoming for some time into  
the future) destined for endpoints on an intranet.  And yet SHIM6  
makes -all TCP/IP networking- for multihomed organizations vastly  
more complicated and troublesome in the ways outlined previously due  
to this one (important, granted) global set of destinations.]

The question is whether -you- (in your role as endpoint) ought to be - 
mandated- to make those types of decisions, or whether it's more  
desirable in most cases to let the network infrastructure make those  
types of decisions.  Endpoints have been capable of running daemons  
which listen to the IGP and make initial path selection decisions  
based upon that information for a couple of decades, and yet HSRP/ 
GLBP/VRRP/CARP were developed due to network operator demand for a  
way to accomplish this initial path selection without any dynamism on  
the part of the endpoint, instead handling it within the network  
infrastructure.  There is a reason for this.

Now, you in your role as endpoint certainly -ought- to be able to  
make those types of decisions if you've been configured to do so; but  
since the overwhelming majority of endpoints in multihomed network  
topologies are deliberately not configured to this today with  
currently-available mechanisms, despite the advantages such a  
configuration would bring, it seems pretty clear that the  
disadvantages of this type of endpoint behavior in the vast majority  
of cases outweighs its perceived advantages.

Note that the objections I've raised mainly apply to the current  
model in which we utilize 'IP addresses' which conflate locator and  
host ID information on a loosely-coupled stack, and which further  
encourages us to try and (mis)use that conflated information for AAA,  
entitlement, and the like.  If we could achieve a host/locator split  
and a more tightly coupled stack, many of these problems would in all  
likelihood go away; but since this doesn't seem likely to happen  
anytime soon, the objections stand, IMHO.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

		All battles are perpetual.

     		   -- Milton Friedman