Subject: [lisp] draft-ietf-lisp-architecture: Demand Loading of Mappings

From: Ronald Bonica <[email-masked]>
Date: Wed, 9 Jan 2013 16:22:09 +0000

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

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 9 Jan 2013 16:34:44 +0000

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-masked] [mailto:[email-masked]] On Behalf Of
> Ronald Bonica
> Sent: Wednesday, January 09, 2013 11:22 AM
> To: [email-masked]
> 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.
> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Eliot Lear <[email-masked]>
Date: Wed, 09 Jan 2013 17:40:37 +0100

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

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 9 Jan 2013 16:57:42 +0000

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

> From: Eliot Lear [mailto:[email-masked]]
> Sent: Wednesday, January 09, 2013 11:41 AM
> To: Ronald Bonica
> Cc: [email-masked]
> Subject: Re: [lisp] draft-ietf-lisp-architecture: Demand Loading of
> Mappings
> 
> Ron,
> 
> > 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."
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Ronald Bonica

---

From: Eliot Lear <[email-masked]>
Date: Wed, 09 Jan 2013 18:03:08 +0100

Ron,

This is what I did with NERD, and aligns very much with your description.

Eliot

---

From: [email-masked]
Date: Wed, 9 Jan 2013 12:38:53 -0500 (EST)

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-masked]>
An: lisp <[email-masked]>
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."

                                                Ron