RE: Merge MAC Withdraw Drafts?

["Dutta, Pranjal K (Pranjal)" <[e-mail]>]

Hi Ali,

         Please refer my responses inline in blue.

Thanks,

Pranjal



-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[e-mail]]
Sent: Thursday, May 06, 2010 11:51 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante; [e-mail]
Subject: RE: Merge MAC Withdraw Drafts?



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] IMO, the question here is not about C-MAC Flushing in native PBB
          network via .1Qbe. In PBB-VPLS PE model (draft-ietf-l2vpn-pbb-vpls-pe)
          we have extended the *existing* VPLS bridge Module (aka VSI) with I/B
          components for service scalability and MAC table scalability. In PBB-VPLS

          PE, the RFC 4762 LDP MAC Flush is already in place. Now regarding the

          question on how we are going to inter-op with PBB access networks -

          the PBB-VPLS PE model doesn't necessitate the presence on a PBB access

          networks. So the question should be other way around - are we going to

          invent something new in RFC 4762 deployments for each access network

          requirement. So in draft-balus-pbb-ldp-ext we are not coining something
          new or re-inventing the wheel and just piggybacking PBB specific info in
          LDP MAC Flush. Using existing LDP based approach is generic and can be
          extended for future applications as well. We don't need run each native
          ethernet protocol in core. Neither we are ruling out that fact the

          native ethernet protocols can't be run between C-MAC components.





>

> [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] I would probably disagree with this point. In implementations

no such strict separation exists although we place a separate building

block to describe components/functionalities involved such as VPLS

forwarders, CMAC bridging etc. From packet flow perspective, yes I agree

that components are dis-joint but not from control plane perspective

towards the core. The same PE box that has CMAC component also has full
fledged RFC 4762 and LDP implementation already.  Secondly, it's not always
necessary that there is a native PBB network towards CE.



Here is what I read from section 5. Control plane in

draft-ietf-l2vpn-pbb-vpls-pe-model.



   The existing control plane procedures described in [L2VPN-Sig<http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-vpls-pe-model-01#ref-L2VPN-Sig#ref-L2VPN-Sig>] and

   [RFC4762<http://tools.ietf.org/html/rfc4762>] can be re-used in a PBB-VPLS to setup the PW infrastructure

   in the service provider and/or customer bridging space. This allows

   porting the existing control plane procedures (e.g. BGP-AD, PW setup,

   VPLS MAC Flush, PW OAM) for each domain.



So I don't see where we have the conflict between
draft-ietf-l2vpn-pbb-vpls-pe-model and draft-balus-pbb-ldp-ext.
Towards VPLS/Core we would want only one generic protocol catering to
all requirements of MAC Flush. It makes implementations lot simpler from
deployment perspectiive. As mentioned by others in the thread - existing
LDP MAC flush is a proven and simple mechanism being deployed in RFC 4762
deployments for several years. draft-balus-pbb-ldp-ext exactly complies
with Section 5. in draft-ietf-l2vpn-pbb-vpls.



>

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



[Pranjal] I think what protocol we use in core should be orthogonal

          to presence of PBBN access. The PBBN access can definitely

          run native ethernet protocols. As I mentioned above as per

          draft-ietf-l2vpn-pbb-vpls model we have inherited the PBB

          I/B components into existing VPLS PE and doesn't necessitate

          presence on PBBN access network.



      - section 4.3

[Pranjal] Same as comment in 4.2. We can run any X native ethernent

          Protocols on access network but all translates into an

          uniquitous generic mechanism in core for better
          inter-operability.



      - 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



[Pranjal] I agree with the fact in all the above sections, that packet

          traverses thru disjoint components (transparent to each other)

          but should be one control plane towards core.





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.



[Pranjal] I would probably disagree with the point that

"their flushing should be governed by native Ethernet mechanism".

I don't see any reference in existing PBB VPLS WG drafts where

We have mentioned that C-MAC Flushing "SHOULD" be done with

native ethernet mechanism.



Cheers,

Ali