Ron, This is what I did with NERD, and aligns very much with your description.
Eliot On 1/9/13 5:57 PM, Ronald Bonica wrote: > 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
