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

Dinesh Dutt <ddutt@cumulusnetworks.com> Sat, 16 May 2015 19:20 UTC

Return-Path: <ddutt@cumulusnetworks.com>
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 BAEEC1A1AC6 for <idr@ietfa.amsl.com>; Sat, 16 May 2015 12:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 DNklSOVSwcaE for <idr@ietfa.amsl.com>; Sat, 16 May 2015 12:20:55 -0700 (PDT)
Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6778A1A1AB4 for <idr@ietf.org>; Sat, 16 May 2015 12:20:55 -0700 (PDT)
Received: by yhda23 with SMTP id a23so41150760yhd.2 for <idr@ietf.org>; Sat, 16 May 2015 12:20:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=r6pt+3XyGXDSgdMVa9dzWLfRZFapZq3rsTX2adyP0AI=; b=DzngtXtSIytkO9KP9a7VikZ8CblR93NUZWt6lhLlHdcpAkICJh/ha+un7ti0QBTcHW JhZt5U4hPN/nZIOoKJgOd4z8+Sd/qEyUcldnz15mv0IxrKEVrAo+UaP77bVN5qisooPD yrmahZioOwUoCpa0NLOBIuuNUz0w0VzleMtgM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=r6pt+3XyGXDSgdMVa9dzWLfRZFapZq3rsTX2adyP0AI=; b=CISQXJTSOXqqes4E/tQe+39CkwakWzyE0PDyx0mZeyrI/hSaUyV+js6poPCQ4t9PMS nPuIm2BTW7XmVXoKOgg79MXZstg/3XusuMcXFOE9adWO81h3aq9KIuniwMBsT8G84gQQ xbq1QydkxpDqiiVCv6ZxS2vjS7beN2OBpWvta8vYOoPKwUrSZIP3WmtAG+vMARf3PGdr b0+zGL/fsJYRYRxuzLK4zwsfytFubrVhLQ1lD2t0hlESRYXwABD94Fsu80rFIDjXDaTT vTKTdp+cv8h5ck4c0wL+hW+kdaiZm6/Rip5/RpzUxOurfRQ19nYMLSn06bWIx/olAE5k gULw==
X-Gm-Message-State: ALoCoQnXqKEyz3wQa06fu/JmnuxVWwJ6EMDYD45DIAPqnWK4SJxEevNLdE4Nds4zaFT/A4lm74+d
X-Received: by 10.170.81.87 with SMTP id x84mr17566248ykx.113.1431804054813; Sat, 16 May 2015 12:20:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.103.8 with HTTP; Sat, 16 May 2015 12:20:34 -0700 (PDT)
In-Reply-To: <CANL=f0gK01FXaCXj9jKiNWw951zksC66yx9Z=8Bu5J70bC_dBA@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> <CA+b+ERmpCfa2ns5bfd7FJvsG_-5jGX+_QG9oBzK0b8GD1yhveg@mail.gmail.com> <CANL=f0gK01FXaCXj9jKiNWw951zksC66yx9Z=8Bu5J70bC_dBA@mail.gmail.com>
From: Dinesh Dutt <ddutt@cumulusnetworks.com>
Date: Sat, 16 May 2015 12:20:34 -0700
Message-ID: <CABg5FUWEQKrM_NEZVsuGd0S6OSvkdd7OB11-uXbUW+zY9t1dxQ@mail.gmail.com>
To: Daniel Walton <dwalton@cumulusnetworks.com>
Content-Type: multipart/alternative; boundary="001a113a908e13568a051637dc0e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/hMJKteoL8bVaTtPCaX_Ql7bqkz0>
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 19:20:56 -0000

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 <dwalton@cumulusnetworks.com
> wrote:

>
>
> On Sat, May 16, 2015 at 9:03 AM, Robert Raszuk <robert@raszuk.net> wrote:
>
>> ​Hi Daniel,​
>>
>>
>>
>>> If DNS is down how does that make knowing the hostname of a LL BGP peer
>>> useless?
>>>
>>
>> ​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.
>>
>
> Ack, we'll add some text that gives some examples of how/why an
> implementation might use the hostname data.
>
>
> 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 :)
>>
>>
> 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
>
>