RE: Merge MAC Withdraw Drafts?

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

Hi Pranjal,

 

Please refer to my comment 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.

 

It seems like there may be confusion between flushing mechanism for
B-MAC and C-MAC domains. In one of my emails, I described that the two
are apples and oranges and although one can extend the flushing
mechanism of the B-MAC domain for C-MAC domain, it is not a  good
solution since it will requires each network-type protocol be extended
to do that - for example each of the following protocols need to be
extended for doing this:

-          LDP for PBB-VPLS

-          MSTP for PBB

-          R-APS for G.8032

-          802.1aq for SPB-M

 

Furthermore, it now creates a massive interop issue since we have so
many different permutation to worry about interop for C-MAC flushing -
e.g., O(N!); where N is number of protocols.

 

A much cleaner way of addressing C-MAC flushing is to consider it
independent from B-MAC domain and use a simple native Ethernet message .
Since this message is an Ethernet message, it will work across all
different types of network.

 

> 

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

 

The implementation can be anything but that's why we went through the
exercise of this modeling to have a clear demarcation and not burden
ourselves with reinventing bridging protocols when such protocols work
just fine. The reasons for this having PBB-VPLS PE model is the same as
that we did for  draft-ietf-l2vpn-vpls-bridge-interop:

 "This draft extends the PE model described in [RFC-4664] 

   based on IEEE 802.1ad bridge module, and illustrates a clear 

   demarcation between the IEEE bridge module and IETF LAN emulation 

   module. By doing so, it shows that the majority of interoperability 

   issues with CE bridges can be delegated to the 802.1ad bridge 

   module, thus removing the burden on the IETF LAN emulation module 

   within a VPLS PE."

 

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-L2
VPN-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.
 
I don't see any mention to flushing C-MAC addresses, so if there was an
implicit assumption then that's was not my intention. 

 

So I don't see where we have the conflict between 
draft-ietf-l2vpn-pbb-vpls-pe-model and draft-balus-pbb-ldp-ext.

 

The conflict is with the model and the reason for me describing such
model was to make it clear that the same principles described in
draft-ietf-l2vpn-vpls-bridge-interop draft to apply here.

 
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.

 

If creating a canned Ethernet message was difficult or complex, then I
would have agreed. But we are talking about also very simple native
Ethernet scheme which consists of basically building a canned message.
So, it basically comes done to encoding the information that we already
have in either LDP message or Ethernet message. And using Native
Ethernet message gives us faster convergence and works well for all
mixed of network including  all-MPLS and avoid any interoperability down
the road.

 

 

 

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.

 

The point is how do we handle a scenario where we have both PBB access
and CE hanging off of the PE. In such case, can either do:

              a) LDP-based mechanism

              b) MIRP mechanism

              c) interop between the two

or simply just do (b).

 

 

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

Same comment as bove.

 

 

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

 

Same comment as above.

 

           

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.

 

Please refer to my previous comments above.

 

-Ali