Christopher Morrow wrote: > On Mon, Dec 1, 2008 at 12:53 PM, Yakov Rekhter <[EMAIL PROTECTED]> wrote: >> Tony, >> >>> |Recent postings suggest drop the first packet during map >>> |lookup. Oeps!!!! >>> |I think first packet delivery is a MUST. >>> >>> >>> The problem is that first packet delivery requires buffering. To quote an >>> esteemed colleague: "Buffering bad." ;-) >> This discussion focuses on the implication of dropping or buffering >> the first packet of a given flow. But there are cases where other >> than the first packet of a given flow would need to be either >> buffered or dropped. >> >> Consider the scenario where an ITR goes down, and as a result *all* >> the flows that used to go through that ITR would need to be shifted >> to other ITR(s), and other ITR(s) have no mapping info for these/ > > if the ITR goes down won't the IGP/EGP take care of shifting > some/all/most of this traffic away? for the ETR that might be more > complex, but for the ITR there is either a backup/neighbor/vrrp-pair > or another option (another link) for this traffic to go to, right? > > (or there SHOULD be, or the customer is in the same problem space as > they are in today's internet... their PE device died and has no > routes, so no traffic gets passed) > >> flows. What would these other ITR(s) do with the packets of these >> flows as these other ITR(s) are in the process of acquiring mapping > > I suspect that the same thing that happens today happens tomorrow, > packets/flows get dropped. Losing a router isn't a recoverable > situation today, if you have no routing info you are SOL. > >> info ? Would these other ITR(s) buffer all of them until they acquire >> the mapping info ? (with link speeds of of several Gb/s that may >> be a *lot* to buffer). Or would they drop all of them until they >> acquire the mapping info ? (with link speeds of several Gb/s that >> may be a *lot* to drop). > > agreed, this is a bunch of traffic, but it's a problem we have today > already. This isn't changed with any proposal going forward, as with > APT even you don't necessarily have enough routing info to see the > default-mapper at boot-time (depending on deployment scenarios of > course).
Though I agree that many of the other problems above already exist today, I don't think this last one does. If I understand correctly, Yakov's concern isn't about boot time, it's about failover from one active ITR to another. The original ITR has the appropriate mapping for some prefix with a huge amount of data being sent to it. This ITR fails, and the second ITR doesn't have the right mapping info. However, as Dan already pointed out, this should not be a problem in APT, since default mappers prevent ITRs from ever having to buffer packets. -Michael _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
