draft-ietf-rtgwg-policy-model default reject-route

Kris Lambrechts <kris@netedge.plus> Fri, 17 September 2021 14:36 UTC

Return-Path: <kris@netedge.plus>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DD03A1BCA for <rtgwg@ietfa.amsl.com>; Fri, 17 Sep 2021 07:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netedge-plus.20210112.gappssmtp.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 UI7LjwsNu0Pm for <rtgwg@ietfa.amsl.com>; Fri, 17 Sep 2021 07:36:47 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 146623A1BC8 for <rtgwg@ietf.org>; Fri, 17 Sep 2021 07:36:46 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id v5so30429103edc.2 for <rtgwg@ietf.org>; Fri, 17 Sep 2021 07:36:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netedge-plus.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=o5F8QhZawk5akuQ9/hagHFqJEF3wWxtdO8mqa02/90M=; b=kk8J2M3mlkJUuFPd/LxwofJ9zIJ0yymMYK52AQsxTPsHPrzhu9Rm2W/TwrMegvFiP5 fnodU1ADuPW88BnuwNBUwCU1Fu172dzfseajOASpqIl7wYUDTVvg+4XG7qCmBL+YDpXz YNZFOwmOPBzkbLvJYxRprCT4xbMzPDNh4huw0dDfX9fDSbVRkEA/F3MeL5HFMbYA7GCI rwHaBTEQuUKE0PffxZ32gmXchscPnJ8S2vggfpTN0CDs3XVOfSiA81mDoGlsKvSbgdKr LdKeO62Bhly9qc1IKfVannU4yRNdmmoHt9z1jG9FZ8kBy3kuO/WdUFYIpxNE10SdXjzy 7Byw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=o5F8QhZawk5akuQ9/hagHFqJEF3wWxtdO8mqa02/90M=; b=w6JxlfjNDqbgzf9/+iGI/3uPhUmlhtt3vE5/RdgWQz2YtrB2mphI42cFf816oppAqZ J0ooGmX/ZIalRsE5pt4KuCVtHPi8iyxFFdp3HNpG2nYfAlI6Bi9XmLX+G6CAvi3nTRAT T8wKvcLwDYCozJ9nGLpAGqpvEwpug8Fv18y4JMv43uCvzDXIdYBCFj6Y8gbvaqu4IBY8 8WVcXbv/VbbELwMPfiGuYb33G0YO1zsdw1bhMWYgYfqsA6EmtaxpztvuRrCmF2f68Wy0 enTGf3AcbXGGL5AXU/5BmI8Qr3XowFjT+65xllgWXZEgs/rUX3Xp+QYHNH/RPJlRy3Cw rPgQ==
X-Gm-Message-State: AOAM531IOCuYS5YL1nPNvKHGWpQ4XQUL166ipTrOegwOwJ/RwURbpHeI IGLB3rjyLStWwb8VvnL2G2FClgizpDUnobddjw2BPkzdQZ+zNA==
X-Google-Smtp-Source: ABdhPJybZyTdmWF3eGp3ufXQs0/yDXCJ8aJV6X3HAj9OhaSHHXvLvKnjyy7WLhNJA2Mmylf79lyaRpEHSMXoTOLrefk=
X-Received: by 2002:aa7:c988:: with SMTP id c8mr12862182edt.105.1631889404912; Fri, 17 Sep 2021 07:36:44 -0700 (PDT)
MIME-Version: 1.0
From: Kris Lambrechts <kris@netedge.plus>
Date: Fri, 17 Sep 2021 16:36:33 +0200
Message-ID: <CAAEiB=0Y5tB+xDRnhi4=c9vrxWcj0HErEfE56r2KFi9NgEatRQ@mail.gmail.com>
Subject: draft-ietf-rtgwg-policy-model default reject-route
To: draft-ietf-rtgwg-policy-model@ietf.org
Cc: rtgwg@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/l4XZDD4EahQbrCU87p6ISyEEsQc>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Sep 2021 14:55:32 -0000

Hi,

I have been working on an implementation of
ietf-routing-policy@2021-08-12.yang and
ietf-bgp-policy@2021-07-11.yang and I'm struggling to implement a
pattern that I think is very common among routing policies.

The problem I'm seeing is with the policy-result leaf under actions.
It is of type policy-result-type meaning that it can be either
accept-route or reject-route with a default of reject-route. As per
section 5.  Policy evaluation, all processing ends when either of
these is encountered. That would mean only one statement in a policy
can ever be processed. The first paragraph of section 5 suggests the
presence of those actions is optional however:
> If the actions include either accept-route or reject-route actions, evaluation of the current policy definition stops, and no further policy statement is evaluated.

In any vendor implementation I'm familiar with it is possible, and
common in practice, to combine actions (i.e. set a BGP community or
local-preference) from various statements which are processed in order
by either implicitly or explicitly continuing on to the next
statement.

So my proposal here is to remove the default statement from the
policy-result, which would signify an implicit continuation to the
next statement. Or with the same net effect, you could add a
next-statement enum to the policy-result-types to make the choice
explicit.

I feel like either change would make it much easier to write elegant,
compact and easy-to-understand policies (and to port existing
policies). Still, if this goes against your intended design, it would
be good to fix any wording in the draft that implies that these
actions are optional.

Thank you,

Kris Lambrechts