Subject: [netmod] capability set caching

From: Andy Bierman <[email-masked]>
Date: Sat, 8 Mar 2014 07:25:54 -0800

Hi,

I have been thinking about the integrated feature set for YANG 1.1.
I have not figured out how a YANG 1.0 client connecting
to a YANG 1.1 server is going to continue to work.
I want to support YANG 1.0 and 1.1 clients with the same server.

The only way I know to do that is have the server delay
its <hello> to check the client <hello> for the 'capability-id'
URI, as specified in the NETCONF-EX draft.
This is non-trivial to implement, and probably doesn't work in
some situations (Martin does not like it).

A YANG 1.0 client will look for the "module=foo" parameters
in the server <hello> and not find any URIs, and not load
any modules (ietf-netconf-monitoring is optional to implement).

I think the capabilities defined in the NETCONF-EX draft needs
to be part of the charter to support RESTCONF and YANG 1.1.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 08 Mar 2014 17:19:07 +0100 (CET)

Hi,

Even if the server advertises 1.1 modules like today (directly in the
hello), the YANG 1.0 client will not be able to load these modules.

I think the server has to advertise any YANG 1.0 modules it implements
just like today.  But 1.1 modules can be advertised using the new
caching mechanism.  

This means that there are cases where a 1.0 client would have
continued to work if the 1.1 modules were advertised as before (if it
didn't try to download the new revision of the module, but just used
its old revision); but with the new caching mechanism it will not
work.

I think this is a price we have to pay.  However, operationally, it
should be possible to configure the server to run in "1.0" mode and
advertise modules as before.  When the operator knows that all his
clients have been upgraded, "1.0" legacy mode can be turned off.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 8 Mar 2014 09:15:29 -0800

> clients have been upgraded, "1.0" legacy mode can be turned off.
This means implementation of even 1 YANG 1.1 module breaks
these YANG 1.0 clients, even though they do not even use
those modules. So they cannot use this feature.

So how does a server know if a YANG 1.0 or 1.1 client is going
to connect without seeing its <hello> message?  The server
can never send the abbreviated <hello> if it wants to continue
supporting existing YANG 1.0 applications. Not OK.

In our code, the thin client that is called by OpenSSH
is triggered because the client sent a <hello> message,
so there is no delay.  It may not be hard to deliver
the client hello in the initial connect message.
So no delay or timeout is needed, just some code changes.

Are there server implementations that send the hello
as soon as the TCP or SSH session is started?

A YANG 1.0 client should be able to continue working
with the server because it was written to only use
YANG 1.0 modules, so it is not importing any YANG 1.1 modules.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 8 Mar 2014 18:39:52 +0100

> supporting existing YANG 1.0 applications. Not OK.

In London, I suggested to do translation of 1.1 to 1.0 and hence a
server could announce 1.0 versions of 1.1 modules to clients that do
not grok 1.1 format. I got told this is not a good idea...

> as soon as the TCP or SSH session is started?

Relying on hello timing is brittle.

In hindsight, we should not have announced the yang modules during the
<hello> and instead mandated implementation of the monitoring data
model or a separate get-yang-modules RPC. The <hello> should really
have only been used for protocol capabilities, not for announcing data
models.

/js 

-- 
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: Martin Bjorklund <[email-masked]>
Date: Sat, 08 Mar 2014 19:44:26 +0100 (CET)

> those modules. So they cannot use this feature.

No, if the server implements module A in YANG 1.0 and B in 1.1, it
would advertise A as usual, and then the new cache-thing for B only.
So the 1.0 client that knows about A still works.

> to connect without seeing its <hello> message?

It will have to be configured to advertise all modules, b/c the
operator knows that there are (or might be) 1.0 clients in his
network.

> The server

Over time, old clients get upgraded, and all servers can advertise
just the new stuff.  I think the benefit of cached module capabilities
is worth this.  At least it allows the optimization over time.

I would say that a 1.1 server MUST either advertise all modules like
before, or advertise the new cache thing (or both).  A 1.1 client MUST
be prepared for old-style module advertisement, and the new style.

> as soon as the TCP or SSH session is started?

Yes, since this is the REQUIRED behavior according to 6241 (and
4741).  I know at least two other implementations (in addition to
ours) than does this.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 08 Mar 2014 19:47:40 +0100 (CET)

> not grok 1.1 format. I got told this is not a good idea...

It doesn't work b/c the server doesn't know if the client is 1.0, as
you also stated.  Also, a translation of 1.1 to 1.0 would not be
correct, and maybe not even possible (e.g., if we allow multiple base
statements in an identity).

> have only been used for protocol capabilities, not for announcing data

Yes.  This is what we want to do now in 1.1.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 8 Mar 2014 11:18:58 -0800

> So the 1.0 client that knows about A still works.

A YANG 1.1 module can import 1.0, but not the other way around.
If this happens, there will be a mix of versions advertised in the
module URIs.

> operator knows that there are (or might be) 1.0 clients in his

This is very brittle because just 1 old client will probably
disable caching for every application.

This can be left as an implementation detail.
If a server knows how to get the client hello
and send its hello to match, then it will be completely
transparent to the client.  So we will implement it anyway.

> 4741).  I know at least two other implementations (in addition to
It is not required.
There is no text that says that any incoming packet has
to invoke a response within a certain time interval.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 08 Mar 2014 20:25:43 +0100 (CET)

> If this happens, there will be a mix of versions advertised in the

Yes.  But does it matter?

> disable caching for every application.

Correct.  But the alternative is that we keep the old behavior and
never get caching, even if all our clients are 1.1.

> This can be left as an implementation detail.

No, b/c it won't be interoperable.

> to invoke a response within a certain time interval.

Section 8.1 of 6241:

   A peer MUST NOT wait to receive the capability
   set from the other side before sending its own set.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 8 Mar 2014 14:18:20 -0800

> No, b/c it won't be interoperable.

Yes it is -- servers only talk to clients, not other servers.
It is completely transparent to the client.

>    set from the other side before sending its own set.

Right -- we follow this -- the NETCONF client peer sends a <hello>
and the server responds right away.  This text refers to the NETCONF
layer.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 8 Mar 2014 18:11:35 -0800

>    set from the other side before sending its own set.

OK -- so we are back to square 1:

 1) The client should decide which type of advertisement to make, if
possible.
 2) A new client should indicate its version before sending the <hello>
 3) A new server must not need to have the client <hello> before deciding

What about a new SSH subsystem?
What if we followed to rules you suggest for sub-system "netconf"
and use the cache version rules (1.1) for sub-system "netconf-ex"?
Applications can either learn or be configured to use 1 or the other
in many cases.

An old client keeps doing the same thing and keeps working.
A new client does a new thing and the new advertisement works.
It does not help to mandate behavior after the <hello> if the point
is to send a shorter <hello> to only new clients.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 09 Mar 2014 10:48:36 +0100 (CET)

> What about a new SSH subsystem?

Unfortunatley, this would be a protocol change, and only work for the
SSH transport.

I still think the solution where the server MAY advertise an "etag" is
ok.  View this is an optimization that we allow depolyments to enable
if all clients speak 1.1.

It still might make sense for 1.1 servers that advertise just a small
set of modules to do that in the hello, in order to save one
round-trip, and avoid keeping state on the client side.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 09 Mar 2014 11:35:11 +0100

> statements in an identity).

Yes, I also think the server(s) will have to stick to 1.0 if there is any need for using 1.0 clients.

On the other hand, due to the backward compatibility requirements, data models could be a mix of YANG 1.0 and 1.1 modules.

BTW, can a YANG 1.1 module be a new revision of a YANG 1.0 module?

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 09 Mar 2014 12:15:50 +0100

> So the 1.0 client that knows about A still works.

Hmm, can this really work? Since module B may augment A, the client would have to be prepared to accept unknown stuff anywhere in a get/get-config reply, RPC reply, or a notification.

Or consider this:

module A {
  ...
  container things-to-do {
    presence "do something";
    leaf watch-birds {
      type boolean;
    }
  }
}

module B {
  ...
  augment "/A:things-to-do" {
    leaf launch-missiles {
      type boolean;
      default true;
    }
  }
}

Then the server would also launch missiles upon receiving edit-config with

<things-to-do>
  <watch-birds>true</watch-birds>
</things-to-do>

