[08:57:51] --- sleinen has joined
[08:58:28] --- mjo has joined
[09:00:10] --- javier has joined
[09:00:16] --- javier has left
[09:00:32] <sleinen> status of active drafts
[09:00:39] <sleinen> draft-ietf-grow-bgp-med-considerations-02
[09:00:52] <sleinen> will be resubmitted. Last Call early next week - please look at it
[09:02:26] <sleinen> draft-ietf-grow-anycast-00.txt Presentation
[09:04:13] <sleinen> presentor: Joe Abley
[09:05:32] --- bert has joined
[09:05:51] --- ggm has joined
[09:06:56] <sleinen> Pekka Savola at the mike: can you clarify what an "anycast node" is precisely
[09:07:48] <sleinen> Joe: can be a single host or a collection of nodes - such as the F-Root nodes which are internally anycast using IGP. The draft is deliberately unspecific on this.
[09:09:48] <sleinen> Dave Meyer: PCH's anycast deployment also uses IGP, but in an overlay network that spans all anycast sites
[09:09:49] <ggm> Dave is confusing things. tunnels are not visible over the global net, they are edgy in this context.
[09:10:01] <ggm> its not relevant in layering terms
[09:10:51] --- suz has joined
[09:11:31] <sleinen> Hiroshi Kitamura (NEC): would like a clear definition/taxonomy for Anycast
[09:17:27] <sleinen> Dave Meyer: note about IPv6 anycast. We need to disambiguate between what people actually do (like in IPv4, inject routes into unicast routing system from several places) as opposed to "IPv6 Anycast" as originally specified. Maybe the latter should be deprecated?
[09:17:30] <ggm> Meyer: V6 anycast needs to note, nothing stops injection of V6 unicast prefix into routing cloud same as V4. construct same kind of anycast service. Its not the same as V6 anycast -they have to be disambiguating. I think deprecate V6 anycast may be the way to go. clarify in draft. Pekka: don't think this draft is DNS centric. multi-service nodes, main focus of doc should be single-service nodes.
[09:17:45] <ggm> (sorry Simon I thought you might have left. I'll not inject my notes!)
[09:17:50] <sleinen> OK
[09:18:14] <sleinen> Kurtis Lindqvist: should we send this back to the IPv6 WG?
[09:18:30] --- kazuya has joined
[09:19:11] <sleinen> Geoff Huston:draft talks about what is done today, and that's a good thing. The "IPv6 Anycast" architecture isn't usable as of today - that's for the IPv6 WG to look at.
[09:20:13] <sleinen> Pekka Savola: For multiservice nodes interconnected by tunnels, expect problems when packet size exceeds tunnel MTU
[09:20:53] <sleinen> Joe Abley: We look at these constructs as massively multihomed ASes, where the anycasting is done internally (IGP over tunnels).
[09:21:28] <sleinen> next up: draft-ietf-grow-bgp-wedgies-00.txt (Griffin/Huston)
[09:21:42] <sleinen> Not many people have read the draft lately.
[09:22:02] <sleinen> Geoff gives a short summary on the "wedgies" described in the draft.
[09:22:52] <sleinen> Pekka Savola had made a couple of comments quite a while ago
[09:23:02] <sleinen> Geoff: will be addressed in Last Call(?)
[09:23:19] <sleinen> draft-ietf-grow-rift-01.txt
[09:23:48] <sleinen> Will discuss with ADs as to how to proceed with this. No progress yet.
[09:24:39] <sleinen> Pekka Savola on Tunnel Endpoint Discovery - Anycast Perspective
[09:28:00] <ggm> isn't this a generalized service-discovery problem and solution? I don't see why this has to be in GROW frankly, except a problem statement 'tunnels need this'
[09:28:14] <ggm> and seeding 'golden' nets in WKS is .. contentious
[09:28:43] <ggm> having said which, I think a generalized method would be good!
[09:29:33] <sleinen> Kurtis: using Anycast for forwarding-plane discovery seems like a really bad idea
[09:30:49] <sleinen> Pekka: for tunnels, this must be addressed in the Tunnel CONFIGURATION protocol
[09:32:50] <sleinen> Geoff: Points to Dave Plonka's draft about hardwired addresses being a really, really, really bad idea. Doesn't this here have the same drawbacks? Should use a real service location protocol. The well-known (anycast) address approach has also been discredited for discovery of local DNS servers by Keith Moore.
[09:33:27] <sleinen> Pekka: A difference here is that these well-known addresses are not taken out of any operator's address space.
[09:33:43] <sleinen> We had looked at SLP, but it had some serious issues.
[09:34:31] <sleinen> Dave Meyer: operational question. How large a provider-independent prefix would you expect to need for this?
[09:35:43] <sleinen> Pekka thinks that in IPv4, /24 is sufficient, as this is what is used in 6to4 (
[09:36:45] <sleinen> DaveM finds it hard to choose prefix sizes that are globally accepted in routing, without being overly wasteful of address space
[09:37:41] <sleinen> Joe: suggests a potential issue of hijacking (of routing prefixes) in the presence of filters
[09:38:14] <sleinen> Joe: given the last comments, you might want a prefix that ISN'T routable globally
[09:38:32] <sleinen> Pekka: Yes, looking at private well-known address space that can be used for this service.
[09:39:49] <sleinen> Next up: Lixia Zhang on "AS-Level Topology Growth: A Preliminary Measurement"
[09:42:18] --- Yoshifumi Atarashi has joined
[09:42:28] <sleinen> URL: http://irl.cs.ucla.edu/topology/
[09:43:33] <sleinen> CCR'05 paper http://irl.cs.ucla.edu/topology/ccr05.pdf
[09:50:29] <sleinen> Andy ?: What do you use to define your buckets 1, 2, 3, 4, 5? Is there a strict rule?
[09:51:21] <sleinen> Lixia: Yes. The rules are fixed, but not like laws of physics. They are Lixin Gao's (UMass) and are explained in the paper.
[09:52:23] <sleinen> Dave Meyer: Are the ASes in your Tier-1 bin the same as known as the "Skitter core"?
[09:52:51] <sleinen> Geoff: Skitter is only based on degree (number of interconnections) rather than a hierarchy, as here.
[09:57:19] --- Bill has joined
[09:59:06] <sleinen> Simon: are you trying to exclude transient effects when counting added/removed links? Lixia explains that this was shown two slides ago
[09:59:35] <sleinen> Geoff: You're assuming that what you see in updates corresponds to reality?
[09:59:53] <sleinen> Lixia: If you define reality as existence of AS peering sessions, this is true.
[10:01:12] <sleinen> Lixia explains how they tried to cross-check their findings by asking ISPs for verification
[10:01:49] <sleinen> ?: Also wants to know whether the numbers show "real growth" or just links that are newly discovered by the method.
[10:04:14] <sleinen> ?: Points out situations where existing paths won't be seen for extended periods of time (months) - heavy AS-prepending for backup path. Would those be seen as appearing/disappearing links?
[10:04:47] <sleinen> Lixia: We remove links from the "disappeared" counts when the reappear.
[10:05:05] <mjo> ?=Cengiz
[10:05:50] <ggm> I missed Jeffs comments after Gengiz
[10:06:00] <sleinen> me too :-(
[10:06:45] <sleinen> Lixia: growth in terms of links occurs mainly in the "Tier-2" bin, growth in terms of nodes in the "Tier-5" bin
[10:07:20] <ggm> Jeff: was data corrected for non-bogus AS paths [no]
[10:07:48] <sleinen> [more discussion about the effect of transient routes on the analysis]
[10:08:51] <sleinen> Joe Abley: AS-path poisoning by prepending a nother-than-local AS (AS-path poisoning). Did you look at this?
[10:09:02] <sleinen> Lixia: seems to be a very, very rare occurrence.
[10:09:02] --- suz has left
[10:09:03] --- suz has joined
[10:09:11] <sleinen> Joe: How did you determine when you see this?
[10:10:01] <sleinen> Lixia: verifying against "normal BGP policies" whether links correspond to real topology [more explanation omitted]
[10:11:51] <sleinen> ggm at the mike: Geoff often pointed out that AS-path length seems to remain constant although connectivity is growing. What you are showing here may be a corrolary of this.
[10:12:50] --- rbless has joined
[10:13:19] --- rbless has left: Lost connection
[10:13:20] <sleinen> Looking at BGP slow-convergence problem, which may be exacerbated by growth in connectivity
[10:19:03] <sleinen> Jeff: correlation between number of explored paths and the actual convergence time?
[10:19:32] <sleinen> Lixia: yes, definitely. The (high) number of updates is spread over a longer time period.
[10:20:28] <sleinen> Lixia points out the timestamps in the previous slide.
[10:20:52] <sleinen> convergence time more or less proportional to the number of updates
[10:23:02] --- bless has joined
[10:23:02] --- bless has left: Lost connection
[10:23:12] <sleinen> Next up: Nischal Piratla on "FRTR: A Scalable Mechanism for Global Routing Consistency"
[10:25:28] --- bless has joined
[10:25:28] --- bless has left: Lost connection
[10:32:32] <sleinen> Pekka Savola: please clarify: this trades update bandwidth against processing time (when router has to check 100'000 routes for consistency)?
[10:33:23] <sleinen> Tony Li: rephrase this. What do you see as the constraint that causes BGP's slow convergence?
[10:33:49] <sleinen> Nischal: one thing is session resets. This is about avoiding to send a full table after a restart.
[10:34:27] <sleinen> Tony: Time to convergence seems to be dominated by processing time (in the real world). What this does is to minimize bandwidth, right?
[10:35:17] <sleinen> Nischal: One thing is bandwidth conservation, the other is about removing the inconsistencies due to the digest mechanism
[10:36:03] <sleinen> Tony: it's very likely that after a session reset, MY path attributes are completely different from YOUR path attributes, so everything will be re-exchanged?
[10:36:54] <sleinen> Lixia: you don't have to recompute the digest instantly on each change. [...]
[10:38:04] <ggm> who is this?
[10:38:17] <sleinen> don't know. Someone from Cisco, he said
[10:39:16] <sleinen> ?: Points out that the possibility of false positives is a showstopper, because this leads to black holes.
[10:39:17] <ggm> chandra
[10:41:04] <sleinen> Jeff: thinks that the effort of route-selection (from a retained RibIn) will be higher than the effort of reprocessing a full set of updates
[10:41:33] --- Yoshifumi Atarashi has left: Replaced by new connection
[10:41:34] --- Yoshifumi Atarashi has joined
[10:42:00] <sleinen> Yakov Rekhter: shouldn't we spent more effort on avoiding BGP sessions flapping in the first space?
[10:42:11] <sleinen> Tony Li: You can't stop the backhoe!
[10:42:43] <sleinen> [discussion between Tony and Yakov about benefits of lower-layer restoration facilities such as in SONET.]
[10:43:05] <sleinen> Tony sees benefit of this for scheduled updates.
[10:43:28] <sleinen> but there's a simpler mechanism for this (avoiding necessity to store AdjRibIn)
[10:43:56] <sleinen> could use a "resynchronize" procedure [...]
[10:44:16] <sleinen> Nevertheless this is a wonderful technique, just applied in the wrong place.
[10:44:29] <sleinen> Go to the IS-IS WG and talk about rapid CSNP(?)s
[10:44:56] <sleinen> Henk Uijterwaal: Suggests some performance measurements (overhead/bandwidth)
[10:45:11] <sleinen> Nischal mentions some measurements that were made.
[10:45:58] <sleinen> Nischal goes on with the presentation (BGP message format for digests...)
[10:46:37] --- mjo has left
[10:47:29] <sleinen> Nischal presents performance evaluations of the FRTR mechanism
[10:52:45] <sleinen> [Dave Meyer on last item - that doesn't seem to be appropriate as a work item for an operational group - this is FRTR]
[10:53:08] <sleinen> Now up: Geoff Huston about the current state of BGP tables
[10:59:39] <sleinen> Dave Meyer: do you have an idea how much of the more-specifics can be explained by "rational" (e.g. traffic engineering) goals rather than errors?
[11:01:24] <sleinen> Yakov asks whether we'll run out of 16-bit AS numbers or 32-bit IPv4 addresses first?
[11:01:38] <sleinen> Geoff: AS number, by about two years difference. But we could take bets...
[11:08:13] --- suz has left
[11:09:04] --- kazuya has left
[11:09:14] <sleinen> Presentation and meeting concluded.
[11:26:43] --- Yoshifumi Atarashi has left: Disconnected
[11:27:38] --- ggm has left
[11:41:45] --- sleinen has left: Disconnected
[11:41:47] --- Bill has left
[11:44:35] --- Bill has joined
[12:00:32] --- Bill has left
[12:40:05] --- Yoshifumi Atarashi has joined
[12:40:35] --- Yoshifumi Atarashi has left
[12:48:34] --- bert has left
[14:31:46] --- wej has joined
[14:39:41] --- wej has left