Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

[David Allan I <[e-mail]>]

HI Linda:

Replies marked [DA]

One correction, I meant to say MACinMAC (same as TRILL or NVO3) only hides hosts addresses from the core nodes, but, all the overlay edge nodes are still exposed to all the hosts addresses on the VLANs that are enabled on the edge.

[DA] I eventually figured out what you were getting at :-)

We have seriously considered MACinMAC back then for Ethernet transport, but found out that most networks have access traffic to most of nodes, i.e. most of the nodes become "MACinMAC" edge nodes. Basically there is no core nodes to benefit from hiding individual addresses in access domains.  

[DA] That does not mean that the overall set of customer MACs for a given network is not divided amongst the set of BEBs. As we both agreed, every VLAN does not have end-stations on every BEB. So there is an element of divide and conquer here. Which as I've indicated, with a tiny bit of discipline in implementing VM affinity rules would become even more beneficial for scaling.

Same goes with Overlay Edge enabled on TOR or EOR, there is limited number of nodes between ToR to DC Gateway, to benefit from hosts addresses being hiden. Maybe only aggregation switches benefit from the overlay, the DC gateway routers have to be exposed to all addresses of hosts who communicate with external peers. 

[DA] We need to separate DC to DC and user to DC when discussing the gateways. I do not know why gateways would see VM MACs in the DC to DC case (see draft-allan-l2vpn-spbm-evpn...), and those MACs would be unique vs the user to DC case.

Most of hosts in DC do communicate with external peers, maybe the volume is not as high as east/west traffic. 

[DA] traffic wise I would agree external traffic is a fraction of east west....

Cheers
Dave


> -----Original Message-----
> [Linda] MACinMAC (IEEE802.1ah) doesn't summarize all remote hosts with 
> common MAC.
> 
> [DA] Excuse me.? It encapsulates frames from a remote BEB with a 
> header that includes the BMAC of the remote BEB which is what appears 
> in all core forwarding tables.  If you want to call it something else 
> fine, but it is functionally equivalent.
> 
> All switches and hosts attached to the boundary Edge and the Backbone 
> Edge are exposed to all the remote hosts' MAC/VLAN addresses.
> 
> [DA] Ahhh, you are worried about compressing the MAC state in the 
> ingress TOR and replacing it with state in the egress in a new 
> function requiring a technology change and a separate table. I'd 
> concede you will get some benefit in theoretical scalability, but 
> individual TOR chips these days can handle north of 250000 MAC 
> addresses in on chip tables, so again unless you are focused on an 
> extreme corner case which I do not subscribe to , I do not see an 
> issue with current technology
> 

Linda