From exim@www1.ietf.org  Tue May  4 10:12:44 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03311
	for <l3vpn-archive@odin.ietf.org>; Tue, 4 May 2004 10:12:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BL0dn-0006O3-P3
	for l3vpn-archive@odin.ietf.org; Tue, 04 May 2004 10:11:24 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i44EBNDV024551
	for l3vpn-archive@odin.ietf.org; Tue, 4 May 2004 10:11:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BL0ZD-0003ce-AF
	for l3vpn-web-archive@optimus.ietf.org; Tue, 04 May 2004 10:06:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02589
	for <l3vpn-web-archive@ietf.org>; Tue, 4 May 2004 10:06:35 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BL0ZB-0004QY-7G
	for l3vpn-web-archive@ietf.org; Tue, 04 May 2004 10:06:37 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BL0YH-0004Ng-00
	for l3vpn-web-archive@ietf.org; Tue, 04 May 2004 10:05:42 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BL0Xo-0004KY-00
	for l3vpn-web-archive@ietf.org; Tue, 04 May 2004 10:05:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BL0Ss-0007Xx-E2; Tue, 04 May 2004 10:00:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BL0Md-0005xA-1i
	for l3vpn@optimus.ietf.org; Tue, 04 May 2004 09:53:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01692
	for <l3vpn@ietf.org>; Tue, 4 May 2004 09:53:35 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BL0Ma-0003Zc-WC
	for l3vpn@ietf.org; Tue, 04 May 2004 09:53:36 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BL0Ld-0003Vr-00
	for l3vpn@ietf.org; Tue, 04 May 2004 09:52:38 -0400
Received: from [202.54.124.179] (helo=rediffmail.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1BL0Kn-0003Pg-00
	for l3vpn@ietf.org; Tue, 04 May 2004 09:51:45 -0400
Received: (qmail 30040 invoked by uid 510); 4 May 2004 13:09:35 -0000
Date: 4 May 2004 13:09:35 -0000
Message-ID: <20040504130935.30039.qmail@webmail10.rediffmail.com>
Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 04 may 2004 13:09:34 -0000
MIME-Version: 1.0
From: "Karthikeyan Subramaniam" <keyans@rediffmail.com>
Reply-To: "Karthikeyan Subramaniam" <keyans@rediffmail.com>
To: "Anand Oswal" <aoswal@redback.com>
Cc: l3vpn@ietf.org, dasnabendu123@hotmail.com
Subject: Re: Re: draft-ietf-l3vpn-ospf-2547-01.txt query
Content-type: multipart/alternative;
	boundary="Next_1083676174---0-202.54.124.179-30036"
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_MESSAGE,
	MSGID_FROM_MTA_HEADER autolearn=no version=2.60

 This is a multipart mime message


--Next_1083676174---0-202.54.124.179-30036
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0A&nbsp; Anand,<BR>=0A<BR>=0A<BR>=0A&nbsp; Can you produce a scenario (=
in VPN) where and why do we need to distinguish real AS-external routes and=
 external routes generated through standard BGP/OSPF interaction mechanism =
?<BR>=0A<BR>=0Awith regards,<BR>=0AS.Karthikeyan<BR>=0A<BR>=0A<BR>=0AOn Fri=
, 30 Apr 2004 Anand Oswal wrote :<BR>=0A&gt;Karthikeyan,<BR>=0A&gt;<BR>=0A&=
gt;The remote CE routers of the same VPN, need to appear as if they are<BR>=
=0A&gt;part of the same OSPF domain, that is why we carry Type 1,2,3 LSAs<B=
R>=0A&gt;as Type 3.<BR>=0A&gt;<BR>=0A&gt;If you carry all your routes as AS=
 External, how would you know which<BR>=0A&gt;ones<BR>=0A&gt;are the &quot;=
real&quot; Ext routes<BR>=0A&gt;<BR>=0A&gt;Thanks<BR>=0A&gt;Anand<BR>=0A&gt=
;<BR>=0A&gt;Karthikeyan Subramaniam wrote:<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; =
Hello,<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;&nbsp; &nbsp;  As stated in the draft=
 draft-ietf-l3vpn-ospf-2547-01.txt,<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;&nbsp; &=
nbsp; &quot;Per [VPN], the VPN routes are distributed among the PE routers =
by<BR>=0A&gt; &gt;&nbsp; &nbsp; BGP.&nbsp; If the PE uses OSPF to distribut=
e routes to the CE router, the<BR>=0A&gt; &gt;&nbsp; &nbsp; standard proced=
ures governing BGP/OSPF interactions [OSPF] would<BR>=0A&gt; &gt;&nbsp; &nb=
sp; cause routes from one site to be delivered to another as AS-external<BR=
>=0A&gt; &gt;<BR>=0A&gt; &gt;&nbsp; &nbsp; routes (in type 5 LSAs).&nbsp; T=
his is undesirable; it would be much<BR>=0A&gt; &gt;&nbsp; &nbsp; better to=
 deliver such routes in type 3 LSAs (as inter-area routes),<BR>=0A&gt; &gt;=
&nbsp; &nbsp; so that they can be distinguished from any &quot;real&quot; A=
S-external routes<BR>=0A&gt; &gt;&nbsp; &nbsp; that may be circulating in t=
he VPN. (That is, so that they can be<BR>=0A&gt; &gt;&nbsp; &nbsp; distingu=
ished by OSPF from routes which really do not come from<BR>=0A&gt; &gt;&nbs=
p; &nbsp; within the VPN.)&quot;<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;&nbsp; &nbs=
p; So the query is why do we need to distinguish As-external routes from in=
ter-area routes from VPN perspective??? (I guess Type-3 LSAs are generated =
for proper database synchronization from OSPF perspective, is there any oth=
er reason???)<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; Thanks in advance<BR>=0A&gt; =
&gt; S.Karthikeyan<BR>=0A=0A</P>=0A=0A=0A<br>=0A<br><br>=0A<A target=3D"_bl=
ank" HREF=3D"http://clients.rediff.com/signature/track_sig.asp"><IMG SRC=3D=
"http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inb=
ox.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=3D0></a>=0A
--Next_1083676174---0-202.54.124.179-30036
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

 =A0Anand,=0A=0A=0A  Can you produce a scenario (in VPN) where and why do w=
e need to distinguish real AS-external routes and external routes generated=
 through standard BGP/OSPF interaction mechanism ?=0A=0Awith regards,=0AS.K=
arthikeyan=0A=0A=0AOn Fri, 30 Apr 2004 Anand Oswal wrote :=0A>Karthikeyan,=
=0A>=0A>The remote CE routers of the same VPN, need to appear as if they ar=
e=0A>part of the same OSPF domain, that is why we carry Type 1,2,3 LSAs=0A>=
as Type 3.=0A>=0A>If you carry all your routes as AS External, how would yo=
u know which=0A>ones=0A>are the "real" Ext routes=0A>=0A>Thanks=0A>Anand=0A=
>=0A>Karthikeyan Subramaniam wrote:=0A> >=0A> > Hello,=0A> >=0A> >     As s=
tated in the draft draft-ietf-l3vpn-ospf-2547-01.txt,=0A> >=0A> >    "Per [=
VPN], the VPN routes are distributed among the PE routers by=0A> >    BGP. =
 If the PE uses OSPF to distribute routes to the CE router, the=0A> >    st=
andard procedures governing BGP/OSPF interactions [OSPF] would=0A> >    cau=
se routes from one site to be delivered to another as AS-external=0A> >=0A>=
 >    routes (in type 5 LSAs).  This is undesirable; it would be much=0A> >=
    better to deliver such routes in type 3 LSAs (as inter-area routes),=0A=
> >    so that they can be distinguished from any "real" AS-external routes=
=0A> >    that may be circulating in the VPN. (That is, so that they can be=
=0A> >    distinguished by OSPF from routes which really do not come from=
=0A> >    within the VPN.)"=0A> >=0A> >    So the query is why do we need t=
o distinguish As-external routes from inter-area routes from VPN perspectiv=
e??? (I guess Type-3 LSAs are generated for proper database synchronization=
 from OSPF perspective, is there any other reason???)=0A> >=0A> > Thanks in=
 advance=0A> > S.Karthikeyan=0A=0A=0A=0A
--Next_1083676174---0-202.54.124.179-30036--





From exim@www1.ietf.org  Tue May  4 10:50:00 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06153
	for <l3vpn-archive@odin.ietf.org>; Tue, 4 May 2004 10:50:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BL1Bu-0000oW-GH
	for l3vpn-archive@odin.ietf.org; Tue, 04 May 2004 10:46:38 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i44EkccK003121
	for l3vpn-archive@odin.ietf.org; Tue, 4 May 2004 10:46:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BL19Q-0008VP-Qo
	for l3vpn-web-archive@optimus.ietf.org; Tue, 04 May 2004 10:44:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05673
	for <l3vpn-web-archive@ietf.org>; Tue, 4 May 2004 10:44:00 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BL19O-0007D3-Fq
	for l3vpn-web-archive@ietf.org; Tue, 04 May 2004 10:44:02 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BL18b-00076h-00
	for l3vpn-web-archive@ietf.org; Tue, 04 May 2004 10:43:13 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BL17Z-0006zK-00
	for l3vpn-web-archive@ietf.org; Tue, 04 May 2004 10:42:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BL11d-0005sT-GH; Tue, 04 May 2004 10:36:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BL0wR-0004YH-VV
	for l3vpn@optimus.ietf.org; Tue, 04 May 2004 10:30:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04528
	for <l3vpn@ietf.org>; Tue, 4 May 2004 10:30:36 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BL0wP-0005x7-Jw
	for l3vpn@ietf.org; Tue, 04 May 2004 10:30:37 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BL0vW-0005uG-00
	for l3vpn@ietf.org; Tue, 04 May 2004 10:29:43 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BL0vB-0005r4-00
	for l3vpn@ietf.org; Tue, 04 May 2004 10:29:21 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
  by rtp-iport-2.cisco.com with ESMTP; 04 May 2004 07:24:46 -0700
X-BrightmailFiltered: true
Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i44ESmpI028258;
	Tue, 4 May 2004 10:28:49 -0400 (EDT)
Message-Id: <200405041428.i44ESmpI028258@rtp-core-2.cisco.com>
To: "Karthikeyan Subramaniam" <keyans@rediffmail.com>
cc: "Anand Oswal" <aoswal@redback.com>, l3vpn@ietf.org,
        dasnabendu123@hotmail.com
Subject: Re: draft-ietf-l3vpn-ospf-2547-01.txt query 
In-reply-to: Your message of 04 May 2004 13:09:35 -0000.
             <20040504130935.30039.qmail@webmail10.rediffmail.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3
 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 04 May 2004 10:28:48 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60


> So the  query is  why do  we need to  distinguish As-external  routes from
> inter-area routes from VPN perspective???  

- to  ensure  that  the inter-area  routes  are  preferred  by OSPF  to  the
  AS-external routes, if some prefix can be reached either way;

- to  ensure that inter-area routes  via the VPN backbone  are comparable to
  inter-area routes via "backdoors". 





From exim@www1.ietf.org  Wed May  5 06:17:26 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04726
	for <l3vpn-archive@odin.ietf.org>; Wed, 5 May 2004 06:17:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLJPS-00018G-TI
	for l3vpn-archive@odin.ietf.org; Wed, 05 May 2004 06:13:51 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i45ADokF004345
	for l3vpn-archive@odin.ietf.org; Wed, 5 May 2004 06:13:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLJKK-0007Ay-4x
	for l3vpn-web-archive@optimus.ietf.org; Wed, 05 May 2004 06:08:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04263
	for <l3vpn-web-archive@ietf.org>; Wed, 5 May 2004 06:08:28 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLJKG-0003dT-Fj
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 06:08:28 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLJJR-0003Qv-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 06:07:38 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLJIb-0003EQ-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 06:06:45 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLJD5-0004yt-Di; Wed, 05 May 2004 06:01:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLJ5l-0002Hc-Gx
	for l3vpn@optimus.ietf.org; Wed, 05 May 2004 05:53:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03024
	for <l3vpn@ietf.org>; Wed, 5 May 2004 05:53:25 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLJ5h-0000VM-UQ
	for l3vpn@ietf.org; Wed, 05 May 2004 05:53:26 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLJ4k-0000Jo-00
	for l3vpn@ietf.org; Wed, 05 May 2004 05:52:27 -0400
Received: from bay13-f112.bay13.hotmail.com ([64.4.31.112] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLJ4U-00008L-00
	for l3vpn@ietf.org; Wed, 05 May 2004 05:52:10 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 5 May 2004 02:51:41 -0700
Received: from 203.200.20.226 by by13fd.bay13.hotmail.msn.com with HTTP;
	Wed, 05 May 2004 09:51:41 GMT
X-Originating-IP: [203.200.20.226]
X-Originating-Email: [dasnabendu123@hotmail.com]
X-Sender: dasnabendu123@hotmail.com
From: "nabendu das" <dasnabendu123@hotmail.com>
To: erosen@cisco.com
Cc: l3vpn@ietf.org
Subject: draft-ietf-l3vpn-ospf-2547-01.txt Query
Date: Wed, 05 May 2004 15:21:41 +0530
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY13-F112Rqf69aZbL00000ea0@hotmail.com>
X-OriginalArrivalTime: 05 May 2004 09:51:41.0896 (UTC) FILETIME=[915C2C80:01C43286]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA03025
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS 
	autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable


HI
In section 4.1 it is stated --

   1) Every PE attached to a particular OSPF network MUST function as an
   OSPF area 0 router. This allows it to distribute inter-area routes to
   the CE via Type 3 LSAs.

   -- Why PE MUST function as an OSPF area 0 router.... ????
   What is the issue if PE acts as ABR of the area to which PE/CE link=20
belongs and
   distribute inter-area routes to the attached CE via Type 3 LSAs????

   2) If the OSPF domain has any area 0 routers (other than the PE
   routers), then at least one of those MUST be a CE router, and MUST
   have an area 0 link to at least one PE router.

   -- Plz explain the above statement ...Why at least one of those MUST b=
e a=20
CE
   router and why MUST have an area 0 link to at least one PE router????


TIA
Nabendu.

_________________________________________________________________
Sports, sports and more sports! Keep up with all that=92s happening!=20
http://www.msn.co.in/sports/ Stay connected with MSN Sports!





