Subject: [netmod] logical-systems (was: review of draft-ietf-netmod-routing-cfg-02)

From: Kent Watsen <[email-masked]>
Date: Mon, 16 Apr 2012 16:16:14 -0700

I can't believe I missed the discussion about logical-routers, but it seems not too late and I have some pretty defined thoughts about it.

First off, note that the trend is to virtualize the entire system, not just the "routing" part of it.  For instance, I've seen virtualization implemented on firewalls, routers, and switches.  Sometimes, a small subset of the data-model is virtualized (routing), but more often it's the entire shebang.

Defining an explicit tree in the data-model for the virtualized systems is not ideal - bigger schema file, harder to understand, difficult to keep in sync.  The best implementation I ever saw was from NetScreen's ScreenOS product - they had a single data-model with per-node attributes indicating if the node was "host-only" or "lsys-only" (lsys=="logical system"), all other nodes were considered shared by default.

Also, it's a mistake to assume the host-system's configuration is a superset including the lsys configs.  I've see some implementations where fetching configuration on the host-system did not return any lsys-specfic configuration; you had to explicitly ask the logical-system for its configuration.

To define a unified solution to span all these variations, we used a global attribute to specify the xpath to where lsys-configs might be rooted in the host-system's config.  If not specified, then it meant that they weren't part of host-system's config.

We did the same with rpcs, defined a mechanism to indicate when RPCs were available - host-only, lsys-only, or both (the default).   

We also defined the notion of a "context".  If SSH'd to a logical-system, you would be in the logical-system's context.  If SSH'd to the host-system, you would be in the host-system's context, by default, but then could use special RPCs to enter a lsys's contexts, run RPCs there and what not, and then return to the host-system's context.

The above covers basic support.  The more complicated bit comes with object-sharing, including heterogeneous lists, and immutables, and overrides.  More on that later.

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Apr 2012 09:15:17 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> 
> I can't believe I missed the discussion about logical-routers, but it seems not
> too late and I have some pretty defined thoughts about it.
> 
> First off, note that the trend is to virtualize the entire system, not just the
> "routing" part of it.  For instance, I've seen virtualization implemented on
> firewalls, routers, and switches.  Sometimes, a small subset of the data-model
> is virtualized (routing), but more often it's the entire shebang.
> 
> Defining an explicit tree in the data-model for the virtualized systems is not
> ideal - bigger schema file, harder to understand, difficult to keep in sync.

I very much agree with this.

> The best implementation I ever saw was from NetScreen's ScreenOS product - they
> had a single data-model with per-node attributes indicating if the node was
> "host-only" or "lsys-only" (lsys=="logical system"), all other nodes were
> considered shared by default.

Hmmm... this works well if the data model is tied to the
implementation.  A standard data model can probably never have these
attributes.  So some other mechanism is needed to indicate e.g. which
objects are shared.

> We also defined the notion of a "context".  If SSH'd to a logical-system, you
> would be in the logical-system's context.  If SSH'd to the host-system, you
> would be in the host-system's context, by default, but then could use special
> RPCs to enter a lsys's contexts, run RPCs there and what not, and then return
> to the host-system's context.

I agree that this is probably the way to go.  It is similar to how it
is done in SNMPv3.

> The above covers basic support.  The more complicated bit comes with
> object-sharing, including heterogeneous lists, and immutables, and overrides.
> More on that later.

Ok.

So, what is your conclusion wrt draft-ietf-netmod-routing-cfg?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 17 Apr 2012 10:21:10 +0200

> First off, note that the trend is to virtualize the entire system, not just the "routing" part of it.  For instance, I've seen virtualization implemented on firewalls, routers, and switches.  Somet…

OK, but this requires support from the level of the entire system, which is not present in the existing modules yet. On the other hand, at least one use case for the routing subsystem virtualization has been identified - MPLS/BGP VPNs. 

> 
> Defining an explicit tree in the data-model for the virtualized systems is not ideal - bigger schema file, harder to understand, difficult to keep in sync.  The best implementation I ever saw was from NetScreen's

But this is not what the routing module does, right? There is only one (schema) tree which is supposed to be used by both types of router instances.

> ScreenOS product - they had a single data-model with per-node attributes indicating if the node was "host-only" or "lsys-only" (lsys=="logical system"), all other nodes were considered shared by default.

This could be implemented by adding a "host/lsys" switch and then using "when" or "must" constraints at appropriate places. And it can be done by a module which implements this kind of logic via augmenting.

> Also, it's a mistake to assume the host-system's configuration is a superset including the lsys configs.  I've see some implementations where fetching configuration on the host-system did not retur…

Does this mistake appear in the routing data model? I don't think so.

> We did the same with rpcs, defined a mechanism to indicate when RPCs were available - host-only, lsys-only, or both (the default).

Are there any obstacles why this cannot be done by augmenting the existing data model?

> We also defined the notion of a "context".  If SSH'd to a logical-system, you would be in the logical-system's context.  If SSH'd to the host-system, you would be in the host-system's context, by d…

This is an interesting idea but if I understand it correctly, this would require support from the NETCONF protocol which is not there.

My main concern is that the deadline for the core routing data model is this August, so we don't really have time for any sweeping changes and substantial additions. I'd appreciate suggestions for changes that are reasonably compatible with the given time frame.

From the reviews so far I got the impression that the possibility of defining multiple router instances is quite welcome.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Apr 2012 10:28:41 +0200

> From the reviews so far I got the impression that the possibility of defining multiple router instances is quite welcome.

I tend to agree that multiple router instances are reasonably
understood and that this is in scope of the routing data model. The
more general problem, how to deal with virtualization, requires a much
more fundamental discussion how to do this properly with NETCONF/YANG.

/js (speaking as contributor)

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 17 Apr 2012 10:33:20 +0200

> I very much agree with this.

Same here, but if I am not mistaken, in Paris you proposed to use separate schema subtrees for physical and logical routers, in order to avoid the extra level of hierarchy in the case where there are no logical routers.

> attributes.  So some other mechanism is needed to indicate e.g. which

Yes, this could/should be done in other modules that need it, via augments.

> I agree that this is probably the way to go.  It is similar to how it

Can you outline the necessary steps for implementing this?

> So, what is your conclusion wrt draft-ietf-netmod-routing-cfg?

I second this question.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Apr 2012 10:41:31 +0200 (CEST)

> Yes, this could/should be done in other modules that need it, via augments.

The problem is that this vitualization is a property of the
implementation, not of the data model.  A system w/o virtualization
will have a single instance of foo.yang, but another device might have
one instance of foo.yang per "logical system".   So it is not feasible
to use data model annotations for this.

> Can you outline the necessary steps for implementing this?

  rpc get-contexts {
    output {
      leaf-list context-name {
        type string;
      }
    }
  }

  rpc enter-context {
    input {
      leaf context-name {
        type string;
      }
    }
    // maybe the output is a list of capabilities in this context
    description
      "On success, the NETCONF session now is 'jailed' in the
       new context."
  }

  rpc exit-context;

/martin

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 17 Apr 2012 20:55:14 +1200

> But this is not what the routing module does, right? There is only one (schema) tree which is supposed to be used by both types of router instances.

So, fully virtualised routers is one thing, but partial virtualisation where one system has multiple protocol instances is another.  MPLS/BGP VPNs are one example of that sort of behaviour, our 'VRF Lite' partial virtualisation is another, and linux network namespaces could be a third.  In each case, there's an entirely separate routing table and protocol instances, but only one system, and I think it worth reflecting that in the data model.

Andrew

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 17 Apr 2012 11:27:38 +0200

> to use data model annotations for this.

Why not? We can have a switch in foo.yang distinguishing these two cases and then conditional contents depending on this switch where necessary.

>      "On success, the NETCONF session now is 'jailed' in the

This seems to have been accomplished in a "RESTful" way in the current model by exposing the individual contexts as entries of the "router" list. The "RPC" approach would remove one level from the data hierarchy, but are there any other benefits? I can imagine a client software implementing this context-oriented view for a human user and internally working with the list of router instances.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Apr 2012 11:35:44 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Why not? We can have a switch in foo.yang distinguishing these two cases and
> then conditional contents depending on this switch where necessary.

Because you would have to design all your data models - including IETF
models - to be prepared for virtualization.  And you would have to
figure out and design for all the different virtualization scenarios
that Kent mentioned.

> This seems to have been accomplished in a "RESTful" way in the current model by
> exposing the individual contexts as entries of the "router" list. The "RPC"
> approach would remove one level from the data hierarchy, but are there any
> other benefits?

You remove the definition of this virtualization context from the data
model, making the data model cleaner.  You support multiple
virtualization scenarios.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Apr 2012 08:05:36 -0700

On 04/17/2012 02:35 AM, Martin Bjorklund wrote:
> Ladislav Lhotka<[email-masked]>  wrote:
>>
>>> Ladislav Lhotka<[email-masked]>  wrote:
>>>>
>>>>> Kent Watsen<[email-masked]>  wrote:
>>>

I agree -- a logical system that appears to the client as a self-contained
device should just implement modules (and data instances) that are part of
that logical system.

There is going to be some separate config on the physical system that will tell the
implementation how to create logical systems (e.g. per-VLAN).

>>>>> I agree that this is probably the way to go.  It is similar to how it

This is too restrictive, and does not really fit the 'isolation' use-case.
It would be complicated to define a mapping from logical system to
physical system, so each logical system can be accessed from the physical device.
There may be instance-identifier translation, etc.

>>>       "On success, the NETCONF session now is 'jailed' in the

The SNMP way is to specify the context in every PDU, not to
enter some new 'in context X' state.

> virtualization scenarios.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Apr 2012 11:29:39 -0700

>> So, what is your conclusion wrt draft-ietf-netmod-routing-cfg?

I'm not a routing guy, which is why I didn't review the draft before.

Taking a quick look, I see container "routing" has list "router".  This makes sense to me, as each LR is not having delegated administrative access.  Logical-systems are primarily distinguished as having distinct admin access...

In yesterday's posting, I wasn't reacting to the draft so much as some of the discussion in the "review of draft-ietf-netmod-routing-cfg-02" thread.  I changed the email-subject to reflect that it wasn't intended to be a review of the routing draft, sorry if that wasn't clear.  Hopefully I've now clarified that I don't actually have an issue with the draft as is.

Thanks,
Kent