removed license for srl and changed to pub image

docs/manual/kinds/bridge.md

@@ -4,9 +4,9 @@ Containerlab can connect its nodes to a Linux bridge instead of interconnecting
 
 For example, by connecting a lab node to a bridge we can:
 
-1. allow a node to talk to any workloads (VMs, containers, baremetals) which are connected to that bridge
+1. allow a node to talk to any workload (VM, container, baremetal) which are connected to that bridge
 2. let a node to reach networks which are available via that bridge
-3. scale out containerlab labs by running separate labs in different hosts and get network reachibility between them
+3. scale out containerlab labs by running separate labs in different hosts and get network reachability between them
 4. wiring nodes' data interfaces via a broadcast domain (linux bridge) and use vlans to making dynamic connections
 
 
@@ -25,8 +25,7 @@ topology:
   kinds:
     srl:
       type: ixrd2
-      image: srlinux
-      license: license.key
+      image: ghcr.io/nokia/srlinux
   nodes:
     srl1:
       kind: srl
@@ -61,4 +60,4 @@ br-clab         8000.6281eb7133d2       no              eth1
                                                         eth3
 ```
 
-Chec out ["External bridge"](../../lab-examples/ext-bridge.md) lab for a ready-made example on how to use bridges.
+Check out ["External bridge"](../../lab-examples/ext-bridge.md) lab for a ready-made example on how to use bridges.

docs/manual/kinds/kinds.md

@@ -14,8 +14,7 @@ topology:
     node1:
       kind: srl              # node1 is of srl kind
       type: ixrd2
-      image: srlinux:20.6.3-145
-      license: license.key
+      image: ghcr.io/nokia/srlinux
     node2:
       kind: ceos             # node2 is of ceos kind
       image: ceos:4.25F

docs/manual/kinds/srl.md

@@ -52,7 +52,6 @@ topology:
     srl1:
       kind: srl
       type: ixr6
-      license: lic.key
 ```
 
 The generated config will be saved by the path `clab-<lab_name>/<node-name>/config/config.json`. Using the example topology presented above, the exact path to the config will be `clab-srl_lab/srl1/config/config.json`.
@@ -67,7 +66,7 @@ topology:
     srl1:
       kind: srl
       type: ixr6
-      license: lic.key
+      image: ghcr.io/nokia/srlinux
       config: myconfig.json
 ```
 
@@ -111,7 +110,10 @@ In case a user-provided certificates/keys need to be used, the `root-ca.pem`, `<
 In case only `root-ca.pem` and `root-ca-key.pem` files are provided, the node certificates will be generated using these CA files.
 
 ### License
