Eliot,

In Section 6.1, Noel never uses the word "state". He uses the more specific 
term, "mappings". Are you suggesting that he should add some context around 
that word?

                          Ron


> -----Original Message-----
> From: Eliot Lear [mailto:[email protected]]
> Sent: Wednesday, January 09, 2013 11:41 AM
> To: Ronald Bonica
> Cc: [email protected]
> Subject: Re: [lisp] draft-ietf-lisp-architecture: Demand Loading of
> Mappings
> 
> 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