Rob:
Hi!
Did you have comments on this? I'm assuming that we're expecting an
updated document at some point, but if we need to discuss more...
Thanks!
Alvaro.
On 5/25/16, 12:09 AM, "Alvaro Retana (aretana)" <aret...@cisco.com> wrote:
>On 4/26/16, 6:58 PM, "Rob Austein" <s...@hactrn.net> wrote:
>
>Rob:
>
>Hi!
>
>>At Sat, 23 Apr 2016 00:09:07 +0000, Alvaro Retana (aretana) wrote:
>>>
>>> * Section 1.2. (Changes from RFC 6810): "The protocol
>>> described in this document is largely compatible with
>>> [RFC6810]." What does "largely compatible" mean? It
>>> either is compatible or it isn't.
>>
>>It means that most of the code one needs to deal with version one is
>>the same as the code one needs to deal with version zero. Feel free
>>to suggest better text.
>
>When I think about protocol compatibility I think about on-the-wire
>behavior and packets, not about the implementation internals.
>
>NEW>
> The protocol described in this document should allow
> an implementation to largely reuse the code developed
> for version zero.
>
>However, I would prefer if the sentence was taken out completely.
>
>
>...
>>
>>> * This document is marked as obsoleting rfc6810, but it
>>> mandates its use in section 7 ("...the cache MUST downgrade
>>> to protocol version 0 [RFC6810]..."). There are a couple
>>> of paths forward:
>>>
>>> * It seems to me that this document should simply be
>>> called "RPKI to Router Protocol version 1" and not
>>> change the status of rfc6810 - we can always declare
>>> version 0 historic later.
>>>
>>> * If you really want to obsolete version 0, then an
>>> alternative is to eliminate the normative language when
>>> it refers to it... For example,
>>>
>>> * OLD> "If a cache which supports version 1 receives a
>>> query from a router which specifies version 0, the
>>> cache MUST downgrade to protocol version 0 [RFC6810]
>>> or send a version 1 Error Report PDU with Error Code
>>> 4 ("Unsupported Protocol Version") and terminate the
>>> connection."
>>>
>>> * NEW> "If a cache which supports version 1 receives a
>>> query from a router which specifies version 0, the
>>> cache SHOULD send a version 1 Error Report PDU with
>>> Error Code 4 ("Unsupported Protocol Version") and
>>> terminate the connection."
>>
>>The intent is to deprecate version zero, because it lacks features we
>>think are important. But version zero is already in the field and we
>>have no control over how long it will take to upgrade all existing
>>copies. So we have to specify how versions zero and one are intended
>>to interoperate. I don't know how to specify that without normative
>>references to the older version.
>
>If you want to deprecate version zero, then Obsoleting rfc6810 is ok.
>What is not ok is mandating its use at the same time.
>
>I'm thinking that we could get away with removing Section 7 completely,
>and leaving the downgrade behavior as a "local implementation detail" --
>see below: I'm including comments on Section 7, and an optional new
>subsection.
>
>
>Notes_On_7 (my comments with [A]>
>7. Protocol Version Negotiation
>
> A router MUST start each transport connection by issuing either a
> Reset Query or a Serial Query. This query will tell the cache which
> version of this protocol the router implements.
>
>[A] This text (above) is in conflict with Section 8.1. (Start or Restart)
>which reads: "When a transport connection is first established, the router
>MAY send a Reset Query...Alternatively...it MAY start with a Serial
>Query..." To match the behavior in Section 7, here's a suggestion for
>alternate text (for 8.1).
>
>OLD>
> When a transport connection is first established, the router MAY send
> a Reset Query and the cache responds with a data sequence of all data
> it contains.
>
> Alternatively, if the router has significant unexpired data from a
> broken session with the same cache, it MAY start with a Serial Query
> containing the Session ID from the previous session to ensure the
> Serial Numbers are commensurate.
>
>NEW>
> When a transport connection is first established, the router MUST send
> a Reset Query and the cache responds with a data sequence of all data
> it contains, or a Serial Query. The Serial Query can be used if the
> router has significant unexpired data from a broken session with the
> same cache; in this case the Serial Query containing the Session ID
> from the previous session to ensure the Serial Numbers are
>commensurate.
>
>
>[A] BTW, a couple of paragraphs later the text goes back to saying that
>"The router MUST send either a Reset Query or a Serial Query..." I think
>this text would now be redundant and can be deleted.
>
>
>
>
> If a cache which supports version 1 receives a query from a router
> which specifies version 0, the cache MUST downgrade to protocol
> version 0 [RFC6810] or send a version 1 Error Report PDU with Error
> Code 4 ("Unsupported Protocol Version") and terminate the connection.
>
>[A] The behavior of sending the Error PDU is expected if the cache doesn't
>support anything else. In the case of the cache supporting both, it can
>just directly downgrade (as a local decision) -- see some suggested text
>below.
>
>
> 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.
>
>[A] In this case again, the behavior of the router can be a local
>decision: if a version 0 response (including an Error PDU) is received,
>then downgrade -- again, see suggested text below.
>
>
> In any of the downgraded combinations above, the new features of
> version 1 will not be available.
>
> If either party receives a PDU containing an unrecognized Protocol
> Version (neither 0 nor 1) during this negotiation, it MUST either
> downgrade to a known version or terminate the connection, with an
> Error Report PDU unless the received PDU is itself an Error Report
> PDU.
>
>[A] Both versions react the same way to an unrecognized version...so no
>need to repeat.
>
>
> The router MUST ignore any Serial Notify PDUs it might receive from
> the cache during this initial start-up period, regardless of the
> Protocol Version field in the Serial Notify PDU. Since Session ID
> and Serial Number values are specific to a particular protocol
> version, the values in the notification are not useful to the router.
> Even if these values were meaningful, the only effect that processing
> the notification would have would be to trigger exactly the same
> Reset Query or Serial Query that the router has already sent as part
> of the not-yet-complete version negotiation process, so there is
> nothing to be gained by processing notifications until version
> negotiation completes.
>
>[A] This text (above) is in conflict with Section 5.2. (Serial Notify),
>which reads: "If the router receives a Serial Notify PDU during the
>initial start-up period...the router SHOULD simply ignore the Serial
>Notify PDU..." Solution: update 5.2 with a "MUST" -- according to the
>explanation above, there's no real value in listening (which would not
>make it a "SHOULD").
>
>[A] Section 5.2 also says: "See Section 7 for details." Instead of that
>reference, you can include the additional text above (after the first
>sentence).
>
>
> Caches SHOULD NOT send Serial Notify PDUs before version negotiation
> completes. Note, however, that routers MUST handle such
> notifications (by ignoring them) for backwards compatibility with
> caches serving protocol version 0.
>
>[A] The text above is the corollary of the "MUST ignore" text before it
>(you can include it in 5.2)...and the second sentence is really redundant.
>
>
> Once the cache and router have agreed upon a Protocol Version via the
> negotiation process above, that version is stable for the life of the
> session. See Section 5.1 for a discussion of the interaction between
> Protocol Version and Session ID.
>
> If either party receives a PDU for a different Protocol Version once
> the above negotiation completes, that party MUST drop the session;
> unless the PDU containing the unexpected Protocol Version was itself
> an Error Report PDU, the party dropping the session SHOULD send an
> Error Report with an error code of 8 ("Unexpected Protocol Version").
>
>
>[A] Add the exception (receiving an Error PDU) to the definition of error
>code 8 in Section 12.
>
>
>
>
>Given that it is in fact possible to find older versions in the field, you
>might want to include a Section calling that out. My suggestion is to
>create a new Section called "Deployment Considerations", include in it the
>current Section 11. (Deployment Scenarios) as a sub-section, and add a new
>sub-section called "Transition Considerations".
>
>Suggestion>
>11.2 Transition Considerations
>
> This document Obsoletes version zero of this protocol [RFC6810].
> The intent is to deprecate its use. However, version zero is already
> in the field and it is possible that deployments will encounter mixed
> scenarios, where a router or cache may only support version zero. It
> is also expected that during the transition period a cache or router
> that supports version one will also support version zero. The
>determination
> that a peer (cache or router) only supports version zero is straight
> forward: a version zero PDU is received from them. In these cases, it
> is up to the local implementation, and policy, whether it might prefer
> to use version zero to establish the session, with the understanding
> that the new features of version one will not be available.
>
>
>
>
>One new comment:
>
>Section 12. (Error Codes) says that "Errors which are considered fatal
>SHOULD cause the session to be dropped." When is it ok not to drop the
>session? IOW, why not use a "MUST"?
>
>
>Thanks!
>
>Alvaro.
>
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
