[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.
"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.
In the case of content sites that only receive incoming sessions it is
probably possible to come up with a set of contraints within which
there are no problems, but that would still make me EXTREMELY
uncomfortable as people do stuff that they weren't planning on doing
when they set up their networks all the time. Also, as someone who has
spent a fair bit of time debugging network problems, I am very much in
favor of deterministic behavior. So one set of behavior when the
connection is set up from A to B and another when it's from B to A is
not good.
"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'd be interested in learning the rationale behind that feedback,
though.
[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.
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.
It's always difficult to come up with the right amount of
extensiblity: too much, and the protocol becomes unwieldy and
inefficient, too little and obvious improvements can't be made or
require cumbersome kluges. I would point to BGP as a mostly successful
example: we didn't have to come up with BGP-5 for more than a decade
even though we added tons of new stuff because there was an adequate
amount of extensibility.
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.
There are also potential issues with synchronizing the numbering of
the RLOCs in the mapping system and in this field.
Right, there is no such thing as a free lunch. As mentioned at the
Chicago IETF, inserting new RLOCs don't have this problem. That is
appending is easy to do. Removing from the middle of the RLOC list
gets tricky but you could use a dummy slot for a certainly period of
time.
We are experimenting with this to see the best way to stale existing
cache entries.
Right.
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.
So if you have any ideas on how to solve this, we would like to hear
with it and prototype the idea.
Well, mostly just the same idea as I had before, but let's flesh it
out a bit:
The point is to avoid state on the ETRs but still signal information
that becomes available at the ETR back to the ITR as fast as possible
without making the ETR keep state or otherwise work too hard.
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.
(We'll have to figure out if we need to do this per-ETR or per-EID, or
possibly both.)
But, umm, isn't determinism better?
Yes, that was my point. (?)
" Priority: each RLOC is assigned a priority. Lower values are more
preferable. When multiple RLOCs have the same priority, they are
used in a load-split fashion. A value of 255 means the RLOC MUST
NOT be used."
Isn't it more natural to use 0 as the special case value?
We choose this way to be consistent with other priority values.
Namely administrative distance for routing protocols.
Hm, if you make it more like a HSRP priority or local preference then
0 would be the right choice. :-)
Isn't higher == better also in DNS SRV records? I think that would be
the right thing to copy here.
"Note that the destination RLOC address MAY be an anycast address
if the tunnel egress point may be via more than one physical device."
This makes me rather uncomfortable, as anycasting could get in the
way of reachability testing. We have room for a number of RLOCs,
why not put in RLOCs for all physical ETRs rather than anycast them?
Well it provides another of indirection at really no cost. The xTRs
at a site now if they are part of an anycast group and should know
not to clear a loc-reach-bit for another xTR that has gone down in
it's anycast group.
I guess... Wouldn't it be better to leave this open and come up with a
separate document that details how anycast would work here?
Is the "Loc-AFI" field the AFI for an RLOC? Why is this field only
8 bits while other AFI fields are 16 bits?
You found a bug, I will fix it. Thanks. Since I don't have an extra
bit for the R-bit, how about if we do this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
/| 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.
We enumerated the methods, we didn't say you should use all of them.
We recommend using only the loc-reach-bits.
That would be a good example of something I'd like to see moved to
another document.
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.
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.
"perform a route-returnability check"
Return routability check?
A simple anti-spoofing technique.
Yes, but I think you used a less common ordering.
[MTU issue]
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.
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.
--
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