From l2vpn-bounces@ietf.org Mon Dec 03 01:30:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4o1-0007mP-U7; Mon, 03 Dec 2007 01:29:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4o0-0007gJ-S7 for l2vpn@ietf.org; Mon, 03 Dec 2007 01:29:24 -0500 Received: from dog.tcb.net ([64.78.150.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz4ny-0007hp-HX for l2vpn@ietf.org; Mon, 03 Dec 2007 01:29:22 -0500 Received: by dog.tcb.net (Postfix, from userid 0) id 35D952680F4; Sun, 2 Dec 2007 23:29:22 -0700 (MST) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Sun, 02 Dec 2007 23:29:22 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=37361; data-bytes=0 Message-ID: <4753A240.2000606@castlepoint.net> Date: Sun, 02 Dec 2007 23:29:20 -0700 From: Shane Amante User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: Slides for L2VPN WG Meeting at IETF 70 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hi, Just a reminder that we are meeting this Tuesday afternoon, December 4, 1740-1840. Here is a link to the agenda: http://www3.ietf.org/proceedings/07dec/agenda/l2vpn.txt Can those who are presenting, please send Vach and I a copy of your slides by no later than Monday evening, so that we may post them to the IETF Meeting Materials Web page in time for the meeting on Tuesday? -shane From l2vpn-bounces@ietf.org Wed Dec 05 12:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzyS6-0000L5-1H; Wed, 05 Dec 2007 12:54:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzyS5-0000Kx-Aj for l2vpn@ietf.org; Wed, 05 Dec 2007 12:54:29 -0500 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzyS3-00027S-5O for l2vpn@ietf.org; Wed, 05 Dec 2007 12:54:29 -0500 Received: by dog.tcb.net (Postfix, from userid 0) id ED93B2680CE; Wed, 5 Dec 2007 10:54:26 -0700 (MST) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Wed, 05 Dec 2007 10:54:26 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=35668; data-bytes=0 Message-ID: <4756E5D1.9030909@castlepoint.net> Date: Wed, 05 Dec 2007 10:54:25 -0700 From: Shane Amante User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: Presentations from L2VPN WG meeting at IETF70 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org FYI. All presentations given at L2VPN at IETF70 are now online at the IETF Meeting Materials Web site: https://datatracker.ietf.org/meeting/70/materials.html -shane From l2vpn-bounces@ietf.org Wed Dec 05 13:25:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izyvu-0007ka-Hb; Wed, 05 Dec 2007 13:25:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izyvt-0007ju-07 for l2vpn@ietf.org; Wed, 05 Dec 2007 13:25:17 -0500 Received: from audl953.usa.alcatel.com ([143.209.238.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izyvs-0004Ws-6G for l2vpn@ietf.org; Wed, 05 Dec 2007 13:25:16 -0500 Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id lB5IPF30007920 for ; Wed, 5 Dec 2007 12:25:15 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 5 Dec 2007 12:24:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Dec 2007 12:25:56 -0600 Message-ID: <40B2D3B1A8D67246A33D2F5B832C17E7C6CF68@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPLS OAM != .1ag Thread-Index: Acg3bEa6DEWH9HttSPOmJe9257wW6Q== From: "KOMPELLA Vach" To: X-OriginalArrivalTime: 05 Dec 2007 18:24:28.0985 (UTC) FILETIME=[12B42290:01C8376C] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: VPLS OAM != .1ag X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I want to re-iterate that VPLS OAM is not a replacement for .1ag (which neither Ali nor Dan seem to have noticed). In fact, the first slide of my presentation states that it fixes the holes in our analysis of the capabilities provided through .1ag+VCCV (Olen's presentation). In essence, providers are interested in figuring out the mapping of PWs to ethernet MACs, as the MACs are learned, and tracing the consistency of the mapping across the VPLS domain. This specifically covers the MPLS details of the PWs in the VPLS forwarders, which is not covered in .1ag. This also covers the mapping of the FDB to the PWs which is not covered by VCCV. Obviously, this can be (somewhat painfully) achieved by going to individual nodes and using some combinations of .1ag and VCCV, and dumping FDB contents. However, you still have to correlate the failure in the forwarding of .1ag and the state of PWs in a VPLS forwarder reported by VCCV, and the dumping of FDB contents, and putting all that together to get the desired effect. And you are still left with the unsatisfactory feeling that you relied on the output of some tables as opposed to pushing a packet through the suspect forwarding plane entity. Vach Kompella IP Division, Alcatel vach.kompella@alcatel-lucent.com +1 650 623-2556 From l2vpn-bounces@ietf.org Fri Dec 07 17:57:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0m8F-0002tZ-Dc; Fri, 07 Dec 2007 17:57:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0m8D-0002tI-B8 for l2vpn@ietf.org; Fri, 07 Dec 2007 17:57:17 -0500 Received: from eci-iron1.ecitele.com ([147.234.242.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0m8C-00049g-O4 for l2vpn@ietf.org; Fri, 07 Dec 2007 17:57:17 -0500 Received: from ilptexfe.ecitele.com (HELO ilptexch01.ecitele.com) ([172.31.244.40]) by eci-iron1-out.ecitele.com with ESMTP; 08 Dec 2007 01:06:05 +0200 Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.240.5; Sat, 8 Dec 2007 00:57:15 +0200 Received: from USPITMAIL01.ecitele.com ([10.0.0.81]) by ILPTMAIL01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Dec 2007 00:57:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Dec 2007 17:57:11 -0500 Message-ID: <4EF7ED00175A4E4DAE68A5EE31A4F91E588041@USPITMAIL01.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: VPLS OAM != .1ag Thread-Index: Acg5JICErdX5OfYMTTKVAOV8OWEt8w== From: Jeremy Brayley To: , X-OriginalArrivalTime: 07 Dec 2007 22:57:15.0400 (UTC) FILETIME=[82AC6080:01C83924] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: RE: VPLS OAM != .1ag X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Vach, I think you make a useful point about CFM's (802.1ag's) ability to trace MAC address to PW bindings in VPLS. Someone should be able to trace MAC to PW bindings just like MAC to physical Ethernet port bindings. ***from draft-stokes-vkompella-l2vpn-vpls-oam-01.txt - For troubleshooting and validation, it is necessary to know the PW behind which a specific MAC address is located. As CFM entities are not present in intermediate VPLS forwarders in an H- VPLS[L2VPN-CFM], it is not possible to obtain information with such granularity from CFM operations.=20 *** However, I wonder how much of this is due to the VPLS model as presented in RFC 4664. I agree that if an implementation followed this model it would seem that PWs (and their MAC bindings) would be invisible to CFM. You also have to assume that CFM MPs could only be placed on the bridge ports or emulated LAN interface and not associated with the VPLS forwarder. At least I would certainly get that impression from the VPLS model in RFC 4664. But I think there is a different way of modeling VPLS that allows CFM to address the MAC to PW binding issue.=20 In short, why not treat the PWs just like any other port on the bridge module? For example, you can eliminate the separation between the VPLS forwarder and bridge by treating each PW as if it is a separate port on the bridge. You wouldn't need the concept of a VPLS forwarder. And as a bridge port, you would ensure that the PW is visible to CFM. There would be no special requirement to enhance the CFM protocols to support PWs because they look just like ports. Thanks, Jeremy=20 --Vach Kompella writes: I want to re-iterate that VPLS OAM is not a replacement for .1ag (which neither Ali nor Dan seem to have noticed). In fact, the first slide of my presentation states that it fixes the holes in our analysis of the capabilities provided through .1ag+VCCV (Olen's presentation). In essence, providers are interested in figuring out the mapping of PWs to ethernet MACs, as the MACs are learned, and tracing the consistency of the mapping across the VPLS domain. This specifically covers the MPLS details of the PWs in the VPLS forwarders, which is not covered in .1ag. This also covers the mapping of the FDB to the PWs which is not covered by VCCV. Obviously, this can be (somewhat painfully) achieved by going to individual nodes and using some combinations of .1ag and VCCV, and dumping FDB contents. However, you still have to correlate the failure in the forwarding of .1ag and the state of PWs in a VPLS forwarder reported by VCCV, and the dumping of FDB contents, and putting all that together to get the desired effect. And you are still left with the unsatisfactory feeling that you relied on the output of some tables as opposed to pushing a packet through the suspect forwarding plane entity. Vach Kompella IP Division, Alcatel vach.kompella at alcatel-lucent.com +1 650 623-2556 From l2vpn-bounces@ietf.org Fri Dec 07 19:05:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0nBi-0001um-Nq; Fri, 07 Dec 2007 19:04:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0nBg-0001uU-Sg for l2vpn@ietf.org; Fri, 07 Dec 2007 19:04:56 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0nBf-0007p0-7i for l2vpn@ietf.org; Fri, 07 Dec 2007 19:04:56 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Dec 2007 16:04:54 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB804sDv002716; Fri, 7 Dec 2007 16:04:54 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB804sqZ025154; Sat, 8 Dec 2007 00:04:54 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 16:04:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Dec 2007 16:04:45 -0800 Message-ID: <483F121CD2155B43B56DB71228DBAF15A3B106@xmb-sjc-239.amer.cisco.com> In-Reply-To: <40B2D3B1A8D67246A33D2F5B832C17E7C6CF68@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPLS OAM != .1ag Thread-Index: Acg3bEa6DEWH9HttSPOmJe9257wW6QBumSGQ From: "Ali Sajassi (sajassi)" To: "KOMPELLA Vach" , X-OriginalArrivalTime: 08 Dec 2007 00:04:54.0349 (UTC) FILETIME=[F5FED7D0:01C8392D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2639; t=1197072294; x=1197936294; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi@cisco.com; z=From:=20=22Ali=20Sajassi=20(sajassi)=22=20 |Subject:=20RE=3A=20VPLS=20OAM=20!=3D=20.1ag |Sender:=20; bh=XJq39KVoNQrVEwPUubcDNPOrnS0TAofjL4AGoZOT6+s=; b=P8Dy/Hw6aMGPN8PxCtSQq1X1s1Q7XplL4bPxRFrSzySW8X11KWR4NxiXRBdwET3/Kv2Ieibs AgOjwmmv3LlX4qGLPOGEp6ODPQzMfshyn6Np9zl+JvLkh1aZx+x0eV2n; Authentication-Results: sj-dkim-4; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: RE: VPLS OAM != .1ag X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Vach, As I pointed out during the meeting, if you use the right model, then you will see that the combination of 802.1ag with VCCV gives a very good coverage. The problem is that you are starting with a wrong model and your coverage analysis is based on that model - e.g., you are assuming that for H-VPLS w/ MPLS access, the packet does not touch bridge module at n-PE devices and thus 802.1ag doesn't give you coverage on the n-PE. And that is a wrong assumption to begin with.=20 As I mention during the meeting, lets start with the right model and then perform the analysis and see if there is any issues with the coverage of .1ag + VCCV before introducing yet another oam mechanism.=20 I had a chat with Olen to review with him the models in bridge-interop draft and RFC 4664 and take the discussion from there. Cheers, Ali P.S. I will be on PTO starting next week but I am sure there will be tons of discussions before I come back :-) =20 =20 > -----Original Message----- > From: KOMPELLA Vach [mailto:Vach.Kompella@alcatel-lucent.com]=20 > Sent: Wednesday, December 05, 2007 10:26 AM > To: l2vpn@ietf.org > Subject: VPLS OAM !=3D .1ag >=20 > I want to re-iterate that VPLS OAM is not a replacement for=20 > .1ag (which neither Ali nor Dan seem to have noticed). In=20 > fact, the first slide of my presentation states that it fixes=20 > the holes in our analysis of the capabilities provided=20 > through .1ag+VCCV (Olen's presentation). >=20 > In essence, providers are interested in figuring out the=20 > mapping of PWs to ethernet MACs, as the MACs are learned, and=20 > tracing the consistency of the mapping across the VPLS=20 > domain. This specifically covers the MPLS details of the PWs=20 > in the VPLS forwarders, which is not covered in .1ag. This=20 > also covers the mapping of the FDB to the PWs which is not=20 > covered by VCCV. >=20 > Obviously, this can be (somewhat painfully) achieved by going=20 > to individual nodes and using some combinations of .1ag and=20 > VCCV, and dumping FDB contents. However, you still have to=20 > correlate the failure in the forwarding of .1ag and the state=20 > of PWs in a VPLS forwarder reported by VCCV, and the dumping=20 > of FDB contents, and putting all that together to get the=20 > desired effect. And you are still left with the=20 > unsatisfactory feeling that you relied on the output of some=20 > tables as opposed to pushing a packet through the suspect=20 > forwarding plane entity. >=20 > Vach Kompella > IP Division, Alcatel > vach.kompella@alcatel-lucent.com > +1 650 623-2556 >=20 From l2vpn-bounces@ietf.org Fri Dec 07 19:05:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0nCE-00025t-FX; Fri, 07 Dec 2007 19:05:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0nCC-00025n-Rv for l2vpn@ietf.org; Fri, 07 Dec 2007 19:05:28 -0500 Received: from audl751.usa.alcatel.com ([143.209.238.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0nCC-0007rU-4B for l2vpn@ietf.org; Fri, 07 Dec 2007 19:05:28 -0500 Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id lB805Nkq027020; Fri, 7 Dec 2007 18:05:23 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 7 Dec 2007 18:05:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Dec 2007 18:06:54 -0600 Message-ID: <40B2D3B1A8D67246A33D2F5B832C17E7C6D2E0@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <4EF7ED00175A4E4DAE68A5EE31A4F91E588041@USPITMAIL01.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPLS OAM != .1ag Thread-Index: Acg5JICErdX5OfYMTTKVAOV8OWEt8wACPoqg From: "KOMPELLA Vach" To: "Jeremy Brayley" , X-OriginalArrivalTime: 08 Dec 2007 00:05:23.0433 (UTC) FILETIME=[0754B590:01C8392E] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: RE: VPLS OAM != .1ag X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hi Jeremy, We debated this a long time back, and we decided on this model because the group of PWs is a single entity, otherwise it doesn't model the split horizon aspect of a VPLS. For proper operation, the set of PWs have to be all up or the VPLS forwarder is down. We debated whether to model the VPLS as a giant switch with the collection of PWs across all VPLS PEs being the "switch fabric" and the attachment circuits being the ports, and I think that didn't fly. It's a nice abstraction for presenting what a VPLS does, but it is too simplistic to model the bridge component, the PWs and the split horizon requirement on the PWs. -Vach =20 > -----Original Message----- > From: Jeremy Brayley [mailto:Jeremy.Brayley@ecitele.com]=20 > Sent: Friday, December 07, 2007 2:57 PM > To: KOMPELLA Vach; l2vpn@ietf.org > Subject: RE: VPLS OAM !=3D .1ag >=20 > Vach, >=20 > I think you make a useful point about CFM's (802.1ag's)=20 > ability to trace MAC address to PW bindings in VPLS. Someone=20 > should be able to trace MAC to PW bindings just like MAC to=20 > physical Ethernet port bindings. >=20 > ***from draft-stokes-vkompella-l2vpn-vpls-oam-01.txt > - For troubleshooting and validation, it is necessary to know the > PW behind which a specific MAC address is located. As CFM > entities are not present in intermediate VPLS=20 > forwarders in an H- > VPLS[L2VPN-CFM], it is not possible to obtain information with > such granularity from CFM operations.=20 > *** >=20 > However, I wonder how much of this is due to the VPLS model=20 > as presented in RFC 4664. I agree that if an implementation=20 > followed this model it would seem that PWs (and their MAC=20 > bindings) would be invisible to CFM. > You also have to assume that CFM MPs could only be placed on=20 > the bridge ports or emulated LAN interface and not associated=20 > with the VPLS forwarder. At least I would certainly get that=20 > impression from the VPLS model in RFC 4664. >=20 > But I think there is a different way of modeling VPLS that=20 > allows CFM to address the MAC to PW binding issue.=20 >=20 > In short, why not treat the PWs just like any other port on=20 > the bridge module? >=20 > For example, you can eliminate the separation between the=20 > VPLS forwarder and bridge by treating each PW as if it is a=20 > separate port on the bridge. You wouldn't need the concept=20 > of a VPLS forwarder. And as a bridge port, you would ensure=20 > that the PW is visible to CFM. There would be no special=20 > requirement to enhance the CFM protocols to support PWs=20 > because they look just like ports. >=20 > Thanks, >=20 > Jeremy=20 >=20 > --Vach Kompella writes: > I want to re-iterate that VPLS OAM is not a replacement for=20 > .1ag (which neither Ali nor Dan seem to have noticed). In=20 > fact, the first slide of my presentation states that it fixes=20 > the holes in our analysis of the capabilities provided=20 > through .1ag+VCCV (Olen's presentation). >=20 > In essence, providers are interested in figuring out the=20 > mapping of PWs to ethernet MACs, as the MACs are learned, and=20 > tracing the consistency of the mapping across the VPLS=20 > domain. This specifically covers the MPLS details of the PWs=20 > in the VPLS forwarders, which is not covered in .1ag. This=20 > also covers the mapping of the FDB to the PWs which is not=20 > covered by VCCV. >=20 > Obviously, this can be (somewhat painfully) achieved by going=20 > to individual nodes and using some combinations of .1ag and=20 > VCCV, and dumping FDB contents. However, you still have to=20 > correlate the failure in the forwarding of .1ag and the state=20 > of PWs in a VPLS forwarder reported by VCCV, and the dumping=20 > of FDB contents, and putting all that together to get the=20 > desired effect. And you are still left with the=20 > unsatisfactory feeling that you relied on the output of some=20 > tables as opposed to pushing a packet through the suspect=20 > forwarding plane entity. >=20 > Vach Kompella > IP Division, Alcatel > vach.kompella at alcatel-lucent.com > +1 650 623-2556 >=20 >=20 >=20 >=20 From l2vpn-bounces@ietf.org Fri Dec 07 20:15:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0oI0-0008PA-Vl; Fri, 07 Dec 2007 20:15:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0oHz-0008P1-9H for l2vpn@ietf.org; Fri, 07 Dec 2007 20:15:31 -0500 Received: from static-72-71-250-34.cncdnh.fios.verizon.net ([72.71.250.34] helo=lucidvision.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0oHy-0004V9-Qv for l2vpn@ietf.org; Fri, 07 Dec 2007 20:15:31 -0500 Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 741C45F3B2; Fri, 7 Dec 2007 20:15:51 -0500 (EST) Message-Id: From: Thomas Nadeau To: "Ali Sajassi (sajassi)" In-Reply-To: <483F121CD2155B43B56DB71228DBAF15A3B106@xmb-sjc-239.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 7 Dec 2007 20:15:30 -0500 References: <483F121CD2155B43B56DB71228DBAF15A3B106@xmb-sjc-239.amer.cisco.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: KOMPELLA Vach , l2vpn@ietf.org Subject: Re: VPLS OAM != .1ag X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Ali, I totally agree with your point. --Tom > Vach, > > As I pointed out during the meeting, if you use the right model, then > you will see that the combination of 802.1ag with VCCV gives a very > good > coverage. The problem is that you are starting with a wrong model and > your coverage analysis is based on that model - e.g., you are assuming > that for H-VPLS w/ MPLS access, the packet does not touch bridge > module > at n-PE devices and thus 802.1ag doesn't give you coverage on the n- > PE. > And that is a wrong assumption to begin with. > > As I mention during the meeting, lets start with the right model and > then perform the analysis and see if there is any issues with the > coverage of .1ag + VCCV before introducing yet another oam mechanism. > > I had a chat with Olen to review with him the models in bridge-interop > draft and RFC 4664 and take the discussion from there. > > Cheers, > Ali > > P.S. I will be on PTO starting next week but I am sure there will be > tons of discussions before I come back :-) > > > >> -----Original Message----- >> From: KOMPELLA Vach [mailto:Vach.Kompella@alcatel-lucent.com] >> Sent: Wednesday, December 05, 2007 10:26 AM >> To: l2vpn@ietf.org >> Subject: VPLS OAM != .1ag >> >> I want to re-iterate that VPLS OAM is not a replacement for >> .1ag (which neither Ali nor Dan seem to have noticed). In >> fact, the first slide of my presentation states that it fixes >> the holes in our analysis of the capabilities provided >> through .1ag+VCCV (Olen's presentation). >> >> In essence, providers are interested in figuring out the >> mapping of PWs to ethernet MACs, as the MACs are learned, and >> tracing the consistency of the mapping across the VPLS >> domain. This specifically covers the MPLS details of the PWs >> in the VPLS forwarders, which is not covered in .1ag. This >> also covers the mapping of the FDB to the PWs which is not >> covered by VCCV. >> >> Obviously, this can be (somewhat painfully) achieved by going >> to individual nodes and using some combinations of .1ag and >> VCCV, and dumping FDB contents. However, you still have to >> correlate the failure in the forwarding of .1ag and the state >> of PWs in a VPLS forwarder reported by VCCV, and the dumping >> of FDB contents, and putting all that together to get the >> desired effect. And you are still left with the >> unsatisfactory feeling that you relied on the output of some >> tables as opposed to pushing a packet through the suspect >> forwarding plane entity. >> >> Vach Kompella >> IP Division, Alcatel >> vach.kompella@alcatel-lucent.com >> +1 650 623-2556 >> > > From l2vpn-bounces@ietf.org Fri Dec 07 21:17:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0pGD-0005cJ-DR; Fri, 07 Dec 2007 21:17:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0pGC-0005cA-AY for l2vpn@ietf.org; Fri, 07 Dec 2007 21:17:44 -0500 Received: from audl751.usa.alcatel.com ([143.209.238.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0pGB-0006bU-F3 for l2vpn@ietf.org; Fri, 07 Dec 2007 21:17:44 -0500 Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id lB82Hf22022019; Fri, 7 Dec 2007 20:17:41 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 7 Dec 2007 20:17:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83940.8289FB41" Date: Fri, 7 Dec 2007 20:17:41 -0600 Message-ID: <40B2D3B1A8D67246A33D2F5B832C17E70FE8FF@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPLS OAM != .1ag Thread-Index: Acg3bEa6DEWH9HttSPOmJe9257wW6QBumSGQAAZ1zAc= From: "KOMPELLA Vach" To: , X-OriginalArrivalTime: 08 Dec 2007 02:17:41.0653 (UTC) FILETIME=[82E0F450:01C83940] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Subject: Re: VPLS OAM != .1ag X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C83940.8289FB41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QWxpLA0KDQpBcyBJIGhhdmUgcmVwZWF0ZWRseSBzYWlkLCB5b3VyIG1vZGVsIGRvZXNuJ3QgbWFw IE1BQyBhZGRyZXNzZXMgaW4gdGhlIGJyaWRnZSB0byBQV3MgaW4gdGhlIFZQTFMgZm9yd2FyZGVy cy4gIFRoaXMgaXMgZXhwcmVzc2VkIGluIHRoZSBkcmFmdCB0aGF0IE9sZW4gcHJlc2VudGVkLiAN Cg0KSXQgaXMgbm90IGVub3VnaCB0byBzYXkgd2Ugd2lsbCB0ZXN0IHRoZSBmb3J3YXJkaW5nIHRo cm91Z2ggdGhlIGJyaWRnZSBhbmQgdGhlIGZvcndhcmRpbmcgb2YgYW4gaW5kaXZpZHVhbCBQVyB0 byBkZXRlcm1pbmUgdGhlIGNvbXBsZXRlIGZvcndhcmRpbmcgcGF0aC4gWW91IGhhdmUgdG8gaWRl bnRpZnkgdGhlIG1hcHBpbmcgb2YgTUFDIGFkZHJlc3MgdG8gdGhlIGFzc29jaWF0ZWQgUFcgaW4g dGhlIFZQTFMgZm9yd2FyZGVyIC0gc29tZXRoaWluZyBuZWl0aGVyIC4xYWcgbm9yIFZDQ1YgYXJl IGNhcGFibGUgb2YuIA0KDQpJIGhhdmUgdGhlIG1vZGVsIHJpZ2h0LiBJIGRvbid0IHNlZSB5b3Vy IHBvaW50LiANCg0KVG9tLCBpZiB5b3Ugc2VlIHNvbWV0aGluZyBJIGRvbid0LCBjYW4geW91IGV4 cHJlc3MgaXQgYXMgc29tZXRoaW5nIG90aGVyIHRoYW4gInlvdSBoYXZlIHRoZSB3cm9uZyBtb2Rl bC4iLiBJIGhhdmUgZ2l2ZW4gYSBjb25jcmV0ZSBleGFtcGxlIG9mIHdoeSBJIGhhdmUgdGhlIHJp Z2h0IG1vZGVsLiANCg0KSSBob3BlIHRoaXMgaXNuJ3QgaGFya2luZyBiYWNrIHRvIHRoZSBzYW1l IGlzc3VlIHRoYXQgVlBMUy1PQU0gaXNuJ3QgZW5vdWdoIGJlY2F1c2Ugbm8tb25lIGlzIHNheWlu ZyB0aGF0LiAgDQotVmFjaA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBB bGkgU2FqYXNzaSAoc2FqYXNzaSkgPHNhamFzc2lAY2lzY28uY29tPg0KVG86IEtPTVBFTExBIFZh Y2g7IGwydnBuQGlldGYub3JnIDxsMnZwbkBpZXRmLm9yZz4NClNlbnQ6IEZyaSBEZWMgMDcgMTg6 MDQ6NDUgMjAwNw0KU3ViamVjdDogUkU6IFZQTFMgT0FNICE9IC4xYWcNCg0KDQpWYWNoLA0KDQpB cyBJIHBvaW50ZWQgb3V0IGR1cmluZyB0aGUgbWVldGluZywgaWYgeW91IHVzZSB0aGUgcmlnaHQg bW9kZWwsIHRoZW4NCnlvdSB3aWxsIHNlZSB0aGF0IHRoZSBjb21iaW5hdGlvbiBvZiA4MDIuMWFn IHdpdGggVkNDViBnaXZlcyBhIHZlcnkgZ29vZA0KY292ZXJhZ2UuIFRoZSBwcm9ibGVtIGlzIHRo YXQgeW91IGFyZSBzdGFydGluZyB3aXRoIGEgd3JvbmcgbW9kZWwgYW5kDQp5b3VyIGNvdmVyYWdl IGFuYWx5c2lzIGlzIGJhc2VkIG9uIHRoYXQgbW9kZWwgLSBlLmcuLCB5b3UgYXJlIGFzc3VtaW5n DQp0aGF0IGZvciBILVZQTFMgdy8gTVBMUyBhY2Nlc3MsIHRoZSBwYWNrZXQgZG9lcyBub3QgdG91 Y2ggYnJpZGdlIG1vZHVsZQ0KYXQgbi1QRSBkZXZpY2VzIGFuZCB0aHVzIDgwMi4xYWcgZG9lc24n dCBnaXZlIHlvdSBjb3ZlcmFnZSBvbiB0aGUgbi1QRS4NCkFuZCB0aGF0IGlzIGEgd3JvbmcgYXNz dW1wdGlvbiB0byBiZWdpbiB3aXRoLiANCg0KQXMgSSBtZW50aW9uIGR1cmluZyB0aGUgbWVldGlu ZywgbGV0cyBzdGFydCB3aXRoIHRoZSByaWdodCBtb2RlbCBhbmQNCnRoZW4gcGVyZm9ybSB0aGUg YW5hbHlzaXMgYW5kIHNlZSBpZiB0aGVyZSBpcyBhbnkgaXNzdWVzIHdpdGggIHRoZQ0KY292ZXJh Z2Ugb2YgLjFhZyArIFZDQ1YgYmVmb3JlIGludHJvZHVjaW5nIHlldCBhbm90aGVyIG9hbSBtZWNo YW5pc20uIA0KDQpJIGhhZCBhIGNoYXQgd2l0aCBPbGVuIHRvIHJldmlldyB3aXRoIGhpbSB0aGUg bW9kZWxzIGluIGJyaWRnZS1pbnRlcm9wDQpkcmFmdCBhbmQgUkZDIDQ2NjQgYW5kIHRha2UgdGhl IGRpc2N1c3Npb24gZnJvbSB0aGVyZS4NCg0KQ2hlZXJzLA0KQWxpDQoNClAuUy4gSSB3aWxsIGJl IG9uIFBUTyBzdGFydGluZyBuZXh0IHdlZWsgYnV0IEkgYW0gc3VyZSB0aGVyZSB3aWxsIGJlDQp0 b25zIG9mIGRpc2N1c3Npb25zIGJlZm9yZSBJIGNvbWUgYmFjayA6LSkgICAgIA0KDQogDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogS09NUEVMTEEgVmFjaCBbbWFpbHRv OlZhY2guS29tcGVsbGFAYWxjYXRlbC1sdWNlbnQuY29tXSANCj4gU2VudDogV2VkbmVzZGF5LCBE ZWNlbWJlciAwNSwgMjAwNyAxMDoyNiBBTQ0KPiBUbzogbDJ2cG5AaWV0Zi5vcmcNCj4gU3ViamVj dDogVlBMUyBPQU0gIT0gLjFhZw0KPiANCj4gSSB3YW50IHRvIHJlLWl0ZXJhdGUgdGhhdCBWUExT IE9BTSBpcyBub3QgYSByZXBsYWNlbWVudCBmb3IgDQo+IC4xYWcgKHdoaWNoIG5laXRoZXIgQWxp IG5vciBEYW4gc2VlbSB0byBoYXZlIG5vdGljZWQpLiAgSW4gDQo+IGZhY3QsIHRoZSBmaXJzdCBz bGlkZSBvZiBteSBwcmVzZW50YXRpb24gc3RhdGVzIHRoYXQgaXQgZml4ZXMgDQo+IHRoZSBob2xl cyBpbiBvdXIgYW5hbHlzaXMgb2YgdGhlIGNhcGFiaWxpdGllcyBwcm92aWRlZCANCj4gdGhyb3Vn aCAuMWFnK1ZDQ1YgKE9sZW4ncyBwcmVzZW50YXRpb24pLg0KPiANCj4gSW4gZXNzZW5jZSwgcHJv dmlkZXJzIGFyZSBpbnRlcmVzdGVkIGluIGZpZ3VyaW5nIG91dCB0aGUgDQo+IG1hcHBpbmcgb2Yg UFdzIHRvIGV0aGVybmV0IE1BQ3MsIGFzIHRoZSBNQUNzIGFyZSBsZWFybmVkLCBhbmQgDQo+IHRy YWNpbmcgdGhlIGNvbnNpc3RlbmN5IG9mIHRoZSBtYXBwaW5nIGFjcm9zcyB0aGUgVlBMUyANCj4g ZG9tYWluLiAgVGhpcyBzcGVjaWZpY2FsbHkgY292ZXJzIHRoZSBNUExTIGRldGFpbHMgb2YgdGhl IFBXcyANCj4gaW4gdGhlIFZQTFMgZm9yd2FyZGVycywgd2hpY2ggaXMgbm90IGNvdmVyZWQgaW4g LjFhZy4gIFRoaXMgDQo+IGFsc28gY292ZXJzIHRoZSBtYXBwaW5nIG9mIHRoZSBGREIgdG8gdGhl IFBXcyB3aGljaCBpcyBub3QgDQo+IGNvdmVyZWQgYnkgVkNDVi4NCj4gDQo+IE9idmlvdXNseSwg dGhpcyBjYW4gYmUgKHNvbWV3aGF0IHBhaW5mdWxseSkgYWNoaWV2ZWQgYnkgZ29pbmcgDQo+IHRv IGluZGl2aWR1YWwgbm9kZXMgYW5kIHVzaW5nIHNvbWUgY29tYmluYXRpb25zIG9mIC4xYWcgYW5k IA0KPiBWQ0NWLCBhbmQgZHVtcGluZyBGREIgY29udGVudHMuICBIb3dldmVyLCB5b3Ugc3RpbGwg aGF2ZSB0byANCj4gY29ycmVsYXRlIHRoZSBmYWlsdXJlIGluIHRoZSBmb3J3YXJkaW5nIG9mIC4x YWcgYW5kIHRoZSBzdGF0ZSANCj4gb2YgUFdzIGluIGEgVlBMUyBmb3J3YXJkZXIgcmVwb3J0ZWQg YnkgVkNDViwgYW5kIHRoZSBkdW1waW5nIA0KPiBvZiBGREIgY29udGVudHMsIGFuZCBwdXR0aW5n IGFsbCB0aGF0IHRvZ2V0aGVyIHRvIGdldCB0aGUgDQo+IGRlc2lyZWQgZWZmZWN0LiAgQW5kIHlv dSBhcmUgc3RpbGwgbGVmdCB3aXRoIHRoZSANCj4gdW5zYXRpc2ZhY3RvcnkgZmVlbGluZyB0aGF0 IHlvdSByZWxpZWQgb24gdGhlIG91dHB1dCBvZiBzb21lIA0KPiB0YWJsZXMgYXMgb3Bwb3NlZCB0 byBwdXNoaW5nIGEgcGFja2V0IHRocm91Z2ggdGhlIHN1c3BlY3QgDQo+IGZvcndhcmRpbmcgcGxh bmUgZW50aXR5Lg0KPiANCj4gVmFjaCBLb21wZWxsYQ0KPiBJUCBEaXZpc2lvbiwgQWxjYXRlbA0K PiB2YWNoLmtvbXBlbGxhQGFsY2F0ZWwtbHVjZW50LmNvbQ0KPiArMSA2NTAgNjIzLTI1NTYNCj4g DQo= ------_=_NextPart_001_01C83940.8289FB41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTEuNTkiPg0KPFRJVExFPlJlOiBWUExTIE9B TSAhPSAuMWFnPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0 ZXh0L3BsYWluIGZvcm1hdCAtLT4NCg0KPFA+PEZPTlQgU0laRT0yPkFsaSw8QlI+DQo8QlI+DQpB cyBJIGhhdmUgcmVwZWF0ZWRseSBzYWlkLCB5b3VyIG1vZGVsIGRvZXNuJ3QgbWFwIE1BQyBhZGRy ZXNzZXMgaW4gdGhlIGJyaWRnZSB0byBQV3MgaW4gdGhlIFZQTFMgZm9yd2FyZGVycy4mbmJzcDsg VGhpcyBpcyBleHByZXNzZWQgaW4gdGhlIGRyYWZ0IHRoYXQgT2xlbiBwcmVzZW50ZWQuPEJSPg0K PEJSPg0KSXQgaXMgbm90IGVub3VnaCB0byBzYXkgd2Ugd2lsbCB0ZXN0IHRoZSBmb3J3YXJkaW5n IHRocm91Z2ggdGhlIGJyaWRnZSBhbmQgdGhlIGZvcndhcmRpbmcgb2YgYW4gaW5kaXZpZHVhbCBQ VyB0byBkZXRlcm1pbmUgdGhlIGNvbXBsZXRlIGZvcndhcmRpbmcgcGF0aC4gWW91IGhhdmUgdG8g aWRlbnRpZnkgdGhlIG1hcHBpbmcgb2YgTUFDIGFkZHJlc3MgdG8gdGhlIGFzc29jaWF0ZWQgUFcg aW4gdGhlIFZQTFMgZm9yd2FyZGVyIC0gc29tZXRoaWluZyBuZWl0aGVyIC4xYWcgbm9yIFZDQ1Yg YXJlIGNhcGFibGUgb2YuPEJSPg0KPEJSPg0KSSBoYXZlIHRoZSBtb2RlbCByaWdodC4gSSBkb24n dCBzZWUgeW91ciBwb2ludC48QlI+DQo8QlI+DQpUb20sIGlmIHlvdSBzZWUgc29tZXRoaW5nIEkg ZG9uJ3QsIGNhbiB5b3UgZXhwcmVzcyBpdCBhcyBzb21ldGhpbmcgb3RoZXIgdGhhbiAmcXVvdDt5 b3UgaGF2ZSB0aGUgd3JvbmcgbW9kZWwuJnF1b3Q7LiBJIGhhdmUgZ2l2ZW4gYSBjb25jcmV0ZSBl eGFtcGxlIG9mIHdoeSBJIGhhdmUgdGhlIHJpZ2h0IG1vZGVsLjxCUj4NCjxCUj4NCkkgaG9wZSB0 aGlzIGlzbid0IGhhcmtpbmcgYmFjayB0byB0aGUgc2FtZSBpc3N1ZSB0aGF0IFZQTFMtT0FNIGlz bid0IGVub3VnaCBiZWNhdXNlIG5vLW9uZSBpcyBzYXlpbmcgdGhhdC4mbmJzcDs8QlI+DQotVmFj aDxCUj4NCjxCUj4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08QlI+DQpGcm9tOiBBbGkg U2FqYXNzaSAoc2FqYXNzaSkgJmx0O3NhamFzc2lAY2lzY28uY29tJmd0OzxCUj4NClRvOiBLT01Q RUxMQSBWYWNoOyBsMnZwbkBpZXRmLm9yZyAmbHQ7bDJ2cG5AaWV0Zi5vcmcmZ3Q7PEJSPg0KU2Vu dDogRnJpIERlYyAwNyAxODowNDo0NSAyMDA3PEJSPg0KU3ViamVjdDogUkU6IFZQTFMgT0FNICE9 IC4xYWc8QlI+DQo8QlI+DQo8QlI+DQpWYWNoLDxCUj4NCjxCUj4NCkFzIEkgcG9pbnRlZCBvdXQg ZHVyaW5nIHRoZSBtZWV0aW5nLCBpZiB5b3UgdXNlIHRoZSByaWdodCBtb2RlbCwgdGhlbjxCUj4N CnlvdSB3aWxsIHNlZSB0aGF0IHRoZSBjb21iaW5hdGlvbiBvZiA4MDIuMWFnIHdpdGggVkNDViBn aXZlcyBhIHZlcnkgZ29vZDxCUj4NCmNvdmVyYWdlLiBUaGUgcHJvYmxlbSBpcyB0aGF0IHlvdSBh cmUgc3RhcnRpbmcgd2l0aCBhIHdyb25nIG1vZGVsIGFuZDxCUj4NCnlvdXIgY292ZXJhZ2UgYW5h bHlzaXMgaXMgYmFzZWQgb24gdGhhdCBtb2RlbCAtIGUuZy4sIHlvdSBhcmUgYXNzdW1pbmc8QlI+ DQp0aGF0IGZvciBILVZQTFMgdy8gTVBMUyBhY2Nlc3MsIHRoZSBwYWNrZXQgZG9lcyBub3QgdG91 Y2ggYnJpZGdlIG1vZHVsZTxCUj4NCmF0IG4tUEUgZGV2aWNlcyBhbmQgdGh1cyA4MDIuMWFnIGRv ZXNuJ3QgZ2l2ZSB5b3UgY292ZXJhZ2Ugb24gdGhlIG4tUEUuPEJSPg0KQW5kIHRoYXQgaXMgYSB3 cm9uZyBhc3N1bXB0aW9uIHRvIGJlZ2luIHdpdGguPEJSPg0KPEJSPg0KQXMgSSBtZW50aW9uIGR1 cmluZyB0aGUgbWVldGluZywgbGV0cyBzdGFydCB3aXRoIHRoZSByaWdodCBtb2RlbCBhbmQ8QlI+ DQp0aGVuIHBlcmZvcm0gdGhlIGFuYWx5c2lzIGFuZCBzZWUgaWYgdGhlcmUgaXMgYW55IGlzc3Vl cyB3aXRoJm5ic3A7IHRoZTxCUj4NCmNvdmVyYWdlIG9mIC4xYWcgKyBWQ0NWIGJlZm9yZSBpbnRy b2R1Y2luZyB5ZXQgYW5vdGhlciBvYW0gbWVjaGFuaXNtLjxCUj4NCjxCUj4NCkkgaGFkIGEgY2hh dCB3aXRoIE9sZW4gdG8gcmV2aWV3IHdpdGggaGltIHRoZSBtb2RlbHMgaW4gYnJpZGdlLWludGVy b3A8QlI+DQpkcmFmdCBhbmQgUkZDIDQ2NjQgYW5kIHRha2UgdGhlIGRpc2N1c3Npb24gZnJvbSB0 aGVyZS48QlI+DQo8QlI+DQpDaGVlcnMsPEJSPg0KQWxpPEJSPg0KPEJSPg0KUC5TLiBJIHdpbGwg YmUgb24gUFRPIHN0YXJ0aW5nIG5leHQgd2VlayBidXQgSSBhbSBzdXJlIHRoZXJlIHdpbGwgYmU8 QlI+DQp0b25zIG9mIGRpc2N1c3Npb25zIGJlZm9yZSBJIGNvbWUgYmFjayA6LSkmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPEJSPg0KJmd0OyBGcm9tOiBLT01QRUxMQSBWYWNoIFs8QSBIUkVGPSJtYWls dG86VmFjaC5Lb21wZWxsYUBhbGNhdGVsLWx1Y2VudC5jb20iPm1haWx0bzpWYWNoLktvbXBlbGxh QGFsY2F0ZWwtbHVjZW50LmNvbTwvQT5dPEJSPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIERlY2Vt YmVyIDA1LCAyMDA3IDEwOjI2IEFNPEJSPg0KJmd0OyBUbzogbDJ2cG5AaWV0Zi5vcmc8QlI+DQom Z3Q7IFN1YmplY3Q6IFZQTFMgT0FNICE9IC4xYWc8QlI+DQomZ3Q7PEJSPg0KJmd0OyBJIHdhbnQg dG8gcmUtaXRlcmF0ZSB0aGF0IFZQTFMgT0FNIGlzIG5vdCBhIHJlcGxhY2VtZW50IGZvcjxCUj4N CiZndDsgLjFhZyAod2hpY2ggbmVpdGhlciBBbGkgbm9yIERhbiBzZWVtIHRvIGhhdmUgbm90aWNl ZCkuJm5ic3A7IEluPEJSPg0KJmd0OyBmYWN0LCB0aGUgZmlyc3Qgc2xpZGUgb2YgbXkgcHJlc2Vu dGF0aW9uIHN0YXRlcyB0aGF0IGl0IGZpeGVzPEJSPg0KJmd0OyB0aGUgaG9sZXMgaW4gb3VyIGFu YWx5c2lzIG9mIHRoZSBjYXBhYmlsaXRpZXMgcHJvdmlkZWQ8QlI+DQomZ3Q7IHRocm91Z2ggLjFh ZytWQ0NWIChPbGVuJ3MgcHJlc2VudGF0aW9uKS48QlI+DQomZ3Q7PEJSPg0KJmd0OyBJbiBlc3Nl bmNlLCBwcm92aWRlcnMgYXJlIGludGVyZXN0ZWQgaW4gZmlndXJpbmcgb3V0IHRoZTxCUj4NCiZn dDsgbWFwcGluZyBvZiBQV3MgdG8gZXRoZXJuZXQgTUFDcywgYXMgdGhlIE1BQ3MgYXJlIGxlYXJu ZWQsIGFuZDxCUj4NCiZndDsgdHJhY2luZyB0aGUgY29uc2lzdGVuY3kgb2YgdGhlIG1hcHBpbmcg YWNyb3NzIHRoZSBWUExTPEJSPg0KJmd0OyBkb21haW4uJm5ic3A7IFRoaXMgc3BlY2lmaWNhbGx5 IGNvdmVycyB0aGUgTVBMUyBkZXRhaWxzIG9mIHRoZSBQV3M8QlI+DQomZ3Q7IGluIHRoZSBWUExT IGZvcndhcmRlcnMsIHdoaWNoIGlzIG5vdCBjb3ZlcmVkIGluIC4xYWcuJm5ic3A7IFRoaXM8QlI+ DQomZ3Q7IGFsc28gY292ZXJzIHRoZSBtYXBwaW5nIG9mIHRoZSBGREIgdG8gdGhlIFBXcyB3aGlj aCBpcyBub3Q8QlI+DQomZ3Q7IGNvdmVyZWQgYnkgVkNDVi48QlI+DQomZ3Q7PEJSPg0KJmd0OyBP YnZpb3VzbHksIHRoaXMgY2FuIGJlIChzb21ld2hhdCBwYWluZnVsbHkpIGFjaGlldmVkIGJ5IGdv aW5nPEJSPg0KJmd0OyB0byBpbmRpdmlkdWFsIG5vZGVzIGFuZCB1c2luZyBzb21lIGNvbWJpbmF0 aW9ucyBvZiAuMWFnIGFuZDxCUj4NCiZndDsgVkNDViwgYW5kIGR1bXBpbmcgRkRCIGNvbnRlbnRz LiZuYnNwOyBIb3dldmVyLCB5b3Ugc3RpbGwgaGF2ZSB0bzxCUj4NCiZndDsgY29ycmVsYXRlIHRo ZSBmYWlsdXJlIGluIHRoZSBmb3J3YXJkaW5nIG9mIC4xYWcgYW5kIHRoZSBzdGF0ZTxCUj4NCiZn dDsgb2YgUFdzIGluIGEgVlBMUyBmb3J3YXJkZXIgcmVwb3J0ZWQgYnkgVkNDViwgYW5kIHRoZSBk dW1waW5nPEJSPg0KJmd0OyBvZiBGREIgY29udGVudHMsIGFuZCBwdXR0aW5nIGFsbCB0aGF0IHRv Z2V0aGVyIHRvIGdldCB0aGU8QlI+DQomZ3Q7IGRlc2lyZWQgZWZmZWN0LiZuYnNwOyBBbmQgeW91 IGFyZSBzdGlsbCBsZWZ0IHdpdGggdGhlPEJSPg0KJmd0OyB1bnNhdGlzZmFjdG9yeSBmZWVsaW5n IHRoYXQgeW91IHJlbGllZCBvbiB0aGUgb3V0cHV0IG9mIHNvbWU8QlI+DQomZ3Q7IHRhYmxlcyBh cyBvcHBvc2VkIHRvIHB1c2hpbmcgYSBwYWNrZXQgdGhyb3VnaCB0aGUgc3VzcGVjdDxCUj4NCiZn dDsgZm9yd2FyZGluZyBwbGFuZSBlbnRpdHkuPEJSPg0KJmd0OzxCUj4NCiZndDsgVmFjaCBLb21w ZWxsYTxCUj4NCiZndDsgSVAgRGl2aXNpb24sIEFsY2F0ZWw8QlI+DQomZ3Q7IHZhY2gua29tcGVs bGFAYWxjYXRlbC1sdWNlbnQuY29tPEJSPg0KJmd0OyArMSA2NTAgNjIzLTI1NTY8QlI+DQomZ3Q7 PEJSPg0KPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C83940.8289FB41-- From l2vpn-bounces@ietf.org Fri Dec 07 21:24:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0pMW-0000dh-7o; Fri, 07 Dec 2007 21:24:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0pMU-0000dV-Qo for l2vpn@ietf.org; Fri, 07 Dec 2007 21:24:14 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0pMT-0006tG-8R for l2vpn@ietf.org; Fri, 07 Dec 2007 21:24:14 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lB82NLIT010095; Fri, 7 Dec 2007 20:23:22 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 20:23:21 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.20]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Dec 2007 07:53:17 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 8 Dec 2007 07:53:16 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD4241965A5455F@INEXC1U01.in.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPLS OAM != .1ag Thread-Index: Acg3bEa6DEWH9HttSPOmJe9257wW6QBumSGQAASYGs0= References: <483F121CD2155B43B56DB71228DBAF15A3B106@xmb-sjc-239.amer.cisco.com> From: "Dutta, Pranjal Kumar \(Pranjal\)" To: "Ali Sajassi \(sajassi\)" , "KOMPELLA, Vach \(Vach\)" , X-OriginalArrivalTime: 08 Dec 2007 02:23:17.0177 (UTC) FILETIME=[4ADDDA90:01C83941] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: RE: VPLS OAM != .1ag X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Ali, =20 Both draft-stokes-l2vpn-cfm-vccv and = draft-stokes-vkompella-l2vpn-vpls-oam should be evaluated together to = consider the solutions proposed. VCCV alone can do the diagnostics = across the PWs in the VPLS and .1ag mechanisms can be used for = diagnostics of the bridging/MAC aspects.=20 =20 But the issue here is the mapping or inconsistency of packet forwarders = to the PWs - that's the association of the MACs with VPLS transport. In = such issues .1ag verification methods does not provide adequate details. = VCCV diagnostics would declare everything fine as the PW alone is doing = quite well. Then some intuitive debugging through various = forwarding/mapping tables might lead to the issue, provided the problem = is persistent enough. Such intuitive debugging does not help in = troubleshooting transient mapping issues. =20 draft-stokes-vkompella-vpls-oam provides a methodology to diagnose such = issues that can't be covered by .1ag + VCCV together. Again to = re-iterate that it is not a replacement of .1ag.=20 =20 Cheers, Pranjal =20 ________________________________ From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sat 12/8/2007 5:34 AM To: KOMPELLA, Vach (Vach); l2vpn@ietf.org Subject: RE: VPLS OAM !=3D .1ag Vach, As I pointed out during the meeting, if you use the right model, then you will see that the combination of 802.1ag with VCCV gives a very good coverage. The problem is that you are starting with a wrong model and your coverage analysis is based on that model - e.g., you are assuming that for H-VPLS w/ MPLS access, the packet does not touch bridge module at n-PE devices and thus 802.1ag doesn't give you coverage on the n-PE. And that is a wrong assumption to begin with. As I mention during the meeting, lets start with the right model and then perform the analysis and see if there is any issues with the coverage of .1ag + VCCV before introducing yet another oam mechanism. I had a chat with Olen to review with him the models in bridge-interop draft and RFC 4664 and take the discussion from there. Cheers, Ali P.S. I will be on PTO starting next week but I am sure there will be tons of discussions before I come back :-) =20 > -----Original Message----- > From: KOMPELLA Vach [mailto:Vach.Kompella@alcatel-lucent.com] > Sent: Wednesday, December 05, 2007 10:26 AM > To: l2vpn@ietf.org > Subject: VPLS OAM !=3D .1ag > > I want to re-iterate that VPLS OAM is not a replacement for > .1ag (which neither Ali nor Dan seem to have noticed). In > fact, the first slide of my presentation states that it fixes > the holes in our analysis of the capabilities provided > through .1ag+VCCV (Olen's presentation). > > In essence, providers are interested in figuring out the > mapping of PWs to ethernet MACs, as the MACs are learned, and > tracing the consistency of the mapping across the VPLS > domain. This specifically covers the MPLS details of the PWs > in the VPLS forwarders, which is not covered in .1ag. This > also covers the mapping of the FDB to the PWs which is not > covered by VCCV. > > Obviously, this can be (somewhat painfully) achieved by going > to individual nodes and using some combinations of .1ag and > VCCV, and dumping FDB contents. However, you still have to > correlate the failure in the forwarding of .1ag and the state > of PWs in a VPLS forwarder reported by VCCV, and the dumping > of FDB contents, and putting all that together to get the > desired effect. And you are still left with the > unsatisfactory feeling that you relied on the output of some > tables as opposed to pushing a packet through the suspect > forwarding plane entity. > > Vach Kompella > IP Division, Alcatel > vach.kompella@alcatel-lucent.com > +1 650 623-2556 > From l2vpn-bounces@ietf.org Sun Dec 09 17:29:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1Udk-0004kD-EB; Sun, 09 Dec 2007 17:28:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1Udi-0004a6-LC for l2vpn@ietf.org; Sun, 09 Dec 2007 17:28:46 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1Udg-0005fh-VC for l2vpn@ietf.org; Sun, 09 Dec 2007 17:28:46 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Dec 2007 14:28:44 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB9MSiiL015954; Sun, 9 Dec 2007 14:28:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB9MSiqZ002938; Sun, 9 Dec 2007 22:28:44 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Dec 2007 14:28:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83AB2.DB37AA7A" Date: Sun, 9 Dec 2007 14:28:42 -0800 Message-ID: <483F121CD2155B43B56DB71228DBAF15A3B1D7@xmb-sjc-239.amer.cisco.com> In-Reply-To: <40B2D3B1A8D67246A33D2F5B832C17E70FE8FF@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPLS OAM != .1ag Thread-Index: Acg3bEa6DEWH9HttSPOmJe9257wW6QBumSGQAAZ1zAcAW4ZxMA== From: "Ali Sajassi (sajassi)" To: "KOMPELLA Vach" , X-OriginalArrivalTime: 09 Dec 2007 22:28:44.0041 (UTC) FILETIME=[DB733790:01C83AB2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16913; t=1197239324; x=1198103324; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi@cisco.com; z=From:=20=22Ali=20Sajassi=20(sajassi)=22=20 |Subject:=20RE=3A=20VPLS=20OAM=20!=3D=20.1ag |Sender:=20; bh=gO7+oJ8zRlKyJg2De5e9l/Sw/6WbGNwmP/KE+L9dl5M=; b=xUIc2XYtmQlLgOb3pR1aeTgoii412muz/VhNRt+1yeSNyvwutAUxf+alwo2uWzGLS7hxpwam CwBGGJWkmCpjnqbNdb8YOpAbiCsK07sDfTlyeCJsnnij2IjH2xdbCivH; Authentication-Results: sj-dkim-2; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec Cc: Subject: RE: VPLS OAM != .1ag X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C83AB2.DB37AA7A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vach, =20 I think there is a misunderstanding on your part regarding how the model in bridge-interop and RFC 4664 works since you are making some claims listed below that are non-existent if you use the model properly: =20 1) Forwarding at n-PE doesn't go through bridge module at n-PE for H-VPLS with MPLS access (when packet is switched between access and core networks) =20 2) VCCV OAM is not sufficient for multi-segment PW which is used for inter-AS option B and thus we need additional OAM functionality =20 3) 802.1ag + VCCV does not cover MAC address mapping between PWs and VPLS forwarders. =20 Let me go through each with you: =20 1) I hope from all the conversation that we have had so far, it is clear that bridge module is used when doing switching between access and core networks. This was the original intention when I helped the editors to put this model in the RFC 4664. And it is the same model that is used in my bridge-interop draft that has passed WG last call and becoming RFC. This means that 802.1ag can detect and isolate faults not only at the u-PE devices but also at the n-PE devices =20 2) The OAM for multi-segment PW needs to be taken care by PW VCCV. If there is anything missing in this area, then we need to address this using VCCV PW in PWE3 and not coming with yet another mechanism. The scope of this work is outside of VPLS since the multi-segment PW can be directly connected to AC (rather than VSI). =20 3) By having a down MEP at the interface between bridge module and VPLS forwarder, you can cover both VPLS forwarder and the associated PWs such that if there is any issue with either forwarder or PW, you can detect it and isolate the fault accordingly. If you think, there is a scenario, that cannot be covered in terms of fault detection or isolation, please be specific. =20 I am supposed to be on my PTO for next couple of weeks so I won't be checking my emails regardless of how tempting that may be :-) If needed, I like to ask Dinesh to continue this discussion and provide any clarifications that may be needed.=20 =20 Cheers, Ali ________________________________ From: KOMPELLA Vach [mailto:Vach.Kompella@alcatel-lucent.com]=20 Sent: Friday, December 07, 2007 6:18 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Subject: Re: VPLS OAM !=3D .1ag =09 =09 Ali, =09 As I have repeatedly said, your model doesn't map MAC addresses in the bridge to PWs in the VPLS forwarders. This is expressed in the draft that Olen presented. =09 It is not enough to say we will test the forwarding through the bridge and the forwarding of an individual PW to determine the complete forwarding path. You have to identify the mapping of MAC address to the associated PW in the VPLS forwarder - somethiing neither .1ag nor VCCV are capable of. =09 I have the model right. I don't see your point. =09 Tom, if you see something I don't, can you express it as something other than "you have the wrong model.". I have given a concrete example of why I have the right model. =09 I hope this isn't harking back to the same issue that VPLS-OAM isn't enough because no-one is saying that.=20 -Vach =09 ----- Original Message ----- From: Ali Sajassi (sajassi) To: KOMPELLA Vach; l2vpn@ietf.org Sent: Fri Dec 07 18:04:45 2007 Subject: RE: VPLS OAM !=3D .1ag =09 =09 Vach, =09 As I pointed out during the meeting, if you use the right model, then you will see that the combination of 802.1ag with VCCV gives a very good coverage. The problem is that you are starting with a wrong model and your coverage analysis is based on that model - e.g., you are assuming that for H-VPLS w/ MPLS access, the packet does not touch bridge module at n-PE devices and thus 802.1ag doesn't give you coverage on the n-PE. And that is a wrong assumption to begin with. =09 As I mention during the meeting, lets start with the right model and then perform the analysis and see if there is any issues with the coverage of .1ag + VCCV before introducing yet another oam mechanism. =09 I had a chat with Olen to review with him the models in bridge-interop draft and RFC 4664 and take the discussion from there. =09 Cheers, Ali =09 P.S. I will be on PTO starting next week but I am sure there will be tons of discussions before I come back :-) =20 =09 =09 =09 > -----Original Message----- > From: KOMPELLA Vach [mailto:Vach.Kompella@alcatel-lucent.com] > Sent: Wednesday, December 05, 2007 10:26 AM > To: l2vpn@ietf.org > Subject: VPLS OAM !=3D .1ag > > I want to re-iterate that VPLS OAM is not a replacement for > .1ag (which neither Ali nor Dan seem to have noticed). In > fact, the first slide of my presentation states that it fixes > the holes in our analysis of the capabilities provided > through .1ag+VCCV (Olen's presentation). > > In essence, providers are interested in figuring out the > mapping of PWs to ethernet MACs, as the MACs are learned, and > tracing the consistency of the mapping across the VPLS > domain. This specifically covers the MPLS details of the PWs > in the VPLS forwarders, which is not covered in .1ag. This > also covers the mapping of the FDB to the PWs which is not > covered by VCCV. > > Obviously, this can be (somewhat painfully) achieved by going > to individual nodes and using some combinations of .1ag and > VCCV, and dumping FDB contents. However, you still have to > correlate the failure in the forwarding of .1ag and the state > of PWs in a VPLS forwarder reported by VCCV, and the dumping > of FDB contents, and putting all that together to get the > desired effect. And you are still left with the > unsatisfactory feeling that you relied on the output of some > tables as opposed to pushing a packet through the suspect > forwarding plane entity. > > Vach Kompella > IP Division, Alcatel > vach.kompella@alcatel-lucent.com > +1 650 623-2556 > =09 ------_=_NextPart_001_01C83AB2.DB37AA7A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: VPLS OAM !=3D .1ag
Vach,
 
I think there is a misunderstanding on your = part regarding=20 how the model in bridge-interop and RFC 4664 works since you are = making=20 some claims listed below that are non-existent if you use the = model=20 properly:
 
1) Forwarding at n-PE doesn't go = through=20 bridge module at n-PE for H-VPLS with MPLS access (when packet = is=20 switched between access and core networks)
 
2) VCCV OAM is not sufficient for = multi-segment=20 PW which is used for inter-AS option B and thus we need=20  additional OAM functionality
 
3) 802.1ag + VCCV does not cover MAC = address mapping=20 between PWs and VPLS forwarders.
 
Let me go through each with = you:
 
1) I hope from all the conversation that we = have had so=20 far, it is clear that bridge module is used when doing switching between = access=20 and core networks. This was the original intention when I helped the = editors to=20 put this model in the RFC 4664. And it is the same model that is used in = my=20 bridge-interop draft that has passed WG last call and becoming RFC. = This=20 means that 802.1ag can detect and isolate faults not only at the u-PE = devices=20 but also at the n-PE devices
 
2) The OAM for multi-segment PW needs to be = taken care by=20 PW VCCV. If there is anything missing in this area, then we need to = address this=20 using VCCV PW in PWE3 and not coming with yet another mechanism. = The scope=20 of this work is outside of VPLS since the multi-segment PW can be = directly=20 connected to AC (rather than VSI).
 
3) By having a down MEP at the interface = between bridge=20 module and VPLS forwarder, you can cover both VPLS forwarder and the = associated=20 PWs such that if there is any issue with either forwarder or PW, you can = detect=20 it and isolate the fault accordingly. If you think, there is a scenario, = that=20 cannot be covered in terms of fault detection or isolation, please be=20 specific.
 
I am supposed to be on my PTO for next = couple of weeks=20 so I won't be checking my emails regardless of how tempting = that may=20 be :-) If needed, I like to ask Dinesh to continue this discussion = and=20 provide any clarifications that may be needed.
 
