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

Alvaro Retana <aretana.ietf@gmail.com> Wed, 05 January 2022 21:33 UTC

Return-Path: <aretana.ietf@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 4B7263A0C02; Wed, 5 Jan 2022 13:33:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 VQMFjd7Ulmgk; Wed, 5 Jan 2022 13:33:09 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 51D503A0BE1; Wed, 5 Jan 2022 13:33:09 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id k15so1585098edk.13; Wed, 05 Jan 2022 13:33:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=gZjtF7kUX0f4RW5I/VVRuGn/fi4wSuufAfN8B+9u/kw=; b=S/SJa6VAa1e+VHzMCobSzXEXuhqxVT39KuJQBR8leH9ZdnjunGoPhMz9Y7aCr+TGpN 7acLFSCbeH34ypNxnD6bFWp+dBEgvA7aWJdApe7gmRHSCPxvD1IkT3pOE7B87TJVL1Du uS0De9hayoHthQf9aUgGDHKfdGMCenRMoGxT0bG4m8NLe4XM19fydxxM9AUizetHFlPf OM5yLGMSBWVCXbG1ghyY5nqxEG0ZF2HJ9CXlkVJFG5VDB6IFePYsNjclQuc+Mb8mPXv0 8qyRkZDk8Q6/0TYtnqRaW5BbvgljqzBObC99qOLGc++GxdScHWymg/au+uYmiIIPwDjn 8Z3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=gZjtF7kUX0f4RW5I/VVRuGn/fi4wSuufAfN8B+9u/kw=; b=y19aW7VDGZ55OmdUSZxj0P7vMDug0YHhoqasgufTHIht34vFkinic6ROUF/DBwgz1W jxXd3vRThQOoqQpBjY/slVRA6UfRqqe1JTU/055e9KDy//CZgXu+YYRfeMz52mXa13Dd zOhD4pT40iawNZ2bH1NXLk4Em0b6Vb1WK13i6oWU3BSRDmK72y/UX+I5GU2CSsFnXr8s yVBH6qqI1+Bzh/+JaUCAiZ9q0nctJezV/P2HNELm0WH1SdQRLhn9jKGeglwlOUZViDVR fSNqfFuxSqaeGPJL0z1kkCcIfJwhq8OfHCA8VrbBNkioWxoFBtBltzw+q9V1sHO/Rn9U qrQQ==
X-Gm-Message-State: AOAM530Vh3jJtVBWo2nyVV3qELutJiqQnPdVaSuTWfRKz1szuh5Si1Fj zXWGsjfo6xEMhatF5dYfXVcQ2aqj+xdQbwV56FzcSEGW
X-Google-Smtp-Source: ABdhPJyl0qRXc95kvO6n54g8MyWZz7qSyCVGPfImXHjMEoyiqaffIar4hO3hKSMsPFyEY7jGuM2MgEle+2MS+QwLYHI=
X-Received: by 2002:a17:907:7e95:: with SMTP id qb21mr46607635ejc.105.1641418387067; Wed, 05 Jan 2022 13:33:07 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 5 Jan 2022 13:33:06 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <SA1PR09MB8142DBB76926B62226E7BB6D844B9@SA1PR09MB8142.namprd09.prod.outlook.com>
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>
MIME-Version: 1.0
Date: Wed, 05 Jan 2022 13:33:06 -0800
Message-ID: <CAMMESswPLViBv_hcAWyzhrfYsXGn3uZhWVXEP4AHy=8YQRgCpw@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
Cc: "draft-ietf-idr-bgp-open-policy.all@ietf.org" <draft-ietf-idr-bgp-open-policy.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/UKHWeklSS8CUe48eBE_NUFSaAo4>
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 21:33:13 -0000

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.

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

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


> 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).

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


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.

Thanks!

Alvaro.