Intarea Meeting ** Draft ** Minutes 5/11/15 IETF94 - Yokohama Chairs: Suresh Krishnan (SK), Juan-Carlos Zuniga (JCZ) Minute taker - JINMEI, Tatuya - Ian Farrer 1. Agenda Bashing, WG & Document Status (Chairs) 5 minutes Chairs explained document status. Rolf Winter quickly talked about broad and multicast protocol designs. He wants this wg to read and comment on it. Suresh encourages read GRE tunneling mechanism draft. Agenda bashing: no update. 2, Tunnels in the Internet Architecture - Mark Townsley (MT) https://www.ietf.org/proceedings/94/slides/slides-94-intarea-7.pdf 10 minutes draft-ietf-intarea-tunnels-01 MT explains main idea quickly: when and where we need it. wide variety of uses: load balancing: often don't have an idea what's happening inside. tunnels must be designed in such a way when carrying IP, when using IP, this means looking like a network layer and host. Diagram is shown. current status explained: it's a complete revision. current plans include: augment with additional notes, relation to existing RFCs, and clarifications. David Black (DB) I've discussed with Joe. There are many tunnel types. This is about IP in IP There are other tunnel types. in the TSVWG we are working on RFC5405-bis. We are putting in info for carrying stuff in UDP about what to do. I encourage you to read this MT - The doc tries to capture IP over foo. That doesn't mean it tries to include the UDP considerations DB the place that I'm drawing the line when foo is UDP. There are special considerations for UDP. IP checksum Lee Howard (LH) - There's a lot of placeholders still to be written. Who is the audience? MT - Protocol designers. Network operators. LH - It's a long doc without all of the words. There are repetitions. MT - We need to adjust it more Fred Templin (FT) - UDP is only one example of foo MT - The tunnel generics would be here. UDP has specifics DB - This is for IP in IP. Consideration for UDP and when the payload is not IP are in the TAWG draft Lucy Yong (LY) - The tunnel forms a link. Moving forward there might be meta-data for this link We need to think that the link might have more properties MT - links have been around for a long time. They have some properties that they express to the upper layers. This could be extended, but I don't think its' necessary. The document could be extended, but I don't think that it's necessary. SK encouraged people to read the doc. 3, IEEE 802.11 multicast Optimisations - Dan Harkins (DH) https://www.ietf.org/proceedings/94/slides/slides-94-intarea-1.pdf 15 minutes (No Draft) background: multicast performs so bad in wifi. 802.11 packet transmission explained. how multicast affect WLANs. 802.11 multicast properties: lower rater -> larger frame, less airtime for everything else. there are some options to improve it. things we can do to address it are: proxy ARP in 802.11-2012 (IPv6 support exists) Directed Multicast Service (DMS) Groupcast with Retries (GCR) issue: unacceptable latency; ongoing extension to improve performance multicast optimization implementation nothing in the standard to stop an implementer from turning MC to unicast GCR and DMS Erik Nordmark (EN) - I didn't know you had proxy ARP and ND. Does it work with SEND? DH - No. It's not like it's widely implemented, but we want to add feature and that makes is harder DH - I'll make sure that the message gets received EN - What about special types DH - There are special groups the GCR implementation was doing HD video. I don't know anyone selling produces DH - We see networks melting Lorenzo Colliti (LC) - I'm trying to make tradeoffs between uni and multi - in your slides uni is 100 times faster DH - They're exampels If you can do 600, you do 600, multi will be sent out at the slowest MCS LC - Suppose I've got a multi that I want to send to people. How many clients do I need to have before multi before multi becomes a good idea I might as well send 10 unis before multi becomes a good idea What is the efficiency rate for small packets. How is the math different between big and small packets. If there's a long setup time, then multi may be more efficient DH - in todays networks it's sent at the lowest NCS LC - 1500 byte vs 300 how is the math different? Christian Huitame (CH) - They're saying that multicast sucks There might be 2 usage patterns - you send because everyone's going to use it or we send to everyone because we want ot reach somebody. This is the one that suck We should consider this and should we change it DH - if you take anything from this pres. the difference is not 100x. Multi is sent at the slowest reate Mikael Abrahammson (MA) - I went to the IEEE about this. There is a non-WG mailing list. Please join it JCZ - we want to tackle this from IEEE and IETF side. Please join the list SK - we'll send this to the list 4, GRE Tunnel Fragmentation - Fred Templin (FT) https://www.ietf.org/proceedings/94/slides/slides-94-intarea-2.pdf 10 minutes draft-templin-intarea-grefrag Three different ways of fragmentation. each has issues: 1. fragment encapsulation packet 2. fragment encapsulated packet 3. tunnel fragmentation references: RFC2764, 2 internet drafts No comments 5, IP over intentionally partially partitioned links - Erik Nordmark (EN) https://www.ietf.org/proceedings/94/slides/slides-94-intarea-3.pdf why care? => key issue, increased dependency, both IPv4 and IPv6 https://www.ietf.org/proceedings/94/slides/slides-94-intarea-3.pdf an example diagram shown. proxy ARP/ND problems shown. SK - There is an adoption call. It's just finished, but I'll extend it 6, Yang data model for GRE - Guanying Zheng (GZ) https://www.ietf.org/proceedings/94/slides/slides-94-intarea-4.pdf 10 minutes draft-zheng-intarea-gre-yang-00 motivation: define data model for GRE what's in rev00: define YANG model based on RFC2784, 2890, 7676 and 7588. yang model data hierarchy tree: next steps: get comments and seek contributions & collaborations, eventual WG adoption SK - This is here because there' snot a home for it. We need to discuss with the ADs how to go forward with this 7, YANG data model for Tunnels - Ing-Wher Chen (IC) https://www.ietf.org/proceedings/94/slides/slides-94-intarea-5.pdf Two ways to organization data question to the WG: which data organization (separate lists vs 1 single list) comparisons shown about - naming - attribute change GRE tunnel vs IPIPv4 tunnel Dave Thaler (DT) - you may want to look at how the IP tunnel mib works. They alredy have a solution to this. You put generic in one place and try to extend it IC - That was discussed SK - Send a mail to the list and have the discussion on there. 8, IEEE 802.15.llc (Logical Link Control) - Charlie Perkins (CP) https://www.ietf.org/proceedings/94/slides/slides-94-intarea-6.pdf study group meets next week want to discuss goals, get feedback layer diagram shown: IPv4, 6lowpan, etc/New LLC work/802.15.4 MAC/802.15.4 PHY prioritized functionality list shown proposed timeline: meeting next week, January interim, March Plenary within a few years, spec will be published EN - I didn't see fragmentation. I thought taht 15.4 ahs a small frames size CP - there iis already spec for fragmentation. The LLC has this EN - the other thing - when you do IPv6 will that run with 6lopan or will it run directly over the LLC CP - It's not on the slide. I think that this should be a priority Ralf Droms (RD) - Thanks for bringing this Side 1, you said - as easy to use as wifi and ethernet. Does this mean that it will look to IP like wifi and ethernet? CP - No it doesn't. That was an error. We want to have 802.11 RD - Is that explained in more detail. Tehr'es a lot of ways that you could do that Will LLC I could get from an device on that mesh to any other devcie. It's not going through the IP. RD - Where can I find out about that? SK - Do you understand the question? CP - I think I understand the question SK - can you look at the slides and send a pointer to Ralf CP - the longer version of the slides doesn't answer the quetstion. The specific answer to your question, we don't have that information yet, but we do need to provide it.