-SR Linux containers require a license file to be provided. With a [`license`](../nodes.md#license) directive it's possible to provide a path to a license file that will be used for srl nodes.
+SR Linux container can run without any license :partying_face:.  
+In that license-less mode the datapath is limited to 100PPS and the sr_linux process will reboot once a week.
+
+The license file lifts these limitations and a path to it can be provided with [`license`](../nodes.md#license) directive.
 
 ## Container configuration
 To start an SR Linux NOS containerlab uses the configuration that is described in [SR Linux Software Installation Guide](https://documentation.nokia.com/cgi-bin/dbaccessfilename.cgi/3HE16113AAAATQZZA01_V1_SR%20Linux%20R20.6%20Software%20Installation.pdf)

docs/manual/multi-node.md

@@ -4,7 +4,7 @@ Containerlab is a perfect tool of choice when all the lab components/nodes fit i
 Although containerlab is not (yet) capable of deploying topologies over a number of container hosts, we have embedded some capabilities that can help you to workaround the single-host resources constraint.
 
 ## Exposing services
-Sometimes all that is needed is to make certain services running inside the nodes launched with containerlab availalbe to a system running outside of the container host. For example, you might have an already running telemetry stack somewhere in your lab and you want to use it with the routing systems deployed with containerlab.
+Sometimes all that is needed is to make certain services running inside the nodes launched with containerlab available to a system running outside of the container host. For example, you might have an already running telemetry stack somewhere in your lab and you want to use it with the routing systems deployed with containerlab.
 
 In that case, the simple solution would be to expose the nodes' ports which are used to collect telemetry information. Take a look the following example where two nodes are defined in the topology file and get their gNMI port exposed to a host under a user-defined host-port.
 
@@ -21,8 +21,7 @@ topology:
         - 57401:57400
     srl:
       kind: srl
-      image: srl:latest
-      license: lic.txt
+      image: ghcr.io/nokia/srlinux
       ports:
         - 57402:57400
   links:
@@ -39,14 +38,14 @@ Exposing services on a per-port basis as shown above is a quick and easy way to
 Imagine if you want to integrate an NMS system running elsewhere with a lab you launched with containerlab. Typically you would need to expose the entire management network for an NMS to start managing the nodes with management protocols required.  
 In this scenario you wouldn't get far with exposing services via host-ports, as NMS would expect to have IP connectivity with the node it is about to adopt for managing.
 
-For integration tasks like this containerlab users can levelrage static routing towards [containerlab management network](network.md#management-network). Consider the following diagram:
+For integration tasks like this containerlab users can leverage static routing towards [containerlab management network](network.md#management-network). Consider the following diagram:
 
 <div class="mxgraph" style="max-width:100%;border:1px solid transparent;margin:0 auto; display:block;" data-mxgraph="{&quot;page&quot;:0,&quot;zoom&quot;:1.5,&quot;highlight&quot;:&quot;#0000ff&quot;,&quot;nav&quot;:true,&quot;check-visible-state&quot;:true,&quot;resize&quot;:true,&quot;url&quot;:&quot;https://raw.githubusercontent.com/srl-labs/containerlab/diagrams/multinode.drawio&quot;}"></div>
 <script type="text/javascript" src="https://cdn.jsdelivr.net/gh/hellt/drawio-js@main/embed2.js" async></script>
 
-This solution requires to set up roting between the host which runs the NMS and the container host that has containerlab nodes inside. Since containers are always attached to a common management network, we can make this network reachable by installing, for example, a static route on the NMS host. This will provision the datapath between the NMS and the containerlab management network.
+This solution requires to set up routing between the host which runs the NMS and the container host that has containerlab nodes inside. Since containers are always attached to a common management network, we can make this network reachable by installing, for example, a static route on the NMS host. This will provision the datapath between the NMS and the containerlab management network.
 
-By default, containerlab management network is addressed with `172.20.20./0` IPv4 address, but this can be easily [changed](network.md#configuring-management-network) to accomodate for network environment.
+By default, containerlab management network is addressed with `172.20.20./0` IPv4 address, but this can be easily [changed](network.md#configuring-management-network) to accommodate for network environment.
 
 ## Bridging
 Previous examples were aiming management network access, but what if we need to rather connect a network interfaces of a certain node with a system running outside of the container host? An example for such connectivity requirement could be a traffic generator connected to a containerized node port.

docs/manual/network.md

@@ -20,8 +20,7 @@ topology:
   kinds:
     srl:
       type: ixr6
-      image: srlinux
-      license: license.key
+      image: ghcr.io/nokia/srlinux
   nodes:
     srl1:
       kind: srl
@@ -171,7 +170,7 @@ mgmt:
 Since `bridge` network is created by default by docker, using its name in the configuration will make nodes to connect to this network.
 
 #### bridge name
-By default, containerlab will create a linux bridge backing the management docker network with the following name `br-<netword-id>`. The network-id part is coming from the docker network ID that docker manages.
+By default, containerlab will create a linux bridge backing the management docker network with the following name `br-<network-id>`. The network-id part is coming from the docker network ID that docker manages.
 
 We allow our users to change the bridge name that the management network will use. This can be used to connect containers to an already existing bridge with other workloads connected:
 
@@ -219,7 +218,7 @@ The above diagram shows how links are created in the topology definition file. I
 The p2p links are provided by the `veth` device pairs where each end of the `veth` pair is attached to a respective container. The MTU on these veth links is set to 65000, so a regular 9212 MTU on the network links shouldn't be a problem.
 
 ### host links
-It is also possible to interconnect container' data inteface not with other container or add it to a [bridge](kinds/bridge.md), but to attach it to a host's root namespace. This is, for example, needed to create a L2 connectivity between containerlab nodes running on different VMs (aka multi-node labs).
+It is also possible to interconnect container' data interface not with other container or add it to a [bridge](kinds/bridge.md), but to attach it to a host's root namespace. This is, for example, needed to create a L2 connectivity between containerlab nodes running on different VMs (aka multi-node labs).
 
 This "host-connectivity" is achieved by using a reserved node name - `host` - referenced in the endpoints section. Consider the following example where an SR Linux container has its only data interface connected to a hosts root namespace via veth interface:
 
@@ -230,8 +229,7 @@ topology:
   nodes:
     srl:
       kind: srl
-      image: srlinux:20.6.3-145
-      license: license.key
+      image: ghcr.io/nokia/srlinux
       config: test-srl-config.json
   links:
     - endpoints: ["srl:e1-1", "host:srl_e1-1"]
@@ -259,8 +257,7 @@ topology:
   nodes:
     n1:
       kind: srl
-      image: srlinux:21.3.1-410
-      license: license.key
+      image: ghcr.io/nokia/srlinux
   links:
     - endpoints:
         - "n1:e1-1"

docs/manual/nodes.md

@@ -9,8 +9,7 @@ topology:
     node1:  # node name
       kind: srl
       type: ixrd2
-      image: srlinux
-      license: license.key
+      image: ghcr.io/nokia/srlinux
       config: /root/mylab/node1.cfg
       binds:
         - /usr/local/bin/gobgp:/root/gobgp
@@ -56,7 +55,7 @@ docker tag srlinux:20.6.1-286 srlinux:latest
 ```
 
 ### license
-Some containerized NOSes require a license to operate. With `license` property a user sets a path to a license file that a node will use. The license file will then be mounted to the container by the path that is defined by the `kind/type` of the node.
+Some containerized NOSes require a license to operate or can leverage a license to lift-off limitations of an unlicensed version. With `license` property a user sets a path to a license file that a node will use. The license file will then be mounted to the container by the path that is defined by the `kind/type` of the node.
 
 ### startup-config
 For some kinds it's possible to pass a path to a config file that a node will use on start instead of a bare config. Check documentation for a specific kind to see if `startup-config` element is supported.
@@ -258,7 +257,7 @@ nodes:
 ```
 
 ### publish
-Container lab integrates with [mysocket.io](https://mysocket.io) service to allow for private, Internet-reachable tunnels created for ports of containerlab nodes. This enables effortless access sharing with cusomters/partners/colleagues.
+Container lab integrates with [mysocket.io](https://mysocket.io) service to allow for private, Internet-reachable tunnels created for ports of containerlab nodes. This enables effortless access sharing with customers/partners/colleagues.
 
 This integration is extensively covered on [Publish ports](published-ports.md) page.
 

docs/manual/published-ports.md

@@ -93,8 +93,7 @@ topology:
   nodes:
     r1:
       kind: srl
-      image: srlinux:20.6.3-145
-      license: license.key
+      image: ghcr.io/nokia/srlinux
       publish:
         - tcp/22     # tcp port 22 will be exposed
 

docs/manual/topo-def-file.md

@@ -15,8 +15,7 @@ topology:
   nodes:
     srl:
       kind: srl
-      image: srlinux:20.6.3-145
-      license: license.key
+      image: ghcr.io/nokia/srlinux
     ceos:
       kind: ceos
       image: ceos:4.25.0F
@@ -57,8 +56,7 @@ topology:
     srl:                    # this is a name of the 1st node
       kind: srl
       type: ixrd2
-      image: srlinux:20.6.3-145
-      license: license.key
+      image: ghcr.io/nokia/srlinux
     ceos:                   # this is a name of the 2nd node
       kind: ceos
       image: ceos:4.25.0F
@@ -72,8 +70,7 @@ Each node can have multiple configuration properties which make containerlab qui
 srl:
   kind: srl
   type: ixrd2
-  image: srlinux
-  license: license.key
+  image: ghcr.io/nokia/srlinux
 ```
 
 Refer to the [node configuration](nodes.md) document to meet all other options a node can have.
@@ -116,8 +113,7 @@ topology:
   kinds:
     srl:
       type: ixrd2
-      image: srlinux
-      license: license.key
+      image: ghcr.io/nokia/srlinux
   nodes:
     srl1:
       kind: srl
@@ -127,9 +123,9 @@ topology:
       kind: srl
 ```
 
-In the example above the `topology.kinds` element has `srl` kind referenced. With this, we set some values for the properties of the `srl` kind. A configuration like that says that nodes of `srl` kind will also inherit the properties (type, image, license) defined on the _kind level_.
+In the example above the `topology.kinds` element has `srl` kind referenced. With this, we set some values for the properties of the `srl` kind. A configuration like that says that nodes of `srl` kind will also inherit the properties (type, image) defined on the _kind level_.
 
-Essentially, what `kinds` section allows us to do is to shorten the lab definition in cases when we have a number of nodes of a same kind. All the nodes (`srl1`, `srl2`, `srl3`) will have the same values for their `type`, `image` and `license` properties.
+Essentially, what `kinds` section allows us to do is to shorten the lab definition in cases when we have a number of nodes of a same kind. All the nodes (`srl1`, `srl2`, `srl3`) will have the same values for their `type` and `image` properties.
 
 Consider how the topology would have looked like without setting the `kinds` object:
 
@@ -139,18 +135,15 @@ topology:
     srl1:
       kind: srl
       type: ixrd2
-      image: srlinux
-      license: license.key
+      image: ghcr.io/nokia/srlinux
     srl2:
       kind: srl
       type: ixrd2
-      image: srlinux
-      license: license.key
+      image: ghcr.io/nokia/srlinux
     srl3:
       kind: srl
       type: ixrd2
-      image: srlinux
-      license: license.key
+      image: ghcr.io/nokia/srlinux
 ```
 
 A lot of unnecessary repetition which is eliminated when we set `srl` kind properties on kind level.