From exim@www1.ietf.org  Wed May  5 07:38:32 2004
Received: from optimus.ietf.org (www.iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08196
	for <l3vpn-archive@odin.ietf.org>; Wed, 5 May 2004 07:38:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLKiW-0007k1-EM
	for l3vpn-archive@odin.ietf.org; Wed, 05 May 2004 07:37:36 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Bbavu029750
	for l3vpn-archive@odin.ietf.org; Wed, 5 May 2004 07:37:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLKgX-000743-Gn
	for l3vpn-web-archive@optimus.ietf.org; Wed, 05 May 2004 07:35:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08073
	for <l3vpn-web-archive@ietf.org>; Wed, 5 May 2004 07:35:32 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLKgW-0006kl-SO
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 07:35:32 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLKfb-0006Y2-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 07:34:36 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLKfM-0006LU-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 07:34:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLKcA-0005bV-FJ; Wed, 05 May 2004 07:31:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLKal-0005H8-Us
	for l3vpn@optimus.ietf.org; Wed, 05 May 2004 07:29:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07779
	for <l3vpn@ietf.org>; Wed, 5 May 2004 07:29:34 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLKal-0005K2-BO
	for l3vpn@ietf.org; Wed, 05 May 2004 07:29:35 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLKZn-000568-00
	for l3vpn@ietf.org; Wed, 05 May 2004 07:28:35 -0400
Received: from [202.54.124.152] (helo=rediffmail.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1BLKYx-0004fy-00
	for l3vpn@ietf.org; Wed, 05 May 2004 07:27:44 -0400
Received: (qmail 16776 invoked by uid 510); 5 May 2004 11:27:08 -0000
Date: 5 May 2004 11:27:08 -0000
Message-ID: <20040505112708.16775.qmail@webmail7.rediffmail.com>
Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 05 may 2004 11:27:08 -0000
MIME-Version: 1.0
From: "Karthikeyan Subramaniam" <keyans@rediffmail.com>
Reply-To: "Karthikeyan Subramaniam" <keyans@rediffmail.com>
To: l3vpn@ietf.org
Cc: dasnabendu123@hotmail.com, "Anand Oswal" <aoswal@redback.com>
Subject: Re: Re: Re: draft-ietf-l3vpn-ospf-2547-01.txt query
Content-type: multipart/alternative;
	boundary="Next_1083756428---0-202.54.124.152-16760"
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_MESSAGE,
	MSGID_FROM_MTA_HEADER autolearn=no version=2.60

 This is a multipart mime message


--Next_1083756428---0-202.54.124.152-16760
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0A Hello,<BR>=0A<BR>=0ACan anybody in the list help me&nbsp; in produci=
ng a scenario (in VPN) where and why do we need to distinguish real AS-exte=
rnal routes and external routes generated through standard BGP/OSPF interac=
tion mechanism ?<BR>=0A<BR>=0AThanks in advance.<BR>=0AWith regards,<BR>=0A=
S.Karthikeyan<BR>=0A<BR>=0AOn Tue, 04 May 2004 Karthikeyan Subramaniam wrot=
e :<BR>=0A&gt;&nbsp; =A0Anand,<BR>=0A&gt;<BR>=0A&gt;<BR>=0A&gt;&nbsp;  Can =
you produce a scenario (in VPN) where and why do we need to distinguish rea=
l AS-external routes and external routes generated through standard BGP/OSP=
F interaction mechanism ?<BR>=0A&gt;<BR>=0A&gt;with regards,<BR>=0A&gt;S.Ka=
rthikeyan<BR>=0A&gt;<BR>=0A&gt;<BR>=0A&gt;On Fri, 30 Apr 2004 Anand Oswal w=
rote :<BR>=0A&gt; &gt;Karthikeyan,<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;The remot=
e CE routers of the same VPN, need to appear as if they are<BR>=0A&gt; &gt;=
part of the same OSPF domain, that is why we carry Type 1,2,3 LSAs<BR>=0A&g=
t; &gt;as Type 3.<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;If you carry all your rout=
es as AS External, how would you know which<BR>=0A&gt; &gt;ones<BR>=0A&gt; =
&gt;are the &quot;real&quot; Ext routes<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;Than=
ks<BR>=0A&gt; &gt;Anand<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;Karthikeyan Subraman=
iam wrote:<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt; Hello,<BR>=0A&gt; &gt;=
 &gt;<BR>=0A&gt; &gt; &gt;&nbsp; &nbsp;  As stated in the draft draft-ietf-=
l3vpn-ospf-2547-01.txt,<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt;&nbsp; &nb=
sp; &quot;Per [VPN], the VPN routes are distributed among the PE routers by=
<BR>=0A&gt; &gt; &gt;&nbsp; &nbsp; BGP.&nbsp; If the PE uses OSPF to distri=
bute routes to the CE router, the<BR>=0A&gt; &gt; &gt;&nbsp; &nbsp; standar=
d procedures governing BGP/OSPF interactions [OSPF] would<BR>=0A&gt; &gt; &=
gt;&nbsp; &nbsp; cause routes from one site to be delivered to another as A=
S-external<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt;&nbsp; &nbsp; routes (i=
n type 5 LSAs).&nbsp; This is undesirable; it would be much<BR>=0A&gt; &gt;=
 &gt;&nbsp; &nbsp; better to deliver such routes in type 3 LSAs (as inter-a=
rea routes),<BR>=0A&gt; &gt; &gt;&nbsp; &nbsp; so that they can be distingu=
ished from any &quot;real&quot; AS-external routes<BR>=0A&gt; &gt; &gt;&nbs=
p; &nbsp; that may be circulating in the VPN. (That is, so that they can be=
<BR>=0A&gt; &gt; &gt;&nbsp; &nbsp; distinguished by OSPF from routes which =
really do not come from<BR>=0A&gt; &gt; &gt;&nbsp; &nbsp; within the VPN.)&=
quot;<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt;&nbsp; &nbsp; So the query i=
s why do we need to distinguish As-external routes from inter-area routes f=
rom VPN perspective??? (I guess Type-3 LSAs are generated for proper databa=
se synchronization from OSPF perspective, is there any other reason???)<BR>=
=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt; Thanks in advance<BR>=0A&gt; &gt; &g=
t; S.Karthikeyan<BR>=0A&gt;<BR>=0A&gt;<BR>=0A&gt;<BR>=0A=0A</P>=0A=0A=0A<br=
>=0A<br><br>=0A<A target=3D"_blank" HREF=3D"http://clients.rediff.com/signa=
ture/track_sig.asp"><IMG SRC=3D"http://ads.rediff.com/RealMedia/ads/adstrea=
m_nx.cgi/www.rediffmail.com/inbox.htm@Bottom" BORDER=3D0 VSPACE=3D0 HSPACE=
=3D0></a>=0A
--Next_1083756428---0-202.54.124.152-16760
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

 Hello,=0A=0ACan anybody in the list help me  in producing a scenario (in V=
PN) where and why do we need to distinguish real AS-external routes and ext=
ernal routes generated through standard BGP/OSPF interaction mechanism ?=0A=
=0AThanks in advance.=0AWith regards,=0AS.Karthikeyan=0A=0AOn Tue, 04 May 2=
004 Karthikeyan Subramaniam wrote :=0A>  =A0Anand,=0A>=0A>=0A>   Can you pr=
oduce a scenario (in VPN) where and why do we need to distinguish real AS-e=
xternal routes and external routes generated through standard BGP/OSPF inte=
raction mechanism ?=0A>=0A>with regards,=0A>S.Karthikeyan=0A>=0A>=0A>On Fri=
, 30 Apr 2004 Anand Oswal wrote :=0A> >Karthikeyan,=0A> >=0A> >The remote C=
E routers of the same VPN, need to appear as if they are=0A> >part of the s=
ame OSPF domain, that is why we carry Type 1,2,3 LSAs=0A> >as Type 3.=0A> >=
=0A> >If you carry all your routes as AS External, how would you know which=
=0A> >ones=0A> >are the "real" Ext routes=0A> >=0A> >Thanks=0A> >Anand=0A> =
>=0A> >Karthikeyan Subramaniam wrote:=0A> > >=0A> > > Hello,=0A> > >=0A> > =
>     As stated in the draft draft-ietf-l3vpn-ospf-2547-01.txt,=0A> > >=0A>=
 > >    "Per [VPN], the VPN routes are distributed among the PE routers by=
=0A> > >    BGP.  If the PE uses OSPF to distribute routes to the CE router=
, the=0A> > >    standard procedures governing BGP/OSPF interactions [OSPF]=
 would=0A> > >    cause routes from one site to be delivered to another as =
AS-external=0A> > >=0A> > >    routes (in type 5 LSAs).  This is undesirabl=
e; it would be much=0A> > >    better to deliver such routes in type 3 LSAs=
 (as inter-area routes),=0A> > >    so that they can be distinguished from =
any "real" AS-external routes=0A> > >    that may be circulating in the VPN=
. (That is, so that they can be=0A> > >    distinguished by OSPF from route=
s which really do not come from=0A> > >    within the VPN.)"=0A> > >=0A> > =
>    So the query is why do we need to distinguish As-external routes from =
inter-area routes from VPN perspective??? (I guess Type-3 LSAs are generate=
d for proper database synchronization from OSPF perspective, is there any o=
ther reason???)=0A> > >=0A> > > Thanks in advance=0A> > > S.Karthikeyan=0A>=
=0A>=0A>=0A=0A=0A=0A
--Next_1083756428---0-202.54.124.152-16760--





From exim@www1.ietf.org  Wed May  5 11:01:05 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18487
	for <l3vpn-archive@odin.ietf.org>; Wed, 5 May 2004 11:01:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLNc2-00016r-BP
	for l3vpn-archive@odin.ietf.org; Wed, 05 May 2004 10:43:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Eh6KF004265
	for l3vpn-archive@odin.ietf.org; Wed, 5 May 2004 10:43:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLNVz-0007Id-Bz
	for l3vpn-web-archive@optimus.ietf.org; Wed, 05 May 2004 10:36:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16656
	for <l3vpn-web-archive@ietf.org>; Wed, 5 May 2004 10:36:47 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLNVw-0001dI-VU
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 10:36:49 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLNV1-0001OM-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 10:35:51 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLNUF-00019O-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 10:35:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLNGs-0002Vv-RW; Wed, 05 May 2004 10:21:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLNFT-0001pc-Qr
	for l3vpn@optimus.ietf.org; Wed, 05 May 2004 10:19:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15589
	for <l3vpn@ietf.org>; Wed, 5 May 2004 10:19:43 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLNFQ-0005Jq-Gv
	for l3vpn@ietf.org; Wed, 05 May 2004 10:19:44 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLNEO-000562-00
	for l3vpn@ietf.org; Wed, 05 May 2004 10:18:40 -0400
Received: from bay13-f3.bay13.hotmail.com ([64.4.31.3] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLNE5-0004sI-00
	for l3vpn@ietf.org; Wed, 05 May 2004 10:18:22 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 5 May 2004 07:17:51 -0700
Received: from 203.200.20.226 by by13fd.bay13.hotmail.msn.com with HTTP;
	Wed, 05 May 2004 14:17:51 GMT
X-Originating-IP: [203.200.20.226]
X-Originating-Email: [dasnabendu123@hotmail.com]
X-Sender: dasnabendu123@hotmail.com
From: "nabendu das" <dasnabendu123@hotmail.com>
To: dasnabendu123@hotmail.com, erosen@cisco.com
Cc: l3vpn@ietf.org
Subject: How data packets are forwarded  through sham link
Date: Wed, 05 May 2004 19:47:51 +0530
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY13-F3vlZGdOZofu4000014fe@hotmail.com>
X-OriginalArrivalTime: 05 May 2004 14:17:51.0492 (UTC) FILETIME=[BFFB2440:01C432AB]
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS 
	autolearn=no version=2.60



HI

Cosidering the scenario below, how data packets will be forwarded through 
sham link


H1 
------------CE1----------PE1-----------P---------------P-------------PE2--------------CE2


sham link endpoint addresses are 10.1.1.1 at PE1 and 10.2.2.2 at PE2. and 
lets say PE/CE
links are attached to VRF A. and H1 IP address is 30.30.30.30



IF CE2 wants to forward packet to host H1, it will forward to PE2 by LPM 
lookup.
Now PE2 will look into VRF A for 30.30.30.30 and find sham link endpoint 
address (10.1.1.1) at PE1
as next-hop.  Then PE2 should look for 10.1.1.1 in the VRF and find BGP 
next-hop and label for 10.1.1.1   Next PE2 will find the MPLS tunnel for the 
BGP next-hop and then forward the packet via the tunnel by encapsulating the 
packet with the BGP label and then MPLS label.


PLZ correct me if my understanding is wrong.....

TIA
Nabendu.

_________________________________________________________________
Post Classifieds on MSN classifieds. http://go.msnserver.com/IN/44045.asp 
Buy and Sell on MSN Classifieds.





From exim@www1.ietf.org  Wed May  5 11:23:33 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20580
	for <l3vpn-archive@odin.ietf.org>; Wed, 5 May 2004 11:23:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLO4b-0006rA-5W
	for l3vpn-archive@odin.ietf.org; Wed, 05 May 2004 11:12:37 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i45FCbd4026357
	for l3vpn-archive@odin.ietf.org; Wed, 5 May 2004 11:12:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLNwH-00014y-A9
	for l3vpn-web-archive@optimus.ietf.org; Wed, 05 May 2004 11:04:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18759
	for <l3vpn-web-archive@ietf.org>; Wed, 5 May 2004 11:03:57 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLNwE-0001UB-Oj
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 11:03:58 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLNvV-0001Dr-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 11:03:14 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLNuk-0000vY-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 11:02:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLNgn-0002g8-PS; Wed, 05 May 2004 10:48:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLNWz-0007dk-G8
	for l3vpn@optimus.ietf.org; Wed, 05 May 2004 10:37:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16738
	for <l3vpn@ietf.org>; Wed, 5 May 2004 10:37:49 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLNWx-0001tr-6Q
	for l3vpn@ietf.org; Wed, 05 May 2004 10:37:51 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLNWA-0001f6-00
	for l3vpn@ietf.org; Wed, 05 May 2004 10:37:03 -0400
Received: from bay13-f63.bay13.hotmail.com ([64.4.31.63] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLNVY-0001Op-00
	for l3vpn@ietf.org; Wed, 05 May 2004 10:36:24 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 5 May 2004 07:35:53 -0700
Received: from 203.200.20.226 by by13fd.bay13.hotmail.msn.com with HTTP;
	Wed, 05 May 2004 14:35:53 GMT
X-Originating-IP: [203.200.20.226]
X-Originating-Email: [dasnabendu123@hotmail.com]
X-Sender: dasnabendu123@hotmail.com
From: "nabendu das" <dasnabendu123@hotmail.com>
To: erosen@cisco.com
Cc: l3vpn@ietf.org
Subject: How manual configuration is done for sham link
Date: Wed, 05 May 2004 20:05:53 +0530
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY13-F63l4maEqxGGm00001582@hotmail.com>
X-OriginalArrivalTime: 05 May 2004 14:35:53.0314 (UTC) FILETIME=[44CC1420:01C432AE]
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS 
	autolearn=no version=2.60



HI

Cosidering the scenario below, how data packets will be forwarded
through sham link


H1 
------------CE1----------PE1-----------P---------------P-------------PE2--------------CE2


A) AUTO-configuration:
PE1 will distribute its sham link endpoint address(10.1.1.1) at PE1 as 
VPN-IPV4 route through BGP along with BGP next-hop and label L1. So PE2 will 
have a routing entry at its VRF for 10.1.1.1 with BGP next-hop and label. So 
while forwarding packet to H1, it will find 10.1.1.1 as next-hop and for 
10.1.1.1 it will find the BGP next-hop and ..it will find the tunnel to that 
BGP next-hop and packet can be forwarded through the tunnel after 
encapsulating the packet with L1 and tunnel first next-hop label.


B) MANUAL configuration:
PE1 and PE2 both will be configured with sham link endpoint address as 
10.1.1.1 and 10.2.2.2 ..
But there will be no route at PE2 for PE1 endpoint address i.e 10.1.1. (as 
we are manually configuring, VPN-IPV4 route for 10.1.1.1 will not be 
advertised via BGP to PE2).... So when we do manual configuration for sham 
link , how sham link will be up and how data packets will be forwarded 
through sham link ???????


TIA
Nabendu

_________________________________________________________________
Best of Indian handicrafts. 
http://www.fabmall.com/affiliatehtml/redir/nl8.asp At MSN Shopping.





From exim@www1.ietf.org  Wed May  5 11:35:59 2004
Received: from optimus.ietf.org (www.iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21417
	for <l3vpn-archive@odin.ietf.org>; Wed, 5 May 2004 11:35:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLOFa-00031l-FY
	for l3vpn-archive@odin.ietf.org; Wed, 05 May 2004 11:23:58 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i45FNwoY011633
	for l3vpn-archive@odin.ietf.org; Wed, 5 May 2004 11:23:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLODX-0001QC-Mn
	for l3vpn-web-archive@optimus.ietf.org; Wed, 05 May 2004 11:21:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20489
	for <l3vpn-web-archive@ietf.org>; Wed, 5 May 2004 11:21:49 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLODW-0006XF-SQ
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 11:21:50 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLOCW-0006Hy-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 11:20:49 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLOC6-00063A-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 11:20:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLNxM-0001O7-Ug; Wed, 05 May 2004 11:05:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLNmg-0005Mm-Iv
	for l3vpn@optimus.ietf.org; Wed, 05 May 2004 10:54:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17745
	for <l3vpn@ietf.org>; Wed, 5 May 2004 10:54:02 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLNme-0006CZ-2U
	for l3vpn@ietf.org; Wed, 05 May 2004 10:54:04 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLNlh-0005tn-00
	for l3vpn@ietf.org; Wed, 05 May 2004 10:53:06 -0400
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLNkl-0005bF-00
	for l3vpn@ietf.org; Wed, 05 May 2004 10:52:07 -0400
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP
	id 388F2876D70; Wed,  5 May 2004 07:52:03 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1])
 by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 18301-05; Wed,  5 May 2004 07:52:03 -0700 (PDT)
Received: from malt (malt.redback.com [155.53.12.41])
	by prattle.redback.com (Postfix) with ESMTP
	id F2EA4876D65; Wed,  5 May 2004 07:52:02 -0700 (PDT)
Date: Wed, 5 May 2004 07:52:02 -0700 (PDT)
From: Anand Oswal <aoswal@redback.com>
X-Sender: aoswal@malt
To: nabendu das <dasnabendu123@hotmail.com>
Cc: erosen@cisco.com, l3vpn@ietf.org
Subject: Re: How manual configuration is done for sham link
In-Reply-To: <BAY13-F63l4maEqxGGm00001582@hotmail.com>
Message-ID: <Pine.GSO.4.10.10405050744390.13090-100000@malt>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at redback.com
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

Hi,

The sham link end point will be  a  loopback interface (usually)
associated with your VRF.
For manual config you will need to explicitly specify the endpoint
for the sham link.

You can use BGP to carry this address to the remote PE VRF.

So in your example below.
on PE1, you will have a manual config to specify
10.1.1.1 sham-source 
10.1.1.2 sham-endpoint

Hope that helps.
Thanks
Anand



On Wed, 5 May 2004, nabendu das wrote:

> 
> 
> HI
> 
> Cosidering the scenario below, how data packets will be forwarded
> through sham link
> 
> 
> H1 
> ------------CE1----------PE1-----------P---------------P-------------PE2--------------CE2
> 
> 
> A) AUTO-configuration:
> PE1 will distribute its sham link endpoint address(10.1.1.1) at PE1 as 
> VPN-IPV4 route through BGP along with BGP next-hop and label L1. So PE2 will 
> have a routing entry at its VRF for 10.1.1.1 with BGP next-hop and label. So 
> while forwarding packet to H1, it will find 10.1.1.1 as next-hop and for 
> 10.1.1.1 it will find the BGP next-hop and ..it will find the tunnel to that 
> BGP next-hop and packet can be forwarded through the tunnel after 
> encapsulating the packet with L1 and tunnel first next-hop label.
> 
> 
> B) MANUAL configuration:
> PE1 and PE2 both will be configured with sham link endpoint address as 
> 10.1.1.1 and 10.2.2.2 ..
> But there will be no route at PE2 for PE1 endpoint address i.e 10.1.1. (as 
> we are manually configuring, VPN-IPV4 route for 10.1.1.1 will not be 
> advertised via BGP to PE2).... So when we do manual configuration for sham 
> link , how sham link will be up and how data packets will be forwarded 
> through sham link ???????
> 
> 
> TIA
> Nabendu
> 
> _________________________________________________________________
> Best of Indian handicrafts. 
> http://www.fabmall.com/affiliatehtml/redir/nl8.asp At MSN Shopping.
> 
> 





