Re: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.

Alexander Azimov <a.e.azimov@gmail.com> Tue, 16 June 2020 20:00 UTC

Return-Path: <a.e.azimov@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 E03483A08AC for <idr@ietfa.amsl.com>; Tue, 16 Jun 2020 13:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 E98AT1hGjpZm for <idr@ietfa.amsl.com>; Tue, 16 Jun 2020 13:00:00 -0700 (PDT)
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 97A5F3A08AA for <idr@ietf.org>; Tue, 16 Jun 2020 13:00:00 -0700 (PDT)
Received: by mail-oi1-x22f.google.com with SMTP id 25so20363718oiy.13 for <idr@ietf.org>; Tue, 16 Jun 2020 13:00:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4/KOe5ph7F1pF5DOn5ev73ObnstvybUujoDg1paWTFo=; b=JkR01iNcX6C+AbfdfYsyUhqEJ1Wg8LT07dXX6EhzSbVQz6jBFMw7QnohRydqtLBKkM ljaeC7HTpa5VcZYzfSeQd0Jl5Ydslt9irjob+IkfvDySGnCV6hSWsZN++68nm/Hofoey nTDqD3VWE0VEDueyNw9S5UAxvl1t/TMeGZMFmB6EVj4gc3jIPI9uGDYmWO6bjTqh9B7a S+ZbqLErSVDSxEgG3iPtoh9VQl/C6peiv0QZcYBdnCqpYHUDLLXlMGTFjSa2CTOG25Lt ieSKVo68B7HItzMPmdoBh4vssB74B9+SUWXbOhftVYqBKs+xSI4obDX+evQRcSgGOZdT XcbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4/KOe5ph7F1pF5DOn5ev73ObnstvybUujoDg1paWTFo=; b=Rc8JZmMzDQ6LMN7+z44c0aR1ndI8Lw4moKhK1rBt8JVNUotcIQA9/c1ASJy7bGvCz9 Hfrgh5FTQXwb9X2c/eq+H8A367ulNNwJahcaxBU6DXG74dtzTORMCCIoN4lnrYJ0EsY3 eLn+Wzrc8ogCBzfhChKbzxeu7NEcc0vYv4taVQFqF2b77y7KfEdFqIBSS9xG30gnxu76 pMMdZQfQmEk1UQIKsCWc+QlSncGmC/E7hRTQ6JJgI6wdPWilRCc4q4CMZ1tnjFDD5msU F7++mJhA3G+bnfZjg3bO0VI5O63MR/U9aFHxo+Kc5cf/2YWGyOUT1ohZhA6yi9k9zZBm n6vA==
X-Gm-Message-State: AOAM530A6Zh3cDDB4wJXAlnFHqWxdmLJBaVpHbE7tsD0cppRuT8sEW1J e6LdnWUZaCPMJVHD/1t5ftEzcyquRcUdIhxM7DQ=
X-Google-Smtp-Source: ABdhPJxS8+Ws0d1/SADRxzksjwm9kdWmEEV3ZbPUUjMjvQ+IE9kEUJD2fNNXX2gOQl26RKSf1Nx33+NWM3NMYu5diog=
X-Received: by 2002:aca:d884:: with SMTP id p126mr4976444oig.4.1592337599711; Tue, 16 Jun 2020 12:59:59 -0700 (PDT)
MIME-Version: 1.0
References: <005901d63ab5$d6003e00$8200ba00$@ndzh.com> <xYEQPENpYuG2jhRQLLPPFqEtAVXGmqrvBx5utttybbIYY3uFj0sqcaD8344GaN2eb98bz9hfpd9nPHh9qTb4WP9EcYnZdmg4itWE2EZ6X4M=@plunin.net> <CABNhwV0fF+TOgJuEud-44rMBYaym1Oe1kEcLoAQavaU31i9Yzw@mail.gmail.com>
In-Reply-To: <CABNhwV0fF+TOgJuEud-44rMBYaym1Oe1kEcLoAQavaU31i9Yzw@mail.gmail.com>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Tue, 16 Jun 2020 22:59:48 +0300
Message-ID: <CAEGSd=Cic7ig7PS72i-rUnx8f0sAbwZSOLZjBoSWEAH5EU5vgA@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Pavel Lunin <plunin@plunin.net>, "idr@ietf. org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="000000000000fe4da205a838fcad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CPjoEqyDuyDXYkqzNwc0gupuikk>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 16 Jun 2020 20:00:03 -0000

Dear colleagues,

