RE: Merge MAC Withdraw Drafts?

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Pranjal,

Please refer to my comments inline ...

But let me emphasize the interop issue here a bit more. We know the only
way to do C-MAC flushing in PBB network is via .1Qbe, by doing yet
another mechanism without clear advantage, then how are we going to
interoperate between PBB & MPLS access networks? Now, are we going to
create more work for ourselves and come up yet with another
interoperability spec? If the native Ethernet mechanism required a
complex protocol (or even a moderate protocol), then I would have agreed
that it is better to piggy back this C-MAC flush mechanism over existing
LDP MAC withdraw. However, that's not the case and the native Ethernet
mechanism is as simple as building a pre-canned message and transmitting
it - e.g., no MRP state-machine is required for the native mechanism.

> 
> [Pranjal] Are we saying that we will deploy two different MAC flush
>           solutions, one for existing "vanilla" VPLS part and another
>           For CMAC Flush? 

Yes, that's what I am saying. In PBB-VPLS model per figure-2 of
draft-ietf-l2vpn-pbb-vpls-pe-model, C-MACs sits in the bridge module
entirely (in the I-comp of bridge module being more precise) and VPLS
forwarders are completely transparent to these C-MCAS because they
operate on B-MACs. One of the main reason for doing this model was to
simplify our life and try not to reinvent the wheel unnecessarily. If
there is a good reason to reinvent the wheel, then I am O.K. with it but
that's not the case here.


> 
> [Pranjal] Didn't get exactly. Can you please provide reference to
>           the relevant sections in draft-ietf-l2vpn-pbb-vpls-interop
>           where we think draft-balus-l2vpn-pbb-ldp-ext brings
conflict.
>           That would be helpful for further discussions in the list.

It LDP-based C-MAC scheme cannot be used in the following scenarios: 
	- section 4.2 
	- section 4.3
	- section 5.1
	- section 5.2
	- section 6.1 (w/ mixed of both MPLS & PBB access networks)
	- section 7.2 & 7.3 (w/ mixed of both MPLS & PBB access
networks)


> 
> [Pranjal] It would help if you can explain in what way it's
consistent.
> 

The inconsistency with draft-ietf-l2vpn-pbb-vpls-pe-model, is that as
mentioned above, the C-MACs are within the bridge module and therefore
their flushing should be governed by native Ethernet mechanism and
transparent to VPLS forwarder for a number of reasons and advantages
discussed in draft-sajassi-l2vpn-pbb-vpls-cmac-flush.

Cheers,
Ali