On Tue, Dec 2, 2008 at 3:49 AM, Michael Meisel <[EMAIL PROTECTED]> wrote: > 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
ah, sorry! yes, that was his question in grow/rrg I believe... I think it makes sense to have the ability to share mapping info among the 'vrrp pairs'. That's not hard to do, it's just a feature request. In practice the 'vrrp pair' probably is servicing traffic on both members of the 'pair' and keeping the mapping info sync'd (within a reasonable time lag) is sensible. This isn't a change to ITR/ETR functionality, it's just an added feature to the implementation. In fact, it maybe that an operator wants to share the mapping info among devices in a 'region' or 'pop' to avoid mapping request overhead in a local region... that fits into the 'vrrp pair' model above as well. Note: 'vrrp pair' doesn't have to be 'vrrp' it could be paired devices (as seen from the CE side) in a provider network... Something like diverse PE devices of course. > 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. > sure, and I agree that APT has potential in certain deployment scenarios, but in reality isn't likely the 'best' solution for everyone, so isn't the 'only solution', and honestly isn't very different from a LISP deployment on it's own... save the ::0/0 -> to-the-left with TTL 999999999 entry in the mapping database. -chris > -Michael > _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