From exim@www1.ietf.org  Wed May  5 14:15:34 2004
Received: from optimus.ietf.org (www.iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01588
	for <l3vpn-archive@odin.ietf.org>; Wed, 5 May 2004 14:15:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLQoM-0003Uz-Lv
	for l3vpn-archive@odin.ietf.org; Wed, 05 May 2004 14:08:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i45I82RA013436
	for l3vpn-archive@odin.ietf.org; Wed, 5 May 2004 14:08:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLQgP-0007jp-Ep
	for l3vpn-web-archive@optimus.ietf.org; Wed, 05 May 2004 13:59:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00240
	for <l3vpn-web-archive@ietf.org>; Wed, 5 May 2004 13:59:46 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLQgN-0002oA-4k
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 13:59:47 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLQdu-00026R-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 13:57:15 -0400
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLQc3-0001a0-00
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 13:55:19 -0400
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1BLQc4-0007MT-R9
	for l3vpn-web-archive@ietf.org; Wed, 05 May 2004 13:55:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLQYs-0004e6-RY; Wed, 05 May 2004 13:52:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLQPD-0000pB-9G
	for l3vpn@optimus.ietf.org; Wed, 05 May 2004 13:42:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28393
	for <l3vpn@ietf.org>; Wed, 5 May 2004 13:42:00 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLQPA-0005Mt-R4
	for l3vpn@ietf.org; Wed, 05 May 2004 13:42:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLQMe-0004ZV-00
	for l3vpn@ietf.org; Wed, 05 May 2004 13:39:25 -0400
Received: from mailgate1b.savvis.net ([216.91.182.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLQLh-0004FC-00
	for l3vpn@ietf.org; Wed, 05 May 2004 13:38:25 -0400
Received: from sl6exch3.savvis.ad.savvis.net (sl6exch3.it.savvis.net [10.12.134.21])
	by mailgate1b.savvis.net (8.12.10/8.12.1) with ESMTP id i45HYp5K025273;
	Wed, 5 May 2004 12:34:51 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
Date: Wed, 5 May 2004 12:34:11 -0500
Message-ID: <51909D9AC2941E4F9D35B264D12CD7C20A5D3325@sl6exch3.savvis.ad.savvis.net>
Thread-Topic: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
Thread-Index: AcQouRld7AQm/s0YTJadBX7bg0c8UgKC8t4A
From: "Schliesser, Benson" <benson.schliesser@savvis.net>
To: <l3vpn@ietf.org>, <hbrahim@nortelnetworks.com>, <erosen@cisco.com>,
        <yakov@juniper.net>
X-ECS-MailScanner: No virus is found
Content-Transfer-Encoding: quoted-printable
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable


Just a couple comments, for wg-last-call, regarding
draft-ietf-l3vpn-bgpvpn-auto-03.

Section 4.2.2 introduces a new extended community for signaling a VR's
role in the VPN topology. It should be stated more clearly (assuming
I've inferred correctly) that spokes connect to hubs and vice versa, and
meshes connect to each other. Further, the draft should address the
situation where hub, spoke, and mesh VRs all coexist in the same VPN.
One might argue that this is a misconfiguration, but I'd propose that
mesh sites should connect to each other and to hubs while spokes only
connect to hubs, etc.

Section 6 addresses tunnel discovery, and recommends tunneling
mechanisms with demultiplexing capabilities. The draft should either
discuss or point to discussion of how the multiplex keys get
distributed/determined. (it's clear for MPLS, but less so for other
protocols; i.e., IKE, NLRI-encoded, ext community, etc? I know of
implementations that exist, but not necessarily specifications...)

Thanks,
-Benson


> -----Original Message-----
> From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On=20
> Behalf Of Ross Callon
> Sent: Thursday, April 22, 2004 4:43 PM
> To: l3vpn@ietf.org
> Subject: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
>=20
> This begins working group last call on=20
> draft-ietf-l3vpn-bgpvpn-auto-03.txt.
> The last call will terminate two weeks from tomorrow (Friday May 7th).
>=20
> Comments to the list please.
>=20
> thanks, Ross
>=20
>=20
> >X-JNPR-Received-From: outside
> >To: i-d-announce@ietf.org
> >Cc: l3vpn@ietf.org
> >From: Internet-Drafts@ietf.org
> >Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-03.txt
> >Date: Thu, 22 Apr 2004 15:41:33 -0400
> >Sender: l3vpn-admin@ietf.org
> >X-BeenThere: l3vpn@ietf.org
> >X-Mailman-Version: 2.0.12
> >List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
> >         <mailto:l3vpn-request@ietf.org?subject=3Dunsubscribe>
> >List-Id: <l3vpn.ietf.org>
> >List-Post: <mailto:l3vpn@ietf.org>
> >List-Help: <mailto:l3vpn-request@ietf.org?subject=3Dhelp>
> >List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
> >         <mailto:l3vpn-request@ietf.org?subject=3Dsubscribe>
> >X-Not-Spam: Spam Score: 4.681 -
> >JNPR_BAD_RECV1,MIME_BOUND_NEXTPART,NO_REAL_NAME
> >X-Scanned-By: MIMEDefang 2.39
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts=20
> >directories.
> >This draft is a work item of the Layer 3 Virtual Private Networks=20
> >Working Group of the IETF.
> >
> >         Title           : Using BGP as an Auto-Discovery=20
> Mechanism for
> >                           Provider-provisioned VPNs
> >         Author(s)       : H. Ould-Brahim, et al.
> >         Filename        : draft-ietf-l3vpn-bgpvpn-auto-03.txt
> >         Pages           : 13
> >         Date            : 2004-4-22
> >
> >In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider
> >    Edge (PE) devices attached to a common VPN must exchange certain
> >    information as a prerequisite to establish VPN-specific
> >    connectivity. The purpose of this draft is to define a BGP based
> >    auto-discovery mechanism for both layer-2 VPN architectures and
> >    layer-3 VPNs (Virtual Routers ?VR [VPN-VR]). This=20
> mechanism is based
> >    on the approach used by BGP/MPLS-IP-VPN [BGP/MPLS-IP-VPN] for
> >    distributing VPN routing information within the service=20
> provider(s).
> >    Each VPN scheme uses the mechanism to automatically discover the
> >    information needed by that particular scheme.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-a
> uto-03.txt
> >
> >To remove yourself from the I-D Announcement list, send a message to=20
> >i-d-announce-request@ietf.org with the word unsubscribe in=20
> the body of=20
> >the message.
> >You can also visit=20
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> >to change your subscription settings.
> >
> >
> >Internet-Drafts are also available by anonymous FTP. Login with the=20
> >username "anonymous" and a password of your e-mail address. After=20
> >logging in, type "cd internet-drafts" and then
> >         "get draft-ietf-l3vpn-bgpvpn-auto-03.txt".
> >
> >A list of Internet-Drafts directories can be found in=20
> >http://www.ietf.org/shadow.html or=20
> >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >Internet-Drafts can also be obtained by e-mail.
> >
> >Send a message to:
> >         mailserv@ietf.org.
> >In the body type:
> >         "FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt".
> >
> >NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before=20
> the "FILE"
> >         command.  To decode the response(s), you will need=20
> "munpack" or
> >         a MIME-compliant mail reader.  Different=20
> MIME-compliant mail readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which=20
> have been split
> >         up into multiple messages), so check your local=20
> documentation on
> >         how to manipulate these messages.
> >
> >
> >Below is the data which will enable a MIME compliant mail reader=20
> >implementation to automatically retrieve the ASCII version of the=20
> >Internet-Draft.
> >Content-Type: text/plain
> >Content-ID:     <2004-4-22154050.I-D@ietf.org>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-a
> uto-03.txt
> >>
>=20
>=20
>=20




From exim@www1.ietf.org  Thu May  6 13:30:58 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05285
	for <l3vpn-archive@odin.ietf.org>; Thu, 6 May 2004 13:30:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLmXG-0001Y1-Ua
	for l3vpn-archive@odin.ietf.org; Thu, 06 May 2004 13:19:50 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HJooA005941
	for l3vpn-archive@odin.ietf.org; Thu, 6 May 2004 13:19:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLlvT-0001vU-RO
	for l3vpn-web-archive@optimus.ietf.org; Thu, 06 May 2004 12:40:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28482
	for <l3vpn-web-archive@ietf.org>; Thu, 6 May 2004 12:40:44 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLlvS-0001BB-9n
	for l3vpn-web-archive@ietf.org; Thu, 06 May 2004 12:40:46 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLlsf-0000JD-00
	for l3vpn-web-archive@ietf.org; Thu, 06 May 2004 12:37:55 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLlpA-0006sr-00
	for l3vpn-web-archive@ietf.org; Thu, 06 May 2004 12:34:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLl2c-0004HT-TG; Thu, 06 May 2004 11:44:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLkoL-0004XN-Rw
	for l3vpn@optimus.ietf.org; Thu, 06 May 2004 11:29:21 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20184;
	Thu, 6 May 2004 11:29:19 -0400 (EDT)
Message-Id: <200405061529.LAA20184@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: l3vpn@ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-l3vpn-as2547-04.txt
Date: Thu, 06 May 2004 11:29:19 -0400
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART,
	NO_REAL_NAME autolearn=no version=2.60

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF.

	Title		: Applicability Statement for BGP/MPLS IP VPNs
	Author(s)	: E. Rosen
	Filename	: draft-ietf-l3vpn-as2547-04.txt
	Pages		: 32
	Date		: 2004-5-5
	
This document provides an Applicability Statement for the VPN
   solution described in [BGP-MPLS-IP-VPN] and other documents listed in
   the References section.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-as2547-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-l3vpn-as2547-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-l3vpn-as2547-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-5-6113457.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-l3vpn-as2547-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-l3vpn-as2547-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-5-6113457.I-D@ietf.org>

--OtherAccess--

--NextPart--






From exim@www1.ietf.org  Fri May  7 12:04:31 2004
Received: from optimus.ietf.org (www.iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02852
	for <l3vpn-archive@odin.ietf.org>; Fri, 7 May 2004 12:04:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BM7kd-00061s-6W
	for l3vpn-archive@odin.ietf.org; Fri, 07 May 2004 11:59:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Fx3TQ023170
	for l3vpn-archive@odin.ietf.org; Fri, 7 May 2004 11:59:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BM7ga-0004AV-QI
	for l3vpn-web-archive@optimus.ietf.org; Fri, 07 May 2004 11:54:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02486
	for <l3vpn-web-archive@ietf.org>; Fri, 7 May 2004 11:54:49 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BM7gZ-0005fD-LJ
	for l3vpn-web-archive@ietf.org; Fri, 07 May 2004 11:54:51 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BM7fp-0005Fc-00
	for l3vpn-web-archive@ietf.org; Fri, 07 May 2004 11:54:06 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BM7f5-0004pO-00
	for l3vpn-web-archive@ietf.org; Fri, 07 May 2004 11:53:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BM7Y1-000237-BK; Fri, 07 May 2004 11:46:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BM7OH-0007Q3-Vj
	for l3vpn@optimus.ietf.org; Fri, 07 May 2004 11:35:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01764
	for <l3vpn@ietf.org>; Fri, 7 May 2004 11:35:54 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BM7OG-00056y-Ny
	for l3vpn@ietf.org; Fri, 07 May 2004 11:35:56 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BM7NN-0004gV-00
	for l3vpn@ietf.org; Fri, 07 May 2004 11:35:01 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BM7MZ-0003xK-00
	for l3vpn@ietf.org; Fri, 07 May 2004 11:34:11 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
  by rtp-iport-1.cisco.com with ESMTP; 07 May 2004 08:36:16 -0700
X-BrightmailFiltered: true
Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i47FXcpI007323;
	Fri, 7 May 2004 11:33:38 -0400 (EDT)
Message-Id: <200405071533.i47FXcpI007323@rtp-core-2.cisco.com>
To: "nabendu das" <dasnabendu123@hotmail.com>
cc: l3vpn@ietf.org
Subject: Re: draft-ietf-l3vpn-ospf-2547-01.txt Query 
In-reply-to: Your message of Wed, 05 May 2004 15:21:41 +0530.
             <BAY13-F112Rqf69aZbL00000ea0@hotmail.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3
 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 07 May 2004 11:33:39 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60


> Why PE MUST function as an OSPF  area 0 router.... ????  What is the issue
> if PE acts as  ABR of the area to which PE/CE  link belongs and distribute
> inter-area routes to the attached CE via Type 3 LSAs???? 

The PEs function as  area 0 routers in that they are  part of the inter-area
backbone. 

If there is also a "native" area  0, then one of the "native" area 0 routers
must connect to a PE router, or else there would be two inter-area backbones
that weren't connected. 





From exim@www1.ietf.org  Fri May  7 15:26:35 2004
Received: from optimus.ietf.org (www.iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15516
	for <l3vpn-archive@odin.ietf.org>; Fri, 7 May 2004 15:26:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BMAx9-0004rz-HL
	for l3vpn-archive@odin.ietf.org; Fri, 07 May 2004 15:24:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i47JOBPh018720
	for l3vpn-archive@odin.ietf.org; Fri, 7 May 2004 15:24:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BMAu8-00040G-VB
	for l3vpn-web-archive@optimus.ietf.org; Fri, 07 May 2004 15:21:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15210
	for <l3vpn-web-archive@ietf.org>; Fri, 7 May 2004 15:21:02 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BMAu7-0003xH-NI
	for l3vpn-web-archive@ietf.org; Fri, 07 May 2004 15:21:03 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BMAt7-0003T2-00
	for l3vpn-web-archive@ietf.org; Fri, 07 May 2004 15:20:02 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BMAsE-00032I-00
	for l3vpn-web-archive@ietf.org; Fri, 07 May 2004 15:19:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BMAmJ-0008WJ-36; Fri, 07 May 2004 15:12:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BMAif-000694-St
	for l3vpn@optimus.ietf.org; Fri, 07 May 2004 15:09:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13948
	for <l3vpn@ietf.org>; Fri, 7 May 2004 15:09:09 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BMAic-0006YC-JA
	for l3vpn@ietf.org; Fri, 07 May 2004 15:09:10 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BMAhc-00067b-00
	for l3vpn@ietf.org; Fri, 07 May 2004 15:08:09 -0400
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BMAgy-0005Nu-00
	for l3vpn@ietf.org; Fri, 07 May 2004 15:07:28 -0400
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i47J6t005896;
	Fri, 7 May 2004 15:06:55 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <JCT8QR3F>; Fri, 7 May 2004 15:06:55 -0400
Message-ID: <D38D073716F2D411BEE400508BCF62960B2CE7BF@zcard04k.ca.nortel.com>
From: "Hamid Ould-Brahim" <hbrahim@nortelnetworks.com>
To: "Schliesser, Benson" <benson.schliesser@savvis.net>, l3vpn@ietf.org,
        erosen@cisco.com, yakov@juniper.net
Subject: RE: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
Date: Fri, 7 May 2004 15:06:54 -0400 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60

Benson,

Thanks for the feedback.

> 
> Just a couple comments, for wg-last-call, regarding 
> draft-ietf-l3vpn-bgpvpn-auto-03.
> 
> Section 4.2.2 introduces a new extended community for 
> signaling a VR's role in the VPN topology. It should be 
> stated more clearly (assuming I've inferred correctly) that 
> spokes connect to hubs and vice versa, and meshes connect to 
> each other. Further, the draft should address the situation 
> where hub, spoke, and mesh VRs all coexist in the same VPN. 
> One might argue that this is a misconfiguration, but I'd 
> propose that mesh sites should connect to each other and to 
> hubs while spokes only connect to hubs, etc.
> 

Sure. I will make this clarification.

> Section 6 addresses tunnel discovery, and recommends 
> tunneling mechanisms with demultiplexing capabilities. The 
> draft should either discuss or point to discussion of how the 
> multiplex keys get distributed/determined. (it's clear for 
> MPLS, but less so for other protocols; i.e., IKE, 
> NLRI-encoded, ext community, etc? I know of implementations 
> that exist, but not necessarily specifications...)
> 

Indeed, multiple implementations may have different ways to
distribute/determine the demultiplexing capabilities and what
is needed for the discovery process to convey. In fact,
the draft is just trying to focus on the discovery process and
the minimum information such as PE address, VR- private address 
(that may or may not be used), membership information and not 
to describe how each tunnel protocol will use it. 
However, we can elaborate and clarify that the demultiplexing scheme 
needs to be determined as part of the discovery process or as part 
of the signaling protocol.

How about we add a text along these lines:

"The auto-discovery mechanism should convey minimum information 
for the tunnels to be setup. The means of distributing multiplexors 
must be defined either via some sort of  tunnel-protocol-specific 
signaling mechanism, or via additional information carried by the  
auto-discovery protocol. That information may or may not be 
used directly within the specific signaling protocol. 
On one end of the spectrum, the combination of IP address 
(such as BGP next hop and IP address carried within the NLRI) 
and the label and/or VPN-ID provides sufficient information for a 
PE to setup per VPN or per set of VPNs tunnels. On another end of the 
spectrum additional specific tunnel related information can be carried
within the discovery process if needed."


Thanks again.

Hamid.

> Thanks,
> -Benson
> 
> 
> > -----Original Message-----
> > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On
> > Behalf Of Ross Callon
> > Sent: Thursday, April 22, 2004 4:43 PM
> > To: l3vpn@ietf.org
> > Subject: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
> > 
> > This begins working group last call on
> > draft-ietf-l3vpn-bgpvpn-auto-03.txt.
> > The last call will terminate two weeks from tomorrow 
> (Friday May 7th).
> > 
> > Comments to the list please.
> > 
> > thanks, Ross
> > 
> > 
> > >X-JNPR-Received-From: outside
> > >To: i-d-announce@ietf.org
> > >Cc: l3vpn@ietf.org
> > >From: Internet-Drafts@ietf.org
> > >Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-03.txt
> > >Date: Thu, 22 Apr 2004 15:41:33 -0400
> > >Sender: l3vpn-admin@ietf.org
> > >X-BeenThere: l3vpn@ietf.org
> > >X-Mailman-Version: 2.0.12
> > >List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
> > >         <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
> > >List-Id: <l3vpn.ietf.org>
> > >List-Post: <mailto:l3vpn@ietf.org>
> > >List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
> > >List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
> > >         <mailto:l3vpn-request@ietf.org?subject=subscribe>
> > >X-Not-Spam: Spam Score: 4.681 - 
> > >JNPR_BAD_RECV1,MIME_BOUND_NEXTPART,NO_REAL_NAME
> > >X-Scanned-By: MIMEDefang 2.39
> > >
> > >A New Internet-Draft is available from the on-line Internet-Drafts
> > >directories.
> > >This draft is a work item of the Layer 3 Virtual Private Networks 
> > >Working Group of the IETF.
> > >
> > >         Title           : Using BGP as an Auto-Discovery 
> > Mechanism for
> > >                           Provider-provisioned VPNs
> > >         Author(s)       : H. Ould-Brahim, et al.
> > >         Filename        : draft-ietf-l3vpn-bgpvpn-auto-03.txt
> > >         Pages           : 13
> > >         Date            : 2004-4-22
> > >
> > >In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider
> > >    Edge (PE) devices attached to a common VPN must 
> exchange certain
> > >    information as a prerequisite to establish VPN-specific
> > >    connectivity. The purpose of this draft is to define a 
> BGP based
> > >    auto-discovery mechanism for both layer-2 VPN architectures and
> > >    layer-3 VPNs (Virtual Routers ?VR [VPN-VR]). This
> > mechanism is based
> > >    on the approach used by BGP/MPLS-IP-VPN [BGP/MPLS-IP-VPN] for
> > >    distributing VPN routing information within the service
> > provider(s).
> > >    Each VPN scheme uses the mechanism to automatically 
> discover the
> > >    information needed by that particular scheme.
> > >
> > >A URL for this Internet-Draft is: 
> > >http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-a
> > uto-03.txt
> > >
> > >To remove yourself from the I-D Announcement list, send a 
> message to
> > >i-d-announce-request@ietf.org with the word unsubscribe in 
> > the body of
> > >the message.
> > >You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > >to change your subscription settings.
> > >
> > >
> > >Internet-Drafts are also available by anonymous FTP. Login with the
> > >username "anonymous" and a password of your e-mail address. After 
> > >logging in, type "cd internet-drafts" and then
> > >         "get draft-ietf-l3vpn-bgpvpn-auto-03.txt".
> > >
> > >A list of Internet-Drafts directories can be found in
> > >http://www.ietf.org/shadow.html or 
> > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > >Internet-Drafts can also be obtained by e-mail.
> > >
> > >Send a message to:
> > >         mailserv@ietf.org.
> > >In the body type:
> > >         "FILE 
> /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt".
> > >
> > >NOTE:   The mail server at ietf.org can return the document in
> > >         MIME-encoded form by using the "mpack" utility.  
> To use this
> > >         feature, insert the command "ENCODING mime" before
> > the "FILE"
> > >         command.  To decode the response(s), you will need
> > "munpack" or
> > >         a MIME-compliant mail reader.  Different
> > MIME-compliant mail readers
> > >         exhibit different behavior, especially when dealing with
> > >         "multipart" MIME messages (i.e. documents which
> > have been split
> > >         up into multiple messages), so check your local
> > documentation on
> > >         how to manipulate these messages.
> > >
> > >
> > >Below is the data which will enable a MIME compliant mail reader
> > >implementation to automatically retrieve the ASCII version of the 
> > >Internet-Draft.
> > >Content-Type: text/plain
> > >Content-ID:     <2004-4-22154050.I-D@ietf.org>
> > >
> > >ENCODING mime
> > >FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt
> > >
> > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-a
> > uto-03.txt
> > >>
> > 
> > 
> > 
> 




From exim@www1.ietf.org  Fri May  7 22:05:02 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04323
	for <l3vpn-archive@odin.ietf.org>; Fri, 7 May 2004 22:05:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BMH9h-00049U-T5
	for l3vpn-archive@odin.ietf.org; Fri, 07 May 2004 22:01:34 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4821XM6015955
	for l3vpn-archive@odin.ietf.org; Fri, 7 May 2004 22:01:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BMH1x-0002Ou-BM
	for l3vpn-web-archive@optimus.ietf.org; Fri, 07 May 2004 21:53:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03933
	for <l3vpn-web-archive@ietf.org>; Fri, 7 May 2004 21:53:29 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BMH1u-0001QR-EI
	for l3vpn-web-archive@ietf.org; Fri, 07 May 2004 21:53:30 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BMH0r-000101-00
	for l3vpn-web-archive@ietf.org; Fri, 07 May 2004 21:52:26 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BMH0N-0000ZQ-00
	for l3vpn-web-archive@ietf.org; Fri, 07 May 2004 21:51:55 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BMGtl-00009r-Ir; Fri, 07 May 2004 21:45:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BMGoA-0006xZ-Kk
	for l3vpn@optimus.ietf.org; Fri, 07 May 2004 21:39:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03599
	for <l3vpn@ietf.org>; Fri, 7 May 2004 21:39:15 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BMGo7-0003Mr-NM
	for l3vpn@ietf.org; Fri, 07 May 2004 21:39:15 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BMGnI-0002wb-00
	for l3vpn@ietf.org; Fri, 07 May 2004 21:38:25 -0400
Received: from mailgate1b.savvis.net ([216.91.182.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BMGmM-0002VC-00
	for l3vpn@ietf.org; Fri, 07 May 2004 21:37:26 -0400
Received: from sl6exch3.savvis.ad.savvis.net (sl6exch3.it.savvis.net [10.12.134.21])
	by mailgate1b.savvis.net (8.12.10/8.12.1) with ESMTP id i481b95K027327;
	Fri, 7 May 2004 20:37:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
Date: Fri, 7 May 2004 20:36:27 -0500
Message-ID: <51909D9AC2941E4F9D35B264D12CD7C20ACBBAAF@sl6exch3.savvis.ad.savvis.net>
Thread-Topic: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
Thread-Index: AcQ0Zmd2R5TsgDNnQpWCX2DrGlRolgANelWw
From: "Schliesser, Benson" <benson.schliesser@savvis.net>
To: "Hamid Ould-Brahim" <hbrahim@nortelnetworks.com>, <l3vpn@ietf.org>,
        <erosen@cisco.com>, <yakov@juniper.net>
X-ECS-MailScanner: No virus is found
Content-Transfer-Encoding: quoted-printable
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hamid-
I think your proposed changes (quoted below) are fine.
Thanks,
-Benson

> -----Original Message-----
> From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com]=20
> Sent: Friday, May 07, 2004 2:07 PM
> To: Schliesser, Benson; l3vpn@ietf.org; erosen@cisco.com;=20
> yakov@juniper.net
> Subject: RE: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
>=20
> Benson,
>=20
> Thanks for the feedback.
>=20
> >=20
> > Just a couple comments, for wg-last-call, regarding=20
> > draft-ietf-l3vpn-bgpvpn-auto-03.
> >=20
> > Section 4.2.2 introduces a new extended community for=20
> signaling a VR's=20
> > role in the VPN topology. It should be stated more clearly=20
> (assuming=20
> > I've inferred correctly) that spokes connect to hubs and=20
> vice versa,=20
> > and meshes connect to each other. Further, the draft should address=20
> > the situation where hub, spoke, and mesh VRs all coexist in=20
> the same=20
> > VPN.
> > One might argue that this is a misconfiguration, but I'd=20
> propose that=20
> > mesh sites should connect to each other and to hubs while=20
> spokes only=20
> > connect to hubs, etc.
> >=20
>=20
> Sure. I will make this clarification.
>=20
> > Section 6 addresses tunnel discovery, and recommends=20
> > tunneling mechanisms with demultiplexing capabilities. The=20
> > draft should either discuss or point to discussion of how the=20
> > multiplex keys get distributed/determined. (it's clear for=20
> > MPLS, but less so for other protocols; i.e., IKE,=20
> > NLRI-encoded, ext community, etc? I know of implementations=20
> > that exist, but not necessarily specifications...)
> >=20
>=20
> Indeed, multiple implementations may have different ways to
> distribute/determine the demultiplexing capabilities and what
> is needed for the discovery process to convey. In fact,
> the draft is just trying to focus on the discovery process and
> the minimum information such as PE address, VR- private address=20
> (that may or may not be used), membership information and not=20
> to describe how each tunnel protocol will use it.=20
> However, we can elaborate and clarify that the demultiplexing scheme=20
> needs to be determined as part of the discovery process or as part=20
> of the signaling protocol.
>=20
> How about we add a text along these lines:
>=20
> "The auto-discovery mechanism should convey minimum information=20
> for the tunnels to be setup. The means of distributing multiplexors=20
> must be defined either via some sort of  tunnel-protocol-specific=20
> signaling mechanism, or via additional information carried by the =20
> auto-discovery protocol. That information may or may not be=20
> used directly within the specific signaling protocol.=20
> On one end of the spectrum, the combination of IP address=20
> (such as BGP next hop and IP address carried within the NLRI)=20
> and the label and/or VPN-ID provides sufficient information for a=20
> PE to setup per VPN or per set of VPNs tunnels. On another end of the=20
> spectrum additional specific tunnel related information can be carried
> within the discovery process if needed."
>=20
>=20
> Thanks again.
>=20
> Hamid.
>=20
> > Thanks,
> > -Benson
> >=20
> >=20
> > > -----Original Message-----
> > > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On
> > > Behalf Of Ross Callon
> > > Sent: Thursday, April 22, 2004 4:43 PM
> > > To: l3vpn@ietf.org
> > > Subject: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
> > >=20
> > > This begins working group last call on
> > > draft-ietf-l3vpn-bgpvpn-auto-03.txt.
> > > The last call will terminate two weeks from tomorrow=20
> > (Friday May 7th).
> > >=20
> > > Comments to the list please.
> > >=20
> > > thanks, Ross
> > >=20
> > >=20
> > > >X-JNPR-Received-From: outside
> > > >To: i-d-announce@ietf.org
> > > >Cc: l3vpn@ietf.org
> > > >From: Internet-Drafts@ietf.org
> > > >Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-03.txt
> > > >Date: Thu, 22 Apr 2004 15:41:33 -0400
> > > >Sender: l3vpn-admin@ietf.org
> > > >X-BeenThere: l3vpn@ietf.org
> > > >X-Mailman-Version: 2.0.12
> > > >List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
> > > >         <mailto:l3vpn-request@ietf.org?subject=3Dunsubscribe>
> > > >List-Id: <l3vpn.ietf.org>
> > > >List-Post: <mailto:l3vpn@ietf.org>
> > > >List-Help: <mailto:l3vpn-request@ietf.org?subject=3Dhelp>
> > > >List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
> > > >         <mailto:l3vpn-request@ietf.org?subject=3Dsubscribe>
> > > >X-Not-Spam: Spam Score: 4.681 -=20
> > > >JNPR_BAD_RECV1,MIME_BOUND_NEXTPART,NO_REAL_NAME
> > > >X-Scanned-By: MIMEDefang 2.39
> > > >
> > > >A New Internet-Draft is available from the on-line=20
> Internet-Drafts
> > > >directories.
> > > >This draft is a work item of the Layer 3 Virtual Private=20
> Networks=20
> > > >Working Group of the IETF.
> > > >
> > > >         Title           : Using BGP as an Auto-Discovery=20
> > > Mechanism for
> > > >                           Provider-provisioned VPNs
> > > >         Author(s)       : H. Ould-Brahim, et al.
> > > >         Filename        : draft-ietf-l3vpn-bgpvpn-auto-03.txt
> > > >         Pages           : 13
> > > >         Date            : 2004-4-22
> > > >
> > > >In any Provider Provisioned-Based VPN (PPVPN) scheme,=20
> the Provider
> > > >    Edge (PE) devices attached to a common VPN must=20
> > exchange certain
> > > >    information as a prerequisite to establish VPN-specific
> > > >    connectivity. The purpose of this draft is to define a=20
> > BGP based
> > > >    auto-discovery mechanism for both layer-2 VPN=20
> architectures and
> > > >    layer-3 VPNs (Virtual Routers ?VR [VPN-VR]). This
> > > mechanism is based
> > > >    on the approach used by BGP/MPLS-IP-VPN [BGP/MPLS-IP-VPN] for
> > > >    distributing VPN routing information within the service
> > > provider(s).
> > > >    Each VPN scheme uses the mechanism to automatically=20
> > discover the
> > > >    information needed by that particular scheme.
> > > >
> > > >A URL for this Internet-Draft is:=20
> > > >http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-a
> > > uto-03.txt
> > > >
> > > >To remove yourself from the I-D Announcement list, send a=20
> > message to
> > > >i-d-announce-request@ietf.org with the word unsubscribe in=20
> > > the body of
> > > >the message.
> > > >You can also visit
> > > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > >to change your subscription settings.
> > > >
> > > >
> > > >Internet-Drafts are also available by anonymous FTP.=20
> Login with the
> > > >username "anonymous" and a password of your e-mail=20
> address. After=20
> > > >logging in, type "cd internet-drafts" and then
> > > >         "get draft-ietf-l3vpn-bgpvpn-auto-03.txt".
> > > >
> > > >A list of Internet-Drafts directories can be found in
> > > >http://www.ietf.org/shadow.html or=20
> > > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > >
> > > >Internet-Drafts can also be obtained by e-mail.
> > > >
> > > >Send a message to:
> > > >         mailserv@ietf.org.
> > > >In the body type:
> > > >         "FILE=20
> > /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt".
> > > >
> > > >NOTE:   The mail server at ietf.org can return the document in
> > > >         MIME-encoded form by using the "mpack" utility. =20
> > To use this
> > > >         feature, insert the command "ENCODING mime" before
> > > the "FILE"
> > > >         command.  To decode the response(s), you will need
> > > "munpack" or
> > > >         a MIME-compliant mail reader.  Different
> > > MIME-compliant mail readers
> > > >         exhibit different behavior, especially when dealing with
> > > >         "multipart" MIME messages (i.e. documents which
> > > have been split
> > > >         up into multiple messages), so check your local
> > > documentation on
> > > >         how to manipulate these messages.
> > > >
> > > >
> > > >Below is the data which will enable a MIME compliant mail reader
> > > >implementation to automatically retrieve the ASCII=20
> version of the=20
> > > >Internet-Draft.
> > > >Content-Type: text/plain
> > > >Content-ID:     <2004-4-22154050.I-D@ietf.org>
> > > >
> > > >ENCODING mime
> > > >FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt
> > > >
> > > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-a
> > > uto-03.txt
> > > >>
> > >=20
> > >=20
> > >=20
> >=20
>=20




From exim@www1.ietf.org  Mon May 10 04:33:26 2004
Received: from optimus.ietf.org (www.iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17227
	for <l3vpn-archive@odin.ietf.org>; Mon, 10 May 2004 04:33:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BN68a-00084j-Ok
	for l3vpn-archive@odin.ietf.org; Mon, 10 May 2004 04:27:48 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4A8Rmnx031030
	for l3vpn-archive@odin.ietf.org; Mon, 10 May 2004 04:27:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BN63V-00074D-A0
	for l3vpn-web-archive@optimus.ietf.org; Mon, 10 May 2004 04:22:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16513
	for <l3vpn-web-archive@ietf.org>; Mon, 10 May 2004 04:22:30 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BN63S-0005cK-IY
	for l3vpn-web-archive@ietf.org; Mon, 10 May 2004 04:22:30 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BN62R-0005Jy-00
	for l3vpn-web-archive@ietf.org; Mon, 10 May 2004 04:21:28 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BN61S-00051X-00
	for l3vpn-web-archive@ietf.org; Mon, 10 May 2004 04:20:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BN5wG-0006DN-95; Mon, 10 May 2004 04:15:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BN4gK-0006uS-AG
	for l3vpn@optimus.ietf.org; Mon, 10 May 2004 02:54:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13552
	for <l3vpn@ietf.org>; Mon, 10 May 2004 02:54:28 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BN4gG-0002tT-Ds
	for l3vpn@ietf.org; Mon, 10 May 2004 02:54:28 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BN4fJ-0002bn-00
	for l3vpn@ietf.org; Mon, 10 May 2004 02:53:30 -0400
Received: from av7-2-sn4.m-sp.skanova.net ([81.228.10.109])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BN4et-0002KM-00
	for l3vpn@ietf.org; Mon, 10 May 2004 02:53:03 -0400
Received: by av7-2-sn4.m-sp.skanova.net (Postfix, from userid 502)
	id 6FF8F37E82; Mon, 10 May 2004 08:52:34 +0200 (CEST)
Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182])
	by av7-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 6186537E6E
	for <l3vpn@ietf.org>; Mon, 10 May 2004 08:52:34 +0200 (CEST)
Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178])
	by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 45FC037E62
	for <l3vpn@ietf.org>; Mon, 10 May 2004 08:52:34 +0200 (CEST)
Message-ID: <409F26A6.6050100@pi.se>
Date: Mon, 10 May 2004 08:52:22 +0200
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: l3vpn@ietf.org
Subject: MPLS2004 Conference CFP
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

The MPLS2004 Conference will be held in Washington DC, from October 17
to October 19, 2004. This year's conference will include, but will not
be limited, to the following topics:

- Network Consolidation and Service Convergence
- Traffic engineering and QoS
- MPLS network operation, administration, and maintenance
- OSS Systems for MPLS-based networks
- MPLS Multicast
- Service Provisioning
- MPLS in multi-AS networks
- L2VPNs (pseudo-wire emulation, VPWS, VPLS, and others)
- L3VPNs (BGP/MPLS, IPSec interworking, virtual routers, and others)
- Voice, video, and real-time services over MPLS networks
- Scalability and performance of MPLS protocols and networks
- Network processor architectures for next generation MPLS networks
- MPLS certification, verification, and conformance testing
- MPLS network security
- MPLS reliability and survivability (fast reroute, graceful restart,
   and restoration techniques)
- IP Optical Integration
- Multilayer control, management, and optimization
- MPLS deployment case studies: Service Provider operational experience

The Program Committee for MPLS2004 is soliciting presentation proposals
for this conference. If you wish to propose a particular topic for
consideration, please send a one page summary, including speaker's name,
affiliation, and contact information to the Technical Program
Committee at: MPLS2004-CFP@isocore.com

All proposals must be received by June 18, 2004. See
http://www.mpls2004.com for more details.

The program committee is looking for original and unpublished work to
continue the tradition of addressing cutting-edge topics that was
initiated by this conference in 1998. Presentations from the vendor,
service provider, research, and user communities covering technology
evolution and operational experience are solicited.
-- 

Loa Andersson

mobile +46 739 81 21 64





From exim@www1.ietf.org  Tue May 11 18:07:46 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00734
	for <l3vpn-archive@odin.ietf.org>; Tue, 11 May 2004 18:07:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNfJT-0005sC-0G
	for l3vpn-archive@odin.ietf.org; Tue, 11 May 2004 18:01:23 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BM1MuH022576
	for l3vpn-archive@odin.ietf.org; Tue, 11 May 2004 18:01:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNf17-0008T4-HV
	for l3vpn-web-archive@optimus.ietf.org; Tue, 11 May 2004 17:42:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28267
	for <l3vpn-web-archive@ietf.org>; Tue, 11 May 2004 17:42:21 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BNf15-000655-3p
	for l3vpn-web-archive@ietf.org; Tue, 11 May 2004 17:42:23 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BNf0L-0005em-00
	for l3vpn-web-archive@ietf.org; Tue, 11 May 2004 17:41:38 -0400
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BNezc-0005Cf-00
	for l3vpn-web-archive@ietf.org; Tue, 11 May 2004 17:40:52 -0400
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1BNezN-00061j-Dm
	for l3vpn-web-archive@ietf.org; Tue, 11 May 2004 17:40:37 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNer4-0004XR-4P; Tue, 11 May 2004 17:32:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNePQ-0003v5-BJ
	for l3vpn@optimus.ietf.org; Tue, 11 May 2004 17:03:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25304
	for <l3vpn@ietf.org>; Tue, 11 May 2004 17:03:24 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BNePO-0004N5-Aa
	for l3vpn@ietf.org; Tue, 11 May 2004 17:03:26 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BNeOU-0003us-00
	for l3vpn@ietf.org; Tue, 11 May 2004 17:02:31 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BNeNc-0003OB-00
	for l3vpn@ietf.org; Tue, 11 May 2004 17:01:37 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4BL16917831
	for <l3vpn@ietf.org>; Tue, 11 May 2004 14:01:06 -0700 (PDT)
	(envelope-from rcallon@juniper.net)
Received: from rcallon-lt1.juniper.net ([172.28.5.27])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4BL10J73364
	for <l3vpn@ietf.org>; Tue, 11 May 2004 14:01:00 -0700 (PDT)
	(envelope-from rcallon@juniper.net)
Message-Id: <5.0.0.25.2.20040511165701.00bb5318@zircon.juniper.net>
X-Sender: rcallon@zircon.juniper.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 11 May 2004 16:57:48 -0400
To: l3vpn@ietf.org
From: Ross Callon <rcallon@juniper.net>
Subject: End of Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt
In-Reply-To: <5.0.0.25.2.20040422173959.00b99960@zircon.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60

This ends the last call on  draft-ietf-l3vpn-bgpvpn-auto-03.txt.

thanks, Ross

At 05:42 PM 4/22/2004 -0400, Ross Callon wrote:
>This begins working group last call on draft-ietf-l3vpn-bgpvpn-auto-03.txt.
>The last call will terminate two weeks from tomorrow (Friday May 7th).
>
>Comments to the list please.
>
>thanks, Ross
>
>
>>X-JNPR-Received-From: outside
>>To: i-d-announce@ietf.org
>>Cc: l3vpn@ietf.org
>>From: Internet-Drafts@ietf.org
>>Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-03.txt
>>Date: Thu, 22 Apr 2004 15:41:33 -0400
>>Sender: l3vpn-admin@ietf.org
>>X-BeenThere: l3vpn@ietf.org
>>X-Mailman-Version: 2.0.12
>>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
>>         <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
>>List-Id: <l3vpn.ietf.org>
>>List-Post: <mailto:l3vpn@ietf.org>
>>List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
>>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
>>         <mailto:l3vpn-request@ietf.org?subject=subscribe>
>>X-Not-Spam: Spam Score: 4.681 - 
>>JNPR_BAD_RECV1,MIME_BOUND_NEXTPART,NO_REAL_NAME
>>X-Scanned-By: MIMEDefang 2.39
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>This draft is a work item of the Layer 3 Virtual Private Networks Working 
>>Group of the IETF.
>>
>>         Title           : Using BGP as an Auto-Discovery Mechanism for
>>                           Provider-provisioned VPNs
>>         Author(s)       : H. Ould-Brahim, et al.
>>         Filename        : draft-ietf-l3vpn-bgpvpn-auto-03.txt
>>         Pages           : 13
>>         Date            : 2004-4-22
>>
>>In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider
>>    Edge (PE) devices attached to a common VPN must exchange certain
>>    information as a prerequisite to establish VPN-specific
>>    connectivity. The purpose of this draft is to define a BGP based
>>    auto-discovery mechanism for both layer-2 VPN architectures and
>>    layer-3 VPNs (Virtual Routers ?VR [VPN-VR]). This mechanism is based
>>    on the approach used by BGP/MPLS-IP-VPN [BGP/MPLS-IP-VPN] for
>>    distributing VPN routing information within the service provider(s).
>>    Each VPN scheme uses the mechanism to automatically discover the
>>    information needed by that particular scheme.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt
>>
>>To remove yourself from the I-D Announcement list, send a message to
>>i-d-announce-request@ietf.org with the word unsubscribe in the body of 
>>the message.
>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>>to change your subscription settings.
>>
>>
>>Internet-Drafts are also available by anonymous FTP. Login with the username
>>"anonymous" and a password of your e-mail address. After logging in,
>>type "cd internet-drafts" and then
>>         "get draft-ietf-l3vpn-bgpvpn-auto-03.txt".
>>
>>A list of Internet-Drafts directories can be found in
>>http://www.ietf.org/shadow.html
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>>         mailserv@ietf.org.
>>In the body type:
>>         "FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt".
>>
>>NOTE:   The mail server at ietf.org can return the document in
>>         MIME-encoded form by using the "mpack" utility.  To use this
>>         feature, insert the command "ENCODING mime" before the "FILE"
>>         command.  To decode the response(s), you will need "munpack" or
>>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>         exhibit different behavior, especially when dealing with
>>         "multipart" MIME messages (i.e. documents which have been split
>>         up into multiple messages), so check your local documentation on
>>         how to manipulate these messages.
>>
>>
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the
>>Internet-Draft.
>>Content-Type: text/plain
>>Content-ID:     <2004-4-22154050.I-D@ietf.org>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt
>>
>><ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt>
>
>





From exim@www1.ietf.org  Wed May 12 12:05:39 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21659
	for <l3vpn-archive@odin.ietf.org>; Wed, 12 May 2004 12:05:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNvXg-0007S9-3l
	for l3vpn-archive@odin.ietf.org; Wed, 12 May 2004 11:21:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CFL8V3028642
	for l3vpn-archive@odin.ietf.org; Wed, 12 May 2004 11:21:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNvC4-000618-Uq
	for l3vpn-web-archive@optimus.ietf.org; Wed, 12 May 2004 10:58:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13508
	for <l3vpn-web-archive@ietf.org>; Wed, 12 May 2004 10:58:45 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BNvC2-0002Vs-FX
	for l3vpn-web-archive@ietf.org; Wed, 12 May 2004 10:58:46 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BNvA7-0001Zv-00
	for l3vpn-web-archive@ietf.org; Wed, 12 May 2004 10:56:48 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BNv7W-0000QQ-00
	for l3vpn-web-archive@ietf.org; Wed, 12 May 2004 10:54:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNuF8-0002FF-Am; Wed, 12 May 2004 09:57:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNtyG-0004PT-S0
	for l3vpn@optimus.ietf.org; Wed, 12 May 2004 09:40:28 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02533;
	Wed, 12 May 2004 09:40:26 -0400 (EDT)
Message-Id: <200405121340.JAA02533@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: l3vpn@ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-l3vpn-as2547-05.txt
Date: Wed, 12 May 2004 09:40:25 -0400
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART,
	NO_REAL_NAME autolearn=no version=2.60

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF.

	Title		: Applicability Statement for BGP/MPLS IP VPNs
	Author(s)	: E. Rosen
	Filename	: draft-ietf-l3vpn-as2547-05.txt
	Pages		: 32
	Date		: 2004-5-11
	
This document provides an Applicability Statement for the VPN
   solution described in [BGP-MPLS-IP-VPN] and other documents listed in
   the References section.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-as2547-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-l3vpn-as2547-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-l3vpn-as2547-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-5-12094138.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-l3vpn-as2547-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-l3vpn-as2547-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-5-12094138.I-D@ietf.org>

--OtherAccess--

--NextPart--






From exim@www1.ietf.org  Wed May 12 16:06:07 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07911
	for <l3vpn-archive@odin.ietf.org>; Wed, 12 May 2004 16:06:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNzwM-0002XT-Bj
	for l3vpn-archive@odin.ietf.org; Wed, 12 May 2004 16:02:54 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CK2stU009759
	for l3vpn-archive@odin.ietf.org; Wed, 12 May 2004 16:02:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNzqk-0000dB-Nm
	for l3vpn-web-archive@optimus.ietf.org; Wed, 12 May 2004 15:57:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07361
	for <l3vpn-web-archive@ietf.org>; Wed, 12 May 2004 15:57:04 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BNzqj-0001Ax-7o
	for l3vpn-web-archive@ietf.org; Wed, 12 May 2004 15:57:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BNzpf-0000cy-00
	for l3vpn-web-archive@ietf.org; Wed, 12 May 2004 15:56:00 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BNzoN-0007Sr-00
	for l3vpn-web-archive@ietf.org; Wed, 12 May 2004 15:54:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNzlq-0007d4-L5; Wed, 12 May 2004 15:52:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BNzcA-000503-7D
	for l3vpn@optimus.ietf.org; Wed, 12 May 2004 15:42:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02773
	for <l3vpn@ietf.org>; Wed, 12 May 2004 14:52:42 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BNyqQ-00076c-Ts
	for l3vpn@ietf.org; Wed, 12 May 2004 14:52:43 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BNypO-0006af-00
	for l3vpn@ietf.org; Wed, 12 May 2004 14:51:39 -0400
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BNyoQ-00064l-00
	for l3vpn@ietf.org; Wed, 12 May 2004 14:50:39 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64])
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1BNyoP-0006Tg-Rw
	for l3vpn@ietf.org; Wed, 12 May 2004 14:50:38 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4CInmBm093791
	for <l3vpn@ietf.org>; Wed, 12 May 2004 11:49:48 -0700 (PDT)
	(envelope-from rcallon@juniper.net)
Received: from rcallon-lt1.juniper.net (rcallon-lt1.jnpr.net [10.10.133.15])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4CInlJ17766
	for <l3vpn@ietf.org>; Wed, 12 May 2004 11:49:47 -0700 (PDT)
	(envelope-from rcallon@juniper.net)
Message-Id: <5.0.0.25.2.20040512141506.02c7da50@zircon.juniper.net>
X-Sender: rcallon@zircon.juniper.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 12 May 2004 14:38:00 -0400
To: l3vpn@ietf.org
From: Ross Callon <rcallon@juniper.net>
Subject: Progression of VR and IPsec Architectures
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60

In reviewing the VR and IPsec architectures and associated applicability
statements, the IESG has pointed out that the documents do not actually
read as standards, in the sense that they don't specify what needs to be
implemented for interoperability.

This gives us two choices:

One option would be to publish the documents in approximately their
current form as informational RFCs.

The second option would be to update the documents to specify which
features need to be implemented to allow interoperability between different
implementations.

Note that the VR architecture already contains a few MUST and
SHOULD statements, particularly in section 2. However, it is not clear
whether the sum of the MUST's which are present are sufficient to
ensure interoperability. For example, there is no single discovery
scheme which MUST be implemented (would the MUST apply to
implementation of discovery via manual configuration??).

The CE-based VPN architecture based on IPsec contains a significant
number of MUST statements. However, these are primarily of the form
"for such a feature to work, the implementation MUST operate as follows",
rather than of the form "to be compliant, the implementation MUST
implement the following protocol or feature".

As a working group, we need to decide whether to publish the current
documents as informational, or to begin a process of determining which
features are MUST versus which are SHOULD or MAY, in order to ensure
interoperability, and thereby allow us to progress the documents on the
standards track.

Comments?

thanks, Ross





From exim@www1.ietf.org  Wed May 12 18:44:04 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16734
	for <l3vpn-archive@odin.ietf.org>; Wed, 12 May 2004 18:44:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BO2Qy-0006pu-2g
	for l3vpn-archive@odin.ietf.org; Wed, 12 May 2004 18:42:40 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CMgeGj026275
	for l3vpn-archive@odin.ietf.org; Wed, 12 May 2004 18:42:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BO2PK-0006QQ-Rh
	for l3vpn-web-archive@optimus.ietf.org; Wed, 12 May 2004 18:40:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16538
	for <l3vpn-web-archive@ietf.org>; Wed, 12 May 2004 18:40:54 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BO2PH-0006jm-Rj
	for l3vpn-web-archive@ietf.org; Wed, 12 May 2004 18:40:55 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BO2OM-0006E0-00
	for l3vpn-web-archive@ietf.org; Wed, 12 May 2004 18:39:59 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BO2NR-0005iL-00
	for l3vpn-web-archive@ietf.org; Wed, 12 May 2004 18:39:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BO28u-0002jK-RL; Wed, 12 May 2004 18:24:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BO241-0001Su-GX
	for l3vpn@optimus.ietf.org; Wed, 12 May 2004 18:18:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15653
	for <l3vpn@ietf.org>; Wed, 12 May 2004 18:18:53 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BO23y-0003JN-Kv
	for l3vpn@ietf.org; Wed, 12 May 2004 18:18:54 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BO238-0002ok-00
	for l3vpn@ietf.org; Wed, 12 May 2004 18:18:02 -0400
Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BO22T-0002It-00
	for l3vpn@ietf.org; Wed, 12 May 2004 18:17:21 -0400
Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.134]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XT41L4KJ; Wed, 12 May 2004 18:16:51 -0400
Message-Id: <5.2.0.9.0.20040512173612.0206d490@email>
X-Sender: mduffy@email
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 12 May 2004 18:05:46 -0400
To: erosen@cisco.com, yakov@juniper.net, l3vpn@ietf.org
From: Mark Duffy <mduffy@quarrytech.com>
Subject: question on rfc2547bis re inter-AS
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

Hi this is a question for the authors of rfc2547bis regarding section 10 
Multi-AS Backbones.

In the approach "b) EBGP redistribution of labeled VPN-IPv4 routes from AS 
to neighboring AS":

               ... The ASBR then uses EBGP to redistribute those labeled
          VPN-IPv4 routes to an ASBR in another AS, which in turn
          distributes them to the PE routers in that AS, or perhaps to
          another ASBR which in turn distributes them ...

Is it the case that the ASBRs (one or both at each ebgp peering) replace 
the BGP next hop in the VPN-IPv4 routes with their own address?  And 
therefore they also assign a label to the VPN-IPv4 route and perform label 
switching on the "inner" (vpn) label while forwarding vpn packets?

The document doesn't state that but it would seem to follow from the normal 
bgp behavior of updating the next hop.  It would also explain why this 
section b) does not contain all the same discussion as section c) regarding 
the establishment of an "outer" LSP from ingress PE to egress PE.

Although for some reason section b) does say:

          This procedure requires that there be a label switched path
          leading from a packet's ingress PE to its egress PE.

Is that perhaps referring to the LSP represented by the inner (vpn) 
labels?  Because if the ASBRs are really switching on the vpn label, then 
there is not an outer LSP from ingress PE to egress PE.  Rather there is an 
outer LSP from ingress PE to ASBR, perhaps another outer LSP from ASBR to 
ASBR, and an outer LSP from ASBR to egress PE.

Thanks, Mark





From exim@www1.ietf.org  Thu May 13 02:37:02 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21912
	for <l3vpn-archive@odin.ietf.org>; Thu, 13 May 2004 02:37:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BO9oQ-0007Tk-4j
	for l3vpn-archive@odin.ietf.org; Thu, 13 May 2004 02:35:25 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D6ZLEE028735
	for l3vpn-archive@odin.ietf.org; Thu, 13 May 2004 02:35:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BO9kp-0006ox-D9
	for l3vpn-web-archive@optimus.ietf.org; Thu, 13 May 2004 02:31:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21654
	for <l3vpn-web-archive@ietf.org>; Thu, 13 May 2004 02:31:36 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BO9kl-0007Sq-HA
	for l3vpn-web-archive@ietf.org; Thu, 13 May 2004 02:31:35 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BO9jv-0006ym-00
	for l3vpn-web-archive@ietf.org; Thu, 13 May 2004 02:30:44 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BO9iy-0006L8-00
	for l3vpn-web-archive@ietf.org; Thu, 13 May 2004 02:29:44 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BO9gR-00062N-9R; Thu, 13 May 2004 02:27:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BO9fJ-0005qU-TI
	for l3vpn@optimus.ietf.org; Thu, 13 May 2004 02:25:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21442
	for <l3vpn@ietf.org>; Thu, 13 May 2004 02:25:54 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BO9fF-0004Pf-VB
	for l3vpn@ietf.org; Thu, 13 May 2004 02:25:54 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BO9eE-0003vk-00
	for l3vpn@ietf.org; Thu, 13 May 2004 02:24:51 -0400
