From jgs@juniper.net Tue Nov 3 08:58:56 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096CB3A6A31 for ; Tue, 3 Nov 2009 08:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYKuo4CA853D for ; Tue, 3 Nov 2009 08:58:55 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id DEB713A67E5 for ; Tue, 3 Nov 2009 08:58:54 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSvBhY3nPR6Cb7kwhLO8Y6M5VbPTYGoGI@postini.com; Tue, 03 Nov 2009 08:59:16 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 3 Nov 2009 08:53:23 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 08:53:23 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 08:53:22 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 08:53:21 -0800 Received: from [172.16.13.206] ([172.16.13.206]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA3GrLj62696 for ; Tue, 3 Nov 2009 08:53:21 -0800 (PST) (envelope-from jgs@juniper.net) From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Tue, 3 Nov 2009 11:53:20 -0500 Message-ID: <1D6475D7-9656-478D-903C-3E5A109DF31F@juniper.net> To: idr List MIME-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 03 Nov 2009 16:53:21.0618 (UTC) FILETIME=[26A56320:01CA5CA6] Subject: [Idr] Minute taker for upcoming meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:58:56 -0000 Folks, We have a full agenda for next week (see http://www.ietf.org/proceedings/09nov/agenda/idr.txt ) and so it would be even more helpful than usual for someone to volunteer ahead of time to take minutes. We can't start the meeting without at least one note taker, and if we have any extra time I'd rather use it for discussing drafts than badgering the group for volunteers. Let's not always see the same hands, now. Thanks in advance, --John From jgs@juniper.net Sat Nov 7 22:35:34 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D95F3A6837 for ; Sat, 7 Nov 2009 22:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NrR0t5v--j7 for ; Sat, 7 Nov 2009 22:35:33 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 5F1EF3A69ED for ; Sat, 7 Nov 2009 22:35:33 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSvZmzSfgtj7hJMPQiKAkWOmDMhh+DJhI@postini.com; Sat, 07 Nov 2009 22:35:58 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 7 Nov 2009 22:32:39 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Nov 2009 22:32:39 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Nov 2009 22:32:38 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Nov 2009 22:32:38 -0800 Received: from jgs-sslvpn-nc.jnpr.net (jgs-sslvpn-nc.jnpr.net [172.23.8.196]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA86Wbj62712; Sat, 7 Nov 2009 22:32:37 -0800 (PST) (envelope-from jgs@juniper.net) From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Sun, 8 Nov 2009 10:05:45 +0900 Message-ID: To: idr List MIME-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 08 Nov 2009 06:32:38.0326 (UTC) FILETIME=[43FAC560:01CA603D] Subject: [Idr] IDR charter update X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 06:35:34 -0000 Folks, The IDR charter is overdue for an update. Here is our proposal, we've tried to keep it short and sweet: The Inter-Domain Routing Working Group is chartered to standardize and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC 4271] capable of supporting policy based routing for TCP/IP internets. The objective is to promote the use of BGP-4 to support IP version 4 and IP version 6. The working group will continue to work on improving the robustness and scalability of BGP, and extending the protocol as otherwise needed to support the growth and success of the Internet. We'll discuss this at Tuesday's meeting. Comments on the mailing list are also welcome of course. I'm hoping to send this to the IESG for approval ASAP. Milestones and so on will also be updated, but the process for doing that is lightweight. --John & Sue From jgs@juniper.net Sun Nov 8 16:10:22 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462303A6839 for ; Sun, 8 Nov 2009 16:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C+fwK2+u7JH for ; Sun, 8 Nov 2009 16:10:20 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 847043A635F for ; Sun, 8 Nov 2009 16:10:20 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSvdeBVNNB89JKD2vtN7lH+gSejTb2j3+@postini.com; Sun, 08 Nov 2009 16:10:46 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sun, 8 Nov 2009 16:07:44 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 16:07:43 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 16:07:43 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 16:07:43 -0800 Received: from sa-nc-common-196.static.jnpr.net (sa-nc-common-196.static.jnpr.net [172.23.8.196]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nA907hj01165 for ; Sun, 8 Nov 2009 16:07:43 -0800 (PST) (envelope-from jgs@juniper.net) From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 9 Nov 2009 09:07:41 +0900 References: <1D6475D7-9656-478D-903C-3E5A109DF31F@juniper.net> To: idr List Message-ID: <97DF8116-6876-44A3-BE62-72BD1E0F3F26@juniper.net> MIME-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 09 Nov 2009 00:07:43.0267 (UTC) FILETIME=[A8AA2F30:01CA60D0] Subject: [Idr] Fwd: Minute taker for upcoming meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 00:10:22 -0000 Nobody has stepped forward to volunteer yet. Anyone, anyone? --John Begin forwarded message: > From: John Scudder > Date: November 4, 2009 1:53:20 AM GMT+09:00 > To: idr List > Subject: [Idr] Minute taker for upcoming meeting > > Folks, > > We have a full agenda for next week (see http://www.ietf.org/proceedings/09nov/agenda/idr.txt > ) and so it would be even more helpful than usual for someone to > volunteer ahead of time to take minutes. We can't start the meeting > without at least one note taker, and if we have any extra time I'd > rather use it for discussing drafts than badgering the group for > volunteers. > > Let's not always see the same hands, now. > > Thanks in advance, > > --John From dongjie_dj@huawei.com Mon Nov 9 21:30:52 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631343A69CB for ; Mon, 9 Nov 2009 21:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4WlASE3KHkL for ; Mon, 9 Nov 2009 21:30:50 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id C5E143A6905 for ; Mon, 9 Nov 2009 21:30:50 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSV00IATOO5UP@usaga03-in.huawei.com> for idr@ietf.org; Mon, 09 Nov 2009 23:31:17 -0600 (CST) Received: from JYS8110164H (host-18-190.meeting.ietf.org [133.93.18.190]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSV00LQIOO2Q3@usaga03-in.huawei.com> for idr@ietf.org; Mon, 09 Nov 2009 23:31:17 -0600 (CST) Date: Tue, 10 Nov 2009 14:31:03 +0900 From: Jie Dong To: raszuk@cisco.com Message-id: <06c501ca61c7$0d8c86e0$1200a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_GxzCy9GTjvWVYItSqGAxfw)" Thread-index: Acphxv608CV5bAAGQgyAXkoaNTiFtA== Cc: idr@ietf.org Subject: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:30:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_GxzCy9GTjvWVYItSqGAxfw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Robert, Thanks for your comments. My three points here: 1. By carefully configuring the RTs may resolve the issues raised in our draft (e.g., in small/simple networks, there are not so much VPNs deployed in the network). But with the increment of the size/VPNs of the network, it requires that the operators have to assign RTs very carefully to make sure there is no overlapping between RT spaces of different kind of VPNs, this sometime may be a big burden for SPs. And this might be easy for networks which is operated by only one operator, but is quite difficult for networks operated by many ISPs. 2. With the current mechanisms, there is possibility that the deployment of a new VPN affects the existing network, and sometimes it may lead to unexpected situations. IMO this is the worst thing that operators do not want to see. 3. BTW, there is another issue regarding to the length of the RT filed, the IPv6 address specified RT is covered in rfc4684. Regards Jie --Boundary_(ID_GxzCy9GTjvWVYItSqGAxfw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Robert,

 

Thanks for your comments. =

 

My three points = here:

1. By carefully configuring the RTs may resolve = the issues raised in our draft (e.g., in small/simple networks, there are = not so much VPNs deployed in the network).  But with the increment of the = size/VPNs of the network, it requires that the operators have to assign RTs very = carefully to make sure there is no overlapping between RT spaces of different kind = of VPNs, this sometime may be a big burden for SPs. And this might be easy = for networks which is operated by only one operator, but is quite difficult = for networks operated by many ISPs.

 

2. With the current mechanisms, there is = possibility that the deployment of a new VPN affects the existing network, and sometimes = it may lead to unexpected situations. IMO this is the worst thing that = operators do not want to see.

        =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;         =

3. BTW, there is another issue regarding to the = length of the RT filed, the IPv6 address specified RT is covered in = rfc4684.

 

Regards

Jie

--Boundary_(ID_GxzCy9GTjvWVYItSqGAxfw)-- From raszuk@cisco.com Mon Nov 9 22:47:44 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87DD3A6920 for ; Mon, 9 Nov 2009 22:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX9RDJeU91rS for ; Mon, 9 Nov 2009 22:47:44 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id F389D3A68C4 for ; Mon, 9 Nov 2009 22:47:43 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG+b+EpAaHte/2dsb2JhbADEO4EcCAGWU4Q+BIFoeA X-IronPort-AV: E=Sophos;i="4.44,714,1249257600"; d="scan'208";a="48730179" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2009 06:48:10 +0000 Received: from [10.70.231.225] (tky-vpn-client-231-225.cisco.com [10.70.231.225]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAA6m8JE029930; Tue, 10 Nov 2009 06:48:09 GMT Message-ID: <4AF90CAA.3030700@cisco.com> Date: Tue, 10 Nov 2009 15:48:10 +0900 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jie Dong References: <06c501ca61c7$0d8c86e0$1200a8c0@china.huawei.com> In-Reply-To: <06c501ca61c7$0d8c86e0$1200a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 06:47:44 -0000 Hi Jie, > 1. By carefully configuring the RTs may resolve the issues raised in our > draft (e.g., in small/simple networks, there are not so much VPNs > deployed in the network). But with the increment of the size/VPNs of > the network, it requires that the operators have to assign RTs very > carefully to make sure there is no overlapping between RT spaces of > different kind of VPNs, I don't think this is of any mandatory requirement to make sure that RTs are specified unique between different kinds of VPNs of a given customer. In particular if you have customer interested in using IPv4 and IPv6 addressing I would in fact very much suggest to set the RTs to be a descriptive reflection of such customer sites and be of the same value. For customers using l2VPN and L3VPNs or MVPNs those also will be congruent with a given customer sites. In fact it would be a mistake to specify different RTs for IP unicast and for MVPN in most cases. Of course between different customer's VPNs you need different RT values but this is basic provisioning requirement for BGP VPNs application. > this sometime may be a big burden for SPs. And > this might be easy for networks which is operated by only one > operator, but is quite difficult for networks operated by many ISPs. There is already very well defined set of procedures to provide inter-as VPNs for any type of VPN. I am not sure if your draft would make it any easier to send RTs separately for different SAFIs. In worst case the consequence of splitting RT space may result in duplicating identical RT information to be distributed many times. > 2. With the current mechanisms, there is possibility that the > deployment of a new VPN affects the existing network, and sometimes it > may lead to unexpected situations. IMO this is the worst thing that > operators do not want to see. I don't see what unexpected situations may arise. Can you provide some examples here ? > 3. BTW, there is another issue regarding to the length of the RT > filed, the IPv6 address specified RT is covered in rfc4684. Can you clarify what is the issue ? Many thx, R. > My three points here: > > 1. By carefully configuring the RTs may resolve the issues raised in our > draft (e.g., in small/simple networks, there are not so much VPNs > deployed in the network). But with the increment of the size/VPNs of > the network, it requires that the operators have to assign RTs very > carefully to make sure there is no overlapping between RT spaces of > different kind of VPNs, this sometime may be a big burden for SPs. And > this might be easy for networks which is operated by only one operator, > but is quite difficult for networks operated by many ISPs. > > > > 2. With the current mechanisms, there is possibility that the deployment > of a new VPN affects the existing network, and sometimes it may lead to > unexpected situations. IMO this is the worst thing that operators do not > want to see. > > > > > 3. BTW, there is another issue regarding to the length of the RT filed, > the IPv6 address specified RT is covered in rfc4684. > > > > Regards > > Jie > From mach@huawei.com Tue Nov 10 08:09:48 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AFA93A6AD8 for ; Tue, 10 Nov 2009 08:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuMFi1ZkEfkw for ; Tue, 10 Nov 2009 08:09:47 -0800 (PST) Received: from lhrga03-in.huawei.com (lhrga03-in.huawei.com [195.33.106.148]) by core3.amsl.com (Postfix) with ESMTP id E3DFC3A6A05 for ; Tue, 10 Nov 2009 08:09:32 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSW00EA5I8LU1@lhrga03-in.huawei.com> for idr@ietf.org; Tue, 10 Nov 2009 16:09:58 +0000 (GMT) Received: from LENOVOmach (host-113-133.meeting.ietf.org [133.93.113.133]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSW006AYI8I3Z@lhrga03-in.huawei.com> for idr@ietf.org; Tue, 10 Nov 2009 16:09:57 +0000 (GMT) Date: Wed, 11 Nov 2009 00:10:00 +0800 From: Mach Chen In-reply-to: <4AF90CAA.3030700@cisco.com> To: raszuk@cisco.com Message-id: Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <06c501ca61c7$0d8c86e0$1200a8c0@china.huawei.com> <4AF90CAA.3030700@cisco.com> Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Mach Chen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 16:09:48 -0000 Hi Robert, Fogive me to chime in. Please see inline... > Hi Jie, > > > 1. By carefully configuring the RTs may resolve the issues raised in our > > draft (e.g., in small/simple networks, there are not so much VPNs > > deployed in the network). But with the increment of the size/VPNs of > > the network, it requires that the operators have to assign RTs very > > carefully to make sure there is no overlapping between RT spaces of > > different kind of VPNs, > > I don't think this is of any mandatory requirement to make sure that RTs > are specified unique between different kinds of VPNs of a given customer. The issue we really concern is that the RTs overlap among different customers. Different VPNs for different customers may be configiured to used same RT, that means the RT of one type of VPN may attracted unwanted routes belong to other types of VPNS, and that the RT configuration/modification of one type VPN may affect the other VPNs that are totally not relevant to that VPN. > > In particular if you have customer interested in using IPv4 and IPv6 > addressing I would in fact very much suggest to set the RTs to be a > descriptive reflection of such customer sites and be of the same value. A fine decription of a specific RT may help the opertor to admin their VPNs deloyment, but it could not change the essence of the existing RT-constrian that it may lead to RTs overlap or conflicts among dififferent VPNs. > > For customers using l2VPN and L3VPNs or MVPNs those also will be congruent > with a given customer sites. In fact it would be a mistake to specify > different RTs for IP unicast and for MVPN in most cases. > > Of course between different customer's VPNs you need different RT values > but this is basic provisioning requirement for BGP VPNs application. Different customers serviced with the same kinds of VPN, of cause, RT should be set to different values. As I said above, different customers serviced with different kinds of VPNs, it SHOULD not be required to use different values anymore. > > > this sometime may be a big burden for SPs. And > > this might be easy for networks which is operated by only one > > operator, but is quite difficult for networks operated by many ISPs. > > There is already very well defined set of procedures to provide inter-as > VPNs for any type of VPN. I am not sure if your draft would make it any > easier to send RTs separately for different SAFIs. In our draft, we firstly propose to send RTs separately for different AFIs, and of cause, if we could differentiate different SAFIs(it is also proposed in the draft), that will be better. With these extensions, there will (and SHOULD) be no affection/relationship among different kinds of VPNs anymore. > > In worst case the consequence of splitting RT space may result in > duplicating identical RT information to be distributed many times. IMO, compare to the unwanted routes sending/processing and the underlying affection among VPNs, it could be ignored. > > > 2. With the current mechanisms, there is possibility that the > > deployment of a new VPN affects the existing network, and sometimes it > > may lead to unexpected situations. IMO this is the worst thing that > > operators do not want to see. > > I don't see what unexpected situations may arise. Can you provide some > examples here ? For a BGP router, with the current BT-constrian mechansims, it's possilbe that it may received some out-of-expectation routes, and these routes may make the number of the routes of that router reaching to a threshold that may triger the router to disconnect BGP sessions. > > > 3. BTW, there is another issue regarding to the length of the RT > > filed, the IPv6 address specified RT is covered in rfc4684. > > Can you clarify what is the issue ? Here is the RT difinition in RFC4684: +-------------------------------+ | origin as (4 octets) | +-------------------------------+ | route target (8 octets) | + + | | +-------------------------------+ There is only 8 octets left for route target. Best regards, Mach > > Many thx, > R. > > >> My three points here: >> >> 1. By carefully configuring the RTs may resolve the issues raised in our >> draft (e.g., in small/simple networks, there are not so much VPNs >> deployed in the network). But with the increment of the size/VPNs of the >> network, it requires that the operators have to assign RTs very carefully >> to make sure there is no overlapping between RT spaces of different kind >> of VPNs, this sometime may be a big burden for SPs. And this might be >> easy for networks which is operated by only one operator, but is quite >> difficult for networks operated by many ISPs. >> >> 2. With the current mechanisms, there is possibility that the deployment >> of a new VPN affects the existing network, and sometimes it may lead to >> unexpected situations. IMO this is the worst thing that operators do not >> want to see. >> >> >> 3. BTW, there is another issue regarding to the length of the RT filed, >> the IPv6 address specified RT is covered in rfc4684. >> >> Regards >> >> Jie >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From roque@cisco.com Tue Nov 10 08:31:18 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11CD3A6B38 for ; Tue, 10 Nov 2009 08:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX8sQUx8k9D0 for ; Tue, 10 Nov 2009 08:31:17 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E30953A68FE for ; Tue, 10 Nov 2009 08:31:17 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJsj+UqrR7Hu/2dsb2JhbADGXpgjgj+BfwQ X-IronPort-AV: E=Sophos;i="4.44,717,1249257600"; d="scan'208";a="429196444" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 10 Nov 2009 16:31:45 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nAAGVjiJ002249; Tue, 10 Nov 2009 16:31:45 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 08:31:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 08:31:43 -0800 Message-ID: <7C53A945334A5E4B87A5B5002F0EB35508BD29AA@xmb-sjc-233.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Response to comments on generalized RT constrain solution Thread-Index: AcpiIFNJj4BOY7f2TZuOzz4zx3avsQAABUog References: <06c501ca61c7$0d8c86e0$1200a8c0@china.huawei.com><4AF90CAA.3030700@cisco.com> From: "Pedro Marques (roque)" To: "Mach Chen" , "Robert Raszuk (raszuk)" X-OriginalArrivalTime: 10 Nov 2009 16:31:45.0301 (UTC) FILETIME=[4ADF5C50:01CA6223] Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 16:31:18 -0000 > The issue we really concern is that the RTs overlap among different > customers. Different VPNs for different customers may be configiured to > used > same RT, that means the RT of one type of VPN may attracted unwanted > routes > belong to other types of VPNS, and that the RT > configuration/modification of > one type VPN may affect the other VPNs that are totally not relevant to > that > VPN. I'm not sure I follow your argument. Clearly if we are talking about VPNs with the same address family you can't use the same RT for different VPNs. For a VPN service to operate correctly the provisioning mechanism should be able to assign an unique RT per VPN. Now, even if you had the ability to use the same RT value across different address families you most likely wouldn't want to use it. For example, if customer A has a VPN with v4 service and customer B has a VPN with v6 service it would be a *really bad idea* to assign the same value to both because A may want to have v6 service in the future or vice-versa. The main point here is that in practice RT assignment is not per AF but per VPN. That is the reason the rt constraint draft handles the RT independently of the AF. It seems to me that attempts to have RT constraint have per AF semantics are misguided in the least. A VPN will very likely have multiple services that use different BGP AFI,SAFIs and while in theory they could use multiple RTs there is no practical value in doing so. That would result in having to advertise multiple times the same information when using rt-constraint. In my mind, the question we should ask is: would a service provider use the same customer id for 2 different customers (even if they have different services ?). The answer is no. The same way the SP provisioning system should be able to assign unique RTs per customer so that ops can retrieve the customer-id from the RT. Pedro. From dongjie_dj@huawei.com Tue Nov 10 17:59:47 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C5E3A6925 for ; Tue, 10 Nov 2009 17:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t42GGwppphJ0 for ; Tue, 10 Nov 2009 17:59:46 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id DF6803A6A37 for ; Tue, 10 Nov 2009 17:59:33 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSX00IB99K0QN@usaga03-in.huawei.com> for idr@ietf.org; Tue, 10 Nov 2009 20:00:01 -0600 (CST) Received: from JYS8110164H (host-18-190.meeting.ietf.org [133.93.18.190]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSX00GSB9JT0Z@usaga03-in.huawei.com> for idr@ietf.org; Tue, 10 Nov 2009 20:00:00 -0600 (CST) Date: Wed, 11 Nov 2009 10:59:39 +0900 From: Jie Dong In-reply-to: <7C53A945334A5E4B87A5B5002F0EB35508BD29AA@xmb-sjc-233.amer.cisco.com> To: "'Pedro Marques (roque)'" , 'Mach Chen' , "'Robert Raszuk (raszuk)'" Message-id: <002b01ca6272$b4a77e70$be125d85@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpiIFNJj4BOY7f2TZuOzz4zx3avsQAABUogABHmqwA= Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:59:47 -0000 Hi, Thanks for your comments. Please see inline... > > The issue we really concern is that the RTs overlap among different > > customers. Different VPNs for different customers may be configiured > to > > used > > same RT, that means the RT of one type of VPN may attracted unwanted > > routes > > belong to other types of VPNS, and that the RT > > configuration/modification of > > one type VPN may affect the other VPNs that are totally not relevant > to > > that > > VPN. > > I'm not sure I follow your argument. Clearly if we are talking about > VPNs with the same address family you can't use the same RT for > different VPNs. For a VPN service to operate correctly the provisioning > mechanism should be able to assign an unique RT per VPN. > Yes, for VPNs with the same AFI/SAFI, different RT should be assigned for different customers. > Now, even if you had the ability to use the same RT value across > different address families you most likely wouldn't want to use it. For > example, if customer A has a VPN with v4 service and customer B has a > VPN with v6 service it would be a *really bad idea* to assign the same > value to both because A may want to have v6 service in the future or > vice-versa. What we mean here is for different AFI/SAFIs the allocation of RT should be able to operate independently. Operators can choose to use same or different RT for different kinds of VPNs, either for same customer or different customers. The assignment of RT can be quite flexible. Especially in mutli-ISP scenarios, different ISP may use the same RT for different kind of VPNs. > The main point here is that in practice RT assignment is not per AF but > per VPN. That is the reason the rt constraint draft handles the RT > independently of the AF. If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for these two VPNs are independent, they could use either different RT or same RT based on the policy of the operator. > It seems to me that attempts to have RT constraint have per AF semantics > are misguided in the least. A VPN will very likely have multiple > services that use different BGP AFI,SAFIs and while in theory they could > use multiple RTs there is no practical value in doing so. That would > result in having to advertise multiple times the same information when > using rt-constraint Using same RT for multiple services is reasonable, however the sites may not be identical for all these services. Some sites may only be interested in some of these services, and more unneeded routes may get their PEs into trouble. But with normal rt-constrain PEs of these sites will receive VPN routes of all these services, including the unwanted ones. This can happen especially during network migration and deployment of new services. As you said, using different RT is not recommended, and using same RT some PEs need the ability to notify others only some kind of routes are needed. And as Mach has said before, compared with the quantity of unwanted routes being advertised, the amount of RT-constrain information can be ignored. > > In my mind, the question we should ask is: would a service provider use > the same customer id for 2 different customers (even if they have > different services ?). The answer is no. The same way the SP > provisioning system should be able to assign unique RTs per customer so > that ops can retrieve the customer-id from the RT. Operators can choose how to manage their networks, and also different operators can choose different ways. IMO we should provide methods to lighten operators' burden on VPN service provisioning and assure that different services will not affect each other. Regards Jie From raszuk@cisco.com Tue Nov 10 18:16:58 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE14728C269 for ; Tue, 10 Nov 2009 18:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPpAUkds2iWX for ; Tue, 10 Nov 2009 18:16:57 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A06CC3A67D3 for ; Tue, 10 Nov 2009 18:16:57 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,719,1249257600"; d="scan'208";a="103453827" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2009 02:17:24 +0000 Received: from [10.70.230.207] (tky-vpn-client-230-207.cisco.com [10.70.230.207]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAB2HMek007501; Wed, 11 Nov 2009 02:17:23 GMT Message-ID: <4AFA1EB5.8070105@cisco.com> Date: Wed, 11 Nov 2009 11:17:25 +0900 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jie Dong References: <002b01ca6272$b4a77e70$be125d85@china.huawei.com> In-Reply-To: <002b01ca6272$b4a77e70$be125d85@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 02:16:58 -0000 Jie, > But with normal rt-constrain PEs of these sites will receive VPN > routes of all these services, including the unwanted ones. I don't understand the definition of "unwanted routes" in the draft and in your email description. If RT is assigned that matches the routes they are received and accepted. If RT attached to the route is not part of import of any VRF of the PE they are dropped today and with rt-constrain will not be sent. I really don't see how this is related to SAFIs/services provided. In fact if you don't have service ABC configured on such PE in question it will not receive any routes either today or with rt-constrain. Please observe that rt-constrain is just a filter not the request for routes. I think what you are trying to express is to assing on one PE 100:1 for L3VPNs for customer X and on the other PE 100:1 for L2VPNs for customer Y. That would be IMHO a misconfiguration. Cheers, R. > Hi, > > Thanks for your comments. Please see inline... > >>> The issue we really concern is that the RTs overlap among different >>> customers. Different VPNs for different customers may be configiured >> to >>> used >>> same RT, that means the RT of one type of VPN may attracted unwanted >>> routes >>> belong to other types of VPNS, and that the RT >>> configuration/modification of >>> one type VPN may affect the other VPNs that are totally not relevant >> to >>> that >>> VPN. >> I'm not sure I follow your argument. Clearly if we are talking about >> VPNs with the same address family you can't use the same RT for >> different VPNs. For a VPN service to operate correctly the provisioning >> mechanism should be able to assign an unique RT per VPN. >> > Yes, for VPNs with the same AFI/SAFI, different RT should be assigned for > different customers. > >> Now, even if you had the ability to use the same RT value across >> different address families you most likely wouldn't want to use it. For >> example, if customer A has a VPN with v4 service and customer B has a >> VPN with v6 service it would be a *really bad idea* to assign the same >> value to both because A may want to have v6 service in the future or >> vice-versa. > What we mean here is for different AFI/SAFIs the allocation of RT should be > able to operate independently. Operators can choose to use same or different > RT for different kinds of VPNs, either for same customer or different > customers. The assignment of RT can be quite flexible. Especially in > mutli-ISP scenarios, different ISP may use the same RT for different kind of > VPNs. > >> The main point here is that in practice RT assignment is not per AF but >> per VPN. That is the reason the rt constraint draft handles the RT >> independently of the AF. > If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for these two > VPNs are independent, they could use either different RT or same RT based on > the policy of the operator. > >> It seems to me that attempts to have RT constraint have per AF semantics >> are misguided in the least. A VPN will very likely have multiple >> services that use different BGP AFI,SAFIs and while in theory they could >> use multiple RTs there is no practical value in doing so. That would >> result in having to advertise multiple times the same information when >> using rt-constraint > Using same RT for multiple services is reasonable, however the sites may not > be identical for all these services. Some sites may only be interested in > some of these services, and more unneeded routes may get their PEs into > trouble. But with normal rt-constrain PEs of these sites will receive VPN > routes of all these services, including the unwanted ones. This can happen > especially during network migration and deployment of new services. As you > said, using different RT is not recommended, and using same RT some PEs need > the ability to notify others only some kind of routes are needed. > > And as Mach has said before, compared with the quantity of unwanted routes > being advertised, the amount of RT-constrain information can be ignored. > >> In my mind, the question we should ask is: would a service provider use >> the same customer id for 2 different customers (even if they have >> different services ?). The answer is no. The same way the SP >> provisioning system should be able to assign unique RTs per customer so >> that ops can retrieve the customer-id from the RT. > Operators can choose how to manage their networks, and also different > operators can choose different ways. IMO we should provide methods to > lighten operators' burden on VPN service provisioning and assure that > different services will not affect each other. > > Regards > Jie > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From mach@huawei.com Tue Nov 10 20:29:50 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE66D3A68DD for ; Tue, 10 Nov 2009 20:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NYrm7mwgsmT for ; Tue, 10 Nov 2009 20:29:49 -0800 (PST) Received: from lhrga01-in.huawei.com (lhrga01-in.huawei.com [195.33.106.110]) by core3.amsl.com (Postfix) with ESMTP id 033E03A6930 for ; Tue, 10 Nov 2009 20:29:32 -0800 (PST) Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSX003S9GHY9Y@lhrga01-in.huawei.com> for idr@ietf.org; Wed, 11 Nov 2009 04:29:58 +0000 (GMT) Received: from LENOVOmach (host-113-133.meeting.ietf.org [133.93.113.133]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSX00J98GHV0C@lhrga01-in.huawei.com> for idr@ietf.org; Wed, 11 Nov 2009 04:29:58 +0000 (GMT) Date: Wed, 11 Nov 2009 12:30:02 +0800 From: Mach Chen In-reply-to: <4AFA1EB5.8070105@cisco.com> To: raszuk@cisco.com, Jie Dong Message-id: <5C3E6F82217140AEBE3DDC9341DE66B0@LENOVOmach> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <002b01ca6272$b4a77e70$be125d85@china.huawei.com> <4AFA1EB5.8070105@cisco.com> Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Mach Chen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:29:50 -0000 Hi Robert, > I think what you are trying to express is to assing on one PE 100:1 for > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for customer Exactly, this is one of the issues that may lead to sending/receiving unnecessary VPN routes. > Y. That would be IMHO a misconfiguration. Why do you think this is misconfiguration? By your logic, does it mean the configuration of one type of VPN will restrict and/or be restricted by other types of VPNs. If things like this, it will affect the flexibility of the deployment/provisioning of VPNs. And that, especially in inter-domain scenarios, it may be difficult/impossible to apply this restriction. Best regards, Mach -------------------------------------------------- From: "Robert Raszuk" Sent: Wednesday, November 11, 2009 10:17 AM To: "Jie Dong" Cc: "'Pedro Marques (roque)'" ; "'Mach Chen'" ; Subject: Re: [Idr] Response to comments on generalized RT constrain solution > Jie, > >> But with normal rt-constrain PEs of these sites will receive VPN >> routes of all these services, including the unwanted ones. > > I don't understand the definition of "unwanted routes" in the draft and in > your email description. > > If RT is assigned that matches the routes they are received and accepted. > If RT attached to the route is not part of import of any VRF of the PE > they are dropped today and with rt-constrain will not be sent. > > I really don't see how this is related to SAFIs/services provided. > > In fact if you don't have service ABC configured on such PE in question it > will not receive any routes either today or with rt-constrain. Please > observe that rt-constrain is just a filter not the request for routes. > > I think what you are trying to express is to assing on one PE 100:1 for > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for customer Y. > That would be IMHO a misconfiguration. > > Cheers, > R. > > >> Hi, Thanks for your comments. Please see inline... >> >>>> The issue we really concern is that the RTs overlap among different >>>> customers. Different VPNs for different customers may be configiured >>> to >>>> used >>>> same RT, that means the RT of one type of VPN may attracted unwanted >>>> routes >>>> belong to other types of VPNS, and that the RT >>>> configuration/modification of >>>> one type VPN may affect the other VPNs that are totally not relevant >>> to >>>> that >>>> VPN. >>> I'm not sure I follow your argument. Clearly if we are talking about >>> VPNs with the same address family you can't use the same RT for >>> different VPNs. For a VPN service to operate correctly the provisioning >>> mechanism should be able to assign an unique RT per VPN. >>> >> Yes, for VPNs with the same AFI/SAFI, different RT should be assigned for >> different customers. >>> Now, even if you had the ability to use the same RT value across >>> different address families you most likely wouldn't want to use it. For >>> example, if customer A has a VPN with v4 service and customer B has a >>> VPN with v6 service it would be a *really bad idea* to assign the same >>> value to both because A may want to have v6 service in the future or >>> vice-versa. >> What we mean here is for different AFI/SAFIs the allocation of RT should >> be >> able to operate independently. Operators can choose to use same or >> different >> RT for different kinds of VPNs, either for same customer or different >> customers. The assignment of RT can be quite flexible. Especially in >> mutli-ISP scenarios, different ISP may use the same RT for different kind >> of >> VPNs. >> >>> The main point here is that in practice RT assignment is not per AF but >>> per VPN. That is the reason the rt constraint draft handles the RT >>> independently of the AF. >> If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for these >> two >> VPNs are independent, they could use either different RT or same RT based >> on >> the policy of the operator. >>> It seems to me that attempts to have RT constraint have per AF semantics >>> are misguided in the least. A VPN will very likely have multiple >>> services that use different BGP AFI,SAFIs and while in theory they could >>> use multiple RTs there is no practical value in doing so. That would >>> result in having to advertise multiple times the same information when >>> using rt-constraint >> Using same RT for multiple services is reasonable, however the sites may >> not >> be identical for all these services. Some sites may only be interested in >> some of these services, and more unneeded routes may get their PEs into >> trouble. But with normal rt-constrain PEs of these sites will receive VPN >> routes of all these services, including the unwanted ones. This can >> happen >> especially during network migration and deployment of new services. As >> you >> said, using different RT is not recommended, and using same RT some PEs >> need >> the ability to notify others only some kind of routes are needed. >> >> And as Mach has said before, compared with the quantity of unwanted >> routes >> being advertised, the amount of RT-constrain information can be ignored. >> >>> In my mind, the question we should ask is: would a service provider use >>> the same customer id for 2 different customers (even if they have >>> different services ?). The answer is no. The same way the SP >>> provisioning system should be able to assign unique RTs per customer so >>> that ops can retrieve the customer-id from the RT. >> Operators can choose how to manage their networks, and also different >> operators can choose different ways. IMO we should provide methods to >> lighten operators' burden on VPN service provisioning and assure that >> different services will not affect each other. >> >> Regards >> Jie >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > From dongjie_dj@huawei.com Tue Nov 10 21:13:17 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFADC3A6C0F for ; Tue, 10 Nov 2009 21:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOnTo+4MqhuH for ; Tue, 10 Nov 2009 21:13:16 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 9568D3A6A39 for ; Tue, 10 Nov 2009 21:13:16 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSX009S8IIW7S@usaga01-in.huawei.com> for idr@ietf.org; Tue, 10 Nov 2009 21:13:44 -0800 (PST) Received: from JYS8110164H (host-113-134.meeting.ietf.org [133.93.113.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSX00MS4IIT60@usaga01-in.huawei.com> for idr@ietf.org; Tue, 10 Nov 2009 21:13:44 -0800 (PST) Date: Wed, 11 Nov 2009 14:13:53 +0900 From: Jie Dong In-reply-to: <4AFA1EB5.8070105@cisco.com> To: raszuk@cisco.com Message-id: <003e01ca628d$c4e986f0$be125d85@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpidUC49c5uP9arTieblLbvNGgShAACxlAA Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:13:18 -0000 Hi Robert, > > But with normal rt-constrain PEs of these sites will receive VPN > > routes of all these services, including the unwanted ones. > > I don't understand the definition of "unwanted routes" in the draft and > in your email description. > > If RT is assigned that matches the routes they are received and > accepted. If RT attached to the route is not part of import of any VRF > of the PE they are dropped today and with rt-constrain will not be sent. > If attached RT of VPNv6 routes matches the imported RT for VPNv4 routes on one PE, with normal rt-constrain that VPNv6 routes can also be sent to that PE. These routes are not what the PE wants. Note that PE may want VPNv6 routes of another VPN, thus the AFI/SAFI capability negotiation indicates that PE is VPNv6 capable. > I really don't see how this is related to SAFIs/services provided. > > In fact if you don't have service ABC configured on such PE in question > it will not receive any routes either today or with rt-constrain. Please > observe that rt-constrain is just a filter not the request for routes. > > I think what you are trying to express is to assing on one PE 100:1 for > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for customer > Y. That would be IMHO a misconfiguration. If this is a misconfiguration, then RTs used by L3VPN cannot be used for L2VPN. This is a restriction to deployment of different kind of VPNs. And in this way, different kind of VPNs cannot be operated and managed independently, do you think this is reasonable? In most networks different kind of VPNs are deployed gradually based on the demand of customers. Thus it is impossible to make a plan for deployment of all kinds of VPNs at the beginning. And this would also affect the flexibility of deployment of new VPN services. Also, I would like to remind you of the problem with length of the RT field. It is another problem our draft proposes to solve. Regards Jie > > Hi, > > > > Thanks for your comments. Please see inline... > > > >>> The issue we really concern is that the RTs overlap among different > >>> customers. Different VPNs for different customers may be configiured > >> to > >>> used > >>> same RT, that means the RT of one type of VPN may attracted unwanted > >>> routes > >>> belong to other types of VPNS, and that the RT > >>> configuration/modification of > >>> one type VPN may affect the other VPNs that are totally not relevant > >> to > >>> that > >>> VPN. > >> I'm not sure I follow your argument. Clearly if we are talking about > >> VPNs with the same address family you can't use the same RT for > >> different VPNs. For a VPN service to operate correctly the provisioning > >> mechanism should be able to assign an unique RT per VPN. > >> > > Yes, for VPNs with the same AFI/SAFI, different RT should be assigned for > > different customers. > > > >> Now, even if you had the ability to use the same RT value across > >> different address families you most likely wouldn't want to use it. For > >> example, if customer A has a VPN with v4 service and customer B has a > >> VPN with v6 service it would be a *really bad idea* to assign the same > >> value to both because A may want to have v6 service in the future or > >> vice-versa. > > What we mean here is for different AFI/SAFIs the allocation of RT should be > > able to operate independently. Operators can choose to use same or different > > RT for different kinds of VPNs, either for same customer or different > > customers. The assignment of RT can be quite flexible. Especially in > > mutli-ISP scenarios, different ISP may use the same RT for different kind > of > > VPNs. > > > >> The main point here is that in practice RT assignment is not per AF but > >> per VPN. That is the reason the rt constraint draft handles the RT > >> independently of the AF. > > If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for these two > > VPNs are independent, they could use either different RT or same RT based > on > > the policy of the operator. > > > >> It seems to me that attempts to have RT constraint have per AF semantics > >> are misguided in the least. A VPN will very likely have multiple > >> services that use different BGP AFI,SAFIs and while in theory they could > >> use multiple RTs there is no practical value in doing so. That would > >> result in having to advertise multiple times the same information when > >> using rt-constraint > > Using same RT for multiple services is reasonable, however the sites may not > > be identical for all these services. Some sites may only be interested in > > some of these services, and more unneeded routes may get their PEs into > > trouble. But with normal rt-constrain PEs of these sites will receive VPN > > routes of all these services, including the unwanted ones. This can happen > > especially during network migration and deployment of new services. As you > > said, using different RT is not recommended, and using same RT some PEs need > > the ability to notify others only some kind of routes are needed. > > > > And as Mach has said before, compared with the quantity of unwanted routes > > being advertised, the amount of RT-constrain information can be ignored. > > > >> In my mind, the question we should ask is: would a service provider use > >> the same customer id for 2 different customers (even if they have > >> different services ?). The answer is no. The same way the SP > >> provisioning system should be able to assign unique RTs per customer so > >> that ops can retrieve the customer-id from the RT. > > Operators can choose how to manage their networks, and also different > > operators can choose different ways. IMO we should provide methods to > > lighten operators' burden on VPN service provisioning and assure that > > different services will not affect each other. > > > > Regards > > Jie > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > From raszuk@cisco.com Tue Nov 10 21:30:44 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFC628C296 for ; Tue, 10 Nov 2009 21:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8go8niQ2I7I for ; Tue, 10 Nov 2009 21:30:44 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1798228C266 for ; Tue, 10 Nov 2009 21:30:44 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKfa+UpAaHte/2dsb2JhbADFBIEcCAGXK4Q8BIFreA X-IronPort-AV: E=Sophos;i="4.44,721,1249257600"; d="scan'208";a="103466741" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2009 05:31:11 +0000 Received: from [10.70.231.115] (tky-vpn-client-231-115.cisco.com [10.70.231.115]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAB5V9xr023923; Wed, 11 Nov 2009 05:31:09 GMT Message-ID: <4AFA4C20.40604@cisco.com> Date: Wed, 11 Nov 2009 14:31:12 +0900 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mach Chen References: <06c501ca61c7$0d8c86e0$1200a8c0@china.huawei.com> <4AF90CAA.3030700@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:30:45 -0000 >> > 3. BTW, there is another issue regarding to the length of the RT >> > filed, the IPv6 address specified RT is covered in rfc4684. >> >> Can you clarify what is the issue ? > > Here is the RT difinition in RFC4684: > +-------------------------------+ > | origin as (4 octets) | > +-------------------------------+ > | route target (8 octets) | > + + > | | > +-------------------------------+ > > There is only 8 octets left for route target. Why do you need more ? RFC4360 is quite clear on route target format and it is 8 octets. RFC4684 just talks about IPv4 or IPv6 next hops to be used as part of MP_REACH_NLRI. That has nothing to do with different RT format. Cheers, R. From raszuk@cisco.com Tue Nov 10 21:40:13 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDAE3A6910 for ; Tue, 10 Nov 2009 21:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9--emDfv+Zl for ; Tue, 10 Nov 2009 21:40:12 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 57E8C3A686D for ; Tue, 10 Nov 2009 21:40:12 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMPc+UpAaHte/2dsb2JhbADEfoEcCAGXKYI9gX8EgmM X-IronPort-AV: E=Sophos;i="4.44,721,1249257600"; d="scan'208";a="103467282" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2009 05:40:40 +0000 Received: from [10.70.231.115] (tky-vpn-client-231-115.cisco.com [10.70.231.115]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAB5ecvm025909; Wed, 11 Nov 2009 05:40:38 GMT Message-ID: <4AFA4E59.2010008@cisco.com> Date: Wed, 11 Nov 2009 14:40:41 +0900 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jie Dong References: <003e01ca628d$c4e986f0$be125d85@china.huawei.com> In-Reply-To: <003e01ca628d$c4e986f0$be125d85@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:40:13 -0000 Jie, > In most networks different > kind of VPNs are deployed gradually based on the demand of customers. Thus > it is impossible to make a plan for deployment of all kinds of VPNs at the > beginning. And this would also affect the flexibility of deployment of new > VPN services. There is many years of operational experience in deployment of various VPN services today. AFAIK non of the deployments today have found this to be of any practical issue. I think it would be great at this point to hear from operator's community if they see a recommendation for unique RT assignment for different customers/services as a problem. Thx, R. From rajiva@cisco.com Tue Nov 10 22:00:24 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7FBF28C2A9 for ; Tue, 10 Nov 2009 22:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFLA277gArXJ for ; Tue, 10 Nov 2009 22:00:22 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5FDBC28C2A7 for ; Tue, 10 Nov 2009 22:00:22 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK/h+UqrR7Hu/2dsb2JhbADEcJhLgj2BfwSBaw X-IronPort-AV: E=Sophos;i="4.44,721,1249257600"; d="scan'208";a="429722127" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2009 06:00:50 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nAB60onQ015665; Wed, 11 Nov 2009 06:00:50 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 00:00:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 00:00:41 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C197CA7@XMB-RCD-111.cisco.com> In-Reply-To: <4AFA1EB5.8070105@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Response to comments on generalized RT constrain solution Thread-Index: AcpidSJqUsNuengwTDG9EVV9WrJrDAAFTRFg References: <002b01ca6272$b4a77e70$be125d85@china.huawei.com> <4AFA1EB5.8070105@cisco.com> From: "Rajiv Asati (rajiva)" To: "Robert Raszuk (raszuk)" , "Jie Dong" X-OriginalArrivalTime: 11 Nov 2009 06:00:49.0571 (UTC) FILETIME=[51831F30:01CA6294] Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:00:24 -0000 > I don't understand the definition of "unwanted routes" in the draft and > in your email description. >=20 > If RT is assigned that matches the routes they are received and > accepted. If RT attached to the route is not part of import of any VRF > of the PE they are dropped today and with rt-constrain will not be sent. >=20 > I really don't see how this is related to SAFIs/services provided. Allow me to justify this problem per the draft, though we can't yet justify the solution: ~~~~~~~~~~~~~ Consider VPN customer A has 10 sites - siteA1, siteA2...siteA10. All the sites need IPv4 any-to-any connectivity, however, only siteA1 and siteA2 need IPv6 connectivity. If the VRF for VPN customer A is configured with the same RT set for both IPv4 and IPv6 SAFIs on each PE connected to each of 10 sites, then each PE router ends up with all IPv4 and IPv6 routes related to that VPN.=20 Of course, PEs connected to siteA3,...siteA10 should not care about the IPv6 routes in that VPN since the sites don't need them. Hence, those routes become unwanted routes. ~~~~~~~ I don't know if this is how the draft defines the "unwanted routes", but that's my understanding based on the slides I saw yday. Cheers, Rajiv > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert > Raszuk (raszuk) > Sent: Tuesday, November 10, 2009 9:17 PM > To: Jie Dong > Cc: idr@ietf.org > Subject: Re: [Idr] Response to comments on generalized RT constrain solution >=20 > Jie, >=20 > > But with normal rt-constrain PEs of these sites will receive VPN > > routes of all these services, including the unwanted ones. >=20 > I don't understand the definition of "unwanted routes" in the draft and > in your email description. >=20 > If RT is assigned that matches the routes they are received and > accepted. If RT attached to the route is not part of import of any VRF > of the PE they are dropped today and with rt-constrain will not be sent. >=20 > I really don't see how this is related to SAFIs/services provided. >=20 > In fact if you don't have service ABC configured on such PE in question > it will not receive any routes either today or with rt-constrain. Please > observe that rt-constrain is just a filter not the request for routes. >=20 > I think what you are trying to express is to assing on one PE 100:1 for > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for customer > Y. That would be IMHO a misconfiguration. >=20 > Cheers, > R. >=20 >=20 > > Hi, > > > > Thanks for your comments. Please see inline... > > > >>> The issue we really concern is that the RTs overlap among different > >>> customers. Different VPNs for different customers may be configiured > >> to > >>> used > >>> same RT, that means the RT of one type of VPN may attracted unwanted > >>> routes > >>> belong to other types of VPNS, and that the RT > >>> configuration/modification of > >>> one type VPN may affect the other VPNs that are totally not relevant > >> to > >>> that > >>> VPN. > >> I'm not sure I follow your argument. Clearly if we are talking about > >> VPNs with the same address family you can't use the same RT for > >> different VPNs. For a VPN service to operate correctly the provisioning > >> mechanism should be able to assign an unique RT per VPN. > >> > > Yes, for VPNs with the same AFI/SAFI, different RT should be assigned for > > different customers. > > > >> Now, even if you had the ability to use the same RT value across > >> different address families you most likely wouldn't want to use it. For > >> example, if customer A has a VPN with v4 service and customer B has a > >> VPN with v6 service it would be a *really bad idea* to assign the same > >> value to both because A may want to have v6 service in the future or > >> vice-versa. > > What we mean here is for different AFI/SAFIs the allocation of RT should be > > able to operate independently. Operators can choose to use same or different > > RT for different kinds of VPNs, either for same customer or different > > customers. The assignment of RT can be quite flexible. Especially in > > mutli-ISP scenarios, different ISP may use the same RT for different kind of > > VPNs. > > > >> The main point here is that in practice RT assignment is not per AF but > >> per VPN. That is the reason the rt constraint draft handles the RT > >> independently of the AF. > > If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for these two > > VPNs are independent, they could use either different RT or same RT based on > > the policy of the operator. > > > >> It seems to me that attempts to have RT constraint have per AF semantics > >> are misguided in the least. A VPN will very likely have multiple > >> services that use different BGP AFI,SAFIs and while in theory they could > >> use multiple RTs there is no practical value in doing so. That would > >> result in having to advertise multiple times the same information when > >> using rt-constraint > > Using same RT for multiple services is reasonable, however the sites may not > > be identical for all these services. Some sites may only be interested in > > some of these services, and more unneeded routes may get their PEs into > > trouble. But with normal rt-constrain PEs of these sites will receive VPN > > routes of all these services, including the unwanted ones. This can happen > > especially during network migration and deployment of new services. As you > > said, using different RT is not recommended, and using same RT some PEs need > > the ability to notify others only some kind of routes are needed. > > > > And as Mach has said before, compared with the quantity of unwanted routes > > being advertised, the amount of RT-constrain information can be ignored. > > > >> In my mind, the question we should ask is: would a service provider use > >> the same customer id for 2 different customers (even if they have > >> different services ?). The answer is no. The same way the SP > >> provisioning system should be able to assign unique RTs per customer so > >> that ops can retrieve the customer-id from the RT. > > Operators can choose how to manage their networks, and also different > > operators can choose different ways. IMO we should provide methods to > > lighten operators' burden on VPN service provisioning and assure that > > different services will not affect each other. > > > > Regards > > Jie > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rajiva@cisco.com Tue Nov 10 22:01:09 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AAA928C2AD for ; Tue, 10 Nov 2009 22:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvaEb1KgekNV for ; Tue, 10 Nov 2009 22:01:07 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7F94428C2A7 for ; Tue, 10 Nov 2009 22:01:07 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK/h+UqtJV2Z/2dsb2JhbADEcJhLgj2BfwSBaw X-IronPort-AV: E=Sophos;i="4.44,721,1249257600"; d="scan'208";a="67418564" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2009 06:01:34 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id nAB61YuH013547; Wed, 11 Nov 2009 06:01:34 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 00:01:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 00:01:29 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C197CA8@XMB-RCD-111.cisco.com> In-Reply-To: <5C3E6F82217140AEBE3DDC9341DE66B0@LENOVOmach> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Response to comments on generalized RT constrain solution Thread-Index: Acpih8GPtUdciADQTWmIyE2z9W37fgAAPvtQ References: <002b01ca6272$b4a77e70$be125d85@china.huawei.com><4AFA1EB5.8070105@cisco.com> <5C3E6F82217140AEBE3DDC9341DE66B0@LENOVOmach> From: "Rajiv Asati (rajiva)" To: "Mach Chen" , "Robert Raszuk (raszuk)" , "Jie Dong" X-OriginalArrivalTime: 11 Nov 2009 06:01:34.0200 (UTC) FILETIME=[6C1CF780:01CA6294] Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:01:09 -0000 Firstly, assigning the same RT to two different customers' VPN inside the SP network must be avoided (unless the intent is that two VPNs need each others' routes). It is indeed a misconfiguration. In fact, this is explicitly outlined in section 4.3.5 of RFC4364. Then each site is associated with a VRF, a single Route Target attribute is chosen, that Route Target is assigned to each VRF as both the Import Target and the Export Target, and that Route Target is not assigned to any other VRFs as either the Import Target or the Export Target. Secondly, assigning the same RT to different (sub) address-families belonging to the same customer' VPN inside the SP network should not be permitted unless they result in the congruent topologies. If they don't, then the customer sites should be perceived to belonging to different VPNs (one for IPv4 and the other for IPv6, say), requiring two different RT value(s). In the contrary, if each customer site needs both=20 IPv4 and IPv6 routes, then each site participates=20 in congruent IPv4 and IPv6 topologies. Hence, same=20 RT (set) could be utilized in the VRF. Unfortunately, RFC4364 is not explicit about this. While one may deduce the above from the section 4.3.5 of RFC4364, the section 4.3.1 paints a different picture: A Route Target attribute can be thought of as identifying a set of sites. (Though it would be more precise to think of it as identifying a set of VRFs.) Associating a particular Route Target attribute with a route allows that route to be placed in the VRFs that are used for routing traffic that is received from the corresponding sites. Unfortunately, the RFC4659 (VPNv6) is moot on this topic. We need to write a document to clarify this better, otherwise the lack of clarity on this topic would continue to stir the confusion, resulting in the undesired proposals and efforts. Cheers, Rajiv > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Mach > Chen > Sent: Tuesday, November 10, 2009 11:30 PM > To: Robert Raszuk (raszuk); Jie Dong > Cc: idr@ietf.org > Subject: Re: [Idr] Response to comments on generalized RT constrain solution >=20 > Hi Robert, >=20 > > I think what you are trying to express is to assing on one PE 100:1 for > > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for customer >=20 > Exactly, this is one of the issues that may lead to sending/receiving > unnecessary VPN routes. >=20 > > Y. That would be IMHO a misconfiguration. >=20 > Why do you think this is misconfiguration? By your logic, does it mean the > configuration of one type of VPN will restrict and/or be restricted by other > types of VPNs. If things like this, it will affect the flexibility of the > deployment/provisioning of VPNs. And that, especially in inter-domain > scenarios, it may be difficult/impossible to apply this restriction. >=20 >=20 > Best regards, > Mach >=20 > -------------------------------------------------- > From: "Robert Raszuk" > Sent: Wednesday, November 11, 2009 10:17 AM > To: "Jie Dong" > Cc: "'Pedro Marques (roque)'" ; "'Mach Chen'" > ; > Subject: Re: [Idr] Response to comments on generalized RT constrain solution >=20 > > Jie, > > > >> But with normal rt-constrain PEs of these sites will receive VPN > >> routes of all these services, including the unwanted ones. > > > > I don't understand the definition of "unwanted routes" in the draft and in > > your email description. > > > > If RT is assigned that matches the routes they are received and accepted. > > If RT attached to the route is not part of import of any VRF of the PE > > they are dropped today and with rt-constrain will not be sent. > > > > I really don't see how this is related to SAFIs/services provided. > > > > In fact if you don't have service ABC configured on such PE in question it > > will not receive any routes either today or with rt-constrain. Please > > observe that rt-constrain is just a filter not the request for routes. > > > > I think what you are trying to express is to assing on one PE 100:1 for > > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for customer Y. > > That would be IMHO a misconfiguration. > > > > Cheers, > > R. > > > > > >> Hi, Thanks for your comments. Please see inline... > >> > >>>> The issue we really concern is that the RTs overlap among different > >>>> customers. Different VPNs for different customers may be configiured > >>> to > >>>> used > >>>> same RT, that means the RT of one type of VPN may attracted unwanted > >>>> routes > >>>> belong to other types of VPNS, and that the RT > >>>> configuration/modification of > >>>> one type VPN may affect the other VPNs that are totally not relevant > >>> to > >>>> that > >>>> VPN. > >>> I'm not sure I follow your argument. Clearly if we are talking about > >>> VPNs with the same address family you can't use the same RT for > >>> different VPNs. For a VPN service to operate correctly the provisioning > >>> mechanism should be able to assign an unique RT per VPN. > >>> > >> Yes, for VPNs with the same AFI/SAFI, different RT should be assigned for > >> different customers. > >>> Now, even if you had the ability to use the same RT value across > >>> different address families you most likely wouldn't want to use it. For > >>> example, if customer A has a VPN with v4 service and customer B has a > >>> VPN with v6 service it would be a *really bad idea* to assign the same > >>> value to both because A may want to have v6 service in the future or > >>> vice-versa. > >> What we mean here is for different AFI/SAFIs the allocation of RT should > >> be > >> able to operate independently. Operators can choose to use same or > >> different > >> RT for different kinds of VPNs, either for same customer or different > >> customers. The assignment of RT can be quite flexible. Especially in > >> mutli-ISP scenarios, different ISP may use the same RT for different kind > >> of > >> VPNs. > >> > >>> The main point here is that in practice RT assignment is not per AF but > >>> per VPN. That is the reason the rt constraint draft handles the RT > >>> independently of the AF. > >> If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for these > >> two > >> VPNs are independent, they could use either different RT or same RT based > >> on > >> the policy of the operator. > >>> It seems to me that attempts to have RT constraint have per AF semantics > >>> are misguided in the least. A VPN will very likely have multiple > >>> services that use different BGP AFI,SAFIs and while in theory they could > >>> use multiple RTs there is no practical value in doing so. That would > >>> result in having to advertise multiple times the same information when > >>> using rt-constraint > >> Using same RT for multiple services is reasonable, however the sites may > >> not > >> be identical for all these services. Some sites may only be interested in > >> some of these services, and more unneeded routes may get their PEs into > >> trouble. But with normal rt-constrain PEs of these sites will receive VPN > >> routes of all these services, including the unwanted ones. This can > >> happen > >> especially during network migration and deployment of new services. As > >> you > >> said, using different RT is not recommended, and using same RT some PEs > >> need > >> the ability to notify others only some kind of routes are needed. > >> > >> And as Mach has said before, compared with the quantity of unwanted > >> routes > >> being advertised, the amount of RT-constrain information can be ignored. > >> > >>> In my mind, the question we should ask is: would a service provider use > >>> the same customer id for 2 different customers (even if they have > >>> different services ?). The answer is no. The same way the SP > >>> provisioning system should be able to assign unique RTs per customer so > >>> that ops can retrieve the customer-id from the RT. > >> Operators can choose how to manage their networks, and also different > >> operators can choose different ways. IMO we should provide methods to > >> lighten operators' burden on VPN service provisioning and assure that > >> different services will not affect each other. > >> > >> Regards > >> Jie > >> > >> > >> _______________________________________________ > >> Idr mailing list > >> Idr@ietf.org > >> https://www.ietf.org/mailman/listinfo/idr > >> > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rajiva@cisco.com Tue Nov 10 22:09:25 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B5B28C2B4 for ; Tue, 10 Nov 2009 22:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGI7qw3B90yK for ; Tue, 10 Nov 2009 22:09:24 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4B4A33A6853 for ; Tue, 10 Nov 2009 22:08:39 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI/j+UpAZnwN/2dsb2JhbADEaZhIhDwEgWs X-IronPort-AV: E=Sophos;i="4.44,721,1249257600"; d="scan'208";a="67368788" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 11 Nov 2009 06:09:06 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.190]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAB696iD014462; Wed, 11 Nov 2009 06:09:06 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 00:09:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 00:09:03 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C197CAA@XMB-RCD-111.cisco.com> In-Reply-To: <4AFA4C20.40604@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Response to comments on generalized RT constrain solution Thread-Index: AcpikDNEU4IAr0rwSBmk6Dk9rzuxLAABLUzw References: <06c501ca61c7$0d8c86e0$1200a8c0@china.huawei.com><4AF90CAA.3030700@cisco.com> <4AFA4C20.40604@cisco.com> From: "Rajiv Asati (rajiva)" To: "Robert Raszuk (raszuk)" , "Mach Chen" X-OriginalArrivalTime: 11 Nov 2009 06:09:06.0401 (UTC) FILETIME=[79A55D10:01CA6295] Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:09:25 -0000 If the RT is specified using 'draft-ietf-l3vpn-v6-ext-communities' (20 octets), then how would it fit in the RT definition of RFC4684 (8 octets)?=20 Not sure if this is what Mach is alluding to, but I do see this as an issue. Cheers, Rajiv > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert > Raszuk (raszuk) > Sent: Wednesday, November 11, 2009 12:31 AM > To: Mach Chen > Cc: idr@ietf.org > Subject: Re: [Idr] Response to comments on generalized RT constrain solution >=20 >=20 > >> > 3. BTW, there is another issue regarding to the length of the RT > >> > filed, the IPv6 address specified RT is covered in rfc4684. > >> > >> Can you clarify what is the issue ? > > > > Here is the RT difinition in RFC4684: > > +-------------------------------+ > > | origin as (4 octets) | > > +-------------------------------+ > > | route target (8 octets) | > > + + > > | | > > +-------------------------------+ > > > > There is only 8 octets left for route target. >=20 > Why do you need more ? RFC4360 is quite clear on route target format and > it is 8 octets. >=20 > RFC4684 just talks about IPv4 or IPv6 next hops to be used as part of > MP_REACH_NLRI. That has nothing to do with different RT format. >=20 > Cheers, > R. >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From mach@huawei.com Tue Nov 10 22:15:40 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A2428C2B5 for ; Tue, 10 Nov 2009 22:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wD7WLUv39AhP for ; Tue, 10 Nov 2009 22:15:39 -0800 (PST) Received: from lhrga01-in.huawei.com (lhrga01-in.huawei.com [195.33.106.110]) by core3.amsl.com (Postfix) with ESMTP id 3350728C0F7 for ; Tue, 10 Nov 2009 22:15:39 -0800 (PST) Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSX003JOLES9Y@lhrga01-in.huawei.com> for idr@ietf.org; Wed, 11 Nov 2009 06:16:04 +0000 (GMT) Received: from LENOVOmach (host-18-200.meeting.ietf.org [133.93.18.200]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSX00JWFLEM0C@lhrga01-in.huawei.com> for idr@ietf.org; Wed, 11 Nov 2009 06:16:02 +0000 (GMT) Date: Wed, 11 Nov 2009 14:16:05 +0800 From: Mach Chen In-reply-to: <4AFA4C20.40604@cisco.com> To: raszuk@cisco.com Message-id: <3093148F4C884E249316B2EBC9CE9E18@LENOVOmach> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <06c501ca61c7$0d8c86e0$1200a8c0@china.huawei.com> <4AF90CAA.3030700@cisco.com> <4AFA4C20.40604@cisco.com> Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Mach Chen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:15:40 -0000 Hi Robert, IPv6 address specified RT (length of 20 bytes) is defined in http://tools.ietf.org/html/draft-ietf-l3vpn-v6-ext-communities-02, and RFC 4684 does not support this new RT. Best regards, Mach -------------------------------------------------- From: "Robert Raszuk" Sent: Wednesday, November 11, 2009 1:31 PM To: "Mach Chen" Cc: ; "Dong Jie" Subject: Re: [Idr] Response to comments on generalized RT constrain solution > >>> > 3. BTW, there is another issue regarding to the length of the RT >>> > filed, the IPv6 address specified RT is covered in rfc4684. >>> >>> Can you clarify what is the issue ? >> >> Here is the RT difinition in RFC4684: >> +-------------------------------+ >> | origin as (4 octets) | >> +-------------------------------+ >> | route target (8 octets) | >> + + >> | | >> +-------------------------------+ >> >> There is only 8 octets left for route target. > > Why do you need more ? RFC4360 is quite clear on route target format and > it is 8 octets. > > RFC4684 just talks about IPv4 or IPv6 next hops to be used as part of > MP_REACH_NLRI. That has nothing to do with different RT format. > > Cheers, > R. > > From mach@huawei.com Tue Nov 10 22:17:41 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5A728C2B5 for ; Tue, 10 Nov 2009 22:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPO1DtxU3rsg for ; Tue, 10 Nov 2009 22:17:40 -0800 (PST) Received: from lhrga03-in.huawei.com (lhrga03-in.huawei.com [195.33.106.148]) by core3.amsl.com (Postfix) with ESMTP id B32E228C2AD for ; Tue, 10 Nov 2009 22:17:40 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSX008WTLI7H3@lhrga03-in.huawei.com> for idr@ietf.org; Wed, 11 Nov 2009 06:18:07 +0000 (GMT) Received: from LENOVOmach (host-18-200.meeting.ietf.org [133.93.18.200]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSX002JHLI3NF@lhrga03-in.huawei.com> for idr@ietf.org; Wed, 11 Nov 2009 06:18:06 +0000 (GMT) Date: Wed, 11 Nov 2009 14:18:10 +0800 From: Mach Chen In-reply-to: <067E6CE33034954AAC05C9EC85E2577C197CAA@XMB-RCD-111.cisco.com> To: "Rajiv Asati (rajiva)" , "Robert Raszuk (raszuk)" Message-id: <942662AA71564DCC98A55D05DAA8071D@LENOVOmach> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <06c501ca61c7$0d8c86e0$1200a8c0@china.huawei.com> <4AF90CAA.3030700@cisco.com> <4AFA4C20.40604@cisco.com> <067E6CE33034954AAC05C9EC85E2577C197CAA@XMB-RCD-111.cisco.com> Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Mach Chen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:17:41 -0000 Hi Rajiv, > If the RT is specified using 'draft-ietf-l3vpn-v6-ext-communities' (20 > octets), then how would it fit in the RT definition of RFC4684 (8 > octets)? > > Not sure if this is what Mach is alluding to, but I do see this as an > issue. Correctly! Best regards, Mach > > Cheers, > Rajiv > >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Robert >> Raszuk (raszuk) >> Sent: Wednesday, November 11, 2009 12:31 AM >> To: Mach Chen >> Cc: idr@ietf.org >> Subject: Re: [Idr] Response to comments on generalized RT constrain > solution >> >> >> >> > 3. BTW, there is another issue regarding to the length of the RT >> >> > filed, the IPv6 address specified RT is covered in rfc4684. >> >> >> >> Can you clarify what is the issue ? >> > >> > Here is the RT difinition in RFC4684: >> > +-------------------------------+ >> > | origin as (4 octets) | >> > +-------------------------------+ >> > | route target (8 octets) | >> > + + >> > | | >> > +-------------------------------+ >> > >> > There is only 8 octets left for route target. >> >> Why do you need more ? RFC4360 is quite clear on route target format > and >> it is 8 octets. >> >> RFC4684 just talks about IPv4 or IPv6 next hops to be used as part of >> MP_REACH_NLRI. That has nothing to do with different RT format. >> >> Cheers, >> R. >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From dongjie_dj@huawei.com Tue Nov 10 22:25:15 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5845428C2B5 for ; Tue, 10 Nov 2009 22:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1UavHLzuAYa for ; Tue, 10 Nov 2009 22:25:14 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 157433A6BD9 for ; Tue, 10 Nov 2009 22:25:11 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSX001S4LUQZQ@usaga03-in.huawei.com> for idr@ietf.org; Wed, 11 Nov 2009 00:25:38 -0600 (CST) Received: from JYS8110164H (host-18-190.meeting.ietf.org [133.93.18.190]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSX00GIPLUOMY@usaga03-in.huawei.com> for idr@ietf.org; Wed, 11 Nov 2009 00:25:38 -0600 (CST) Date: Wed, 11 Nov 2009 15:25:48 +0900 From: Jie Dong In-reply-to: <067E6CE33034954AAC05C9EC85E2577C197CA7@XMB-RCD-111.cisco.com> To: "'Rajiv Asati (rajiva)'" , "'Robert Raszuk (raszuk)'" Message-id: <004d01ca6297$d05e38a0$be125d85@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpidSJqUsNuengwTDG9EVV9WrJrDAAFTRFgAAMUCUA= Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:25:15 -0000 Hi, Thanks for clarifying this problem, that's one scenario of receiving "unwanted" (Sorry for confusing on this.) routes: same RT is used by one customer for different kind of VPNs. And another possible scenario is that same RT is used by different customer for different kind of VPNs. In both these cases PEs may receive "unwanted" routes. Jie > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Wednesday, November 11, 2009 3:01 PM > To: Robert Raszuk (raszuk); Jie Dong > Cc: idr@ietf.org > Subject: RE: [Idr] Response to comments on generalized RT constrain solution > > > I don't understand the definition of "unwanted routes" in the draft > and > > in your email description. > > > > If RT is assigned that matches the routes they are received and > > accepted. If RT attached to the route is not part of import of any VRF > > of the PE they are dropped today and with rt-constrain will not be > sent. > > > > I really don't see how this is related to SAFIs/services provided. > > Allow me to justify this problem per the draft, though we can't yet > justify the solution: > > ~~~~~~~~~~~~~ > Consider VPN customer A has 10 sites - siteA1, siteA2...siteA10. > > All the sites need IPv4 any-to-any connectivity, however, only siteA1 > and siteA2 need IPv6 connectivity. > > If the VRF for VPN customer A is configured with the same RT set for > both IPv4 and IPv6 SAFIs on each PE connected to each of 10 sites, then > each PE router ends up with all IPv4 and IPv6 routes related to that > VPN. > > Of course, PEs connected to siteA3,...siteA10 should not care about the > IPv6 routes in that VPN since the sites don't need them. Hence, those > routes become unwanted routes. > ~~~~~~~ > > I don't know if this is how the draft defines the "unwanted routes", but > that's my understanding based on the slides I saw yday. > > Cheers, > Rajiv > > > > -----Original Message----- > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Robert > > Raszuk (raszuk) > > Sent: Tuesday, November 10, 2009 9:17 PM > > To: Jie Dong > > Cc: idr@ietf.org > > Subject: Re: [Idr] Response to comments on generalized RT constrain > solution > > > > Jie, > > > > > But with normal rt-constrain PEs of these sites will receive VPN > > > routes of all these services, including the unwanted ones. > > > > I don't understand the definition of "unwanted routes" in the draft > and > > in your email description. > > > > If RT is assigned that matches the routes they are received and > > accepted. If RT attached to the route is not part of import of any VRF > > of the PE they are dropped today and with rt-constrain will not be > sent. > > > > I really don't see how this is related to SAFIs/services provided. > > > > In fact if you don't have service ABC configured on such PE in > question > > it will not receive any routes either today or with rt-constrain. > Please > > observe that rt-constrain is just a filter not the request for routes. > > > > I think what you are trying to express is to assing on one PE 100:1 > for > > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for > customer > > Y. That would be IMHO a misconfiguration. > > > > Cheers, > > R. > > > > > > > Hi, > > > > > > Thanks for your comments. Please see inline... > > > > > >>> The issue we really concern is that the RTs overlap among > different > > >>> customers. Different VPNs for different customers may be > configiured > > >> to > > >>> used > > >>> same RT, that means the RT of one type of VPN may attracted > unwanted > > >>> routes > > >>> belong to other types of VPNS, and that the RT > > >>> configuration/modification of > > >>> one type VPN may affect the other VPNs that are totally not > relevant > > >> to > > >>> that > > >>> VPN. > > >> I'm not sure I follow your argument. Clearly if we are talking > about > > >> VPNs with the same address family you can't use the same RT for > > >> different VPNs. For a VPN service to operate correctly the > provisioning > > >> mechanism should be able to assign an unique RT per VPN. > > >> > > > Yes, for VPNs with the same AFI/SAFI, different RT should be > assigned for > > > different customers. > > > > > >> Now, even if you had the ability to use the same RT value across > > >> different address families you most likely wouldn't want to use it. > For > > >> example, if customer A has a VPN with v4 service and customer B has > a > > >> VPN with v6 service it would be a *really bad idea* to assign the > same > > >> value to both because A may want to have v6 service in the future > or > > >> vice-versa. > > > What we mean here is for different AFI/SAFIs the allocation of RT > should be > > > able to operate independently. Operators can choose to use same or > different > > > RT for different kinds of VPNs, either for same customer or > different > > > customers. The assignment of RT can be quite flexible. Especially in > > > mutli-ISP scenarios, different ISP may use the same RT for different > kind of > > > VPNs. > > > > > >> The main point here is that in practice RT assignment is not per AF > but > > >> per VPN. That is the reason the rt constraint draft handles the RT > > >> independently of the AF. > > > If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for > these two > > > VPNs are independent, they could use either different RT or same RT > based on > > > the policy of the operator. > > > > > >> It seems to me that attempts to have RT constraint have per AF > semantics > > >> are misguided in the least. A VPN will very likely have multiple > > >> services that use different BGP AFI,SAFIs and while in theory they > could > > >> use multiple RTs there is no practical value in doing so. That > would > > >> result in having to advertise multiple times the same information > when > > >> using rt-constraint > > > Using same RT for multiple services is reasonable, however the sites > may not > > > be identical for all these services. Some sites may only be > interested in > > > some of these services, and more unneeded routes may get their PEs > into > > > trouble. But with normal rt-constrain PEs of these sites will > receive VPN > > > routes of all these services, including the unwanted ones. This can > happen > > > especially during network migration and deployment of new services. > As you > > > said, using different RT is not recommended, and using same RT some > PEs need > > > the ability to notify others only some kind of routes are needed. > > > > > > And as Mach has said before, compared with the quantity of unwanted > routes > > > being advertised, the amount of RT-constrain information can be > ignored. > > > > > >> In my mind, the question we should ask is: would a service provider > use > > >> the same customer id for 2 different customers (even if they have > > >> different services ?). The answer is no. The same way the SP > > >> provisioning system should be able to assign unique RTs per > customer so > > >> that ops can retrieve the customer-id from the RT. > > > Operators can choose how to manage their networks, and also > different > > > operators can choose different ways. IMO we should provide methods > to > > > lighten operators' burden on VPN service provisioning and assure > that > > > different services will not affect each other. > > > > > > Regards > > > Jie > > > > > > > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr > > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr From rajiva@cisco.com Tue Nov 10 22:47:51 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81BE3A698E for ; Tue, 10 Nov 2009 22:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8Durxj2gemA for ; Tue, 10 Nov 2009 22:47:50 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0200B3A68F3 for ; Tue, 10 Nov 2009 22:47:50 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACvt+UqrR7H+/2dsb2JhbADESpg/gj2BfwSBaw X-IronPort-AV: E=Sophos;i="4.44,721,1249257600"; d="scan'208";a="429748476" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2009 06:48:17 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAB6mHl0005756; Wed, 11 Nov 2009 06:48:17 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 00:48:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 00:48:10 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C197CB7@XMB-RCD-111.cisco.com> In-Reply-To: <004d01ca6297$d05e38a0$be125d85@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Response to comments on generalized RT constrain solution Thread-Index: AcpidSJqUsNuengwTDG9EVV9WrJrDAAFTRFgAAMUCUAAAFhoAA== References: <067E6CE33034954AAC05C9EC85E2577C197CA7@XMB-RCD-111.cisco.com> <004d01ca6297$d05e38a0$be125d85@china.huawei.com> From: "Rajiv Asati (rajiva)" To: "Jie Dong" , "Robert Raszuk (raszuk)" X-OriginalArrivalTime: 11 Nov 2009 06:48:15.0626 (UTC) FILETIME=[F1E4A6A0:01CA629A] Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 06:47:51 -0000 Hi Jie, The former scenario is questionable, whereas the latter scenario is invalid. Please see my earlier email and reference to RFC4364 section 4.3.5.=20 Nonetheless, you have brought up a good point that deserves further clarity about different SAFIs per VRF wrt RFC4364, at minimum. Cheers, Rajiv > -----Original Message----- > From: Jie Dong [mailto:dongjie_dj@huawei.com] > Sent: Wednesday, November 11, 2009 1:26 AM > To: Rajiv Asati (rajiva); Robert Raszuk (raszuk) > Cc: idr@ietf.org > Subject: RE: [Idr] Response to comments on generalized RT constrain solution >=20 > Hi, >=20 > Thanks for clarifying this problem, that's one scenario of receiving > "unwanted" (Sorry for confusing on this.) routes: same RT is used by one > customer for different kind of VPNs. And another possible scenario is that > same RT is used by different customer for different kind of VPNs. In both > these cases PEs may receive "unwanted" routes. >=20 >=20 > Jie >=20 >=20 > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: Wednesday, November 11, 2009 3:01 PM > > To: Robert Raszuk (raszuk); Jie Dong > > Cc: idr@ietf.org > > Subject: RE: [Idr] Response to comments on generalized RT constrain > solution > > > > > I don't understand the definition of "unwanted routes" in the draft > > and > > > in your email description. > > > > > > If RT is assigned that matches the routes they are received and > > > accepted. If RT attached to the route is not part of import of any VRF > > > of the PE they are dropped today and with rt-constrain will not be > > sent. > > > > > > I really don't see how this is related to SAFIs/services provided. > > > > Allow me to justify this problem per the draft, though we can't yet > > justify the solution: > > > > ~~~~~~~~~~~~~ > > Consider VPN customer A has 10 sites - siteA1, siteA2...siteA10. > > > > All the sites need IPv4 any-to-any connectivity, however, only siteA1 > > and siteA2 need IPv6 connectivity. > > > > If the VRF for VPN customer A is configured with the same RT set for > > both IPv4 and IPv6 SAFIs on each PE connected to each of 10 sites, then > > each PE router ends up with all IPv4 and IPv6 routes related to that > > VPN. > > > > Of course, PEs connected to siteA3,...siteA10 should not care about the > > IPv6 routes in that VPN since the sites don't need them. Hence, those > > routes become unwanted routes. > > ~~~~~~~ > > > > I don't know if this is how the draft defines the "unwanted routes", but > > that's my understanding based on the slides I saw yday. > > > > Cheers, > > Rajiv > > > > > > > -----Original Message----- > > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > > Robert > > > Raszuk (raszuk) > > > Sent: Tuesday, November 10, 2009 9:17 PM > > > To: Jie Dong > > > Cc: idr@ietf.org > > > Subject: Re: [Idr] Response to comments on generalized RT constrain > > solution > > > > > > Jie, > > > > > > > But with normal rt-constrain PEs of these sites will receive VPN > > > > routes of all these services, including the unwanted ones. > > > > > > I don't understand the definition of "unwanted routes" in the draft > > and > > > in your email description. > > > > > > If RT is assigned that matches the routes they are received and > > > accepted. If RT attached to the route is not part of import of any VRF > > > of the PE they are dropped today and with rt-constrain will not be > > sent. > > > > > > I really don't see how this is related to SAFIs/services provided. > > > > > > In fact if you don't have service ABC configured on such PE in > > question > > > it will not receive any routes either today or with rt-constrain. > > Please > > > observe that rt-constrain is just a filter not the request for routes. > > > > > > I think what you are trying to express is to assing on one PE 100:1 > > for > > > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for > > customer > > > Y. That would be IMHO a misconfiguration. > > > > > > Cheers, > > > R. > > > > > > > > > > Hi, > > > > > > > > Thanks for your comments. Please see inline... > > > > > > > >>> The issue we really concern is that the RTs overlap among > > different > > > >>> customers. Different VPNs for different customers may be > > configiured > > > >> to > > > >>> used > > > >>> same RT, that means the RT of one type of VPN may attracted > > unwanted > > > >>> routes > > > >>> belong to other types of VPNS, and that the RT > > > >>> configuration/modification of > > > >>> one type VPN may affect the other VPNs that are totally not > > relevant > > > >> to > > > >>> that > > > >>> VPN. > > > >> I'm not sure I follow your argument. Clearly if we are talking > > about > > > >> VPNs with the same address family you can't use the same RT for > > > >> different VPNs. For a VPN service to operate correctly the > > provisioning > > > >> mechanism should be able to assign an unique RT per VPN. > > > >> > > > > Yes, for VPNs with the same AFI/SAFI, different RT should be > > assigned for > > > > different customers. > > > > > > > >> Now, even if you had the ability to use the same RT value across > > > >> different address families you most likely wouldn't want to use it. > > For > > > >> example, if customer A has a VPN with v4 service and customer B has > > a > > > >> VPN with v6 service it would be a *really bad idea* to assign the > > same > > > >> value to both because A may want to have v6 service in the future > > or > > > >> vice-versa. > > > > What we mean here is for different AFI/SAFIs the allocation of RT > > should be > > > > able to operate independently. Operators can choose to use same or > > different > > > > RT for different kinds of VPNs, either for same customer or > > different > > > > customers. The assignment of RT can be quite flexible. Especially in > > > > mutli-ISP scenarios, different ISP may use the same RT for different > > kind of > > > > VPNs. > > > > > > > >> The main point here is that in practice RT assignment is not per AF > > but > > > >> per VPN. That is the reason the rt constraint draft handles the RT > > > >> independently of the AF. > > > > If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for > > these two > > > > VPNs are independent, they could use either different RT or same RT > > based on > > > > the policy of the operator. > > > > > > > >> It seems to me that attempts to have RT constraint have per AF > > semantics > > > >> are misguided in the least. A VPN will very likely have multiple > > > >> services that use different BGP AFI,SAFIs and while in theory they > > could > > > >> use multiple RTs there is no practical value in doing so. That > > would > > > >> result in having to advertise multiple times the same information > > when > > > >> using rt-constraint > > > > Using same RT for multiple services is reasonable, however the sites > > may not > > > > be identical for all these services. Some sites may only be > > interested in > > > > some of these services, and more unneeded routes may get their PEs > > into > > > > trouble. But with normal rt-constrain PEs of these sites will > > receive VPN > > > > routes of all these services, including the unwanted ones. This can > > happen > > > > especially during network migration and deployment of new services. > > As you > > > > said, using different RT is not recommended, and using same RT some > > PEs need > > > > the ability to notify others only some kind of routes are needed. > > > > > > > > And as Mach has said before, compared with the quantity of unwanted > > routes > > > > being advertised, the amount of RT-constrain information can be > > ignored. > > > > > > > >> In my mind, the question we should ask is: would a service provider > > use > > > >> the same customer id for 2 different customers (even if they have > > > >> different services ?). The answer is no. The same way the SP > > > >> provisioning system should be able to assign unique RTs per > > customer so > > > >> that ops can retrieve the customer-id from the RT. > > > > Operators can choose how to manage their networks, and also > > different > > > > operators can choose different ways. IMO we should provide methods > > to > > > > lighten operators' burden on VPN service provisioning and assure > > that > > > > different services will not affect each other. > > > > > > > > Regards > > > > Jie > > > > > > > > > > > > _______________________________________________ > > > > Idr mailing list > > > > Idr@ietf.org > > > > https://www.ietf.org/mailman/listinfo/idr > > > > > > > > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Wed Nov 11 04:06:52 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857CB3A6A9F for ; Wed, 11 Nov 2009 04:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msQZJ2+YcVji for ; Wed, 11 Nov 2009 04:06:51 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A5BA93A6AA2 for ; Wed, 11 Nov 2009 04:06:51 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAP82+kpAaHte/2dsb2JhbADEFoEbCAGWeYQ8BIFrew X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="103515207" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2009 12:07:16 +0000 Received: from [10.70.231.33] (tky-vpn-client-231-33.cisco.com [10.70.231.33]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nABC7EED027419; Wed, 11 Nov 2009 12:07:14 GMT Message-ID: <4AFAA8F4.3030907@cisco.com> Date: Wed, 11 Nov 2009 21:07:16 +0900 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mach Chen References: <06c501ca61c7$0d8c86e0$1200a8c0@china.huawei.com> <4AF90CAA.3030700@cisco.com> <4AFA4C20.40604@cisco.com> <3093148F4C884E249316B2EBC9CE9E18@LENOVOmach> In-Reply-To: <3093148F4C884E249316B2EBC9CE9E18@LENOVOmach> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:06:52 -0000 Mach, You are correct that RFC4684 does not support this new RT as proposed by draft-ietf-l3vpn-v6-ext-communities-02. RFC4684 supports what BGP VPN defined by RFC 4364 or any other VPN specification which uses Route Target ext community attribute. That is all what is sufficient to be supported. If we are discussing in particular RFC 4364 it's _normative_ reference explicitly states that Route Target ext community for all possible applications must be supported as defined in RFC 4360. So first I recommend to wait for new version of RFC4364 with new normative reference section which would potentially refer to RFC XYZ which could be perhaps created one day by progressing draft-ietf-l3vpn-v6-ext-communities further. At this point draft-ietf-l3vpn-v6-ext-communities is not applicable to RFC 4364 or any other VPN specification I am aware of. In fact I do not know what draft-ietf-l3vpn-v6-ext-communities is applicable for. Perhaps it's author could clarify this on this list. Cheers, R. > Hi Robert, > > IPv6 address specified RT (length of 20 bytes) is defined in > http://tools.ietf.org/html/draft-ietf-l3vpn-v6-ext-communities-02, and > RFC 4684 does not support this new RT. > > Best regards, > Mach > > -------------------------------------------------- > From: "Robert Raszuk" > Sent: Wednesday, November 11, 2009 1:31 PM > To: "Mach Chen" > Cc: ; "Dong Jie" > Subject: Re: [Idr] Response to comments on generalized RT constrain > solution > >> >>>> > 3. BTW, there is another issue regarding to the length of the RT >>>> > filed, the IPv6 address specified RT is covered in rfc4684. >>>> >>>> Can you clarify what is the issue ? >>> >>> Here is the RT difinition in RFC4684: >>> +-------------------------------+ >>> | origin as (4 octets) | >>> +-------------------------------+ >>> | route target (8 octets) | >>> + + >>> | | >>> +-------------------------------+ >>> >>> There is only 8 octets left for route target. >> >> Why do you need more ? RFC4360 is quite clear on route target format >> and it is 8 octets. >> >> RFC4684 just talks about IPv4 or IPv6 next hops to be used as part of >> MP_REACH_NLRI. That has nothing to do with different RT format. >> >> Cheers, >> R. >> >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From dongjie_dj@huawei.com Wed Nov 11 04:13:01 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B4F28C104 for ; Wed, 11 Nov 2009 04:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgHMFddpXrKM for ; Wed, 11 Nov 2009 04:12:59 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 4A5B13A6774 for ; Wed, 11 Nov 2009 04:12:58 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSY005PW1YB57@usaga01-in.huawei.com> for idr@ietf.org; Wed, 11 Nov 2009 04:13:23 -0800 (PST) Received: from JYS8110164H (host-113-134.meeting.ietf.org [133.93.113.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSY00EIR1Y8G0@usaga01-in.huawei.com> for idr@ietf.org; Wed, 11 Nov 2009 04:13:23 -0800 (PST) Date: Wed, 11 Nov 2009 21:13:33 +0900 From: Jie Dong In-reply-to: <067E6CE33034954AAC05C9EC85E2577C197CA8@XMB-RCD-111.cisco.com> To: "'Rajiv Asati (rajiva)'" , 'Mach Chen' , "'Robert Raszuk (raszuk)'" Message-id: <006a01ca62c8$64f3a1f0$be125d85@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acpih8GPtUdciADQTWmIyE2z9W37fgAAPvtQAAP4kgA= Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:13:01 -0000 Hi Rajiv, > Firstly, assigning the same RT to two different customers' VPN inside > the SP network must be avoided (unless the intent is that two VPNs need > each others' routes). It is indeed a misconfiguration. In fact, this is > explicitly outlined in section 4.3.5 of RFC4364. > > > Then each site is associated with a VRF, a single Route Target > attribute is chosen, that Route Target is assigned to each VRF as > both the Import Target and the Export Target, and that Route Target > is not assigned to any other VRFs as either the Import Target or the > Export Target. > Thanks for the references. IMO, this description is about different customers' VPN of the same address family (because this rfc only describes the procedures of L3VPNv4). But the procedures of RT assignment among different kinds of VPNs are not explicitly described. > > Secondly, assigning the same RT to different (sub) address-families > belonging to the same customer' VPN inside the SP network should not be > permitted unless they result in the congruent topologies. If they don't, > then the customer sites should be perceived to belonging to different > VPNs (one for IPv4 and the other for IPv6, say), requiring two different > RT value(s). > > In the contrary, if each customer site needs both > IPv4 and IPv6 routes, then each site participates > in congruent IPv4 and IPv6 topologies. Hence, same > RT (set) could be utilized in the VRF. > > Unfortunately, RFC4364 is not explicit about this. While one may deduce > the above from the section 4.3.5 of RFC4364, the section 4.3.1 paints a > different picture: > > > > A Route Target attribute can be thought of as identifying a set of > sites. (Though it would be more precise to think of it as > identifying a set of VRFs.) Associating a particular Route Target > attribute with a route allows that route to be placed in the VRFs > that are used for routing traffic that is received from the > corresponding sites. > > > > Unfortunately, the RFC4659 (VPNv6) is moot on this topic. We need to > write a document to clarify this better, I agree that currently there is no clear description on RT assignment among different kinds of VPNs. For this purpose, a document on this topic is good. > otherwise the lack of clarity > on this topic would continue to stir the confusion, resulting in the > undesired proposals and efforts. It depends on whether the requirement is valid or not, and with detailed analysis of the problems, it would make it clearer and may give us more inputs to determine whether the proposals and efforts are needed. Regards Jie > > Cheers, > Rajiv > > > > -----Original Message----- > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Mach > > Chen > > Sent: Tuesday, November 10, 2009 11:30 PM > > To: Robert Raszuk (raszuk); Jie Dong > > Cc: idr@ietf.org > > Subject: Re: [Idr] Response to comments on generalized RT constrain > solution > > > > Hi Robert, > > > > > I think what you are trying to express is to assing on one PE 100:1 > for > > > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for > customer > > > > Exactly, this is one of the issues that may lead to sending/receiving > > unnecessary VPN routes. > > > > > Y. That would be IMHO a misconfiguration. > > > > Why do you think this is misconfiguration? By your logic, does it mean > the > > configuration of one type of VPN will restrict and/or be restricted by > other > > types of VPNs. If things like this, it will affect the flexibility of > the > > deployment/provisioning of VPNs. And that, especially in inter-domain > > scenarios, it may be difficult/impossible to apply this restriction. > > > > > > Best regards, > > Mach > > > > -------------------------------------------------- > > From: "Robert Raszuk" > > Sent: Wednesday, November 11, 2009 10:17 AM > > To: "Jie Dong" > > Cc: "'Pedro Marques (roque)'" ; "'Mach Chen'" > > ; > > Subject: Re: [Idr] Response to comments on generalized RT constrain > solution > > > > > Jie, > > > > > >> But with normal rt-constrain PEs of these sites will receive VPN > > >> routes of all these services, including the unwanted ones. > > > > > > I don't understand the definition of "unwanted routes" in the draft > and in > > > your email description. > > > > > > If RT is assigned that matches the routes they are received and > accepted. > > > If RT attached to the route is not part of import of any VRF of the > PE > > > they are dropped today and with rt-constrain will not be sent. > > > > > > I really don't see how this is related to SAFIs/services provided. > > > > > > In fact if you don't have service ABC configured on such PE in > question it > > > will not receive any routes either today or with rt-constrain. > Please > > > observe that rt-constrain is just a filter not the request for > routes. > > > > > > I think what you are trying to express is to assing on one PE 100:1 > for > > > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for > customer Y. > > > That would be IMHO a misconfiguration. > > > > > > Cheers, > > > R. > > > > > > > > >> Hi, Thanks for your comments. Please see inline... > > >> > > >>>> The issue we really concern is that the RTs overlap among > different > > >>>> customers. Different VPNs for different customers may be > configiured > > >>> to > > >>>> used > > >>>> same RT, that means the RT of one type of VPN may attracted > unwanted > > >>>> routes > > >>>> belong to other types of VPNS, and that the RT > > >>>> configuration/modification of > > >>>> one type VPN may affect the other VPNs that are totally not > relevant > > >>> to > > >>>> that > > >>>> VPN. > > >>> I'm not sure I follow your argument. Clearly if we are talking > about > > >>> VPNs with the same address family you can't use the same RT for > > >>> different VPNs. For a VPN service to operate correctly the > provisioning > > >>> mechanism should be able to assign an unique RT per VPN. > > >>> > > >> Yes, for VPNs with the same AFI/SAFI, different RT should be > assigned for > > >> different customers. > > >>> Now, even if you had the ability to use the same RT value across > > >>> different address families you most likely wouldn't want to use > it. For > > >>> example, if customer A has a VPN with v4 service and customer B > has a > > >>> VPN with v6 service it would be a *really bad idea* to assign the > same > > >>> value to both because A may want to have v6 service in the future > or > > >>> vice-versa. > > >> What we mean here is for different AFI/SAFIs the allocation of RT > should > > >> be > > >> able to operate independently. Operators can choose to use same or > > >> different > > >> RT for different kinds of VPNs, either for same customer or > different > > >> customers. The assignment of RT can be quite flexible. Especially > in > > >> mutli-ISP scenarios, different ISP may use the same RT for > different kind > > >> of > > >> VPNs. > > >> > > >>> The main point here is that in practice RT assignment is not per > AF but > > >>> per VPN. That is the reason the rt constraint draft handles the RT > > >>> independently of the AF. > > >> If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for > these > > >> two > > >> VPNs are independent, they could use either different RT or same RT > based > > >> on > > >> the policy of the operator. > > >>> It seems to me that attempts to have RT constraint have per AF > semantics > > >>> are misguided in the least. A VPN will very likely have multiple > > >>> services that use different BGP AFI,SAFIs and while in theory they > could > > >>> use multiple RTs there is no practical value in doing so. That > would > > >>> result in having to advertise multiple times the same information > when > > >>> using rt-constraint > > >> Using same RT for multiple services is reasonable, however the > sites may > > >> not > > >> be identical for all these services. Some sites may only be > interested in > > >> some of these services, and more unneeded routes may get their PEs > into > > >> trouble. But with normal rt-constrain PEs of these sites will > receive VPN > > >> routes of all these services, including the unwanted ones. This can > > >> happen > > >> especially during network migration and deployment of new services. > As > > >> you > > >> said, using different RT is not recommended, and using same RT some > PEs > > >> need > > >> the ability to notify others only some kind of routes are needed. > > >> > > >> And as Mach has said before, compared with the quantity of unwanted > > >> routes > > >> being advertised, the amount of RT-constrain information can be > ignored. > > >> > > >>> In my mind, the question we should ask is: would a service > provider use > > >>> the same customer id for 2 different customers (even if they have > > >>> different services ?). The answer is no. The same way the SP > > >>> provisioning system should be able to assign unique RTs per > customer so > > >>> that ops can retrieve the customer-id from the RT. > > >> Operators can choose how to manage their networks, and also > different > > >> operators can choose different ways. IMO we should provide methods > to > > >> lighten operators' burden on VPN service provisioning and assure > that > > >> different services will not affect each other. > > >> > > >> Regards > > >> Jie > > >> > > >> > > >> _______________________________________________ > > >> Idr mailing list > > >> Idr@ietf.org > > >> https://www.ietf.org/mailman/listinfo/idr > > >> > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr From raszuk@cisco.com Wed Nov 11 04:25:40 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D9428C20E for ; Wed, 11 Nov 2009 04:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9o-t+BXN36b for ; Wed, 11 Nov 2009 04:25:39 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 80E1C28C104 for ; Wed, 11 Nov 2009 04:25:39 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="48968996" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2009 12:26:06 +0000 Received: from [10.70.231.33] (tky-vpn-client-231-33.cisco.com [10.70.231.33]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nABCQ5tH011879; Wed, 11 Nov 2009 12:26:05 GMT Message-ID: <4AFAAD5F.60406@cisco.com> Date: Wed, 11 Nov 2009 21:26:07 +0900 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jie Dong References: <006a01ca62c8$64f3a1f0$be125d85@china.huawei.com> In-Reply-To: <006a01ca62c8$64f3a1f0$be125d85@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:25:41 -0000 Jie and Rajiv, > I agree that currently there is no clear description on RT assignment > among different kinds of VPNs. For this purpose, a document on this > topic is good. I disagree. RT assignment purposely and not by omission has not been specified by keystroke by the original spec to allow various levels of VPN topology flexibilities. Document on this topic would be as useful as a document on how any ISP should define it's internal BGP policies. Again let me reiterate that this is not up to any equipment vendor to decide if given standard specification they offer is easy to use or not. This is up to the operators' community to voice such concerns and as far as I can tell we have zero prove that what any VPN specification which uses RT based filtering there is any provisioning problem. Cheers, R. > Hi Rajiv, > >> Firstly, assigning the same RT to two different customers' VPN inside >> the SP network must be avoided (unless the intent is that two VPNs need >> each others' routes). It is indeed a misconfiguration. In fact, this is >> explicitly outlined in section 4.3.5 of RFC4364. >> >> >> Then each site is associated with a VRF, a single Route Target >> attribute is chosen, that Route Target is assigned to each VRF as >> both the Import Target and the Export Target, and that Route Target >> is not assigned to any other VRFs as either the Import Target or the >> Export Target. >> > > Thanks for the references. > IMO, this description is about different customers' VPN of the same address > family (because this rfc only describes the procedures of L3VPNv4). But the > procedures of RT assignment among different kinds of VPNs are not explicitly > described. > >> Secondly, assigning the same RT to different (sub) address-families >> belonging to the same customer' VPN inside the SP network should not be >> permitted unless they result in the congruent topologies. If they don't, >> then the customer sites should be perceived to belonging to different >> VPNs (one for IPv4 and the other for IPv6, say), requiring two different >> RT value(s). >> >> In the contrary, if each customer site needs both >> IPv4 and IPv6 routes, then each site participates >> in congruent IPv4 and IPv6 topologies. Hence, same >> RT (set) could be utilized in the VRF. >> >> Unfortunately, RFC4364 is not explicit about this. While one may deduce >> the above from the section 4.3.5 of RFC4364, the section 4.3.1 paints a >> different picture: >> >> >> >> A Route Target attribute can be thought of as identifying a set of >> sites. (Though it would be more precise to think of it as >> identifying a set of VRFs.) Associating a particular Route Target >> attribute with a route allows that route to be placed in the VRFs >> that are used for routing traffic that is received from the >> corresponding sites. >> >> >> >> Unfortunately, the RFC4659 (VPNv6) is moot on this topic. We need to >> write a document to clarify this better, > I agree that currently there is no clear description on RT assignment among > different kinds of VPNs. For this purpose, a document on this topic is good. > >> otherwise the lack of clarity >> on this topic would continue to stir the confusion, resulting in the >> undesired proposals and efforts. > It depends on whether the requirement is valid or not, and with detailed > analysis of the problems, it would make it clearer and may give us more > inputs to determine whether the proposals and efforts are needed. > > > Regards > Jie > >> Cheers, >> Rajiv >> >> >>> -----Original Message----- >>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of >> Mach >>> Chen >>> Sent: Tuesday, November 10, 2009 11:30 PM >>> To: Robert Raszuk (raszuk); Jie Dong >>> Cc: idr@ietf.org >>> Subject: Re: [Idr] Response to comments on generalized RT constrain >> solution >>> Hi Robert, >>> >>>> I think what you are trying to express is to assing on one PE 100:1 >> for >>>> L3VPNs for customer X and on the other PE 100:1 for L2VPNs for >> customer >>> Exactly, this is one of the issues that may lead to sending/receiving >>> unnecessary VPN routes. >>> >>>> Y. That would be IMHO a misconfiguration. >>> Why do you think this is misconfiguration? By your logic, does it mean >> the >>> configuration of one type of VPN will restrict and/or be restricted by >> other >>> types of VPNs. If things like this, it will affect the flexibility of >> the >>> deployment/provisioning of VPNs. And that, especially in inter-domain >>> scenarios, it may be difficult/impossible to apply this restriction. >>> >>> >>> Best regards, >>> Mach >>> >>> -------------------------------------------------- >>> From: "Robert Raszuk" >>> Sent: Wednesday, November 11, 2009 10:17 AM >>> To: "Jie Dong" >>> Cc: "'Pedro Marques (roque)'" ; "'Mach Chen'" >>> ; >>> Subject: Re: [Idr] Response to comments on generalized RT constrain >> solution >>>> Jie, >>>> >>>>> But with normal rt-constrain PEs of these sites will receive VPN >>>>> routes of all these services, including the unwanted ones. >>>> I don't understand the definition of "unwanted routes" in the draft >> and in >>>> your email description. >>>> >>>> If RT is assigned that matches the routes they are received and >> accepted. >>>> If RT attached to the route is not part of import of any VRF of the >> PE >>>> they are dropped today and with rt-constrain will not be sent. >>>> >>>> I really don't see how this is related to SAFIs/services provided. >>>> >>>> In fact if you don't have service ABC configured on such PE in >> question it >>>> will not receive any routes either today or with rt-constrain. >> Please >>>> observe that rt-constrain is just a filter not the request for >> routes. >>>> I think what you are trying to express is to assing on one PE 100:1 >> for >>>> L3VPNs for customer X and on the other PE 100:1 for L2VPNs for >> customer Y. >>>> That would be IMHO a misconfiguration. >>>> >>>> Cheers, >>>> R. >>>> >>>> >>>>> Hi, Thanks for your comments. Please see inline... >>>>> >>>>>>> The issue we really concern is that the RTs overlap among >> different >>>>>>> customers. Different VPNs for different customers may be >> configiured >>>>>> to >>>>>>> used >>>>>>> same RT, that means the RT of one type of VPN may attracted >> unwanted >>>>>>> routes >>>>>>> belong to other types of VPNS, and that the RT >>>>>>> configuration/modification of >>>>>>> one type VPN may affect the other VPNs that are totally not >> relevant >>>>>> to >>>>>>> that >>>>>>> VPN. >>>>>> I'm not sure I follow your argument. Clearly if we are talking >> about >>>>>> VPNs with the same address family you can't use the same RT for >>>>>> different VPNs. For a VPN service to operate correctly the >> provisioning >>>>>> mechanism should be able to assign an unique RT per VPN. >>>>>> >>>>> Yes, for VPNs with the same AFI/SAFI, different RT should be >> assigned for >>>>> different customers. >>>>>> Now, even if you had the ability to use the same RT value across >>>>>> different address families you most likely wouldn't want to use >> it. For >>>>>> example, if customer A has a VPN with v4 service and customer B >> has a >>>>>> VPN with v6 service it would be a *really bad idea* to assign the >> same >>>>>> value to both because A may want to have v6 service in the future >> or >>>>>> vice-versa. >>>>> What we mean here is for different AFI/SAFIs the allocation of RT >> should >>>>> be >>>>> able to operate independently. Operators can choose to use same or >>>>> different >>>>> RT for different kinds of VPNs, either for same customer or >> different >>>>> customers. The assignment of RT can be quite flexible. Especially >> in >>>>> mutli-ISP scenarios, different ISP may use the same RT for >> different kind >>>>> of >>>>> VPNs. >>>>> >>>>>> The main point here is that in practice RT assignment is not per >> AF but >>>>>> per VPN. That is the reason the rt constraint draft handles the RT >>>>>> independently of the AF. >>>>> If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for >> these >>>>> two >>>>> VPNs are independent, they could use either different RT or same RT >> based >>>>> on >>>>> the policy of the operator. >>>>>> It seems to me that attempts to have RT constraint have per AF >> semantics >>>>>> are misguided in the least. A VPN will very likely have multiple >>>>>> services that use different BGP AFI,SAFIs and while in theory they >> could >>>>>> use multiple RTs there is no practical value in doing so. That >> would >>>>>> result in having to advertise multiple times the same information >> when >>>>>> using rt-constraint >>>>> Using same RT for multiple services is reasonable, however the >> sites may >>>>> not >>>>> be identical for all these services. Some sites may only be >> interested in >>>>> some of these services, and more unneeded routes may get their PEs >> into >>>>> trouble. But with normal rt-constrain PEs of these sites will >> receive VPN >>>>> routes of all these services, including the unwanted ones. This can >>>>> happen >>>>> especially during network migration and deployment of new services. >> As >>>>> you >>>>> said, using different RT is not recommended, and using same RT some >> PEs >>>>> need >>>>> the ability to notify others only some kind of routes are needed. >>>>> >>>>> And as Mach has said before, compared with the quantity of unwanted >>>>> routes >>>>> being advertised, the amount of RT-constrain information can be >> ignored. >>>>>> In my mind, the question we should ask is: would a service >> provider use >>>>>> the same customer id for 2 different customers (even if they have >>>>>> different services ?). The answer is no. The same way the SP >>>>>> provisioning system should be able to assign unique RTs per >> customer so >>>>>> that ops can retrieve the customer-id from the RT. >>>>> Operators can choose how to manage their networks, and also >> different >>>>> operators can choose different ways. IMO we should provide methods >> to >>>>> lighten operators' burden on VPN service provisioning and assure >> that >>>>> different services will not affect each other. >>>>> >>>>> Regards >>>>> Jie >>>>> >>>>> >>>>> _______________________________________________ >>>>> Idr mailing list >>>>> Idr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/idr >>>>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From russ@cisco.com Wed Nov 11 16:09:28 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18A03A6926 for ; Wed, 11 Nov 2009 16:09:28 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVybAD7MkciR for ; Wed, 11 Nov 2009 16:09:28 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0EDB63A6808 for ; Wed, 11 Nov 2009 16:09:28 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,726,1249257600"; d="scan'208";a="49087832" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 12 Nov 2009 00:09:55 +0000 Received: from tky-vpn-client-231-154.cisco.com (tky-vpn-client-231-154.cisco.com [10.70.231.154]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAC09s7k027670; Thu, 12 Nov 2009 00:09:54 GMT Message-ID: <4AFB5252.7050301@cisco.com> Date: Thu, 12 Nov 2009 09:09:54 +0900 From: Russ White User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <067E6CE33034954AAC05C9EC85E2577C197CA7@XMB-RCD-111.cisco.com> <004d01ca6297$d05e38a0$be125d85@china.huawei.com> <067E6CE33034954AAC05C9EC85E2577C197CB7@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C197CB7@XMB-RCD-111.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Robert Raszuk \(raszuk\)" , idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 00:09:28 -0000 > Nonetheless, you have brought up a good point that deserves further > clarity about different SAFIs per VRF wrt RFC4364, at minimum. I think it's worthwhile to pursue a bis on 4364 to clarify the usage of the RT to avoid the problem described--although I also think it's pretty much "common sense" to avoid it in the design and operation stages. I don't think we need to change make RT constrain as contained in the presented draft, as this would likely just add more confusion, and probably wouldn't be deployed in the real world, because of the additional configuration overhead involved. Russ From raszuk@cisco.com Wed Nov 11 16:28:39 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5D13A68F4 for ; Wed, 11 Nov 2009 16:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2pzTHyJXqS1 for ; Wed, 11 Nov 2009 16:28:39 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E69C63A67D1 for ; Wed, 11 Nov 2009 16:28:38 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,726,1249257600"; d="scan'208";a="49088966" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 12 Nov 2009 00:29:06 +0000 Received: from [10.70.231.240] (tky-vpn-client-231-240.cisco.com [10.70.231.240]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAC0T5ea002833; Thu, 12 Nov 2009 00:29:05 GMT Message-ID: <4AFB56D0.2040701@cisco.com> Date: Thu, 12 Nov 2009 09:29:04 +0900 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Russ White References: <067E6CE33034954AAC05C9EC85E2577C197CA7@XMB-RCD-111.cisco.com> <004d01ca6297$d05e38a0$be125d85@china.huawei.com> <067E6CE33034954AAC05C9EC85E2577C197CB7@XMB-RCD-111.cisco.com> <4AFB5252.7050301@cisco.com> In-Reply-To: <4AFB5252.7050301@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 00:28:39 -0000 Hi Russ, > I think it's worthwhile to pursue a bis on 4364 to clarify the usage > of the RT to avoid the problem described- Usage of RTs in RFC4364 is very clear. It has been deployed for over 9 years and AFAIK the flexibility RFC4364 leaves as far as RT assignment did not generated any confusion, but allowed different VPN topologies to be build without spelling out each one in the spec. The "problem" described here may come from using RTs between other applications which utilize the same extended community other then 4364 examples: l2vpns, vpls, mvpn etc... So bis on 4364 seems like not right choice at all. On the other hand if 4364 should ever adopt different RT format and specifically IPv6 address specific RT format the bis or new RFC update is required. But that is a separate issue from RT deployment recommendation. Cheers, R. >> Nonetheless, you have brought up a good point that deserves further >> clarity about different SAFIs per VRF wrt RFC4364, at minimum. > > I think it's worthwhile to pursue a bis on 4364 to clarify the usage of > the RT to avoid the problem described--although I also think it's pretty > much "common sense" to avoid it in the design and operation stages. I > don't think we need to change make RT constrain as contained in the > presented draft, as this would likely just add more confusion, and > probably wouldn't be deployed in the real world, because of the > additional configuration overhead involved. > > Russ > > From mach@huawei.com Wed Nov 11 16:54:09 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFA513A68D1 for ; Wed, 11 Nov 2009 16:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbEiw50Pjxfl for ; Wed, 11 Nov 2009 16:54:09 -0800 (PST) Received: from lhrga01-in.huawei.com (lhrga01-in.huawei.com [195.33.106.110]) by core3.amsl.com (Postfix) with ESMTP id E47803A6808 for ; Wed, 11 Nov 2009 16:54:08 -0800 (PST) Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSZ00H9A16QR1@lhrga01-in.huawei.com> for idr@ietf.org; Thu, 12 Nov 2009 00:54:26 +0000 (GMT) Received: from LENOVOmach (host-113-133.meeting.ietf.org [133.93.113.133]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSZ007H416HD9@lhrga01-in.huawei.com> for idr@ietf.org; Thu, 12 Nov 2009 00:54:21 +0000 (GMT) Date: Thu, 12 Nov 2009 08:54:12 +0800 From: Mach Chen In-reply-to: <4AFB56D0.2040701@cisco.com> To: raszuk@cisco.com, Russ White Message-id: Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <067E6CE33034954AAC05C9EC85E2577C197CA7@XMB-RCD-111.cisco.com> <004d01ca6297$d05e38a0$be125d85@china.huawei.com> <067E6CE33034954AAC05C9EC85E2577C197CB7@XMB-RCD-111.cisco.com> <4AFB5252.7050301@cisco.com> <4AFB56D0.2040701@cisco.com> Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Mach Chen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 00:54:09 -0000 Hi Robert, > Usage of RTs in RFC4364 is very clear. It has been deployed for over 9 > years and AFAIK the flexibility RFC4364 leaves as far as RT assignment did > not generated any confusion, but allowed different VPN topologies to be > build without spelling out each one in the spec. If there is no RT-constrain, yes,there will be no any confusion, because the RT space for different AFI/SAFI is actually seperated. The operator could assign RTs freely for a specific VPN without considering(and IMHO, it SHOULD NOT) any other type of VPNs. Otherwise, when configure L3VPN, if you have to consider the underlying confilicts with other type of VPNs, for me, that will be an annoying thing. Best regards, Mach > >>> Nonetheless, you have brought up a good point that deserves further >>> clarity about different SAFIs per VRF wrt RFC4364, at minimum. >> >> I think it's worthwhile to pursue a bis on 4364 to clarify the usage of >> the RT to avoid the problem described--although I also think it's pretty >> much "common sense" to avoid it in the design and operation stages. I >> don't think we need to change make RT constrain as contained in the >> presented draft, as this would likely just add more confusion, and >> probably wouldn't be deployed in the real world, because of the >> additional configuration overhead involved. >> >> Russ >> >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From roque@cisco.com Wed Nov 11 17:18:32 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FADF3A68E9 for ; Wed, 11 Nov 2009 17:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niPS8+WvSzPY for ; Wed, 11 Nov 2009 17:18:31 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A3BF23A6828 for ; Wed, 11 Nov 2009 17:18:31 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,726,1249257600"; d="scan'208";a="430445957" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 12 Nov 2009 01:19:00 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nAC1J0Fk025580; Thu, 12 Nov 2009 01:19:00 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 17:18:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 17:18:58 -0800 Message-ID: <7C53A945334A5E4B87A5B5002F0EB35508BD319B@xmb-sjc-233.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Response to comments on generalized RT constrain solution Thread-Index: AcpjMtcjNgNYap5QRy+EfMqUze8s9gAAU/0g References: <067E6CE33034954AAC05C9EC85E2577C197CA7@XMB-RCD-111.cisco.com><004d01ca6297$d05e38a0$be125d85@china.huawei.com><067E6CE33034954AAC05C9EC85E2577C197CB7@XMB-RCD-111.cisco.com><4AFB5252.7050301@cisco.com> <4AFB56D0.2040701@cisco.com> From: "Pedro Marques (roque)" To: "Mach Chen" , "Robert Raszuk (raszuk)" , "russ (mailer list)" X-OriginalArrivalTime: 12 Nov 2009 01:18:59.0952 (UTC) FILETIME=[1D01C700:01CA6336] Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:18:32 -0000 Mach, >=20 > If there is no RT-constrain, yes,there will be no any confusion, > because the > RT space for different AFI/SAFI is actually seperated. The operator > could > assign RTs freely for a specific VPN without considering(and IMHO, it > SHOULD > NOT) any other type of VPNs. I disagree. There are very strong practical reasons why the operator would want to make sure it can determine the VPN from the RT. VPNs will have different services (e.g. v4/v6/mcast) enabled on them and policy is expressed in terms of VPNs. That includes policy in ASBRs, etc. In practice and operator will want to assign RTs per VPN and not per (AF, VPN). rt-constraint doesn't change this equation a bit. On the other hand I see no harm in an informational document that states that life is much simpler if RTs are assigned per VPN. For instance, that document can state that one of the advantages is that when using RT-constraint a single RT can express the VPN membership. I don't believe this needs to be a "bis". But clarifying this point would be a good thing. I'm sure the question will be posed again. It is the kind of issue that is just bound to be raised periodically. Pedro. From mach@huawei.com Wed Nov 11 17:20:42 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C324F28C16C for ; Wed, 11 Nov 2009 17:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6yPfQtfrUzo for ; Wed, 11 Nov 2009 17:20:42 -0800 (PST) Received: from lhrga01-in.huawei.com (lhrga01-in.huawei.com [195.33.106.110]) by core3.amsl.com (Postfix) with ESMTP id ECCC928C15F for ; Wed, 11 Nov 2009 17:20:41 -0800 (PST) Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSZ00HNH2EYR1@lhrga01-in.huawei.com> for idr@ietf.org; Thu, 12 Nov 2009 01:20:58 +0000 (GMT) Received: from LENOVOmach (host-113-133.meeting.ietf.org [133.93.113.133]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSZ007YX2EPD9@lhrga01-in.huawei.com> for idr@ietf.org; Thu, 12 Nov 2009 01:20:53 +0000 (GMT) Date: Thu, 12 Nov 2009 09:20:43 +0800 From: Mach Chen In-reply-to: <4AFB5252.7050301@cisco.com> To: Russ White , "Rajiv Asati (rajiva)" Message-id: <389F3F537AEC4C16BFDB291667203697@LENOVOmach> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <067E6CE33034954AAC05C9EC85E2577C197CA7@XMB-RCD-111.cisco.com> <004d01ca6297$d05e38a0$be125d85@china.huawei.com> <067E6CE33034954AAC05C9EC85E2577C197CB7@XMB-RCD-111.cisco.com> <4AFB5252.7050301@cisco.com> Cc: "Robert Raszuk \(raszuk\)" , idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Mach Chen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:20:42 -0000 Hi Russ, > I > don't think we need to change make RT constrain as contained in the > presented draft, as this would likely just add more confusion, and > probably wouldn't be deployed in the real world, because of the > additional configuration overhead involved. As said in my previous email, there is actually no confusion before RT-constrian being invented. The purpose of RT-constrain is to limit the unnecessay routes sending/receiving, if many restrictions have to be applied to the designing/operating, the restrictions will reduce the merits of RT-constrain, even more probably make RT-constrain un-deployable. Best regards, Mach > > Russ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From enkechen@cisco.com Thu Nov 12 18:27:48 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7240628C16D for ; Thu, 12 Nov 2009 18:27:48 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MV32NMMaP+-K for ; Thu, 12 Nov 2009 18:27:47 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9F5C328C10F for ; Thu, 12 Nov 2009 18:27:47 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: I-D Action:draft-walton-bgp-route-oscillation-stop-02.txt.eml : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADpT/EqrR7Ht/2dsb2JhbAC9WpgnhDwE X-IronPort-AV: E=Sophos;i="4.44,732,1249257600"; d="eml'208?txt'208,208?scan'208,208,208";a="270540019" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Nov 2009 02:28:17 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAD2SHrs012086 for ; Fri, 13 Nov 2009 02:28:17 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 18:28:17 -0800 Received: from [171.71.139.181] ([171.71.139.181]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 18:28:16 -0800 Message-ID: <4AFCC43D.60509@cisco.com> Date: Thu, 12 Nov 2009 18:28:13 -0800 From: Enke Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: idr Content-Type: multipart/mixed; boundary="------------010206060208010805080405" X-OriginalArrivalTime: 13 Nov 2009 02:28:16.0980 (UTC) FILETIME=[F533A940:01CA6408] Subject: [Idr] [Fwd: I-D Action:draft-walton-bgp-route-oscillation-stop-02.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 02:27:48 -0000 This is a multi-part message in MIME format. --------------010206060208010805080405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. -- Enke --------------010206060208010805080405 Content-Type: message/rfc822; name="I-D Action:draft-walton-bgp-route-oscillation-stop-02.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D Action:draft-walton-bgp-route-oscillation-stop-02.txt.em"; filename*1="l" Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 17:16:01 -0800 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 17:16:00 -0800 Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: draft-walton-bgp-route-oscillation-stop-02.txt : None Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 13 Nov 2009 01:16:00 +0000 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAD1FxwG020927; Fri, 13 Nov 2009 01:15:59 GMT X-from-outside-Cisco: 64.170.98.32 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicBAOJB/EpAqmIgd2dsb2JhbACaWIFBAQwLCAkQCKBtmCaEPAQ X-IronPort-AV: E=Sophos;i="4.44,732,1249257600"; d="txt'208?scan'208,208";a="172512616" Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-a.cisco.com with ESMTP; 13 Nov 2009 01:15:59 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F69F28B56A; Thu, 12 Nov 2009 17:15:08 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DC7B83A69E1; Thu, 12 Nov 2009 17:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-walton-bgp-route-oscillation-stop-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091113011503.DC7B83A69E1@core3.amsl.com> Date: Thu, 12 Nov 2009 17:15:02 -0800 (PST) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org Return-Path: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 13 Nov 2009 01:16:00.0334 (UTC) FILETIME=[DC5BFEE0:01CA63FE] --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Persistent Route Oscillation Solutions Author(s) : D. Walton, et al. Filename : draft-walton-bgp-route-oscillation-stop-02.txt Pages : 9 Date : 2009-11-12 In this document we present two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-induced route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first one, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED- induced route oscillations (subject to certain commonly adopted topological constrains). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-walton-bgp-route-oscillation-stop-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-walton-bgp-route-oscillation-stop-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-12170206.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --NextPart-- --------------010206060208010805080405-- From mikeb@gblx.net Fri Nov 13 09:16:27 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2717C3A6807 for ; Fri, 13 Nov 2009 09:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx6TDLrjXhqB for ; Fri, 13 Nov 2009 09:16:26 -0800 (PST) Received: from pinky.disturbed.org (host-216-9-185-208.orbitelcom.com [216.9.185.208]) by core3.amsl.com (Postfix) with ESMTP id 60A083A6778 for ; Fri, 13 Nov 2009 09:16:25 -0800 (PST) Received: from pinky.disturbed.org (localhost [127.0.0.1]) by pinky.disturbed.org (8.14.3/8.14.3) with ESMTP id nADHGN4s009872; Fri, 13 Nov 2009 10:16:23 -0700 (MST) (envelope-from mikeb@gblx.net) Received: (from mikeb@localhost) by pinky.disturbed.org (8.14.3/8.14.3/Submit) id nADHGMK8009871; Fri, 13 Nov 2009 10:16:22 -0700 (MST) (envelope-from mikeb@gblx.net) X-Authentication-Warning: pinky.disturbed.org: mikeb set sender to mikeb@gblx.net using -f Date: Fri, 13 Nov 2009 10:16:22 -0700 From: Mike Benjamin To: Robert Raszuk Message-ID: <20091113171622.GA9788@gblx.net> References: <003e01ca628d$c4e986f0$be125d85@china.huawei.com> <4AFA4E59.2010008@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AFA4E59.2010008@cisco.com> User-Agent: Mutt/1.4.2.3i Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 17:16:27 -0000 On Wed, Nov 11, 2009 at 02:40:41PM +0900, Robert Raszuk wrote: : Jie, : : >In most networks different : >kind of VPNs are deployed gradually based on the demand of customers. Thus : >it is impossible to make a plan for deployment of all kinds of VPNs at the : >beginning. And this would also affect the flexibility of deployment of new : >VPN services. : : There is many years of operational experience in deployment of various : VPN services today. AFAIK non of the deployments today have found this : to be of any practical issue. : : I think it would be great at this point to hear from operator's : community if they see a recommendation for unique RT assignment for : different customers/services as a problem. The current RT method is the preferable method from our perspective. Even if the possibility to re-use RTs based on AFI existed, we would avoid using it for the sake of our operations teams. To us the RT represents a network, regardless of address type within that network. If that network is IPv4 today and later wants to enable IPv6, we expect it to exist within the same topology. If our customer wants a *different* network topology to exist for the new address family, that is a different network, and now a different RT. >From a design/scale perspective I can see this being slightly useful to preserve memory where the topology does not require a route (read; mixed v4/v6 network, but one PE does not handle any v4 connectivity), but I see this more as a solution looking for a problem than anything. As a service provider, I would not support its introduction. --mikeb : Thx, : R. : _______________________________________________ : Idr mailing list : Idr@ietf.org : https://www.ietf.org/mailman/listinfo/idr -- Mike Benjamin - +1-602-744-3403 mikeb@gblx.net - Development Engineering Global Crossing - Phoenix, USA From Guan.Deng@KabelDeutschland.de Sun Nov 15 15:09:08 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5913A6A33 for ; Sun, 15 Nov 2009 15:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+dohBUSbxFP for ; Sun, 15 Nov 2009 15:09:07 -0800 (PST) Received: from antivir.kabeldeutschland.de (antivir.kabeldeutschland.de [83.169.191.241]) by core3.amsl.com (Postfix) with ESMTP id 950A83A6A26 for ; Sun, 15 Nov 2009 15:09:04 -0800 (PST) Received: from qrz2023.kabeldeutschland.de [10.32.12.99] by antivir.kabeldeutschland.de id UTWJLCGR outgoing id BBKSPDAO; 16 Nov 2009 00:00:47 +0100 Received: from QRZ4283.viola.local (qrz4283.kabeldeutschland.de [10.32.29.50]) by qrz2023.kabeldeutschland.de (8.12.10+Sun/8.12.10) with ESMTP id nAFN4QIR027181; Mon, 16 Nov 2009 00:04:26 +0100 (CET) Received: from QRZ4287.viola.local ([10.32.29.51]) by QRZ4283.viola.local with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 00:08:44 +0100 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_01CA6648.9445CB13" Date: Mon, 16 Nov 2009 00:08:44 +0100 Message-ID: <86F81850BABA434A9E2F6FEF592816E903395FD7@QRZ4287.viola.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Response to comments on generalized RT constrain solution Thread-Index: AcpkhSztZNPC7V5TQZeeb85+gwmLMgBwq1rW References: <003e01ca628d$c4e986f0$be125d85@china.huawei.com><4AFA4E59.2010008@cisco.com> <20091113171622.GA9788@gblx.net> From: "Deng, Guan" To: "Mike Benjamin" , "Robert Raszuk" X-OriginalArrivalTime: 15 Nov 2009 23:08:44.0984 (UTC) FILETIME=[94934B80:01CA6648] Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 23:09:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6648.9445CB13 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert, Mike I agree your opinion, it will confuse our Ops a great deal. Guan -----Original Message----- From: idr-bounces@ietf.org on behalf of Mike Benjamin Sent: Fri 11/13/2009 6:16 PM To: Robert Raszuk Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solut= ion =20 On Wed, Nov 11, 2009 at 02:40:41PM +0900, Robert Raszuk wrote: : Jie, :=20 : >In most networks different : >kind of VPNs are deployed gradually based on the demand of customers. = Thus : >it is impossible to make a plan for deployment of all kinds of VPNs at= the : >beginning. And this would also affect the flexibility of deployment of= new : >VPN services. :=20 : There is many years of operational experience in deployment of various=20 : VPN services today. AFAIK non of the deployments today have found this=20 : to be of any practical issue. :=20 : I think it would be great at this point to hear from operator's=20 : community if they see a recommendation for unique RT assignment for=20 : different customers/services as a problem. The current RT method is the preferable method from our perspective. Even if the possibility to re-use RTs based on AFI existed, we would avoid using it for the sake of our operations teams. To us the RT represents a network, regardless of address type within that network. If that network is IPv4 today and later wants to enable IPv6, we expect it to exist within the same topology. If our customer wants a *different* network topology to exist for the new address family, that is a different network, and now a different RT. >From a design/scale perspective I can see this being slightly useful to preserve memory where the topology does not require a route (read; mixed v4/v6 network, but one PE does not handle any v4 connectivity), but I see this more as a solution looking for a problem than anything. As a service provider, I would not support its introduction. --mikeb =20 : Thx, : R. : _______________________________________________ : Idr mailing list : Idr@ietf.org : https://www.ietf.org/mailman/listinfo/idr -- Mike Benjamin - +1-602-744-3403 mikeb@gblx.net - Development Engineering Global Crossing - Phoenix, USA _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr -- Kabel Deutschland bietet Ihnen Fernsehen, Internet und Telefonie aus eine= r Hand. Informieren Sie sich ueber unsere Produkte unter www.kabeldeutsch= land.de Diese E-Mail und etwaige Anhaenge enthalten vertrauliche und/oder rechtli= ch geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind, = benachrichtigen Sie bitte den Absender und vernichten Sie anschliessend d= iese Mail und die Anlagen. -- Kabel Deutschland GmbH Betastr. 6-8 85774 Unterfoehring Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cub= ero del Castillo-Olivares, Paul Thomason Vorsitzender des Aufsichtsrats: Prof. Dr. Heinz Riesenhuber Handelsregister: Amtsgericht Muenchen HRB 145 837, Sitz der Gesellschaft:= Unterfoehring ------------ Kabel Deutschland Vertrieb und Service GmbH & Co. KG Betastr. 6-8 85774 Unterfoehring Handelsregister: Amtsgericht Muenchen HRA 83902, Sitz der Gesellschaft: U= nterfoehring Komplementaerin: Kabel Deutschland Verwaltungs GmbH, Amtsgericht Muenchen= , HRB 145 835, Sitz der Gesellschaft: Unterfoehring Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cub= ero del Castillo-Olivares, Paul Thomason ------------ Kabel Deutschland Breitband Services GmbH Betastr. 6-8 85774 Unterfoehring Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cub= ero del Castillo-Olivares, Paul Thomason Handelsregister: Amtsgericht Muenchen HRB 122 932, Sitz der Gesellschaft:= Unterfoehring ------------ ------_=_NextPart_001_01CA6648.9445CB13 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Idr] Response to comments on generalized RT constrain solutio= n

Hi Robert, Mike

I agree your opinion, it will confuse our Ops a great deal.

Guan




-----Original Message-----
From: idr-bounces@ietf.org on behalf of Mike Benjamin
Sent: Fri 11/13/2009 6:16 PM
To: Robert Raszuk
Cc: idr@ietf.org
Subject: Re: [Idr] Response to comments on generalized RT constrain solut= ion

On Wed, Nov 11, 2009 at 02:40:41PM +0900, Robert Raszuk wrote:
: Jie,
:
: >In most networks different
: >kind of VPNs are deployed gradually based on the demand of customer= s. Thus
: >it is impossible to make a plan for deployment of all kinds of VPNs= at the
: >beginning. And this would also affect the flexibility of deployment= of new
: >VPN services.
:
: There is many years of operational experience in deployment of various<= BR> : VPN services today. AFAIK non of the deployments today have found this<= BR> : to be of any practical issue.
:
: I think it would be great at this point to hear from operator's
: community if they see a recommendation for unique RT assignment for
: different customers/services as a problem.


The current RT method is the preferable method from our perspective.

Even if the possibility to re-use RTs based on AFI existed, we would
avoid using it for the sake of our operations teams.  To us the RT represents a network, regardless of address type within that network.
If that network is IPv4 today and later wants to enable IPv6, we
expect it to exist within the same topology.  If our customer wants = a
*different* network topology to exist for the new address family,
that is a different network, and now a different RT.

>From a design/scale perspective I can see this being slightly useful
to preserve memory where the topology does not require a route (read;
mixed v4/v6 network, but one PE does not handle any v4 connectivity),
but I see this more as a solution looking for a problem than anything.
As a service provider, I would not support its introduction.

--mikeb



: Thx,
: R.
: _______________________________________________
: Idr mailing list
: Idr@ietf.org
: https://www.ietf.= org/mailman/listinfo/idr

--
Mike Benjamin   -     +1-602-744-3403
mikeb@gblx.net  - Development Engineering
Global Crossing -       Phoenix, USA
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.or= g/mailman/listinfo/idr

--

Kabel Deutschland bietet Ihnen Fernsehen, Internet und Telefonie aus eine= r Hand. Informieren Sie sich ueber unsere Produkte unter www.kabeldeutschland.de
Diese E-Mail und etwaige Anhaenge enthalten vertrauliche und/oder rechtli= ch geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind, = benachrichtigen Sie bitte den Absender und vernichten Sie anschliessend d= iese Mail und die Anlagen.

--

Kabel Deutschland GmbH
Betastr. 6-8
85774 Unterfoehring
Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cub= ero del Castillo-Olivares, Paul Thomason
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinz Riesenhuber
Handelsregister: Amtsgericht Muenchen HRB 145 837, Sitz der Gesellschaft:= Unterfoehring

------------

Kabel Deutschland Vertrieb und Service GmbH & Co. KG
Betastr. 6-8
85774 Unterfoehring
Handelsregister: Amtsgericht Muenchen HRA 83902, Sitz der Gesellschaft: U= nterfoehring
Komplementaerin: Kabel Deutschland Verwaltungs GmbH, Amtsgericht Muenchen= , HRB 145 835, Sitz der Gesellschaft: Unterfoehring
=20 Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cub= ero del Castillo-Olivares, Paul Thomason

------------

Kabel Deutschland Breitband Services GmbH
Betastr. 6-8
85774 Unterfoehring
Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cub= ero del Castillo-Olivares, Paul Thomason
Handelsregister: Amtsgericht Muenchen HRB 122 932, Sitz der Gesellschaft:= Unterfoehring

------------ ------_=_NextPart_001_01CA6648.9445CB13-- From dongjie_dj@huawei.com Tue Nov 17 00:42:42 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114AE3A68B1 for ; Tue, 17 Nov 2009 00:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.99 X-Spam-Level: ** X-Spam-Status: No, score=2.99 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGPoIObSXIoB for ; Tue, 17 Nov 2009 00:42:40 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6E7CE3A6808 for ; Tue, 17 Nov 2009 00:42:40 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KT800L44W4RD4@szxga01-in.huawei.com> for idr@ietf.org; Tue, 17 Nov 2009 16:41:15 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KT800HDYW4QU0@szxga01-in.huawei.com> for idr@ietf.org; Tue, 17 Nov 2009 16:41:15 +0800 (CST) Received: from d65110 ([10.111.12.193]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KT800BYAW4QMR@szxml06-in.huawei.com> for idr@ietf.org; Tue, 17 Nov 2009 16:41:14 +0800 (CST) Date: Tue, 17 Nov 2009 16:41:14 +0800 From: Jie Dong In-reply-to: <86F81850BABA434A9E2F6FEF592816E903395FD7@QRZ4287.viola.local> To: "'Deng, Guan'" , 'Mike Benjamin' , 'Robert Raszuk' Message-id: <040e01ca6761$b90f5980$c10c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_etgNDlnEaEmxFK+KlSNtVA)" Thread-index: AcpkhSztZNPC7V5TQZeeb85+gwmLMgBwq1rWABlEehA= Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 08:42:42 -0000 This is a multi-part message in MIME format. --Boundary_(ID_etgNDlnEaEmxFK+KlSNtVA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Guan & Mike, Thanks for your attention to this topic. I'm not quite sure what the "it" means in your comments. I think some clarification here is needed. Generalized RT-constrain doesn't require any modification to the usage of RT, but only to insure that even without elaborate planning of RT allocation, operators will not encounter problems, such as receiving unneeded VPN routes, or affecting existing networks, which may happen if existing RT-constrain is used. So this generalized RT-constrain will not restrict the behavior of operators, in opposite it will relax the restriction on the planning of different kinds of VPN services, thus could help operators in the deployment of new VPNs. And please note that generalized RT-constrain supports IPv6 address specified RT, which cannot be used with existing RT-constrain. Best regards, Jie _____ From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Deng, Guan Sent: Monday, November 16, 2009 7:09 AM To: Mike Benjamin; Robert Raszuk Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution Hi Robert, Mike I agree your opinion, it will confuse our Ops a great deal. Guan -----Original Message----- From: idr-bounces@ietf.org on behalf of Mike Benjamin Sent: Fri 11/13/2009 6:16 PM To: Robert Raszuk Cc: idr@ietf.org Subject: Re: [Idr] Response to comments on generalized RT constrain solution On Wed, Nov 11, 2009 at 02:40:41PM +0900, Robert Raszuk wrote: : Jie, : : >In most networks different : >kind of VPNs are deployed gradually based on the demand of customers. Thus : >it is impossible to make a plan for deployment of all kinds of VPNs at the : >beginning. And this would also affect the flexibility of deployment of new : >VPN services. : : There is many years of operational experience in deployment of various : VPN services today. AFAIK non of the deployments today have found this : to be of any practical issue. : : I think it would be great at this point to hear from operator's : community if they see a recommendation for unique RT assignment for : different customers/services as a problem. The current RT method is the preferable method from our perspective. Even if the possibility to re-use RTs based on AFI existed, we would avoid using it for the sake of our operations teams. To us the RT represents a network, regardless of address type within that network. If that network is IPv4 today and later wants to enable IPv6, we expect it to exist within the same topology. If our customer wants a *different* network topology to exist for the new address family, that is a different network, and now a different RT. >From a design/scale perspective I can see this being slightly useful to preserve memory where the topology does not require a route (read; mixed v4/v6 network, but one PE does not handle any v4 connectivity), but I see this more as a solution looking for a problem than anything. As a service provider, I would not support its introduction. --mikeb : Thx, : R. : _______________________________________________ : Idr mailing list : Idr@ietf.org : https://www.ietf.org/mailman/listinfo/idr -- Mike Benjamin - +1-602-744-3403 mikeb@gblx.net - Development Engineering Global Crossing - Phoenix, USA _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr -- Kabel Deutschland bietet Ihnen Fernsehen, Internet und Telefonie aus einer Hand. Informieren Sie sich ueber unsere Produkte unter www.kabeldeutschland.de Diese E-Mail und etwaige Anhaenge enthalten vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind, benachrichtigen Sie bitte den Absender und vernichten Sie anschliessend diese Mail und die Anlagen. -- Kabel Deutschland GmbH Betastr. 6-8 85774 Unterfoehring Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero del Castillo-Olivares, Paul Thomason Vorsitzender des Aufsichtsrats: Prof. Dr. Heinz Riesenhuber Handelsregister: Amtsgericht Muenchen HRB 145 837, Sitz der Gesellschaft: Unterfoehring ------------ Kabel Deutschland Vertrieb und Service GmbH & Co. KG Betastr. 6-8 85774 Unterfoehring Handelsregister: Amtsgericht Muenchen HRA 83902, Sitz der Gesellschaft: Unterfoehring Komplementaerin: Kabel Deutschland Verwaltungs GmbH, Amtsgericht Muenchen, HRB 145 835, Sitz der Gesellschaft: Unterfoehring Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero del Castillo-Olivares, Paul Thomason ------------ Kabel Deutschland Breitband Services GmbH Betastr. 6-8 85774 Unterfoehring Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero del Castillo-Olivares, Paul Thomason Handelsregister: Amtsgericht Muenchen HRB 122 932, Sitz der Gesellschaft: Unterfoehring ------------ --Boundary_(ID_etgNDlnEaEmxFK+KlSNtVA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT RE: [Idr] Response to comments on generalized RT constrain solution
Hi Guan & Mike,
 
Thanks for your attention to this topic. I'm not quite sure what the "it" means in your comments. I think some clarification here is needed.
 
Generalized RT-constrain doesn't require any modification to the usage of RT, but only to insure that even without elaborate planning of RT allocation, operators will not encounter problems, such as receiving unneeded VPN routes, or affecting existing networks, which may happen if existing RT-constrain is used.
 
So this generalized RT-constrain will not restrict the behavior of operators, in opposite it will relax the restriction on the planning of different kinds of VPN services, thus could help operators in the deployment of new VPNs.
 
And please note that generalized RT-constrain supports IPv6 address specified RT, which cannot be used with existing RT-constrain.
 

Best regards,
Jie

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Deng, Guan
Sent: Monday, November 16, 2009 7:09 AM
To: Mike Benjamin; Robert Raszuk
Cc: idr@ietf.org
Subject: Re: [Idr] Response to comments on generalized RT constrain solution


Hi Robert, Mike

I agree your opinion, it will confuse our Ops a great deal.

Guan




-----Original Message-----
From: idr-bounces@ietf.org on behalf of Mike Benjamin
Sent: Fri 11/13/2009 6:16 PM
To: Robert Raszuk
Cc: idr@ietf.org
Subject: Re: [Idr] Response to comments on generalized RT constrain solution

On Wed, Nov 11, 2009 at 02:40:41PM +0900, Robert Raszuk wrote:
: Jie,
:
: >In most networks different
: >kind of VPNs are deployed gradually based on the demand of customers. Thus
: >it is impossible to make a plan for deployment of all kinds of VPNs at the
: >beginning. And this would also affect the flexibility of deployment of new
: >VPN services.
:
: There is many years of operational experience in deployment of various
: VPN services today. AFAIK non of the deployments today have found this
: to be of any practical issue.
:
: I think it would be great at this point to hear from operator's
: community if they see a recommendation for unique RT assignment for
: different customers/services as a problem.


The current RT method is the preferable method from our perspective.

Even if the possibility to re-use RTs based on AFI existed, we would
avoid using it for the sake of our operations teams.  To us the RT
represents a network, regardless of address type within that network.
If that network is IPv4 today and later wants to enable IPv6, we
expect it to exist within the same topology.  If our customer wants a
*different* network topology to exist for the new address family,
that is a different network, and now a different RT.

From a design/scale perspective I can see this being slightly useful
to preserve memory where the topology does not require a route (read;
mixed v4/v6 network, but one PE does not handle any v4 connectivity),
but I see this more as a solution looking for a problem than anything.

As a service provider, I would not support its introduction.

--mikeb



: Thx,
: R.
: _______________________________________________
: Idr mailing list
: Idr@ietf.org
: https://www.ietf.org/mailman/listinfo/idr

--
Mike Benjamin   -     +1-602-744-3403
mikeb@gblx.net  - Development Engineering
Global Crossing -       Phoenix, USA
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--

Kabel Deutschland bietet Ihnen Fernsehen, Internet und Telefonie aus einer Hand. Informieren Sie sich ueber unsere Produkte unter www.kabeldeutschland.de
Diese E-Mail und etwaige Anhaenge enthalten vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind, benachrichtigen Sie bitte den Absender und vernichten Sie anschliessend diese Mail und die Anlagen.

--

Kabel Deutschland GmbH
Betastr. 6-8
85774 Unterfoehring
Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero del Castillo-Olivares, Paul Thomason
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinz Riesenhuber
Handelsregister: Amtsgericht Muenchen HRB 145 837, Sitz der Gesellschaft: Unterfoehring

------------

Kabel Deutschland Vertrieb und Service GmbH & Co. KG
Betastr. 6-8
85774 Unterfoehring
Handelsregister: Amtsgericht Muenchen HRA 83902, Sitz der Gesellschaft: Unterfoehring
Komplementaerin: Kabel Deutschland Verwaltungs GmbH, Amtsgericht Muenchen, HRB 145 835, Sitz der Gesellschaft: Unterfoehring
Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero del Castillo-Olivares, Paul Thomason

------------

Kabel Deutschland Breitband Services GmbH
Betastr. 6-8
85774 Unterfoehring
Geschaeftsfuehrer: Dr. Adrian von Hammerstein, Erik Adams, Dr. Manuel Cubero del Castillo-Olivares, Paul Thomason
Handelsregister: Amtsgericht Muenchen HRB 122 932, Sitz der Gesellschaft: Unterfoehring

------------
--Boundary_(ID_etgNDlnEaEmxFK+KlSNtVA)--