ietf
[Top] [All Lists]

Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

2012-11-16 10:47:26
Hi,

The main motivation for this prefix is to optimize ITRs so they know that 
a destination is in a LISP site. This COULD eliminate a mapping database 
lookup for a destination not in this range. Meaning, if a packet is 
destined to a non-EID, you may know this by inspecting the address rather 
than asking the mapping system.

I don't agree. For example: I'm using regular space for LISP EIDs now, so 
you can't assume that if it's not in this block that it's not in the 
mapping system...

That is why I capitalized "COULD".

Ok :-)

But I think it comes down to
 COULD ignore that certain EIDs are in the mapping system and always route 
them legacy-style

No, I don't think so. You just avoided doing LISP to the destination site that 
wants multi-homing.

I wouldn't agree with
 COULD know if certain addresses are EIDs or not by looking at the prefix
because any address space can be used as EIDs now. Or are you proposing to 
deprecate the use of all other address space as EIDs?

You can configure a device to be more restrictive. And this would be the case 
in the non-capital I internet.

Because the RIR communities will probably just refuse to allocate from this 
space if it means that all those routes end up in the BGP table... They are 
already plenty of people that don't like regular PI policies...

You have all the PITRs in the world advertise only the one /12 into 
underlying routing.

ROFL. No sorry, that's not going to work

I'm sorry, it can work and people will WANT to do this. Infrastructure 
providers do want to attract traffic.

a) they would have to pay all the bandwidth cost for users of that EID space 
that they have no business relation with

If you have enough PITRs spread around the Internet, it works no differently 
than a set of boxes at a public inter-connect that advertises the same prefix 
(to say google).

b) as a user of that EID space I would be at the mercy of PITR operators that 
I don't even know

You are at the mercy of a lot of infrastructure components today. This is no 
different. You are at the mercy of your DNS server, are you not? It is the same 
thing. So let's not make things more complicated.

c) See all the arguments about why 6to4 is unreliable. They'll apply here too

Then you deploy an ITR at your site. You will want to for other reasons, so you 
kill the problem you think you have.

which will make a mess of the global IPv6 routing table...

And why do you think you need to assign PITRs per sub-block?

I hope that is not necessary, but if addresses are assigned to end-sites 
directly in a PI-like way then who is going to provide PITR services for 
the users? Someone has to pay the bandwidth cost for operating 

PITR services are provide for non-LISP sources to send to these sites. If 
you have a well-known defined /12 that all PITRs advertise, then when you 
allocate sub-blocks, you don't have to change, reconfigure, or touch the 
1000s of PITRs deployed.

What makes you think that all those PITRs will pay the cost for routing all 
that traffic?

Pay the cost? The cost is the bandwidth that is already provision to come into 
those boxes. And infrastructure providers do want to attract traffic.

a PITR... And the users of that space want reliability, so they are not 
going to rely on the goodwill of some unknown 3rd parties. There is too 
much bad experience with 2002::/16 for that.

We do that all the time on the Internet unless you sent this email on a 
source-route to me. ;-)

No, sorry. I now pay my ISP to make sure my connectivity works. In your 
example I'm going to rely on some unknown PETR for outbound traffic and on 
whatever PITR is closest to the other side for my inbound

Don't change the context of this discussion. We are talking PITRs. PETRs are 
something completely different.

traffic. I might be able to control the PETR, but not the PITR because that 
depends on the routing from the other side. We have been here before with 
2002::/16. Don't repeat that huge mistake!

- Sander

This is now off topic. The draft has nothing to do with PITR deployment.

Dino


<Prev in Thread] Current Thread [Next in Thread>