RE: Merge MAC Withdraw Drafts?
"Balus, Florin Stelian (Florin)" <florin.balus@alcatel-lucent.com> Fri, 07 May 2010 16:27 UTC
Return-Path: <florin.balus@alcatel-lucent.com>
X-Original-To: l2vpn@core3.amsl.com
Delivered-To: l2vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFAB3A6AE9 for <l2vpn@core3.amsl.com>; Fri, 7 May 2010 09:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.505
X-Spam-Level:
X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn64Pitqw7aB for <l2vpn@core3.amsl.com>; Fri, 7 May 2010 09:27:20 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 87E673A6A58 for <l2vpn@ietf.org>; Fri, 7 May 2010 09:27:20 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o47GQwXY013947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 May 2010 11:26:58 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o47GQt5C013403 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 May 2010 11:26:58 -0500
Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.139]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 7 May 2010 11:26:56 -0500
From: "Balus, Florin Stelian (Florin)" <florin.balus@alcatel-lucent.com>
To: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, Shane Amante <shane@castlepoint.net>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Date: Fri, 07 May 2010 11:26:37 -0500
Subject: RE: Merge MAC Withdraw Drafts?
Thread-Topic: Merge MAC Withdraw Drafts?
Thread-Index: AcrrPOBGvXpyTe5XSwC37bfOXMhS8QBb0HVgAAd1enAAHHFfoAAuqKOwAAKoS/A=
Message-ID: <2073A6C5467C99478898544C6EBA3F46029E4DA535@USNAVSXCHMBSC3.ndc.alcatel-lucent.com>
References: <52AAA34A-CB83-4588-8E1A-E003578BDD80@castlepoint.net> <7F115A41909B2641A9550322C4DF9D5603AB3368@xmb-sjc-22d.amer.cisco.com> <C584046466ED224CA92C1BC3313B963E09E096B157@INBANSXCHMBSA3.in.alcatel-lucent.com> <7F115A41909B2641A9550322C4DF9D5603AB3566@xmb-sjc-22d.amer.cisco.com> <C584046466ED224CA92C1BC3313B963E09E096B5A0@INBANSXCHMBSA3.in.alcatel-lucent.com>
In-Reply-To: <C584046466ED224CA92C1BC3313B963E09E096B5A0@INBANSXCHMBSA3.in.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-puzzleid: {6A51059E-209B-42AB-8F97-6911189921A4}
x-cr-hashedpuzzle: CXD+ CtxT IhPp SCba UfXU WpoP Y36O aLWp aNyN bxTC dAtd eQDO fY3a hHVs hQN0 h3r3; 3; bAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAcwBhAGoAYQBzAHMAaQBAAGMAaQBzAGMAbwAuAGMAbwBtADsAcwBoAGEAbgBlAEAAYwBhAHMAdABsAGUAcABvAGkAbgB0AC4AbgBlAHQA; Sosha1_v1; 7; {6A51059E-209B-42AB-8F97-6911189921A4}; ZgBsAG8AcgBpAG4ALgBiAGEAbAB1AHMAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA=; Fri, 07 May 2010 16:26:37 GMT; UgBFADoAIABNAGUAcgBnAGUAIABNAEEAQwAgAFcAaQB0AGgAZAByAGEAdwAgAEQAcgBhAGYAdABzAD8A
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2073A6C5467C99478898544C6EBA3F46029E4DA535USNAVSXCHMBSC_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2010 16:27:28 -0000
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". 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. From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Dutta, Pranjal K (Pranjal) Sent: Friday, May 07, 2010 8:58 AM To: Ali Sajassi (sajassi); Shane Amante; l2vpn@ietf.org Subject: RE: Merge MAC Withdraw Drafts? Hi Ali, Please refer my responses inline in blue. Thanks, Pranjal -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Thursday, May 06, 2010 11:51 AM To: Dutta, Pranjal K (Pranjal); Shane Amante; l2vpn@ietf.org 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
- RE: Merge MAC Withdraw Drafts? Aissaoui, Mustapha (Mustapha)
- Merge MAC Withdraw Drafts? Shane Amante
- RE: Merge MAC Withdraw Drafts? Henderickx, Wim (Wim)
- RE: Merge MAC Withdraw Drafts? LASSERRE, MARC (MARC)
- RE: Merge MAC Withdraw Drafts? Manuel.Paul
- Re: Merge MAC Withdraw Drafts? Thomas Nadeau
- Re: Merge MAC Withdraw Drafts? Himanshu Shah
- RE: Merge MAC Withdraw Drafts? Rabadan, Jorge (Jorge)
- RE: Merge MAC Withdraw Drafts? Fragassi, Roberto (Roberto)
- RE: Merge MAC Withdraw Drafts? William Zayas
- RE: Merge MAC Withdraw Drafts? Olen Stokes
- RE: Merge MAC Withdraw Drafts? Mallette, Edwin
- RE: Merge MAC Withdraw Drafts? Yong Lucy
- RE: Merge MAC Withdraw Drafts? Seaton, Mark
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? Linda Dunbar
- RE: Merge MAC Withdraw Drafts? Delregno, Christopher N (Nick DelRegno)
- Re: Merge MAC Withdraw Drafts? Raymond Key
- Re: Merge MAC Withdraw Drafts? Simon Delord
- RE: Merge MAC Withdraw Drafts? Dutta, Pranjal K (Pranjal)
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- RE: Merge MAC Withdraw Drafts? Dutta, Pranjal K (Pranjal)
- RE: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? Henderickx, Wim (Wim)
- RE: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- RE: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? neil.2.harrison
- RE: Merge MAC Withdraw Drafts? David Allan I
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? David Allan I
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- RE: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- RE: Merge MAC Withdraw Drafts? Henderickx, Wim (Wim)
- RE: Merge MAC Withdraw Drafts? Dutta, Pranjal K (Pranjal)
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? Dutta, Pranjal K (Pranjal)
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? David Allan I
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? neil.2.harrison
- RE: Merge MAC Withdraw Drafts? Dutta, Pranjal K (Pranjal)
- RE: Merge MAC Withdraw Drafts? David Allan I
- RE: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- RE: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- RE: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- FW: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- RE: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- Re: Merge MAC Withdraw Drafts? Shane Amante
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? neil.2.harrison
- Re: Merge MAC Withdraw Drafts? Shane Amante
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? geraldine.calvignac
- Summary of debate RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- RE: Merge MAC Withdraw Drafts? Ali Sajassi (sajassi)
- Re: Merge MAC Withdraw Drafts? Shane Amante
- RE: Merge MAC Withdraw Drafts? Balus, Florin Stelian (Florin)
- Inappropriate email content Balus, Florin Stelian (Florin)
- RE: Summary of debate RE: Merge MAC Withdraw Draf… Ali Sajassi (sajassi)
- RE: Inappropriate email content Ali Sajassi (sajassi)
- RE: Inappropriate email content Balus, Florin Stelian (Florin)
- RE: Inappropriate email content Ali Sajassi (sajassi)
- Re: Inappropriate email content Shane Amante
- Re: Merge MAC Withdraw Drafts? Shane Amante