Thank you Tony. Very helpful feedback. Jorge
-----Original Message----- From: Antoni Przygienda <[email protected]> Date: Tuesday, March 31, 2015 at 4:53 PM To: Jorge Rabadan <[email protected]>, Erik Nordmark <[email protected]>, "Henderickx, Wim (Wim)" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: RE: [bess] ARP ND draft >> [JORGE] 2 ACs on the same ESI/EVI on the same PE? I suppose to are >>talking >> about VLAN-aware bundle interfaces, where each VLAN goes to a different >>BD? >> note that the proxy-arp/nd function is per broadcast domain, i.e. one >>per EVI for >> VLAN-based and VLAN-bundle and one per BD for VLAN-aware bundle >> interfaces. We can clarify that in the draft. > > [Tony saiz:] same EVI/ESI/VLAN which for me indicates that the two ACs >belong to the same customer and are same ether. very small nitpick, >probably not worth mentioning ;-) > >> >> >> > >> >Small observation for 4.3: enabling the send-refresh option is a >> >dangerous thing. It's not only they may keep up active entries in the >> >fast-path forever (since there is always some traffic generated by the >> >'probes'), it's also that the IP/MAC binding 'kept up' even if there is >> >no traffic is sitting in all PEs as RT-2. The section talks about >> >advantages, maybe it deserves a sentence to point out the dangers of >> >such behavior. >> >> [JORGE] send-fresh is optional and should be enabled/disabled depending >>on the >> use-case. The purpose is in fact keep local IP->MAC bindings active and >>make >> sure they are still valid before withdrawing the RT2s. It can also help >>keeping >> active not only the proxy entry but also the MAC-VRF entry. If the user >>wants to >> rely purely on the age-time, that should be allowed. Not sure why this >>is a >> danger? > > [Tony saiz:] because disabling aging will basically accumulate more and >more state in fwd path even if the src/dst pairs don't talk to each other >anymore. In your customer's scenario that's what's needed, in e.g. >sparse, large scale EVPN deployments in backbone it's probably not what a >carrier would be excited about given PE state is expensive. > >> > >> >[Tony saiz:] as I wrote in other email, the problem is if the first >> >route goes, the second should be honored IMO. It seems to me we have >> >this very case BTW with the aliased default gateways? >> >> [JORGE] Yes, if the first route is withdrawn (IP1->M1), the second >> (IP1->M2) will be now installed in the proxy-arp/nd table. As long as >>the BGP >> route is kept we are good. A different thing is anycast, in which case >> IP1->M1 and IP1->M2 are both valid at the same time. We will tackle this >> in the next rev. >> > > [Tony saiz:] I agree with that (i.e. the 2nd best BGP route is >GARP'ed). The anycast in ipv4 is a rare animal from the sightings I had >so I'm only concered about the 'aliased default GW' case I guess. > >> > >> >> >> >> >> >> d)eVPN draft does not explain anything about possibility to snoop >> >> >> @ DHCP >> >> >> >> [JORGE] do you mean in the proxy-arp/nd draft or in the base spec? >> >> In the proxy-arp/nd only ARP/ND messages are used. DHCP is not always >> >>there. >> >> Not there in the IXP use-case anyway. >> > >> > [Tony saiz:] agreed, I just read the draft in wider scope than just >> >IXP and that's why I'm asking. >> >> [JORGE] IMHO focusing on learning arp/nd for the time being is simpler, >>and it is >> really what we want to keep under control to reduce flooding. >> But we can discuss. > > [Tony saiz:] agreed. Maybe one sentence placeholder like "DHCP and >other strange fruit can be snooped beside to learn the IP/MAC bindings" >;-) > > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
