[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] Re: Different approaches for different protocols

	
[Redirected from RAM...]


On Dec 19, 2007, at 12:45 PM, Dino Farinacci wrote:


To start with we need to evaluate whether an 8+8-style approach is
better than an map&encap approach *at all*, regardless of address
family. If it is -- which is not clear by any means -- then that will 
be the time to consider multiple routing modes.
I think a GSE++ approach could work very well. The only worry I have, with respect to how it is spec'ed out now is that an entire 128-bits is in the DNS. You don't really want to have locators in the DNS. You really want to decouple it.
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.
1) Put A records in DNS for IPv6 hosts as ::<eid>, where <eid> is 8- bytes. 


Counter-proposal: have DNS support the following records:

	I4	- v4 identifier
	I6	- v6 identifier
	L4	- v4 locator
	L6	- v6 locator
Obviously, a DNS name can return multiple I4 or I6 records, since a host can have multiple interfaces. Each identifier may be associated with one or more locators.
Note that this also let's us trivially support cross-version data plane proposals for no additional cost.
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. 



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?
4) When the packet enters the destination site, the ETR will translate because the locator is it's own address, so it changes the source and destination 
   locator bits to 0.



Yup.  Note that the acronym ETR no longer really applies.
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.

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