[Xorp-hackers] BGP configuration

[Atanu Ghosh]

    Kristian> I have been labbing with BGP now for a while and I
    Kristian> have a few thoughts about it...  You have to configure
    Kristian> local-ip, this is something I like, it forces the user to
    Kristian> pick a interface, be it a loopback for iBGP or a fixed
    Kristian> interface for eBGP. But the next-hop? Why on earth do I
    Kristian> need to set a next-hop? Alright if it's an option but it
    Kristian> shouldn't be required or have I missed something?

    >>  For eBGP peerings we require the next-hop so we have annotated
    >> it as mandatory. We don't yet have a way of annotating a
    >> parameter as conditionally mandatory. Even worse at the moment if
    >> you configure an IPv6 only peering its still necessary to provide
    >> an IPv4 nexthop. This issue has come up a number of times
    >> recently and we have been trying to figure out how the condition
    >> should be specified. Your example is particularly interesting as
    >> it would require us to test the local as and the peer as for
    >> inequality before demanding a next-hop.

    Kristian> Why is it necessary for eBGP?  In my experience eBGP is
    Kristian> seldom multihop and when it is I have never had to specify
    Kristian> the next-hop.  Can not such a value be calculated from the
    Kristian> routing table?

We wanted to provide maximum flexibility to the user by allowing her to
select the next-hop value. I have just looked at the draft again and it
does look like under certain circumstances we should be selecting the
next-hop from the routing table.

    Kristian> And IPv6, it's a bit confusing that one could actually
    Kristian> specify both ipv4 and ipv6 next-hop addresses for one
    Kristian> peer. Is it possible to have "next-hop" receive both v4
    Kristian> and v6 addresses?

You missed my point, we have annotated the next-hop as mandatory
therefore in cases where it is not used we still require it to be in the
configuration. I cited the IPv6 case as an even more egregious example
of the problem. There is a "next-hop6" parameter that takes the IPv6
next-hop address.

    Kristian> Last, isn't "local-ip-address" or "local-address" more
    Kristian> correct than "local-ip" as "ip" is a protocol and we're
    Kristian> talking about an ip address here. It's just a minor ... ;)

You are probably right.

    Kristian> There's also a small annoying bug. Try doing: create
    Kristian> protocols bgp set protocols bgp bgp-id 1.1.1.1 set
    Kristian> protocols bgp local-as 112 commit (everthings fine) create
    Kristian> protocols bgp peer <peer> commit (it will complain over
    Kristian> missing arguments) now fill in the mising stuff, local-ip,
    Kristian> next-hop and as. Try to commit, at least for me it won't
    Kristian> work.

    >>  It failed for me when the local-ip was an illegal value, which
    >> is very bad. It worked when the values were legal.

    Kristian> Strange, it does not for me. It complains on some
    Kristian> resolving error. I can't reproduce now as I lack a
    Kristian> computer to run XORP but I shall try as soon as I get
    Kristian> home.

Okay.

    Kristian> I also would like to rename 'protocols bgp peer <peer>
    Kristian> _as_' to 'peer-as' as it's not crystal clear as to what AS
    Kristian> (local/peer) 'as' is actually referring to.

    >>  You may be right that peer-as would be clearer. We don't want to
    >> break existing configurations as soon as we have an aliasing
    >> story we can try and support both.

    Kristian> No offence here, but do you really think people are using
    Kristian> XORP in production and we need to honour the old
    Kristian> configuration?  Perhaps I am wrong but I still find XORP
    Kristian> to be in it's cradle and so making "drastic" changes like
    Kristian> this should be no problem.  It's better to do it now than
    Kristian> later when people actually start using it.

Making this change without aliasing is already going to be a pain for
us. We have many config files, the regression tests all use this name,
as well as embedded IMUNES configurations. There are often going to be
times that we make a bad naming or syntax choice. Last time we made a
major change we introduced a "%deprecated" keyword in order to help when
configurations broke. I think that making the change with aliasing will
allow us to deal with this and future naming issues.

    Atanu.