[j-nsp] Suggestions for Edge/Peering Router..

[adamv0025 at netconsultings.com]

> From: Saku Ytti <saku at ytti.fi>
> Sent: Thursday, September 19, 2019 2:42 PM
> 
> On Thu, 19 Sep 2019 at 16:29, <adamv0025 at netconsultings.com> wrote:
> 
> > The dynamic in Cisco implementation means that peers are automatically
> placed to update groups based on commonalities in export policies,
> regardless of the configuration.
> > In juniper case you can actually have two peers with exact same export
> policies be part of different update groups just because they have been
> configured that way -which is inefficient, but who cares throw more CPU at it
> and you're done -real operational problem is the meaningless peer reset.
> 
> I'm not sure I've seen this, but I'm ready to accept it to be true, but seems
> like something that could get PR and get fixed. Do you have a particular
> example where neighbours which will export the same set of routes and
> have same behaviour get separate update-groups?
> 
+    group test-group1 {
+        type external;
+        family inet {
+            unicast;
+        }
+        peer-as 65000;
+        neighbor 192.0.2.10;
+    }
+    group test-group2 {
+        type external;
+        family inet {
+            unicast;
+        }
+        peer-as 65000;
+        neighbor 192.0.2.20;
+    }
+    group test-group3 {
+        type internal;
+        family inet {
+            unicast;
+        }
+        neighbor 192.0.2.30;
+    }
+    group test-group4 {
+        type internal;
+        family inet {
+            unicast;
+        }
+        neighbor 192.0.2.40
+        neighbor 192.0.2.41;
+    }

Group Type: External                               Local AS: 31655
  Name: test-group1     Index: 8                   Flags: <>
  Holdtime: 0
  Total peers: 1        Established: 0
  192.0.2.10

Group Type: External                               Local AS: 31655
  Name: test-group2     Index: 9                   Flags: <>
  Holdtime: 0
  Total peers: 1        Established: 0
  192.0.2.20

Group Type: Internal    AS: 31655                  Local AS: 31655
  Name: test-group3     Index: 10                  Flags: <>
  Holdtime: 0
  Total peers: 1        Established: 0
  192.0.2.30
                                        
Group Type: Internal    AS: 31655                  Local AS: 31655
  Name: test-group4     Index: 11                  Flags: <>
  Holdtime: 0                           
  Total peers: 2        Established: 0  
  192.0.2.40                            
  192.0.2.41                            

In cisco these should be under common update group

What is dynamic is that the peer 192.0.2.41 will be kicked out of group 11 if configured with different export policy
And reset in that process unfortunately

set protocols bgp group test-group4 neighbor 192.0.2.41 export INTERNET_EX

Group Type: Internal    AS: 31655                  Local AS: 31655
  Name: test-group4     Index: 12                  Flags: <>
  Export: [ INTERNET_EX ]               
  Holdtime: 0                           
  Total peers: 1        Established: 0  
  192.0.2.41



> > True but the argument can go both ways -in case of common memory
> space there's no protection so one needs to worry about leaking into
> different parts of memory.
> 
> Yes, the whole house of cards effect, which is very relevant in multitenant
> time-shared systems like Linux server, just because sshd crashes doesn't
> mean httpd should suffer. But I'm not sure if it's so important in router.
> 
> > Hmm, but we wouldn’t second guess this multi-process approach for
> desktop/mobile operating systems right?
> 
> They are much less controlled system, you install nillywilly random
> applications to your phone, and it's not good if phone crashes just because
> some background app I already forgot crashed. And servers have multiple
> tenants. I think in most cases routers have very different profile, vendor
> knows exactly what is running there and it's exactly one use-case.
> Note I'm not saying multiprocess is worse than monolithic, I'm just saying, it's
> not obvious to me multiprocess is the superior in this use-case. Certainly C
> has exuberated the problem as it makes it too easy to write memory unsafe
> code, but considering how long lived NOS are, I think every NOS should be
> written in its own DSL which compiles to C++ or Rust. Then you have more
> choices where given problem is best solved.
> 
> Like forwarding code, should we write it in C or P4 which compiles to
> whatever language the NPU can consume? Less capable developers will be
> able to  write good code in P4 and can communicate to the smaller set of
> developers who write the P4 compiler about missing features. And if the P4
> compiler developer notices some nasty hacks the P4 coders need to write to
> solve some problem they can move the solution to the compiler and have
> the P4 coders write something less hacky.
> I think DSL as an abstraction is justified in any complex long lived project.
> 
Your point on all or nothing and single use-case nature of NOSes is certainly interesting. I'll ponder it some more. 

adam