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

From: Daniel Walton <[email-masked]>
Date: Fri, 15 May 2015 21:26:16 -0400

https://tools.ietf.org/html/draft-walton-bgp-hostname-capability-00

Feedback is welcome. There is a "Sectino" typo in the intro, will clean
that up.

Daniel

---

From: Randy Bush <[email-masked]>
Date: Fri, 15 May 2015 15:52:32 -1000

one more unneeded place for things to go wrong

randy

---

From: [email-masked]
Date: Fri, 15 May 2015 22:58:19 -0300

Agree.. adding code for no real operational benefit

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message  
From: Randy Bush
Sent: Friday, May 15, 2015 10:52 PM
To: Daniel Walton
Cc: idr wg; Dinesh Dutt
Subject: Re: [Idr] draft-walton-bgp-hostname-capability-00

randy

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeff Haas <[email-masked]>
Date: Fri, 15 May 2015 22:11:58 -0400

Minimally this is going to want ext-opt-param. :-)

Jeff

> On May 15, 2015, at 21:26, Daniel Walton <[email-masked]> wrote:
> 
> Feedback is welcome. There is a "Sectino" typo in the intro, will clean that up. 
> 
> Daniel
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 15 May 2015 16:49:01 -1000

>> https://tools.ietf.org/html/draft-walton-bgp-hostname-capability-00

also the astologic sign of the last person to config the peer.  in
radians.

---

From: Daniel Walton <[email-masked]>
Date: Sat, 16 May 2015 00:08:35 -0400

Many of our customers use a Clos architecture and bgp peer to the IPv6 LL
address of every directly connected router.  To avoid configuring neighbor
statements with LL addresses we support a "neighbor swpX interface" command
("swpX" is the default notation for an interface name in cumulus linux).
We then peer to the LL address on the other end of the swpX link (we only
support this for point-to-point links).

When you run commands like "show ip bgp summary" you see a list of
interface names instead of IP addresses. Typically if you are loopback
peering you either become familiar with "10.0.0.1 is Chicago" because you
see 10.0.0.1 in the 'show ip bgp summ' output of several different routers
or you could use DNS to do a lookup on 10.0.0.1 and put the hostname in the
output.  When every box is peering to LL addresses though ("swpX" for short
for us) you can't easily tell who that peer is and you can't use DNS
because they LL addresses

*Before*

leaf-11# show ip bgp summ
BGP router identifier 6.0.0.5, local AS number 65101
BGP table version 25
RIB entries 33, using 3960 bytes of memory
Peers 6, using 100 KiB of memory
Peer groups 1, using 56 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
 State/PfxRcd
swp1            4 65000     196     198        0    0    0 00:02:51        9
swp2            4 65000     195     200        0    0    0 00:02:51        9
swp3            4 65000     197     200        0    0    0 00:02:51        9
swp4            4 65000     198     200        0    0    0 00:02:51        9
swp5            4 65201     207     200        0    0    0 00:02:51        2
swp6            4 65202     210     201        0    0    0 00:02:52        2

Total number of neighbors 6
leaf-11#

spine-3# show ip bgp summ
BGP router identifier 6.0.0.15, local AS number 65000
BGP table version 19
RIB entries 33, using 3960 bytes of memory
Peers 8, using 134 KiB of memory
Peer groups 1, using 56 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
 State/PfxRcd
swp5            4 65101     675     675        0    0    0 00:10:49        5
swp6            4 65101     678     676        0    0    0 00:10:50        5
swp7            4 65101     667     668        0    0    0 00:10:48        5
swp8            4 65101     676     676        0    0    0 00:10:49        5
swp9            4 65102     701     692        0    0    0 00:11:04        5
swp10           4 65102     701     692        0    0    0 00:11:04        5
swp11           4 65102     701     691        0    0    0 00:11:04        5
swp12           4 65102     701     692        0    0    0 00:11:04        5

Total number of neighbors 8
spine-3#
spine-3#

*After*

leaf-11# show ip bgp summ
BGP router identifier 6.0.0.5, local AS number 65101
BGP table version 25
RIB entries 33, using 3960 bytes of memory
Peers 6, using 100 KiB of memory
Peer groups 1, using 56 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
 State/PfxRcd
spine-1(swp1)   4 65000     211     213        0    0    0 00:03:07        9
spine-2(swp2)   4 65000     210     215        0    0    0 00:03:07        9
spine-3(swp3)   4 65000     212     215        0    0    0 00:03:07        9
spine-4(swp4)   4 65000     213     215        0    0    0 00:03:07        9
tor-11(swp5)    4 65201     222     215        0    0    0 00:03:07        2
tor-12(swp6)    4 65202     225     216        0    0    0 00:03:08        2

Total number of neighbors 6
leaf-11#

spine-3# show ip bgp summ
BGP router identifier 6.0.0.15, local AS number 65000
BGP table version 19
RIB entries 33, using 3960 bytes of memory
Peers 8, using 134 KiB of memory
Peer groups 1, using 56 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
 State/PfxRcd
leaf-11(swp5)   4 65101    1119    1119        0    0    0 00:18:13        5
leaf-12(swp6)   4 65101    1122    1120        0    0    0 00:18:14        5
leaf-13(swp7)   4 65101    1110    1111        0    0    0 00:18:12        5
leaf-14(swp8)   4 65101    1119    1119        0    0    0 00:18:13        5
leaf-21(swp9)   4 65102    1144    1135        0    0    0 00:18:28        5
leaf-22(swp10)  4 65102    1144    1135        0    0    0 00:18:28        5
leaf-23(swp11)  4 65102    1144    1134        0    0    0 00:18:28        5
leaf-24(swp12)  4 65102    1144    1135        0    0    0 00:18:28        5

Total number of neighbors 8
spine-3#

It makes troubleshooting much easier.

Daniel

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 16 May 2015 08:01:56 +0200

Hi Daniel & Dinesh,

I very much like the intention, but have a concern how it would simplify
troubleshooting in practice ...

Imagine we exchange the names in new capability when session comes up so we
list it in summary output instead of link local address. But when you try
to trace or ping that name (from pc or router) your local or global DNS
will return not the LL address but most likely loopback so the results will
be rather of questionable value.

Would you not see this as a problem ? I hope you did not intended to just
cover the cosmetic nature of few show commands which I must agree with
others is rather a legacy way to operate the network these days anyway ;)).

Cheers,
R.

On Saturday, May 16, 2015, Daniel Walton <[email-masked]>
wrote:

> On Fri, May 15, 2015 at 9:58 PM, <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Dinesh Dutt <[email-masked]>
Date: Fri, 15 May 2015 23:18:10 -0700

Hi Robert,

On Fri, May 15, 2015 at 11:01 PM, Robert Raszuk <[email-masked]> wrote:

> Imagine we exchange the names in new capability when session comes up so
> we list it in summary output instead of link local address. But when you
> try to trace or ping that name (from pc or router) your local or global DNS

I'm confused. Why would we send a hostname in this capability that is
different from the one assigned to loopback ? Within the DC at least,
people don't advertise link addresses at all, only the loopback.  So, the
hostname exchanged in the capability would be the same as the one returned
by traceroute/ping.

Dinesh

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 16 May 2015 08:27:45 +0200

Hi Dinesh,

Q1 - how do you ping physical interface not a loopback

Q2 - how about lookup on bgp rtr id instead LL address to get the name ?

Cheers,
R.

On Saturday, May 16, 2015, Dinesh Dutt <[email-masked]> wrote:

> Hi Robert,
>
> On Fri, May 15, 2015 at 11:01 PM, Robert Raszuk <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> Hi Daniel & Dinesh,
>>
>> On Saturday, May 16, 2015, Daniel Walton <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>>> Many of our customers use a Clos architecture and bgp peer to the IPv6
>>> LL address of every directly connected router.  To avoid configuring
>>> neighbor statements with LL addresses we support a "neighbor swpX
>>> interface" command ("swpX" is the default notation for an interface name in
>>> cumulus linux).  We then peer to the LL address on the other end of the
>>> swpX link (we only support this for point-to-point links).
>>>

---

From: Dinesh Dutt <[email-masked]>
Date: Sat, 16 May 2015 00:00:27 -0700

Hi Robert,

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

> 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,

Dinesh

>>> Would you not see this as a problem ? I hope you did not intended to
>>> just cover the cosmetic nature of few show commands which I must agree with

---

From: "Thomas Mangin" <[email-masked]>
Date: Sat, 16 May 2015 09:06:19 +0100

Hello Daniel,

As unknown capability are ignored anyway, from a technical point, I see 
no problem with the capability presented.
It would be trivial to implement (only speaking for myself here).

In time of outage when quick debugging is the most important and when 
DNS may not be reachable ( been there, seen it ) having the “commonly 
used name” of the remote device does sound like a bad idea ( I could 
only remember so many IP ) but I appreciate it is an area where 
individual opinion will differ widely.

Thomas

http://exa.net.uk/about/contact-us

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 16 May 2015 12:27:35 +0200

Dinesh,

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

> I don't lookup LL address. Router ID is typically the loopback IP address

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.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 16 May 2015 11:37:38 +0000

One minor point --

I don't lookup LL address. Router ID is typically the loopback IP address in DC,

The above is true for dual-stack or single-stack IPv4 networks (loop back IPv4 address usually is router ID), but not true for single-stack IPv6 networks in which the router ID (4 bytes) would barely be related to the loop back IPv6 address (128 bytes).

Cheers,
Rajiv

On May 16, 2015, at 3:01 AM, Dinesh Dutt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Robert,

On Fri, May 15, 2015 at 11:27 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dinesh,

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.

I don't lookup LL address. Router ID is typically the loopback IP address in DC,

Dinesh

Cheers,
R.

On Saturday, May 16, 2015, Dinesh Dutt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

I very much like the intention, but have a concern how it would simplify troubleshooting in practice ...

Imagine we exchange the names in new capability when session comes up so we list it in summary output instead of link local address. But when you try to trace or ping that name (from pc or router) your local or global DNS will return not the LL address but most likely loopback so the results will be rather of questionable value.

I'm confused. Why would we send a hostname in this capability that is different from the one assigned to loopback ? Within the DC at least, people don't advertise link addresses at all, only the loopback.  So, the hostname exchanged in the capability would be the same as the one returned by traceroute/ping.

Dinesh

Would you not see this as a problem ? I hope you did not intended to just cover the cosmetic nature of few show commands which I must agree with others is rather a legacy way to operate the network these days anyway ;)).

Cheers,
R.

On Saturday, May 16, 2015, Daniel Walton <[email-masked]> wrote:
Many of our customers use a Clos architecture and bgp peer to the IPv6 LL address of every directly connected router.  To avoid configuring neighbor statements with LL addresses we support a "neighbor swpX interface" command ("swpX" is the default notation for an interface name in cumulus linux).  We then peer to the LL address on the other end of the swpX link (we only support this for point-to-point links).

When you run commands like "show ip bgp summary" you see a list of interface names instead of IP addresses. Typically if you are loopback peering you either become familiar with "10.0.0.1 is Chicago" because you see 10.0.0.1 in the 'show ip bgp summ' output of several different routers or you could use DNS to do a lookup on 10.0.0.1 and put the hostname in the output.  When every box is peering to LL addresses though ("swpX" for short for us) you can't easily tell who that peer is and you can't use DNS because they LL addresses

Before

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

After

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

Daniel

randy

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 16 May 2015 11:54:48 +0000

If it is about figuring out the adjacent IPv6 neighbor names (certainly, a reasonable operational ask), then let's not solve it just for BGP (or using BGP), else we would end up solving the same problem again (using a different protocol) for non-BGP enabled nodes.

Perhaps, IPv6 ND (*) is better suited to carry the host names. The reason is that IPv6 ND is mandatory for every IPv6 node, hence the lowest common denominator.

BGP can pick up the host names from the local ND database and display it in the neighbor table.

Of course, this doesn't solve the multi-hop BGP scenario, but IPv6 LL addresses (the original intent of this draft) can't be used in multi-hop anyway. It also doesn't solve the BGP path trace (that Robert pointed out).

We should bring this up to the v6ops and IPv6 groups.

Cheers,
Rajiv

Ps:

On May 16, 2015, at 6:27 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Dinesh,

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

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.

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.

---

From: Daniel Walton <[email-masked]>
Date: Sat, 16 May 2015 08:04:31 -0400

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

> troubleshooting anyway so you fall back to using old fashined IP addresses

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

> better option especially if other proposals already call for introduction
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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 16 May 2015 15:03:26 +0200

​Hi Daniel,​

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

​It was not clear from the draft that you would use those to resolve names
also locally (say via temporary caching into hosts file) when learned by
BGP.

I think while the extension you are proposing is indeed minor I would
personnaly see this being solved in general v6 case not just for BGP as
Rajiv mentioned.

Btw are you not running LLDP already on the interfaces ? If so the peer
name is already there. If not adding OpenLLDP (http://open-lldp.org/)
should be a mater of minutes :)

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

But it also solves your problem automagically - that is why I have
mentioned it here for consideration of the group.

Cheers,
R.

---

From: "Thomas Mangin" <[email-masked]>
Date: Sat, 16 May 2015 16:59:09 +0100

> 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?

I do not know any of the directly connected IP of most of our equipments 
but I know all our router names and they include some form of encoding 
of the hw type and location. Therefore if not vital this information is 
useful.

Also more than once I have seen process failure where a equipment IP is 
changed but where DNS information is not and consequently stale. This 
will help with this case.

I would rather see this totally harmless draft (as vendors can decide to 
ignore it without consequences) progress than seeing Cumulus assigning a 
capability number for it and later find that we have like multisession 
two different code for the same feature :p

Thomas

---

From: John Heasley <[email-masked]>
Date: Sat, 16 May 2015 12:37:00 -0400

Am 16.05.2015 um 11:59 schrieb Thomas Mangin <[email-masked]>:
> 
> I would rather see this totally harmless draft (as vendors can decide to ignore it without consequences) progress than seeing Cumulus assigning a capability number for it and later find that we have like multisession two different code for the same feature :p

Or just keep track of your peering info in a database ... With contact info, business relationship, etc.  this is not a bgp problem, IMO.  Its a CRM and NMS problem.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 16 May 2015 18:45:58 +0100

On 16/05/2015 12:54, Rajiv Asati (rajiva) wrote:
> Perhaps, IPv6 ND (*) is better suited to carry the host names. The reason
> is that IPv6 ND is mandatory for every IPv6 node, hence the lowest common
> denominator. 

please no.  Major layering violation.

Nick

---

From: Daniel Walton <[email-masked]>
Date: Sat, 16 May 2015 14:50:41 -0400

> also locally (say via temporary caching into hosts file) when learned by

Ack, we'll add some text that gives some examples of how/why an
implementation might use the hostname data.

> should be a mater of minutes :)
yep, we have LLDP :)  We did consider using LLDP initially but there are
some situations where it doesn't work:

   - LLDP is not enabled.  This would be uncommon within a data center but
   I have worked with customers before who turn off LLDP on all customer
   facing links.
   - If you want to peer to multiple peers on a single L2 segment you are
   only going to see the L2 switch as a LLDP peer and not all of the L3 boxes
   that you are BGP peering with.  For us we only support the "neighbor swpX
   interface" syntax for p2p links but that might change someday and a
   customer could always configure multiple neighbors on that interface by
   specifying "neighbor fe80::...... remote-as X".

Daniel

---

From: "Thomas Mangin" <[email-masked]>
Date: Sat, 16 May 2015 20:04:24 +0100

>> I would rather see this totally harmless draft (as vendors can decide 
>> to ignore it without consequences) progress than seeing Cumulus 
>> assigning a capability number for it and later find that we have like 
>> multisession two different code for the same feature :p
>
> Or just keep track of your peering info in a database ... With contact 
> info, business relationship, etc.  this is not a bgp problem, IMO.  
> Its a CRM and NMS problem.

We will clearly not agree.

As we believe in “working code and rough consensus”, we now have the 
first half.
https://github.com/Exa-Networks/exabgp/commit/2641669f0bf6f34e3639bcdc36a940c381c89548

I will let people decide about the second half.

Thomas

---

From: Dinesh Dutt <[email-masked]>
Date: Sat, 16 May 2015 12:17:41 -0700

Hi Thomas,

I think you have captured our intent well.

On Sat, May 16, 2015 at 12:04 PM, Thomas Mangin <
[email-masked]> wrote:

>>> capability number for it and later find that we have like multisession two
>>> different code for the same feature :p
>>>
>>
>> info, business relationship, etc.  this is not a bgp problem, IMO.  Its a
>> CRM and NMS problem.
>>
>
> As we believe in “working code and rough consensus”, we now have the first
> half.
>

In the same spirit, we had added a link to the Quagga implementation that
we have in the draft. May we add a link to your implementation as well ?

Dinesh

---

From: Dinesh Dutt <[email-masked]>
Date: Sat, 16 May 2015 12:19:07 -0700

> please no.  Major layering violation.

Ack. There are other reasons too such as working with IPv4 peering, and
iBGP peering which is not always one-hop away.

Dinesh

---

From: Dinesh Dutt <[email-masked]>
Date: Sat, 16 May 2015 12:20:34 -0700

Also add to this list, iBGP peering, which may not be one hop away. Within
the DC, people are deploying BGP-based controllers.

Dinesh

On Sat, May 16, 2015 at 11:50 AM, Daniel Walton <[email-masked]

>> ​It was not clear from the draft that you would use those to resolve
>> names also locally (say via temporary caching into hosts file) when learned
>> by BGP.
>>
>
>    - LLDP is not enabled.  This would be uncommon within a data center
>    but I have worked with customers before who turn off LLDP on all customer
>    facing links.

---

From: Job Snijders <[email-masked]>
Date: Sat, 16 May 2015 21:25:56 +0200

On Sat, May 16, 2015 at 12:37:00PM -0400, John Heasley wrote:
> > I would rather see this totally harmless draft (as vendors can
> > decide to ignore it without consequences) progress than seeing
> > Cumulus assigning a capability number for it and later find that we
> > have like multisession two different code for the same feature :p
> 

I agree with John.

One could easily create a tool which takes 'show bgp sum' data and
enriches that view with various database lookups. Passing strings around
in BGP might seem convenient, but does not address the architectual
shortcomings of your system if case you have no idea who your neighbor
is.

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 May 2015 11:52:41 -1000

> enriches that view with various database lookups. Passing strings
> around in BGP might seem convenient, but does not address the
> architectual shortcomings of your system if case you have no idea who
> your neighbor is.

and we're all waiting for the attack where the sender puts tasty things
in the supposed dns name

randy

---

From: Dinesh Dutt <[email-masked]>
Date: Sat, 16 May 2015 16:07:21 -0700

Hi John,

> info, business relationship, etc.  this is not a bgp problem, IMO.  Its a

In the data center, you've met the other side, and its you. I don't think I
said that carrying the hostname was a BGP problem. We see it as a way to
simplify operations in the DC, by supplementing numbers with names,

Dinesh

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 May 2015 13:20:01 -1000

> In the data center, you've met the other side, and its you. I don't
> think I said that carrying the hostname was a BGP problem. We see it
> as a way to simplify operations in the DC, by supplementing numbers
> with names,

and you want to do it by adding yet another bag of dren on an already
massively overloaded, overly complex, fragile, and critical protocol.
as heas, who has done it, says, fix your oss.

randy

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 16 May 2015 19:50:43 -0400

> simplify operations in the DC, by supplementing numbers with names,

Pardon my ignorance of BGP, but wouldn't a check of the router-id
resolve that issue.  You know that non-routable 4 bit thing that is
unique and isn't an address (but somehow manages to fall within an
assigned IPv4 prefix) that has been in BGP for a while.

Look up the router-id maybe?  And yes peering info in a database has
been successfully tried before.  If you need peering info, why is FQDN
any easier to use to look it up than router-id?

Isn't there something in DNS to map an address to FQDN?  Maybe you
could use that.  I think some people have successfully used that too.

Never ran a DC but I always thought that if you brought up a peering
and "it was you" your network was in rather bad shape to start with.

:-)

Curtis

---

From: jim deleskie <[email-masked]>
Date: Sat, 16 May 2015 21:42:28 -0300

Curtis,

 But what would you know... :)  Good to see you, its been a while, hope all
is well.

-jim

On Sat, May 16, 2015 at 8:50 PM, Curtis Villamizar <[email-masked]>
wrote:

> In message <
> [email-masked]>
> Dinesh Dutt writes:
>
> > Hi John,
> >
> decide to
> think I

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 May 2015 14:45:12 -1000

> Pardon my ignorance of BGP

this would explain a *lot*!

randy

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 16 May 2015 20:55:14 -0400

> It makes troubleshooting much easier.

so does not using private addressing?
why solve this in the bgp space? why not solve this in any of the
other domains much better built for this?

---

From: John Heasley <[email-masked]>
Date: Sat, 16 May 2015 22:49:40 -0400

Am 16.05.2015 um 19:07 schrieb Dinesh Dutt <[email-masked]>:
> 
> In the data center, you've met the other side, and its you. I don't think I said that carrying the hostname was a BGP problem. We see it as a way to simplify operations in the DC, by supplementing numbers with names,
> 

If you want to give it a name, then do so in your config. Ie: 'neighbor 1.2.3.4 name peerWhoICallJoe' provides 'clear ip bgp peerWhoICallJoeNet', usw.

 If i am malicious, which i am, and automated, which i may be, i can change the name every April Fools day - or every day - or after every reboot - or it might move to another device. Your managment should be based on a name that you control and is meaningful to _you_. Even if i like the like the idea of referring to a peer by name, i want it to be the name/ID that i know it by ... In my CRM/database, not whatever goofy name the peer has given to the device.

---

From: "Thomas Mangin" <[email-masked]>
Date: Sun, 17 May 2015 09:57:55 +0100

> and we're all waiting for the attack where the sender puts tasty 

If the worry is about the complexity of handling UTF-8, the draft could 
be change to require ascii 'a' through 'z' (in a case-insensitive 
manner), the digits '0' through '9', and the hyphen ('-') to be put in 
the draft as it is what DNS allows.

Thomas

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 May 2015 23:24:45 -1000

>> and we're all waiting for the attack where the sender puts tasty
>> things in the supposed dns name
> If the worry is about the complexity of handling UTF-8, the draft
> could be change to require ascii 'a' through 'z' (in a
> case-insensitive manner), the digits '0' through '9', and the hyphen
> ('-') to be put in the draft as it is what DNS allows.

bzzzzt!  dns is eight bit clear.  you are thinking of some restrictions
on hostnames, the leftmost chunk of the lhs at most.

randy

---

From: "Thomas Mangin" <[email-masked]>
Date: Sun, 17 May 2015 11:00:13 +0100

> on hostnames, the leftmost chunk of the lhs at most.

I stand corrected. 
That said, then perhaps the way is to only pass the hostname and not the fqdn.

Thomas

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 17 May 2015 12:00:56 +0200

> If you want to give it a name, then do so in your config. Ie: 'neighbor
> 1.2.3.4 name peerWhoICallJoe' provides 'clear ip bgp peerWhoICallJoeNet',
> usw.
>

​The point is they do not want to configure peers. The LL v6 address​ would
be used for auto-peering.

r.

---

From: heasley <[email-masked]>
Date: Sun, 17 May 2015 12:03:26 +0000

> on hostnames, the leftmost chunk of the lhs at most.

in which, '-' is not valid, iirc.

---

From: Dinesh Dutt <[email-masked]>
Date: Sun, 17 May 2015 05:05:25 -0700

Hi John,

I appreciate your taking the time to provide alternate suggestions.

On Sat, May 16, 2015 at 7:49 PM, John Heasley <[email-masked]> wrote:

> think I said that carrying the hostname was a BGP problem. We see it as a
> way to simplify operations in the DC, by supplementing numbers with names,
> >
>

Interestingly, what you suggest is where we began originally. But this
makes the box configuration specific to each box. In the data center,
making the configuration as cookie-cutter as possible to ease automation is
a fairly fundamental goal given the size of the network.

Dinesh

>
>  If i am malicious, which i am, and automated, which i may be, i can
> change the name every April Fools day - or every day - or after every
> reboot - or it might move to another device. Your managment should be based
> on a name that you control and is meaningful to _you_. Even if i like the
> like the idea of referring to a peer by name, i want it to be the name/ID
> that i know it by ... In my CRM/database, not whatever goofy name the peer
> has given to the device.
>
>

---

From: Dinesh Dutt <[email-masked]>
Date: Sun, 17 May 2015 05:07:15 -0700

> That said, then perhaps the way is to only pass the hostname and not the

That'll be fine. We added fqdn to allow for cases outside the DC.

On a different note, OSPF has a far more involved modification to allow the
carrying of hostnames (https://tools.ietf.org/html/rfc5642). I'm curious as
to why that was considered OK.

Dinesh

---

From: "Thomas Mangin" <[email-masked]>
Date: Sun, 17 May 2015 13:11:55 +0100

> in which, '-' is not valid, iirc.

‘-‘ is definitively acceptable in hostnames, many of mine are called 
“service-number”.
For the disclosure, this is copy and paste from wikipedia.

Thomas

---

From: "Thomas Mangin" <[email-masked]>
Date: Sun, 17 May 2015 13:16:15 +0100

> That'll be fine. We added fqdn to allow for cases outside the DC.

In that case the draft could make this capability IBGP only which would 
remove even more concern about security ?
If an ASN want to use it, then it is up to them, it would not affect 
other network.

Thomas

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 17 May 2015 14:30:07 +0200

In DC most deployments use EBGP to construct L3 fabric.

Best,
R.
On May 17, 2015 2:16 PM, "Thomas Mangin" <[email-masked]>
wrote:

> If an ASN want to use it, then it is up to them, it would not affect other
> network.
>
> Thomas
>

---

From: "Thomas Mangin" <[email-masked]>
Date: Sun, 17 May 2015 13:34:31 +0100

> In DC most deployments use EBGP to construct L3 fabric.

In that case, the way would be to make it a configuration option on the 
session (for sending).
And if not configured the receiving end would simply ignore it and treat 
it as unknown.

Thomas

---

From: Łukasz Bromirski <[email-masked]>
Date: Sun, 17 May 2015 14:47:06 +0200

Hi,

Some of the vendors already have problems with the BGP code bloat. Of course session negotiation could take care of the additional feature, but would this option really change the world for BGP users?

Also bear in mind, even if feature is not active on specific session, the code is still there, compiled, adding kBs of binary to existing code base. It can be exploited, it can contain some hard to catch bugs in non-trivial scenarios outside typical test cases... It can kick you in the balls during some complex migration where the bug will suddenly trigger itself. 

And BTW - last time I checked, BGP was still limited to 4kB segment and this space will all extended communities and so on is getting crowded very fast.

If the improvement is for operations and not for core of BGP, let's deal with this at operational/NMS level (and possibly protocols).

-- 
my 0.03PLN

On 17 May 2015, at 14:34, Thomas Mangin <[email-masked]> wrote:

> In that case, the way would be to make it a configuration option on the session (for sending).
> And if not configured the receiving end would simply ignore it and treat it as unknown.
> 
> Thomas
>

---

From: Daniel Walton <[email-masked]>
Date: Sun, 17 May 2015 08:50:05 -0400

On Sat, May 16, 2015 at 8:55 PM, Christopher Morrow <[email-masked]

> so does not using private addressing?

IPv6 link-local addressing is the main motivator, not private addressing.

> other domains much better built for this?

Solving it in BGP is very simple, it works if routing is down (no DNS), it
works for ipv4/ipv6 and it is a very small change.

Daniel

---

From: Daniel Walton <[email-masked]>
Date: Sun, 17 May 2015 08:56:34 -0400

On Sun, May 17, 2015 at 8:47 AM, Łukasz Bromirski <
[email-masked]> wrote:

> Hi,
>
> Some of the vendors already have problems with the BGP code bloat. Of
> course session negotiation could take care of the additional feature, but
> would this option really change the world for BGP users?
>
> Also bear in mind, even if feature is not active on specific session, the
> code is still there, compiled, adding kBs of binary to existing code base.
> It can be exploited, it can contain some hard to catch bugs in non-trivial
> scenarios outside typical test cases... It can kick you in the balls during
> some complex migration where the bug will suddenly trigger itself.
>

Did you see the quagga patch and exabgp patch?  This is probably the
easiest bgp capability to implement there as ever been :)

> And BTW - last time I checked, BGP was still limited to 4kB segment and
> this space will all extended communities and so on is getting crowded very
> fast.
>

This is a capability in the OPEN message, the hostname is not exchanged as
part of the UPDATE.

Daniel

---

From: Daniel Walton <[email-masked]>
Date: Sun, 17 May 2015 08:59:34 -0400

IMO whether a vendor sends the capability by default or not, is a decision
left up to the vendor and not part of the draft.  We've been trying to
avoid adding new configuartion knobs as much as possible so we send it by
default.

Daniel

---

From: Daniel Walton <[email-masked]>
Date: Sun, 17 May 2015 09:01:38 -0400

> That'll be fine. We added fqdn to allow for cases outside the DC.
Dropping the domain name part of the draft and s/UTF-8/ASCII/ would be fine
with me.

> On a different note, OSPF has a far more involved modification to allow
> the carrying of hostnames (https://tools.ietf.org/html/rfc5642). I'm
> curious as to why that was considered OK.
>

ISIS as well:

Dynamic Hostname Exchange Mechanism for IS-IS

https://tools.ietf.org/html/rfc5301

Daniel

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 17 May 2015 13:02:22 +0000

Hi Dinesh,

From: Dinesh Dutt <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 17, 2015 at 8:07 AM
To: Thomas Mangin <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-walton-bgp-hostname-capability-00

On Sun, May 17, 2015 at 3:00 AM, Thomas Mangin <[email-masked]<mailto:[email-masked]>> wrote:

I stand corrected.

On a different note, OSPF has a far more involved modification to allow the carrying of hostnames (https://tools.ietf.org/html/rfc5642). I'm curious as to why that was considered OK.

Note that the OSPF mechanism advertises the host name throughout the area or entire OSPF routing domain so it is analogous to what Robert suggested with a new attribute or BGP wide community.

Thanks,
Acee

Dinesh

Thomas

---

From: "Thomas Mangin" <[email-masked]>
Date: Sun, 17 May 2015 14:15:46 +0100

> Some of the vendors already have problems with the BGP code bloat.

Agree, let’s close the mailing list, we are all guilty here :-)

> And BTW - last time I checked, BGP was still limited to 4kB segment 
> and this space will all extended communities and so on is getting 
> crowded very fast.

This is the first argument I fully agree with .. The draft should indeed 
have included some wording that the capability not not be added should 
the OPEN message be larger than the allowed message size with it.

> If the improvement is for operations and not for core of BGP, let's 
> deal with this at operational/NMS level (and possibly protocols).

I am not fully un-sympathetic to that argument but why not let customers 
vote with their money by asking their vendors what to implement or not. 
Not all implementations include all the BGP RFC !

My issue is that without a Capability number, any implementation of the 
draft could later lead to a conflict and DO cause real interoperability 
issue.

I already pointed to Cumulus that the code they have in their Quagga 
implementation (131) was used by Cisco for Multi-Session before it 
became an RFC ! Mine (72 - which I intend to change too) is perhaps used 
elsewhere too. _That_ could cause a problem (more than anything 
discussed in this thread IMO) !

Thomas

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 17 May 2015 12:13:26 -0400

> this would explain a *lot*!

Grand Wizard Randy,

But you already knew that.  :-)

Curtis

---

From: Randy Bush <[email-masked]>
Date: Sun, 17 May 2015 06:16:14 -1000

the solace for these bikesheds is that folk one misses surface

randy

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 17 May 2015 14:09:33 -0400

> to why that was considered OK.

OSPF can and often is run on unnumbered interfaces (or using link
local addresses in IPv6).  You can't use rDNS in these cases and the
router-id is not supposed to be an address so you can't be sure a rDNS
lookup of the router-id will yield anything useful.  [Realistically,
ISIS did it so OSPF felt obligated.]

AFAIK - BGP is still being run on numbered interfaces or bound to a
numbered loopback interface, which in both cases can be looked up
using rDNS to get FQDN.

If you use reuse PI space within the DC rather than routeable, or
unique allocation from 10/8, or better yet use IPv6, you create your
own mess and you are proposing changing BGP to bandaid over it.

Cluelessly yours,

Curtis

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 17 May 2015 14:25:17 -0400

On Sun, May 17, 2015 at 8:50 AM, Daniel Walton
<[email-masked]> wrote:
>
>
> On Sat, May 16, 2015 at 8:55 PM, Christopher Morrow
> <[email-masked]> wrote:
>>

equivalent to private addressing, in my opinion.

> works for ipv4/ipv6 and it is a very small change.

'is very simple' and 'very small change'... famous last words.

I suppose I hear this:
   "Automation in a network (DC or wide area) is moving forward. We
want to also be able to drop hints that 'peer ip blah is host X' or
the like."

Why not, since  you are automating things, all fancy and stuff, also
include the hostname in the config? (as mr. heasley points out).
Surely in your automated processes you'll know whom you are talking to
and can lay out the right config data as you go, eh?

The problem expands beyond the 'DC' when you add it as a generic
capability to BGP... we all have to pay for the 'solution' in other
gear/code/problems/poor-choices.

Also, this struck me as funny:
  " it works if routing is down (no DNS), "

err... 'if all routing is down', because if your peer is down it's not
working, right? This actually argues for Mr Heasley's position... put
the name in the config (gathered from your automation and network
discovery work) so when 'why is peer ff02:asd:as:as:asas:01 down?' you
can see instead: "Peer abc123 is down'.

-chris

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 18 May 2015 06:31:19 +0000

Hi Daniel,

This is an interesting document, a few years ago we proposed something similar in -00 version of draft-dong-idr-fsm-subcode (http://tools.ietf.org/html/draft-dong-idr-fsm-subcode-00), in which a new BGP capability called “BGP Session Information Capability” was defined, and “BGP Speaker Description” was one of the proposed TLVs in that new capability. Considerations about the impact on the Capability parameter space in OPEN message were also discussed.

My personal opinion on this feature is it may help the operation and troubleshooting, although the hostname information is exchanged only between peers, as opposed to the proposals in IGP extensions.

Best regards,
Jie

From: Idr [mailto:[email-masked]] On Behalf Of Daniel Walton
Sent: Saturday, May 16, 2015 9:26 AM
To: idr wg; Dinesh Dutt
Subject: [Idr] draft-walton-bgp-hostname-capability-00

Daniel

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 18 May 2015 10:05:35 +0200

hi daniel,

given the LL nature of the IP addresses (= no DNS) this sounds a reasonable proposal.

assuming that all name information go to some internal database for resolution:
have you put some thought on how to consolidate naming information from different
sources ? (bgp-hostnames, BGP-LS node/link names, LLDP ...)

/hannes

On Sat, May 16, 2015 at 12:08:35AM -0400, Daniel Walton wrote:
|    Many of our customers use a Clos architecture and bgp peer to the IPv6 LL
|    address of every directly connected router.  To avoid configuring neighbor
|    statements with LL addresses we support a "neighbor swpX interface"
|    command ("swpX" is the default notation for an interface name in cumulus
|    linux).  We then peer to the LL address on the other end of the swpX link
|    (we only support this for point-to-point links).
|    When you run commands like "show ip bgp summary" you see a list of
|    interface names instead of IP addresses. Typically if you are loopback
|    peering you either become familiar with "10.0.0.1 is Chicago" because you
|    see 10.0.0.1 in the 'show ip bgp summ' output of several different routers
|    or you could use DNS to do a lookup on 10.0.0.1 and put the hostname in
|    the output.  When every box is peering to LL addresses though ("swpX" for
|    short for us) you can't easily tell who that peer is and you can't use DNS
|    because they LL addresses
|    Before
|    leaf-11# show ip bgp summ
|    BGP router identifier 6.0.0.5, local AS number 65101
|    BGP table version 25
|    RIB entries 33, using 3960 bytes of memory
|    Peers 6, using 100 KiB of memory
|    Peer groups 1, using 56 bytes of memory
|    Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
|     State/PfxRcd
|    swp1            4 65000     196     198        0    0    0 00:02:51
|     9
|    swp2            4 65000     195     200        0    0    0 00:02:51
|     9
|    swp3            4 65000     197     200        0    0    0 00:02:51
|     9
|    swp4            4 65000     198     200        0    0    0 00:02:51
|     9
|    swp5            4 65201     207     200        0    0    0 00:02:51
|     2
|    swp6            4 65202     210     201        0    0    0 00:02:52
|     2
|    Total number of neighbors 6
|    leaf-11#
|    spine-3# show ip bgp summ
|    BGP router identifier 6.0.0.15, local AS number 65000
|    BGP table version 19
|    RIB entries 33, using 3960 bytes of memory
|    Peers 8, using 134 KiB of memory
|    Peer groups 1, using 56 bytes of memory
|    Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
|     State/PfxRcd
|    swp5            4 65101     675     675        0    0    0 00:10:49
|     5
|    swp6            4 65101     678     676        0    0    0 00:10:50
|     5
|    swp7            4 65101     667     668        0    0    0 00:10:48
|     5
|    swp8            4 65101     676     676        0    0    0 00:10:49
|     5
|    swp9            4 65102     701     692        0    0    0 00:11:04
|     5
|    swp10           4 65102     701     692        0    0    0 00:11:04
|     5
|    swp11           4 65102     701     691        0    0    0 00:11:04
|     5
|    swp12           4 65102     701     692        0    0    0 00:11:04
|     5
|    Total number of neighbors 8
|    spine-3#
|    spine-3#
|    After
|    leaf-11# show ip bgp summ
|    BGP router identifier 6.0.0.5, local AS number 65101
|    BGP table version 25
|    RIB entries 33, using 3960 bytes of memory
|    Peers 6, using 100 KiB of memory
|    Peer groups 1, using 56 bytes of memory
|    Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
|     State/PfxRcd
|    spine-1(swp1)   4 65000     211     213        0    0    0 00:03:07
|     9
|    spine-2(swp2)   4 65000     210     215        0    0    0 00:03:07
|     9
|    spine-3(swp3)   4 65000     212     215        0    0    0 00:03:07
|     9
|    spine-4(swp4)   4 65000     213     215        0    0    0 00:03:07
|     9
|    tor-11(swp5)    4 65201     222     215        0    0    0 00:03:07
|     2
|    tor-12(swp6)    4 65202     225     216        0    0    0 00:03:08
|     2
|    Total number of neighbors 6
|    leaf-11#
|    spine-3# show ip bgp summ
|    BGP router identifier 6.0.0.15, local AS number 65000
|    BGP table version 19
|    RIB entries 33, using 3960 bytes of memory
|    Peers 8, using 134 KiB of memory
|    Peer groups 1, using 56 bytes of memory
|    Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
|     State/PfxRcd
|    leaf-11(swp5)   4 65101    1119    1119        0    0    0 00:18:13
|     5
|    leaf-12(swp6)   4 65101    1122    1120        0    0    0 00:18:14
|     5
|    leaf-13(swp7)   4 65101    1110    1111        0    0    0 00:18:12
|     5
|    leaf-14(swp8)   4 65101    1119    1119        0    0    0 00:18:13
|     5
|    leaf-21(swp9)   4 65102    1144    1135        0    0    0 00:18:28
|     5
|    leaf-22(swp10)  4 65102    1144    1135        0    0    0 00:18:28
|     5
|    leaf-23(swp11)  4 65102    1144    1134        0    0    0 00:18:28
|     5
|    leaf-24(swp12)  4 65102    1144    1135        0    0    0 00:18:28
|     5
|    Total number of neighbors 8
|    spine-3#
|    It makes troubleshooting much easier.
|    Daniel
|    On Fri, May 15, 2015 at 9:58 PM, <[1][email-masked]> wrote:
| 
|      Agree.. adding code for no real operational benefit
| 
|      Sent from my BlackBerry 10 smartphone on the Rogers network.
|        Original Message
|      From: Randy Bush
|      Sent: Friday, May 15, 2015 10:52 PM
|      To: Daniel Walton
|      Cc: idr wg; Dinesh Dutt
|      Subject: Re: [Idr] draft-walton-bgp-hostname-capability-00
|      one more unneeded place for things to go wrong
| 
|      randy
| 
|      _______________________________________________
|      Idr mailing list
|      [2][email-masked]
|      [3]https://www.ietf.org/mailman/listinfo/idr
| 
| References
| 
|    Visible links
|    1. mailto:[email-masked]
|    2. mailto:[email-masked]
|    3. https://www.ietf.org/mailman/listinfo/idr

| _______________________________________________
| Idr mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/idr

---

From: <[email-masked]>
Date: Mon, 18 May 2015 09:27:50 +0000

> From: Idr [mailto:[email-masked]] On Behalf Of Christopher Morrow
> Sent: Sunday, May 17, 2015 2:55 AM
> 
> why solve this in the bgp space? why not solve this in any of the other
> domains much better built for this?

+1

e.g. what about SNMPv1? Seems to fit all requirements:
- simple 
- available now
- works if routing is down
- works in lab
- works for all "upper" layer protocols / same name for all
- works with link local
- authentication/encryption not required
- no configuration needed  (use IP@ for the BGP session)

Regarding MIB, either MIB-II System name (1.3.6.1.2.1.1.5), or a to be standardized "BGP name", or a vendor specific OID. 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 19 May 2015 12:47:03 +0100

> Feedback is welcome. There is a "Sectino" typo in the intro, will clean

I like this idea because it makes my life as an operator easier.

There is a similar option in ISIS for transmitting hostnames in ISIS.  This
is operationally useful for a wide variety of purposes.

I would suggest that it would be more appropriate to define a generic text
bgp capability along the lines of draft-ietf-idr-advisory, and define the
BGP hostname as a subtype rather than using a dedicated bgp hostname
capability.

Nick

---

From: "Neil J. McRae" <[email-masked]>
Date: Tue, 19 May 2015 13:25:35 +0000

have to say I’m with Randy on this one. Not sure why this is needed.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 20 May 2015 10:42:03 -0400

> Feedback is welcome. There is a "Sectino" typo in the intro, will clean

At John's request, here is a short list of things I find problematic about
this draft.  Note that this isn't a statement of my opinion on the value of
it.

1. The draft really should require the ext-opt-param feature.  It's too easy
for a hostname to eat all of the capability space.
2. You can't rely on the hostname in question being useful for DNS purposes.
The IPv6 link local peering is just one example of why.
3. The specification should offer some guidance about what to do when you
have multiple peering sessions with a given router.
4. The specification should offer some guidance about what to do when two
distinct routers use the same name.

Note that 3 and 4 can be distinguished based on BGP Identifier.

As for the UTF-8 issue, it's the right thing to do and as much as it makes
things a real mess, the draft wouldn't progress in IESG without I18N issues
being dealt with.

That said, carefully consider what you expect to do with the names returned
by such a feature.  Just because you can print the things, does that mean
the input portion of your UI can accept it?

-- Jeff (best I can do with anything that isn't Latin-1 is cut and paste)

---

From: Daniel Walton <[email-masked]>
Date: Wed, 20 May 2015 13:19:05 -0400

Hi Jeff,
Thank you for the feedback.  Questions/comments inline...

> for a hostname to eat all of the capability space.

I think requiring ext-opt-param should be fine.  Agreed that if someone
configures a 255 character hostname and 255 character domain name that
would be problematic with the current draft.

> The IPv6 link local peering is just one example of why.

The hostnames learned should only be used for bgp UI purposes, we have no
plans to try to auto-populate DNS or anything like that.  We will add some
text to clarify this.

> Note that 3 and 4 can be distinguished based on BGP Identifier.

Ack.  We can put in a section of sample show command output with some
possible ways to handle these scenarios.  How one decides to display this
will obviously be implementation specific but some examples can't hurt.

Daniel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 21 May 2015 02:39:42 +0000

Hi Nick, 

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Nick Hilliard
> Sent: Tuesday, May 19, 2015 7:47 PM
> To: Daniel Walton; idr wg; Dinesh Dutt
> There is a similar option in ISIS for transmitting hostnames in ISIS.  This is
> operationally useful for a wide variety of purposes.
> 
> I would suggest that it would be more appropriate to define a generic text bgp
> capability along the lines of draft-ietf-idr-advisory, and define the BGP
> hostname as a subtype rather than using a dedicated bgp hostname capability.

Totally agree with this, and actually the "BGP Session Information Capability" as defined in draft-dong-idr-fsm-subcode-00 (only in the -00 version) can meet your requirement, in which the "peer description" is just one of the subtypes. This part was splitted out from later versions of draft-fsm-subcode, but this mechanism can be used if such information needs to be exchanged.

Best regards,
Jie

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 26 May 2015 09:37:43 -0400

> avoid adding new configuartion knobs as much as possible so we send it by

I support this draft generally, it provides a useful feature for DC
fabrics and many other troubleshooting use cases for i/eBGP.  However, I
think the draft should say "implementations SHOULD provide a knob for
disabling the sending/use of received information in this capability".
I can imagine there are a number of organizations that for various
reasons may want to use this only on some peerings or not at all, or
don't want their troubleshooting output mangled by information from
various peers.  I don't see this relationship of where to turn this
on/off easily tied to protocol differences (iBGP/eBGP) or other
attributes.  Also agree with the comments that hostname only in ASCII
should be sufficient.

-Jon