Received: from [202.54.124.179] (helo=rediffmail.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1BO9dg-0003PR-00
	for l3vpn@ietf.org; Thu, 13 May 2004 02:24:17 -0400
Received: (qmail 10496 invoked by uid 510); 13 May 2004 06:23:43 -0000
Date: 13 May 2004 06:23:43 -0000
Message-ID: <20040513062343.10495.qmail@webmail10.rediffmail.com>
Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 13 may 2004 06:23:43 -0000
MIME-Version: 1.0
From: "Karthikeyan Subramaniam" <keyans@rediffmail.com>
Reply-To: "Karthikeyan Subramaniam" <keyans@rediffmail.com>
To: "Anand Oswal" <aoswal@redback.com>
Cc: erosen@cisco.com, l3vpn@ietf.org,
        "nabendu das" <dasnabendu123@hotmail.com>
Subject: Sham link query
Content-type: multipart/alternative;
	boundary="Next_1084429423---0-202.54.124.179-10493"
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_MESSAGE,
	MSGID_FROM_MTA_HEADER autolearn=no version=2.60

 This is a multipart mime message


--Next_1084429423---0-202.54.124.179-10493
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0A&nbsp; <BR>=0AHi,<BR>=0A<BR>=0A&nbsp; &nbsp; Can I configure more tha=
n one sham link between two PE's. For example <BR>=0A&nbsp; <BR>=0Aarea 120=
 sham-link 10.44.0.1 10.0.0.1 cost 1<BR>=0Aarea 100 sham-link 10.44.0.1 10.=
0.0.1 cost 1<BR>=0A<BR>=0Awith regards,<BR>=0AS.Karthikeyan.<BR>=0A<BR>=0A<=
BR>=0AOn Wed, 05 May 2004 Anand Oswal wrote :<BR>=0A&gt;Hi,<BR>=0A&gt;<BR>=
=0A&gt;The sham link end point will be&nbsp; a&nbsp; loopback interface (us=
ually)<BR>=0A&gt;associated with your VRF.<BR>=0A&gt;For manual config you =
will need to explicitly specify the endpoint<BR>=0A&gt;for the sham link.<B=
R>=0A&gt;<BR>=0A&gt;You can use BGP to carry this address to the remote PE =
VRF.<BR>=0A&gt;<BR>=0A&gt;So in your example below.<BR>=0A&gt;on PE1, you w=
ill have a manual config to specify<BR>=0A&gt;10.1.1.1 sham-source<BR>=0A&g=
t;10.1.1.2 sham-endpoint<BR>=0A&gt;<BR>=0A&gt;Hope that helps.<BR>=0A&gt;Th=
anks<BR>=0A&gt;Anand<BR>=0A&gt;<BR>=0A&gt;<BR>=0A&gt;<BR>=0A&gt;On Wed, 5 M=
ay 2004, nabendu das wrote:<BR>=0A&gt;<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;<BR>=
=0A&gt; &gt; HI<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; Cosidering the scenario bel=
ow, how data packets will be forwarded<BR>=0A&gt; &gt; through sham link<BR=
>=0A&gt; &gt;<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; H1<BR>=0A&gt; &gt; ----------=
--CE1----------PE1-----------P---------------P-------------PE2-------------=
-CE2<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; A) AUTO-configuration:=
<BR>=0A&gt; &gt; PE1 will distribute its sham link endpoint address(10.1.1.=
1) at PE1 as<BR>=0A&gt; &gt; VPN-IPV4 route through BGP along with BGP next=
-hop and label L1. So PE2 will<BR>=0A&gt; &gt; have a routing entry at its =
VRF for 10.1.1.1 with BGP next-hop and label. So<BR>=0A&gt; &gt; while forw=
arding packet to H1, it will find 10.1.1.1 as next-hop and for<BR>=0A&gt; &=
gt; 10.1.1.1 it will find the BGP next-hop and ..it will find the tunnel to=
 that<BR>=0A&gt; &gt; BGP next-hop and packet can be forwarded through the =
tunnel after<BR>=0A&gt; &gt; encapsulating the packet with L1 and tunnel fi=
rst next-hop label.<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; B) MANU=
AL configuration:<BR>=0A&gt; &gt; PE1 and PE2 both will be configured with =
sham link endpoint address as<BR>=0A&gt; &gt; 10.1.1.1 and 10.2.2.2 ..<BR>=
=0A&gt; &gt; But there will be no route at PE2 for PE1 endpoint address i.e=
 10.1.1. (as<BR>=0A&gt; &gt; we are manually configuring, VPN-IPV4 route fo=
r 10.1.1.1 will not be<BR>=0A&gt; &gt; advertised via BGP to PE2).... So wh=
en we do manual configuration for sham<BR>=0A&gt; &gt; link , how sham link=
 will be up and how data packets will be forwarded<BR>=0A&gt; &gt; through =
sham link ???????<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; TIA<BR>=
=0A&gt; &gt; Nabendu<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; ______________________=
___________________________________________<BR>=0A&gt; &gt; Best of Indian =
handicrafts.<BR>=0A&gt; &gt; http://www.fabmall.com/affiliatehtml/redir/nl8=
.asp At MSN Shopping.<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;<BR>=0A&gt;<BR>=0A&gt;=
<BR>=0A=0A</P>=0A=0A=0A<br>=0A<br><br>=0A<A target=3D"_blank" HREF=3D"http:=
//clients.rediff.com/signature/track_sig.asp"><IMG SRC=3D"http://ads.rediff=
.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbox.htm@Bottom" BOR=
DER=3D0 VSPACE=3D0 HSPACE=3D0></a>=0A
--Next_1084429423---0-202.54.124.179-10493
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

 =A0=0AHi,=0A=0A    Can I configure more than one sham link between two PE'=
s. For example =0A  =0Aarea 120 sham-link 10.44.0.1 10.0.0.1 cost 1=0Aarea =
100 sham-link 10.44.0.1 10.0.0.1 cost 1=0A=0Awith regards,=0AS.Karthikeyan.=
=0A=0A=0AOn Wed, 05 May 2004 Anand Oswal wrote :=0A>Hi,=0A>=0A>The sham lin=
k end point will be  a  loopback interface (usually)=0A>associated with you=
r VRF.=0A>For manual config you will need to explicitly specify the endpoin=
t=0A>for the sham link.=0A>=0A>You can use BGP to carry this address to the=
 remote PE VRF.=0A>=0A>So in your example below.=0A>on PE1, you will have a=
 manual config to specify=0A>10.1.1.1 sham-source=0A>10.1.1.2 sham-endpoint=
=0A>=0A>Hope that helps.=0A>Thanks=0A>Anand=0A>=0A>=0A>=0A>On Wed, 5 May 20=
04, nabendu das wrote:=0A>=0A> >=0A> >=0A> > HI=0A> >=0A> > Cosidering the =
scenario below, how data packets will be forwarded=0A> > through sham link=
=0A> >=0A> >=0A> > H1=0A> > ------------CE1----------PE1-----------P-------=
--------P-------------PE2--------------CE2=0A> >=0A> >=0A> > A) AUTO-config=
uration:=0A> > PE1 will distribute its sham link endpoint address(10.1.1.1)=
 at PE1 as=0A> > VPN-IPV4 route through BGP along with BGP next-hop and lab=
el L1. So PE2 will=0A> > have a routing entry at its VRF for 10.1.1.1 with =
BGP next-hop and label. So=0A> > while forwarding packet to H1, it will fin=
d 10.1.1.1 as next-hop and for=0A> > 10.1.1.1 it will find the BGP next-hop=
 and ..it will find the tunnel to that=0A> > BGP next-hop and packet can be=
 forwarded through the tunnel after=0A> > encapsulating the packet with L1 =
and tunnel first next-hop label.=0A> >=0A> >=0A> > B) MANUAL configuration:=
=0A> > PE1 and PE2 both will be configured with sham link endpoint address =
as=0A> > 10.1.1.1 and 10.2.2.2 ..=0A> > But there will be no route at PE2 f=
or PE1 endpoint address i.e 10.1.1. (as=0A> > we are manually configuring, =
VPN-IPV4 route for 10.1.1.1 will not be=0A> > advertised via BGP to PE2)...=
. So when we do manual configuration for sham=0A> > link , how sham link wi=
ll be up and how data packets will be forwarded=0A> > through sham link ???=
????=0A> >=0A> >=0A> > TIA=0A> > Nabendu=0A> >=0A> > ______________________=
___________________________________________=0A> > Best of Indian handicraft=
s.=0A> > http://www.fabmall.com/affiliatehtml/redir/nl8.asp At MSN Shopping=
.=0A> >=0A> >=0A>=0A>=0A=0A=0A=0A
--Next_1084429423---0-202.54.124.179-10493--





