Enable hostname capability (fqdn)

[ton31337]

Some of the open-source implementations already support this feature by default.

https://datatracker.ietf.org/doc/html/draft-walton-bgp-hostname-capability-02

Tested between ExaBGP and FRR:

$ vtysh -c 'show bgp neighbor 127.0.0.1 json' | jq '."127.0.0.1".neighborCapabilities.hostName'
{
  "advHostName": "donatas-laptop",
  "advDomainName": "n/a",
  "rcvHostName": "belekas",
  "rcvDomainName": "donatas.net"
}

The config is:

neighbor 127.0.0.2 {
  router-id 10.10.10.10;
  local-address 127.0.0.1;
  local-as 65001;
  peer-as 65001;
  host-name belekas;
  domain-name donatas.net;
...
}

[thomas-mangin]

The last time I looked, this draft was, IMHO, dangerous as it allows users to set up a very long hostname, which may prevent encoding the other attributes in the OPEN message.

FRR and ExaBGP have used an implementation to test the draft. I am not sure if I want to re-enable the code. Let me look back at the spec and think about it.

[ton31337]

Encoding extra capabilities into OPEN would technically require extended optional parameters support.

[ton31337]

We might maybe turn off it by default, but send it if defined explicitly, what do you think?

[thomas-mangin]

as the length is here limited to 64, I will merge

[ton31337]

Let me figure out what's failing yet :)

[thomas-mangin]

Do not waste your time .. It is Python 3.6 being Python 3.6

[vincentbernat]

FI, I did implement it for BIRD, but even one of the author of the RFC said it was a bad idea due to the fact it shouldn't have it implemented as a capability. Unfortunately, no alternative was proposed (as a RFC).

[ton31337]

I don't see it's bad in any case. I known there were discussions by encoding into ext communities, introducing another BGP message, but that's totally overengineering for such a useful/trivial feature. One thing to have in mind is to avoid using too much optional parameters including capabilities unless you have extended optional parameters support.

[thomas-mangin]

BGP is in a mess because RFC authors do pack lots of things in attributes in other ways when they should not. If you want to have a "fun" BGP read, I author the slides in 2017 and they still hold up http://thomas.mangin.com/data/pdf/NetMCR%20-%20Oct%2012%20-%20BGP%20Good%20Bad%20Missing.pdf

[ton31337]

Good reading.

Btw, this is already a RFC :) https://datatracker.ietf.org/doc/html/rfc8654

One more interesting draft for you regarding attributes transitivity is https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-attribute-announcement :)

[thomas-mangin]

And ... This size extention is negotiated with OPEN messages ... so the OPEN has to remain 4k for backward compatibility.

Thank you for pointing me to this other draft from our usual IETF suspects. Not sure I like it as authored but as I do not engage with the IETF anymore (or at least not ATM), I have no right to complain.