> [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
