FW: Merge MAC Withdraw Drafts?

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

Resending  because of large message size error

 

From: Ali Sajassi (sajassi) 
Sent: Friday, May 07, 2010 5:12 PM
To: 'Balus, Florin Stelian (Florin)'; Dutta, Pranjal K (Pranjal); Shane
Amante; [e-mail]
Subject: RE: Merge MAC Withdraw Drafts?

 

 

I would summarize it as follow: we got two options:

 

LDP-based:

-------------

Pros:

-          Simple to implement, no certification required, no OSS
modification

-          Works for E2E MPLS only

Cons:

-          Slower to converge (relative to Ethernet mechanism)

-          Creates interop issues and will require additional interop
solutions

-          Requires implementing, testing, and operating such interop
solutions 

 

Native Ethernet-based:

Pros:

-           Simple to implement, no certification required, no OSS
modification

-          Works for E2E MPLS 

-          Faster to converge

-          No interop issue

-          No additional interop solution development, testing, and
operating

Cons:

-          None ( based on this long email thread, no one has pointed a
single con regarding this)

 

Florin, one more comment inline ...

 

 

 

 

From: Balus, Florin Stelian (Florin)
[mailto:[e-mail]] 
Sent: Friday, May 07, 2010 9:27 AM
To: Dutta, Pranjal K (Pranjal); Ali Sajassi (sajassi); Shane Amante;
[e-mail]
Subject: RE: Merge MAC Withdraw Drafts?

 

I would summarize what Pranjal said here in the following way:

-          All the interop remarks below do not  apply since we never
said we are targeting any Native PBB-VPLS interop. Focusing on MPLS E2E
case.

-          The answer to the second point, inconsistency between
pbb-vpls-pe-model and draft-balus is not applicable - see Ali's
clarification below:

 

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.

 

I challenge everybody to go in the draft-ietf-l2vpn-pbb-vpls-pe-model
and find the text Ali quotes: "should be governed by native Ethernet
mechanism".

 

Your challenge is met J Take a look at
draft-ietf-l2vpn-vpls-bridge-interop on which the modeling of PBB-VPLS
was based. It says:

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

 

-Ali

 

And even if the text was there last time I checked SHOULD does not mean
MUST.

 

I think we need to drop this email chain as irrelevant for the
discussion.