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

[Daniel Walton <[e-mail]>]

On Sat, May 16, 2015 at 6:27 AM, Robert Raszuk <[e-mail]> wrote:

> 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).
>

No, we just want to know the hostname of our peer so that the user has more
context to work with other than an interface name. It is as simple as
displaying/using that hostname in show commands, debug output, clear
commands, etc.  Using a simple capability allows this to work if DNS is
down or not configured (lab environment...granted this scenario is low
priority) or if you have the scenario that Rajiv pointed out.



> 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 :)
>

If DNS is down how does that make knowing the hostname of a LL BGP peer
useless?



>
> - - -
>
> 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.
>
>
This sounds far more heavy handed and would be solving a problem that we
are not attempting to solve :) I just need to know the hostnames of my
peers.

Daniel