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

[RRG] Re: Different approaches for different protocols

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.
What else is new. ;-) Well I think it's an architectural benefit to decouple the service provider address from the name.
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.
I want to decouple so no locators in DNS, then you can move with less DNS changes.
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? 


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.
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.
Yes, it does, Egress Translation Router. And why we picked the acronym initially, so we could go either way. 

So we do think things through.  ;-)
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. 

Dino

--
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