I believe both parties must agree upon the complete data model (contract) before proceeding. 

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 09 Mar 2014 13:32:00 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Hmm, can this really work? Since module B may augment A, the client would have
> to be prepared to accept unknown stuff anywhere in a get/get-config reply, RPC
> reply, or a notification.
> 
> Or consider this:
> 
> module A {
>   ...
>   container things-to-do {
>     presence "do something";
>     leaf watch-birds {
>       type boolean;
>     }
>   }
> }
> 
> module B {
>   ...

I'm glad you brought up this real-world example ;)

> I believe both parties must agree upon the complete data model (contract)

This is an orthognal issue from YANG 1.0 vs 1.1.

It would imply that unless the client understands the semantics of
*exact* versions of *all* data models, it would not proceed.  I don't
think is a workable model.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 9 Mar 2014 14:37:20 +0100

> This is an orthognal issue from YANG 1.0 vs 1.1.

Do you mean that the idea of a client cherry-picking modules is already in YANG? Where in RFC 6020 is this stated? Actually, sec. 5.6.1 says:

   The model defines a contract between the NETCONF client and server,
   which allows both parties to have faith the other knows the syntax
   and semantics behind the modeled data.  The strength of YANG lies in
   the strength of this contract.

My example shows that this would be an illusion if cherry-picking was allowed (and I can give more examples).

It is true that the cherry-picking idea was used as the rationale behind the CLR that augments must not define mandatory nodes, but I’ve been arguing against this several times already. 
 
> think is a workable model.

But what is a workable model then? The augment statement and XPath are extremely powerful but this power and flexibility also means that different modules are not necessarily isolated from each other.

Maybe in the beginning we underestimated (I did for sure) the role that augments and XPath would play in the data models.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 09 Mar 2014 14:46:55 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Do you mean that the idea of a client cherry-picking modules is already in
> YANG?

Sure.  Suppose I write a client that is used to configure the generic
parts of an interface; ietf-interfaces.yang.  This client doesn't know
anything else.  But the server advertises acme-ethernet, which
augments ietf-interfaces.  The client continues to work.

> Where in RFC 6020 is this stated? Actually, sec. 5.6.1 says:
> 
> It is true that the cherry-picking idea was used as the rationale behind the
> CLR that augments must not define mandatory nodes, but I’ve been arguing
> against this several times already.

It just means that the design of an augmenting module must be done
carefully.  First, follow the mechanical rules (not allowed to
augment).  Then make sure that no missiles are launched by mistake due
to the design of the model :)

/martin

> But what is a workable model then? The augment statement and XPath are
> extremely powerful but this power and flexibility also means that different
> modules are not necessarily isolated from each other.
> 
> Maybe in the beginning we underestimated (I did for sure) the role that
> augments and XPath would play in the data models.
> 
> Lada
> 
> > 
> > 
> > /martin
> 
> --

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 9 Mar 2014 15:01:50 +0100

> augments ietf-interfaces.  The client continues to work.

Or maybe not, see my example. The CLR about mandatory stuff in augments is terribly insufficient.

I don’t see any statement in 6020 saying that the client is free to ignore parts of the data model as advertised in server’s hello.

> to the design of the model :)

You can take care about this if you are developing a data model for a particular customer. However, if we envision many modules being developed by independent parties, we must make sure that different contributions play together well. Of course, my example is an extreme case, there can be other, more subtle, side effects.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sun, 9 Mar 2014 07:52:32 -0700

Hi,

I do not think this is a workable plan.
Too many requirements and too little gain.
This feature should be left out of YANG 1.1.
The old advertisement scheme should be used
without any changes at all.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 09 Mar 2014 16:11:15 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> I don’t see any statement in 6020 saying that the client is free to ignore
> parts of the data model as advertised in server’s hello.

The server tells the client what it implements, the client does
whatever it wants with this information.

How exactly would such a requirement be phrased?  How would it be
enforced or even tested?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 09 Mar 2014 16:18:01 +0100 (CET)

> I do not think this is a workable plan.
 
Why doesn't this work?  In environments with mixed 1.0 and 1.1
clients, the optimization can be disabled.  In environments with only
standard-compliant 1.1 clients, the optimization can be enabled.

> Too many requirements and too little gain.

One requirement: a 1.1 server MAY send the "etag", and thus a 1.1
client must be prepared to handle it.

> without any changes at all.

If we don't take the opportunity to specify this now, it won't happen
- unless we do YANG 1.2 or 2.0; and at that point we'll have the same
discussion again.

It would be interesting to hear what others think.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 9 Mar 2014 08:35:04 -0700

Hi,

On Sun, Mar 9, 2014 at 8:11 AM, Martin Bjorklund <[email-masked]> wrote:

> > I don't see any statement in 6020 saying that the client is free to
> ignore
> > parts of the data model as advertised in server's hello.
>
I think you are right.
If the client builds the server schema tree from the import statements
of the modules it cares about, then the import chain will never hit the new
YANG 1.1 module that is augmenting the old data structure. This is how
import-by-revision allows different versions of the same imported
module to be used by multiple importing modules.