Cheers,
Ali

From: KOMPELLA Vach=20 [mailto:Vach.Kompella@alcatel-lucent.com]
Sent: Friday, = December=20 07, 2007 6:18 PM
To: Ali Sajassi (sajassi);=20 l2vpn@ietf.org
Subject: Re: VPLS OAM !=3D = .1ag

Ali,

As I have repeatedly said, your model = doesn't map=20 MAC addresses in the bridge to PWs in the VPLS forwarders.  This = is=20 expressed in the draft that Olen presented.

It is not enough to = say we=20 will test the forwarding through the bridge and the forwarding of an=20 individual PW to determine the complete forwarding path. You have to = identify=20 the mapping of MAC address to the associated PW in the VPLS forwarder = -=20 somethiing neither .1ag nor VCCV are capable of.

I have the = model=20 right. I don't see your point.

Tom, if you see something I = don't, can=20 you express it as something other than "you have the wrong model.". I = have=20 given a concrete example of why I have the right model.

I hope = this=20 isn't harking back to the same issue that VPLS-OAM isn't enough = because no-one=20 is saying that. 
-Vach

----- Original Message = -----
From:=20 Ali Sajassi (sajassi) <sajassi@cisco.com>
To: KOMPELLA Vach;=20 l2vpn@ietf.org <l2vpn@ietf.org>
Sent: Fri Dec 07 18:04:45=20 2007
Subject: RE: VPLS OAM !=3D .1ag


Vach,

As I = pointed out=20 during the meeting, if you use the right model, then
you will see = that the=20 combination of 802.1ag with VCCV gives a very good
coverage. The = problem is=20 that you are starting with a wrong model and
your coverage analysis = is=20 based on that model - e.g., you are assuming
that for H-VPLS w/ = MPLS=20 access, the packet does not touch bridge module
at n-PE devices and = thus=20 802.1ag doesn't give you coverage on the n-PE.
And that is a wrong=20 assumption to begin with.

As I mention during the meeting, lets = start=20 with the right model and
then perform the analysis and see if there = is any=20 issues with  the
coverage of .1ag + VCCV before introducing = yet=20 another oam mechanism.

I had a chat with Olen to review with = him the=20 models in bridge-interop
draft and RFC 4664 and take the discussion = from=20 there.

Cheers,
Ali

P.S. I will be on PTO starting = next week=20 but I am sure there will be
tons of discussions before I come back=20 :-)    



> -----Original=20 Message-----
> From: KOMPELLA Vach [mailto:Vach.Kompella@alc= atel-lucent.com]
>=20 Sent: Wednesday, December 05, 2007 10:26 AM
> To: = l2vpn@ietf.org
>=20 Subject: VPLS OAM !=3D .1ag
>
> I want to re-iterate that = VPLS OAM=20 is not a replacement for
> .1ag (which neither Ali nor Dan seem = to have=20 noticed).  In
> fact, the first slide of my presentation = states=20 that it fixes
> the holes in our analysis of the capabilities=20 provided
> through .1ag+VCCV (Olen's = presentation).
>
> In=20 essence, providers are interested in figuring out the
> mapping = of PWs=20 to ethernet MACs, as the MACs are learned, and
> tracing the = consistency=20 of the mapping across the VPLS
> domain.  This specifically = covers=20 the MPLS details of the PWs
> in the VPLS forwarders, which is = not=20 covered in .1ag.  This
> also covers the mapping of the FDB = to the=20 PWs which is not
> covered by VCCV.
>
> Obviously, = this can=20 be (somewhat painfully) achieved by going
> to individual nodes = and=20 using some combinations of .1ag and
> VCCV, and dumping FDB=20 contents.  However, you still have to
> correlate the = failure in=20 the forwarding of .1ag and the state
> of PWs in a VPLS = forwarder=20 reported by VCCV, and the dumping
> of FDB contents, and putting = all=20 that together to get the
> desired effect.  And you are = still left=20 with the
> unsatisfactory feeling that you relied on the output = of=20 some
> tables as opposed to pushing a packet through the = suspect
>=20 forwarding plane entity.
>
> Vach Kompella
> IP = Division,=20 Alcatel
> vach.kompella@alcatel-lucent.com
> +1 650=20 623-2556
>

------_=_NextPart_001_01C83AB2.DB37AA7A-- From l2vpn-bounces@ietf.org Mon Dec 10 13:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1njx-0001ao-2U; Mon, 10 Dec 2007 13:52:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0zcU-00050F-Mq; Sat, 08 Dec 2007 08:21:26 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0zcS-0004FL-JE; Sat, 08 Dec 2007 08:21:26 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 2C2A632875; Sat, 8 Dec 2007 13:20:54 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1J0zby-00043N-1K; Sat, 08 Dec 2007 08:20:54 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: swallow@cisco.com, loa@pi.se, adrian@olddog.co.uk, dbrungard@att.com, danny@arbor.net, stbryant@cisco.com, Shane.Amante@Level3.com, vach.kompella@alcatel-lucent.com From: Greg Jones (ITU-T SG 15) Message-Id: Date: Sat, 08 Dec 2007 08:20:54 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Mon, 10 Dec 2007 13:52:04 -0500 Cc: mpls@lists.ietf.org, zinin@psg.com, mankin@psg.com, pwe3@ietf.org, sob@harvard.edu, yoichi.maeda@ntt-at.co.jp, l2vpn@ietf.org, matthew.bocci@alcatel-lucent.co.uk, sjtrowbridge@alcatel-lucent.com, jari.arkko@piuha.net, dward@cisco.com, rcallon@juniper.net, townsley@cisco.com, ghani.abbas@ericsson.com Subject: New Liaison Statement, "T-MPLS Ring Protection" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsbsg15@itu.int List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Title: T-MPLS Ring Protection Submission Date: 2007-12-08 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=386 Please reply by 2008-02-11 From: Greg Jones(ITU-T SG 15) To: IETF MPLS, CCAMP, PWE3 and L2VPN(swallow@cisco.com,loa@pi.se,adrian@olddog.co.uk,dbrungard@att.com,danny@arbor.net,stbryant@cisco.com,Shane.Amante@Level3.com,vach.kompella@alcatel-lucent.com) Cc: sob@harvard.edu rcallon@juniper.net dward@cisco.com mpls@lists.ietf.org zinin@psg.com jari.arkko@piuha.net townsley@cisco.com mankin@psg.com matthew.bocci@alcatel-lucent.co.uk pwe3@ietf.org l2vpn@ietf.org yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com ghani.abbas@ericsson.com Reponse Contact: tsbsg15@itu.int Technical Contact: ghani.abbas@ericsson.com Purpose: For comment Body: SG15 Q9 has nearly completed its work on a recommendation for T-MPLS Ring Protection - G.8132. It is targeted to consent this new recommendation in the next SG15 plenary meeting scheduled for Feb., 2008. We have attached the latest draft for your information and comments. Attachment(s): T-MPLS Ring Protection - body text plus attachment (https://datatracker.ietf.org/documents/LIAISON/file502.pdf) From l2vpn-bounces@ietf.org Mon Dec 10 13:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1njw-0001ai-NJ; Mon, 10 Dec 2007 13:52:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0pft-0007F5-SH for l2vpn@ietf.org; Fri, 07 Dec 2007 21:44:17 -0500 Received: from imo-m19.mx.aol.com ([64.12.137.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0pfs-0000Yp-PP for l2vpn@ietf.org; Fri, 07 Dec 2007 21:44:17 -0500 Received: from balavenkata@aim.com by imo-m19.mx.aol.com (mail_out_v38_r9.3.) id l.c13.21f9dd69 (57874) for ; Fri, 7 Dec 2007 21:44:09 -0500 (EST) Received: from webmail-md11 (webmail-md11.webmail.aol.com [64.12.170.129]) by air-ia02.mail.aol.com (v121.4) with ESMTP id MAILINIA24-e212475a04f9212; Fri, 07 Dec 2007 21:44:09 -0500 References: To: l2vpn@ietf.org Date: Fri, 07 Dec 2007 21:44:09 -0500 In-Reply-To: X-MB-Message-Source: WebUI MIME-Version: 1.0 From: Bala Venkata X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com" X-Mailer: AIM WebMail 33060-STANDARD Received: from 76.199.70.100 by webmail-md11.sysops.aol.com (64.12.170.129) with HTTP (WebMailUI); Fri, 07 Dec 2007 21:44:09 -0500 Message-Id: <8CA075B57E0AFAF-93C-25D9@webmail-md11.sysops.aol.com> X-AOL-IP: 64.12.170.129 X-Spam-Flag: NO X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 X-Mailman-Approved-At: Mon, 10 Dec 2007 13:51:58 -0500 Subject: Re: L2vpn Digest, Vol 40, Issue 3 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org ----------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" HI Tom/Kaushik- Is there a newer version of the VPLS MIB that you are working on ? I have cupla mino points regarding the version I see (which seems to have expired): - the section 5 refers to vplsLdpPwBindType for an entry in vplsLdpPwBindTable. Is it supposed to be vplsPwBindType ? - How do you associate a VSI to an on or more ACs & PWs ? Thanks ! /bala -----Original Message----- From: l2vpn-request@ietf.org To: l2vpn@ietf.org Sent: Thu, 16 Aug 2007 9:00 am Subject: L2vpn Digest, Vol 40, Issue 3 Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. I-D ACTION:draft-ietf-l2vpn-vpls-mib-00.txt (Internet-Drafts@ietf.org) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 Aug 2007 15:15:01 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mib-00.txt To: i-d-announce@ietf.org Cc: l2vpn@ietf.org Message-ID: Content-Type: text/plain; charset="us-ascii" A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Virtual Private Lan Services (VPLS) Management Information Base Author(s) : T. Nadeau, K. Koushik Filename : draft-ietf-l2vpn-vpls-mib-00.txt Pages : 39 Date : 2007-8-15 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Virtual Private LAN services. It needs to be used in conjunction with Pswudo Wire (PW) Management Information Base [PWE3-PW-MIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-vpls-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-vpls-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www1.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 40, Issue 3 ************************************ ________________________________________________________________________ More new features than ever. Check out the new AIM(R) Mail ! - http://o.aolcdn.com/cdn.webmail.aol.com/mailtour/aol/en-us/text.htm?ncid=aimcmp00050000000001 ----------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii" HI Tom/Kaushik-

Is there a newer version of the VPLS MIB that you are working on ? I have cupla
mino points regarding the version I see (which seems to have expired):

- the section 5 refers to vplsLdpPwBindType for an entry in vplsLdpPwBindTable. Is it supposed to be vplsPwBindType ?
- How do you associate a VSI to an on or more ACs & PWs ?


Thanks !

/bala


-----Original Message-----
From: l2vpn-request@ietf.org
To: l2vpn@ietf.org
Sent: Thu, 16 Aug 2007 9:00 am
Subject: L2vpn Digest, Vol 40, Issue 3

Send L2vpn mailing list submissions to

    l2vpn@ietf.org



To subscribe or unsubscribe via the World Wide Web, visit

    https://www1.ietf.org/mailman/listinfo/l2vpn

or, via email, send a message with subject or body 'help' to

    l2vpn-request@ietf.org



You can reach the person managing the list at

    l2vpn-owner@ietf.org



When replying, please edit your Subject line so it is more specific

than "Re: Contents of L2vpn digest..."





Today's Topics:



   1. I-D ACTION:draft-ietf-l2vpn-vpls-mib-00.txt 

      (Internet-Drafts@ietf.org)





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



Message: 1

Date: Wed, 15 Aug 2007 15:15:01 -0400

From: Internet-Drafts@ietf.org

Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mib-00.txt 

To: i-d-announce@ietf.org

Cc: l2vpn@ietf.org

Message-ID: <E1ILOKb-0000TV-Pm@stiedprstage1.ietf.org>

Content-Type: text/plain; charset="us-ascii"



A New Internet-Draft is available from the on-line Internet-Drafts 

directories.

This draft is a work item of the Layer 2 Virtual Private Networks Working Group 

of the IETF.



    Title       : Virtual Private Lan Services (VPLS) Management Information 

Base

    Author(s)   : T. Nadeau, K. Koushik

    Filename    : draft-ietf-l2vpn-vpls-mib-00.txt

    Pages       : 39

    Date        : 2007-8-15

    

    This memo defines an experimental portion of the Management

    Information Base for use with network management protocols in the

    Internet community.  In particular, it describes managed objects

    for modeling of Virtual Private LAN services. It needs to be used

    in conjunction with Pswudo Wire (PW) Management Information Base

    [PWE3-PW-MIB].     



A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mib-00.txt



To remove yourself from the I-D Announcement list, send a message to 

i-d-announce-request@ietf.org with the word unsubscribe in the body of 

the message. 

You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 

to change your subscription settings.



Internet-Drafts are also available by anonymous FTP. Login with the 

username "anonymous" and a password of your e-mail address. After 

logging in, type "cd internet-drafts" and then 

"get draft-ietf-l2vpn-vpls-mib-00.txt".



A list of Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html 

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



Internet-Drafts can also be obtained by e-mail.



Send a message to:

    mailserv@ietf.org.

In the body type:

    "FILE /internet-drafts/draft-ietf-l2vpn-vpls-mib-00.txt".

    

NOTE:   The mail server at ietf.org can return the document in

    MIME-encoded form by using the "mpack" utility.  To use this

    feature, insert the command "ENCODING mime" before the "FILE"

    command.  To decode the response(s), you will need "munpack" or

    a MIME-compliant mail reader.  Different MIME-compliant mail readers

    exhibit different behavior, especially when dealing with

    "multipart" MIME messages (i.e. documents which have been split

    up into multiple messages), so check your local documentation on

    how to manipulate these messages.



Below is the data which will enable a MIME compliant mail reader

implementation to automatically retrieve the ASCII version of the

Internet-Draft.

-------------- next part --------------

Skipped content of type multipart/alternative



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



_______________________________________________

L2vpn mailing list

L2vpn@ietf.org

https://www1.ietf.org/mailman/listinfo/l2vpn





End of L2vpn Digest, Vol 40, Issue 3

************************************
More new features than ever. Check out the new AIM(R) Mail!
----------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com-- From l2vpn-bounces@ietf.org Mon Dec 10 13:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1njw-0001ac-A2; Mon, 10 Dec 2007 13:52:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgQ8-0002sC-VP; Thu, 15 Nov 2007 10:14:20 -0500 Received: from [2001:14b8:400:101::2] (helo=n2.nomadiclab.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsgQ6-0008Bu-Oj; Thu, 15 Nov 2007 10:14:20 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1AD631EFE58; Thu, 15 Nov 2007 17:14:18 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9492A1EFE56; Thu, 15 Nov 2007 17:14:17 +0200 (EET) Message-ID: <473C6247.9080309@nomadiclab.com> Date: Thu, 15 Nov 2007 17:14:15 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Gen-ART Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Mon, 10 Dec 2007 13:51:54 -0500 Cc: l2vpn@ietf.org, Shane.Amante@Level3.com, yetik_serbest@labs.att.com, yuichiro.wada@ntt.com, y.kamite@ntt.com, thomas.morin@francetelecom.com, Jari Arkko , Mark Townsley , lufang@cisco.com, vach.kompella@alcatel.com Subject: Gen-ART Review of draft-ietf-l2vpn-vpls-mcast-reqts-05 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document..........: draft-ietf-l2vpn-vpls-mcast-reqts-05 Reviewer..........: Christian Vogt Review date.......: Nov 15, 2007 IESG Telechat date: -- Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: (1) Section 4.1.2, "Multicast Packet Types", says: Since the mapping between IPv4 multicast addresses and Ethernet layer multicast addresses is ambiguous (i.e., multiplicity of 1 Ethernet address to 32 IP addresses), MAC-based multicast forwarding is not ideal for IP multicast. Would be good to provide some rationale here. It seems that the non-injective mapping from IP addresses to MAC addresses does not limit scalability, provided the solution tracks IP addresses rather than MAC addresses. It also does not seem to have an impact on security. The worst that could happen would be that some hosts receive packets they are not interested in. Another undesired feature might be that network administration becomes slightly more complicated. But the reader is left out in the rain here. Giving some rationale would certainly help. (2) Section 4.3, "Backward Compatibility", says: A solution SHOULD be backward compatible with the existing VPLS solution. It SHOULD allow a case where a common VPLS instance is composed of both PEs supporting the solution and PEs not supporting it, and the multicast forwarding enhancement is partially achieved by the compliant PEs. The last sentence here should be "achieved *between* the compliant PEs" because coordination will probably be required between the forwarding side and the receiving side, thus requiring upgrades on both sides. The current text talks about the forwarding side only and so makes the requirement more (IMO too much) ambitious. (3) Section 5.10, "Fate-Sharing...": I don't see a reason for this section's claim that unicast and multicast should always be either both up or both down. The section currently calls for deliberate de-activation of one transmission method in case the other transmission method fails. Is there any reason why a customer or a provider might benefit from such policy? -- I think section 5.10 be removed from the draft. (4) Section 5.6, "Access Connectivity", should IMO be split into an "Access Connectivity" section comprising the currently first paragraph, and a "Multi-Homing" section comprising the rest. (5) Editorial Section 1.1., 6th paragraph: "VPLS PEs" is an unknown acronym at this point. Section 2.1: "- Multicast Channel: (S,G) in the SSM model" -- So "multicast channel" is an SSM-specific term and is undefined for ASM? Section 3.2, 1st paragraph: "ingress PE" -- Is this the U-PE or the N-PE? Section 3.3.1, "Native Ethernet service aspect": s/Their main interest is how to deal with the issue/Their main interest is solve the issue/ Section 3.3.1, "IP multicast service aspect": s/Their main interest is how to provide/Their main interest is to provide/ Section 4.1.1.1: "Issues A and B" appeared long before, so better add a page/section number in parentheses as a reference. Hope this helps. - Christian From l2vpn-bounces@ietf.org Mon Dec 10 13:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1njx-0001ao-2U; Mon, 10 Dec 2007 13:52:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0zcU-00050F-Mq; Sat, 08 Dec 2007 08:21:26 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0zcS-0004FL-JE; Sat, 08 Dec 2007 08:21:26 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 2C2A632875; Sat, 8 Dec 2007 13:20:54 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1J0zby-00043N-1K; Sat, 08 Dec 2007 08:20:54 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: swallow@cisco.com, loa@pi.se, adrian@olddog.co.uk, dbrungard@att.com, danny@arbor.net, stbryant@cisco.com, Shane.Amante@Level3.com, vach.kompella@alcatel-lucent.com From: Greg Jones (ITU-T SG 15) Message-Id: Date: Sat, 08 Dec 2007 08:20:54 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Mon, 10 Dec 2007 13:52:04 -0500 Cc: mpls@lists.ietf.org, zinin@psg.com, mankin@psg.com, pwe3@ietf.org, sob@harvard.edu, yoichi.maeda@ntt-at.co.jp, l2vpn@ietf.org, matthew.bocci@alcatel-lucent.co.uk, sjtrowbridge@alcatel-lucent.com, jari.arkko@piuha.net, dward@cisco.com, rcallon@juniper.net, townsley@cisco.com, ghani.abbas@ericsson.com Subject: New Liaison Statement, "T-MPLS Ring Protection" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsbsg15@itu.int List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Title: T-MPLS Ring Protection Submission Date: 2007-12-08 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=386 Please reply by 2008-02-11 From: Greg Jones(ITU-T SG 15) To: IETF MPLS, CCAMP, PWE3 and L2VPN(swallow@cisco.com,loa@pi.se,adrian@olddog.co.uk,dbrungard@att.com,danny@arbor.net,stbryant@cisco.com,Shane.Amante@Level3.com,vach.kompella@alcatel-lucent.com) Cc: sob@harvard.edu rcallon@juniper.net dward@cisco.com mpls@lists.ietf.org zinin@psg.com jari.arkko@piuha.net townsley@cisco.com mankin@psg.com matthew.bocci@alcatel-lucent.co.uk pwe3@ietf.org l2vpn@ietf.org yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com ghani.abbas@ericsson.com Reponse Contact: tsbsg15@itu.int Technical Contact: ghani.abbas@ericsson.com Purpose: For comment Body: SG15 Q9 has nearly completed its work on a recommendation for T-MPLS Ring Protection - G.8132. It is targeted to consent this new recommendation in the next SG15 plenary meeting scheduled for Feb., 2008. We have attached the latest draft for your information and comments. Attachment(s): T-MPLS Ring Protection - body text plus attachment (https://datatracker.ietf.org/documents/LIAISON/file502.pdf) From l2vpn-bounces@ietf.org Mon Dec 10 13:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1njw-0001ai-NJ; Mon, 10 Dec 2007 13:52:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0pft-0007F5-SH for l2vpn@ietf.org; Fri, 07 Dec 2007 21:44:17 -0500 Received: from imo-m19.mx.aol.com ([64.12.137.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0pfs-0000Yp-PP for l2vpn@ietf.org; Fri, 07 Dec 2007 21:44:17 -0500 Received: from balavenkata@aim.com by imo-m19.mx.aol.com (mail_out_v38_r9.3.) id l.c13.21f9dd69 (578From l2vpn-bounces@ietf.org Mon Dec 10 13:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1njx-0001ao-2U; Mon, 10 Dec 2007 13:52:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0zcU-00050F-Mq; Sat, 08 Dec 2007 08:21:26 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0zcS-0004FL-JE; Sat, 08 Dec 2007 08:21:26 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 2C2A632875; Sat, 8 Dec 2007 13:20:54 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1J0zby-00043N-1K; Sat, 08 Dec 2007 08:20:54 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: swallow@cisco.com, loa@pi.se, adrian@olddog.co.uk, dbrungard@att.com, danny@arbor.net, stbryant@cisco.com, Shane.Amante@Level3.com, vach.kompella@alcatel-lucent.com From: Greg Jones (ITU-T SG 15) Message-Id: Date: Sat, 08 Dec 2007 08:20:54 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Mon, 10 Dec 2007 13:52:04 -0500 Cc: mpls@lists.ietf.org, zinin@psg.com, mankin@psg.com, pwe3@ietf.org, sob@harvard.edu, yoichi.maeda@ntt-at.co.jp, l2vpn@ietf.org, matthew.bocci@alcatel-lucent.co.uk, sjtrowbridge@alcatel-lucent.com, jari.arkko@piuha.net, dward@cisco.com, rcallon@juniper.net, townsley@cisco.com, ghani.abbas@ericsson.com Subject: New Liaison Statement, "T-MPLS Ring Protection" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsbsg15@itu.int List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Title: T-MPLS Ring Protection Submission Date: 2007-12-08 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=386 Please reply by 2008-02-11 From: Greg Jones(ITU-T SG 15) To: IETF MPLS, CCAMP, PWE3 and L2VPN(swallow@cisco.com,loa@pi.se,adrian@olddog.co.uk,dbrungard@att.com,danny@arbor.net,stbryant@cisco.com,Shane.Amante@Level3.com,vach.kompella@alcatel-lucent.com) Cc: sob@harvard.edu rcallon@juniper.net dward@cisco.com mpls@lists.ietf.org zinin@psg.com jari.arkko@piuha.net townsley@cisco.com mankin@psg.com matthew.bocci@alcatel-lucent.co.uk pwe3@ietf.org l2vpn@ietf.org yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com ghani.abbas@ericsson.com Reponse Contact: tsbsg15@itu.int Technical Contact: ghani.abbas@ericsson.com Purpose: For comment Body: SG15 Q9 has nearly completed its work on a recommendation for T-MPLS Ring Protection - G.8132. It is targeted to consent this new recommendation in the next SG15 plenary meeting scheduled for Feb., 2008. We have attached the latest draft for your information and comments. Attachment(s): T-MPLS Ring Protection - body text plus attachment (https://datatracker.ietf.org/documents/LIAISON/file502.pdf) From l2vpn-bounces@ietf.org Mon Dec 10 13:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1njw-0001ai-NJ; Mon, 10 Dec 2007 13:52:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0pft-0007F5-SH for l2vpn@ietf.org; Fri, 07 Dec 2007 21:44:17 -0500 Received: from imo-m19.mx.aol.com ([64.12.137.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0pfs-0000Yp-PP for l2vpn@ietf.org; Fri, 07 Dec 2007 21:44:17 -0500 Received: from balavenkata@aim.com by imo-m19.mx.aol.com (mail_out_v38_r9.3.) id l.c13.21f9dd69 (57874) for ; Fri, 7 Dec 2007 21:44:09 -0500 (EST) Received: from webmail-md11 (webmail-md11.webmail.aol.com [64.12.170.129]) by air-ia02.mail.aol.com (v121.4) with ESMTP id MAILINIA24-e212475a04f9212; Fri, 07 Dec 2007 21:44:09 -0500 References: To: l2vpn@ietf.org Date: Fri, 07 Dec 2007 21:44:09 -0500 In-Reply-To: X-MB-Message-Source: WebUI MIME-Version: 1.0 From: Bala Venkata X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com" X-Mailer: AIM WebMail 33060-STANDARD Received: from 76.199.70.100 by webmail-md11.sysops.aol.com (64.12.170.129) with HTTP (WebMailUI); Fri, 07 Dec 2007 21:44:09 -0500 Message-Id: <8CA075B57E0AFAF-93C-25D9@webmail-md11.sysops.aol.com> X-AOL-IP: 64.12.170.129 X-Spam-Flag: NO X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 X-Mailman-Approved-At: Mon, 10 Dec 2007 13:51:58 -0500 Subject: Re: L2vpn Digest, Vol 40, Issue 3 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org ----------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" HI Tom/Kaushik- Is there a newer version of the VPLS MIB that you are working on ? I have cupla mino points regarding the version I see (which seems to have expired): - the section 5 refers to vplsLdpPwBindType for an entry in vplsLdpPwBindTable. Is it supposed to be vplsPwBindType ? - How do you associate a VSI to an on or more ACs & PWs ? Thanks ! /bala -----Original Message----- From: l2vpn-request@ietf.org To: l2vpn@ietf.org Sent: Thu, 16 Aug 2007 9:00 am Subject: L2vpn Digest, Vol 40, Issue 3 Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. I-D ACTION:draft-ietf-l2vpn-vpls-mib-00.txt (Internet-Drafts@ietf.org) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 Aug 2007 15:15:01 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mib-00.txt To: i-d-announce@ietf.org Cc: l2vpn@ietf.org Message-ID: Content-Type: text/plain; charset="us-ascii" A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Virtual Private Lan Services (VPLS) Management Information Base Author(s) : T. Nadeau, K. Koushik Filename : draft-ietf-l2vpn-vpls-mib-00.txt Pages : 39 Date : 2007-8-15 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Virtual Private LAN services. It needs to be used in conjunction with Pswudo Wire (PW) Management Information Base [PWE3-PW-MIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe i74) for ; Fri, 7 Dec 2007 21:44:09 -0500 (EST) Received: from webmail-md11 (webmail-md11.webmail.aol.com [64.12.170.129]) by air-ia02.mail.aol.com (v121.4) with ESMTP id MAILINIA24-e212475a04f9212; Fri, 07 Dec 2007 21:44:09 -0500 References: To: l2vpn@ietf.org Date: Fri, 07 Dec 2007 21:44:09 -0500 In-Reply-To: X-MB-Message-Source: WebUI MIME-Version: 1.0 From: Bala Venkata X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com" X-Mailer: AIM WebMail 33060-STANDARD Received: from 76.199.70.100 by webmail-md11.sysops.aol.com (64.12.170.129) with HTTP (WebMailUI); Fri, 07 Dec 2007 21:44:09 -0500 Message-Id: <8CA075B57E0AFAF-93C-25D9@webmail-md11.sysops.aol.com> X-AOL-IP: 64.12.170.129 X-Spam-Flag: NO X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 X-Mailman-Approved-At: Mon, 10 Dec 2007 13:51:58 -0500 Subject: Re: L2vpn Digest, Vol 40, Issue 3 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org ----------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" HI Tom/Kaushik- Is there a newer version of the VPLS MIB that you are working on ? I have cupla mino points regarding the version I see (which seems to have expired): - the section 5 refers to vplsLdpPwBindType for an entry in vplsLdpPwBindTable. Is it supposed to be vplsPwBindType ? - How do you associate a VSI to an on or more ACs & PWs ? Thanks ! /bala -----Original Message----- From: l2vpn-request@ietf.org To: l2vpn@ietf.org Sent: Thu, 16 Aug 2007 9:00 am Subject: L2vpn Digest, Vol 40, Issue 3 Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. I-D ACTION:draft-ietf-l2vpn-vpls-mib-00.txt (Internet-Drafts@ietf.org) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 Aug 2007 15:15:01 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mib-00.txt To: i-d-announce@ietf.org Cc: l2vpn@ietf.org Message-ID: Content-Type: text/plain; charset="us-ascii" A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Virtual Private Lan Services (VPLS) Management Information Base Author(s) : T. Nadeau, K. Koushik Filename : draft-ietf-l2vpn-vpls-mib-00.txt Pages : 39 Date : 2007-8-15 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Virtual Private LAN services. It needs to be used in conjunction with Pswudo Wire (PW) Management Information Base [PWE3-PW-MIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-vpls-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-vpls-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www1.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 40, Issue 3 ************************************ ________________________________________________________________________ More new features than ever. Check out the new AIM(R) Mail ! - http://o.aolcdn.com/cdn.webmail.aol.com/mailtour/aol/en-us/text.htm?ncid=aimcmp00050000000001 ----------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii" HI Tom/Kaushik-

Is there a newer version of the VPLS MIB that you are working on ? I have cupla
mino points regarding the version I see (which seems to have expired):

- the section 5 refers to vplsLdpPwBindType for an entry in vplsLdpPwBindTable. Is it supposed to be vplsPwBindType ?
- How do you associate a VSI to an on or more ACs & PWs ?


Thanks !

/bala


-----Original Message-----
From: l2vpn-request@ietf.org
To: l2vpn@ietf.org
Sent: Thu, 16 Aug 2007 9:00 am
Subject: L2vpn Digest, Vol 40, Issue 3

Send L2vpn mailing list submissions to

    l2vpn@ietf.org



To subscribe or unsubscribe via the World Wide Web, visit

    https://www1.ietf.org/mailman/listinfo/l2vpn

or, via email, send a message with subject or body 'help' to

    l2vpn-request@ietf.org



You can reach the person managing the list at

    l2vpn-owner@ietf.org



When replying, please edit your Subject line so it is more specific

than "Re: Contents of L2vpn digest..."





Today's Topics:



   1. I-D ACTION:draft-ietf-l2vpn-vpls-mib-00.txt 

      (Internet-Drafts@ietf.org)





----------------------------------------------------------------------n the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-l2vpn-vpls-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
    mailserv@ietf.org.
In the body type:
    "FILE /internet-drafts/draft-ietf-l2vpn-vpls-mib-00.txt".
    
NOTE:   The mail server at ietf.org can return the document in
    MIME-encoded form by using the "mpack" utility.  To use this
    feature, insert the command "ENCODING mime" before the "FILE"
    command.  To decode the response(s), you will need "munpack" or
    a MIME-compliant mail reader.  Different MIME-compliant mail readers
    exhibit different behavior, especially when dealing with
    "multipart" MIME messages (i.e. documents which have been split
    up into multiple messages), so check your local documentation on
    how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
Skipped content of type multipart/alternative

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

_______________________________________________
L2vpn mailing list
L2vpn@ietf.org
https://www1.ietf.org/mailman/listinfo/l2vpn


End of L2vpn Digest, Vol 40, Issue 3
************************************



 


________________________________________________________________________
More new features than ever.  Check out the new AIM(R) Mail ! - http://o.aolcdn.com/cdn.webmail.aol.com/mailtour/aol/en-us/text.htm?ncid=aimcmp00050000000001

----------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="us-ascii"

HI Tom/Kaushik-



Is there a newer version of the VPLS MIB that you are working on ? I have cupla

mino points regarding the version I see (which seems to have expired):



- the section 5 refers to vplsLdpPwBindType for an entry in vplsLdpPwBindTable. Is it supposed to be vplsPwBindType ?

- How do you associate a VSI to an on or more ACs & PWs ?





Thanks !



/bala



 





 



-----Original Message-----

From: l2vpn-request@ietf.org

To: l2vpn@ietf.org

Sent: Thu, 16 Aug 2007 9:00 am

Subject: L2vpn Digest, Vol 40, Issue 3













Send L2vpn mailing list submissions to

    l2vpn@ietf.org



To subscribe or unsubscribe via the World Wide Web, visit

    https://www1.ietf.org/mailman/listinfo/l2vpn

or, via email, send a message with subject or body 'help' to

    l2vpn-request@ietf.org



You can reach the person managing the list at

    l2vpn-owner@ietf.org



When replying, please edit your Subject line so it is more specific

than "Re: Contents of L2vpn digest..."





Today's Topics:



   1. I-D ACTION:draft-ietf-l2vpn-vpls-mib-00.txt 

      (Internet-Drafts@ietf.org)





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



Message: 1

Date: Wed, 15 Aug 2007 15:15:01 -0400

From: Internet-Drafts@ietf.org

Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mib-00.txt 

To: i-d-announce@ietf.org

Cc: l2vpn@ietf.org

Message-ID: <E1ILOKb-0000TV-Pm@stiedprstage1.ietf.org>

Content-Type: text/plain; charset="us-ascii"



A New Internet-Draft is available from the on-line Internet-Drafts 

directories.

This draft is a work item of the Layer 2 Virtual Private Networks Working Group 

of the IETF.



    Title       : Virtual Private Lan Services (VPLS) Management Information 

Base

    Author(s)   : T. Nadeau, K. Koushik

    Filename    : draft-ietf-l2vpn-vpls-mib-00.txt

    Pages       : 39

    Date        : 2007-8-15

    

    This memo defines an experimental portion of the Management

    Information Base for use with network management protocols in the

    Internet community.  In particular, it describes managed objects

    for modeling of Virtual Private LAN services. It needs to be used

    in conjunction with Pswudo Wire (PW) Management Information Base

    [PWE3-PW-MIB].     



A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mib-00.txt



To remove yourself from the I-D Announcement list, send a message to 

i-d-announce-request@ietf.org with the word unsubscribe in the body of 

the message. 

You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 

to change your subscription settings.



Internet-Drafts are also available by anonymous FTP. Login with the 

username "anonymous" and a password of your e-mail address. After 

logging in, type "cd internet-drafts" and then 

"get draft-ietf-l2vpn-vpls-mib-00.txt".



A list of Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html 

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



Internet-Drafts can also be obtained by e-mail.



Send a message to:

    mailserv@ietf.org.

In the body type:

    "FILE /internet-drafts/draft-ietf-l2vpn-vpls-mib-00.txt".

    

NOTE:   The mail server at ietf.org can return the document in

    MIME-encoded form by using the "mpack" utility.  To use this

    feature, insert the command "ENCODING mime" before the "FILE"

    command.  To decode the response(s), you will need "munpack" or

    a MIME-compliant mail reader.  Different MIME-compliant mail readers

    exhibit different behavior, especially when dealing with

    "multipart" MIME messages (i.e. documents which have been split

    up into multiple messages), so check your local documentation on

    how to manipulate these messages.



Below is the data which will enable a MIME compliant mail reader

implementation to automatically retrieve the ASCII version of the

Internet-Draft.

-------------- next part --------------

Skipped content of type multipart/alternative



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



_______________________________________________

L2vpn mailing list

L2vpn@ietf.org

https://www1.ietf.org/mailman/listinfo/l2vpn





End of L2vpn Digest, Vol 40, Issue 3

************************************





 





More new features than ever.  Check out the new AIM(R) Mail!




----------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com--






From l2vpn-bounces@ietf.org Mon Dec 10 13:52:33 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1njw-0001ac-A2; Mon, 10 Dec 2007 13:52:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsgQ8-0002sC-VP; Thu, 15 Nov 2007 10:14:20 -0500
Received: from [2001:14b8:400:101::2] (helo=n2.nomadiclab.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IsgQ6-0008Bu-Oj; Thu, 15 Nov 2007 10:14:20 -0500
Received: from n2.nomadiclab.com (localhost [127.0.0.1])
	by n2.nomadiclab.com (Postfix) with ESMTP id 1AD631EFE58;
	Thu, 15 Nov 2007 17:14:18 +0200 (EET)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by n2.nomadiclab.com (Postfix) with ESMTP id 9492A1EFE56;
	Thu, 15 Nov 2007 17:14:17 +0200 (EET)
Message-ID: <473C6247.9080309@nomadiclab.com>
Date: Thu, 15 Nov 2007 17:14:15 +0200
From: Christian Vogt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
	rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Gen-ART Mailing List 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: -1.4 (-)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
X-Mailman-Approved-At: Mon, 10 Dec 2007 13:51:54 -0500
Cc: l2vpn@ietf.org, Shane.Amante@Level3.com, yetik_serbest@labs.att.com,
	yuichiro.wada@ntt.com, y.kamite@ntt.com, thomas.morin@francetelecom.com,
	Jari Arkko ,
	Mark Townsley , lufang@cisco.com,
	vach.kompella@alcatel.com
Subject: Gen-ART Review of draft-ietf-l2vpn-vpls-mcast-reqts-05
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: l2vpn-bounces@ietf.org

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.


Document..........:  draft-ietf-l2vpn-vpls-mcast-reqts-05
Reviewer..........:  Christian Vogt
Review date.......:  Nov 15, 2007
IESG Telechat date:  --


Summary:  This draft is basically ready for publication, but has nits
           that should be fixed before publication.

Comments:

(1)  Section 4.1.2, "Multicast Packet Types", says:

                                             Since the mapping between
    IPv4 multicast addresses and Ethernet layer multicast addresses is
    ambiguous (i.e., multiplicity of 1 Ethernet address to 32 IP
    addresses), MAC-based multicast forwarding is not ideal for IP
    multicast.

Would be good to provide some rationale here.  It seems that the
non-injective mapping from IP addresses to MAC addresses does not limit
scalability, provided the solution tracks IP addresses rather than MAC
addresses.  It also does not seem to have an impact on security.  The
worst that could happen would be that some hosts receive packets they
are not interested in.  Another undesired feature might be that network
administration becomes slightly more complicated.  But the reader is
left out in the rain here.  Giving some rationale would certainly help.


(2)  Section 4.3, "Back85dc-7168e56e9f99 -->





More new features than ever.  Check out the new AIM(R) Mail!




----------MB_8CA075B57E0AFAF_93C_4D0B_webmail-md11.sysops.aol.com--






From l2vpn-bounces@ietf.org Mon Dec 10 13:52:33 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1njw-0001ac-A2; Mon, 10 Dec 2007 13:52:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IsgQ8-0002sC-VP; Thu, 15 Nov 2007 10:14:20 -0500
Received: from [2001:14b8:400:101::2] (helo=n2.nomadiclab.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IsgQ6-0008Bu-Oj; Thu, 15 Nov 2007 10:14:20 -0500
Received: from n2.nomadiclab.com (localhost [127.0.0.1])
	by n2.nomadiclab.com (Postfix) with ESMTP id 1AD631EFE58;
	Thu, 15 Nov 2007 17:14:18 +0200 (EET)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by n2.nomadiclab.com (Postfix) with ESMTP id 9492A1EFE56;
	Thu, 15 Nov 2007 17:14:17 +0200 (EET)
Message-ID: <473C6247.9080309@nomadiclab.com>
Date: Thu, 15 Nov 2007 17:14:15 +0200
From: Christian Vogt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
	rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Gen-ART Mailing List 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: -1.4 (-)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
X-Mailman-Approved-At: Mon, 10 Dec 2007 13:51:54 -0500
Cc: l2vpn@ietf.org, Shane.Amante@Level3.com, yetik_serbest@labs.att.com,
	yuichiro.wada@ntt.com, y.kamite@ntt.com, thomas.morin@francetelecom.com,
	Jari Arkko ,
	Mark Townsley , lufang@cisco.com,
	vach.kompella@alcatel.com
Subject: Gen-ART Review of draft-ietf-l2vpn-vpls-mcast-reqts-05
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: l2vpn-bounces@ietf.org

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.


Document..........:  draft-ietf-l2vpn-vpls-mcast-reqts-05
Reviewer..........:  Christian Vogt
Review date.......:  Nov 15, 2007
IESG Telechat date:  --


Summary:  This draft is basically ready for publication, but has nits
           that should be fixed before publication.

Comments:

(1)  Section 4.1.2, "Multicast Packet Types", says:

                                             Since the mapping between
    IPv4 multicast addresses and Ethernet layer multicast addresses is
    ambiguous (i.e., multiplicity of 1 Ethernet address to 32 IP
    addresses), MAC-based multicast forwarding is not ideal for IP
    multicast.

Would be good to provide some rationale here.  It seems that the
non-injective mapping from IP addresses to MAC addresses does not limit
scalability, provided the solution tracks IP addresses rather than MAC
addresses.  It also does not seem to have an impact on security.  The
worst that could happen would be that some hosts receive packets they
are not interested in.  Another undesired feature might be that network
administration becomes slightly more complicated.  But the reader is
left out in the rain here.  Giving some rationale would certainly help.


(2)  Section 4.3, "Backward Compatibility", says:

    A solution SHOULD be backward compatible with the existing VPLS
    solution.  It SHOULD allow a case where a common VPLS instance is
    composed of both PEs supporting the solution and PEs not supporting
    it, and the multicast forwarding enhancement is partially achieved by
    the compliant PEs.

The last sentence here should be "achieved *between* the compliant PEs"
because coordination will probably be required between the forwarding
side and the receiving side, thus requiring upgrades on both sides.  The
current text talks about the forwarding side only and so makes the
requirement more (IMO too much) ambitious.


(3)  Section 5.10, "Fate-Sharing...":

I don't see a reason for this section's claim that unicast and multicast
should always be either both up or both down.

The section currently calls for deliberate de-activation of one
transmission method in case the other transmission method fails.  Is
there any reason why a customer or a provider might benefit from such
policy? -- I think section 5.10 be removed from the draft.


(4)  Section 5.6, "Access Connectivity", should IMO be split into an
"Access Connectivity" section comprising the currently first paragraph,
and a "Multi-Homing" section comprising the rest.


(5)  Editorial

Section 1.1., 6th paragraph:  "VPLS PEs" is an unknown acronym at this
point.

Section 2.1:  "- Multicast Channel:  (S,G) in the SSM model" -- So
"multicast channel" is an SSM-specific term and is undefined for ASM?

Section 3.2, 1st paragraph:  "ingress PE" -- Is this the U-PE or the N-PE?

Section 3.3.1, "Native Ethernet service aspect":  s/Their main interest
is how to deal with the issue/Their main interest is solve the issue/

Section 3.3.1, "IP multicast service aspect":  s/Their main interest is
how to provide/Their main interest is to provide/

Section 4.1.1.1:  "Issues A and B" appeared long before, so better add a
page/section number in parentheses as a reference.


Hope this helps.
- Christian








ward Compatibility", says:

    A solution SHOULD be backward compatible with the existing VPLS
    solution.  It SHOULD allow a case where a common VPLS instance is
    composed of both PEs supporting the solution and PEs not supporting
    it, and the multicast forwarding enhancement is partially achieved by
    the compliant PEs.

The last sentence here should be "achieved *between* the compliant PEs"
because coordination will probably be required between the forwarding
side and the receiving side, thus requiring upgrades on both sides.  The
current text talks about the forwarding side only and so makes the
requirement more (IMO too much) ambitious.


(3)  Section 5.10, "Fate-Sharing...":

I don't see a reason for this section's claim that unicast and multicast
should always be either both up or both down.

The section currently calls for deliberate de-activation of one
transmission method in case the other transmission method fails.  Is
there any reason why a customer or a provider might benefit from such
policy? -- I think section 5.10 be removed from the draft.


(4)  Section 5.6, "Access Connectivity", should IMO be split into an
"Access Connectivity" section comprising the currently first paragraph,
and a "Multi-Homing" section comprising the rest.


(5)  Editorial

Section 1.1., 6th paragraph:  "VPLS PEs" is an unknown acronym at this
point.

Section 2.1:  "- Multicast Channel:  (S,G) in the SSM model" -- So
"multicast channel" is an SSM-specific term and is undefined for ASM?

Section 3.2, 1st paragraph:  "ingress PE" -- Is this the U-PE or the N-PE?

Section 3.3.1, "Native Ethernet service aspect":  s/Their main interest
is how to deal with the issue/Their main interest is solve the issue/

Section 3.3.1, "IP multicast service aspect":  s/Their main interest is
how to provide/Their main interest is to provide/

Section 4.1.1.1:  "Issues A and B" appeared long before, so better add a
page/section number in parentheses as a reference.


Hope this helps.
- Christian








From l2vpn-bounces@ietf.org Mon Dec 10 17:03:10 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1qiQ-0000a1-NR; Mon, 10 Dec 2007 17:03:06 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qiP-0000ZY-FK
	for l2vpn@ietf.org; Mon, 10 Dec 2007 17:03:05 -0500
Received: from eci-iron1.ecitele.com ([147.234.242.117])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1qiO-0000yC-1e
	for l2vpn@ietf.org; Mon, 10 Dec 2007 17:03:05 -0500
Received: from ilptexfe.ecitele.com (HELO ILPTEXCH02.ecitele.com)
	([147.234.245.181])
	by eci-iron1-out.ecitele.com with ESMTP; 11 Dec 2007 00:12:31 +0200
Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by
	ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id
	8.1.240.5; Tue, 11 Dec 2007 00:02:54 +0200
Received: from USPITMAIL01.ecitele.com ([10.0.0.81]) by ILPTMAIL01.ecitele.com
	with Microsoft SMTPSVC(6.0.3790.3959);
	Tue, 11 Dec 2007 00:02:54 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 10 Dec 2007 17:02:50 -0500
Message-ID: <4EF7ED00175A4E4DAE68A5EE31A4F91E588196@USPITMAIL01.ecitele.com>
In-Reply-To: <483F121CD2155B43B56DB71228DBAF15A3B1D7@xmb-sjc-239.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: VPLS OAM != .1ag
Thread-Index: Acg3bEa6DEWH9HttSPOmJe9257wW6QBumSGQAAZ1zAcAW4ZxMAAw4odg
References: <40B2D3B1A8D67246A33D2F5B832C17E70FE8FF@USDALSMBS03.ad3.ad.alcatel.com>
	<483F121CD2155B43B56DB71228DBAF15A3B1D7@xmb-sjc-239.amer.cisco.com>
From: Jeremy Brayley 
To: "Ali Sajassi (sajassi)" ,
	"KOMPELLA Vach" , 
X-OriginalArrivalTime: 10 Dec 2007 22:02:54.0658 (UTC)
	FILETIME=[6A5BE220:01C83B78]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d9238570526f12788af3d33c67f37625
Cc: 
Subject: RE: VPLS OAM != .1ag
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: l2vpn-bounces@ietf.org


Ali (or Dinesh),

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]=20
> Sent: Sunday, December 09, 2007 5:29 PM
> To: KOMPELLA Vach; l2vpn@ietf.org
> Subject: RE: VPLS OAM !=3D .1ag
>=20
> Vach,
> =20
> I think there is a misunderstanding on your part regarding=20
> how the model in bridge-interop and RFC 4664 works since you=20
> are making some claims listed below that are non-existent if=20
> you use the model properly:
> =20
> 1) Forwarding at n-PE doesn't go through bridge module at=20
> n-PE for H-VPLS with MPLS access (when packet is switched=20
> between access and core networks)
> =20
> 2) VCCV OAM is not sufficient for multi-segment PW which is=20
> used for inter-AS option B and thus we need  additional OAM=20
> functionality
> =20
> 3) 802.1ag + VCCV does not cover MAC address mapping between=20
> PWs and VPLS forwarders.
> =20
> Let me go through each with you:
> =20
> 1) I hope from all the conversation that we have had so far,=20
> it is clear that bridge module is used when doing switching=20
> between access and core networks. This was the original=20
> intention when I helped the editors to put this model in the=20
> RFC 4664. And it is the same model that is used in my=20
> bridge-interop draft that has passed WG last call and=20
> becoming RFC. This means that 802.1ag can detect and isolate=20
> faults not only at the u-PE devices but also at the n-PE devices
> =20
> 2) The OAM for multi-segment PW needs to be taken care by PW=20
> VCCV. If there is anything missing in this area, then we need=20
> to address this using VCCV PW in PWE3 and not coming with yet=20
> another mechanism. The scope of this work is outside of VPLS=20
> since the multi-segment PW can be directly connected to AC=20
> (rather than VSI).
> =20
> 3) By having a down MEP at the interface between bridge=20
> module and VPLS forwarder, you can cover both VPLS forwarder=20
> and the associated PWs such that if there is any issue with=20
> either forwarder or PW, you can detect it and isolate the=20
> fault accordingly. If you think, there is a scenario, that=20
> cannot be covered in terms of fault detection or isolation,=20
> please be specific.

The issue is with CFM linktrace.  I agree you would have coverage for
CCM and Loopback. =20

But let's say rather than a down MEP you have a MIP on the interface
between the bridge module and the forwarder.  And we're talking a simple
full mesh VPLS forwarder, not an H-VPLS case.

Now suppose the bridge module receives a CFM LinkTrace message from one
of its ACs and the target address is known to be reachable through the
emulated LAN interface.  When it responds the MIP is supposed to include
an egress port ID in the LTR. =20

In the model you describe, won't the MIP respond only with the emulated
port ID?  (Because the PWs are hidden behind the VPLS forwarder from the
bridge module's persective.)

Now the PE certainly knows the MAC to PW binding, but with the module
you describe I believe the MIP wouldn't report the binding.  Instead it
would likely report the emulated LAN interface as the egress port ID and
rebroadcast the LTM to every PE.  Assuming there are similar MIPs on the
other PEs, you would be able to trace the PEs in the path to the target,
but you would not learn the PWs.  Nor would you be sure that the MAC to
PW binding actually exists in the VPLS forwarder.  The VPLS forwarder
might be forwarding to the target as an unknown unicast even.

I think this is the problem that Vach is talking about.

Note that I believe that CFM is adequate to return the MAC to PW binding
info in LinkTrace.  It just requires CFM to treat the PWs as virtual
ports on the same bridge module and return the right PW as the egress
port ID in the LTR.  The MIP would then rebroadcast the LTM on the right
PW for the target MAC.=20

Thanks,

Jeremy

> I am supposed to be on my PTO for next couple of weeks so I=20
> won't be checking my emails regardless of how tempting that=20
> may be :-) If needed, I like to ask Dinesh to continue this=20
> discussion and provide any clarifications that may be needed.=20
> =20
> Cheers,
> Ali
>=20
>=20
> ________________________________
>=20
> 	From: KOMPELLA Vach [mailto:Vach.Kompella@alcatel-lucent.com]=20
> 	Sent: Friday, December 07, 2007 6:18 PM
> 	To: Ali Sajassi (sajassi); l2vpn@ietf.org
> 	Subject: Re: VPLS OAM !=3D .1ag
> =09
> =09
>=20
> 	Ali,
> =09
> 	As I have repeatedly said, your model doesn't map MAC=20
> addresses in the bridge to PWs in the VPLS forwarders.  This=20
> is expressed in the draft that Olen presented.
> =09
> 	It is not enough to say we will test the forwarding=20
> through the bridge and the forwarding of an individual PW to=20
> determine the complete forwarding path. You have to identify=20
> the mapping of MAC address to the associated PW in the VPLS=20
> forwarder - somethiing neither .1ag nor VCCV are capable of.
> =09
> 	I have the model right. I don't see your point.
> =09
> 	Tom, if you see something I don't, can you express it=20
> as something other than "you have the wrong model.". I have=20
> given a concrete example of why I have the right model.
> =09
> 	I hope this isn't harking back to the same issue that=20
> VPLS-OAM isn't enough because no-one is saying that.=20
> 	-Vach
> =09
> 	----- Original Message -----
> 	From: Ali Sajassi (sajassi) 
> 	To: KOMPELLA Vach; l2vpn@ietf.org 
> 	Sent: Fri Dec 07 18:04:45 2007
> 	Subject: RE: VPLS OAM !=3D .1ag
> =09
> =09
> 	Vach,
> =09
> 	As I pointed out during the meeting, if you use the=20
> right model, then
> 	you will see that the combination of 802.1ag with VCCV=20
> gives a very good
> 	coverage. The problem is that you are starting with a=20
> wrong model and
> 	your coverage analysis is based on that model - e.g.,=20
> you are assuming
> 	that for H-VPLS w/ MPLS access, the packet does not=20
> touch bridge module
> 	at n-PE devices and thus 802.1ag doesn't give you=20
> coverage on the n-PE.
> 	And that is a wrong assumption to begin with.
> =09
> 	As I mention during the meeting, lets start with the=20
> right model and
> 	then perform the analysis and see if there is any=20
> issues with  the
> 	coverage of .1ag + VCCV before introducing yet another=20
> oam mechanism.
> =09
> 	I had a chat with Olen to review with him the models in=20
> bridge-interop
> 	draft and RFC 4664 and take the discussion from there.
> =09
> 	Cheers,
> 	Ali
> =09
> 	P.S. I will be on PTO starting next week but I am sure=20
> there will be
> 	tons of discussions before I come back :-)   =20
> =09
> =09
> =09
> 	> -----Original Message-----
> 	> From: KOMPELLA Vach [mailto:Vach.Kompella@alcatel-lucent.com]
> 	> Sent: Wednesday, December 05, 2007 10:26 AM
> 	> To: l2vpn@ietf.org
> 	> Subject: VPLS OAM !=3D .1ag
> 	>
> 	> I want to re-iterate that VPLS OAM is not a replacement for
> 	> .1ag (which neither Ali nor Dan seem to have noticed).  In
> 	> fact, the first slide of my presentation states that it fixes
> 	> the holes in our analysis of the capabilities provided
> 	> through .1ag+VCCV (Olen's presentation).
> 	>
> 	> In essence, providers are interested in figuring out the
> 	> mapping of PWs to ethernet MACs, as the MACs are learned, and
> 	> tracing the consistency of the mapping across the VPLS
> 	> domain.  This specifically covers the MPLS details of the PWs
> 	> in the VPLS forwarders, which is not covered in .1ag.  This
> 	> also covers the mapping of the FDB to the PWs which is not
> 	> covered by VCCV.
> 	>
> 	> Obviously, this can be (somewhat painfully) achieved by going
> 	> to individual nodes and using some combinations of .1ag and
> 	> VCCV, and dumping FDB contents.  However, you still have to
> 	> correlate the failure in the forwarding of .1ag and the state
> 	> of PWs in a VPLS forwarder reported by VCCV, and the dumping
> 	> of FDB contents, and putting all that together to get the
> 	> desired effect.  And you are still left with the
> 	> unsatisfactory feeling that you relied on the output of some
> 	> tables as opposed to pushing a packet through the suspect
> 	> forwarding plane entity.
> 	>
> 	> Vach Kompella
> 	> IP Division, Alcatel
> 	> vach.kompella@alcatel-lucent.com
> 	> +1 650 623-2556
> 	>
> =09
>=20
>=20




From l2vpn-bounces@ietf.org Tue Dec 11 08:26:07 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J257Z-0006HM-0n; Tue, 11 Dec 2007 08:26:01 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J257Y-0006Gc-2L
	for l2vpn@ietf.org; Tue, 11 Dec 2007 08:26:00 -0500
Received: from extrgate1.extremenetworks.com ([207.179.9.4]
	helo=mail3.extremenetworks.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J257W-0005XA-W3
	for l2vpn@ietf.org; Tue, 11 Dec 2007 08:25:59 -0500
Received: by mail3.extremenetworks.com with Internet Mail Service (5.5.2655.55)
	id ; Tue, 11 Dec 2007 05:14:44 -0800
Message-ID: <3DC3910A44FBD94B8513C8E2A3F220E1026990AE@sc-msexch-16.extremenetworks.com>
From: Olen Stokes 
To: 'Jeremy Brayley' , "Ali Sajassi (sajassi)"
	, KOMPELLA Vach , 
	l2vpn@ietf.org
Date: Tue, 11 Dec 2007 05:25:41 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae
Cc: 
Subject: RE: VPLS OAM != .1ag
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: l2vpn-bounces@ietf.org


I understand the point that Jeremy is making.  There is a similar discussion
in Section 6 of our OAM draft.  However, I would like to backup for a
moment.  When I spoke with several people following the L2 VPN meeting in
Vancouver, there was general agreement to the following plan:

1) obtain working group agreement on a H-VPLS reference model 
2) based on that model, reach agreement on the location of MIPs/MEPs
3) based on that placement, confirm the coverage of 802.1ag and VCCV

The H-VPLS reference model to which Ali referred in the meeting can be found
at:

http://www3.ietf.org/proceedings/04nov/slides/l2vpn-9.pdf

My intent is to start a new thread specifically to discuss the H-VPLS
reference model.  If we can get agreement on that, then specifying MP
locations should be straightforward.  Following that, some of the points
being raised in this thread can be discussed with a common model in mind.

Cheers,
Olen


-----Original Message-----
From: Jeremy Brayley [mailto:Jeremy.Brayley@ecitele.com]
Sent: Monday, December 10, 2007 5:03 PM
To: Ali Sajassi (sajassi); KOMPELLA Vach; l2vpn@ietf.org
Subject: RE: VPLS OAM != .1ag



Ali (or Dinesh),

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] 
> Sent: Sunday, December 09, 2007 5:29 PM
> To: KOMPELLA Vach; l2vpn@ietf.org
> Subject: RE: VPLS OAM != .1ag
> 
> Vach,
>  
> I think there is a misunderstanding on your part regarding 
> how the model in bridge-interop and RFC 4664 works since you 
> are making some claims listed below that are non-existent if 
> you use the model properly:
>  
> 1) Forwarding at n-PE doesn't go through bridge module at 
> n-PE for H-VPLS with MPLS access (when packet is switched 
> between access and core networks)
>  
> 2) VCCV OAM is not sufficient for multi-segment PW which is 
> used for inter-AS option B and thus we need  additional OAM 
> functionality
>  
> 3) 802.1ag + VCCV does not cover MAC address mapping between 
> PWs and VPLS forwarders.
>  
> Let me go through each with you:
>  
> 1) I hope from all the conversation that we have had so far, 
> it is clear that bridge module is used when doing switching 
> between access and core networks. This was the original 
> intention when I helped the editors to put this model in the 
> RFC 4664. And it is the same model that is used in my 
> bridge-interop draft that has passed WG last call and 
> becoming RFC. This means that 802.1ag can detect and isolate 
> faults not only at the u-PE devices but also at the n-PE devices
>  
> 2) The OAM for multi-segment PW needs to be taken care by PW 
> VCCV. If there is anything missing in this area, then we need 
> to address this using VCCV PW in PWE3 and not coming with yet 
> another mechanism. The scope of this work is outside of VPLS 
> since the multi-segment PW can be directly connected to AC 
> (rather than VSI).
>  
> 3) By having a down MEP at the interface between bridge 
> module and VPLS forwarder, you can cover both VPLS forwarder 
> and the associated PWs such that if there is any issue with 
> either forwarder or PW, you can detect it and isolate the 
> fault accordingly. If you think, there is a scenario, that 
> cannot be covered in terms of fault detection or isolation, 
> please be specific.

The issue is with CFM linktrace.  I agree you would have coverage for
CCM and Loopback.  

But let's say rather than a down MEP you have a MIP on the interface
between the bridge module and the forwarder.  And we're talking a simple
full mesh VPLS forwarder, not an H-VPLS case.

Now suppose the bridge module receives a CFM LinkTrace message from one
of its ACs and the target address is known to be reachable through the
emulated LAN interface.  When it responds the MIP is supposed to include
an egress port ID in the LTR.  

In the model you describe, won't the MIP respond only with the emulated
port ID?  (Because the PWs are hidden behind the VPLS forwarder from the
bridge module's persective.)

Now the PE certainly knows the MAC to PW binding, but with the module
you describe I believe the MIP wouldn't report the binding.  Instead it
would likely report the emulated LAN interface as the egress port ID and
rebroadcast the LTM to every PE.  Assuming there are similar MIPs on the
other PEs, you would be able to trace the PEs in the path to the target,
but you would not learn the PWs.  Nor would you be sure that the MAC to
PW binding actually exists in the VPLS forwarder.  The VPLS forwarder
might be forwarding to the target as an unknown unicast even.

I think this is the problem that Vach is talking about.

Note that I believe that CFM is adequate to return the MAC to PW binding
info in LinkTrace.  It just requires CFM to treat the PWs as virtual
ports on the same bridge module and return the right PW as the egress
port ID in the LTR.  The MIP would then rebroadcast the LTM on the right
PW for the target MAC. 

Thanks,

Jeremy

> I am supposed to be on my PTO for next couple of weeks so I 
> won't be checking my emails regardless of how tempting that 
> may be :-) If needed, I like to ask Dinesh to continue this 
> discussion and provide any clarifications that may be needed. 
>  
> Cheers,
> Ali
> 
> 
> ________________________________
> 
> 	From: KOMPELLA Vach [mailto:Vach.Kompella@alcatel-lucent.com] 
> 	Sent: Friday, December 07, 2007 6:18 PM
> 	To: Ali Sajassi (sajassi); l2vpn@ietf.org
> 	Subject: Re: VPLS OAM != .1ag
> 	
> 	
> 
> 	Ali,
> 	
> 	As I have repeatedly said, your model doesn't map MAC 
> addresses in the bridge to PWs in the VPLS forwarders.  This 
> is expressed in the draft that Olen presented.
> 	
> 	It is not enough to say we will test the forwarding 
> through the bridge and the forwarding of an individual PW to 
> determine the complete forwarding path. You have to identify 
> the mapping of MAC address to the associated PW in the VPLS 
> forwarder - somethiing neither .1ag nor VCCV are capable of.
> 	
> 	I have the model right. I don't see your point.
> 	
> 	Tom, if you see something I don't, can you express it 
> as something other than "you have the wrong model.". I have 
> given a concrete example of why I have the right model.
> 	
> 	I hope this isn't harking back to the same issue that 
> VPLS-OAM isn't enough because no-one is saying that. 
> 	-Vach
> 	
> 	----- Original Message -----
> 	From: Ali Sajassi (sajassi) 
> 	To: KOMPELLA Vach; l2vpn@ietf.org 
> 	Sent: Fri Dec 07 18:04:45 2007
> 	Subject: RE: VPLS OAM != .1ag
> 	
> 	
> 	Vach,
> 	
> 	As I pointed out during the meeting, if you use the 
> right model, then
> 	you will see that the combination of 802.1ag with VCCV 
> gives a very good
> 	coverage. The problem is that you are starting with a 
> wrong model and
> 	your coverage analysis is based on that model - e.g., 
> you are assuming
> 	that for H-VPLS w/ MPLS access, the packet does not 
> touch bridge module
> 	at n-PE devices and thus 802.1ag doesn't give you 
> coverage on the n-PE.
> 	And that is a wrong assumption to begin with.
> 	
> 	As I mention during the meeting, lets start with the 
> right model and
> 	then perform the analysis and see if there is any 
> issues with  the
> 	coverage of .1ag + VCCV before introducing yet another 
> oam mechanism.
> 	
> 	I had a chat with Olen to review with him the models in 
> bridge-interop
> 	draft and RFC 4664 and take the discussion from there.
> 	
> 	Cheers,
> 	Ali
> 	
> 	P.S. I will be on PTO starting next week but I am sure 
> there will be
> 	tons of discussions before I come back :-)    
> 	
> 	
> 	
> 	> -----Original Message-----
> 	> From: KOMPELLA Vach [mailto:Vach.Kompella@alcatel-lucent.com]
> 	> Sent: Wednesday, December 05, 2007 10:26 AM
> 	> To: l2vpn@ietf.org
> 	> Subject: VPLS OAM != .1ag
> 	>
> 	> I want to re-iterate that VPLS OAM is not a replacement for
> 	> .1ag (which neither Ali nor Dan seem to have noticed).  In
> 	> fact, the first slide of my presentation states that it fixes
> 	> the holes in our analysis of the capabilities provided
> 	> through .1ag+VCCV (Olen's presentation).
> 	>
> 	> In essence, providers are interested in figuring out the
> 	> mapping of PWs to ethernet MACs, as the MACs are learned, and
> 	> tracing the consistency of the mapping across the VPLS
> 	> domain.  This specifically covers the MPLS details of the PWs
> 	> in the VPLS forwarders, which is not covered in .1ag.  This
> 	> also covers the mapping of the FDB to the PWs which is not
> 	> covered by VCCV.
> 	>
> 	> Obviously, this can be (somewhat painfully) achieved by going
> 	> to individual nodes and using some combinations of .1ag and
> 	> VCCV, and dumping FDB contents.  However, you still have to
> 	> correlate the failure in the forwarding of .1ag and the state
> 	> of PWs in a VPLS forwarder reported by VCCV, and the dumping
> 	> of FDB contents, and putting all that together to get the
> 	> desired effect.  And you are still left with the
> 	> unsatisfactory feeling that you relied on the output of some
> 	> tables as opposed to pushing a packet through the suspect
> 	> forwarding plane entity.
> 	>
> 	> Vach Kompella
> 	> IP Division, Alcatel
> 	> vach.kompella@alcatel-lucent.com
> 	> +1 650 623-2556
> 	>
> 	
> 
> 




From l2vpn-bounces@ietf.org Wed Dec 12 09:13:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2SKT-0004OY-RR; Wed, 12 Dec 2007 09:12:53 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2SKS-0004OS-UG
	for l2vpn@ietf.org; Wed, 12 Dec 2007 09:12:52 -0500
Received: from mail3.extremenetworks.com ([207.179.9.4]
	helo=extrgate1.extremenetworks.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2SKS-00056n-9z
	for l2vpn@ietf.org; Wed, 12 Dec 2007 09:12:52 -0500
Received: by extrgate1.extremenetworks.com with Internet Mail Service
	(5.5.2657.72) id ; Wed, 12 Dec 2007 06:12:47 -0800
Message-ID: <3DC3910A44FBD94B8513C8E2A3F220E1026990B4@sc-msexch-16.extremenetworks.com>
From: Olen Stokes 
To: l2vpn@ietf.org
Date: Wed, 12 Dec 2007 06:12:42 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Subject: Reference model for H-VPLS node
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: l2vpn-bounces@ietf.org


There was significant discussion at the last IETF about the correct
reference model to be used when discussing OAM for a H-VPLS node.  For the
H-VPLS network in Figure 2 of draft-stokes-l2vpn-cfm-vccv-oam-00.txt, the
reference model described in that draft is shown below in Figure A:

         |--- PW-1 ----|  |--- PW-13 ----|  |---- PW-3 ----|
Emulated |             |  |              |  |              |
LAN      |             |  |              |  |              |
....................................................................
.        |             |  |              |  |              |       .
.|-------|-----|  |----|--|-----|  |-----|--|----|  |------|------|.
.| ----------- |  | ----------- |  | ----------- |  | ----------- |.
.|     VPLS    |  |     VPLS    |  |     VPLS    |  |    VPLS     |.
.|  Forwarder  |  |  Forwarder  |  |  Forwarder  |  |  Forwarder  |.
.| ------|---- |  | -----|----- |  | -----|----- |  | -----|----- |.
.|.............|..|................|................................
 |       |     |  |      |      |  |      |      |  |      |      |
 |       |     |  |      |      |  |      |      |  |------|------|
 | ------|---- |  | -----|----- |  | -----|----- |  | -----|----- |
 | |         | |  | |         | |  | |         | |  | |         | |
 | | Bridge  | |  | | Bridge  | |  | |  Bridge | |  | |  Bridge | |
 | |         | |  | |         | |  | |         | |  | |         | |
 | |  |      | |  | |         | |  | |         | |  | |      |  | |
 | ---|------- |  | ----------- |  | ----------- |  | -------|--- |
 |----|--------|  |-------------|  |-------------|  |--------|----|
      |                                                      |
      |                                                      |
     CE-1                                                  CE-3

     MTU1-s            PE1-rs           PE3-rs           MTU3-s

     Figure A: H-VPLS node using only VPLS Forwarder connections


An alternative model based on
http://www3.ietf.org/proceedings/04nov/slides/l2vpn-9.pdf is shown below in
Figure B:

                          |--- PW-13 ----|
                Emulated  |              |
                 LAN      |              |
                ....................................
                .         |              |         .
                . |-------|-----|  |-----|-------| .
                . | ----------- |  | ----------- | .
                . |     VPLS    |  |     VPLS    | .
                . |  Forwarder  |  |  Forwarder  | .
                . | -----|----- |  | -----|----- | .
                ..|................|................
                  |      |      |  |      |      |
 |-------------|  |      |      |  |      |      |  |-------------|
 | ----------- |  | -----|----- |  | -----|----- |  | ----------- |
 | |         | |  | |         | |  | |         | |  | |         | |
 | |  Bridge | |  | | Bridge  | |  | |  Bridge | |  | |  Bridge | |
 | |         | |  | |         | |  | |         | |  | |         | |
 | |  |   *  | |  | |    *    | |  | |    *    | |  | |  *   |  | |
 | ---|---|--- |  | -----|----- |  | -----|----- |  | ---|---|--- |
 |----|---|----|  |------|------|  |------|------|  |----|---|----|
      |   |              |                |              |   |
      |   |---- PW-1 ----|                |----- PW-3 ---|   |
     CE-1                                                  CE-3

     MTU1-s            PE1-rs           PE3-rs           MTU3-s

Note: "*" = emulated bridge port

    Figure B: H-VPLS node using emulated bridge port connections


Please note that Figure B is my interpretation of Ali's charts from his
November, 2004 presentation.

There are definite implications based on the differences of the two models.
The VPLS forwarder only model in Figure A treats a H-VPLS network with PW
access the same as a simple full mesh VPLS network.  The bridge model sees a
single emulated LAN interface to the (H)VPLS network and therefore is not
concerned with the structure of that (H)VPLS network.  

The emulated bridge port model treats a H-VPLS network with PW access the
same as a H-VPLS network with Ethernet access.  In effect, it "separates"
the network into a full mesh VPLS emulated LAN and individual access
networks that can be PW or Ethernet.  This "separation" is a result of the
presence of the bridge module between these connections.

One difference from an OAM perspective is that the emulated bridge port
model allows 802.1ag MPs to be associated with PW access connections such as
PW-1 in Figure B above. 

There may be implications to other protocols such as spanning tree.  In the
emulated bridge port model, PW-1 is seen by the bridge module and could be
considered separately should the bridge module in PE1-rs participate in
spanning tree.  However, in the VPLS forwarder only model, only the single
emulated LAN would be included in spanning tree. 

As I said during the L2 VPN meeting, I believe that choosing the correct
reference model is a decision to be made by the working group.  Therefore,
please use the mailing list to state your views on the correct reference
model to be used for a H-VPLS node.

Cheers,
Olen














From l2vpn-bounces@ietf.org Wed Dec 12 12:24:23 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2VJi-0007hJ-Mm; Wed, 12 Dec 2007 12:24:18 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2VJh-0007bt-MB
	for l2vpn@ietf.org; Wed, 12 Dec 2007 12:24:17 -0500
Received: from smail5.alcatel.fr ([62.23.212.27])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2VJg-0003B0-1z
	for l2vpn@ietf.org; Wed, 12 Dec 2007 12:24:17 -0500
Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com
	[155.132.6.76])
	by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id lBCHO0Pd018361; 
	Wed, 12 Dec 2007 18:24:00 +0100
Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.35]) by
	FRVELSBHS04.ad2.ad.alcatel.com with Microsoft
	SMTPSVC(6.0.3790.2499); Wed, 12 Dec 2007 18:24:10 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 Dec 2007 18:24:09 +0100
Message-ID: 
In-Reply-To: <475FEE24.3060906@lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Reference model for H-VPLS node
Thread-Index: Acg8yeroZuO1utwaSeSgEbtOlXvELwABiJ6w
From: "VISSERS Maarten" 
To: "Olen Stokes" 
X-OriginalArrivalTime: 12 Dec 2007 17:24:10.0649 (UTC)
	FILETIME=[CEE62090:01C83CE3]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35
Cc: l2vpn@ietf.org
Subject: RE: Reference model for H-VPLS node
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: l2vpn-bounces@ietf.org

Olen,

I made the following reference model for this figure 2, assuming the
there are VPLSs between the MTU and the PE-rs. I have included all PW's
that terminate in the PE1-rs and PE3-rs nodes; i.e. also PW-12 and
PW-23.

                                     PW-23-|
                               |-PW-12     |
             |--- PW-1 ---|    ||- PW-13 -||    |--- PW-3 ---|
   Emulated  |            |    ||         ||    |            |
    LAN      |            |    ||         ||    |            |
   .....................................................................
   .         |            |    ||         ||    |            |         .
   . |-------|-----|  |---|----||---| |---||----|---|  |-----|-------| .
   . | ----------- |  | ----- ----- | | ----- ----- |  | ----------- | .
   . |     VPLS    |  | VPLS| |VPLS | | VPLS| |VPLS |  |     VPLS    | .
   . |  Forwarder  |  | Fwdr| |Fwdr | | Fwdr| |Fwdr |  |  Forwarder  | .
   . | -----|----- |  | --|-- --|-- | | --|-- --|-- |  | -----|----- | .
   ..|.................................................|................
     |      |      |  |   |     |   | |   |     |   |  |      |      |
     |      |      |  |   |     |   | |   |     |   |  |      |      |
     | -----|----- |  | --|-----|-- | | --|-----|-- |  | -----|----- |
     | |         | |  | |         | | | |         | |  | |         | |
     | | Bridge  | |  | | Bridge  | | | | Bridge  | |  | | Bridge  | |
     | |         | |  | |         | | | |         | |  | |         | |

         MTU1-s            PE1-rs          PE3-rs           MTU3-s

					FIGURE A

In your model, you assume that there are no VPLSs present between MTU
and PE-rs. This would then result in the following model (Figure B), in
which also the PW-12 and PW-23 are included.

                                     PW-23-|
                               |-PW-12     |
             |--- PW-1 ---|    ||- PW-13 -||    |--- PW-3 ---|
   Emulated  |            |    ||         ||    |            |
    LAN      |            |    ||         ||    |            |
   .....................................................................
   .         |            |    ||         ||    |            |         .
   . |-------|-----|  |---|----||---| |---||----|---|  |-----|-------| .
   . |       |     |  |   |   ----- | | -----   |   |  |     |       | .
   . |       |     |  |   |   |VPLS | | VPLS|   |   |  |     |       | .
   . |       |     |  |   |   |Fwdr | | Fwdr|   |   |  |     |       | .
   . |       |     |  |   |   --|-- | | --|--   |   |  |     |       | .
   ..|.................................................|................
     |       |     |  |   |     |   | |   |     |   |  |     |       |
     |       |     |  |   |     |   | |   |     |   |  |     |       |
     | ------|---- |  | --|-----|-- | | --|-----|-- |  | ----|------ |
     | |         | |  | |         | | | |         | |  | |         | |
     | | Bridge  | |  | | Bridge  | | | | Bridge  | |  | | Bridge  | |
     | |         | |  | |         | | | |         | |  | |         | |

         MTU1-s            PE1-rs          PE3-rs           MTU3-s

					FIGURE B

The Bridge and VPLS Forwarder functions are in terms of 802.1Q part of
the MAC Relay function. We have to consider now the different VPLS
modes: tree-structured and full-mesh.=20

In tree-structured mode the VPLS Forwarder has only 1 PW associated with
the in/output port it has with the bridge function; it essentially
becomes a null function and can be omitted, as is done in the case of
PW-1 and PW-3.

In full-mesh mode the VPLS Forwarder provides a split-horizon
functionality, which is similar to the MAC Relay functionality specified
for "Asymmetric-VLANs in Shared VLAN Learning (SVL) mode" as specified
in clause B.1.3/802.1Q.

For a full-mesh VPLS, the 802.1Q MAC Relay function combines the regular
any-to-any MAC forwarding within the (Independent VLAN Learning (IVL)
mode) VLAN with the "Asymmetric-VLANs in SVL mode". I.e. some of the
ports of the VLAN on this MAC RElay (encompassing the bridge and VPLS
Forwarder functionality) are more special (split-horizon) than other
ports of the VLAN.

>From an 802.1Q/ag perspective, this will then result in the following
location of Ethernet MEPs and MIPs (see Figure C), assuming that the
MTU-s's have a MEP at MD Level 4. Consequently, the Ethernet MIPs that
are located between the PW and Bridge (PW-1, PW-3), or the PW and the
VPLS Forwarder (PW-12,PW-13,PW-23) are also having MD Level 4.

                                     PW-23-|
                               |-PW-12     |
             |--- PW-1 ---|    ||- PW-13 -||    |--- PW-3 ---|
   Emulated  |            |    ||         ||    |            |
    LAN      |            |    ||         ||    |            |
   .....................................................................
   . |-------|-----|  |---|----||---| |---||----|---|  |-----|-------| .
     |  MIP X MD   |  |MD X MIPXX MD| |MD XXMIP X MD|  | MIP X MD    |
     |      | L4   |  |L4 |    || L4| |L4 ||    | L4|  |     | L4    |
     |      |      |  |   |    ||   | |   ||    |   |  |     |       |
   . |      |      |  |   |    ||   | |   ||    |   |  |     |       |
.
   . |      |      |  |   |   ----- | | -----   |   |  |     |       | .
   . |      |      |  |   |   |VPLS | | VPLS|   |   |  |     |       | .
   . |      |      |  |   |   |Fwdr | | Fwdr|   |   |  |     |       | .
   . |      |      |  |   |   --|-- | | --|--   |   |  |      |      | .
   ..|.................................................|................
     |      |      |  |   |     |   | |   |     |   |  |      |      |
     |      |      |  |   |     |   | |   |     |   |  |      |      |
     | -----|----- |  | --|-----|-- | | --|-----|-- |  | -----|----- |
     | |         | |  | |         | | | |         | |  | |         | |
     | | Bridge  | |  | | Bridge  | | | | Bridge  | |  | | Bridge  | |
     | |         | |  | |         | | | |         | |  | |         | |
     | |    |    | |  | |         | | | |         | |  | |    |    | |
     | |MEP X MD | |  | |         | | | |         | |  | |MEP X MD | |
     | |    | L4 | |  | |         | | | |         | |  | |    | L4 | |
=20
         MTU-1s           PE1-rs           PE3-rs          MTU-3s

					FIGURE C

>From an 802.1Q perspective, the set of PWs within a MPLS tunnel that
carry VPLS (i.e. VLAN) signals constitute a virtual bridge port. Such
virtual bridge port has an 802.1Q EISS SAP with the VPLS Forwarder
fucntion (as it is part of the MAC Relay). Over this EISS SAP flows
EM_UNITDATA.indication and EM_UNITDATA.request information.

The endpoint of the set of PWs provide from an 802.1Q perspective a
"support of the EISS" function. Such function adds in a pure 802.1Q
environment a VLAN Tag or a Backbone Service Instance Tag, while in the
hybrid 802.1Q/MPLS environment it adds a PW label to carry the
EM_UNITDATA.request information over the MPLS tunnel.

In this model, the MPLS PW label stack entry provides from the viewpoint
of the 802.1Q environment a Tag which has a 20-bit "vlan identifier" (to
carry the EM_UNITDATA.request.vlan_identifier parameter information) and
a 3-bit "priority code point" (to carry the EM_UNITDATA.request.priority
and EM_UNITDATA.request.drop_eligible parameter information. From the
MPLS environment viewpoint, the PW label provides a 20-bit label and a
3-bit EXP field carrying PHB information.

In this model, the VPLS looks from the 802.1Q viewpoint a VLAN with a
"MPLS Label Stack Entry based VLAN Tag" (i.e. an "M-VLAN Tag" or
"M-Tag").

As the PW label value for every PW in the VPLS may be different, and as
the PW label value between MTU-s and PE-rs may be different, the 802.1Q
equivalent model of the VPLS contains a "VID Translation Table" function
as specified in 802.1ad.

In this model, the MPLS tunnels provide point-to-point virtual interface
ports between MAC Relay functions.=20

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

There is a second 802.1Q equivalent model possible for VPLS. In this
model each PW endpoint provides a virtual bridge port supporting a
single (untagged) VLAN. The interconnect between the PW endpoint and the
VPLS Forwarder/Bridge function is then an ISS SAP and M_UNITDATA.request
and M_UNITDATA.indication information is passed over it.

The 1-to-1 nature of the VLAN-PW relationship allows to carry the VLAN
untagged. In such case the M_UNITDATA.request.priority and
M_UNITDATA.request.drop_eligible information is either dropped (no means
to carry it), or is carried via the PW label (note that in this case the
PW label is not longer performing the "M-Tag" function).

It is obvious that the number of virtual bridge ports in this second
model will be much larger than in the first model. From the 802.1Q
environment viewpoint there will now be many parallel virtual links
between two adjacent MAC Relay functions. This seems more complex then
the first model.

Regards,
Maarten



-------- Originele bericht --------
Onderwerp: 	Reference model for H-VPLS node
Datum: 	Wed, 12 Dec 2007 06:12:42 -0800
Van: 	Olen Stokes 
Aan: 	l2vpn@ietf.org



There was significant discussion at the last IETF about the correct
reference model to be used when discussing OAM for a H-VPLS node.  For
the H-VPLS network in Figure 2 of
draft-stokes-l2vpn-cfm-vccv-oam-00.txt, the reference model described in
that draft is shown below in Figure A:

         |--- PW-1 ----|  |--- PW-13 ----|  |---- PW-3 ----|
Emulated |             |  |              |  |              |
LAN      |             |  |              |  |              |
....................................................................
.        |             |  |              |  |              |       .
.|-------|-----|  |----|--|-----|  |-----|--|----|  |------|------|.
.| ----------- |  | ----------- |  | ----------- |  | ----------- |.
.|     VPLS    |  |     VPLS    |  |     VPLS    |  |    VPLS     |.
.|  Forwarder  |  |  Forwarder  |  |  Forwarder  |  |  Forwarder  |.
.| ------|---- |  | -----|----- |  | -----|----- |  | -----|----- |.
.|.............|..|................|................................
 |       |     |  |      |      |  |      |      |  |      |      |
 |       |     |  |      |      |  |      |      |  |------|------|
 | ------|---- |  | -----|----- |  | -----|----- |  | -----|----- |
 | |         | |  | |         | |  | |         | |  | |         | |
 | | Bridge  | |  | | Bridge  | |  | |  Bridge | |  | |  Bridge | |
 | |         | |  | |         | |  | |         | |  | |         | |
 | |  |      | |  | |         | |  | |         | |  | |      |  | |
 | ---|------- |  | ----------- |  | ----------- |  | -------|--- |
|----|--------|  |-------------|  |-------------|  |--------|----|
      |                                                      |
      |                                                      |
     CE-1                                                  CE-3

     MTU1-s            PE1-rs           PE3-rs           MTU3-s

     Figure A: H-VPLS node using only VPLS Forwarder connections


An alternative model based on
http://www3.ietf.org/proceedings/04nov/slides/l2vpn-9.pdf is shown below
in Figure B:

                          |--- PW-13 ----|
                Emulated  |              |
                 LAN      |              |
                ....................................
                .         |              |         .
                . |-------|-----|  |-----|-------| .
                . | ----------- |  | ----------- | .
                . |     VPLS    |  |     VPLS    | .
                . |  Forwarder  |  |  Forwarder  | .
                . | -----|----- |  | -----|----- | .
                ..|................|................
                  |      |      |  |      |      |
 |-------------|  |      |      |  |      |      |  |-------------|
 | ----------- |  | -----|----- |  | -----|----- |  | ----------- |
 | |         | |  | |         | |  | |         | |  | |         | |
 | |  Bridge | |  | | Bridge  | |  | |  Bridge | |  | |  Bridge | |
 | |         | |  | |         | |  | |         | |  | |         | |
 | |  |   *  | |  | |    *    | |  | |    *    | |  | |  *   |  | |
 | ---|---|--- |  | -----|----- |  | -----|----- |  | ---|---|--- |
|----|---|----|  |------|------|  |------|------|  |----|---|----|
      |   |              |                |              |   |
      |   |---- PW-1 ----|                |----- PW-3 ---|   |
     CE-1                                                  CE-3

     MTU1-s            PE1-rs           PE3-rs           MTU3-s

Note: "*" =3D emulated bridge port

    Figure B: H-VPLS node using emulated bridge port connections


Please note that Figure B is my interpretation of Ali's charts from his
November, 2004 presentation.

There are definite implications based on the differences of the two
models.
The VPLS forwarder only model in Figure A treats a H-VPLS network with
PW access the same as a simple full mesh VPLS network.  The bridge model
sees a single emulated LAN interface to the (H)VPLS network and
therefore is not concerned with the structure of that (H)VPLS network. =20

The emulated bridge port model treats a H-VPLS network with PW access
the same as a H-VPLS network with Ethernet access.  In effect, it
"separates"
the network into a full mesh VPLS emulated LAN and individual access
networks that can be PW or Ethernet.  This "separation" is a result of
the presence of the bridge module between these connections.

One difference from an OAM perspective is that the emulated bridge port
model allows 802.1ag MPs to be associated with PW access connections
such as
PW-1 in Figure B above.=20

There may be implications to other protocols such as spanning tree.  In
the emulated bridge port model, PW-1 is seen by the bridge module and
could be considered separately should the bridge module in PE1-rs
participate in spanning tree.  However, in the VPLS forwarder only
model, only the single emulated LAN would be included in spanning tree.=20

As I said during the L2 VPN meeting, I believe that choosing the correct
reference model is a decision to be made by the working group.
Therefore, please use the mailing list to state your views on the
correct reference model to be used for a H-VPLS node.

Cheers,
Olen
















From l2vpn-bounces@ietf.org Wed Dec 12 15:13:17 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2XxB-0007KF-GL; Wed, 12 Dec 2007 15:13:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Xx9-0007Jy-Cy
	for l2vpn@ietf.org; Wed, 12 Dec 2007 15:13:11 -0500
Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Xx7-0000Qx-E5
	for l2vpn@ietf.org; Wed, 12 Dec 2007 15:13:11 -0500
Received: from unknown (HELO ILPTAM01.ecitele.com) ([172.31.244.55])
	by iron.ecitele.com with ESMTP; 12 Dec 2007 22:22:40 +0200
Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by
	ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Wed, 12 Dec 2007 22:13:08 +0200
Received: from ILPTMAIL01.ecitele.com (147.234.245.210) by
	ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id
	8.1.240.5; Wed, 12 Dec 2007 22:13:07 +0200
Received: from USPITMAIL01.ecitele.com ([10.0.0.81]) by ILPTMAIL01.ecitele.com
	with Microsoft SMTPSVC(6.0.3790.3959);
	Wed, 12 Dec 2007 22:13:07 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 Dec 2007 15:13:03 -0500
Message-ID: <4EF7ED00175A4E4DAE68A5EE31A4F91E588405@USPITMAIL01.ecitele.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Reference model for H-VPLS node
Thread-Index: Acg8yeroZuO1utwaSeSgEbtOlXvELwABiJ6wAAoiewA=
References: <475FEE24.3060906@lucent.com>
	
From: Jeremy Brayley 
To: "VISSERS Maarten" ,
	"Olen Stokes" 
X-OriginalArrivalTime: 12 Dec 2007 20:13:07.0461 (UTC)
	FILETIME=[68E8E350:01C83CFB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b
Cc: l2vpn@ietf.org
Subject: RE: Reference model for H-VPLS node
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: l2vpn-bounces@ietf.org

Maarten,

> -----Original Message-----
> From: VISSERS Maarten [mailto:Maarten.Vissers@alcatel-lucent.de]=20
> Sent: Wednesday, December 12, 2007 12:24 PM
> To: Olen Stokes
> Cc: l2vpn@ietf.org
> Subject: RE: Reference model for H-VPLS node
>=20
> Olen,
>=20
> I made the following reference model for this figure 2,=20
> assuming the there are VPLSs between the MTU and the PE-rs. I=20
> have included all PW's that terminate in the PE1-rs and=20
> PE3-rs nodes; i.e. also PW-12 and PW-23.
>=20
>                                      PW-23-|
>                                |-PW-12     |
>              |--- PW-1 ---|    ||- PW-13 -||    |--- PW-3 ---|
>    Emulated  |            |    ||         ||    |            |
>     LAN      |            |    ||         ||    |            |
>   =20
> .....................................................................
>    .         |            |    ||         ||    |           =20
> |         .
>    . |-------|-----|  |---|----||---| |---||----|---| =20
> |-----|-------| .
>    . | ----------- |  | ----- ----- | | ----- ----- |  |=20
> ----------- | .
>    . |     VPLS    |  | VPLS| |VPLS | | VPLS| |VPLS |  |    =20
> VPLS    | .
>    . |  Forwarder  |  | Fwdr| |Fwdr | | Fwdr| |Fwdr |  | =20
> Forwarder  | .
>    . | -----|----- |  | --|-- --|-- | | --|-- --|-- |  |=20
> -----|----- | .
>   =20
> ..|.................................................|................
>      |      |      |  |   |     |   | |   |     |   |  |      |      |
>      |      |      |  |   |     |   | |   |     |   |  |      |      |
>      | -----|----- |  | --|-----|-- | | --|-----|-- |  | -----|----- |
>      | |         | |  | |         | | | |         | |  | |         | |
>      | | Bridge  | |  | | Bridge  | | | | Bridge  | |  | | Bridge  | |
>      | |         | |  | |         | | | |         | |  | |         | |
>=20
>          MTU1-s            PE1-rs          PE3-rs           MTU3-s
>=20
> 					FIGURE A
>=20
> In your model, you assume that there are no VPLSs present=20
> between MTU and PE-rs. This would then result in the=20
> following model (Figure B), in which also the PW-12 and PW-23=20
> are included.
>=20
>                                      PW-23-|
>                                |-PW-12     |
>              |--- PW-1 ---|    ||- PW-13 -||    |--- PW-3 ---|
>    Emulated  |            |    ||         ||    |            |
>     LAN      |            |    ||         ||    |            |
>   =20
> .....................................................................
>    .         |            |    ||         ||    |           =20
> |         .
>    . |-------|-----|  |---|----||---| |---||----|---| =20
> |-----|-------| .
>    . |       |     |  |   |   ----- | | -----   |   |  |    =20
> |       | .
>    . |       |     |  |   |   |VPLS | | VPLS|   |   |  |    =20
> |       | .
>    . |       |     |  |   |   |Fwdr | | Fwdr|   |   |  |    =20
> |       | .
>    . |       |     |  |   |   --|-- | | --|--   |   |  |    =20
> |       | .
>   =20
> ..|.................................................|................
>      |       |     |  |   |     |   | |   |     |   |  |     |       |
>      |       |     |  |   |     |   | |   |     |   |  |     |       |
>      | ------|---- |  | --|-----|-- | | --|-----|-- |  | ----|------ |
>      | |         | |  | |         | | | |         | |  | |         | |
>      | | Bridge  | |  | | Bridge  | | | | Bridge  | |  | | Bridge  | |
>      | |         | |  | |         | | | |         | |  | |         | |
>=20
>          MTU1-s            PE1-rs          PE3-rs           MTU3-s
>=20
> 					FIGURE B
>=20
> The Bridge and VPLS Forwarder functions are in terms of=20
> 802.1Q part of the MAC Relay function. We have to consider=20
> now the different VPLS
> modes: tree-structured and full-mesh.=20
>=20
> In tree-structured mode the VPLS Forwarder has only 1 PW=20
> associated with the in/output port it has with the bridge=20
> function; it essentially becomes a null function and can be=20
> omitted, as is done in the case of
> PW-1 and PW-3.
>=20
> In full-mesh mode the VPLS Forwarder provides a split-horizon=20
> functionality, which is similar to the MAC Relay=20
> functionality specified for "Asymmetric-VLANs in Shared VLAN=20
> Learning (SVL) mode" as specified in clause B.1.3/802.1Q.
>=20
> For a full-mesh VPLS, the 802.1Q MAC Relay function combines=20
> the regular any-to-any MAC forwarding within the (Independent=20
> VLAN Learning (IVL)
> mode) VLAN with the "Asymmetric-VLANs in SVL mode". I.e. some=20
> of the ports of the VLAN on this MAC RElay (encompassing the=20
> bridge and VPLS Forwarder functionality) are more special=20
> (split-horizon) than other ports of the VLAN.
>=20
> >From an 802.1Q/ag perspective, this will then result in the following
> location of Ethernet MEPs and MIPs (see Figure C), assuming=20
> that the MTU-s's have a MEP at MD Level 4. Consequently, the=20
> Ethernet MIPs that are located between the PW and Bridge=20
> (PW-1, PW-3), or the PW and the VPLS Forwarder=20
> (PW-12,PW-13,PW-23) are also having MD Level 4.
>=20
>                                      PW-23-|
>                                |-PW-12     |
>              |--- PW-1 ---|    ||- PW-13 -||    |--- PW-3 ---|
>    Emulated  |            |    ||         ||    |            |
>     LAN      |            |    ||         ||    |            |
>   =20
> .....................................................................
>    . |-------|-----|  |---|----||---| |---||----|---| =20
> |-----|-------| .
>      |  MIP X MD   |  |MD X MIPXX MD| |MD XXMIP X MD|  | MIP X MD    |
>      |      | L4   |  |L4 |    || L4| |L4 ||    | L4|  |     | L4    |
>      |      |      |  |   |    ||   | |   ||    |   |  |     |       |
>    . |      |      |  |   |    ||   | |   ||    |   |  |     |       |
> .
>    . |      |      |  |   |   ----- | | -----   |   |  |    =20
> |       | .
>    . |      |      |  |   |   |VPLS | | VPLS|   |   |  |    =20
> |       | .
>    . |      |      |  |   |   |Fwdr | | Fwdr|   |   |  |    =20
> |       | .
>    . |      |      |  |   |   --|-- | | --|--   |   |  |     =20
> |      | .
>   =20
> ..|.................................................|................
>      |      |      |  |   |     |   | |   |     |   |  |      |      |
>      |      |      |  |   |     |   | |   |     |   |  |      |      |
>      | -----|----- |  | --|-----|-- | | --|-----|-- |  | -----|----- |
>      | |         | |  | |         | | | |         | |  | |         | |
>      | | Bridge  | |  | | Bridge  | | | | Bridge  | |  | | Bridge  | |
>      | |         | |  | |         | | | |         | |  | |         | |
>      | |    |    | |  | |         | | | |         | |  | |    |    | |
>      | |MEP X MD | |  | |         | | | |         | |  | |MEP X MD | |
>      | |    | L4 | |  | |         | | | |         | |  | |    | L4 | |
> =20
>          MTU-1s           PE1-rs           PE3-rs          MTU-3s
>=20
> 					FIGURE C
>=20
> >From an 802.1Q perspective, the set of PWs within a MPLS tunnel that
> carry VPLS (i.e. VLAN) signals constitute a virtual bridge=20
> port. Such virtual bridge port has an 802.1Q EISS SAP with=20
> the VPLS Forwarder fucntion (as it is part of the MAC Relay).=20
> Over this EISS SAP flows EM_UNITDATA.indication and=20
> EM_UNITDATA.request information.

For clarification...you are saying the "set of PWs within a MPLS tunnel"
constitute a virtual bridge port.  That means the tunnel to a single PE
right (i.e to a single remote VPLS forwarder)?  And it would have
multiple PWs on it only if it supported multiple VPLSs.=20

>From the placement of the MIPs it looks like the VPLS forwarder treats
each tunnel to a PE as a separate virtual port.

Or do you mean that the set of PWs to all PEs consititute a port?

Thanks,

Jeremy

=20
> The endpoint of the set of PWs provide from an 802.1Q=20
> perspective a "support of the EISS" function. Such function=20
> adds in a pure 802.1Q environment a VLAN Tag or a Backbone=20
> Service Instance Tag, while in the hybrid 802.1Q/MPLS=20
> environment it adds a PW label to carry the=20
> EM_UNITDATA.request information over the MPLS tunnel.
>=20
> In this model, the MPLS PW label stack entry provides from=20
> the viewpoint of the 802.1Q environment a Tag which has a=20
> 20-bit "vlan identifier" (to carry the=20
> EM_UNITDATA.request.vlan_identifier parameter information)=20
> and a 3-bit "priority code point" (to carry the=20
> EM_UNITDATA.request.priority and=20
> EM_UNITDATA.request.drop_eligible parameter information. From=20
> the MPLS environment viewpoint, the PW label provides a=20
> 20-bit label and a 3-bit EXP field carrying PHB information.
>=20
> In this model, the VPLS looks from the 802.1Q viewpoint a=20
> VLAN with a "MPLS Label Stack Entry based VLAN Tag" (i.e. an=20
> "M-VLAN Tag" or "M-Tag").
>=20
> As the PW label value for every PW in the VPLS may be=20
> different, and as the PW label value between MTU-s and PE-rs=20
> may be different, the 802.1Q equivalent model of the VPLS=20
> contains a "VID Translation Table" function as specified in 802.1ad.
>=20
> In this model, the MPLS tunnels provide point-to-point=20
> virtual interface ports between MAC Relay functions.=20
>=20
> ----------------
>=20
> There is a second 802.1Q equivalent model possible for VPLS.=20
> In this model each PW endpoint provides a virtual bridge port=20
> supporting a single (untagged) VLAN. The interconnect between=20
> the PW endpoint and the VPLS Forwarder/Bridge function is=20
> then an ISS SAP and M_UNITDATA.request and=20
> M_UNITDATA.indication information is passed over it.
>=20
> The 1-to-1 nature of the VLAN-PW relationship allows to carry=20
> the VLAN untagged. In such case the=20
> M_UNITDATA.request.priority and=20
> M_UNITDATA.request.drop_eligible information is either=20
> dropped (no means to carry it), or is carried via the PW=20
> label (note that in this case the PW label is not longer=20
> performing the "M-Tag" function).
>=20
> It is obvious that the number of virtual bridge ports in this=20
> second model will be much larger than in the first model.=20
> From the 802.1Q environment viewpoint there will now be many=20
> parallel virtual links between two adjacent MAC Relay=20
> functions. This seems more complex then the first model.
>=20
> Regards,
> Maarten
>=20
>=20
>=20
> -------- Originele bericht --------
> Onderwerp: 	Reference model for H-VPLS node
> Datum: 	Wed, 12 Dec 2007 06:12:42 -0800
> Van: 	Olen Stokes 
> Aan: 	l2vpn@ietf.org
>=20
>=20
>=20
> There was significant discussion at the last IETF about the=20
> correct reference model to be used when discussing OAM for a=20
> H-VPLS node.  For the H-VPLS network in Figure 2 of=20
> draft-stokes-l2vpn-cfm-vccv-oam-00.txt, the reference model=20
> described in that draft is shown below in Figure A:
>=20
>          |--- PW-1 ----|  |--- PW-13 ----|  |---- PW-3 ----|
> Emulated |             |  |              |  |              |
> LAN      |             |  |              |  |              |
> ....................................................................
> .        |             |  |              |  |              |       .
> .|-------|-----|  |----|--|-----|  |-----|--|----|  |------|------|.
> .| ----------- |  | ----------- |  | ----------- |  | ----------- |.
> .|     VPLS    |  |     VPLS    |  |     VPLS    |  |    VPLS     |.
> .|  Forwarder  |  |  Forwarder  |  |  Forwarder  |  |  Forwarder  |.
> .| ------|---- |  | -----|----- |  | -----|----- |  | -----|----- |.
> .|.............|..|................|................................
>  |       |     |  |      |      |  |      |      |  |      |      |
>  |       |     |  |      |      |  |      |      |  |------|------|
>  | ------|---- |  | -----|----- |  | -----|----- |  | -----|----- |
>  | |         | |  | |         | |  | |         | |  | |         | |
>  | | Bridge  | |  | | Bridge  | |  | |  Bridge | |  | |  Bridge | |
>  | |         | |  | |         | |  | |         | |  | |         | |
>  | |  |      | |  | |         | |  | |         | |  | |      |  | |
>  | ---|------- |  | ----------- |  | ----------- |  | -------|--- |
> |----|--------|  |-------------|  |-------------|  |--------|----|
>       |                                                      |
>       |                                                      |
>      CE-1                                                  CE-3
>=20
>      MTU1-s            PE1-rs           PE3-rs           MTU3-s
>=20
>      Figure A: H-VPLS node using only VPLS Forwarder connections
>=20
>=20
> An alternative model based on
> http://www3.ietf.org/proceedings/04nov/slides/l2vpn-9.pdf is=20
> shown below in Figure B:
>=20
>                           |--- PW-13 ----|
>                 Emulated  |              |
>                  LAN      |              |
>                 ....................................
>                 .         |              |         .
>                 . |-------|-----|  |-----|-------| .
>                 . | ----------- |  | ----------- | .
>                 . |     VPLS    |  |     VPLS    | .
>                 . |  Forwarder  |  |  Forwarder  | .
>                 . | -----|----- |  | -----|----- | .
>                 ..|................|................
>                   |      |      |  |      |      |
>  |-------------|  |      |      |  |      |      |  |-------------|
>  | ----------- |  | -----|----- |  | -----|----- |  | ----------- |
>  | |         | |  | |         | |  | |         | |  | |         | |
>  | |  Bridge | |  | | Bridge  | |  | |  Bridge | |  | |  Bridge | |
>  | |         | |  | |         | |  | |         | |  | |         | |
>  | |  |   *  | |  | |    *    | |  | |    *    | |  | |  *   |  | |
>  | ---|---|--- |  | -----|----- |  | -----|----- |  | ---|---|--- |
> |----|---|----|  |------|------|  |------|------|  |----|---|----|
>       |   |              |                |              |   |
>       |   |---- PW-1 ----|                |----- PW-3 ---|   |
>      CE-1                                                  CE-3
>=20
>      MTU1-s            PE1-rs           PE3-rs           MTU3-s
>=20
> Note: "*" =3D emulated bridge port
>=20
>     Figure B: H-VPLS node using emulated bridge port connections
>=20
>=20
> Please note that Figure B is my interpretation of Ali's=20
> charts from his November, 2004 presentation.
>=20
> There are definite implications based on the differences of=20
> the two models.
> The VPLS forwarder only model in Figure A treats a H-VPLS=20
> network with PW access the same as a simple full mesh VPLS=20
> network.  The bridge model sees a single emulated LAN=20
> interface to the (H)VPLS network and therefore is not=20
> concerned with the structure of that (H)VPLS network. =20
>=20
> The emulated bridge port model treats a H-VPLS network with=20
> PW access the same as a H-VPLS network with Ethernet access. =20
> In effect, it "separates"
> the network into a full mesh VPLS emulated LAN and individual=20
> access networks that can be PW or Ethernet.  This=20
> "separation" is a result of the presence of the bridge module=20
> between these connections.
>=20
> One difference from an OAM perspective is that the emulated=20
> bridge port model allows 802.1ag MPs to be associated with PW=20
> access connections such as
> PW-1 in Figure B above.=20
>=20
> There may be implications to other protocols such as spanning=20
> tree.  In the emulated bridge port model, PW-1 is seen by the=20
> bridge module and could be considered separately should the=20
> bridge module in PE1-rs participate in spanning tree. =20
> However, in the VPLS forwarder only model, only the single=20
> emulated LAN would be included in spanning tree.=20
>=20
> As I said during the L2 VPN meeting, I believe that choosing=20
> the correct reference model is a decision to be made by the=20
> working group.
> Therefore, please use the mailing list to state your views on=20
> the correct reference model to be used for a H-VPLS node.
>=20
> Cheers,
> Olen
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20




From l2vpn-bounces@ietf.org Fri Dec 14 06:59:50 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J39Ci-000411-Ft; Fri, 14 Dec 2007 06:59:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J39Ch-00040w-QF
	for l2vpn@ietf.org; Fri, 14 Dec 2007 06:59:43 -0500
Received: from smail5.alcatel.fr ([62.23.212.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J39Ce-00035F-M8
	for l2vpn@ietf.org; Fri, 14 Dec 2007 06:59:43 -0500
Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com
	[155.132.6.76])
	by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id lBEBx1wI030173; 
	Fri, 14 Dec 2007 12:59:04 +0100
Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.35]) by
	FRVELSBHS04.ad2.ad.alcatel.com with Microsoft
	SMTPSVC(6.0.3790.2499); Fri, 14 Dec 2007 12:59:31 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 14 Dec 2007 12:59:32 +0100
Message-ID: 
In-Reply-To: <4EF7ED00175A4E4DAE68A5EE31A4F91E588405@USPITMAIL01.ecitele.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Reference model for H-VPLS node
Thread-Index: Acg8yeroZuO1utwaSeSgEbtOlXvELwABiJ6wAAoiewAAUXQXwA==
From: "VISSERS Maarten" 
To: "Jeremy Brayley" ,
	"Olen Stokes" 
X-OriginalArrivalTime: 14 Dec 2007 11:59:31.0285 (UTC)
	FILETIME=[C91E9050:01C83E48]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29
Cc: l2vpn@ietf.org
Subject: RE: Reference model for H-VPLS node
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: l2vpn-bounces@ietf.org

Jeremy,

> For clarification...you are saying the "set of PWs within a
> MPLS tunnel" constitute a virtual bridge port.  That means
> the tunnel to a single PE right (i.e to a single remote VPLS
> forwarder)? =20

Yes, it is the set of PWs within a single MPLS tunnel between two PEs.=20
If there are n PEs at the edge of a tunnel domain (e.g. a core domain),
then there are n-1 MPLS tunnels on a PE, and thus n-1 virtual bridge
ports.

> And it would have multiple PWs on it only if it supported
> multiple VPLSs.=20

Yes, each virtual bridge port and its associated MPLS tunnel has one PW
for every VPLS instance connected to it.

> From the placement of the MIPs it looks like the VPLS forwarder
> treats each tunnel to a PE as a separate virtual port.

Yes, each MPLS tunnel between the local PE and a remote PE is treated as
a separate virtual bridge port.

> Or do you mean that the set of PWs to all PEs consititute a port?

No.

-------

It may be helpful to clarify the above with a figure, assuming the local
node is PE1. PE1 is connected with PE2,PE3 and PE4 via a full mesh of
MPLS tunnels. PE1 is connected with a single MPLS tunnel to PE5 (PE5 is
not connected to PE2/3/4) and with another MPLS tunnel to MTU1.
PE1/2/3/4 will deploy full-mesh VPLSs, while PE1/PE5 and PE1/MTU1 deploy
tree-structured VPLSs.

The Brdige function has ports to VPLS Forwarders and ports to virtual
bridge ports. The VPLS Forwarders have ports to one or more virtual
bridge ports.

The Bridge function and VPLS Forwarders are part of the MAC Relay
function.

 .............................................................
 .                           MAC Relay                       .
 . --------------------------------------------------------- .
 . |              Bridge  with VLAN/VPLS instances         | .
 . --------------------------------------------------------- .
 .      |                 |            ||||       |||||      .
 . -----------       -----------       ||||       |||||      .
 . |  VPLS   | ....  |  VPLS   |       ||||       |||||      .
 . |Forwarder|       |Forwarder|       ||||       |||||      .
 . -----------       -----------       ||||       |||||      .
 .    /\\            ____/\            ||||       |||||      .
 .   /  \\__________/_____ \           ||||       |||||      .
 .   |   \______    |     \ \          ||||       |||||      .
 .   |          \   |      \|          ||||       |||||      .
 ....|||||......|||||......||||........||||.......|||||.......
     |||||EISS  |||||EISS  ||||EISS    ||||EISS   |||||EISS
     |||||      |||||      ||||        ||||       |||||     ^
   ---------  ---------  ---------   ---------  ---------   |
   |virtual|  |virtual|  |virtual|   |virtual|  |virtual| VLANs
   |bridge |  |bridge |  |bridge |   |bridge |  |bridge |
   |port   |  |port   |  |port   |   |port   |  |port   | PWs
   ---------  ---------  ---------   ---------  ---------  |
      |           |          |           |          |      V
   --------   --------   --------    --------   --------=20
   | MPLS |   | MPLS |   | MPLS |    | MPLS |   | MPLS |
   |Tunnel|   |Tunnel|   |Tunnel|    |Tunnel|   |Tunnel|
   | MEP  |   | MEP  |   |  MEP |    | MEP  |   | MEP  |
   --------   --------   --------    --------   --------
      |          |          |            |          |
    to PE2     to PE3     to PE4      to PE5    to MTU1

Regards,
Maarten

-----Original Message-----
From: Jeremy Brayley [mailto:Jeremy.Brayley@ecitele.com]=20
Sent: woensdag 12 december 2007 21:13
To: VISSERS Maarten; Olen Stokes
Cc: l2vpn@ietf.org
Subject: RE: Reference model for H-VPLS node

Maarten,

> -----Original Message-----
> From: VISSERS Maarten [mailto:Maarten.Vissers@alcatel-lucent.de]
> Sent: Wednesday, December 12, 2007 12:24 PM
> To: Olen Stokes
> Cc: l2vpn@ietf.org
> Subject: RE: Reference model for H-VPLS node
>=20
> Olen,
>=20
> I made the following reference model for this figure 2, assuming the=20
> there are VPLSs between the MTU and the PE-rs. I have included all=20
> PW's that terminate in the PE1-rs and PE3-rs nodes; i.e. also PW-12=20
> and PW-23.
>=20
>                                      PW-23-|
>                                |-PW-12     |
>              |--- PW-1 ---|    ||- PW-13 -||    |--- PW-3 ---|
>    Emulated  |            |    ||         ||    |            |
>     LAN      |            |    ||         ||    |            |
>   =20
> .....................................................................
>    .         |            |    ||         ||    |           =20
> |         .
>    . |-------|-----|  |---|----||---| |---||----|---|
> |-----|-------| .
>    . | ----------- |  | ----- ----- | | ----- ----- |  |
> ----------- | .
>    . |     VPLS    |  | VPLS| |VPLS | | VPLS| |VPLS |  |    =20
> VPLS    | .
>    . |  Forwarder  |  | Fwdr| |Fwdr | | Fwdr| |Fwdr |  | Forwarder  |=20
> .
>    . | -----|----- |  | --|-- --|-- | | --|-- --|-- |  |
> -----|----- | .
>   =20
> ..|.................................................|................
>      |      |      |  |   |     |   | |   |     |   |  |      |      |
>      |      |      |  |   |     |   | |   |     |   |  |      |      |
>      | -----|----- |  | --|-----|-- | | --|-----|-- |  | -----|----- |
>      | |         | |  | |         | | | |         | |  | |         | |
>      | | Bridge  | |  | | Bridge  | | | | Bridge  | |  | | Bridge  | |
>      | |         | |  | |         | | | |         | |  | |         | |
>=20
>          MTU1-s            PE1-rs          PE3-rs           MTU3-s
>=20
> 					FIGURE A
>=20
> In your model, you assume that there are no VPLSs present between MTU=20
> and PE-rs. This would then result in the following model (Figure B),=20
> in which also the PW-12 and PW-23 are included.
>=20
>                                      PW-23-|
>                                |-PW-12     |
>              |--- PW-1 ---|    ||- PW-13 -||    |--- PW-3 ---|
>    Emulated  |            |    ||         ||    |            |
>     LAN      |            |    ||         ||    |            |
>   =20
> .....................................................................
>    .         |            |    ||         ||    |           =20
> |         .
>    . |-------|-----|  |---|----||---| |---||----|---|
> |-----|-------| .
>    . |       |     |  |   |   ----- | | -----   |   |  |    =20
> |       | .
>    . |       |     |  |   |   |VPLS | | VPLS|   |   |  |    =20
> |       | .
>    . |       |     |  |   |   |Fwdr | | Fwdr|   |   |  |    =20
> |       | .
>    . |       |     |  |   |   --|-- | | --|--   |   |  |    =20
> |       | .
>   =20
> ..|.................................................|................
>      |       |     |  |   |     |   | |   |     |   |  |     |       |
>      |       |     |  |   |     |   | |   |     |   |  |     |       |
>      | ------|---- |  | --|-----|-- | | --|-----|-- |  | ----|------ |
>      | |         | |  | |         | | | |         | |  | |         | |
>      | | Bridge  | |  | | Bridge  | | | | Bridge  | |  | | Bridge  | |
>      | |         | |  | |         | | | |         | |  | |         | |
>=20
>          MTU1-s            PE1-rs          PE3-rs           MTU3-s
>=20
> 					FIGURE B
>=20
> The Bridge and VPLS Forwarder functions are in terms of 802.1Q part of

> the MAC Relay function. We have to consider now the different VPLS
> modes: tree-structured and full-mesh.=20
>=20
> In tree-structured mode the VPLS Forwarder has only 1 PW associated=20
> with the in/output port it has with the bridge function; it=20
> essentially becomes a null function and can be omitted, as is done in=20
> the case of
> PW-1 and PW-3.
>=20
> In full-mesh mode the VPLS Forwarder provides a split-horizon=20
> functionality, which is similar to the MAC Relay functionality=20
> specified for "Asymmetric-VLANs in Shared VLAN Learning (SVL) mode" as

> specified in clause B.1.3/802.1Q.
>=20
> For a full-mesh VPLS, the 802.1Q MAC Relay function combines the=20
> regular any-to-any MAC forwarding within the (Independent VLAN=20
> Learning (IVL)
> mode) VLAN with the "Asymmetric-VLANs in SVL mode". I.e. some of the=20
> ports of the VLAN on this MAC RElay (encompassing the bridge and VPLS=20
> Forwarder functionality) are more special
> (split-horizon) than other ports of the VLAN.
>=20
> >From an 802.1Q/ag perspective, this will then result in the following
> location of Ethernet MEPs and MIPs (see Figure C), assuming that the=20
> MTU-s's have a MEP at MD Level 4. Consequently, the Ethernet MIPs that

> are located between the PW and Bridge (PW-1, PW-3), or the PW and the=20
> VPLS Forwarder
> (PW-12,PW-13,PW-23) are also having MD Level 4.
>=20
>                                      PW-23-|
>                                |-PW-12     |
>              |--- PW-1 ---|    ||- PW-13 -||    |--- PW-3 ---|
>    Emulated  |            |    ||         ||    |            |
>     LAN      |            |    ||         ||    |            |
>   =20
> .....................................................................
>    . |-------|-----|  |---|----||---| |---||----|---|
> |-----|-------| .
>      |  MIP X MD   |  |MD X MIPXX MD| |MD XXMIP X MD|  | MIP X MD    |
>      |      | L4   |  |L4 |    || L4| |L4 ||    | L4|  |     | L4    |
>      |      |      |  |   |    ||   | |   ||    |   |  |     |       |
>    . |      |      |  |   |    ||   | |   ||    |   |  |     |       |
> .
>    . |      |      |  |   |   ----- | | -----   |   |  |    =20
> |       | .
>    . |      |      |  |   |   |VPLS | | VPLS|   |   |  |    =20
> |       | .
>    . |      |      |  |   |   |Fwdr | | Fwdr|   |   |  |    =20
> |       | .
>    . |      |      |  |   |   --|-- | | --|--   |   |  |     =20
> |      | .
>   =20
> ..|.................................................|................
>      |      |      |  |   |     |   | |   |     |   |  |      |      |
>      |      |      |  |   |     |   | |   |     |   |  |      |      |
>      | -----|----- |  | --|-----|-- | | --|-----|-- |  | -----|----- |
>      | |         | |  | |         | | | |         | |  | |         | |
>      | | Bridge  | |  | | Bridge  | | | | Bridge  | |  | | Bridge  | |
>      | |         | |  | |         | | | |         | |  | |         | |
>      | |    |    | |  | |         | | | |         | |  | |    |    | |
>      | |MEP X MD | |  | |         | | | |         | |  | |MEP X MD | |
>      | |    | L4 | |  | |         | | | |         | |  | |    | L4 | |
> =20
>          MTU-1s           PE1-rs           PE3-rs          MTU-3s
>=20
> 					FIGURE C
>=20
> >From an 802.1Q perspective, the set of PWs within a MPLS tunnel that
> carry VPLS (i.e. VLAN) signals constitute a virtual bridge port. Such=20
> virtual bridge port has an 802.1Q EISS SAP with the VPLS Forwarder=20
> fucntion (as it is part of the MAC Relay).
> Over this EISS SAP flows EM_UNITDATA.indication and=20
> EM_UNITDATA.request information.

For clarification...you are saying the "set of PWs within a MPLS tunnel"
constitute a virtual bridge port.  That means the tunnel to a single PE
right (i.e to a single remote VPLS forwarder)?  And it would have
multiple PWs on it only if it supported multiple VPLSs.=20

>From the placement of the MIPs it looks like the VPLS forwarder treats
each tunnel to a PE as a separate virtual port.

Or do you mean that the set of PWs to all PEs consititute a port?

Thanks,

Jeremy

=20
> The endpoint of the set of PWs provide from an 802.1Q perspective a=20
> "support of the EISS" function. Such function adds in a pure 802.1Q=20
> environment a VLAN Tag or a Backbone Service Instance Tag, while in=20
> the hybrid 802.1Q/MPLS environment it adds a PW label to carry the=20
> EM_UNITDATA.request information over the MPLS tunnel.
>=20
> In this model, the MPLS PW label stack entry provides from the=20
> viewpoint of the 802.1Q environment a Tag which has a 20-bit "vlan=20
> identifier" (to carry the EM_UNITDATA.request.vlan_identifier=20
> parameter information) and a 3-bit "priority code point" (to carry the

> EM_UNITDATA.request.priority and EM_UNITDATA.request.drop_eligible=20
> parameter information. From the MPLS environment viewpoint, the PW=20
> label provides a 20-bit label and a 3-bit EXP field carrying PHB=20
> information.
>=20
> In this model, the VPLS looks from the 802.1Q viewpoint a VLAN with a=20
> "MPLS Label Stack Entry based VLAN Tag" (i.e. an "M-VLAN Tag" or=20
> "M-Tag").
>=20
> As the PW label value for every PW in the VPLS may be different, and=20
> as the PW label value between MTU-s and PE-rs may be different, the=20
> 802.1Q equivalent model of the VPLS contains a "VID Translation Table"

> function as specified in 802.1ad.
>=20
> In this model, the MPLS tunnels provide point-to-point virtual=20
> interface ports between MAC Relay functions.
>=20
> ----------------
>=20
> There is a second 802.1Q equivalent model possible for VPLS.=20
> In this model each PW endpoint provides a virtual bridge port=20
> supporting a single (untagged) VLAN. The interconnect between the PW=20
> endpoint and the VPLS Forwarder/Bridge function is then an ISS SAP and

> M_UNITDATA.request and M_UNITDATA.indication information is passed=20
> over it.
>=20
> The 1-to-1 nature of the VLAN-PW relationship allows to carry the VLAN

> untagged. In such case the M_UNITDATA.request.priority and=20
> M_UNITDATA.request.drop_eligible information is either dropped (no=20
> means to carry it), or is carried via the PW label (note that in this=20
> case the PW label is not longer performing the "M-Tag" function).
>=20
> It is obvious that the number of virtual bridge ports in this second=20
> model will be much larger than in the first model.
> From the 802.1Q environment viewpoint there will now be many parallel=20
> virtual links between two adjacent MAC Relay functions. This seems=20
> more complex then the first model.
>=20
> Regards,
> Maarten
>=20
>=20
>=20
> -------- Originele bericht --------
> Onderwerp: 	Reference model for H-VPLS node
> Datum: 	Wed, 12 Dec 2007 06:12:42 -0800
> Van: 	Olen Stokes 
> Aan: 	l2vpn@ietf.org
>=20
>=20
>=20
> There was significant discussion at the last IETF about the correct=20
> reference model to be used when discussing OAM for a H-VPLS node.  For

> the H-VPLS network in Figure 2 of=20
> draft-stokes-l2vpn-cfm-vccv-oam-00.txt, the reference model described=20
> in that draft is shown below in Figure A:
>=20
>          |--- PW-1 ----|  |--- PW-13 ----|  |---- PW-3 ----|
> Emulated |             |  |              |  |              |
> LAN      |             |  |              |  |              |
> ....................................................................
> .        |             |  |              |  |              |       .
> .|-------|-----|  |----|--|-----|  |-----|--|----|  |------|------|.
> .| ----------- |  | ----------- |  | ----------- |  | ----------- |.
> .|     VPLS    |  |     VPLS    |  |     VPLS    |  |    VPLS     |.
> .|  Forwarder  |  |  Forwarder  |  |  Forwarder  |  |  Forwarder  |.
> .| ------|---- |  | -----|----- |  | -----|----- |  | -----|----- |.
> .|.............|..|................|................................
>  |       |     |  |      |      |  |      |      |  |      |      |
>  |       |     |  |      |      |  |      |      |  |------|------|
>  | ------|---- |  | -----|----- |  | -----|----- |  | -----|----- |
>  | |         | |  | |         | |  | |         | |  | |         | |
>  | | Bridge  | |  | | Bridge  | |  | |  Bridge | |  | |  Bridge | |
>  | |         | |  | |         | |  | |         | |  | |         | |
>  | |  |      | |  | |         | |  | |         | |  | |      |  | |
>  | ---|------- |  | ----------- |  | ----------- |  | -------|--- |
> |----|--------|  |-------------|  |-------------|  |--------|----|
>       |                                                      |
>       |                                                      |
>      CE-1                                                  CE-3
>=20
>      MTU1-s            PE1-rs           PE3-rs           MTU3-s
>=20
>      Figure A: H-VPLS node using only VPLS Forwarder connections
>=20
>=20
> An alternative model based on
> http://www3.ietf.org/proceedings/04nov/slides/l2vpn-9.pdf is shown=20
> below in Figure B:
>=20
>                           |--- PW-13 ----|
>                 Emulated  |              |
>                  LAN      |              |
>                 ....................................
>                 .         |              |         .
>                 . |-------|-----|  |-----|-------| .
>                 . | ----------- |  | ----------- | .
>                 . |     VPLS    |  |     VPLS    | .
>                 . |  Forwarder  |  |  Forwarder  | .
>                 . | -----|----- |  | -----|----- | .
>                 ..|................|................
>                   |      |      |  |      |      |
>  |-------------|  |      |      |  |      |      |  |-------------|
>  | ----------- |  | -----|----- |  | -----|----- |  | ----------- |
>  | |         | |  | |         | |  | |         | |  | |         | |
>  | |  Bridge | |  | | Bridge  | |  | |  Bridge | |  | |  Bridge | |
>  | |         | |  | |         | |  | |         | |  | |         | |
>  | |  |   *  | |  | |    *    | |  | |    *    | |  | |  *   |  | |
>  | ---|---|--- |  | -----|----- |  | -----|----- |  | ---|---|--- |
> |----|---|----|  |------|------|  |------|------|  |----|---|----|
>       |   |              |                |              |   |
>       |   |---- PW-1 ----|                |----- PW-3 ---|   |
>      CE-1                                                  CE-3
>=20
>      MTU1-s            PE1-rs           PE3-rs           MTU3-s
>=20
> Note: "*" =3D emulated bridge port
>=20
>     Figure B: H-VPLS node using emulated bridge port connections
>=20
>=20
> Please note that Figure B is my interpretation of Ali's charts from=20
> his November, 2004 presentation.
>=20
> There are definite implications based on the differences of the two=20
> models.
> The VPLS forwarder only model in Figure A treats a H-VPLS network with

> PW access the same as a simple full mesh VPLS network.  The bridge=20
> model sees a single emulated LAN interface to the (H)VPLS network and=20
> therefore is not concerned with the structure of that (H)VPLS network.
>=20
> The emulated bridge port model treats a H-VPLS network with PW access=20
> the same as a H-VPLS network with Ethernet access.
> In effect, it "separates"
> the network into a full mesh VPLS emulated LAN and individual access=20
> networks that can be PW or Ethernet.  This "separation" is a result of

> the presence of the bridge module between these connections.
>=20
> One difference from an OAM perspective is that the emulated bridge=20
> port model allows 802.1ag MPs to be associated with PW access=20
> connections such as
> PW-1 in Figure B above.=20
>=20
> There may be implications to other protocols such as spanning tree. =20
> In the emulated bridge port model, PW-1 is seen by the bridge module=20
> and could be considered separately should the bridge module in PE1-rs=20
> participate in spanning tree.
> However, in the VPLS forwarder only model, only the single emulated=20
> LAN would be included in spanning tree.
>=20
> As I said during the L2 VPN meeting, I believe that choosing the=20
> correct reference model is a decision to be made by the working group.
> Therefore, please use the mailing list to state your views on the=20
> correct reference model to be used for a H-VPLS node.
>=20
> Cheers,
> Olen
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20




From l2vpn-bounces@ietf.org Mon Dec 17 01:06:40 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J496n-0005zp-FL; Mon, 17 Dec 2007 01:05:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1J496l-0005zJ-JT
	for l2vpn@ietf.org; Mon, 17 Dec 2007 01:05:43 -0500
Received: from dog.tcb.net ([64.78.150.133])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J496h-0005Bi-6k
	for l2vpn@ietf.org; Mon, 17 Dec 2007 01:05:39 -0500
Received: by dog.tcb.net (Postfix, from userid 0)
	id 9FDD5268096; Sun, 16 Dec 2007 23:05:38 -0700 (MST)
Received: from pmac.castlepoint.net (71-218-122-107.hlrn.qwest.net
	[71.218.122.107]) (authenticated-user smtp)
	(TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP;
	for l2vpn@ietf.org; Sun, 16 Dec 2007 23:05:38 -0700 (MST)
	(envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.218.122.107;
	client-port=4375; syn-fingerprint=65535:55:1:64:M1460,N,W3,N,N,T,S MacOS
	10.4.8; data-bytes=0
Message-Id: <8A1D10D0-D9B3-4AAC-B712-132645A2EDB0@castlepoint.net>
From: Shane Amante 
To: l2vpn@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Sun, 16 Dec 2007 23:05:23 -0700
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Subject: IETF 70: DRAFT L2VPN WG Meeting Minutes
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: l2vpn-bounces@ietf.org

The following are the DRAFT meeting minutes of IETF 70 L2VPN WG  
meeting in Vancouver, BC, Canada:
http://www3.ietf.org/proceedings/07dec/minutes/l2vpn.txt

Please take a look and mail the chairs if there are changes.  Changes  
are due by January 4, 2008.

-shane & Vach