From l3vpn-bounces@ietf.org Tue Apr 04 09:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlqp-0002eJ-BH; Tue, 04 Apr 2006 09:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlqn-0002eE-SN for l3vpn@ietf.org; Tue, 04 Apr 2006 09:45:41 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQlqm-00069y-LG for l3vpn@ietf.org; Tue, 04 Apr 2006 09:45:41 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 04 Apr 2006 06:45:40 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208"; a="537743750:sNHT21139764" Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 09:45:39 -0400 Message-ID: <44327880.2000201@juniper.net> Date: Tue, 04 Apr 2006 09:45:36 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2006 13:45:39.0216 (UTC) FILETIME=[0F007900:01C657EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: LAST CALL: draft-ietf-l3vpn-ppvpn-mcast-reqts-05 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Folks, This ends the last call on draft-ietf-l3vpn-ppvpn-mcast-reqts-05. Thomas, In your response to Tom Nadeau, did you mention that there would be another spin of the draft. If you could produce that, I will send it on to the IESG for publication as INFORMATIONAL. -r From l3vpn-bounces@ietf.org Tue Apr 04 10:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmwa-0001Ic-Av; Tue, 04 Apr 2006 10:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmwY-0001IN-50 for l3vpn@ietf.org; Tue, 04 Apr 2006 10:55:42 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmwW-0001Te-UC for l3vpn@ietf.org; Tue, 04 Apr 2006 10:55:42 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 04 Apr 2006 07:55:40 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208"; a="540942405:sNHT21484724" Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 10:55:39 -0400 Message-ID: <443288E9.1080703@juniper.net> Date: Tue, 04 Apr 2006 10:55:37 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2006 14:55:39.0592 (UTC) FILETIME=[D69EFC80:01C657F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Folks, Since the list has been pretty quiet lately, I would like to entertain discussion regarding whether draft-kulmala-l3vpn-interas-option-d-02 should become a working group item. I am particularly interested in hearing from operators, but everybody is welcomed to join in the discussion. -r From l3vpn-bounces@ietf.org Tue Apr 04 11:37:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnau-0002Ri-Rb; Tue, 04 Apr 2006 11:37:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnas-0002RY-TJ for l3vpn@ietf.org; Tue, 04 Apr 2006 11:37:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQm8j-0007Br-JV for l3vpn@ietf.org; Tue, 04 Apr 2006 10:04:13 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FQlwp-0001l5-Px for l3vpn@ietf.org; Tue, 04 Apr 2006 09:51:57 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 04 Apr 2006 06:51:55 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208"; a="537744723:sNHT24600768" Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 09:51:53 -0400 Message-ID: <443279F7.6020505@juniper.net> Date: Tue, 04 Apr 2006 09:51:51 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2006 13:51:53.0988 (UTC) FILETIME=[EE622440:01C657EE] X-Spam-Score: -1.1 (-) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Subject: IETF 65 minutes X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Folks, Please review these minute from our meeting in Dallas. If I hear no objections, I will post them on Friday. Ron P.S. Thanks to the minute takers. ===================================================================== Layer 3 Virtual Private Networks (Internet Area) TUESDAY, March 21, 2006 ======================= Chairs: Ross Callon Rick Wilder Ron Bonica Agenda: 17:40-17:50 Working Group Status - R. Bonica 17:50-18:05 Inter AS option for BGP/MPLS IP VPN - M. Halstead draft-kulmala-l3vpn-interas-option-d-02 18:05-18:20 Reqs for MPLS Services Over L3VPN - K. Kumaki draft-kumaki-l3vpn-e2e-rsvp-te-reqts-00 18:20-18:35 Multicast Requirements - T. Morin draft-ietf-l3vpn-ppvpn-mcast-reqts-05 18:50-19:35 Multicast Solutions - E. Rosen, R. Aggarwal draft-ietf-l3vpn-2547bis-mcast-01 draft-raggarwa-l3vpn-2547bis-mcast-bgp-01 19:35-19:50 Multicast Experience - Y. Cai draft-ycai-mvpn-experience-00.txt Alex Zinin asked for a change in the Agenda - try to fit Sam Hartman in for a security issues overview sometime during the first hour. One of the presenters will be unable to attend. Sam can talk during the slot assigned to that individual. Working Group Status - R. Bonica Available at http://tools.ietf.org/wg/l3vpn: Inter AS option for BGP/MPLS IP VPN - M. Halstead - draft-kulmala-l3vpn-interas-option-d-02 See presentation. Should we adopt this as a working group document. Ron Bonica asked a question about slide 3 - is there a mapping function at the ASBR for adapting RT/RD in one AS to RT/RD in another. Not a mapping so much as a replacement, the upshot is that there is no requirement to coordinate between one AS and another. Ron then asked a question about slide 4 - ??? Something about service providers not wanting to share a view od their internal VPN with another service provider. Yakov Rehkter asked a question about slide 3 - ??? Load balancing issues drive use of unique RDs at the ASBR. Ron Bonica asked for a show of hands for people who read the draft? A few. Ron then asked for a show of hands for operators in the room? Not many. Ron asked for hands of those in favor of adopting? A few. Ron then asked for hands those against adopting? None. Take it to the list... =============================================================== Mark Townsley talked about work he and Sam Hartman did on l3vpn security issues. Sam has gone through all the documents and understands the VPN technology. There are issues that are "sticking" the MPLS/GRE and L2TP(?) Mark then said that he had completed his update and turned the meeting back over to the WG. =============================================================== Multicast Requirements - T. Morin - draft-ietf-l3vpn-ppvpn-mcast-reqts-05 Mr Morin was not in. Ron started to show his slides, but then said they were available. The draft will be going to last call as soon as possible after the meeting. There was a discussion (rat-hole) on RFC 1264 issues and the fact that this document includes some IPv6 "stuff" that has not been implemented. =============================================================== Christian Jaquinet gave a presentation on draft-halstead-guichard-mavs-requirements-01.txt See slides. =============================================================== 18:50-19:35 Multicast Solutions - E. Rosen, R. Aggarwal draft-ietf-l3vpn-2547bis-mcast-01 draft-raggarwa-l3vpn-2547bis-mcast-bgp-01 See presentation. Eric Rosen summarized the current status of the work on these drafts. R. Aggarwal continued presentation on inter-AS MVPN specific details. Eric Rosen continued with a few topical discussion points, a mention of things they yet need to do and a wrap up. Dave Thaler - what is the impact of dampening the joins and not the prunes (or vice versa) Ron Bonica (individual) - raised a concern about the permutations of the various options and asked if there were some combinations that don't make sense in any application. So, would it make some sense to provide application examples for each combination? Eric said that this should be in a different document because it will add more issues to generate disagreement. Luyuan Fong - asked what the difference is in the multi-homing case between unicast and multicast? Also, how will a customer set the options they us in the multi-AS. Eric Rosen said that we have so many options now because people asked for them. Yakov Rekhter said that not everyone is going to make the same choices, consequently, there are different options. Ron said that all this is true, but - at some point we will have to decide which of the various options/combinations will get fleshed out. Yakov said that we could define a "must implement" subset and still not dictate what different implementations actually do. Mark Townsley said that would make his job easier. =============================================================== 19:35-19:50 Multicast Experience - Y. Cai draft-ycai-mvpn-experience-00.txt Yiqun Cai gave a presentation on this draft. See slides. From l3vpn-bounces@ietf.org Mon Apr 10 15:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2Ok-0006Ho-RX; Mon, 10 Apr 2006 15:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2Og-0006Gf-D9; Mon, 10 Apr 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT2Of-0008RW-VW; Mon, 10 Apr 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3AJo1BX021081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FT2Of-0007lw-Ne; Mon, 10 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 10 Apr 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-07.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-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 3 Virtual Private Networks Working Group of the IETF. Title : Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs Author(s) : H. Ould-Brahim, et al. Filename : draft-ietf-l3vpn-bgpvpn-auto-07.txt Pages : 12 Date : 2006-4-10 In any provider-based VPN scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The main purpose of an auto-discovery mechanism is to enable a PE to dynamically discover the set of remote PEs having VPN members in common. The auto-discovery mechanism proceeds by having a PE advertises to other PEs, at a minimum, its own IP address and the list of VPN members configured on that PE. Once that information is received the remote PEs will then identify the list of VPN members they have in common with the advertising PE, and use the information carried within the discovery mechanism to establish VPN connectivity. This draft defines a BGP based auto-discovery mechanism for Virtual Router-based layer-3 VPNs. This mechanism is based on the approach used by BGP/MPLS-IP-VPN for distributing VPN routing information within the service provider(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-07.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-l3vpn-bgpvpn-auto-07.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-l3vpn-bgpvpn-auto-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-10142031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgpvpn-auto-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-10142031.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Mon Apr 10 16:26:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2y6-0000ew-S6; Mon, 10 Apr 2006 16:26:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2y6-0000er-2f for l3vpn@ietf.org; Mon, 10 Apr 2006 16:26:38 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT2y4-00032G-OS for l3vpn@ietf.org; Mon, 10 Apr 2006 16:26:38 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 10 Apr 2006 13:26:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,108,1144047600"; d="txt'208?scan'208,208"; a="539024690:sNHT32476480" Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 16:26:35 -0400 Message-ID: <443ABF78.3040804@juniper.net> Date: Mon, 10 Apr 2006 16:26:32 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/mixed; boundary="------------090609070802020904070003" X-OriginalArrivalTime: 10 Apr 2006 20:26:35.0383 (UTC) FILETIME=[1012C070:01C65CDD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [Fwd: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-07.txt] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org This is a multi-part message in MIME format. --------------090609070802020904070003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This begins a brief last call on the document. Last call will be complete in 14 days. -r -------- Original Message -------- Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-07.txt Date: Mon, 10 Apr 2006 15:50:01 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: l3vpn@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs Author(s) : H. Ould-Brahim, et al. Filename : draft-ietf-l3vpn-bgpvpn-auto-07.txt Pages : 12 Date : 2006-4-10 In any provider-based VPN scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The main purpose of an auto-discovery mechanism is to enable a PE to dynamically discover the set of remote PEs having VPN members in common. The auto-discovery mechanism proceeds by having a PE advertises to other PEs, at a minimum, its own IP address and the list of VPN members configured on that PE. Once that information is received the remote PEs will then identify the list of VPN members they have in common with the advertising PE, and use the information carried within the discovery mechanism to establish VPN connectivity. This draft defines a BGP based auto-discovery mechanism for Virtual Router-based layer-3 VPNs. This mechanism is based on the approach used by BGP/MPLS-IP-VPN for distributing VPN routing information within the service provider(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-07.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-l3vpn-bgpvpn-auto-07.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-l3vpn-bgpvpn-auto-07.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. --------------090609070802020904070003 Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgpvpn-auto-07.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-l3vpn-bgpvpn-auto-07.txt" Content-Type: text/plain Content-ID: <2006-4-10142031.I-D@ietf.org> --------------090609070802020904070003-- From l3vpn-bounces@ietf.org Tue Apr 11 05:36:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTFHy-0005rg-N0; Tue, 11 Apr 2006 05:35:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTFHx-0005rb-Q4 for l3vpn@ietf.org; Tue, 11 Apr 2006 05:35:57 -0400 Received: from mgw1.noc.ntt.com ([210.163.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTFHw-0001O5-6a for l3vpn@ietf.org; Tue, 11 Apr 2006 05:35:57 -0400 Received: from mop1.noc.ntt.com by mgw1.noc.ntt.com (NTT-Com MailSV) with ESMTP id k3B9Zpo7006563 for ; Tue, 11 Apr 2006 18:35:51 +0900 (JST) Received: from mip3.noc.ntt.com (mvi3.noc.ntt.com) by mop1.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0IXJ00ALQXBRNA@ntt.com> for l3vpn@ietf.org; Tue, 11 Apr 2006 18:35:51 +0900 (JST) Date: Tue, 11 Apr 2006 18:35:50 +0900 From: "Yuji KAMITE" In-reply-to: <443288E9.1080703@juniper.net> To: l3vpn@ietf.org Message-id: <0IXJ002D0XBRNZ@ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcZX9/QSJfB6XiALRXCX/07Cm6RXKgFUZABw X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org > I am particularly interested in hearing from operators, but > everybody is welcomed to join in the discussion. I'd like to know what is the most biggest motivation/application for deploying this. Let me ask some questions to the authors. Q.1 About this solution's advantages. Is the difference from option A, only to decrease the number of BGP peer of ASBRs (especially if "private interface forwarding" is adopted in the option D.) ? In another way of saying, for SPs who does not have peering number problems yet, do they get any special benefits by this? Q.2 The implementation difference from the existing A/B/C, resides just in route import/advertisement behavior? (i.e., no capability negotiation etc.) Q.3 Is the criteria which scheme should be taken, "Private Interface Forwarding" or "Shared Interface Forwarding", equivalent to the criteria which option, "A" or "B" is preferred? Q.4 In terms of Inter/intra-AS TE context, the difference between option B and D is whether or not it can provide "per-vrf" tunnel setup, isn't it? Option A and D look similar in terms of adopting "Intra"-AS TE connected approach, though. -Yuji > -----Original Message----- > From: Ron Bonica [mailto:rbonica@juniper.net] > Sent: Tuesday, April 04, 2006 11:56 PM > To: l3vpn@ietf.org > Subject: draft-kulmala-l3vpn-interas-option-d-02 > > Folks, > > Since the list has been pretty quiet lately, I would like to > entertain discussion regarding whether > draft-kulmala-l3vpn-interas-option-d-02 > should become a working group item. > > I am particularly interested in hearing from operators, but > everybody is welcomed to join in the discussion. > > -r > From l3vpn-bounces@ietf.org Tue Apr 11 15:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOE2-0003x1-NI; Tue, 11 Apr 2006 15:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOE1-0003ww-J3 for l3vpn@ietf.org; Tue, 11 Apr 2006 15:08:29 -0400 Received: from fep01-0.kolumbus.fi ([193.229.0.41] helo=fep01-app.kolumbus.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTODz-00061N-Rf for l3vpn@ietf.org; Tue, 11 Apr 2006 15:08:29 -0400 Received: from mood.vph.iki.fi ([193.185.137.112]) by fep01-app.kolumbus.fi with ESMTP id <20060411190826.JUCW28409.fep01-app.kolumbus.fi@mood.vph.iki.fi>; Tue, 11 Apr 2006 22:08:26 +0300 Received: from vph by mood.vph.iki.fi with local (Exim 4.50) id 1FTODy-0001rv-Pg; Tue, 11 Apr 2006 22:08:26 +0300 Date: Tue, 11 Apr 2006 22:08:26 +0300 From: Ville Hallivuori To: Yuji KAMITE Message-ID: <20060411190826.GA5910@mood.vph.iki.fi> References: <443288E9.1080703@juniper.net> <0IXJ002D0XBRNZ@ntt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0IXJ002D0XBRNZ@ntt.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vph@iki.fi List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org On Tue, Apr 11, 2006 at 06:35:50PM +0900, Yuji KAMITE wrote: > I'd like to know what is the most biggest motivation/application > for deploying this. Let me ask some questions to the authors. Our motivation is to combine benefits of option A and B to a single option. With option D one gets: +No need to provision per VRF AC:s if shared interface forwarding is used (B) +No per VRF BGP sessions (B) +Operational separation for allocation of RD:s and RTs for SPs (A) +Because RD is per ASBR, a reasonable load balancing is possible (with option B RD is per remote PE so local RR selects only one of possible ASBRs to reach the remote PE) (A) +Possible to perform IP forwarding at ASBR (in VRF) -> route aggregation, ACLs, re-classifying, etc are possible. (A) +VRF context -> per VRF PSN tunnel selection, per VRF policing, etc (A) > Q.1 > About this solution's advantages. > Is the difference from option A, only to decrease the number of BGP peer of ASBRs > (especially if "private interface forwarding" is adopted in the option D.) ? > In another way of saying, for SPs who does not have peering number problems yet, > do they get any special benefits by this? With shared interface forwarding you do get the MPLS forwarding option (->no need to provision separate per VRF ACs). If you have thousands or tens of thousands VPNs per ASBR, having same number of BGP sessions seems rather unreasonable. If single ASBR would peer with three other ASBRs using option B and would have 10 000 common VPNs with each, with default BGP timers there would be 1000 BGP keep-alives every second just for maintaining the per VRF BGP sessions... with option D you would only need one hello every ten second. > Q.2 > The implementation difference from the existing A/B/C, resides just in > route import/advertisement behavior? (i.e., no capability negotiation etc.) This is correct. The line protocol remains unchanged, and only advertisement behaviour has been changed. This option can actually inter-operate with option B speaker. > Q.3 > Is the criteria which scheme should be taken, > "Private Interface Forwarding" or "Shared Interface Forwarding", > equivalent to the criteria which option, "A" or "B" is preferred? Shared interface forwarding is more convenient to provision. However sometimes having MPLS enabled interface towards another SP might be concidered as a security risk, and in such situations private interface forwarding might be preferable. > Q.4 > In terms of Inter/intra-AS TE context, the difference between option B and D is > whether or not it can provide "per-vrf" tunnel setup, isn't it? > Option A and D look similar in terms of adopting "Intra"-AS TE connected > approach, though. This is correct. -- [Ville Hallivuori][vph@iki.fi][http://www.iki.fi/vph/] [ID 8E1AD461][FP16=C9 50 E2 DF 48 F6 33 62 5D 87 47 9D 3F 2B 07 5D] [ID 58543419][FP20=8731 941D 15AB D4A0 88A0 FC8F B55C F4C4 5854 3419] [ID 8061C24E][FP20=C722 12DA 841E D811 DBFE 2FB3 174C E291 8061 C24E] From l3vpn-bounces@ietf.org Wed Apr 12 10:32:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgOg-0007Uh-Jz; Wed, 12 Apr 2006 10:32:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgOf-0007Uc-7y for l3vpn@ietf.org; Wed, 12 Apr 2006 10:32:41 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTgOe-0007nW-Tz for l3vpn@ietf.org; Wed, 12 Apr 2006 10:32:41 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.20]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Apr 2006 15:32:39 +0100 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, 12 Apr 2006 15:32:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 (Yuji KAMITE) Thread-Index: AcZdgQrw89VO5tGBSyiDunbQbRjk9gAsvF0A From: "Martin Halstead" To: X-OriginalArrivalTime: 12 Apr 2006 14:32:39.0748 (UTC) FILETIME=[F3798040:01C65E3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 (Yuji KAMITE) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Yugi RE: draft-kulmala-l3vpn-interas-option-d-02 Thanks for posting these questions. I have attempted to respond to each one in-line.=20 Q.1 About this solution's advantages.=20 Is the difference from option A, only to decrease the number of BGP peer of ASBRs (especially if "private interface forwarding" is adopted in the option D.) ? =20 In another way of saying, for SPs who does not have peering number problems yet, do they get any special benefits by this? MH: Reducing the number of back-to-back peers is indeed a big motivator for this option as a number of operators have expressed concerns regarding numbers of BtB peering sessions demanded by 'option a'. In my experience, it is one of the primary reasons for some operators to prefer 'option b'. In addition to reducing the number of peers, this option (independent of both traffic forwarding methods) allows for RT based import/export policies to exist between service provider domains that are independent of the RT import/export policies adopted by each service provider within their own ASes. This is not achievable by 'option a' or indeed 'option b', but useful for a service provider or third party organisation wanting to administer VPN routing based on RT import/export policy, independent of existing service provider VPN membership schemas. =20 Q.2 The implementation difference from the existing A/B/C, resides just in route import/advertisement behavior? (i.e., no capability negotiation etc.) MH: True for this version. There has been discussion about applicability to CsC (which may require additional capability announcement and is alluded to in the draft). For 'shared interface forwarding', this option seamlessly interworks with 'option b'. For 'private interface forwarding' however, a capability announcement may be useful to get around next hop issues where the advertised next hop may not be in the 'global' routing table, but is applicable within the context of a VRF. What do you think? Q.3 Is the criteria which scheme should be taken,=20 "Private Interface Forwarding" or "Shared Interface Forwarding", equivalent to the criteria which option, "A" or "B" is preferred? MH: Good question. I think that service providers do fall into two separate camps on this one - ones who will not contemplate connecting their MPLS core to another service provider via a 'global' interface due in part to security issues related to the possibility of label based attacks and routing vendors inability to prevent these attacks. 'Option a' and 'shared interface forwarding' are equally applicable here to solve these concerns. Other service providers however have sufficient trust with their partners and do not see this as an issue. The 'loose coupling' of VPN services that an MPLS based connection gives in 'shared interface forwarding' (per ASBR VRFs are not attached across AS borders) allows for some interesting topology builds that could be achieved across SPs by logically associating ASBR VRFs across AS borders as hub-and-spoke. One of the nice thing about this additional option though is that the control plane for 'private' and 'shared' interface forwarding could be administered identically meaning that a single service provider could connect to different partners via either data plane method and use the same administrative policies at the control plane to link sites across AS borders. That is not possible in options 'a' and 'b'.=20 Q.4 In terms of Inter/intra-AS TE context, the difference between option B and D is whether or not it can provide "per-vrf" tunnel setup, isn't it? Option A and D look similar in terms of adopting "Intra"-AS TE connected approach, though. MH: Agreed - for both forwarding options in the draft, assuming that the ASBR supports per VRF TE setup, numbers of TE tunnels can be drastically reduced across ASes (compared with 'option c').=20 Thanks for the questions. Do you see this additional option as being useful based on your knowledge so far? Regards Martin Halstead mhalstead@nexagent.com From l3vpn-bounces@ietf.org Wed Apr 12 18:33:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTntT-00012G-Az; Wed, 12 Apr 2006 18:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTntS-00010S-8V for l3vpn@ietf.org; Wed, 12 Apr 2006 18:32:58 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTntR-0003XR-Ip for l3vpn@ietf.org; Wed, 12 Apr 2006 18:32:58 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 2DD73644E3; Wed, 12 Apr 2006 16:32:50 -0600 (MDT) Message-ID: <443D8017.5020809@castlepoint.net> Date: Wed, 12 Apr 2006 16:32:55 -0600 From: Shane Amante User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Halstead References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 (Yuji KAMITE) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Martin, I also had some questions on this draft, as well, (as an operator interested in it): 1) I understand the goal you're attempting to achieve to reduce the number of BGP sessions between ASBR's, but the 'private interface forwarding' as detailed in Section 4 is concerning: For private interface forwarding, interface 'a' is a VRF attachment circuit associated to VRF2 (on ASBR1) and VRF3 (on ASBR2) and is used to transport labeled or native IP VPN traffic between VRF pairs. Per VPN routing updates are not advertised across this interface, rather interface 'b' carries all ASBR VPN-IPv4 routing updates exported from VRF pairs. Specifically, you are proposing to decouple data-plane forwarding from the control-plane, if I understand your proposal correctly. How do you propose to detect data-plane liveness/viability for the VRF-to-VRF AC's if there is no routing protocol run across the private AC's between VRF's? 2) In Section 5.2, 'Per VRF Route Limiting'. The text states that "the ASBR SHOULD have the ability to restrict numbers of routes learned on a per-VRF and BGP neighbor basis" for both eBGP and iBGP neighbors. I'm unclear how you would attempt to achieve this in practice where only a single eBGP session exists across one AC between ASBR's? Are you proposing filtering number of routes inside a VRF based on number of prefixes associated with an RD and/or RT to control the number of routes learned inside a single VRF, since only a single eBGP session exists between the ASBR's? Thanks, -shane Martin Halstead wrote: > Yugi > > RE: draft-kulmala-l3vpn-interas-option-d-02 > > Thanks for posting these questions. I have attempted to respond to each > one in-line. > > Q.1 > About this solution's advantages. > Is the difference from option A, only to decrease the number of BGP > peer of ASBRs > (especially if "private interface forwarding" is adopted in the option > D.) ? > In another way of saying, for SPs who does not have peering number > problems yet, > do they get any special benefits by this? > > MH: Reducing the number of back-to-back peers is indeed a big motivator > for this option as a number of operators have expressed concerns > regarding numbers of BtB peering sessions demanded by 'option a'. In my > experience, it is one of the primary reasons for some operators to > prefer 'option b'. In addition to reducing the number of peers, this > option (independent of both traffic forwarding methods) allows for RT > based import/export policies to exist between service provider domains > that are independent of the RT import/export policies adopted by each > service provider within their own ASes. This is not achievable by > 'option a' or indeed 'option b', but useful for a service provider or > third party organisation wanting to administer VPN routing based on RT > import/export policy, independent of existing service provider VPN > membership schemas. > > Q.2 > The implementation difference from the existing A/B/C, resides just in > route import/advertisement behavior? (i.e., no capability negotiation > etc.) > > MH: True for this version. There has been discussion about applicability > to CsC (which may require additional capability announcement and is > alluded to in the draft). For 'shared interface forwarding', this option > seamlessly interworks with 'option b'. For 'private interface > forwarding' however, a capability announcement may be useful to get > around next hop issues where the advertised next hop may not be in the > 'global' routing table, but is applicable within the context of a VRF. > What do you think? > > Q.3 > Is the criteria which scheme should be taken, > "Private Interface Forwarding" or "Shared Interface Forwarding", > equivalent to the criteria which option, "A" or "B" is preferred? > > MH: Good question. I think that service providers do fall into two > separate camps on this one - ones who will not contemplate connecting > their MPLS core to another service provider via a 'global' interface due > in part to security issues related to the possibility of label based > attacks and routing vendors inability to prevent these attacks. 'Option > a' and 'shared interface forwarding' are equally applicable here to > solve these concerns. Other service providers however have sufficient > trust with their partners and do not see this as an issue. The 'loose > coupling' of VPN services that an MPLS based connection gives in 'shared > interface forwarding' (per ASBR VRFs are not attached across AS borders) > allows for some interesting topology builds that could be achieved > across SPs by logically associating ASBR VRFs across AS borders as > hub-and-spoke. One of the nice thing about this additional option though > is that the control plane for 'private' and 'shared' interface > forwarding could be administered identically meaning that a single > service provider could connect to different partners via either data > plane method and use the same administrative policies at the control > plane to link sites across AS borders. That is not possible in options > 'a' and 'b'. > > Q.4 > In terms of Inter/intra-AS TE context, the difference between option B > and D is whether or not it can provide "per-vrf" tunnel setup, isn't it? > Option A and D look similar in terms of adopting "Intra"-AS TE > connected > approach, though. > > MH: Agreed - for both forwarding options in the draft, assuming that > the ASBR supports per VRF TE setup, numbers of TE tunnels can be > drastically reduced across ASes (compared with 'option c'). > > Thanks for the questions. Do you see this additional option as being > useful based on your knowledge so far? > > Regards > > Martin Halstead > mhalstead@nexagent.com > From l3vpn-bounces@ietf.org Thu Apr 13 04:34:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTxHW-0003qb-3c; Thu, 13 Apr 2006 04:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTxHU-0003qW-RI for l3vpn@ietf.org; Thu, 13 Apr 2006 04:34:24 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTxHU-0003e4-By for l3vpn@ietf.org; Thu, 13 Apr 2006 04:34:24 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.21]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 09:34:22 +0100 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: Thu, 13 Apr 2006 09:34:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 (Yuji KAMITE) Thread-Index: AcZekfiIbH/oZP5VQWWggyNm6V5aTAAPzssA From: "Martin Halstead" To: "Shane Amante" X-OriginalArrivalTime: 13 Apr 2006 08:34:22.0872 (UTC) FILETIME=[10C04980:01C65ED5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: l3vpn@ietf.org Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 (Yuji KAMITE) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Shane Thank you for interest in this option. Answers in-line: I also had some questions on this draft, as well, (as an operator=20 interested in it): 1) I understand the goal you're attempting to achieve to reduce the=20 number of BGP sessions between ASBR's, but the 'private interface=20 forwarding' as detailed in Section 4 is concerning: For private interface forwarding, interface 'a' is a VRF attachment circuit associated to VRF2 (on ASBR1) and VRF3 (on ASBR2) and is used to transport labeled or native IP VPN traffic between VRF pairs. Per VPN routing updates are not advertised across this interface, rather interface 'b' carries all ASBR VPN-IPv4 routing updates exported from VRF pairs. Specifically, you are proposing to decouple data-plane forwarding from=20 the control-plane, if I understand your proposal correctly. How do you=20 propose to detect data-plane liveness/viability for the VRF-to-VRF AC's=20 if there is no routing protocol run across the private AC's between VRF's? MH: Indeed, the proposal for this data plane option is to decouple the control from the data plane, but how that is achieved in practice can be implementation specific, for example: - If the link layer supports LMI, there should be no issue. - If the data plane and control plane are carried across the same physical layer, again there should be no issue. - For a link layer that currently lacks LMI, it should be possible to run an IGP and advertise loopback addresses as next hops. Not ideal I know, but certainly achievable. 2) In Section 5.2, 'Per VRF Route Limiting'. The text states that "the=20 ASBR SHOULD have the ability to restrict numbers of routes learned on a=20 per-VRF and BGP neighbor basis" for both eBGP and iBGP neighbors. I'm=20 unclear how you would attempt to achieve this in practice where only a=20 single eBGP session exists across one AC between ASBR's? Are you=20 proposing filtering number of routes inside a VRF based on number of=20 prefixes associated with an RD and/or RT to control the number of routes learned inside a single VRF, since only a single eBGP session exists=20 between the ASBR's? MH: I think that route filtering based on RTs makes a lot of sense for this option, but don't feel it is appropriate to specify how a vendor should satisfy this requirement. I think what is important is that service providers who connect their AS to a third party - be that an enterprise or another service provider should be able to use similar mechanisms to prevent overloading their VPN control plane, specifically at the level of a VPN, rather than an entire peer. =20 Again, thanks for the good questions. Regards Martin mhalstead@nexagent.com Martin Halstead wrote: > Yugi >=20 > RE: draft-kulmala-l3vpn-interas-option-d-02 >=20 > Thanks for posting these questions. I have attempted to respond to each > one in-line.=20 >=20 > Q.1 > About this solution's advantages.=20 > Is the difference from option A, only to decrease the number of BGP > peer of ASBRs > (especially if "private interface forwarding" is adopted in the option > D.) ? =20 > In another way of saying, for SPs who does not have peering number > problems yet, > do they get any special benefits by this? >=20 > MH: Reducing the number of back-to-back peers is indeed a big motivator > for this option as a number of operators have expressed concerns > regarding numbers of BtB peering sessions demanded by 'option a'. In my > experience, it is one of the primary reasons for some operators to > prefer 'option b'. In addition to reducing the number of peers, this > option (independent of both traffic forwarding methods) allows for RT > based import/export policies to exist between service provider domains > that are independent of the RT import/export policies adopted by each > service provider within their own ASes. This is not achievable by > 'option a' or indeed 'option b', but useful for a service provider or > third party organisation wanting to administer VPN routing based on RT > import/export policy, independent of existing service provider VPN > membership schemas. =20 >=20 > Q.2 > The implementation difference from the existing A/B/C, resides just in > route import/advertisement behavior? (i.e., no capability negotiation > etc.) >=20 > MH: True for this version. There has been discussion about applicability > to CsC (which may require additional capability announcement and is > alluded to in the draft). For 'shared interface forwarding', this option > seamlessly interworks with 'option b'. For 'private interface > forwarding' however, a capability announcement may be useful to get > around next hop issues where the advertised next hop may not be in the > 'global' routing table, but is applicable within the context of a VRF. > What do you think? >=20 > Q.3 > Is the criteria which scheme should be taken,=20 > "Private Interface Forwarding" or "Shared Interface Forwarding", > equivalent to the criteria which option, "A" or "B" is preferred? >=20 > MH: Good question. I think that service providers do fall into two > separate camps on this one - ones who will not contemplate connecting > their MPLS core to another service provider via a 'global' interface due > in part to security issues related to the possibility of label based > attacks and routing vendors inability to prevent these attacks. 'Option > a' and 'shared interface forwarding' are equally applicable here to > solve these concerns. Other service providers however have sufficient > trust with their partners and do not see this as an issue. The 'loose > coupling' of VPN services that an MPLS based connection gives in 'shared > interface forwarding' (per ASBR VRFs are not attached across AS borders) > allows for some interesting topology builds that could be achieved > across SPs by logically associating ASBR VRFs across AS borders as > hub-and-spoke. One of the nice thing about this additional option though > is that the control plane for 'private' and 'shared' interface > forwarding could be administered identically meaning that a single > service provider could connect to different partners via either data > plane method and use the same administrative policies at the control > plane to link sites across AS borders. That is not possible in options > 'a' and 'b'.=20 >=20 > Q.4 > In terms of Inter/intra-AS TE context, the difference between option B > and D is whether or not it can provide "per-vrf" tunnel setup, isn't it? > Option A and D look similar in terms of adopting "Intra"-AS TE > connected > approach, though. >=20 > MH: Agreed - for both forwarding options in the draft, assuming that > the ASBR supports per VRF TE setup, numbers of TE tunnels can be > drastically reduced across ASes (compared with 'option c').=20 >=20 > Thanks for the questions. Do you see this additional option as being > useful based on your knowledge so far? >=20 > Regards >=20 > Martin Halstead > mhalstead@nexagent.com >=20 From l3vpn-bounces@ietf.org Thu Apr 13 09:18:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1hd-0005S2-Ur; Thu, 13 Apr 2006 09:17:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1hc-0005Ru-FC for l3vpn@ietf.org; Thu, 13 Apr 2006 09:17:40 -0400 Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU1ha-0004aH-Tl for l3vpn@ietf.org; Thu, 13 Apr 2006 09:17:40 -0400 Received: from mop1.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id k3DDHTaq029397; Thu, 13 Apr 2006 22:17:29 +0900 (JST) Received: from mip2.noc.ntt.com (mvi2.noc.ntt.com) by mop1.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0IXN00BN5WX4LA@ntt.com>; Thu, 13 Apr 2006 22:17:29 +0900 (JST) Date: Thu, 13 Apr 2006 22:17:28 +0900 From: "Yuji KAMITE" In-reply-to: To: "'Martin Halstead'" , l3vpn@ietf.org Message-id: <0IXN00FTKWX4F2@ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcZdgQrw89VO5tGBSyiDunbQbRjk9gAsvF0AAC0T9hA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 (Yuji KAMITE) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Hi Martin, > Q.2 > The implementation difference from the existing A/B/C, > resides just in > route import/advertisement behavior? (i.e., no capability > negotiation > etc.) > > MH: True for this version. There has been discussion about > applicability to CsC (which may require additional capability > announcement and is alluded to in the draft). For 'shared > interface forwarding', this option seamlessly interworks with > 'option b'. For 'private interface forwarding' however, a > capability announcement may be useful to get around next hop > issues where the advertised next hop may not be in the > 'global' routing table, but is applicable within the context of a VRF. > What do you think? As long as 'private interface' case, treatment of "next hop" looks a little awkward to me. It seems to require a new paradigm of creating and using routing table, In my understanding, VPNv4 prefix is attached with "overwritten" RD/RT at ASBR and next-hop interface must be treated at per sub-interface level, for private interface's isolation; however, advertised next-hop is always at global route. For option A users, It MUST have a mechanism to avoid mixturing each VRF's route and other interfaces (for non-vpn usage as well). If it can be prevented at protocol-level negotiation, some kind of capability advertisement might be useful, and safe. Basically description about operational differences (or migration scheme) from existing A/B users would be useful and highly expected. Connectivity checking scheme (as already pointed out) is included there too. -Yuji From l3vpn-bounces@ietf.org Thu Apr 13 09:53:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2GD-0006pE-J8; Thu, 13 Apr 2006 09:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2GC-0006oN-4W for l3vpn@ietf.org; Thu, 13 Apr 2006 09:53:24 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU2GB-0005Ps-Ty for l3vpn@ietf.org; Thu, 13 Apr 2006 09:53:24 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Apr 2006 06:53:23 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,118,1144047600"; d="scan'208"; a="539673841:sNHT22320694" Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 09:53:22 -0400 Message-ID: <443E57CF.2030103@juniper.net> Date: Thu, 13 Apr 2006 09:53:19 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2006 13:53:22.0447 (UTC) FILETIME=[A0D3A9F0:01C65F01] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Folks, So far, we have had a few interesting questions regarding this draft, but not much explicit support for adopting it as a WG item. So, if you would like to see this draft adopted as a WG item, please speak up in the next eight days. Ron From l3vpn-bounces@ietf.org Thu Apr 13 10:42:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU31B-0006kD-NZ; Thu, 13 Apr 2006 10:41:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU319-0006fw-Kz for l3vpn@ietf.org; Thu, 13 Apr 2006 10:41:55 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU319-00078G-C6 for l3vpn@ietf.org; Thu, 13 Apr 2006 10:41:55 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.21]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 15:41:53 +0100 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: Thu, 13 Apr 2006 15:41:50 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 (Yuji KAMITE) Thread-Index: AcZdgQrw89VO5tGBSyiDunbQbRjk9gAsvF0AAC0T9hAAB45M8A== From: "Martin Halstead" To: "Yuji KAMITE" , X-OriginalArrivalTime: 13 Apr 2006 14:41:53.0809 (UTC) FILETIME=[68224010:01C65F08] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 (Yuji KAMITE) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Yuji Answers in-line > Q.2 > The implementation difference from the existing A/B/C,=20 > resides just in > route import/advertisement behavior? (i.e., no capability=20 > negotiation > etc.) >=20 > MH: True for this version. There has been discussion about=20 > applicability to CsC (which may require additional capability=20 > announcement and is alluded to in the draft). For 'shared=20 > interface forwarding', this option seamlessly interworks with=20 > 'option b'. For 'private interface forwarding' however, a=20 > capability announcement may be useful to get around next hop=20 > issues where the advertised next hop may not be in the=20 > 'global' routing table, but is applicable within the context of a VRF. > What do you think? As long as 'private interface' case, treatment of "next hop" looks a little awkward to me. It seems to require a new paradigm of creating and using routing table, In my understanding, VPNv4 prefix is attached with "overwritten" RD/RT at ASBR=20 and next-hop interface must be treated at per sub-interface level, for private interface's isolation; however, advertised next-hop is always at global route. MH: True, but the simplest way to solve this with no additional capability announcement is to ensure on each ASBR that all VRF AC interfaces share the same address as the global peer. Saying that, I do agree with your next comment. For option A users, It MUST have a mechanism to avoid mixturing each VRF's route and other interfaces (for non-vpn usage as well). If it can be=20 prevented at protocol-level negotiation, some kind of capability advertisement=20 might be useful, and safe.=20 MH: Agreed - will include this in the next version. Basically description about operational differences (or migration scheme) from existing A/B users would be useful and highly expected. Connectivity checking scheme (as already pointed out) is included there too. MH: The draft does talk about supporting options 'a' and 'b' along with this additional option, but more detailed interworking descriptions for all options could be added fairly easily. Again, thanks for the comments, Regards Martin mhalstead@nexagent.com From l3vpn-bounces@ietf.org Thu Apr 13 11:12:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3UW-0004uq-04; Thu, 13 Apr 2006 11:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3UT-0004uk-Tz for l3vpn@ietf.org; Thu, 13 Apr 2006 11:12:13 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU3UQ-0008Fs-Ly for l3vpn@ietf.org; Thu, 13 Apr 2006 11:12:13 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Apr 2006 08:12:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,118,1144047600"; d="scan'208"; a="539688461:sNHT26375948" Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 11:12:09 -0400 Message-ID: <443E6A46.6000904@juniper.net> Date: Thu, 13 Apr 2006 11:12:06 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Halstead References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2006 15:12:09.0385 (UTC) FILETIME=[A24D2990:01C65F0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Martin, Could you explain the motivation for private interface forwarding? I don't understand which problems it solves that could not be solved with an equal number of Option A and Option B interfaces between ASBR's Ron /as individual contributror From l3vpn-bounces@ietf.org Thu Apr 13 12:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU4SG-0004Lx-7A; Thu, 13 Apr 2006 12:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU4SE-0004Ls-U9 for l3vpn@ietf.org; Thu, 13 Apr 2006 12:13:58 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU4SD-0001l9-Lj for l3vpn@ietf.org; Thu, 13 Apr 2006 12:13:58 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.21]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 17:13:56 +0100 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: Thu, 13 Apr 2006 17:13:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 Thread-Index: AcZfDKVFOevUqlqpQP+UQObReQ51KQAADQNw From: "Martin Halstead" To: "Ron Bonica" X-OriginalArrivalTime: 13 Apr 2006 16:13:56.0192 (UTC) FILETIME=[43BB0600:01C65F15] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: l3vpn@ietf.org Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Ron Thanks for the question. Option 'a' requires an IPV4 peer between attached VRF pairs at each ASBR. Each ASBR must therefore support at least one IPV4 peer per VPN. As the number of VPNs increase, so do the number of peers giving rise to convergence and complexity issues. If a service provider wants to associate all VPN traffic with at least one VRF (as some do for security, per VPN route learning, per VPN ACL support reasons etc), then at the moment 'option a' and all those associated IPV4 peers is the only way to go. Configuring 'option b' on the same ASBR pair will not help here as there is no way to set up paths for 'option b' learned VPN-IPV4 routes for VPN traffic flowing across per VRF ACs (unless you implement this additional option ;-). There isn't really much point in configuring more than a single option 'b' interface between ASBRs though as a single interface supports multiple VPNs and additional interfaces do not need to be configured as the number of VPNs increase. Regards Martin Halstead mhalstead@nexagent.com -----Original Message----- From: Ron Bonica [mailto:rbonica@juniper.net]=20 Sent: 13 April 2006 16:12 To: Martin Halstead Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 Martin, Could you explain the motivation for private interface forwarding? I don't understand which problems it solves that could not be solved with an equal number of Option A and Option B interfaces between ASBR's Ron /as individual contributror From l3vpn-bounces@ietf.org Thu Apr 13 13:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5Hp-0003yb-CC; Thu, 13 Apr 2006 13:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5Ho-0003yW-Fm for l3vpn@ietf.org; Thu, 13 Apr 2006 13:07:16 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU5Ho-0003Zv-6E for l3vpn@ietf.org; Thu, 13 Apr 2006 13:07:16 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Apr 2006 10:07:11 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,118,1144047600"; d="scan'208"; a="539709650:sNHT24278636" Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 13:07:10 -0400 Message-ID: <443E853A.3030108@juniper.net> Date: Thu, 13 Apr 2006 13:07:06 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Halstead References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2006 17:07:10.0362 (UTC) FILETIME=[B39AAFA0:01C65F1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Martin Halstead wrote: > Ron > > Thanks for the question. Option 'a' requires an IPV4 peer between > attached VRF pairs at each ASBR. Each ASBR must therefore support at > least one IPV4 peer per VPN. As the number of VPNs increase, so do the > number of peers giving rise to convergence and complexity issues. I understand this much.... If a > service provider wants to associate all VPN traffic with at least one > VRF (as some do for security, per VPN route learning, per VPN ACL > support reasons etc), then at the moment 'option a' and all those > associated IPV4 peers is the only way to go. Configuring 'option b' on > the same ASBR pair will not help here as there is no way to set up paths > for 'option b' learned VPN-IPV4 routes for VPN traffic flowing across > per VRF ACs (unless you implement this additional option ;-). There > isn't really much point in configuring more than a single option 'b' > interface between ASBRs though as a single interface supports multiple > VPNs and additional interfaces do not need to be configured as the > number of VPNs increase. I would like to propose another alternative. Assume that two Service Providers (SP1 and SP2) share five customers (C1, C2, C3, C4 and C5). C1, C2 and C3 are happy to share bandwidth on a common link between SP1 and SP2. However, C4 and C5 each want dedicated bandwidth between the SPs. (I think that this is the problem that you want to solve?) The SPs might solve this problem as follows: Establish three links (LG, L4 and L5) between SP1 and SP2. LG is in the general routing instance, L4 is in C4's VRF and L5 is in C5's VRF. Configure an mp-ebgp peering session on LG (as per Interprovider Option B). However, do not advertise routes belonging to C4 and C5. Then configure L4 and L5 as per Interprovider Option A. The drawback of this solution is that it may require two extra bgp peering sessions. The benefits are a) that it doesn't separate the control and data planes and b) that it doesn't require a new option. -r /as individual contributor > > Regards > > Martin Halstead > mhalstead@nexagent.com > > > -----Original Message----- > From: Ron Bonica [mailto:rbonica@juniper.net] > Sent: 13 April 2006 16:12 > To: Martin Halstead > Cc: l3vpn@ietf.org > Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 > > Martin, > > Could you explain the motivation for private interface forwarding? I > don't understand which problems it solves that could not be solved with > an equal number of Option A and Option B interfaces between ASBR's > > Ron > /as individual contributror > From l3vpn-bounces@ietf.org Fri Apr 14 05:49:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUKvU-0007jv-5D; Fri, 14 Apr 2006 05:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUKvR-0007bl-V8 for l3vpn@ietf.org; Fri, 14 Apr 2006 05:49:13 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUKvR-0003KG-Bg for l3vpn@ietf.org; Fri, 14 Apr 2006 05:49:13 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.21]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Apr 2006 10:49:07 +0100 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, 14 Apr 2006 10:49:05 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 Thread-Index: AcZfHLnIU6lgV69NRvKOK3uSnjOdPQAhhgXA From: "Martin Halstead" To: "Ron Bonica" X-OriginalArrivalTime: 14 Apr 2006 09:49:07.0468 (UTC) FILETIME=[AC3114C0:01C65FA8] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: l3vpn@ietf.org Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Ron I would like to propose another alternative. Assume that two Service Providers (SP1 and SP2) share five customers (C1, C2, C3, C4 and C5). C1, C2 and C3 are happy to share bandwidth on a common link between SP1 and SP2. However, C4 and C5 each want dedicated bandwidth between the SPs. (I think that this is the problem that you want to solve?) The SPs might solve this problem as follows: Establish three links (LG, L4 and L5) between SP1 and SP2. LG is in the general routing instance, L4 is in C4's VRF and L5 is in C5's VRF. Configure an mp-ebgp peering session on LG (as per Interprovider Option B). However, do not advertise routes belonging to C4 and C5. Then configure L4 and L5 as per Interprovider Option A. The drawback of this solution is that it may require two extra bgp peering sessions. The benefits are a) that it doesn't separate the control and data planes and b) that it doesn't require a new option. MH: Ah, I see what you meant by the previous question! You are right, this is another alternative. Some issues though with that solution: - It is highly unusual to have 'option a' and 'option b' on the same ASBR pair linking a common pair of SPs. Typically each SP to SP link has a single interconnect option supported. This is due to operational complexity of running separate multi-AS options on the same ASBR pairs. - Hopefully the service will scale i.e. numbers of shared VPNs will increase. What if SP1 and SP2 decide to connect more VPNs by using 'option a'? Your solution does not prevent additional peers (at least one per additional VPN) from being configured. Also, as the number of VPNs increase, you will also have to deal with additional per VPN route filtering to prevent route 'leakage' across the 'option b' link. - There is an operational knock-on effect within each SPs VPN domain. SP1 and SP2 will have to concurrently operate different RT import/export policies at PEs. Some RTs will be shared across SPs via the 'option b' VPNs, and some RTs will come from each SPs own separate RT pool ie 'option a' VPNs. Again, operational issues here. Regards Martin mhalstead@nexagent.com =20 =20 From l3vpn-bounces@ietf.org Mon Apr 17 13:45:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXmr-0007GT-GR; Mon, 17 Apr 2006 13:45:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXmq-0007EB-9P; Mon, 17 Apr 2006 13:45:20 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXmq-0003KG-0s; Mon, 17 Apr 2006 13:45:20 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3HHjFBX017802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Apr 2006 17:45:15 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FVXml-00007m-PV; Mon, 17 Apr 2006 13:45:15 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 17 Apr 2006 13:45:15 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: l3vpn mailing list , Internet Architecture Board , l3vpn chair , l3vpn chair , RFC Editor Subject: Protocol Action: 'Constrained VPN Route Distribution' to Proposed Standard X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org The IESG has approved the following document: - 'Constrained VPN Route Distribution ' as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Margaret Wasserman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt Technical Summary This document addresses scaling issues for VPN routing information maintained atroute reflectors. It extends the RFC2547bis approach using “Cooperative Route Filtering” between router reflectors for support multiple autonomous systems and asymmetric VPN topologies such as hub-and-spoke. The solution uses MP-BGP UPDATE messages to propagate Route Target membership information. Received RouteTarget membership information can then be used to restrict advertisement ofVPN NLRI to peers that have advertised their respective Route Targets, effectively building a route distribution graph. In this model, VPN NLRI routing informationflows in the inverse direction of Route Target membership information. This mechanism is applicable to any BGP NLRI that controls the distribution of routing information based on Route Targets, such as BGP L2VPNs [L2VPN] and VPLS [VPLS]. Working Group Summary There were several detailed issued which were raised when the document was submitted to the WG. Constructive comments led to modifications to the document which addressed the concerns that were raised. Protocol Quality In addition to L3VPN review, this document was reviewed by the IDR WG where it received review comments from Rick Wilder, Chandrashekhar Appanna, and Jeff Haas. Multiple implementations exist. Note to RFC Editor The upper left hand corner of the title page should include: "Updates: draft-ietf-l3vpn-rfc2547bis-03" In section 2, please replace "proposal" with "document" in the following text: > This proposal extends the RFC2547bis [3] ORF work to include support > for multiple autonomous systems, and asymmetric VPN topologies such > as hub-and-spoke. Also in section 2, please remove the [?] reference, new text is: > This mechanism is applicable to any BGP NLRI that controls the > distribution of routing information based on Route Targets such > as VPLS [9]. Please change the title to: "Constrained Route Distribution for BGP/MPLS IP VPNs" Please replace the Abstract with: This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates draft-ietf-l3vpn-rfc2547bis-03. [RFC Editor: please replace this Internet-Draft reference with an RFC number when it is assigned.]" Please add a Terminology Section with the following acronyms expanded and defined and the informational reference to RFC4026: This document uses a number of terms and acronyms specific to Provider-Provisioned VPNs, including those specific to L2VPNs, L3VPNs and BGP. Definitions for many of these terms may be found in the VPN terminology document [RFC4026]. This section also includes some brief acronym expansion and terminology to aid the reader. AFI - Address Family Identifier (a BGP address type) BGP - Border Gateway Protocol BGP/MPLS VPN - A Layer 3 VPN implementation based upon BGP and MPLS. CE - Customer Edge (router) iBGP - Internal BGP; i.e., a BGP peering session that connects two routers within an autonomous system L2VPN - Layer 2 Virtual Private Network L3VPN - Layer 3 Virtual Private Network MP-BGP - Multi-Protocol Border Gateway Protocol MPLS - Multi-Protocol Label Switching NLRI - Network Layer Reachability Information ORF - Outbound Route Filtering PE - Provider Edge (router) RT - Route Target (i.e., a BGP extended community that conditions network layer reachability information with VPN membership) SAFI - Subsequence Address Family Identifier (a BGP address sub-type) VPLS - Virtual Private LAN Service VPN - Virtual Private Network Editor: Please include an informational reference to RFC 4026 in the referencessection. Please change the following text in section 6 From: A BGP speaker should generate the minimum set of BGP VPN route updates necessary to transition between the previous and current state of the route distribution graph that is derived from Route Target membership information. To: A BGP speaker should generate the minimum set of BGP VPN route updates (advertisements and/or withdrawls) necessary to transition between the previous and current state of the route distribution graph that is derived from Route Target membership information. From l3vpn-bounces@ietf.org Mon Apr 17 13:47:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXol-0000UD-UA; Mon, 17 Apr 2006 13:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXok-0000Oe-H0; Mon, 17 Apr 2006 13:47:18 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXok-0003YS-5p; Mon, 17 Apr 2006 13:47:18 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3HHl2BX017872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Apr 2006 17:47:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FVXoU-0000A6-HY; Mon, 17 Apr 2006 13:47:02 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 17 Apr 2006 13:47:02 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: l3vpn chair , Internet Architecture Board , l3vpn mailing list , RFC Editor Subject: Protocol Action: 'BGP-MPLS IP VPN extension for IPv6 VPN' to Proposed Standard X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org The IESG has approved the following document: - 'BGP-MPLS IP VPN extension for IPv6 VPN ' as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-07.txt Technical Summary This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method [2547bis] for support of IPv6. In particular, this method uses the same "peer model" as [2547bis], in which the customers' edge routers ("CE routers") send their IPv6 routes to the Service Provider's edge routers ("PE routers"). BGP ("Border Gateway Protocol", [BGP, BGP-MP]) is then used by the Service Provider to exchange the routes of a particular IPv6 VPN among the PE routers that are attached to that IPv6 VPN. Eventually, the PE routers distribute, to the CE routers in a particular VPN, the IPv6 routes from other CE routers in that VPN. As with IPv4 VPNs, a key characteristic of this "peer model" is that the (IPv6) CE routers within an (IPv6) VPN do not peer with each other and there is no "overlay" visible to the (IPv6) VPN's routing algorithm. A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6 capable and is natively connected over an IPv6 interface or sub- interface to the SP backbone via a Provider Edge device (PE). A site may be both IPv4-capable and IPv6-capable. The logical interface on which packets arrive at the PE may determine the IP version. Alternatively the same logical interface may be used for both IPv4 and IPv6 in which case a per-packet lookup at the Version field of the IP packet header determines the IP version. This document only concerns itself with handling of the IPv6 packets. As such the inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. In a similar manner to how IPv4 VPN routes are distributed in [2547bis], BGP and its extensions are used to distribute routes from an IPv6 VPN site to all the other PE routers connected to a site of the same IPv6 VPN. PEs use "VPN Routing and Forwarding tables" (VRFs) to separately maintain the reachability information and forwarding information of each IPv6 VPN. As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have its own IPv6 address space, which means that a given address may denote different systems in different VPNs. This is achieved via a new address family, the VPN-IPv6 Address Family, in a fashion similar to the VPN-IPv4 address family defined in [2547bis] and which prepends a Route Distinguisher to the IP address. In addition to its operation over MPLS Label Switched Paths (LSPs), the IPv4 BGP/MPLS VPN solution has been extended to allow operation over other tunneling techniques including GRE tunnels, IP-in-IP tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3] and IPsec- protected tunnels [2547-IPsec]. In a similar manner, this document allows support of an IPv6 VPN service over MPLS LSPs as well as over other tunneling techniques including GRE tunnels, IP-in-IP tunnels, L2TPv3 tunnels and IPsec-protected tunnels. This document allows support for an IPv6 VPN service over an IPv4 backbone as well as over an IPv6 backbone. The IPv6 VPN service supported is identical in both cases. Working Group Summary This document went smoothly through the WG process. Protocol Quality At least two vendors have developed to earlier versions of this draft. Jeffrey Haas and Pedro Marques both commented on the draft as it went through multiple revisions. RFC Editor Note: The document's references to draft-ietf-ipv6-unique-local-addr-09.txt need to be updated; one section refers to Section 10, which no longer exists. I believeit should refer to Section 4.7. Please search and replace on "byte" replacing it with "octet" throughout the document. Please remove the reference to [RFC2547bis] in the Abstract. There are citation inconsistencies, please work with the authors to clear theseup. See tracker for reference check tool output. Please add the following clarifying sentence at the end of Section 5: "Recommendations and considerations for which of these supported address types should be used in a given IPv6 VPN environments are beyond the scope of this document" From l3vpn-bounces@ietf.org Mon Apr 17 16:56:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FValQ-00088f-Mi; Mon, 17 Apr 2006 16:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FValP-00088a-0x for l3vpn@ietf.org; Mon, 17 Apr 2006 16:56:03 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FValO-0004kR-O4 for l3vpn@ietf.org; Mon, 17 Apr 2006 16:56:03 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 17 Apr 2006 13:56:02 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,127,1144047600"; d="scan'208"; a="540560276:sNHT25038436" Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 16:56:00 -0400 Message-ID: <444400DE.6060802@juniper.net> Date: Mon, 17 Apr 2006 16:55:58 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Halstead References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2006 20:56:00.0970 (UTC) FILETIME=[555632A0:01C66261] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Martin, I am coming around to your point of view regarding Option D, but still have a few comments. - The draft needs a section that describes its motivation. You might want to say something like the following: "Interprovider Options A, B and C all require SPs to co-ordinate RDs. Interprovider Option D relaxes this requirement by re-assigning RDs at the ASBR. Also, interprovider Options A, B, and C provide no mechanism through which SPs can dedicate bandwidth between ASBRs to a particular VPN. Interprovider Option D solves this problem through Private Interface Forwarding. In this approach, the SP dedicates a logical interface between ASBRs to each VPN and forces VPN traffic over the appropriate interface by manipulating BGP next-hops". - Also, your might want to explore approaches to the second problem that do not separate the forwarding path from the control path. I realize that the approach described in my last email may not suite all SPs. So, I will suggest another variation on that theme. Instead of establishing multiple layer 3 interfaces between the ASBRs, establish a single interface and run multiple, single-hop LSPs over that. Police and rate-limit each LSP as per VPN policy. As in your original proposal, run a single mp-ebgp peering session between the two ASBRs and force traffic over the correct LSP by manipulating BGP next-hops. The advantage of this approach is that it doesn't separate the forwarding path from the control path. Also, it consumes fewer logical interfaces. - If you must separate the forwarding and control paths, please add a section to the draft describing what might happen if the forwarding path goes down and the control path does not. Also describe mitigation techniques. ron /as individual contributor > > MH: Ah, I see what you meant by the previous question! You are right, > this is another alternative. Some issues though with that solution: > - It is highly unusual to have 'option a' and 'option b' on the same > ASBR pair linking a common pair of SPs. Typically each SP to SP link has > a single interconnect option supported. This is due to operational > complexity of running separate multi-AS options on the same ASBR pairs. > - Hopefully the service will scale i.e. numbers of shared VPNs will > increase. What if SP1 and SP2 decide to connect more VPNs by using > 'option a'? Your solution does not prevent additional peers (at least > one per additional VPN) from being configured. Also, as the number of > VPNs increase, you will also have to deal with additional per VPN route > filtering to prevent route 'leakage' across the 'option b' link. > - There is an operational knock-on effect within each SPs VPN domain. > SP1 and SP2 will have to concurrently operate different RT import/export > policies at PEs. Some RTs will be shared across SPs via the 'option b' > VPNs, and some RTs will come from each SPs own separate RT pool ie > 'option a' VPNs. Again, operational issues here. > > Regards > > Martin > mhalstead@nexagent.com > > > > From l3vpn-bounces@ietf.org Tue Apr 18 06:34:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVnXa-0006XI-0C; Tue, 18 Apr 2006 06:34:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVnXY-0006XB-L7 for l3vpn@ietf.org; Tue, 18 Apr 2006 06:34:36 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVnXY-0005wH-Al for l3vpn@ietf.org; Tue, 18 Apr 2006 06:34:36 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.21]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 11:34:32 +0100 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, 18 Apr 2006 11:34:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 Thread-Index: AcZiYVlmsBUopoFMSrCV+aral4jCGAAcarog From: "Martin Halstead" To: "Ron Bonica" X-OriginalArrivalTime: 18 Apr 2006 10:34:32.0854 (UTC) FILETIME=[AE4CFB60:01C662D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: l3vpn@ietf.org Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Ron Thanks for the excellent suggestions - we will incorporate them in the next version of the draft and issue it shortly.=20 Many thanks to the other contributors - any further clarifications/additions to the draft, please let us know. Regards Martin mhalstead@nexagent.com -----Original Message----- From: Ron Bonica [mailto:rbonica@juniper.net]=20 Sent: 17 April 2006 21:56 To: Martin Halstead Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 Martin, I am coming around to your point of view regarding Option D, but still have a few comments. - The draft needs a section that describes its motivation. You might want to say something like the following: "Interprovider Options A, B and C all require SPs to co-ordinate RDs. Interprovider Option D relaxes this requirement by re-assigning RDs at the ASBR. Also, interprovider Options A, B, and C provide no mechanism through which SPs can dedicate bandwidth between ASBRs to a particular VPN. Interprovider Option D solves this problem through Private Interface Forwarding. In this approach, the SP dedicates a logical interface between ASBRs to each VPN and forces VPN traffic over the appropriate interface by manipulating BGP next-hops". - Also, your might want to explore approaches to the second problem that do not separate the forwarding path from the control path. I realize that the approach described in my last email may not suite all SPs. So, I will suggest another variation on that theme. Instead of establishing multiple layer 3 interfaces between the ASBRs, establish a single interface and run multiple, single-hop LSPs over that. Police and rate-limit each LSP as per VPN policy. As in your original proposal, run a single mp-ebgp peering session between the two ASBRs and force traffic over the correct LSP by manipulating BGP next-hops. The advantage of this approach is that it doesn't separate the forwarding path from the control path. Also, it consumes fewer logical interfaces. - If you must separate the forwarding and control paths, please add a section to the draft describing what might happen if the forwarding path goes down and the control path does not. Also describe mitigation techniques. ron /as individual contributor >=20 > MH: Ah, I see what you meant by the previous question! You are right, > this is another alternative. Some issues though with that solution: > - It is highly unusual to have 'option a' and 'option b' on the same > ASBR pair linking a common pair of SPs. Typically each SP to SP link has > a single interconnect option supported. This is due to operational > complexity of running separate multi-AS options on the same ASBR pairs. > - Hopefully the service will scale i.e. numbers of shared VPNs will > increase. What if SP1 and SP2 decide to connect more VPNs by using > 'option a'? Your solution does not prevent additional peers (at least > one per additional VPN) from being configured. Also, as the number of > VPNs increase, you will also have to deal with additional per VPN route > filtering to prevent route 'leakage' across the 'option b' link. > - There is an operational knock-on effect within each SPs VPN domain. > SP1 and SP2 will have to concurrently operate different RT import/export > policies at PEs. Some RTs will be shared across SPs via the 'option b' > VPNs, and some RTs will come from each SPs own separate RT pool ie > 'option a' VPNs. Again, operational issues here. >=20 > Regards >=20 > Martin > mhalstead@nexagent.com =20 >=20 >=20 > =20 >=20 From l3vpn-bounces@ietf.org Tue Apr 18 06:56:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVnt5-0002qb-UV; Tue, 18 Apr 2006 06:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVnt4-0002qV-R9 for l3vpn@ietf.org; Tue, 18 Apr 2006 06:56:50 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVnt3-00079g-LC for l3vpn@ietf.org; Tue, 18 Apr 2006 06:56:50 -0400 Received: from usruamalisl.mail.com (c-24-147-100-163.hsd1.ma.comcast.net[24.147.100.163]) by comcast.net (sccrmhc12) with SMTP id <2006041810564801200j5r3oe>; Tue, 18 Apr 2006 10:56:49 +0000 Message-Id: <7.0.1.0.2.20060418065629.05d59690@comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 18 Apr 2006 06:56:47 -0400 To: Ron Bonica From: "Andrew G. Malis" In-Reply-To: <443E57CF.2030103@juniper.net> References: <443E57CF.2030103@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: l3vpn@ietf.org Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Ron, I support this becoming a working group draft. Thanks, Andy ----------- At 4/13/2006 09:53 -0400, Ron Bonica wrote: >Folks, > >So far, we have had a few interesting questions regarding this draft, >but not much explicit support for adopting it as a WG item. So, if you >would like to see this draft adopted as a WG item, please speak up in >the next eight days. > > Ron From l3vpn-bounces@ietf.org Tue Apr 18 14:37:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVv4C-00039F-MP; Tue, 18 Apr 2006 14:36:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVv4A-00039A-OQ for l3vpn@ietf.org; Tue, 18 Apr 2006 14:36:46 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVv49-00080P-Gn for l3vpn@ietf.org; Tue, 18 Apr 2006 14:36:46 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 18 Apr 2006 11:36:45 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,131,1144047600"; d="scan'208"; a="540769366:sNHT20765164" Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 14:36:44 -0400 Message-ID: <444531B9.7010102@juniper.net> Date: Tue, 18 Apr 2006 14:36:41 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Halstead References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2006 18:36:44.0159 (UTC) FILETIME=[0AB3C8F0:01C66317] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Martin, BTW, would Option D play well with Constrained VPN Route Distribution ( draft-ietf-l3vpn-rt-constrain)? Ron From l3vpn-bounces@ietf.org Thu Apr 20 06:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWWTG-0003O8-Pl; Thu, 20 Apr 2006 06:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWWTG-0003O2-9x for l3vpn@ietf.org; Thu, 20 Apr 2006 06:33:10 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWWTF-0006eh-1H for l3vpn@ietf.org; Thu, 20 Apr 2006 06:33:10 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.21]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Apr 2006 11:33:04 +0100 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: Thu, 20 Apr 2006 11:33:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 Thread-Index: AcZjFw7si+ih4riVTV22ShRaAd1KXQBTQ1mA From: "Martin Halstead" To: "Ron Bonica" X-OriginalArrivalTime: 20 Apr 2006 10:33:04.0022 (UTC) FILETIME=[CE2DCB60:01C66465] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: l3vpn@ietf.org Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Ron You make a good point - I think that 'draft-ietf-l3vpn-rt-constrain' does play well with 'option d' as a means to restrict VPN route updates to interested parties only. This could apply when a single ASBR is peered with more than one ASBR (in my opinion a very good thing). The distribution graphs (and associated policies) would then sit between peered ASBRs, rather than across ASes as described in the 'constrain' draft. BTW - I think that in the case of L3 VPN, the 'constrain' draft should add that the option is only applicable to multi-AS options 'b' and 'c' and by implication will not work with option 'a'. Regards Martin mhalstead@nexagent.com -----Original Message----- From: Ron Bonica [mailto:rbonica@juniper.net]=20 Sent: 18 April 2006 19:37 To: Martin Halstead Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 Martin, BTW, would Option D play well with Constrained VPN Route Distribution ( draft-ietf-l3vpn-rt-constrain)? Ron From l3vpn-bounces@ietf.org Thu Apr 20 16:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWftC-0003Vu-Im; Thu, 20 Apr 2006 16:36:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWftB-0003Vp-OF for l3vpn@ietf.org; Thu, 20 Apr 2006 16:36:33 -0400 Received: from web310.biz.mail.mud.yahoo.com ([68.142.199.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWftA-0004yL-Em for l3vpn@ietf.org; Thu, 20 Apr 2006 16:36:33 -0400 Received: (qmail 52178 invoked by uid 60001); 20 Apr 2006 20:36:31 -0000 Message-ID: <20060420203631.52176.qmail@web310.biz.mail.mud.yahoo.com> Received: from [198.205.32.93] by web310.biz.mail.mud.yahoo.com via HTTP; Thu, 20 Apr 2006 13:36:31 PDT Date: Thu, 20 Apr 2006 13:36:31 -0700 (PDT) From: Rick Wilder To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: draft-kulmala-l3vpn-interas-option-d-02 consensus X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Dear Working Group Participants, May we please have more active response on the question of whether draft-kulmala-l3vpn-interas-option-d-02 should become a working group document? We need more active response on this issue to determine a consensus. Intention to implement from equipment vendors and intention to deploy from service providers would be espcially helpful. Please speak up now. Thanks, Rick and Ron From l3vpn-bounces@ietf.org Thu Apr 20 19:03:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWiBX-0007M5-PS; Thu, 20 Apr 2006 19:03:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWiBW-0007Lv-1i for l3vpn@ietf.org; Thu, 20 Apr 2006 19:03:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWgMg-0006Jo-HR for l3vpn@ietf.org; Thu, 20 Apr 2006 17:07:02 -0400 Received: from borg.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWg0L-0006Hc-Iy for l3vpn@ietf.org; Thu, 20 Apr 2006 16:43:57 -0400 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 20 Apr 2006 13:43:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,141,1144047600"; d="scan'208"; a="544831956:sNHT21915084" Received: from sapphire.juniper.net ([172.17.28.108]) by alpha.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 13:43:56 -0700 Date: Thu, 20 Apr 2006 13:43:56 -0700 (PDT) From: Rahul Aggarwal To: Rick Wilder In-Reply-To: <20060420203631.52176.qmail@web310.biz.mail.mud.yahoo.com> Message-ID: <20060420134334.Q17237@sapphire.juniper.net> References: <20060420203631.52176.qmail@web310.biz.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 20 Apr 2006 20:43:56.0639 (UTC) FILETIME=[24D74EF0:01C664BB] X-Spam-Score: -2.6 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 consensus X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Hi Rick, On Thu, 20 Apr 2006, Rick Wilder wrote: > > Dear Working Group Participants, > > May we please have more active response on the question of whether > draft-kulmala-l3vpn-interas-option-d-02 should become a working group > document? > No. rahul > We need more active response on this issue to determine a consensus. Intention to > implement from equipment vendors and intention to deploy from service providers would be > espcially helpful. Please speak up now. > > Thanks, > > Rick and Ron > > > > From l3vpn-bounces@ietf.org Sat Apr 22 20:43:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXSgY-0004K9-AK; Sat, 22 Apr 2006 20:42:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXSgX-0004K4-6C for l3vpn@ietf.org; Sat, 22 Apr 2006 20:42:45 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXSgV-0006Pg-Rr for l3vpn@ietf.org; Sat, 22 Apr 2006 20:42:45 -0400 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 k3N0gaX98987; Sat, 22 Apr 2006 17:42:36 -0700 (PDT) (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 k3N0gU532494; Sat, 22 Apr 2006 17:42:30 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200604230042.k3N0gU532494@merlot.juniper.net> To: "Martin Halstead" In-Reply-To: Your message of "Thu, 20 Apr 2006 11:33:02 BST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25548.1145752950.1@juniper.net> Date: Sat, 22 Apr 2006 17:42:30 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Martin, > Ron > > You make a good point - I think that 'draft-ietf-l3vpn-rt-constrain' > does play well with 'option d' as a means to restrict VPN route updates > to interested parties only. This could apply when a single ASBR is > peered with more than one ASBR (in my opinion a very good thing). The > distribution graphs (and associated policies) would then sit between > peered ASBRs, rather than across ASes as described in the 'constrain' > draft. Could you please elaborate on "does play well". Specifically, would option d require to rewrite NLRI carried in RT constrains ? Yakov. > > BTW - I think that in the case of L3 VPN, the 'constrain' draft should > add that the option is only applicable to multi-AS options 'b' and 'c' > and by implication will not work with option 'a'. > > Regards > > Martin > mhalstead@nexagent.com > > -----Original Message----- > From: Ron Bonica [mailto:rbonica@juniper.net] > Sent: 18 April 2006 19:37 > To: Martin Halstead > Cc: l3vpn@ietf.org > Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 > > Martin, > > BTW, would Option D play well with Constrained VPN Route Distribution ( > draft-ietf-l3vpn-rt-constrain)? > > Ron > From l3vpn-bounces@ietf.org Sat Apr 22 22:33:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXUPk-0003FA-Iw; Sat, 22 Apr 2006 22:33:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXUPj-0003Bb-Jr for l3vpn@ietf.org; Sat, 22 Apr 2006 22:33:31 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXUPj-0003RM-8F for l3vpn@ietf.org; Sat, 22 Apr 2006 22:33:31 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 22 Apr 2006 19:33:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,149,1144047600"; d="scan'208"; a="541745376:sNHT23713196" Received: from [127.0.0.1] ([207.17.136.44]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Apr 2006 19:33:30 -0700 Message-ID: <444AE776.3040006@juniper.net> Date: Sat, 22 Apr 2006 19:33:26 -0700 From: Pedro Roque Marques User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Rick Wilder References: <20060420203631.52176.qmail@web310.biz.mail.mud.yahoo.com> In-Reply-To: <20060420203631.52176.qmail@web310.biz.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2006 02:33:30.0186 (UTC) FILETIME=[4EE01AA0:01C6667E] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 consensus X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Rick Wilder wrote: > Dear Working Group Participants, > > May we please have more active response on the question of whether > draft-kulmala-l3vpn-interas-option-d-02 should become a working group > document? > I believe it should not. From a problem statement analysis it seems to ignore the existence of option b) deployments that perform per VRF routing policy and traffic filtering decisions (usually associated with option a) capabilities). From a solution point of view, it seems to me that the proposal is not explained in a detailed enough manner that one can assess the protocol and/or implementation changes being proposed. I also find the document very hard to read. I'd like to see a step by step analysis of the protocol mechanisms that are being introduced and or modified. I don't see this in the document... my personal impression is that it "hand waves" around some pretty complex implementation consequences of what is being proposed. Specific comments: Option 'A' inherently allows per VRF route readvertisement import/export policy at the AS border. Options 'B' and 'C' do not have this attribute, but remove Option 'A's requirement for per VRF [...] ==> This is not factually correct in my opinion. Given the knowledge of import targets per VRF, option b or c allow one to specific import and export route policies. The draft does call per per VRF configuration. This appears to be the problem statement in the document. It describes a set of mechanisms but i'd like to understand what is the problem so that we can evaluate other potential solutions. 4.1.1. Route Advertisement - Private interface forwarding VPN-IPv4 prefixes are advertised from ASBR1 to ASBR2 via a BGP session that is in the global routing table context. This implies that the advertised next-hop address is also reachable via the global routing table context. In order to force traffic to be forwarded via interface 'a', VRF forwarding entries need to be installed using a next-hop address that is in VRF3's (which resides on ASBR2) routing context. ==> The concept of having route advertisements in one instance refer to address in a separate instance needs to be looked at very carefully. It is unclear to me how the addressing realm for this next-hop is to be determined by the receiver, for instance. A next-hop on an ebgp session is expected to be directly connected to the peering interface. There is no discussion of the protocol changes that would be required to make this happen. 5.1. Inter-AS IP VPN Route Distribution Routes received from internal or external peers that are imported into ASBR VRFs SHOULD NOT be readvertised to any BGP neighbors. ==> Why ? what happens if the ASBR is also a PE ? regards, Pedro. From l3vpn-bounces@ietf.org Mon Apr 24 08:41:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY0NM-0005cG-MP; Mon, 24 Apr 2006 08:41:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY0NL-0005ag-Ky for l3vpn@ietf.org; Mon, 24 Apr 2006 08:41:11 -0400 Received: from mx.tellabs.fi ([193.65.253.34] helo=mx2-priv.tellabs.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY0NK-0001Ze-2m for l3vpn@ietf.org; Mon, 24 Apr 2006 08:41:11 -0400 Received: from fies1wms01a.tellabs.fi (HELO FIESEX1.tellabs-east.tellabsinc.net) ([172.19.6.63]) by mx2-priv.tellabs.fi with ESMTP; 24 Apr 2006 12:49:59 +0000 X-SBRS: None X-IronPort-AV: i="4.04,151,1144022400"; d="scan'208"; a="7127726:sNHT56468736" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Apr 2006 15:40:31 +0300 Message-ID: <4EE011314003124CA4389D37DC21940F03658C49@FIESEX1.tellabs-east.tellabsinc.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 consensus Thread-Index: AcZkukmZ4rPEQPzeQLyuf4+KHtw2eAC4Slng From: "Kulmala, Marko" To: "Rick Wilder" , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 consensus X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org =20 > -----Original Message----- > From: Rick Wilder [mailto:rick@rhwilder.net]=20 > Sent: 20. huhtikuuta 2006 23:37 > To: l3vpn@ietf.org > Subject: draft-kulmala-l3vpn-interas-option-d-02 consensus >=20 >=20 > Dear Working Group Participants, >=20 > May we please have more active response on the question of whether > draft-kulmala-l3vpn-interas-option-d-02 should become a=20 > working group document?=20 Yes.=20 >=20 > We need more active response on this issue to determine a=20 > consensus. Intention to implement from equipment vendors and=20 > intention to deploy from service providers would be espcially=20 > helpful. Please speak up now. Tellabs has 'option-d' implementation. Regards, Marko Kulmala =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From l3vpn-bounces@ietf.org Mon Apr 24 11:10:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY2hF-00034L-6t; Mon, 24 Apr 2006 11:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY2hD-00033f-9Y for l3vpn@ietf.org; Mon, 24 Apr 2006 11:09:51 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY2h9-00019v-0z for l3vpn@ietf.org; Mon, 24 Apr 2006 11:09:51 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA17635; Mon, 24 Apr 2006 10:09:40 -0500 (CDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3OF9dG13446; Mon, 24 Apr 2006 10:09:39 -0500 (CDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 08:09:38 -0700 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, 24 Apr 2006 08:09:38 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2D8BD@XCH-SW-42.sw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 consensus Thread-Index: AcZkus9jTjzldXTbTVqomYxLhQlVuQC9kg9A From: "Drake, John E" To: "Rick Wilder" , X-OriginalArrivalTime: 24 Apr 2006 15:09:39.0244 (UTC) FILETIME=[1B5AB6C0:01C667B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 consensus X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org yes > -----Original Message----- > From: Rick Wilder [mailto:rick@rhwilder.net] > Sent: Thursday, April 20, 2006 1:37 PM > To: l3vpn@ietf.org > Subject: draft-kulmala-l3vpn-interas-option-d-02 consensus >=20 >=20 > Dear Working Group Participants, >=20 > May we please have more active response on the question of whether > draft-kulmala-l3vpn-interas-option-d-02 should become a working group > document? >=20 > We need more active response on this issue to determine a consensus. > Intention to > implement from equipment vendors and intention to deploy from service > providers would be > espcially helpful. Please speak up now. >=20 > Thanks, >=20 > Rick and Ron >=20 >=20 >=20 From l3vpn-bounces@ietf.org Tue Apr 25 07:04:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYLKq-0003vd-AL; Tue, 25 Apr 2006 07:04:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYLKp-0003vY-41 for l3vpn@ietf.org; Tue, 25 Apr 2006 07:03:59 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYLKn-0007rm-Re for l3vpn@ietf.org; Tue, 25 Apr 2006 07:03:59 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.20]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 12:03:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Apr 2006 12:03:48 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 (Yakov Rekhter) Thread-Index: AcZm7wirYlzwdbNvRg696YrtbqWz9gAjpFhA From: "Martin Halstead" To: X-OriginalArrivalTime: 25 Apr 2006 11:03:48.0710 (UTC) FILETIME=[EDC39860:01C66857] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 (Yakov Rekhter) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org 1. Re: draft-kulmala-l3vpn-interas-option-d-02 (Yakov Rekhter) Martin, > Ron >=20 > You make a good point - I think that 'draft-ietf-l3vpn-rt-constrain' > does play well with 'option d' as a means to restrict VPN route updates > to interested parties only. This could apply when a single ASBR is > peered with more than one ASBR (in my opinion a very good thing). The > distribution graphs (and associated policies) would then sit between > peered ASBRs, rather than across ASes as described in the 'constrain' > draft. Could you please elaborate on "does play well". Specifically, would option d require to rewrite NLRI carried in RT constrains ? Yakov. MH: If the RT constrain is generated within an AS (a PE), then it would be 'rewritten' at the ASBR. An ASBR running option 'd' would advertise a 'new' RT constrain NLRI by the process of generating VPN-IPv4 prefixes within per VPN VRFs at the ASBR. The constrain draft does seem to be geared towards RFC4364 multi-AS option 'c' though as in option 'b', IP NLRI would be rewritten by the ASBR as well? =20 From l3vpn-bounces@ietf.org Tue Apr 25 07:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYM44-0002Yp-G3; Tue, 25 Apr 2006 07:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYM41-0002Yj-Tu for l3vpn@ietf.org; Tue, 25 Apr 2006 07:50:42 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYM41-0001rb-EV for l3vpn@ietf.org; Tue, 25 Apr 2006 07:50:41 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.20]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 12:50:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Apr 2006 12:50:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro Roque Marques) Thread-Index: AcZm7wirYlzwdbNvRg696YrtbqWz9gBaO3xA From: "Martin Halstead" To: X-OriginalArrivalTime: 25 Apr 2006 11:50:36.0828 (UTC) FILETIME=[778865C0:01C6685E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro Roque Marques) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Pedro Answers in-line. Regards Martin mhalstead@nexagent.com Message: 2 Date: Sat, 22 Apr 2006 19:33:26 -0700 From: Pedro Roque Marques Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 consensus To: Rick Wilder Cc: l3vpn@ietf.org Message-ID: <444AE776.3040006@juniper.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Rick Wilder wrote: > Dear Working Group Participants, >=20 > May we please have more active response on the question of whether=20 > draft-kulmala-l3vpn-interas-option-d-02 should become a working group > document?=20 >=20 I believe it should not. From a problem statement analysis it seems to ignore the existence of=20 option b) deployments that perform per VRF routing policy and traffic=20 filtering decisions (usually associated with option a) capabilities). MH: True - but RFC4364 does not describe using VRFs in option 'b'. I think that it is a long shot to say that importing RTs within a VRF on an ASBR is equivalent to 'option 'a' capabilities. In option 'b', RT and RD values are not advertised per ASBR VRF, rather they are advertised from PE to PE - a major difference. I appreciate you could change RT values on a per peer basis (depending on vendor support), but again that is nothing to do with option 'a's ability to generate VPN-IPv4 routes per VRF. Also, traffic filtering capabilities are not equivalent to option 'a'. There is no sub-interface on which to apply ACLs per VPN in option 'b' =20 From a solution point of view, it seems to me that the proposal is not=20 explained in a detailed enough manner that one can assess the protocol=20 and/or implementation changes being proposed. I also find the document very hard to read. I'd like to see a step by=20 step analysis of the protocol mechanisms that are being introduced and=20 or modified. I don't see this in the document... my personal impression=20 is that it "hand waves" around some pretty complex implementation=20 consequences of what is being proposed. MH: Fair comment, will take a look at being more specific.=20 Specific comments: Option 'A' inherently allows per VRF route readvertisement import/export policy at the AS border. Options 'B' and 'C' do not have this attribute, but remove Option 'A's requirement for per VRF [...] =3D=3D> This is not factually correct in my opinion. Given the knowledge of=20 import targets per VRF, option b or c allow one to specific import and=20 export route policies. The draft does call per per VRF configuration. MH: In addition to my first answer, options 'b' and 'c' DO NOT allow for per VRF exports at an ASBR. Further, option 'c' does not allow per VRF route filtering at an AS border.=20 This appears to be the problem statement in the document. It describes a set of mechanisms but i'd like to understand what is the problem so that we can evaluate other potential solutions. MH: There is an attempt at elaborating on the problem statement further in the document (section 9 - comparison of inter-AS options). 4.1.1. Route Advertisement - Private interface forwarding VPN-IPv4 prefixes are advertised from ASBR1 to ASBR2 via a BGP session that is in the global routing table context. This implies that the advertised next-hop address is also reachable via the global routing table context. In order to force traffic to be forwarded via interface 'a', VRF forwarding entries need to be installed using a next-hop address that is in VRF3's (which resides on ASBR2) routing context. =3D=3D> The concept of having route advertisements in one instance refer = to=20 address in a separate instance needs to be looked at very carefully. It=20 is unclear to me how the addressing realm for this next-hop is to be=20 determined by the receiver, for instance. A next-hop on an ebgp session is expected to be directly connected to=20 the peering interface. There is no discussion of the protocol changes=20 that would be required to make this happen. 5.1. Inter-AS IP VPN Route Distribution Routes received from internal or external peers that are imported into ASBR VRFs SHOULD NOT be readvertised to any BGP neighbors. =3D=3D> Why ? what happens if the ASBR is also a PE ? MH: Have pasted the whole paragraph below. If the ASBR is also a PE, then a separate IPV4 peer would be configured within a VRF context. In that case, routes would be advertised to the CE neighbour. The statement is meant for 'global' routing context neighbors. 'Routes received from internal or external peers that are imported=20 into ASBR VRFs SHOULD NOT be readvertised to any BGP neighbors.=20 Routes that are not imported into VRFs but are installed in the=20 ASBR's global routing table MAY be readvertised using existing Option 'B' techniques as described in the Multi-AS section of [RFC4364]. The ASBR MUST be equipped with RT based filtering mechanisms that=20 explicitly permit all or a subset of such RT values to be=20 readvertised to its neighbors. ' The reason for this statement is to allow an ASBR to operate option 'b' and 'd' concurrently on the same ASBR. In option 'd', an imported route is readvertised via an export statement within the same VRF - a major difference to option 'b'. You could in addition run option 'b' on the box by turning on a knob and disabling bgp route target filtering, but have to be careful to not readvertise the same route twice via some careful route mapping as the consequences could be nasty... Regards and thanks for the comments, Martin ------------------------------ _______________________________________________ L3vpn mailing list L3vpn@ietf.org https://www1.ietf.org/mailman/listinfo/l3vpn End of L3vpn Digest, Vol 24, Issue 10 ************************************* From l3vpn-bounces@ietf.org Tue Apr 25 13:17:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYR9p-0002jF-6R; Tue, 25 Apr 2006 13:17:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYR9n-0002jA-RF for l3vpn@ietf.org; Tue, 25 Apr 2006 13:16:59 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYR9m-0003W4-Hx for l3vpn@ietf.org; Tue, 25 Apr 2006 13:16:59 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 25 Apr 2006 10:16:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,154,1144047600"; d="scan'208"; a="542284140:sNHT24220768" Received: from [172.17.12.76] ([172.17.12.76]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 10:16:55 -0700 Message-ID: <444E5987.6010002@juniper.net> Date: Tue, 25 Apr 2006 10:16:55 -0700 From: Pedro Roque Marques User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Martin Halstead References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2006 17:16:55.0806 (UTC) FILETIME=[0D8359E0:01C6688C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro Roque Marques) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Martin Halstead wrote: > From a problem statement analysis it seems to ignore the existence of > option b) deployments that perform per VRF routing policy and traffic > filtering decisions (usually associated with option a) capabilities). > > > MH: True - but RFC4364 does not describe using VRFs in option 'b'. I > think that it is a long shot to say that importing RTs within a VRF on > an ASBR is equivalent to 'option 'a' capabilities. Martin, There is no standardization effort required to be able to use per VRF routing and traffic policies with "option b)". This draft should start by admitting that. This has been demonstrated in deployment. > In option 'b', RT and > RD values are not advertised per ASBR VRF, rather they are advertised > from PE to PE - a major difference. I'm sorry but why does that matter ? I'd like to start by understanding what problem you are trying to solve... that would allow us to discuss if there are other alternatives to solving that problem and which tradeoffs are there. A comment of "values are not advertised per VRF" is really hard to understand without such context. >I appreciate you could change RT > values on a per peer basis (depending on vendor support), but again that > is nothing to do with option 'a's ability to generate VPN-IPv4 routes > per VRF. I really don't understand what you mean by "ability to generate routes per VRF"... > Also, traffic filtering capabilities are not equivalent to > option 'a'. There is no sub-interface on which to apply ACLs per VPN in > option 'b' Why does that matter ? what are you trying to accomplish ? > ==> > This is not factually correct in my opinion. Given the knowledge of > import targets per VRF, option b or c allow one to specific import and > export route policies. The draft does call per per VRF configuration. > > MH: In addition to my first answer, options 'b' and 'c' DO NOT allow for > per VRF exports at an ASBR. What do you mean by per VRF exports ? If you mean applying BGP export policy it is evident that one can achieve this given the knowledge of which RTs correspond to which VRF. > > MH: Have pasted the whole paragraph below. If the ASBR is also a PE, > then a separate IPV4 peer would be configured within a VRF context. In > that case, routes would be advertised to the CE neighbour. The statement > is meant for 'global' routing context neighbors. This illustrates the point i was making about the draft not containing a detailed enough description of protocol mechanisms. There are conflicting statements regarding protocol behavior. This is not a document that is ready for WG status imho. Pedro. From l3vpn-bounces@ietf.org Wed Apr 26 10:07:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkfI-0002UL-HQ; Wed, 26 Apr 2006 10:06:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkfG-0002Tk-TO for l3vpn@ietf.org; Wed, 26 Apr 2006 10:06:46 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYkfG-0006Dy-KS for l3vpn@ietf.org; Wed, 26 Apr 2006 10:06:46 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.20]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 15:06:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Apr 2006 15:06:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro Roque Marques) Thread-Index: AcZojBHqIq4geHjbQJuRjToUwFFPigAo2I9Q From: "Martin Halstead" To: "Pedro Roque Marques" X-OriginalArrivalTime: 26 Apr 2006 14:06:45.0402 (UTC) FILETIME=[A6CB9FA0:01C6693A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: l3vpn@ietf.org Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro Roque Marques) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Pedro > In option 'b', RT and > RD values are not advertised per ASBR VRF, rather they are advertised > from PE to PE - a major difference.=20 >I'm sorry but why does that matter ? MH: No need to be sorry ;-) this matters for the following reasons (amongst others): Operational issues: Typically service providers have in-house or COTS based OSS systems that address single domain VPN provisioning only. These OSS systems allocate RT and RD values for a single domain only. When these service providers partner and run option 'b' (not many if any run option 'c') typically they need to introduce manual processes to get around allocating RT values across AS borders i.e. using someone else's RT values. Unfortunately, that is not always possible due to some SPs inability to change their automated systems and processes. Load balancing: SPs use various traffic load-balancing techniques between customer sites in order to optimize traffic flows within their own ASes. As described in RFC4364, this necessitates the use of different RD values provisioned across VRFs to which the customer is multi-homed. Similar mechanisms SHOULD be available when ASes are multi-homed and a SP wants to load balance to ASBR pairs. This is not possible in option 'b' where SPs run RRs. Optimal interconnect selection: Consider a customer site in the middle of the USA. It is connected to an AS (AS1) that is interconnected to another AS (AS2) at interconnect points in both New York and Los Angeles. In order to minimize latency, traffic must be sent to a site in Tokyo (connected to AS2) via the LA interconnect point and not via New York. From a network utilization perspective, routing Tokyo-bound traffic via New York incurs an inefficient, resource-consuming round trip traversal of the planet. Similarly, the same site might also send traffic to London (also connected via AS2). The optimal route for this traffic must however be via New York rather than LA as in that case the traffic path is more optimal. Assuming AS2 uses RRs, this routing scenario cannot be supported by option 'b' for the same reasons as described for load balancing above. RD overlap: The advertisement of RD values end-to-end between SPs, combined with the customer's use of private [RFC1918] addressing could result in RRs making incorrect best path decisions for identical routes received from external as well as internal PE network elements. This will occur where RD and customer address space overlap across ASes. Although the probability of this scenario is small, the consequences could be severe and difficult to isolate. RFC4364 states that RD values should be made unique by using public ASNs. Trouble is that not all SPs actually do that. Regards Martin From l3vpn-bounces@ietf.org Wed Apr 26 13:52:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYoBs-0004Ld-L2; Wed, 26 Apr 2006 13:52:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYoBr-0004LY-Jj for l3vpn@ietf.org; Wed, 26 Apr 2006 13:52:39 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYoBn-0001kk-7i for l3vpn@ietf.org; Wed, 26 Apr 2006 13:52:39 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 26 Apr 2006 10:51:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,158,1144047600"; d="scan'208"; a="542528899:sNHT25339372" Received: from [172.17.12.76] ([172.17.12.76]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 10:51:56 -0700 Message-ID: <444FB33C.40406@juniper.net> Date: Wed, 26 Apr 2006 10:51:56 -0700 From: Pedro Roque Marques User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Martin Halstead References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2006 17:51:56.0643 (UTC) FILETIME=[1C1F6330:01C6695A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro Roque Marques) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Martin Halstead wrote: > Operational issues: > Typically service providers have in-house or COTS based OSS systems that > address single domain VPN provisioning only. These OSS systems allocate > RT and RD values for a single domain only. When these service providers > partner and run option 'b' (not many if any run option 'c') typically > they need to introduce manual processes to get around allocating RT > values across AS borders i.e. using someone else's RT values. > Unfortunately, that is not always possible due to some SPs inability to > change their automated systems and processes. There are existing deployments that use RT translation... with option b) and c). RD translation would be highly undesirable from an implementation POV, imho. Which isn't to say that you need anything other than option b) / c) to do it. > > Load balancing: > SPs use various traffic load-balancing techniques between customer sites > in order to optimize traffic flows within their own ASes. As described > in RFC4364, this necessitates the use of different RD values provisioned > across VRFs to which the customer is multi-homed. That is not true. Naive network designs on the receiver that use centralized route reflectors (a solution that will not scale) cause problems such as lack of required path information. This is just a question of network design on the receiver... a problem for the receiver to solve for sure. Again, even if the receiver wants to do RD translation (a very questionable choice) this does not require any standardization effort other than what is currently defined in 2547. > Similar mechanisms > SHOULD be available when ASes are multi-homed and a SP wants to load > balance to ASBR pairs. This is not possible in option 'b' where SPs run > RRs. Just not available with centralized RRs. > > Optimal interconnect selection: > Consider a customer site in the middle of the USA. It is connected to an > AS (AS1) that is interconnected to another AS (AS2) at interconnect > points in both New York and Los Angeles. In order to minimize latency, > traffic must be sent to a site in Tokyo (connected to AS2) via the LA > interconnect point and not via New York. From a network utilization > perspective, routing Tokyo-bound traffic via New York incurs an > inefficient, resource-consuming round trip traversal of the planet. > Similarly, the same site might also send traffic to London (also > connected via AS2). The optimal route for this traffic must however be > via New York rather than LA as in that case the traffic path is more > optimal. Assuming AS2 uses RRs, this routing scenario cannot be > supported by option 'b' for the same reasons as described for load > balancing above. You are assuming centralized RRs. Centralized RRs have all sort of issues on a large scale network... including this one. Rewriting RDs is not going to make centralized RRs work either, as far as i can see. But if supporting centralized RRs if the goal of your work, why don't you state it upfront ? We can then evaluate the proposal by its merits. The current document as a inaccurate description of what the problem statement is. imho, this alone would be enough reason to conclude that the document is not ready for WG status. > > RD overlap: > The advertisement of RD values end-to-end between SPs, combined with the > customer's use of private [RFC1918] addressing could result in RRs > making incorrect best path decisions for identical routes received from > external as well as internal PE network elements. i don't believe the above is accurate. RDs are required to be assigned uniquely (this is completely independent of rfc1918 addressing). For RDs to be unique they need to rely on a publicly assigned value... there are 2 options available as you know. AS or public IP. These seem to work for pretty much everyone... Specially the networks that have these big OSS systems that you refer to in the beggining... i've never seen one deployment that doesn't unique RDs. Is there any ? can someone please step forward w/ an example ? To rehash: - Contrary to what the document states, option b) *does* allow per VRF route policy and traffic filtering decisions. There are existing deployments to prove this point. - There is no clearly defined problem statement, imho, to support the introduction of this document as a WG item. regards, Pedro. From l3vpn-bounces@ietf.org Thu Apr 27 04:50:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ2D7-0001Cf-IO; Thu, 27 Apr 2006 04:50:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ2D6-0001CX-7a for l3vpn@ietf.org; Thu, 27 Apr 2006 04:50:52 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ2D5-0005UL-PM for l3vpn@ietf.org; Thu, 27 Apr 2006 04:50:52 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.20]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 09:50:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Apr 2006 09:50:46 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro Roque Marques) Thread-Index: AcZpWjSmmX0PxPAeRsWezvfl3lIk+wAcMRhg From: "Martin Halstead" To: "Pedro Roque Marques" X-OriginalArrivalTime: 27 Apr 2006 08:50:50.0045 (UTC) FILETIME=[AEEF6ED0:01C669D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: l3vpn@ietf.org Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro Roque Marques) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Pedro ' There are existing deployments that use RT translation... with option b)=20 and c). RD translation would be highly undesirable from an=20 implementation POV, imho. Which isn't to say that you need anything=20 other than option b) / c) to do it.' MH: The problem with RT translation is that that infernal software the SPs use issues different numbers of RT values per VPN - some construct a VPN as hub-and-spoke, other as fully meshed, some partial mesh. So - RT translation is rather tricky in bilatereral relationship. For multilateral it is not possible when SPs have different allocation schemas. As for RDs, although option 'd' does not do RD 'translation', would be interested to understand why iyho RD translation is not desirable. ' That is not true. Naive network designs on the receiver that use=20 centralized route reflectors (a solution that will not scale) cause=20 problems such as lack of required path information. This is just a=20 question of network design on the receiver... a problem for the receiver to solve for sure.' MH: Agreed that centralized RRs don't scale and the receiver should do something about that ie distribute routes across RRs such that not all RR clusters contain all routes for all VPNs. Could you please explain in an option 'b' distributed RR implementation how a PE that has received a single path via ASBR pairs in the same AS can load balance traffic? That should address the optimal path issue I described next. Thanks. Martin MH:=20 -----Original Message----- From: Pedro Roque Marques [mailto:roque@juniper.net]=20 Sent: 26 April 2006 18:52 To: Martin Halstead Cc: l3vpn@ietf.org Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro Roque Marques) Martin Halstead wrote: > Operational issues: > Typically service providers have in-house or COTS based OSS systems that > address single domain VPN provisioning only. These OSS systems allocate > RT and RD values for a single domain only. When these service providers > partner and run option 'b' (not many if any run option 'c') typically > they need to introduce manual processes to get around allocating RT > values across AS borders i.e. using someone else's RT values. > Unfortunately, that is not always possible due to some SPs inability to > change their automated systems and processes. There are existing deployments that use RT translation... with option b) and c). RD translation would be highly undesirable from an=20 implementation POV, imho. Which isn't to say that you need anything=20 other than option b) / c) to do it. >=20 > Load balancing: > SPs use various traffic load-balancing techniques between customer sites > in order to optimize traffic flows within their own ASes. As described > in RFC4364, this necessitates the use of different RD values provisioned > across VRFs to which the customer is multi-homed. That is not true. Naive network designs on the receiver that use=20 centralized route reflectors (a solution that will not scale) cause=20 problems such as lack of required path information. This is just a=20 question of network design on the receiver... a problem for the receiver to solve for sure. Again, even if the receiver wants to do RD translation (a very=20 questionable choice) this does not require any standardization effort=20 other than what is currently defined in 2547. > Similar mechanisms > SHOULD be available when ASes are multi-homed and a SP wants to load > balance to ASBR pairs. This is not possible in option 'b' where SPs run > RRs. Just not available with centralized RRs. >=20 > Optimal interconnect selection: > Consider a customer site in the middle of the USA. It is connected to an > AS (AS1) that is interconnected to another AS (AS2) at interconnect > points in both New York and Los Angeles. In order to minimize latency, > traffic must be sent to a site in Tokyo (connected to AS2) via the LA > interconnect point and not via New York. From a network utilization > perspective, routing Tokyo-bound traffic via New York incurs an > inefficient, resource-consuming round trip traversal of the planet. > Similarly, the same site might also send traffic to London (also > connected via AS2). The optimal route for this traffic must however be > via New York rather than LA as in that case the traffic path is more > optimal. Assuming AS2 uses RRs, this routing scenario cannot be > supported by option 'b' for the same reasons as described for load > balancing above. You are assuming centralized RRs. Centralized RRs have all sort of=20 issues on a large scale network... including this one. Rewriting RDs is=20 not going to make centralized RRs work either, as far as i can see. But=20 if supporting centralized RRs if the goal of your work, why don't you=20 state it upfront ? We can then evaluate the proposal by its merits. The current document as a inaccurate description of what the problem=20 statement is. imho, this alone would be enough reason to conclude that=20 the document is not ready for WG status. >=20 > RD overlap: > The advertisement of RD values end-to-end between SPs, combined with the > customer's use of private [RFC1918] addressing could result in RRs > making incorrect best path decisions for identical routes received from > external as well as internal PE network elements. i don't believe the above is accurate. RDs are required to be assigned=20 uniquely (this is completely independent of rfc1918 addressing). For RDs to be unique they need to rely on a publicly assigned value... there are 2 options available as you know. AS or public IP. These seem to work for pretty much everyone... Specially the networks that have these big OSS systems that you refer to in the beggining... i've never seen one deployment that doesn't unique=20 RDs. Is there any ? can someone please step forward w/ an example ? To rehash: - Contrary to what the document states, option b) *does* allow per VRF=20 route policy and traffic filtering decisions. There are existing=20 deployments to prove this point. - There is no clearly defined problem statement, imho, to support the=20 introduction of this document as a WG item. regards, Pedro. From l3vpn-bounces@ietf.org Thu Apr 27 14:06:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZAt4-0006jL-FH; Thu, 27 Apr 2006 14:06:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZAt2-0006jG-PL for l3vpn@ietf.org; Thu, 27 Apr 2006 14:06:44 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZAt1-00068L-GY for l3vpn@ietf.org; Thu, 27 Apr 2006 14:06:44 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 27 Apr 2006 11:06:40 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,161,1144047600"; d="scan'208"; a="546467296:sNHT23195520" Received: from [172.17.12.76] ([172.17.12.76]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 11:06:35 -0700 Message-ID: <4451082B.6090903@juniper.net> Date: Thu, 27 Apr 2006 11:06:35 -0700 From: Pedro Roque Marques User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Martin Halstead References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2006 18:06:35.0482 (UTC) FILETIME=[525D53A0:01C66A25] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: l3vpn@ietf.org Subject: inter-as and reflection (was option-d consensus) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Martin Halstead wrote: > MH: The problem with RT translation is that that infernal software the > SPs use I'm trying to figure out if that was a typo or intentional :-) Regarding inter-as and route reflection interaction. If one is to use a centralized design where each externally received path is advertised with a different RD, then for each of these prefixes we have multiplied the routing information M times, where M is the number of exchanges w/ a given peer. We know from experience that M can get to be pretty large (10..20 peering points)... So a centralized RR design explodes routing information by a factor that is certainly unworkable in the long run. Both N (number of external routes) and M (number of peering sessions w/ ASn) are expected to grow with time and this NxM equation does not look pretty. The information one actually desires is to have on a per region basis the best exit point for a given "reachability" point. This is what you get by default by doing path selection on an NLRI using metrics as tie breaker. The logical conclusion, imho, would be that for large scale deployments a SP needs to have RRs per region that perform this local selection decision so that PEs are not bothered w/ it. That is why it is undesirable to rewrite RDs... doing so breaks the ability to perform path selection on what is essentially the same information. All this stuff is not anything new... all one needs to do is copy the design used for Internet route reflection. A pair of RRs per "region"/"pop" which pick the locally best exit points and reduce the ammount of routing information torwards the PEs. All the mechanisms are in place to achieve this... However efforts to get centralized RRs to see and reflect all possible paths (without path selection) may be counterproductive. I'd be very concerned if the WG where to give its stamp of approval to such attempts. It would also be contrary to the current direction the WG has taken... the recently approved rt-constrain mechanism is a step towards making decentralized RRs a more useful tool in l3vpn network design. regards, Pedro. From l3vpn-bounces@ietf.org Fri Apr 28 07:08:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZQpR-0000YK-1w; Fri, 28 Apr 2006 07:08:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZQpQ-0000YF-6p for l3vpn@ietf.org; Fri, 28 Apr 2006 07:08:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZPpT-0006fW-C0 for l3vpn@ietf.org; Fri, 28 Apr 2006 06:04:03 -0400 Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZPH5-0007i0-OV for l3vpn@ietf.org; Fri, 28 Apr 2006 05:28:32 -0400 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.20]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:28:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Apr 2006 10:28:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: inter-as and reflection (was option-d consensus) Thread-Index: AcZqJVmtNwzopjDeSpavTEDfuhN1gAAfJ3oQ From: "Martin Halstead" To: "Pedro Roque Marques" X-OriginalArrivalTime: 28 Apr 2006 09:28:27.0739 (UTC) FILETIME=[1B09F2B0:01C66AA6] X-Spam-Score: -2.6 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: l3vpn@ietf.org Subject: RE: inter-as and reflection (was option-d consensus) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Pedro You make some valid points about the need for regionalized RRs and the need to scale the control plane. As you know, SPs do load balance traffic to multi-homed sites within their domains. They do that via configuring different RD values per PE VRF pairs. All the option'd' draft says is that the same thing can be achieved using option'd' (just like option 'a'). That however is also not solved via distributed RRs within a region. Your statement in a previous email on load balancing: 'That is not true. Naive network designs on the receiver that use=20 centralized route reflectors (a solution that will not scale) cause=20 problems such as lack of required path information. This is just a=20 question of network design on the receiver... a problem for the receiver to solve for sure.' therefore does not stack up. As you now describe: ' The information one actually desires is to have on a per region basis=20 the best exit point for a given "reachability" point. This is what you=20 get by default by doing path selection on an NLRI using metrics as tie=20 breaker. The logical conclusion, imho, would be that for large scale=20 deployments a SP needs to have RRs per region that perform this local=20 selection decision so that PEs are not bothered w/ it.' Load balancing is not solved via regional route reflectors in option 'b' environments. I know I am being pedantic here, but you cannot therefore argue that option 'b' achieves the same end as option'd' for load balancing (and for that matter 'optimal' path selection across ASes). BTW: The phrase 'infernal' is definitely intentional :-) Regards Martin From l3vpn-bounces@ietf.org Fri Apr 28 14:28:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXhS-00065E-Co; Fri, 28 Apr 2006 14:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXhR-000659-Ir for l3vpn@ietf.org; Fri, 28 Apr 2006 14:28:17 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXhQ-0002zl-9y for l3vpn@ietf.org; Fri, 28 Apr 2006 14:28:17 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 28 Apr 2006 11:28:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,164,1144047600"; d="scan'208"; a="543002878:sNHT22740516" Received: from [172.17.12.76] ([172.17.12.76]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 11:28:15 -0700 Message-ID: <44525EBE.1090601@juniper.net> Date: Fri, 28 Apr 2006 11:28:14 -0700 From: Pedro Roque Marques User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Martin Halstead References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 18:28:15.0227 (UTC) FILETIME=[837C6CB0:01C66AF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: l3vpn@ietf.org Subject: Re: inter-as and reflection (was option-d consensus) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Martin Halstead wrote: > Pedro > > You make some valid points about the need for regionalized RRs and the > need to scale the control plane. > As you know, SPs do load balance > traffic to multi-homed sites within their domains. They do that via > configuring different RD values per PE VRF pairs. All the option'd' > draft says is that the same thing can be achieved using option'd' (just > like option 'a'). Does this document imply or recommend that different inter-as peering points rewrite the same "reachability information" with different RDs ? if so this practice can have very negative scaling implications and i would recommend the WG to think very carefully before putting its stamp of approval on such proposal. > That however is also not solved via distributed RRs > within a region. My claim is that using a reflection cluster per region makes it unnecessary to have different RD values. And is a more scalable approach. You have not refuted that, i believe. > Your statement in a previous email on load balancing: > [...] > there fore does not stack up. Please explain. > Load balancing is not solved via regional route reflectors in option 'b' > environments. Can you please provide some data to substantiate that claim. My data point: standard internet RR design of a pair of reflectors per "POP"/Region. Seems to work fine w/ locally optimal best exist point choices. Been deployed for a while. Inter-as mpls-vpn routing is equivalent to internet inter-as peering exchanges. Same prefix advertised via multiple exit points. > I know I am being pedantic here, but you cannot therefore > argue that option 'b' achieves the same end as option'd' for load > balancing (and for that matter 'optimal' path selection across ASes). My claim is: - that "local best route selection" is best solved using per region RRs; - centralized RRs will not scale. - option "d" has no magic properties. The entire argument for rewriting RDs stems from the concept of a centralized RR with per ingress PE decision. Which means each PE needs to do path selection between M different paths (number of inter-as exchange points... i.e. one per city). This is not the best way to scale a network. Pedro.