In addition, the client can skip modules that fail to compile
when the server <hello> modules are processed.  It won't have he new
schema nodes for sending requests.  Any replies with these
unknown nodes get parsed as 'anyxml' instead of the real schema.
(This is how our client code works today.)

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 9 Mar 2014 16:53:55 +0100

> How exactly would such a requirement be phrased?  How would it be

What I meant was “… that it is safe for the client to ignore parts …”.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 9 Mar 2014 17:02:24 +0100

> (This is how our client code works today.)

My point is that the skipped modules may change semantics of the remaining modules. So the client should not be surprised by error conditions or unexpected behaviour of the server.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Mar 2014 17:30:11 +0100

> It would be interesting to hear what others think.

I think I do not really understand the various options yet. One option
could be that YANG 1.1 modules won't be announced anymore during the
<hello>; YANG 1.1 clients are expected to pick modules them from the
monitoring data model. There could also be an etag like mechanism so
that I can safely cache knowledge of available YANG 1.1 modules. Over
time, the list of announced data models announced in the hello will
get shorter. (A different issue is an etag like mechanism for the
config state itself.)

The unanswered question seems to be whether the server can learn that
it is talking to a client supporting YANG 1.1 before the <hello> or
whether this is needed to support.

But I am likely missing part of the discussion. Perhaps we need to
break this into separate issues so we can track things more easily?

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Mar 2014 11:56:27 -0700

> break this into separate issues so we can track things more easily?
Here is some sort of list:

   - Big picture: how to support YANG 1.0 and 1.1 clients with the same
server

       - A capability cache is for new clients only.  An entity tag for the
set of
         YANG module capabilities is advertised by the server somehow.

       - An abbreviated <hello> does not have any YANG module URIs.
        They are replaced with 1 capability-id URI with the current ETag
value.

       - The client <hello> is not relevant since the server is not
         supposed to wait before sending its own <hello>.

      -  The server has to be configured to either always send the full
<hello>
         or always send the abbreviated <hello>.  An operator must configure
         the full <hello> if any 1.0 applications are in use.

Issues:

 - For new clients, the capability-id is matched to its own cached value.
   If no match, then the client has to get the capabilities somehow (A, B,
?)
      - A: make ietf-monitoring "schema" data subtree mandatory to implement
        and the client will retrieve it
      - B: introduce a new mandatory-to-implement RPC like
"get-module-capabilities".

 - Is there any concern that YANG 1.0 applications cannot be upgraded
quickly?
   If not, then this plan is OK.

Not related to YANG capability caching:

 - Is there any concern about mixing YANG 1.0 and 1.1 modules in the same
server?
   Will 1.0 clients be able to ignore new data augmenting old data?

/js

Andy

---

From: Robert Varga <[email-masked]>
Date: Tue, 11 Mar 2014 11:18:54 +0100

> My point is that the skipped modules may change semantics of the remaining modules. So the client should not be surprised by error conditions or unexpected behaviour of the server.

I am not sure they can really *change* semantics. I think we agree that 
the read-side of things is safe.

The only trouble I see if a 1.0 client attempts to overwrite a tree 
which currently contains 1.1 data with only 1.0 data, either in a 
read-modify-write cycle or by a simple write. Since the server knows it 
is talking to a 1.0 client, I think we can come up with a solution which 
gives the client least surprises by tracking of what happened on the 
session and making a few assumptions about what a reasonable client is 
doing ;-)

Bye,
Robert

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Mar 2014 11:57:20 +0100

On 11 Mar 2014, at 11:18, Robert Varga <[email-masked]> wrote:

> I am not sure they can really *change* semantics. I think we agree that the read-side of things is safe.

Well, my example shows that the module that is being ignored by the client can define default values that the server considers as being present even if the client is not aware of them.

Another problem is that the ignored module may define data nodes with “must” constraints that affect the contents of old modules.

Anyway, the term “data tree” is defined in RFC 6020 as follows:

   o  data tree: The instantiated tree of configuration and state data
      on a device.

The idea of a client cherry-picking modules from hello means that the server and client work with different data trees. This is something I can hardly accept.

Lada
 
> 
> The only trouble I see if a 1.0 client attempts to overwrite a tree which currently contains 1.1 data with only 1.0 data, either in a read-modify-write cycle or by a simple write. Since the server knows it is talking to a 1.0 client, I think we can come up with a solution which gives the client least surprises by tracking of what happened on the session and making a few assumptions about what a reasonable client is doing ;-)
> 
> Bye,
> Robert
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Mar 2014 09:13:52 -0700

