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

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 1 Jan 2007 19:34:54 -0600

Happy New Year. Sorry for the slow response.

From: "Noel Chiappa" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, December 31, 2006 8:07 AM
Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering

>    > From: "Spencer Dawkins" <[email-masked]>
>
>    > if path selection is under host control,
>
> Multiple routing-names for a destination is not really general "path
> selection"; it does provide a small amount of influence on the path a
> packet takes, but that's a long way from general path control (a la
> "source route" options, etc).

Yes, I agree (not general "path selection"), the concern was something more 
along the lines of someone who thought it would be fun to switch all the 
sites with DSL "backup" links to using their DSL as primary links, just to 
see what would happen, for example. If your network is the one getting 
flogged, the fact that it's not possible to flog other networks is less 
interesting, I guess.

Also please notice that I missed the last two NANOGs and didn't speak for an 
operator before that - if someone else has a clearer vison of the stated 
concern, this would be a lovely time to share it!

Thanks,

Spencer

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

---

From: David Meyer <[email-masked]>
Date: Wed, 3 Jan 2007 08:04:43 -0800

> "source route" options, etc).

	This is one of the shim6 arguments I never did buy, for
	exactly the reasons you mention. Its more like
	"optimized" egress selection (where "egress" is egress
	from the site).

> And as I just pointed out, while it does allow hosts at multi-homed sites
> to select their link to a particular ISP, if the link to one ISP is down,
> you'd *better* be able to select the link to another ISP....

	I suppose there are corner cases in which you wouldn't
	want to do so (but it would seem that those would be
	infrequent).  

> If people wanted (for a variety of reasons, which might include
> management control, defense against crackers, etc) a solution where the
> decision on "use ISP P, not ISP Q" was in the hands of some site-wide
> networking agent, as opposed to being a per-host choice, people should
> have gone for a solution which puts that choice in the border router (or
> some other device with site-wide authority).

	Again, would seem so, for predictability/management
	reasons alone. 

> However, I gather that class of solutions is somewhat constrained because
> of TCP checksum issues; the border router can only do so much, unless the
> host is in on it too. (Which is why GSE proposed to make the TCP checksum
> cover only the ID half, but that horse is long-gone, alas...) Hence TLi's
> comment about "too NAT-like", I suspect...

	Is it? Real question. Its not clear to me (yet) what the
	architectural design constraints we're working with here
	are.

	--dmm