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

From: [email-masked] (Noel Chiappa)
Date: Sun, 31 Dec 2006 09:07:12 -0500 (EST)

> 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).

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....

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).

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...

	Noel

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

---

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

> some other device with site-wide authority).

Er, that's how things work today for multihomed sites - the  
'networking agent' is the network infrastructure.  This is what  
people have wanted, and so that's how it's done.

The basic problem with all of this (IPv6 itself, as well as the  
various IPv6 multihoming proposals which engage in problem-shifting  
away from the network infrastructure to the endpoints, and the users  
and help-desk personnel responsible for those endpoints) is that the  
groups generating these proposals and making decisions in this arena  
have not been representative of the actual user/customer population  
and do not grasp the problems faced by those populations nor their  
actual needs in this space.

I'm not saying this in a condemnatory manner - after all, the process  
has always been open and anyone can participate, but I'm positing  
that this is the situation on the ground today.  One can argue that  
it's pretty late in the process to start raising objections, but if  
the process doesn't produce a result which is acceptable to the  
network operator community (both SP and enterprise) and to the user/ 
customer base, it's all for naught, anyways; and since IPv6 is  
largely greenfield, we've still the opportunity to fix at least some  
of these problems now.

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

		All battles are perpetual.

     		   -- Milton Friedman

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 31 Dec 2006 17:32:16 +0100

> comment about "too NAT-like", I suspect...

the other problem is that if you want to make these type of approaches 
secure enough (to be acceptable), you need to provide means to securely 
discover the locator set and this requires state (i don't think it can 
be done stateless like GSE does it), so you end up with state in the 
middle box, which introduces the other limitations of the NAT... this 
can be done, but it is not as attractive one could think it would be 
when you don't consider the security stuff.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 31 Dec 2006 17:32:16 +0100

Regards, marcelo

---

From: Tony Li <[email-masked]>
Date: Sun, 31 Dec 2006 09:58:04 -0800

> the other problem is that if you want to make these type of  
> approaches secure enough (to be acceptable), you need to provide  
> means to securely discover the locator set and this requires state  
> (i don't think it can be done stateless like GSE does it), so you  
> end up with state in the middle box, which introduces the other  
> limitations of the NAT... this can be done, but it is not as  
> attractive one could think it would be when you don't consider the  
> security stuff.

Well, I think we're past the point of something being attractive and  
we're well into considering the lesser of multiple evils.  We can  
live with the current architecture.  We can take a host based  
solution ala shim6.  Or we can have a border solution.

Note that the latter two both break current ISP 'traffic engineering'  
requirements, and the status quo breaks ISP financial requirements.   
Something has to give...

Tony

---

From: Tony Li <[email-masked]>
Date: Sun, 31 Dec 2006 10:25:11 -0800

> comment about "too NAT-like", I suspect...

I sincerely hope that we can rein in that horse and reconsider it.   
Otherwise the entire concept of a host/locator split ends up looking  
wholly like NAT, either in the host or in the middle box.

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 31 Dec 2006 22:38:46 +0100

El 31/12/2006, a las 18:58, Tony Li escribió:

>> means to securely discover the locator set and this requires state (i 
>> don't think it can be done stateless like GSE does it), so you end up 
>> with state in the middle box, which introduces the other limitations 
>> of the NAT... this can be done, but it is not as attractive one could 
>> think it would be when you don't consider the security stuff.
>
>
> we're well into considering the lesser of multiple evils.  We can live 
> with the current architecture.  We can take a host based solution ala 
> shim6.  Or we can have a border solution.
>

fully agree

---

From: Roland Dobbins <[email-masked]>
Date: Sun, 31 Dec 2006 13:57:31 -0800

On Dec 31, 2006, at 9:58 AM, Tony Li wrote:

> the status quo breaks ISP financial requirements

And the host model breaks enterprise OPEX and CAPEX financial  
requirements, IMHO - OPEX because of the ongoing admin and support  
overhead, along with regular renumbering exercises requiring even  
more overhead, and CAPEX due to increased hardware requirements to  
handle substantially larger/longer iACLS/firewall rules/QoS policies/ 
etc.

Cost-shifting isn't the correct way to handle this issue.  As you  
say, something has to give; unattractive as it is, perhaps there's  
some variation of the border model which can be constructed so as to  
permit sufficient traffic engineering capabilities to satisfy all  
parties.

[ Or we get started on IPv10, stat. ]

     		   -- Milton Friedman

---

From: Tony Li <[email-masked]>
Date: Sun, 31 Dec 2006 16:51:05 -0800

> some variation of the border model which can be constructed so as  
> to permit sufficient traffic engineering capabilities to satisfy  
> all parties.

This isn't a matter of cost shifting, and I wasn't even close to  
implying that.  I was simply delineating the entire known solution  
space.

Again, the border model doesn't do anything that's fundamentally  
different from SHIM6, from an ISP perspective.  It relieves some  
enterprise issues, but does nothing to enable longer-prefix traffic  
engineering, as we have it today.

> [ Or we get started on IPv10, stat. ]

Whether the architectural changes are in v6 or v10, we need to have  
consensus as to the architecture for the solution.  Clicking our  
shoes together and saying "v10, v10, v10" does not give us a new  
conceptual framework to work with.  We are still stuck with  
identifiers, locators and routes.

Tony

---

From: Roland Dobbins <[email-masked]>
Date: Sun, 31 Dec 2006 17:06:33 -0800

> implying that.  I was simply delineating the entire known solution  

I didn't mean to imply that you were implying it, heh; I'm merely  
pointing out that it's an unintended and previously-undiscussed  
consequence of the SHIM6 host-based solution.

> engineering, as we have it today.

As this model currently stands, yes.  I've some hopes that perhaps  
there may be some ways around those limitations, but have nothing  
intelligent to say on the subject at this time.

> identifiers, locators and routes.

The first step on the road to recovery is admitting we've a problem.   
The second step is ensuring we've a grasp of the real magnitude of  
the problem and all the relevant aspects of the problem.  IMHO, we're  
coming out of the first step and are maybe 1/5th of the way through  
the second step.  I don't know if we'll get any further than this.

Assuming we never make it through step 2, as seems likely, we will  
most certainly still be stuck with identifiers, locators, and  
routes.  If we somehow make it through step 2, we may still be stuck  
with locators, identifiers, and routes, but (hopefully) improved  
versions of same; or we may - mirabile dictu! - halt this headlong  
push to put new lipstick on the current iteration of IPv6 and grasp  
the nettle.  This would entail coming up with something qualitatively  
better and which may well be predicated upon a paradigm which differs  
to one degree or another from the current one.

So, what's it to be - step 1, steps 1-1.2, or steps 1-2?  I'm  
currently the only person who seems to believe there's a need for  
steps 1-2, so I doubt my 'consensus of one' is going to get very far,  
heh.

     		   -- Milton Friedman