Suresh and Julien, When the "draft-nachum-sarp-02" was presented at InterArea WG in 84th IETF, the feedback was that the draft needs to be updated to include the processing for IPv6.
So we updated the draft to include the processing of ND for IPv6. When the revised draft (draft-nachum-sarp-03) was presented at the InterArea WG in 85th IETF, there are several people saying there is no problems for IPv6 ND, therefore it shouldn't be optimized. Even though that IPv6 ND uses multicast instead broadcast, IPv6 ND does have scalability issues in Data Center when hosts within same subnet are spread across different access switches, and when there are lot of those subnets. In particular: * when hosts within the same subnet are spread across multiple switches (or GWs in the draft), the ND solicitation still go to all switches which might have the same subnet hosts attached. The traffic across GWs are same as IPv4's ARP. The only difference is that hosts impact is reduced. * When host "a" needs to communicate with host "b" in different subnet, "a" needs to send "Neighbor Solicitation" to L2/L3 boundary router, (just the same way as IPv4 ARP). When there are many subnets spreading across many access switches, the L2/L3 boundary router has to enable all those subnets on many of its ports/links. When the first "a"-> "b" data frame arrives at the boundary router, the boundary router has to "hold the data frame" and send a "Neighbor Solicitation" to all links which has the subnet for "b" enabled. The boundary router may need to send "NS" multiple times until it can make sure the target "b" exists before sending down the data frame from "a". This process is not only CPU intensive, but also takes buffer. We need your advice on how to move this draft forward. Thank you very much. Linda
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
