Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01

[Ben Maddison <[e-mail]>]

Hi Warren,

On Fri, 2020-03-20 at 12:33 -0400, Warren Kumari wrote:
> On Fri, Mar 20, 2020 at 12:11 PM Randy Bush <[e-mail]> wrote:
> > 
> > > > > BGP implementations have to take removal of private AS(s),
> > > > > confederation, AS migration, etc into consideration.
> > > > 
> > > > and the winds of summer.  we do not need to enumerate all
> > > > knobs, as
> > > > if we could.
> > > > 
> > > 
> > > But enumerating *some* helps the reader understand the context in
> > > which
> > > this is important/useful.
> > 
> > which is why
> > 
> >    When applied to egress policy, the effective origin AS MUST be
> > used
> >    to determine the Origin Validation state.  The effective origin
> > AS is
> >    that which will actually be the origin AS in the
> > announcement.  It
> >    might be affected by removal of private AS(s), confederation, AS
> >    migration, etc.
> > 
> 
> One of the things that I personally like most about this document is
> that it concise - it clarifies something for *implementors* to keep
> in
> mind / points out something where they might trip over something and
> hurt themselves.
> 
I only partially agree. For three reasons:

- My experience over the last 12 months of running invalid==deny in
production is that some implementors have managed to take every
ambiguity in the various rov-related RFCs and translate it into bugs or
fragile/hostile behavior. I think our lesson should be that even
obvious-seeming spec gaps ought to be filled in this area.

- Operators using implementations of this draft will observe
behavioural differences between similar-seeming policy applied at
different attachment points. This document should help them understand
those differences.

- We may very well see some implementations wind up with separate
policy knobs for "enable rpki-rov" and "enable rpki-rov-egress". Again,
operators will need a spec against which to validate that feature
behaviour if it is claiming RFC compliance.

> While I generally like examples and detail in RFCs, in this case it
> would be "teaching your grandmother to suck eggs"[0] - the readers in
> this case are folk who write BGP, the document basically says
> "Warning: sharp object, careful with fingers" - having too much
> detail
> decreases the utility in this case.
> 
> Again, I generally agree that documents should enumerate all of the
> corner cases, have examples, etc - but in this case I think it would
> do more harm than good...
> 
I'm not suggesting turning this into a use-case doc. But enough color
to make the mental link between real-world policy and protocol concepts
is necessary, imho.

Cheers,

Ben

> W
> [0]: https://en.wikipedia.org/wiki/Teaching_grandmother_to_suck_eggs
> > randy
> 
> 
>