From internet-drafts@ietf.org Wed Jul 6 10:15:51 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2621A21F88BE; Wed, 6 Jul 2011 10:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krzU7EjMbtYK; Wed, 6 Jul 2011 10:15:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A244821F8895; Wed, 6 Jul 2011 10:15:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-mvpn-infra-addrs-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110706171550.14271.25316.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2011 10:15:50 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:15:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Work= ing Group of the IETF. Title : IPv4 and IPv6 Infrastructure Addresses in BGP Updates fo= r Multicast VPN Author(s) : Rahul Aggarwal Eric C. Rosen Filename : draft-ietf-l3vpn-mvpn-infra-addrs-05.txt Pages : 10 Date : 2011-07-06 To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN&= quot;) BGP routes; they also originate unicast VPN routes that carry MVPN- specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider'= ;s address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field t= hat specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as four- octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates draft-ietf- l3vpn-2547bis-mcast-bgp-08.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-infra-addrs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-infra-addrs-05.txt From zengqing@huawei.com Sun Jul 10 20:41:24 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2C111E807B; Sun, 10 Jul 2011 20:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-T8pg6xMJfz; Sun, 10 Jul 2011 20:41:23 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9911F11E807A; Sun, 10 Jul 2011 20:41:23 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO500HZVGWXNY@szxga04-in.huawei.com>; Mon, 11 Jul 2011 11:41:21 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO500B1NGWX5R@szxga04-in.huawei.com>; Mon, 11 Jul 2011 11:41:21 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACO11958; Mon, 11 Jul 2011 11:41:19 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 11 Jul 2011 11:41:18 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.31]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Mon, 11 Jul 2011 11:41:14 +0800 Date: Mon, 11 Jul 2011 03:42:11 +0000 From: Zengqing Subject: [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt X-Originating-IP: [10.110.98.163] To: "idr@ietf.org" , "l3vpn@ietf.org" Message-id: <520F3F1A8F14EC4C81AB2F2558D7EB49DC552D@szxeml526-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt Thread-index: AQHMP3ximLR1dj/49kqEhmYfUin9jw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 03:41:24 -0000 FYI. Any comments will be appreciated. Best Regards! Qing & Jie > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, July 04, 2011 6:48 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Maximum Transmission Unit Extended Community > for BGP-4 > Author(s) : Qing Zeng > Jie Dong > Filename : draft-zeng-idr-bgp-mtu-extension-00.txt > Pages : 6 > Date : 2011-07-04 > > Proper functioning of [RFC1191] path Maximum Transmission Unit (MTU) > discovery requires that IP routers have knowledge of the MTU for each > link to which they are connected. As MPLS progresses, [RFC3988] > specifies some extensions to LDP in support of LDP LSP MTU discovery. > For the LSP created using Border Gateway Protocol (BGP) [RFC3107], it > does not have the ability to signal the path MTU to the ingress Label > Switching Router (LSR). In the absence of this functionality, the > MTU for the BGP LSP must be statically configured by network > operators or by equivalent off-line mechanisms. > > This document defines the MTU Extended Community for BGP in support > of BGP LSP MTU discovery. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zeng-idr-bgp-mtu-extension-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-zeng-idr-bgp-mtu-extension-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From internet-drafts@ietf.org Mon Jul 11 15:12:26 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859B311E8309; Mon, 11 Jul 2011 15:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgGVECghP62N; Mon, 11 Jul 2011 15:12:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E7D11E82EF; Mon, 11 Jul 2011 15:12:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-ospfv3-pece-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711221225.24001.48412.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 15:12:25 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 22:12:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Work= ing Group of the IETF. Title : OSPFv3 as a PE-CE routing protocol Author(s) : Padma Pillay-Esnault Peter Moyer Jeff Doyle Emre Ertekin Michael Lundberg Filename : draft-ietf-l3vpn-ospfv3-pece-08.txt Pages : 20 Date : 2011-07-11 Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ospfv3-pece-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-ospfv3-pece-08.txt From iesg-secretary@ietf.org Tue Jul 19 08:37:57 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A129421F8AF6; Tue, 19 Jul 2011 08:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.822 X-Spam-Level: X-Spam-Status: No, score=-101.822 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zd++OgLKFLNp; Tue, 19 Jul 2011 08:37:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2314F21F8AF8; Tue, 19 Jul 2011 08:37:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Internal BGP as Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)' to Proposed Standard (draft-ietf-l3vpn-ibgp-08.txt) X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110719153754.20505.94358.idtracker@ietfa.amsl.com> Date: Tue, 19 Jul 2011 08:37:54 -0700 Cc: l3vpn chair , l3vpn mailing list , RFC Editor X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 15:37:57 -0000 The IESG has approved the following document: - 'Internal BGP as Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)' (draft-ietf-l3vpn-ibgp-08.txt) as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ibgp/ Technical Summary In current RFC4364 deployments, when BGP is used as the PE-CE routing protocol, BGP peering sessions are typically configured as an external peering between the VPN provider AS and the customer network AS. While this technique works well in situations where there are no BGP routing exchanges between the client network and other networks, it does have drawbacks for customer networks that use BGP internally for purposes other than interaction between CE and PE routers. In order to make the usage of BGP/MPLS VPN services as transparent as possible to any external interaction, it is desirable to define a mechanism by which PE-CE routers can exchange BGP routes by means other than external BGP. This document specifies a means to use Internal BGP for the purpose of exchanging PE-CE routes. Working Group Summary This document is a product of L3VPN WG. The document underwent WG Last Call in both the L3VPN and IDR WGs. Document Quality The L3VPN WG is aware of two implementations. Personnel Ben Niven-Jenkins is the Document Shepherd for this document Stewart Bryant is the Responsible Area Director. From iesg-secretary@ietf.org Tue Jul 19 10:09:03 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F64521F8599; Tue, 19 Jul 2011 10:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.22 X-Spam-Level: X-Spam-Status: No, score=-102.22 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izUxopB7OGZZ; Tue, 19 Jul 2011 10:08:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7098021F85CB; Tue, 19 Jul 2011 10:08:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN' to Proposed Standard (draft-ietf-l3vpn-mvpn-infra-addrs-05.txt) X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110719170854.17214.23900.idtracker@ietfa.amsl.com> Date: Tue, 19 Jul 2011 10:08:54 -0700 Cc: l3vpn chair , l3vpn mailing list , RFC Editor X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 17:09:03 -0000 The IESG has approved the following document: - 'IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN' (draft-ietf-l3vpn-mvpn-infra-addrs-05.txt) as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-infra-addrs/ Technical Summary To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN- specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as four- octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. Working Group Summary This document is a product of L3VPN WG. There were no technical comments on the document during the WG Last Call, which was completed in November 2010. During IESG review some additional comments were raised by a member of the community that required the document to go back through WG Last Call and IETF Last Call where no further comments were made. Document Quality The L3VPN chairs report that they are aware of at least two implementations of this specification. Personnel Ben Niven-Jenkins is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. RFC Editor Note This document updates draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt which is in the same cluster. This document should therefore be assigned a later RFC number than draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt From naikumar@cisco.com Wed Jul 27 11:48:13 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2920211E8123; Wed, 27 Jul 2011 11:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p42-Xruy5Sao; Wed, 27 Jul 2011 11:48:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9A64A21F87C5; Wed, 27 Jul 2011 11:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naikumar@cisco.com; l=4784; q=dns/txt; s=iport; t=1311792490; x=1313002090; h=mime-version:content-transfer-encoding:subject:date: message-id:references:from:to; bh=AiSEQ4T6Nl4CgluuagMMin9SAT+NIpQlPzJiL30NML0=; b=HWpiCK2cCMTVnayD+KGxmNY/DBWFBYtiN5vdX9+8EQ2ki8sXrGLcs/j7 5dmFsNddmtyyyocIahqej3wYEhwcaXzarUsteOjzoJ58imBi2ereomlR8 DIXZG6nA4tusAC4/9yISd39U8dZ3GxNQ8gU4q8oIaAD8Ufjd6Jofzx59d E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAMZcME5Io8US/2dsb2JhbAA1AQEBAQMBAQERARQNBEAXBQIBCREEAQEDAgYGIwECAgIBARIYIw0BBQMCBQELCwwBDA6EL5Msjlhwd4kAoyWNI5FJgSuEBjBfBIdVkDCEXIZ+ X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208";a="45015904" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 27 Jul 2011 18:48:07 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIm7gt023354; Wed, 27 Jul 2011 18:48:07 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 00:18:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt Date: Thu, 28 Jul 2011 00:18:03 +0530 Message-ID: <7582AC0D011A46419BCDDB2B6DE5481903636648@XMB-BGL-41B.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt Thread-Index: AQHMP3ximLR1dj/49kqEhmYfUin9j5UAkQdAgAALWdA= References: <520F3F1A8F14EC4C81AB2F2558D7EB49DC552D@szxeml526-mbx.china.huawei.com> From: "Nagendra Kumar (naikumar)" To: "Zengqing" , , X-OriginalArrivalTime: 27 Jul 2011 18:48:07.0288 (UTC) FILETIME=[B97B7F80:01CC4C8D] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:48:13 -0000 SGksDQoNCkkgd2FzIHJlYWRpbmcgdGhpcyBkcmFmdCBhbmQgY2FuIHlvdSBwbGVhc2UgY2xhcmlm eSB0aGUgYmVsb3csDQoNCjxzbmlwPg0KQS4gSWYgQkdQIHNwZWFrZXIgQSBpcyBvcmlnaW5hdG9y IG9mIHRoZSBsYWJlbGVkIElQdjQgKG9yIElQdjYpDQogICByb3V0ZSwgQSBzZXRzIGl0cyBCR1Ag TFNQIFBhdGggTVRVIHRvIHRoZSBtYXhpbWFsIHZhbHVlLCBhZHZlcnRpc2VzDQogICB0aGUgbGFi ZWxlZCBJUHY0IChvciBJUHY2KSByb3V0ZSB3aXRoIHRoZSBNVFUgRXh0ZW5kZWQgQ29tbXVuaXR5 IHRvDQogICBpdHMgQkdQIFBlZXIgKGl0cyB1cHN0cmVhbSBCR1AgTFNSKS4NCg0KMS4gIEFueSBy ZWFzb24gdG8gc3BlY2lmeSB0aGUgTVRVIHdpdGggbWF4aW1hbCB2YWx1ZSBvbiBlZ3Jlc3Mgc2lk ZT8uIEkgdW5kZXJzdGFuZCBSRkMzOTg4IGhhdmUgdGhlIHNhbWUgYmVoYXZpb3IsIGJ1dCBJIGFt IG5vdCBhd2FyZSBvZiBhbnkgcmVhc29uLiBQZXIgbXkgdW5kZXJzdGFuZGluZywgc2V0dGluZyB0 aGUgTVRVIHZhbHVlIGFzIHRoZSBsaW5rIE1UVSB0byB0aGUgcmVzcGVjdGl2ZSBGRUMgdmFsdWUg d2lsbCBoZWxwIGF2b2lkIElQIGZyYWdtZW50YXRpb24gdXB0byBlZ3Jlc3Mgc2lkZS4gRm9yIGV4 YW1wbGUsIGlmIG9uIGVncmVzcyBQRSwgdGhlIGxpbmsgTVRVIGlzIDE1MDAgd2hpbGUgdGhlIGNh bGN1bGF0ZWQgUGF0aCBNVFUgKGJhc2VkIG9uIHRoaXMgZHJhZnQpIGlzIDkwMDAsIGl0IHN0aWxs IG5lZWRzIElQIGZyYWdtZW50YXRpb24gb24gZWdyZXNzIHNpZGUuDQoNCjIuIEFmdGVyIGFkdmVy dGlzaW5nIHRoZSBVUERBVEUgdG8gbmVpZ2hib3Igd2hhdCB3aWxsIGJlIHRoZSBhY3Rpb24gd2hl biB0aGUgTVRVIGNoYW5nZXM/Lg0KDQozLiBTaW5jZSB3ZSBhbHJlYWR5IGhhdmUgUkZDMzk4OCB0 aGF0IGhlbHBzIGNhbGN1bGF0ZSBNVFUgd2l0aCBMRFAsIEFtIEkgYXNzdW1pbmcgcmlnaHQgdGhh dCB0aGlzIElEIGhlbHBzIGluIEludGVyLUFTIHNjZW5hcmlvcyAoT3B0aW9uIEIpIG9yIHNjZW5h cmlvcyB3aGVyZSBSU1ZQIGlzIHVzZWQgZm9yIExTUCBlc3RhYmxpc2htZW50Py4gU2hvdWxkIHdl IHNwZWNpZnkgdGhhdCBpbiBJRD8uDQoNClRoYW5rcywNCk5hZ2VuZHJhDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2 cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFplbmdxaW5nDQpTZW50OiBNb25kYXks IEp1bHkgMTEsIDIwMTEgOToxMiBBTQ0KVG86IGlkckBpZXRmLm9yZzsgbDN2cG5AaWV0Zi5vcmcN ClN1YmplY3Q6IFtpZHJdIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC16ZW5nLWlkci1iZ3AtbXR1LWV4 dGVuc2lvbi0wMC50eHQNCg0KRllJLiAgDQpBbnkgY29tbWVudHMgd2lsbCBiZSBhcHByZWNpYXRl ZC4NCg0KQmVzdCBSZWdhcmRzISAgIA0KUWluZyAmIEppZQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogaS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmcNCj4gW21h aWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiBTZW50OiBNb25kYXksIEp1bHkgMDQsIDIwMTEgNjo0OCBQ TQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IFN1YmplY3Q6IEktRCBBY3Rpb246IGRy YWZ0LXplbmctaWRyLWJncC1tdHUtZXh0ZW5zaW9uLTAwLnR4dA0KPiANCj4gQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRp cmVjdG9yaWVzLg0KPiANCj4gCVRpdGxlICAgICAgICAgICA6IE1heGltdW0gVHJhbnNtaXNzaW9u IFVuaXQgRXh0ZW5kZWQgQ29tbXVuaXR5DQo+IGZvciBCR1AtNA0KPiAJQXV0aG9yKHMpICAgICAg IDogUWluZyBaZW5nDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSmllIERvbmcNCj4gCUZp bGVuYW1lICAgICAgICA6IGRyYWZ0LXplbmctaWRyLWJncC1tdHUtZXh0ZW5zaW9uLTAwLnR4dA0K PiAJUGFnZXMgICAgICAgICAgIDogNg0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxMS0wNy0wNA0K PiANCj4gICAgUHJvcGVyIGZ1bmN0aW9uaW5nIG9mIFtSRkMxMTkxXSBwYXRoIE1heGltdW0gVHJh bnNtaXNzaW9uIFVuaXQgKE1UVSkNCj4gICAgZGlzY292ZXJ5IHJlcXVpcmVzIHRoYXQgSVAgcm91 dGVycyBoYXZlIGtub3dsZWRnZSBvZiB0aGUgTVRVIGZvciBlYWNoDQo+ICAgIGxpbmsgdG8gd2hp Y2ggdGhleSBhcmUgY29ubmVjdGVkLiAgQXMgTVBMUyBwcm9ncmVzc2VzLCBbUkZDMzk4OF0NCj4g ICAgc3BlY2lmaWVzIHNvbWUgZXh0ZW5zaW9ucyB0byBMRFAgaW4gc3VwcG9ydCBvZiBMRFAgTFNQ IE1UVSBkaXNjb3ZlcnkuDQo+ICAgIEZvciB0aGUgTFNQIGNyZWF0ZWQgdXNpbmcgQm9yZGVyIEdh dGV3YXkgUHJvdG9jb2wgKEJHUCkgW1JGQzMxMDddLCBpdA0KPiAgICBkb2VzIG5vdCBoYXZlIHRo ZSBhYmlsaXR5IHRvIHNpZ25hbCB0aGUgcGF0aCBNVFUgdG8gdGhlIGluZ3Jlc3MgTGFiZWwNCj4g ICAgU3dpdGNoaW5nIFJvdXRlciAoTFNSKS4gIEluIHRoZSBhYnNlbmNlIG9mIHRoaXMgZnVuY3Rp b25hbGl0eSwgdGhlDQo+ICAgIE1UVSBmb3IgdGhlIEJHUCBMU1AgbXVzdCBiZSBzdGF0aWNhbGx5 IGNvbmZpZ3VyZWQgYnkgbmV0d29yaw0KPiAgICBvcGVyYXRvcnMgb3IgYnkgZXF1aXZhbGVudCBv ZmYtbGluZSBtZWNoYW5pc21zLg0KPiANCj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBN VFUgRXh0ZW5kZWQgQ29tbXVuaXR5IGZvciBCR1AgaW4gc3VwcG9ydA0KPiAgICBvZiBCR1AgTFNQ IE1UVSBkaXNjb3ZlcnkuDQo+IA0KPiANCj4gDQo+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURy YWZ0IGlzOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16ZW5n LWlkci1iZ3AtbXR1LWV4dGVuc2lvbi0wMC50eHQNCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IFRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJp ZXZlZCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16ZW5n LWlkci1iZ3AtbXR1LWV4dGVuc2lvbi0wMC50eHQNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiBJ LUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNo YWRvdy1zaXRlcy50eHQNCg== From jie.dong@huawei.com Wed Jul 27 13:04:16 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8362911E809C; Wed, 27 Jul 2011 13:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdlRkq1OHi4B; Wed, 27 Jul 2011 13:04:15 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCA711E8082; Wed, 27 Jul 2011 13:04:15 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP0002LMD32E2@szxga05-in.huawei.com>; Thu, 28 Jul 2011 04:04:14 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP000901D31IA@szxga05-in.huawei.com>; Thu, 28 Jul 2011 04:04:14 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACQ54400; Thu, 28 Jul 2011 04:04:13 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Jul 2011 04:04:07 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.156]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Thu, 28 Jul 2011 04:04:09 +0800 Date: Wed, 27 Jul 2011 20:04:08 +0000 From: Jie Dong Subject: RE: [Idr] [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt In-reply-to: <7582AC0D011A46419BCDDB2B6DE5481903636648@XMB-BGL-41B.cisco.com> X-Originating-IP: [172.24.2.40] To: "Nagendra Kumar (naikumar)" , Zengqing , "idr@ietf.org" , "l3vpn@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C9270B7676C8@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt Thread-index: AQHMTI3M2Sk2gU/1lE62no9k0Ewlu5UAhGKz X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <520F3F1A8F14EC4C81AB2F2558D7EB49DC552D@szxeml526-mbx.china.huawei.com> <7582AC0D011A46419BCDDB2B6DE5481903636648@XMB-BGL-41B.cisco.com> X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:04:16 -0000 Hi Nagendra, Thanks a lot for your comments, and please see replies with [Jie] A. If BGP speaker A is originator of the labeled IPv4 (or IPv6) route, A sets its BGP LSP Path MTU to the maximal value, advertises the labeled IPv4 (or IPv6) route with the MTU Extended Community to its BGP Peer (its upstream BGP LSR). 1. Any reason to specify the MTU with maximal value on egress side?. I understand RFC3988 have the same behavior, but I am not aware of any reason. Per my understanding, setting the MTU value as the link MTU to the respective FEC value will help avoid IP fragmentation upto egress side. For example, if on egress PE, the link MTU is 1500 while the calculated Path MTU (based on this draft) is 9000, it still needs IP fragmentation on egress side. [Jie] Actually this specification is for scenarios where the prefix advertised with label belongs to the egress node. When it's not the case, the MTU would be set to the link MTU to the prefix. I guess you are talking about advertising VPN routes, right? Yes in this case the Path MTU should be to a specific VPN prefix. This specification would be modified in next revision. 2. After advertising the UPDATE to neighbor what will be the action when the MTU changes?. [Jie] when the MTU changes, similar to other path attribute changes, update would be sent the the peer. In order to avoid unnecessary route flapping, we would define rules like this: If the MTU decreases, the update SHOULD be sent to peer immediately to avoid possible packet discard. If the MTU increases, the update SHOULD be hold down for a while, probably be sent when there is also change of other attributes. 3. Since we already have RFC3988 that helps calculate MTU with LDP, Am I assuming right that this ID helps in Inter-AS scenarios (Option B) or scenarios where RSVP is used for LSP establishment?. Should we specify that in ID?. [Jie] As I know, RSVP also defines its mechanism of MTU discovery. Thus this draft helps in scenarios where end-to-end LSP is established with labeled BGP. The typical use cases include inter-AS VPN Option C, Seamless MPLS and Carrier's Carrier. And Option B may also be a use case. Next revision will describe the scenarios. Discussion about other possible use cases would be appreciated. Many thanks, Jie -----Original Message----- From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Zengqing Sent: Monday, July 11, 2011 9:12 AM To: idr@ietf.org; l3vpn@ietf.org Subject: [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt FYI. Any comments will be appreciated. Best Regards! Qing & Jie > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, July 04, 2011 6:48 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Maximum Transmission Unit Extended Community > for BGP-4 > Author(s) : Qing Zeng > Jie Dong > Filename : draft-zeng-idr-bgp-mtu-extension-00.txt > Pages : 6 > Date : 2011-07-04 > > Proper functioning of [RFC1191] path Maximum Transmission Unit (MTU) > discovery requires that IP routers have knowledge of the MTU for each > link to which they are connected. As MPLS progresses, [RFC3988] > specifies some extensions to LDP in support of LDP LSP MTU discovery. > For the LSP created using Border Gateway Protocol (BGP) [RFC3107], it > does not have the ability to signal the path MTU to the ingress Label > Switching Router (LSR). In the absence of this functionality, the > MTU for the BGP LSP must be statically configured by network > operators or by equivalent off-line mechanisms. > > This document defines the MTU Extended Community for BGP in support > of BGP LSP MTU discovery. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zeng-idr-bgp-mtu-extension-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-zeng-idr-bgp-mtu-extension-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From naikumar@cisco.com Sat Jul 30 05:02:16 2011 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335A021F881C for ; Sat, 30 Jul 2011 05:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.246 X-Spam-Level: X-Spam-Status: No, score=-10.246 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUUbshr9emec for ; Sat, 30 Jul 2011 05:02:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 787CE21F880C for ; Sat, 30 Jul 2011 05:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naikumar@cisco.com; l=6065; q=dns/txt; s=iport; t=1312027335; x=1313236935; h=mime-version:subject:date:message-id:from:to:cc; bh=uDhl//B0YULB4tQ9I0jpkirZFwW9VVsGlpr4T3k/rXA=; b=myEjTYcQAUMbqZMNIl8RRVT0IPQTOm0cTPC//J2CZ2TM565PgR4yazus iC1jnwZ97SNLtg8FJiTDtzyBAKAtx/c3oDfMYzkwelTXKk2B2OHvQa/vx SWHQfdHwSvFGDAEENvOZea/S4VLpfDKv0ZqNPj86WcxojpuIFYSc/piZW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwGAETyM05Io8UT/2dsb2JhbABBgk2WBo8Pd4FCAQEDEgEJEQNJEgEqBhgHVwEECxAaqV0BnheFY18Eh1iQM4tc X-IronPort-AV: E=Sophos;i="4.67,291,1309737600"; d="scan'208,217";a="105786742" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2011 12:02:12 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6UC2BTo015074; Sat, 30 Jul 2011 12:02:11 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 30 Jul 2011 17:32:11 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4EB0.837EA223" Subject: Mail regarding draft-rekhter-l3vpn-virtual-hub Date: Sat, 30 Jul 2011 17:32:03 +0530 Message-ID: <7582AC0D011A46419BCDDB2B6DE548190370A282@XMB-BGL-41B.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mail regarding draft-rekhter-l3vpn-virtual-hub Thread-Index: AcxOsH54I9fegROKSFS0H02eLLFrCA== From: "Nagendra Kumar (naikumar)" To: X-OriginalArrivalTime: 30 Jul 2011 12:02:11.0768 (UTC) FILETIME=[83B35380:01CC4EB0] Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 12:02:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4EB0.837EA223 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I was reading this draft and can you please let me know the below, =20 1. From ID, I understood that V-spoke PE will be advertising a default route to CE site. Am I missing any statement about what will be advertised to CE sites which are connected to V-Hub PE?. Will it advertise all prefixes from other hub and spoke PEs or just default route?. 2. Since V-spoke will be advertising default route to its connected CE site, Wont it result in undesired traffic from CE site traversing over SP cloud and get dropped at Hub PE device?. Do you have any recommendation/way to avoid it?. 3. I understood that any V-spoke PE can advertise all prefixes to CE site instead of default route on a need basis (From Section 8 "Further refinements") . I believe it should be made mandatory for CE which has internet gateway connected. So the deployment I believe should be that any PE (V-hub or V-spoke) to which Internet GW site is connected SHOULD use methodology specified in Section 8. In other words, PE if receives default route from a CE site, should advertise all prefixes from other site to that CE and NOT the VPN-IP default route. =20 Regards, Nagendra ------_=_NextPart_001_01CC4EB0.837EA223 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I was reading this draft and can you please let me = know the below,

 

1.       From ID, I understood that V-spoke PE will be advertising a default route to CE site. Am I missing any statement about = what will be advertised to CE sites which are connected to V-Hub PE?. Will it advertise all prefixes from other hub and spoke PEs or just default = route?.

2.       Since V-spoke will be advertising default route = to its connected CE site, Wont it result in undesired traffic from CE site traversing = over SP cloud and get dropped at Hub PE device?. Do you have any recommendation/way to = avoid it?.

3.       I understood that any V-spoke PE can advertise = all prefixes to CE site instead of default route on a need basis (From = Section 8 “Further refinements”) . I believe it should be made mandatory for CE which = has internet gateway connected. So the deployment I believe should be that = any PE (V-hub or V-spoke) to which Internet GW site is connected SHOULD use methodology specified in Section 8. In other words, PE if receives = default route from a CE site, should advertise all prefixes from other site to = that CE and NOT the VPN-IP default route.

 

Regards,

Nagendra

------_=_NextPart_001_01CC4EB0.837EA223--