From l2vpn-bounces@ietf.org Thu Dec 01 18:50:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhyBp-0003po-Su; Thu, 01 Dec 2005 18:50:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhyBf-0003l7-7y; Thu, 01 Dec 2005 18:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03048; Thu, 1 Dec 2005 18:49:16 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhyWE-0003iM-K2; Thu, 01 Dec 2005 19:11:19 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhyBd-00048j-Vd; Thu, 01 Dec 2005 18:50:01 -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: Thu, 01 Dec 2005 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mcast-00.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: , Sender: l2vpn-bounces@ietf.org 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 : Multicast in VPLS Author(s) : R. Aggarwal, et al. Filename : draft-ietf-l2vpn-vpls-mcast-00.txt Pages : 20 Date : 2005-12-1 This document describes a solution for overcoming the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the backbone can be used to carry traffic belonging only to a specified set of one or more multicast groups from one or more VPLSs are also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-vpls-mcast-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-vpls-mcast-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2005-12-1163056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-mcast-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-mcast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-1163056.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Thu Dec 01 22:03:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei1DL-0003yD-Bd; Thu, 01 Dec 2005 22:03:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei1DJ-0003xd-Fq; Thu, 01 Dec 2005 22:03:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29031; Thu, 1 Dec 2005 22:03:09 -0500 (EST) Received: from hostreea1.alcatel.com ([143.209.238.161] helo=audl951.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei1Xu-0004YO-R4; Thu, 01 Dec 2005 22:25:15 -0500 Received: from alcatelxp ([172.22.187.74]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id jB233k7b029633; Thu, 1 Dec 2005 21:03:46 -0600 From: "Suresh Boddapati" To: "'Yakov Rekhter'" , "'Shane Amante'" Date: Thu, 1 Dec 2005 19:04:58 -0800 Message-ID: <02da01c5f6ed$2e28b930$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <200511301451.jAUEpj506611@merlot.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, pim@ietf.org Subject: RE: PIM Snooping 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org > > Since there was little, if any, consensus in Vancouver as to the best > > direction forward with the PIM snooping work, we would like to hear from > > the WG: > > A) Should we require disabling Join Suppression on CE's? > > B) Should we NOT require disabling Join Suppression on CE's, thereby > > making the PE a more active element in PIM procedures in a VPLS? > > C) Other, more palatable, suggestions? > > > > Please answer the above questions and feel free to add color commentary > > as to other issues or concerns not identified above. > > Wrt (B) what are the implications of making the PE a "more active > element" on the externally visible behavior (where by "externall > visible" I mean visible to a VPLS customer) ? > The implications are that a customer router connected to a PE will not necessarily see the same packet that its counterpart at another PE generated. The packets may be modified, consumed and/or generated by PEs on behalf of customer routers. > Specifically would a VPLS customer be able to distinguish between > the cases where a PE operates as specified today, and making the > PE "a more active element in PIM procedures in a VPLS" ? > Not necessarily. The whole idea of making the PE an active element would be to ensure that nothing has to change in C routers, the multicast states will be built as before. The only difference is that the C routers may end up seeing different packets than what they used to before. Let us consider what a "more active element" in this context means. Consider an example where there are three PEs: PE1, PE2, PE3. PE1 has the upstream router U and a downstream router D1 connected to it on the same AC. PE2 has a downstream router D2. PE3 has a downstream router D3. In order for snooping to build states correctly: 1)If D2 sends a Join to U, we don't want D3 to see the Join because if it did, then it would suppress its Join and the pseudowire PE1-PE3 will not receive the traffic (since PE1 never saw a Join on PE1-PE3). This would not be a problem if all C routers disabled Join suppression and did explicit tracking. 2)If D2 sends a Prune to U, we want D3 to see the Prune so that it can override it. Same would apply if D1 sent a Prune to U; you want D2 and D3 to see it so that they can override the Prune. Again, this would not be a problem if Join suppression was disabled. It would be easy to solve the problem without requiring disabling of Join suppression if Joins and Prunes were separate messages - just unicast Joins (by modifying the dest mac to the upstream router's mac) and multicast Prunes. But Joins and Prunes can be in the SAME JP message and that's where it becomes more complicated. If we want to preserve the transparency to the C routers (i.e. not requiring them to disable Join suppression), then the PEs will have to do something like: 1) Consume the Join/Prune messages seen on the AC. This means we might have to consume other PIM packets (Hello, Assert, BSM) and then send them so that the ordering between the messages is preserved. (An Assert sent to an upstream router that does not have a downstream state will be dropped, for example, since the Join came after the Assert when actually it was sent before the Assert). 2) Separate the Joins from the Prunes: This means the PE is generating packets on behalf of the C routers. 3) Unicast joins to the upstream router and multicast the Prunes to all routers. There may be other ways of doing this, but essentially, we are trying to make the PEs make up for Join Suppression not being disabled in the VPLS by simulating it. The downside is we are no longer plain "snooping", we are also an active participant. Of course, there are also some benefits to doing this. Since the PE is assuming a Proxy role, if it has already signaled a Join for an (S,G) on a PW (due to having received one on an AC), it need not signal Joins for the same state if they arrive on other ACs, as long as it keeps track of how many ACs sent the Joins. This way, the number of Join states sent on the PWs is also reduced. So the question boils down to: Is this the direction we want to go in i.e. have the PEs assume a Proxy role so that the C routers do not have to change OR should we require C routers to disable Join suppression and do explicit tracking. There is a tradeoff here: 1) If we want to preserve the transparency to the C routers (a reasonable goal indeed), the proxy procedures might be perceived by some as "hacks". It was said so in the previous IETF at Paris. But that is the cost of preserving the transparency. 2) If we want to keep the snooping procedures straightforward without any modifications to the C packets, then the C routers have to disable Join suppression. It was suggested at the Vancover IETF that this is an unreasonable requirement since most routers do not support Explicit tracking today. This is a good point too. Both the approaches have merits and demerits. We would like opinions on what the WGs think is the best approach. Thanks. Suresh From l2vpn-bounces@ietf.org Fri Dec 02 01:20:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei4HC-0007ZU-In; Fri, 02 Dec 2005 01:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei4HB-0007ZM-Km; Fri, 02 Dec 2005 01:20:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12069; Fri, 2 Dec 2005 01:19:22 -0500 (EST) Received: from mail1.optus.com.au ([203.13.126.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei4bm-0001GP-9z; Fri, 02 Dec 2005 01:41:29 -0500 Received: from CHOW2KE003.optus.com.au ([161.43.32.10]) by mail1.optus.com.au with InterScan Messaging Security Suite; Fri, 02 Dec 2005 17:04:19 +1100 Received: from shqw2ke001.optus.com.au ([10.17.224.13]) by CHOW2KE003.optus.com.au with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 17:04:19 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Dec 2005 17:04:15 +1100 Message-ID: <799B0CDA650143429C5EA103965B59F8011B6061@shqw2ke001.optus.com.au> Thread-Topic: PIM Snooping Thread-Index: AcX27fZRR9Qm51GESG2EM9pVloTnBQAF4MKA From: "Fil Dickinson" To: "Suresh Boddapati" , "Yakov Rekhter" , "Shane Amante" X-OriginalArrivalTime: 02 Dec 2005 06:04:19.0351 (UTC) FILETIME=[3BB50270:01C5F706] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pim@ietf.org Subject: RE: PIM Snooping 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Suresh. My opinion. I would like any "hacks", "tweaks" or "work arounds" to occur on the CE router. This is because as a provider I want to eliminate as many non-standard elements from my edge and core as possible, having them taken care of further out where I have more flexibility in development [and diminished responsibility for support;-)]. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Suresh Boddapati Sent: Friday, 2 December 2005 2:05 PM To: 'Yakov Rekhter'; 'Shane Amante' Cc: l2vpn@ietf.org; pim@ietf.org Subject: RE: PIM Snooping > > Since there was little, if any, consensus in Vancouver as to the best > > direction forward with the PIM snooping work, we would like to hear from > > the WG: > > A) Should we require disabling Join Suppression on CE's? > > B) Should we NOT require disabling Join Suppression on CE's, thereby > > making the PE a more active element in PIM procedures in a VPLS? > > C) Other, more palatable, suggestions? > > > > Please answer the above questions and feel free to add color commentary > > as to other issues or concerns not identified above. >=20 > Wrt (B) what are the implications of making the PE a "more active=20 > element" on the externally visible behavior (where by "externall=20 > visible" I mean visible to a VPLS customer) ? >=20 The implications are that a customer router connected to a PE will not necessarily see the same packet that its counterpart at another PE generated. The packets may be modified, consumed and/or generated by PEs on behalf of customer routers.=20 > Specifically would a VPLS customer be able to distinguish between the=20 > cases where a PE operates as specified today, and making the PE "a=20 > more active element in PIM procedures in a VPLS" ? >=20 Not necessarily. The whole idea of making the PE an active element would be to ensure that nothing has to change in C routers, the multicast states will be built as before. The only difference is that the C routers may end up seeing different packets than what they used to before.=20 Let us consider what a "more active element" in this context means. Consider an example where there are three PEs: PE1, PE2, PE3.=20 PE1 has the upstream router U and a downstream router D1 connected to it on the same AC. PE2 has a downstream router D2. PE3 has a downstream router D3. In order for snooping to build states correctly: 1)If D2 sends a Join to U, we don't want D3 to see the Join because if it did, then it would suppress its Join and the pseudowire PE1-PE3 will not receive the traffic (since PE1 never saw a Join on PE1-PE3). This would not be a problem if all C routers disabled Join suppression and did explicit tracking. 2)If D2 sends a Prune to U, we want D3 to see the Prune so that it can override it. Same would apply if D1 sent a Prune to U; you want D2 and D3 to see it so that they can override the Prune. Again, this would not be a problem if Join suppression was disabled. It would be easy to solve the problem without requiring disabling of Join suppression if Joins and Prunes were separate messages - just unicast Joins (by modifying the dest mac to the upstream router's mac) and multicast Prunes. But Joins and Prunes can be in the SAME JP message and that's where it becomes more complicated. If we want to preserve the transparency to the C routers (i.e. not requiring them to disable Join suppression), then the PEs will have to do something like: 1) Consume the Join/Prune messages seen on the AC. This means we might have to consume other PIM packets (Hello, Assert, BSM) and then send them so that the ordering between the messages is preserved. (An Assert sent to an upstream router that does not have a downstream state will be dropped, for example, since the Join came after the Assert when actually it was sent before the Assert). 2) Separate the Joins from the Prunes: This means the PE is generating packets on behalf of the C routers. 3) Unicast joins to the upstream router and multicast the Prunes to all routers. There may be other ways of doing this, but essentially, we are trying to make the PEs make up for Join Suppression not being disabled in the VPLS by simulating it. The downside is we are no longer plain "snooping", we are also an active participant. Of course, there are also some benefits to doing this. Since the PE is assuming a Proxy role, if it has already signaled a Join for an (S,G) on a PW (due to having received one on an AC), it need not signal Joins for the same state if they arrive on other ACs, as long as it keeps track of how many ACs sent the Joins. This way, the number of Join states sent on the PWs is also reduced. =20 So the question boils down to: Is this the direction we want to go in i.e. have the PEs assume a Proxy role so that the C routers do not have to change OR should we require C routers to disable Join suppression and do explicit tracking. There is a tradeoff here: 1) If we want to preserve the transparency to the C routers (a reasonable goal indeed), the proxy procedures might be perceived by some as "hacks". It was said so in the previous IETF at Paris. But that is the cost of preserving the transparency. 2) If we want to keep the snooping procedures straightforward without any modifications to the C packets, then the C routers have to disable Join suppression. It was suggested at the Vancover IETF that this is an unreasonable requirement since most routers do not support Explicit tracking today. This is a good point too.=20 Both the approaches have merits and demerits. We would like opinions on what the WGs think is the best approach. Thanks. Suresh From l2vpn-bounces@ietf.org Fri Dec 02 13:09:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFLT-0006X8-GA; Fri, 02 Dec 2005 13:09:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFLR-0006Oa-9A for l2vpn@megatron.ietf.org; Fri, 02 Dec 2005 13:09:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26323 for ; Fri, 2 Dec 2005 13:08:30 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiFg9-0000iL-SD for l2vpn@ietf.org; Fri, 02 Dec 2005 13:30:43 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2005 10:09:05 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,207,1131350400"; d="scan'208"; a="16417837:sNHT22347556" Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id jB2I90UR013779; Fri, 2 Dec 2005 13:09:02 -0500 (EST) Message-ID: <43908DBC.8000000@cisco.com> Date: Fri, 02 Dec 2005 11:09:00 -0700 From: Luca Martini User-Agent: Mail/News 1.4 (X11/20050929) MIME-Version: 1.0 To: L2VPN Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: David McDysan , bsd@cisco.com Subject: AII differences between PW routing and l2vpn signalling draft provisionong methods. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org WG, After a good discussion with Bruce Davie, we came up with the following explanation on why we need to have different AII type int he PW setup and maintenance protocol. This note explains why draft-ietf-l2vpn-signaling-06.txt (the L2VPN Signaling draft) and draft-balus-bocci-martini-dyn-ms-pwe3-00.txt (the MS PW draft) make use of different AII types, as defined in draft-metz-aii-aggregate-01.txt. In a nutshell, the two drafts use different AII types because they are tackling different problems. Specifically, L2VPN Signaling draft is concerned with setting up all the PWs for a given L2VPN, while the MS PW draft is concerned with setting up individual PWs. Because it is concerned with building L2VPNs, the L2VPN Signaling draft makes use of the AGI (the contents of which effectively identify the VPN) plus the AII to identify a particular PW. Hence, the AII only needs to identify a "pool" or a VSI relative to a particular AGI. Hence a simple 32 bit AII is sufficient. By contrast, because the MS PW draft is concerned with setting up individual PWs, not L2VPNs, it has no use for the AGI - there is no "group" concept. Hence it fully identifies the PW in the AII. Because there may be many PWs connected to a given U-PE device, it is necessary to identify the PWs relative to a given U-PE. And it is necessary to identify the U-PE within the AII so that the signaling message can be routed toward the correct U-PE. Hence the requirements for the AII are quite different, and it makes sense to use an AII type that is designed to meet these requirements. It is obvious that the simple AII type could be encoded in the more complex AII type by leaving various fields set to zero, but this does not seem to serve any useful purpose. Luca From l2vpn-bounces@ietf.org Fri Dec 02 13:58:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiG6b-0004FE-DA; Fri, 02 Dec 2005 13:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiG6Z-0004El-Oj for l2vpn@megatron.ietf.org; Fri, 02 Dec 2005 13:57:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01839 for ; Fri, 2 Dec 2005 13:57:12 -0500 (EST) Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm3.ca.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiGRI-0002Hz-F0 for l2vpn@ietf.org; Fri, 02 Dec 2005 14:19:25 -0500 Received: from CAOTTN02768 (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id jB2IvglW025037; Fri, 2 Dec 2005 13:57:42 -0500 (EST) Message-Id: <200512021857.jB2IvglW025037@tm3.ca.alcatel.com> From: "Mustapha Aissaoui" To: "'Luca Martini'" , "'L2VPN'" Date: Fri, 2 Dec 2005 13:57:41 -0500 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcX3bCNCqUrVybg+SZyj42ms6hyplAAA6RjQ In-reply-to: <43908DBC.8000000@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 'David McDysan' , bsd@cisco.com Subject: RE: AII differences between PW routing and l2vpn signalling draft provisionong methods. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Luca, I do not believe there is any substantial difference that warrants to standardize two different AII types. A MS-PW can also terminate on a VSI, e.g., VPLS. The issue is to be able to encode the target termination interface: an endpoint for a p2p PW or a VSI for a VPLS in a way such that it will work for both single hop PWs and MS-PWs. Both types can be used for the various L2VPN applications. Pragmatically, the way to go is to deprecate the FEC 129 as defined in draft-ietf-l2vpn-signaling-06.txt (Type 1) and extend the Type 2 to cover the various applications. One other reason to deprecate Type 1 is that we do not want an implementation to use different FEC 129 types for single-hop PW and MS-PW. FEC 128 will be restricted to singe hop PW and will be fine as long as we specify a way to reach U-PEs which are on a FEC 129 Type 2 network. Mustapha. -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Luca Martini Sent: Friday, December 02, 2005 1:09 PM To: L2VPN Cc: David McDysan; bsd@cisco.com Subject: AII differences between PW routing and l2vpn signalling draft provisionong methods. WG, After a good discussion with Bruce Davie, we came up with the following explanation on why we need to have different AII type int he PW setup and maintenance protocol. This note explains why draft-ietf-l2vpn-signaling-06.txt (the L2VPN Signaling draft) and draft-balus-bocci-martini-dyn-ms-pwe3-00.txt (the MS PW draft) make use of different AII types, as defined in draft-metz-aii-aggregate-01.txt. In a nutshell, the two drafts use different AII types because they are tackling different problems. Specifically, L2VPN Signaling draft is concerned with setting up all the PWs for a given L2VPN, while the MS PW draft is concerned with setting up individual PWs. Because it is concerned with building L2VPNs, the L2VPN Signaling draft makes use of the AGI (the contents of which effectively identify the VPN) plus the AII to identify a particular PW. Hence, the AII only needs to identify a "pool" or a VSI relative to a particular AGI. Hence a simple 32 bit AII is sufficient. By contrast, because the MS PW draft is concerned with setting up individual PWs, not L2VPNs, it has no use for the AGI - there is no "group" concept. Hence it fully identifies the PW in the AII. Because there may be many PWs connected to a given U-PE device, it is necessary to identify the PWs relative to a given U-PE. And it is necessary to identify the U-PE within the AII so that the signaling message can be routed toward the correct U-PE. Hence the requirements for the AII are quite different, and it makes sense to use an AII type that is designed to meet these requirements. It is obvious that the simple AII type could be encoded in the more complex AII type by leaving various fields set to zero, but this does not seem to serve any useful purpose. Luca From l2vpn-bounces@ietf.org Fri Dec 02 18:20:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiKD2-0006Td-8Y; Fri, 02 Dec 2005 18:20:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiKCz-0006T8-WB for l2vpn@megatron.ietf.org; Fri, 02 Dec 2005 18:20:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12241 for ; Fri, 2 Dec 2005 18:20:06 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiKXl-0007vk-In for l2vpn@ietf.org; Fri, 02 Dec 2005 18:42:22 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2005 15:20:44 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,208,1131350400"; d="scan'208"; a="16440037:sNHT25639988" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB2NKX4b022039; Fri, 2 Dec 2005 18:20:41 -0500 (EST) Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Dec 2005 18:20:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Dec 2005 18:20:35 -0500 Message-ID: Thread-Topic: AII differences between PW routing and l2vpn signalling draftprovisionong methods. Thread-Index: AcX3bCNCqUrVybg+SZyj42ms6hyplAAA6RjQAAa+pBA= From: "Chris Metz \(chmetz\)" To: "Mustapha Aissaoui" , "Luca Martini \(lmartini\)" , "L2VPN" X-OriginalArrivalTime: 02 Dec 2005 23:20:37.0411 (UTC) FILETIME=[00B80730:01C5F797] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Cc: David McDysan , bsd@cisco.com Subject: RE: AII differences between PW routing and l2vpn signalling draftprovisionong methods. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hey Folks- Here is my take on this interesting question: - AII Type 1 is for provisioning models that best make use of a fixed-length 32-bit value. L2VPN signaling is one and does not need anything more (from the AII perspective). Another might be FEC129 compatibility with AC's previously configured with original Pwid. Selective VPWS with no aggregation is not one.=20 - AII Type 2 is necessary for Selective VPWS because a) many discrete AII values can be summarized, b)provides structure for global uniqueness. - Either AII type should not infer reachability to the TT-PE between or within an AS. That can only be determined by the locality of the ST-PE and the precision of the routing information (IP, PW L2, etc.) it possesses to route the PW signaling messages to the TT-PE. Examples: ST-PE in one AS will have complete IP reachability and LDP session to TT-PE in another AS. FEC129/AII Type 2 (or AII Type 1) is then used in PW setup.=20 Conversely there may be tuples in PW L2 routing table and MS-PW signaling would be required to reach the TT-PE. Why can't the ST-PE include an AII Type 1 value in the FEC129 field and expect PW routing to progress it towards the TT-PE?=20 There could also be FEC129/AII Type 2 PWs setup between ST-PE and TT-PE in the same AS. - Having different AII types for different applications/services is useful for network management, trouble-shooting, provisioning and logical functional separation in the network elements. I am not entirely clear, in the absense of a different AII types, how a local ST-PE would know when/how to launch PW setups if there was only one AII Type and they all arrived via BGP? I can smell new BGP attributes on the horizon :-) ... "here is the new BGP AII Type 2 attribute " yuck, yuck, yuck ... - I have said it before and will say it again: we can debate on one or two AII types but eventually we will need more because some application/service/provisioning model will come along and AII Type 1/2 will be insufficient (read IPv6). IMHO we should: - go with the two AII types ... - decouple MS-PW LDP signaling procedures from AII Type 2. Really shouldn't any AII type suffice? Thanks,=20 Chris =20 =20 =20 =20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Mustapha Aissaoui > Sent: Friday, December 02, 2005 10:58 AM > To: Luca Martini (lmartini); 'L2VPN' > Cc: 'David McDysan'; bsd@cisco.com > Subject: RE: AII differences between PW routing and l2vpn=20 > signalling draftprovisionong methods. >=20 > Luca, > I do not believe there is any substantial difference that=20 > warrants to standardize two different AII types. A MS-PW can=20 > also terminate on a VSI, e.g., VPLS. >=20 > The issue is to be able to encode the target termination=20 > interface: an endpoint for a p2p PW or a VSI for a VPLS in a=20 > way such that it will work for both single hop PWs and=20 > MS-PWs. Both types can be used for the various L2VPN applications. >=20 > Pragmatically, the way to go is to deprecate the FEC 129 as=20 > defined in draft-ietf-l2vpn-signaling-06.txt (Type 1) and=20 > extend the Type 2 to cover the various applications. One=20 > other reason to deprecate Type 1 is that we do not want an=20 > implementation to use different FEC 129 types for single-hop=20 > PW and MS-PW. FEC 128 will be restricted to singe hop PW and=20 > will be fine as long as we specify a way to reach U-PEs which=20 > are on a FEC 129 Type 2 network. >=20 > Mustapha. > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Luca Martini > Sent: Friday, December 02, 2005 1:09 PM > To: L2VPN > Cc: David McDysan; bsd@cisco.com > Subject: AII differences between PW routing and l2vpn=20 > signalling draft provisionong methods. >=20 > WG, >=20 > After a good discussion with Bruce Davie, we came up with=20 > the following explanation on why we need to have different=20 > AII type int he PW setup and maintenance protocol. > This note explains why draft-ietf-l2vpn-signaling-06.txt (the=20 > L2VPN Signaling draft) and=20 > draft-balus-bocci-martini-dyn-ms-pwe3-00.txt (the MS PW > draft) make use of different AII types, as defined in=20 > draft-metz-aii-aggregate-01.txt. > In a nutshell, the two drafts use different AII types=20 > because they are tackling different problems. Specifically,=20 > L2VPN Signaling draft is concerned with setting up all the=20 > PWs for a given L2VPN, while the MS PW draft is concerned=20 > with setting up individual PWs. > Because it is concerned with building L2VPNs, the L2VPN=20 > Signaling draft makes use of the AGI (the contents of which=20 > effectively identify the > VPN) plus the AII to identify a particular PW. Hence, the AII=20 > only needs to identify a "pool" or a VSI relative to a=20 > particular AGI. Hence a simple 32 bit AII is sufficient. > By contrast, because the MS PW draft is concerned with=20 > setting up individual PWs, not L2VPNs, it has no use for the=20 > AGI - there is no "group" concept. > Hence it fully identifies the PW in the AII. Because there=20 > may be many PWs connected to a given U-PE device, it is=20 > necessary to identify the PWs relative to a given U-PE. And=20 > it is necessary to identify the U-PE within the AII so that=20 > the signaling message can be routed toward the correct U-PE. > Hence the requirements for the AII are quite different, and=20 > it makes sense to use an AII type that is designed to meet=20 > these requirements. > It is obvious that the simple AII type could be encoded in=20 > the more complex AII type by leaving various fields set to=20 > zero, but this does not seem to serve any useful purpose. >=20 > Luca >=20 >=20 >=20 From l2vpn-bounces@ietf.org Mon Dec 05 09:00:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjGtg-0008Do-LG; Mon, 05 Dec 2005 09:00:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjGtc-0008CL-SY for l2vpn@megatron.ietf.org; Mon, 05 Dec 2005 09:00:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21552 for ; Mon, 5 Dec 2005 08:59:57 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjHEt-0002V9-0u for l2vpn@ietf.org; Mon, 05 Dec 2005 09:22:49 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jB5Drbm01823; Mon, 5 Dec 2005 08:53:37 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Dec 2005 08:53:36 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650751590B@zcarhxm1.corp.nortel.com> Thread-Topic: AII differences between PW routing and l2vpn signalling draftprovisionong methods. Thread-Index: AcX3bCNCqUrVybg+SZyj42ms6hyplAAA6RjQAIZVVDA= From: "Florin Balus" To: "Mustapha Aissaoui" , "Luca Martini" , "L2VPN" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable Cc: David McDysan , bsd@cisco.com Subject: RE: AII differences between PW routing and l2vpn signalling draftprovisionong methods. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org I agree with Mustapha's proposal: we should just deprecate AII type 1 before people start implementing it. All its functionality could be easily reproduced if need be using AII type 2: just set Global ID and Prefix fields to zero. L2VPN Signaling itself proposes a similar approach for the 32 bits field associated with AII type 1 when it comes to BGP auto-discovery: i.e. just re-use 32 bits from the NLRI for BGP VPLS SAFI and set the other unnecessary fields to zero... Note that AII type 2 will be required for L2VPN addressing: all the Use Cases (e.g. MAN-WAN, Inter-provider, Scalability, private PE addressing) described in MS-PW requirements draft apply also for L2VPNs (PWs being used as infrastructure).=20 So there won't be a clear cut between the 2 cases outlined by Luca below: there will be plenty of scenarios where 2 VSIs (VPLS)/Pools (VPWS) will need to be connected via a MS-PW.=20 Moreover there will be cases where the same PE will have to connect its VSI to remote ones using both SS and MS-PWs. How does the PE choose when to use one AII type versus the other? Definitely that should not happen based on whether the PW goes one hop or multiple hops.=20 Everybody will require sooner or later support for MS-PWs. So I think it's a good idea to put in place early in the L2 build up, the L2 addressing that will easily accommodate the MS-PW expansion instead of trying to live with 2 addressing plans: one unique per AGI (AII type 1), one globally unique (AII type 2). Focusing on one addressing format will maximize also technology re-use (MS/SS-PWs transparently applicable to Individual VCs, VPWS, VPLS) and will avoid interoperability issues between vendors and SPs. Regards, Florin=20 >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >On Behalf Of Mustapha Aissaoui >Sent: Friday, December 02, 2005 1:58 PM >To: 'Luca Martini'; 'L2VPN' >Cc: 'David McDysan'; bsd@cisco.com >Subject: RE: AII differences between PW routing and l2vpn=20 >signalling draftprovisionong methods. > > >Luca, >I do not believe there is any substantial difference that >warrants to standardize two different AII types. A MS-PW can=20 >also terminate on a VSI, e.g., VPLS. > >The issue is to be able to encode the target termination >interface: an endpoint for a p2p PW or a VSI for a VPLS in a=20 >way such that it will work for both single hop PWs and MS-PWs.=20 >Both types can be used for the various L2VPN applications. > >Pragmatically, the way to go is to deprecate the FEC 129 as >defined in draft-ietf-l2vpn-signaling-06.txt (Type 1) and=20 >extend the Type 2 to cover the various applications. One other=20 >reason to deprecate Type 1 is that we do not want an=20 >implementation to use different FEC 129 types for single-hop=20 >PW and MS-PW. FEC 128 will be restricted to singe hop PW and=20 >will be fine as long as we specify a way to reach U-PEs which=20 >are on a FEC 129 Type 2 network. > >Mustapha. >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >On Behalf Of Luca Martini >Sent: Friday, December 02, 2005 1:09 PM >To: L2VPN >Cc: David McDysan; bsd@cisco.com >Subject: AII differences between PW routing and l2vpn=20 >signalling draft provisionong methods. > >WG, > >After a good discussion with Bruce Davie, we came up with the >following explanation on why we need to have different AII=20 >type int he PW setup and maintenance protocol. This note=20 >explains why draft-ietf-l2vpn-signaling-06.txt (the L2VPN=20 >Signaling draft) and=20 >draft-balus-bocci-martini-dyn-ms-pwe3-00.txt (the MS PW >draft) make use of different AII types, as defined in=20 >draft-metz-aii-aggregate-01.txt. In a nutshell, the two=20 >drafts use different AII types because they are tackling=20 >different problems. Specifically, L2VPN Signaling draft is=20 >concerned with setting up all the PWs for a given L2VPN, while=20 >the MS PW draft is concerned with setting up individual PWs. =20 >Because it is concerned with building L2VPNs, the L2VPN=20 >Signaling draft makes use of the AGI (the contents of which=20 >effectively identify the >VPN) plus the AII to identify a particular PW. Hence, the AII=20 >only needs to identify a "pool" or a VSI relative to a=20 >particular AGI. Hence a simple 32 bit AII is sufficient. By=20 >contrast, because the MS PW draft is concerned with setting up=20 >individual PWs, not L2VPNs, it has no use for the AGI - there=20 >is no "group" concept. Hence it fully identifies the PW in the=20 >AII. Because there may be many PWs connected to a given U-PE=20 >device, it is necessary to identify the PWs relative to a=20 >given U-PE. And it is necessary to identify the U-PE within=20 >the AII so that the signaling message can be routed toward the=20 >correct U-PE. Hence the requirements for the AII are quite=20 >different, and it makes sense to use an AII type that is=20 >designed to meet these requirements. It is obvious that the=20 >simple AII type could be encoded in the more complex AII type=20 >by leaving various fields set to zero, but this does not seem=20 >to serve any useful purpose. > >Luca > > > > > > From l2vpn-bounces@ietf.org Mon Dec 05 12:26:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjK6E-0007VK-R3; Mon, 05 Dec 2005 12:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjK6C-0007UO-OL for l2vpn@megatron.ietf.org; Mon, 05 Dec 2005 12:26:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16273 for ; Mon, 5 Dec 2005 12:25:10 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjKRV-0001Y8-5w for l2vpn@ietf.org; Mon, 05 Dec 2005 12:48:03 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 05 Dec 2005 12:25:47 -0500 X-IronPort-AV: i="3.99,217,1131339600"; d="scan'208"; a="77113523:sNHT29250028" Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id jB5HPc4X014152; Mon, 5 Dec 2005 12:25:43 -0500 (EST) Message-ID: <43947812.7070606@cisco.com> Date: Mon, 05 Dec 2005 10:25:38 -0700 From: Luca Martini User-Agent: Mail/News 1.4 (X11/20050929) MIME-Version: 1.0 To: Florin Balus References: <9671A92C3C8B5744BC97F855F7CB64650751590B@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650751590B@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit Cc: L2VPN , David McDysan , Mustapha Aissaoui , bsd@cisco.com Subject: Re: AII differences between PW routing and l2vpn signalling draftprovisionong methods. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Florin, Florin Balus wrote: > I agree with Mustapha's proposal: we should just deprecate AII type 1 > before people start implementing it. All its functionality could be > easily reproduced if need be using AII type 2: just set Global ID and > Prefix fields to zero. L2VPN Signaling itself proposes a similar > Prefixing the fields to 0 just means that you really have encoded a new AII type , but you are hiding it. What happens when a new provisioning model comes along ? do we put all the fields to 0xffff ? > approach for the 32 bits field associated with AII type 1 when it comes > to BGP auto-discovery: i.e. just re-use 32 bits from the NLRI for BGP > VPLS SAFI and set the other unnecessary fields to zero... > > Note that AII type 2 will be required for L2VPN addressing: all the Use > Cases (e.g. MAN-WAN, Inter-provider, Scalability, private PE addressing) > described in MS-PW requirements draft apply also for L2VPNs (PWs being > used as infrastructure). > > So there won't be a clear cut between the 2 cases outlined by Luca > below: there will be plenty of scenarios where 2 VSIs (VPLS)/Pools > (VPWS) will need to be connected via a MS-PW. > > Yes , and this case is handled properly in the l2vpn-signaling draft. For VPLS the PW-Switching point PE is a BGP speaker, hence it can advertise the VPLS with itself as a next hop. This will initiate the MS-PW segments correctly through the S-PE ( basically , the BGP speaker itself ) > Moreover there will be cases where the same PE will have to connect its > VSI to remote ones using both SS and MS-PWs. How does the PE choose when > to use one AII type versus the other? Definitely that should not happen > based on whether the PW goes one hop or multiple hops. > > there is no need to choose. In this case , the BGP message contains 2 piece of information: "please setup a PW to myself" , and " here is the VSI you should connect the PW to" This is very different from the MS-PW BGP message that simply says "you can reach this PW AC address here" . > Everybody will require sooner or later support for MS-PWs. So I think > it's a good idea to put in place early in the L2 build up, the L2 > addressing that will easily accommodate the MS-PW expansion instead of > trying to live with 2 addressing plans: one unique per AGI (AII type 1), > one globally unique (AII type 2). > > Focusing on one addressing format will maximize also technology re-use > (MS/SS-PWs transparently applicable to Individual VCs, VPWS, VPLS) and > will avoid interoperability issues between vendors and SPs. > > The reason we had an AII type field is to allow different provisioning schemes ... what would be the point to have only one AII type ? Although I think this is fairly complicated, keeping the AII type 1 as is , ( which is used in a different context ) does not preclude any of the MS-PW technology from being used. On the contrary , only using AII type 2 , precludes the autodiscovery methodology described in the l2vpn-signaling draft, unless most fields are set to 0 which gets us right back to AII type 1. Thanks. Luca > Regards, > Florin > > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >> On Behalf Of Mustapha Aissaoui >> Sent: Friday, December 02, 2005 1:58 PM >> To: 'Luca Martini'; 'L2VPN' >> Cc: 'David McDysan'; bsd@cisco.com >> Subject: RE: AII differences between PW routing and l2vpn >> signalling draftprovisionong methods. >> >> >> Luca, >> I do not believe there is any substantial difference that >> warrants to standardize two different AII types. A MS-PW can >> also terminate on a VSI, e.g., VPLS. >> >> The issue is to be able to encode the target termination >> interface: an endpoint for a p2p PW or a VSI for a VPLS in a >> way such that it will work for both single hop PWs and MS-PWs. >> Both types can be used for the various L2VPN applications. >> >> Pragmatically, the way to go is to deprecate the FEC 129 as >> defined in draft-ietf-l2vpn-signaling-06.txt (Type 1) and >> extend the Type 2 to cover the various applications. One other >> reason to deprecate Type 1 is that we do not want an >> implementation to use different FEC 129 types for single-hop >> PW and MS-PW. FEC 128 will be restricted to singe hop PW and >> will be fine as long as we specify a way to reach U-PEs which >> are on a FEC 129 Type 2 network. >> >> Mustapha. >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >> On Behalf Of Luca Martini >> Sent: Friday, December 02, 2005 1:09 PM >> To: L2VPN >> Cc: David McDysan; bsd@cisco.com >> Subject: AII differences between PW routing and l2vpn >> signalling draft provisionong methods. >> >> WG, >> >> After a good discussion with Bruce Davie, we came up with the >> following explanation on why we need to have different AII >> type int he PW setup and maintenance protocol. This note >> explains why draft-ietf-l2vpn-signaling-06.txt (the L2VPN >> Signaling draft) and >> draft-balus-bocci-martini-dyn-ms-pwe3-00.txt (the MS PW >> draft) make use of different AII types, as defined in >> draft-metz-aii-aggregate-01.txt. In a nutshell, the two >> drafts use different AII types because they are tackling >> different problems. Specifically, L2VPN Signaling draft is >> concerned with setting up all the PWs for a given L2VPN, while >> the MS PW draft is concerned with setting up individual PWs. >> Because it is concerned with building L2VPNs, the L2VPN >> Signaling draft makes use of the AGI (the contents of which >> effectively identify the >> VPN) plus the AII to identify a particular PW. Hence, the AII >> only needs to identify a "pool" or a VSI relative to a >> particular AGI. Hence a simple 32 bit AII is sufficient. By >> contrast, because the MS PW draft is concerned with setting up >> individual PWs, not L2VPNs, it has no use for the AGI - there >> is no "group" concept. Hence it fully identifies the PW in the >> AII. Because there may be many PWs connected to a given U-PE >> device, it is necessary to identify the PWs relative to a >> given U-PE. And it is necessary to identify the U-PE within >> the AII so that the signaling message can be routed toward the >> correct U-PE. Hence the requirements for the AII are quite >> different, and it makes sense to use an AII type that is >> designed to meet these requirements. It is obvious that the >> simple AII type could be encoded in the more complex AII type >> by leaving various fields set to zero, but this does not seem >> to serve any useful purpose. >> >> Luca >> >> >> >> >> >> >> > > From l2vpn-bounces@ietf.org Tue Dec 06 11:07:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjfLn-0001dO-8j; Tue, 06 Dec 2005 11:07:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjfLm-0001dD-2y for l2vpn@megatron.ietf.org; Tue, 06 Dec 2005 11:07:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17267 for ; Tue, 6 Dec 2005 11:06:39 -0500 (EST) Received: from howler.tri.sbc.com ([205.173.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjfhH-0007Oy-SQ for l2vpn@ietf.org; Tue, 06 Dec 2005 11:29:45 -0500 Received: from sbctri.tri.sbc.com (mayhem-webdmz.tri.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.12.10/8.12.10) with ESMTP id jB6G79Db024001; Tue, 6 Dec 2005 10:07:09 -0600 (CST) Received: from TSMAIL.ad.tri.sbc.com (tsmail.ad.tri.sbc.com [144.60.55.228]) by sbctri.tri.sbc.com (8.12.10/8.12.10) with ESMTP id jB6G73OU028890; Tue, 6 Dec 2005 10:07:03 -0600 (CST) Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Dec 2005 10:07:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Dec 2005 10:07:02 -0600 Message-ID: <0CED449E95A92A42991EB71B778C17BF020A730C@TSMAIL2.ad.tri.sbc.com> Thread-Topic: PIM Snooping Thread-Index: AcX1D+GwJMv4DA1+Rnuk8eJfqxLYpAFbx7WQ From: "Serbest, Yetik" To: , "Shane Amante" X-OriginalArrivalTime: 06 Dec 2005 16:07:03.0505 (UTC) FILETIME=[18DFFC10:01C5FA7F] X-Scanned-By: MIMEDefang 2.38 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org Subject: RE: PIM Snooping 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Eric, What is your solution/proposal to support multicast over VPLS? Flooding? Thanks, yetik -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Eric Rosen Sent: Tuesday, November 29, 2005 12:00 PM To: Shane Amante Cc: l2vpn@ietf.org Subject: Re: PIM Snooping=20 > Should we require disabling Join Suppression on CE's?=20 Oh, it's worse than that. We'd also have to prohibit CEs from ever implementing PIM refresh reduction (if such a thing ever comes to be), from ever running PIM over TCP (if such a thing ever comes to be), etc. Well, it's a good thing the customer has bought an L2 service, to which all the L3 protocols are transparent ;-) And remember, it's not just CEs that are "directly" connected to PEs, it's all routers on a LAN which is bridged to a PE. =20 > Should we NOT require disabling Join Suppression on CE's, thereby making > the PE a more active element in PIM procedures in a VPLS?=20 At least the PE would only have to understand the customer's multicast routing, it wouldn't have to understand anything really complicated, like the customer's unicast routing ;-) Maybe we should step back and look at what we're doing here.=20 From l2vpn-bounces@ietf.org Tue Dec 06 11:38:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjfqD-0005S9-GG; Tue, 06 Dec 2005 11:38:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjfqC-0005Ri-CZ for l2vpn@megatron.ietf.org; Tue, 06 Dec 2005 11:38:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21425 for ; Tue, 6 Dec 2005 11:38:05 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjgBi-00009U-VE for l2vpn@ietf.org; Tue, 06 Dec 2005 12:01:11 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jB6GXWR16824; Tue, 6 Dec 2005 11:33:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Dec 2005 11:33:30 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650758A61D@zcarhxm1.corp.nortel.com> Thread-Topic: AII differences between PW routing and l2vpn signalling draftprovisionong methods. Thread-Index: AcX5wPDb+xRYswI2Q+K4FT+lXAMriwAUtQtg X-Message-Flag: Follow up From: "Florin Balus" To: "Luca Martini" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: quoted-printable Cc: L2VPN , David McDysan , Mustapha Aissaoui , bsd@cisco.com Subject: RE: AII differences between PW routing and l2vpn signalling draftprovisionong methods. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Luca, It looks like we are making progress here. Let me summarize what I understood from your follow up: - you are acknowledging that VPLS/VPWS might use either one or a combination of both MS and SS-PWs to interconnect their VSIs/VFs associated with their pools? - in your view AII type 1 and implicitly the (AGI, 32 bit AII) addressing scheme solves in the simplest way the provisioning model for VPLS/VPWS based on Autodiscovery of the endpoints? Can you confirm my summary?=20 I am happy with the first part. For the second part we should also note there are a good chunk of L2VPNs (all currently deployed LDP-VPLS) provisioning models where no AD is used/available. In my opinion, AII type 2 is a must in these scenarios whenever at least one MS-PW is involved. That is the first reason for saying that there is not a clear delineation - AII type 1 for L2VPNs, type 2 for Individual MS-PWs. On the other hand, I agree that until a new scheme for AD-based provisioning model is described, the one described in L2VPN Signaling is the only one available. Still I still think what is happening during the AD process does not dictate what is included in the fields used for PW Signaling phase. Furthermore before closing on where each AII type should be used, I think we should spend some time looking into options to streamline the BGP AD procedures for the generalized case (where either a MS/SS-PW may be used for L2VPNs). See also in-line... Thanks, Florin >-----Original Message----- >From: Luca Martini [mailto:lmartini@cisco.com] >Sent: Monday, December 05, 2005 12:26 PM >To: Balus, Florin [CAR:6955:EXCH] >Cc: Mustapha Aissaoui; L2VPN; David McDysan; bsd@cisco.com >Subject: Re: AII differences between PW routing and l2vpn=20 >signalling draftprovisionong methods. > > >Florin, > >Florin Balus wrote: >> I agree with Mustapha's proposal: we should just deprecate >AII type 1 >> before people start implementing it. All its functionality could be >> easily reproduced if need be using AII type 2: just set=20 >Global ID and >> Prefix fields to zero. L2VPN Signaling itself proposes a similar >> =20 >Prefixing the fields to 0 just means that you really have >encoded a new=20 >AII type , but you are hiding it. Is that a problem? Isn't the same thing proposed for BGP Autodiscovery in L2VPN Signaling: all the NLRI fields from BGP VPLS SAFI are set to zero except a 32 bits one...=20 In any case I just mentioned the above option (set Global ID, Prefix fields to zero) as a posibility. I don't really see a problem to include the real values for the Global ID and Prefix fields when signaling any PW, regardless of whether it connects VSIs/Pools/VFs, or whether it is SS/MS type. >What happens when a new provisioning model comes along ? do we put all >the fields to 0xffff ? I was speaking about the well known L2VPN models we are aware of: i.e. individual VCs, VPWS, VPLS. Provisioned or autodiscovered. I am saying that in all three of them you can use nicely an AII type 2 to signal the PW building blocks, without worrying whether it is a SS/MS-PW. As per my first in-line note, I think it's actually a good idea to include for all of them Global ID and Prefix field. The AC ID is the only field that needs to be set to 0 only for non-distributed VPLS. > >> approach for the 32 bits field associated with AII type 1 when it >> comes to BGP auto-discovery: i.e. just re-use 32 bits from the NLRI=20 >> for BGP VPLS SAFI and set the other unnecessary fields to zero... >> >> Note that AII type 2 will be required for L2VPN addressing: all the >> Use Cases (e.g. MAN-WAN, Inter-provider, Scalability, private PE=20 >> addressing) described in MS-PW requirements draft apply also for=20 >> L2VPNs (PWs being used as infrastructure). >> >> So there won't be a clear cut between the 2 cases outlined by Luca >> below: there will be plenty of scenarios where 2 VSIs (VPLS)/Pools >> (VPWS) will need to be connected via a MS-PW. >> >> =20 >Yes , and this case is handled properly in the l2vpn-signaling >draft. For VPLS the PW-Switching point PE is a BGP speaker,=20 >hence it can=20 >advertise the VPLS with itself as a next hop. This will initiate the=20 >MS-PW segments correctly through the S-PE ( basically , the=20 >BGP speaker=20 >itself ) > See my reply in the summary (for the second part)... > >> Moreover there will be cases where the same PE will have to connect >> its VSI to remote ones using both SS and MS-PWs. How does the PE=20 >> choose when to use one AII type versus the other? Definitely that=20 >> should not happen based on whether the PW goes one hop or multiple=20 >> hops. >> >> =20 >there is no need to choose. In this case , the BGP message contains 2 >piece of information: "please setup a PW to myself" , and "=20 >here is the=20 >VSI you should connect the PW to" I understand and agree with the AD description in L2VPN Signaling. But then during the Signaling step, what stops us from putting "myself" info in the AII type 2 fields?=20 =20 > >This is very different from the MS-PW BGP message that simply >says "you=20 >can reach this PW AC address here" . > >> Everybody will require sooner or later support for MS-PWs. >So I think >> it's a good idea to put in place early in the L2 build up, the L2 >> addressing that will easily accommodate the MS-PW expansion=20 >instead of >> trying to live with 2 addressing plans: one unique per AGI (AII type >> 1), one globally unique (AII type 2). >> >> Focusing on one addressing format will maximize also >technology re-use >> (MS/SS-PWs transparently applicable to Individual VCs, VPWS, >VPLS) and >> will avoid interoperability issues between vendors and SPs. >> >> =20 >The reason we had an AII type field is to allow different provisioning >schemes ... >what would be the point to have only one AII type ? > Yes I agree as long as it is clear that one can't do it easily with existing ones. >Although I think this is fairly complicated, keeping the AII type 1 as >is , ( which is used in a different context ) does not preclude any of=20 >the MS-PW technology from being used. >On the contrary , only using AII type 2 , precludes the autodiscovery=20 >methodology described in the l2vpn-signaling draft,=20 >unless most fields are set to 0=20 >which gets us right back to AII type 1. I would just say here that we should spend more time discussing options before reaching a conclusion. > >Thanks. >Luca > > >> Regards, >> Florin >> >> =20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf Of Mustapha Aissaoui >>> Sent: Friday, December 02, 2005 1:58 PM >>> To: 'Luca Martini'; 'L2VPN' >>> Cc: 'David McDysan'; bsd@cisco.com >>> Subject: RE: AII differences between PW routing and l2vpn >>> signalling draftprovisionong methods. >>> >>> >>> Luca, >>> I do not believe there is any substantial difference that >warrants to >>> standardize two different AII types. A MS-PW can also >terminate on a >>> VSI, e.g., VPLS. >>> >>> The issue is to be able to encode the target termination >>> interface: an endpoint for a p2p PW or a VSI for a VPLS in a way=20 >>> such that it will work for both single hop PWs and MS-PWs. Both=20 >>> types can be used for the various L2VPN applications. >>> >>> Pragmatically, the way to go is to deprecate the FEC 129 as defined >>> in draft-ietf-l2vpn-signaling-06.txt (Type 1) and extend the Type 2=20 >>> to cover the various applications. One other reason to=20 >deprecate Type >>> 1 is that we do not want an implementation to use different FEC 129 >>> types for single-hop PW and MS-PW. FEC 128 will be restricted to=20 >>> singe hop PW and will be fine as long as we specify a way to reach=20 >>> U-PEs which are on a FEC 129 Type 2 network. >>> >>> Mustapha. >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf Of Luca Martini >>> Sent: Friday, December 02, 2005 1:09 PM >>> To: L2VPN >>> Cc: David McDysan; bsd@cisco.com >>> Subject: AII differences between PW routing and l2vpn >>> signalling draft provisionong methods. >>> >>> WG, >>> >>> After a good discussion with Bruce Davie, we came up with the >>> following explanation on why we need to have different AII type int=20 >>> he PW setup and maintenance protocol. This note explains why=20 >>> draft-ietf-l2vpn-signaling-06.txt (the L2VPN Signaling draft) and >>> draft-balus-bocci-martini-dyn-ms-pwe3-00.txt (the MS PW >>> draft) make use of different AII types, as defined in=20 >>> draft-metz-aii-aggregate-01.txt. In a nutshell, the two=20 >>> drafts use different AII types because they are tackling=20 >>> different problems. Specifically, L2VPN Signaling draft is=20 >>> concerned with setting up all the PWs for a given L2VPN, while=20 >>> the MS PW draft is concerned with setting up individual PWs. =20 >>> Because it is concerned with building L2VPNs, the L2VPN=20 >>> Signaling draft makes use of the AGI (the contents of which=20 >>> effectively identify the >>> VPN) plus the AII to identify a particular PW. Hence, the AII=20 >>> only needs to identify a "pool" or a VSI relative to a=20 >>> particular AGI. Hence a simple 32 bit AII is sufficient. By=20 >>> contrast, because the MS PW draft is concerned with setting up=20 >>> individual PWs, not L2VPNs, it has no use for the AGI - there=20 >>> is no "group" concept. Hence it fully identifies the PW in the=20 >>> AII. Because there may be many PWs connected to a given U-PE=20 >>> device, it is necessary to identify the PWs relative to a=20 >>> given U-PE. And it is necessary to identify the U-PE within=20 >>> the AII so that the signaling message can be routed toward the=20 >>> correct U-PE. Hence the requirements for the AII are quite=20 >>> different, and it makes sense to use an AII type that is=20 >>> designed to meet these requirements. It is obvious that the=20 >>> simple AII type could be encoded in the more complex AII type=20 >>> by leaving various fields set to zero, but this does not seem=20 >>> to serve any useful purpose. >>> >>> Luca >>> >>> >>> >>> >>> >>> >>> =20 >> >> =20 > > From l2vpn-bounces@ietf.org Tue Dec 06 22:08:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejpfj-0005iU-1o; Tue, 06 Dec 2005 22:08:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejpfh-0005iM-6u; Tue, 06 Dec 2005 22:08:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26707; Tue, 6 Dec 2005 22:07:53 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejq1I-0004Rl-QZ; Tue, 06 Dec 2005 22:31:06 -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 <0IR300FK3YAMFX@szxga01-in.huawei.com>; Wed, 07 Dec 2005 11:13:35 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR30031YYALA1@szxga01-in.huawei.com>; Wed, 07 Dec 2005 11:13:34 +0800 (CST) Received: from d10570a ([10.70.77.239]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR300AC7YDK86@szxml02-in.huawei.com>; Wed, 07 Dec 2005 11:15:20 +0800 (CST) Date: Wed, 07 Dec 2005 11:05:08 +0800 From: Jixiong Dong To: pwe3 , Luca Martini , Florin Balus Message-id: <000b01c5fadb$0805b220$ef4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <9671A92C3C8B5744BC97F855F7CB64650758A61D@zcarhxm1.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Content-Transfer-Encoding: 7BIT Cc: L2VPN , David McDysan , Mustapha Aissaoui , bsd@cisco.com Subject: Re: AII differences between PW routing and l2vpn signallingdraftprovisionong methods. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Florin, >>Florin Balus wrote: >Is that a problem? Isn't the same thing proposed for BGP Autodiscovery >in L2VPN Signaling: all the NLRI fields from BGP VPLS SAFI are set to >zero except a 32 bits one... >In any case I just mentioned the above option (set Global ID, Prefix >fields to zero) as a posibility. I don't really see a problem to include >the real values for the Global ID and Prefix fields when signaling any >PW, regardless of whether it connects VSIs/Pools/VFs, or whether it is >SS/MS type. [Dong] I agree with you. According to the current pw signaling, we must select one between ss-pw signaling and ms-pw signaling when we setup a pw. It's very difficult and add the addtional complexity.So it's very useful to unify the ss-pw signaling and ms-pw signaling, i.e., stop developing the ss-pw signaling. Moreover, I suggest we should reserve the AGI field in ms-pw signaling so that we can use it for group status notification or group pw teardown and so on as indicated in the draft "draft-ietf-pwe3-control-protocol-17.txt". When AGI = 0, we can ignore this field. Regards, Dong ----- Original Message ----- From: "Florin Balus" To: "Luca Martini" Cc: "L2VPN" ; "David McDysan" ; "Mustapha Aissaoui" ; Sent: Wednesday, December 07, 2005 12:33 AM Subject: RE: AII differences between PW routing and l2vpn signallingdraftprovisionong methods. Luca, It looks like we are making progress here. Let me summarize what I understood from your follow up: - you are acknowledging that VPLS/VPWS might use either one or a combination of both MS and SS-PWs to interconnect their VSIs/VFs associated with their pools? - in your view AII type 1 and implicitly the (AGI, 32 bit AII) addressing scheme solves in the simplest way the provisioning model for VPLS/VPWS based on Autodiscovery of the endpoints? Can you confirm my summary? I am happy with the first part. For the second part we should also note there are a good chunk of L2VPNs (all currently deployed LDP-VPLS) provisioning models where no AD is used/available. In my opinion, AII type 2 is a must in these scenarios whenever at least one MS-PW is involved. That is the first reason for saying that there is not a clear delineation - AII type 1 for L2VPNs, type 2 for Individual MS-PWs. On the other hand, I agree that until a new scheme for AD-based provisioning model is described, the one described in L2VPN Signaling is the only one available. Still I still think what is happening during the AD process does not dictate what is included in the fields used for PW Signaling phase. Furthermore before closing on where each AII type should be used, I think we should spend some time looking into options to streamline the BGP AD procedures for the generalized case (where either a MS/SS-PW may be used for L2VPNs). See also in-line... Thanks, Florin >-----Original Message----- >From: Luca Martini [mailto:lmartini@cisco.com] >Sent: Monday, December 05, 2005 12:26 PM >To: Balus, Florin [CAR:6955:EXCH] >Cc: Mustapha Aissaoui; L2VPN; David McDysan; bsd@cisco.com >Subject: Re: AII differences between PW routing and l2vpn >signalling draftprovisionong methods. > > >Florin, > >Florin Balus wrote: >> I agree with Mustapha's proposal: we should just deprecate >AII type 1 >> before people start implementing it. All its functionality could be >> easily reproduced if need be using AII type 2: just set >Global ID and >> Prefix fields to zero. L2VPN Signaling itself proposes a similar >> >Prefixing the fields to 0 just means that you really have >encoded a new >AII type , but you are hiding it. Is that a problem? Isn't the same thing proposed for BGP Autodiscovery in L2VPN Signaling: all the NLRI fields from BGP VPLS SAFI are set to zero except a 32 bits one... In any case I just mentioned the above option (set Global ID, Prefix fields to zero) as a posibility. I don't really see a problem to include the real values for the Global ID and Prefix fields when signaling any PW, regardless of whether it connects VSIs/Pools/VFs, or whether it is SS/MS type. >What happens when a new provisioning model comes along ? do we put all >the fields to 0xffff ? I was speaking about the well known L2VPN models we are aware of: i.e. individual VCs, VPWS, VPLS. Provisioned or autodiscovered. I am saying that in all three of them you can use nicely an AII type 2 to signal the PW building blocks, without worrying whether it is a SS/MS-PW. As per my first in-line note, I think it's actually a good idea to include for all of them Global ID and Prefix field. The AC ID is the only field that needs to be set to 0 only for non-distributed VPLS. > >> approach for the 32 bits field associated with AII type 1 when it >> comes to BGP auto-discovery: i.e. just re-use 32 bits from the NLRI >> for BGP VPLS SAFI and set the other unnecessary fields to zero... >> >> Note that AII type 2 will be required for L2VPN addressing: all the >> Use Cases (e.g. MAN-WAN, Inter-provider, Scalability, private PE >> addressing) described in MS-PW requirements draft apply also for >> L2VPNs (PWs being used as infrastructure). >> >> So there won't be a clear cut between the 2 cases outlined by Luca >> below: there will be plenty of scenarios where 2 VSIs (VPLS)/Pools >> (VPWS) will need to be connected via a MS-PW. >> >> >Yes , and this case is handled properly in the l2vpn-signaling >draft. For VPLS the PW-Switching point PE is a BGP speaker, >hence it can >advertise the VPLS with itself as a next hop. This will initiate the >MS-PW segments correctly through the S-PE ( basically , the >BGP speaker >itself ) > See my reply in the summary (for the second part)... > >> Moreover there will be cases where the same PE will have to connect >> its VSI to remote ones using both SS and MS-PWs. How does the PE >> choose when to use one AII type versus the other? Definitely that >> should not happen based on whether the PW goes one hop or multiple >> hops. >> >> >there is no need to choose. In this case , the BGP message contains 2 >piece of information: "please setup a PW to myself" , and " >here is the >VSI you should connect the PW to" I understand and agree with the AD description in L2VPN Signaling. But then during the Signaling step, what stops us from putting "myself" info in the AII type 2 fields? > >This is very different from the MS-PW BGP message that simply >says "you >can reach this PW AC address here" . > >> Everybody will require sooner or later support for MS-PWs. >So I think >> it's a good idea to put in place early in the L2 build up, the L2 >> addressing that will easily accommodate the MS-PW expansion >instead of >> trying to live with 2 addressing plans: one unique per AGI (AII type >> 1), one globally unique (AII type 2). >> >> Focusing on one addressing format will maximize also >technology re-use >> (MS/SS-PWs transparently applicable to Individual VCs, VPWS, >VPLS) and >> will avoid interoperability issues between vendors and SPs. >> >> >The reason we had an AII type field is to allow different provisioning >schemes ... >what would be the point to have only one AII type ? > Yes I agree as long as it is clear that one can't do it easily with existing ones. >Although I think this is fairly complicated, keeping the AII type 1 as >is , ( which is used in a different context ) does not preclude any of >the MS-PW technology from being used. >On the contrary , only using AII type 2 , precludes the autodiscovery >methodology described in the l2vpn-signaling draft, >unless most fields are set to 0 >which gets us right back to AII type 1. I would just say here that we should spend more time discussing options before reaching a conclusion. > >Thanks. >Luca > > >> Regards, >> Florin >> >> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf Of Mustapha Aissaoui >>> Sent: Friday, December 02, 2005 1:58 PM >>> To: 'Luca Martini'; 'L2VPN' >>> Cc: 'David McDysan'; bsd@cisco.com >>> Subject: RE: AII differences between PW routing and l2vpn >>> signalling draftprovisionong methods. >>> >>> >>> Luca, >>> I do not believe there is any substantial difference that >warrants to >>> standardize two different AII types. A MS-PW can also >terminate on a >>> VSI, e.g., VPLS. >>> >>> The issue is to be able to encode the target termination >>> interface: an endpoint for a p2p PW or a VSI for a VPLS in a way >>> such that it will work for both single hop PWs and MS-PWs. Both >>> types can be used for the various L2VPN applications. >>> >>> Pragmatically, the way to go is to deprecate the FEC 129 as defined >>> in draft-ietf-l2vpn-signaling-06.txt (Type 1) and extend the Type 2 >>> to cover the various applications. One other reason to >deprecate Type >>> 1 is that we do not want an implementation to use different FEC 129 >>> types for single-hop PW and MS-PW. FEC 128 will be restricted to >>> singe hop PW and will be fine as long as we specify a way to reach >>> U-PEs which are on a FEC 129 Type 2 network. >>> >>> Mustapha. >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf Of Luca Martini >>> Sent: Friday, December 02, 2005 1:09 PM >>> To: L2VPN >>> Cc: David McDysan; bsd@cisco.com >>> Subject: AII differences between PW routing and l2vpn >>> signalling draft provisionong methods. >>> >>> WG, >>> >>> After a good discussion with Bruce Davie, we came up with the >>> following explanation on why we need to have different AII type int >>> he PW setup and maintenance protocol. This note explains why >>> draft-ietf-l2vpn-signaling-06.txt (the L2VPN Signaling draft) and >>> draft-balus-bocci-martini-dyn-ms-pwe3-00.txt (the MS PW >>> draft) make use of different AII types, as defined in >>> draft-metz-aii-aggregate-01.txt. In a nutshell, the two >>> drafts use different AII types because they are tackling >>> different problems. Specifically, L2VPN Signaling draft is >>> concerned with setting up all the PWs for a given L2VPN, while >>> the MS PW draft is concerned with setting up individual PWs. >>> Because it is concerned with building L2VPNs, the L2VPN >>> Signaling draft makes use of the AGI (the contents of which >>> effectively identify the >>> VPN) plus the AII to identify a particular PW. Hence, the AII >>> only needs to identify a "pool" or a VSI relative to a >>> particular AGI. Hence a simple 32 bit AII is sufficient. By >>> contrast, because the MS PW draft is concerned with setting up >>> individual PWs, not L2VPNs, it has no use for the AGI - there >>> is no "group" concept. Hence it fully identifies the PW in the >>> AII. Because there may be many PWs connected to a given U-PE >>> device, it is necessary to identify the PWs relative to a >>> given U-PE. And it is necessary to identify the U-PE within >>> the AII so that the signaling message can be routed toward the >>> correct U-PE. Hence the requirements for the AII are quite >>> different, and it makes sense to use an AII type that is >>> designed to meet these requirements. It is obvious that the >>> simple AII type could be encoded in the more complex AII type >>> by leaving various fields set to zero, but this does not seem >>> to serve any useful purpose. >>> >>> Luca >>> >>> >>> >>> >>> >>> >>> >> >> > > From l2vpn-bounces@ietf.org Wed Dec 07 07:30:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjyQz-0006Kq-2y; Wed, 07 Dec 2005 07:30:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjyQx-0006JB-Ta; Wed, 07 Dec 2005 07:30:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28147; Wed, 7 Dec 2005 07:29:15 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejyme-0006Ap-5o; Wed, 07 Dec 2005 07:52:32 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jB7CSjv16441; Wed, 7 Dec 2005 07:28:45 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Dec 2005 07:28:43 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650758AEFA@zcarhxm1.corp.nortel.com> Thread-Topic: AII differences between PW routing and l2vpn signallingdraftprovisionong methods. Thread-Index: AcX63RfTb8m8ieWUTOGBvft7vaiGZgAS+CLA From: "Florin Balus" To: "Jixiong Dong" , "pwe3" , "Luca Martini" X-Spam-Score: 0.0 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Content-Transfer-Encoding: quoted-printable Cc: L2VPN , David McDysan , Mustapha Aissaoui , bsd@cisco.com Subject: RE: AII differences between PW routing and l2vpn signallingdraftprovisionong methods. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Dong, [..] >Moreover, I suggest we should reserve the AGI field in ms-pw=20 >signaling so that we can use it for group status notification=20 >or group pw teardown and=20 >so on as indicated in the draft=20 >"draft-ietf-pwe3-control-protocol-17.txt". >When AGI =3D 0, we can ignore this field. There is a TLV already in place for that (see 5.3.2.2 PW Grouping TLV in the above draft)... AGI in my opinion should still be used during the signaling process for the same functionalities as described in L2VPN Signaling: e.g. VPN membership... Regards, Florin > >Regards, >Dong > >----- Original Message -----=20 >From: "Florin Balus" >To: "Luca Martini" >Cc: "L2VPN" ; "David McDysan"=20 >; "Mustapha Aissaoui"=20 >; >Sent: Wednesday, December 07, 2005 12:33 AM >Subject: RE: AII differences between PW routing and l2vpn=20 >signallingdraftprovisionong methods. > > > >Luca, > >It looks like we are making progress here. Let me summarize=20 >what I understood from your follow up: >- you are acknowledging that VPLS/VPWS might use either one or=20 >a combination of both MS and SS-PWs to interconnect their=20 >VSIs/VFs associated with their pools? >- in your view AII type 1 and implicitly the (AGI, 32 bit AII)=20 >addressing scheme solves in the simplest way the provisioning=20 >model for VPLS/VPWS based on Autodiscovery of the endpoints? > >Can you confirm my summary?=20 > >I am happy with the first part. For the second part we should=20 >also note there are a good chunk of L2VPNs (all currently=20 >deployed LDP-VPLS) provisioning models where no AD is=20 >used/available. In my opinion, AII type 2 is a must in these=20 >scenarios whenever at least one MS-PW is involved. That is the=20 >first reason for saying that there is not a clear delineation=20 >- AII type 1 for L2VPNs, type 2 for Individual MS-PWs. > >On the other hand, I agree that until a new scheme for=20 >AD-based provisioning model is described, the one described in=20 >L2VPN Signaling is the only one available. Still I still think=20 >what is happening during the AD process does not dictate=20 >what is included in the fields used for PW Signaling phase.=20 >Furthermore before closing on where each AII type should be=20 >used, I think we should spend some time looking into options=20 >to streamline the BGP AD procedures for the generalized case=20 >(where either a MS/SS-PW may be used for L2VPNs). > >See also in-line... > >Thanks, >Florin > > >>-----Original Message----- >>From: Luca Martini [mailto:lmartini@cisco.com] >>Sent: Monday, December 05, 2005 12:26 PM >>To: Balus, Florin [CAR:6955:EXCH] >>Cc: Mustapha Aissaoui; L2VPN; David McDysan; bsd@cisco.com >>Subject: Re: AII differences between PW routing and l2vpn >>signalling draftprovisionong methods. >> >> >>Florin, >> >>Florin Balus wrote: >>> I agree with Mustapha's proposal: we should just deprecate >>AII type 1 >>> before people start implementing it. All its functionality could be=20 >>> easily reproduced if need be using AII type 2: just set >>Global ID and >>> Prefix fields to zero. L2VPN Signaling itself proposes a similar >>> =20 >>Prefixing the fields to 0 just means that you really have=20 >encoded a new >>AII type , but you are hiding it. > >Is that a problem? Isn't the same thing proposed for BGP=20 >Autodiscovery in L2VPN Signaling: all the NLRI fields from BGP=20 >VPLS SAFI are set to zero except a 32 bits one...=20 > >In any case I just mentioned the above option (set Global ID,=20 >Prefix fields to zero) as a posibility. I don't really see a=20 >problem to include the real values for the Global ID and=20 >Prefix fields when signaling any PW, regardless of whether it=20 >connects VSIs/Pools/VFs, or whether it is SS/MS type. > >>What happens when a new provisioning model comes along ? do=20 >we put all=20 >>the fields to 0xffff ? > >I was speaking about the well known L2VPN models we are aware=20 >of: i.e. individual VCs, VPWS, VPLS. Provisioned or=20 >autodiscovered. I am saying that in all three of them you can=20 >use nicely an AII type 2 to signal the PW building blocks,=20 >without worrying whether it is a SS/MS-PW. As per my first=20 >in-line note, I think it's actually a good idea to include for=20 >all of them Global ID and Prefix field. The AC ID is the only=20 >field that needs to be set to 0 only for non-distributed VPLS. > >> >>> approach for the 32 bits field associated with AII type 1 when it=20 >>> comes to BGP auto-discovery: i.e. just re-use 32 bits from the NLRI=20 >>> for BGP VPLS SAFI and set the other unnecessary fields to zero... >>> >>> Note that AII type 2 will be required for L2VPN addressing: all the=20 >>> Use Cases (e.g. MAN-WAN, Inter-provider, Scalability, private PE >>> addressing) described in MS-PW requirements draft apply also for >>> L2VPNs (PWs being used as infrastructure). >>> >>> So there won't be a clear cut between the 2 cases outlined by Luca >>> below: there will be plenty of scenarios where 2 VSIs (VPLS)/Pools >>> (VPWS) will need to be connected via a MS-PW. >>> >>> =20 >>Yes , and this case is handled properly in the l2vpn-signaling draft.=20 >>For VPLS the PW-Switching point PE is a BGP speaker, hence it can >>advertise the VPLS with itself as a next hop. This will initiate the=20 >>MS-PW segments correctly through the S-PE ( basically , the=20 >>BGP speaker=20 >>itself ) >> > >See my reply in the summary (for the second part)... > >> >>> Moreover there will be cases where the same PE will have to connect=20 >>> its VSI to remote ones using both SS and MS-PWs. How does the PE=20 >>> choose when to use one AII type versus the other? Definitely that=20 >>> should not happen based on whether the PW goes one hop or multiple=20 >>> hops. >>> >>> =20 >>there is no need to choose. In this case , the BGP message contains 2=20 >>piece of information: "please setup a PW to myself" , and "=20 >here is the >>VSI you should connect the PW to" > >I understand and agree with the AD description in L2VPN=20 >Signaling. But then during the Signaling step, what stops us=20 >from putting "myself" info in the AII type 2 fields?=20 >=20 >> >>This is very different from the MS-PW BGP message that simply=20 >says "you >>can reach this PW AC address here" . >> >>> Everybody will require sooner or later support for MS-PWs. >>So I think >>> it's a good idea to put in place early in the L2 build up, the L2=20 >>> addressing that will easily accommodate the MS-PW expansion >>instead of >>> trying to live with 2 addressing plans: one unique per AGI=20 >(AII type=20 >>> 1), one globally unique (AII type 2). >>> >>> Focusing on one addressing format will maximize also >>technology re-use >>> (MS/SS-PWs transparently applicable to Individual VCs, VPWS, >>VPLS) and >>> will avoid interoperability issues between vendors and SPs. >>> >>> =20 >>The reason we had an AII type field is to allow different=20 >provisioning=20 >>schemes ... what would be the point to have only one AII type ? >> > >Yes I agree as long as it is clear that one can't do it easily=20 >with existing ones. > >>Although I think this is fairly complicated, keeping the AII=20 >type 1 as=20 >>is , ( which is used in a different context ) does not=20 >preclude any of=20 >>the MS-PW technology from being used. On the contrary , only=20 >using AII=20 >>type 2 , precludes the autodiscovery methodology described in the=20 >>l2vpn-signaling draft, unless most fields are set to 0 >>which gets us right back to AII type 1. > >I would just say here that we should spend more time=20 >discussing options before reaching a conclusion. > >> >>Thanks. >>Luca >> >> >>> Regards, >>> Florin >>> >>> =20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On=20 >>>> Behalf Of Mustapha Aissaoui >>>> Sent: Friday, December 02, 2005 1:58 PM >>>> To: 'Luca Martini'; 'L2VPN' >>>> Cc: 'David McDysan'; bsd@cisco.com >>>> Subject: RE: AII differences between PW routing and l2vpn=20 >signalling=20 >>>> draftprovisionong methods. >>>> >>>> >>>> Luca, >>>> I do not believe there is any substantial difference that >>warrants to >>>> standardize two different AII types. A MS-PW can also >>terminate on a >>>> VSI, e.g., VPLS. >>>> >>>> The issue is to be able to encode the target termination >>>> interface: an endpoint for a p2p PW or a VSI for a VPLS in a way >>>> such that it will work for both single hop PWs and MS-PWs. Both=20 >>>> types can be used for the various L2VPN applications. >>>> >>>> Pragmatically, the way to go is to deprecate the FEC 129=20 >as defined=20 >>>> in draft-ietf-l2vpn-signaling-06.txt (Type 1) and extend=20 >the Type 2=20 >>>> to cover the various applications. One other reason to >>deprecate Type >>>> 1 is that we do not want an implementation to use=20 >different FEC 129=20 >>>> types for single-hop PW and MS-PW. FEC 128 will be restricted to=20 >>>> singe hop PW and will be fine as long as we specify a way to reach=20 >>>> U-PEs which are on a FEC 129 Type 2 network. >>>> >>>> Mustapha. >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On=20 >>>> Behalf Of Luca Martini >>>> Sent: Friday, December 02, 2005 1:09 PM >>>> To: L2VPN >>>> Cc: David McDysan; bsd@cisco.com >>>> Subject: AII differences between PW routing and l2vpn signalling=20 >>>> draft provisionong methods. >>>> >>>> WG, >>>> >>>> After a good discussion with Bruce Davie, we came up with the=20 >>>> following explanation on why we need to have different AII=20 >type int=20 >>>> he PW setup and maintenance protocol. This note explains why=20 >>>> draft-ietf-l2vpn-signaling-06.txt (the L2VPN Signaling draft) and=20 >>>> draft-balus-bocci-martini-dyn-ms-pwe3-00.txt (the MS PW >>>> draft) make use of different AII types, as defined in >>>> draft-metz-aii-aggregate-01.txt. In a nutshell, the two=20 >>>> drafts use different AII types because they are tackling=20 >>>> different problems. Specifically, L2VPN Signaling draft is=20 >>>> concerned with setting up all the PWs for a given L2VPN, while=20 >>>> the MS PW draft is concerned with setting up individual PWs. =20 >>>> Because it is concerned with building L2VPNs, the L2VPN=20 >>>> Signaling draft makes use of the AGI (the contents of which=20 >>>> effectively identify the >>>> VPN) plus the AII to identify a particular PW. Hence, the AII=20 >>>> only needs to identify a "pool" or a VSI relative to a=20 >>>> particular AGI. Hence a simple 32 bit AII is sufficient. By=20 >>>> contrast, because the MS PW draft is concerned with setting up=20 >>>> individual PWs, not L2VPNs, it has no use for the AGI - there=20 >>>> is no "group" concept. Hence it fully identifies the PW in the=20 >>>> AII. Because there may be many PWs connected to a given U-PE=20 >>>> device, it is necessary to identify the PWs relative to a=20 >>>> given U-PE. And it is necessary to identify the U-PE within=20 >>>> the AII so that the signaling message can be routed toward the=20 >>>> correct U-PE. Hence the requirements for the AII are quite=20 >>>> different, and it makes sense to use an AII type that is=20 >>>> designed to meet these requirements. It is obvious that the=20 >>>> simple AII type could be encoded in the more complex AII type=20 >>>> by leaving various fields set to zero, but this does not seem=20 >>>> to serve any useful purpose. >>>> >>>> Luca >>>> >>>> >>>> >>>> >>>> >>>> >>>> =20 >>> >>> =20 >> >> > > From l2vpn-bounces@ietf.org Wed Dec 07 12:59:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3ZE-0001N3-1W; Wed, 07 Dec 2005 12:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3Z9-0001MD-AR; Wed, 07 Dec 2005 12:58:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05734; Wed, 7 Dec 2005 12:58:03 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek3ut-0000dO-5Q; Wed, 07 Dec 2005 13:21:23 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Ek3Z8-0006xy-0A; Wed, 07 Dec 2005 12:58:54 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 07 Dec 2005 12:58:54 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: l2vpn@ietf.org Subject: Last Call: 'Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks' to Informational RFC X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org The IESG has received a request from the Layer 2 Virtual Private Networks WG to consider the following document: - 'Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements-05.txt From l2vpn-bounces@ietf.org Wed Dec 07 21:58:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkByq-000355-55; Wed, 07 Dec 2005 21:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkBym-00033A-Ez; Wed, 07 Dec 2005 21:57:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13950; Wed, 7 Dec 2005 21:57:03 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkCKZ-0005yw-UW; Wed, 07 Dec 2005 22:20:29 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR500L0ISDLX0@szxga03-in.huawei.com>; Thu, 08 Dec 2005 11:00:58 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR500F49SDLWD@szxga03-in.huawei.com>; Thu, 08 Dec 2005 11:00:57 +0800 (CST) Received: from d10570a ([10.70.77.239]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR500HBPSL8TK@szxml02-in.huawei.com>; Thu, 08 Dec 2005 11:05:32 +0800 (CST) Date: Thu, 08 Dec 2005 10:55:19 +0800 From: Jixiong Dong To: Florin Balus , pwe3 , Luca Martini Message-id: <012e01c5fba2$d35390b0$ef4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <9671A92C3C8B5744BC97F855F7CB64650758AEFA@zcarhxm1.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Content-Transfer-Encoding: 7BIT Cc: L2VPN , David McDysan , Mustapha Aissaoui , bsd@cisco.com Subject: Re: AII differences between PW routing and l2vpn signallingdraftprovisionong methods. 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Florin, I agree with you on this point completely. Thanks, Dong ----- Original Message ----- From: "Florin Balus" To: "Jixiong Dong" ; "pwe3" ; "Luca Martini" Cc: ; "Mustapha Aissaoui" ; "David McDysan" ; "L2VPN" Sent: Wednesday, December 07, 2005 8:28 PM Subject: RE: AII differences between PW routing and l2vpn signallingdraftprovisionong methods. Hi Dong, [..] >Moreover, I suggest we should reserve the AGI field in ms-pw >signaling so that we can use it for group status notification >or group pw teardown and >so on as indicated in the draft >"draft-ietf-pwe3-control-protocol-17.txt". >When AGI = 0, we can ignore this field. There is a TLV already in place for that (see 5.3.2.2 PW Grouping TLV in the above draft)... AGI in my opinion should still be used during the signaling process for the same functionalities as described in L2VPN Signaling: e.g. VPN membership... Regards, Florin > >Regards, >Dong > >----- Original Message ----- >From: "Florin Balus" >To: "Luca Martini" >Cc: "L2VPN" ; "David McDysan" >; "Mustapha Aissaoui" >; >Sent: Wednesday, December 07, 2005 12:33 AM >Subject: RE: AII differences between PW routing and l2vpn >signallingdraftprovisionong methods. > > > >Luca, > >It looks like we are making progress here. Let me summarize >what I understood from your follow up: >- you are acknowledging that VPLS/VPWS might use either one or >a combination of both MS and SS-PWs to interconnect their >VSIs/VFs associated with their pools? >- in your view AII type 1 and implicitly the (AGI, 32 bit AII) >addressing scheme solves in the simplest way the provisioning >model for VPLS/VPWS based on Autodiscovery of the endpoints? > >Can you confirm my summary? > >I am happy with the first part. For the second part we should >also note there are a good chunk of L2VPNs (all currently >deployed LDP-VPLS) provisioning models where no AD is >used/available. In my opinion, AII type 2 is a must in these >scenarios whenever at least one MS-PW is involved. That is the >first reason for saying that there is not a clear delineation >- AII type 1 for L2VPNs, type 2 for Individual MS-PWs. > >On the other hand, I agree that until a new scheme for >AD-based provisioning model is described, the one described in >L2VPN Signaling is the only one available. Still I still think >what is happening during the AD process does not dictate >what is included in the fields used for PW Signaling phase. >Furthermore before closing on where each AII type should be >used, I think we should spend some time looking into options >to streamline the BGP AD procedures for the generalized case >(where either a MS/SS-PW may be used for L2VPNs). > >See also in-line... > >Thanks, >Florin > > >>-----Original Message----- >>From: Luca Martini [mailto:lmartini@cisco.com] >>Sent: Monday, December 05, 2005 12:26 PM >>To: Balus, Florin [CAR:6955:EXCH] >>Cc: Mustapha Aissaoui; L2VPN; David McDysan; bsd@cisco.com >>Subject: Re: AII differences between PW routing and l2vpn >>signalling draftprovisionong methods. >> >> >>Florin, >> >>Florin Balus wrote: >>> I agree with Mustapha's proposal: we should just deprecate >>AII type 1 >>> before people start implementing it. All its functionality could be >>> easily reproduced if need be using AII type 2: just set >>Global ID and >>> Prefix fields to zero. L2VPN Signaling itself proposes a similar >>> >>Prefixing the fields to 0 just means that you really have >encoded a new >>AII type , but you are hiding it. > >Is that a problem? Isn't the same thing proposed for BGP >Autodiscovery in L2VPN Signaling: all the NLRI fields from BGP >VPLS SAFI are set to zero except a 32 bits one... > >In any case I just mentioned the above option (set Global ID, >Prefix fields to zero) as a posibility. I don't really see a >problem to include the real values for the Global ID and >Prefix fields when signaling any PW, regardless of whether it >connects VSIs/Pools/VFs, or whether it is SS/MS type. > >>What happens when a new provisioning model comes along ? do >we put all >>the fields to 0xffff ? > >I was speaking about the well known L2VPN models we are aware >of: i.e. individual VCs, VPWS, VPLS. Provisioned or >autodiscovered. I am saying that in all three of them you can >use nicely an AII type 2 to signal the PW building blocks, >without worrying whether it is a SS/MS-PW. As per my first >in-line note, I think it's actually a good idea to include for >all of them Global ID and Prefix field. The AC ID is the only >field that needs to be set to 0 only for non-distributed VPLS. > >> >>> approach for the 32 bits field associated with AII type 1 when it >>> comes to BGP auto-discovery: i.e. just re-use 32 bits from the NLRI >>> for BGP VPLS SAFI and set the other unnecessary fields to zero... >>> >>> Note that AII type 2 will be required for L2VPN addressing: all the >>> Use Cases (e.g. MAN-WAN, Inter-provider, Scalability, private PE >>> addressing) described in MS-PW requirements draft apply also for >>> L2VPNs (PWs being used as infrastructure). >>> >>> So there won't be a clear cut between the 2 cases outlined by Luca >>> below: there will be plenty of scenarios where 2 VSIs (VPLS)/Pools >>> (VPWS) will need to be connected via a MS-PW. >>> >>> >>Yes , and this case is handled properly in the l2vpn-signaling draft. >>For VPLS the PW-Switching point PE is a BGP speaker, hence it can >>advertise the VPLS with itself as a next hop. This will initiate the >>MS-PW segments correctly through the S-PE ( basically , the >>BGP speaker >>itself ) >> > >See my reply in the summary (for the second part)... > >> >>> Moreover there will be cases where the same PE will have to connect >>> its VSI to remote ones using both SS and MS-PWs. How does the PE >>> choose when to use one AII type versus the other? Definitely that >>> should not happen based on whether the PW goes one hop or multiple >>> hops. >>> >>> >>there is no need to choose. In this case , the BGP message contains 2 >>piece of information: "please setup a PW to myself" , and " >here is the >>VSI you should connect the PW to" > >I understand and agree with the AD description in L2VPN >Signaling. But then during the Signaling step, what stops us >from putting "myself" info in the AII type 2 fields? > >> >>This is very different from the MS-PW BGP message that simply >says "you >>can reach this PW AC address here" . >> >>> Everybody will require sooner or later support for MS-PWs. >>So I think >>> it's a good idea to put in place early in the L2 build up, the L2 >>> addressing that will easily accommodate the MS-PW expansion >>instead of >>> trying to live with 2 addressing plans: one unique per AGI >(AII type >>> 1), one globally unique (AII type 2). >>> >>> Focusing on one addressing format will maximize also >>technology re-use >>> (MS/SS-PWs transparently applicable to Individual VCs, VPWS, >>VPLS) and >>> will avoid interoperability issues between vendors and SPs. >>> >>> >>The reason we had an AII type field is to allow different >provisioning >>schemes ... what would be the point to have only one AII type ? >> > >Yes I agree as long as it is clear that one can't do it easily >with existing ones. > >>Although I think this is fairly complicated, keeping the AII >type 1 as >>is , ( which is used in a different context ) does not >preclude any of >>the MS-PW technology from being used. On the contrary , only >using AII >>type 2 , precludes the autodiscovery methodology described in the >>l2vpn-signaling draft, unless most fields are set to 0 >>which gets us right back to AII type 1. > >I would just say here that we should spend more time >discussing options before reaching a conclusion. > >> >>Thanks. >>Luca >> >> >>> Regards, >>> Florin >>> >>> >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>> Behalf Of Mustapha Aissaoui >>>> Sent: Friday, December 02, 2005 1:58 PM >>>> To: 'Luca Martini'; 'L2VPN' >>>> Cc: 'David McDysan'; bsd@cisco.com >>>> Subject: RE: AII differences between PW routing and l2vpn >signalling >>>> draftprovisionong methods. >>>> >>>> >>>> Luca, >>>> I do not believe there is any substantial difference that >>warrants to >>>> standardize two different AII types. A MS-PW can also >>terminate on a >>>> VSI, e.g., VPLS. >>>> >>>> The issue is to be able to encode the target termination >>>> interface: an endpoint for a p2p PW or a VSI for a VPLS in a way >>>> such that it will work for both single hop PWs and MS-PWs. Both >>>> types can be used for the various L2VPN applications. >>>> >>>> Pragmatically, the way to go is to deprecate the FEC 129 >as defined >>>> in draft-ietf-l2vpn-signaling-06.txt (Type 1) and extend >the Type 2 >>>> to cover the various applications. One other reason to >>deprecate Type >>>> 1 is that we do not want an implementation to use >different FEC 129 >>>> types for single-hop PW and MS-PW. FEC 128 will be restricted to >>>> singe hop PW and will be fine as long as we specify a way to reach >>>> U-PEs which are on a FEC 129 Type 2 network. >>>> >>>> Mustapha. >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>> Behalf Of Luca Martini >>>> Sent: Friday, December 02, 2005 1:09 PM >>>> To: L2VPN >>>> Cc: David McDysan; bsd@cisco.com >>>> Subject: AII differences between PW routing and l2vpn signalling >>>> draft provisionong methods. >>>> >>>> WG, >>>> >>>> After a good discussion with Bruce Davie, we came up with the >>>> following explanation on why we need to have different AII >type int >>>> he PW setup and maintenance protocol. This note explains why >>>> draft-ietf-l2vpn-signaling-06.txt (the L2VPN Signaling draft) and >>>> draft-balus-bocci-martini-dyn-ms-pwe3-00.txt (the MS PW >>>> draft) make use of different AII types, as defined in >>>> draft-metz-aii-aggregate-01.txt. In a nutshell, the two >>>> drafts use different AII types because they are tackling >>>> different problems. Specifically, L2VPN Signaling draft is >>>> concerned with setting up all the PWs for a given L2VPN, while >>>> the MS PW draft is concerned with setting up individual PWs. >>>> Because it is concerned with building L2VPNs, the L2VPN >>>> Signaling draft makes use of the AGI (the contents of which >>>> effectively identify the >>>> VPN) plus the AII to identify a particular PW. Hence, the AII >>>> only needs to identify a "pool" or a VSI relative to a >>>> particular AGI. Hence a simple 32 bit AII is sufficient. By >>>> contrast, because the MS PW draft is concerned with setting up >>>> individual PWs, not L2VPNs, it has no use for the AGI - there >>>> is no "group" concept. Hence it fully identifies the PW in the >>>> AII. Because there may be many PWs connected to a given U-PE >>>> device, it is necessary to identify the PWs relative to a >>>> given U-PE. And it is necessary to identify the U-PE within >>>> the AII so that the signaling message can be routed toward the >>>> correct U-PE. Hence the requirements for the AII are quite >>>> different, and it makes sense to use an AII type that is >>>> designed to meet these requirements. It is obvious that the >>>> simple AII type could be encoded in the more complex AII type >>>> by leaving various fields set to zero, but this does not seem >>>> to serve any useful purpose. >>>> >>>> Luca >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > > From l2vpn-bounces@ietf.org Wed Dec 07 23:35:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkDV4-0007cV-Uf; Wed, 07 Dec 2005 23:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkDV3-0007cP-0a for l2vpn@megatron.ietf.org; Wed, 07 Dec 2005 23:35:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21650; Wed, 7 Dec 2005 23:34:27 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkDqr-0000Ef-L7; Wed, 07 Dec 2005 23:57:54 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id E0A4764351; Wed, 7 Dec 2005 21:34:43 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E9CCE07-4B8B-4861-AA12-450BD6C361F6@castlepoint.net> Content-Transfer-Encoding: 7bit From: Shane Amante Date: Wed, 7 Dec 2005 21:34:48 -0700 To: Mark Townsley , margaret@thingmagic.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, iesg-secretary@ietf.org Subject: Request to advance l2vpn-signaling to Proposed Standard 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Mark, Margaret, On behalf of the L2VPN WG would like to request draft-ietf-l2vpn- signaling-06.txt be published as a RFC in the Proposed Standard category. Provisioning, Autodiscovery, and Signaling in L2VPNs http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-06.txt The Working Group Last Call for this document was completed on 9/6/2005, with minor comments from Yakov Rehkter & Hamid Ould-Brahim being incorporated into the I-D. Thank you for your time and consideration, -shane & Vach From l2vpn-bounces@ietf.org Thu Dec 08 12:38:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPis-0004BL-Dr; Thu, 08 Dec 2005 12:38:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPio-0004A5-OA; Thu, 08 Dec 2005 12:38:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15286; Thu, 8 Dec 2005 12:37:29 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkPiq-0001QW-Nr; Thu, 08 Dec 2005 12:38:24 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EkPio-000878-6t; Thu, 08 Dec 2005 12:38:22 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 08 Dec 2005 12:38:22 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: l2vpn@ietf.org Subject: Last Call: 'Provisioning, Autodiscovery, and Signaling in L2VPNs' to Proposed Standard X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org The IESG has received a request from the Layer 2 Virtual Private Networks WG to consider the following document: - 'Provisioning, Autodiscovery, and Signaling in L2VPNs ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-06.txt From l2vpn-bounces@ietf.org Thu Dec 08 22:08:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkYc7-0000lA-1f; Thu, 08 Dec 2005 22:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkYbz-0000h2-85; Thu, 08 Dec 2005 22:08:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26649; Thu, 8 Dec 2005 22:06:54 -0500 (EST) Received: from hostree9f.alcatel.com ([143.209.238.159] helo=audl952.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkYbu-0008N5-KC; Thu, 08 Dec 2005 22:07:54 -0500 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id jB937SDM023419; Thu, 8 Dec 2005 21:07:28 -0600 Received: from venuxp (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id jB937dn7003451; Thu, 8 Dec 2005 19:07:41 -0800 (PST) From: "Venu Hemige" To: "'Fil Dickinson'" , "'Suresh Boddapati'" , "'Yakov Rekhter'" , "'Shane Amante'" Date: Thu, 8 Dec 2005 19:09:30 -0800 Message-ID: <014801c5fc6d$f9a93d20$4ebb16ac@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-reply-to: <799B0CDA650143429C5EA103965B59F8011B6061@shqw2ke001.optus.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, pim@ietf.org Subject: RE: [pim] RE: PIM Snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: venu.hemige@alcatel.com List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Fil, Agree with you in general that hacks should be avoided. And hacks can be easily avoided in PIM-Snooping if CE devices disable PIM Join suppression. This is exactly the way draft-hemige-serbest-l2vpn-vpls-pim-snooping-00 is written. However, the arguments against it have been that 1. A provider has to co-ordinate with his customers to make sure PIM Join suppression is disabled on all CEs in the VPLS. 2. Existing CEs that have already been deployed may not even support the capability to disable PIM Join suppression. So if we make it a requirement for CEs to disable PIM Join Suppression, it may mean that CEs will have to be upgraded to allow for this option. So the concern has been that it may not be a practical solution to require CEs to disable PIM Join Suppression. With what Suresh is suggesting, you lose some of the transparency of VPLS. But the transparency is lost only for PIM control packets in the VPLS. All other packet types are (more importantly data packets) are still transparent. Please note that this is not the first time such a deviation is being proposed. IGMP Proxy is a commonly deployed solution which employs similar hacks in the interest of scalability. By doing what Suresh is suggesting, 1. a provider does not have to worry about coordinating with his customers to get PIM join suppression disabled. 2. it allows for VPLS Multicast to scale much better. E.g. If N downstream CEs send Join(S,G) to an upstream CE, the PEs in between can intelligently forward only one Join(S,G) to the upstream CE. Similar procedures for prunes can be applied as well. Regards, -Venu > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of Fil > Dickinson > Sent: Thursday, December 01, 2005 10:04 PM > To: Suresh Boddapati; Yakov Rekhter; Shane Amante > Cc: l2vpn@ietf.org; pim@ietf.org > Subject: [pim] RE: PIM Snooping > > Suresh. > My opinion. I would like any "hacks", "tweaks" or "work arounds" to > occur on the CE router. > This is because as a provider I want to eliminate as many non-standard > elements from my edge and core as possible, having them taken care of > further out where I have more flexibility in development [and diminished > responsibility for support;-)]. > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Suresh Boddapati > Sent: Friday, 2 December 2005 2:05 PM > To: 'Yakov Rekhter'; 'Shane Amante' > Cc: l2vpn@ietf.org; pim@ietf.org > Subject: RE: PIM Snooping > > > > Since there was little, if any, consensus in Vancouver as to the > best > > > direction forward with the PIM snooping work, we would like to hear > from > > > the WG: > > > A) Should we require disabling Join Suppression on CE's? > > > B) Should we NOT require disabling Join Suppression on CE's, thereby > > > > making the PE a more active element in PIM procedures in a VPLS? > > > C) Other, more palatable, suggestions? > > > > > > Please answer the above questions and feel free to add color > commentary > > > as to other issues or concerns not identified above. > > > > Wrt (B) what are the implications of making the PE a "more active > > element" on the externally visible behavior (where by "externall > > visible" I mean visible to a VPLS customer) ? > > > The implications are that a customer router connected to a PE will not > necessarily see the same packet that its counterpart at another PE > generated. The packets may be modified, consumed and/or generated by PEs > on behalf of customer routers. > > > Specifically would a VPLS customer be able to distinguish between the > > cases where a PE operates as specified today, and making the PE "a > > more active element in PIM procedures in a VPLS" ? > > > Not necessarily. The whole idea of making the PE an active element would > be to ensure that nothing has to change in C routers, the multicast > states will be built as before. The only difference is that the C > routers may end up seeing different packets than what they used to > before. > > Let us consider what a "more active element" in this context means. > Consider an example where there are three PEs: PE1, PE2, PE3. > PE1 has the upstream router U and a downstream router D1 connected to > it on the same AC. > PE2 has a downstream router D2. > PE3 has a downstream router D3. > > In order for snooping to build states correctly: > 1)If D2 sends a Join to U, we don't want D3 to see the Join because if > it did, then it would suppress its Join and the pseudowire PE1-PE3 will > not receive the traffic (since PE1 never saw a Join on PE1-PE3). This > would not be a problem if all C routers disabled Join suppression and > did explicit tracking. > > 2)If D2 sends a Prune to U, we want D3 to see the Prune so that it can > override it. Same would apply if D1 sent a Prune to U; you want D2 and > D3 to see it so that they can override the Prune. Again, this would not > be a problem if Join suppression was disabled. > > It would be easy to solve the problem without requiring disabling of > Join suppression if Joins and Prunes were separate messages - just > unicast Joins (by modifying the dest mac to the upstream router's mac) > and multicast Prunes. But Joins and Prunes can be in the SAME JP message > and that's where it becomes more complicated. > > If we want to preserve the transparency to the C routers (i.e. not > requiring them to disable Join suppression), then the PEs will have to > do something like: > > 1) Consume the Join/Prune messages seen on the AC. This means we might > have to consume other PIM packets (Hello, Assert, BSM) and then send > them so that the ordering between the messages is preserved. (An Assert > sent to an upstream router that does not have a downstream state will be > dropped, for example, since the Join came after the Assert when actually > it was sent before the Assert). > 2) Separate the Joins from the Prunes: This means the PE is generating > packets on behalf of the C routers. > 3) Unicast joins to the upstream router and multicast the Prunes to all > routers. > > There may be other ways of doing this, but essentially, we are trying to > make the PEs make up for Join Suppression not being disabled in the VPLS > by simulating it. The downside is we are no longer plain "snooping", we > are also an active participant. Of course, there are also some benefits > to doing this. Since the PE is assuming a Proxy role, if it has already > signaled a Join for an (S,G) on a PW (due to having received one on an > AC), it need not signal Joins for the same state if they arrive on other > ACs, as long as it keeps track of how many ACs sent the Joins. This way, > the number of Join states sent on the PWs is also reduced. > > So the question boils down to: Is this the direction we want to go in > i.e. have the PEs assume a Proxy role so that the C routers do not have > to change OR should we require C routers to disable Join suppression and > do explicit tracking. There is a tradeoff here: > 1) If we want to preserve the transparency to the C routers (a > reasonable goal indeed), the proxy procedures might be perceived by some > as "hacks". It was said so in the previous IETF at Paris. But that is > the cost of preserving the transparency. > 2) If we want to keep the snooping procedures straightforward without > any modifications to the C packets, then the C routers have to disable > Join suppression. It was suggested at the Vancover IETF that this is an > unreasonable requirement since most routers do not support Explicit > tracking today. This is a good point too. > > Both the approaches have merits and demerits. We would like opinions on > what the WGs think is the best approach. Thanks. > > Suresh > > > > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www1.ietf.org/mailman/listinfo/pim From l2vpn-bounces@ietf.org Thu Dec 08 22:35:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkZ2n-0003ug-6u; Thu, 08 Dec 2005 22:35:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkZ2m-0003u8-3m for l2vpn@megatron.ietf.org; Thu, 08 Dec 2005 22:35:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29171 for ; Thu, 8 Dec 2005 22:34:32 -0500 (EST) Received: from hostreea2.alcatel.com ([143.209.238.162] helo=audl953.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkZ2h-0000ka-US for l2vpn@ietf.org; Thu, 08 Dec 2005 22:35:33 -0500 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id jB93ZDmA020792; Thu, 8 Dec 2005 21:35:13 -0600 Received: from venuxp (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id jB93ZPn7003519; Thu, 8 Dec 2005 19:35:26 -0800 (PST) From: "Venu Hemige" To: , "'Shane Amante'" Date: Thu, 8 Dec 2005 19:37:16 -0800 Message-ID: <014901c5fc71$da7f5890$4ebb16ac@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-reply-to: <200511291800.jATI0Lln003077@rtp-core-1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org Subject: RE: PIM Snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: venu.hemige@alcatel.com List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Eric, Please see comments inline > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Eric Rosen > Sent: Tuesday, November 29, 2005 10:00 AM > To: Shane Amante > Cc: l2vpn@ietf.org > Subject: Re: PIM Snooping > > > > Should we require disabling Join Suppression on CE's? > > Oh, it's worse than that. We'd also have to prohibit CEs from > ever > implementing PIM refresh reduction (if such a thing ever comes to be), > from > ever running PIM over TCP (if such a thing ever comes to be), etc. > Well, > it's a good thing the customer has bought an L2 service, to which all the > L3 > protocols are transparent ;-) There are already solutions deployed today by many vendors that make the L2 service not so transparent ;-). Obviously, these are done because they provide a better solution to the customer. As Yakov points out, PIM-Snooping is already employed in Ethernet switches. We should work towards requiring the PIM refresh reduction solution to be friendly to PIM-Snooping. The requirement for refresh reduction may very well come from l3vpn multicast. But PIM WG is building a generic refresh reduction solution and as such it should be friendly to other technologies like PIM Snooping as well. > > And remember, it's not just CEs that are "directly" connected to PEs, > it's > all routers on a LAN which is bridged to a PE. True. But what is the problem you see here? > > > Should we NOT require disabling Join Suppression on CE's, thereby > making > > the PE a more active element in PIM procedures in a VPLS? > > At least the PE would only have to understand the customer's > multicast > routing, it wouldn't have to understand anything really complicated, > like > the customer's unicast routing ;-) > Whether we adopt a solution that requires CEs to disable Join suppression or not, PEs will not have to understand the customer's unicast routing. We are not suggesting to make the PE a router. > Maybe we should step back and look at what we're doing here. We would be interested in hearing alternate solutions if they are better. As is evident from the requirements draft, VPLS Multicast is becoming an important requirement to Providers. We have not seen any solutions other than PIM Snooping on the table. Suggestions to make the PIM Snooping solution better are always welcome. Regards, -Venu From l2vpn-bounces@ietf.org Wed Dec 14 09:57:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmY4K-00057j-CP; Wed, 14 Dec 2005 09:57:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmY4G-00056n-E8; Wed, 14 Dec 2005 09:57:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05888; Wed, 14 Dec 2005 09:56:10 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmY5C-0001n9-Kl; Wed, 14 Dec 2005 09:58:20 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jBEEun039691; Wed, 14 Dec 2005 06:56:49 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jBEEua597534; Wed, 14 Dec 2005 06:56:36 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200512141456.jBEEua597534@merlot.juniper.net> To: "Suresh Boddapati" In-Reply-To: Your message of "Thu, 01 Dec 2005 19:04:58 PST." <02da01c5f6ed$2e28b930$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5195.1134572196.1@juniper.net> Date: Wed, 14 Dec 2005 06:56:36 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: l2vpn@ietf.org, 'Shane Amante' , pim@ietf.org Subject: Re: PIM Snooping 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Suresh, [clipped...] > If we want to preserve the transparency to the C routers (i.e. not > requiring them to disable Join suppression), then the PEs will have to > do something like: > > 1) Consume the Join/Prune messages seen on the AC. This means we might > have to consume other PIM packets (Hello, Assert, BSM) and then send > them so that the ordering between the messages is preserved. (An Assert > sent to an upstream router that does not have a downstream state will be > dropped, for example, since the Join came after the Assert when actually > it was sent before the Assert). > 2) Separate the Joins from the Prunes: This means the PE is generating > packets on behalf of the C routers. > 3) Unicast joins to the upstream router and multicast the Prunes to all > routers. How the above would work (especially the part where the PE is generating packets on behalf of the C routers) if one uses IPSec authentication header to provide data integrity protection and data origin authentication of PIM protocol messages ? Yakov. From l2vpn-bounces@ietf.org Thu Dec 15 14:07:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmyS0-00034X-QO; Thu, 15 Dec 2005 14:07:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmyRs-0002z6-UY; Thu, 15 Dec 2005 14:07:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18900; Thu, 15 Dec 2005 14:06:18 -0500 (EST) Received: from hostree9f.alcatel.com ([143.209.238.159] helo=audl952.usa.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmyT9-0005tB-BQ; Thu, 15 Dec 2005 14:08:48 -0500 Received: from alcatelxp ([172.22.187.74]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id jBFJ73rd015441; Thu, 15 Dec 2005 13:07:03 -0600 From: "Suresh Boddapati" To: "'Yakov Rekhter'" Date: Thu, 15 Dec 2005 11:05:40 -0800 Message-ID: <001801c601aa$8a99ef50$4abb16ac@alcatelxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-reply-to: <200512141456.jBEEua597534@merlot.juniper.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, 'Shane Amante' , pim@ietf.org Subject: RE: PIM Snooping 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org . > > How the above would work (especially the part where the PE is > generating packets on behalf of the C routers) if one uses IPSec > authentication header to provide data integrity protection and data > origin authentication of PIM protocol messages ? > Yakov, you make a good point. I am not an IPSEC expert, but it seems like if authentication header is used, then we will still be able to snoop, but will not be able to do proxy, since we won't have the security associations. I guess we need to make some hard calls here. If the requirement is not to require CE routers to disable Join Suppression, then proxy as a solution does not still give you pure plug and play in at least one case that you pointed out. Plus, the solution has more complexity than just snooping. This seems like one more argument to not go the proxy way and stick with pure snooping. Another thing to consider is how many routers actually support authentication of PIM packets using IPSEC and how many deployments of this are out there. If they plan to move to an authentication scheme in the future, they anyway have to upgrade (assuming all routers do not support this), in which case requiring disabling Join suppression may still be ok. What do you think? Thanks, Suresh From l2vpn-bounces@ietf.org Fri Dec 16 08:58:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnG6Y-0006hh-MN; Fri, 16 Dec 2005 08:58:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnG6X-0006hV-Ez; Fri, 16 Dec 2005 08:58:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21201; Fri, 16 Dec 2005 08:57:37 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnG88-00081X-Av; Fri, 16 Dec 2005 09:00:17 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Dec 2005 14:58:22 +0100 Received: from l-at8613.rd.francetelecom.fr ([10.193.15.49]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Dec 2005 14:58:21 +0100 From: Thomas Morin To: Toerless Eckert In-Reply-To: <20051215135844.J25829@cisco.com> References: <20051215135844.J25829@cisco.com> Content-Type: text/plain; charset=utf-8 Organization: France Telecom R&D Date: Fri, 16 Dec 2005 14:58:06 +0100 Message-Id: <1134741486.1791.19.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 16 Dec 2005 13:58:22.0023 (UTC) FILETIME=[C6A4D570:01C60248] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, pim@ietf.org, 'Shane Amante' Subject: Re: [pim] RE: PIM Snooping 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi folks, Toerless Eckert: > What i still don't understand is how IGMP Snoping or PIM Snooping > are considered to be acceptable within the scope of L2VPNs. I > quite frankly think that it is important to point out that > using these two mechanisms very much breaks the transparency > expectation that traditionally has been the primary reason of > a customer to buy into an L2VPN service instead of let's say > an L3VPN service.=20 >=20 > In my opinion, L2VPN is perfectly fine as long as the service > required for multicast works well without snooping on PE nodes > (aka: broadcast type multicast traffic), but once you need to > have traffic constrainment only achievale with snooping, you should > seriously consider an L3VPN service, because effectively you are > running exactly the same tree building mechanisms now, just that > in L3VPN you are making it based on explicit, standardized > protocol interactions, and in L2VPN you would need to trust and pray > for vendor specific PIM Snooping functionality to be compatible > with the particular set of functions in PIM / IGMP that you as > the customer are relying on - like Bidir, DR/DF priorities, any > extensions like Proxies for InterAS, or for Dino's membership counting, > different address families (IPv4, IPv6),... >=20 > I don't understand why the base requirements of L2VPN services don't > have a very strong statement about this basic principle - transparency > of the service, and independence of protocol properties used on CE > from what the SP is using. Just to mitigate this one statement : there actually is some text about snooping/transparency related considerations (4.1.2 =C2=A74), asking for careful design choices, etc. Though you might consider the wording not strong enough depending on how hard you feel about snooping. > Surely each of the vendors will implement as much PIM, IGMP and foobar > snooping as they can make money with, and that certainly includes > Cisco, but that doesn't make it really a good thing to pursue that > type of approach in the IETF. For example, we also have two drafts > on IGMP out: one for IGMP snooping, the oher one for IGMP proxy > routing. The proxy-routing is tageted for standards track, the snoping > one just informational. That's i think as far as any other technology > that depends on or describes snooping should go in the IETF. I agree : it has to be kept in mind that snooping is a design trade-off. Cheers, -Thomas From l2vpn-bounces@ietf.org Sun Dec 18 20:08:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo9W6-0004B8-PN; Sun, 18 Dec 2005 20:08:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo9W5-0004Ak-Gq for l2vpn@megatron.ietf.org; Sun, 18 Dec 2005 20:08:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16575 for ; Sun, 18 Dec 2005 20:07:38 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eo9YB-0004vC-Js for l2vpn@ietf.org; Sun, 18 Dec 2005 20:10:52 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 98E95644D2 for ; Sun, 18 Dec 2005 18:08:05 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <08C63A4D-69A8-48A8-80DC-9945AB95CF84@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: l2vpn@ietf.org From: Shane Amante Date: Sun, 18 Dec 2005 18:08:10 -0700 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: WG Last Call: draft-ietf-l2vpn-ipls-05.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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Folks, This note starts a WG Last Call for comments on: draft-ietf-l2vpn- ipls-05.txt, "IP-Only LAN Service (IPLS)". It can be found at: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-ipls-05.txt Please thoroughly review the document and send any comments to the list. Also, please indicate whether you do or do not believe this document is ready to go to the IESG. Due to the holidays, the WG Last Call will end on 13 Jan 2006 at 1700 MST (UTC/GMT -7). -shane From l2vpn-bounces@ietf.org Thu Dec 29 15:50:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es4jA-00069T-Ag; Thu, 29 Dec 2005 15:50:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es4iq-000629-5e; Thu, 29 Dec 2005 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12392; Thu, 29 Dec 2005 15:48:51 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es4n8-0002aJ-Br; Thu, 29 Dec 2005 15:54:30 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Es4in-0002oh-Sy; Thu, 29 Dec 2005 15:50:01 -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: Thu, 29 Dec 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-bgp-06.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: , Sender: l2vpn-bounces@ietf.org 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 : Virtual Private LAN Service Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-l2vpn-vpls-bgp-06.txt Pages : 34 Date : 2005-12-29 Virtual Private LAN (Local Area Network) Service (VPLS), also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bgp-06.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-bgp-06.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-bgp-06.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: <2005-12-29145945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-vpls-bgp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-bgp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-29145945.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Thu Dec 29 16:19:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es5BR-0003tG-SN; Thu, 29 Dec 2005 16:19:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es5BQ-0003t8-HP for l2vpn@megatron.ietf.org; Thu, 29 Dec 2005 16:19:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19251 for ; Thu, 29 Dec 2005 16:18:25 -0500 (EST) Received: from lin1-118-39-26.ciena.com ([63.118.39.26] helo=mdmxm01.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es5Fj-00050Y-1F for l2vpn@ietf.org; Thu, 29 Dec 2005 16:24:04 -0500 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm01.ciena.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Dec 2005 16:19:21 -0500 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_01C60CBD.87C92E41" Date: Thu, 29 Dec 2005 16:19:19 -0500 Message-ID: Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCg== From: "Shah, Himanshu" To: X-OriginalArrivalTime: 29 Dec 2005 21:19:21.0119 (UTC) FILETIME=[88DD3AF0:01C60CBD] X-Spam-Score: 0.5 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Subject: VPLS question on MAC address withdrawal 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: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C60CBD.87C92E41 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hope somebody can shed light on the following questions.... (1) There are two mechanisms described -=20 MAC address withdraw List TLV and empty MAC Address withdraw List TLV cut-and-paste from draft. 6.2.2. Address Withdraw Message Containing MAC List TLV=20 =20 The processing for MAC List TLV received in an Address Withdraw=20 Message is:=20 =20 For each MAC address in the TLV:=20 - Remove the association between the MAC address and the AC or=20 PW over which this message is received=20 =20 For a MAC Address Withdraw message with empty list:=20 - Remove all the MAC addresses associated with the VPLS=20 instance (specified by the FEC TLV) except the MAC addresses=20 learned over the PW associated with this signaling session=20 over which the message was received=20 =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in=20 the MAC Address Withdraw Message. The number of MAC addresses can=20 be deduced from the length field in the TLV.=20 To simplify the problem, lets assume that for a given VPLS instance A = there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd = MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite = result. That is, sending=20 explicit list will cause the receiver to remove all 5 addresses (lets = assume that they all were associated with sender). But by sending, empty MAC-address-withdrawal = list, it will remove=20 none. However, the draft says, In order to minimize the impact on LDP convergence time, when the=20 MAC list TLV contains a large number of MAC addresses, it may be=20 preferable to send a MAC address withdrawal message with an empty=20 list.=20 (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to = U-PW, etc needs to be described. regards, himanshu Himanshu Shah Ciena Corp=20 ------_=_NextPart_001_01C60CBD.87C92E41 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable VPLS question on MAC address withdrawal

Hope somebody can shed light on = the following questions....

(1)
There are two mechanisms = described -
MAC address withdraw List TLV = and empty MAC Address withdraw List TLV

cut-and-paste from draft.

6.2.2. Address Withdraw Message = Containing MAC List TLV
  
  The processing for MAC List TLV received in an Address = Withdraw
  Message is:
  
  For each MAC address in the TLV:
     - Remove the association between the MAC = address and the AC or
        PW over which this message is = received
  
  For a MAC Address Withdraw message with empty list:
     - Remove all the MAC addresses associated with = the VPLS
        instance  (specified by = the FEC TLV) except the MAC addresses
        learned over the PW = associated with this signaling session
        over which the message was = received
  
  The scope of a MAC List TLV is the VPLS specified in the FEC TLV = in
  the MAC Address Withdraw Message.  The number of MAC = addresses can
  be deduced from the length field in the TLV.

To simplify the problem, lets = assume that for a given VPLS instance A there are only 5 MAC
addresses and one PW. In this = case, for TCN-Triggererd MAC-address-withdrawal, sending
a list of 5 MAC address vs = sending an empty list achieves opposite result. That is, sending
explicit list will cause the = receiver to remove all 5 addresses (lets assume that they all = were
associated with sender). But by = sending, empty MAC-address-withdrawal list, it will remove
none.  However, the draft = says,

In order to minimize the impact = on LDP convergence time, when the
  MAC list TLV contains a large number of MAC addresses, it may = be
  preferable to send a MAC address withdrawal message with an = empty
  list.

(2)
Is MAC-Address-withdraw = mechanism ever intended to be used for U-PW (user facing PW, = MTU-S<->PErs)?
If so, how, when, implication = of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to
be described.

regards,
himanshu

Himanshu Shah
Ciena Corp

------_=_NextPart_001_01C60CBD.87C92E41--