From l3vpn-bounces@ietf.org Fri Apr 8 11:09:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00561 for ; Fri, 8 Apr 2005 11:09:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJvCW-0008F4-9h for l3vpn-web-archive@ietf.org; Fri, 08 Apr 2005 11:15:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJuS9-0001lH-ID; Fri, 08 Apr 2005 10:27:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJuS5-0001kp-GK; Fri, 08 Apr 2005 10:27:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25332; Fri, 8 Apr 2005 10:27:15 -0400 (EDT) Message-Id: <200504081427.KAA25332@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 08 Apr 2005 10:27:15 -0400 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-mpls-vpn-mib-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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --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 : MPLS/BGP Layer 3 Virtual Private Network Management Information Base Author(s) : T. Nadeau, H. Van Der Linde Filename : draft-ietf-l3vpn-mpls-vpn-mib-07.txt Pages : 42 Date : 2005-4-7 This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multi-protocol Label Switching Layer-3 Virtual Private Networks on a Multi-Protocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-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-mpls-vpn-mib-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-mpls-vpn-mib-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: <2005-4-8105838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-mpls-vpn-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-8105838.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Fri Apr 8 11:14:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01125 for ; Fri, 8 Apr 2005 11:10:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJv82-0007PI-22 for l3vpn-web-archive@ietf.org; Fri, 08 Apr 2005 11:10:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJuRO-0001bl-E1; Fri, 08 Apr 2005 10:26:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJuRJ-0001bJ-1N; Fri, 08 Apr 2005 10:26:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25301; Fri, 8 Apr 2005 10:26:27 -0400 (EDT) Message-Id: <200504081426.KAA25301@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 08 Apr 2005 10:26:27 -0400 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-mgt-fwk-06.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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --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 : Framework for L3VPN Operations and Management Author(s) : Y. Mghazli, et al. Filename : draft-ietf-l3vpn-mgt-fwk-06.txt Pages : 22 Date : 2005-4-7 This document provides a framework for operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. Selection of specific approaches, making choices among information models and protocols are outside of the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mgt-fwk-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-mgt-fwk-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-mgt-fwk-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-8105831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-mgt-fwk-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-mgt-fwk-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-8105831.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Fri Apr 8 15:39:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29600 for ; Fri, 8 Apr 2005 15:39:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJzTU-00006v-DX for l3vpn-web-archive@ietf.org; Fri, 08 Apr 2005 15:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJz8a-0008FJ-09; Fri, 08 Apr 2005 15:27:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJz8W-0008Er-Gj; Fri, 08 Apr 2005 15:27:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26431; Fri, 8 Apr 2005 15:27:22 -0400 (EDT) Message-Id: <200504081927.PAA26431@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 08 Apr 2005 15:27:22 -0400 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-mgt-fwk-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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --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 : Framework for L3VPN Operations and Management Author(s) : Y. Mghazli, et al. Filename : draft-ietf-l3vpn-mgt-fwk-07.txt Pages : 22 Date : 2005-4-8 This document provides a framework for operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. Selection of specific approaches, making choices among information models and protocols are outside of the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mgt-fwk-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-mgt-fwk-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-mgt-fwk-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: <2005-4-8155949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-mgt-fwk-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-mgt-fwk-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-8155949.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Fri Apr 8 15:50:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03270 for ; Fri, 8 Apr 2005 15:50:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJzdJ-0001Y4-58 for l3vpn-web-archive@ietf.org; Fri, 08 Apr 2005 15:59:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJz8D-0008DW-TN; Fri, 08 Apr 2005 15:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJz89-0008Cg-Cf; Fri, 08 Apr 2005 15:27:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26380; Fri, 8 Apr 2005 15:26:59 -0400 (EDT) Message-Id: <200504081926.PAA26380@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 08 Apr 2005 15:26:59 -0400 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-tc-mib-06.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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 --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 : Definition of Textual Conventions for Virtual Private Network (VPN) Management Author(s) : B. Schliesser, T. Nadeau Filename : draft-ietf-l3vpn-tc-mib-06.txt Pages : 6 Date : 2005-4-8 This document describes Textual Conventions used for managing Virtual Private Networks (VPNs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-tc-mib-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-tc-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-tc-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-8155943.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-tc-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-tc-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-8155943.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Mon Apr 11 15:58:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15023 for ; Mon, 11 Apr 2005 15:58:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5Cc-0003Bj-8g for l3vpn-web-archive@ietf.org; Mon, 11 Apr 2005 16:08:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4oO-0008KY-4G; Mon, 11 Apr 2005 15:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4oJ-0008Jx-T1; Mon, 11 Apr 2005 15:43:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13542; Mon, 11 Apr 2005 15:43:01 -0400 (EDT) Message-Id: <200504111943.PAA13542@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 11 Apr 2005 15:43:01 -0400 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-mgt-fwk-08.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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --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 : Framework for L3VPN Operations and Management Author(s) : Y. Mghazli, et al. Filename : draft-ietf-l3vpn-mgt-fwk-08.txt Pages : 26 Date : 2005-4-11 This document provides a framework for operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. Selection of specific approaches, making choices among information models and protocols are outside of the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mgt-fwk-08.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-mgt-fwk-08.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-mgt-fwk-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-11161357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-mgt-fwk-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-mgt-fwk-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-11161357.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Mon Apr 11 16:52:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25834 for ; Mon, 11 Apr 2005 16:52:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL634-0006rG-4T for l3vpn-web-archive@ietf.org; Mon, 11 Apr 2005 17:02:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5hU-0003DY-RS; Mon, 11 Apr 2005 16:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5hQ-0003BG-0i; Mon, 11 Apr 2005 16:40:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23568; Mon, 11 Apr 2005 16:39:57 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5qr-00065u-T7; Mon, 11 Apr 2005 16:49:46 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DL5hP-00050q-B8; Mon, 11 Apr 2005 16:39:59 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 11 Apr 2005 16:39:59 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: l3vpn@ietf.org Subject: Last Call: 'MPLS/BGP Layer 3 Virtual Private Network Management Information Base' to Proposed Standard X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c The IESG has received a request from the Layer 3 Virtual Private Networks WG to consider the following document: - 'MPLS/BGP Layer 3 Virtual Private Network Management Information Base ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-07.txt From l3vpn-bounces@ietf.org Mon Apr 11 16:56:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26576 for ; Mon, 11 Apr 2005 16:56:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL66g-000746-MO for l3vpn-web-archive@ietf.org; Mon, 11 Apr 2005 17:06:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5ie-0003KG-4G; Mon, 11 Apr 2005 16:41:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5iZ-0003Jq-Ua; Mon, 11 Apr 2005 16:41:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23751; Mon, 11 Apr 2005 16:41:09 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5s1-00068X-Rk; Mon, 11 Apr 2005 16:50:57 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DL5iZ-00054N-Cp; Mon, 11 Apr 2005 16:41:11 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 11 Apr 2005 16:41:11 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: l3vpn@ietf.org Subject: Last Call: 'Definition of Textual Conventions for Virtual Private Network (VPN) Management' to Proposed Standard X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c The IESG has received a request from the Layer 3 Virtual Private Networks WG to consider the following document: - 'Definition of Textual Conventions for Virtual Private Network (VPN) Management ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-tc-mib-06.txt From l3vpn-bounces@ietf.org Wed Apr 13 20:20:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22555 for ; Wed, 13 Apr 2005 20:20:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsFa-0000wU-Ml for l3vpn-web-archive@ietf.org; Wed, 13 Apr 2005 20:30:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLs3o-0008Pi-Nm; Wed, 13 Apr 2005 20:18:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLs3n-0008Pd-Fh for l3vpn@megatron.ietf.org; Wed, 13 Apr 2005 20:18:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22502 for ; Wed, 13 Apr 2005 20:18:18 -0400 (EDT) Received: from web25308.mail.ukl.yahoo.com ([217.12.10.80]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLsDd-0000tK-8t for l3vpn@ietf.org; Wed, 13 Apr 2005 20:28:32 -0400 Received: (qmail 76144 invoked by uid 60001); 14 Apr 2005 00:18:06 -0000 Message-ID: <20050414001806.76142.qmail@web25308.mail.ukl.yahoo.com> Received: from [66.17.149.13] by web25308.mail.ukl.yahoo.com via HTTP; Thu, 14 Apr 2005 01:18:06 BST Date: Thu, 14 Apr 2005 01:18:06 +0100 (BST) From: John Smith To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 8bit Subject: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 8bit Hi, PEx -- PEz -- PEy This is in the context of L3 VPNs. PEz is a BGP route reflector connected to two clients PEx and PEy (its also connected to other PE routers which i have omitted for the sake of clarity). By default, PEy recieves all BGP UPDATEs from PEx which have PEx as the NEXT_HOP. This happens for the NEXT_HOP attribute in the BGP UPDATE message and also for the next-hop that is encoded inside MP_REACH_NLRI. This way, PEy knows that it needs to put an outer label that corresponds to the router PEx. Now, we want all the BGP labelled packets to terminate at the RR viz PEz. So, we configured next-hop-self on the RR thinking that it will change the NEXT_HOP path attribute carried in the BGP UPDATE message and that carried inside the MP_REACH_NLRI to that of the PEz. Is this correct? We find that the outer NEXT_HOP gets converted to that of the RR, but the internal still points to PEx. Is this vendor behavior incorrect or is there a flaw in our understanding? Thanks, John Send instant messages to your online friends http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Wed Apr 13 20:39:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23856 for ; Wed, 13 Apr 2005 20:39:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsYD-0001N9-CD for l3vpn-web-archive@ietf.org; Wed, 13 Apr 2005 20:49:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsMC-0002lZ-KV; Wed, 13 Apr 2005 20:37:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsMA-0002l6-Vl for l3vpn@megatron.ietf.org; Wed, 13 Apr 2005 20:37:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23600 for ; Wed, 13 Apr 2005 20:37:09 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsVw-0001JU-7B for l3vpn@ietf.org; Wed, 13 Apr 2005 20:47:24 -0400 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 01:37:01 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Apr 2005 20:36:59 -0400 Received: from [172.24.253.172] ([172.24.253.172]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 20:36:59 -0400 Message-ID: <425DBB29.3060501@juniper.net> Date: Wed, 13 Apr 2005 20:36:57 -0400 From: Ronald Bonica User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Smith References: <20050414001806.76142.qmail@web25308.mail.ukl.yahoo.com> In-Reply-To: <20050414001806.76142.qmail@web25308.mail.ukl.yahoo.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2005 00:36:59.0292 (UTC) FILETIME=[117BD5C0:01C5408A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi John, Normally, route reflectors don't set next-hop-self. If you let PEz relay the UPDATE without modifying it at all, things will work fine. Maybe I am misunderstanding point of your question? Ron John Smith wrote: > Hi, > > PEx -- PEz -- PEy > > This is in the context of L3 VPNs. PEz is a BGP route reflector connected to two clients > PEx and PEy (its also connected to other PE routers which i have omitted for the sake of > clarity). > > By default, PEy recieves all BGP UPDATEs from PEx which have PEx as the NEXT_HOP. This > happens for the NEXT_HOP attribute in the BGP UPDATE message and also for the next-hop > that is encoded inside MP_REACH_NLRI. This way, PEy knows that it needs to put an outer > label that corresponds to the router PEx. > > Now, we want all the BGP labelled packets to terminate at the RR viz PEz. So, we > configured next-hop-self on the RR thinking that it will change the NEXT_HOP path > attribute carried in the BGP UPDATE message and that carried inside the MP_REACH_NLRI to > that of the PEz. > > Is this correct? We find that the outer NEXT_HOP gets converted to that of the RR, but > the internal still points to PEx. Is this vendor behavior incorrect or is there a flaw in > our understanding? > > Thanks, > John > > Send instant messages to your online friends http://uk.messenger.yahoo.com > From l3vpn-bounces@ietf.org Wed Apr 13 20:46:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24345 for ; Wed, 13 Apr 2005 20:46:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsfI-0001XN-Ke for l3vpn-web-archive@ietf.org; Wed, 13 Apr 2005 20:57:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsTa-00048B-8k; Wed, 13 Apr 2005 20:44:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsTX-00047q-Ld for l3vpn@megatron.ietf.org; Wed, 13 Apr 2005 20:44:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24246 for ; Wed, 13 Apr 2005 20:44:46 -0400 (EDT) Received: from web25306.mail.ukl.yahoo.com ([217.12.10.78]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLsdH-0001Up-S9 for l3vpn@ietf.org; Wed, 13 Apr 2005 20:55:01 -0400 Received: (qmail 37471 invoked by uid 60001); 14 Apr 2005 00:44:37 -0000 Message-ID: <20050414004437.37469.qmail@web25306.mail.ukl.yahoo.com> Received: from [66.17.149.13] by web25306.mail.ukl.yahoo.com via HTTP; Thu, 14 Apr 2005 01:44:37 BST Date: Thu, 14 Apr 2005 01:44:37 +0100 (BST) From: John Smith To: Ronald Bonica , l3vpn@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 8bit Subject: Re: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 8bit Hi Ron, This is the problem. PEy has an MPLS tunnel till PEz and not till PEx. Routes recieved from PEx have PEx as the next-hop. BGP running on PEy will not be able to recursivly resolve the next-hops for the routes to PEx and will not use them. However, if we change the nexthop to that of PEz then PEy will install the routes. Its the same logic that exists in ordinary RRs. I am just trying to see if it will work for L3 VPNs OR as you say, it may be making no sense at all! Thanks, John --- Ronald Bonica wrote: > Hi John, > > Normally, route reflectors don't set next-hop-self. If you let PEz relay > the UPDATE without modifying it at all, things will work fine. > > Maybe I am misunderstanding point of your question? > > Ron > > > John Smith wrote: > > Hi, > > > > PEx -- PEz -- PEy > > > > This is in the context of L3 VPNs. PEz is a BGP route reflector connected to two > clients > > PEx and PEy (its also connected to other PE routers which i have omitted for the sake > of > > clarity). > > > > By default, PEy recieves all BGP UPDATEs from PEx which have PEx as the NEXT_HOP. > This > > happens for the NEXT_HOP attribute in the BGP UPDATE message and also for the > next-hop > > that is encoded inside MP_REACH_NLRI. This way, PEy knows that it needs to put an > outer > > label that corresponds to the router PEx. > > > > Now, we want all the BGP labelled packets to terminate at the RR viz PEz. So, we > > configured next-hop-self on the RR thinking that it will change the NEXT_HOP path > > attribute carried in the BGP UPDATE message and that carried inside the MP_REACH_NLRI > to > > that of the PEz. > > > > Is this correct? We find that the outer NEXT_HOP gets converted to that of the RR, > but > > the internal still points to PEx. Is this vendor behavior incorrect or is there a > flaw in > > our understanding? > > > > Thanks, > > John > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Wed Apr 13 20:51:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24547 for ; Wed, 13 Apr 2005 20:51:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLskE-0001fX-Dj for l3vpn-web-archive@ietf.org; Wed, 13 Apr 2005 21:02:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsa2-0005Fj-Nn; Wed, 13 Apr 2005 20:51:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsa1-0005Fb-6u for l3vpn@megatron.ietf.org; Wed, 13 Apr 2005 20:51:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24527 for ; Wed, 13 Apr 2005 20:51:35 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsju-0001fB-Ic for l3vpn@ietf.org; Wed, 13 Apr 2005 21:01:50 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2005 21:01:20 -0400 X-IronPort-AV: i="3.92,99,1112587200"; d="scan'208"; a="44496827:sNHT27494528" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3E0pNbd023818; Wed, 13 Apr 2005 20:51:25 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 20:51:24 -0400 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, 13 Apr 2005 20:51:23 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B6103295@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Doubt in BGP for L3 VPNs Thread-Index: AcVAiEsJ93YOH7c/R0OcaQtH+bGEUQAAnucA From: "Rajiv Asati \(rajiva\)" To: "John Smith" , X-OriginalArrivalTime: 14 Apr 2005 00:51:24.0951 (UTC) FILETIME=[1574EA70:01C5408C] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Subject: RE: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable John, > By default, PEy recieves all BGP UPDATEs from PEx which have=20 > PEx as the NEXT_HOP. This happens for the NEXT_HOP attribute=20 > in the BGP UPDATE message and also for the next-hop that is=20 > encoded inside MP_REACH_NLRI. This way, PEy knows that it=20 When the UPDATE carries MP_REACH_NLRI, the NEXT_HOP attribute should not be carried since the NEXT_HOP information is encoded inside the MP_REACH_NLRI. This is needed so that the same UPDATE can pack multiple MP_REACH_NLRI (that may have different NEXT_HOPs). Please take a look at the RFC2283. > Now, we want all the BGP labelled packets to terminate at the=20 > RR viz PEz.=20 Could you please explain "why" ? > Is this correct? We find that the outer NEXT_HOP gets=20 > converted to that of the RR, but the internal still points to=20 > PEx. Is this vendor behavior incorrect or is there a flaw in=20 > our understanding? By definition, the RR is not supposed to change the NEXT_HOP. Cheers, Rajiv > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org]=20 > On Behalf Of John Smith > Sent: Wednesday, April 13, 2005 8:18 PM > To: l3vpn@ietf.org > Subject: Doubt in BGP for L3 VPNs >=20 > Hi, >=20 > PEx -- PEz -- PEy >=20 > This is in the context of L3 VPNs. PEz is a BGP route=20 > reflector connected to two clients PEx and PEy (its also=20 > connected to other PE routers which i have omitted for the=20 > sake of clarity). >=20 > By default, PEy recieves all BGP UPDATEs from PEx which have=20 > PEx as the NEXT_HOP. This happens for the NEXT_HOP attribute=20 > in the BGP UPDATE message and also for the next-hop that is=20 > encoded inside MP_REACH_NLRI. This way, PEy knows that it=20 > needs to put an outer label that corresponds to the router PEx. >=20 > Now, we want all the BGP labelled packets to terminate at the=20 > RR viz PEz. So, we configured next-hop-self on the RR=20 > thinking that it will change the NEXT_HOP path attribute=20 > carried in the BGP UPDATE message and that carried inside the=20 > MP_REACH_NLRI to that of the PEz.=20 >=20 > Is this correct? We find that the outer NEXT_HOP gets=20 > converted to that of the RR, but the internal still points to=20 > PEx. Is this vendor behavior incorrect or is there a flaw in=20 > our understanding? >=20 > Thanks, > John >=20 > Send instant messages to your online friends=20 > http://uk.messenger.yahoo.com=20 >=20 From l3vpn-bounces@ietf.org Wed Apr 13 21:09:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25781 for ; Wed, 13 Apr 2005 21:09:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLt1T-00026P-PQ for l3vpn-web-archive@ietf.org; Wed, 13 Apr 2005 21:20:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsqj-0007a6-L0; Wed, 13 Apr 2005 21:08:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsqi-0007Zg-Pn for l3vpn@megatron.ietf.org; Wed, 13 Apr 2005 21:08:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25724 for ; Wed, 13 Apr 2005 21:08:43 -0400 (EDT) Received: from natint3.juniper.net ([66.129.224.36] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLt0T-00025R-9k for l3vpn@ietf.org; Wed, 13 Apr 2005 21:18:58 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id j3E18XX8059360; Wed, 13 Apr 2005 18:08:33 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id j3E18Xnp059357; Wed, 13 Apr 2005 18:08:33 -0700 (PDT) From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16989.49809.70074.120151@roque-bsd.juniper.net> Date: Wed, 13 Apr 2005 18:08:33 -0700 To: John Smith In-Reply-To: <20050414001806.76142.qmail@web25308.mail.ukl.yahoo.com> References: <20050414001806.76142.qmail@web25308.mail.ukl.yahoo.com> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit John Smith writes: > So, we configured next-hop-self on the RR thinking that it will > change the NEXT_HOP path attribute carried in the BGP UPDATE message > and that carried inside the MP_REACH_NLRI to that of the PEz. > Is this correct? Depends on your equipement. It will work as you described on a JunOS box. You should see PEx use a label assigned by the RR and mpls swap state for that label installed in the RR. > We find that the outer NEXT_HOP gets converted to > that of the RR, but the internal still points to PEx. Is this vendor > behavior incorrect or is there a flaw in our understanding? This is vendor defined behaviour, afaik, not standards defined behaviour. The ieft, imho, should get involved in defining "next-hop self" behaviour. Pedro. From l3vpn-bounces@ietf.org Wed Apr 13 21:12:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26112 for ; Wed, 13 Apr 2005 21:12:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLt4E-0002DI-OJ for l3vpn-web-archive@ietf.org; Wed, 13 Apr 2005 21:22:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsu3-0008L4-Ku; Wed, 13 Apr 2005 21:12:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsu2-0008Kl-NJ for l3vpn@megatron.ietf.org; Wed, 13 Apr 2005 21:12:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26051 for ; Wed, 13 Apr 2005 21:12:09 -0400 (EDT) Received: from natint3.juniper.net ([66.129.224.36] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLt3o-0002CW-7F for l3vpn@ietf.org; Wed, 13 Apr 2005 21:22:24 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id j3E1C1X8059387; Wed, 13 Apr 2005 18:12:01 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id j3E1C1sf059384; Wed, 13 Apr 2005 18:12:01 -0700 (PDT) From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16989.50017.441302.285871@roque-bsd.juniper.net> Date: Wed, 13 Apr 2005 18:12:01 -0700 To: Pedro Roque Marques In-Reply-To: <16989.49809.70074.120151@roque-bsd.juniper.net> References: <20050414001806.76142.qmail@web25308.mail.ukl.yahoo.com> <16989.49809.70074.120151@roque-bsd.juniper.net> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: John Smith , l3vpn@ietf.org Subject: correction was: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit sorry... mistyped. Pedro Roque Marques writes: > This is vendor defined behaviour, afaik, not standards defined > behaviour. The ieft, imho, should get involved in defining "next-hop ^^^^^^ should NOT > self" behaviour. > Pedro. From l3vpn-bounces@ietf.org Wed Apr 13 22:09:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29418 for ; Wed, 13 Apr 2005 22:09:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLtxX-0003cm-8a for l3vpn-web-archive@ietf.org; Wed, 13 Apr 2005 22:19:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLtmw-00086l-3I; Wed, 13 Apr 2005 22:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLtmu-00085y-R5 for l3vpn@megatron.ietf.org; Wed, 13 Apr 2005 22:09:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29361 for ; Wed, 13 Apr 2005 22:08:50 -0400 (EDT) Received: from web25310.mail.ukl.yahoo.com ([217.12.10.82]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLtwe-0003bD-Ju for l3vpn@ietf.org; Wed, 13 Apr 2005 22:19:07 -0400 Received: (qmail 65648 invoked by uid 60001); 14 Apr 2005 02:08:30 -0000 Message-ID: <20050414020830.65646.qmail@web25310.mail.ukl.yahoo.com> Received: from [66.17.149.13] by web25310.mail.ukl.yahoo.com via HTTP; Thu, 14 Apr 2005 03:08:30 BST Date: Thu, 14 Apr 2005 03:08:30 +0100 (BST) From: John Smith To: "Rajiv Asati \(rajiva\)" , l3vpn@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 8bit Subject: RE: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 8bit Hi Rajiv, > When the UPDATE carries MP_REACH_NLRI, the NEXT_HOP attribute should not > be carried since the NEXT_HOP information is encoded inside the > MP_REACH_NLRI. This is needed so that the same UPDATE can pack multiple > MP_REACH_NLRI (that may have different NEXT_HOPs). Please take a look at > the RFC2283. I understand the point that NEXT_HOP is not mandatory when we have MP_REACH_NLRI path attribute, but there are a lot of implementations in the wild that do advertise the NEXT_HOP nevertheless. Any sane implementation will NOT get bothered with a NEXT_HOP in the UPDATE message when there are only multiprotocol NLRIs to process. > > > Now, we want all the BGP labelled packets to terminate at the > > RR viz PEz. > > Could you please explain "why" ? I did that in my other mail. I'll do it once more. PEx -- RR -- PEy PEy does not have a MPLS tunnel till PEx. It has it only till the RR. In this case, PEy will not be able to install routes learnt from PEx (using 2547) as it will not be able to resolve the next-hop. In such cases, an admin can manually set the next-hop-self on RR so that RR sets the NEXT_HOP to itself in all the MPBGP NLRIs that it advertises to PEy. PEy will now be able to accept the L3 VPN prefixes because the next-hop in MP_REACH_NLRI is resolvable. > > > Is this correct? We find that the outer NEXT_HOP gets > > converted to that of the RR, but the internal still points to > > PEx. Is this vendor behavior incorrect or is there a flaw in > > our understanding? > > By definition, the RR is not supposed to change the NEXT_HOP. But there is nothing that forbids it from doing that! In fact, there could be scenarios when it becomes vital for the RR to do that. One case which i can think of at the top of my head right now is when you want to enforce the RR to come in the forwarding path. There could be zillion reasons why you may want that to happen, security, QoS, predictability in the path being taken in case you have equal cost BGP routes originating from your behind, etc. Thanks, John > > Cheers, > Rajiv > > > -----Original Message----- > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] > > On Behalf Of John Smith > > Sent: Wednesday, April 13, 2005 8:18 PM > > To: l3vpn@ietf.org > > Subject: Doubt in BGP for L3 VPNs > > > > Hi, > > > > PEx -- PEz -- PEy > > > > This is in the context of L3 VPNs. PEz is a BGP route > > reflector connected to two clients PEx and PEy (its also > > connected to other PE routers which i have omitted for the > > sake of clarity). > > > > By default, PEy recieves all BGP UPDATEs from PEx which have > > PEx as the NEXT_HOP. This happens for the NEXT_HOP attribute > > in the BGP UPDATE message and also for the next-hop that is > > encoded inside MP_REACH_NLRI. This way, PEy knows that it > > needs to put an outer label that corresponds to the router PEx. > > > > Now, we want all the BGP labelled packets to terminate at the > > RR viz PEz. So, we configured next-hop-self on the RR > > thinking that it will change the NEXT_HOP path attribute > > carried in the BGP UPDATE message and that carried inside the > > MP_REACH_NLRI to that of the PEz. > > > > Is this correct? We find that the outer NEXT_HOP gets > > converted to that of the RR, but the internal still points to > > PEx. Is this vendor behavior incorrect or is there a flaw in > > our understanding? > > > > Thanks, > > John > > > > Send instant messages to your online friends > > http://uk.messenger.yahoo.com > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Wed Apr 13 23:29:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04599 for ; Wed, 13 Apr 2005 23:29:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvCI-0005Nd-3z for l3vpn-web-archive@ietf.org; Wed, 13 Apr 2005 23:39:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLv08-000244-19; Wed, 13 Apr 2005 23:26:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLuzY-0001y5-8D for l3vpn@megatron.ietf.org; Wed, 13 Apr 2005 23:26:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04524 for ; Wed, 13 Apr 2005 23:26:05 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLv9S-0005KH-Qo for l3vpn@ietf.org; Wed, 13 Apr 2005 23:36:23 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 Apr 2005 20:25:58 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3E3PolG012375; Wed, 13 Apr 2005 20:25:50 -0700 (PDT) Received: from [10.21.123.34] (sjc-vpn6-802.cisco.com [10.21.123.34]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDY05922; Wed, 13 Apr 2005 20:25:54 -0700 (PDT) Message-ID: <425DE2C0.5050808@cisco.com> Date: Wed, 13 Apr 2005 20:25:52 -0700 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Smith References: <20050414020830.65646.qmail@web25310.mail.ukl.yahoo.com> In-Reply-To: <20050414020830.65646.qmail@web25310.mail.ukl.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: Doubt in BGP for L3 VPNs X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Hi John, Sure you are correct. There is no problem with RRs setting next hop to self even for VPN routes. The problem is with forwarding traffic ... you need to install the VPN labels into LFIBs and swap on them. Simply it requires an ASBR like functionality when inter-as option B is used. The difference is that here this is all one AS but the forwarding plane this is transparent. In your case when nhs is set for RR the IGP will be impl-null label so will not exist. When the topology grows you also need to consider imposing IGP/LDP label when swapping VPN packets at the RR. Is your doubt resolved ? Cheers, R. > John Smith wrote: > > Hi Rajiv, > > >>When the UPDATE carries MP_REACH_NLRI, the NEXT_HOP attribute should not >>be carried since the NEXT_HOP information is encoded inside the >>MP_REACH_NLRI. This is needed so that the same UPDATE can pack multiple >>MP_REACH_NLRI (that may have different NEXT_HOPs). Please take a look at >>the RFC2283. > > > I understand the point that NEXT_HOP is not mandatory when we have MP_REACH_NLRI path > attribute, but there are a lot of implementations in the wild that do advertise the > NEXT_HOP nevertheless. Any sane implementation will NOT get bothered with a NEXT_HOP in > the UPDATE message when there are only multiprotocol NLRIs to process. > > >>>Now, we want all the BGP labelled packets to terminate at the >>>RR viz PEz. >> >>Could you please explain "why" ? > > > I did that in my other mail. I'll do it once more. > > PEx -- RR -- PEy > > PEy does not have a MPLS tunnel till PEx. It has it only till the RR. In this case, PEy > will not be able to install routes learnt from PEx (using 2547) as it will not be able to > resolve the next-hop. In such cases, an admin can manually set the next-hop-self on RR so > that RR sets the NEXT_HOP to itself in all the MPBGP NLRIs that it advertises to PEy. PEy > will now be able to accept the L3 VPN prefixes because the next-hop in MP_REACH_NLRI is > resolvable. > > > >>>Is this correct? We find that the outer NEXT_HOP gets >>>converted to that of the RR, but the internal still points to >>>PEx. Is this vendor behavior incorrect or is there a flaw in >>>our understanding? >> >>By definition, the RR is not supposed to change the NEXT_HOP. > > > But there is nothing that forbids it from doing that! In fact, there could be scenarios > when it becomes vital for the RR to do that. One case which i can think of at the top of > my head right now is when you want to enforce the RR to come in the forwarding path. > There could be zillion reasons why you may want that to happen, security, QoS, > predictability in the path being taken in case you have equal cost BGP routes originating > from your behind, etc. > > Thanks, > John > > >>Cheers, >>Rajiv >> >> >>>-----Original Message----- >>>From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] >>>On Behalf Of John Smith >>>Sent: Wednesday, April 13, 2005 8:18 PM >>>To: l3vpn@ietf.org >>>Subject: Doubt in BGP for L3 VPNs >>> >>>Hi, >>> >>>PEx -- PEz -- PEy >>> >>>This is in the context of L3 VPNs. PEz is a BGP route >>>reflector connected to two clients PEx and PEy (its also >>>connected to other PE routers which i have omitted for the >>>sake of clarity). >>> >>>By default, PEy recieves all BGP UPDATEs from PEx which have >>>PEx as the NEXT_HOP. This happens for the NEXT_HOP attribute >>>in the BGP UPDATE message and also for the next-hop that is >>>encoded inside MP_REACH_NLRI. This way, PEy knows that it >>>needs to put an outer label that corresponds to the router PEx. >>> >>>Now, we want all the BGP labelled packets to terminate at the >>>RR viz PEz. So, we configured next-hop-self on the RR >>>thinking that it will change the NEXT_HOP path attribute >>>carried in the BGP UPDATE message and that carried inside the >>>MP_REACH_NLRI to that of the PEz. >>> >>>Is this correct? We find that the outer NEXT_HOP gets >>>converted to that of the RR, but the internal still points to >>>PEx. Is this vendor behavior incorrect or is there a flaw in >>>our understanding? >>> >>>Thanks, >>>John >>> >>>Send instant messages to your online friends >>>http://uk.messenger.yahoo.com >>> >> >> > > Send instant messages to your online friends http://uk.messenger.yahoo.com > From l3vpn-bounces@ietf.org Wed Apr 13 23:42:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05461 for ; Wed, 13 Apr 2005 23:42:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvPZ-0005is-FH for l3vpn-web-archive@ietf.org; Wed, 13 Apr 2005 23:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvBG-00043r-Uq; Wed, 13 Apr 2005 23:38:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvBD-00040z-2z for l3vpn@megatron.ietf.org; Wed, 13 Apr 2005 23:38:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05237 for ; Wed, 13 Apr 2005 23:38:08 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvL6-0005bX-PT for l3vpn@ietf.org; Wed, 13 Apr 2005 23:48:26 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2005 23:47:54 -0400 X-IronPort-AV: i="3.92,100,1112587200"; d="scan'208"; a="44524334:sNHT29965740" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3E3bwbb001749; Wed, 13 Apr 2005 23:37:58 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 23:37:57 -0400 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, 13 Apr 2005 23:37:56 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B61032B3@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Doubt in BGP for L3 VPNs Thread-Index: AcVAlunn6N614hLVRD+zQ1pNjeIdUAAB2dOQ From: "Rajiv Asati \(rajiva\)" To: "John Smith" , X-OriginalArrivalTime: 14 Apr 2005 03:37:57.0350 (UTC) FILETIME=[59640060:01C540A3] X-Spam-Score: 1.1 (+) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable Subject: RE: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable John, As long as RR can change the NEXT_HOP within MP_REACH_NLRI, associate a new label with the NLRI, and install the label mapping in the MPLS forwarding table, it should work fine. It puts the RR in the forwarding path of VPN traffic. I do have a follow-up Q on the background though. Please see inline... > PEx -- RR -- PEy >=20 > PEy does not have a MPLS tunnel till PEx. It has it only till=20 > the RR. In this case, PEy will not be able to install routes=20 > learnt from PEx (using 2547) as it will not be able to=20 > resolve the next-hop. In such cases, an admin can manually=20 So, PEx has an LSP to RR, and so does PEy. (Just having the LSP tunnel on one segment will not provide the MPLS path between PEs.) Just curious What's the reason behind PEs not learning each other's route and/or label ? Cheers, Rajiv > -----Original Message----- > From: John Smith [mailto:jsmith4112003@yahoo.co.uk]=20 > Sent: Wednesday, April 13, 2005 10:09 PM > To: Rajiv Asati (rajiva); l3vpn@ietf.org > Subject: RE: Doubt in BGP for L3 VPNs >=20 > Hi Rajiv, >=20 > > When the UPDATE carries MP_REACH_NLRI, the NEXT_HOP=20 > attribute should=20 > > not be carried since the NEXT_HOP information is encoded inside the=20 > > MP_REACH_NLRI. This is needed so that the same UPDATE can pack=20 > > multiple MP_REACH_NLRI (that may have different NEXT_HOPs). Please=20 > > take a look at the RFC2283. >=20 > I understand the point that NEXT_HOP is not mandatory when we=20 > have MP_REACH_NLRI path attribute, but there are a lot of=20 > implementations in the wild that do advertise the NEXT_HOP=20 > nevertheless. Any sane implementation will NOT get bothered=20 > with a NEXT_HOP in the UPDATE message when there are only=20 > multiprotocol NLRIs to process. >=20 > >=20 > > > Now, we want all the BGP labelled packets to terminate at=20 > the RR viz=20 > > > PEz. > >=20 > > Could you please explain "why" ? >=20 > I did that in my other mail. I'll do it once more. >=20 > PEx -- RR -- PEy >=20 > PEy does not have a MPLS tunnel till PEx. It has it only till=20 > the RR. In this case, PEy will not be able to install routes=20 > learnt from PEx (using 2547) as it will not be able to=20 > resolve the next-hop. In such cases, an admin can manually=20 > set the next-hop-self on RR so that RR sets the NEXT_HOP to=20 > itself in all the MPBGP NLRIs that it advertises to PEy. PEy=20 > will now be able to accept the L3 VPN prefixes because the=20 > next-hop in MP_REACH_NLRI is resolvable. >=20 >=20 > >=20 > > > Is this correct? We find that the outer NEXT_HOP gets=20 > converted to=20 > > > that of the RR, but the internal still points to PEx. Is=20 > this vendor=20 > > > behavior incorrect or is there a flaw in our understanding? > >=20 > > By definition, the RR is not supposed to change the NEXT_HOP. >=20 > But there is nothing that forbids it from doing that! In=20 > fact, there could be scenarios when it becomes vital for the=20 > RR to do that. One case which i can think of at the top of my=20 > head right now is when you want to enforce the RR to come in=20 > the forwarding path. > There could be zillion reasons why you may want that to=20 > happen, security, QoS, predictability in the path being taken=20 > in case you have equal cost BGP routes originating from your=20 > behind, etc. >=20 > Thanks, > John >=20 > >=20 > > Cheers, > > Rajiv > >=20 > > > -----Original Message----- > > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On=20 > > > Behalf Of John Smith > > > Sent: Wednesday, April 13, 2005 8:18 PM > > > To: l3vpn@ietf.org > > > Subject: Doubt in BGP for L3 VPNs > > >=20 > > > Hi, > > >=20 > > > PEx -- PEz -- PEy > > >=20 > > > This is in the context of L3 VPNs. PEz is a BGP route reflector=20 > > > connected to two clients PEx and PEy (its also connected=20 > to other PE=20 > > > routers which i have omitted for the sake of clarity). > > >=20 > > > By default, PEy recieves all BGP UPDATEs from PEx which=20 > have PEx as=20 > > > the NEXT_HOP. This happens for the NEXT_HOP attribute in the BGP=20 > > > UPDATE message and also for the next-hop that is encoded inside=20 > > > MP_REACH_NLRI. This way, PEy knows that it needs to put an outer=20 > > > label that corresponds to the router PEx. > > >=20 > > > Now, we want all the BGP labelled packets to terminate at=20 > the RR viz=20 > > > PEz. So, we configured next-hop-self on the RR thinking=20 > that it will=20 > > > change the NEXT_HOP path attribute carried in the BGP=20 > UPDATE message=20 > > > and that carried inside the MP_REACH_NLRI to that of the PEz. > > >=20 > > > Is this correct? We find that the outer NEXT_HOP gets=20 > converted to=20 > > > that of the RR, but the internal still points to PEx. Is=20 > this vendor=20 > > > behavior incorrect or is there a flaw in our understanding? > > >=20 > > > Thanks, > > > John > > >=20 > > > Send instant messages to your online friends=20 > > > http://uk.messenger.yahoo.com > > >=20 > >=20 > >=20 >=20 > Send instant messages to your online friends=20 > http://uk.messenger.yahoo.com=20 >=20 From l3vpn-bounces@ietf.org Fri Apr 15 15:07:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03437 for ; Fri, 15 Apr 2005 15:07:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWJv-0007cW-CV for l3vpn-web-archive@ietf.org; Fri, 15 Apr 2005 15:17:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMViy-0006nJ-B6; Fri, 15 Apr 2005 14:39:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMViw-0006nB-TK; Fri, 15 Apr 2005 14:39:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00243; Fri, 15 Apr 2005 14:39:25 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMVtC-0005rm-7J; Fri, 15 Apr 2005 14:50:02 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j3FIc0607918; Fri, 15 Apr 2005 11:38:00 -0700 (PDT) Message-Id: <200504151838.j3FIc0607918@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 15 Apr 2005 11:38:00 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: l3vpn@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4031 on Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs) 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4031 Title: Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs) Authors: M. Carugi, Ed., D. McDysan, Ed. Status: Informational Date: April 2005 Mailbox: marco.carugi@nortel.com, dave.mcdysan@mci.com Pages: 50 Characters: 118568 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l3vpn-requirements-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4031.txt This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider. This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050415113420.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4031 --OtherAccess Content-Type: Message/External-body; name="rfc4031.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050415113420.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Sun Apr 17 12:19:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNCV3-0001j9-Jn; Sun, 17 Apr 2005 12:19:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNCV1-0001j4-Vj for l3vpn@megatron.ietf.org; Sun, 17 Apr 2005 12:19:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02840 for ; Sun, 17 Apr 2005 12:19:53 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNCff-0002me-Lm for l3vpn@ietf.org; Sun, 17 Apr 2005 12:30:55 -0400 Received: from stevelaptop (c-24-1-178-175.hsd1.tx.comcast.net[24.1.178.175]) by comcast.net (sccrmhc14) with SMTP id <2005041716194601400h4r1ke>; Sun, 17 Apr 2005 16:19:46 +0000 From: "Steve Yao" To: "John Smith" , "Rajiv Asati \(rajiva\)" , Date: Sun, 17 Apr 2005 11:19:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20050414020830.65646.qmail@web25310.mail.ukl.yahoo.com> Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Cc: Subject: RE: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org John, If you want to enforce the RR to be in the forwarding path, would it be more convenient to set up explicit-routed LSPs between PEx and PEy that go through the RR? Steve -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org]On Behalf Of John Smith Sent: Wednesday, April 13, 2005 9:09 PM To: Rajiv Asati (rajiva); l3vpn@ietf.org Subject: RE: Doubt in BGP for L3 VPNs Hi Rajiv, > When the UPDATE carries MP_REACH_NLRI, the NEXT_HOP attribute should not > be carried since the NEXT_HOP information is encoded inside the > MP_REACH_NLRI. This is needed so that the same UPDATE can pack multiple > MP_REACH_NLRI (that may have different NEXT_HOPs). Please take a look at > the RFC2283. I understand the point that NEXT_HOP is not mandatory when we have MP_REACH_NLRI path attribute, but there are a lot of implementations in the wild that do advertise the NEXT_HOP nevertheless. Any sane implementation will NOT get bothered with a NEXT_HOP in the UPDATE message when there are only multiprotocol NLRIs to process. > > > Now, we want all the BGP labelled packets to terminate at the > > RR viz PEz. > > Could you please explain "why" ? I did that in my other mail. I'll do it once more. PEx -- RR -- PEy PEy does not have a MPLS tunnel till PEx. It has it only till the RR. In this case, PEy will not be able to install routes learnt from PEx (using 2547) as it will not be able to resolve the next-hop. In such cases, an admin can manually set the next-hop-self on RR so that RR sets the NEXT_HOP to itself in all the MPBGP NLRIs that it advertises to PEy. PEy will now be able to accept the L3 VPN prefixes because the next-hop in MP_REACH_NLRI is resolvable. > > > Is this correct? We find that the outer NEXT_HOP gets > > converted to that of the RR, but the internal still points to > > PEx. Is this vendor behavior incorrect or is there a flaw in > > our understanding? > > By definition, the RR is not supposed to change the NEXT_HOP. But there is nothing that forbids it from doing that! In fact, there could be scenarios when it becomes vital for the RR to do that. One case which i can think of at the top of my head right now is when you want to enforce the RR to come in the forwarding path. There could be zillion reasons why you may want that to happen, security, QoS, predictability in the path being taken in case you have equal cost BGP routes originating from your behind, etc. Thanks, John > > Cheers, > Rajiv > > > -----Original Message----- > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] > > On Behalf Of John Smith > > Sent: Wednesday, April 13, 2005 8:18 PM > > To: l3vpn@ietf.org > > Subject: Doubt in BGP for L3 VPNs > > > > Hi, > > > > PEx -- PEz -- PEy > > > > This is in the context of L3 VPNs. PEz is a BGP route > > reflector connected to two clients PEx and PEy (its also > > connected to other PE routers which i have omitted for the > > sake of clarity). > > > > By default, PEy recieves all BGP UPDATEs from PEx which have > > PEx as the NEXT_HOP. This happens for the NEXT_HOP attribute > > in the BGP UPDATE message and also for the next-hop that is > > encoded inside MP_REACH_NLRI. This way, PEy knows that it > > needs to put an outer label that corresponds to the router PEx. > > > > Now, we want all the BGP labelled packets to terminate at the > > RR viz PEz. So, we configured next-hop-self on the RR > > thinking that it will change the NEXT_HOP path attribute > > carried in the BGP UPDATE message and that carried inside the > > MP_REACH_NLRI to that of the PEz. > > > > Is this correct? We find that the outer NEXT_HOP gets > > converted to that of the RR, but the internal still points to > > PEx. Is this vendor behavior incorrect or is there a flaw in > > our understanding? > > > > Thanks, > > John > > > > Send instant messages to your online friends > > http://uk.messenger.yahoo.com > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Mon Apr 18 07:23:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNULi-0008QV-9c; Mon, 18 Apr 2005 07:23:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNULg-0008QQ-MQ for l3vpn@megatron.ietf.org; Mon, 18 Apr 2005 07:23:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08681 for ; Mon, 18 Apr 2005 07:23:28 -0400 (EDT) Received: from web60907.mail.yahoo.com ([216.155.196.83]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DNUWP-0006sz-2f for l3vpn@ietf.org; Mon, 18 Apr 2005 07:34:38 -0400 Received: (qmail 22083 invoked by uid 60001); 18 Apr 2005 11:23:14 -0000 Message-ID: <20050418112314.22081.qmail@web60907.mail.yahoo.com> Received: from [202.144.106.188] by web60907.mail.yahoo.com via HTTP; Mon, 18 Apr 2005 12:23:13 BST Date: Mon, 18 Apr 2005 12:23:13 +0100 (BST) From: Spice Sylvia To: Steve Yao , John Smith , "Rajiv Asati \(rajiva\)" , l3vpn@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 8bit Cc: Subject: RE: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hi, What could be more explicit than physically placing it in the forwarding path and setting next-hop to self? May I understand the need for an "LSP" in this case? -brgds Sylvia --- Steve Yao wrote: > John, > > If you want to enforce the RR to be in the > forwarding path, would it be more > convenient to > set up explicit-routed LSPs between PEx and PEy that > go through the RR? > > Steve > > -----Original Message----- > From: l3vpn-bounces@ietf.org > [mailto:l3vpn-bounces@ietf.org]On Behalf Of > John Smith > Sent: Wednesday, April 13, 2005 9:09 PM > To: Rajiv Asati (rajiva); l3vpn@ietf.org > Subject: RE: Doubt in BGP for L3 VPNs > > > Hi Rajiv, > > > When the UPDATE carries MP_REACH_NLRI, the > NEXT_HOP attribute should not > > be carried since the NEXT_HOP information is > encoded inside the > > MP_REACH_NLRI. This is needed so that the same > UPDATE can pack multiple > > MP_REACH_NLRI (that may have different NEXT_HOPs). > Please take a look at > > the RFC2283. > > I understand the point that NEXT_HOP is not > mandatory when we have > MP_REACH_NLRI path > attribute, but there are a lot of implementations in > the wild that do > advertise the > NEXT_HOP nevertheless. Any sane implementation will > NOT get bothered with a > NEXT_HOP in > the UPDATE message when there are only multiprotocol > NLRIs to process. > > > > > > Now, we want all the BGP labelled packets to > terminate at the > > > RR viz PEz. > > > > Could you please explain "why" ? > > I did that in my other mail. I'll do it once more. > > PEx -- RR -- PEy > > PEy does not have a MPLS tunnel till PEx. It has it > only till the RR. In > this case, PEy > will not be able to install routes learnt from PEx > (using 2547) as it will > not be able to > resolve the next-hop. In such cases, an admin can > manually set the > next-hop-self on RR so > that RR sets the NEXT_HOP to itself in all the MPBGP > NLRIs that it > advertises to PEy. PEy > will now be able to accept the L3 VPN prefixes > because the next-hop in > MP_REACH_NLRI is > resolvable. > > > > > > > Is this correct? We find that the outer NEXT_HOP > gets > > > converted to that of the RR, but the internal > still points to > > > PEx. Is this vendor behavior incorrect or is > there a flaw in > > > our understanding? > > > > By definition, the RR is not supposed to change > the NEXT_HOP. > > But there is nothing that forbids it from doing > that! In fact, there could > be scenarios > when it becomes vital for the RR to do that. One > case which i can think of > at the top of > my head right now is when you want to enforce the RR > to come in the > forwarding path. > There could be zillion reasons why you may want that > to happen, security, > QoS, > predictability in the path being taken in case you > have equal cost BGP > routes originating > from your behind, etc. > > Thanks, > John > > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: l3vpn-bounces@ietf.org > [mailto:l3vpn-bounces@ietf.org] > > > On Behalf Of John Smith > > > Sent: Wednesday, April 13, 2005 8:18 PM > > > To: l3vpn@ietf.org > > > Subject: Doubt in BGP for L3 VPNs > > > > > > Hi, > > > > > > PEx -- PEz -- PEy > > > > > > This is in the context of L3 VPNs. PEz is a BGP > route > > > reflector connected to two clients PEx and PEy > (its also > > > connected to other PE routers which i have > omitted for the > > > sake of clarity). > > > > > > By default, PEy recieves all BGP UPDATEs from > PEx which have > > > PEx as the NEXT_HOP. This happens for the > NEXT_HOP attribute > > > in the BGP UPDATE message and also for the > next-hop that is > > > encoded inside MP_REACH_NLRI. This way, PEy > knows that it > > > needs to put an outer label that corresponds to > the router PEx. > > > > > > Now, we want all the BGP labelled packets to > terminate at the > > > RR viz PEz. So, we configured next-hop-self on > the RR > > > thinking that it will change the NEXT_HOP path > attribute > > > carried in the BGP UPDATE message and that > carried inside the > > > MP_REACH_NLRI to that of the PEz. > > > > > > Is this correct? We find that the outer NEXT_HOP > gets > > > converted to that of the RR, but the internal > still points to > > > PEx. Is this vendor behavior incorrect or is > there a flaw in > > > our understanding? > > > > > > Thanks, > > > John > > > > > > Send instant messages to your online friends > > > http://uk.messenger.yahoo.com > > > > > > > > > Send instant messages to your online friends > http://uk.messenger.yahoo.com > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Mon Apr 18 13:22:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZxG-0006yi-SX; Mon, 18 Apr 2005 13:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZxF-0006yd-Ax for l3vpn@megatron.ietf.org; Mon, 18 Apr 2005 13:22:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07844 for ; Mon, 18 Apr 2005 13:22:34 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNa84-0005j7-7J for l3vpn@ietf.org; Mon, 18 Apr 2005 13:33:50 -0400 Received: from stevelaptop (c-24-1-178-175.hsd1.tx.comcast.net[24.1.178.175]) by comcast.net (sccrmhc13) with SMTP id <2005041817222501600hq9p8e>; Mon, 18 Apr 2005 17:22:25 +0000 From: "Steve Yao" To: "Spice Sylvia" , "John Smith" , "Rajiv Asati \(rajiva\)" , Date: Mon, 18 Apr 2005 12:22:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20050418112314.22081.qmail@web60907.mail.yahoo.com> Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: 7bit Cc: Subject: RE: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Sylvia, My understanding of the issue is to put the RR in the forwarding path AND to allow the L3VPN forwarding to work. Like mentioned previously by others, you need to have a forwarding entry such that the VPN label pushed by PEy will be eventually presented at PEx. Setting up an LSP from PEy to PEx is certainly one option here. But if you say you don't want the VPN labeled packets to go to PEx at all, then there is no need for the LSP. But then the question is what is it that you are trying to do? Steve -----Original Message----- From: Spice Sylvia [mailto:falsesylvia@yahoo.co.uk] Sent: Monday, April 18, 2005 6:23 AM To: Steve Yao; John Smith; Rajiv Asati (rajiva); l3vpn@ietf.org Subject: RE: Doubt in BGP for L3 VPNs Hi, What could be more explicit than physically placing it in the forwarding path and setting next-hop to self? May I understand the need for an "LSP" in this case? -brgds Sylvia --- Steve Yao wrote: > John, > > If you want to enforce the RR to be in the > forwarding path, would it be more > convenient to > set up explicit-routed LSPs between PEx and PEy that > go through the RR? > > Steve > > -----Original Message----- > From: l3vpn-bounces@ietf.org > [mailto:l3vpn-bounces@ietf.org]On Behalf Of > John Smith > Sent: Wednesday, April 13, 2005 9:09 PM > To: Rajiv Asati (rajiva); l3vpn@ietf.org > Subject: RE: Doubt in BGP for L3 VPNs > > > Hi Rajiv, > > > When the UPDATE carries MP_REACH_NLRI, the > NEXT_HOP attribute should not > > be carried since the NEXT_HOP information is > encoded inside the > > MP_REACH_NLRI. This is needed so that the same > UPDATE can pack multiple > > MP_REACH_NLRI (that may have different NEXT_HOPs). > Please take a look at > > the RFC2283. > > I understand the point that NEXT_HOP is not > mandatory when we have > MP_REACH_NLRI path > attribute, but there are a lot of implementations in > the wild that do > advertise the > NEXT_HOP nevertheless. Any sane implementation will > NOT get bothered with a > NEXT_HOP in > the UPDATE message when there are only multiprotocol > NLRIs to process. > > > > > > Now, we want all the BGP labelled packets to > terminate at the > > > RR viz PEz. > > > > Could you please explain "why" ? > > I did that in my other mail. I'll do it once more. > > PEx -- RR -- PEy > > PEy does not have a MPLS tunnel till PEx. It has it > only till the RR. In > this case, PEy > will not be able to install routes learnt from PEx > (using 2547) as it will > not be able to > resolve the next-hop. In such cases, an admin can > manually set the > next-hop-self on RR so > that RR sets the NEXT_HOP to itself in all the MPBGP > NLRIs that it > advertises to PEy. PEy > will now be able to accept the L3 VPN prefixes > because the next-hop in > MP_REACH_NLRI is > resolvable. > > > > > > > Is this correct? We find that the outer NEXT_HOP > gets > > > converted to that of the RR, but the internal > still points to > > > PEx. Is this vendor behavior incorrect or is > there a flaw in > > > our understanding? > > > > By definition, the RR is not supposed to change > the NEXT_HOP. > > But there is nothing that forbids it from doing > that! In fact, there could > be scenarios > when it becomes vital for the RR to do that. One > case which i can think of > at the top of > my head right now is when you want to enforce the RR > to come in the > forwarding path. > There could be zillion reasons why you may want that > to happen, security, > QoS, > predictability in the path being taken in case you > have equal cost BGP > routes originating > from your behind, etc. > > Thanks, > John > > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: l3vpn-bounces@ietf.org > [mailto:l3vpn-bounces@ietf.org] > > > On Behalf Of John Smith > > > Sent: Wednesday, April 13, 2005 8:18 PM > > > To: l3vpn@ietf.org > > > Subject: Doubt in BGP for L3 VPNs > > > > > > Hi, > > > > > > PEx -- PEz -- PEy > > > > > > This is in the context of L3 VPNs. PEz is a BGP > route > > > reflector connected to two clients PEx and PEy > (its also > > > connected to other PE routers which i have > omitted for the > > > sake of clarity). > > > > > > By default, PEy recieves all BGP UPDATEs from > PEx which have > > > PEx as the NEXT_HOP. This happens for the > NEXT_HOP attribute > > > in the BGP UPDATE message and also for the > next-hop that is > > > encoded inside MP_REACH_NLRI. This way, PEy > knows that it > > > needs to put an outer label that corresponds to > the router PEx. > > > > > > Now, we want all the BGP labelled packets to > terminate at the > > > RR viz PEz. So, we configured next-hop-self on > the RR > > > thinking that it will change the NEXT_HOP path > attribute > > > carried in the BGP UPDATE message and that > carried inside the > > > MP_REACH_NLRI to that of the PEz. > > > > > > Is this correct? We find that the outer NEXT_HOP > gets > > > converted to that of the RR, but the internal > still points to > > > PEx. Is this vendor behavior incorrect or is > there a flaw in > > > our understanding? > > > > > > Thanks, > > > John > > > > > > Send instant messages to your online friends > > > http://uk.messenger.yahoo.com > > > > > > > > > Send instant messages to your online friends > http://uk.messenger.yahoo.com > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Mon Apr 18 14:52:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbMG-0000b2-CG; Mon, 18 Apr 2005 14:52:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbME-0000ax-UJ for l3vpn@megatron.ietf.org; Mon, 18 Apr 2005 14:52:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17070 for ; Mon, 18 Apr 2005 14:52:29 -0400 (EDT) From: kkhanna@isocore.com Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNbX4-0002nw-Qw for l3vpn@ietf.org; Mon, 18 Apr 2005 15:03:44 -0400 Received: from cpanel by ns1.cpanel.btnaccess.com with local (Exim 4.50) id 1DNbM0-0002n0-7J for l3vpn@ietf.org; Mon, 18 Apr 2005 14:52:16 -0400 Received: from 68.228.14.175 ([68.228.14.175]) by isocore.com (Horde) with HTTP for ; Mon, 18 Apr 2005 14:52:15 -0400 Message-ID: <20050418145215.bo0vnejrjy5co0cs@isocore.com> Date: Mon, 18 Apr 2005 14:52:15 -0400 To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Subject: MPLS 2005 Call for Presentations (Oct 16-19, Wash. DC) 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org ===================================== MPLS 2005 International Conference http://www.mpls2005.com October 16-19, 2005 Washington, DC ====================================== The Program Committee of MPLS2005 () is soliciting presentation proposals for this conference. If you wish to suggest a particular topic or a contribution, please send a one page long proposal (including speaker's contact details) to the attention of the Technical Program Committee at mpls2005-cfp@isocore.com by June 10, 2005. This year's conference will include, but not be limited to, topics such as: - MPLS in multi-area and multi-AS networks - Point-to-multipoint MPLS and applications - Supporting multicast in MPLS VPNs and for VPLS - Single and Multi-hop Pseudowire placement, setup and management - Providing QoS in MPLS networks - MPLS network management - OAM for MPLS networks - MPLS in the Next Generation Network - Voice over IP/MPLS - Triple-play applications on MPLS - MPLS-enabled Advanced services and converged networks - Interworking and migration for MPLS and GMPLS - Multi-layer networks and integration with non-packet technologies - Deploying, interworking and operating L2 and L3 MPLS VPNs - MPLS deployment experience: scaling, performance and security - Testing the technology: MPLS test tools and experience - Protection, restoration and reliability - Network processors for MPLS and GMPLS - MPLS/GMPLS control plane resilience, scaling and robustness - MPLS TE applications of the Path Computation Element (PCE) - Motivations and requirements for extending MPLS into the access network The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations from the vendor, service provider, research and user community are solicited on new technologies and operational experience. REGISTRATION is also now open, with extremely lucrative early-bird discounts - visit for details. Thank you for your continued support. Regards, Kavita From l3vpn-bounces@ietf.org Mon Apr 18 15:23:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbq9-0004dS-RV; Mon, 18 Apr 2005 15:23:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbq8-0004bY-A2 for l3vpn@megatron.ietf.org; Mon, 18 Apr 2005 15:23:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21026 for ; Mon, 18 Apr 2005 15:23:22 -0400 (EDT) Received: from web60906.mail.yahoo.com ([216.155.196.82]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DNc0y-0003yB-5X for l3vpn@ietf.org; Mon, 18 Apr 2005 15:34:38 -0400 Received: (qmail 99453 invoked by uid 60001); 18 Apr 2005 19:23:12 -0000 Message-ID: <20050418192312.99451.qmail@web60906.mail.yahoo.com> Received: from [202.144.106.188] by web60906.mail.yahoo.com via HTTP; Mon, 18 Apr 2005 20:23:12 BST Date: Mon, 18 Apr 2005 20:23:12 +0100 (BST) From: Spice Sylvia To: l3vpn@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 8bit Subject: RE: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Steve, This is the one case whose behaviour I am trying to clarify. Take the case where the RR acts as both the P and PE router. The same RR can be an PE+transit for some customer scenarios, the label mapping can be carried by BGP for both cases. for example: CE CE | | PE PE | | CE---PE-----RR-----RR----PE--CE | | CE CE This CEs all belong to the same VPN. Rather than use a seperate mechanism to signal a P2P LSP across PEs, let BGP carry the association, by mapping traffic/prefixes to the appropriate customer VRFs. You agree that the VRFs in the middle on the RRs has to have VPN routes of all PEs in that VPN? ------------------------------------------------------ Send instant messages to your online friends http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Mon Apr 18 16:05:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcUQ-0005k5-1j; Mon, 18 Apr 2005 16:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcUO-0005fT-Cm for l3vpn@megatron.ietf.org; Mon, 18 Apr 2005 16:05:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29052 for ; Mon, 18 Apr 2005 16:04:58 -0400 (EDT) Received: from rchss002.chiaro.com ([63.88.196.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNcfF-0006no-CE for l3vpn@ietf.org; Mon, 18 Apr 2005 16:16:14 -0400 Received: from rchst007.cus.chiaro.com ([192.168.8.120]) by rchss002.chiaro.com (8.12.11/8.12.11) with SMTP id j3IK2PLW014875 for ; Mon, 18 Apr 2005 15:02:25 -0500 (CDT) (envelope-from syao@chiaro.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2005 15:04:42 -0500 Message-ID: <34B6386F843340459B22F59DFF7B12FF0133A66F@192-168-240-22.chiaro.com> Thread-Topic: Doubt in BGP for L3 VPNs Thread-Index: AcVETF1ebGnhp6OcTUacb4G614sc/AAA4V+g From: "Steve Yao" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Subject: RE: Doubt in BGP for L3 VPNs 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Sylvia, Yes. But in order to get to the VRF at RR, you need to have the label allocated by the RR instead of a label that's allocated by a PE and "reflected" by the RR to another PE. Steve -----Original Message----- From: Spice Sylvia [mailto:falsesylvia@yahoo.co.uk] Sent: Monday, April 18, 2005 2:23 PM To: l3vpn@ietf.org Subject: RE: Doubt in BGP for L3 VPNs Steve, This is the one case whose behaviour I am trying to clarify. Take the case where the RR acts as both the P and PE router. The same RR can be an PE+transit for some customer scenarios, the label mapping can be carried by BGP for both cases. for example: CE CE=20 | | PE PE | | CE---PE-----RR-----RR----PE--CE | | CE CE This CEs all belong to the same VPN. Rather than use a seperate mechanism to signal a P2P LSP across PEs, let BGP carry the association, by mapping traffic/prefixes to the appropriate customer VRFs. You agree that the VRFs in the middle on the RRs has to have VPN routes of all PEs in that VPN? ------------------------------------------------------ Send instant messages to your online friends = http://uk.messenger.yahoo.com=20 From l3vpn-bounces@ietf.org Tue Apr 26 22:35:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQcOr-0002Iz-F8; Tue, 26 Apr 2005 22:35:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQcOn-0002IF-A0; Tue, 26 Apr 2005 22:35:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15850; Tue, 26 Apr 2005 22:35:35 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQcbM-0006vV-R9; Tue, 26 Apr 2005 22:48:36 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DQcOm-0002ev-Fh; Tue, 26 Apr 2005 22:35:36 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 26 Apr 2005 22:35:36 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Internet Architecture Board , l3vpn mailing list , l3vpn chair , l3vpn chair , RFC Editor Subject: Document Action: 'Framework for L3VPN Operations and Management' to Informational RFC 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: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org The IESG has approved the following document: - 'Framework for L3VPN Operations and Management ' as an Informational RFC This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Margaret Wasserman. Technical Summary This document provides a framework for operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. Selection of specific approaches, making choices among information models and protocols are outside of the scope of this document. Working Group Summary There was support for this document in the WG. Protocol Quality This document has been reviewed for the IESG by Thomas Narten.