Interdomain Routing (IDR) WG MONDAY, July 26, 2010 0900-1130 Morning Session I 0.9 Athens ===================================================== CHAIR(s): Susan Hares John Scudder Scribe(s): The chairs. AGENDA o Administrivia 10 minutes Chairs - Note Well - Scribe - Blue Sheets - Document Status o draft-varlashkin-idr-multisession-same-port-00 10 minutes Ilya Varlashkin o draft-raszuk-wide-bgp-communities-00 15 minutes Robert Raszuk o Avoiding Transient Loops when using BGP Best External 15 minutes draft-xu-idr-best-external-loop-avoidance-00 Xu Xiaohu o Subcodes for BGP Finite State Machine Error 10 minutes draft-dong-idr-fsm-subcode-01.txt Jie Dong o Constrained Route Distribution for BGP based VPNs 10 minutes draft-dong-idr-vpn-route-constrain-00.txt Jie Dong o BGP Add-Paths Analysis and Guidelines 10 minutes draft-uttaro-idr-add-paths-guidelines Pierre Francois Audio: http://www.ietf.org/audio/ietf78/ietf78-ch5-mon-am.mp3 draft-varlashkin-idr-multisession-same-port-00 ---------------------------------------------- John Scudder: We can get rid of the dynamic ports in the WG drafts. John: We are adding a distinct capability. I’m ok adding a signaling for this capability. I would be interested in a discussion on the list on the mechanism to add the capability. John: In your draft and my draft, there is a more complicated set. In your draft, you want to reuse the MP-capability. In the WG draft, it uses an arbitrary it uses a general capability. As an author, I’m happy to work through discussing a joint draft. draft-raszuk-wide-bgp-communities-00 ------------------------------------ Consensus: Split into base wide-byte community, registered functionalities can be placed into second document. [Q/A during slide 6] Aleksi Suhonen: why use source AS as the parameter on slide 6? Robert Raszuk: easy to use source to identify who is the owner of the given community Aleksi: but these are all source originated anyway, so isn't it redundant to list the source AS explicitly? Robert: this follows the same model as existing communities, there is plenty of additional space Chris Morrow: but what if the customer is already using that community for something else? This will step on that use. Robert Raszuk: This will not occur, because this is a new wide encoding from a different namespace. Aleksi: but since these are essentially well-known, why do we need to qualify them with an AS? functionally they are like well-known. they don't seem to be source address specific. John Scudder: 0xffff does make the community canonical and avoids conflicts Aleksi: well not quite because you can send two conflicting well knowns too. Of course, using the route-map you can clean this. Chris Morrow: We had this long discussion about well-known or source-specific. Will these communities transit between ASes? Robert: Between the customers, I would see that some of the communities would transit multiple ASes. Chris: Many ISPs strip on inbound and outbound. The communities may not go beyond the hop. Robert: I do not limit the number of hops between these places. Aleksi: From implementation perspective if you have source AS instead of 0xffff you have a larger number space to match against (four billion vs. just one). Also with regard to Chris's point, it would be desirable to never strip for debug purposes so that communities show up at looking glasses. Also one would like communities to propagate across tier-2 to tier-1. Robert: I would envision the source AS would be used in the match route criteria or the rest. [Slide presentation concludes] Danny MacPherson: RFC 1998 uses receiving AS, not source AS. Robert: The source address is just the marking of who created the community. Danny: a nice capability would be the ability to see who added a given element to the AS_Path. Ruediger Volk: happy to see work on getting 4-byte, that is obviously needed. Not sure all my requirements are met. I would certainly suggest splitting format work which should be noncontroversial, from standardized/registered functionalities since that seems like it could be more contentious. I'm worried about some of the proposed functionalities. I think there is value to it but it's more complicated and rings many alarms when I look through it. A lot of discussion is needed there. In particular should I really be joyful when my vendor says "we will implement more complicated stuff and that will get you out of the business of writing your own policy"? Your policy language is already a pain in some part of my body, do I really want a whole new pile of code to debug for rarely used functions? I remember even in discussion of NO_PEER that the intention was to let users code it in policy rather than hard coding it. One other comment: there ARE NO two byte ASes. There are only four byte ASes, some have zeroes in the top bytes. Robert: let's put the noncontroversial ones in the base doc John: problem is everyone may have a different view of what is controversial. Sue Hares: agree with Ruediger about splitting. Also saw a lot of debate at nanog. Robert: Agree to split. Andrew Lange: how about flexibile communities, did you look at that? Robert: Don't think we really need that much flexibility. Andrew: Easier to be explicit than shoehorn it into multiple communities. Anyway, let's take it off line, we seem to be trying to solve the same problem. Aleksi: I was advocating this kind of thing back in the 90s but I can see one reason against it. There are still transit operators who are still baffled by very basic aspects of BGP. If a software upgrade suddenly starts making new functionality appear that is a problem. Robert: default the functionality off. Aleksi: consider prepend and drop -- they have a count parameter embedded in the bottom nibble. In the real internet we have seen 256 prepends. Ruediger: that was a fat finger or really, bug. Aleksi: I hope general consensus is that after 4-5 prepends it's pointless. Maybe AS path range should be larger, and prepend range shorter. Robert: Good point. Warren Kumari: I don't think it's realistic to expect providers to ever transit communities. Robert: it depends on how far. Warren: provider-to-provider, not gonna happen. Many of the things you're asking for can already be done with existing communities. Would be more useful to just standardize a best practice for existing communities. Doesn't seem like IETF work. Robert: Yes, this is just a way of getting IANA to register the best practice. Warren: You are also sneaking in a lot of other features. Robert: That's why we need to split it. Jeff Tantsura: Do you expect customers to change their existing policy frameworks to accommodate your new scheme? Robert: This is additional functionality, not a replacement. If you need the new encoding, you can use it. Jeff: Security is hard, more attention needed to considerations Robert: Yes, agreed plan of action: - break into two halves, four-byte and functionalities - once broken into halves, can consider WG adoption Jeff Haas: Thing that killed flex comms wasn't encoding issues, it was operators weren't interested in having super fancy policies imposed remotely. Regarding four-byte, I'm a co-author on l3vpn four-byte draft, might be a useful base John: Please send reference to l3vpn draft to list Eric Gray: would base doc establish IANA registry? Robert: yes I think so. draft-xu-idr-best-external-loop-avoidance-00 -------------------------------------------- Robert Raszuk: you're proposing to use 3107 for Internet routes, right? forget vpn, you mean we would use 3107 just for best external but not primary routes? so how do you protect 3107 itself from this problem? we can take it to the list. Second q, some implementations use safi 1/1 and 1/4 totally independent. how do you make that work? John Scudder: would you use 3107 for all internet routes or just for best external? Xu Xiaohu: just best external Robert: different ribs for 1/1 and 1/4. Also, sometimes best external is used for load balancing. this draft neglects that. Xu: only thinking about backup Robert: basically I think backups in a different aft/safi is broken. Xu: backup is just a demonstration Robert: best external has similar issues to add-paths and diverse-paths. we should have a common approach. Xu: this approach can also be used for add-paths q: but then again you have to do 1/1 and 1/4 separately Aleksi Suhonen: problem stated in draft is inherent to bellman-ford, no routing protocol based on bellman-ford will totally eradicate it. not sure there is any value in "almost" fixing the problem. There are also tons of operators that don't want any MPLS, so a solution that relies on MPLS is incomplete. Xu: regardless of bellman-ford point, point fix that improves things seems useful even if not totally complete. Regarding MPLS, I think it's pretty common Aleksi: I disagree. Keyur Patel: I think the problem statement is right but needs to cover add-path and diverse-path as well. If we seek a solution it needs to be much more generic. John Scudder: WG adoption has been requested. quite a few have read, no support in room for adoption -- take to list. draft-dong-idr-fsm-subcode-01 ----------------------------- Aleksi Suhonen: I think this is very valuable. needs some editing but support adoption. John Scudder: WG adoption has been requested. Poll of the room – who has read this draft (~10-15) How many people support – [~10] How many oppose [few or none] ... some support, no opposition. adoption requested on list. will do two-week call. please remember to email if you support. draft-dong-idr-vpn-route-constrain-00.txt ----------------------------------------- Ilya Varlashkin: you propose to use same RT for both v4 and v6 vpn. how can that be aligned with implementations? RT is generally specific to address space. Why does using same RT make a difference? You still have to advertise different AFs as different update messages anyway, how does this help? For example, suppose I have two sites with both v4 and v6 enabled, what's the advantage of using same RT? Jie Dong: It's possible to use the same RT, right? Ilya: yes Jie: this is an optimization for those cases. Robert Raszuk: there's no harm since the v4-only site won't even advertise v6 support in its session so it won't receive v6 routes. Jie: (didn't get) Robert: requirement of draft can be met easily by simply configuring different RT values. You argue some customers don't want to do that. Such customers are just getting what they're asking for. Jie: a lot of SPs may require same RT. John Scudder: they should say so on the list Keyur Patel: speaking as co author of RT Constraint, we looked at this way back and never had requirements from SP community. In fact if you're going to configure VRFs for multiple AFs you'll probably have similar tagging for those VRFs. Provider feedback would help. Feedback to list requested. draft-uttaro-idr-add-paths-guidelines ------------------------------------- Note -02 version of draft exists but not on iETF servers yet. -02 includes discussion about forwarding loops (relates to earlier xu presentation). Will propose a mandatory selection mode so interested parties should review. Keyur Patel: Problem statement is generic to BGP. We are working on a similar solution, we should merge Pierre: Once -02 is published, will ask for WG adoption. Currently proposed status is informational. Show of hands for interest in the work... lots of hands