From exim@www1.ietf.org  Thu May 13 14:45:12 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04943
	for <l3vpn-archive@odin.ietf.org>; Thu, 13 May 2004 14:45:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOL8z-00052c-PA
	for l3vpn-archive@odin.ietf.org; Thu, 13 May 2004 14:41:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DIfL1Z019378
	for l3vpn-archive@odin.ietf.org; Thu, 13 May 2004 14:41:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOL4K-0002u5-Ks
	for l3vpn-web-archive@optimus.ietf.org; Thu, 13 May 2004 14:36:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04101
	for <l3vpn-web-archive@ietf.org>; Thu, 13 May 2004 14:36:29 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BOL4I-0002FP-1m
	for l3vpn-web-archive@ietf.org; Thu, 13 May 2004 14:36:30 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BOL2T-0001N7-00
	for l3vpn-web-archive@ietf.org; Thu, 13 May 2004 14:34:38 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BOL0s-0000Hb-00
	for l3vpn-web-archive@ietf.org; Thu, 13 May 2004 14:32:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOKoo-0003R9-F2; Thu, 13 May 2004 14:20:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOKNH-0007wr-Og
	for l3vpn@optimus.ietf.org; Thu, 13 May 2004 13:52:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28546
	for <l3vpn@ietf.org>; Thu, 13 May 2004 13:52:01 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BOKNF-0003TL-Dt
	for l3vpn@ietf.org; Thu, 13 May 2004 13:52:01 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BOKLV-0002Kp-00
	for l3vpn@ietf.org; Thu, 13 May 2004 13:50:14 -0400
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BOKJX-00017L-00
	for l3vpn@ietf.org; Thu, 13 May 2004 13:48:12 -0400
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP
	id 3505991A881; Thu, 13 May 2004 10:48:11 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1])
 by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 14407-08; Thu, 13 May 2004 10:48:10 -0700 (PDT)
Received: from redback.com (dhcp-41-22.redback.com [155.53.41.22])
	by prattle.redback.com (Postfix) with ESMTP
	id DB0C091A880; Thu, 13 May 2004 10:48:10 -0700 (PDT)
Message-ID: <40A3B4DB.C73B5B0@redback.com>
Date: Thu, 13 May 2004 10:48:11 -0700
From: Anand Oswal <aoswal@redback.com>
Organization: Redback Networks 
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Karthikeyan Subramaniam <keyans@rediffmail.com>
Cc: erosen@cisco.com, l3vpn@ietf.org, nabendu das <dasnabendu123@hotmail.com>
Subject: Re: Sham link query
References: <20040513062343.10495.qmail@webmail10.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at redback.com
Content-Transfer-Encoding: 7bit
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


A sham-link is required between any two VPN sites (VRF's) belonging 
to the same area and they also have a backdoor link between the CE
routers.
If a backdoor link is not present between the CE routers, sham-link is 
not required.

Sham Link source and endpoint are part of the VRF.
Sham link area is the same as the area towards the CE.

You could have more than one sham link between the same source
and endpoint in the same area, but dont think it would be very useful.

Hope that helps.
Thanks
Anand



Karthikeyan Subramaniam wrote:
> 
> 
> Hi,
> 
>     Can I configure more than one sham link between two PE's. For example
> 
> area 120 sham-link 10.44.0.1 10.0.0.1 cost 1
> area 100 sham-link 10.44.0.1 10.0.0.1 cost 1
> 
> with regards,
> S.Karthikeyan.
> 
> On Wed, 05 May 2004 Anand Oswal wrote :
> >Hi,
> >
> >The sham link end point will be  a  loopback interface (usually)
> >associated with your VRF.
> >For manual config you will need to explicitly specify the endpoint
> >for the sham link.
> >
> >You can use BGP to carry this address to the remote PE VRF.
> >
> >So in your example below.
> >on PE1, you will have a manual config to specify
> >10.1.1.1 sham-source
> >10.1.1.2 sham-endpoint
> >
> >Hope that helps.
> >Thanks
> >Anand
> >
> >
> >
> >On Wed, 5 May 2004, nabendu das wrote:
> >
> > >
> > >
> > > HI
> > >
> > > Cosidering the scenario below, how data packets will be forwarded
> > > through sham link
> > >
> > >
> > > H1
> > > ------------CE1----------PE1-----------P---------------P-------------PE2--------------CE2
> > >
> > >
> > > A) AUTO-configuration:
> > > PE1 will distribute its sham link endpoint address(10.1.1.1) at PE1 as
> > > VPN-IPV4 route through BGP along with BGP next-hop and label L1. So PE2 will
> > > have a routing entry at its VRF for 10.1.1.1 with BGP next-hop and label. So
> > > while forwarding packet to H1, it will find 10.1.1.1 as next-hop and for
> > > 10.1.1.1 it will find the BGP next-hop and ..it will find the tunnel to that
> > > BGP next-hop and packet can be forwarded through the tunnel after
> > > encapsulating the packet with L1 and tunnel first next-hop label.
> > >
> > >
> > > B) MANUAL configuration:
> > > PE1 and PE2 both will be configured with sham link endpoint address as
> > > 10.1.1.1 and 10.2.2.2 ..
> > > But there will be no route at PE2 for PE1 endpoint address i.e 10.1.1. (as
> > > we are manually configuring, VPN-IPV4 route for 10.1.1.1 will not be
> > > advertised via BGP to PE2).... So when we do manual configuration for sham
> > > link , how sham link will be up and how data packets will be forwarded
> > > through sham link ???????
> > >
> > >
> > > TIA
> > > Nabendu
> > >
> > > _________________________________________________________________
> > > Best of Indian handicrafts.
> > > http://www.fabmall.com/affiliatehtml/redir/nl8.asp At MSN Shopping.
> > >
> > >
> >
> >




From exim@www1.ietf.org  Thu May 13 17:41:42 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18343
	for <l3vpn-archive@odin.ietf.org>; Thu, 13 May 2004 17:41:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BONmo-0005Fu-D2
	for l3vpn-archive@odin.ietf.org; Thu, 13 May 2004 17:30:38 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DLUcHs020203
	for l3vpn-archive@odin.ietf.org; Thu, 13 May 2004 17:30:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BONiB-0002IE-9Q
	for l3vpn-web-archive@optimus.ietf.org; Thu, 13 May 2004 17:25:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16110
	for <l3vpn-web-archive@ietf.org>; Thu, 13 May 2004 17:25:47 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BONi9-0001wx-1O
	for l3vpn-web-archive@ietf.org; Thu, 13 May 2004 17:25:49 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BONf1-0000q1-00
	for l3vpn-web-archive@ietf.org; Thu, 13 May 2004 17:22:36 -0400
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BONca-00076P-01
	for l3vpn-web-archive@ietf.org; Thu, 13 May 2004 17:20:04 -0400
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1BONMt-0000jz-Og
	for l3vpn-web-archive@ietf.org; Thu, 13 May 2004 17:03:51 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOMlB-00059l-HE; Thu, 13 May 2004 16:24:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOMAq-00055m-EE
	for l3vpn@optimus.ietf.org; Thu, 13 May 2004 15:47:20 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09340;
	Thu, 13 May 2004 15:47:17 -0400 (EDT)
Message-Id: <200405131947.PAA09340@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: l3vpn@ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-04.txt
Date: Thu, 13 May 2004 15:47:17 -0400
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART,
	NO_REAL_NAME autolearn=no version=2.60

--NextPart
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA09341
Content-Transfer-Encoding: quoted-printable

A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
This draft is a work item of the Layer 3 Virtual Private Networks Working=
 Group of the IETF.

	Title		: Using BGP as an Auto-Discovery Mechanism for Layer-3 and=20
			  Layer-2 VPNs
	Author(s)	: H. Ould-Brahim, et al.=20
	Filename	: draft-ietf-l3vpn-bgpvpn-auto-04.txt
	Pages		: 14
	Date		: 2004-5-13
=09
In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider=20
   Edge (PE) devices attached to a common VPN must exchange certain=20
   information as a prerequisite to establish VPN-specific=20
   connectivity. The purpose of this draft is to define a BGP based=20
   auto-discovery mechanism for both layer-2 VPN architectures and=20
   layer-3 VPNs (Virtual Routers =FBVR [VPN-VR]). This mechanism is based=
=20
   on the approach used by BGP/MPLS-IP-VPN [BGP/MPLS-IP-VPN] for=20
   distributing VPN routing information within the service provider(s).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-04.txt

To remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.org with the word unsubscribe in the body of th=
e message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the usern=
ame
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-l3vpn-bgpvpn-auto-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-04.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-5-13160853.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-l3vpn-bgpvpn-auto-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-5-13160853.I-D@ietf.org>

--OtherAccess--

--NextPart--






From exim@www1.ietf.org  Fri May 14 03:15:05 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01714
	for <l3vpn-archive@odin.ietf.org>; Fri, 14 May 2004 03:15:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOWnN-0002iD-V8
	for l3vpn-archive@odin.ietf.org; Fri, 14 May 2004 03:07:50 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E77nRt010424
	for l3vpn-archive@odin.ietf.org; Fri, 14 May 2004 03:07:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOWlX-00025u-MA
	for l3vpn-web-archive@optimus.ietf.org; Fri, 14 May 2004 03:05:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00981
	for <l3vpn-web-archive@ietf.org>; Fri, 14 May 2004 03:05:51 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BOWlT-0003Tc-O6
	for l3vpn-web-archive@ietf.org; Fri, 14 May 2004 03:05:51 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BOWkM-0002vZ-00
	for l3vpn-web-archive@ietf.org; Fri, 14 May 2004 03:04:43 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BOWjI-0002IQ-00
	for l3vpn-web-archive@ietf.org; Fri, 14 May 2004 03:03:36 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOWb2-0005Dt-4e; Fri, 14 May 2004 02:55:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOWWq-000249-2P
	for l3vpn@optimus.ietf.org; Fri, 14 May 2004 02:50:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00505
	for <l3vpn@ietf.org>; Fri, 14 May 2004 02:50:40 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BOWWm-0003E3-6P
	for l3vpn@ietf.org; Fri, 14 May 2004 02:50:40 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BOWVo-0002gr-00
	for l3vpn@ietf.org; Fri, 14 May 2004 02:49:41 -0400
Received: from [202.54.124.151] (helo=rediffmail.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1BOWUq-0001eY-00
	for l3vpn@ietf.org; Fri, 14 May 2004 02:48:40 -0400
Received: (qmail 20086 invoked by uid 510); 14 May 2004 06:48:07 -0000
Date: 14 May 2004 06:48:07 -0000
Message-ID: <20040514064807.20085.qmail@webmail6.rediffmail.com>
Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 14 may 2004 06:48:07 -0000
MIME-Version: 1.0
From: "Karthikeyan Subramaniam" <keyans@rediffmail.com>
Reply-To: "Karthikeyan Subramaniam" <keyans@rediffmail.com>
To: "Anand Oswal" <aoswal@redback.com>
Cc: erosen@cisco.com, l3vpn@ietf.org,
        "nabendu das" <dasnabendu123@hotmail.com>
Subject: Re: Re: Sham link query
Content-type: multipart/alternative;
	boundary="Next_1084517287---0-202.54.124.151-20081"
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_MESSAGE,
	MSGID_FROM_MTA_HEADER autolearn=no version=2.60

 This is a multipart mime message


--Next_1084517287---0-202.54.124.151-20081
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<P>=0AAnand,<BR>=0A<BR>=0A&nbsp; My question was, is it valid to configure =
sham link between the same source and endpoint but each sham link belonging=
 to different area?<BR>=0ALike ...<BR>=0A area 120 sham-link 10.44.0.1 10.0=
.0.1 cost 1<BR>=0A area 100 sham-link 10.44.0.1 10.0.0.1 cost 1<BR>=0A<BR>=
=0AAssuming backdoor link exist for two areas.<BR>=0A<BR>=0Awith regards,<B=
R>=0AS.Karthikeyan.<BR>=0A<BR>=0A<BR>=0A&gt;If a backdoor link is not prese=
nt between the CE routers, sham-link is<BR>=0A&gt;not required.<BR>=0A&gt;<=
BR>=0A&gt;Sham Link source and endpoint are part of the VRF.<BR>=0A&gt;Sham=
 link area is the same as the area towards the CE.<BR>=0A&gt;<BR>=0A&gt;You=
 could have more than one sham link between the same source<BR>=0A&gt;and e=
ndpoint in the same area, but dont think it would be very useful.<BR>=0A&gt=
;<BR>=0A&gt;Hope that helps.<BR>=0A&gt;Thanks<BR>=0A&gt;Anand<BR>=0A&gt;<BR=
>=0A&gt;<BR>=0A&gt;<BR>=0A&gt;Karthikeyan Subramaniam wrote:<BR>=0A&gt; &gt=
;<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; Hi,<BR>=0A&gt; &gt;<BR>=0A&gt; &gt;&nbsp;=
 &nbsp;  Can I configure more than one sham link between two PE's. For exam=
ple<BR>=0A&gt; &gt;<BR>=0A&gt; &gt; area 120 sham-link 10.44.0.1 10.0.0.1 c=
ost 1<BR>=0A&gt; &gt; area 100 sham-link 10.44.0.1 10.0.0.1 cost 1<BR>=0A&g=
t; &gt;<BR>=0A&gt; &gt; with regards,<BR>=0A&gt; &gt; S.Karthikeyan.<BR>=0A=
&gt; &gt;<BR>=0A&gt; &gt; On Wed, 05 May 2004 Anand Oswal wrote :<BR>=0A&gt=
; &gt; &gt;Hi,<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt;The sham link end p=
oint will be&nbsp; a&nbsp; loopback interface (usually)<BR>=0A&gt; &gt; &gt=
;associated with your VRF.<BR>=0A&gt; &gt; &gt;For manual config you will n=
eed to explicitly specify the endpoint<BR>=0A&gt; &gt; &gt;for the sham lin=
k.<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt;You can use BGP to carry this a=
ddress to the remote PE VRF.<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt;So in=
 your example below.<BR>=0A&gt; &gt; &gt;on PE1, you will have a manual con=
fig to specify<BR>=0A&gt; &gt; &gt;10.1.1.1 sham-source<BR>=0A&gt; &gt; &gt=
;10.1.1.2 sham-endpoint<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt;Hope that =
helps.<BR>=0A&gt; &gt; &gt;Thanks<BR>=0A&gt; &gt; &gt;Anand<BR>=0A&gt; &gt;=
 &gt;<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt;On Wed,=
 5 May 2004, nabendu das wrote:<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt; &=
gt;<BR>=0A&gt; &gt; &gt; &gt;<BR>=0A&gt; &gt; &gt; &gt; HI<BR>=0A&gt; &gt; =
&gt; &gt;<BR>=0A&gt; &gt; &gt; &gt; Cosidering the scenario below, how data=
 packets will be forwarded<BR>=0A&gt; &gt; &gt; &gt; through sham link<BR>=
=0A&gt; &gt; &gt; &gt;<BR>=0A&gt; &gt; &gt; &gt;<BR>=0A&gt; &gt; &gt; &gt; =
H1<BR>=0A&gt; &gt; &gt; &gt; ------------CE1----------PE1-----------P------=
---------P-------------PE2--------------CE2<BR>=0A&gt; &gt; &gt; &gt;<BR>=
=0A&gt; &gt; &gt; &gt;<BR>=0A&gt; &gt; &gt; &gt; A) AUTO-configuration:<BR>=
=0A&gt; &gt; &gt; &gt; PE1 will distribute its sham link endpoint address(1=
0.1.1.1) at PE1 as<BR>=0A&gt; &gt; &gt; &gt; VPN-IPV4 route through BGP alo=
ng with BGP next-hop and label L1. So PE2 will<BR>=0A&gt; &gt; &gt; &gt; ha=
ve a routing entry at its VRF for 10.1.1.1 with BGP next-hop and label. So<=
BR>=0A&gt; &gt; &gt; &gt; while forwarding packet to H1, it will find 10.1.=
1.1 as next-hop and for<BR>=0A&gt; &gt; &gt; &gt; 10.1.1.1 it will find the=
 BGP next-hop and ..it will find the tunnel to that<BR>=0A&gt; &gt; &gt; &g=
t; BGP next-hop and packet can be forwarded through the tunnel after<BR>=0A=
&gt; &gt; &gt; &gt; encapsulating the packet with L1 and tunnel first next-=
hop label.<BR>=0A&gt; &gt; &gt; &gt;<BR>=0A&gt; &gt; &gt; &gt;<BR>=0A&gt; &=
gt; &gt; &gt; B) MANUAL configuration:<BR>=0A&gt; &gt; &gt; &gt; PE1 and PE=
2 both will be configured with sham link endpoint address as<BR>=0A&gt; &gt=
; &gt; &gt; 10.1.1.1 and 10.2.2.2 ..<BR>=0A&gt; &gt; &gt; &gt; But there wi=
ll be no route at PE2 for PE1 endpoint address i.e 10.1.1. (as<BR>=0A&gt; &=
gt; &gt; &gt; we are manually configuring, VPN-IPV4 route for 10.1.1.1 will=
 not be<BR>=0A&gt; &gt; &gt; &gt; advertised via BGP to PE2).... So when we=
 do manual configuration for sham<BR>=0A&gt; &gt; &gt; &gt; link , how sham=
 link will be up and how data packets will be forwarded<BR>=0A&gt; &gt; &gt=
; &gt; through sham link ???????<BR>=0A&gt; &gt; &gt; &gt;<BR>=0A&gt; &gt; =
&gt; &gt;<BR>=0A&gt; &gt; &gt; &gt; TIA<BR>=0A&gt; &gt; &gt; &gt; Nabendu<B=
R>=0A&gt; &gt; &gt; &gt;<BR>=0A&gt; &gt; &gt; &gt; ________________________=
_________________________________________<BR>=0A&gt; &gt; &gt; &gt; Best of=
 Indian handicrafts.<BR>=0A&gt; &gt; &gt; &gt; http://www.fabmall.com/affil=
iatehtml/redir/nl8.asp At MSN Shopping.<BR>=0A&gt; &gt; &gt; &gt;<BR>=0A&gt=
; &gt; &gt; &gt;<BR>=0A&gt; &gt; &gt;<BR>=0A&gt; &gt; &gt;<BR>=0A&gt;<BR>=
=0A=0A</P>=0A=0A=0A<br>=0A<br><br>=0A<A target=3D"_blank" HREF=3D"http://cl=
ients.rediff.com/signature/track_sig.asp"><IMG SRC=3D"http://ads.rediff.com=
/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbox.htm@Bottom" BORDER=
=3D0 VSPACE=3D0 HSPACE=3D0></a>=0A
--Next_1084517287---0-202.54.124.151-20081
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Anand,=0A=0A  My question was, is it valid to configure sham link between t=
he same source and endpoint but each sham link belonging to different area?=
=0ALike ...=0A area 120 sham-link 10.44.0.1 10.0.0.1 cost 1=0A area 100 sha=
m-link 10.44.0.1 10.0.0.1 cost 1=0A=0AAssuming backdoor link exist for two =
areas.=0A=0Awith regards,=0AS.Karthikeyan.=0A=0A=0A>If a backdoor link is n=
ot present between the CE routers, sham-link is=0A>not required.=0A>=0A>Sha=
m Link source and endpoint are part of the VRF.=0A>Sham link area is the sa=
me as the area towards the CE.=0A>=0A>You could have more than one sham lin=
k between the same source=0A>and endpoint in the same area, but dont think =
it would be very useful.=0A>=0A>Hope that helps.=0A>Thanks=0A>Anand=0A>=0A>=
=0A>=0A>Karthikeyan Subramaniam wrote:=0A> >=0A> >=0A> > Hi,=0A> >=0A> >   =
  Can I configure more than one sham link between two PE's. For example=0A>=
 >=0A> > area 120 sham-link 10.44.0.1 10.0.0.1 cost 1=0A> > area 100 sham-l=
