Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou...

From: [email-masked]
Date: Tue, 28 Nov 2006 17:47:13 EST

Great.   But there is a price to pay in routing. How to  recognize the 
egress-ISP ? What if ISP-A delivers to the ground floor whereas  ISP-B delivers to 
the second floor of the same building ? 
Therefore, I am still in favor of integrating at least the  primary  ISP's 
ASN as well.
 
Heiner
 
In einer eMail vom 28.11.2006 20:50:01 Westeuropäische Normalzeit schreibt  
[email-masked]:

>  blurs the line between the two different functions of "identification   
> of end point" and "location of network attachment"

Just a  thought:

- person's name = ID
- person's address = location (geo,  topo, any physical)
- ID does not change
- location changes  often

to reach a person an envelope needs a combination: ID +  location

Could the same principle apply to a network:
- ID's and  locators are independent
- Uniqueness realizes at the attachment point = ID  + location

Result
- No dependency on a provider
- No scaling  problem because the routing table is fixed in a robust hierarchy

Thank  you,

Peter

--- David Conrad <[email-masked]>  wrote:

> Jim,
> 
> On Nov 23, 2006, at 9:39 PM, Bound,  Jim wrote:
> > Agree and that aggregation is important but will not  always be  
> > possible.
> 
> I agree that it won't  always be possible.  However, we have changed  
> the Internet  scaling characteristics from tending towards O(ISPs 
> +enterprises+end  users) to O(ISPs).  As we have an existence proof  
> that we  can have over 200K entries with today's technology, I think  
> we  have some room to grow.
> 
> >> The whole point of this  discussion is that the term "address"
> >> as it is used today  implies the concepts of identity and
> >> location are   merged.
> > That is where I believe I disagree.
> 
> I  think you misunderstood me as I believe we mostly agree.
> 
> >  What Pekka N. proposed leaves this question
> > open for now. If ISP1  has prefix for location as FFEE but ISP2 has
> > prefix FEEF the  aggregation is only for the first order bits (leaving
> > undefined)  and without more bits location cannot be known for routing.
> 
>  Right.  Since I do not believe it realistic to assume we can   
> aggregate ISPs without changing ISP business models (which they  are  
> not particularly inclined to do), I'm implicitly assuming  that each  
> ISP would have their own prefix.  That is, at  the highest level of  
> hierarchy, the locator space would be  flat.
> 
> However, a nice aspect of separating identity from  location (and  
> providing a mapping function to translate between  the two) is that in  
> the future, we can rip out the location  mechanism and replace it with  
> something better without  impacting the end users (in fact, they won't  
> even have to know  there has been a change), so if we discover the two- 
> tiered approach  doesn't scale enough for whatever reason, we can  
> deploy a  new/better solution much, much more easily.
> 
> > The  identifier comes into play only for me between the two end-to-end
> >  applications, security enhancements, and transport end-points  
>  > possibly.
> 
> Yes.
> 
> > Whether that is  part of an IP address with the locator for me is
> > premature  discussion and identifying the requirements.
> 
> As I've said  previously, I don't like to use the term "address" as it  
> blurs  the line between the two different functions of "identification  
>  of end point" and "location of network attachment".  These two   
> functions can obviously be merged into a single bit string (albeit,  I  
> believe this will require changes to all deployed TCP/IP  stacks which  
> I'm skeptical we can do in any reasonable  timeframe), but I believe  
> it would be really helpful to keep  the functions as conceptually  
> distinct as possible.
>  
> Rgds,
> -drc
> 
> 
>  _______________________________________________
> Architecture-discuss  mailing list
> [email-masked]
>  https://www1.ietf.org/mailman/listinfo/architecture-discuss
>  

__________________________________
__________________________________________________
Do  you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail  beta.
http://new.mail.yahoo.com

_______________________________________________
Architecture-discuss  mailing  list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss