Re: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-rov-no-rr-06: (with COMMENT)

[Randy Bush <[e-mail]>]

rob:

thanks for the review.

> 1.
>    but on the order of
>    the in-degree of ROV implementing BGP speakers.
> 
> Being ignorant, I didn't know what "in-degree" meant before I looked
> it up.  Possibly, clarifying here would be beneficial.

i am torn.  if you insist, i will hack.  but it is a well-known term.

> 2.
>    As storing these paths could cause problems in resource constrained
>    devices, there MUST be a knob allowing operator control of this
>    feature.  Such a knob MUST NOT be per peer, as this could cause
>    inconsistent behavior.
> 
> I would suggest that you use text like "config setting" rather than
> "knob".

      As storing these routes could cause problems in resource
      constrained devices, there MUST be a global operation, CLI, YANG,
      etc. allowing the operator to enable this feature, storing the
      dropped routes.  Such an operator control MUST NOT be per peer, as
      this could cause inconsistent behavior.

> I think that it would be useful to understand whether there is any
> IETF YANG configuration module to control this behaviour, either
> existing, or in the works.

not to my limited knowledge.  if any of this august company knows of
such, please send a cite.

>    Such a knob MUST NOT be per peer, as this could cause
>    inconsistent behavior.
> 
> Would this necessarily give inconsistent behaviour?  Wouldn't it just
> mean that it would always need to resync against some BGP peers, but
> not others?  It feels quite prescriptive for an RFC to be banning more
> granular configuration options.

you seem to be suggesting that the device store dropped routes from some
peers but not others.  so how does it know which peers had invalidated
routes and therefore to which peers it needs to send route refresh when
new rpki data come in?  or does it just hammer on those not configured
to be keep-dropped?

> 4.
>    Operators deploying ROV and/or other RPKI based policies SHOULD
>    ensure that the BGP speaker implementation is not causing
>    unnecessary Route Refresh requests to neighbors.
> 
> Given these are "unnecessary Route Refresh", I was wondering why this
> couldn't be a MUST rather than a SHOULD.

because someone else whacked be the other way :).  in fact, it is
currently a lower case, non-normative (deviant?:) 'should'.  i can go
with either.  guidance solicited.

> 5.
>    If the BGP speaker has insufficient resources to support either of
>    the two proposed options,
> 
> It was not 100% clear to me what the two proposed options are, I'm presuming
> that it is: "BGP Speakers MUST either keep the full Adj-RIB-In or implement the
> specification in Section 4.", but perhaps worth considering if this could be
> made clearer.

      If the BGP speaker's equipment has insufficient resources to
      support either of the two proposed options (keeping a full
      AdjRibIn or at least the dropped routes), it MUST NOT ...

as these are not major, i will wait for feedback on the above and other
issues before pushing a revised version.

randy