[Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
Tony Przygienda <tonysietf@gmail.com> Tue, 19 July 2016 10:06 UTC
Return-Path: <tonysietf@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 AC60D12D1A2 for <idr@ietfa.amsl.com>; Tue, 19 Jul 2016 03:06:49 -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 xYvoxDpE72hO for <idr@ietfa.amsl.com>; Tue, 19 Jul 2016 03:06:46 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 6DEC712D5CC for <idr@ietf.org>; Tue, 19 Jul 2016 03:04:36 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id f6so87815159ith.1 for <idr@ietf.org>; Tue, 19 Jul 2016 03:04:36 -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; bh=e6/n7BFaDV0yf1jek5+qkX/a5MWCbQ/nz6oHlfwkRto=; b=N5AzpkFVN3K/m/3JRn+E22osJlXBTVOolYbgt+7hgfbTgyr/tMBbITTnYkMJm+qDk7 E9B2DsEpFYt78rW7eqQoVuCXwna6NsWUVXlV78+iRwHWVML2utbuKwiPpa+hfVrTyZFu hzV6QnaVKpYMlB2DzLb+VQZW3MJzPOHqD4F3yRkCF0uzwDxbe4JbH0jKtx+eXzyQk0pO +m9JJVGfgZIblblMp4mzZtRirGz8Ktym1spe0FGjgHfQqdHP45BdFnn8+niXBSDLaa4+ BPukCSAVzKehiiUzpb5E9yJvyXwV+sM86kIpcLoR9cvZ8QBvy2nay9jSAk1cfvmDp5fb Lcaw==
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; bh=e6/n7BFaDV0yf1jek5+qkX/a5MWCbQ/nz6oHlfwkRto=; b=R8HLa/hO3lYZZIDfAforAcfgNrXKgdVC1yX0zTJJyIimP4INdH0Ouvn7Whd3cvav2A OKfjd+IfvkjwYWtCMmgRDbQmun7G2AT48vDRYz2g71WsWRgLT9WbjBTFljEMq5ojQgPL wyMDFO9K9ANYOLwQ/DzffAAMmOq6UKU6I4LAY1EvpTUtrGcuyX+fxu7bLMLSuqriJl7q aYKpLcgcrNRhKXgeqf5Ehq56jNMT+6pMNrpQk9brorNBAKZPt4jegExjL61IMOCm8chZ wOjb1DS4RzGQwn7nG0mJCkQ2vfHokuILufbuv9a+LlrLY5bkbRTX+2RxU/ohbt45idv/ N3zw==
X-Gm-Message-State: ALyK8tL9yns8TuhI5r8iqBXfoC8E87gLRn3gJpxR6kuCXtN4T5dFrXA9ZKc1Nrxeml+0RS2BCPU4zHcU3am8SQ==
X-Received: by 10.36.19.75 with SMTP id 72mr2777388itz.83.1468922675756; Tue, 19 Jul 2016 03:04:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.158.82 with HTTP; Tue, 19 Jul 2016 03:03:56 -0700 (PDT)
In-Reply-To: <CA+wi2hMsbVetW_D+HpsdXEHyh75yZkx+QTpj+FoX2hMTcqbrzw@mail.gmail.com>
References: <CA+wi2hM+y_K+_50Q_QRS64VBdzgBWtx8hL-6iepsVqed+NtqTw@mail.gmail.com> <CA+b+ERm2AnRAYeJRDdsAh=hLX81aQUTVd7Pe5PYLpWmHNvbgtQ@mail.gmail.com> <CA+wi2hMsbVetW_D+HpsdXEHyh75yZkx+QTpj+FoX2hMTcqbrzw@mail.gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Tue, 19 Jul 2016 03:03:56 -0700
Message-ID: <CA+wi2hNk2+GLY0G800Uo8qgdZQWh=9AzFGhZTk+fWRd6isgriw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary="001a1145180a4a88170537fa36db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/3Mv9TA58ggjkNHmN260SsxZFVv0>
Subject: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
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: Tue, 19 Jul 2016 10:06:50 -0000
Resending ... ---------- Forwarded message ---------- From: Tony Przygienda <tonysietf@gmail.com> Date: Mon, Jul 11, 2016 at 3:04 PM Subject: Re: [Idr] Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt To: Robert Raszuk <robert@raszuk.net> Cc: idr wg <idr@ietf.org> On Mon, Jul 11, 2016 at 1:47 PM, Robert Raszuk <robert@raszuk.net> wrote: > Hi Tony, > Hey Robert, thanks for chiming in. Good questions. I speak here for myself, other authors of the draft may have differing opinions. > > Can you clarify what is the expected behaviour as far as per peer > filter-list when you negotiate both Refresh with options, ORF and RTC ? > Note that ORF also includes recent extension as described in RFC7543 - > would all of those be always a logical AND towards a peer which pushed > those ? > We didn't discuss that one through but the only logical conclusion for me is that the ORF/CP-ORF installed are respected (i.e. it's an implicit AND). I see ORF as statefull, remote-pushed policy on the peer that is not being flipped around all the time (albeit AFAIR there were some attempts @ non-persistent, one shot ORF but that ended up expiring?) The motivation for this work were scenarios where a single-shot refresh is needed, actually concurrent bunch of those based on configuration changes, peer having dropped received routes based on specs (A-D), in policy changes, joining VPNs, EVIs and so on. Putting ORF on a peer, refresh and remove ORFs is significantly heavier process that may interfere on top with normal update process going on and needs to be done one-by-one (since you have to wait for single BoRR/EoRR pair) unless one is very smart about combining ORF possibly & playing with the DEFER/IMMEDIATEs. As we indicated, if the AFI/SAFI is covered by RTC and RTC is supported & one is willing to configure RTs for each subset of routes that may need refreshing, RT will be doing the same job just fine. > > Would you always carry ORF with separate Refresh_ID value ? > Yes, Refresh-ID# is strictly monotonic so there is never a misunderstanding WHAT the BoRR belongs to. Observe that the draft does NOT mandate that a request MUST be followed by according BoRR, only that BoRRs must follow same sequence as requests (i.e. are also strictly monotonic). However, we should probably specify that options _and_ ORF can NOT be mixed in the same type #3 message but it's either one or the other (and anything else is error). This will allow ORF operations like today + benefit of the Refresh ID# on the BoRR so the IMMEDIATE can go on @ the same time as another request with higher Refresh ID# (de facto we allow multiple parallel refreshes as you see). In case of DEFER there will be simply no BoRR for it. > > If one requests full Adj_RIB_Out in the new model and sends refresh > message with new refresh_id and no options however there are ORF entries > already installed in the past would he get just the subset of routes > against all ORF entries ? In other words I think the draft should state > that Refresh_IDs have no impact to ORF ADDs or REMOVE actions - don't you > think ? > I agree. Yes, ORF is kind of "permanent filter" on the peer while the intent of this draft is to have bunch of "small refreshes" going on @ same time possibly (if you request the refreshes from a good implementation while low-end implementations may serialize the requests to simplify internal logic ;-). > > As far as current types why not add regular/extended community ? > Discussion came up. Feeling was it's an immediate encroach on RT territory. I argued for it ;-) Ultimately, taking a more relaxed view, we chose to wait and see what the response is and most pressing use cases people bring to it and then we start to define bits and bytes of the options supported, possibly borrowing to an extent from the ORF specs ;-) As in "most sincere form of flattery" and such ... ;-) -- tony -- *We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* —Robert Wilensky
- [Idr] Slot request in IDR to present https://www.… Tony Przygienda
- Re: [Idr] Fwd: Slot request in IDR to present htt… Randy Bush
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Tony Przygienda
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Tony Przygienda
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… heasley
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Tony Przygienda
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Tony Przygienda
- Re: [Idr] Fwd: Slot request in IDR to present htt… Randy Bush
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Randy Bush
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Niloofar Fazlollahi
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Keyur Patel (keyupate)
- Re: [Idr] Fwd: Slot request in IDR to present htt… Keyur Patel (keyupate)
- Re: [Idr] Fwd: Slot request in IDR to present htt… Dongjie (Jimmy)
- Re: [Idr] Fwd: Slot request in IDR to present htt… Dongjie (Jimmy)
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Jakob Heitz (jheitz)
- Re: [Idr] Fwd: Slot request in IDR to present htt… Jakob Heitz (jheitz)
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Keyur Patel (keyupate)
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Dongjie (Jimmy)
- Re: [Idr] Fwd: Slot request in IDR to present htt… Robert Raszuk
- Re: [Idr] Fwd: Slot request in IDR to present htt… Jakob Heitz (jheitz)
- Re: [Idr] Slot request in IDR to present https://… Xuxiaohu
- Re: [Idr] Slot request in IDR to present https://… Robert Raszuk
- Re: [Idr] Slot request in IDR to present https://… Tony Przygienda
- Re: [Idr] Slot request in IDR to present https://… Robert Raszuk
- Re: [Idr] Slot request in IDR to present https://… Tony Przygienda
- [Idr] Fwd: Slot request in IDR to present https:/… Tony Przygienda
- Re: [Idr] Slot request in IDR to present https://… Tony Przygienda
- Re: [Idr] Slot request in IDR to present https://… Robert Raszuk