David, Answers to your comments are inserted below:
From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of David Allan I Sent: Thursday, August 29, 2013 12:53 PM To: int-area@ietf.org Subject: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Hi: I have read this draft and will state I'm not a fan. My issues can be summarized as follows: 1) The first justification example in the motivation section is just plain silly, yet I keep seeing it over and over in IETF discussions. No one would ever design and implement the deployment of any single application that way, let alone all apps attached to every TOR in a cloud. [Linda] The motivation is showing that today's server virtualization and business demand has made applications in one subnet no longer necessarily be placed closely together. They are the same driver for NVo3. If you go to this week's VMWorld, you will see more. The motivation doesn't say anything along the line of "all apps attached to every TOR in a cloud". VM placement affinity rules would NEVER see absolutely every local VM belonging to a different tenant network and requiring connectivity only to remote VMs. [Linda] "VM placement affinity rule" is set by operators. One operator can set the rule of not allowing different subnets to be placed under one rack, by sacrificing the flexibility of placement. Other operators may prefer the flexibility by setting more lose rules. Which says to me this is a solution to a non-problem unless the goal is to circumvent near-malicious stupidity in the design of the provisioning algorithms used in the cloud management system. [Linda] You can still implement the rule of requiring hosts of one subnet being placed together under one ToR. Then there is no problem. But it doesn't mean that we don't need to evolve network to enable operators to utilize the new technology for flexibility and elasticity. 2) I believe the notion of an ARP proxy and use of MAC-NAT for scaling are divisible concepts and each can be examined in isolation. [Linda] Agree with your point here. The draft really has two portions: Proxy Gateway and caching the entries. a. If I want an ARP proxy system, Ethernet already defines the capability to map frames with a specific Ethertype to a distinct VLAN, so ARP transactions (0x806) can be separated out of the datastream using existing standardized technology and delivered to a remote proxy ARP system of any arbitrary design, no further standardization required. [Linda] There can be multiple VLANs hosts (applications) placed on the rack. Do you mean giving them different EtherTypes? So the traffic is mapped to another VLAN? Does it mean each subnet will need two VLANs? Besides, you can't dictate on what EtherType to use for applications being instantiated on servers. Can you elaborate more of this "ARP Transactions"? If it works well, we can document it in the draft and replace the ARP proxy being currently described. b. An alternative to MAC NAT (a form of summarization in a flat dataplane) is with MACinMAC (a form of summarization via hierarchical stacking). [Linda] MACinMAC (IEEE802.1ah) doesn't summarize all remote hosts with common MAC. All switches and hosts attached to the boundary Edge and the Backbone Edge are exposed to all the remote hosts' MAC/VLAN addresses. Which is already standardized and deployed and would have identical scaling properties. NVO3 class of solutions while not yet standard, have similar properties. c. MAC NAT itself means the e2e path has a pseudo L3 hop in it, which effectively prevents all L2 protocols (e.g. CFM, DCB etc.) from being able to instrument connectivity e2e, so (for example) to diagnose what looks like an L2 hop, I would need to use both ETH-LB and ICMP ping, even then with questionable ability to fault sectionalize after the MAC NAT function. [Linda] CFM is among switches, not among end stations. The proxy Gateway is to represent all remote end-stations (or hosts) by their Gateway addresses. Switch addresses are never an issue because there are only very limited number of switches in the network. Can you elaborate this "pseudo L3 hop"? ETH-LB and ICMP are also for switch nodes too. They are not for end stations. My 2 cents Dave ---------------------------- Hi all, This draft has been presented at several intarea face to face meetings and has received quite a bit of discussion. It has been difficult to gauge whether the wg is interested in this work or not. This call is being initiated to determine whether there is WG consensus towards adoption of draft-nachum-sarp-06 as an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-09-04. Regards Suresh & Julien
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
