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

Alvaro Retana via Datatracker <noreply@ietf.org> Mon, 06 April 2020 22:07 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 908223A0D29; Mon, 6 Apr 2020 15:07:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-sidrops-ov-egress@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-chairs@ietf.org, keyur@arrcus.com, warren@kumari.net, nathalie@ripe.net, keyur@arrcus.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.124.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <158621083315.16634.8714357093097492160@ietfa.amsl.com>
Date: Mon, 06 Apr 2020 15:07:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/p_rI3m3qXKLUKad_d9gKZ8QyA18>
Subject: [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
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: Mon, 06 Apr 2020 22:07:14 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-sidrops-ov-egress-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(0) This document should be marked as replacing draft-ymbk-sidrops-ov-egress.

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

(2) §1:

   As the 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 against the origin
   Autonomous System number which will actually be put in the AS_PATH
   (see [RFC4271] 4.3 Path Attributes:b) of the UPDATE to the peer.

(2a) [major] "MUST apply Route Origin Validation policy semantics against the
origin Autonomous System number which will actually be put in the AS_PATH"  Put
where?

 The assumption in this text seems to be that there will only be one AS number
 present (even with prepending), in line with §5.1.2/rfc4271.  However, rfc7705
 (which Updates rfc4271) specifies AS migration mechanisms...some of which may
 result in more than one AS number placed in the AS_PATH (even at route
 origination).  It is then important to clarify *where* the ASN "will actually
 be put", or which ASN should the validation be done against.  [Note that this
 is a variation of the initial comment about clearly defining the terms.]

(2b) [nit] s/(see [RFC4271] 4.3 Path Attributes:b)/([RFC4271])

 Not only is the detailed reference unnecessary, but the format may be
 confusing.  Also, it is §5.1.2 the section that actually talks about the use
 of the AS_PATH.

(3) §1: It would be very nice to add these references: s/confederation, AS
migration/confederation [rfc5065], AS migration [rfc7705]

 Given the comment above, the reference to rfc7705 should be Normative.

(4) §3: "BGP implementations supporting RPKI-based origin validation SHOULD
provide the same policy configuration primitives for decisions based on
validation state available for use in ingress, redistribution, and egress
policies."

When would it be ok for an implementation not to "provide the same policy
configuration"?  IOW, why is MUST not used?   s/SHOULD/MUST

(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 not
for 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"??

 [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??]

(5b) I know that this next point was discussed on the list...but describing the
outcome of complex policy as not "easily predicted" and non-deterministic is
causing me a lot of heartburn.  I can see how optional information in an Update
(communities, etc.) can cause a policy result to be known only at "run time",
but that doesn't make the outcome unpredictable or non-deterministic: the
outcome of the policy is what it is supposed to be, given the current
conditions -- we just didn't know before the Update was received.  This is a
non-blocking comment and you can consider it a nit...it simply sounds as if the
operator was guessing, and I know some are not. ;-)

 s/...may not be easily predicted before all policies...such non-deterministic
 policies./...may be determined only after all policies...such policies.

(6) §4: "SHOULD be able to list what announcements are not sent to a peer
because they were marked Invalid, as long as the router still has them in
memory."   After reading this text many times, I think I understand that you
mean that the operator should be able to use a "show command"...and not that
he/she should be able to create a list of announcements (as in a filter).  Is
that what you mean?

Suggestion (maybe something like this)>
   An implementation SHOULD display announcements that are not sent to a peer
   because they were marked Invalid, as long as the router still has them in
   memory.