On Wed, Jun 29, 2011 at 08:03:14PM +0900, Randy Bush wrote:
| hi hannes,
|
| first, i need to confess that i have disagreed with 'be liberal in what
| you accept' from day zero. that way lies entropy.
|
| > 5: Unsupported PDU Type (fatal): The PDU Type is not known by the
| > receiver of the PDU.
| >
| > <-- this prevents seamless upgrading once we want to extend the protocol;
| > why is this fatal ?
|
| not exactly. it prevents chaotic pretend upgrading producing a bunch of
| incorrect garbage in the router's database which leads to incorrect
| validity decisions and thus incorrect routing.
|
| imagine that the unrecognized pdu was signaling "flush all data with
| origin AS 42," or "delete all roas for prefix P or longer."
1. the router does not recognize the new PDU and returns an error.
2. by including the unrecognized PDU in the error message the
cache knows what particular PDU type has caused grief,
such that it can log it and bring it to the operators attention.
---
ok lets go through this:
i was worried about e.g. a "central" deployment model where all your ASBRs
have a session to a central cache. now consider you want to upgrade
the cache with rob's latest sw (which introduces new PDUs).
now all rpki-rtr sessions start to flap, unless you have upgraded
routers to support the new PDUs. - you might argue that you should simply
upgrade the routers first, thereby implying a certain upgrade order/procedure.
that is going to be a problem:
at some of my larger customers operational responsibilities (routers, servers)
are strictly seperate and this hidden requirement to upgrade routers first,
will likely be causing support-tickets at vendors of routing and local-cache
software.
| > 6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0
| > but a record for the Prefix/PrefixLength/MaxLength triple does not
| > exist in the receiver's database.
| >
| > 7: Duplicate Announcement Received (fatal): The received PDU has an
| > identical {prefix, len, max-len, asn} tuple as a PDU which is
| > still active in the router.
| >
| > <-- why do we need to reset the session here for reasons 6 & 7 ? -
| > in the spirit of "be tolerant what you receive" a receiving router
| > can do the right thing w/o disrupting the session.
|
| in general, all these indicate that the receiver and the sender are
| seriously out of whack. e.g. if the receiver goes ahead despite 6 or 7,
| the receiver's data are most likely incorrect in the sense that it will
| [in]validate an update which it should not. if that's not fatal, what
| is?
the IP PDUs in the protocol have canceling semantics - i.e. latest status
wins. so whats the point in bitching about the latest state ?
| but, i think at root, we have a disagreement on the idea of requiring
| 'correctness.' as i said, i admit to being a naggumite.
consider the following exchange:
(all IPvXn prefix PDUd carry exactly the same update);
Cache Router
~ ~
| -------- Notify ----------> | (optional)
| |
| <----- Reset Query -------- | R requests data
| |
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix1 -----> | C sends zero or more
| ------- IPvX Prefix2 -----> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix3 -----> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
| <----- Reset Query -------- | R requests data
| |
| ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix1 -----> | C sends zero or more
| ------- IPvX Prefix2 -----> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix3 -----> | Payload PDUs
| ------ End of Data ------> | C sends End of Data
| | and sends new serial
question:
is the second IPvX Prefix1 Update a duplicate update ?
if so: must the cache filter those out ?
if so: how can i guarantee that a "Reset Query" really
gets me the latest view ?
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
