> From: Ronald Bonica <[email protected]>
> In Section 6.1, you say:
Hi, sorry this reply is so slow. I wasn't able to reply then, and it's taken
me a while to get back to it. Anyway...
> "Push as a mechanism is also fundamentally less desirable than pull,
> since the control plane overhea d consumed to load and maintain
> information about unused destinations is entirely wasted. The only
> potential downside to the pull option is the delay required for the
> demand-loading of information."
> Another downside of the pull option is that the XTR must ensure the
> freshness of information that it pulls to itself. In order to ensure
> freshness, the XTR relies on LISP-specific protocol machinery ... With
> that additional machinery comes additional operational complexity and
> security considerations.
...
> what we really have before us is an architectural trade-off.
> In the push paradigm, "control plane overhead ...".
> In the pull paradigm, "the XTR must ensure the freshness ..."
I've been pondering this for a couple of days, but I think I don't agree
(although I don't have any axes to grind/defend, either way). I guess I'm not
convinced that pull is necessarily architecturally more complicated than pull.
I can start with examples like ISPF and IS-IS, which are certainly fairly
complicated. Yes, I know, they have very hard constraints, because unless
everyone is perfectly synched, loops can result. But still, they show that
push is not trivial either.
This makes sense, because many of the fundamental issues they face (e.g.
making sure that the other side has correct, up-to-date, data) are in fact
quite similar.
In fact, I can make some hand-wavy arguments that, in some aspects at least,
pull can actually be _simpler_.
Take, for example, time-outs. Push _has_ to have timeouts, to ensure that the
other party got updated information. But, in the simple cases at least, you
can slide on them in pull. E.g. if an ITR sends a Map-Request, and it (or the
reply) is lost, it doesn't _have_ to do anything - because _if there is no
further traffic_, one doesn't care if one don't have the mapping. And if there
is _more_ traffic, then one can use that to trigger more enquiries.
And in LISP, with its very large fan-outs, a push relationship means a _lot_
of state and state-keeping, etc, at the source end of the pairing.
Etc, etc.
So I do think the actual key tradeoff is the one I already had in the text:
response time (for push) versus less control overhead (pull).
> "With that additional machinery comes additional ... security
> considerations."
Again, it's not clear to me that security is worse in pull than in push. Take
a look, for instance, at BGPSEC (although that's more painful than routing
security necessarily _has_ to be, because of the distributed computation
nature of destination-vector routing architectures, so it's not the fairest
example).
But on all of these points, I do have an open mind, so if you think I've read
it wrong, by all means please show me where I've gone off the rails! :-)
> I wonder if this text could be crafted to reflect that architectural
> trade-off?
Assuming my read (above) is correct, would it be worth saying something about
that briefly? It might be that a lot of people have the initial assumption
that you did, that pull is more complex, so it might be worth a sentence or
two to briefly allude to the reading above.
(If we decide I read it wrong, and that the tradeoff is in fact more
complicated than just efficiency/response-time, of course I will say something
on that topic.)
Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
