[07:03:15] --- LOGGING STARTED
[07:05:01] --- LOGGING STARTED
[07:08:03] --- LOGGING STARTED
[07:09:21] --- LOGGING STARTED
[07:11:34] --- LOGGING STARTED
[13:14:17] --- ggm has joined
[13:22:58] --- gih has joined
[13:34:26] <gih> Q: the only way you know the other end has gone is to write to the socket - with passive and active ends the passive end may not need to be able to write to the socket
[13:34:51] <gih> a: the slides show graceful restart - the passive client can still init a connect
[13:35:41] <gih> followup: we saw this problem with colliding inits of a session and did not see this approach as the resolution
[13:36:48] <gih> Kumar: you have to give both sides the ability to restart the connection, as relying on tcp restart
[13:37:17] <gih> Hares: this is one more configuration knob - e.g. two passive speakers is a problem that will cause things to slow down
[13:37:46] <gih> Enke: the proposal here is to make the active / passive selection automatic so that you try to avoid mutual active or mutual passive
[13:38:13] <gih> Hares: so you are attempting to rule out this case by automatic mode selction
[13:38:47] <gih> ?: the situation where one speaker has this config and the other does not is not efficient - the exponential backoff for a passive to init a session may be too slow
[13:39:21] <gih> ?: I find the combination of (?) and this is too complex with up to 3 minute wait
[13:40:24] --- ggm has left: Disconnected
[13:40:28] <gih> Enke: the other mechanism you cite (ldp) uses UDP discovery and then TCP - this is a straight TCP mechanism
[13:41:04] <gih> Enke: if there is a restart then the BGP session crashes - we are not eliminating this possibility
[13:41:56] <gih> John Pickering: the tiebreaker on IP addresses relies on BGP config specifying addresses on the remote side. you know the remote addr, but you are not sure what the remote side will use as uyour addr
[13:42:05] <gih> Enke: the addresses have to match.
[13:42:16] --- ggm has joined
[13:42:35] <gih> Zinin: the primary goal here is to simplyfy the code - right?
[13:42:59] <gih> Zinin: I sympathesize - but of course the old code will need to be supported for years.
[13:43:46] <gih> Enke: One way to avoid the old code in the implementation, and replace it with random backoff, and supporting the old code is unnecessary - the impl will support one fsm, not two
[13:44:01] <gih> Zinin: this nees to be confirmed
[13:44:54] <gih> ? Long time to re-estab connectivity is a problem. the passive / active mode selection as implicit is a problem as it may be a policy / function role assignation, rather than an automated mechanis,
[13:45:40] <gih> Emke: this does not excluse role assignation (active/passive) by explicit config. This was the case in the NSFNET days
[13:46:15] <gih> Kumar: there are no more than half a dozen really useful bgp implementations - can we survey them on this proposed change?
[13:47:17] <gih> Scudder: this is backward compatible, interoperable with old impl - do it - you win!
[13:49:02] <gih> Py: presentation of redistribution of cooperative filtering information
[13:50:20] <gih> - exploratory work, exploring the mechanism - clearly we are not sure that we know what we are doing
[13:50:38] <gih> - NOT trying to standardize distributed common bogon filtering
[13:50:51] <gih> (even this this is an application of these mechanisms)
[13:50:53] --- ggm has left: Disconnected
[13:51:08] <gih> - we think we could use this mechanism to distribute the bogon list
[13:51:42] <gih> -goal to reuse ORF mechanisms to distribute these prefixes
[13:52:20] --- ggm has joined
[13:52:31] <gih> - tell the peer "dont send X, I'm going to filter it anyway" - generalize this to a distribution across a net
[13:55:23] <gih> - propose to send an orf named object desired by the receiver
[13:57:01] <gih> - the need for the named object is to be able to reuse the named collection in other parts of the router's config by reference to the name - i.e. dynamic installation of routing information
[13:58:30] <gih> issues: interaction between orf and ibgp, draft too detailed, issues with iBGP topologies
[14:00:47] <gih> Scudder: this is pretty nice - its mainly a matter of implementation, so to that extent you may want to publish and suggest to your vendor that they implement this and give you a keyword. Its not evoidently a protocol action. Have you looked at the flowspec document? This is a way to push filters around within an AS (and possibly outside)
[14:01:18] <gih> py: we looked at the flowspec, and concluded that flowspec would be a significant amount of work - here its a case just of being able to name and reuse the object
[14:02:01] <gih> Scudder: seems like the downside of this dynamic sheme - you are counting on a server pushing bogons all over the next - its then a target for attack and a single point of faoilure in publishing this information
[14:04:42] <gih> draft-nalawade-bgp-soft-notify-00.txt
[14:06:01] <gih> - propose to use notification for a particular afi/safi
[14:06:59] <gih> (is an afeesafee a sesame street character? :-) )
[14:07:55] <gih> - an afeesafee notifuication that will not bring down or up the entire bgp session
[14:11:07] --- ggm has left
[14:23:01] --- ggm has joined
[14:28:29] --- ggm has left: Disconnected
[14:28:47] --- ggm has joined
[14:29:51] --- gih has left
[14:30:24] --- ggm has left
[14:38:06] --- maho has joined
[14:44:03] --- maho has left
[14:44:18] --- maho has joined
[14:45:17] --- maho has left: Logged out
[14:45:17] --- maho has joined
[14:45:17] --- maho has left: Lost connection
[14:55:04] --- ggm has joined
[14:55:08] --- ggm has left