[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] draft-farinacci-lisp-05
On 19 dec 2007, at 6:20, Dino Farinacci wrote:
There is no version field in the LISP header. There should be. At
least a few "set to zero on send, ignore on receive" bits that can
be used for extensions without bumping the version number is also
a good idea.
We decided to use control-plane type codes.
Unless I missed something, this means you can never make backwards-
incompatible changes to the LISP header without running the old and
new versions on different RLOCs.
We can for control packets. But no, we can't for data packets. We
didn't see this as a problem for GRE, when we defined it in the early
90s. I don't see it as a problem here right now.
"In order to eliminate the need for a mapping lookup in the
reverse direction, the ETR gleans RLOC information from the LISP
header."
I find this undesirable because this way, the behavior of the
system can be different depending on which end initiated the
communication. Trusting information supplied directly by the other
end is also problematic security-wise. I would much prefer it if
both ends did an independent mapping lookup.
We stated this because there was a requirement from big content
providers. I will loosen the language and say "MAY glean".
This is one of the big problems with GSE: if someone contacts you
with EID=windowsupdate.com and RLOC=l33th4x0r, and you trust this
relationship, an attacker gets to redirect traffic for that EID to a
random place. This is especially bad when the attacker can set up
this state just as you're about to set up an outgoing connection to
that EID, because then they get to intercept your outgoing traffic.
Understand.
"LISP Locator Reach Bits: in the LISP header are set by an ITR to
indicate to an ETR the reachability of the Locators in the source
site."
I wonder how useful this is in practice. First of all, having 32
RLOCs is way too many.
We have received feedback that it may not be enough. ;-)
As the LISP related documents that I've read are light on failure
detection and repair, it's hard to say anything definitive, but with
32 ITRs and 32 ETRs TCP has probably long since given up when you
get around to learning that it's ITR 31 that can talk to ETR 31 but
the other 1023 combinations don't work.
I find it very unlikely that all xTRs would be down.
I'd be interested in learning the rationale behind that feedback,
though.
Will add.
[xTRs in ISP networks or (also) in end-user sites]
As I said at the IETF, for a CE deployment of xTRs, the most common
failure points in the network, which affects connectivity to the
site, is the CE router going down, the CE-to-PE link going down, or
the PE router going down. Other failures are rerouted in the core
based on richness of connectivity or are damped out due to
aggregation.
That's what the big ISPs tell us. Myself, I haven't had too much
trouble with my last kilometers, so my experiences may not be
representative, but I can tell you that routing failurs and
brownouts DO happen and anyone who cares enough about their
connectivity to be multihomed, wants to be protected against that,
too. Especially having a single ETR go down or function incorrectly
(claiming incorrect (un)reachability for other ETRs serving the same
EID) and then being unreachable or having severely degraded
reachability would be highly unacceptable to any multihomer that
I've ever known.
Right and encapsulating a packet isn't going to change it. And you
can't depend on LISP to solve a core routing failure.
In these cases, the loc-reach-bits are extremely effective and gets
the new status information to the other sites at data-plane rates.
Only if the return traffic uses the ITR for the forward traffic as
its ETR, which makes sense in your view. However, this is a good
example of a more general tendency in LISP to commit to a narrow
mode of operation rather than to make the whole thing more open so
it's easy to change the protocol later for the IETF and to make
different deployment tradeoffs for operators.
All xTRs from source-site to destination-site (and vice versus) will
most likely use all xTRs so traffic will be flowing out and in all
them. That's the whole point in doing multi-homing. We want to do it
*better* and better means active-active and not active-backup, which
is slow converging.
I'm currently not seeing this amount of extensiblity in LISP. The
fact that all of this is happening in an IRTF wg and that we've had
numerous previous efforts before that either failed to address the
issue completely (IPv6) or created something that only solves part
of the problem (shim6, and some would argue that I'm being generous)
shows that closing off too many paths at this stage is probably not
a good idea.
How about thinking of designing a protocol that is simple to get the
job done efficiently and incrementally. Rather than bloating it with
gratuitous features which most likely won't be used.
We have received a lot of operational feedback from network operators
about what they want and what they don't want. We respect their
opinions and don't want to give them more.
We did consider sending a "free cache" bit in the data plane so
sites that have cached state could time out the state and re-
request a new mapping if they needed it, but as you might guess it
would cause a request implosion to the site.
This is the same argument that you used against my idea of having a
code point in the LISP header to signal back reachability and other
information on request.
Right, I wasn't for what I suggested above. I told you we considered
it and threw it out.
We do this by having the ITR ask the ETR to send updates of the
relevant information (not important what exactly that information is
right now) by setting a code point in the LISP header. To avoid
having to send back information that's already known, the ETR keeps
a "table version" like value. I think we only need two or three bits
for this. When the ITR asks for an update, it supplies the "table
version" of the latest information that it learned. If the table
version at the ETR is the same as in the ITR's request, it doesn't
do anything. If the table version is different, the ETR sends back
an update. The ITR keeps an RTT estimate and makes sure there is
only one request in flight per RTT so the ETR won't be sending
unnecessary copies of the information packets.
Let's see what the other LISP coauthors say about this. I will discuss
it with them offline.
/| Priority | Weight |R| Loc-
AFI |
Loc +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
\|
Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
But since we won't use all the AFIs that are encoded, a byte should
be sufficient. Please comment if you think we should stick with 16-
bits or compress all occurences of AFI to 8 bits.
Aren't multiprotocol BGP AFIs 16 bits? In that case, it saves IANA
from creating another registry for something that they already
register so if 16 bits is no imposition then that would be the
natural choice. But if you need the bits for something else, then
let IANA work a bit harder for their money... Obviously, they should
all be the same size at least in the context of LISP.
I know, but it packs so nicely right now.
Well if an ITR didn't have any data to know if the destination site
was LISP-capable and encapsulated the packet by copying the inner
DA to the outer DA, and the site was using PA addressing, the
packet would enter the destination site and travel to the host. The
host would not recognize a destination port of 4341, so it would
respond with a port unreachable.
But we would not do this anymore with the advent of the lisp-
interworking draft.
That's good, because it doesn't make much sense to me to tunnel
packets to destinations for which you don't know if they support the
tunneling, even if we ignore for a moment how you would discover the
non-existant RLOC in that case.
Right.
So basically the use of mapping requests/replies is the only
reliable (implicit) reachability detection mechanism. However, it
is largely unspecified how ITRs should use this mechanism to
determine reachability.
That and receiving data packets from the site.
Sometimes traffic only flows in one direction. Although this is rare
for long periods unless you count asymmetric traffic flow, it's much
more common for short times when a session goes from active to idle.
Yes, for maybe one flow, but if you look at all flows between the two
sites, there are safe chances it flows bidirectionally.
I guess we have had enough discussion on this. ;-)
Well, let me put it this way: I'll gladly forego more discussion in
lieu of more consensus. Unfortunately, most people haven't spoken
out in favor of an approach towards the MTU thing.
Many have spoken out to do nothing because it is really not a problem.
In my opinion, it would be beneficial to remove pretty much all of
the text that doesn't pertain to actual LISP operation from this
draft, and move that which is still useful (some of it is a bit
stale after five iterations) to a new "LISP architecture" document.
Can you list what is in this document doesn't pertain to LISP
operation?
I have a long list of other documents that I should review at some
point, so I don't want to go over the LISP draft again at this time.
If you agree with my suggestion, just keep your eye open for text
that qualifies on the next iteration of the document. If you don't,
don't.
Will do. Thanks for you comments.
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