Pull (LISP) versus Push (legacy IP). This discussion confirms that LISP is not and has never been a loc-id-split protocol. Instead it is only a PULL variant of the existing state-of-art protocol. Such behavior is called camouflage, right ?
Heiner -----Ursprüngliche Mitteilung----- Von: Ronald Bonica <[email protected]> An: lisp <[email protected]> Verschickt: Mi, 9 Jan 2013 5:37 pm Betreff: Re: [lisp] draft-ietf-lisp-architecture: Demand Loading of Mappings 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
