Suresh, RFC 4389 is about proxying between multiple interfaces when classic bridging is not possible, while as the proxy described in SARP is about classic bridged network spanning many locations (server racks).
RFC4389 specifically stated that it is not applicable to classic bridging. Even though RFC 4389 describes how a "Proxy" interface caches the neighbor entries, it states in Section 4.1.3.1 that "no NA is generated". The Section 1.2 of the "draft-nachum-sarp-4" has stated: "Note: The Guidelines to proxy developers [RFC4389] have been carefully considered for the SARP protocols. The section 3.3 has demonstrated how SARP works when VMs are moved from one segment to another." Linda > -----Original Message----- > From: Suresh Krishnan [mailto:[email protected]] > Sent: Thursday, March 14, 2013 9:58 AM > To: Tal Mizrahi > Cc: Linda Dunbar; [email protected] > Subject: Re: Can we chat on Thurs on IPv6 ND impact on L2/L3 boundary > routers when subnets spanning across multiple locations? > > Hi Tal, > I met with Linda yesterday. She clarified your intent a bit and I > felt > that the intent was similar to what ND proxy intended to achieve. I > recommended her to take a look at RFC4389 and identify any potential > shortcomings and restate your goals in terms of these shortcomings. > > Thanks > Suresh > > On 03/14/2013 10:00 AM, Tal Mizrahi wrote: > > Are we meeting today? > > > > Tal. > > > > > > -----Original Message----- > > From: Suresh Krishnan [mailto:[email protected]] > > Sent: Wednesday, March 13, 2013 4:34 PM > > To: Linda Dunbar > > Cc: [email protected]; Tal Mizrahi > > Subject: Re: Can we chat on Thurs on IPv6 ND impact on L2/L3 boundary > routers when subnets spanning across multiple locations? > > > > Hi Linda, > > The v6ops session is today :-). I am in the back of the room. > > > > Cheers > > Suresh > > > > On 03/13/2013 03:13 PM, Linda Dunbar wrote: > >> Suresh, > >> > >> > >> > >> You said that you will be available Thus after 3pm at IPv6 Ops, but > I > >> don't see IPv6 Ops WG on the calendar. > >> > >> > >> > >> Where can we meet you? > >> > >> > >> > >> Linda > >> > >> > >> > >> *From:*Linda Dunbar > >> *Sent:* Tuesday, March 12, 2013 11:44 AM > >> *To:* 'Suresh Krishnan'; '[email protected]' > >> *Cc:* 'Tal Mizrahi' > >> *Subject:* Can we chat on Thurs on IPv6 ND impact on L2/L3 boundary > >> routers when subnets spanning across multiple locations? > >> > >> > >> > >> Suresh and Julien, > >> > >> > >> > >> Can we chat face to face on the IPv6 ND impact on L2/L3 boundary > >> routers when subnets spanning across multiple locations? > >> > >> > >> > >> It seems that written words are not enough to convey the message. > >> > >> We really appreciate you be able to talk to us face to face to > >> understand your concern. > >> > >> > >> > >> Is Thurs afternoon good for you? Any time after 3pm is good for us. > >> > >> > >> > >> > >> > >> Here are some text showing the ND impact to L2/L3 boundary routers: > >> > >> > >> > >> > >> > >> > >> * Scenario: Communicating with a peer in a different > subnet > >> > >> When the originating end station doesn't have its default gateway > MAC > >> address in its ARP/ND cache and needs to communicate with a peer in > a > >> different subnet, it needs to send ARP/ND requests to its default > >> gateway router to resolve the router's MAC address. If there are > many > >> subnets on the gateway router and a large number of end stations in > >> those subnets that don't have gateway MAC in their ARP/ND caches, > the > >> gateway router has to process a very large number of ARP/ND requests. > >> This is often CPU intensive as ARP/ND messages are usually processed > >> by the CPU (and not in hardware). > >> > >> > >> > >> For IPv4 networks, a practice to alleviate this problem is to have > the > >> L2/L3 boundary router send periodic gratuitous ARP [GratuitousARP] > >> messages, so that all the connected end stations can refresh their > ARP > >> caches. As a result, most (if not all) end stations will not need to > >> send ARP requests for the gateway routers when they need to > >> communicate with external peers. > >> > >> For the above scenario, IPv6 end stations are still required to send > >> unicast ND messages to their default gateway router (even with those > >> routers periodically sending Unsolicited Neighbor Advertisements) > >> because IPv6 requires bi-directional path validation. > >> > >> > >> > >> > >> * Inter subnets communications > >> > >> The router could be hit with ARP/ND twice when the originating and > >> destination stations are in different subnets attached to the same > >> router and those hosts don't communicate with external peers often > >> enough. The first hit is when the originating station in subnet-A > >> initiates an ARP/ND request to the L2/L3 boundary router if the > >> router's MAC is not in the host's cache; and the second hit is when > >> the L2/L3 boundary router initiates ARP/ND requests to the target in > >> subnet-B if the target is not in router's ARP/ND cache. > >> > >> > >> > >> > >> > >> When the combined number of VMs (or hosts) in all those subnets is > >> large, this can lead to impact on L2/L3 boundary routers. > >> > >> > >> > >> Hope to talk to you face to face. > >> > >> > >> > >> Linda > >> > >> > >> > >> > >> > >> > >> > >> > >> > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
