Subject: [RRG] Re: Different approaches for different protocols

From: Tony Li <[email-masked]>
Date: Wed, 19 Dec 2007 15:20:59 -0800

[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 [email-masked] 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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Dec 2007 18:15:51 -0800

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

> host can have multiple interfaces.  Each identifier may be  
> associated with one or more locators.
>

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

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

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

> 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.  ;-)

> 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

---

From: Tony Li <[email-masked]>
Date: Wed, 19 Dec 2007 18:31:51 -0800

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

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

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

> 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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Dec 2007 18:34:32 -0800

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

Sorry about that, it was really a typo and not what I intended. Should  
say "is the CE's locator", which means 8-bytes of prefix that is  
associated with it's attached SP.

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

Definitely. That goes without saying.

Dino

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2007 15:37:26 +1300

On 2007-12-20 09:32, Dino Farinacci wrote:
> Ran, first off, really good post.
> 
>> So I would suggest that folks think about IPv4 and IPv6 solution
>> approaches separately.  For example, while one might want one of
>> the existing proposal for IPv4 (partly for expediency and partly
>> because IPv4 has more constraints), one might well want a different
>> more architecturally fundamental change for IPv6 (partly because
>> the protocol is more flexible due to extra bits in the header
>> and partly because we have more time to study, prototype, and
>> design a more elegant solution).
> 
> So let me propose something:
> 
> 1) For IPv4, use LISP encapsulation as spec'ed in the -05 draft.
> 2) For IPv6, use header address translation (of the high-order 8-bytes),
>    spec that out as GSE++.

As far as I can tell, that whole line of thinking was thrown out
of the boat when the RIRs and ISPs declined to accept the recommendation
that *all* site prefixes should be /48 or shorter. I don't see any way
to revive a (6+2)+8 type of proposal now, unless you can figure out
how to deal with variable length routing goop.

(That's the underlying reason why shim6 deals exclusively with
/128s, too.)

> 3) Have both use the same mapping database infrastructure.

That's certainly correct, if you can overcome the problem just
noted.

     Brian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Dec 2007 18:46:55 -0800

> how to deal with variable length routing goop.

Actually might be a good thing. Those 2 bytes will be useful (read:  
necessary) for site subnetting. So maybe we should call it 6+2+8 where  
the 6 is global-locator, the 2 is a site-based locator, and the 8 is  
an ID.

Dino

P.S. The 8+8 proposal didn't clearly tell me how sites wouldn't have  
to subnet renumber when they gave the Routing Goop back. Again, need  
the decoupling.

---

From: Tony Li <[email-masked]>
Date: Wed, 19 Dec 2007 18:54:29 -0800

> how to deal with variable length routing goop.

We've done variable length before...  ;-)

In any case, if we go down this path, we are making enough other  
changes (e.g., shifting away from PI prefixes) that we shouldn't feel  
overly constrained.  We could decide, for example, to reserve some  
address space for 6+10 and then migrate into that...

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2007 16:19:21 +1300

On 2007-12-20 15:46, Dino Farinacci wrote:
> the 6 is global-locator, the 2 is a site-based locator, and the 8 is an ID.
> 
> Dino
> 
> P.S. The 8+8 proposal didn't clearly tell me how sites wouldn't have to 
> subnet renumber when they gave the Routing Goop back. Again, need the 
> decoupling.

Sure, but that was covered in the 2nd ("GSE") version
draft-ietf-ipngwg-gseaddr-00.txt which quickly replaced the
original 8+8 draft.

The problem for sites arises if different ISPs give them different
prefix lengths --- that will really mess things up at the subnet
level.

On 2007-12-20 15:54, Tony Li wrote:

> In any case, if we go down this path, we are making enough other changes 
> (e.g., shifting away from PI prefixes) that we shouldn't feel overly 
> constrained.  We could decide, for example, to reserve some address 
> space for 6+10 and then migrate into that...

Sure. There's plenty of space to do that. But don't forget the
other big problem of 8+8 or GSE -- the transport layer has to be
fixed up too, unless you can arrange for all goops to have the
same checksum ;-)

     Brian

---

From: Tony Li <[email-masked]>
Date: Wed, 19 Dec 2007 21:38:11 -0800

> prefix lengths --- that will really mess things up at the subnet

No, you just zero out the prefix to the length that applies for that  
connection.  As long as your subnetting fits within the longer  
prefix, you're still fine.  If not, then you need a shorter prefix...

> fixed up too, unless you can arrange for all goops to have the

Not a problem if, as you suggested, the host can be forged^Wtrained  
into always expecting the most significant bits to be zero and if the  
CE is always stepping on the inbound bits.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Dec 2007 21:46:48 -0800

> prefix, you're still fine.  If not, then you need a shorter prefix...

You do realize this requires a lot of site changes. Readdressing  
routers and doing longest match after the 6 bytes. Then the question  
is what if you want to use variable length subnet masks across your  
domain, etc.

There are a lot of administrative changes to make this work. If people  
are doubting the usefulness of Loc/ID split, adding more cost for the  
benefit will cause more resistance.

Dino

---

From: Tony Li <[email-masked]>
Date: Wed, 19 Dec 2007 21:54:09 -0800

> routers and doing longest match after the 6 bytes. Then the  
> question is what if you want to use variable length subnet masks  
> across your domain, etc.

Yes, certainly anyone who has v6 already deployed would be  
inconvenienced.  However, I'm not willing to sacrifice the  
architecture of the net to grandfather those few folks in forever.   
If they want to play, they should renumber.

Again, we can start in a specific prefix so that we can have  
interoperability and have a rolling migration.  However, everyone  
*should* play the same game, eventually.

> There are a lot of administrative changes to make this work. If  
> people are doubting the usefulness of Loc/ID split, adding more  
> cost for the benefit will cause more resistance.

Of course.  However, no pain, no gain....

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Dec 2007 22:00:33 -0800

> *should* play the same game, eventually.

And the router changes to do a different type of longest match?

And in the ETR case, the forwarding algorithm is different as well.  
Because you have to tell your FIB to match on high-order bits only to  
determine the packet needs to be translated.

GSE "appears" to be a good idea but the devil is in the details. Could  
be completely different for host-based GSE.

Dino

---

From: Tony Li <[email-masked]>
Date: Wed, 19 Dec 2007 22:54:12 -0800

> Because you have to tell your FIB to match on high-order bits only  
> to determine the packet needs to be translated.

I'm not sure I see the need for different longest matches.  After  
all, this is a translation box and you're allowed to know which  
interfaces are 'inside' and which are 'outside'.

Packets flowing inside to outside are pretty straightforward: look up  
the destination id (possibly cached), add destination routing goop,  
perform normal longest match lookup resulting in an outbound  
interface, add source routing goop dependent on the outbound interface.

Packets flowing outside to inside are somewhat trickier:  you know  
the routing goop associated with the input interface and thus the  
routing goop on the destination, so erase it.  Now, from a reverse  
lookup on the source address (again, possibly cached), determine the  
length of the source routing goop.  Erase that.  Now on your internal  
routing table, perform a normal longest match lookup.

Did I miss something?

> GSE "appears" to be a good idea but the devil is in the details.  
> Could be completely different for host-based GSE.

Host based GSE would be fine by me, but I think that it would garner  
a great deal of grief, in exactly the same ways that shim6 did.   
Specifically, the thought of having to manage multiple addresses at  
each and every host is NOT something that we automated in v6.  Also,  
Dave Thaler might provide us with some entertainment at the mere  
mention of host changes.  ;-)

Tony

---

From: "Victor Grishchenko" <[email-masked]>
Date: Thu, 20 Dec 2007 12:27:20 +0500

> mention of host changes.  ;-)

That host changes might not be mandatory. v1 hosts get 1 address, v2 hosts
get a bunch.

                         Victor

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Dec 2007 11:43:31 +0100

