IETF 78 - TRILL Working Group Minutes ---- -- ----- ------- ----- ------- Chairs: Erik Nordmark, Donald Eastlake 3rd The TRILL Working Group met Tuesday, 1300-1500 hours, in Room 0.4 Brussels. Minutes were taken by Jukka Manner and T. Sridhar who are thanked for volunteering. Those minutes were merged and edited by the chairs. The "Notes" in square brackets below were added during editing of the minutes. ============ Administrativia (scribes etc), Agenda Bashing, Chairs Erik chaired the meeting, Donald couldn't make it. There were no suggested changes to the Agenda. ============ Review of Existing Milestones, Document Status, and Non-IETF Code Point Allocations Erik Nordmark presented a slide set on the goals and milestones. Main points: - Only active topic on current milestone list is actually rechartering or shut down the WG, shown as occurring in July 2010. - Problem statement now RFC 5556 - Base protocol approved and in RFC Editor queue but blocked on the ISIS TRILL draft - Ethertypes and multicast address block have been allocated by IEEE: 0x22F3 - Ethertype for TRILL, 0x22F4 - Ethertype for L2-IS-IS - NLPID (Network Layer Protocol ID) allocated for TRILL, 0xC0 - Other Working Group drafts: VLAN Mapping draft needs update based on mailing list comments Initial version of a MIB exists Initial draft on options exists TRILL over PPP document at version 01 (in PPPEXT WG) Individual draft on IS-IS extensions for layer 2 systems exists, to be posted as an ISIS WG draft after Maastricht - Recommended that the group attend the IS-IS WG at 5PM today ============ ARP for Large Data Center Problem Statement Linda Dunbar, Sue Hares draft-dunbar-arp-for-large-dc-problem-statement-00.txt Edge Rbridge will have some ports facing end stations (virtual hosts) with Ethernet links. Key problem is the introduction of virtual hosts that will increase the amount of ARP. There will be a Bar BoF on this topic Thursday 29July 11:30 AM to 1PM - Questions / Comments after presentation: Joe Touch, Question: Which of the different problems in the thematic area you are talking about? Linda Dunbar, Answer: Target areas include data centers and cloud computing, IaaS (Infrastructure as a Service). Joe Touch, Question: Routers are used to solve this problem (i.e. Layer 3 solutions)? Why wasn't that considered? Linda Dunbar, Answer: When you move around, IP address should not change. This is a requirement with many customers. Same for VMotion. Joe Touch, Comment: There is a well-known problem with ARP caches. When you read an ARP cache entry, the ARP timer is updated. When you move the destination, the ARP cache is can stay "current" if the source continues to send traffic using the same ARP mapping. Joe Touch, Comment: Remember the TRILL charter does not consider very big networks. Erik Nordmark, TRILL WG Co-Chair, Response: The existing charter references an early draft of Radia's that includes ARP/ND optimization. The new charter is with the IESG and it includes a work item on ARP/ND. Puneet Agarwal, Question: Is the charter going to be updated to include solving issues related to large networks? Erik Nordmark, Answer: That could be considered. [ Note: The TRILL Charter is silent on network size. RFC 5556, "TRILL Problem and Applicability Statement", contains the following text at the top of page 9: "Solutions to TRILL need not support deployment of larger scales of Ethernet link subnets than current broadcast domains can support (e.g., around 1,000 end-hosts in a single bridged LAN of 100 bridges, or 100,000 end-hosts inside 1,000 VLANs served by 10,000 bridges)". ] ============ TRILL ARP/ND Optimization, Radia Perlman ARP/ND optimization was originally in the TRILL specification but was taken out to make progress on other items. So it is time to revisit it. Don Eastlake has compiled the issues and will be posting a new draft based on material on ARP/ND optimization from the earlier TRILL drafts. TRILL is Layer 2.5 - which is a natural place for ARP/ND which operates in a layer 2 cloud. With smart components inside the cloud and no modification of IP node behavior, we can cut down traffic in the cloud. - Questions / Comments after presentation: Joe Touch, Comment: The term "Proxy ARP" should not be used since proxies forward a query as is off the subnet - instead we should call it "cached responses". I would call TRILL Layer 1.9, since it operates under Layer 2. Radia Perlman, Response: I mostly agree on terminology. However, TRILL operates above Layer 2 (instead of STP) so it is Layer 2.5. By your reasoning IP routers would by Layer 1.9 but most people say they are Layer 3. Joe Touch, Comment: I'm worried about the interactions between ARP and ESADI and about corner cases. For example, cases where interfaces have the same IP address but different MAC addresses. I worry about debugging implications as well as those on robustness and security Radia Perlman, Reponse: These issues need to be taken into account and any specification needs to be clear about corner cases. Ralph Droms, TRILL WG Area Director, Question: Everyone is talking about ARP, is there no discussion of ND? [ Note: ND = Neighbor Discovery, the IPv6 equivalent of IPv4 ARP. ] Radia Perlman, Answer: There has been consideration of ND, it's just easier to use "ARP" when talking about this instead of always saying "ARP slash ND". Ralph Droms, Question: I have concerns about some of the same issues as Joe Touch. Does this accommodate multiple Virtual Machines on a single port? Radia Perlman, Answer: No problem, TRILL doesn't care. Erik Nordmark, TRILL WG Co-Chair, Question: Secure ND needs the packet to go end-to-end because of nonces that have to match etc., so in that case shouldn't you have the packet go all the way to the end host? Radia Perlman, Answer: Yes, but even in that case, unicasting the packet to the destination Rbridge is more efficient. Richard Scheffenegger, Comment: RFC 2643 actually already describes similar functionality, that is, optimizations of broadcasting. ============ Requirements for multicast to unicast optimization in TRILL Yizhou Li, draft-liyz-trill-reqs-mlt2uni-opt-00.txt TRILL enables larger L2 networks and therefore broadcasting will become an issue. DHCP, ARP/ND and ARP cases discussed. Eric Nordmark, TRILL WG Co-Chair, Comment: You need to check the ARP Probe and Advertisement RFC to handle ARP conflicts. Yizhou Li, Response: Should have inserted a reference to that here... Though this RFC exists, it is not popular for implementations. [ Note: The RFC referred to is RFC 5227, "IPv4 Address Conflict Detection". ] Joe Touch, Comment: None of these optimizations will help. - Questions / Comments after the presentation: Joe Touch, Question: I can't understand why DHCP would cause a load problem. There are mechanisms that send packets directly to a port instead of broadcasting it. ARP would be a load, but DHCP happens once a day? Yizhou Li, Response: Broadband (DSLAM) broadcasts DHCP responses to all hosts. Ralph Droms TRILL WG Area Director, Comment: You need to talk to the DHC WG if you are looking at DHC optimization. I believe you are duplicating a Layer 2 relay agent. Radia Perlman, Comment: I like the idea of configuring DHCP servers at Rbridges and forwarding to specific servers. Ralph Droms, Comment: You need to be careful because there are deployments that introduce DHCP fail-over that makes use of DHCP broadcasts. Layer 2 relay agent unicasting to a single DHCP server would be a problem since there are implementations that need to broadcast or serially unicast to multiple DHCP servers. Radia Perlman, Comment: RBridges could broadcast to other servers if they have a DHCP server connected. Erik Nordmark, Comment: You could filter out DHCP replies so that they can only come from certain ports. Radia Perlman, Comment: It would be useful to provide links to the stuff Ralph is talking about on the TRILL mailing list. Ralph Droms, Comment: Yizhou Li should send this proposal (short summary) to the DHC mailing list. Joe Touch, Comment: Large networks and mobility - whatever would work on Layer 2 would work the same on TRILL - there is no commitment that large networks or mobility should work better on TRILL - see the Problem Statement. The way to look at this - does the optimization work on Layer 2 and does it work on TRILL? Erik Nordmark, Comment: We wrote the original charter only looking at MAC addresses and not at optimization. Joe Touch, Comment: IS-IS addresses a part of this using the goals of the original charter. ============ Charter Update Ralph Droms, TRILL WG Area Director: New charter is circulated for review. Some comments received. Will be in on the IESG Telechat of August 12. ============ Meeting Adjourned.