Hi Linda, On 11/12/2012 05:36 PM, Linda Dunbar wrote: > Suresh and Julien, > > > > When the “draft-nachum-sarp-02” was presented at InterArea WG in 84^th > 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 85^th 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.
This is not true. If the switches are MLD snooping then the packets will not be sent to irrelevant GWs/switches. > > > > · 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). Correct. But only the router gets it. Not all the other hosts in the subnet (which is the case for 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. This is purely an implementation issue. I know of several router implementations where this is not the case. > > > > 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. (Chair hat off) I personally find the IPv6 ND motivations to be lacking. I think the draft needs a better description of the ND related issues that are not stated in the armd problem statement. Thanks Suresh _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
