Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 09 June 2016 20:09 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7059812D9C0; Thu, 9 Jun 2016 13:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3B3auMOs5sbq; Thu, 9 Jun 2016 13:09:56 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 B159012D734; Thu, 9 Jun 2016 13:09:55 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id k204so75167156wmk.0; Thu, 09 Jun 2016 13:09:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hK8t3MxIj2/4I8Na5CE3UlxKlGnH50+WrCTyljdkNTE=; b=CvlgGpE5TT/mF+l9tAn21TfgWzo0pOkgkyMII0q2rPlYhjy1B+iz7gjZuqQ0bQTxen uFHK37/vGmvwQqwBzlZRSa9bQ2fIs7RDsw/LCqSViE7GH7BBPB9AZky2EPLbyE68NBAX 23sJ4vWBd3uyWo9rSz5JT+QeRU91Y4FnSo4fxsAzZSpz0h2eyqMSmffqFwK04okFKJYT M9Lpn4n2Gx5TDEZaUIHXrog+Rsn0eZtD76gPLwAVTyPHalaw9IDdYz6I/HN9X6yjEMrc Y3DfaCunIqzI9inuga4xlArs8RhRk/qAT2sGyXlCTWPYkx8Phn6W6B7tF5rZwr3kunbR 9PvA==
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; bh=hK8t3MxIj2/4I8Na5CE3UlxKlGnH50+WrCTyljdkNTE=; b=EK6fHXDGIjepvaXyHLbqZE9UZ7Zk6UXaVhTWLZbiGHaUSJw27TeXtAegdWnyS9mtvf aMPrhSl/MmCO4H352CFjkNJYDWIAJ+z4GQiRnCj731KpJRZ2nrikvsMJqcYWoQUNj97m cVtSDCS0eulfNOg44Q9MnQH3Jtw36WQx2fkctlDmmLGlcnwgHjx9rlYaa54eVTQyfQ8h qNySK0As81JoPtfLUgAXTV5wbCBqHi9hlrdcGb/vQu5T91vYdX1xxOaD9KQGCgNqQoMK JzbpEivyfkxS/aRAuKwGpHeeRM18gc+pGf3e7BK+6yiO/99MQyLG0uGbCM0+I81oL7dr z0sg==
X-Gm-Message-State: ALyK8tI4RU45YqvEHK8jhEwj/7vW9AXPlVNk3kj9yxNfunZRJgHIl5pr+fegF0rcKaHQAzcpAquJcB9k6o71Cw==
X-Received: by 10.194.25.135 with SMTP id c7mr3805452wjg.63.1465502994284; Thu, 09 Jun 2016 13:09:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.127.195 with HTTP; Thu, 9 Jun 2016 13:09:53 -0700 (PDT)
In-Reply-To: <m2mvmuupax.wl%randy@psg.com>
References: <012e01d1c012$1d05f8d0$5711ea70$@ndzh.com> <20160609163225.GC2524@Vurt.local> <m2mvmuupax.wl%randy@psg.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 9 Jun 2016 13:09:53 -0700
Message-ID: <CAH1iCio0GrhczkM0twQPU+QsfMGwEtjHHHqz0W+bAtRqG-X1ag@mail.gmail.com>
To: Randy Bush <randy@psg.com>
Content-Type: multipart/alternative; boundary=047d7b2e11296448f30534de0109
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/3bY36bgH_D7GsHG3vHOD_oU4Cdw>
Cc: IETF IDR <idr@ietf.org>, draft-ietf-idr-route-leak-detection-mitigation@ietf.org, "John G. Scudder" <jgs@bgp.nu>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 09 Jun 2016 20:09:57 -0000

I am not 100% certain, and don't speak for them, but I believe Hurricane
Electric (HE) often has peers who use them for both IPv4 peering and IPv6
transit; I don't know, but would guess that at least some of those are over
a single MP-BGP session.

Brian

On Thu, Jun 9, 2016 at 12:37 PM, Randy Bush <randy@psg.com> wrote:

> > Secondly (and more importantly), the roles are not necessarily a BGP
> > session-specific characteristic, but rather a prefix-specific
> > property.  The proposed OPEN method does not provide for this level
> > granularity if I am reading it correctly. The method would affect all
> > prefixes exchange over a BGP session, without exception.
>
> i can not be sure, as you lack example.  but the example i commonly use
> is when A gives B local peering and also sells B global transit.  today,
> this is two separate sessions.  do you use another approach; not can
> think of, but actualy use?
>
> are there other real-world examples?  just trying to understand.
>
> randy
>