Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17 -> Updated Version -18 and Flowspec v6

[Alvaro Retana <[e-mail]>]

On January 17, 2020 at 3:55:14 AM, Christoph Loibl wrote:

Christoph:

Hi!

> > On 12.12.2019, at 20:38, Alvaro Retana wrote:
...
> > There is only one significant item remaining that we should resolve
> > before moving the document forward: the handling of unknown
> > components; take a look at the comments in §11 (of -18).
> >
> > Thanks!
>
> This issue has been discussed before Christmas on the mailinglist. The main
> points in that discussion were that we do not want to propagate any garbage,
> while allowing a certain degree of extensibility of the NLRI (given the zoo
> of FS drafts and expected AFI/SAFI pollution out there this seems to be
> reasonable - extension Authors may still choose how they extend the NLRI this
> is not specified in this draft) and keep backwards compatibility.
>
> In this context Alvaro pointed out that the behaviour explained in the draft
> fits closely RFC7606 Section 5.4 (Typed NLRI) and Jeffrey explained that
> walking NLRIs may lead to synchronisation issues between a buggy FS sender
> and a receiver.
>
> The document that we now uploaded clearly references RFC7606 Typed NLRI as
> the mechanism to treat unknown FS components and to allow the receiver to
> skip over (and discard) a single NLRI if it hits an unknown component type
> (previously the very same behaviour was explained in the draft without
> referencing RFC7606). We also added a paragraph to the security
> considerations section to explain that RFC7606 Section 5.4 allows to skip
> (and discard) *unknown* octets and carefully crafted/misbehaving BGP speakers
> may exploit that fact.

<personal opinion>

I think I was advocating for discarding the whole UPDATE, not a single
NLRI.  But, re-reading what I wrote, maybe I was not clear.

I don't think Jeff liked the Typed NLRI approach.

I am ok with the current text -- I think I understand the risks that
Jeff is pointing out.

</personal opinion>


<AD hat back on>

However, I cannot call consensus on my own suggestion, specially based
on having only 3 people speaking up, with 2-3 different approaches.

WG Chairs (John): Please start a separate thread (not everyone reads
"AD reviews") to poll the WG on this item.  This shouldn't be a long
discussion (1 week should be enough), but if should also be long
enough to get some thoughts/discussion.

Note that the result also affects the treatment of out of order or
duplicate components.


Once the Chairs call consensus we'll be ready to go.  I put a couple
of no-action-needed comments below just to close loops.

Thanks!!

Alvaro.


...
> > > > 742 6. Validation Procedure
...
> > I'm still not happy with the contradiction: MUST means "an absolute
> > requirement" (no exceptions!), but then we say MAY, which makes the
> > MUST optional...even with the "by default"... Please s/MUST/SHOULD
> > The MAY will then explain the "valid reason" to not...
> >
>
> <-- AUTHORS
> Tracked via issue #135: https://github.com/stoffi92/rfc5575bis/issues/135
>
> The point to stress out is that the "default" behaviour MUST be "validate"
> according to the spec. Not the default can be changed but the "validation"
> MAY be relaxed by configuration.
> -->

Needless to say, I'm still not happy as there was no change.  But I'm
ok with letting go -- and dealing with comments later in the process,
if any. :-)




...
> > > > The reason/history doesn't matter anymore, but the current use does. The
> > > > mechanism described in this document is clearly not experimental. Given
> > > > that changing the Type values is not an option because of the deployed
> > > > base, etc.., then I think we should clean up the Registry and move
> > > > 0x80-0x82 from the Experimental Use range to the FCFS range. This
> > > > change would mean an Update to rfc7153.
>
> [..]
>
> > > <-- *** Authors ***
> > > Tracked via issue #99: https://github.com/stoffi92/rfc5575bis/issues/99
> > >
> > > This is not to be solved within this document. I note that I should
> > > propose a update to RFC7153 to cleanup the registry independently. - As
> > > noticed moving the values around is not an option.
> > > -->
> >
> > So, are you working on this already? ;-)
> >
>
> <-- AUTHORS
> Tracked via issue #138: https://github.com/stoffi92/rfc5575bis/issues/138
>
> Seriously. IF the only thing that is needed here is a IANA considerations
> draft I will look into this later. If this can be done easier. I think after
> the 5575bis changes have been made in the registry. There is a good chance to
> have this cleaned up.
>
> -->

Independent of this document...  Yes, all we need is an IANA
considerations draft.  If you will look into it, that would be great.
If not, then let me know and I'll take care of it. ;-)