IntArea WG Agenda IETF 98 - Chicago 13:00-14:30 Tuesday Afternoon session I, Room Zurich D Chairs: Juan Carlos Zuniga (SIGFOX) - (JCZ) Wassim Haddad (Ericsson) - (WH) Minutes taken by Ian Farrer 1. Agenda Bashing, WG & Document Status, Announcements (Chairs) 5 minutes Francis Dupont (FD) - I have a concern over IPv10 presentation. i think it gives the wrong message to the community. JCZ - We want to give them a chance to have their say and have the discussion. Suresh Krishnan (SK) - Fair point. This has been hanging around a number of workgroups. The idea is to give a chance to explain what it is. From the draft it doens't look like there is. 2. IEEE 802.1 liaison about "IP over intentionally partially partitioned links" Glenn Parsons (GP) and Erik Nordmark 10 minutes draft-nordmark-intarea-ippl-05 Lorenzo Colitti (LC) - I think there shouldn't be any conflict here. The document recommeds how IPv4 and Ipv6 should be made to work on this type of network, which the IETF should define. GP - Yes LC - So it should be OK to have the MUSTs and SHOULDs GP - We saw that as being constraints on 802.1q bridges. We're looking at how to clarrify that. EN - There are two MUSTs that are the problem here. Part of the challenge was mapping what industry uses to the appendix in the 802.1q spec and the clauses in the normative part of the doc. Are we free to do that? GP - That was the idea from the proposal. This liason approved the text. It is the veiw of the committee. ONe of whom is coming to the mike now: Norman Finn (NF) - The intent was that if you put on the right rose colored glasses, we have an appendix in the liason which tells you how to do what you want to do. If you find it helpful, then use it. We'd be the right guys to reference. EN - Referenced as an individul? NF - Yes GP - It would also be useful to reference the comittee. JCZ - We will look to adopt and progress it. 3. Extended Ping, Ron Bonica 10 minutes draft-bonica-intarea-eping-04 (Query by IPv6 link local slide) Bob Hinden (BH) - There may be multilple interfaces that have that link local address. RB - You would get an error saying there's a conflict, I need more information. BH - Or you could bring back info for both. RB - We thought about that but thought there might be security considerations with that. BH - There maybe people that say you are well over that line already. Eric Osborne (EO- I can see different response codes from different verdors. SK - I've seen Packet Too Bigs getting filtered. What are the chances of this actually making it on the Internet? Also, I would like to see this run by an Ops group RB - OK I'll run it by them As for filtering, there is nothing to lose by forwarding it. It should be blocked by the destination host. SK - I would like to see that in the doc. Eric Vynke (EV) - What if you send a multicast address - what is the expected behaviour? RB - We had some different views in different versions of the draft. In one version we prohibited it. later we thoguht it should work as well as pinging a multicast address does now EV - I see advanage to replying once. I'm not against Multicast. EN - I could use this to send to all routers to see who has that address RB - You could make the dest. a multicast and a link local the target EN - You could put other extenstions in there. Does the draft need to say something about those? Meetcho - Is there a scenario for IPv4 to (inaudible) JCZ - You need get in the meetcho meeting line queue EN - Could the target and the destination be in address families RB - Absolutely. It's perfectly legal and one of the use cases. JCZ - It's coming up for adoption. Who has read the draft? c. 5 people Hum for adoption sumpport medium Hum for no support Silence 5. GUE and Extensions, Tom Hebert (TH) 5 minutes draft-ietf-intarea-gue-01 draft-herbert-gue-extensions-01 draft-herbert-nvo3-ila-04 LC - One thing about ILA in its basic format it deals in /128s. It relies on the mobility of individual addresses. It should say that it is not recommended for assignng addresses to individual hosts. TH - We said that it's not for the general case SK - This works fine in the DC where things are really cont.rolled. I'm looking for some guidance from you on how much work is involved. If it's one off then it belongs in INTAREA. If it's more, then it doesn't belong here. There's been no discussion on it for 5 months. TH - There's been discussion in a lot of other contexts. There is a larger context than just the data plane. SK - We did GRE here. I want ot make the differentiation for GUE and ILA. I want a better idea of whether it's here or if it's a BOF. TH - We talked about that. I'm not sure it needs its own working group. I'd like to restrict it to being data plane, but we need a control plane. Running on the Internet is very possible, as it's IPv6. Should I take it up on the list? SK - Yes JCZ - Raise your hands if you've read the draft. 'A handful' JCZ - We'll continue discussion and do a call on the list. 6. Multicast over IEEE 802 Wireless, Juan Carlos Zuniga 5 minutes draft-perkins-intarea-multicast-ieee802-02 JCZ - draft reworked to highlight multicast issues and solutions defined at IEEE802, IETF and some operational solutions. Calling for comments and contributions. End goal is to give recommendations to developers and system administrators. No comments from the group. 7. 802.11 multicast testbed and results, Carlos Bernardos (CB) 10 minutes (no draft) JCZ - You said this is ongoing work and the plan is to test more CB - You can use the test data to show some of the problems in the draft. With the legacy, here are the problems. We are open to do more. JC - Is the test best isolated? CB - We can put any kind of traffic there JCZ - It's still a test bed, isolated CB - It's a test bed, isolated, but you do get interference for LC - Did you test small packets, v6 control: NS, RA? CB - These focus on video packets. These requests are the the ones we are interested in. If you want, we can test these. LC - The control traffic is more spiky and small. CB - The idea is to have a famework to test these things. Dave Thaler (DT) - I think the draft should also point out wierd implementaiton with AFIs and thus interface with the appli That's 802.11 specific, this draft seems as good a point as any to point this out. 8. Proposals to discover Provisioning Domains, Eric Vyncke (EV) 10 minutes draft-bruneau-intarea-provisioning-domains-00 (Bootstrap PVD slide) Erik Klien (EK) - Insted of saying that it only applies to the PIO, it should apploy to everything in the RA EV - Yes it's better defined in the draft than on the slides. SK - We've been thorugh this. Why is this different? There's going to be RIO options in the future. If you have a tightly scoped small set of things. For a broader scope it's more difficult EV - The mechanism is simple. The string is extensible. There doesn't need to be more TLVs. I'm offering you this information, if you take it it's up to you. SK - ...then you add secuirty, you need trust. You add more. That's the slope that you go down EV - We need to find the right balance. I have more on this. Mark Townsley (MT) - Why is it different this time? Two of the reasons are standing at the mike now (points to TP and LC). The host vendors are standing interested. It's serious this time round. Enterprise networks are pushing us for IPv6 only. I think this is a predicate for IPv6 taking off. Tommy Pauly (TP) - I agree with all of that. There's more of this multiple PVS stuff going on. There's more cases where there's two uplinks. I get that everyone wants to put their pony into RAs. The point is you have multiple PVDs that you want to know about explictly. Tim Chown (TC) - I agree with Mark that the time is now. MIF had feature creep. LC - To SK's point. That optional information has got to go. We had a discussion about it. To me, it's important that the information that's given at the earliest time tells you what you need. You don't want a provisioning race condition. We need to limit it to the smallest information possible. We need to limit it to 'these are PVD specific and these are not'. I think we fix these issues. I think there was an issue with putting it into DHCPv4, but that's not an issue here. EN - I know that people have done stuff with different interfaces on phones. What's the impact of this on other devices? Will every device have to know this? Where does it lead us on the application side? Will all apps have to know this? EV - Then you're back to MIF EK - I had a MIF userspace API document. I could bring that back here. Christian Huitema (CH) - You can cite the phone example. There is not the same kind of user for another network. Wheen I move to another network, that network will be multihomed too. On this network do this, on this network do that. The user having to use that information is unrealistic. EV - We thought about it. There's something in the draft. SK - I think you should continue discussion on the list. I don't think it's ready for adoption. I don't want INTAREA to become MIF. It needs more discussion. EN - I would suggest that you go to the apps area earlier rather than late. You don't want to turn up in 3 years and surprise them. EV - It's a good point. 4. IP Tunnels in the Internet Architecture, Mark Townsley (MT) 10 minutes draft-ietf-intarea-tunnels-04 JCZ - Please ask the 'BCP or not' question on the m/l MT - It's been asked JCZ - Please respond! 9.IPv10, Khaled Omar (KO) 5 minutes draft-omar-ipv10-00 FD - IPv6 was 1995, not 1998! Presentation cut short due to problem with video conference 10.DHCPv6 Options for Discovery NAT64 Prefixes, Jordi Palet (JP) 5 minutes draft-li-intarea-nat64-prefix-dhcp-option-00 David Schinazi (D - It's in RFC7050 it uses DNS. Why another one? JP - If you have different IPv4 destinations that use different NAT 64s, then you need it. DS - Who's deploying this? What's the goal? JP - Different IPv4 destinations. LC - You can use IP routing to do that. JP - This is how we do it in DHCPv6. TP - I'm having trouble with the use case. If we wanted the host ot know about different gateways, then this is PVS. Just adding to DHCP, I don't know how that's going to be useful. DS - To answer your point 'this is DHCPv6, this is how we do everything'. No it's not. 11. SDN Multicast Overlay, Nabil Bitar (NB) and Dave Qi (DQ) 10 minutes draft-qi-bitar-intarea-software-defined-multicast-overlay-00 DQ - We are solicting feedback for the draft We want to add more content Lastly, we want to find out if it's an interesting topic to work on. 12.Multiple Access Management, Hannu Flinck 5 minutes draft-zhu-intarea-mams-control-protocol-00 Presentation not given due to lack of time.