Re: [Gen-art] Genart last call review of draft-ietf-idr-bgp-open-policy-18

Gyan Mishra <hayabusagsm@gmail.com> Wed, 05 January 2022 22:27 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383693A11C2; Wed, 5 Jan 2022 14:27:23 -0800 (PST)
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 sczCm4aBfczC; Wed, 5 Jan 2022 14:27:18 -0800 (PST)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 8B4CA3A11BA; Wed, 5 Jan 2022 14:27:18 -0800 (PST)
Received: by mail-pj1-x102a.google.com with SMTP id b1-20020a17090a990100b001b14bd47532so534903pjp.0; Wed, 05 Jan 2022 14:27:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+9B0FcA8wcvCVTF4Vwf8oCIqPok2zfE5jRIfH9wzzoU=; b=DY/L6Uuv5/ZJ7aDbnujjYJQKBa60y4La1WwXGBFP6oxKl6QkwnMtt5UMNihFxrsuCJ SpUAOdgX6Qw8KlILAkzWEGfmftgOQ2VfS/Scnih+ed3lP3AoWet79J6UTsHjN9f5Abet F6MRMQZMHL/ARHJz7g0iq8lkrbnsl5eKvp51gndSwz3Na4BHx1JvKhSu6xhHUGB6iWS9 carBiEI3T1NtDOmL4TUfyEnd6aCNjuY8Zj60jwmGdjeyxje4SN7SPb0efRbpkO6XIzuf pqpfBesqWPrFTULcUzOjqvFPVxRuyuYvO+TzPkA1nY/jT0f9a05nQdWIXejHRjEfjJAk Tytg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+9B0FcA8wcvCVTF4Vwf8oCIqPok2zfE5jRIfH9wzzoU=; b=farqj0+8RlPMXyaVRYLSJqa7lPydveGLVrOjNIoCp6EfIny5UyUMMkdwOJzA73Smqo LAW1E7a/luQkUJYaKYVVIAe3kR4Qhk4mJFzE5TRV+d7L8II7ATW9VPbMA4l4pGT24Cy+ Avx05C70VJk2LITNzhm2iBNalpZG8zK+fZm4Q9N6i83jEmae7hbIIkA5YXnlBDulUTNm OAc2/lQ9oABADCvDcndjcDt/TGnKvFptM/s4e5/vRnxpYUqfDlGd47G3EHY1knmt23+/ vBKGvasNoeOugNJ4I1j2vWWBuATsPj625UNzr7Gds+p2Bld5danr0CZOtlfUIjUY5GjT mF8w==
X-Gm-Message-State: AOAM531pF8ED6ct4LyOYxOAZvABK3TV23egbvumKUVYpnRuQmJj3SVxO pj3CKXkLW5YsAfqkcPxmK092pgV2HRHYTfc8727izVEg
X-Google-Smtp-Source: ABdhPJwAjvSugpCr6U1a63tN6RIepnv1QN8eMtRa6nP26nRcrKwYt3EIrIcXi7Z92bjHFJZR2wwJES0jQ5PrUWr4BEY=
X-Received: by 2002:a17:903:41ce:b0:149:7d85:745b with SMTP id u14-20020a17090341ce00b001497d85745bmr43469860ple.100.1641421637024; Wed, 05 Jan 2022 14:27:17 -0800 (PST)
MIME-Version: 1.0
References: <164013488006.27197.13873644386825552452@ietfa.amsl.com> <CAMMESsx35+gC7CP9ox+U-QsT8Dxkv3=Du8VRq_cprMsEc5PCyQ@mail.gmail.com> <CABNhwV30nrqJ-mOpniso6c=rJpFi0zQX93BWaQKJvKNVcrMNAw@mail.gmail.com> <SA1PR09MB8142D79278F793814694AD40844A9@SA1PR09MB8142.namprd09.prod.outlook.com> <CABNhwV0cGhp1pW24mzJvtOoaGDYM2ypBtTn_--L-0dNRmFhSUA@mail.gmail.com> <SA1PR09MB8142DBB76926B62226E7BB6D844B9@SA1PR09MB8142.namprd09.prod.outlook.com> <CAMMESswPLViBv_hcAWyzhrfYsXGn3uZhWVXEP4AHy=8YQRgCpw@mail.gmail.com>
In-Reply-To: <CAMMESswPLViBv_hcAWyzhrfYsXGn3uZhWVXEP4AHy=8YQRgCpw@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 05 Jan 2022 17:27:05 -0500
Message-ID: <CABNhwV1f7W7oBRmNq8d_7fG5XtjrzMQ1-fZEw=Nj-ypkJeB5uA@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, "draft-ietf-idr-bgp-open-policy.all@ietf.org" <draft-ietf-idr-bgp-open-policy.all@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009a014705d4dd4146"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/gocZZxImsY2RZPEFu055BkdXVOc>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-idr-bgp-open-policy-18
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jan 2022 22:27:23 -0000

Hi Alvaro

Responses In-line

I think the document needs to clearly state that the role priority by
itself does not have an import policy that is automatically configured.
The import policy is based on OTC Attribute.  The document should also
clearly state that Role priority must be used in conjunction with OTC
attribute.  I think this is being implied but needs to be clear that role
priority must be used with OTC attribute for route leak detection and
prevention.  Also in order for the route leak detection and prevention to
work correctly, the role priority cannot have an automatic inbound policy
and must depend on the dynamic signaling nature of OTC path attribute to
signal route leak.

Kind Regards

Gyan

On Wed, Jan 5, 2022 at 4:33 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:

> On January 5, 2022 at 12:12:14 PM, Sriram, Kotikalapudi wrote:
>
>
> Sriram:
>
> Hi!
>
>
> > [KS/AA]: That is interesting. We did already enhance the Role
> descriptions
> > [KS/AA]: as follows to add the import policy verbiage (to the already
> > [KS/AA]: existing export policy) in Sec. 2 of v-19 to be uploaded:
>
> Route leaks are created by the (incorrect) advertisement of routes.
> Defining egress rules is then in line with the subject of this
> document.


   Gyan> Agreed

>
>
> OTOH, ingress rules are not.  Also, the ingress behavior is tied in
> the draft to the OTC attribute (and not directly to the role).
>

   Gyan> Agreed

>
> The result is that the updated text is not consistent with the
> behavior already defined elsewhere.  For example, using the Provider
> role:
>

   Gyan> Good point

>
>
>
> > Old text:
> ...
> > Provider: MAY propagate any available route to a Customer.
> >
> ...
> > New text:
> ...
> > Provider: May propagate any available route to a Customer. May
> > accept routes originated by the Customer or its Customers; all
> > other routes from the Customer must not be accepted.
>
> [Besides loosing the normative language...]
>
> A strict interpretation of the text (routes originated by a Customer
> can be accepted) is in contradiction with this text in §4:
>
>    1.  If a route with the OTC Attribute is received from a Customer or
>        RS-Client, then it is a route leak and MUST be considered
>        ineligible (see Section 1.1).
>

     Gyan> Very Good point.  OTC attribute must be used for the route leak
detection dynamic import policy.

>
> Note that this text doesn't talk about the origin, but it qualifies
> the policy based on the OTC attribute.
>

   Gyan> Agreed

>
>
> All this is to say that the expected ingress behavior, which depends
> on the OTC attribute, is already defined elsewhere and there's no need
> to change the role definition.
>

    Gyan> Completely agree

>
> Thanks!
>
> Alvaro.
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*