RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)

"Tony Li" <> Wed, 03 September 2008 20:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9D963A67DB for <>; Wed, 3 Sep 2008 13:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.723
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MpZMyzv6C1Sf for <>; Wed, 3 Sep 2008 13:11:27 -0700 (PDT)
Received: from ( [IPv6:2001:418:1::62]) by (Postfix) with ESMTP id E696D3A6D58 for <>; Wed, 3 Sep 2008 13:11:22 -0700 (PDT)
Received: from majordom by with local (Exim 4.69 (FreeBSD)) (envelope-from <>) id 1KayUu-0000KT-Jc for; Wed, 03 Sep 2008 19:58:36 +0000
Received: from [] ( by with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <>) id 1KayUq-0000Jz-Ax for; Wed, 03 Sep 2008 19:58:34 +0000
Received: from ([]) by with comcast id ABAC1a00M0FhH24A6KyYbY; Wed, 03 Sep 2008 19:58:32 +0000
Received: from TONYLTM9XP ([]) by 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: <>
From: "Tony Li" <>
To: "'Igor Bryskin'" <>, "'Drake, John E'" <>, "'Yakov Rekhter'" <>, "'Lou Berger'" <>
Cc: "'Yakov Rekhter'" <>, "'Adrian Farrel'" <>, <>, <>
References: <>
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)
Date: Wed, 3 Sep 2008 12:57:57 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AC_01C90DC4.BB9BA2A0"
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AckN9kIr+JcE4iARRnO1al65+4VAbAACL+Zg
Precedence: bulk
List-ID: <>


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