In the last days, I have accumulated comments that were received both
on-list and off-list. I'd like to thank all who contributed to the improved
quality of the document. Accompanied by minor changes there are two
important edits that I'd like to highlight:

   - We clearly specified the scope of the Roles configuration: 'BGP Roles
   SHOULD be configured on each eBGP session between ISPs that carry IPv4
   and(or) IPv6 unicast prefixes'. In section 8 there is also an explicit
   statement that the applicability of Roles for other address families is out
   of scope of this document.
   - The registry for Roles now has three parts: Expert Review
   (0-127), First Come First Served (128-251), and Experimental Use (252-255).
   The statement is added that guarantees that newly defined roles will not
   pair with Roles defined in the draft.

Since these changes don't affect the OTC/Role mechanics no changes and
needed in the implementations.
The new version of the draft is available:
https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-11


пт, 12 июн. 2020 г. в 20:47, Gyan Mishra <hayabusagsm@gmail.com>om>:

> Hi Susan
>
> I agree with Pavel’s important point in the draft in that this feature
> would be for “inter domain” which from internet perspective would be ASBRs
> ties interconnection between providers thus “eBGP” only and could be over
> AFI/SAFI 1/1 2/1 1/128 2/128.
>
> I mention the SAFI 128 as the internet has mix of carriers having internet
> table carried in 3 scenarios — global table IP backbone, global table over
> mpls, IP VPN.  In the IP VPN case their are providers that segregate global
> table to be clean of customer routes with only connected interfaces IGP for
> P,PE,RR reachability and Internet table carried in a dedicated internet
> VRF.  In those cases inter-as carriers may do mpls inter-as option or if IP
> only an IP based bgp policy.  Their maybe some cases but less often where
> MPLS is used over internet and public internet and private is carried over
> the same MPLS transport.
>
> Those permutations of the operators network inter-as types maybe important
> to mention as may impact the use of role feature.
>
> The main use case is for internet providers but could be used for large
> enterprises as well.
>
> Once vendors implement the feature any operator can use for any use case
> so which is why it’s critical to keep disabled by Default.
>
> That being said we would not want the role priority feature to be Default
> enabled since you cannot distinguish eBGP or iBGP from a MP reach
> capability standpoint it really has to be disabled by Default.  This would
> allow in a controlled fashion by operators to enable on their “inter-as”
> ASBR-ASBR boundary ties only.
>
> Kind Regards
>
> Gyan
>
> On Wed, Jun 10, 2020 at 9:02 PM Pavel Lunin <plunin@plunin.net> wrote:
>
>> Hi Susan,
>>
>> 1) I support the advancement of this draft to publication.
>>
>> A little comment though. The so called "Gao-Rexford model" and more
>> generally role-based relationships logic is mostly applicable to eBGP
>> sessions. iBGP sessions are usually 'complex' in terms used in this
>> document, so assigning roles to iBGP speakers seems practically
>> unnecessary. From the implementation point of view it doesn't change a lot:
>> ability to assign roles to iBGP speakers doesn't seem to make any harm, and
>> having the option of not assigning the roles lets the network operators
>> make the decision whether they want to change the today's behavior of iBGP
>> default policies.
>>
>> However from the operational point of view it's somewhat unclear if
>> authors propose to configure roles on iBGP sessions. The general term "BGP"
>> is used everywhere throughout the document (with an exception of only one
>> occurrence), so it might seem that the document recommends to set the roles
>> on all iBGP sessions as well as eBGP. Here it might look evident that the
>> general context is inter-domain routing, so the document covers eBGP.
>> However the potential audience of this document is very broad, including
>> people not very experienced in BGP operational practices (this is were
>> route leaks often come from) so I would suggest to make this point more
>> explicit. Probably some occurrences of the word 'BGP' should be replaced by
>> 'eBGP' or just a little sentence/paragraph is needed to make this point
>> clearer.
>>
>> > By default, strict mode SHOULD be set to false for backward
>> compatibility with BGP speakers that do not yet support this mechanism.
>> Same here. "Backward compatibility" suggests that in future all or almost
>> all BGP sessions should be configured with roles while it's not totally
>> correct: iBGP speakers won't probably ever need roles and role-based
>> policies.
>>
>> This being said, this nuance only affects operational practice
>> recommendations. Protocol behavior specification, as defined by the
>> document, looks good: both eBGP and iBGP can be configured with roles if
>> needed.
>>
>> 2) Deployments of this extension will be valuable for almost all use
>> cases where eBGP is used to exchange public Internet routes.
>>
>>
>> Kind regards,
>> Pavel
>>
>>
>> Please comment on the following questions:
>>
>> 1) Is this specification ready for publication?
>>
>> 2) Are there deployments where this BGP protocol extension is valuable?
>>
>> 3) Do you believe the error code handling is ready for publication?
>>
>>
>>
>> The shepherd for this draft is Susan Hares.
>>
>> During the WG LC, the shepherd’s report will be sent.
>>
>>
>>
>> Cheers,
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>


-- 
Best regards,
Alexander Azimov