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

From: [email-masked] (Noel Chiappa)
Date: Sat, 30 Dec 2006 16:24:43 -0500 (EST)

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

    >> a solution that results in that the end points need to manage multiple
    >> IP addresses is simply a non starter, right?

    > Yes, because of the administrative and resource overhead (think iACLs,
    > firewall rules, etc. .. and consuming twice or more the TCAM space in
    > ASICs to hold those iACLs and other filtering/policy enforcement
    > mechanisms, MAC/CAM table sizes, along with things like uRPF, and so
    > forth) and because of the support burden

The problem, at an archtectural level, is that you all are using the term "IP
addresses" for these names, and then assuming we're going to use them the
same way we use IP addresses today.

If we had another namespace, then normal hosts would have only one name each
from the "identification namespace" (hence zero hassle in handling multiple
of them per host), and then access controls, etc should/would apply to that
namespace, and a lot of the problems you're talking about would just go away.

Stop saying - and thinking - "IP addresses". "IP addresses", as currently
constituted, are totally broken, and any attempt to fix the system using "IP
addreses" is doomed to failure.

	Noel

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

---

From: Roland Dobbins <[email-masked]>
Date: Sat, 30 Dec 2006 13:48:35 -0800

> addreses" is doomed to failure.

You are correct, something like 'host IDs' is a better term.  But I  
do believe that whatever we end up with in terms of 'host IDs', that  
people will still refer to them as 'IP addresses' for some time to come.

;>

-----------------------------------------------------------------------
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 00:04:18 +0100

Hi Noel,

> namespace, and a lot of the problems you're talking about would just 

I am not sure about this...

what would packets contain in their headers?

They must contain locators (since you need them to route the packet 
(more precisely, they must contain forwarding tags, which can or cannot 
be the actual locators, but anyway, the point is that these are not the 
identifiers))

They may contain the identifiers but they don't need to. So if they do 
not contain the identifiers, then filters and ACLs not located in the 
peer itself will need to run on locators (or forwarding tags) rather 
than in the identifier (since the identifier is not in every packet (i 
know it is possible to leave the middle boxes implementing the ACL and 
filter to track the identifiers associated with the locator, but this 
has more porblems of its own...))

If they do contain the identifiers, then we may come with an important 
overhead (big locator pair and big identifier pair this assuming you 
only carry one locator pair) but you will also need to carry security 
information, so the ACL can validate the binding between the identifier 
and the locator (if not anyone can include a cool identifier that is 
allow to pass any acl in his own packets...). Besides, you also need to 
take into account Jim's comment about what is visible by middle boxes 
i.e. idendtifers may be encrypted e2e...

So, i am not sure that it is possible to run filters and acl on 
anything else than locators or forwarding tags...

Regards, marcelo

---

From: Roland Dobbins <[email-masked]>
Date: Sat, 30 Dec 2006 15:12:58 -0800

> anything else than locators or forwarding tags...

Sure it is, with a true host/locator split and some form of coupling  
up and down the protocol stack (and devices/features which can parse  
the packets of such a protocol stack).  Identity/AAA/entitlement and  
many other things could be handled much more effectively and less  
inelegantly than what we're limited to today, IMHO.

In other words, something kind of SNA-like, in some respects - which  
is ironic, given that the OSI model was inspired by the structure and  
layering model of the SNA stack.

;>

     		   -- Milton Friedman

---

From: Tony Li <[email-masked]>
Date: Sat, 30 Dec 2006 16:12:22 -0800

> If they do contain the identifiers, then we may come with an  
> important overhead (big locator pair and big identifier pair this  
> assuming you only carry one locator pair)

There's an important unstated assumption here that I don't think is  
necessarily true.  The locator need not be 'big'.  The identifier  
need not be 'big'.  I refer you to the 8+8 proposal again for one  
possible encoding that takes no more space than we use today for v6.

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 31 Dec 2006 13:29:44 +0100

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

> necessarily true.  The locator need not be 'big'.  The identifier need 
> not be 'big'.  I refer you to the 8+8 proposal again for one possible 
> encoding that takes no more space than we use today for v6.
>

agree...

however, you would still need to include the security information to 
bind them in the packet itself...

Regards, marcelo