Re: [lisp] Fwd: I-D Action: draft-ietf-lisp-introduction-05.txt - Decoupling

[Dino Farinacci <[e-mail]>]

> 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"

But that is an introduction section. The "degree" means more detail.

Dino

> 
>                                                                        Ron
> 
> 
>> -----Original Message-----
>> From: Dino Farinacci [mailto:[e-mail]]
>> Sent: Tuesday, October 07, 2014 5:04 PM
>> To: Ronald Bonica
>> Cc: Albert Cabellos; [e-mail]; 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
>