Subject: Some reasonings on the draft "Optimized MAC Address Operations in VPLS with Redundancy"

From: Jiang Yuan-long <[email-masked]>
Date: Thu, 07 Aug 2008 11:36:27 +0800

Hi, Marc:

Thank you for your comments on the IETF 72 meeting, here I will give some more reasonings concerning 
with your comments.

The following is the excerpt from the 72nd IETF L2VPN WG minutes:
- Marc Lassere: There is already an existing proposal,
          (draft-pdutta-l2vpn-vpls-ldp-mac-opt-03), so I'm not sure what the
          benefits are vs. what has been proposed already to only flush relevant
          MAC addresses.
- Marc Lassere: In the proposal made, the PE-id is used to find out what
          the MAC addresses are to be flushed.  So, instead of blindly flushing,
          it's not an empty list, you only flush the ones behind the PE that
          failed.  This is as optimized as can be.  The second point is I'm a bit
          worried that you're suggesting to switch MAC addresses.  You don't want
          to create a new learning engine in VPLS, you want to learn from data
          plane as they come.  You don't want two FIB's, because you got some
          LDP-based message.
-end of the excerpt

With regard to draft-pdutta-l2vpn-vpls-ldp-mac-opt-03, we have introduced it in brief in our draft.
Firstly, IMO, it applies only to a certain hub-and-spoke network topology, if CE is dual-homed to 
the PEs by ACs, it will be out of the capability of the draft.
Secondly, for the customer sites with hundreds of MACs, still a lot of MAC learning will be needed.
Thirdly, for the customer site with few MACs but large bandwidth, although few MACs are flushed, but 
as the time for the responsive frame to arrive at the PEs where MACs are flushed is not trivial, the
total frames flooded accross the core may be added to a high volume.
Therefore, draft-jiang-l2vpn-vpls-mac-operation-00 tries to eliminate the MAC leaning and subsequent 
flooding procedures due to PE or PW switching in a broader way.

For the 2nd question, I don't think we need two FIBs to provide MAC switching function.
For what I know, the original MAC address withdrawal process defined in RFC4762 first provides
the LDP-based message to flush specified MACs or all MACs except those associated with certain PWs 
in the FIB, so maybe there is no problem to pass MACs and PW information to the dataplane.

The only difference lies in the processing logic of the dataplane, which depends on the implementation.
Except "flush all MACs" blindly, selectively flushing or any other optimizations will somehow introduce 
complexities to the logic. IMO, from the view of computation comlexity, MAC switching is just the same
as RFC 4762.

The following are some snippets for the comparisons of the processing logic :
In RFC 4762: 
1) for each MAC in a set of MACs,
        lookup the FIB for this MAC and flush the corresponding FIB item.

2) Given PW1, for each item in the FIB, 
        if the item's outport is not the same as this PW, then flush it.

In our draft, 
1) Given PW1, for each MAC in a set of MACs,
        lookup the FIB for this MAC and change its outport to PW1.
2) Given PW1, PW2, for each item in the FIB, 
        if the item's outport is the same as PW1, then change it to PW2.

cheers,

Yuanlong