RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
"Tony Li" <tony.li@tony.li> Wed, 03 September 2008 20:11 UTC
Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D963A67DB for <ietfarch-ccamp-archive@core3.amsl.com>; Wed, 3 Sep 2008 13:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.723
X-Spam-Level:
X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 MpZMyzv6C1Sf for <ietfarch-ccamp-archive@core3.amsl.com>; Wed, 3 Sep 2008 13:11:27 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E696D3A6D58 for <ccamp-archive@ietf.org>; Wed, 3 Sep 2008 13:11:22 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KayUu-0000KT-Jc for ccamp-data@psg.com; Wed, 03 Sep 2008 19:58:36 +0000
Received: from [76.96.30.56] (helo=QMTA06.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <tony.li@tony.li>) id 1KayUq-0000Jz-Ax for ccamp@ops.ietf.org; Wed, 03 Sep 2008 19:58:34 +0000
Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id ABAC1a00M0FhH24A6KyYbY; Wed, 03 Sep 2008 19:58:32 +0000
Received: from TONYLTM9XP ([155.53.41.237]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id AKyA1a00c570qEr8UKyCfW; Wed, 03 Sep 2008 19:58:30 +0000
X-Authority-Analysis: v=1.0 c=1 a=0P2359lHxj4A:10 a=krugRf0ugssA:10 a=c-oBEJbvLM7mxdzZayAA:9 a=Zqc249_-pahxbYgCocpBg-w6L7MA:4 a=gJcimI5xSWUA:10 a=d5ueH2sHBxHPe-7eOCMA:9 a=nf-2ecfEtzM8hdZOakQA:7 a=lx58BR5cHtJZi0FYsQ_zsLsftnEA:4 a=AfD3MYMu9mQA:10
Reply-To: tony.li@tony.li
From: Tony Li <tony.li@tony.li>
To: 'Igor Bryskin' <i_bryskin@yahoo.com>, "'Drake, John E'" <John.E.Drake2@boeing.com>, 'Yakov Rekhter' <yakov@juniper.net>, 'Lou Berger' <lberger@labn.net>
Cc: 'Yakov Rekhter' <yakov@juniper.net>, 'Adrian Farrel' <adrian@olddog.co.uk>, ccamp@ops.ietf.org, softwires@ietf.org
References: <679584.43004.qm@web36807.mail.mud.yahoo.com>
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Wed, 03 Sep 2008 12:57:57 -0700
Message-ID: <2DBA1AF00FC94E3EB0B71D96AEF2F6AE@ad.redback.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AC_01C90DC4.BB9BA2A0"
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <679584.43004.qm@web36807.mail.mud.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AckN9kIr+JcE4iARRnO1al65+4VAbAACL+Zg
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
I completely agree with you. By creating overlays I propose to do exactly what you are saying: constrain the topology only to the interested parties. This puts away the scalability concerns but raises the question how bad it is in terms of configuration effort, specifically, how difficult it is to add a new PE (a member of a subset of VPNs). I know that BGP configuration is not exactly automatic either. So how big is the difference in the configuration efforts? I know for a fact that some L1 network operators are interested in L1 VPN application but reluctant to deploy BGP. They do deploy for quite some time already GMPLS based control plane with OSPF-TE. Why in your opinion the multi-instance OSPF solution will not be acceptible for them? Providers are disinclined to have any configuration that scales linearly with the number of VPNs. The higher the complexity of the per-VPN configuration, the higher the work multiplier. Of course, if you really want to advocate building static tunnels for VPNs, one has to wonder why PE's and P's are involved at all. Push the VPN configuration to the CPE and leave the centralized boxes out of the equation entirely. Tony
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Drake, John E
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- RE: [Softwires] BGP TE attr last call by softwire… Tony Li
- Re: [Softwires] BGP TE attr last call by softwire… Lou Berger
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- RE: [Softwires] BGP TE attr last call by softwire… Tony Li
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin
- Re: [Softwires] BGP TE attr last call by softwire… Lou Berger
- Re: [Softwires] BGP TE attr last call by softwire… Adrian Farrel
- Re: [Softwires] BGP TE attr last call by softwire… Igor Bryskin