[PATCH,RFC 1/3] BGP: Implement secondary remote AS number support.

[Ondrej Zajicek]

On Fri, Mar 10, 2017 at 05:19:11PM +0200, Lennert Buytenhek wrote:
> On Thu, Mar 09, 2017 at 05:53:51PM +0100, Ondrej Zajicek wrote:
> 
> > > This patch implements the latter option, and this functionality is
> > > enabled by specifying two different remote AS numbers for a peer in
> > > the neighbor statement.  Instead of specifying:
> > > 
> > > 	neighbor 1.2.3.4 as 12345;
> > > 
> > > Specify this:
> > > 
> > > 	neighbor 1.2.3.4 as 12345 as 23456;
> > 
> > I would prefer if the secondary as would either have a separate keyword,
> > (e.g. neighbor 1.2.3.4 as 12345 secondary as 23456) or it was just plain
> > positional (e.g. neighbor 1.2.3.4 as 12345 23456).
> 
> Right, okay.  There isn't really a difference in the code between the
> "primary" and the "secondary" AS 

That is true, i thought about local AS.


> > > @@ -1291,8 +1289,6 @@ bgp_init(struct proto_config *C)
> > >  void
> > >  bgp_check_config(struct bgp_config *c)
> > >  {
> > > -  int internal = (c->local_as == c->remote_as);
> > > -
> > 
> > I don't like changes in bgp_check_config(). I think that if you set
> > remote_as as EBGP, while remote_as2 as IBGP, you could end up with
> > inconsistent settings. IMHO allowing remote_as2 only in EBGP makes
> > sense, as in IBGP remote ASN must be the same as local ASN. So we
> > could make internal / is_internal fixed, as it was.
> 
> My main use case for this patch is actually to migrate a data center
> network from iBGP to eBGP, with a setup that is vaguely similar to
> the one described in rfc7938.

Well, that seems like too specific use case. Although you carefully
modified bgp_check_config(), it makes changes to it harder, esp. in 2.0
branch when there is more branching related to which kind of BGP
session is configured.

But the idea of allowing a different remote ASNs in EBGP make sense to
me. Perhaps instead of having two remote ASNs, there could be variant to
allow any.


> I'm sitting on a bunch more patches related to this, for example a
> per-peer toggle to consider routes from an eBGP peer as iBGP routes
> as far as the RFC 4271 9.1.2.2. d) check (Prefer external peers) is
> concerned, and an extension to 'path metric' to skip leading private
> ASes in the AS_PATH when comparing path lengths, et cetera, but I am
> not actually a fan of using eBGP in the data center.  The main reason
> why people do this, as far as I can see, is that using eBGP gives you
> a superior route redistribution and loop detection model, and IMHO,
> iBGP should have had some intra-AS variant of AS_PATH with router IDs
> instead of AS numbers (called, say, INTRA_AS_PATH)

That is essentially BGP confederations (RFC 5065). We already have that
in 2.0 branch [*], but we do not plan to backport it to 1.6 branch.

Or perhaps just setting every router as route reflector / separate
RR cluster and use CLUSTER_LIST as your INTRA_AS_PATH.

The main question here is that whether you want forwarding paths to be
congruent with BGP propagation paths, which is done in EBGP, but not
in IBGP nor in BGP confederations. Althought that could be probably
forced by resetting NEXT_HOP attribute (next hop self option).

[*] https://gitlab.labs.nic.cz/labs/bird/commit/5509e17d0c1b4e75d5911864f75ba119769e5725


> That said, these patches are invaluable to us, but they might not
> all make a lot of sense to merge upstream.  We carry a lot more bird
> patches internally, for example a patch to do ADD_PATHS only for a
> subset of prefixes, more fine-grained control over how to merge
> multipath BGP routes, and we have our own way to inject MPLS routes
> (!), and my goal was to try a bit harder than we traditionally have
> to get things upstream,

Great. I am glad to see moving patches to upstream, although i am
sometimes a bit slow to react to them. Perhaps you could first send us a
list of patches/changes (or just raw / unsanitized patches) so we could
response which ones we see as worth of merging to upstream.


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."