Re: [Idr] draft-walton-bgp-hostname-capability-00

[Robert Raszuk <[e-mail]>]

Dinesh,

Q1 - how do you ping physical interface not a loopback
>
>
> In the DC, common practice I've seen is pinging node, not physical
> interface. The physical interface addresses aren't even advertised to be
> able to be reachable more than one hop away.
>

​Ping is just an example. Think about tool like BGP path trace ... do you
want to know the interface names packets are coming on from leaf to leaf or
not ? I was hoping with your extension you will be providing node name of
the form spine44_g10 (where eth10 is the interface ​name).


Q2 - how about lookup on bgp rtr id instead LL address to get the name ?
>>
>
> I don't lookup LL address. Router ID is typically the loopback IP address
> in DC,
>

Perhaps you missed my point. If router id is loopback as you correctly
point out you already have it during BGP OPEN msg on any peering session so
just reverse DNS lookup on router_id will provide you with the name of the
node. Done with no bgp extensions needed.

If DNS is down as Thomas points out your names are useless for
troubleshooting anyway so you fall back to using old fashined IP addresses
in the show command :)

- - -

Now since we are on this topic we had an idea long long time back to carry
the name of the next hop in BGP (learned from ISIS extension which Henk
did) so not only peering will be known locally, but you can also see next
hops by node names rather then IPv6 like strings.

Originally it was added to IGP extensions for BGP discovery.

later the proposal was to carry this as new next hop descriptor attribute
so everynode in the AS can use it.

Now we are working on BGP remote next hop draft which could be used for
that as well. It will apply both to EBGP DC cases as well as for the normal
IBGP AS. In DC normally nh = peering address so naturally your case would
also be solved.

Using capability you only know the name of your immediate peer and that
sounds like a bit of limitation to me.

Propagating the name in the update as an attribute or new wide bgp
community (which I am happy to add new type for) seems to like a much
better option especially if other proposals already call for introduction
of beacon prefixes.

Best,
r.