Subject: RE: Identifier/locator recap

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Mar 2003 10:20:18 -0500

> > If we can make them implied its an extra condition check 
> for routers 
> > and hosts but will make the overall architecture less heavy 
> and less 
> > to manage.  I believe in overload though it is complex to implement 
> > not impossible.
> 
> Routers don't have to do anything, just the end points. 
> Having the identifier in each packet really doesn't buy you 
> any simplicity since the relationship between the locators 
> and identifiers must be authenticated to steer clear of 
> endless security troubles.

At the last hop to the node the identifier is needed by the router. 

> 
> > > There is also the question of what makes good 
> identifiers. HIP uses 
> > > the fingerprint of a cryptographic key. MHAP uses 
> > > provider-independent IPv6 addresses that aren't visible in the 
> > > global routing table. I myself have suggested to use FQDNs as the 
> > > first choice.
> 
> > I suggest not being dependent on crypto anything is wise it implies 
> > PKI to the solution and I fear that is a non-starter?
> 
> No, HIP is smarter than that. But what I find troublesome 
> with that approach is that the identifiers are a flat 120+ 
> bit space which makes it incredibly hard to create a 
> distributed way to look up properties for identifiers.

Not a fan of HIP.  But should I go down that rathole and my issues with
it?
At least for now.  Rather spend my energy on the model/architecture
agreement.

Thanks
/jim

---

From: "Tony Li" <[email-masked]>
Date: Wed, 19 Mar 2003 09:53:36 -0800

Erik,

|    To me this is a no brainer because I can't see how there
|    can exist a scalable approach to multihoming that doesn't
|    separate identifiers and locators.

Excellent, welcome to the club.

|    At some level one could argue that host multi-addressing 
|    is scalable
|    (at the expense of moving complexity to the hosts and 
|    applications).but
|    my concern is that host multi-addressing will more or less have
|    the hosts track with source/destination combinations 
|    (which approximate
|    routing paths at some rough level) work vs. doesn't.

Yes, that's going to happen.

|    To get fast failover this essentially turns into doing 
|    end-to-end "hello"
|    traffic instead of relying on the local hello traffic 
|    performed by the routing
|    protocols. So I think there are severe limitations in 
|    making this scale.
|    (And trying to aggregate this end-to-end "hello" traffic will just
|    cause a reinvention of routing.)

As Iljitsch seemed to hint at, there is no need to add protocol to
do this.  For example, a TCP implementation can simply watch the
RTT, compare it to the sRTT and consider switching locators anytime
it needs to retransmit.

I don't know of a requirement that asks us to react faster than that
timeframe, just that we not drop TCP connections.  So why not use
what's there?

Tony

---

From: "Tony Li" <[email-masked]>
Date: Wed, 19 Mar 2003 15:44:19 -0800

|    > 	Middleboxes break the end-to-end principle and are generally not
|    > desirable architecturally.
|    
|    I agree middleboxes aren't desirable. On the other hand, I 
|    doubt very
|    many people will applaud a clean architecture if that 
|    means they have to
|    upgrade large numbers of individual hosts rather than a 
|    few middleboxes.

Folks,

Let's please understand that these are not mutually exclusive.  We can
have an architecture that does not require middleboxes and at the same
time does not exclude them.

Tony