Subject: [Sdn] Static-route - control or mgmt plane?

From: Sriganesh Kini <[email-masked]>
Date: Thu, 6 Mar 2014 02:08:42 -0800

Adding to the discussion at the mic of
draft-haleplidis-sdnrg-layer-terminology -

The key determining factor between control v/s mgmt is the ephemeral v/s
persistent nature of state.

However the operational model of configuring a network device where state
is created (and reflected even in forwarding) and then made persistent in a
separate config-operation can cause confusion in the determination.

E.g. If a static-route is configured it is part of the control-plane if a
second operation is required to makes it persistent ! Only after the second
operation does it become part of the management plane.

Sri

---

From: Russ White <[email-masked]>
Date: Thu, 6 Mar 2014 02:13:51 -0800

The problem is everything is ephemeral for some period of time... It's all a matter of scale. Time functions generally don't work for differentiating control and management, IMHO. You might say, "survives a reboot," but there are problems here as well, for instance a lot of boxes boot with a configuration that just loads a configuration file from elsewhere -- does this mean everything is ephemeral?

:-)

Russ

<><
[email-masked]
Ericsson

> On Mar 6, 2014, at 2:08 AM, Sriganesh Kini <[email-masked]> wrote:
> 
> Adding to the discussion at the mic of draft-haleplidis-sdnrg-layer-terminology -
> 
> The key determining factor between control v/s mgmt is the ephemeral v/s persistent nature of state.
> 
> However the operational model of configuring a network device where state is created (and reflected even in forwarding) and then made persistent in a separate config-operation can cause confusion in the determination.
> 
> E.g. If a static-route is configured it is part of the control-plane if a second operation is required to makes it persistent ! Only after the second operation does it become part of the management plane.
> 
> 
> Sri
> 
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 6 Mar 2014 02:47:48 -0800

Everything is ephemeral if the assumptions of persistence no longer hold
true. E.g. A device config-file is stored in SSD and the SSD goes bad due
to which device boots from a default-config in other persistent storage.

So in the example you gave, the state specified in the config-file is
management plane subject to the assumption that the entire system that
creates state from the remote config-file does not have any failure.

The time-function I used in my example was to illustrate that it is not a
given that a static-route is control or mgmt state if we don't take into
context the operational model. It was not to imply that time-function is
sufficient to determine which plane it is in.

Sri

On Thu, Mar 6, 2014 at 2:13 AM, Russ White <[email-masked]> wrote:

>
> The problem is everything is ephemeral for some period of time... It's all
> a matter of scale. Time functions generally don't work for differentiating
> control and management, IMHO. You might say, "survives a reboot," but there
> are problems here as well, for instance a lot of boxes boot with a
> configuration that just loads a configuration file from elsewhere -- does
> this mean everything is ephemeral?
>
> :-)
>
> Russ
>
> <><
> [email-masked]
> Ericsson
>
> > However the operational model of configuring a network device where
> state is created (and reflected even in forwarding) and then made
> persistent in a separate config-operation can cause confusion in the
> determination.
> >
> > E.g. If a static-route is configured it is part of the control-plane if
> a second operation is required to makes it persistent ! Only after the
> second operation does it become part of the management plane.
> >
> >
> > Sri
> >

---

From: Scott Brim <[email-masked]>
Date: Thu, 6 Mar 2014 15:33:50 +0000

What is the value in distinguishing between management and control?

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 6 Mar 2014 08:03:02 -0800

Good question. I will let the draft authors answer that.

I was looking at it from the I2RS perspective where we scoped the modeling
exercise to not include device management objects.

Sri

---

From: Kostas Pentikousis <[email-masked]>
Date: Thu, 6 Mar 2014 18:14:43 +0100

Hi Sri,

| I was looking at it from the I2RS perspective where we scoped
| the modeling exercise to not include device management objects.

What motivated this decision?

Best regards,

Kostas

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 7 Mar 2014 02:39:53 -0800

Hi Kostas,

The charter of the I2RS group was to develop a standardized interface to
the "routing system". The device management models are vendor specific and
considered as outside of the "routing system", and the I2RS WG was not
chartered to look into that.

Sri

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 7 Mar 2014 15:00:55 +0000

> What is the value in distinguishing between management and control?

Scott,

The importance of the existence of both control and management planes is that they enable explicit selection of CAP tradeoffs.

I think that I have explained the CAP theorem here before.
Quick review - 
There are three characteristics of distributed systems that are universally desirable:
* Consistency, meaning that the system responds identically to a query no matter which node receives the request (or does not respond at all);
* Availability, i.e., that the system always responds to a request (although the response may not be consistent or correct); and
* Partition tolerance, namely that the system continues to function even when nodes or the communications network fail.
Brewer conjectured that a distributed system can satisfy any two of these guarantees at the same time, but not all three. This conjecture was later proven by Gilbert and Lynch.

SDN teaches us that packet forwarding is simply a computational problem. This is the major abstraction that SDN posits - all packet based network elements (Ethernet switches, IP routers, NAT, firewalls, etc.) are computational resources that perform a single computational task with 5 steps: 1) input a packet, 2) inspect fields in the packet, 3) decide how to handle the packet, 4) optionally edit the packet, and 5) forward or drop the packet. The difference between the different network elements is the decision logic in step 3. 

Since the task of forwarding a packet from network ingress to network egress is obviously carried out by a large number of forwarding elements, the network of packet forwarding devices is a distributed computational system. Hence, the CAP theorem applies.

So which two of the three desirable characteristics of distributed systems do we want to achieve, and more importantly, which one are we willing to forego?

Conventional networks explicitly perform CAP tradeoffs by using a combination of control plane and management plane operations. Management plane operations are initiated from a central management site (e.g., a NOC) and are used for relatively slow, infrequent operations, such as configuration, setup of new services, collection of monitoring data, etc. Control plane operations are usually local and are used when rapid response is required (e.g., automatic protection switching). The combination of the two is required to satisfy a service provider's needs. 

While commissioning a new service, conventional networks use the management plane, which stresses consistency and forgoes availability. Consistency is important since a customer will be billed for the service, and new services are not allowed to interfere with existing services. The price is a compromise regarding availability - while commissioning the service is not available for an extended amount of time. Commissioning testing (e.g., using Y.1564) is typically from 2 to 24 hours. In addition, while commissioning a service it is assumed that there are no communications failures.

Once a service is set up, conventional routed networks exploit the control plane and basically forego consistency in order to obtain availability (e.g., 5 nines) and partition tolerance (e.g., 50 msec. to correct failures). Each router has its own local Forwarding Information Base (FIB), which is locally created and only weakly tied to the FIBs of the others. Lack of forwarding consistency means that packets can sometimes become misrouted or "black-holed" (go around in circles until they are dropped). That is the reason the IP packet header has a TTL field, and the reason TCP is layered over IP to retransmit lost packets. IP routing can be shown to be eventually consistent (i.e., attain consistency after a very long time if nothing further happens in the network), but deployed networks frequently operate with considerably less time between network events (new services or failures) than required to achieve consistency.  On the other hand, IP service unavailability is almost always due to a local break that physically disconnects the host from the IP network, and, as previously discussed, IP networks are extremely tolerant to partition failures. 

On the other hand SDN has a single plane which it calls "control" (indeed, SDN enthusiasts believe they invented the separation of forwarding and control operations), but being based on a centralized controller is similar to the conventional management plane. SDN networks stress consistency, but have no flexibility to adapt to forgo consistency for availability when the need arises. 

Since transport networks typically have SLAs regarding availability (5 nines)
and partition tolerance (50 msec) 
but are less stringent concerning consistency (packet loss, billing correctness)
such tradeoffs are needed.

Y(J)S

---

From: Sharon <[email-masked]>
Date: Fri, 7 Mar 2014 10:37:51 -0800

Yaakov, Very good backgrounder but I think not fully accurate interpretation of the situation.
If SDN targets dynamic flows as the interface to forwarding, ie  it is not about static circuits,
then it is targeting innovative control without compromising performance, not just management. 

Centralization doesn't mean much unless single sequential process can scale control of any network. 
Since this is not the case for most networks then we have to further evolve the SDN distinction.
Best bet on the table right now, picking up de-facto momentum in the market is-
Combination of SDN control-forward separation with NVO identity-location separation.  

This effectively reduces the network-CAP problem to be a database-CAP problem, e.g.
While each overlay node contains the flow interface, the CAP strain is on the underlay mapping authority.
Mapping turns the discrete nodes into a distributed system.

Since as you said you need to pick your trade offs and "choose your poison",  
then it's best to pick an NVO solution that lets you choose your mapping technology.
LISP had been able to offer that flexibility, and hopefully so will other NVO standards.

--szb

On Mar 7, 2014, at 7:00, Yaakov Stein <[email-masked]> wrote:

> Once a service is set up, conventional routed networks exploit the control plane and basically forego consistency in order to obtain availability (e.g., 5 nines) and partition tolerance (e.g., 50 msec. to correct failures). Each router has its own local Forwarding Information Base (FIB), which is locally created and only weakly tied to the FIBs of the others. Lack of forwarding consistency means that packets can sometimes become misrouted or "black-holed" (go around in circles until they are dropped). That is the reason the IP packet header has a TTL field, and the reason TCP is layered over IP to retransmit lost packets. IP routing can be shown to be eventually consistent (i.e., attain consistency after a very long time if nothing further happens in the network), but deployed networks frequently operate with considerably less time between network events (new services or failures) than required to achieve consistency.  On the other hand, IP service unavailability is almost always due
>  to a local break that physically disconnects the host from the IP network, and, as previously discussed, IP networks are extremely tolerant to partition failures. 
>