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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 06 Apr 2020 15:07:13 -0700

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.

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Apr 2020 13:45:24 -0700

cc: redundancy reduced

thanks alvaro for the thorough and helpful review

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

an elf seems to have done that; thanks elf

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

and made text consistent

>  confusing.  Also, it is §5.1.2 the section that actually talks about the use

how about

   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.

>  Given the comment above, the reference to rfc7705 should be

and 5085 too, i guess.  ok

> configuration"?  IOW, why is MUST not used?   s/SHOULD/MUST

ok

> akin to "if the origin AS is X, then the route must always be considered

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.

   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.

>  validation policy for *all* policies??]

i am not sure where to go here

>  policies./...may be determined only after all policies...such

ack.  will the above do?

>    because they were marked Invalid, as long as the router still has them in

i prefer 'list' to 'display' because it could be in response to non-cli.
but, indeed, it is the implementation which should list.  and i realize
that they might not have been sent for a validation policy other than
drop invalid.  so how about

   An implementation SHOULD be able to list announcements that were not
   sent to a peer, e.g., because they were marked Invalid, as long as
   the router still has them in memory.

randy

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 8 Apr 2020 04:25:49 -0700

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

Randy:

Hi!

...
> Autonomous System number which is used by [RFC6811] BGP Prefix Origin

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>

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.

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

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.

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

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.

---

From: Randy Bush <[email-masked]>
Date: Wed, 08 Apr 2020 12:47:38 -0700

-04 pushed

randy