Ron,

Before we circle in for a landing, I would suggest that we separate
forms of state between operational and provisioned, and then what it
means to maintain both in the context of "push" v. "pull" (terms I
heartily dislike).

Eliot

On 1/9/13 5:34 PM, Ronald Bonica wrote:
> 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
>
>

_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to