GROW: Friday, 0900-1130

	I.	GROW WG Update
	A.	BGP Graceful Restart got published
	B.	3 drafts in IESG queue
	II.	Operational Requirements for Enhanced Error Handling Behaviour in BGP-4: Rob Shakir
	A.	draft-shakir-idr-ops-reqs-for-bgp-error-handling 
	B.	Presented @ IDR yesterday and consensus there was that this is, most likely, a doc best handled looked in GROW
	C.	Avoid sending notification 
	1.	1st requirement is avoid sending NOTIFICATION where possible, because session failure affects all NLRIÕs, even though negative impact affects only a single AFI/SAFI.
	D.	Recover RIB Consistency
	1.	Inconsistent RIB compromises protocol correctness, namely in the case of treating UPDATE as withdraw.
	2.	Route Refresh is inefficient, because you need to transmit entire RIB.  Requirement is to be able to request specific RIB subsets.
	E.	Avoid Session Reset when recvÕing a Notification
	1.	Limits the impact on forwarding
	F.	Additional complexity in the protocol requires further operational visibility, so we need to enhance operational visibility.  For example, if there is an invalid UPDATE, the transmitter would really like to see it.
	G.	Caveats of Requirements
	1.	Finite control plane resources, so need to ensure that when automatic recovery is possible we donÕt get into situation where we enter a Òspiral of deathÓ.
	2.	Exponential back-off for RIB recovery requests
	3.	Avoid constant (back2back) session resets
	H.	Draft Progress
	1.	Although some differences of opinion on how we might accomplish some of the above, everyone (so far) has agreed with the general direction. 
	2.	Would like GROW WG to adopt doc.
	I.	Questions/Comments:
	1.	Ilya Varlashkin: Extended Message size.  It would be nice to specify in your draft that Ext. Message size was a requirement in order to see a full UPDATE, w/out worrying about truncation.
	2.	Rob: Agree.
	3.	Jeff Haas: Would like group to adopt the draft.  Covers about 70% of the problem space.  Should perhaps be split apart to discuss the problem space, without discussing the solutions.
	4.	Chairs: clear indication for people in room to adopt the draft.  WeÕll ask the list.
	III.	Time to Remove Filters for Previously Unallocated IPv4 /8s: Terry Manderson
	A.	draft-ietf-grow-no-more-unallocated-slash8s
	B.	Purpose
	1.	Observation is that many operators are slow to remove ex-bogons from their BGP and other filters
	2.	Problem is acute in Enterprise, etc. networks
	C.	Example: US GovÕt ETSA Web site
	D.	Goal:
	1.	Short, easy primer for people to know that there is only a small set of things that are legitimate to filter.
	E.	Suggestions RecvÕd:
	1.	Incorporate IPv6 & AS filtering recommendations
	F.	Open question on whether or not to accept those proposals
	1.	Both IPv6 and ASN spaces are open to further allocations, so if we did include them this doc would lose value
	G.	Wes George: agree those things should be in another document.
	H.	Jeff Haas: should probably mention the term ÒDark IPÓ in the document, because commercial products use that term instead of bogons, etc.
	I.	Seichi Kamamura: IÕm with Wes that it should be in a separate doc.  Sent a message to Leo that there should be clarity as to whether this is solely addressing control plane filtering or in-band dataplane filtering as well.
	J.	Terry: please send text to list.
	K.	Chairs: what is the authors recommendation?
	L.	Terry: Authors didnÕt have one, asking for feedback from WG members.
	M.	Recommendation was that another rev was due and it should be out in another few weeks.
	IV.	BGP Next-Hop SAFI: Ilya Varlashkin
	A.	draft-varlashkin-bgp-nh-cost
	B.	Goal is to optimize route reflection by sending next-hop cost information.
	C.	DonÕt want to waste peopleÕs time, since this was already presented in IDR yesterday.  Happy to take questions & avoid another re-preso.
	D.	Rob Shakir: all the feedback was in IDR yesterday.  Having this in a separate SAFI would be a great idea.
	E.	Aiming to have this doc in IDR.  This was just a heads up.
	V.	Diverse Path Implementation Report: Rob Raszuk
	A.	draft-mynam-grow-diverse-path-impl-00
	B.	Base spec:
	1.	Overall objective of this work is to not require any changes on the client
	2.	Base spec was waiting on implementation report
	3.	Current version of base spec is -03.  Has been stable for at least 2 IETFÕs.
	C.	See slides to details
	D.	???: Supporting case of two, different route reflectors that advertise primary and secondary?
	E.	Rob Raszuk: Yes, primary route reflector sends best-path.  Second RR sends backup path.  Today, deployments have two iBGP sessions to primary and backup RRÕs in same POP, usually.  So, in deployments of diverse path the PEÕs will always have same sessions, but they will also have primary and backup best paths, because each RR operates on different ÒplaneÓ.  PEÕs will only choose secondary/backup path when primary RR goes down.
	F.	 Authors recommend that we WG LC the Diverse Path Specification.
	G.	Jeff Haas: Good doc, but usually implementation reports come out after a specification has been published as an RFC and, usually, there are 2 or more implementations discussed in implementation report to progress it.
	H.	Rob Raszuk: Only IDR has a requirement for 2 separate implementations.  This is something that co-chairs asked for, so we put it together.
	VI.	Route Flap Damping Deployment Status Survey: Shisio Tsuchiya
	A.	draft-shishio-grow-isp-rfd-implement-survey
	B.	See slides for details.
	C.	Researchers are proposing to tune RFD so it has less aggressive suppress threshold, because RFD isnÕt as widely used as it could be.  Problem is some implementations have built-in/hardcoded values for suppress threshold.
	D.	Survey asks about a bunch of RIPE & RFC documents on RFD.
	E.	Surveyed JANOG and, most recently, NANOG.
	F.	NANOG survey to end May 25, 2011.
	G.	JANOG results: 19 respondents.  Slides/draft walk through of JANOG survey results.
	H.	From JANOG survey, itÕs clear there are many SPÕs that have RFD disabled.
	I.	Asking that survey be forwarded to any Network Operator Groups that people are aware of.
	J.	Authors recommend that this doc be taken up by GROW, since itÕs a survey, not protocols doc.
	K.	Chris Morrow: But, if this is requested changes to the RFD specs, then this should be taken up by IDR, correct?
	L.	Randy Bush: 2 classes of issues.
	1.	I consider max limits built-in to implementations that arenÕt actually in the specs to be ÒbugsÓ and they should be filed as bugs with vendors and fixed.
	2.	Default values for penalties are operational issues and the place to change them is IDR, but the place to figure out whether to change them is here.  Concern is that if/when changes to the defaults are made and new code ships, then it will result in slight increase in memory + CPU which might surprise some operators.
	M.	Chairs: Who thinks it should be adopted by GROW?  About 12+ hands.  Will take it to the list and see what are next steps.
	VII.	Virtual Aggregation: Xu Xiaohu
	A.	Summary of comments on Virtual Aggreation drafts
	B.	Reviews received from 3 people, expecting 1 more review.  TodayÕs preso to go over comments and how they will be addressed in next draft.
	C.	See slides for details.
	D.	Rob Raszuk: AddtÕl information.  If you were at APRICOT, we presented ÒSimple VAÓ slides and made it even more simple.  Talking with Paul Francis about adjusting ÒSimple VAÓ draft to make it even more simple.  Expect doc by next IETF.
	VIII.	FIB Aggregation Work: Zartash Uzmi
	A.	draft-uzmi-smalta-01
	B.	1st introduced in IETF 76 in draft-zhang-fib-aggregation: Levels 1 - 4 of aggregation.
	C.	SMALTA presented @ IETF 78, which is better (near optimal)
	D.	Changes since IETF 78
	1.	Evaluation based on data from real ISP has been completed, which lead to refinement of SMALTA
	2.	In progress: consolidation of draft-zhang-fib-aggregations with this draft
	E.	Evaluation of SMALTA
	1.	Original evaluation was using data sets from:
	a)	routeviews (12/2001 to 12/2010)
	b)	Various routers from a Tier-1 ISP
	2.	Main finding was savings of 35% and up to 75% in FIB space
	3.	Fewer aggregation opportunities with more next-hops
	4.	Draft hasnÕt been fully updated with this results and need to consolidate these two drafts, as well.
	F.	Comments/Questions?
	1.	Wes George: One of the problems with higher levels of FIB aggregation was a trade-off between efficiency of (optimal) aggregation vs. overlapping routes.
	2.	Zartash: largest trade-off is you have to apply snapshot algorithm in order to bring the FIB table back to itÕs most optimal state, but the ÒcostÓ of running the snapshot algorithm is not CPU intensive.
	3.	Wes: Is that computation time?
	4.	Zartash: Computation time.
	5.	Wes: Is that written in a way to parallelize it?
	6.	Zartash: Not right now, but could look into it further.
	7.	Wes: Most router HW is moving toward parallelization, so if there is a way to increase your parallelization that would be great.
	8.	Wes: Original question re: aggregation vs. overlapping routes.
	9.	Zartash: In terms of Level 1 & 2 routes, the addition here is (minor) incremental updates to FIB aggregation table compared to before.
	10.	Rudegir Volk: Some of us are willing to throw a little more memory at the FIB in order to improve convergence.  Has anyone looked at this + IPFRR?
	11.	Zartash: I donÕt have an answer to that question.
	12.	Rob Raszuk: FIB compression helps fast connectivity, because you have less prefixes that you need to protect/restore connectivity to.
	13.	John Scudder: Assumption is that you can compress anything that has the same next-hop.  But, if you have 10 routes with 10 different next-hopÕs, then you wonÕt get any gain.
	14.	Zartash: if you want, you can exclude certain prefixes from being optimally compressed with SMALTA.  Just run them through normal RIB to FIB update process like today.
	15.	???: Not sure how valid that point (IPFRR) is, because many primary & backup paths share the same next-hop.
	16.	Rob Raszuk: Another flavor to consider is multipath.  Something else to consider.
	17.	David Fredman: In multipath situation, it wouldnÕt be useful to recommend a different next-hop for primary vs. backup path.
	18.	Rob Raszuk: It might be useful to have diff. next-hops, because people want to load-share.
	19.	Chris Morrow: Concerned that it only looks at one part of the problem.  Only concentrates on looking at optimizing the FIB in HW, but trade-off is the number of updates being made from RIB to FIB.  And, concern is that speed of RIB to FIB update hasnÕt improved dramatically.  Another concern is that desktop HW isnÕt an accurate representation of CPU in routers today.
	20.	Zartash: Your concern is only applicable to snapshot, but that only needs to get run every few hours.  Incremental updates can always get incorporated very easily with no addtÕl CPU.
	21.	Chris Morrow: snapshot is just a regrooming of the FIB within the HW.
	22.	John Scudder: This is good work. Is there anyway you can provide any guarantees on the amount of compression you can get so that it gives HW vendors more comfort with moving forward to implement this? 
	23.	Zartash: Answer is it depends on prefix-distribution, prefix-lengths & next-hops.  Best thing we can do is to take a look within each SP, or more SPÕs, to develop better guidelines on ranges of improvement we can observe.
	24.	Wes George: IÕm not looking for a guarantee, particularly when it comes to optimization.  Thing you need to show is incremental benefit vs. associated overhead.  We know it will have benefits, but we also know this will redraw the curve in terms of memory + CPU.  As long as that curve stays somewhat deterministic and we can capacity plan against it, then IÕm OK with that.
	25.	Zartash: There is less than one FIB update per recvÕd RIB update, so overall increase shouldnÕt be that bad.
	26.	Chairs to Zartash: Next Steps?
	27.	Zartash: After drafts are consolidated, weÕll send out an update and ask to make it a WG doc.