Ron,
To second Dino's point: both statements are true. There doesn't seem to
be any contraction. Would you care to elaborate?
Concerning the forwarding and control plane comparison, such discussion
seems much more fit for the BGP to LISP comparison section in the impact
document.
Florin
On 10/7/14 2:12 PM, Ronald Bonica wrote:
Dino,
The naïve reader (i.e., me) may not understand the subtle difference between the words
"isolate" and "separate", especially when applied to routing systems.
Rather than making the blanket statement, it might be a good idea to compare the
degree to which the control and forwarding plane are separated in LISP and the
degree to which they are separated in push-based routing protocols"
Ron
-----Original Message-----
From: Dino Farinacci [mailto:[email protected]]
Sent: Tuesday, October 07, 2014 5:04 PM
To: Ronald Bonica
Cc: Albert Cabellos; [email protected]; Damien Saucez
Subject: Re: [lisp] Fwd: I-D Action: draft-ietf-lisp-introduction-05.txt -
Decoupling
To me, this means that draft-ietf-lisp-introduction-05 MUST NOT contradict
RFC 6830. Now consider the following text from RFC 6830:
"In order to maintain security and stability, Internet protocols typically
isolate the control and data planes. Therefore, user activity cannot cause
control-plane state to be created or destroyed. LISP does not maintain this
separation. The degree to which the loss of separation impacts security and
stability is a topic for experimental observation."
Now, consider the following text from draft-ietf-lisp-introduction-05:
"Decoupled data and control-plane: Separating the data-plane from the
control-plane allows them to scale independently and use different
architectural approaches. This is important given that they typically have
different requirements."
"Isolate" means non-overlapping. But the control-plane and data-plane are
generally separated. And in all architectures, when one depends on the
other, you have to question how isolated the planes really are.
The statements made in the intro document are general and not detailed, so
it is not contradicting what we defer to as more detail in RFC 6830.
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
