Noel,
Having thought about my previous comment for another moment, what we really
have before us is an architectural trade-off.
In the push paradigm, "control plane overhead consumed to load and maintain
information about unused destinations is entirely wasted".
In the pull paradigm, "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 (e.g., control information piggybacked on user data). With
that additional machinery comes additional operational complexity and security
considerations."
I wonder if this text could be crafted to reflect that architectural trade-off?
Ron
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Ronald Bonica
> Sent: Wednesday, January 09, 2013 11:22 AM
> To: [email protected]
> Subject: [lisp] draft-ietf-lisp-architecture: Demand Loading of
> Mappings
>
> Hi Noel,
>
> In Section 6.1, you say:
>
> "Push as a mechanism is also fundamentally less desirable than pull,
> since the control plane overhead 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 (e.g.,
> control information piggybacked on user data). With that additional
> machinery comes additional operational complexity and security
> considerations.
>
>
> --------------------------
> Ron Bonica
> vcard: www.bonica.org/ron/ronbonica.vcf
>
>
>
> _______________________________________________
> lisp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
