IntArea WG Agenda IETF 103 - Bangkok 15:40-17:10 Wednesday November 7th, Afternoon Session II, Chitlada 3 Chairs: Juan Carlos Zuniga (SIGFOX) (JCZ) Wassim Haddad (Ericsson) (WH) - not present Minutes: Ian Farrer Jabber: Mikael Abrahmsson 1. Agenda Bashing, WG & Document Status Updates (Chairs) 10 minutes 2. Discovering Provisioning Domain Names and Data, Eric Vyncke (EV) draft-ietf-intarea-provisioning-domains-03 Ian Farrer (IF): You can change the rfc3633 ref to 3315bis as this is going to be published soon. 3. IP Fragmentation Considered Harmful, Ron Bonica (RB) draft-ietf-intarea-frag-fragile-02 David Black (DB): In Transport Area WG were working on UDP options. It could be used for fragmenting UDP at the UDP level. In discussion this morning, we were uncertian about the vaule. I sound like this is a reommendation to stop using fragmentation. RB: UDP fragmentation solves my problem DB: I believe it does Mikael Abramahson (MA): I think it does. The problem is not fragmention itself it's that there is not information in every packet. RB: A recommendation to middle box devs to handle this MA: I was looking for a MUST to get middlebox devs, but were not the protocol police. I think this is a reasonable compromise. Fred Baker (FB): I'm not sure UDP frag solves your problmem. You've got TCP fragmentation. It only helps if know what the path MTU is. Suresh Krishnan (SK): We need a way to expose the path mtu to the upper layers. That needs to be specified somewhere. Erik Kline (EK): There's a sentance about it SK: I don't know how that's going to happen. We need to see how this is going to be implemented. You need to handle changes across the paths. I'm happier with the second recommendation than the first one. It's a decision for the Transport Domain if they want to do it. That's what I think. JCZ: You have to care about the application and the developer. RB: It's a variant of Postel's Law - conservative send, liberal receive. EK: 7.4 says be standards compliant. Is it worth saying that operators should set the right MTU on their links? MA: There are ways of seeing this at the moment. It's good for devs to include this. RB: It would be good to have a one liner saying that this interface should exist and define it elsewehere. Corry Fairhurst (CF): -missed- RB: What area should that live in? SK: I think the answer until today has been 'not in the IETF'. We've pushed it POSIX or wherever. I think that DT would say we can write an abstraction for this. Dave Thaler (DT): Where does the discussion belong? TAPS Does the IETF do abstract or concrete? TAPs for abstract. POSIX etc. for concrete. I'm the liason for this. All they are talking about is the boost(?) style APIs at the moment. If there are things we want the community to do then I can post that. CF: There's 2 different sizes of MTU. We need to be careful that network isn't making 1 dicision and transport another and app another. We need an API. RB: We're just saying that we need a solution, not what the solution should be. CF: Be careful what you put in the socket layer. Maybe the application can do this? DB: This just says it happens at a higher layer. RB: I think the action is a recommendation for a new interface, and a sentance from EK. DB: I agree with CF about not refencing UDP fragmentation in the draft 4. GUE update, Tom Herbert (REMOTE) (TH) draft-ietf-intarea-gue-06 draft-ietf-intarea-gue-extensions-05 draft-herbert-intarea-gue-ctrl-messages-00 draft-herbert-tsvwg-gte-00 ** TH's video link dropped shortly into the presentation and wasn't completed or able to respond to the comments ** CF: As TSVWG chair I didn't get why it was being proposed. TSVWG is in the title and this is what TSVWG does. Please talk to us about it. SK: I think we did is say this was a 1 off document. Now there's 4. If it becomes a protocol suite, it doesn't below here. If TSVWG wants to take it.... CF: I wanted to comment on it! Whether we need another encap protocol. We need a BOF etc. SK: If there's a significant amount of work, we need a BOF. this is not the right place for it We can talk off line. 5. Limited Domains and Internet Protocols, Brian Carpenter Presented by Bing Lui (BL) draft-carpenter-limited-domains-04 EV: Maybe I missed the concept of domain, but when I see 'join domain', it could just be my old laptop talking to my new laptop. Or did I miss the meaning of domain? BL: It may be geographic, it may be logical. Thres' two models. In your case it's the network EK: If you have domains next to each other it may be overkill. BL: We need to make the definition more comprehensive. DB: We wrote RFC8085 which defines a 'controlled environment'. It sounds like you're saying when I get away from geographical alignment, you've got an overlay network. For controlled environment, we used common mangemanet & admin, like an AS number as the definition BL: I belive that there is an overlay here. I don't know the controlled environment. Maybe we need an explicit defintion as options or metadata in the protocol. Currently, it's always out of band. DB: I think I agree you need to sort out the overlap between limited domain and controlled environment. I offer to help. EK: This looks like a way to get execptions for things you otherwise wouldn't be allowed to do. Sometimes things jump domains. I don't think I agree philiosophically that this is a good idea. BL: -missed- EK: Not really DB: It doens't have to be both. Exapmles are MPLS over UDP which has to be run separatedly and GRE over UDP. We needed controlled environment to get those done. EK: That sounds like administrate domains DB: Yes, it relies on network admins to know what to do and when things are going wrong. EK: This is a superset of -missed- DB: I agree there's a relastionship. I defer on if it's a superset or subset SK: I think we need more eyeballs on this. It affects a lot of areas. Maybe a BOF? It needs to be looked at. BL: I think that's a good idea. Ruediger Volk (RV): All examples were at low network layers. These can also happen at higher layers. This is a wide field and I don't know it can be controlled. BL: This is based on some fact in the Internet and we need to consider it. RV: Are you giving any examples of what you're concerned about? BL: There are example, but they might not show that there is a trend. I cannot prove that the trend is happening. RV: The hints that I'm hearing are that if you have well structured systems there are infinite ways to break the structure. If one allows people in the wild to do whatever they want, you get trends like this. It's not a trend you want to support. BL: I understand. 6. IPv6-based discovery and association of Virtualization Infrastructure Manager (VIM) and Network Function Virtualization Orchestrator (NFVO), Carlos Jesus Bernardos Cano draft-bernardos-intarea-vim-discovery-00 Not presented 7. User-Plane Protocols for MultipleAccess Management Services (MAMS), Jing Zhu (REMOTE) (JZ) draft-zhu-intarea-mams-user-protocol-06 SK: I'm trying to understand your end goal. The framework doc. has been submitted independently for publication. Where is this is this going? ZK: We want to bring this one into the communiy to define with the convergence layer. DK: My issues is that there is a lot of work to do. This isn't the home for this. Come to me or another AD for a BOF. The scope of this is huge from the framework. Let's talk about the future. ZK: Yes. I want to mention that the convergence layer isn't limited to MAMS. We introduce a new convergence protocol. We want to know how to owrk together with IETF on this. 8. Overlayed Path Segment Forwarding (OPSF) Problem Statement, Yizhou Li (YL) draft-li-tsvwg-overlayed-path-segment-fwding-ps-00 EK: If you name this with an acronym so close to OSPF, it's confusing. YL: We noticed that. 9. SOCKS Protocol Version 6, Vladimir Olteanu (VO) discuss draft-olteanu-intarea-socks-6-05 SK: How do you want to progess it? Here or AD sponsoered? YL I'd like to standardise it. SK: Talk to me.