ink 10.44.0.1 10.0.0.1 cost 1=0A> >=0A> > with regards,=0A> > S.Karthikeyan=
.=0A> >=0A> > On Wed, 05 May 2004 Anand Oswal wrote :=0A> > >Hi,=0A> > >=0A=
> > >The sham link end point will be  a  loopback interface (usually)=0A> >=
 >associated with your VRF.=0A> > >For manual config you will need to expli=
citly specify the endpoint=0A> > >for the sham link.=0A> > >=0A> > >You can=
 use BGP to carry this address to the remote PE VRF.=0A> > >=0A> > >So in y=
our example below.=0A> > >on PE1, you will have a manual config to specify=
=0A> > >10.1.1.1 sham-source=0A> > >10.1.1.2 sham-endpoint=0A> > >=0A> > >H=
ope that helps.=0A> > >Thanks=0A> > >Anand=0A> > >=0A> > >=0A> > >=0A> > >O=
n Wed, 5 May 2004, nabendu das wrote:=0A> > >=0A> > > >=0A> > > >=0A> > > >=
 HI=0A> > > >=0A> > > > Cosidering the scenario below, how data packets wil=
l be forwarded=0A> > > > through sham link=0A> > > >=0A> > > >=0A> > > > H1=
=0A> > > > ------------CE1----------PE1-----------P---------------P--------=
-----PE2--------------CE2=0A> > > >=0A> > > >=0A> > > > A) AUTO-configurati=
on:=0A> > > > PE1 will distribute its sham link endpoint address(10.1.1.1) =
at PE1 as=0A> > > > VPN-IPV4 route through BGP along with BGP next-hop and =
label L1. So PE2 will=0A> > > > have a routing entry at its VRF for 10.1.1.=
1 with BGP next-hop and label. So=0A> > > > while forwarding packet to H1, =
it will find 10.1.1.1 as next-hop and for=0A> > > > 10.1.1.1 it will find t=
he BGP next-hop and ..it will find the tunnel to that=0A> > > > BGP next-ho=
p and packet can be forwarded through the tunnel after=0A> > > > encapsulat=
ing the packet with L1 and tunnel first next-hop label.=0A> > > >=0A> > > >=
=0A> > > > B) MANUAL configuration:=0A> > > > PE1 and PE2 both will be conf=
igured with sham link endpoint address as=0A> > > > 10.1.1.1 and 10.2.2.2 .=
.=0A> > > > But there will be no route at PE2 for PE1 endpoint address i.e =
10.1.1. (as=0A> > > > we are manually configuring, VPN-IPV4 route for 10.1.=
1.1 will not be=0A> > > > advertised via BGP to PE2).... So when we do manu=
al configuration for sham=0A> > > > link , how sham link will be up and how=
 data packets will be forwarded=0A> > > > through sham link ???????=0A> > >=
 >=0A> > > >=0A> > > > TIA=0A> > > > Nabendu=0A> > > >=0A> > > > __________=
_______________________________________________________=0A> > > > Best of I=
ndian handicrafts.=0A> > > > http://www.fabmall.com/affiliatehtml/redir/nl8=
.asp At MSN Shopping.=0A> > > >=0A> > > >=0A> > >=0A> > >=0A>=0A=0A=0A=0A
--Next_1084517287---0-202.54.124.151-20081--





From exim@www1.ietf.org  Fri May 14 10:51:10 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26347
	for <l3vpn-archive@odin.ietf.org>; Fri, 14 May 2004 10:51:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOdyL-00013j-PO
	for l3vpn-archive@odin.ietf.org; Fri, 14 May 2004 10:47:39 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EElbbm004070
	for l3vpn-archive@odin.ietf.org; Fri, 14 May 2004 10:47:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOdwp-0000jg-FG
	for l3vpn-web-archive@optimus.ietf.org; Fri, 14 May 2004 10:46:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26127
	for <l3vpn-web-archive@ietf.org>; Fri, 14 May 2004 10:45:59 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BOdwn-0005Wt-2v
	for l3vpn-web-archive@ietf.org; Fri, 14 May 2004 10:46:01 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BOdvn-00051y-00
	for l3vpn-web-archive@ietf.org; Fri, 14 May 2004 10:44:59 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BOduh-0004G4-00
	for l3vpn-web-archive@ietf.org; Fri, 14 May 2004 10:43:51 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOdrz-0008CF-BR; Fri, 14 May 2004 10:41:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOdr0-0007wE-MI
	for l3vpn@optimus.ietf.org; Fri, 14 May 2004 10:40:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25934
	for <l3vpn@ietf.org>; Fri, 14 May 2004 10:39:58 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BOdqy-0002ag-4Z
	for l3vpn@ietf.org; Fri, 14 May 2004 10:40:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BOdq7-00026T-00
	for l3vpn@ietf.org; Fri, 14 May 2004 10:39:08 -0400
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BOdpA-0001bN-00
	for l3vpn@ietf.org; Fri, 14 May 2004 10:38:08 -0400
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP
	id B30599F3423; Fri, 14 May 2004 07:38:06 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1])
 by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 00156-09; Fri, 14 May 2004 07:38:06 -0700 (PDT)
Received: from malt (malt.redback.com [155.53.12.41])
	by prattle.redback.com (Postfix) with ESMTP
	id 51DEC9F3430; Fri, 14 May 2004 07:38:06 -0700 (PDT)
Date: Fri, 14 May 2004 07:38:06 -0700 (PDT)
From: Anand Oswal <aoswal@redback.com>
X-Sender: aoswal@malt
To: Karthikeyan Subramaniam <keyans@rediffmail.com>
Cc: erosen@cisco.com, l3vpn@ietf.org, nabendu das <dasnabendu123@hotmail.com>
Subject: Re: Re: Sham link query
In-Reply-To: <20040514064807.20085.qmail@webmail6.rediffmail.com>
Message-ID: <Pine.GSO.4.10.10405140737380.27307-100000@malt>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at redback.com
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60


Yes, If they are part of different VRF's 

Anand

On 14 May 2004, Karthikeyan Subramaniam wrote:

> Anand,

  My question was, is it valid to configure sham link between the same source and endpoint but each sham link belonging to different area?
Like ...
 area 120 sham-link 10.44.0.1 10.0.0.1 cost 1
 area 100 sham-link 10.44.0.1 10.0.0.1 cost 1

Assuming backdoor link exist for two areas.

with regards,
S.Karthikeyan.


>If a backdoor link is not present between the CE routers, sham-link is
>not required.
>
>Sham Link source and endpoint are part of the VRF.
>Sham link area is the same as the area towards the CE.
>
>You could have more than one sham link between the same source
>and endpoint in the same area, but dont think it would be very useful.
>
>Hope that helps.
>Thanks
>Anand
>
>
>
>Karthikeyan Subramaniam wrote:
> >
> >
> > Hi,
> >
> >     Can I configure more than one sham link between two PE's. For example
> >
> > area 120 sham-link 10.44.0.1 10.0.0.1 cost 1
> > area 100 sham-link 10.44.0.1 10.0.0.1 cost 1
> >
> > with regards,
> > S.Karthikeyan.
> >
> > On Wed, 05 May 2004 Anand Oswal wrote :
> > >Hi,
> > >
> > >The sham link end point will be  a  loopback interface (usually)
> > >associated with your VRF.
> > >For manual config you will need to explicitly specify the endpoint
> > >for the sham link.
> > >
> > >You can use BGP to carry this address to the remote PE VRF.
> > >
> > >So in your example below.
> > >on PE1, you will have a manual config to specify
> > >10.1.1.1 sham-source
> > >10.1.1.2 sham-endpoint
> > >
> > >Hope that helps.
> > >Thanks
> > >Anand
> > >
> > >
> > >
> > >On Wed, 5 May 2004, nabendu das wrote:
> > >
> > > >
> > > >
> > > > HI
> > > >
> > > > Cosidering the scenario below, how data packets will be forwarded
> > > > through sham link
> > > >
> > > >
> > > > H1
> > > > ------------CE1----------PE1-----------P---------------P-------------PE2--------------CE2
> > > >
> > > >
> > > > A) AUTO-configuration:
> > > > PE1 will distribute its sham link endpoint address(10.1.1.1) at PE1 as
> > > > VPN-IPV4 route through BGP along with BGP next-hop and label L1. So PE2 will
> > > > have a routing entry at its VRF for 10.1.1.1 with BGP next-hop and label. So
> > > > while forwarding packet to H1, it will find 10.1.1.1 as next-hop and for
> > > > 10.1.1.1 it will find the BGP next-hop and ..it will find the tunnel to that
> > > > BGP next-hop and packet can be forwarded through the tunnel after
> > > > encapsulating the packet with L1 and tunnel first next-hop label.
> > > >
> > > >
> > > > B) MANUAL configuration:
> > > > PE1 and PE2 both will be configured with sham link endpoint address as
> > > > 10.1.1.1 and 10.2.2.2 ..
> > > > But there will be no route at PE2 for PE1 endpoint address i.e 10.1.1. (as
> > > > we are manually configuring, VPN-IPV4 route for 10.1.1.1 will not be
> > > > advertised via BGP to PE2).... So when we do manual configuration for sham
> > > > link , how sham link will be up and how data packets will be forwarded
> > > > through sham link ???????
> > > >
> > > >
> > > > TIA
> > > > Nabendu
> > > >
> > > > _________________________________________________________________
> > > > Best of Indian handicrafts.
> > > > http://www.fabmall.com/affiliatehtml/redir/nl8.asp At MSN Shopping.
> > > >
> > > >
> > >
> > >
>








From exim@www1.ietf.org  Fri May 14 17:06:44 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27051
	for <l3vpn-archive@odin.ietf.org>; Fri, 14 May 2004 17:06:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOjfn-0007dy-NG
	for l3vpn-archive@odin.ietf.org; Fri, 14 May 2004 16:52:51 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EKqpMd029382
	for l3vpn-archive@odin.ietf.org; Fri, 14 May 2004 16:52:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOjaa-00046T-1e
	for l3vpn-web-archive@optimus.ietf.org; Fri, 14 May 2004 16:47:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24530
	for <l3vpn-web-archive@ietf.org>; Fri, 14 May 2004 16:47:24 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BOjaY-0000nY-5u
	for l3vpn-web-archive@ietf.org; Fri, 14 May 2004 16:47:26 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BOjWP-00079f-00
	for l3vpn-web-archive@ietf.org; Fri, 14 May 2004 16:43:09 -0400
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BOjU2-00068T-00
	for l3vpn-web-archive@ietf.org; Fri, 14 May 2004 16:40:42 -0400
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1BOjMc-0001l9-98
	for l3vpn-web-archive@ietf.org; Fri, 14 May 2004 16:33:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOig3-0005Lx-Nu; Fri, 14 May 2004 15:49:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BOiXM-0003VH-5X
	for l3vpn@optimus.ietf.org; Fri, 14 May 2004 15:40:04 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18025;
	Fri, 14 May 2004 15:40:01 -0400 (EDT)
Message-Id: <200405141940.PAA18025@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: l3vpn@ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-l3vpn-mpls-vpn-mib-03.txt
Date: Fri, 14 May 2004 15:40:01 -0400
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART,
	NO_REAL_NAME autolearn=no version=2.60

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF.

	Title		: MPLS/BGP Layer 3 Virtual Private Network Management 
			  Information Base
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-l3vpn-mpls-vpn-mib-03.txt
	Pages		: 36
	Date		: 2004-5-14
	
   This memo defines an portion of the Management
   Information Base (MIB) for use with network management protocols
   in the Internet community.  In particular, it describes managed
   objects to configure and/or monitor Multi-protocol Label
   Switching Layer-3 Virtual Private Networks on a
   Multi-Protocol Label Switching (MPLS) Label Switching Router 
   (LSR) supporting this feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-l3vpn-mpls-vpn-mib-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-5-14155110.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-l3vpn-mpls-vpn-mib-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-5-14155110.I-D@ietf.org>

--OtherAccess--

--NextPart--






From exim@www1.ietf.org  Mon May 17 18:12:41 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07595
	for <l3vpn-archive@odin.ietf.org>; Mon, 17 May 2004 18:12:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BPq9B-0000iX-LD
	for l3vpn-archive@odin.ietf.org; Mon, 17 May 2004 17:59:45 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HLxjAr002743
	for l3vpn-archive@odin.ietf.org; Mon, 17 May 2004 17:59:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BPpwG-0002uy-KR
	for l3vpn-web-archive@optimus.ietf.org; Mon, 17 May 2004 17:46:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03628
	for <l3vpn-web-archive@ietf.org>; Mon, 17 May 2004 17:46:21 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BPpwE-0006u3-5B
	for l3vpn-web-archive@ietf.org; Mon, 17 May 2004 17:46:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BPprE-0005V3-00
	for l3vpn-web-archive@ietf.org; Mon, 17 May 2004 17:41:13 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BPplo-0004Go-00
	for l3vpn-web-archive@ietf.org; Mon, 17 May 2004 17:35:36 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BPpKR-00065a-Eh; Mon, 17 May 2004 17:07:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BPoGZ-0003Hd-NQ
	for l3vpn@optimus.ietf.org; Mon, 17 May 2004 15:59:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20568
	for <l3vpn@ietf.org>; Mon, 17 May 2004 15:59:13 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BPoGY-0003wv-2o
	for l3vpn@ietf.org; Mon, 17 May 2004 15:59:14 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BPoFY-0003bi-00
	for l3vpn@ietf.org; Mon, 17 May 2004 15:58:13 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BPoER-0002w7-00
	for l3vpn@ietf.org; Mon, 17 May 2004 15:57:03 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i4HJuX950454
	for <l3vpn@ietf.org>; Mon, 17 May 2004 12:56:33 -0700 (PDT)
	(envelope-from rcallon@juniper.net)
Received: from rcallon-lt.juniper.net ([10.10.132.242])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4HJuSJ10806
	for <l3vpn@ietf.org>; Mon, 17 May 2004 12:56:28 -0700 (PDT)
	(envelope-from rcallon@juniper.net)
Message-Id: <4.3.2.20040517123351.02f346d8@zircon.juniper.net>
X-Sender: rcallon@zircon.juniper.net (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Mon, 17 May 2004 13:01:17 -0400
To: l3vpn@ietf.org
From: Ross Callon <rcallon@juniper.net>
Subject: Re: draft-marques-ppvpn-rt-constrain-01
In-Reply-To: <000f01c40bd3$024fdd90$f37032a6@mcilink.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,FORGED_MUA_EUDORA 
	autolearn=no version=2.60

At 10:50 PM 3/16/2004 -0500, Ronald Bonica wrote:
>Folks,
>
>I would like to propose that the working group adopt
>draft-marques-ppvpn-rt-constrain-01 as a WG item. I feel that it fits within
>the current charter because it contributes to the scaling properties of the
>BGP/MPLS VPN solution.
>
>/speaking as individual contributor
>
>----------------
>Ronald P. Bonica
>----------------

All of the comments received were either positive or informational.
Thus the draft is accepted as a working group document.

I will ask the authors to update it in response to the comments
received. 

Thanks, Ross





From exim@www1.ietf.org  Mon May 17 18:29:59 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09354
	for <l3vpn-archive@odin.ietf.org>; Mon, 17 May 2004 18:29:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BPqJS-0008Mn-Nn
	for l3vpn-archive@odin.ietf.org; Mon, 17 May 2004 18:10:22 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HMAMi1032152
	for l3vpn-archive@odin.ietf.org; Mon, 17 May 2004 18:10:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BPq7X-0008Is-Sv
	for l3vpn-web-archive@optimus.ietf.org; Mon, 17 May 2004 17:58:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05691
	for <l3vpn-web-archive@ietf.org>; Mon, 17 May 2004 17:58:00 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BPq7V-0002dr-A5
	for l3vpn-web-archive@ietf.org; Mon, 17 May 2004 17:58:01 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BPq5O-00021X-00
	for l3vpn-web-archive@ietf.org; Mon, 17 May 2004 17:55:51 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BPq3I-0001N6-00
	for l3vpn-web-archive@ietf.org; Mon, 17 May 2004 17:53:40 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BPpn1-0005Y2-DD; Mon, 17 May 2004 17:36:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BPpN0-0007iH-2X
	for l3vpn@optimus.ietf.org; Mon, 17 May 2004 17:09:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28255
	for <l3vpn@ietf.org>; Mon, 17 May 2004 17:09:54 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BPpMx-0004kY-DQ
	for l3vpn@ietf.org; Mon, 17 May 2004 17:09:55 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BPpII-0003Nx-00
	for l3vpn@ietf.org; Mon, 17 May 2004 17:05:07 -0400
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BPpDT-00028N-00
	for l3vpn@ietf.org; Mon, 17 May 2004 17:00:07 -0400
Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4HKxUi15841;
	Mon, 17 May 2004 16:59:30 -0400 (EDT)
Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19)
	id <KJ4MFG64>; Mon, 17 May 2004 16:59:29 -0400
Message-ID: <6204FDDE129D364D8040A98BCCB290EF0DA8C4F7@zbl6c004.corpeast.baynetworks.com>
From: "Paul Knight" <paul.knight@nortelnetworks.com>
To: Ross Callon <rcallon@juniper.net>, l3vpn@ietf.org
Subject: RE: Progression of VR and IPsec Architectures
Date: Mon, 17 May 2004 16:59:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C43C51.D83E543C"
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE 
	autolearn=no version=2.60

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C43C51.D83E543C
Content-Type: text/plain

Hi Ross and all,

I am contacting the authors and contributors of the VR draft, VR
Applicability Statement, and VR MIB to get comments concerning the way to
move forward with the VR architecture.  We should be able to provide some
input by the end of this week.

Regards,
Paul Knight
Editor, Virtual Router draft

> -----Original Message-----
> From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On 
> Behalf Of Ross Callon
> Sent: Wednesday, May 12, 2004 2:38 PM
> To: l3vpn@ietf.org
> Subject: Progression of VR and IPsec Architectures
> 
> 
> In reviewing the VR and IPsec architectures and associated 
> applicability statements, the IESG has pointed out that the 
> documents do not actually read as standards, in the sense 
> that they don't specify what needs to be implemented for 
> interoperability.
> 
> This gives us two choices:
> 
> One option would be to publish the documents in approximately 
> their current form as informational RFCs.
> 
> The second option would be to update the documents to specify 
> which features need to be implemented to allow 
> interoperability between different implementations.
> 
> Note that the VR architecture already contains a few MUST and 
> SHOULD statements, particularly in section 2. However, it is 
> not clear whether the sum of the MUST's which are present are 
> sufficient to ensure interoperability. For example, there is 
> no single discovery scheme which MUST be implemented (would 
> the MUST apply to implementation of discovery via manual 
> configuration??).
> 
> The CE-based VPN architecture based on IPsec contains a 
> significant number of MUST statements. However, these are 
> primarily of the form "for such a feature to work, the 
> implementation MUST operate as follows", rather than of the 
> form "to be compliant, the implementation MUST implement the 
> following protocol or feature".
> 
> As a working group, we need to decide whether to publish the 
> current documents as informational, or to begin a process of 
> determining which features are MUST versus which are SHOULD 
> or MAY, in order to ensure interoperability, and thereby 
> allow us to progress the documents on the standards track.
> 
> Comments?
> 
> thanks, Ross
> 
> 
> 

------_=_NextPart_001_01C43C51.D83E543C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>RE: Progression of VR and IPsec Architectures</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Ross and all,</FONT>
</P>

<P><FONT SIZE=3D2>I am contacting the authors and contributors of the =
VR draft, VR Applicability Statement, and VR MIB to get comments =
concerning the way to move forward with the VR architecture.&nbsp; We =
should be able to provide some input by the end of this =
week.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Paul Knight</FONT>
<BR><FONT SIZE=3D2>Editor, Virtual Router draft</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: l3vpn-admin@ietf.org [<A =
HREF=3D"mailto:l3vpn-admin@ietf.org">mailto:l3vpn-admin@ietf.org</A>] =
On </FONT>
<BR><FONT SIZE=3D2>&gt; Behalf Of Ross Callon</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, May 12, 2004 2:38 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: l3vpn@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Progression of VR and IPsec =
Architectures</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In reviewing the VR and IPsec architectures and =
associated </FONT>
<BR><FONT SIZE=3D2>&gt; applicability statements, the IESG has pointed =
out that the </FONT>
<BR><FONT SIZE=3D2>&gt; documents do not actually read as standards, in =
the sense </FONT>
<BR><FONT SIZE=3D2>&gt; that they don't specify what needs to be =
implemented for </FONT>
<BR><FONT SIZE=3D2>&gt; interoperability.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This gives us two choices:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; One option would be to publish the documents in =
approximately </FONT>
<BR><FONT SIZE=3D2>&gt; their current form as informational =
RFCs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The second option would be to update the =
documents to specify </FONT>
<BR><FONT SIZE=3D2>&gt; which features need to be implemented to allow =
</FONT>
<BR><FONT SIZE=3D2>&gt; interoperability between different =
implementations.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Note that the VR architecture already contains =
a few MUST and </FONT>
<BR><FONT SIZE=3D2>&gt; SHOULD statements, particularly in section 2. =
However, it is </FONT>
<BR><FONT SIZE=3D2>&gt; not clear whether the sum of the MUST's which =
are present are </FONT>
<BR><FONT SIZE=3D2>&gt; sufficient to ensure interoperability. For =
example, there is </FONT>
<BR><FONT SIZE=3D2>&gt; no single discovery scheme which MUST be =
implemented (would </FONT>
<BR><FONT SIZE=3D2>&gt; the MUST apply to implementation of discovery =
via manual </FONT>
<BR><FONT SIZE=3D2>&gt; configuration??).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The CE-based VPN architecture based on IPsec =
contains a </FONT>
<BR><FONT SIZE=3D2>&gt; significant number of MUST statements. However, =
these are </FONT>
<BR><FONT SIZE=3D2>&gt; primarily of the form &quot;for such a feature =
to work, the </FONT>
<BR><FONT SIZE=3D2>&gt; implementation MUST operate as follows&quot;, =
rather than of the </FONT>
<BR><FONT SIZE=3D2>&gt; form &quot;to be compliant, the implementation =
MUST implement the </FONT>
<BR><FONT SIZE=3D2>&gt; following protocol or feature&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As a working group, we need to decide whether =
to publish the </FONT>
<BR><FONT SIZE=3D2>&gt; current documents as informational, or to begin =
a process of </FONT>
<BR><FONT SIZE=3D2>&gt; determining which features are MUST versus =
which are SHOULD </FONT>
<BR><FONT SIZE=3D2>&gt; or MAY, in order to ensure interoperability, =
and thereby </FONT>
<BR><FONT SIZE=3D2>&gt; allow us to progress the documents on the =
standards track.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Comments?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; thanks, Ross</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C43C51.D83E543C--




From exim@www1.ietf.org  Thu May 20 18:27:29 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02255
	for <l3vpn-archive@odin.ietf.org>; Thu, 20 May 2004 18:27:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BQvrM-0004Ja-Dj
	for l3vpn-archive@odin.ietf.org; Thu, 20 May 2004 18:17:52 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KMHqhD016587
	for l3vpn-archive@odin.ietf.org; Thu, 20 May 2004 18:17:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BQvj5-0007vV-Em
	for l3vpn-web-archive@optimus.ietf.org; Thu, 20 May 2004 18:09:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00578
	for <l3vpn-web-archive@ietf.org>; Thu, 20 May 2004 18:09:14 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BQvj2-0004hf-8d
	for l3vpn-web-archive@ietf.org; Thu, 20 May 2004 18:09:16 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BQvi4-0004de-00
	for l3vpn-web-archive@ietf.org; Thu, 20 May 2004 18:08:17 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BQvhe-0004ZX-00
	for l3vpn-web-archive@ietf.org; Thu, 20 May 2004 18:07:50 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BQvbE-0002cT-Cc; Thu, 20 May 2004 18:01:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BQvVT-0008Ti-H0
	for l3vpn@optimus.ietf.org; Thu, 20 May 2004 17:55:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28982
	for <l3vpn@ietf.org>; Thu, 20 May 2004 17:55:11 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BQvVQ-0003f8-Qm
	for l3vpn@ietf.org; Thu, 20 May 2004 17:55:12 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BQvUQ-0003aP-00
	for l3vpn@ietf.org; Thu, 20 May 2004 17:54:11 -0400
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BQvTm-0003WV-00
	for l3vpn@ietf.org; Thu, 20 May 2004 17:53:30 -0400
Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i4KLrHeD012076
	for <l3vpn@ietf.org>; Thu, 20 May 2004 14:53:20 -0700 (PDT)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p061005d1bcd2d90748f1@[10.20.30.249]>
Date: Thu, 20 May 2004 14:53:08 -0700
To: l3vpn@ietf.org
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Fwd: Last Call: 'BGP/MPLS IP VPNs' to Proposed Standard
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL autolearn=no version=2.60

[[ For some reason, this didn't get sent to the WG mailing list... ]]

>X-test-idtracker: no
>To: IETF-Announce :;
>From: The IESG <iesg-secretary@ietf.org>
>Subject: Last Call: 'BGP/MPLS IP VPNs' to Proposed Standard
>Reply-to: iesg@ietf.org
>Date: Wed, 19 May 2004 18:37:21 -0400
>X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
>	ietf-mx.ietf.org
>X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,TO_HAS_SPACES autolearn=no
>	version=2.60
>Sender: ietf-announce-admin@ietf.org
>X-BeenThere: ietf-announce@ietf.org
>X-Mailman-Version: 2.0.12
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
>List-Id: <ietf-announce.ietf.org>
>List-Post: <mailto:ietf-announce@ietf.org>
>List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:ietf-announce-request@ietf.org?subject=subscribe>
>
>The IESG has received a request from the Layer 3 Virtual Private Networks WG
>to consider the following documents:
>
>- 'BGP/MPLS IP VPNs '
>    <draft-ietf-l3vpn-rfc2547bis-01.txt> as a Proposed Standard
>- 'Applicability Statement for BGP/MPLS IP VPNs '
>    <draft-ietf-l3vpn-as2547-05.txt> as an Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>iesg@ietf.org or ietf@ietf.org mailing lists by 2004-06-02.
>
>The files can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rfc2547bis-01.txt
>http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-as2547-05.txt
>
>
>_______________________________________________
>IETF-Announce mailing list
>IETF-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf-announce





From exim@www1.ietf.org  Thu May 20 18:35:11 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02833
	for <l3vpn-archive@odin.ietf.org>; Thu, 20 May 2004 18:35:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BQw1F-0008E1-JG
	for l3vpn-archive@odin.ietf.org; Thu, 20 May 2004 18:28:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KMS4F2031601
	for l3vpn-archive@odin.ietf.org; Thu, 20 May 2004 18:28:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BQvxH-0006Y2-80
	for l3vpn-web-archive@optimus.ietf.org; Thu, 20 May 2004 18:23:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02112
	for <l3vpn-web-archive@ietf.org>; Thu, 20 May 2004 18:23:54 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BQvxE-0005f2-Cl
	for l3vpn-web-archive@ietf.org; Thu, 20 May 2004 18:23:56 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BQvwI-0005cb-00
	for l3vpn-web-archive@ietf.org; Thu, 20 May 2004 18:22:59 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BQvvS-0005Z3-00
	for l3vpn-web-archive@ietf.org; Thu, 20 May 2004 18:22:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BQvjm-0008VO-3e; Thu, 20 May 2004 18:10:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BQvd5-0004iS-Lx
	for l3vpn@optimus.ietf.org; Thu, 20 May 2004 18:03:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29615
	for <l3vpn@ietf.org>; Thu, 20 May 2004 18:03:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BQvd2-0004DS-VB
	for l3vpn@ietf.org; Thu, 20 May 2004 18:03:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BQvcH-00048r-00
	for l3vpn@ietf.org; Thu, 20 May 2004 18:02:18 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BQvbO-00040Z-00
	for l3vpn@ietf.org; Thu, 20 May 2004 18:01:22 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i4KM0qBm030462
	for <l3vpn@ietf.org>; Thu, 20 May 2004 15:00:52 -0700 (PDT)
	(envelope-from rcallon@juniper.net)
Received: from rcallon-lt1.juniper.net ([172.28.5.55])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i4KM0qJ93388
	for <l3vpn@ietf.org>; Thu, 20 May 2004 15:00:52 -0700 (PDT)
	(envelope-from rcallon@juniper.net)
Message-Id: <5.0.0.25.2.20040520180003.0290e4a0@zircon.juniper.net>
X-Sender: rcallon@zircon.juniper.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 20 May 2004 18:00:43 -0400
To: l3vpn@ietf.org
From: Ross Callon <rcallon@juniper.net>
Subject: FYI: ID Tracker State Update Notice:
  draft-ietf-l3vpn-rfc2547bis 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60


>From: The IESG <iesg-secretary@ietf.org>
>To: IETF-Announce :;
>Date: Wed, 19 May 2004 18:37:21 -0400
>Subject: Last Call: 'BGP/MPLS IP VPNs' to Proposed Standard
>Reply-to: iesg@ietf.org
>
>The IESG has received a request from the Layer 3 Virtual Private Networks WG
>to consider the following documents:
>
>- 'BGP/MPLS IP VPNs '
>    <draft-ietf-l3vpn-rfc2547bis-01.txt> as a Proposed Standard
>- 'Applicability Statement for BGP/MPLS IP VPNs '
>    <draft-ietf-l3vpn-as2547-05.txt> as an Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>iesg@ietf.org or ietf@ietf.org mailing lists by 2004-06-02.
>
>The files can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rfc2547bis-01.txt
>http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-as2547-05.txt
>
>
>_______________________________________________
>IETF-Announce mailing list
>IETF-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf-announce





From exim@www1.ietf.org  Sun May 23 23:15:49 2004
Received: from optimus.ietf.org (www.iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22626
	for <l3vpn-archive@odin.ietf.org>; Sun, 23 May 2004 23:15:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BS5qF-00067M-HW
	for l3vpn-archive@odin.ietf.org; Sun, 23 May 2004 23:09:31 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O39V5B023514
	for l3vpn-archive@odin.ietf.org; Sun, 23 May 2004 23:09:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BS5gB-0004bH-L2
	for l3vpn-web-archive@optimus.ietf.org; Sun, 23 May 2004 22:59:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21963
	for <l3vpn-web-archive@ietf.org>; Sun, 23 May 2004 22:59:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BS5g8-0006wp-1n
	for l3vpn-web-archive@ietf.org; Sun, 23 May 2004 22:59:04 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BS5fE-0006fR-00
	for l3vpn-web-archive@ietf.org; Sun, 23 May 2004 22:58:09 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BS5eI-0006Ov-00
	for l3vpn-web-archive@ietf.org; Sun, 23 May 2004 22:57:10 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BS5YM-0003Vp-LN; Sun, 23 May 2004 22:51:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BS5WM-0003Bf-BQ
	for l3vpn@optimus.ietf.org; Sun, 23 May 2004 22:48:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21534
	for <l3vpn@ietf.org>; Sun, 23 May 2004 22:48:54 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BS5WI-00049H-OZ
	for l3vpn@ietf.org; Sun, 23 May 2004 22:48:54 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BS5VJ-0003s4-00
	for l3vpn@ietf.org; Sun, 23 May 2004 22:47:53 -0400
Received: from pmesmtp04.mci.com ([199.249.20.36])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BS5UF-0003Lx-00
	for l3vpn@ietf.org; Sun, 23 May 2004 22:46:47 -0400
Received: from dgismtp06.wcomnet.com ([166.38.58.89])
 by firewall.mci.com (Iplanet MTA 5.2)
 with ESMTP id <0HY700CCJ6D5MO@firewall.mci.com> for l3vpn@ietf.org; Mon,
 24 May 2004 02:46:17 +0000 (GMT)
Received: from dgismtp06.wcomnet.com by dgismtp06.mcilink.com
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with SMTP id <0HY7003016D53C@dgismtp06.mcilink.com> for l3vpn@ietf.org; Mon,
 24 May 2004 02:46:17 +0000 (GMT)
Received: from XS344V8061681 ([166.50.112.198])
 by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar
 18 2003)) with ESMTP id <0HY70025N6D4BB@dgismtp06.mcilink.com> for
 l3vpn@ietf.org; Mon, 24 May 2004 02:46:17 +0000 (GMT)
Date: Sun, 23 May 2004 22:46:21 -0400
From: Ronald Bonica <ronald.p.bonica@mci.com>
Subject: draft-ietf-l3vpn-mpls-vpn-mib drop counter
To: l3vpn@ietf.org
Message-id: <023b01c44139$4be4be80$c67032a6@mcilink.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook, Build 10.0.4510
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: quoted-printable
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Folks,

By now, I hope that some of you have reviewed
draft-ietf-l3vpn-mpls-vpn-mib-03. This MIB contains a performance table
entry representing each VRF on a router. Each performance table entry
contains the following objects:

- mplsL3VpnVrfPerfRoutesAdded - "Indicates the number of routes added to
this VPN/VRF since this device has last been reset or the VRF was =
created,
whichever came last."  =20
- mplsL3VpnVrfPerfRoutesDeleted - "Indicates the number of routes =
removed
from this VPN/VRF."  =20
- mplsL3VpnVrfPerfCurrNumRoutes - "Indicates the number of routes =
currently
used by this VRF."

It has been proposed that a RoutesDropped counter be added to each
performance table entry. The RoutesDropped object would reflect the =
number
of routes dropped due to prefix limits since the device was last reset.
Proponents of this counter maintain that it would be useful for planning
purposes.

Others maintain that this counter would be difficult to maintain without
also maintaining a database of discarded prefixes. Otherwise, it would =
be
impossible to distinguish between two prefixes being discarded and the =
same
prefix being discarded twice. Also, this counter would never decrement. =
It
would only reset when the SNMP agent resets.

I would like those who have an opinion on way or another to please speak =
up
on the list. We will defer last call on this document for one week to =
allow
this discussion. If there is no discussion in one week, we will progress =
the
MIB to last call without this counter.

----------------
Ronald P. Bonica
----------------





From exim@www1.ietf.org  Mon May 24 11:16:03 2004
Received: from optimus.ietf.org (www.iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13073
	for <l3vpn-archive@odin.ietf.org>; Mon, 24 May 2004 11:16:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BSH1f-0006ME-5f
	for l3vpn-archive@odin.ietf.org; Mon, 24 May 2004 11:06:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OF63pn024439
	for l3vpn-archive@odin.ietf.org; Mon, 24 May 2004 11:06:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BSGvN-0004v0-Lf
	for l3vpn-web-archive@optimus.ietf.org; Mon, 24 May 2004 10:59:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11918
	for <l3vpn-web-archive@ietf.org>; Mon, 24 May 2004 10:59:28 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BSGvK-0003Je-OW
	for l3vpn-web-archive@ietf.org; Mon, 24 May 2004 10:59:30 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BSGuQ-0003FY-00
	for l3vpn-web-archive@ietf.org; Mon, 24 May 2004 10:58:35 -0400
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BSGu6-0003BO-00
	for l3vpn-web-archive@ietf.org; Mon, 24 May 2004 10:58:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BSGVn-000153-Ag; Mon, 24 May 2004 10:33:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BSGMO-0007tA-VI
	for l3vpn@optimus.ietf.org; Mon, 24 May 2004 10:23:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09605
	for <l3vpn@ietf.org>; Mon, 24 May 2004 10:23:21 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BSGMM-0000Z5-Ms
	for l3vpn@ietf.org; Mon, 24 May 2004 10:23:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BSGLU-0000UE-00
	for l3vpn@ietf.org; Mon, 24 May 2004 10:22:29 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BSGKU-0000MO-00
	for l3vpn@ietf.org; Mon, 24 May 2004 10:21:26 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 24 May 2004 06:27:42 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4OEKr8R019542;
	Mon, 24 May 2004 07:20:54 -0700 (PDT)
Received: from cisco.com (che-vpn-cluster-1-30.cisco.com [10.86.240.30])
	by flask.cisco.com (MOS 3.4.6-GR)
	with ESMTP id AIS80638;
	Mon, 24 May 2004 10:20:53 -0400 (EDT)
Message-ID: <40B204C4.1010809@cisco.com>
Date: Mon, 24 May 2004 10:20:52 -0400
From: Thomas Nadeau <tnadeau@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ronald Bonica <ronald.p.bonica@mci.com>
CC: l3vpn@ietf.org
Subject: Re: draft-ietf-l3vpn-mpls-vpn-mib drop counter
References: <023b01c44139$4be4be80$c67032a6@mcilink.com>
In-Reply-To: <023b01c44139$4be4be80$c67032a6@mcilink.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>,
	<mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Ronald Bonica wrote:

> Folks,
> 
> By now, I hope that some of you have reviewed
> draft-ietf-l3vpn-mpls-vpn-mib-03. This MIB contains a performance table
> entry representing each VRF on a router. Each performance table entry
> contains the following objects:
> 
> - mplsL3VpnVrfPerfRoutesAdded - "Indicates the number of routes added to
> this VPN/VRF since this device has last been reset or the VRF was created,
> whichever came last."   
> - mplsL3VpnVrfPerfRoutesDeleted - "Indicates the number of routes removed
> from this VPN/VRF."   
> - mplsL3VpnVrfPerfCurrNumRoutes - "Indicates the number of routes currently
> used by this VRF."
> 
> It has been proposed that a RoutesDropped counter be added to each
> performance table entry. The RoutesDropped object would reflect the number
> of routes dropped due to prefix limits since the device was last reset.
> Proponents of this counter maintain that it would be useful for planning
> purposes.
 >
> Others maintain that this counter would be difficult to maintain without
> also maintaining a database of discarded prefixes. Otherwise, it would be
> impossible to distinguish between two prefixes being discarded and the same
> prefix being discarded twice. Also, this counter would never decrement. It
> would only reset when the SNMP agent resets.
	
	One additional point you missed was that this counter
doesn't indicate which protocol tried to add the offending route/routes,
so it makes it further difficult to use in practice.  Given this plus
the other reasons you list above, I have a hard time understanding its
usefulness.

	--Tom


> I would like those who have an opinion on way or another to please speak up
> on the list. We will defer last call on this document for one week to allow
> this discussion. If there is no discussion in one week, we will progress the
> MIB to last call without this counter.
> 
> ----------------
> Ronald P. Bonica
> ----------------
> 
> 
>