> 2) For IPv6, use header address translation (of the high-order 8- 

I would really prefer not to invoke "GSE" because it gives people  
ideas that won't fly in practice. I'll refer you to my presentation at  
the RA workshop in Amsterdam. But I guess it's too late for that  
warning now.

Although I like to see an approach where we can avoid more overhead,  
it's not clear to me what you intend to accomplish with this.

Does this go back to the MTU issue? Although IPv6 isn't immune to this  
(for some unknown reason, I need to type "ping6 -s 1436 ..." to get  
PMTUD to my mail server to work in the morning or my mail client  
forgets all my mail folders, love it when one bug triggers another)  
the real issue is with IPv4 where change is de facto impossible and  
99% of all traffic has the DF bit set so fragmentation isn't much more  
of an option than with IPv6.

Please note that a GSE model isn't the only possible one where  
addresses are rewritten. In GSE, you modify the host to ignore the  
parts that are rewritten. Shim6 restores the part that is rewritten  
based on prenegotiated state. A third approach is to map each locator  
back to the identifier it's associated with. This is easy as long as  
locator and identifier space don't overlap. For instance:

Host A has id 2001::a.

Middlebox X close to the source looks up 2001::a and sees locator  
prefixes 3000::/48 and 3800::/48, so it rewrites 2001::a to 3800::a.

Middlebox Y close to the destination knows that 3000::/48 and  
3800::/48 map to 2001::/48 so it rewrites 3800::a to 2001::a.

Host A receives the packet and is none the wiser.

(With shim6 the problem of something like this is backward  
compatibility but with a jack up approach we assume that we change two  
ends so that wouldn't be an issue.)

> [Redirected from RAM...]

[This somewhat amuses me, seeing the more engineering-oriented nature  
of many of the current discussions.]

> existing DNS is an issue... TBD.

Well, if you just publish the set of possibly reachable locators and  
then detect reachability through other means than the DNS this  
wouldn't be a problem. However, there is another problem: LISP &  
family do the id->loc mapping in a middlebox, when the DNS name used  
to come up with the id that's in the packet header is a distant  
memory. Even when doing this in the host itself the FQDN may not be  
available when the time comes to do the mapping. So unless we're ready  

> addressing nonsense should be hidden in the stack.

and thus update all protocols that embed addresses today start  
embedding FQDNs instead (both good ideas for other reasons), this  
isn't going to work and we need an id->loc mapping rather than an FQDN- 
 >loc mapping.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Dec 2007 08:41:09 -0800

> available when the time comes to do the mapping.

When the ITR is co-located with the DNS resolver, this
isn't so much of a problem (i.e., the RLOC and EID
lookups could occur when the FQDN is still available).

Fred
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Dec 2007 10:22:13 -0800

> interfaces are 'inside' and which are 'outside'.

Well, until there is a clearly written spec, everyone is going to  
speculate how it works and make different assumptions.

So I am not going to respond because I think an "ETR-based GSE" works  
a certain way. A way I think I can implement. That is probably a lot  
different from what other people think.

And I wanted it to look roughly like the LISP architecture so you can  
implement one architecture in the ETR for IPv4 and IPv6. We will need  
to have both coexist at the same time and people will want multi- 
homing to work for both protocol families.

So I'm going to stop here.

Can someone write a spec!  I hear there is a lot of interest and  
people are keen on GSE but no one is doing detailed work.

I have said publicly many times, I will implement a GSE design if  
someone can write it down. I don't have cycles to do LISP design and  
GSE design but am willing to contribute.

Dino

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Dec 2007 18:29:47 +0100

On 20 dec 2007, at 14:05, RJ Atkinson wrote:

> Using FQDNs in sockets works fine and is what the world would
> have done if pvm had invented DNS *before* BSD invented Sockets.

Right. And then applications wouldn't have to be updated to work with  
IPv6 and we'd have had more options to work with in multi6.  
Unfortunately, things worked out differently. There are many  
applications that still use the old socket API mechanics where the app  
is in charge of the name to address mapping.

> Further, we do not need a *direct* I->L mapping.

Right again. But this does complicate matters.

> I strongly suspect that you are making some (unclear to me)  
> assumptions
> about how an 8+8 scheme works, that are not necessarily true  
> assumptions
> for all 8+8 schemes.  O'Dell described a possible 8+8 approach in his
> documents.  He did not define all possible 8+8 approaches in his
> documents.  Please think outside the box (or I-D). :-)

You're right, my comments were based directly on the GSE draft.

As I've said many times, if you address the security and deployability  
problems in GSE you end up with something that looks a whole lot like  
shim6.

> I think the only constant for the 8+8 class of solutions is the
> fixed split at 8 bytes between the Routing Goop and the Identifier.
> I think everything else, including the semantics of both RG and
> ID, can vary between one 8+8 scheme and another.

