[Idr] Re: Publication has been requested for draft-ietf-idr-deprecate-as-set-confed-set-16

[Tony Przygienda <[e-mail]>]

On Mon, Jan 27, 2025 at 4:04 PM Job Snijders <[e-mail]> wrote:

> Dear Tony,
>
> Thank you for your time reviewing this internet-draft.
>
> On Mon, Jan 27, 2025 at 03:32:15PM +0100, Tony Przygienda wrote:
> >     Overall, the document specifies in my eyes basically BGP version 5
> >     if the default behavior is to drop stuff generated by version 4 as
> >     suggested.  The argument I would make for this assertion is that
> >     interoperability is not met by the default behavior standardized
> >     here.
>
> I think I disagree with your characterization of the Internet-Draft at
> hand being "BGP-5", it is not. RFC 7606 also wasn't "BGP-5" and made
> significant (beneficial) changes to how BGP-4 worked. Part of long term
> protocol maintenance is to recognize things like 'whelp, so-and-so
> feature didnt work out as we hoped' and then deprecate such features
> (keeping in mind the best interests of the overall ecosystem). Related:
> RFC 7606 might have been a source of inspiration how exactly to deal
> with 'old world' messages: treat-as-withdraw.
>
> >     Further, it seems to defeat the well served axiom of "be liberal
> >     in what you accept" that has proven a solid architectural
> >     guideline in well written IP normative documents.
>
> This 'well served' axiom is anything but!
>
> Please see RFC 9413 section 2.2, where BGP-4 is mentioned as an example
> of a 'flexible' protocol which does not align to Postel's Law. I've
> argued before that BGP is robust but not "postel-compliant", see:
>
> https://mailarchive.ietf.org/arch/msg/architecture-discuss/TLUkM4oZktJnglu6MsypKm1NUaI/
>
> In other words, I posit the 'solid' (note the quotes) 'guidelines'
> should not be followed when contemplating publication of
> draft-ietf-idr-deprecate-as-set-confed-set. Keep it simple, let's avoid
> piling on even more technical debt.
>

Hey Job, I guess we disagree here then at fairly deep philosophical level
but then again, BGP was always _special_ ;-)


>
> >     Why do I think a capability is needed? Otherwise there may be
> >     "silent" peerings sitting there looking like this specification
> >     has been followed and all of a sudden sending a route triggering
> >     "treat-as-withdraw" to the operational surprise of all parties.
>
> I'd consider introduction of a new BGP OPEN Capability a very unwelcome
> complication which will delay deprecation for no obvious upsides. I'd
> refuse to implement such a capability. Part of the attraction of
> draft-ietf-idr-deprecate-as-set-confed-set is that down the road we get
> to delete code, however adding a new capability would mean adding code
> that's going to have to be around until the heat death of the universe.
>
> If one takes a look at today's default-free zone, AS_SETs are present in
> only ~ 240 routes, e.g. 0.02% of the GRT. Operationally speaking it is
> well within our collective reach to cleanse the global Internet routing
> system of AS_SETs.
>
> Collective action on those 240 routes is a walk in the park compared to
> the global deployment of the practise of rejecting RPKI-ROV-invalid
> routes like occurred back in 2020. Given that publishing this I-D as RFC
> will not lead to immediate code changes, nor immediate deployment, in
> effect there will be an extensive grace period for potentially affected
> operators to re-evaluate their configurations.
>

I read you on the "minimal amount of routes" and I agree here that
such a minimal set is operationally not warratying any complexity.
Possibly this should be spelt out (even clearer) out in the draft.

My job was to review the stuff from the protocol mechanics perspective.

Generally, I'm baffled why this should be "standards track" if the
considerations you bring forward are basically mostly based on
operational realities. Wouldn't a BCP path still be not more adequate here?

-- tony


>
> > It seems to me an attack surface to not prevent advertisement of
> > summaries with ROA if all the underlying more specifics are not ROA
> > (e.g. fail RPKI validations). something along the lines of "SHOULD NOT
> > unless at least one prefix ROA" is in place maybe? Generally, unless
> > _all_ prefixes must strictly pass ROA it seems to me that it may be an
> > idea worth considering to force such peers on advertisement of
> > aggregate with ROA based on mix of prefixes with ROA/without to attach
> > something like ATOMIC_INSECURE for easier tracking of such
> > attacks/operational scenarios even if that does not influence route
> > selection?
>
> A new Capability? ATOMIC_INSECURE? It seems *you* are inventing BGP-5
> here! :-)
>
> I'm all for documents being as readable as possible and making
> publications fit in neatly with the existing body of work, if more
> tidying up is needed yup shure then let's do it. However, there
> absolutely is no need to go back to the drawing board on the core
> concepts and re-invent how to deprecate AS_SETs on a technical level.
>
> I'd like to encourage the authors to not stray too far from the choosen
> path.
>
> Kind regards,
>
> Job
>