[RRG] Re: Different approaches for different protocols

[Tony Li <tli@cisco.com>]

> > I have to disagree.  You obviously want identifiers in DNS  
> > replies, regardless of the solution.  If you could also return  
> > locators, that cuts down on your startup time, as you effectively  
> > get the id->locator lookup for free.  Yes, doing locator updates  
> > within the existing DNS is an issue... TBD.
>
> What else is new.  ;-)


16 years and going strong... ;-)


>   Well I think it's an architectural benefit to decouple the  
> service provider address from the name.


Agreed, we definitely want a clean separation of the mappings.  If  
DNS could provide both the FQDN->id and id->locator mappings as  
separate co-functioning spaces, that would be ideal.  Note that  
there's precedent for this already because there's already a FQDN ->  
address mapping and an address -> FQDN mapping, FQDN -> MX mapping,  
FQDN -> location mapping, etc.


> I want to decouple so no locators in DNS, then you can move with  
> less DNS changes.


Fair.  The cost is that you have to do two separate mappings to go  
from FQDN -> id -> locator.  Are you ok with the increased latency?


> > > 2) Have socket connections use the following addresses for tcb  
> > > lookups:
> > >
> > > 	source = ::<source-eid>  dest = ::<dest-eid>
> >
> >
> > Counter-proposal: Have sockets operate on FQDNs.  All of this  
> > addressing nonsense should be hidden in the stack.
>
> What? And you want to carry FQDNs in packets? I don't follow and I  
> don't think you mean this. Or are you joking?


Pardon, I was unclear.  I want the socket API to be FQDNs, but as I  
re-read it, I think you're only talking about internals.  If so, then  
I agree with you, but would go further and simply remove the ability  
for the socket internals to have any locator in them.  Instead they  
should ONLY contain identifiers.


> > > 3) CE routers that participate in the mapping database, will do  
> > > this:
> > >
> > >        Make ::<source-eid> into <source-locator>::<source-eid>
> > > 	Make ::<dest-eid> into <dest-locator>::<source-eid>
> > >
> > >    where:
> > > 	<source-locator> is the CE's IPv6 address out of the address block
> > >                         from the provider it is attached to
> > >        <dest-locator>   is the locator returned from a mapping  
> > > database
> > >                         lookup for <dest-id>
> >
> >
> > I think I'm with you, but the results seem like too many bits.   
> > How about if <source-locator> is the routing goop (TM) associated  
> > with the CE's outbound interface?
>
> Then you weren't following me.  ;-) The concatenation above is a  
> 128-bit value broken up into a <locator>::<eid>. Note the "::"  
> because there is likely 0 bits in the middle.


Your definition above says that a source-locator is an IPv6 address.   
Since that's already 128 bits, concatenating a few more seems like it  
gives you an overflow.

Also, please allow for the case of a CE being multi-homed.


> > > 5) No host changes because the checksums are always based on non- 
> > > zero bits in
> > >   the EID field and 0 bits in the locator field.
> > >
> > > We can do this with LISP-ALT as the mapping database mechanism.
> > >
> > > Should we prototype this?  Comments?
> >
> > As always, I prefer to think things through before coding.
>
> And what makes you think we haven't? The question was put up to ask  
> if it's *worth* prototyping.

So let's try to converge on the design first...

Tony

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg