IETF Logo Mail Archive

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

"Thomas Mangin" <thomas.mangin@exa-networks.co.uk> Sat, 16 May 2015 15:59 UTC

Return-Path: <thomas.mangin@exa-networks.co.uk>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6CD1A8984; Sat, 16 May 2015 08:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.999
X-Spam-Level: **
X-Spam-Status: No, score=2.999 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ut0XnRH9bFr; Sat, 16 May 2015 08:59:26 -0700 (PDT)
Received: from out-1.mail.exa.net.uk (out-1.mail.exa.net.uk [82.219.4.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F07A1A8923; Sat, 16 May 2015 08:59:26 -0700 (PDT)
Received: from smtp-1.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id 674AC1C027A; Sat, 16 May 2015 16:59:23 +0100 (BST)
Received: from smtp-1.mail.exa.net.uk (localhost [127.0.0.1]) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id 4F7D0221413; Sat, 16 May 2015 16:59:23 +0100 (BST)
Received: from [10.37.129.2] (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTPSA; Sat, 16 May 2015 16:59:23 +0100 (BST)
From: Thomas Mangin <thomas.mangin@exa-networks.co.uk>
To: idr-bounces@ietf.org
Date: Sat, 16 May 2015 16:59:09 +0100
Message-ID: <FC7F6336-4846-4C4C-B002-4DE255F10B2A@exa-networks.co.uk>
In-Reply-To: <CANL=f0iPLinA6Qr8-r6mev4474UZT9g5Bjng_6+f7xPZ2zdfVg@mail.gmail.com>
References: <CANL=f0h9ZV+SPr+2vcx2dEk4O9MxBAZJEU7xgHZDC=ep2g2r-g@mail.gmail.com> <m2bnhlwaov.wl%randy@psg.com> <20150516015819.5849234.74476.67011@gmail.com> <CANL=f0gAfs9f-Jt7r3bxMfB7f3Ta+funv8nvmkiCmFsQfGHTcg@mail.gmail.com> <CA+b+ERmY46GHLJUhi5PzwyVJ4Wcns_R11QXC=oLMzAXrYi-v2g@mail.gmail.com> <CABg5FUV5Z+S_m6V7=dB_cuOZpDV-MS_cV+mhwERtjaNCiNfT2w@mail.gmail.com> <CA+b+ERmCpjbBmNAeFyNm6_KTWtOB41Zge559O4jbtEjwKG+yXg@mail.gmail.com> <CABg5FUVSq4Xunivo3tBNh0=x+W=ZOD9pUYGWs18EcuXiFG-4MQ@mail.gmail.com> <CA+b+ER=m_LttyMumi+JLd1cfTLqk16RAQgfbX4qmxGAh1k5Wxw@mail.gmail.com> <CANL=f0iPLinA6Qr8-r6mev4474UZT9g5Bjng_6+f7xPZ2zdfVg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.1r5084)
X-Virus-Scanned: clamav-milter 0.98.7 at out-2-2.mail.exa.net.uk
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/58L1u735tVR2yO70vovmC73bdlA>
Cc: idr wg <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [Idr] draft-walton-bgp-hostname-capability-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 May 2015 15:59:27 -0000

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

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

v2.23.0 | Report a Bug | By Email