I'd say that the basic idea is the split between id and loc. Having  
both in the same packet is GSE and having both be 8 bytes is 8+8. At  
some point we were discussing "16+16" where either the id or the loc  
is present, not both. Although this complicates some stuff, this is  
all stuff that is complicated by the security issue (you can't trust  
the loc that the other side supplies with the id) so that's not an  
issue and it buys you deployability so it's a net win.

The only advantage a more pure 8+8 approach has over starting an  
IPngNG effort is that you get to keep your IPv6 silicon. From the  
standardization, software and deployment perspectives this is pretty  
much going back 15 years in time and hoping to redo what we did in 5  
years but now with better results. I'm sure we can improve some  
details here and there, but I don't believe the fundamentals of the  
problem have changed so I don't think the outcome will be  
fundamentally different, either.

> Now, to reiterate a point I try repeatedly to make.  I don't think
> that 8+8 schemes are the only viable way to proceed.  I think they
> are one possible way to proceed in IPv6-land.  I also think that
> we should not race to decide how to proceed in IPv6-land.  In
> IPv4-land, more haste might be necessary due to current operational
> challenges, but there is no need for haste in IPv6-land.

Then again, why waste time on IPv4? Even with routing that scales O(1)  
we're never going to have more than 2^32 IPv4 addresses, which isn't  
enough to give every person on earth one, while I have currently IP  
capable devices in both my pants pockets in addition to the computer  
I'm typing this on in front of me. If we assume that the maximum  
prefix length on the internet is going to stay at /24 we're not going  
to see more than a 6 x increase in the v4 table, anyway. What we  
really need is scalable routing while giving users what they want in  
IPv6, then we can simply move to that and have some fun coming up with  
creative ways to demolish IPv4.

More practically, we should probably stick to working on both IP  
versions until such time that this becomes unpractical rather than try  
to agree on which IP version is the one that should be addressed  
first...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Dec 2007 18:13:00 +0100

On 20 dec 2007, at 17:41, Templin, Fred L wrote:

>> LISP & family do the id->loc mapping in a middlebox, when the DNS  
>> name used
>> memory.

> lookups could occur when the FQDN is still available).

This would solve the problem most of the time, but you really don't  
want stuff to work "most of the time":

>> Even when doing this in the host itself the FQDN may not be

I.e., if the packets are sent to an IP address that was not recently  
derived from a DNS lookup, but rather, learned from the user, a config  
file, something that was stored on disk for some time, a referral in a  
protocol that does IP address referrals, etc.

Also, this kind of DNS magic is a large part of why NAT-PT was  
deprecated.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2007 17:34:37 +1300

Victor,

> That host changes might not be mandatory. v1 hosts get 1 address, v2 hosts

IPv6 has always supported multiple addresses per interface. What we
are talking about is really whether an address selection algorithm
like RFC 3484 is sufficient to handle multiple addresses, or whether
something more sophisticated like shim6 (or SCTP) is required.

LISP is in some sense a step backwards since it assumes that
sites won't be running multiple prefixes, so the only use
of multiple addresses will be link local v. ULA v. PI.

     Brian

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Dec 2007 22:46:49 -0800

> of multiple addresses will be link local v. ULA v. PI.

Sites *can* have multiple EID-prefixes in LISP, and they will occur  
when small EID-prefix blocks are allocated because a site under- 
estimated the number of systems it has to number.

Dino

---

From: "Victor Grishchenko" <[email-masked]>
Date: Fri, 21 Dec 2007 16:32:33 +0500

> something more sophisticated like shim6 (or SCTP) is required.

RFC 3484  R. Draves  Microsoft Research
"...Well-behaved applications SHOULD iterate through the list of
addresses returned from getaddrinfo() until they find a working
address...
...all else being equal prefer address pairs having the longest
possible common prefix..."

Seems good enough. In the bunch-to-the-host scenario
longest-common-prefix might be the best simple strategy.
In the context of an IP connection, keeping it open while a site
rehomes is hardly critical in the common case. Intuitively, an
ordinary topology change will affect just part of a bunch, so the rest
remains functional and applications may re-connect.
So, my point holds. Further sophistication is useful but it is hardly
mandatory. May always sell it as v2.0 / mobile extensions / pervasive
load balancing / etc

