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

[Randy Bush <[e-mail]>]

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

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

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.


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

and 5085 too, i guess.  ok

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

ok

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

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.

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

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

ack.  will the above do?

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

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