Re: [Sidrops] version negotiation

[Job Snijders <[e-mail]>]

Randy,

Related to RTR being “trinary”, and it being desirable for the protocol
negotiation to be generalized - would it make sense to add a text that in
order to facilitate protocol upgrades, the cache should start a new
session, or perhaps introduce a new non-fatal Error Code “Upgrade
Available”? Or some other signal?

Some router implementations doing ISSU (potentially making for extremely
long-lived RTR sessions), I imagine it’s valuable if there is explicit
guidance on how protocol upgrades work.

It would be suboptimal if both cache and router support newer versions of
RTR, but because of a past negotiation, neither uses the newer version.

Kind regards,

Job

On Wed, 10 Jan 2024 at 22:11, Randy Bush <[e-mail]> wrote:

> >>    If the router query has version Q> N, the cache MUST send an Error
> >>    Report (Section 5.11) with Protocol Version N and Error Code 4
> >>    ("Unsupported Protocol Version"), and the router SHOULD send another
> >>    query with a Protocol Version Q of the version N in the Error Report,
> >>    unless it has already failed at that version.  This MAY repeat with
> >>    the router attempting to negotiate lower and lower versions until
> >>    they agree.
> >
> > Coming back to session downgrades (router query Q> N). RFC8210 has this:
> >
> >    2.  The cache may reply with a version 0 response.  In this case, the
> >        router MUST either downgrade to version 0 or terminate the
> >        connection.
>
> the 8210 text is
>
>    If a router which supports version 1 sends a query to a cache which
>    only supports version 0, one of two things will happen:
>
>    1.  The cache may terminate the connection, perhaps with a version 0
>        Error Report PDU.  In this case, the router MAY retry the
>        connection using protocol version 0.
>
>    2.  The cache may reply with a version 0 response.  In this case, the
>        router MUST either downgrade to version 0 or terminate the
>        connection.
>
> > This is in direct conflict with the above. It is also in
> > draft-ietf-sidrops-8210bis-11. Also the rtr caches I checked use this
> > implicit downgrade for sessions. So I don't think this method can be
> > removed.
>
> agree that this is problematic in a number of ways.
>
> i think we would want /terminate the connection/terminate the session/
>
> but further, 8210 is a one or zero negotiation.  and we're now trinary,
> and next year we'll be quaternary :(  so hard coding the 1 to 0 downgrade
> seems ill advised and should be generalized.
>
> so 'implicit' downgrade to zero or terminate should probably be phrased
> as a N-ary process, which the proposed text attempts to do.
>
> for ref, our current working text is as follows:
>
>    If a cache which supports version C receives a query with Protocol
>    Version Q < C, and the cache does not support versions <= Q, the
>    cache MUST send an Error Report (Section 5.11) with Protocol Version
>    C and Error Code 4 ("Unsupported Protocol Version") and disconnect
>    the transport, as negotiation is hopeless.
>
>    If a cache which supports version C receives a query with Protocol
>    Version Q < C, and the ache can support version Q, the cache MUST
>    downgrade to protocol version Q, [RFC6810] or [RFC8210], and respond
>    with a Cache Response (Section 5.5) of that Protocol Version, Q, and
>    the RPKI-Rtr session is considered open.
>
>    If the the cache which supports C as its highest verion receives a
>    query of version Q > C, the cache MUST send an Error Report with
>    Protocol Version C and Error Code 4.  The router SHOULD send another
>    query with a Protocol Version Q with Q == the version C in the Error
>    Report; unless it has already failed at that version, which indicates
>    a fatal error in programming of the cache which SHOULD result in
>    transport termination.
>
>    If the router requests Q == 0 and it still fails with the cache
>    responding with an Error Report with Error Code 4, then the router
>    MUST abort the transport connection, as negotiation is hopeless.
>
> we think this should interop with v0 and v1 devices.  but we would
> definitely appreciate specific text where it could be improved.
>
> randy
>
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops
>