BTW, regarding D.Meyer's remark in IETF Journal Oct 2007.
> It has been proposed that the Domain Name System [DNS] would be
> used to ﬁnd the destination address, but then how does one ﬁnd the
> address of the DNS servers?
Supporting (routing to) the root DNS server farms might be obligatory
for those "Large Structures" (i.e. owners of root prefixes). Thus,
addresses of the root DNS servers will be short and immutable.

-- 

    Victor
-��칻�&ޱ��jg�����낷���-���l"�a{
+v�칻�&ފv��x%zX�y�-�鞲Ơzױ��ɪ܆+ކ�i��l��&�X����߶�����o鹿��l���

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 21 Dec 2007 07:40:49 -0800

Dino, 

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Thursday, December 20, 2007 10:47 PM
> To: Brian E Carpenter
> Cc: Victor Grishchenko; Tony Li; Routing Research Group list
> Subject: Re: [RRG] Re: [RAM] Different approaches for 
> different protocols
> 

Then, why not have LISP cut straight to the chase and
go straight to IPv6 in the EID space (leave the RLOC
space as IPv4)? To my understanding, management of
multiple prefixes is better handled in IPv6, and IMHO
we need to get to IPv6 in the not-too-distant future
anyway...

Thanks - Fred

---

From: Tony Li <[email-masked]>
Date: Fri, 21 Dec 2007 10:32:52 -0800

On Dec 21, 2007, at 3:32 AM, Victor Grishchenko wrote:
> rehomes is hardly critical in the common case.

Unfortunately, that's exactly the critical case that's vital for  
multi-homed sites.  If our transport protocols were agile enough to  
recover across the failure of any given address, then there would be  
far less incentive to demand PI addressing.  Shim6 is simply a lie to  
preserve the delicate fiction that the transport protocols operate  
under.

> Intuitively, an

This trivializes the service interruption that comes with breaking a  
connection.  For those that are trying to provide reliable, robust  
services and have revenue tied to it, losing a connection is nothing  
short of lost revenue.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Dec 2007 08:16:04 +1300

On 2007-12-22 07:32, Tony Li wrote:
> recover across the failure of any given address, then there would be far 
> less incentive to demand PI addressing.  Shim6 is simply a lie to 
> preserve the delicate fiction that the transport protocols operate under.

Right, and there's also the issue that RFC 3484 doesn't handle
source address selection - but that is crucial to avoid ingress
filters when sending to an arbitrarily chosen transit ISP. This
is being discussed currently in IPv6-land.

      Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Dec 2007 08:18:58 +1300

On 2007-12-21 19:46, Dino Farinacci wrote:
> Sites *can* have multiple EID-prefixes in LISP, and they will occur when 
> small EID-prefix blocks are allocated because a site under-estimated the 
> number of systems it has to number.

Right, but that doesn't necessarily imply that all hosts in the site
(or to be more precise, all interfaces) have multiple simultaneous
addresses. The basic IPv6 model does assume that if a site has
multiple prefixes, some or all interfaces will have multiple
addresses (and multiple AAAA records for the same FQDN).

     Brian

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Dec 2007 11:22:27 -0800

> (or to be more precise, all interfaces) have multiple simultaneous

But that's because the netadmin didn't configure it that way. If they  
did decide to a LISP-enabled site can support it.

So not sure what your point is.

> addresses (and multiple AAAA records for the same FQDN).

Fine, but LISP makes no assumption about this. That is what I take  
issue with in your statement.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Dec 2007 11:47:20 -0800

> space as IPv4)? To my understanding, management of

It certainly can. LISP is not taking any detours. I mentioned this at  
the RRG, on our roadmap for implementation is to test IPv6 EIDs over  
IPv4 RLOCs.

> we need to get to IPv6 in the not-too-distant future

We are not designing in serial but in parallel.

Dino

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Dec 2007 13:39:12 +1300

On 2007-12-22 08:22, Dino Farinacci wrote:
>>> when small EID-prefix blocks are allocated because a site 
>>> under-estimated the number of systems it has to number.
>>

Only to point out the obvious, I guess...

     Brian
> Fine, but LISP makes no assumption about this. That is what I take issue 
> with in your statement.
> 
> Dino
>