On Tue, Mar 11, 2014 at 3:57 AM, Ladislav Lhotka <[email-masked]> wrote:

> >> My point is that the skipped modules may change semantics of the
> remaining modules. So the client should not be surprised by error
> conditions or unexpected behaviour of the server.
> >
> Well, my example shows that the module that is being ignored by the client
> can define default values that the server considers as being present even
> if the client is not aware of them.
>
> Another problem is that the ignored module may define data nodes with
> "must" constraints that affect the contents of old modules.
>
> Anyway, the term "data tree" is defined in RFC 6020 as follows:
>
> The idea of a client cherry-picking modules from hello means that the
> server and client work with different data trees. This is something I can
> hardly accept.
>
>
The client is coded to use certain modules.
It is not required to use modules written in the future or
unrelated to the application.

The client needs to use merge instead of replace.
We already have this problem dues to access control.
It does not even require augments to cause the problem.
This is 1 reason that PUT/replace is not as good as PATCH/merge.

In all likelihood, the addition of even 1 YANG 1.1 module to a server
implementation is going to break all 1.0 applications, because
clients tend to retrieve all the advertised modules, if they retrieve any
modules at all.  Apps that are hard-wired to only understand certain
modules would have no way of knowing that a new 1.1 module
is available to load.

It is not cherry-picking -- it is just a hard-wired design.

Lada

Andy

> read-modify-write cycle or by a simple write. Since the server knows it is
> talking to a 1.0 client, I think we can come up with a solution which gives
> the client least surprises by tracking of what happened on the session and
> making a few assumptions about what a reasonable client is doing ;-)
> >
> > Bye,
> > Robert
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Mar 2014 17:31:30 +0100

> unrelated to the application.

I think it really depends on the design of the data model. For example, ietf-routing makes sense only together with at least one address-family specific modul like ietf-ipv4-unicast-routing. In a sense, ietf-routing is an abstract module. 

> It is not cherry-picking -- it is just a hard-wired design.

If the client is hardwired, then it could also have problems with get operations because unexpected elements can appear pretty much anywhere in the reply.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Mar 2014 10:07:41 -0700

On Tue, Mar 11, 2014 at 9:31 AM, Ladislav Lhotka <[email-masked]> wrote:

> ......
> If the client is hardwired, then it could also have problems with get
> operations because unexpected elements can appear pretty much anywhere in
> the reply.
>
>
The hard-wired implementations are on their own.
We assume clients and servers are written to cope
with module changes (RFC 6020, sec 10). We never thought about
any upgrade guidelines for moving to a new language version.

You are right.
A well-designed schema-driven client is likely to retrieve
all the YANG modules the server advertises, and it will
reject all the YANG 1.1 modules.  Whether it continues to function
is data-model and implementation specific.

We should assume that adding even 1 YANG 1.1 module to
a deployment is likely to require all YANG-driven tools to
be updated at once (a forklift upgrade).

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Mar 2014 18:17:50 +0100

> be updated at once (a forklift upgrade).

In case 1.1 modules are not announced anymore automatically, an old
client will never see them. That said, it is likely that clients are
much easier and faster to upgrade than servers.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Mar 2014 10:21:44 -0700

> much easier and faster to upgrade than servers.
Good point.
They will have to upgrade if they expect to find module capabilities
in the <hello> and they all disappear.  Applications will definitely stop
working if this happens.

/js

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Mar 2014 16:43:57 +0100

> model or a separate get-yang-modules RPC. The <hello> should really

I am now looking to the monitoring data model and wondering: is there any way for the server to announce the supported features? The "schema/namespace" leaf is only supposed to contain the module namespace, according to the description.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Mar 2014 08:49:59 -0700

On Thu, Mar 13, 2014 at 8:43 AM, Ladislav Lhotka <[email-masked]> wrote:

> I am now looking to the monitoring data model and wondering: is there any
> way for the server to announce the supported features? The
> "schema/namespace" leaf is only supposed to contain the module namespace,
> according to the description.
>
>
The full capability URIs are in the /netconf-state/capabilities/capability
list.

Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Mar 2014 16:58:20 +0100

On 13 Mar 2014, at 16:49, Andy Bierman <[email-masked]> wrote:

> The full capability URIs are in the /netconf-state/capabilities/capability list.

OK, so this list may also include capabilities that were not advertised in hello, right?

Lada