On Tue, Dec 2, 2008 at 11:03 AM, Yakov Rekhter <[EMAIL PROTECTED]> wrote: > Chris, > >> 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... > > That is correct. > >> 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. > > Consider the case where ITRs belong to ISPs, and customers who are > multi-homed to different ISPs. In this case ITRs in a 'vrrp pair' > may belong to different ISPs. > > Moreover, a given ITR may need to participate not in one, but in > multiple 'vrrp pairs', as different customers connected to that ITR > may have their other connection(s) to different (other) ITRs. > > Do you think that is still "not hard to do" ? >
the multi-isp situation is harder, indeed... in practical cases some of the missing data on the alternate provider should exist (due to other customers on the relevant edge device(s) ), but yes some traffic will be dropped. Do you have an alternate possible solution for that case? (someone off-list pointed out to me that the ITR might not actually be the PE, which side-steps this situation I think, right?) As to the second portion, whether it's one or more 'vrrp pair' devices there exist already many ways to distribute this sort of info... I don't see that as a large problem, no. -Chris > Yakov. > _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
