Very draft IDR minutes, IETF-82 Scribe: John Scudder Time stamps are approximate and Taipei time 9:05 Meeting start 9:08 John: consensus to resume the publication of draft-ietf-idr-deprecate-as-sets as a BCP Danny: please don't forget to do the deprecation step! Chairs: Agreed. 9:15 Sue - Now is the time to provide input regarding error handling! 9:22 Ruediger: Attribute 128 blowup from earlier this year. It seems as though IDR's attention "slipped there a little bit". Looking at attr 128, it turns the linear structure of a bgp update into a recursive data structure. This is a qualitative difference in complexity. I'm not sure this was carefully considered or not. 9:24 Sue: To that, in updating error processing we need to consider interaction with L2VPN, L3VPN. 9:25 Robert: You mentioned BMP. How do you envision BMP being related to this presentation? Sue: It's input from GROW. We're just pointing out that we are paying attention to GROW. Chris Morrow: For BMP, a possible application is to make sure you ship the packet out before you die! 9:26 Robert: Right, this may require an update to BMP. Chris: to Sue's point, let's categorize error types and decide how to properly deal with them. 9:28 Enke, error handling 9:38 John: poll for number of people who have reviewed (lots) 9:39 Alton: Many of these problems come from optional transitive attributes. 9:40 Danny: IAB took away a lesson from the optional transitive experience. 9:41 Alton; I'm not suggesting deprecation. If there is a problem with a mandatory attribute you at least get direct feedback. John: Yes, although clue bats from operators indicates that there is a problem with direct peering too. 9:43 Alton Lo -- Automatic RT filtering for legacy PEs 9:48 John: how many have read it? (some) Danny: I think it was broken that we removed the reflect-back-to-self restriction on route reflectors. This fixes that, right? Alton: Yes, makes sense. This is basically what 4684 already says, just in a tricky way. 9:50 Robert Raszuk: I have ago operational concern. Suppose I have a mixed network where some RRs support this and some don't. Maybe a better long-term approach is support RTC on all PEs. John: comments from network operators please. 9:51 Keyur; Assumption is it will be deployed to all RRs. We assume the RR layer is not mixed. Sue: What happens if you think you've done that, but you haven't. 9:53 Keyur: Configuration. Sue: What happens if your config gets broken, e.g. due to a software rollback. What is the failure mode? Danny: I think this could be a problem because (missed XXX, I think blackholing case due to implicit filtering). 9:55 John: basically, please think about failure modes. 9:55 Bruno, BGP Persistence 10:03 Enke: I think this is best covered in GR with a few knobs or tweaks. My suggestion since GR respin is going on to try to accommodate (some of) these requirements in GR. That would also suggest converting this from a solution document to a requirement document. 10:04 Bruno: That sounds fine to me as long as the requirements are met. [See also Bruno's clarification at http://www.ietf.org/mail-archive/web/idr/current/msg05717.html] 10:05 Enke: Let's consider some of the comparison items on slide 7. The assumption about forwarding path being usable (didn't follow the point XXX). GR not retaining stale path in restart can be fixed by introducing a "minimum stale timer". Third, 68 minute timer, that is NOT the stale path time, that is time to re-establish BGP session. Unless we are talking about static routing 68 minutes is a long time. 10:06 Bruno: reiterates ... but I think the use cases are different. Specifically with respect to de-preferencing stale paths or not. 10:07 Enke: GR by design localizes routing changes (avoid churn). Clearly there is a tradeoff. But, we can provide a configuration knob for that tradeoff. 10:09 John: summarizing, Enke says use persistence draft as requirements, Bruno agrees if those requirements can be met, great, doesn't mandate specific solution. 10:10 Keyur: Regardless of persistence marking, when the session goes down any new updates propagating over that session won't get through. Is it correct to assume that whether the routes are marked persistent or not, any black-holing still remains with the persistence draft? If so, all the marking does is let the rest of the network know that the session has gone down? 10:11 Bruno: agreement 10:12 Robert: I agree with Enke, 90% of these requirements can be addressed by GR. The other 10% is the marking part. Bruno: Currently ARE NOT addressed, but COULD BE, agreed. Robert: last 10% is about marking. Maybe we could use cost community within the domain. External to domain, this maybe is Yet Another way of influencing best path. John: comes down to requirements. If we agree on the path selection requirement, let us then consider what tools are best to address it. 10:14 Sue: (missed) Ilya: Along the best path selection topic, what happens if you have two RRs and the session to one of them dies, then primary attachment session dies? Is the backup route from the rest of the network every instantiated? (back to slide 5) 10:16 John: double-fault case. 10:17 Bruno: (missed) 10:18 John (as individual): stale routes are least preferred Ilya: OK that would work but I don't see it in the draft. 10:18 Jie Dong, MTU Sue: call for adoption to list 10:21 Hannes 10:26 We have clarified with PCE WG chairs (JP) that he is fine with this. Major change is we have actually started implementation which has provided insight! 10:32 Sue: has it been reviewed by PCE? Hannes: they're good with it (PCE co-chair): I know you discussed with JP and I agree, but the WG as such has not assessed. John: can you poll your WG? (PCE co-chair): Will do on Thursday. 10:34 Robert: (missed) Hannes: We use this as a sync mechanism to sync TE dbs. (more, missed) 10:35 huaimo from Huawei: (missed, something about overlap) 10:36 Hannes: for OSPF you might be right although the majority of TLVs have area-wide scope. Same for IS-IS. We also want to address increasing deployment of architectures like Seamless MPLS where we have several disjoint IGP topos but PCEs need to compute e2e LSPs. 10:37 Huaimo: Some providers may not want to distribute entire topo outside. Have you considered that? Hannes: Any sane implementation wouldn't disclose the full internal topology to the outside world. First, this is an optional extension. Second, the draft does consider aggregation for exactly this reason. It is under control of operator policy. 10:39 Ilya: You mentioned inter-AS option C. I didn't find anything about that in the draft. Can it also be used with option B? Hannes: Yes, it's not limited. Ed Crabbe from Google: I support this, (missed). Also, this isn't THE state distribution mechanism, it's ONE mechanism, others could be introduced. 10:40 Sue: Clarification, if you don't want to distribute full information but don't want to use summarization, is there some way it works? Hannes: Maybe we should add that this has to be explicitly enabled. You're worried about security implications? Sue: That too. But if you just want to distribute a subset of the db, does this still work out? Hannes: Yes, as long as you advertise a contiguous path. (agreement) Hannes: this is totally in-scope. 10:42 Stefano: I think this is very important and is one of the motivations for the draft. One reason for choosing BGP is to have policy. (Hannes agrees.) 10:43 Huaimo: (something about scalability issues) Hannes: Largest SPs in world have ASes with 6-8k links, so 6-8k entries in RIB. Ed Crabbe: This isn't targeted for wide scale distribution of state. 10:44 Jie: Does ALTO server need to peer with every BGP speaker? Just one? Hannes: I mentioned previously that BGP was "victimized". There is no single answer to your question. Jan Medved: In short, peer with one BGP speaker. 10:45 Jie: Any scalability issues? Hannes: No. 10:46 Ruediger: Yes, number of entries is low, dynamics might be high. Need clarification for whether this data needs to be in-band with other BGP, or can it use a different instance of BGP? Hannes: This comes down to implementation. Flying carpet. Sue: Might be worth touching on this to address scaling. 10:47 Ilya: You could use BGP Multisession. Hannes: Probably ruediger wants it in a different routing daemon. Jan M: It could easily be deployed in a whole separate RR infrastructure. There is no requirement to do it in line with other routing. 10:49 Ilya 10:54 ORR draft is what does custom selection. So this is really the application of three drafts together. 10:56 John: (missed) Lou Berger: You could probably achieve the same thing with add-path and it might be cheaper? Ilya: This gets back to the add-path vs. ORR debate we had before. We did discuss this on the list before. (Summarizes previous discussion, related to number of paths sent and lack of optimality arising from that.) (Discussion of chattiness. Ilya asserts it's not too chatty.) Lou: This reflects a tradeoff of computational complexity on RR. 11:00 John: please review ORR adoption debate George Swallow: As chair of other WG, just because you're a WG draft doesn't guarantee you will be an RFC! Also, as point of clarification isn't this as chatty as your IGP is? Ilya: Basically, yes. George: That's a heavy impulse load on the network. Also, note number of INSTALLED prefix is the issue for routers, number of control plane prefixes isn't a big deal. Ilya: IMO even in a fairly large network the universe of next hops will probably be in the hundreds. 11:02 Jacob Heitz: The router is busiest at startup time. On startup this proposal is a problem since the RR may have to revise its opinion based on NH info it learns. Ilya: You can extract /32's from IGP (converges fast) and proactively ask RR-clients about costs to those Jacob: Also, a router may have a labeled path to a next hop and an IP path to a next hop. They may have different costs. How is the router supposed to know what the relevant cost to provide is? Ilya: Basically it is the cost you will use for forwarding. We can talk about it further on the list. 11:04 Sue: In the past various drafts have covered identifying different next hops based on safi, etc. Look at past history. Robert: To address George's point. This is no more chatty than the TE proposal. You can threshold your changes. 11:05 Sue: Path selection is an upcoming work item for the WG. This kind of work will get prioritized when we get to that one. There are 500-600 academic documents on this topic alone.