[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Comments on draft-lewis-lisp-interworking
I read this draft a couple of weeks ago and had a few comments.
Thanks for reading the draft and sending comments.
First of all, as I have stated before, having this document has been a
big improvement. We need to talk about the way legacy and new networks
communicate, we need to talk about the incentives and deployment
scenarios. Thanks for writing it!
Yes, a big improvement over having nothing, sure. ;-)
In case 3 (LISP site to Non-LISP site), a LISP site can send
packets
to a non-LISP site because the non-LISP site prefixes are routable.
The non-LISP site need not do anything new to receive packets. The
only action the LISP site needs to take is to know when not to
LISP-
encapsulate packets.
Hmm. But aren't there other things involved, too? If you do not
Like what?
LISP-encapsulate, you must be performing some kind of NAT
translation to
No, not in this case. We break out the case when the non-LISP site
wants to send packets to the LISP site into 2 sub-cases, if the LISP
site has routable addresses and when it does not.
And of course when it doesn't have routable addresses, you have to
NAT, you have no choice. Just like your home network does.
Observation on Section 4.3: limiting the impact of routable EIDs is
not
enough, we have to create an incentive to do so. Since we cannot block
people from advertising things in BGP, pretty much the only remaining
option is to make some other approach more desirable: better, cheaper,
faster, etc. Can you say something about what
That is what the PTR option is for. It's simply a question of having
this control locally at the site (the NAT solution) or having the
infrastructure help (the PTR solution). They both have their downsides.
Comment on Section 5: The document should talk about what is the
motivation for deploying PTRs.
Will add to it, but you probably guess the motivation is so you can
pull PI addresses out of the core as soon as possible without using
NATs on the edges.
Comment on Section 5: I don't understand how we distinguish
advertising
the EIDs vs. larger prefixes. Given the non-aggregability of EIDs, can
Don't assume EIDs are not aggregatable, they could be very much
aggregatable in IPv6 down to a /16. In IPv4, we'll have to use a few
prefixes, hopefully just 10 or so and not in the 100s and definitely
won't deploy it if in the 1000s. But many think this is still a very
small price to pay (in the 1000s) to be able to suppress more specific
PA advertisements of PI advertisements from the 10^6 multi-homed sites
we expect to come.
you even have larger ones, other than "all EIDs"? The business
implications seem severe, because you cannot have contracts for
specific
service.
Well, maybe a business opportunity too!
Section 5.2: it seems that the MTU implications of PTRs are different
from pure LISP. In pure LISP, you have the ability to locally
configure
Please don't differentiate a PTR from a pure LISP. A PTR is a router
that does ITR functionality but does not do ETR functionality because
the packet has a direct-site return path.
your network with an MTU that fits in 1500 bytes even if a LISP header
is added to it. With PTRs, the encapsulation is happening without the
knowledge of the legacy endsite. This means that either we must
require
the legacy endsites (and paths to them) to be able to deal with PMTU
discovery or the PTR - LISP site tunneling mechanisms need to be
able to
carry 1500 byte payload packets. Some discussion of this might be
useful
in the document.
See draft-farinacci-lisp-06.txt for resolving MTU issues.
Section 5.3, scaling. It seems that we hit the worst point when 50% of
the Internet is LISP capable and 50% not. Assuming equal traffic
distribution, 25% of traffic in the Internet would have to go
through a
PTR, right? It would be interesting to see some discussion of the
How do you think 25% of all traffic today will go through one router?
Well, it doesn't happen so LISP can't help create more switching
capacity. You build out many of them. And deployment experience will
tell us if the "interworking tunnels" should have large diameter (PTRs
deployed closer to non-LISP sites) or smaller diameter (PTRs deployed
closer to LISP-sites).
This will also depend on if PA address are also used as EIDs. Because
you'll have an overlap situation between these two namespaces.
This is why 240.0.0.0/4 has value. You could use it strictly for
additional addresses for the locator namespace or use it the EID
namespace. The former is easier to deploy because it would be required
in a smaller set of product platforms. But the later is more
beneficial for PTR aggregation performance but will require host
platform changes too.
anycast routing properties in this situation. For instance, do we
expect
PTRs might look like they use anycast addressing since other proposals
refer to it as such. But it's not using anycast addressing. That is
the PTR routers do not have the same IP address assigned to each of
them. They simply advertise the same EID-prefixes making the non-LISP
sites think there are multiple paths to the EID. This way, you
distribute load by having sources send to the closest PTR which will
encapsulate to the LISP site.
that only "all EIDs" can be advertised? If so, how stable can we
expect
the anycast routing to stay? Can we expect sudden switching to other
PTRs, which with these traffic amounts would obviously be a pretty
significant event? I'm sure we have some data on this from DNS anycast
already...
I am not following you, how would switching to other PTRs help the
"all EIDs cannot be advertised" question.
Section 7, security considerations. There is the obvious vulnerability
that you can advertise someone else's EID space as a PTR, and you
get to
Someone elses? They all advertise the entire space if we can pull it
off. And if SoBGP is up and running, we can say what AS origins can
advertise the EID-prefixes.
see their traffic. But the interesting question is if this is any
different from you doing the same thing in regular BGP. I think
there is
one difference -- in BGP you are limited with what you can do for the
attacker - victim site path, because you need to simultaneously
attract
the victim's packets to you but also be able to forward them to the
victim after taking a peek into them. With LISP encapsulation, this is
not an issue and you can do it from any location.
I think it's the same, in both cases you build a secure infrastructure
or you do ingress filtering the best you can.
In any case, I'd like to see some discussion of this draft and the
above
topics in the meeting!
Sure, when or if we get a time slot.
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