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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 17 June 2020 21:55 UTC

Return-Path: <hayabusagsm@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 31B633A081D; Wed, 17 Jun 2020 14:55:11 -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 KvHWGuzQJtNT; Wed, 17 Jun 2020 14:55:09 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 3837B3A0844; Wed, 17 Jun 2020 14:55:02 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id w18so4762769iom.5; Wed, 17 Jun 2020 14:55:02 -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=i940Z1gWHDtLQ4fYITzmGveXxRRD5Z5D/sBWr96GPEA=; b=KW2qtwiqT39BibBchYfj7pc4klaLkv80uAqgsv6xWHBKoMLJh0sHROMOBOWDgvjfbY uzlRSEGglr/C/ehifHDBQzkwqhgnT4FnNA6UGrvFFlZ8JPPgp1nE7NczhGVeLvm6YRZ6 r3sXm5wPVt4qO7lRnzOg83CIgRGnKgALvotqFXtxFVRCLzfVvOwAVwYsqrcGOnMS3hh+ plOQejaDWJUC9nCtiwJ9Br2M0bLPO1t8ZfEPFl9LypT2wakan//OWEXBfKOu3keAXbUe dLETLF4FlkkuDTKd64/d7TA7Khtu9Kzur8QPW3Gzh0XlNGuAiZqomhx2xMSrlW1/3CDv x4hw==
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=i940Z1gWHDtLQ4fYITzmGveXxRRD5Z5D/sBWr96GPEA=; b=SVXzJCNf5YTw/8mc0BynFbLmzykBoRAyRAibU5OIZQwqHui5cQ4k/tHgXk5Ep5MHMP 8Z/brRRy6c5UPOxa97H/FD1Agci1U9G1kVK03IYGmHbQ3Y7vOykgEHqlDxfBTPUkQJ6f Lk2z5ax3EM6tbCGLeaElwC+4GNZ08c3K7GvM0ETqwV9HayDwwJrI6aYYRgsAu/3DxSn4 HK/830z8YJdRmsVvpAGI+hhADb+AGTF4LAzVkFBtiTep9FNGtjK+Ev0GMvSUZo6r+S9a +hd7CRLjfF8QxuLjuU9NkZ9Evp7kb5WqrGXJKwU49/oPuFHBYYTOjJrVaHKux+AMAVjX zmlQ==
X-Gm-Message-State: AOAM532Jy6lyjXUll7bIN6WQvml+yotq+J0fsbxREXRdu/Mvvrmx4Dmf ItcxalecVtSAemhorZuihL4tOt190hQBY9zJTno=
X-Google-Smtp-Source: ABdhPJzm+HKrQhZPCHFrCEBf+mNayZHXkNbYlyxTgxfQtGqCIkOrbMMB0Y1oOklUgdCJLmQmBjNJBZXANdkww0dAH34=
X-Received: by 2002:a6b:e60e:: with SMTP id g14mr1621571ioh.141.1592430901519; Wed, 17 Jun 2020 14:55:01 -0700 (PDT)
MIME-Version: 1.0
References: <BL0PR0901MB3682A78982CD60BF5D8039A084800@BL0PR0901MB3682.namprd09.prod.outlook.com> <CABNhwV1e9nu336Y-WRB=d=8zo3Gyc4FB_-SeDf50NSRQCHOirQ@mail.gmail.com> <CAEGSd=DfKmpEqZuTHy=FuuWHiCViHC5Wm0HcyqSx4c72R9QNbQ@mail.gmail.com>
In-Reply-To: <CAEGSd=DfKmpEqZuTHy=FuuWHiCViHC5Wm0HcyqSx4c72R9QNbQ@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 17 Jun 2020 17:54:50 -0400
Message-ID: <CABNhwV2-6aRek11bD0zjZ1wmbr+7So-M55wUbfk_m77D6wDxbg@mail.gmail.com>
To: Alexander Azimov <a.e.azimov@gmail.com>
Cc: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, Susan Hares <shares@ndzh.com>, "draft-ietf-idr-bgp-open-policy@ietf.org" <draft-ietf-idr-bgp-open-policy@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000036e98005a84eb69f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-BAkYbYiNwTCrIrYxmpZSeQtNg8>
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: Wed, 17 Jun 2020 21:55:12 -0000

Hi Alexander

Thank you for responding as far as vendor implementation status and
compatibility.

I mentioned this off list to one of the other authors
Sriram.

One aspect of this role feature that is critical to Verizon is if this
feature can be used with SAFI 128.

Verizon as well as most other Tier 1 / 2 providers carry the internet table
in a separate IP VPN VRF over an MPLS  or SR core and keep the global table
clean of just operator IGP connected prefixes carrying topmost label FEC
binding only and not cluttered with the internet BGP table.

So this feature would need to support SAFI 128 for inter-as options or in
SR case SR-TE binding sid policy.

Kind Regards

Gyan

On Tue, Jun 16, 2020 at 4:48 PM Alexander Azimov <a.e.azimov@gmail.com>
wrote:

> Hi Gyan,
>
> As it was discussed in the mailing list the two of three current
> implementations are based on open source software: BIRD and FRR, they are
> compatible. We haven't yet tested intercompatibility with Microtik. There
> were also plans at the openbgpd community, but as far as I know, now
> results yet.
>
> From Yandex, we are planning to add Open Policy as a feature request for
> Juniper. I know that DTAG has already made these requests for its vendors.
> If Verizon will also ask for this feature it may get more momentum.
>
> пт, 12 июн. 2020 г. в 20:28, Gyan Mishra <hayabusagsm@gmail.com>om>:
>
>>
>>
>> On Thu, Jun 11, 2020 at 11:14 AM Sriram, Kotikalapudi (Fed) <
>> kotikalapudi.sriram@nist.gov> wrote:
>>
>>> Hi Gyan,
>>>
>>> >I support this draft and believe the specification is ready for
>>> publication.
>>>
>>> >I think the role capability for auto route leaking mitigation is very
>>> >valuable for both service providers as well as very large enterprises.
>>>
>>> Thank you.
>>>
>>> >This WGLC draft along with below route leak detection of well known
>>> large
>>> >BGP communities can help tremendously in automating route leak
>>> mitigation.
>>>
>>> >
>>> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02
>>>
>>> Appreciate the comment. We plan to request a WGLC in GROW for the above
>>> draft soon.
>>>
>>> >BGP Large Community
>>> >https://tools.ietf.org/html/rfc8092
>>>
>>> >Speaking from the looking glass  of a tier 1 provider Verizon we could
>>> >definitely benefit from the role priority feature from the leak types
>>> >described in RFC 7908.
>>>
>>> I think you meant '...definitely benefit from the role priority
>>> feature [to protect] from the leak types described in RFC 7908'.
>>
>>
>>   Gyan> Yes that is what I meant
>>
>>  So the two implementations that were done and interoperability which
>> were the vendors?
>>
>> Also if the beta code feature is available do you have any operators
>> testing the code?
>>
>>>
>>>
>>> Great to hear that.
>>>
>>> Sriram
>>>
>>> > https://tools.ietf.org/html/rfc7908
>>>
>>> >Kind regards
>>>
>>> >Gyan
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>>
>
> --
> Best regards,
> Alexander Azimov
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD