Hi,
I don't know if the agenda has already be discussed or fixed. However, if there is still a 15 minute slot available at the next IEPG meeting, I would like to present/discuss performance tests results we had on BIND9/NSD/UNBOUND.
Regards,
Daniel
--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
So we have the following on the agenda 1. comparative performance of HTTP access via NAT64 or NAT-PT, Brian Carpenter, 15mins 2. performance tests results on BIND9/NSD/UNBOUND, Daniel Migault, 15mins 3. Some DNS server IPv6 measures in an anycast cloud, Kurtis Lindqvist, 5 mins 4. Network Measurement Reporting (NMR), Richard Barnes, 20mins This is only an hour but a) i might get one more presentation, b) We tend to over run all the time and this time I have promised we won't c) Ricahrd said he can talk up to 30 mins. But I can squeeze some more in if there are last minute presentations. Anyone willing to do an RIR update? Last, can all presenters please mail me their slides... Best regards, - kurtis -
On 4 nov 2010, at 14.48, Lindqvist Kurt Erik wrote: > > > > So we have the following on the agenda > Latest agenda is as follows : 1. comparative performance of HTTP access via NAT64 or NAT-PT, Brian Carpenter, 15mins 2. performance tests results on BIND9/NSD/UNBOUND, Daniel Migault, 15mins 3. Some DNS server IPv6 measures in an anycast cloud, Kurtis Lindqvist, 5 mins 4. Network Measurement Reporting (NMR), Richard Barnes, 20mins 5. Some interesting research, Randy Bush, 45mins We meet at 10.00 in Garden Ballroom 1 Best regards, - kurtis -
IEPGers,, Included below is a link to a PAM paper and presentation covering a large-scale investigation into the occurrence of duplicate updates in BGP. http://www.cs.ucla.edu/~jpark/dupbgp.pdf http://www.cs.ucla.edu/~jpark.dupbgp-pam10.ppt The point at the microphone I made was that if folks reenable RFD with ANY thresholds then it should be done with extreme caution and that operators should press their vendors to implement RFD with per-path state, not simply per prefix, else duplicates from multiple iBGP paths in an adjacent AS might unfairly penalize prefixes contained in superfluous duplicate updates in those same implementations. If anyone has concerns with the methodology in the paper I certainly welcome some explanation of those concerns, as it seems perfectly reasonable to me. -danny
IEPGers,, Included below is a link to a PAM paper and presentation covering a large-scale investigation into the occurrence of duplicate updates in BGP. http://www.cs.ucla.edu/~jpark/dupbgp.pdf http://www.cs.ucla.edu/~jpark.dupbgp-pam10.ppt The point at the microphone I made was that if folks reenable RFD with ANY thresholds then it should be done with extreme caution and that operators should press their vendors to implement RFD with per-path state, not simply per prefix, else duplicates from multiple iBGP paths in an adjacent AS might unfairly penalize prefixes contained in superfluous duplicate updates in those same implementations. If anyone has concerns with the methodology in the paper I certainly welcome some explanation of those concerns, as it seems perfectly reasonable to me. -danny
> Included below is a link to a PAM paper and presentation covering a > large-scale investigation into the occurrence of duplicate updates in > BGP. where the network in question was said not have cluster id set on the rrs, thus producing dupes in a different distribution than one would see normally. but indeed, there are a lot of dupes out there. randy
> where the network in question was said not have cluster id set on the > rrs, thus producing dupes in a different distribution than one would see > normally. There were certainly cluster IDs on the iBGP RRs, and even if there weren't, they'd default to the BGP RRs router ID, but that's not relevant anyway. The point is that this could occur with any non-transitive non-mandatory attribute, it's just much more obvious in places where more influencers (e.g., RR or confederation path attributes that reflect internal topologies but aren't propagated externally) surface. There are two options here, the cleaner is for BGP implementations to keep state of exactly what they've propagated to a given eBGP peer and avoid readvertisement of duplicates that result from non-transitive attributes being stripped. We chatted with Keyur about this when we saw the behavior and he said there were some optimizations in some code, but not all. Additionally, RFD implementations need to keep per path state for just this reason else intermediate ASNs can have iBGP issues that result in duplicates which penalize the entire prefix, even if it's reasonably stable. IIRC, RFC2439 describes something to this effect. -danny > but indeed, there are a lot of dupes out there.
> where the network in question was said not have cluster id set on the > rrs, thus producing dupes in a different distribution than one would see > normally. There were certainly cluster IDs on the iBGP RRs, and even if there weren't, they'd default to the BGP RRs router ID, but that's not relevant anyway. The point is that this could occur with any non-transitive non-mandatory attribute, it's just much more obvious in places where more influencers (e.g., RR or confederation path attributes that reflect internal topologies but aren't propagated externally) surface. There are two options here, the cleaner is for BGP implementations to keep state of exactly what they've propagated to a given eBGP peer and avoid readvertisement of duplicates that result from non-transitive attributes being stripped. We chatted with Keyur about this when we saw the behavior and he said there were some optimizations in some code, but not all. Additionally, RFD implementations need to keep per path state for just this reason else intermediate ASNs can have iBGP issues that result in duplicates which penalize the entire prefix, even if it's reasonably stable. IIRC, RFC2439 describes something to this effect. -danny > but indeed, there are a lot of dupes out there.
> if there weren't, they'd default to the BGP RRs router ID, but that's > not relevant anyway. it is very relevant as both would then have two diff clusterIDs and they would then dupe > The point is that this could occur with any non-transitive non-mandatory > attribute, it's just much more obvious in places where more influencers > (e.g., RR or confederation path attributes that reflect internal > topologies but aren't propagated externally) surface. agree. route amplifiers. > There are two options here, the cleaner is for BGP implementations to > keep state of exactly what they've propagated to a given eBGP peer and > avoid readvertisement of duplicates that result from non-transitive > attributes being stripped. not cheap. memory. data structure. ... randy
> it is very relevant as both would then have two diff clusterIDs and they > would then dupe If you have RR clients that are homed to multiple clusters for redundancy and path diversity or multiple levels of iBGP RR hierarchy, or both, or any of an array of other iBGP topologies, then it has the same effect .. and this is just one trigger of the problem outlined more broadly below, that was the point, with which You seemed to agree. Depending on the connectivity and redundancy requirements for clients, it may be perfectly reasonable to have no RRs in an iBGP topology that share a common cluster ID. -danny
RSS Feed11 | |
|---|---|
6 | |
16 | |
10 | |
5 | |
3 | |
16 | |
5 | |
1 | |
9 | |
4 | |
16 | |
12 | |
5 | |
14 | |
3 | |
18 | |
15 | |
10 | |
2 | |
11 | |
2 | |
4 | |
1 | |
7 | |
10 | |
10 | |
6 | |
1 | |
12 | |
3 | |
1 | |
13 | |
4 |
