Noel,
Would you agree with the following statements:
1) In both the push and the pull model, one party provides routing information
and another party consumes it
2) The consumer is in the best position to know which routes it needs. In the
pull model, the consumer can pull only the routes that it needs, thus
conserving resources. The push model, the producer pushes everything, including
routes that the consumer doesn't need. A push-protocol can be tweaked to
prevent distribution of unwanted routes (e.g., BGP's ORF). However, this
tweaking adds complexity.
3) The producer is in the best position to know the current status of a route
(fresh versus state). In the push model, the producer pushes the most current
version of each route that it maintains, ensuring that the consumer always has
a fresh version of each route. By contrast, in the pull model, when a consumer
uses a route, it is never 100% sure that the route is fresh. Mechanisms can be
built into the protocol so that if the consumer uses a stale route, it will be
able to obtain a fresher route quickly. However, these mechanisms add
complexity.
So, at best, we have an architectural trade off.
Ron
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Noel Chiappa
> Sent: Sunday, February 24, 2013 11:28 AM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [lisp] draft-ietf-lisp-architecture: Demand Loading of
> Mappings
>
> > 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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
