Re: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Wed, 08 April 2020 11:25 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254713A1357; Wed, 8 Apr 2020 04:25:59 -0700 (PDT)
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 qV3i_jMnM47K; Wed, 8 Apr 2020 04:25:57 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 7B0653A1356; Wed, 8 Apr 2020 04:25:52 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id y24so967710wma.4; Wed, 08 Apr 2020 04:25:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=u/upePLVufZWGba7yokIyDddJnC4hb35orNv8w7h30g=; b=HYZkCrOep/5Z89MnzRbjTLsLicCket6kv4YIfto0gZKkuhZlLqoEhBvG1VTu2X/FEE 2aU8fIsJLEEWjtMjTQ868lhx07TV+0pbgwtriWOIkS1RH6yGEE0wbA2uccP6siDn5aN9 tE/iADHL0iPMKA7h/eRy4yUz1MpeFgG/L+xNcZMbZUvzoFb5QzNu02x45MESo+8cm0Df dZ+HSrlAhLVPGBB/8IHbUST/gPkrb7PuA1VwtDsPRIECNcRnQwrzbLL0v50XeAEqQKNv hmIpj/nY4BFWUnuQzkZwCTSZifUIVMQX+xaROr+xIY1nVgbg9XJIgD6ZjoOTWJNjh8Wu DwjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=u/upePLVufZWGba7yokIyDddJnC4hb35orNv8w7h30g=; b=KhGEJ99MBQOR8W9teW7+JPnjHQsx6IfH5AmlMjzGxUMk3IYVqeAvogDOKgmGBS8PXN fUtTnxonGKfnHu0r73tiieqgBpJU44Isvoffme0CXzBtKGexBJDW8bvr6KYHYitmkTaA c+GJQA5lrbuweKeLJ62mDevqENbGdxOoKzWnTc1bkI1zRv9lasQFT+y+jyRtP/BiY8c0 fUevS7bqfLeVDpcekTKSapGcM4mIdSWOyX14gunpp1oD8kBsqvT7omzsZggSd31nRyF4 WyD6JYzSFY0z+9BMWAI+c0IdkyR2iCa/ruC84UHEYf7h8nOvipOQQjW30/b2KMYniB5b L0fQ==
X-Gm-Message-State: AGi0PuZaXDgdU5QiLqsmVwP9sa0iCpS5Du/y6XCvDD5jkpvJS/vsrIfi bW/uf7tdPFyVqYswPmN9DR8+JCxYNU2+As7WYwUHsWrR
X-Google-Smtp-Source: APiQypJ2OnX+hRdf3B1naFk26cZdbGg4u+zizRNUG5k2YwDGnhopH7YiDHZUgZMHAxPSD7Wk41BYnRzG7LlpaFsZ5TY=
X-Received: by 2002:a1c:5ac4:: with SMTP id o187mr4373854wmb.79.1586345150696; Wed, 08 Apr 2020 04:25:50 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 8 Apr 2020 04:25:49 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <m2zhbn81p7.wl-randy@psg.com>
References: <158621083315.16634.8714357093097492160@ietfa.amsl.com> <m2zhbn81p7.wl-randy@psg.com>
MIME-Version: 1.0
Date: Wed, 08 Apr 2020 04:25:49 -0700
Message-ID: <CAMMESszDJJ8eGEFXuX+0s5h7Tm48EQQLvWibxSck_dUXMdbr=A@mail.gmail.com>
To: Randy Bush <randy@psg.com>
Cc: draft-ietf-sidrops-ov-egress@ietf.org, sidrops@ietf.org, The IESG <iesg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/_ddUj_w6GhAWUAD55IYqBYRWb1M>
Subject: Re: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-ov-egress-02: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Apr 2020 11:25:59 -0000

On April 7, 2020 at 4:45:40 PM, Randy Bush wrote:


Randy:

Hi!


...
> > (1) The purpose of this document is to clarify "that implementations
> > must use the effective origin AS". The use of "effective" seems
> > deliberate to qualify a specific characteristic of the origin AS.
> > However, the term is not only not defined anywhere (with respect to
> > simply using "origin AS", for example), but there is inconsistency in
> > the language, for example: "origin Autonomous System number which will
> > actually be put in the AS_PATH" or "final announced origin AS".
> > Please be clear in the definition, and consistent in the language
> > used.
>
> added
>
> The term 'effective origin AS' as used in this document refers to the
> Autonomous System number which is used by [RFC6811] BGP Prefix Origin
> Validation.

Honestly, that sounds like a circular reference to me because we
already know that the intent of this document is to clarify "that
implementations must use the effective origin AS" -- so it is obvious
that it will be the one used for origin validation.  Maybe a better
question should have been, how is it determined by a validating
router?

I looked at rfc6811 and it started by talking about "the AS number
claiming to originate an address prefix (as derived from the AS_PATH
attribute of the BGP route)"...not too useful.  But then I ran into
the definition of the "Route Origin ASN".

Suggestion>
   The term 'effective origin AS' as used in this document refers to the Route
   Origin ASN ([RFC6811]) of the UPDATE to be sent to neighboring BGP speakers.


Another alternative is to simply s/effective origin AS/Route Origin ASN


> and made text consistent

There's some repetition here (looking at -03):

OLD>
   As the effective origin AS of a BGP UPDATE is decided by
   configuration and outbound policy of the BGP speaker, a validating
   BGP speaker MUST apply Route Origin Validation policy semantics (see
   [RFC6811] Sec 2 and [RFC8481] Sec 4) against the origin Autonomous
   System number which will actually be used by subsequent [RFC6811] BGP
   Prefix Origin Validation.

NEW>
   The effective origin AS of a BGP UPDATE is decided by configuration and
   outbound policy of the BGP speaker.  A validating BGP speaker MUST apply
   Route Origin Validation policy semantics (see [RFC6811] Sec 2 and [RFC8481]
   Sec 4) after applying any egress configuration and policy.

[This text would also address comment #2.]

[nit] I think that the references to explicit sections is not
needed...but I can live with them.


...
> > (5) §4:
> >
> > Configurations may have complex policy where the final announced
> > origin AS may not be easily predicted before all policies have been
> > run. Therefore it SHOULD be possible to specify an origin validation
> > policy which MUST BE run after such non-deterministic policies.
> >
> > (5a) [major] "SHOULD be possible to specify an origin validation policy"
> > What is an "origin validation policy"? To me it sounds as the ability to
> > either validate or not: as in, "the policy is to validate for this origin
> > AS, but notvfor a different one". Is that it? Or are you referring to a
> > blanket policy akin to "if the origin AS is X, then the route must always
> > be considered Valid"??
>
> actually, i my broken memory is that 6811 says config may have policy
> which selectively validates based on origin, prefix, peer, etc.
>
> An implementation MAY provide configuration options to control which
> routes the lookup is applied to.
>
> yes, rfced allowed an adj at the end of a sentence :)
>
> i forget which docco says that may be by peer, prefix, origin, etc.

I see, that makes sense.

I didn't see it specifically in rfc6811 (or rfc7115), but I think the
text above (from rfc6811) is clear enough.  The only issue is that it
says that the support is optional (MAY), while this document
recommends it (SHOULD).
Because we're already Updating rfc6811, then I think this is ok.


> Configurations may have complex policy where the final announced
> effective origin AS may not be easily predicted before the outbound
> policies have been run. Therefore it SHOULD be possible to specify
> origin validation policy which will run after all non-validating
> outbound policies.
>
> > [This piece of text confuses me more given the suggestion to Alissa's
> > comments: "Therefore it SHOULD be possible to specify an origin validation
> > policy which will run after all such non-deterministic policies." A
> > validation policy for *all* policies??]
>
> i am not sure where to go here

Maybe we have too many "policies"...

And don't see the explicit connection between a complex policy and the
need to apply an origin validation policy...much less the need to
apply it to all.

OLD>
   Configurations may have complex policy where the final announced
   effective origin AS may not be easily predicted before the outbound
   policies have been run.  Therefore it SHOULD be possible to specify
   origin validation policy which will run after all non-validating
   outbound policies.

NEW>
   Configurations may have complex policy where the effective origin AS may
   not be easily determined before the outbound policies have been run.  It
   SHOULD be possible to specify a selective origin validation policy to be
   applied after any existing non-validating outbound policies.


I still went with "determined" (instead of "predicted") because we're
not guessing...but can live with either one.


Thanks!

Alvaro.