Re: [Sidrops] Alvaro Retana's Discuss on draft-ietf-sidrops-rov-no-rr-03: (with DISCUSS and COMMENT)

[Randy Bush <[e-mail]>]

hi alvaro:

>>> Was there any consideration given to making a general recommendation
>>> and not just limiting it to ROV? I can see the direct impact on
>>> rfc6811/rfc8481, and how general BGP advice is out of scope for
>>> sidrops. However, I am primarily curious whether there is anything
>>> particular to ROV to focus the recommendation this way.
>>
>> we are not aware of automated provisioning tools which have a policy
>> update frequency on the order of ROV, which can now be seen on the order
>> of ten minutes.
>>
>> this document was a response to real operational events, not theory.
>>
>> the authors are not aware of other provisioning tools which have fluxed
>> policy to the point of other proviers de-peering due to the route
>> refresh load.
>>
>> but, a comment that other high flux rate policy changes might also cause
>> similar problems would not hurt. how about
>>
>> Other mechanisms, such as automented policy provisioning, which
>> have flux rates similar to ROV (i.e. on the order of minutes),
>> could very well cause similar problems.
> 
> As I said, I just wanted to discuss this point.
> 
> The text is ok -- I just hate to hide this type of information in a
> ROV-specific document.  Too late for this document, but it would have
> been better for the recommendation to be general and to use ROV as an
> example/motivation.
> 
> ** Consider this point closed. **

ack

>>> (2) I have a couple of issues with this paragraph from §4. Addressing
>>> them should be relatively easy:
> ...
>>> (b) "MUST be saved (either separately or marked)"
>>>
>>> For a required action, the description is not clear. For starters,
>>> "marked" how? Separately where?
>>>
>>> From §1.1/rfc4271:
>>>
>>> The Adj-RIBs-In contains unprocessed routing information that has
>>> been advertised to the local BGP speaker by its peers.
>>>
>>> The RIB structures in rfc4271 are conceptual -- but since this
>>> document requires keeping information (presumably in the
>>> Adj-RIB-In), please be more specific about where and marked how.
>>
>> as you just pointed out, for many implementations, adjribin is purely
>> conceptual. so what those implentations do is hidden black magic. so
>> how do we describe augmenting black magic? do you have a suggestion?
> 
> rfc4271 spends a lot of time describing the conceptual operation of
> the RIB and those implementations do just fine. ;-)
> 
> The text is confusing because it implies that there is a "separate"
> place to keep the information, even if the section is titled "Keeping
> Partial Adj-RIB-In Data".

i am not sure we can be much clearer than "MUST be saved (either
separately or marked)" without specifying specific mechanisms.

or are you actually suggesting augmenting the Path Attributes in 4271
§5.1 with a new attribute ROV Dropped and then hacking the FSM to deal
with it?  that will engender a five year discussion in idr.  probably
more, as it took eight years to change the message length from 4096 to
64k.

> Also, it seems to separate the storage (separately) from an indication
> that the route is somehow recognized as one that was dropped
> (marked).  There's no explanation for either.

separate store was just a way of marking.

> Combining the two points, here's my suggestion:
> 
>    A route that is dropped by operator policy due to ROV MUST be
>    considered ineligible and MUST be kept in the Adj-RIB-In for
>    potential future evaluation.

ok.  whew!

>>> (3) The following requirement from §5 is outside the scope of this document:
> ...
>> If the BGP speaker has insufficient resources to support either of
>> the two proposed options, it MUST NOT be used for Route Origin
>> Validation. The equiptment should either be replaced with capable
>> equipement or ROV not used. I.e. the knob in Section 4 should only
>> be used in very well known and controlled circumstances.
> 
> The problem that I have is that the normative language applies to the
> box: "the BGP speaker...MUST NOT be used" -- how about if we turn it
> around:
> 
>    The mechanisms specified in this document MUST be used in
>    well-known and controlled circumstances.  If the equipment
>    has insufficient resources to support either of the two
>    proposed options, it should either be replaced with capable
>    equipment or ROV not used.
> 
> ** At this point we're probably splitting hairs, so we can consider
> this item closed too. **

   If the BGP speaker's equipment has insufficient resources to support
   either of the two proposed options, it MUST NOT be used for Route
   Origin Validation.  The equiptment should either be replaced with
   capable equipement or ROV not used.  I.e. the knob in Section 4
   should only be used in very well known and controlled circumstances.

published as -05

randy