[21:18:35] --- underscore has joined
[21:18:39] --- underscore has left
[21:47:35] --- gih has joined
[21:53:27] --- ggm has joined
[21:53:55] <ggm> http://www.1.4.5.net/~dmm/IETF/IETF59/GROW/agenda
[21:57:16] <ggm> Grow WG kickoff. see if more come (sparce room)
[21:57:23] --- shane_ripe has joined
[21:58:41] <ggm> scribehunt completed
[21:59:17] <ggm> WG status changes, Draft status Recharter discussion
[21:59:28] --- Gordon58 has joined
[21:59:34] --- tskj has joined
[21:59:48] <ggm> Status of active Drafts: med considerations. new version in next 4 weeks. please send to him/list
[21:59:58] <ggm> draft-ietf-grow-bgp-med-considerations-00.txt
[22:00:22] <ggm> Embedding globally routable addrs considered harmful -Dave Plonka
[22:00:44] <ggm> Ready for WG last call? objections?
[22:00:56] <ggm> ok. issue WG last call on it.
[22:01:09] <ggm> BGP communities for data collection, Meyer.
[22:01:14] <ggm> 02 draft quite a lot of changes
[22:01:30] <ggm> ready for WG last call. readers... none
[22:01:41] <ggm> issue WG last call on it
[22:02:27] <ggm> Op concerns for routing, draft-ietf-grow-rift-01.txt Meyer/Design team
[22:02:39] <ggm> want to talk a bit, but nearly ready for WG last call.
[22:03:07] --- joew has joined
[22:03:17] <ggm> used to be called RPO. Routing Protocol Overload. now RIFT. Risk Interferance and Fit where we stand
[22:05:16] <ggm> concern using BGP for generalized feature transport.
[22:05:44] <ggm> approach: build framwork. gen. purp. transport inf (GPT) model.
[22:05:54] <ggm> Special Purpose Transport Inf (SPT) model.
[22:06:11] <ggm> designed specifically to transport idr inf
[22:06:27] <ggm> model components of risk. interference & application fit.
[22:07:05] <ggm> app: BGP data tupe and associated sig data eg ipv4 outing, flow spec, auto-discovery
[22:07:48] <ggm> Risk: model robustness tradeoffs. application of generic s/w eng issue on a given impl. "service providers not turning on features because of fear of crash"
[22:08:12] <ggm> risk in trade-off between extending proto and designing/impl/deploy new protocol. trade-offs
[22:08:18] <ggm> Multisession BGP and risk
[22:08:49] <ggm> design team struggling with consensus. built drafts on how to do multisession. fits in with risk
[22:08:50] --- mccreary has joined
[22:09:36] <ggm> refer to drafts. draft-scudder-bgp-multisession, draft-nalawade-bgp-soft-notify, draft-nalawade-bgp-update
[22:09:50] <ggm> simplified risk model.
[22:10:20] <ggm> have to assume special-purpose risks bounded by general solution, otherwise why worry?
[22:11:43] <ggm> model the AFI/SAFI ratio as small number. 1 or 2. -model the ways to make the Gen purp solution
[22:11:51] <ggm> fit the risk profile of the Special purpose solution.
[22:11:53] --- bert has joined
[22:11:57] <mccreary> FYI, the correct agenda URL is http://www.1-4-5.net/~dmm/IETF/IETF59/GROW/agenda
[22:12:07] <ggm> Dave has notation for this.
[22:12:11] <ggm> sorry I got URL wrong.
[22:13:10] <ggm> many other influences on the risk. abstracted away to focus on multisession
[22:13:23] <ggm> RIsk is modelling Interference, when you add AFI/SAFI
[22:13:26] <ggm> Interference.
[22:14:03] <ggm> trying to model potential for new appl. to adversely affecr the proto level behaviours eg new dependency/behaviour not expected. deadlock, destabilize distrib behaviour
[22:14:10] <ggm> Application fit
[22:14:23] <ggm> so no contention thus far
[22:14:26] <ggm> reasonable?
[22:14:33] <ggm> So on to Fit
[22:14:47] --- bert has left: Logged out
[22:15:01] <ggm> matching data to capabilities
[22:15:45] <ggm> different incarnations of this section of the document. got offtrack, talked about solns not issues/problems. in last incarnation, organized it as assertions & counter-assertions. may not be right way
[22:16:21] <ggm> better way to organize this, why need time before last call. look at assertions:counterassertions, try to organize as 'issues'
[22:16:25] <ggm> comments as to approach?
[22:16:31] <ggm> <nada>
[22:16:42] <ggm> Dimitri
[22:17:08] <ggm> Q I have is, when you read this bit, no conclusions
[22:17:19] <ggm> difficult to read, an assertion a counter-assertion how to evaluate?
[22:17:45] <ggm> Dave
[22:17:55] <ggm> document isn't supposed to conclude 'this is the right one'
[22:18:10] <ggm> Kurtis. wanted to wait to end.
[22:18:29] <ggm> Like assert/counterassert. but reads like on the one hand, on the other. no motivation as to WHY people argue one or the other.
[22:18:34] <ggm> elaborate
[22:19:20] <ggm> Luca Martini
[22:19:25] <ggm> could be vendor vs vendor.
[22:19:34] <ggm> really should fill in some stuff. things got missing as counter-assertions
[22:19:50] <ggm> Dave. didn't get as many inputs. easier to get one side rather than n-1 other sides
[22:21:14] <ggm> try to capture args for eg VPLS appl not a good fit to BGP. the arguement stems from pseudo wires
[22:21:20] --- terry has joined
[22:21:22] <ggm> being inherently ptp.
[22:21:38] <ggm> then explore a why on this.
[22:21:56] --- galvinjamesm has joined
[22:22:16] <ggm> if you wanted to do VPWS signalling, have to use route refl with union of all.
[22:22:33] <ggm> compute the size of it. size of per-wire label info x <n>
[22:22:59] <ggm> RR winds up with additional costs. stuff which endpoint could have sent anyway
[22:23:03] <ggm> counter-assertion.
[22:23:06] --- galvinjamesm has left
[22:23:27] <ggm> is a good fit: can use label range to get around the large setup msg. really isn't <n> times as large.
[22:23:52] <ggm> find its about size of label range * <n>
[22:24:04] --- darrin has joined
[22:24:15] <ggm> trying to not argue sides, just show the pro/cons.
[22:24:40] <ggm> Kreeti. citation is in L2VPN.
[22:25:36] <ggm> Yakov. analysis fails to analyse VPLS or any other app may have signalling but not only thing. need system wide analysis. don't see that much value in the arguments here.
[22:25:52] --- darrin has left
[22:25:57] <ggm> Kreeti. analysis of the ops impact of having 2 proto vs 1, the interactions, is also interesting
[22:26:14] --- joew has left
[22:26:32] <ggm> Luca not going to run BGP on some stuff. if talk about additional protocol is one of many
[22:27:52] <ggm> wind up with label ranges, efficient, iff large enough label range allocated to accom. all systems need to add, no per wire info apart from labels.
[22:28:00] <ggm> Kreeti want a counter-counter-counter?
[22:28:08] <ggm> Dave definitly
[22:28:32] <ggm> saving bits in the setup msg has other costs.
[22:28:42] <ggm> Dave this stuff isn't true or not true, its arguments in or against
[22:28:48] <ggm> Kreeti: marketing hype
[22:29:15] <ggm> Luca: comment on prev slide. per wire info. found that lot of per-wire info defined
[22:30:04] <ggm> case of VPLS only one MTU
[22:31:00] <ggm> Raj: assuming VPWS is homogeneous. all same type. worried about transitions where one of the pseudo wires is IP only, ether oneside, frame the other. even if two type of encaps, some have not implemented both types. its not that there isn't per-wire pseudo, there are and we will get more.
[22:31:09] <ggm> Meta-Q> how do we add to assertion/counter assertion
[22:32:29] --- underscore has joined
[22:33:13] <ggm> Kreeti discusses specifics of label issues in this.
[22:33:46] <ggm> Have deployments. people dont see problems.
[22:34:11] <ggm> Yakov. in addition to system not making system wide analysis. now we have random assertions and opinions. this is not a good approach
[22:34:32] <ggm> <?> doc of this type, looking at when labels allocated. look at label wastage
[22:34:55] <ggm> Luca: Yakov can you give us a system wide example so we can add them in? eg what parts?
[22:35:29] <ggm> Yakov. VPLS as a system has at least 2 components. auto discovery AND signalling. nothing on auto disc.
[22:37:28] <ggm> Kreeti. very powerful mechanisms in VPLS. . when talk about "fit" the issue was 'screwing up BGP" using this as transport. label ranges have nothing to do with this. in doing VPLS/VPWS we have changed nothing in the way BGP distributes things.per-NLRI, bitstring. attr filtering, AS path loop checks, all that stuff, peer group, all the same. just bitstring.
[22:38:12] <ggm> application fit: app is distribution of VPLS/VPWS. Q is what have we changed in BGP? none has changed. its a big switch. then check AFI/SAFI and check specific stuff. majority of changes inside.
[22:38:23] <ggm> route filtering, for constrained distribution
[22:38:32] <ggm> that thing was without change for VPLS.
[22:38:49] <ggm> go back and ask meta Q. bGP dist mechs vs appl requirements this analysis is off in the weeds
[22:38:53] <ggm> Dave at the end.
[22:39:04] <ggm> put it up there, didn't feel we were getting anywhere.
[22:39:31] <ggm> Yakov. in part, want to keep assertions./counter-assertions. add 'no check on validity of assertons and counter-assertsion"
[22:39:36] <ggm> Dave looking for a different approach
[22:40:00] <ggm> more like Kreeti. up level a couple. say 'these are some issues' leave it at that
[22:40:33] --- gih has left: Disconnected
[22:42:12] <ggm> Raj. uplevel one or two. debate might end up not being heated. may also not yield results. how far to go, what is end goal?
[22:44:12] <ggm> Kreeti. why vendors not implementing stuff? if you say 'here are risk/application fit issues' they can make decisions. risk too much, app fit perfect.
[22:44:30] <ggm> Kreeti its not x or y, its if I do choose y, what am I getting into?
[22:44:44] <ggm> Kreeti. don't get into counter-counter-counter args.
[22:45:21] <ggm> Raj asking for applicability stateent for this stuff. doc should say.
[22:46:02] <ggm> have to come up with better way of saying stuff
[22:46:16] <ggm> Yakov. exactly. goes nowhere. becomes a pile of trash
[22:46:31] <ggm> focus on what are the issues. dont get into debate
[22:46:47] <ggm> dave want to do this, put to list, get WG last call. in 1 month
[22:47:09] <ggm> Kurtis. impact for discussion: what do you plan to do with the document when published?
[22:47:11] <ggm> Dave informational
[22:47:16] <ggm> Kurtis whats the USE of it?
[22:47:46] <ggm> know it explains issue. why we got here. like the background. what lead to having it. if you take for/against out loose a lot of the value.
[22:47:50] <ggm> Dave compromise.
[22:47:52] <ggm> make appendix
[22:48:22] <ggm> Yakov. not happy.
[22:49:18] <ggm> Kireeti . providers need doc like this to assess issues
[22:49:24] <ggm> Yakov. unrelated example.
[22:49:56] <ggm> proposal in MPLS -to use PIM. need doc like this. pros and cons not argument
[22:50:12] <ggm> Kurtis. like Yakov more than what Kurt is saying.
[22:50:25] <ggm> Express better but saying the same thing.
[22:50:36] <ggm> Dave: Kireeti and I will work on this, get onto ML. have discussion there
[22:50:39] <ggm> WG last call andbe done
[22:50:59] <ggm> <?> if document overloading protos, please track OSPF/ISIS
[22:51:26] --- bkhabs has joined
[22:52:55] <ggm> hardie left rejected. bounded-longest match
[22:52:58] <ggm> Charter.
[22:53:16] <ggm> GROW without charter. dropped milestones. measurement/taxonomy. from PTOMAINE
[22:53:25] <ggm> DaveK Charter up next telecall
[22:54:21] <ggm> charter milestones are on the web presentation.
[22:54:46] --- sob has joined
[22:55:01] <ggm> Yakov: on item 4. first look at interaction of new IGP techniques on IGP itself before we get into BGP eg ISIS
[22:55:25] <ggm> if IGP doesnt work, BGP cant fix
[22:55:43] <ggm> Dave? lattitude to discuss this before teleconf?
[22:56:29] <ggm> Yakov: only on BGP not IGPs?
[22:56:34] <ggm> DaveK yes
[22:56:58] <ggm> Yakov. this is routing system. has both BGP and IGP. ought to look at system wide perspective. other does exist, is as important.
[22:57:07] <ggm> DaveK can argue. dont want to dicate.
[22:57:26] <ggm> Yakov: but to make BGP work, have to make IGP work? so , have first if talk about impact, talk about
[22:57:36] <ggm> impact on IGP. thats where it happens first. not BGP.
[22:57:41] <ggm> Alex Zinin. common ground
[22:58:11] <ggm> what you are saying is covered here. interaction between the IGPs te-extenstions, and BGP happen through normal BGP. interaction between TE exts,
[22:58:27] <ggm> as part of analysis, may appear exactly what you talk about is a problem
[22:58:37] <ggm> Yakov: so why not make it explicit
[22:58:40] <ggm> Zinin Send mail
[22:58:45] <ggm> Dave procedural aspects.
[22:58:56] <ggm> Davek dont care about procedure, just need to get right. text needed, just do it.
[22:59:17] <ggm> Dave: will take action item to take and get to you this? next? week
[22:59:23] <ggm> DAveK this week. faster better
[22:59:31] <ggm> Yakov. Q on item 3.
[22:59:54] <ggm> how to plan to do this? how to determine BGP effects on scaleability of BGP? wishlist or specific plans how WG to do this?
[23:00:10] <ggm> Dave dont have a plan
[23:00:18] <ggm> Yakov somebody has to tell me a plan
[23:00:31] <ggm> Bill. risk stuff is beginning of analysis
[23:00:55] <ggm> Yakov analysis of what?
[23:01:03] <ggm> Dave milestone supposed to cover the RIFT work.
[23:01:06] <ggm> Yakov then say so
[23:02:34] <ggm> more charter args.
[23:03:02] <ggm> bill. if have better way to cover RIFT, do it.
[23:03:08] <ggm> Dave will work on iii and iv by end of week
[23:03:22] <ggm> Bill to me, iii is fine describing RIFT but raises hackles.
[23:05:02] --- tskj has left
[23:05:14] --- bkhabs has left
[23:06:03] <ggm> Yakov. iii don't understand why focus on routing/signalling when also used for auto discovery
[23:07:10] <ggm> zinin
[23:07:24] <ggm> get everything recorded. good idea to post charter to ML, comment, converge there
[23:07:32] <ggm> Dave ADs
[23:07:38] <ggm> DaveK no nitpicking
[23:08:41] <ggm> Yakov item V. secure routing protocols? or what?
[23:08:48] <ggm> Dave D all of the above are in scope.
[23:08:52] <ggm> Yakov make clear in charter
[23:09:07] <ggm> Secure router inf. secure router protocols, not exactly the same. both or something else or ..
[23:10:37] <ggm> Susan Hares. RPSL is just an example. want to look at infrastructure as well.
[23:11:07] <ggm> Bill trying to enumarate every aspect .. its trying to say 'any aspect of security in routing system'
[23:11:14] <ggm> operational aspect.
[23:11:19] <ggm> Zinin
[23:11:58] <ggm> securing the routing protocols themselves, auth etc etc. if we're really careful to document operational aspects of securing the routing system. [Yakov interjected words]
[23:12:03] <ggm> DavidK send text. stop nitpicking
[23:13:09] <ggm> Bert sent msg to list, Geoff as co chair. VeeJay technical adviser, Bill technical adviser, David AD
[23:14:12] <ggm> DavidK this is going to take longer than you like. needs input by thus next week
[23:14:16] <ggm> Dave not hard mark to hit
[23:14:26] <ggm> DavidK not here next week, Bert also travelling. thjink we can manage
[23:14:44] <ggm> Action items done. adj. charter out to ML. done.
[23:14:46] <ggm> [end]
[23:14:54] --- sob has left
[23:15:23] --- ggm has left
[23:15:35] --- Gordon58 has left: Disconnected
[23:15:40] --- terry has left
[23:33:20] --- shane_ripe has left: Disconnected