Hi,
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.
That's what I said (or at least meant :) )
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.
Ok
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).
Yes, but there is a big financial incentive for Google to maintain that.
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.
Yes it is. *please*please*please* study what happened to 6to4 and the 2002::/16
prefix before continuing this discussion.
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.
That assumes that *everybody* runs such a PITR... Otherwise the company running
the PITR will attract traffic from other's and pay for the bandwidth.
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.
Yes, and I explicitly mention below that you *can* control those.
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.
*you* are the one suggesting that PITRs will be deployed that handle the /12 or
/16 that is being proposed in this draft. Getting this EID address accessible
from non-LISP sites needs PITRs, so it is very much on topic.
Please read up on the mess that RFC 3056 caused. There is a good reason that
RFC 6724 depreferenced 2002::/16. It explicitly says (although it contains an
error, it says 2002::/32 when 2002::/16 is meant): "Depreferenced 6to4
(2002::/32) below native IPv4 since 6to4 connectivity is less reliable today
(and is expected to be phased out over time, rather than becoming more
reliable)." The EID prefix has the same problems as the 6to4 prefix.
Before requesting address space for EIDs I think we need to know how it's going
to be distributed (RIRs, separate registry (actually doesn't have to be a bad
idea!)) and how it's going to be routed (like PI space is today with every
end-site a separate entry in the global BGP table, like, PA space where a
LISP-ISP provides aggregation, like 6to4 is with the whole prefix anycast by
open relays, ...)
Please understand that I am u huge fan of LISP (my home network and lab
networks are all using LISP). I am just not very sure if we really need this
EID prefix. I am afraid it will do a lot of harm if defined, distributed and
routed badly.
- Sander