> Tom Hill
> Sent: Friday, April 13, 2018 1:46 PM
> On 12/04/18 18:06, Gert Doering wrote:
> > yum update
> >
> > ... now *that* would be nice...
> I thought you could do that...
>  https://www.cisco.com/c/dam/assets/global/DK/seminarer/pdfs/XR60.pdf
>  (pgs. 30 & 31)
Page 26 of the same doc:
IOS XR  packages  are  installed  with  "install  update/upgrade".
Install  commands  are  a  wrapper  around  YUM  to  provide  multiarch
-so there's your yum update

But from the initial discussions on this from a few years back I thought I'd
be able to spin up container on new version and then just switch to new one
in an instance, or failback quickly if needed, preferably 0 packet loss in
the process (maybe I'm mistaken ncs6k with asr9k). 
Makes me wonder what's going on under the hood on asr9ks ncs5ks actually
-i.e. how does the picture look like at each LC (I guess we'll need to wait
till this "modular" architecture arrives to LCs as well?)
In this sense, to me the router chassis is like a small DC with compute
nodes (in form of RPs and LCs) all connected via Ethernet network -it would
be nice to have control over which containers and what versions run on each
compute node.
And regarding the 0 packet loss, 
I'm wondering whether the NPU microcode version is independent of the (I
guess Admin Plane) version (or whether it's still monolithic)  

Also wondering when we'll be able to take RPs out of the chassis that is
spin up the Control container(s) (and third party containers) on COTS HW and
let these talk to LCs.
As unfortunately these chassis-based systems can become full with just
couple of LCs in them just because the RP can't cope with the high number of
VRFs, prefixes and BGP sessions. 

::carrier-class solutions for the telecommunications industry::

cisco-nsp mailing list  cisco-nsp@puck.nether.net
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to