IDR 2006/11/08 meeting: Taken by John Scudder and Dave Ward. 1. Document status (Yakov): Lots of progress: - GR to RFC editor - Multiprotocol also on RFC editor queue. Needs a little editorial change but nothing substantive. - 6PE -- through IESG LC, IETF LC, approve announcement forthcoming. - 4byte ASNs -- IESG comments to be incorporated. - AS confeds -- revised ID needed, authors to do Real Soon Now. - AS_PATHLIMIT -- early allocation procedures have worked very smoothly. No progress on: - ORF - AS wide unique ID - Avoid Best Path transition - Prefix based ORF 2. AFI and SAFI (Yakov, Bill): Yakov: No IANA procedures for allocating AFIs! Bill Fenner: - IANA needs guidance for what their policy should be for AFI, asked IESG. - Who are stakeholders? Routing for sure, but must be others -- why is AFI 16 == DNS registered? (Bill's guess: MIB.) - If routing is only stakeholder, routing should propose policy. - Other considerations -- scarce? (No, 16 bits.) potential harm from allocation? - Possible policies -- specification req'd + early allocation, or FCFS Discussion: Acee Lindem: Should be some review of AFI, otherwise I could get an Acee Lindem AFI Bill Fenner: Is that harmful though? Yakov: But you can already get a SAFI today... Chandra Appanna: I don't mind FCFS, but how to handle indiscriminate allocations? Bill: FCFS doesn't pretend to, but could break into ranges like other registries, allocate half for FCFS, reserve half for later. Kireeti: Do we have to choose one? Can't we have spaces? Bill: We can have spaces. Kireeti: OK let's, half for FCFS, half for Spec Req'd. Bill: Why? Kireeti: To prevent DoS allocations. Kireeti: Also Spec Req'd code points are shinier and more important looking. Danny McPherson: Talked about this in Paris too, and IESG was asked to make a general guideline about this. In PWE3 we split into three, expert review req'd, FCFS, etc. John: I don't really see a point of having two different allocation policies. If you have FCFS anyway, may as well have only that. Danny: Worry about depletion with FCFS. Challenge was not necessarily an attack but, greedy alloc and potential for depletion. My experience was that FCFS was seen to have the potential for abuse. Bill: If we don't have FCFS, people will just pull numbers from clear blue sky. Yakov: I suggest 1/3 or 1/2 of space reserved, then remainder is some mix of FCFS and maybe Spec Req'd. Bill: OK, let's follow up on list, I'll send a strawman. 3. draft-lefaucheur-idr-v4nlri-v6nh-00.txt (Eric Rosen): For years now we've been playing with different uses for NH of different AF from NLRI. Different deployed examples -- - VPN-IPv4 with IPv4 NH (but with bizarre encoding) - IPv6 AF with IPv4 NH using "IPv4 mapped IPv6 addres" - And so on, e.g. l2vpn, rt-constraint, using length field to distinguish between v4 and v6. - Leaves us with one odd man out: IPv4 NLRI, no way to have v6 NH, no obvious encoding trick to stuff in v6 NH. - Softwire WG has requirement to carry v4 routing over v6-only single stack core -- analogous to "BGP-free core", v4 routing at border routers but not in core. - Implies v4 NLRI with v6 addresses as NH (for tunnels across core). - Straightforward solution is to simply declare that v4 AF can have v6 NH. - Many possible encodings. Current proposal, use length field to distinguish. - Since this isn't interoperable with implementations that don't understand v6 NH, use BGP capability to make sure you don't send such next hops to peers that don't understand them. - Other options considered: - TLV: better solution in general. Slightly more complex encoding. Architecturally "purer". But, we already have hacks for every other option in the matrix of NLRI/NH combinations, so since we just have this one v4/v6 case, might as well do the expedient thing. - New AFI/SAFI for 4/6 case: Operationally more complicated, creates implementation hassles. - Is it even needed? For example, you could have v4-free core by having configured overlay tunnel topology, then run v4 routing protocols over it. - This is a softwire problem, not an IDR problem, softwires is proposing requirements - In general, overlay model seems more painful! Discussion: Yakov: I don't think it's purely a softwire problem. 2547 over IPv6 also needs to be solved -- and your proposal solves it! Eric: Yep, and for the same reason 6PE is useful for softwires. Great! Yakov: What do you want to do with it? Eric: Make it an RFC. Yakov: Oh come on. Eric: Make it a WG doc. Shall we? Yakov: How many have read it? (Show of hands, some.) Of those who've read it, how many would object to making it a WG doc? (~1 hand) Yakov: Eric-Francois to make request to list after posting revision of the draft 4. draft-pmohapat-idr-info-safi-00.txt (Eric Rosen): - Softwire problem requires v4 packets to be tunneled through v6 core and vice-versa. - Of course they should just use MPLS but WG wants to do it the hard way. - So, need to be able to pick an encapsulation. Not only that, but to make it more complex, desire to have various policies for what tunnels are used for what destinations, etc. - At least want to be able to categorize routers into classes, to which tunneling policies can be applied. - Some IP encaps (GRE, L2TPv3) lack appropriate native signalling protocols for multipoint-to-point tunnels. - Hence proposal: New SAFI, "Info-SAFI" (everyone agrees choice of name is poor...) - Carries: - Address of BGP speaker, embedded in NLRI - Characteristics of speaker, as communities - For signalled tunnels, new attribute with signalling info - Allows multiple info-SAFIs per speaker - Obvious alternative: Just use a /32 identifying speaker, attach attributes to that. - Why not? - Route distribution constraints might be different - Don't want trouble with summarization policies - Isn't: - Tunnel-SAFI -- no hidden infrastructure, not naming tunnels, not replacing NH with tunnels - Not "all purpose use BGP to send any random info about anything" scheme Discussion: Chandra: Range of info-SAFIs, or just one? Eric: Just one. In the info-safi there are multiple NRLI's per speaker - good clarification Chandra: Why even bother spec'ing, you could have multiple SAFIs per speaker, what's special about info-SAFI? Eric: Huh? Eric: Oh, what I meant is, there are multiple *NLRI* per speaker within the info-SAFI. Yakov: GRE doesn't have signaling protocol and only need one if you require key. We know GRE works today w/o any of this if key is not used. If you want to mark certain routes to go over GRE tunnel and you want to use a key; what does this proposal buy you vs just carry GRE key with the routes. Eric: I assumed while working this out that we wanted to do it efficiently -- just advertise the BGP speaker's properties ONCE, instead of re-advertising them again and again (once per update). Not clear whether this is the right tradeoff or not -- a little extra complexity for a little extra efficiency. Consider though, that if you change the key or something, you would have to readvertise your whole RIB. Yakov: Good point about L2TPv3. Why not just think of your proposal as just an L2TPv3 signalling protocol for mp2p tunnels? I think that would be fine. If we need it for GRE, get another SAFI. It fits into model we have today for MPLS where we have a distinct AFI/SAFI for setting up mp2p LSPs with BGP. Chandra: I understand that to carry the tunneling info we need a SAFI, but as for attributes of a speaker you exchange them in capabilities. Eric: I'll answer Yakov's question first. It's not clear to me if it's better or worse to have one SAFI for all tunnel signalling, or one for each technology. I'm not sure how to compare them. Yakov: If you do this specific per tunnel encap, you only carry that info. For another you use another. Avoids attr clash and errors. Diff tunneling protocols have different things. Yakov: Regarding Chandra's question, I think "characteristic of BGP speaker" are things we already advertise, and we don't need a info-SAFI! Eric: Problem is desire to divide routers into classes based on, e.g., what kind of tunneling technologies they support. Yakov: That doesn't sound like general characteristics of BGP speakers. That sounds like just characteristics wrt tunnels. Eric: How do you think you're actually going to restrict it? Communities are general things. Once you have an update message, you can put communities in it. Yakov: But the point is, those communities would be embedded in BGP update that carries L2TPv3 tunnel info! Eric: So how do you think you'd signal stuff like tunneling technology preference? Yakov: Color each route with a community. Eric: Seems pretty inefficient when you change an attribute. Eric: So suppose we change the name to tunnel signalling SAFI and leave it the same otherwise? Yakov: That's what it is! Chandra: To carry tunnel info you need a safi but, you say "attributes of a speaker" are those that send in dyn cap at OPEN. So, I am confused Rajiv Asari: I agree with Yakov. Suppose next I want to stick for example compression info out? Yakov: Right, what happens if other end doesn't understand? John Scudder: You can do this with an optional attribute. Yakov: What do you want to do with the doc? Eric: Not ready for WG doc. Chandra: Probably not ready for WG doc. Yakov: Please discuss on mailing list. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr