From l2vpn-bounces@ietf.org Mon Nov 06 12:20:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh88G-00026c-O6; Mon, 06 Nov 2006 12:19:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh88E-000240-K0 for l2vpn@ietf.org; Mon, 06 Nov 2006 12:19:34 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh889-0005ul-0X for l2vpn@ietf.org; Mon, 06 Nov 2006 12:19:34 -0500 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 79EAA64373 for ; Mon, 6 Nov 2006 10:19:18 -0700 (MST) Message-ID: <454F6E92.5090805@castlepoint.net> Date: Mon, 06 Nov 2006 10:19:14 -0700 From: Shane Amante User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) 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: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: IETF 67: l2vpn WG slides 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 Folks, If you haven't done so already, please send Vach & I a copy of your slides ASAP so we can upload them to the IETF Meeting Materials Server *prior* to the L2VPN WG meeting this afternoon! Thanks! -shane & Vach From l2vpn-bounces@ietf.org Mon Nov 06 12:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8Pm-0006jK-VS; Mon, 06 Nov 2006 12:37:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8Pl-0006jD-Uh for l2vpn@ietf.org; Mon, 06 Nov 2006 12:37:41 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh8Ph-0008Tj-O9 for l2vpn@ietf.org; Mon, 06 Nov 2006 12:37:41 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2006 09:37:37 -0800 X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="339966249:sNHT88615436" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6Hbavt003457; Mon, 6 Nov 2006 09:37:36 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA6Hbair006582; Mon, 6 Nov 2006 09:37:36 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 09:37:36 -0800 Received: from [130.129.66.141] ([10.21.146.29]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 09:37:35 -0800 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550ACBFBF8@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B1550ACBFBF8@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <49C29F9C-1875-4BCA-8CBB-EFFC7DE2A8D5@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Mon, 6 Nov 2006 09:37:34 -0800 To: "Wijnen, Bert (Bert)" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Nov 2006 17:37:35.0952 (UTC) FILETIME=[3F3FDD00:01C701CA] DKIM-Signature: a=rsa-sha1; q=dns; l=3890; t=1162834656; x=1163698656; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:Re=3A=20draft-nadeau-l2vpn-vpls-mib-01.txt; X=v=3Dcisco.com=3B=20h=3Dg3q3skXWESpaCKQ/D2nJqx2YI9o=3D; b=LCrZn4x/N/FRZ5G7IgbO/4pCdMjbOZw3goSuKPQzimc2dX+Riu4ZvjrJo0VOIIFOZ2cW9nGy SxeBc6P28z+lg+kKux/2sVJ96d786GM4KpX783jWRuNRmkYx5eS3cfQU; Authentication-Results: sj-dkim-1.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: l2vpn@ietf.org, Shane Amante , Vach Kompella , A Kiran Koushik S Subject: Re: draft-nadeau-l2vpn-vpls-mib-01.txt 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, Sorry for delay. The response was to an email account I don't read very often. > Hi.... I only did a very very quick scan of the MIB module > in the document. Here are some findings (I understand this > is not yet at WGLC, so understandably somethings are not > yet in good shape): > > - Read-write objects/tables need to specify persistency behaviour > This should be well know to this WG and the authors by now, > and I keep encouring that people do so from the very first stages > of writing a MIB document. There is still discussion about whether or not to make these modules read-only, which is why we avoided spending much time on the above. > - There is two times the copyright statement in the DESCRIPTION > clause of vplsGenericDraft01MIB. > - In DESCRIPTION clause of vplsConfigEntry it is stated that > an active row CANNOT be changed, while in the RowStatus > object of that table he states that an active row CAN be > changed. That is conflicting info. > - naming concepts/consistency > VplsConfigEntry ::= > SEQUENCE { > vplsIndex Unsigned32, > vplsName SnmpAdminString, > vplsDescr SnmpAdminString, > vplsAdminStatus INTEGER, > vplsMacLearning TruthValue, > vplsDiscardUnknownDest TruthValue, > vplsMacAging TruthValue, > vplsConfigFwdFullHighWatermark Unsigned32, > vplsConfigFwdFullLowWatermark Unsigned32, > vplsRowStatus RowStatus, > vplsMtu Unsigned32 > } > I would have all those objects have a prefix of vplsConfigXxxx > - same naming issue here: > VplsStatusEntry ::= > SEQUENCE { > vplsOperStatus INTEGER, > vplsVpnId VPNIdOrZero > } > - and here: > VplsPwBindEntry ::= > SEQUENCE { > vplsPwIndex PwIndexType, > vplsPwConfigType INTEGER, > vplsPwBindRowStatus RowStatus > } > - the vplsModuleReadOnlyCompliance seems bogus to me. > - all groups seem mandatory, but listed separately instead of > being listed as MANDATORY-GROUPS > - speaks about ReadOnly compliance while non of the writable > objects are specified as being OK to be supported read-only It is there as a place-holder for now. I didn't want to focus too much on the conformance statements until the objects are solid since the conformance clauses can be very time consuming. I think the next version will be pretty stable, so we can address the conformance clauses then. > I have no looked at the other MIB module in there; Please make > sure that if any similar issues as above are in that module that > you also address them. Agreed, and thanks for reviewing. --Tom > > Hope this helps, > Bert > > >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:thomasdnadeau@gmail.com] >> Sent: Thursday, September 14, 2006 16:22 >> To: l2vpn@ietf.org >> Cc: Shane Amante; Vach Kompella; A Kiran Koushik S >> Subject: draft-nadeau-l2vpn-vpls-mib-01.txt >> >> >> >> L2VPN WG, >> >> Kiran and I have worked hard to try to incorporate >> all of the comments brought by the WG after we presented >> the draft. Many objected to the document being accepted >> as a WG draft until these things were incorporated. Now >> that most of these comments have been added, we would >> like to again ask that the document be accepted as a >> L2 VPN WG draft. >> >> --Tom >> >> >> From l2vpn-bounces@ietf.org Mon Nov 06 16:44:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCF6-00079R-GB; Mon, 06 Nov 2006 16:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCF5-00077j-4u for l2vpn@ietf.org; Mon, 06 Nov 2006 16:42:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCDv-0006ka-U3 for l2vpn@ietf.org; Mon, 06 Nov 2006 16:41:45 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Nov 2006 22:41:44 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALs6T0WQ/uCKY2dsb2JhbACMQBQPKg X-IronPort-AV: i="4.09,392,1157320800"; d="scan'208"; a="117545917:sNHT24153556" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6Lfh2I029600 for ; Mon, 6 Nov 2006 22:41:43 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA6Lfh4Z021763 for ; Mon, 6 Nov 2006 22:41:43 +0100 (MET) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 22:41:42 +0100 Received: from [130.129.66.141] ([10.61.81.47]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 13:41:42 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <2CAFFA8D-7CA5-487E-A08E-A9298D85834E@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: l2vpn@ietf.org From: "Thomas D. Nadeau" Date: Mon, 6 Nov 2006 13:41:41 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Nov 2006 21:41:42.0703 (UTC) FILETIME=[5964B3F0:01C701EC] DKIM-Signature: a=rsa-sha1; q=dns; l=198; t=1162849303; x=1163713303; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:consensus=20to=20make=20draft-nadeau-l2vpn-vpls-mib-01=20l2vpn=20WG=20do cument; X=v=3Dcisco.com=3B=20h=3DJ8G/TKp5od3sGj3q40UoxIrrySI=3D; b=jp0A4mr7yyImbcPlRAgHvneh4ECeaiNRMUYMSuJcovWF5Hzv37b4U582L4fd3y8JExjMEsXf CgSx2PgGcBxDzEWYgONW3Z/xK9e2VFwd8T4F7xZnLi2k+jomDCGwMI34; Authentication-Results: ams-dkim-1; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: consensus to make draft-nadeau-l2vpn-vpls-mib-01 l2vpn WG document 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 During the meeting I asked for a consensus to make draft-nadeau-l2vpn-vpls-mib-01 l2vpn WG document. The chairs asked that we pose this question on the list. Please comment here. --Tom From l2vpn-bounces@ietf.org Mon Nov 06 16:44:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCFA-0007NY-8M; Mon, 06 Nov 2006 16:43:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCF6-00077j-Kz for l2vpn@ietf.org; Mon, 06 Nov 2006 16:42:56 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCCe-0006cy-Gb for l2vpn@ietf.org; Mon, 06 Nov 2006 16:40:26 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Nov 2006 22:40:24 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALs6T0WQ/uCLY2dsb2JhbACMQBQPKg X-IronPort-AV: i="4.09,392,1157320800"; d="scan'208"; a="117545683:sNHT27287328" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6LeNhC008036 for ; Mon, 6 Nov 2006 22:40:23 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA6LeN4Z021033 for ; Mon, 6 Nov 2006 22:40:23 +0100 (MET) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 22:40:23 +0100 Received: from [130.129.66.141] ([10.61.81.47]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 22:40:22 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <67FBA6A55FF15B46B8B572062529D26A059764@USDALSMBS03.ad3.ad.alcatel.com> References: <67FBA6A55FF15B46B8B572062529D26A059764@USDALSMBS03.ad3.ad.alcatel.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <60FB7D3D-5B9A-492B-B3CC-A2E3C495CE33@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Mon, 6 Nov 2006 13:40:21 -0800 To: l2vpn@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Nov 2006 21:40:23.0102 (UTC) FILETIME=[29F28DE0:01C701EC] DKIM-Signature: a=rsa-sha1; q=dns; l=1541; t=1162849223; x=1163713223; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:Open=20Issues=20on=3A=20draft-nadeau-l2vpn-vpls-mib; X=v=3Dcisco.com=3B=20h=3DXCQyOH8BzahqVdQb4AfMa1BrgK4=3D; b=dJ4snHzCPDkwkGwGBCRySRpTuLEaMGb5uWa+9oZ5h42mTGkzP2K2QYAjRvItrQwZArC0k8j3 8ntnLU/VmSf1Nrfis5VHnGQ5Iy12DkD6ESr4phIhDbIva54HjsEYL2Pf; Authentication-Results: ams-dkim-2; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: Open Issues on: draft-nadeau-l2vpn-vpls-mib 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 During the meeting I agreed to post these open issues to the list. Please send comments ASAP. If I do not hear comments by November 20 at 12PM GMT, I will *not* make these additions to the document. 1. Should the MIB modules be read-write or read-only? 2. Add number of attachment circuits per VSI. 3. Add PwBindTable (contains PWs bound to VSI) 4. Add VsiPerfTable (contains number of PWs in VSI, numberLearnedMac) 5. Define vplsOperStatus: current values are unknown, up or down. Propose adding a value 'partialMesh'. Definition of operStatus of VSI: 1 or more PW + 1 or more ACs up == OperStatusUp. 6. Proposed addition to vplsStatusTable to indicate the number of Mesh Peers in this VPLS instance. 7. vplsSpokePeerCount: proposed addition to vplsStatusTable to indicate the number of Spoke Peers in this VPLS instance. 8. The VPLS LDP Qualified Learning/Unqualified Learning mode on the VSI is current read-only. 9. Get IEEE 802.x objects we must look in the IEEE/IETF Bridge MIB. 10. vplsMacAging/Learning: these are currently mandatory requirements in the MIB even though they are not part of the standard itself. Remove them and Rely on IEEE/IETF Bridge MIB or put them in an optional group? 11. vplsACBindTable: proposed table to bind Attachment Circuits to a VPLS 12. Add watermarks for MaxMacAddrs vplsMacLearning, vplsDiscardUnknownDest, forwarding table size. 13. Add vplsPwConfigType that maintains configured auto-discovery method. From l2vpn-bounces@ietf.org Mon Nov 06 17:07:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCbg-00027m-JR; Mon, 06 Nov 2006 17:06:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCbf-00027g-PP for l2vpn@ietf.org; Mon, 06 Nov 2006 17:06:15 -0500 Received: from [143.209.238.164] (helo=audl751.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCbd-0002Sb-0Z for l2vpn@ietf.org; Mon, 06 Nov 2006 17:06:15 -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 kA6M683i022629; Mon, 6 Nov 2006 16:06:08 -0600 Received: from [128.251.10.84] ([172.22.216.4]) by usdalsbhs01.ad3.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Nov 2006 16:06:07 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) To: l2vpn@ietf.org, Vach Kompella , shane@castlepoint.net Message-Id: <9CA1168D-B586-4CF8-A044-380E1FC82AB6@alcatel.com> Content-Type: multipart/mixed; boundary=Apple-Mail-2--140037710 From: Andrew Lange Date: Mon, 6 Nov 2006 14:05:55 -0800 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Nov 2006 22:06:07.0973 (UTC) FILETIME=[C2C32950:01C701EF] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: Subject: L2VPN @ San Diego 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 --Apple-Mail-2--140037710 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello All, Attached are the minutes from today's meeting. Please provide any corrections. Thanks! Andrew --Apple-Mail-2--140037710 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name=l2-vpn-sandiego.txt Content-Disposition: attachment; filename=l2-vpn-sandiego.txt 2006-11-06 L2VPN WG Meeting Notes Document Status review by Shane. Goals: 1) VPLS MIB 2) OAM Work ** need OAM solutions drafts ** 3) Wrap up Multicast work - need to get mcast draft refreshed, other draft are progressing In Progress: Brief overview of in-progress drafts. draft-ietf-l2vpn-radius-pe-discovery (expired) -- some intrest in room for revising and renewing this draft. ------------------- Tom Nadeau, Editor of VPLS MIB ------------------- create a MIB for both BGP and LDP Approaches to LDP draft contains: 3 SNMP MIB mocules updated from -00 based on list comments @80% addressed in the current draft. Open Items: Should MIB module be RW or RO? - who would like the writeable? Add number of attachement ckts per VSI? Add PwBindTable (contains PWs bound to VSI? Add VsiPerfTable (contains number of PWs in VSI, numberLearnedMac)? Defined: vplsOperStatus: current values are unknown, up or down. Propose adding a value of 'partialMesh'. ...continuted on slides Most pressing issues: Some are already in the IETF Bridge MIB, although they do apply, they are configurable elsewhere, so Tom does not want to include them in this MIB. These are things like enabling MAC learning, max # of MAC addr's learnable, etc. (more details on slide) Some are status object that would be good to put in. If no comments are made on these in 1 week or so, they will be left out. Next Steps: need update based on resolutions of open issues just discussed. This will be the -03 revision of this draft. Publish as a L2 VPN WG. Dave McDyson - please post slides, so we can review and comment in detail in the next 2 weeks. Tom - Yes, will do. Shane - poll of room indicated not a lot of reviewers are present. Will defer decision to make it a WG draft until after next rev. ------------------- LDP Extensions for Optimized MAC Withdrawals ------------------- Marc Lassere H-VPLS MAC withdrawal is sub-optimal. Today most implementions tend to send a Null MAC withdrawal (main mode, perhaps make this the default?). the problem with a Null MAC withdrawal is some addresses that do not need to be flushed get flushed and have to be relearned. Add a LSR ID TLV to indicate where the fault occurs, this will speed converence since only fault-relevant MACs are flushed. Next Steps: Solicit comments on l2vpn list. Ali Sajassi - asked Marc to walk through the diagram. Marc - don't have diagram here. Ali - okay, let's take to list. Marc - MAC withdraw should be sent when backup link is active. Consensus - more on list. ------------------- Signalling Standby States of PW groups in H-VPLS ------------------- Marc Lassere Related to Praveen M's draft. H-VPLS dual homing - active/standby pw status managed by MTU-s. Traffic is blocked by MTU, or prim/sec PE's forward BUM traffic to their MTU's (fast failover). the issue is that if a PE is dual homed, unknown, bcast, mcast gets forwarded by both. If traffic is loadbalanced across VSI's, some links get used concurrently, and traffic is sent w/o need. Idea here is to propose (same as Praveen M's draft) - use a PW status with a new bit defined to indicate standy/active. Could apply in a H-VPLS dual homing, or ring topologies. Benefits - use of PW grouping for scalability. Optional mechanism (trade-off between b/w usage and failover). Covered in draft: signalling standby state via LDP (RFC4447). Detailed State Machine including a/s state transitions, and notification procedures. Next Steps: Draft-muley-pwe3-redundancy also has similar ideas -- Merge?? Solicit comments on L2VPN list. Luca - Why do you need a bit? You can do this with a forwarind bit without creating a new extension. I have an implementation which uses existing bits. Pranjal - If you look at applicaiton forwarding bits - if it is in standby, and there is a fault, you have overload of the bit. Luca - when you clear the fault, you do not have to send an all-clear you can clear that one fault and keep it in forwarding. Pranjal - Clarify the existance between FAULT state and STANDBY state. Luca - would like to make it more clear in the text. You can leave the forwarding bit in different states depending on the state. Pranjal - Clear distinction between FAULT state and STANDBY state. Luca - Why? Pranjal - Because they indicate separate states in the network, and to avoid bit overloading. Luca - message mapping draft - we need to define bit usages there to clarify the needs. Mustapha - What is the forwarding bit? What we want to say to the remote node is that this pw is fine, there is no fault, but I do not want you to foeward on this. We can run normal OAM (VCCV etc.) on this pw. But, when we read 4447 it was not clear that forwarding bit could be overloaded to that end. Marc - as currently stated, we need a new bit Luca - It was intended, at least in part, to be used for any faults, if we clarify in the message mapping draft then perhaps we can just use the existing bit. ------------------- MAC Hiding in a HVPLS Environment ------------------- Ian Cowburn Problem: PE-rs learns MAC addresses for customers on its direclty attached MTUs and the remote MAC addresses for all of its configured VPLS insances. So how do you have a very scalable solution. Solution: assign an MTU-id, in control word, including source and dest identifier, switch at PE-rs based on the destination MTU ID's Benefits: extends scalability of H-VPLS, minimized additional overhead per frame (4 bytes), using standard control word through this new use. Draft coverage: signalling MAC hiding capability via LDP, action at MTUs and PE-rs, handling bcast, unknown, mcast, MTU-id specific MAC withdraw, inter- provider use Diagram on slides to demonstrate what the mechanism is doing. Ali - comments on the number of bits used. Marc - although you're using 14-bits for src and dst MAC. MTU-id's can be processed as if they are fake MACs. The processing at the PE level appears as a MAC address. Second point: n-customers could be attached via an MTU or direclty via a PE, if we were to use MAC-in-MAC it may be difficult for some hardware to handle 2 ethernet headers and MPLS Ali - a couple of comments: 32 bits is for both src and dst, you get 16k limit with 14-bits. Total # of devices is limited to this. You could exceed this interprovider. Marc - actually this limit is PER-SP, not for the total space. Ali - The price is re-mapping at SP edges. The objective is not learning UPE MAC addresses at the PE -- instead use "distributed VPLS" and at the edge, translate the label at the edge using the same. Marc - I haven't seen deployments of D-VPLS Ali - it is in the draft. Marc - but it isn't deployed. Ali - Doesn't this do the same thing? Marc - SP's can manage this internal to themselves. Shane - take to list. Anonymous - This prevents the use of preferred control word to support pw fragmentation, that allows a single customer frame to be carried in separate packets, with this control word you cannot do this. How important is this? Don't know, but should be taken into account. Ian - this applies only to ethernet framing. Stewart - applies to path MTU. Anonymous - If there is a large MTU. Marc - yes, this depends on underling jumbo frame support. Stewart - should use existing control words. Looks a bit like "MAC nicknaming" which is something that is going on in trill. So we will want to coordinate with those folks. Next Steps: - solicit comments on the list. --Apple-Mail-2--140037710-- From l2vpn-bounces@ietf.org Mon Nov 06 18:47:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEAW-0006gj-Kk; Mon, 06 Nov 2006 18:46:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEAU-0006gX-Ny for l2vpn@ietf.org; Mon, 06 Nov 2006 18:46:18 -0500 Received: from mx100.qos.net.il ([80.74.96.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEAP-0007o7-6I for l2vpn@ietf.org; Mon, 06 Nov 2006 18:46:16 -0500 Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mx100.qos.net.il (Postfix) with ESMTP id C8AFB34E694 for ; Tue, 7 Nov 2006 01:46:26 +0200 (IST) 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_01C701FD.AEA5D72A" Date: Tue, 7 Nov 2006 01:44:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN @ San Diego Minutes Thread-Index: AccB8Ba+aRGIT+L7TxySus6jSy8xMAADXAyA References: <9CA1168D-B586-4CF8-A044-380E1FC82AB6@alcatel.com> From: "Sasha Vainshtein" To: "Andrew Lange" , , "Vach Kompella" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Subject: RE: L2VPN @ San Diego 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C701FD.AEA5D72A Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Andrew and all, I (Sasha Vainshtein) am the "anonymous" that made the comment about the = PW fragmentation. Regards, Sasha ________________________________ From: Andrew Lange [mailto:andrew.lange@alcatel.com] Sent: Mon 11/6/2006 10:05 To: l2vpn@ietf.org; Vach Kompella; shane@castlepoint.net Subject: L2VPN @ San Diego Minutes Hello All, Attached are the minutes from today's meeting. Please provide any=20 corrections. Thanks! Andrew ------_=_NextPart_001_01C701FD.AEA5D72A Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= L2VPN @ San Diego Minutes=0A= =0A= =0A=
=0A=
Andrew and = all,
=0A=
I (Sasha Vainshtein) am the = "anonymous" =0A= that made the comment about the PW fragmentation.
=0A=
Regards,
=0A=
          &nbs= p;      =0A= Sasha
=0A=

=0A=
=0A= From: Andrew Lange =0A= [mailto:andrew.lange@alcatel.com]
Sent: Mon 11/6/2006 =0A= 10:05
To: l2vpn@ietf.org; Vach Kompella; =0A= shane@castlepoint.net
Subject: L2VPN @ San Diego =0A= Minutes

=0A=
=0A=

Hello All,

Attached are the minutes from = today's =0A= meeting.  Please provide =0A= any 
corrections.

Thanks!

Andrew

=
=0A= =0A= =0A= ------_=_NextPart_001_01C701FD.AEA5D72A-- From l2vpn-bounces@ietf.org Mon Nov 06 18:59:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEMY-0006Th-KA; Mon, 06 Nov 2006 18:58:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEMX-0006Tc-S5 for l2vpn@ietf.org; Mon, 06 Nov 2006 18:58:45 -0500 Received: from [143.209.238.162] (helo=audl953.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEMT-0002P4-6p for l2vpn@ietf.org; Mon, 06 Nov 2006 18:58:45 -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 kA6NwC1U007872; Mon, 6 Nov 2006 17:58:12 -0600 Received: from [128.251.10.78] ([172.22.216.4]) by usdalsbhs01.ad3.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Nov 2006 17:58:11 -0600 In-Reply-To: References: <9CA1168D-B586-4CF8-A044-380E1FC82AB6@alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-4--133313499 Message-Id: <7450279D-8657-471D-9D8D-1724F46D6B6A@alcatel.com> From: Andrew Lange Date: Mon, 6 Nov 2006 15:58:00 -0800 To: "Sasha Vainshtein" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Nov 2006 23:58:11.0906 (UTC) FILETIME=[6A89EA20:01C701FF] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: l2vpn@ietf.org, shane@castlepoint.net, Vach Kompella Subject: Re: L2VPN @ San Diego 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 --Apple-Mail-4--133313499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Thank you, Sasha! Updated version attached. Andrew =EF=BF=BC On Nov 6, 2006, at 3:44 PM, Sasha Vainshtein wrote: > Andrew and all, > I (Sasha Vainshtein) am the "anonymous" that made the comment about =20= > the PW fragmentation. > Regards, > Sasha > > From: Andrew Lange [mailto:andrew.lange@alcatel.com] > Sent: Mon 11/6/2006 10:05 > To: l2vpn@ietf.org; Vach Kompella; shane@castlepoint.net > Subject: L2VPN @ San Diego Minutes > > Hello All, > > Attached are the minutes from today's meeting. Please provide any > corrections. > > Thanks! > > Andrew > > --Apple-Mail-4--133313499 Content-Type: multipart/mixed; boundary=Apple-Mail-5--133313498 --Apple-Mail-5--133313498 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII Thank you, Sasha!

Updated version attached.

Andrew

--Apple-Mail-5--133313498 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name=l2-vpn-sandiego.txt Content-Disposition: attachment; filename=l2-vpn-sandiego.txt 2006-11-06 L2VPN WG Meeting Notes Document Status review by Shane. Goals: 1) VPLS MIB 2) OAM Work ** need OAM solutions drafts ** 3) Wrap up Multicast work - need to get mcast draft refreshed, other draft are progressing In Progress: Brief overview of in-progress drafts. draft-ietf-l2vpn-radius-pe-discovery (expired) -- some intrest in room for revising and renewing this draft. ------------------- Tom Nadeau, Editor of VPLS MIB ------------------- create a MIB for both BGP and LDP Approaches to LDP draft contains: 3 SNMP MIB mocules updated from -00 based on list comments @80% addressed in the current draft. Open Items: Should MIB module be RW or RO? - who would like the writeable? Add number of attachement ckts per VSI? Add PwBindTable (contains PWs bound to VSI? Add VsiPerfTable (contains number of PWs in VSI, numberLearnedMac)? Defined: vplsOperStatus: current values are unknown, up or down. Propose adding a value of 'partialMesh'. ...continuted on slides Most pressing issues: Some are already in the IETF Bridge MIB, although they do apply, they are configurable elsewhere, so Tom does not want to include them in this MIB. These are things like enabling MAC learning, max # of MAC addr's learnable, etc. (more details on slide) Some are status object that would be good to put in. If no comments are made on these in 1 week or so, they will be left out. Next Steps: need update based on resolutions of open issues just discussed. This will be the -03 revision of this draft. Publish as a L2 VPN WG. Dave McDyson - please post slides, so we can review and comment in detail in the next 2 weeks. Tom - Yes, will do. Shane - poll of room indicated not a lot of reviewers are present. Will defer decision to make it a WG draft until after next rev. ------------------- LDP Extensions for Optimized MAC Withdrawals ------------------- Marc Lassere H-VPLS MAC withdrawal is sub-optimal. Today most implementions tend to send a Null MAC withdrawal (main mode, perhaps make this the default?). the problem with a Null MAC withdrawal is some addresses that do not need to be flushed get flushed and have to be relearned. Add a LSR ID TLV to indicate where the fault occurs, this will speed converence since only fault-relevant MACs are flushed. Next Steps: Solicit comments on l2vpn list. Ali Sajassi - asked Marc to walk through the diagram. Marc - don't have diagram here. Ali - okay, let's take to list. Marc - MAC withdraw should be sent when backup link is active. Consensus - more on list. ------------------- Signalling Standby States of PW groups in H-VPLS ------------------- Marc Lassere Related to Praveen M's draft. H-VPLS dual homing - active/standby pw status managed by MTU-s. Traffic is blocked by MTU, or prim/sec PE's forward BUM traffic to their MTU's (fast failover). the issue is that if a PE is dual homed, unknown, bcast, mcast gets forwarded by both. If traffic is loadbalanced across VSI's, some links get used concurrently, and traffic is sent w/o need. Idea here is to propose (same as Praveen M's draft) - use a PW status with a new bit defined to indicate standy/active. Could apply in a H-VPLS dual homing, or ring topologies. Benefits - use of PW grouping for scalability. Optional mechanism (trade-off between b/w usage and failover). Covered in draft: signalling standby state via LDP (RFC4447). Detailed State Machine including a/s state transitions, and notification procedures. Next Steps: Draft-muley-pwe3-redundancy also has similar ideas -- Merge?? Solicit comments on L2VPN list. Luca - Why do you need a bit? You can do this with a forwarind bit without creating a new extension. I have an implementation which uses existing bits. Pranjal - If you look at applicaiton forwarding bits - if it is in standby, and there is a fault, you have overload of the bit. Luca - when you clear the fault, you do not have to send an all-clear you can clear that one fault and keep it in forwarding. Pranjal - Clarify the existance between FAULT state and STANDBY state. Luca - would like to make it more clear in the text. You can leave the forwarding bit in different states depending on the state. Pranjal - Clear distinction between FAULT state and STANDBY state. Luca - Why? Pranjal - Because they indicate separate states in the network, and to avoid bit overloading. Luca - message mapping draft - we need to define bit usages there to clarify the needs. Mustapha - What is the forwarding bit? What we want to say to the remote node is that this pw is fine, there is no fault, but I do not want you to foeward on this. We can run normal OAM (VCCV etc.) on this pw. But, when we read 4447 it was not clear that forwarding bit could be overloaded to that end. Marc - as currently stated, we need a new bit Luca - It was intended, at least in part, to be used for any faults, if we clarify in the message mapping draft then perhaps we can just use the existing bit. ------------------- MAC Hiding in a HVPLS Environment ------------------- Ian Cowburn Problem: PE-rs learns MAC addresses for customers on its direclty attached MTUs and the remote MAC addresses for all of its configured VPLS insances. So how do you have a very scalable solution. Solution: assign an MTU-id, in control word, including source and dest identifier, switch at PE-rs based on the destination MTU ID's Benefits: extends scalability of H-VPLS, minimized additional overhead per frame (4 bytes), using standard control word through this new use. Draft coverage: signalling MAC hiding capability via LDP, action at MTUs and PE-rs, handling bcast, unknown, mcast, MTU-id specific MAC withdraw, inter- provider use Diagram on slides to demonstrate what the mechanism is doing. Ali - comments on the number of bits used. Marc - although you're using 14-bits for src and dst MAC. MTU-id's can be processed as if they are fake MACs. The processing at the PE level appears as a MAC address. Second point: n-customers could be attached via an MTU or direclty via a PE, if we were to use MAC-in-MAC it may be difficult for some hardware to handle 2 ethernet headers and MPLS Ali - a couple of comments: 32 bits is for both src and dst, you get 16k limit with 14-bits. Total # of devices is limited to this. You could exceed this interprovider. Marc - actually this limit is PER-SP, not for the total space. Ali - The price is re-mapping at SP edges. The objective is not learning UPE MAC addresses at the PE -- instead use "distributed VPLS" and at the edge, translate the label at the edge using the same. Marc - I haven't seen deployments of D-VPLS Ali - it is in the draft. Marc - but it isn't deployed. Ali - Doesn't this do the same thing? Marc - SP's can manage this internal to themselves. Shane - take to list. Sasha Vainshtein - This prevents the use of preferred control word to support pw fragmentation, that allows a single customer frame to be carried in separate packets, with this control word you cannot do this. How important is this? Don't know, but should be taken into account. Ian - this applies only to ethernet framing. Stewart - applies to path MTU. Sasha - If there is a large MTU. Marc - yes, this depends on underling jumbo frame support. Stewart - should use existing control words. Looks a bit like "MAC nicknaming" which is something that is going on in trill. So we will want to coordinate with those folks. Next Steps: - solicit comments on the list. --Apple-Mail-5--133313498 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
=
Andrew = and all,
I = (Sasha Vainshtein) am the "anonymous" that made the comment about the PW = fragmentation.
Regards,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Sasha

= From: Andrew Lange [mailto:andrew.lange@alcatel.com]
Sent: Mon 11/6/2006 10:05
To: l2vpn@ietf.org; Vach Kompella; shane@castlepoint.net
Subj= ect: L2VPN @ San Diego Minutes

Hello All,

Attached are the minutes from today's = meeting.=A0 Please provide = any=A0
corrections.

Thanks!

Andrew


= --Apple-Mail-5--133313498-- --Apple-Mail-4--133313499-- From l2vpn-bounces@ietf.org Mon Nov 06 19:45:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhF5C-0005af-2y; Mon, 06 Nov 2006 19:44:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhF5A-0005ZB-Jb for l2vpn@ietf.org; Mon, 06 Nov 2006 19:44:52 -0500 Received: from [143.209.238.161] (helo=audl951.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhF59-0004bP-9w for l2vpn@ietf.org; Mon, 06 Nov 2006 19:44:52 -0500 Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id kA70iVVP027137; Mon, 6 Nov 2006 18:44:31 -0600 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Nov 2006 18:44:31 -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_01C70205.E2DD82CC" Date: Mon, 6 Nov 2006 18:44:26 -0600 Message-ID: In-Reply-To: <7450279D-8657-471D-9D8D-1724F46D6B6A@alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2VPN @ San Diego Minutes Thread-Index: AccCA63xy7XICREjQSizdfkWc4y89QAAFrMA From: "AISSAOUI Mustapha" To: "LANGE Andrew" , "Sasha Vainshtein" X-OriginalArrivalTime: 07 Nov 2006 00:44:31.0317 (UTC) FILETIME=[E3326050:01C70205] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: l2vpn@ietf.org, shane@castlepoint.net, KOMPELLA Vach Subject: RE: L2VPN @ San Diego 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C70205.E2DD82CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andrew, one more comment. In the discussion of draft-pdutta-l2vpn-hvpls-standby-00.txt, Luca and I were talking about the "PW not forwarding" status bit. =20 Regards, Mustapha. ________________________________ From: Andrew Lange [mailto:andrew.lange@alcatel.com]=20 Sent: Monday, November 06, 2006 6:58 PM To: Sasha Vainshtein Cc: l2vpn@ietf.org; shane@castlepoint.net; KOMPELLA Vach Subject: Re: L2VPN @ San Diego Minutes =09 =09 Thank you, Sasha!=20 Updated version attached. =09 =09 Andrew =09 ------_=_NextPart_001_01C70205.E2DD82CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Andrew,
one more comment. In the discussion of=20 draft-pdutta-l2vpn-hvpls-standby-00.txt, Luca and I were talking about = the "PW=20 not forwarding" status bit.
 
Regards,
Mustapha.

From: Andrew Lange=20 [mailto:andrew.lange@alcatel.com]
Sent: Monday, November = 06, 2006=20 6:58 PM
To: Sasha Vainshtein
Cc: l2vpn@ietf.org;=20 shane@castlepoint.net; KOMPELLA Vach
Subject: Re: L2VPN @ = San Diego=20 Minutes

Thank you, Sasha!

Updated version attached.

Andrew

------_=_NextPart_001_01C70205.E2DD82CC-- From l2vpn-bounces@ietf.org Mon Nov 06 20:04:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFNj-0002k4-Ub; Mon, 06 Nov 2006 20:04:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFNh-0002dU-P3 for l2vpn@ietf.org; Mon, 06 Nov 2006 20:04:01 -0500 Received: from [143.209.238.159] (helo=audl952.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhFNg-0006sj-Ft for l2vpn@ietf.org; Mon, 06 Nov 2006 20:04:01 -0500 Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id kA713xBf020554; Mon, 6 Nov 2006 19:03:59 -0600 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Nov 2006 19:03:59 -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: Mon, 6 Nov 2006 19:03:57 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCCJpihXIn1VhZTJKWPR0/+EqVfg== From: "AISSAOUI Mustapha" To: "Martini Luca" X-OriginalArrivalTime: 07 Nov 2006 01:03:59.0606 (UTC) FILETIME=[9B8D2160:01C70208] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: l2vpn@ietf.org Subject: Active/Standby Status Bit 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 Luca, Here is the description of the "PW not forwarding" bit as per RFC 4447: "The presence of the lowest bit (PW Not Forwarding) acts only as a generic failure indication when there is a link-down event for which none of the other bits apply." So, we still need a bit to indicate a failure which is not explicilty indicated by the AC and PSN failure bits. A good example of using this bit is when an LSP switches its path and if the new path MTU does not match anymore that signaled in the PW FEC, this bit is used to signal the remote PE. There may be other types of failures which could use this bit. I can only conclude that we need a separate bit for the "Active/Standby" status. Mustapha.=20 From l2vpn-bounces@ietf.org Mon Nov 06 22:06:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHGz-0008Nh-G4; Mon, 06 Nov 2006 22:05:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHGx-0008NV-Rs for l2vpn@ietf.org; Mon, 06 Nov 2006 22:05:11 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHGw-0006TN-0I for l2vpn@ietf.org; Mon, 06 Nov 2006 22:05:11 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 06 Nov 2006 19:05:09 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="755077582:sNHT49081706" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA73598h000834; Mon, 6 Nov 2006 19:05:09 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA7359in020809; Mon, 6 Nov 2006 19:05:09 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:05:09 -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: Mon, 6 Nov 2006 19:05:07 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB025009F9@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCCJpihXIn1VhZTJKWPR0/+EqVfgADwMzQ From: "Ali Sajassi \(sajassi\)" To: "AISSAOUI Mustapha" , "Luca Martini \(lmartini\)" X-OriginalArrivalTime: 07 Nov 2006 03:05:09.0288 (UTC) FILETIME=[889E9280:01C70219] DKIM-Signature: a=rsa-sha1; q=dns; l=1485; t=1162868709; x=1163732709; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi@cisco.com; z=From:=22Ali=20Sajassi=20\(sajassi\)=22=20 |Subject:RE=3A=20Active/Standby=20Status=20Bit; X=v=3Dcisco.com=3B=20h=3D4JUurn61WXrUHHxElZSi9lRTDDU=3D; b=a7u4aVcvHX3gz6fnLn0qjucJrUsTqEF2+had6eWCOZZ47x62FhY3lpSLGaAGHfVyShi9M/T4 Db+qLOn3NDmwGcY1IMu2bVDHD8OQmdlgPyU9eae9xcTQlPCUFFmYvrqg; Authentication-Results: sj-dkim-4.cisco.com; header.From=sajassi@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit 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 =20 > -----Original Message----- > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com]=20 > Sent: Monday, November 06, 2006 5:04 PM > To: Luca Martini (lmartini) > Cc: l2vpn@ietf.org > Subject: Active/Standby Status Bit >=20 > Luca, > Here is the description of the "PW not forwarding" bit as per=20 > RFC 4447: >=20 > "The presence of the lowest bit (PW Not Forwarding) acts only=20 > as a generic failure indication when there is a link-down=20 > event for which none of the other bits apply." >=20 > So, we still need a bit to indicate a failure which is not=20 > explicilty indicated by the AC and PSN failure bits. A good=20 > example of using this bit is when an LSP switches its path=20 > and if the new path MTU does not match anymore that signaled=20 > in the PW FEC, this bit is used to signal the remote PE.=20 > There may be other types of failures which could use this bit. >=20 With respect to u-PE dual homing applications to two different n-PE devices, it is still not clear to me why we cannot use "PW forwarding" bit (since the MTU for the standby PW is already signaled between u-PE & standby n-PE). If the problem is its definition as defined in RFC 4447, then we can generalize its definition a bit more. However, if there is a more fundamental problem, then lets elaborate on what that is. -Ali > I can only conclude that we need a separate bit for the=20 > "Active/Standby" > status. >=20 > Mustapha.=20 >=20 From l2vpn-bounces@ietf.org Mon Nov 06 22:08:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHJk-0000gH-MN; Mon, 06 Nov 2006 22:08:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHJj-0000gB-QN for l2vpn@ietf.org; Mon, 06 Nov 2006 22:08:03 -0500 Received: from napoleon.monoski.com ([63.227.123.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHJi-0006tk-Ah for l2vpn@ietf.org; Mon, 06 Nov 2006 22:08:03 -0500 Received: from [130.129.65.93] (dhcp65-93.ietf67.org [130.129.65.93]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id kA737OWh020025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Nov 2006 20:07:26 -0700 (MST) Message-ID: <454FF82A.20703@cisco.com> Date: Mon, 06 Nov 2006 20:06:18 -0700 From: Luca Martini User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: AISSAOUI Mustapha References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0a1 (napoleon.monoski.com [63.227.123.227]); Mon, 06 Nov 2006 20:07:27 -0700 (MST) X-Scanned-By: MIMEDefang 2.57 on 63.227.123.227 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: l2vpn@ietf.org Subject: Re: Active/Standby Status Bit 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 Yes, I think that the question here is as follows: Does the status needs to have a different effect then "administratively down " on the remote AC ? If so , then what happens if there is an LDP session failure ? or label withdraw ? One case I think would require this bit , is SONET aps. In that case the remote PE should set the standby bit , as opposed to sending an AIS alarm. In this case , why can't we figure out what to do based on the received SONET K1,K2 bytes ? Any other cases ? If we need one, I would suggest having a separate very short document only on the definition and semantics of a new status bit without all the application text that we have seen in the multiple documents on this subject. Then those documents can more clearly reference the "standby status bit" document , and describe possible different schemes to achieve PW redundancy. Luca AISSAOUI Mustapha wrote: > Luca, > Here is the description of the "PW not forwarding" bit as per RFC 4447: > > "The presence of the lowest bit (PW Not Forwarding) acts only as a > generic failure indication when there is a link-down event for which > none of the other bits apply." > > So, we still need a bit to indicate a failure which is not explicilty > indicated by the AC and PSN failure bits. A good example of using this > bit is when an LSP switches its path and if the new path MTU does not > match anymore that signaled in the PW FEC, this bit is used to signal > the remote PE. There may be other types of failures which could use this > bit. > > I can only conclude that we need a separate bit for the "Active/Standby" > status. > > Mustapha. > > From l2vpn-bounces@ietf.org Tue Nov 07 11:57:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUF4-0003gI-TR; Tue, 07 Nov 2006 11:56:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUF3-0003bD-V0 for l2vpn@ietf.org; Tue, 07 Nov 2006 11:56:05 -0500 Received: from note-back.accton.com ([64.171.8.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhUEr-0002Yv-B7 for l2vpn@ietf.org; Tue, 07 Nov 2006 11:56:05 -0500 To: "Thomas D. Nadeau" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: anilr@accton.com Date: Tue, 7 Nov 2006 12:08:45 -0500 X-MIMETrack: Serialize by Router on note-back/AcctonUS(Release 5.0.8 |June 18, 2001) at 11/07/2006 08:56:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=big5 Content-transfer-encoding: base64 X-Spam-Score: 1.1 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: l2vpn@ietf.org Subject: Re: Open Issues on: draft-nadeau-l2vpn-vpls-mib 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 DQpIaSBUaG9tYXMsDQoNClBsZWFzZSBzZWUgbXkgY29tbWVudHMgb24gdGhlIGlzc3Vlcy4NCg0K DQoNCg0KPiAxLiBTaG91bGQgdGhlIE1JQiBtb2R1bGVzIGJlIHJlYWQtd3JpdGUgb3IgcmVhZC1v bmx5Pw0KDQogICAgIE1ha2luZyBhcHByb3ByaWF0ZSBvYmplY3RzIHJlYWQtd3JpdGUgaXMgdGhl IG5vcm1hbCBwcmFjdGljZTsgY29uY2VybnMNCmFib3V0IHNlY3VyaXR5IGNhbiBiZSBkZWFsdCB3 aXRoIGJ5IHVzZSBvZiBTTk1QdjMsIG9yIHBlcmhhcHMgaW4gc29tZQ0Kc2l0dWF0aW9ucyB3aXRo IGNvbW11bml0aWVzLiBBIHJlYWQtb25seSBNSUIgd29uJ3QgYmUgdmVyeSB1c2VmdWwuDQoNCj4g Mi4gQWRkIG51bWJlciBvZiBhdHRhY2htZW50IGNpcmN1aXRzIHBlciBWU0kuDQoNCiAgICAgQ291 bGQgZG8sIGFsdGhvdWdoIGl0J3MgdGhlIEFDIGJpbmRpbmcgdGFibGUgdGhhdCdzIHRoZSByZWFs DQpyZXF1aXJlbWVudCBoZXJlLiBQV0UzIE1JQiBkb2Vzbid0IHByb3ZpZGUgd2hhdCB3ZSBuZWVk IGZvciBWUExTLCBzaW5jZQ0KVlBMUyBjb25zaXN0cyBvZiBhIGJ1bmNoIG9mIFBXJ3MgYXMgd2Vs bCBhcyBidW5jaCBvZiBBQydzLiBQV0UzIGlzIGENCnBvaW50LXRvLXBvaW50IGNvbmZpZ3VyYXRp b24uDQoNCj4gMy4gQWRkIFB3QmluZFRhYmxlIChjb250YWlucyBQV3MgYm91bmQgdG8gVlNJKQ0K DQogICAgIERvbid0IHlvdSBhbHJlYWR5IGhhdmUgdnBsc1B3QmluZFRhYmxlIGluIHRoZXJlPz8N Cg0KPiA0LiBBZGQgVnNpUGVyZlRhYmxlIChjb250YWlucyBudW1iZXIgb2YgUFdzIGluIFZTSSwg bnVtYmVyTGVhcm5lZE1hYykNCg0KICAgICBTdXJlLCBjb3VsZCBiZSB1c2VmdWwuDQoNCj4gNS4g RGVmaW5lIHZwbHNPcGVyU3RhdHVzOiBjdXJyZW50IHZhbHVlcyBhcmUgdW5rbm93biwgdXAgb3Ig ZG93bi4NCj4gUHJvcG9zZSAgYWRkaW5nIGEgdmFsdWUgJ3BhcnRpYWxNZXNoJy4gRGVmaW5pdGlv biBvZiBvcGVyU3RhdHVzIG9mDQo+IFZTSTogMSBvciBtb3JlIFBXICsgMSBvciBtb3JlIEFDcyB1 cCA9PSBPcGVyU3RhdHVzVXAuDQoNCiAgICAgVGhpcyBpcyBhIHZlcnkgdXNlZnVsIHN0YXRlIHdo aWNoIGNhbiBiZSB1c2VkIGJ5IG1hbmFnZW1lbnQgdG8gdHJhY2sNCmRvd24gbmV0d29yayBpc3N1 ZXMuIEkgYmVsaWV2ZSB5b3Ugd2VyZSBhc2tpbmcgd2hldGhlciB0aGlzIG5lZWRzIGFuIE9BTSAt LQ0KYWxsIHRoYXQncyBuZWVkZWQgaGVyZSBpcyBmb3Igc29mdHdhcmUgdG8gZmlndXJlIG91dCB0 aGF0IHVuZGVybHlpbmcNClBXcy90dW5uZWxzIGFyZSBicm9rZW4sIGJhc2VkIG9uIGFscmVhZHkg ZXhpc3RpbmcgbWVjaGFuaXNtcy4gSXQncyBhIGJpdA0KbGlrZSBidWJibGluZyB1cCBpbnRlcmZh Y2Ugc3RhdHVzIHRvIGJyaWRnZSBvciByb3V0ZXIgcG9ydCBzdGF0ZXMuDQoNCj4gNi4gUHJvcG9z ZWQgYWRkaXRpb24gdG8gdnBsc1N0YXR1c1RhYmxlIHRvIGluZGljYXRlIHRoZSBudW1iZXIgb2YN Cj4gTWVzaCBQZWVycyBpbiB0aGlzIFZQTFMgaW5zdGFuY2UuDQoNCiAgICAgSnVzdCBhIHNpbXBs ZSBvYmplY3QgdG8gdGVsbCB1cyBob3cgYmlnIG91ciBWUExTIGlzLiBBIGJ1bmNoIG9mDQpnZXQt bmV4dHMgY291bGQgYWNjb21wbGlzaCB0aGUgc2FtZSB0aGluZyBpbiBhIG1vcmUgZGlmZmljdWx0 IG1hbm5lci4NCg0KPiA3LiB2cGxzU3Bva2VQZWVyQ291bnQ6IHByb3Bvc2VkIGFkZGl0aW9uIHRv IHZwbHNTdGF0dXNUYWJsZSB0bw0KPiBpbmRpY2F0ZSB0aGUgbnVtYmVyIG9mIFNwb2tlIFBlZXJz IGluIHRoaXMgVlBMUyBpbnN0YW5jZS4NCg0KICAgICBUaGlzIGlzIHVzZWZ1bCBzaW5jZSB3ZSBk b24ndCBoYXZlIG11Y2ggbWFuYWdlbWVudCBob29rcyBhYm91dCB0aGUNCnNwb2tlcy4gU29tZSBv ZiB3aGljaCBtYXkgYmUgUWluUS4NCg0KPiA4LiBUaGUgVlBMUyBMRFAgUXVhbGlmaWVkIExlYXJu aW5nL1VucXVhbGlmaWVkIExlYXJuaW5nIG1vZGUgb24gdGhlDQo+IFZTSSBpcyBjdXJyZW50IHJl YWQtb25seS4NCg0KICAgICBDdXJyZW50bHksIHRoZXJlIGlzIG5vIHF1YWxpZmllZC91bnF1YWxp ZmllZCBsZWFybmluZyBtb2RlIGluIHRoZSBNSUIsDQpmYXIgYXMgSSBjYW4gc2VlLiBJdHMgYWRk aXRpb24sIGV2ZW4gaWYgcmVhZC1vbmx5LCB3b3VsZCBiZSB1c2VmdWwuDQoNCj4gOS4gR2V0IElF RUUgODAyLnggb2JqZWN0cyB3ZSBtdXN0IGxvb2sgaW4gdGhlIElFRUUvSUVURiBCcmlkZ2UgTUlC Lg0KDQogICAgIDgwMi54PyBJIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBpc3N1ZS4gQXMgdGhlIG1h aW4gYXV0aG9yIG9mIHRoZSBCcmlkZ2UNCk1JQiwgSSdkIGJlIGFibGUgdG8gaGVscCBtYXAgb2Jq ZWN0cyBpbiB0aGVyZSB3aXRoIHRoaXMgTUlCIGlmIHBlb3BsZSBmZWVsDQp0aGF0J3MgYSB1c2Vm dWwgZXhlcmNpc2UuIFlvdSBwcm9iYWJseSBhbHNvIG5lZWQgYSAicmVsYXRpb25zaGlwIiBzZWN0 aW9uDQp1cCBmcm9udCB0byBpbmRpY2F0ZSB3aGljaCBwb3J0aW9ucyBvZiB0aGUgQnJpZGdlIE1J QiB3b3VsZCBiZSBleHBlY3RlZCBvbg0KYSBwc2V1ZG93aXJlL1ZQTFMgbG9naWNhbCBwb3J0IGJh c2lzLg0KDQo+IDEwLiB2cGxzTWFjQWdpbmcvTGVhcm5pbmc6IHRoZXNlICBhcmUgY3VycmVudGx5 IG1hbmRhdG9yeQ0KPiByZXF1aXJlbWVudHMgaW4gdGhlIE1JQiBldmVuIHRob3VnaCB0aGV5IGFy ZSBub3QgcGFydCBvZiB0aGUgc3RhbmRhcmQNCj4gaXRzZWxmLiBSZW1vdmUgdGhlbSBhbmQgUmVs eSBvbiBJRUVFL0lFVEYgQnJpZGdlIE1JQiBvciBwdXQgdGhlbSBpbg0KPiBhbiBvcHRpb25hbCBn cm91cD8NCg0KICAgICBDbGVhcmx5LCBJIHRoaW5rIGl0J3MgYmVzdCB0byBsZWF2ZSB0aGVzZSBv cHRpb25hbC4NCg0KPiAxMS4gdnBsc0FDQmluZFRhYmxlOiBwcm9wb3NlZCB0YWJsZSB0byBiaW5k IEF0dGFjaG1lbnQgQ2lyY3VpdHMgdG8gIGENCj4gVlBMUw0KDQogICAgIE5lZWRlZCBJIGJlbGll dmUsIGFzIG1lbnRpb25lZCBhYm92ZS4gVGhlcmUncyBubyBvdGhlciB3YXkgdG8NCmNvbmZpZ3Vy ZSBsb2NhbCBwb3J0cyBpbnRvIHRoZSB2aXJ0dWFsIGJyaWRnZSBjb21wcmlzaW5nIGEgVlBMUyBp bnN0YW5jZS4NCg0KUmVnYXJkcywNCkFuaWwNCg0K From l2vpn-bounces@ietf.org Tue Nov 07 13:35:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVmZ-00006j-In; Tue, 07 Nov 2006 13:34:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVmY-00006c-7C for l2vpn@ietf.org; Tue, 07 Nov 2006 13:34:46 -0500 Received: from [143.209.238.162] (helo=audl953.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVmV-0003SA-TW for l2vpn@ietf.org; Tue, 07 Nov 2006 13:34:46 -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 kA7IYgKB000863; Tue, 7 Nov 2006 12:34:42 -0600 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 7 Nov 2006 12:34:42 -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: Tue, 7 Nov 2006 12:34:41 -0600 Message-ID: In-Reply-To: <454FF82A.20703@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCIdnYnt7jqHMsQNWHPCzSSoKtgAAeFZnw From: "DOLGANOW Andrew" To: "Luca Martini" , "AISSAOUI Mustapha" , "Marc Lasserre" X-OriginalArrivalTime: 07 Nov 2006 18:34:42.0577 (UTC) FILETIME=[64171810:01C7029B] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit 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 All, After further discussions with Luca it seems that the best way forward seems to be a short draft that defines the new bit.=20 In a nutshell, we want an indication that a given pseudowire is established and has no failure that would prevent traffic forwarding once the PW is elected to become operationally up. The "standby" pseudowire must not result in any alarm/OAM indications towards ACs. The case to handle as wells is what to do when one end receives the "standby" indication but does not support the active/standby bit. Andrew=20 > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com]=20 > Sent: Monday, November 06, 2006 10:06 PM > To: AISSAOUI Mustapha > Cc: l2vpn@ietf.org > Subject: Re: Active/Standby Status Bit >=20 > Yes, > I think that the question here is as follows: > Does the status needs to have a different effect then=20 > "administratively down " on the remote AC ? > If so , then what happens if there is an LDP session failure=20 > ? or label withdraw ? >=20 > One case I think would require this bit , is SONET aps. In=20 > that case the remote PE should set the standby bit , as=20 > opposed to sending an AIS alarm. In this case , why can't we=20 > figure out what to do based on the received SONET K1,K2 bytes ? >=20 > Any other cases ? >=20 > If we need one, I would suggest having a separate very short=20 > document only on the definition and semantics of a new status=20 > bit without all the application text that we have seen in the=20 > multiple documents on this subject. >=20 > Then those documents can more clearly reference the "standby=20 > status bit" > document , and describe possible different schemes to achieve=20 > PW redundancy. >=20 > Luca >=20 > AISSAOUI Mustapha wrote: > > Luca, > > Here is the description of the "PW not forwarding" bit as=20 > per RFC 4447: > > > > "The presence of the lowest bit (PW Not Forwarding) acts only as a=20 > > generic failure indication when there is a link-down event=20 > for which=20 > > none of the other bits apply." > > > > So, we still need a bit to indicate a failure which is not=20 > explicilty=20 > > indicated by the AC and PSN failure bits. A good example of=20 > using this=20 > > bit is when an LSP switches its path and if the new path=20 > MTU does not=20 > > match anymore that signaled in the PW FEC, this bit is used=20 > to signal=20 > > the remote PE. There may be other types of failures which could use=20 > > this bit. > > > > I can only conclude that we need a separate bit for the=20 > "Active/Standby" > > status. > > > > Mustapha.=20 > > > > =20 >=20 >=20 >=20 From l2vpn-bounces@ietf.org Tue Nov 07 13:45:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVwV-0000es-B6; Tue, 07 Nov 2006 13:45:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVwU-0000ee-6h for l2vpn@ietf.org; Tue, 07 Nov 2006 13:45:02 -0500 Received: from mx100.qos.net.il ([80.74.96.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVwR-0005Oz-Qf for l2vpn@ietf.org; Tue, 07 Nov 2006 13:45:02 -0500 Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mx100.qos.net.il (Postfix) with ESMTP id 2388A14EF45 for ; Tue, 7 Nov 2006 20:36:07 +0200 (IST) 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_01C7029C.D0ABF012" Date: Tue, 7 Nov 2006 20:42:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCIdnYnt7jqHMsQNWHPCzSSoKtgAAeFZnwAACV/60= References: From: "Sasha Vainshtein" To: "DOLGANOW Andrew" , "Luca Martini" , "AISSAOUI Mustapha" , "Marc Lasserre" X-Spam-Score: 0.1 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: l2vpn@ietf.org, danny@tcb.net, stbryant@cisco.com Subject: RE: Active/Standby Status Bit 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_01C7029C.D0ABF012 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, IMHO such a draft (once prepared) should be handled by the PWE3 WG. Did = I miss something =20 Regards, Sasha ________________________________ From: DOLGANOW Andrew [mailto:Andrew.Dolganow@alcatel.com] Sent: Tue 11/7/2006 06:34 To: Luca Martini; AISSAOUI Mustapha; Marc Lasserre Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit All, After further discussions with Luca it seems that the best way forward seems to be a short draft that defines the new bit. In a nutshell, we want an indication that a given pseudowire is established and has no failure that would prevent traffic forwarding once the PW is elected to become operationally up. The "standby" pseudowire must not result in any alarm/OAM indications towards ACs. The case to handle as wells is what to do when one end receives the "standby" indication but does not support the active/standby bit. Andrew > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Monday, November 06, 2006 10:06 PM > To: AISSAOUI Mustapha > Cc: l2vpn@ietf.org > Subject: Re: Active/Standby Status Bit > > Yes, > I think that the question here is as follows: > Does the status needs to have a different effect then > "administratively down " on the remote AC ? > If so , then what happens if there is an LDP session failure > ? or label withdraw ? > > One case I think would require this bit , is SONET aps. In > that case the remote PE should set the standby bit , as > opposed to sending an AIS alarm. In this case , why can't we > figure out what to do based on the received SONET K1,K2 bytes ? > > Any other cases ? > > If we need one, I would suggest having a separate very short > document only on the definition and semantics of a new status > bit without all the application text that we have seen in the > multiple documents on this subject. > > Then those documents can more clearly reference the "standby > status bit" > document , and describe possible different schemes to achieve > PW redundancy. > > Luca > > AISSAOUI Mustapha wrote: > > Luca, > > Here is the description of the "PW not forwarding" bit as > per RFC 4447: > > > > "The presence of the lowest bit (PW Not Forwarding) acts only as a > > generic failure indication when there is a link-down event > for which > > none of the other bits apply." > > > > So, we still need a bit to indicate a failure which is not > explicilty > > indicated by the AC and PSN failure bits. A good example of > using this > > bit is when an LSP switches its path and if the new path > MTU does not > > match anymore that signaled in the PW FEC, this bit is used > to signal > > the remote PE. There may be other types of failures which could use > > this bit. > > > > I can only conclude that we need a separate bit for the > "Active/Standby" > > status. > > > > Mustapha. > > > > =20 > > > ------_=_NextPart_001_01C7029C.D0ABF012 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: Active/Standby Status Bit=0A= =0A= =0A=
=0A=
Hi = all,
=0A=
IMHO such a draft (once = prepared) should be =0A= handled by the PWE3 WG. Did I miss something
=0A=
 
=0A=
Regards,
=0A=
          &nbs= p;            =0A= Sasha
=0A=

=0A=
=0A= From: DOLGANOW Andrew =0A= [mailto:Andrew.Dolganow@alcatel.com]
Sent: Tue 11/7/2006 =0A= 06:34
To: Luca Martini; AISSAOUI Mustapha; Marc = Lasserre
Cc: =0A= l2vpn@ietf.org
Subject: RE: Active/Standby Status =0A= Bit

=0A=
=0A=

All,

After further discussions with Luca it = seems that =0A= the best way forward
seems to be a short draft that defines the new =0A= bit.

In a nutshell, we want an indication that a given pseudowire =0A= is
established and has no failure that would prevent traffic =0A= forwarding
once the PW is elected to become operationally up. The =0A= "standby"
pseudowire must not result in any alarm/OAM indications = towards =0A= ACs. The
case to handle as wells is what to do when one end receives =0A= the
"standby" indication but does not support the active/standby =0A= bit.

Andrew

> -----Original Message-----
> From: = Luca =0A= Martini [mailto:lmartini@cisco.com]
>= Sent: =0A= Monday, November 06, 2006 10:06 PM
> To: AISSAOUI Mustapha
> = Cc: =0A= l2vpn@ietf.org
> Subject: Re: Active/Standby Status = Bit
>
> =0A= Yes,
> I think that the question  here is as follows:
> = Does =0A= the status needs to have a different effect then
> = "administratively down =0A= " on the remote AC ?
> If so , then what happens if there is an = LDP =0A= session failure
> ? or label withdraw ?
>
> One case I = think =0A= would require this bit , is SONET aps. In
> that case the remote = PE should =0A= set the standby bit , as
> opposed to sending an AIS alarm.  = In this =0A= case , why can't we
> figure out what to do based on the received = SONET =0A= K1,K2 bytes ?
>
> Any other cases ?
>
> If we = need one, =0A= I would suggest having a separate very short
> document only on = the =0A= definition and semantics of a new status
> bit without all the = application =0A= text that we have seen in the
> multiple documents on this =0A= subject.
>
> Then those documents can more clearly reference = the =0A= "standby
> status bit"
> document , and describe possible = different =0A= schemes to achieve
> PW redundancy.
>
> = Luca
>
> =0A= AISSAOUI Mustapha wrote:
> > Luca,
> > Here is the = description =0A= of the "PW not forwarding" bit as
> per RFC 4447:
> = >
> =0A= > "The presence of the lowest bit (PW Not Forwarding) acts only as = a
> =0A= > generic failure indication when there is a link-down event
> = for =0A= which
> > none of the other bits apply."
> >
> = > So, =0A= we still need a bit to indicate a failure which is not
> =0A= explicilty
> > indicated by the AC and PSN failure bits. A good = example =0A= of
> using this
> > bit is when an LSP switches its path = and if =0A= the new path
> MTU does not
> > match anymore that = signaled in =0A= the PW FEC, this bit is used
> to signal
> > the remote = PE. There =0A= may be other types of failures which could use
> > this = bit.
> =0A= >
> > I can only conclude that we need a separate bit for =0A= the
> "Active/Standby"
> > status.
> >
> = > =0A= Mustapha.
> >
> =0A= >  
>
>
>

=0A= =0A= =0A= ------_=_NextPart_001_01C7029C.D0ABF012-- From l2vpn-bounces@ietf.org Tue Nov 07 13:49:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW0R-0002C3-3u; Tue, 07 Nov 2006 13:49:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW0P-0002Bk-LJ for l2vpn@ietf.org; Tue, 07 Nov 2006 13:49:05 -0500 Received: from [143.209.238.162] (helo=audl953.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhW0O-00061x-4o for l2vpn@ietf.org; Tue, 07 Nov 2006 13:49:05 -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 kA7ImbCc010407; Tue, 7 Nov 2006 12:48:37 -0600 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 7 Nov 2006 12:48:37 -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_01C7029D.556E3B68" Date: Tue, 7 Nov 2006 12:48:36 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCIdnYnt7jqHMsQNWHPCzSSoKtgAAeFZnwAACV/60AAC0nwA== From: "DOLGANOW Andrew" To: "Sasha Vainshtein" , "Luca Martini" , "AISSAOUI Mustapha" , "Marc Lasserre" X-OriginalArrivalTime: 07 Nov 2006 18:48:37.0358 (UTC) FILETIME=[55A890E0:01C7029D] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.1 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: l2vpn@ietf.org, danny@tcb.net, stbryant@cisco.com Subject: RE: Active/Standby Status Bit 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_01C7029D.556E3B68 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree.=20 =20 Andrew ________________________________ From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]=20 Sent: Tuesday, November 07, 2006 1:43 PM To: DOLGANOW Andrew; Luca Martini; AISSAOUI Mustapha; Marc Lasserre Cc: l2vpn@ietf.org; stbryant@cisco.com; danny@tcb.net Subject: RE: Active/Standby Status Bit =09 =09 Hi all, IMHO such a draft (once prepared) should be handled by the PWE3 WG. Did I miss something =20 Regards, Sasha ________________________________ From: DOLGANOW Andrew [mailto:Andrew.Dolganow@alcatel.com] Sent: Tue 11/7/2006 06:34 To: Luca Martini; AISSAOUI Mustapha; Marc Lasserre Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit =09 =09 All, =09 After further discussions with Luca it seems that the best way forward seems to be a short draft that defines the new bit. =09 In a nutshell, we want an indication that a given pseudowire is established and has no failure that would prevent traffic forwarding once the PW is elected to become operationally up. The "standby" pseudowire must not result in any alarm/OAM indications towards ACs. The case to handle as wells is what to do when one end receives the "standby" indication but does not support the active/standby bit. =09 Andrew =09 > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Monday, November 06, 2006 10:06 PM > To: AISSAOUI Mustapha > Cc: l2vpn@ietf.org > Subject: Re: Active/Standby Status Bit > > Yes, > I think that the question here is as follows: > Does the status needs to have a different effect then > "administratively down " on the remote AC ? > If so , then what happens if there is an LDP session failure > ? or label withdraw ? > > One case I think would require this bit , is SONET aps. In > that case the remote PE should set the standby bit , as > opposed to sending an AIS alarm. In this case , why can't we > figure out what to do based on the received SONET K1,K2 bytes ? > > Any other cases ? > > If we need one, I would suggest having a separate very short > document only on the definition and semantics of a new status > bit without all the application text that we have seen in the > multiple documents on this subject. > > Then those documents can more clearly reference the "standby > status bit" > document , and describe possible different schemes to achieve > PW redundancy. > > Luca > > AISSAOUI Mustapha wrote: > > Luca, > > Here is the description of the "PW not forwarding" bit as > per RFC 4447: > > > > "The presence of the lowest bit (PW Not Forwarding) acts only as a > > generic failure indication when there is a link-down event > for which > > none of the other bits apply." > > > > So, we still need a bit to indicate a failure which is not > explicilty > > indicated by the AC and PSN failure bits. A good example of > using this > > bit is when an LSP switches its path and if the new path > MTU does not > > match anymore that signaled in the PW FEC, this bit is used > to signal > > the remote PE. There may be other types of failures which could use > > this bit. > > > > I can only conclude that we need a separate bit for the > "Active/Standby" > > status. > > > > Mustapha. > > > > =20 > > > =09 =09 ------_=_NextPart_001_01C7029D.556E3B68 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Active/Standby Status Bit
I agree. 
 
Andrew

From: Sasha Vainshtein=20 [mailto:Sasha@AXERRA.com]
Sent: Tuesday, November 07, 2006 = 1:43=20 PM
To: DOLGANOW Andrew; Luca Martini; AISSAOUI Mustapha; = Marc=20 Lasserre
Cc: l2vpn@ietf.org; stbryant@cisco.com;=20 danny@tcb.net
Subject: RE: Active/Standby Status=20 Bit

Hi = all,
IMHO such a draft (once = prepared) should=20 be handled by the PWE3 WG. Did I miss something
 
Regards,
          &nbs= p;           =20 Sasha

From: DOLGANOW Andrew=20 [mailto:Andrew.Dolganow@alcatel.com]
Sent: Tue 11/7/2006=20 06:34
To: Luca Martini; AISSAOUI Mustapha; Marc=20 Lasserre
Cc: l2vpn@ietf.org
Subject: RE: = Active/Standby=20 Status Bit

All,

After further discussions with Luca it = seems that=20 the best way forward
seems to be a short draft that defines the new = bit.

In a nutshell, we want an indication that a given = pseudowire=20 is
established and has no failure that would prevent traffic=20 forwarding
once the PW is elected to become operationally up. The=20 "standby"
pseudowire must not result in any alarm/OAM indications = towards=20 ACs. The
case to handle as wells is what to do when one end = receives=20 the
"standby" indication but does not support the active/standby=20 bit.

Andrew

> -----Original Message-----
> = From: Luca=20 Martini [mailto:lmartini@cisco.com]
>= Sent:=20 Monday, November 06, 2006 10:06 PM
> To: AISSAOUI = Mustapha
> Cc:=20 l2vpn@ietf.org
> Subject: Re: Active/Standby Status = Bit
>
>=20 Yes,
> I think that the question  here is as = follows:
> Does=20 the status needs to have a different effect then
> = "administratively=20 down " on the remote AC ?
> If so , then what happens if there = is an LDP=20 session failure
> ? or label withdraw ?
>
> One case = I think=20 would require this bit , is SONET aps. In
> that case the remote = PE=20 should set the standby bit , as
> opposed to sending an AIS = alarm. =20 In this case , why can't we
> figure out what to do based on the = received SONET K1,K2 bytes ?
>
> Any other cases = ?
>
>=20 If we need one, I would suggest having a separate very short
> = document=20 only on the definition and semantics of a new status
> bit = without all=20 the application text that we have seen in the
> multiple = documents on=20 this subject.
>
> Then those documents can more clearly = reference=20 the "standby
> status bit"
> document , and describe = possible=20 different schemes to achieve
> PW redundancy.
>
>=20 Luca
>
> AISSAOUI Mustapha wrote:
> > = Luca,
> >=20 Here is the description of the "PW not forwarding" bit as
> per = RFC=20 4447:
> >
> > "The presence of the lowest bit (PW = Not=20 Forwarding) acts only as a
> > generic failure indication = when there=20 is a link-down event
> for which
> > none of the other = bits=20 apply."
> >
> > So, we still need a bit to indicate = a=20 failure which is not
> explicilty
> > indicated by the = AC and=20 PSN failure bits. A good example of
> using this
> > = bit is=20 when an LSP switches its path and if the new path
> MTU does = not
>=20 > match anymore that signaled in the PW FEC, this bit is = used
> to=20 signal
> > the remote PE. There may be other types of = failures which=20 could use
> > this bit.
> >
> > I can only = conclude=20 that we need a separate bit for the
> "Active/Standby"
> = >=20 status.
> >
> > Mustapha.
> >
>=20 = >  
>
>
>

------_=_NextPart_001_01C7029D.556E3B68-- From l2vpn-bounces@ietf.org Tue Nov 07 13:58:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW8G-00052S-UM; Tue, 07 Nov 2006 13:57:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW8F-00052L-JL for l2vpn@ietf.org; Tue, 07 Nov 2006 13:57:11 -0500 Received: from [143.209.238.161] (helo=audl951.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhW8D-0006zX-9X for l2vpn@ietf.org; Tue, 07 Nov 2006 13:57:11 -0500 Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id kA7Iv5Xe008201; Tue, 7 Nov 2006 12:57:05 -0600 Received: from USDALSMBS01.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 7 Nov 2006 12:57:05 -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: Tue, 7 Nov 2006 12:57:04 -0600 Message-ID: In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB025009F9@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCCJpihXIn1VhZTJKWPR0/+EqVfgADwMzQACFIbDA= From: "AISSAOUI Mustapha" To: "Ali Sajassi \(sajassi\)" X-OriginalArrivalTime: 07 Nov 2006 18:57:05.0239 (UTC) FILETIME=[84610E70:01C7029E] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit 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, See below. Mustapha.=20 > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]=20 > Sent: Monday, November 06, 2006 10:05 PM > To: AISSAOUI Mustapha; Luca Martini (lmartini) > Cc: l2vpn@ietf.org > Subject: RE: Active/Standby Status Bit >=20 > =20 >=20 > > -----Original Message----- > > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com] > > Sent: Monday, November 06, 2006 5:04 PM > > To: Luca Martini (lmartini) > > Cc: l2vpn@ietf.org > > Subject: Active/Standby Status Bit > >=20 > > Luca, > > Here is the description of the "PW not forwarding" bit as per RFC=20 > > 4447: > >=20 > > "The presence of the lowest bit (PW Not Forwarding) acts only as a=20 > > generic failure indication when there is a link-down event=20 > for which=20 > > none of the other bits apply." > >=20 > > So, we still need a bit to indicate a failure which is not=20 > explicilty=20 > > indicated by the AC and PSN failure bits. A good example of=20 > using this=20 > > bit is when an LSP switches its path and if the new path=20 > MTU does not=20 > > match anymore that signaled in the PW FEC, this bit is used=20 > to signal=20 > > the remote PE. > > There may be other types of failures which could use this bit. > >=20 > With respect to u-PE dual homing applications to two=20 > different n-PE devices, it is still not clear to me why we=20 > cannot use "PW forwarding" > bit (since the MTU for the standby PW is already signaled=20 > between u-PE & standby n-PE). If the problem is its=20 > definition as defined in RFC 4447, then we can generalize its=20 > definition a bit more. However, if there is a more=20 > fundamental problem, then lets elaborate on what that is. MA> The MTU for tunnel LSP can change if the LSP path for the primay PW or the secondary PW changes. If the new MTU value is lower than the one signaled in the PW FEC iterface parameter field, an alarm should be raised since the PE will drop packets on that PW. So, this is a fault condition which we currently signal using the "PW not forwarding bit". When the PW is in standby state, there is no fault or alarms which are generated. It just an indication to the remote PE to preferably not send traffic over that PW.=20 > -Ali >=20 > > I can only conclude that we need a separate bit for the=20 > > "Active/Standby" > > status. > >=20 > > Mustapha.=20 > >=20 >=20 From l2vpn-bounces@ietf.org Tue Nov 07 14:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWOP-0002sL-FA; Tue, 07 Nov 2006 14:13:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWON-0002qr-EY for l2vpn@ietf.org; Tue, 07 Nov 2006 14:13:51 -0500 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWOK-0000Q3-TN for l2vpn@ietf.org; Tue, 07 Nov 2006 14:13:51 -0500 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA09153; Tue, 7 Nov 2006 11:12:36 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C702A0.AF17E09B" Date: Wed, 8 Nov 2006 00:42:35 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCIdnYnt7jqHMsQNWHPCzSSoKtgAAeFZnwAAFZDfY= References: From: "Dutta, Pranjal" To: "DOLGANOW Andrew" , "Luca Martini" , "AISSAOUI Mustapha" , "Lasserre, Marc" X-Spam-Score: 0.1 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit 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_01C702A0.AF17E09B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Andrew, We have addressed the backward compatibility = issue with PW standby bit in "Section 7. PW state machine" in the draft. = As per current proposal we don't do anything when standby bit is not = understood by the receiver. We made that way as it solves the purpose in = H-VPLS application (PE-rs doesn't block the PW groups to MTU-s if = standby bit not understood). =20 Thanks, Pranjal=20 =20 ________________________________ From: DOLGANOW Andrew [mailto:Andrew.Dolganow@alcatel.com] Sent: Wed 11/8/2006 12:04 AM To: Luca Martini; AISSAOUI Mustapha; Lasserre, Marc Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit All, After further discussions with Luca it seems that the best way forward seems to be a short draft that defines the new bit. In a nutshell, we want an indication that a given pseudowire is established and has no failure that would prevent traffic forwarding once the PW is elected to become operationally up. The "standby" pseudowire must not result in any alarm/OAM indications towards ACs. The case to handle as wells is what to do when one end receives the "standby" indication but does not support the active/standby bit. Andrew > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Monday, November 06, 2006 10:06 PM > To: AISSAOUI Mustapha > Cc: l2vpn@ietf.org > Subject: Re: Active/Standby Status Bit > > Yes, > I think that the question here is as follows: > Does the status needs to have a different effect then > "administratively down " on the remote AC ? > If so , then what happens if there is an LDP session failure > ? or label withdraw ? > > One case I think would require this bit , is SONET aps. In > that case the remote PE should set the standby bit , as > opposed to sending an AIS alarm. In this case , why can't we > figure out what to do based on the received SONET K1,K2 bytes ? > > Any other cases ? > > If we need one, I would suggest having a separate very short > document only on the definition and semantics of a new status > bit without all the application text that we have seen in the > multiple documents on this subject. > > Then those documents can more clearly reference the "standby > status bit" > document , and describe possible different schemes to achieve > PW redundancy. > > Luca > > AISSAOUI Mustapha wrote: > > Luca, > > Here is the description of the "PW not forwarding" bit as > per RFC 4447: > > > > "The presence of the lowest bit (PW Not Forwarding) acts only as a > > generic failure indication when there is a link-down event > for which > > none of the other bits apply." > > > > So, we still need a bit to indicate a failure which is not > explicilty > > indicated by the AC and PSN failure bits. A good example of > using this > > bit is when an LSP switches its path and if the new path > MTU does not > > match anymore that signaled in the PW FEC, this bit is used > to signal > > the remote PE. There may be other types of failures which could use > > this bit. > > > > I can only conclude that we need a separate bit for the > "Active/Standby" > > status. > > > > Mustapha. > > > > =20 > > > ------_=_NextPart_001_01C702A0.AF17E09B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: Active/Standby Status Bit=0A= =0A= =0A=
=0A=
Hi = Andrew,
=0A=
          &nbs= p;            = ;   We =0A= have addressed the backward compatibility issue with PW standby bit in = "Section =0A= 7. PW state machine" in the draft. As = per current =0A= proposal we don't do anything when standby bit is not understood by the =0A= receiver. We made that way as it solves the purpose in H-VPLS = application =0A= (PE-rs doesn't block the PW groups to MTU-s if standby bit not =0A= understood).
=0A=
 
=0A=
Thanks,
=0A=
Pranjal 
=0A=
 
=0A=

=0A=
=0A= From: DOLGANOW Andrew =0A= [mailto:Andrew.Dolganow@alcatel.com]
Sent: Wed 11/8/2006 12:04 =0A= AM
To: Luca Martini; AISSAOUI Mustapha; Lasserre, = Marc
Cc: =0A= l2vpn@ietf.org
Subject: RE: Active/Standby Status =0A= Bit

=0A=
=0A=

All,

After further discussions with Luca it = seems that =0A= the best way forward
seems to be a short draft that defines the new =0A= bit.

In a nutshell, we want an indication that a given pseudowire =0A= is
established and has no failure that would prevent traffic =0A= forwarding
once the PW is elected to become operationally up. The =0A= "standby"
pseudowire must not result in any alarm/OAM indications = towards =0A= ACs. The
case to handle as wells is what to do when one end receives =0A= the
"standby" indication but does not support the active/standby =0A= bit.

Andrew

> -----Original Message-----
> From: = Luca =0A= Martini [mailto:lmartini@cisco.com]
>= Sent: =0A= Monday, November 06, 2006 10:06 PM
> To: AISSAOUI Mustapha
> = Cc: =0A= l2vpn@ietf.org
> Subject: Re: Active/Standby Status = Bit
>
> =0A= Yes,
> I think that the question  here is as follows:
> = Does =0A= the status needs to have a different effect then
> = "administratively down =0A= " on the remote AC ?
> If so , then what happens if there is an = LDP =0A= session failure
> ? or label withdraw ?
>
> One case I = think =0A= would require this bit , is SONET aps. In
> that case the remote = PE should =0A= set the standby bit , as
> opposed to sending an AIS alarm.  = In this =0A= case , why can't we
> figure out what to do based on the received = SONET =0A= K1,K2 bytes ?
>
> Any other cases ?
>
> If we = need one, =0A= I would suggest having a separate very short
> document only on = the =0A= definition and semantics of a new status
> bit without all the = application =0A= text that we have seen in the
> multiple documents on this =0A= subject.
>
> Then those documents can more clearly reference = the =0A= "standby
> status bit"
> document , and describe possible = different =0A= schemes to achieve
> PW redundancy.
>
> = Luca
>
> =0A= AISSAOUI Mustapha wrote:
> > Luca,
> > Here is the = description =0A= of the "PW not forwarding" bit as
> per RFC 4447:
> = >
> =0A= > "The presence of the lowest bit (PW Not Forwarding) acts only as = a
> =0A= > generic failure indication when there is a link-down event
> = for =0A= which
> > none of the other bits apply."
> >
> = > So, =0A= we still need a bit to indicate a failure which is not
> =0A= explicilty
> > indicated by the AC and PSN failure bits. A good = example =0A= of
> using this
> > bit is when an LSP switches its path = and if =0A= the new path
> MTU does not
> > match anymore that = signaled in =0A= the PW FEC, this bit is used
> to signal
> > the remote = PE. There =0A= may be other types of failures which could use
> > this = bit.
> =0A= >
> > I can only conclude that we need a separate bit for =0A= the
> "Active/Standby"
> > status.
> >
> = > =0A= Mustapha.
> >
> =0A= >  
>
>
>

=0A= =0A= =0A= ------_=_NextPart_001_01C702A0.AF17E09B-- From l2vpn-bounces@ietf.org Tue Nov 07 14:17:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWRe-00050m-RW; Tue, 07 Nov 2006 14:17:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWRd-00050h-I5 for l2vpn@ietf.org; Tue, 07 Nov 2006 14:17:13 -0500 Received: from mx100.qos.net.il ([80.74.96.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWRb-0000qM-7I for l2vpn@ietf.org; Tue, 07 Nov 2006 14:17:13 -0500 Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mx100.qos.net.il (Postfix) with ESMTP id E83D034E5FC for ; Tue, 7 Nov 2006 21:17:41 +0200 (IST) 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_01C702A1.4E5A230E" Date: Tue, 7 Nov 2006 21:14:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCCJpihXIn1VhZTJKWPR0/+EqVfgADwMzQACFIbDAAAQijpg== References: From: "Sasha Vainshtein" To: "AISSAOUI Mustapha" , "Ali Sajassi \(sajassi\)" X-Spam-Score: 0.1 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit 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_01C702A1.4E5A230E Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Mustapha, Ali and all, After the yesterday presentation I have been under impression that, in = the case of a dual-homed MTU-s, the status bit would only sirnal to the = "standby" PE-r not to send its BUM traffic over the standby PW.=20 =20 Ali's text below seems to suggest that PE-r should not send ANY traffic = over the "standby" PW. =20 Do I miss something?=20 Or is it a real difference in interpretation (between, say, draft-muley = and VPLS dual-homing)? =20 Regards, Sasha ________________________________ From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com] Sent: Tue 11/7/2006 06:57 To: Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit Ali, See below. Mustapha. > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Monday, November 06, 2006 10:05 PM > To: AISSAOUI Mustapha; Luca Martini (lmartini) > Cc: l2vpn@ietf.org > Subject: RE: Active/Standby Status Bit > >=20 > > > -----Original Message----- > > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com] > > Sent: Monday, November 06, 2006 5:04 PM > > To: Luca Martini (lmartini) > > Cc: l2vpn@ietf.org > > Subject: Active/Standby Status Bit > > > > Luca, > > Here is the description of the "PW not forwarding" bit as per RFC > > 4447: > > > > "The presence of the lowest bit (PW Not Forwarding) acts only as a > > generic failure indication when there is a link-down event > for which > > none of the other bits apply." > > > > So, we still need a bit to indicate a failure which is not > explicilty > > indicated by the AC and PSN failure bits. A good example of > using this > > bit is when an LSP switches its path and if the new path > MTU does not > > match anymore that signaled in the PW FEC, this bit is used > to signal > > the remote PE. > > There may be other types of failures which could use this bit. > > > With respect to u-PE dual homing applications to two > different n-PE devices, it is still not clear to me why we > cannot use "PW forwarding" > bit (since the MTU for the standby PW is already signaled > between u-PE & standby n-PE). If the problem is its > definition as defined in RFC 4447, then we can generalize its > definition a bit more. However, if there is a more > fundamental problem, then lets elaborate on what that is. MA> The MTU for tunnel LSP can change if the LSP path for the primay PW or the secondary PW changes. If the new MTU value is lower than the one signaled in the PW FEC iterface parameter field, an alarm should be raised since the PE will drop packets on that PW. So, this is a fault condition which we currently signal using the "PW not forwarding bit". When the PW is in standby state, there is no fault or alarms which are generated. It just an indication to the remote PE to preferably not send traffic over that PW. > -Ali > > > I can only conclude that we need a separate bit for the > > "Active/Standby" > > status. > > > > Mustapha. > > > ------_=_NextPart_001_01C702A1.4E5A230E Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: Active/Standby Status Bit=0A= =0A= =0A=
=0A=
Mustapha, Ali = and =0A= all,
=0A=
After the yesterday = presentation I have =0A= been under impression that, in the case of a dual-homed MTU-s, the = status bit =0A= would only sirnal to the "standby" PE-r not to send its BUM traffic over = the =0A= standby PW.
=0A=
 
=0A=
Ali's text below seems to = suggest that PE-r =0A= should not send ANY traffic over the "standby" PW.
=0A=
 
=0A=
Do I miss something? =
=0A=
Or is it a real difference in =0A= interpretation (between, say, draft-muley and VPLS = dual-homing)?
=0A=
 
=0A=
Regards,
=0A=
          &nbs= p;     =0A= Sasha
=0A=

=0A=
=0A= From: AISSAOUI Mustapha =0A= [mailto:Mustapha.Aissaoui@alcatel.com]
Sent: Tue 11/7/2006 =0A= 06:57
To: Ali Sajassi (sajassi)
Cc: =0A= l2vpn@ietf.org
Subject: RE: Active/Standby Status =0A= Bit

=0A=
=0A=

Ali,
See below.

Mustapha.

> = -----Original =0A= Message-----
> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
> = Sent: =0A= Monday, November 06, 2006 10:05 PM
> To: AISSAOUI Mustapha; Luca = Martini =0A= (lmartini)
> Cc: l2vpn@ietf.org
> Subject: RE: = Active/Standby Status =0A= Bit
>
> 
>
> > -----Original =0A= Message-----
> > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@al= catel.com]
> =0A= > Sent: Monday, November 06, 2006 5:04 PM
> > To: Luca = Martini =0A= (lmartini)
> > Cc: l2vpn@ietf.org
> > Subject: = Active/Standby =0A= Status Bit
> >
> > Luca,
> > Here is the = description =0A= of the "PW not forwarding" bit as per RFC
> > 4447:
> =0A= >
> > "The presence of the lowest bit (PW Not Forwarding) = acts only =0A= as a
> > generic failure indication when there is a link-down =0A= event
> for which
> > none of the other bits = apply."
> =0A= >
> > So, we still need a bit to indicate a failure which is =0A= not
> explicilty
> > indicated by the AC and PSN failure = bits. A =0A= good example of
> using this
> > bit is when an LSP = switches its =0A= path and if the new path
> MTU does not
> > match anymore = that =0A= signaled in the PW FEC, this bit is used
> to signal
> > = the =0A= remote PE.
> > There may be other types of failures which could = use =0A= this bit.
> >
> With respect to u-PE dual homing = applications to =0A= two
> different n-PE devices, it is still not clear to me why = we
> =0A= cannot use "PW forwarding"
> bit (since the MTU for the standby PW = is =0A= already signaled
> between u-PE & standby n-PE). If the = problem is =0A= its
> definition as defined in RFC 4447, then we can generalize =0A= its
> definition a bit more. However, if there is a more
> =0A= fundamental problem, then lets elaborate on what that is.

MA> = The MTU =0A= for tunnel LSP can change if the LSP path for the primay PW
or the = secondary =0A= PW changes. If the new MTU value is lower than the one
signaled in = the PW FEC =0A= iterface parameter field, an alarm should be
raised since the PE will = drop =0A= packets on that PW. So, this is a fault
condition which we = currently  =0A= signal using the "PW not forwarding bit".

When the PW is in = standby =0A= state, there is no fault or alarms which are
generated. It just an = indication =0A= to the remote PE to preferably not send
traffic over that = PW.


> =0A= -Ali
>
> > I can only conclude that we need a separate = bit for =0A= the
> > "Active/Standby"
> > status.
> = >
> > =0A= Mustapha.
> >
>

=0A= =0A= =0A= ------_=_NextPart_001_01C702A1.4E5A230E-- From l2vpn-bounces@ietf.org Tue Nov 07 14:32:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWgN-0004WC-7h; Tue, 07 Nov 2006 14:32:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWgL-0004W6-2w for l2vpn@ietf.org; Tue, 07 Nov 2006 14:32:25 -0500 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWgK-0002Gs-GI for l2vpn@ietf.org; Tue, 07 Nov 2006 14:32:25 -0500 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA10579; Tue, 7 Nov 2006 11:31:12 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C702A3.4819C77D" Date: Wed, 8 Nov 2006 01:01:11 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCCJpihXIn1VhZTJKWPR0/+EqVfgADwMzQACFIbDAAAQijpgAANM7+ References: From: "Dutta, Pranjal" To: "Sasha Vainshtein" , "AISSAOUI Mustapha" , "Ali Sajassi \(sajassi\)" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit 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_01C702A3.4819C77D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sasha, Here is some clarifications.=20 =20 1) The draft proposed to block traffic at secondary PE-rs which is = standby for the MTU-s. Now in H-VPLS if you see only BUM=20 traffic will reach secondary PE-rs. The unicast learned traffic will = be be flowing to/from MTU-s only via primary/active PE-rs =20 2) In practical deployments in H-VPLS we might end up with control plane = scalability issues if per PW blocking/unblocking/ state change is done = and so we do the same per PW group. So we are using the Group ID in FEC = 128 or Grouping TLV in FEC 129 for per PW group state change with one = single message. =20 Thanks, Pranjal=20 ________________________________ From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Wed 11/8/2006 12:44 AM To: AISSAOUI Mustapha; Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit Mustapha, Ali and all, After the yesterday presentation I have been under impression that, in = the case of a dual-homed MTU-s, the status bit would only sirnal to the = "standby" PE-r not to send its BUM traffic over the standby PW.=20 =20 Ali's text below seems to suggest that PE-r should not send ANY traffic = over the "standby" PW. =20 Do I miss something?=20 Or is it a real difference in interpretation (between, say, draft-muley = and VPLS dual-homing)? =20 Regards, Sasha ________________________________ From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com] Sent: Tue 11/7/2006 06:57 To: Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit Ali, See below. Mustapha. > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Monday, November 06, 2006 10:05 PM > To: AISSAOUI Mustapha; Luca Martini (lmartini) > Cc: l2vpn@ietf.org > Subject: RE: Active/Standby Status Bit > >=20 > > > -----Original Message----- > > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com] > > Sent: Monday, November 06, 2006 5:04 PM > > To: Luca Martini (lmartini) > > Cc: l2vpn@ietf.org > > Subject: Active/Standby Status Bit > > > > Luca, > > Here is the description of the "PW not forwarding" bit as per RFC > > 4447: > > > > "The presence of the lowest bit (PW Not Forwarding) acts only as a > > generic failure indication when there is a link-down event > for which > > none of the other bits apply." > > > > So, we still need a bit to indicate a failure which is not > explicilty > > indicated by the AC and PSN failure bits. A good example of > using this > > bit is when an LSP switches its path and if the new path > MTU does not > > match anymore that signaled in the PW FEC, this bit is used > to signal > > the remote PE. > > There may be other types of failures which could use this bit. > > > With respect to u-PE dual homing applications to two > different n-PE devices, it is still not clear to me why we > cannot use "PW forwarding" > bit (since the MTU for the standby PW is already signaled > between u-PE & standby n-PE). If the problem is its > definition as defined in RFC 4447, then we can generalize its > definition a bit more. However, if there is a more > fundamental problem, then lets elaborate on what that is. MA> The MTU for tunnel LSP can change if the LSP path for the primay PW or the secondary PW changes. If the new MTU value is lower than the one signaled in the PW FEC iterface parameter field, an alarm should be raised since the PE will drop packets on that PW. So, this is a fault condition which we currently signal using the "PW not forwarding bit". When the PW is in standby state, there is no fault or alarms which are generated. It just an indication to the remote PE to preferably not send traffic over that PW. > -Ali > > > I can only conclude that we need a separate bit for the > > "Active/Standby" > > status. > > > > Mustapha. > > > ------_=_NextPart_001_01C702A3.4819C77D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= RE: Active/Standby Status Bit=0A= =0A= =0A=
=0A=
Sasha,
=0A=
          &nbs= p;      =0A= Here is some clarifications.
=0A=
 
=0A=
1) The draft proposed to = block traffic =0A= at secondary PE-rs which is standby for the MTU-s. Now = in H-VPLS if =0A= you see only BUM
=0A=
   traffic = will reach secondary PE-rs. The unicast = learned =0A= traffic will be be flowing to/from MTU-s only = via primary/active =0A= PE-rs
=0A=
 
=0A=
2) In practical deployments = in H-VPLS we =0A= might end up with control plane scalability issues if per =0A= PW   blocking/unblocking/ state change =0A= is done and so we do the same per PW group. So we are using the = Group ID in =0A= FEC 128 or Grouping TLV in FEC 129 for per PW group state change with = one single =0A= message.
=0A=
 
=0A=
Thanks,
=0A=
Pranjal 
=0A=

=0A=
=0A= From: Sasha Vainshtein =0A= [mailto:Sasha@AXERRA.com]
Sent: Wed 11/8/2006 12:44 = AM
To: =0A= AISSAOUI Mustapha; Ali Sajassi (sajassi)
Cc: =0A= l2vpn@ietf.org
Subject: RE: Active/Standby Status =0A= Bit

=0A=
=0A=
=0A=
Mustapha, Ali = and =0A= all,
=0A=
After the yesterday = presentation I have =0A= been under impression that, in the case of a dual-homed MTU-s, the = status bit =0A= would only sirnal to the "standby" PE-r not to send its BUM traffic over = the =0A= standby PW.
=0A=
 
=0A=
Ali's text below seems to = suggest that PE-r =0A= should not send ANY traffic over the "standby" PW.
=0A=
 
=0A=
Do I miss something? =
=0A=
Or is it a real difference in =0A= interpretation (between, say, draft-muley and VPLS = dual-homing)?
=0A=
 
=0A=
Regards,
=0A=
          &nbs= p;     =0A= Sasha
=0A=

=0A=
=0A= From: AISSAOUI Mustapha =0A= [mailto:Mustapha.Aissaoui@alcatel.com]
Sent: Tue 11/7/2006 =0A= 06:57
To: Ali Sajassi (sajassi)
Cc: =0A= l2vpn@ietf.org
Subject: RE: Active/Standby Status =0A= Bit

=0A=
=0A=

Ali,
See below.

Mustapha.

> = -----Original =0A= Message-----
> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
> = Sent: =0A= Monday, November 06, 2006 10:05 PM
> To: AISSAOUI Mustapha; Luca = Martini =0A= (lmartini)
> Cc: l2vpn@ietf.org
> Subject: RE: = Active/Standby Status =0A= Bit
>
> 
>
> > -----Original =0A= Message-----
> > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@al= catel.com]
> =0A= > Sent: Monday, November 06, 2006 5:04 PM
> > To: Luca = Martini =0A= (lmartini)
> > Cc: l2vpn@ietf.org
> > Subject: = Active/Standby =0A= Status Bit
> >
> > Luca,
> > Here is the = description =0A= of the "PW not forwarding" bit as per RFC
> > 4447:
> =0A= >
> > "The presence of the lowest bit (PW Not Forwarding) = acts only =0A= as a
> > generic failure indication when there is a link-down =0A= event
> for which
> > none of the other bits = apply."
> =0A= >
> > So, we still need a bit to indicate a failure which is =0A= not
> explicilty
> > indicated by the AC and PSN failure = bits. A =0A= good example of
> using this
> > bit is when an LSP = switches its =0A= path and if the new path
> MTU does not
> > match anymore = that =0A= signaled in the PW FEC, this bit is used
> to signal
> > = the =0A= remote PE.
> > There may be other types of failures which could = use =0A= this bit.
> >
> With respect to u-PE dual homing = applications to =0A= two
> different n-PE devices, it is still not clear to me why = we
> =0A= cannot use "PW forwarding"
> bit (since the MTU for the standby PW = is =0A= already signaled
> between u-PE & standby n-PE). If the = problem is =0A= its
> definition as defined in RFC 4447, then we can generalize =0A= its
> definition a bit more. However, if there is a more
> =0A= fundamental problem, then lets elaborate on what that is.

MA> = The MTU =0A= for tunnel LSP can change if the LSP path for the primay PW
or the = secondary =0A= PW changes. If the new MTU value is lower than the one
signaled in = the PW FEC =0A= iterface parameter field, an alarm should be
raised since the PE will = drop =0A= packets on that PW. So, this is a fault
condition which we = currently  =0A= signal using the "PW not forwarding bit".

When the PW is in = standby =0A= state, there is no fault or alarms which are
generated. It just an = indication =0A= to the remote PE to preferably not send
traffic over that = PW.


> =0A= -Ali
>
> > I can only conclude that we need a separate = bit for =0A= the
> > "Active/Standby"
> > status.
> = >
> > =0A= Mustapha.
> >
>

=0A= =0A= =0A= ------_=_NextPart_001_01C702A3.4819C77D-- From l2vpn-bounces@ietf.org Tue Nov 07 15:38:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXh9-0006rV-Pf; Tue, 07 Nov 2006 15:37:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXh8-0006rQ-T8 for l2vpn@ietf.org; Tue, 07 Nov 2006 15:37:18 -0500 Received: from mx100.qos.net.il ([80.74.96.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXh5-00011c-7z for l2vpn@ietf.org; Tue, 07 Nov 2006 15:37:18 -0500 Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mx100.qos.net.il (Postfix) with ESMTP id 1DA8C34E4F5 for ; Tue, 7 Nov 2006 22:37:46 +0200 (IST) 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_01C702AC.7DEFA9BC" Date: Tue, 7 Nov 2006 22:37:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCCJpihXIn1VhZTJKWPR0/+EqVfgADwMzQACFIbDAAAQijpgAANM7+AAIZj6k= References: From: "Sasha Vainshtein" To: "Dutta, Pranjal" , "AISSAOUI Mustapha" , "Ali Sajassi \(sajassi\)" X-Spam-Score: 0.1 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit 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_01C702AC.7DEFA9BC Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Pranjal, Thank you for a prompt response and clarification. =20 I am not completely sure that the secondary PE-r shall never send any = known unicasts over the Spoke PW. E.g., during the failure recovery process: *=09 Originally, all the traffic for MTU-s is handled by the Pimary PE-r *=09 After the failure all the traffic will be handled by the Secondary PE-r *=09 Once the Primary Spoke recovers, MTI-S signals the Spoke to the = Secondary PE-r as standby, but it still receives valid unicast frames = for this MTU-s. Do you expect it to start dropping them immediately, or = should it go on with forwarding them until while (presumably) = withdrawing relevant MAC addresses? Speaking in more generic terms: 1. A regular PW architecture includes 3 entities: * An attachment circuit * A PW endpoint * A Forwarder connecting one to the other in a 1:1 way 2. In the PE-r case: * The attachment circuit is, to the best of my understanding replaced = by the Spoke PW * The VSI acts as a many-to-many Forwarder. 3. These (undrawn:-) diagrams lead me to the following question: which = entity is going to interpret the Active/Standby signal? There are, IMHO, = 3 options: * It is interpreted by the (PSN-facing) PW endpoint. This could be the = case in draft-muley but, IMHO, not in the H-VPLS case * It is interpreted by the Spoke PW end point (applicable only for the = H-VPLS case) * It is interpreted by the Forwarder (allowing each forwarder to = interpret it according to its specific nature and, IMHO, equally = applicable to all cases). Did I miss something? Regards, Sasha =20 =20 =20 ________________________________ From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tue 11/7/2006 07:31 To: Sasha Vainshtein; AISSAOUI Mustapha; Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit Sasha, Here is some clarifications.=20 =20 1) The draft proposed to block traffic at secondary PE-rs which is = standby for the MTU-s. Now in H-VPLS if you see only BUM=20 traffic will reach secondary PE-rs. The unicast learned traffic will = be be flowing to/from MTU-s only via primary/active PE-rs =20 2) In practical deployments in H-VPLS we might end up with control plane = scalability issues if per PW blocking/unblocking/ state change is done = and so we do the same per PW group. So we are using the Group ID in FEC = 128 or Grouping TLV in FEC 129 for per PW group state change with one = single message. =20 Thanks, Pranjal=20 ________________________________ From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Wed 11/8/2006 12:44 AM To: AISSAOUI Mustapha; Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit Mustapha, Ali and all, After the yesterday presentation I have been under impression that, in = the case of a dual-homed MTU-s, the status bit would only sirnal to the = "standby" PE-r not to send its BUM traffic over the standby PW.=20 =20 Ali's text below seems to suggest that PE-r should not send ANY traffic = over the "standby" PW. =20 Do I miss something?=20 Or is it a real difference in interpretation (between, say, draft-muley = and VPLS dual-homing)? =20 Regards, Sasha ________________________________ From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com] Sent: Tue 11/7/2006 06:57 To: Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit Ali, See below. Mustapha. > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Monday, November 06, 2006 10:05 PM > To: AISSAOUI Mustapha; Luca Martini (lmartini) > Cc: l2vpn@ietf.org > Subject: RE: Active/Standby Status Bit > >=20 > > > -----Original Message----- > > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com] > > Sent: Monday, November 06, 2006 5:04 PM > > To: Luca Martini (lmartini) > > Cc: l2vpn@ietf.org > > Subject: Active/Standby Status Bit > > > > Luca, > > Here is the description of the "PW not forwarding" bit as per RFC > > 4447: > > > > "The presence of the lowest bit (PW Not Forwarding) acts only as a > > generic failure indication when there is a link-down event > for which > > none of the other bits apply." > > > > So, we still need a bit to indicate a failure which is not > explicilty > > indicated by the AC and PSN failure bits. A good example of > using this > > bit is when an LSP switches its path and if the new path > MTU does not > > match anymore that signaled in the PW FEC, this bit is used > to signal > > the remote PE. > > There may be other types of failures which could use this bit. > > > With respect to u-PE dual homing applications to two > different n-PE devices, it is still not clear to me why we > cannot use "PW forwarding" > bit (since the MTU for the standby PW is already signaled > between u-PE & standby n-PE). If the problem is its > definition as defined in RFC 4447, then we can generalize its > definition a bit more. However, if there is a more > fundamental problem, then lets elaborate on what that is. MA> The MTU for tunnel LSP can change if the LSP path for the primay PW or the secondary PW changes. If the new MTU value is lower than the one signaled in the PW FEC iterface parameter field, an alarm should be raised since the PE will drop packets on that PW. So, this is a fault condition which we currently signal using the "PW not forwarding bit". When the PW is in standby state, there is no fault or alarms which are generated. It just an indication to the remote PE to preferably not send traffic over that PW. > -Ali > > > I can only conclude that we need a separate bit for the > > "Active/Standby" > > status. > > > > Mustapha. > > > ------_=_NextPart_001_01C702AC.7DEFA9BC Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= RE: Active/Standby Status Bit=0A= =0A= =0A=
=0A=
Pranjal,
=0A=
Thank you = for a prompt =0A= response and clarification.
=0A=
 
=0A=
I am not completely sure that = the secondary =0A= PE-r shall never send any known unicasts over the Spoke PW.
=0A=
E.g., during the failure = recovery =0A= process:
=0A=
    =0A=
  • =0A=
    Originally, all the traffic for MTU-s = is handled =0A= by the Pimary PE-r
    • =0A=
  • =0A=
    After the failure all the traffic = will be handled =0A= by the Secondary PE-r
    • =0A=
  • =0A=
    Once the Primary Spoke recovers, = MTI-S signals =0A= the Spoke to the Secondary PE-r as standby, but it still receives = valid =0A= unicast frames for this MTU-s. Do you expect it to start dropping them =0A= immediately, or should it go on with forwarding them until while = (presumably) =0A= withdrawing relevant MAC addresses?
=0A=

Speaking in more generic terms:

=0A=
    =0A=
  1. A regular PW architecture includes 3 =0A= entities:
    2. =0A=
      =0A=
    • An attachment circuit
      • =0A=
    • A PW endpoint
      • =0A=
    • A Forwarder connecting one to the = other in a 1:1 =0A= way
    =0A=
  2. In the PE-r case:
    3. =0A=
      =0A=
    • The attachment circuit is, to the = best of my =0A= understanding replaced by the Spoke PW
      • =0A=
    • The VSI acts as a many-to-many =0A= Forwarder.
    =0A=
  3. These (undrawn:-) diagrams lead me to = the =0A= following question: which entity is going to interpret the = Active/Standby =0A= signal? There are, IMHO, 3 options:
    4. =0A=
      =0A=
    • It is interpreted by the = (PSN-facing) PW =0A= endpoint. This could be the case in draft-muley but, IMHO, not in = the H-VPLS =0A= case
      • =0A=
    • It is interpreted by the Spoke PW = end point =0A= (applicable only for the H-VPLS case)
      • =0A=
    • It is interpreted by the Forwarder = (allowing =0A= each forwarder to interpret it according to its specific nature and, = IMHO, =0A= equally applicable to all cases).
=0A=

Did I miss something?

=0A=

Regards,

=0A=

          &nbs= p;         =0A= Sasha

=0A=

 

=0A=
 
=0A=

 

=0A=

=0A=
=0A=
=0A=
=0A=
From: Dutta, Pranjal =0A= [mailto:pdutta@riverstonenet.com]
Sent: Tue 11/7/2006 =0A= 07:31
To: Sasha Vainshtein; AISSAOUI Mustapha; Ali Sajassi =0A= (sajassi)
Cc: l2vpn@ietf.org
Subject: RE: = Active/Standby =0A= Status Bit

=0A=
=0A=
=0A=
Sasha,
=0A=
          &nbs= p;      =0A= Here is some clarifications.
=0A=
 
=0A=
1) The draft proposed to = block traffic =0A= at secondary PE-rs which is standby for the MTU-s. Now = in H-VPLS if =0A= you see only BUM
=0A=
   traffic = will reach secondary PE-rs. The unicast = learned =0A= traffic will be be flowing to/from MTU-s only = via primary/active =0A= PE-rs
=0A=
 
=0A=
2) In practical deployments = in H-VPLS we =0A= might end up with control plane scalability issues if per =0A= PW   blocking/unblocking/ state change =0A= is done and so we do the same per PW group. So we are using the = Group ID in =0A= FEC 128 or Grouping TLV in FEC 129 for per PW group state change with = one single =0A= message.
=0A=
 
=0A=
Thanks,
=0A=
Pranjal 
=0A=

=0A=
=0A= From: Sasha Vainshtein =0A= [mailto:Sasha@AXERRA.com]
Sent: Wed 11/8/2006 12:44 = AM
To: =0A= AISSAOUI Mustapha; Ali Sajassi (sajassi)
Cc: =0A= l2vpn@ietf.org
Subject: RE: Active/Standby Status =0A= Bit

=0A=
=0A=
=0A=
Mustapha, Ali = and =0A= all,
=0A=
After the yesterday = presentation I have =0A= been under impression that, in the case of a dual-homed MTU-s, the = status bit =0A= would only sirnal to the "standby" PE-r not to send its BUM traffic over = the =0A= standby PW.
=0A=
 
=0A=
Ali's text below seems to = suggest that PE-r =0A= should not send ANY traffic over the "standby" PW.
=0A=
 
=0A=
Do I miss something? =
=0A=
Or is it a real difference in =0A= interpretation (between, say, draft-muley and VPLS = dual-homing)?
=0A=
 
=0A=
Regards,
=0A=
          &nbs= p;     =0A= Sasha
=0A=

=0A=
=0A= From: AISSAOUI Mustapha =0A= [mailto:Mustapha.Aissaoui@alcatel.com]
Sent: Tue 11/7/2006 =0A= 06:57
To: Ali Sajassi (sajassi)
Cc: =0A= l2vpn@ietf.org
Subject: RE: Active/Standby Status =0A= Bit

=0A=
=0A=

Ali,
See below.

Mustapha.

> = -----Original =0A= Message-----
> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
> = Sent: =0A= Monday, November 06, 2006 10:05 PM
> To: AISSAOUI Mustapha; Luca = Martini =0A= (lmartini)
> Cc: l2vpn@ietf.org
> Subject: RE: = Active/Standby Status =0A= Bit
>
> 
>
> > -----Original =0A= Message-----
> > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@al= catel.com]
> =0A= > Sent: Monday, November 06, 2006 5:04 PM
> > To: Luca = Martini =0A= (lmartini)
> > Cc: l2vpn@ietf.org
> > Subject: = Active/Standby =0A= Status Bit
> >
> > Luca,
> > Here is the = description =0A= of the "PW not forwarding" bit as per RFC
> > 4447:
> =0A= >
> > "The presence of the lowest bit (PW Not Forwarding) = acts only =0A= as a
> > generic failure indication when there is a link-down =0A= event
> for which
> > none of the other bits = apply."
> =0A= >
> > So, we still need a bit to indicate a failure which is =0A= not
> explicilty
> > indicated by the AC and PSN failure = bits. A =0A= good example of
> using this
> > bit is when an LSP = switches its =0A= path and if the new path
> MTU does not
> > match anymore = that =0A= signaled in the PW FEC, this bit is used
> to signal
> > = the =0A= remote PE.
> > There may be other types of failures which could = use =0A= this bit.
> >
> With respect to u-PE dual homing = applications to =0A= two
> different n-PE devices, it is still not clear to me why = we
> =0A= cannot use "PW forwarding"
> bit (since the MTU for the standby PW = is =0A= already signaled
> between u-PE & standby n-PE). If the = problem is =0A= its
> definition as defined in RFC 4447, then we can generalize =0A= its
> definition a bit more. However, if there is a more
> =0A= fundamental problem, then lets elaborate on what that is.

MA> = The MTU =0A= for tunnel LSP can change if the LSP path for the primay PW
or the = secondary =0A= PW changes. If the new MTU value is lower than the one
signaled in = the PW FEC =0A= iterface parameter field, an alarm should be
raised since the PE will = drop =0A= packets on that PW. So, this is a fault
condition which we = currently  =0A= signal using the "PW not forwarding bit".

When the PW is in = standby =0A= state, there is no fault or alarms which are
generated. It just an = indication =0A= to the remote PE to preferably not send
traffic over that = PW.


> =0A= -Ali
>
> > I can only conclude that we need a separate = bit for =0A= the
> > "Active/Standby"
> > status.
> = >
> > =0A= Mustapha.
> =0A= >
>

=0A= =0A= =0A= ------_=_NextPart_001_01C702AC.7DEFA9BC-- From l2vpn-bounces@ietf.org Tue Nov 07 17:20:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZHw-0005sY-0f; Tue, 07 Nov 2006 17:19:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZHu-0005oV-R1 for l2vpn@ietf.org; Tue, 07 Nov 2006 17:19:22 -0500 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZHt-0006SO-Qy for l2vpn@ietf.org; Tue, 07 Nov 2006 17:19:22 -0500 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id OAA26466; Tue, 7 Nov 2006 14:18:19 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C702BA.A050418B" Date: Wed, 8 Nov 2006 03:48:18 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCCJpihXIn1VhZTJKWPR0/+EqVfgADwMzQACFIbDAAAQijpgAANM7+AAIZj6kAAwnWqA== References: From: "Dutta, Pranjal" To: "Sasha Vainshtein" , "AISSAOUI Mustapha" , "Ali Sajassi \(sajassi\)" X-Spam-Score: 0.1 (/) X-Scan-Signature: 182294e3fdac3aef093c0503b87ed133 Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit 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_01C702BA.A050418B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sasha, Please refer my answers inline. =20 Regards, Pranjal=20 ________________________________ From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Wed 11/8/2006 2:07 AM To: Dutta, Pranjal; AISSAOUI Mustapha; Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit Pranjal, Thank you for a prompt response and clarification. =20 I am not completely sure that the secondary PE-r shall never send any = known unicasts over the Spoke PW. E.g., during the failure recovery process: *=09 Originally, all the traffic for MTU-s is handled by the Pimary PE-r *=09 After the failure all the traffic will be handled by the Secondary PE-r *=09 Once the Primary Spoke recovers, MTI-S signals the Spoke to the = Secondary PE-r as standby, but it still receives valid unicast frames = for this MTU-s. Do you expect it to start dropping them immediately, or = should it go on with forwarding them until while (presumably) = withdrawing relevant MAC addresses? [Pranjal] In practical terms it makes more sense to make a PW/PW Group = from Active to Standby state after sending the MAC address withdrawal so = that unicast traffic gets relearned over the "latest" active PW. IMHO I = would prefer to leave it as implementation specific and keep it open.=20 =20 Speaking in more generic terms: 1. A regular PW architecture includes 3 entities:=20 * An attachment circuit=20 * A PW endpoint=20 * A Forwarder connecting one to the other in a 1:1 way 2. In the PE-r case:=20 * The attachment circuit is, to the best of my understanding replaced = by the Spoke PW=20 * The VSI acts as a many-to-many Forwarder. 3. These (undrawn:-) diagrams lead me to the following question: which = entity is going to interpret the Active/Standby signal? There are, IMHO, = 3 options:=20 * It is interpreted by the (PSN-facing) PW endpoint. This could be the = case in draft-muley but, IMHO, not in the H-VPLS case=20 * It is interpreted by the Spoke PW end point (applicable only for the = H-VPLS case)=20 *=09 * [Pranjal] The draft-pdutta-standby deals this application. In H-VPLS = we need to block=20 * the spoke PW between MTU-s and PE-rs. We have also = included a Ring Topology in the =20 * draft where we require PW between two PEs or can have = multi-homing as well(requirement =20 * specified in section 5.2 = draft-ietf-l2vpn-vpls-bridge-interop-xx).The mechanism is generic =20 * which can be extended to any application that may = require to block a standby PW. draft-=20 * muley discussed about other applications of SS-PW and = MS-PW where standby PW=20 * blocking is required with standby bit.=20 *=09 * It is interpreted by the Forwarder (allowing each forwarder to = interpret it according to its specific nature and, IMHO, equally = applicable to all cases). *=09 * [Pranjal] In H-VPLS we have left it open to implementation on HOW to = block a PW. The standby bit * is to block the PW endpoint. In H-VPLS case additional actions can be = taken to assist the forwarder according to its specific nature. (e.g = like we have specified in last paragraph in section 6.3 in the draft = that MAC flushing by the PE-rs itself may be possible as PE-rs is now = notified about standby/active state) Did I miss something? Regards, Sasha =20 =20 =20 ________________________________ From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tue 11/7/2006 07:31 To: Sasha Vainshtein; AISSAOUI Mustapha; Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit Sasha, Here is some clarifications.=20 =20 1) The draft proposed to block traffic at secondary PE-rs which is = standby for the MTU-s. Now in H-VPLS if you see only BUM=20 traffic will reach secondary PE-rs. The unicast learned traffic will = be be flowing to/from MTU-s only via primary/active PE-rs =20 2) In practical deployments in H-VPLS we might end up with control plane = scalability issues if per PW blocking/unblocking/ state change is done = and so we do the same per PW group. So we are using the Group ID in FEC = 128 or Grouping TLV in FEC 129 for per PW group state change with one = single message. =20 Thanks, Pranjal=20 ________________________________ From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Wed 11/8/2006 12:44 AM To: AISSAOUI Mustapha; Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit Mustapha, Ali and all, After the yesterday presentation I have been under impression that, in = the case of a dual-homed MTU-s, the status bit would only sirnal to the = "standby" PE-r not to send its BUM traffic over the standby PW.=20 =20 Ali's text below seems to suggest that PE-r should not send ANY traffic = over the "standby" PW. =20 Do I miss something?=20 Or is it a real difference in interpretation (between, say, draft-muley = and VPLS dual-homing)? =20 Regards, Sasha ________________________________ From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com] Sent: Tue 11/7/2006 06:57 To: Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit Ali, See below. Mustapha. > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Monday, November 06, 2006 10:05 PM > To: AISSAOUI Mustapha; Luca Martini (lmartini) > Cc: l2vpn@ietf.org > Subject: RE: Active/Standby Status Bit > >=20 > > > -----Original Message----- > > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com] > > Sent: Monday, November 06, 2006 5:04 PM > > To: Luca Martini (lmartini) > > Cc: l2vpn@ietf.org > > Subject: Active/Standby Status Bit > > > > Luca, > > Here is the description of the "PW not forwarding" bit as per RFC > > 4447: > > > > "The presence of the lowest bit (PW Not Forwarding) acts only as a > > generic failure indication when there is a link-down event > for which > > none of the other bits apply." > > > > So, we still need a bit to indicate a failure which is not > explicilty > > indicated by the AC and PSN failure bits. A good example of > using this > > bit is when an LSP switches its path and if the new path > MTU does not > > match anymore that signaled in the PW FEC, this bit is used > to signal > > the remote PE. > > There may be other types of failures which could use this bit. > > > With respect to u-PE dual homing applications to two > different n-PE devices, it is still not clear to me why we > cannot use "PW forwarding" > bit (since the MTU for the standby PW is already signaled > between u-PE & standby n-PE). If the problem is its > definition as defined in RFC 4447, then we can generalize its > definition a bit more. However, if there is a more > fundamental problem, then lets elaborate on what that is. MA> The MTU for tunnel LSP can change if the LSP path for the primay PW or the secondary PW changes. If the new MTU value is lower than the one signaled in the PW FEC iterface parameter field, an alarm should be raised since the PE will drop packets on that PW. So, this is a fault condition which we currently signal using the "PW not forwarding bit". When the PW is in standby state, there is no fault or alarms which are generated. It just an indication to the remote PE to preferably not send traffic over that PW. > -Ali > > > I can only conclude that we need a separate bit for the > > "Active/Standby" > > status. > > > > Mustapha. > > > ------_=_NextPart_001_01C702BA.A050418B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= RE: Active/Standby Status Bit=0A= =0A= =0A=
=0A=
Hi = Sasha,
=0A=
          &nbs= p;         =0A= Please refer my answers inline.
=0A=
 
=0A=
Regards,
=0A=
Pranjal 
=0A=

=0A=
=0A= From: Sasha Vainshtein =0A= [mailto:Sasha@AXERRA.com]
Sent: Wed 11/8/2006 2:07 = AM
To: =0A= Dutta, Pranjal; AISSAOUI Mustapha; Ali Sajassi (sajassi)
Cc: =0A= l2vpn@ietf.org
Subject: RE: Active/Standby Status =0A= Bit

=0A=
=0A=
Pranjal,
=0A=
Thank you = for a prompt =0A= response and clarification.
=0A=
 
=0A=
I am not completely sure that = the secondary =0A= PE-r shall never send any known unicasts over the Spoke PW.
=0A=
E.g., during the failure = recovery =0A= process:
=0A=
    =0A=
  • =0A=
    Originally, all the traffic for MTU-s = is handled =0A= by the Pimary PE-r
    =0A=
  • =0A=
    After the failure all the traffic = will be handled =0A= by the Secondary PE-r
    =0A=
  • =0A=
    Once the Primary Spoke recovers, = MTI-S signals =0A= the Spoke to the Secondary PE-r as standby, but it still receives = valid =0A= unicast frames for this MTU-s. Do you expect it to start dropping them =0A= immediately, or should it go on with forwarding them until while = (presumably) =0A= withdrawing relevant MAC addresses?
=0A=

[Pranjal] In practical terms it makes = more sense to =0A= make a PW/PW Group from Active to Standby state after sending the MAC = address =0A= withdrawal so that unicast traffic gets relearned over the "latest" = active PW. =0A= IMHO I would prefer to leave it as = implementation =0A= specific and keep it open. 

=0A=

 

=0A=

Speaking in more generic terms:

=0A=
    =0A=
  1. A regular PW architecture includes 3 =0A= entities: =0A=
      =0A=
    • An attachment circuit =0A=
    • A PW endpoint =0A=
    • A Forwarder connecting one to the = other in a 1:1 =0A= way
    =0A=
  2. In the PE-r case: =0A=
      =0A=
    • The attachment circuit is, to the = best of my =0A= understanding replaced by the Spoke PW =0A=
    • The VSI acts as a many-to-many =0A= Forwarder.
    =0A=
  3. These (undrawn:-) diagrams lead me to = the =0A= following question: which entity is going to interpret the = Active/Standby =0A= signal? There are, IMHO, 3 options: =0A=
      =0A=
    • It is interpreted by the = (PSN-facing) PW =0A= endpoint. This could be the case in draft-muley but, IMHO, not in = the H-VPLS =0A= case =0A=
    • It is interpreted by the Spoke PW = end point =0A= (applicable only for the H-VPLS case)=0A=
    • =0A=
    • [Pranjal] The draft-pdutta-standby = deals this =0A= application. In H-VPLS we need to block=0A=
    •           &nbs= p;  the =0A= spoke PW between MTU-s and PE-rs. We have also included a Ring = Topology in =0A= the    =0A=
    •           &nbs= p;  =0A= draft where we require PW between two PEs or can have = multi-homing as =0A= well(requirement  =0A=
    •           &nbs= p; =0A= specified in section 5.2 = draft-ietf-l2vpn-vpls-bridge-interop-xx).The =0A= mechanism is generic  =0A=
    •           &nbs= p;  =0A= which can be extended to any application that may require to block a standby = PW. =0A= draft-=0A=
    •           &nbs= p;  =0A= muley discussed about other =0A= applications of SS-PW and  MS-PW where standby PW =0A=
    •           &nbs= p;  =0A= blocking is required = with standby bit.=0A=
    • =0A=
    • It is interpreted by the Forwarder = (allowing =0A= each forwarder to interpret it according to its specific nature and, = IMHO, =0A= equally applicable to all cases).
      • =0A=
    • =0A=
    • [Pranjal] In H-VPLS we have left it = open to =0A= implementation on HOW to block a PW. The standby bit
      • =0A=
    • is to block the PW endpoint. In = H-VPLS case =0A= additional actions can be taken to assist the forwarder = according =0A= to its specific nature. (e.g like we have specified in last = paragraph in =0A= section 6.3 in the draft that MAC flushing by the PE-rs itself may be possible as PE-rs is now = notified about =0A= standby/active state)
=0A=

Did I miss something?

=0A=

Regards,

=0A=

          &nbs= p;         =0A= Sasha

=0A=

 

=0A=
 
=0A=

 

=0A=

=0A=
=0A=
=0A=
=0A=
From: Dutta, Pranjal =0A= [mailto:pdutta@riverstonenet.com]
Sent: Tue 11/7/2006 =0A= 07:31
To: Sasha Vainshtein; AISSAOUI Mustapha; Ali Sajassi =0A= (sajassi)
Cc: l2vpn@ietf.org
Subject: RE: = Active/Standby =0A= Status Bit

=0A=
=0A=
=0A=
Sasha,
=0A=
          &nbs= p;      =0A= Here is some clarifications.
=0A=
 
=0A=
1) The draft proposed to = block traffic =0A= at secondary PE-rs which is standby for the MTU-s. Now = in H-VPLS if =0A= you see only BUM
=0A=
   traffic = will reach secondary PE-rs. The unicast = learned =0A= traffic will be be flowing to/from MTU-s only = via primary/active =0A= PE-rs
=0A=
 
=0A=
2) In practical deployments = in H-VPLS we =0A= might end up with control plane scalability issues if per =0A= PW   blocking/unblocking/ state change =0A= is done and so we do the same per PW group. So we are using the = Group ID in =0A= FEC 128 or Grouping TLV in FEC 129 for per PW group state change with = one single =0A= message.
=0A=
 
=0A=
Thanks,
=0A=
Pranjal 
=0A=

=0A=
=0A= From: Sasha Vainshtein =0A= [mailto:Sasha@AXERRA.com]
Sent: Wed 11/8/2006 12:44 = AM
To: =0A= AISSAOUI Mustapha; Ali Sajassi (sajassi)
Cc: =0A= l2vpn@ietf.org
Subject: RE: Active/Standby Status =0A= Bit

=0A=
=0A=
=0A=
Mustapha, Ali = and =0A= all,
=0A=
After the yesterday = presentation I have =0A= been under impression that, in the case of a dual-homed MTU-s, the = status bit =0A= would only sirnal to the "standby" PE-r not to send its BUM traffic over = the =0A= standby PW.
=0A=
 
=0A=
Ali's text below seems to = suggest that PE-r =0A= should not send ANY traffic over the "standby" PW.
=0A=
 
=0A=
Do I miss something? =
=0A=
Or is it a real difference in =0A= interpretation (between, say, draft-muley and VPLS = dual-homing)?
=0A=
 
=0A=
Regards,
=0A=
          &nbs= p;     =0A= Sasha
=0A=

=0A=
=0A= From: AISSAOUI Mustapha =0A= [mailto:Mustapha.Aissaoui@alcatel.com]
Sent: Tue 11/7/2006 =0A= 06:57
To: Ali Sajassi (sajassi)
Cc: =0A= l2vpn@ietf.org
Subject: RE: Active/Standby Status =0A= Bit

=0A=
=0A=

Ali,
See below.

Mustapha.

> = -----Original =0A= Message-----
> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
> = Sent: =0A= Monday, November 06, 2006 10:05 PM
> To: AISSAOUI Mustapha; Luca = Martini =0A= (lmartini)
> Cc: l2vpn@ietf.org
> Subject: RE: = Active/Standby Status =0A= Bit
>
> 
>
> > -----Original =0A= Message-----
> > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@al= catel.com]
> =0A= > Sent: Monday, November 06, 2006 5:04 PM
> > To: Luca = Martini =0A= (lmartini)
> > Cc: l2vpn@ietf.org
> > Subject: = Active/Standby =0A= Status Bit
> >
> > Luca,
> > Here is the = description =0A= of the "PW not forwarding" bit as per RFC
> > 4447:
> =0A= >
> > "The presence of the lowest bit (PW Not Forwarding) = acts only =0A= as a
> > generic failure indication when there is a link-down =0A= event
> for which
> > none of the other bits = apply."
> =0A= >
> > So, we still need a bit to indicate a failure which is =0A= not
> explicilty
> > indicated by the AC and PSN failure = bits. A =0A= good example of
> using this
> > bit is when an LSP = switches its =0A= path and if the new path
> MTU does not
> > match anymore = that =0A= signaled in the PW FEC, this bit is used
> to signal
> > = the =0A= remote PE.
> > There may be other types of failures which could = use =0A= this bit.
> >
> With respect to u-PE dual homing = applications to =0A= two
> different n-PE devices, it is still not clear to me why = we
> =0A= cannot use "PW forwarding"
> bit (since the MTU for the standby PW = is =0A= already signaled
> between u-PE & standby n-PE). If the = problem is =0A= its
> definition as defined in RFC 4447, then we can generalize =0A= its
> definition a bit more. However, if there is a more
> =0A= fundamental problem, then lets elaborate on what that is.

MA> = The MTU =0A= for tunnel LSP can change if the LSP path for the primay PW
or the = secondary =0A= PW changes. If the new MTU value is lower than the one
signaled in = the PW FEC =0A= iterface parameter field, an alarm should be
raised since the PE will = drop =0A= packets on that PW. So, this is a fault
condition which we = currently  =0A= signal using the "PW not forwarding bit".

When the PW is in = standby =0A= state, there is no fault or alarms which are
generated. It just an = indication =0A= to the remote PE to preferably not send
traffic over that = PW.


> =0A= -Ali
>
> > I can only conclude that we need a separate = bit for =0A= the
> > "Active/Standby"
> > status.
> = >
> > =0A= Mustapha.
> =0A= >
>

=0A= =0A= =0A= ------_=_NextPart_001_01C702BA.A050418B-- From l2vpn-bounces@ietf.org Tue Nov 07 22:28:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe5N-0008Uq-2Z; Tue, 07 Nov 2006 22:26:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghe5L-0008Ty-Qq for l2vpn@ietf.org; Tue, 07 Nov 2006 22:26:43 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghe5K-0004tA-3J for l2vpn@ietf.org; Tue, 07 Nov 2006 22:26:43 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2006 19:26:42 -0800 X-IronPort-AV: i="4.09,399,1157353200"; d="scan'208,217"; a="350742696:sNHT108383288" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA83QfYi014421; Tue, 7 Nov 2006 19:26:41 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA83Qein009381; Tue, 7 Nov 2006 19:26:41 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 19:26:40 -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_01C702E5.B48621BA" Date: Tue, 7 Nov 2006 19:26:39 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB0256AAE4@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Active/Standby Status Bit Thread-Index: AccCCJpihXIn1VhZTJKWPR0/+EqVfgADwMzQACFIbDAAAQijpgAQ0jXg From: "Ali Sajassi \(sajassi\)" To: "Sasha Vainshtein" , "AISSAOUI Mustapha" X-OriginalArrivalTime: 08 Nov 2006 03:26:40.0756 (UTC) FILETIME=[B4CEB340:01C702E5] DKIM-Signature: a=rsa-sha1; q=dns; l=10847; t=1162956401; x=1163820401; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sajassi@cisco.com; z=From:=22Ali=20Sajassi=20\(sajassi\)=22=20 |Subject:RE=3A=20Active/Standby=20Status=20Bit; X=v=3Dcisco.com=3B=20h=3D/uC5InAygAQPtZ13mQfyn9uT/xw=3D; b=Tbxh9w2YD/ARG7k1dxnh+JgdTwLQD7atgMIztFZvF0fGa1KYz7lk9WrZJYyin7cZFihbhMV5 EdlIO9oRpXVSr/T4ugPRA6+fkLM4WRI8PG2jrm15smuoCATDL9Xlc2HV; Authentication-Results: sj-dkim-4.cisco.com; header.From=sajassi@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit 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_01C702E5.B48621BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]=20 Sent: Tuesday, November 07, 2006 11:14 AM To: AISSAOUI Mustapha; Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit =09 =09 Mustapha, Ali and all, After the yesterday presentation I have been under impression that, in the case of a dual-homed MTU-s, the status bit would only sirnal to the "standby" PE-r not to send its BUM traffic over the standby PW.=20 =20 Ali's text below seems to suggest that PE-r should not send ANY traffic over the "standby" PW.=20 =20 Yes, PE-rs should not send any traffic because known-unicast would never get sent over standby PW from either far-end MTU-s or local MTU-s. However, based on earlier emails, it seems like we need to have a new bit anyway because of OAM indication issue to AC. =20 -Ali =20 Do I miss something?=20 Or is it a real difference in interpretation (between, say, draft-muley and VPLS dual-homing)? =20 Regards, Sasha ________________________________ From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com] Sent: Tue 11/7/2006 06:57 To: Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: Active/Standby Status Bit =09 =09 Ali, See below. =09 Mustapha. =09 > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Monday, November 06, 2006 10:05 PM > To: AISSAOUI Mustapha; Luca Martini (lmartini) > Cc: l2vpn@ietf.org > Subject: RE: Active/Standby Status Bit > >=20 > > > -----Original Message----- > > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel.com] > > Sent: Monday, November 06, 2006 5:04 PM > > To: Luca Martini (lmartini) > > Cc: l2vpn@ietf.org > > Subject: Active/Standby Status Bit > > > > Luca, > > Here is the description of the "PW not forwarding" bit as per RFC > > 4447: > > > > "The presence of the lowest bit (PW Not Forwarding) acts only as a > > generic failure indication when there is a link-down event > for which > > none of the other bits apply." > > > > So, we still need a bit to indicate a failure which is not > explicilty > > indicated by the AC and PSN failure bits. A good example of > using this > > bit is when an LSP switches its path and if the new path > MTU does not > > match anymore that signaled in the PW FEC, this bit is used > to signal > > the remote PE. > > There may be other types of failures which could use this bit. > > > With respect to u-PE dual homing applications to two > different n-PE devices, it is still not clear to me why we > cannot use "PW forwarding" > bit (since the MTU for the standby PW is already signaled > between u-PE & standby n-PE). If the problem is its > definition as defined in RFC 4447, then we can generalize its > definition a bit more. However, if there is a more > fundamental problem, then lets elaborate on what that is. =09 MA> The MTU for tunnel LSP can change if the LSP path for the primay PW or the secondary PW changes. If the new MTU value is lower than the one signaled in the PW FEC iterface parameter field, an alarm should be raised since the PE will drop packets on that PW. So, this is a fault condition which we currently signal using the "PW not forwarding bit". =09 When the PW is in standby state, there is no fault or alarms which are generated. It just an indication to the remote PE to preferably not send traffic over that PW. =09 =09 > -Ali > > > I can only conclude that we need a separate bit for the > > "Active/Standby" > > status. > > > > Mustapha. > > > =09 =09 ------_=_NextPart_001_01C702E5.B48621BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Active/Standby Status Bit
 

From: Sasha Vainshtein=20 [mailto:Sasha@AXERRA.com]
Sent: Tuesday, November 07, 2006 = 11:14=20 AM
To: AISSAOUI Mustapha; Ali Sajassi = (sajassi)
Cc:=20 l2vpn@ietf.org
Subject: RE: Active/Standby Status=20 Bit

Mustapha, = Ali and=20 all,
After the yesterday = presentation I have=20 been under impression that, in the case of a dual-homed MTU-s, the = status bit=20 would only sirnal to the "standby" PE-r not to send its BUM traffic = over the=20 standby PW.
 
Ali's text below = seems to suggest=20 that PE-r should not send ANY traffic over the "standby" PW. 
 
Yes, PE-rs = should not send=20 any traffic because known-unicast would never get sent over standby PW = from=20 either far-end MTU-s or local MTU-s. However, based on earlier emails, = it=20 seems like we need to have a new bit anyway because of OAM = indication=20 issue to AC.
 
-Ali
 
Do I miss something? =
Or is it a real difference = in=20 interpretation (between, say, draft-muley and VPLS = dual-homing)?
 
Regards,
          &nbs= p;    =20 Sasha

From: AISSAOUI Mustapha=20 [mailto:Mustapha.Aissaoui@alcatel.com]
Sent: Tue 11/7/2006=20 06:57
To: Ali Sajassi (sajassi)
Cc:=20 l2vpn@ietf.org
Subject: RE: Active/Standby Status=20 Bit

Ali,
See below.

Mustapha.

> = -----Original=20 Message-----
> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
> = Sent:=20 Monday, November 06, 2006 10:05 PM
> To: AISSAOUI Mustapha; Luca = Martini=20 (lmartini)
> Cc: l2vpn@ietf.org
> Subject: RE: = Active/Standby=20 Status Bit
>
> 
>
> > -----Original=20 Message-----
> > From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@al= catel.com]
>=20 > Sent: Monday, November 06, 2006 5:04 PM
> > To: Luca = Martini=20 (lmartini)
> > Cc: l2vpn@ietf.org
> > Subject:=20 Active/Standby Status Bit
> >
> > Luca,
> > = Here is=20 the description of the "PW not forwarding" bit as per RFC
> > = 4447:
> >
> > "The presence of the lowest bit (PW = Not=20 Forwarding) acts only as a
> > generic failure indication = when there=20 is a link-down event
> for which
> > none of the other = bits=20 apply."
> >
> > So, we still need a bit to indicate = a=20 failure which is not
> explicilty
> > indicated by the = AC and=20 PSN failure bits. A good example of
> using this
> > = bit is=20 when an LSP switches its path and if the new path
> MTU does = not
>=20 > match anymore that signaled in the PW FEC, this bit is = used
> to=20 signal
> > the remote PE.
> > There may be other = types of=20 failures which could use this bit.
> >
> With respect = to u-PE=20 dual homing applications to two
> different n-PE devices, it is = still=20 not clear to me why we
> cannot use "PW forwarding"
> bit = (since=20 the MTU for the standby PW is already signaled
> between u-PE = &=20 standby n-PE). If the problem is its
> definition as defined in = RFC=20 4447, then we can generalize its
> definition a bit more. = However, if=20 there is a more
> fundamental problem, then lets elaborate on = what that=20 is.

MA> The MTU for tunnel LSP can change if the LSP path = for the=20 primay PW
or the secondary PW changes. If the new MTU value is = lower than=20 the one
signaled in the PW FEC iterface parameter field, an alarm = should=20 be
raised since the PE will drop packets on that PW. So, this is a=20 fault
condition which we currently  signal using the "PW not=20 forwarding bit".

When the PW is in standby state, there is no = fault or=20 alarms which are
generated. It just an indication to the remote PE = to=20 preferably not send
traffic over that PW.


>=20 -Ali
>
> > I can only conclude that we need a separate = bit for=20 the
> > "Active/Standby"
> > status.
> = >
>=20 > Mustapha.
>=20 >
>

------_=_NextPart_001_01C702E5.B48621BA-- From l2vpn-bounces@ietf.org Wed Nov 08 01:20:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghgmh-0002nZ-FI; Wed, 08 Nov 2006 01:19:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghgmf-0002nU-T1 for l2vpn@ietf.org; Wed, 08 Nov 2006 01:19:37 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghgmd-0002MI-Ao for l2vpn@ietf.org; Wed, 08 Nov 2006 01:19:37 -0500 Received: from shailenderp (203.197.160.130.ill-bgl.static.vsnl.net.in [203.197.160.130] (may be forged)) by mail.tataelxsi.co.in (MOS 3.8.1-FCS) with ESMTP id CBY07631 (AUTH shailender); Wed, 8 Nov 2006 11:49:31 +0530 (IST) From: Shailender Potharaju To: , Date: Wed, 8 Nov 2006 11:48:24 +0530 Message-ID: <008a01c702fd$b2f5c0a0$2178a8c0@shailenderp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090205.45517677.00AE,ss=1,fgs=0, ip=203.197.160.130, so=2006-07-12 23:31:14, dmn=5.2.121/2006-09-27 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: question on VPLS-LDP-DRAFT-01-MIB X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Shailender Potharaju List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hi Tom, I have a doubt on vplsLdpPwBindTable specified under vplsLdpObjects. This table contains two objects vplsLdpPwBindType and vplsLdpPwBindMacAddressLimit. I feel these two elements are not specific to vpls using ldp signaling. Object vplsLdpPwBindType is just service specific, and nothing do with signaling. As singaling using ldp is not different for mesh and spoke, i think the object vplsLdpPwBindType should not be part of vpls-ldp MIB. Similarly the vplsLdpPwBindMacAddressLimit, which is again independent of the signaling being used. For the above mentioned reason I feel these two objects can be part of vplsPwBindTable of vpls-mib. Regards Shailender From l2vpn-bounces@ietf.org Wed Nov 08 15:52:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhuNJ-0000hR-GH; Wed, 08 Nov 2006 15:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhuN0-0000eB-TT; Wed, 08 Nov 2006 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhuN0-0002PL-BI; Wed, 08 Nov 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 258BA3288B; Wed, 8 Nov 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GhuN0-0000yj-0h; Wed, 08 Nov 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 08 Nov 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-bridge-interop-01.txt 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 --NextPart 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 : VPLS Interoperability with CE Bridges Author(s) : A. Sajassi, et al. Filename : draft-ietf-l2vpn-vpls-bridge-interop-01.txt Pages : 19 Date : 2006-11-8 One of the main motivations behind VPLS is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer bridges. If only connectivity among customer IP routers/hosts was desired, then IPLS solution [IPLS] could have been used. The strength of the VPLS solution is that it can provide connectivity to both bridge and non-bridge types of CE devices. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks today or the same level of service that they receive from their Ethernet Service Providers using IEEE 802.1ad-based networks [P802.1ad] (or its predecessor – QinQ-based network). When CE devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. Majority of these issues have currently been addressed in IEEE 802.1ad standard for provider bridges and they need to be addressed for VPLS networks. This draft discusses these issues and wherever possible, the recommended solutions to these issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bridge-interop-01.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-bridge-interop-01.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-bridge-interop-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-8140318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-bridge-interop-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-bridge-interop-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-8140318.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Thu Nov 09 05:38:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7HA-0007Wg-No; Thu, 09 Nov 2006 05:36:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7H9-0007WF-7q for l2vpn@ietf.org; Thu, 09 Nov 2006 05:36:51 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi7H6-0000cq-Mm for l2vpn@ietf.org; Thu, 09 Nov 2006 05:36:51 -0500 Received: from shailenderp (203.197.160.130.ill-bgl.static.vsnl.net.in [203.197.160.130] (may be forged)) by mail.tataelxsi.co.in (MOS 3.8.1-FCS) with ESMTP id CCA02562 (AUTH shailender); Thu, 9 Nov 2006 16:06:38 +0530 (IST) From: Shailender Potharaju To: , "'Thomas D. Nadeau'" Date: Thu, 9 Nov 2006 16:05:30 +0530 Message-ID: <00da01c703ea$c8200240$2178a8c0@shailenderp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.45530434.009E,ss=1,fgs=0, ip=203.197.160.130, so=2006-07-12 23:31:14, dmn=5.2.121/2006-09-27 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: RE: Open Issues on: draft-nadeau-l2vpn-vpls-mib X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Shailender Potharaju List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Hi, Please see my comments inline. Regards Shailender Date: Mon, 6 Nov 2006 13:40:21 -0800 From: "Thomas D. Nadeau" Subject: Open Issues on: draft-nadeau-l2vpn-vpls-mib To: l2vpn@ietf.org Message-ID: <60FB7D3D-5B9A-492B-B3CC-A2E3C495CE33@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed During the meeting I agreed to post these open issues to the list. Please send comments ASAP. If I do not hear comments by November 20 at 12PM GMT, I will *not* make these additions to the document. 1. Should the MIB modules be read-write or read-only? >> I agree with Anil. 2. Add number of attachment circuits per VSI. >> Would be useful to have this object. 3. Add PwBindTable (contains PWs bound to VSI) >> This is table is required. It allows one to create link between VPLS instance and the mesh or spoke VCs. Also I feel it is a good to have one more object to specify whether the PW is a mesh vc or spoke vc. Anil had mentioned this object before. 4. Add VsiPerfTable (contains number of PWs in VSI, numberLearnedMac) >> Would be useful to have this table. It would be good if it can contain other counters such as InFrames, OutFrames, Discards etc(these counters may be per PW and AC). I feel number of PWs and number of ACs can be added to vplsStatusTable mentioned below. VsiPerfTable can just contain statistics per PW/AC. 5. Define vplsOperStatus: current values are unknown, up or down. Propose adding a value 'partialMesh'. Definition of operStatus of VSI: 1 or more PW + 1 or more ACs up == OperStatusUp. >> Would be useful. 6. Proposed addition to vplsStatusTable to indicate the number of Mesh Peers in this VPLS instance. >> Would be useful. 7. vplsSpokePeerCount: proposed addition to vplsStatusTable to indicate the number of Spoke Peers in this VPLS instance. >> Would be useful. 8. The VPLS LDP Qualified Learning/Unqualified Learning mode on the VSI is current read-only. >> I agree with Anil. This could be made optional if write access provided. 9. Get IEEE 802.x objects we must look in the IEEE/IETF Bridge MIB. >> As Bridge MIB doesn't support multiple bridge instances and more over all objects specified in Bridge MIB are not applicable to VSI, may be a new table need to be defined by taking Bridge MIB as reference. 10. vplsMacAging/Learning: these are currently mandatory requirements in the MIB even though they are not part of the standard itself. Remove them and Rely on IEEE/IETF Bridge MIB or put them in an optional group? >> I agree with Anil. 11. vplsACBindTable: proposed table to bind Attachment Circuits to a VPLS >> To add interfaces (ethernet port or vlan) to VPLS instance, AC bind table is required. This table could just contain vplsIndex, ifIndex. 12. Add watermarks for MaxMacAddrs vplsMacLearning, vplsDiscardUnknownDest, forwarding table size. 13. Add vplsPwConfigType that maintains configured auto-discovery method. From l2vpn-bounces@ietf.org Thu Nov 09 06:32:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi88S-0001vh-QC; Thu, 09 Nov 2006 06:31:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi88R-0001vc-7d for l2vpn@ietf.org; Thu, 09 Nov 2006 06:31:55 -0500 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi88O-0000qA-M4 for l2vpn@ietf.org; Thu, 09 Nov 2006 06:31:55 -0500 Received: from jayanta (gateway.tataelxsi.co.in [203.197.169.100]) by mail.tataelxsi.co.in (MOS 3.8.1-FCS) with ESMTP id CCA08861 (AUTH jayanta); Thu, 9 Nov 2006 17:01:39 +0530 (IST) From: Jayanta Tewari To: , "'Thomas D. Nadeau'" Date: Thu, 9 Nov 2006 17:02:34 +0530 Message-ID: <000201c703f2$c119f020$93b8290c@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090203.4553111A.00B0,ss=1,fgs=0, ip=203.197.169.100, so=2006-07-12 23:31:14, dmn=5.2.121/2006-09-27 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: l2vpn@ietf.org Subject: RE: Open Issues on: draft-nadeau-l2vpn-vpls-mib 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 Comments inline with JT. rgds, --Jayanta -----Original Message----- From: anilr@accton.com [mailto:anilr@accton.com] Sent: Tuesday, November 07, 2006 10:39 PM To: Thomas D. Nadeau Cc: l2vpn@ietf.org Subject: Re: Open Issues on: draft-nadeau-l2vpn-vpls-mib Hi Thomas, Please see my comments on the issues. > 1. Should the MIB modules be read-write or read-only? Making appropriate objects read-write is the normal practice; concerns about security can be dealt with by use of SNMPv3, or perhaps in some situations with communities. A read-only MIB won't be very useful. > 2. Add number of attachment circuits per VSI. Could do, although it's the AC binding table that's the real requirement here. PWE3 MIB doesn't provide what we need for VPLS, since VPLS consists of a bunch of PW's as well as bunch of AC's. PWE3 is a point-to-point configuration. > 3. Add PwBindTable (contains PWs bound to VSI) Don't you already have vplsPwBindTable in there?? JT: Was vplsPwBindTable intended to be meant here ? If that is the case,this point was not very clear asto it's addition. Rather the already existing table can be augmented to bring in general attributes e.g BindType,MacaddressLimit that are currently present in vplsLdpPwBindTable and might not be only specific to LDP signalling.This was discussed in another mail from Shailender. > 4. Add VsiPerfTable (contains number of PWs in VSI, numberLearnedMac) Sure, could be useful. > 5. Define vplsOperStatus: current values are unknown, up or down. > Propose adding a value 'partialMesh'. Definition of operStatus of > VSI: 1 or more PW + 1 or more ACs up == OperStatusUp. This is a very useful state which can be used by management to track down network issues. I believe you were asking whether this needs an OAM -- all that's needed here is for software to figure out that underlying PWs/tunnels are broken, based on already existing mechanisms. It's a bit like bubbling up interface status to bridge or router port states. > 6. Proposed addition to vplsStatusTable to indicate the number of > Mesh Peers in this VPLS instance. Just a simple object to tell us how big our VPLS is. A bunch of get-nexts could accomplish the same thing in a more difficult manner. > 7. vplsSpokePeerCount: proposed addition to vplsStatusTable to > indicate the number of Spoke Peers in this VPLS instance. This is useful since we don't have much management hooks about the spokes. Some of which may be QinQ. > 8. The VPLS LDP Qualified Learning/Unqualified Learning mode on the > VSI is current read-only. Currently, there is no qualified/unqualified learning mode in the MIB, far as I can see. Its addition, even if read-only, would be useful. JT:This one should be introduced to get that information. > 9. Get IEEE 802.x objects we must look in the IEEE/IETF Bridge MIB. 802.x? I don't understand this issue. As the main author of the Bridge MIB, I'd be able to help map objects in there with this MIB if people feel that's a useful exercise. You probably also need a "relationship" section up front to indicate which portions of the Bridge MIB would be expected on a pseudowire/VPLS logical port basis. JT: Won't a new table be useful instead of trying to map with some sections of Bridge MIB ? > 10. vplsMacAging/Learning: these are currently mandatory > requirements in the MIB even though they are not part of the standard > itself. Remove them and Rely on IEEE/IETF Bridge MIB or put them in > an optional group? Clearly, I think it's best to leave these optional. JT:Keep them as optional. > 11. vplsACBindTable: proposed table to bind Attachment Circuits to a > VPLS Needed I believe, as mentioned above. There's no other way to configure local ports into the virtual bridge comprising a VPLS instance. Regards, Anil From l2vpn-bounces@ietf.org Mon Nov 13 04:03:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjXg3-0003t2-TR; Mon, 13 Nov 2006 04:00:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjXg0-0003oE-EU for l2vpn@ietf.org; Mon, 13 Nov 2006 04:00:24 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjXdJ-000877-Gw for l2vpn@ietf.org; Mon, 13 Nov 2006 03:57:39 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8N00D31V3TX4@szxga01-in.huawei.com> for l2vpn@ietf.org; Mon, 13 Nov 2006 16:47:53 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8N00CAJV3TW2@szxga01-in.huawei.com> for l2vpn@ietf.org; Mon, 13 Nov 2006 16:47:53 +0800 (CST) Received: from [127.0.0.1] ([10.111.34.184]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8N0026EV3SIX@szxml03-in.huawei.com> for l2vpn@ietf.org; Mon, 13 Nov 2006 16:47:53 +0800 (CST) Date: Mon, 13 Nov 2006 16:47:51 +0800 From: "Abhay D.S" To: l2vpn@ietf.org Message-id: <45583137.10409@acm.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_QWWTp/41VupCpgkcR8wfjg)" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Any Updates to the expired draft-ietf-l2vpn-signaling-08.txt draft ? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: abhayds@acm.org 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. --Boundary_(ID_QWWTp/41VupCpgkcR8wfjg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT hi group, Any updates to the expired draft draft-ietf-l2vpn-signaling-08.txt It expired on Nov 4th. Thank you, Abhay --Boundary_(ID_QWWTp/41VupCpgkcR8wfjg) Content-type: text/x-vcard; charset=utf-8; name=abhayds.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=abhayds.vcf begin:vcard fn:Abhay Rao n:Rao;Abhay email;internet:abhayds@acm.org version:2.1 end:vcard --Boundary_(ID_QWWTp/41VupCpgkcR8wfjg)-- From l2vpn-bounces@ietf.org Mon Nov 13 15:18:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjiEq-0006S7-MB; Mon, 13 Nov 2006 15:17:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjiEp-0006Ru-Ga for l2vpn@ietf.org; Mon, 13 Nov 2006 15:17:03 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjiEn-00018n-QY for l2vpn@ietf.org; Mon, 13 Nov 2006 15:17:03 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 13 Nov 2006 12:01:46 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kADK1k7J020961; Mon, 13 Nov 2006 12:01:46 -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 kADK1kio007374; Mon, 13 Nov 2006 12:01:46 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 12:01:46 -0800 Received: from [10.0.0.187] ([10.21.145.83]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 12:01:45 -0800 In-Reply-To: <45583137.10409@acm.org> References: <45583137.10409@acm.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8765E488-9A30-4D65-B1A8-54894AE8C654@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Date: Mon, 13 Nov 2006 15:01:45 -0500 To: abhayds@acm.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Nov 2006 20:01:45.0741 (UTC) FILETIME=[8BD12BD0:01C7075E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=451; t=1163448106; x=1164312106; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bsd@cisco.com; z=From:=20Bruce=20Davie=20 |Subject:=20Re=3A=20Any=20Updates=20to=20the=20expired=20draft-ietf-l2vpn -signaling-08.txt=20draft=20? |Sender:=20; bh=OCnKXZIzxhotvfAngZ/Odjb/zK8K/aN4JFUfiIzVhcM=; b=EapAb7UD7KUWj69Mo9SIEWt0Il69tyhp0HRhLA4FDVTnR1lEE2+AW7RUsrLvZyxjjSH3wkKW ulclbS/f4EsZtyog5X22zdlDSPD+k6RKpVFNTharXyxK7332ywA20h8T; Authentication-Results: sj-dkim-1; header.From=bsd@cisco.com; dkim=pass (sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: l2vpn@ietf.org Subject: Re: Any Updates to the expired draft-ietf-l2vpn-signaling-08.txt draft ? 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 It is in the RFC editor queue (and therefore not actually expired, no matter what the expiry date in the draft says). The only edits at this point should be, er, editorial. See https://datatracker.ietf.org/public/pidtracker.cgi Bruce On Nov 13, 2006, at 3:47 AM, Abhay D.S wrote: > hi group, > Any updates to the expired draft draft-ietf-l2vpn-signaling-08.txt > It expired on Nov 4th. > Thank you, > Abhay > From l2vpn-bounces@ietf.org Mon Nov 13 21:14:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjnn5-0000r8-Vq; Mon, 13 Nov 2006 21:12:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjnn5-0000r3-EE for l2vpn@ietf.org; Mon, 13 Nov 2006 21:12:47 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjnn3-0002Bg-AV for l2vpn@ietf.org; Mon, 13 Nov 2006 21:12:47 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8P009E17FXJI@szxga02-in.huawei.com> for l2vpn@ietf.org; Tue, 14 Nov 2006 10:11:57 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8P00HWU7FWZ6@szxga02-in.huawei.com> for l2vpn@ietf.org; Tue, 14 Nov 2006 10:11:57 +0800 (CST) Received: from [127.0.0.1] ([10.111.34.184]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8P0081V7FVEK@szxml04-in.huawei.com> for l2vpn@ietf.org; Tue, 14 Nov 2006 10:11:56 +0800 (CST) Date: Tue, 14 Nov 2006 10:11:55 +0800 From: "Abhay D.S" To: l2vpn@ietf.org Message-id: <455925EB.50105@acm.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_ZO3LFwLR13935P4DSTHpBA)" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: Query on draft draft-ietf-l2vpn-vpls-bgp-08 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: abhayds@acm.org 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. --Boundary_(ID_ZO3LFwLR13935P4DSTHpBA) Content-type: multipart/alternative; boundary="Boundary_(ID_QNqqVcxEMBQe/Qrc9shxbA)" --Boundary_(ID_QNqqVcxEMBQe/Qrc9shxbA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT hi Group, In this draft-ietf-l2vpn-vpls-bgp-08 draft, 3.2. Signaling Once discovery is done, each pair of PEs in a VPLS must be able to establish (and tear down) pseudowires to each other, i.e., exchange (and withdraw) demultiplexors. This process is known as signaling. Signaling is also used to transmit certain characteristics of the pseudowires that a PE sets up for a given VPLS. Recall that a demultiplexor is used to distinguish among several different streams of traffic carried over a tunnel, each stream possibly representing a different service. In the case of VPLS, the demultiplexor not only says to which specific VPLS a packet belongs, but also identifies the ingress PE. "*The former information is used for forwarding the packet; the latter information is used for learning MAC addresses.*" The demultiplexor described here is an MPLS label. However, note that the PE-to-PE tunnels need not be MPLS tunnels. The information in quotes latter information is used for learning MAC address , Im not very clear about this , why to lean the macaddress ? Thank you, Abhay --Boundary_(ID_QNqqVcxEMBQe/Qrc9shxbA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT hi Group,

In this draft-ietf-l2vpn-vpls-bgp-08 draft,


3.2.  Signaling

    Once discovery is done, each pair of PEs in a VPLS must be able to
    establish (and tear down) pseudowires to each other, i.e., exchange
    (and withdraw) demultiplexors.  This process is known as signaling.
    Signaling is also used to transmit certain characteristics of the
    pseudowires that a PE sets up for a given VPLS.

    Recall that a demultiplexor is used to distinguish among several
    different streams of traffic carried over a tunnel, each stream
    possibly representing a different service.  In the case of VPLS, the
    demultiplexor not only says to which specific VPLS a packet belongs,
    but also identifies the ingress PE. 

    "The former information is used
    for forwarding the packet; the latter information is used for
    learning MAC addresses."   The demultiplexor described here is an MPLS
    label.  However, note that the PE-to-PE tunnels need not be MPLS
    tunnels.


    The information in quotes latter information is used for learning MAC address , Im not very clear about this , why to lean the macaddress ?

    Thank you,
    Abhay
  


--Boundary_(ID_QNqqVcxEMBQe/Qrc9shxbA)-- --Boundary_(ID_ZO3LFwLR13935P4DSTHpBA) Content-type: text/x-vcard; charset=utf-8; name=abhayds.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=abhayds.vcf begin:vcard fn:Abhay Rao n:Rao;Abhay email;internet:abhayds@acm.org version:2.1 end:vcard --Boundary_(ID_ZO3LFwLR13935P4DSTHpBA)-- From l2vpn-bounces@ietf.org Tue Nov 14 01:10:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjrSn-0000iY-1z; Tue, 14 Nov 2006 01:08:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjrSl-0000ht-AN for l2vpn@ietf.org; Tue, 14 Nov 2006 01:08:03 -0500 Received: from web8805.mail.in.yahoo.com ([203.84.221.14]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjrSj-0001B6-B1 for l2vpn@ietf.org; Tue, 14 Nov 2006 01:08:03 -0500 Received: (qmail 51195 invoked by uid 60001); 14 Nov 2006 06:07:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=gOjpwJiHmnERmN1lRD8m99l17lYqImKt2ZCG4r7nKIvUTnmXqbfUUySgvygT5TMQraBYIsuxark+Jy9uY5uO4X64+j9HC8T4jHSyaA9axg1280ev7Cab/VCSA2aSgAlnLAwVn1vbS6pX23NNI+Flxc6Es3McK5aVIj+/aqElo0U= ; Message-ID: <20061114060757.51190.qmail@web8805.mail.in.yahoo.com> Received: from [202.144.106.188] by web8805.mail.in.yahoo.com via HTTP; Tue, 14 Nov 2006 11:37:57 IST Date: Tue, 14 Nov 2006 11:37:57 +0530 (IST) From: Ramesh Huliyar To: abhayds@acm.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2021998533-1163484477=:49927" X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: l2vpn@ietf.org Subject: Re: Query on draft draft-ietf-l2vpn-vpls-bgp-08 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 --0-2021998533-1163484477=:49927 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Hello Abhay,=0A=0AVPLS is basically a service which emulate LAN for the cus= tomers. It does this by having a point to point pseudowire from every PE to= every other PE which has customer site and L2 switching capabilites for pr= oper forwarding. Hence it is important that when a packet is recieved over = a pseudowire, it should associate the MAC with that psuedowire, so that the= reverse traffic is sent only to that PE.=0A=0ARegards=0ARamesh Huliyar=0A= =0A----- Original Message ----=0AFrom: Abhay D.S =0ATo: l2= vpn@ietf.org=0ASent: Tuesday, 14 November, 2006 7:41:55 AM=0ASubject: Query= on draft draft-ietf-l2vpn-vpls-bgp-08=0A=0A=0A=0A=0A =0A=0Ahi Group,=0A= =0A=0A=0AIn this draft-ietf-l2vpn-vpls-bgp-08 draft, =0A=0A=0A=0A=0A=0A3.2.= Signaling=0A=0A=0A=0A Once discovery is done, each pair of PEs in a VP= LS must be able to=0A=0A establish (and tear down) pseudowires to each o= ther, i.e., exchange=0A=0A (and withdraw) demultiplexors. This process = is known as signaling.=0A=0A Signaling is also used to transmit certain = characteristics of the=0A=0A pseudowires that a PE sets up for a given V= PLS.=0A=0A=0A=0A Recall that a demultiplexor is used to distinguish amon= g several=0A=0A different streams of traffic carried over a tunnel, each= stream=0A=0A possibly representing a different service. In the case of= VPLS, the=0A=0A demultiplexor not only says to which specific VPLS a pa= cket belongs,=0A=0A but also identifies the ingress PE. =0A=0A=0A=0A = "The former information is used=0A=0A for forwarding the packet; the la= tter information is used for=0A=0A learning MAC addresses." The demult= iplexor described here is=0Aan MPLS=0A=0A label. However, note that the= PE-to-PE tunnels need not be MPLS=0A=0A tunnels.=0A=0A=0A=0A=0A=0A T= he information in quotes latter information is used for learning=0AMAC addr= ess , Im not very clear about this , why to lean the macaddress=0A?=0A=0A= =0A=0A Thank you,=0A=0A Abhay=0A=0A =0A=0A=0A=0A=0A=0Abegin:vcard= =0Afn:Abhay Rao=0An:Rao;Abhay =0Aemail;internet:abhayds@acm.org=0Aversion:= 2.1=0Aend:vcard=0A=0A=0A=0A=0A=0A=0A=0A=0A=09=09=0A________________________= __________________________________=0AYahoo! India Answers: Share what you k= now. Learn something new=0Ahttp://in.answers.yahoo.com/ --0-2021998533-1163484477=:49927 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Hello Abhay,

VPLS is basically a service whi= ch emulate LAN for the customers. It does this by having a point to point p= seudowire from every PE to every other PE which has customer site and L2 sw= itching capabilites for proper forwarding. Hence it is important that when = a packet is recieved over a pseudowire, it should associate the MAC with th= at psuedowire, so that the reverse traffic is sent only to that PE.

= Regards
Ramesh Huliyar

----- Original Message ----
Fro= m: Abhay D.S <abhayds@acm.org>
To: l2vpn@ietf.org
Sent: Tuesday= , 14 November, 2006 7:41:55 AM
Subject: Query on draft draft-ietf-l2vpn-= vpls-bgp-08

=0A=0A=0A =0A=0Ahi Group,
=0A
=0AIn this draft-ie= tf-l2vpn-vpls-bgp-08 draft,
=0A
=0A
=0A3.2.  Signaling
= =0A
=0A    Once discovery is done, each pair of PEs in a = VPLS must be able to
=0A    establish (and tear down) pse= udowires to each other, i.e., exchange
=0A    (and withdr= aw) demultiplexors.  This process is known as signaling.
=0A &= nbsp;  Signaling is also used to transmit certain characteristics of t= he
=0A    pseudowires that a PE sets up for a given VPLS.=
=0A
=0A    Recall that a demultiplexor is used to dis= tinguish among several
=0A    different streams of traffi= c carried over a tunnel, each stream
=0A    possibly repr= esenting a different service.  In the case of VPLS, the
=0A &n= bsp;  demultiplexor not only says to which specific VPLS a packet belo= ngs,
=0A    but also identifies the ingress PE.  =0A
=0A    "The former information is used
=0A&nbs= p;   for forwarding the packet; the latter information is used fo= r
=0A    learning MAC addresses."   The demultip= lexor described here is=0Aan MPLS
=0A    label.  How= ever, note that the PE-to-PE tunnels need not be MPLS
=0A  &nb= sp; tunnels.
=0A
=0A
=0A    The information in quot= es latter information is used for learning=0AMAC address , Im not very clea= r about this , why to lean the macaddress=0A?
=0A
=0A  &nbs= p; Thank you,
=0A    Abhay
=0A  
=0A
= =0A
=0A
begin:vcard
fn:Abhay  Rao
n:Rao;Abhay
em= ail;internet:abhayds@acm.org
version:2.1
end:vcard



=0A=09=0A=0A=09=0A=09=09
=0AFind out= what India is talking about on - Yahoo! Answers India
=0A= Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW --0-2021998533-1163484477=:49927-- From l2vpn-bounces@ietf.org Tue Nov 14 04:54:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjuyE-0000mQ-18; Tue, 14 Nov 2006 04:52:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjuyD-0000mE-6x for l2vpn@ietf.org; Tue, 14 Nov 2006 04:52:45 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjuy9-00087K-Uz for l2vpn@ietf.org; Tue, 14 Nov 2006 04:52:45 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8P00JJESQFEY@szxga02-in.huawei.com> for l2vpn@ietf.org; Tue, 14 Nov 2006 17:51:51 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8P006DRSQEQS@szxga02-in.huawei.com> for l2vpn@ietf.org; Tue, 14 Nov 2006 17:51:51 +0800 (CST) Received: from [127.0.0.1] ([10.111.34.184]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8P009G0SQDVM@szxml03-in.huawei.com> for l2vpn@ietf.org; Tue, 14 Nov 2006 17:51:50 +0800 (CST) Date: Tue, 14 Nov 2006 17:51:47 +0800 From: "Abhay D.S" In-reply-to: <20061114060757.51190.qmail@web8805.mail.in.yahoo.com> To: Ramesh Huliyar Message-id: <455991B3.8060104@acm.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_paCVok/5NneHrz8jCvYCpQ)" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) References: <20061114060757.51190.qmail@web8805.mail.in.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: l2vpn@ietf.org Subject: Re: Query on draft draft-ietf-l2vpn-vpls-bgp-08 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: abhayds@acm.org 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. --Boundary_(ID_paCVok/5NneHrz8jCvYCpQ) Content-type: multipart/alternative; boundary="Boundary_(ID_OXaSq+HuIlw1Yya9cKE9KA)" --Boundary_(ID_OXaSq+HuIlw1Yya9cKE9KA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT hi ramesh, The PW learns the MAC address from the Ethernet Frame it received on the Forwarder side. But the draft mentions this in the signaling of de-multiplexors section. Here no MAC address is learnt. Am I right. Abhay Ramesh Huliyar wrote: > Hello Abhay, > > VPLS is basically a service which emulate LAN for the customers. It > does this by having a point to point pseudowire from every PE to every > other PE which has customer site and L2 switching capabilites for > proper forwarding. Hence it is important that when a packet is > recieved over a pseudowire, it should associate the MAC with that > psuedowire, so that the reverse traffic is sent only to that PE. > > Regards > Ramesh Huliyar > > ----- Original Message ---- > From: Abhay D.S > To: l2vpn@ietf.org > Sent: Tuesday, 14 November, 2006 7:41:55 AM > Subject: Query on draft draft-ietf-l2vpn-vpls-bgp-08 > > hi Group, > > In this draft-ietf-l2vpn-vpls-bgp-08 draft, > > > 3.2. Signaling > > Once discovery is done, each pair of PEs in a VPLS must be able to > establish (and tear down) pseudowires to each other, i.e., exchange > (and withdraw) demultiplexors. This process is known as signaling. > Signaling is also used to transmit certain characteristics of the > pseudowires that a PE sets up for a given VPLS. > > Recall that a demultiplexor is used to distinguish among several > different streams of traffic carried over a tunnel, each stream > possibly representing a different service. In the case of VPLS, the > demultiplexor not only says to which specific VPLS a packet belongs, > but also identifies the ingress PE. > > "*The former information is used > for forwarding the packet; the latter information is used for > learning MAC addresses.*" The demultiplexor described here is an > MPLS > label. However, note that the PE-to-PE tunnels need not be MPLS > tunnels. > > > The information in quotes latter information is used for learning > MAC address , Im not very clear about this , why to lean the macaddress ? > > Thank you, > Abhay > > > > begin:vcard > fn:Abhay Rao > n:Rao;Abhay > email;internet:abhayds@acm.org > version:2.1 > end:vcard > > > > ------------------------------------------------------------------------ > Find out what India is talking about on - Yahoo! Answers India > > Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. > Get it NOW > --Boundary_(ID_OXaSq+HuIlw1Yya9cKE9KA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT    hi ramesh,
The PW learns the MAC address from the Ethernet Frame it received on the Forwarder side. But the draft  mentions this in the signaling of de-multiplexors section.
Here no MAC address is learnt.
Am I right.
Abhay

Ramesh Huliyar wrote:
Hello Abhay,

VPLS is basically a service which emulate LAN for the customers. It does this by having a point to point pseudowire from every PE to every other PE which has customer site and L2 switching capabilites for proper forwarding. Hence it is important that when a packet is recieved over a pseudowire, it should associate the MAC with that psuedowire, so that the reverse traffic is sent only to that PE.

Regards
Ramesh Huliyar

----- Original Message ----
From: Abhay D.S <abhayds@acm.org>
To: l2vpn@ietf.org
Sent: Tuesday, 14 November, 2006 7:41:55 AM
Subject: Query on draft draft-ietf-l2vpn-vpls-bgp-08

hi Group,

In this draft-ietf-l2vpn-vpls-bgp-08 draft,


3.2.  Signaling

    Once discovery is done, each pair of PEs in a VPLS must be able to
    establish (and tear down) pseudowires to each other, i.e., exchange
    (and withdraw) demultiplexors.  This process is known as signaling.
    Signaling is also used to transmit certain characteristics of the
    pseudowires that a PE sets up for a given VPLS.

    Recall that a demultiplexor is used to distinguish among several
    different streams of traffic carried over a tunnel, each stream
    possibly representing a different service.  In the case of VPLS, the
    demultiplexor not only says to which specific VPLS a packet belongs,
    but also identifies the ingress PE. 

    "The former information is used
    for forwarding the packet; the latter information is used for
    learning MAC addresses."   The demultiplexor described here is an MPLS
    label.  However, note that the PE-to-PE tunnels need not be MPLS
    tunnels.


    The information in quotes latter information is used for learning MAC address , Im not very clear about this , why to lean the macaddress ?

    Thank you,
    Abhay
  


begin:vcard
fn:Abhay  Rao
n:Rao;Abhay
email;internet:abhayds@acm.org
version:2.1
end:vcard



Find out what India is talking about on - Yahoo! Answers India
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW
--Boundary_(ID_OXaSq+HuIlw1Yya9cKE9KA)-- --Boundary_(ID_paCVok/5NneHrz8jCvYCpQ) Content-type: text/x-vcard; charset=utf-8; name=abhayds.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=abhayds.vcf begin:vcard fn:Abhay Rao n:Rao;Abhay email;internet:abhayds@acm.org version:2.1 end:vcard --Boundary_(ID_paCVok/5NneHrz8jCvYCpQ)-- From l2vpn-bounces@ietf.org Thu Nov 16 18:19:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkqTf-00074q-44; Thu, 16 Nov 2006 18:17:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkpao-0005Rc-8k for l2vpn@ietf.org; Thu, 16 Nov 2006 17:20:22 -0500 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkpaL-0001Lu-KW for l2vpn@ietf.org; Thu, 16 Nov 2006 17:19:55 -0500 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id OAA28818; Thu, 16 Nov 2006 14:19:52 -0800 (PST) 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_01C709CD.563D5F63" Date: Thu, 16 Nov 2006 14:19:52 -0800 Message-ID: <669C86F5E63F194BA1A36C05FFEEC604046FFB07@legolas.rs.riverstonenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-nadeau-l2vpn-vpls-mib Thread-Index: AccJzVYuOBVAQyBBQgyimIkWwx3DSQ== From: "Gopaladasu, Srinivas" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Thu, 16 Nov 2006 18:17:00 -0500 Subject: Comments on draft-nadeau-l2vpn-vpls-mib 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_01C709CD.563D5F63 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have the following few comments on draft-nadeau-l2vpn-vpls-mib: * An example of vplsPwBindTable usage can be given in the module usage = section. * Is there a particular reason vplsStatusTable is a separate table = instead of augmenting vplsConfigTable? * VPLS service is across or between multiple nodes. A mechanism = describing how to group the nodes in a particualre vpls instace would be helpful for a = network management system. * Any attributes regarding other nodes in the vpls instance? Thanks Srini ------_=_NextPart_001_01C709CD.563D5F63 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-nadeau-l2vpn-vpls-mib

Hi,

I have the following few comments on = draft-nadeau-l2vpn-vpls-mib:

* An example of vplsPwBindTable usage = can be given in the module usage section.
* Is there a particular reason = vplsStatusTable is a separate table instead of augmenting = vplsConfigTable?
* VPLS service is across or between = multiple nodes. A mechanism describing how to
  group the nodes in a = particualre vpls instace would be helpful for a network management = system.
* Any attributes regarding other nodes = in the vpls instance?

Thanks
Srini



------_=_NextPart_001_01C709CD.563D5F63-- From l2vpn-bounces@ietf.org Thu Nov 16 18:45:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkquo-0005wj-80; Thu, 16 Nov 2006 18:45:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkqmA-0000Ss-Nu for l2vpn@ietf.org; Thu, 16 Nov 2006 18:36:10 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkqm7-0006Uf-AU for l2vpn@ietf.org; Thu, 16 Nov 2006 18:36:10 -0500 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J8U00896K81JG@firewall.mci.com> for l2vpn@ietf.org; Thu, 16 Nov 2006 23:36:01 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([127.0.0.1]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J8U00CPGK8060@dgismtp01.mcilink.com> for l2vpn@ietf.org; Thu, 16 Nov 2006 23:36:01 +0000 (GMT) Received: from XS344V8061891 ([131.146.38.79]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J8U00C9LK7X13@dgismtp01.mcilink.com> for l2vpn@ietf.org; Thu, 16 Nov 2006 23:36:00 +0000 (GMT) Date: Thu, 16 Nov 2006 18:35:57 -0500 From: Dave McDysan In-reply-to: <60FB7D3D-5B9A-492B-B3CC-A2E3C495CE33@cisco.com> To: "'Thomas D. Nadeau'" , l2vpn@ietf.org Message-id: <0J8U00C9NK8013@dgismtp01.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Thread-index: AccB7Th9biWIlDYsSd+qaOWnR3pksQH6qI7A X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Thu, 16 Nov 2006 18:45:05 -0500 Cc: Subject: RE: Open Issues on: draft-nadeau-l2vpn-vpls-mib 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 Tom, Below are comments you requested. Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, November 06, 2006 4:40 PM > To: l2vpn@ietf.org > Subject: Open Issues on: draft-nadeau-l2vpn-vpls-mib > > > During the meeting I agreed to post these > > open issues to the list. Please send comments > > ASAP. If I do not hear comments by November 20 > > at 12PM GMT, I will *not* make these additions to the > > document. > > > 1. Should the MIB modules be read-write or read-only? * Important. Should be Read-write so an OSS can direcctly control a network element. 2. Add number of attachment circuits per VSI. * Please include. This would be useful as a quick check that the proper number of customers are attached. 3. Add PwBindTable (contains PWs bound to VSI) * Please include. This would be useful as a quick check that the proper number of PWs to interconnect VSIs are configured. This would be important until 4. Add VsiPerfTable (contains number of PWs in VSI, numberLearnedMac) * Important. The number of learned MAC addresses is an important resource. Being able to keep track of it and even compare to a threshold would be a very useful operational function. 5. Define vplsOperStatus: current values are unknown, up or down. Propose adding a value 'partialMesh'. Definition of operStatus of VSI: 1 or more PW + 1 or more ACs up == OperStatusUp. * The definition above appears to refer to "partial mesh" and not "up." See item 3 and 6. Vplsoperstatus should not be "up" unless there is a "full mesh" of PWs between VSIs. 6. Proposed addition to vplsStatusTable to indicate the number of Mesh Peers in this VPLS instance. * Important. See item 5. How would this relate to item 3? 7. vplsSpokePeerCount: proposed addition to vplsStatusTable to indicate the number of Spoke Peers in this VPLS instance. * Please add. 8. The VPLS LDP Qualified Learning/Unqualified Learning mode on the VSI is current read-only. * Please make read-write. 9. Get IEEE 802.x objects we must look in the IEEE/IETF Bridge MIB. * Please provide a reference to this MIB(s). Adding this to the comments would be most helpful. As you mentioned in the meeting, there is not a need to replicate information. 10. vplsMacAging/Learning: these are currently mandatory requirements in the MIB even though they are not part of the standard itself. Remove them and Rely on IEEE/IETF Bridge MIB or put them in an optional group? * See 9. 11. vplsACBindTable: proposed table to bind Attachment Circuits to a VPLS * Important. Useful in provisioning/ diagnostics. 12. Add watermarks for MaxMacAddrs vplsMacLearning, vplsDiscardUnknownDest, forwarding table size. * Important. Would the watermark generate a trap or notification? 13. Add vplsPwConfigType that maintains configured auto-discovery method. * Important. Please add. From l2vpn-bounces@ietf.org Fri Nov 17 09:10:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl4OE-00075Q-5A; Fri, 17 Nov 2006 09:08:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl4OD-00075K-Nm for l2vpn@ietf.org; Fri, 17 Nov 2006 09:08:21 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl4OC-0000f0-A9 for l2vpn@ietf.org; Fri, 17 Nov 2006 09:08:21 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2006 06:08:18 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAHE8JaU010353; Fri, 17 Nov 2006 09:08:19 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAHE8AYr029085; Fri, 17 Nov 2006 09:08:18 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 09:08:17 -0500 Received: from [10.83.15.50] ([10.83.15.50]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 09:08:16 -0500 In-Reply-To: <669C86F5E63F194BA1A36C05FFEEC604046FFB07@legolas.rs.riverstonenet.com> References: <669C86F5E63F194BA1A36C05FFEEC604046FFB07@legolas.rs.riverstonenet.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-2-781701975 Message-Id: From: "Thomas D. Nadeau" Date: Fri, 17 Nov 2006 09:08:15 -0500 To: "Gopaladasu, Srinivas" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Nov 2006 14:08:16.0934 (UTC) FILETIME=[D4090C60:01C70A51] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3619; t=1163772499; x=1164636499; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20Comments=20on=20draft-nadeau-l2vpn-vpls-mib |Sender:=20 |To:=20=22Gopaladasu,=20Srinivas=22=20; bh=IWoqWtJi4d0ESm8YV1J8y5QahNayHqN/quwf+uZFh5s=; b=xjUV0Othl+1SF44CmcrHnaYtTbyk8O3VfAdY+bJdc/3afrjpOlyCcrhGfv32wuasGhO/ZLV3 p6YMftM2mmCf+PHK6vXpaH0xMxeDJFcYDgJlM7lGJbmwfhhsIimDE4rv; Authentication-Results: rtp-dkim-2; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: l2vpn@ietf.org Subject: Re: Comments on draft-nadeau-l2vpn-vpls-mib 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 --Apple-Mail-2-781701975 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 16, 2006, at 5:19 PM, Gopaladasu, Srinivas wrote: > Hi, > > I have the following few comments on draft-nadeau-l2vpn-vpls-mib: > > * An example of vplsPwBindTable usage can be given in the module > usage section. OK. > * Is there a particular reason vplsStatusTable is a separate table > instead of augmenting vplsConfigTable? Because status is different from configuration; it reflects active state vs. configured. > * VPLS service is across or between multiple nodes. A mechanism > describing how to > group the nodes in a particualre vpls instace would be helpful > for a network management system. The VPLS MIB only describes the local VPLS configuration and state on a particular node. It is not intended to be network-wide. > * Any attributes regarding other nodes in the vpls instance? Do you have any examples of what you think needs to be added? --Tom > > Thanks > Srini > > > --Apple-Mail-2-781701975 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Nov 16, 2006, = at 5:19 PM, Gopaladasu, Srinivas wrote:

Hi,

I have the following few comments on = draft-nadeau-l2vpn-vpls-mib:

* An example of vplsPwBindTable usage can be given in the = module usage section.

= OK.

* Is there a particular reason vplsStatusTable is a = separate table instead of augmenting vplsConfigTable? =


Because status is different from = configuration; it reflects active state
vs. = configured.

* VPLS service is across or between multiple nodes. A = mechanism describing how to
=A0= group the nodes in a particualre vpls instace would be helpful for a = network management system.


The VPLS = MIB only describes the local VPLS configuration and state
on a = particular node. It is not intended to be network-wide.

* Any attributes = regarding other nodes in the vpls instance? =

Do you have any examples of what = you think needs to be added?

= --Tom

=
Thanks
Srini



=

= --Apple-Mail-2-781701975-- From l2vpn-bounces@ietf.org Fri Nov 17 18:44:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlDMT-0004Ad-KI; Fri, 17 Nov 2006 18:43:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlDMR-0004AY-U2 for l2vpn@ietf.org; Fri, 17 Nov 2006 18:43:07 -0500 Received: from [63.113.148.10] (helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlDMQ-0002fX-Fx for l2vpn@ietf.org; Fri, 17 Nov 2006 18:43:07 -0500 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id PAA26663; Fri, 17 Nov 2006 15:42:38 -0800 (PST) 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_01C70AA2.10709786" Date: Fri, 17 Nov 2006 15:42:38 -0800 Message-ID: <669C86F5E63F194BA1A36C05FFEEC60404B900AB@legolas.rs.riverstonenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-nadeau-l2vpn-vpls-mib Thread-Index: AccKUdn51r+HaMcgQnGeO/6jHqpVDwATd+7y References: <669C86F5E63F194BA1A36C05FFEEC604046FFB07@legolas.rs.riverstonenet.com> From: "Gopaladasu, Srinivas" To: "Thomas D. Nadeau" X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: l2vpn@ietf.org Subject: RE: Comments on draft-nadeau-l2vpn-vpls-mib 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_01C70AA2.10709786 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgY29tbWVudHMgYmVsb3c6DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CkZyb206IFRob21hcyBELiBOYWRlYXUgW21haWx0bzp0bmFkZWF1QGNpc2NvLmNvbV0NClNlbnQ6 IEZyaSAxMS8xNy8yMDA2IDY6MDggQU0NClRvOiBHb3BhbGFkYXN1LCBTcmluaXZhcw0KQ2M6IGwy dnBuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogQ29tbWVudHMgb24gZHJhZnQtbmFkZWF1LWwydnBu LXZwbHMtbWliDQoNCg0KDQpPbiBOb3YgMTYsIDIwMDYsIGF0IDU6MTkgUE0sIEdvcGFsYWRhc3Us IFNyaW5pdmFzIHdyb3RlOg0KDQoNCglIaSwgDQoNCglJIGhhdmUgdGhlIGZvbGxvd2luZyBmZXcg Y29tbWVudHMgb24gZHJhZnQtbmFkZWF1LWwydnBuLXZwbHMtbWliOiANCg0KCSogQW4gZXhhbXBs ZSBvZiB2cGxzUHdCaW5kVGFibGUgdXNhZ2UgY2FuIGJlIGdpdmVuIGluIHRoZSBtb2R1bGUgdXNh Z2Ugc2VjdGlvbi4gDQoJDQoNCk9LLg0KDQoJKiBJcyB0aGVyZSBhIHBhcnRpY3VsYXIgcmVhc29u IHZwbHNTdGF0dXNUYWJsZSBpcyBhIHNlcGFyYXRlIHRhYmxlIGluc3RlYWQgb2YgYXVnbWVudGlu ZyB2cGxzQ29uZmlnVGFibGU/IA0KCQ0KDQoNCkJlY2F1c2Ugc3RhdHVzIGlzIGRpZmZlcmVudCBm cm9tIGNvbmZpZ3VyYXRpb247IGl0IHJlZmxlY3RzIGFjdGl2ZSBzdGF0ZQ0KdnMuIGNvbmZpZ3Vy ZWQuDQogDQpBcyBsb25nIGFzIHRoZXJlIGlzIG9uZSB0byBvbmUgbWFwcGluZyBvZiBlbnRyaWVz IHdpdGggc2FtZSBpbmRleCwgSSBhbHdheXMgZm91bmQgaXQgYmV0dGVyIHRvIGF1Z21lbnQgdGhl IHRhYmxlLiANCg0KDQoJKiBWUExTIHNlcnZpY2UgaXMgYWNyb3NzIG9yIGJldHdlZW4gbXVsdGlw bGUgbm9kZXMuIEEgbWVjaGFuaXNtIGRlc2NyaWJpbmcgaG93IHRvIA0KCSAgZ3JvdXAgdGhlIG5v ZGVzIGluIGEgcGFydGljdWFscmUgdnBscyBpbnN0YWNlIHdvdWxkIGJlIGhlbHBmdWwgZm9yIGEg bmV0d29yayBtYW5hZ2VtZW50IHN5c3RlbS4gDQoJDQoNCg0KVGhlIFZQTFMgTUlCIG9ubHkgZGVz Y3JpYmVzIHRoZSBsb2NhbCBWUExTIGNvbmZpZ3VyYXRpb24gYW5kIHN0YXRlDQpvbiBhIHBhcnRp Y3VsYXIgbm9kZS4gSXQgaXMgbm90IGludGVuZGVkIHRvIGJlIG5ldHdvcmstd2lkZS4NCiANCkkg dGhvdWdodCwgaWYgdGhpcyBtaWIgc2VydmVzIHRoZSBwdXJwb3NlIG9mIGlkZW50aWZ5aW5nIG5v ZGVzIHBhcnQgb2Ygc2FtZSB2cGxzIGluc3RhbmNlL25ldHdvcmsgd291bGQgYmUgZ29vZCB0byBt YW5hZ2UgYSB2cGxzIG5ldHdvcmsgYXMgd2VsbC4NCg0KCSogQW55IGF0dHJpYnV0ZXMgcmVnYXJk aW5nIG90aGVyIG5vZGVzIGluIHRoZSB2cGxzIGluc3RhbmNlPyANCgkNCg0KRG8geW91IGhhdmUg YW55IGV4YW1wbGVzIG9mIHdoYXQgeW91IHRoaW5rIG5lZWRzIHRvIGJlIGFkZGVkPw0KIA0KSnVz dCBhIHRob3VnaHQsIG1heSBiZSBwZWVyIElQL01BQyBhZGRyZXNzZXMgb2YgYSB2cGxzIG5vZGU/ DQogDQpUaGFua3MNClNyaW5pDQoNCiANCi0tVG9tDQoNCg0KCQ0KCVRoYW5rcyANCglTcmluaSAN Cg0KDQoNCg0K ------_=_NextPart_001_01C70AA2.10709786 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8SFRNTD48Qk9EWSBzdHlsZT0iV09SRC1XUkFQOiBicmVhay13b3JkIiAgID4K PERJViBpZD1pZE9XQVJlcGx5VGV4dDgzMTA5IGRpcj1sdHI+CjxESVYgZGlyPWx0cj48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPk15IGNvbW1lbnRzIApiZWxvdzo8L0ZPTlQ+ PC9ESVY+PC9ESVY+CjxESVYgZGlyPWx0cj48QlI+CjxIUiB0YWJJbmRleD0tMT4KPEZPTlQgZmFj ZT1UYWhvbWEgc2l6ZT0yPjxCPkZyb206PC9CPiBUaG9tYXMgRC4gTmFkZWF1IApbbWFpbHRvOnRu YWRlYXVAY2lzY28uY29tXTxCUj48Qj5TZW50OjwvQj4gRnJpIDExLzE3LzIwMDYgNjowOCBBTTxC Uj48Qj5Ubzo8L0I+IApHb3BhbGFkYXN1LCBTcmluaXZhczxCUj48Qj5DYzo8L0I+IGwydnBuQGll dGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogCkNvbW1lbnRzIG9uIGRyYWZ0LW5hZGVhdS1s MnZwbi12cGxzLW1pYjxCUj48L0ZPTlQ+PEJSPjwvRElWPgo8RElWPjxCUj4KPERJVj4KPERJVj5P biBOb3YgMTYsIDIwMDYsIGF0IDU6MTkgUE0sIEdvcGFsYWRhc3UsIFNyaW5pdmFzIHdyb3RlOjwv RElWPjxCUiAKY2xhc3M9QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZT4KPEJMT0NLUVVPVEUgdHlw ZT0iY2l0ZSI+CiAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SGksPC9GT05UPiA8L1A+CiAg PFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SSBoYXZlIHRoZSBmb2xsb3dpbmcgZmV3IGNvbW1l bnRzIG9uIAogIGRyYWZ0LW5hZGVhdS1sMnZwbi12cGxzLW1pYjo8L0ZPTlQ+IDwvUD4KICA8UD48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4qIEFuIGV4YW1wbGUgb2YgdnBsc1B3QmluZFRhYmxlIHVz YWdlIGNhbiBiZSBnaXZlbiAKICBpbiB0aGUgbW9kdWxlIHVzYWdlIHNlY3Rpb24uPC9GT05UPiA8 QlI+PC9QPjwvQkxPQ0tRVU9URT4KPERJVj48U1BBTiBjbGFzcz1BcHBsZS10YWItc3BhbiBzdHls ZT0iV0hJVEUtU1BBQ0U6IHByZSI+PC9TUEFOPk9LLjwvRElWPgo8QkxPQ0tRVU9URSB0eXBlPSJj aXRlIj4KICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4qIElzIHRoZXJlIGEgcGFydGljdWxh ciByZWFzb24gdnBsc1N0YXR1c1RhYmxlIGlzIGEgCiAgc2VwYXJhdGUgdGFibGUgaW5zdGVhZCBv ZiBhdWdtZW50aW5nIHZwbHNDb25maWdUYWJsZT88L0ZPTlQ+IAo8QlI+PC9QPjwvQkxPQ0tRVU9U RT4KPERJVj48QlIgY2xhc3M9a2h0bWwtYmxvY2stcGxhY2Vob2xkZXI+PC9ESVY+PFNQQU4gY2xh c3M9QXBwbGUtdGFiLXNwYW4gCnN0eWxlPSJXSElURS1TUEFDRTogcHJlIj48L1NQQU4+QmVjYXVz ZSBzdGF0dXMgaXMgZGlmZmVyZW50IGZyb20gY29uZmlndXJhdGlvbjsgCml0IHJlZmxlY3RzIGFj dGl2ZSBzdGF0ZTwvRElWPgo8RElWPnZzLiBjb25maWd1cmVkLjwvRElWPgo8RElWPiZuYnNwOzwv RElWPgo8RElWPkFzIGxvbmcgYXMgdGhlcmUgaXMgb25lIHRvIG9uZSBtYXBwaW5nIG9mIGVudHJp ZXMgd2l0aCBzYW1lIGluZGV4LCBJIGFsd2F5cyAKZm91bmQgaXQgYmV0dGVyIHRvIGF1Z21lbnQg dGhlIHRhYmxlLiA8QlI+PC9ESVY+CjxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPgogIDxQPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPiogVlBMUyBzZXJ2aWNlIGlzIGFjcm9zcyBvciBiZXR3ZWVuIG11 bHRpcGxlIG5vZGVzLiAKICBBIG1lY2hhbmlzbSBkZXNjcmliaW5nIGhvdyB0bzwvRk9OVD4gPEJS PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyBncm91cCAKICB0aGUgbm9kZXMgaW4gYSBw YXJ0aWN1YWxyZSB2cGxzIGluc3RhY2Ugd291bGQgYmUgaGVscGZ1bCBmb3IgYSBuZXR3b3JrIAog IG1hbmFnZW1lbnQgc3lzdGVtLjwvRk9OVD4gPEJSPjwvUD48L0JMT0NLUVVPVEU+CjxESVY+PEJS IGNsYXNzPWtodG1sLWJsb2NrLXBsYWNlaG9sZGVyPjwvRElWPgo8RElWPjxTUEFOIGNsYXNzPUFw cGxlLXRhYi1zcGFuIHN0eWxlPSJXSElURS1TUEFDRTogcHJlIj48L1NQQU4+VGhlIFZQTFMgTUlC IApvbmx5IGRlc2NyaWJlcyB0aGUgbG9jYWwgVlBMUyBjb25maWd1cmF0aW9uIGFuZCBzdGF0ZTwv RElWPgo8RElWPm9uIGEgcGFydGljdWxhciBub2RlLiBJdCBpcyBub3QgaW50ZW5kZWQgdG8gYmUg bmV0d29yay13aWRlLjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkkgdGhvdWdodCwgaWYm bmJzcDt0aGlzIG1pYiBzZXJ2ZXMgdGhlIHB1cnBvc2Ugb2YgaWRlbnRpZnlpbmcgbm9kZXMgcGFy dCBvZiAKc2FtZSB2cGxzIGluc3RhbmNlL25ldHdvcmsgd291bGQgYmUgZ29vZCB0byBtYW5hZ2Ug YSB2cGxzIG5ldHdvcmsgYXMgd2VsbC48L0RJVj4KPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+CiAg PFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+KiBBbnkgYXR0cmlidXRlcyByZWdhcmRpbmcgb3Ro ZXIgbm9kZXMgaW4gdGhlIHZwbHMgCiAgaW5zdGFuY2U/PC9GT05UPiA8QlI+PC9QPjwvQkxPQ0tR VU9URT4KPERJVj48U1BBTiBjbGFzcz1BcHBsZS10YWItc3BhbiBzdHlsZT0iV0hJVEUtU1BBQ0U6 IHByZSI+PC9TUEFOPkRvIHlvdSBoYXZlIGFueSAKZXhhbXBsZXMgb2Ygd2hhdCB5b3UgdGhpbmsg bmVlZHMgdG8gYmUgYWRkZWQ/PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SnVzdCBhIHRo b3VnaHQsIG1heSBiZSBwZWVyIElQL01BQyBhZGRyZXNzZXMgb2YgYSB2cGxzIG5vZGU/PC9ESVY+ CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+VGhhbmtzPC9ESVY+CjxESVY+U3Jpbmk8L0RJVj4KPERJ Vj48QlIgY2xhc3M9a2h0bWwtYmxvY2stcGxhY2Vob2xkZXI+Jm5ic3A7PC9ESVY+CjxESVY+PFNQ QU4gY2xhc3M9QXBwbGUtdGFiLXNwYW4gc3R5bGU9IldISVRFLVNQQUNFOiBwcmUiPjwvU1BBTj4t LVRvbTwvRElWPjxTUEFOIApjbGFzcz1BcHBsZS10YWItc3BhbiBzdHlsZT0iV0hJVEUtU1BBQ0U6 IHByZSI+PC9TUEFOPgo8RElWPjxCUj48L0RJVj4KPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+CiAg PFA+PEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlRoYW5rczwvRk9OVD4gPEJSPjxGT05UIGZh Y2U9QXJpYWwgCiAgc2l6ZT0yPlNyaW5pPC9GT05UPiA8L1A+PEJSPjxCUj48L0JMT0NLUVVPVEU+ PEJSPjwvRElWPjwvQk9EWT48L0hUTUw+ ------_=_NextPart_001_01C70AA2.10709786-- From l2vpn-bounces@ietf.org Mon Nov 20 04:47:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5jN-000854-Id; Mon, 20 Nov 2006 04:46:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5jN-00084z-2a for l2vpn@ietf.org; Mon, 20 Nov 2006 04:46:25 -0500 Received: from [143.209.238.162] (helo=audl953.usa.alcatel.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gm5jL-0006uQ-JW for l2vpn@ietf.org; Mon, 20 Nov 2006 04:46:24 -0500 Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id kAK9kMts030528; Mon, 20 Nov 2006 03:46:22 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.8]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 20 Nov 2006 03:46:22 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 20 Nov 2006 03:46:20 -0600 Message-ID: <67FBA6A55FF15B46B8B572062529D26A10B070@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <60FB7D3D-5B9A-492B-B3CC-A2E3C495CE33@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open Issues on: draft-nadeau-l2vpn-vpls-mib Thread-Index: AccB+1QxEmeBru+oQPuAC4csS/nurAKiNnMQ From: "MEDIRATTA Rohit" To: "Thomas D. Nadeau" , X-OriginalArrivalTime: 20 Nov 2006 09:46:22.0072 (UTC) FILETIME=[BC7CA780:01C70C88] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: RE: Open Issues on: draft-nadeau-l2vpn-vpls-mib 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 Tom, Please see my comments inline with Rm] -Rohit 1. Should the MIB modules be read-write or read-only? Read-write would be more beneficial. 2. Add number of attachment circuits per VSI. Rm] Useful along with the AC table. 3. Add PwBindTable (contains PWs bound to VSI) 4. Add VsiPerfTable (contains number of PWs in VSI, numberLearnedMac) Rm] If we have a count of number of mesh/spoke peers (as below), do we need a count for total number of PWs ? We could add the numLearntMac's in the vplsStatus table. 5. Define vplsOperStatus: current values are unknown, up or down. =20 Propose adding a value 'partialMesh'. Definition of operStatus of VSI: 1 or more PW + 1 or more ACs up =3D=3D OperStatusUp. Rm] The present definition would have to be changed to accommodate H-Vpls.=20 6. Proposed addition to vplsStatusTable to indicate the number of Mesh Peers in this VPLS instance. Rm] I agree 7. vplsSpokePeerCount: proposed addition to vplsStatusTable to =20 indicate the number of Spoke Peers in this VPLS instance. Rm] I agree 8. The VPLS LDP Qualified Learning/Unqualified Learning mode on the VSI is current read-only. 9. Get IEEE 802.x objects we must look in the IEEE/IETF Bridge MIB. Rm] We probably need to add a table in Vpls-MIB. 10. vplsMacAging/Learning: these are currently mandatory requirements in the MIB even though they are not part of the standard itself. Remove them and Rely on IEEE/IETF Bridge MIB or put them in an optional group? 11. vplsACBindTable: proposed table to bind Attachment Circuits to a VPLS Rm] I agress 12. Add watermarks for MaxMacAddrs vplsMacLearning, vplsDiscardUnknownDest, forwarding table size. 13. Add vplsPwConfigType that maintains configured auto-discovery method. Rm] This already exists. From l2vpn-bounces@ietf.org Sat Nov 25 10:29:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnzRj-0007Gc-EU; Sat, 25 Nov 2006 10:28:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnzRh-0007GO-VW; Sat, 25 Nov 2006 10:28:01 -0500 Received: from mx2.lb.mrv.com ([66.43.110.200] helo=chmailqsrv.int.mrv.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnzRf-0008V3-9x; Sat, 25 Nov 2006 10:28:01 -0500 Received: from chmailqsrv.int.mrv.com (127.0.0.1) by chmailqsrv.int.mrv.com (MlfMTA v3.2r1b3) id hd1gd20171sp; Sat, 25 Nov 2006 07:27:10 -0800 (envelope-from ) Received: from chmailsrv.int.mrv.com ([192.168.11.19]) by chmailqsrv.int.mrv.com (SonicWALL 5.0.0.8239) with ESMTP; Sat, 25 Nov 2006 07:27:10 -0800 Received: from zeus.yok.int.mrv.com ([172.21.9.11]) by chmailsrv.int.mrv.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Nov 2006 07:27:55 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C710A6.43C069FB" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 25 Nov 2006 17:26:45 +0200 Message-ID: <685D66DF6DB563459D23ECD8B30C73A40CD41C@zeus.yok.int.mrv.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?windows-1255?Q?BUG_in_RFC_4379_=28_MPLS_Ping_/_Traceroute=29_-_or_maybe?= =?windows-1255?Q?_not_=96_please_enlighten_me?= Thread-Index: AccQph2T/seaIBlLQ2OaC87LSWoBYQ== From: "Asaf Henig" To: , , X-OriginalArrivalTime: 25 Nov 2006 15:27:55.0267 (UTC) FILETIME=[4772CD30:01C710A6] X-Mlf-Version: 5.0.0.8239 X-Mlf-UniqueId: o200611251527090072636 X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: Alon Michaeli Subject: =?windows-1255?q?BUG_in_RFC_4379_=28_MPLS_Ping_/_Traceroute=29_-?= =?windows-1255?q?_or_maybe_not_=96_please_enlighten_me?= 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_01C710A6.43C069FB Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Section 4.4.1 in the RFC describes an algorithm for Fec Validation, i.e. = a procedure to verify the compatibility between the incoming label and = the FEC tlv that describes it.=20 However, it appears that the RFC writers didn=92t notice that there are = cases in which there is no 1 to 1 compatibility between the incoming = labels and FECs. =20 Specifically let me point out the simple LDP ipv4 FEC tlv which includes = only a simple prefix to describe any FEC. An LSR advertising the = networks to which it is the egress router may advertise different labels = to the same network to different LSRs with which it has opened an LDP = sessions. This is especially true to LSRs working in Global label space. = In general it appears that the RFC writers didn=92t take into = consideration the issue of different LDP sessions. Note that although = the algorithm described in section 4.4.1 also asks to validate the = interface through which the echo request packet arrived, this interface = is not an indicator for the LDP session (think of several LSRs found in = the same network and are connected by a bridge).=20 =20 It is important to note that there are some FEC TLVs in which this issue = is not relevant. An example can be the RSVP ipv4 FEC which includes = extended-tunnel-id that marks the ping originator and thus have a full 1 = to 1 compatibility between the FEC and the incoming label. =20 =20 When an incoming mpls echo request packet, with an LDP ipv4 FEC, reaches = an egress LSR (LER), this LSR needs to match between the incoming packet = and one of his opened LDP sessions. There are several options to solve = this issue: one would be to change RFC 4379 and to add to the LDP ipv4 = FEC described in the RFC a ping originator address (this address should = be the originator=92s transport address). Another option can be to = conclude the LDP session from the source ip address of the echo request = packet. The last option in my opinion shouldn=92t be the preferred one = since it requires matching between the incoming packet and the = address-list TLV used in the LDP protocol. However even this last option = should have been discussed in the RFC.=20 =20 Please enlighten me with your thoughts. Did I miss something in the RFC.=20 Regards Asaf Henig=20 MRV communications. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C710A6.43C069FB Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
=0A=

Section 4.4.1 in the RFC describes an algorithm for Fec = Validation, i.e. =0A= a procedure to verify the compatibility between the incoming label and = the FEC =0A= tlv that describes it.

=0A=

However, it appears that the RFC writers didn=92t notice that = there are =0A= cases in which there is no 1 to 1 compatibility between the incoming = labels and =0A= FECs.

=0A=

 

=0A=

Specifically let me point out the simple LDP ipv4 FEC tlv which = includes =0A= only a simple prefix to describe any FEC. An LSR advertising the = networks to =0A= which it is the egress router may advertise different labels to the same = network =0A= to different LSRs with which it has opened an LDP sessions. This is = especially =0A= true to LSRs working in Global label space.

=0A=

In general it appears that the RFC writers didn=92t take into = consideration =0A= the issue of different LDP sessions. Note that although the algorithm = described =0A= in section 4.4.1 also asks to validate the interface through which the = echo =0A= request packet arrived, this interface is not an indicator for the LDP = session =0A= (think of several LSRs found in the same network and are connected by a = bridge). =0A=

=0A=

 

=0A=

It is important to note that there are some FEC = TLVs in =0A= which this issue is not relevant. An example can be the RSVP ipv4 FEC = which =0A= includes extended-tunnel-id that marks the ping originator and thus have = a full =0A= 1 to 1 compatibility between the FEC and the incoming label.  

=0A=

 

=0A=

When an incoming mpls echo request packet, with an LDP ipv4 = FEC, reaches =0A= an egress LSR (LER), this LSR needs to match between the incoming packet = and one =0A= of his opened LDP sessions. There are several options to solve this = issue: one =0A= would be to change RFC 4379 and to add to the LDP ipv4 FEC described in = the RFC =0A= a ping originator address (this address should be the originator=92s = transport =0A= address).  Another option = can be to =0A= conclude the LDP session from the source ip address of the echo request = packet. =0A= The last option in my opinion shouldn=92t be the preferred one since it = requires =0A= matching between the incoming packet and the address-list TLV used in = the LDP =0A= protocol. However even this last option should have been discussed in = the RFC. =0A=

=0A=

 

=0A=

Please enlighten me with your thoughts.

=0A=

Did I miss something in the RFC.

=0A=

Regards

=0A=

Asaf Henig

=0A=

MRV communications.  =0A=

=0A=

 

=0A=

 

=0A=

 

=0A=

 

=0A=

 

=0A=

  =0A=

=0A=

 

=0A=

 

=0A=

 

------_=_NextPart_001_01C710A6.43C069FB--