From exim@www1.ietf.org Thu Apr 1 14:16: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 OAA26421 for ; Thu, 1 Apr 2004 14:16:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B97fz-0001Bn-1c for l3vpn-archive@odin.ietf.org; Thu, 01 Apr 2004 14:16:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31JGVgQ004572 for l3vpn-archive@odin.ietf.org; Thu, 1 Apr 2004 14:16:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B97fy-0001Bf-RU for l3vpn-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 14:16:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26411 for ; Thu, 1 Apr 2004 14:16:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B97fm-0007B9-00 for l3vpn-web-archive@ietf.org; Thu, 01 Apr 2004 14:16:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B97ep-00074e-00 for l3vpn-web-archive@ietf.org; Thu, 01 Apr 2004 14:15:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B97eP-00070A-00 for l3vpn-web-archive@ietf.org; Thu, 01 Apr 2004 14:14:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B97eX-0000zV-MF; Thu, 01 Apr 2004 14:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B97dy-0000yl-Qe for l3vpn@optimus.ietf.org; Thu, 01 Apr 2004 14:14:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26353 for ; Thu, 1 Apr 2004 14:14:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B97dm-0006z2-00 for l3vpn@ietf.org; Thu, 01 Apr 2004 14:14:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B97cn-0006tq-00 for l3vpn@ietf.org; Thu, 01 Apr 2004 14:13:15 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1B97bp-0006kh-00 for l3vpn@ietf.org; Thu, 01 Apr 2004 14:12:13 -0500 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i31JBME00348; Thu, 1 Apr 2004 14:11:22 -0500 (EST) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <1F3QDV48>; Thu, 1 Apr 2004 14:11:21 -0500 Message-ID: <6204FDDE129D364D8040A98BCCB290EF0C903216@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Mark Duffy , Ross Callon , l3vpn@ietf.org Subject: RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and Date: Thu, 1 Apr 2004 14:11:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4181D.1D9FF25A" 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: , List-Id: List-Post: List-Help: List-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_01C4181D.1D9FF25A Content-Type: text/plain Hi Mark and all, I have a complete (I hope) Section 10 below, along with some responses marked [pk]. > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Thursday, April 01, 2004 12:23 PM > To: Knight, Paul [BL60:1A14:EXCH]; Ross Callon; l3vpn@ietf.org > Subject: RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and > > > > At 07:06 PM 3/31/2004 -0500, Paul Knight wrote: > ... > >[pk] Yes, it does need to be clarified... New text: > >The backbone VR is a mechanism to enhance scalability. The use of > >backbone VRs is OPTIONAL in VR-based VPNs. When backbone VRs > are used, > >they SHOULD be configured on all PEs which participate in > VPNs carried > >over the backbone VRs. > > That seems fine to me. It doesn't explicitly address the > point Ross made > that the backbone VR at any given point could be replaced by > an actual > router adjacent to the PE. But I think that is an arcane > enough point that > it can be left to the reader to deduce :-) > [pk]Yes, Ross's point is exactly right, that an actual adjacent router could provide the same functionality as a VR. However, the recommended approach is to configure backbone VRs instead of sticking another box into the network! > > ... > >[pk] Is this more clear? > > Somewhat. But maybe not enough on the first approach described... > > >New text: > > > >10. Carrier's Carrier Case > > > >In some cases, the customer of a VPN is a service provider or carrier > >offering VPN services for its own customers. We can > describe this as a > >VPN hierarchy, with the "carrier's carrier" providing > backbone services to > >a "sub-carrier." > > > >The VR model provides several approaches to implement this VPN > >hierarchy. > > > >In one approach, tunnels are built from the VRs of the carrier's > >carrier > >to the CEs of the customers of the sub-carrier. > > I'm assuming this use of tunnels is in the same sense that > they may be used > in the non-carriers-carrier case, as described in sect. 3: > "CE devices > can be attached to VRs over any type of access link (e.g. > ATM, frame relay, > ethernet, PPP or IP tunneling mechanism such as IPSec, L2TP > or GRE tunnels)." > > But if those "access link" tunnels go from the carriers' > carrier VRs to the > end-user CEs, as I believe you are describing, that would > seem to largely > bypass the sub-carrier. The sub-carrier could fill a purely > business role > as a reseller (which is out of scope of this draft). The sub > carrier could > also provide IP connectivity between the end-customer CEs and > the carriers' > carrier PEs. But this IP connectivity would not be > VPN-aware! It makes > the sub-carrier more like an ISP. Is this what you have in > mind? If so it > could use more description. [pk] Yes, the sub-carrier is acting as an ISP, providing connectivity but not a VPN-aware service. > > > > In this case, the VRs of the carrier's carrier provide > VPN service > > to > > the remote CEs. This can be particularly useful in cases > where the CEs of > > the sub-carrier are themselves VRs [pk] Sorry, the text is not precise enough. "CEs of the sub-carrier" means the sub-carrier's devices which look like CEs to the carrier's carrier (the sub-carrier's P or PE devices), while "remote CEs"="CEs of the customers of the sub-carrier". [pk] So (referring to your comment now far below) I'm not *TRYING* to describe a three-level hierarchy! I'll try to clarify the text again. [pk] Also, I managed to sort through the final approach described in section 10, and rewrite it in terms of carrier's carrier and sub-carrier. By the way, can you think of better terminology? So: Section 10 in its entirety: 10. Carrier's Carrier Case In some cases, the customer of a VPN is a service provider or carrier offering VPN services for its own customers. We can describe this as a VPN hierarchy, with the "carrier's carrier" providing backbone services to a "sub-carrier." The VR model provides several approaches to implement this VPN hierarchy. In one approach, tunnels are built from the VRs of the carrier's carrier to the CEs of the customers of the sub-carrier. In this case, the VRs of the carrier's carrier provide VPN service to the remote CEs. The sub-carrier provides transport but does not participate in the VPN services. This can be particularly useful in cases where the sub-carrier's PE or P devices (which appear as CE devices to the carrier's carrier) are themselves VRs (which may be instantiated within the same device as the VRs of the carrier's carrier) and where the sub-carrier is outsourcing the management of its customers' VPN services. From the carrier's carrier perspective, this is sometimes called "VPN wholesaling." The carrier's carrier may support multiple sub-carriers within a single PE device, through this approach using VRs. Another approach is where the sub-carrier's VPN services are completely transparent to the VRs of the carrier's carrier. This is the default case. It is up to the sub-carrier's VPN service to distribute VPN reachability among the CEs of its customers. Another approach is for the sub-carrier's VPN service to implement the VR architecture, using backbone VRs as described in section 5.3. In this approach, the backbone VRs of the sub-carrier can establish tunnels to backbone VRs of the carrier's carrier. Compared to the first approach, this can reduce the number of VRs needed on the carrier's carrier devices, since the backbone VRs can multiplex different VPNs. > > Hmm. This sounds to me like you are now describing a *three* level > hierarchy of providers. We have carriers' carrier (company > A), sub-carrier > (company B), and sub-carrier's customer (company C) at whose > site the CE > sits. But when you make that CE into a VR you make company C a > sub-sub-carrier, no? > > > >(which may be instantiated within the same device as the VRs of the > >carrier's carrier) and where the sub-carrier is outsourcing > the management > >of its customers' VPN services. > > So now the CEs belonging to company C are actually VRs > belonging to company > C. And these VRs "belonging" to company C are in the same PE devices > (owned by company A) as the VRs operated by company A, and > connected to > them by IP tunnels within the PE? I can see how the > protocols could do > that but I am at a loss to understand the business model. > And what does > company B provide in this case? > > I can only guess that my interpretation is not what you have in mind. [pk] Yes, two levels is enough to attempt to describe! > > > >Another approach is where the sub-carrier's VPN services are > completely > >transparent to the VRs of the carrier's carrier. This is the > default case. > >It is up to the sub-carrier's VPN service to distribute VPN > reachability > >among the CEs of its customers. > > Now that I understand. :-) > > --Mark > Regards, Paul > > ------_=_NextPart_001_01C4181D.1D9FF25A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and = <draft-ietf-l3v pn-as-vr-01.txt>

Hi Mark and all,

I have a complete (I hope) Section 10 below, along = with some responses marked [pk].

> -----Original Message-----
> From: Mark Duffy [mailto:mduffy@quarrytech.com] =
> Sent: Thursday, April 01, 2004 12:23 PM
> To: Knight, Paul [BL60:1A14:EXCH]; Ross Callon; = l3vpn@ietf.org
> Subject: RE: Last Call, = draft-ietf-l3vpn-vpn-vr-01.txt and
> <draft-ietf-l3v pn-as-vr-01.txt>
>
>
> At 07:06 PM 3/31/2004 -0500, Paul Knight = wrote:
> ...
> >[pk] Yes, it does need to be clarified... = New text:
> >The backbone VR is a mechanism to enhance = scalability.  The use of
> >backbone VRs is OPTIONAL in VR-based VPNs. = When backbone VRs
> are used,
> >they SHOULD be configured on all PEs which = participate in
> VPNs carried
> >over the backbone VRs.
>
> That seems fine to me.  It doesn't = explicitly address the
> point Ross made
> that the backbone VR at any given point could = be replaced by
> an actual
> router adjacent to the PE.  But I think = that is an arcane
> enough point that
> it can be left to the reader to deduce = :-)
>
[pk]Yes, Ross's point is exactly right, that an = actual adjacent router could provide the same functionality as a = VR.  However, the recommended approach is to configure backbone = VRs instead of sticking another box into the network!

>
>   ...
> >[pk] Is this more clear?
>
> Somewhat.  But maybe not enough on the = first approach described...
>
> >New text:
> >
> >10. Carrier's Carrier Case
> >
> >In some cases, the customer of a VPN is a = service provider or carrier
> >offering VPN services for its own = customers.  We can
> describe this as a
> >VPN hierarchy, with the "carrier's = carrier" providing
> backbone services to
> >a "sub-carrier."
> >
> >The VR model provides several approaches to = implement this VPN
> >hierarchy.
> >
> >In one approach, tunnels are built from the = VRs of the carrier's
> >carrier
> >to the CEs of the customers of the = sub-carrier.
>
> I'm assuming this use of tunnels is in the same = sense that
> they may be used
> in the non-carriers-carrier case, as described = in sect. 3:  
> "CE devices
> can be attached to VRs over any type of access = link (e.g.
> ATM, frame relay,
> ethernet, PPP or IP tunneling mechanism such as = IPSec, L2TP
> or GRE tunnels)."
>
> But if those "access link" tunnels go = from the carriers'
> carrier VRs to the
> end-user CEs, as I believe you are describing, = that would
> seem to largely
> bypass the sub-carrier.  The sub-carrier = could fill a purely
> business role
> as a reseller (which is out of scope of this = draft).  The sub
> carrier could
> also provide IP connectivity between the = end-customer CEs and
> the carriers'
> carrier PEs.  But this IP connectivity = would not be
> VPN-aware!  It makes
> the sub-carrier more like an ISP.  Is this = what you have in
> mind?  If so it
> could use more description.
[pk] Yes, the sub-carrier is acting as an ISP, = providing connectivity but not a VPN-aware service.
>
>
> >   In this case, the VRs of the = carrier's carrier provide
> VPN service
> > to
> > the remote CEs. This can be particularly = useful in cases
> where the CEs of
> > the sub-carrier are themselves VRs

[pk] Sorry, the text is not precise enough.  = "CEs of the sub-carrier" means the sub-carrier's devices = which look like CEs to the carrier's carrier (the sub-carrier's P or PE = devices), while "remote CEs"=3D"CEs of the customers of = the sub-carrier".

[pk] So (referring to your comment now far below) I'm = not *TRYING* to describe a three-level hierarchy!  I'll try to = clarify the text again.

[pk] Also, I managed to sort through the final = approach described in section 10, and rewrite it in terms of carrier's = carrier and sub-carrier.  By the way, can you think of better = terminology?

So: Section 10 in its entirety:

10. Carrier's Carrier Case

In some cases, the customer of a VPN is a service = provider or carrier offering VPN services for its own customers.  = We can describe this as a VPN hierarchy, with the "carrier's = carrier" providing backbone services to a "sub-carrier." = The VR model provides several approaches to implement this VPN = hierarchy.

In one approach, tunnels are built from the VRs of = the carrier's carrier to the CEs of the customers of the sub-carrier. = In this case, the VRs of the carrier's carrier provide VPN service to = the remote CEs. The sub-carrier provides transport but does not = participate in the VPN services. This can be particularly useful in = cases where the sub-carrier's PE or P devices (which appear as CE = devices to the carrier's carrier) are themselves VRs (which may be = instantiated within the same device as the VRs of the carrier's = carrier) and where the sub-carrier is outsourcing the management of its = customers' VPN services. From the carrier's carrier perspective, this = is sometimes called "VPN wholesaling."  The carrier's = carrier may support multiple sub-carriers within a single PE device, = through this approach using VRs.

Another approach is where the sub-carrier's VPN = services are completely transparent to the VRs of the carrier's = carrier. This is the default case. It is up to the sub-carrier's VPN = service to distribute VPN reachability among the CEs of its = customers.

Another approach is for the sub-carrier's VPN service = to implement the VR architecture, using backbone VRs as described in = section 5.3. In this approach, the backbone VRs of the sub-carrier can = establish tunnels to backbone VRs of the carrier's carrier. Compared to = the first approach, this can reduce the number of VRs needed on the = carrier's carrier devices, since the backbone VRs can multiplex = different VPNs.

>
> Hmm.  This sounds to me like you are now = describing a *three* level
> hierarchy of providers.  We have carriers' = carrier (company
> A), sub-carrier
> (company B), and sub-carrier's customer = (company C) at whose
> site the CE
> sits.  But when you make that CE into a VR = you make company C a
> sub-sub-carrier, no?
>
>
> >(which may be instantiated within the same = device as the VRs of the
> >carrier's carrier) and where the = sub-carrier is outsourcing
> the management
> >of its customers' VPN services.
>
> So now the CEs belonging to company C are = actually VRs
> belonging to company
> C.  And these VRs "belonging" to = company C are in the same PE devices
> (owned by company A) as the VRs operated by = company A, and
> connected to
> them by IP tunnels within the PE?  I can = see how the
> protocols could do
> that but I am at a loss to understand the = business model. 
> And what does
> company B provide in this case?
>
> I can only guess that my interpretation is not = what you have in mind.
[pk]  Yes, two levels is enough to attempt to = describe!
>
>
> >Another approach is where the sub-carrier's = VPN services are
> completely
> >transparent to the VRs of the carrier's = carrier. This is the
> default case.
> >It is up to the sub-carrier's VPN service = to distribute VPN
> reachability
> >among the CEs of its customers.
>
> Now that I understand.  :-)
>
> --Mark
>
Regards,
Paul
>
>

------_=_NextPart_001_01C4181D.1D9FF25A-- From exim@www1.ietf.org Fri Apr 2 04:06: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 EAA29887 for ; Fri, 2 Apr 2004 04:06:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9GF0-0000kc-3R for l3vpn-archive@odin.ietf.org; Thu, 01 Apr 2004 23:25:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i324PEgD002887 for l3vpn-archive@odin.ietf.org; Thu, 1 Apr 2004 23:25:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9DJP-0003lR-7m for l3vpn-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 20:17:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17394 for ; Thu, 1 Apr 2004 20:17:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9DJN-0000l8-00 for l3vpn-web-archive@ietf.org; Thu, 01 Apr 2004 20:17:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9DIP-0000bY-00 for l3vpn-web-archive@ietf.org; Thu, 01 Apr 2004 20:16:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9DHT-0000PC-00 for l3vpn-web-archive@ietf.org; Thu, 01 Apr 2004 20:15:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ABf-0007ck-8J; Thu, 01 Apr 2004 16:57:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95wW-0001tJ-0E for l3vpn@optimus.ietf.org; Thu, 01 Apr 2004 12:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22802 for ; Thu, 1 Apr 2004 12:25:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B95wK-0003iI-00 for l3vpn@ietf.org; Thu, 01 Apr 2004 12:25:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B95ve-0003d3-00 for l3vpn@ietf.org; Thu, 01 Apr 2004 12:24:34 -0500 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1B95uu-0003QR-00 for l3vpn@ietf.org; Thu, 01 Apr 2004 12:23:48 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.173]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41HLJB; Thu, 1 Apr 2004 12:23:17 -0500 Message-Id: <5.2.0.9.0.20040401114238.020f6b00@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 01 Apr 2004 12:23:04 -0500 To: "Paul Knight" , Ross Callon , l3vpn@ietf.org From: Mark Duffy Subject: RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF0C8A259D@zbl6c004.corpeast .baynetworks.com> 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: , List-Id: List-Post: List-Help: List-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 At 07:06 PM 3/31/2004 -0500, Paul Knight wrote: ... >[pk] Yes, it does need to be clarified... New text: >The backbone VR is a mechanism to enhance scalability. The use of >backbone VRs is OPTIONAL in VR-based VPNs. When backbone VRs are used, >they SHOULD be configured on all PEs which participate in VPNs carried >over the backbone VRs. That seems fine to me. It doesn't explicitly address the point Ross made that the backbone VR at any given point could be replaced by an actual router adjacent to the PE. But I think that is an arcane enough point that it can be left to the reader to deduce :-) ... >[pk] Is this more clear? Somewhat. But maybe not enough on the first approach described... >New text: > >10. Carrier's Carrier Case > >In some cases, the customer of a VPN is a service provider or carrier >offering VPN services for its own customers. We can describe this as a >VPN hierarchy, with the "carrier's carrier" providing backbone services to >a "sub-carrier." > >The VR model provides several approaches to implement this VPN hierarchy. > >In one approach, tunnels are built from the VRs of the carrier's carrier >to the CEs of the customers of the sub-carrier. I'm assuming this use of tunnels is in the same sense that they may be used in the non-carriers-carrier case, as described in sect. 3: "CE devices can be attached to VRs over any type of access link (e.g. ATM, frame relay, ethernet, PPP or IP tunneling mechanism such as IPSec, L2TP or GRE tunnels)." But if those "access link" tunnels go from the carriers' carrier VRs to the end-user CEs, as I believe you are describing, that would seem to largely bypass the sub-carrier. The sub-carrier could fill a purely business role as a reseller (which is out of scope of this draft). The sub carrier could also provide IP connectivity between the end-customer CEs and the carriers' carrier PEs. But this IP connectivity would not be VPN-aware! It makes the sub-carrier more like an ISP. Is this what you have in mind? If so it could use more description. > In this case, the VRs of the carrier's carrier provide VPN service to > the remote CEs. This can be particularly useful in cases where the CEs of > the sub-carrier are themselves VRs Hmm. This sounds to me like you are now describing a *three* level hierarchy of providers. We have carriers' carrier (company A), sub-carrier (company B), and sub-carrier's customer (company C) at whose site the CE sits. But when you make that CE into a VR you make company C a sub-sub-carrier, no? >(which may be instantiated within the same device as the VRs of the >carrier's carrier) and where the sub-carrier is outsourcing the management >of its customers' VPN services. So now the CEs belonging to company C are actually VRs belonging to company C. And these VRs "belonging" to company C are in the same PE devices (owned by company A) as the VRs operated by company A, and connected to them by IP tunnels within the PE? I can see how the protocols could do that but I am at a loss to understand the business model. And what does company B provide in this case? I can only guess that my interpretation is not what you have in mind. >Another approach is where the sub-carrier's VPN services are completely >transparent to the VRs of the carrier's carrier. This is the default case. >It is up to the sub-carrier's VPN service to distribute VPN reachability >among the CEs of its customers. Now that I understand. :-) --Mark From exim@www1.ietf.org Fri Apr 2 17:00:40 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 RAA05460 for ; Fri, 2 Apr 2004 17:00:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Whw-00023G-LD for l3vpn-archive@odin.ietf.org; Fri, 02 Apr 2004 17:00:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32M0Cv7007887 for l3vpn-archive@odin.ietf.org; Fri, 2 Apr 2004 17:00:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Whw-000238-Cn for l3vpn-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:00:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05300 for ; Fri, 2 Apr 2004 17:00:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Whu-00038f-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:00:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9We7-0002FC-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 16:56:17 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Wab-0001TG-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 16:52:37 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WOe-0007fr-Ii for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 16:40:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9UTR-0007XI-1T; Fri, 02 Apr 2004 14:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9RKx-0001oE-Ce for l3vpn@optimus.ietf.org; Fri, 02 Apr 2004 11:16:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16606 for ; Fri, 2 Apr 2004 11:16:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9RKw-0006TA-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 11:16:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9RKB-0006Kw-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 11:15:20 -0500 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1B9RJE-00064p-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 11:14:20 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.173]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41HPBY; Fri, 2 Apr 2004 11:13:49 -0500 Message-Id: <5.2.0.9.0.20040402094017.03f5ab28@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 02 Apr 2004 10:32:53 -0500 To: "Paul Knight" , Mark Duffy , Ross Callon , l3vpn@ietf.org From: Mark Duffy Subject: RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF0C903216@zbl6c004.corpeast .baynetworks.com> 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: , List-Id: List-Post: List-Help: List-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 Paul, this is coming along. But I don't think it is quite there yet. Comments below... At 02:11 PM 4/1/2004 -0500, Paul Knight wrote: >10. Carrier's Carrier Case > >In some cases, the customer of a VPN is a service provider or carrier >offering VPN services for its own customers. We can describe this as a >VPN hierarchy, with the "carrier's carrier" providing backbone services to >a "sub-carrier." The VR model provides several approaches to implement >this VPN hierarchy. > >In one approach, tunnels are built from the VRs of the carrier's carrier >to the CEs of the customers of the sub-carrier ("remote CEs"). In this >case, the VRs of the carrier's carrier provide VPN service to the remote CEs. nit: I'd suggest adding '("remote CEs")' as I have done in your text just above, in order to establish the meaning of that term. >The sub-carrier provides transport but does not participate in the VPN >services. This can be particularly useful in cases where the sub-carrier's >PE or P devices (which appear as CE devices to the carrier's carrier) It doesn't seem accurate in this case to say that the sub-carriers's devices appear as CE devices to the carrier's carrier. I think the "remote CEs" are the ones that appear as CE devices to the C's C. The sub-carrier's devices are just part of an IP access network connecting C's C and the remote CEs, no? Perhaps just omit the whole phrase in parentheses? > are themselves VRs (which may be instantiated within the same device as > the VRs of the carrier's carrier) and where the sub-carrier is > outsourcing the management of its customers' VPN services. I'm not sure what value these intermediate VRs (the ones that are "owned" by the sub-carrier) provide in this case. If you have anything to add about that it might help. > From the carrier's carrier perspective, this is sometimes called "VPN > wholesaling." The carrier's carrier may support multiple sub-carriers > within a single PE device, through this approach using VRs. I think these 2 sentences apply to C's C in general (all 3 approaches) so you might want to move these statements to the top or bottom of the section. >Another approach is where the sub-carrier's VPN services are completely >transparent to the VRs of the carrier's carrier. This is the default case. >It is up to the sub-carrier's VPN service to distribute VPN reachability >among the CEs of its customers. > >Another approach is for the sub-carrier's VPN service to implement the VR >architecture, using backbone VRs as described in section 5.3. In this >approach, the backbone VRs of the sub-carrier can establish tunnels to >backbone VRs of the carrier's carrier. Do you really mean that? I would expect that in this case the backbone VRs of the sub-carrier would appear to the C's C as CE's, and this would connect to "regular" (customer-facing) VRs operated by the C's C (and not to backbone VRs of the C's C which would face towards the C's C backbone). And in this case tunnels would not usually be used because the sub-carrier's backbone VR and the C's C VR would usually be directly adjacent. I.e. I am thinking that this case is just the "default" case but in which the sub-carrier happens to be using backbone VRs (which would actually be transparent to the C's C). If you have something else in mind maybe it needs a bit more explanation. > Compared to the first approach, this can reduce the number of VRs needed > on the carrier's carrier devices, since the backbone VRs can multiplex > different VPNs. Doesn't the C's C need one VR per sub-carrier per POP, regardless? Thanks, Mark From exim@www1.ietf.org Fri Apr 2 17:24:16 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 RAA08618 for ; Fri, 2 Apr 2004 17:24:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4m-0001TY-Q5 for l3vpn-archive@odin.ietf.org; Fri, 02 Apr 2004 17:23:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MNmcP005672 for l3vpn-archive@odin.ietf.org; Fri, 2 Apr 2004 17:23:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4m-0001TB-Df for l3vpn-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:23:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08388 for ; Fri, 2 Apr 2004 17:23:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X4k-0000Kd-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:23:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WzD-00076W-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:18:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WxM-0006bI-01 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:16:08 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9Wrn-0000YU-Iz for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:10:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9W55-0006iL-FP; Fri, 02 Apr 2004 16:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SaK-0001Fx-KS for l3vpn@optimus.ietf.org; Fri, 02 Apr 2004 12:36:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20401 for ; Fri, 2 Apr 2004 12:36:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9SaJ-0002hV-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 12:36:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9SZS-0002Z0-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 12:35:12 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1B9SYi-0002GB-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 12:34:24 -0500 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 i32HPpl09657; Fri, 2 Apr 2004 12:25:51 -0500 (EST) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <1F3Q1W93>; Fri, 2 Apr 2004 12:25:50 -0500 Message-ID: <6204FDDE129D364D8040A98BCCB290EF0C957642@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Mark Duffy , Mark Duffy , Ross Callon , l3vpn@ietf.org Subject: RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and Date: Fri, 2 Apr 2004 12:25:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C418D7.8AC5CA70" 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: , List-Id: List-Post: List-Help: List-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_01C418D7.8AC5CA70 Content-Type: text/plain Hi Mark, This helps a lot. See inline below... > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Friday, April 02, 2004 10:33 AM > To: Knight, Paul [BL60:1A14:EXCH]; Mark Duffy; Ross Callon; > l3vpn@ietf.org > Subject: RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and > > > > Paul, this is coming along. But I don't think it is quite there > yet. Comments below... > > > At 02:11 PM 4/1/2004 -0500, Paul Knight wrote: > >10. Carrier's Carrier Case > > > >In some cases, the customer of a VPN is a service provider or carrier > >offering VPN services for its own customers. We can > describe this as a > >VPN hierarchy, with the "carrier's carrier" providing > backbone services to > >a "sub-carrier." The VR model provides several approaches to > implement > >this VPN hierarchy. > > > >In one approach, tunnels are built from the VRs of the carrier's > >carrier > >to the CEs of the customers of the sub-carrier ("remote > CEs"). In this > >case, the VRs of the carrier's carrier provide VPN service > to the remote CEs. > > nit: I'd suggest adding '("remote CEs")' as I have done in > your text just > above, in order to establish the meaning of that term. [pk]Good! > > >The sub-carrier provides transport but does not participate > in the VPN > >services. This can be particularly useful in cases where the > sub-carrier's > >PE or P devices (which appear as CE devices to the carrier's carrier) > > It doesn't seem accurate in this case to say that the sub-carriers's > devices appear as CE devices to the carrier's carrier. I > think the "remote > CEs" are the ones that appear as CE devices to the C's C. The > sub-carrier's devices are just part of an IP access network > connecting C's > C and the remote CEs, no? Perhaps just omit the whole phrase > in parentheses? [pk]Yes, you're right, they are transparent to the C's C... I'll omit it. > > > are themselves VRs (which may be instantiated within the > same device > > as > > the VRs of the carrier's carrier) and where the sub-carrier is > > outsourcing the management of its customers' VPN services. > > I'm not sure what value these intermediate VRs (the ones that > are "owned" > by the sub-carrier) provide in this case. If you have > anything to add > about that it might help. [pk] These VRs provide a point of control and aggregation for the sub-carrier, just like a separate router providing transport service. For example, the sub-carrier may be able to define its customer-facing circuits (usually VCs) on these VRs. I propose expanding the parenthetical expression, like: (which may be instantiated within the same device as the VRs of the carrier's carrier, aggregating the connections from the remote CEs) Does this help? > > > From the carrier's carrier perspective, this is sometimes > called "VPN > > wholesaling." The carrier's carrier may support multiple > sub-carriers > > within a single PE device, through this approach using VRs. > > I think these 2 sentences apply to C's C in general (all 3 > approaches) so > you might want to move these statements to the top or bottom > of the section. [pk] Yes, I'll do that. > > > >Another approach is where the sub-carrier's VPN services are > completely > >transparent to the VRs of the carrier's carrier. This is the > default case. > >It is up to the sub-carrier's VPN service to distribute VPN > reachability > >among the CEs of its customers. > > [pk] Unless I get any objections from the other authors, I think it will be best to simply remove the third case discussed in section 10 (and below), since it is not clearly distinguished from the default case, and does not appear to provide any clear advantages to it. > >Another approach is for the sub-carrier's VPN service to > implement the > >VR > >architecture, using backbone VRs as described in section > 5.3. In this > >approach, the backbone VRs of the sub-carrier can establish > tunnels to > >backbone VRs of the carrier's carrier. > > Do you really mean that? I would expect that in this case > the backbone VRs > of the sub-carrier would appear to the C's C as CE's, and this would > connect to "regular" (customer-facing) VRs operated by the > C's C (and not > to backbone VRs of the C's C which would face towards the C's C > backbone). And in this case tunnels would not usually be > used because the > sub-carrier's backbone VR and the C's C VR would usually be directly > adjacent. I.e. I am thinking that this case is just the > "default" case but > in which the sub-carrier happens to be using backbone VRs > (which would > actually be transparent to the C's C). If you have something > else in mind > maybe it needs a bit more explanation. > > > Compared to the first approach, this can reduce the number of VRs > > needed > > on the carrier's carrier devices, since the backbone VRs > can multiplex > > different VPNs. > > Doesn't the C's C need one VR per sub-carrier per POP, regardless? [pk] Yes, one per "POP" (although that's not really a term defined in this context, we'd probably have to say "PE of the sub-carrier"). I think the third case can provide a reduction in VRs compared to the first case, where it needs one VR per VPN customer of the sub-carrier at best, or one VR per remote CE at worst... But I really think it's not a clear value compared to the second case, so I propose to omit this third case unless another author wants to clarify it. Thanks and regards, Paul > > > Thanks, Mark > > ------_=_NextPart_001_01C418D7.8AC5CA70 Content-Type: text/html RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and <draft-ietf-l3v pn-as-vr-01.txt>

Hi Mark,

This helps a lot. See inline below...

> -----Original Message-----
> From: Mark Duffy [mailto:mduffy@quarrytech.com]
> Sent: Friday, April 02, 2004 10:33 AM
> To: Knight, Paul [BL60:1A14:EXCH]; Mark Duffy; Ross Callon;
> l3vpn@ietf.org
> Subject: RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and
> <draft-ietf-l3v pn-as-vr-01.txt>
>
>
> Paul, this is coming along.  But I don't think it is quite there
> yet.  Comments below...
>
>
> At 02:11 PM 4/1/2004 -0500, Paul Knight wrote:
> >10. Carrier's Carrier Case
> >
> >In some cases, the customer of a VPN is a service provider or carrier
> >offering VPN services for its own customers.  We can
> describe this as a
> >VPN hierarchy, with the "carrier's carrier" providing
> backbone services to
> >a "sub-carrier." The VR model provides several approaches to
> implement
> >this VPN hierarchy.
> >
> >In one approach, tunnels are built from the VRs of the carrier's
> >carrier
> >to the CEs of the customers of the sub-carrier ("remote
> CEs"). In this
> >case, the VRs of the carrier's carrier provide VPN service
> to the remote CEs.
>
> nit: I'd suggest adding '("remote CEs")' as I have done in
> your text just
> above, in order to establish the meaning of that term.

[pk]Good!
>
> >The sub-carrier provides transport but does not participate
> in the VPN
> >services. This can be particularly useful in cases where the
> sub-carrier's
> >PE or P devices (which appear as CE devices to the carrier's carrier)
>
> It doesn't seem accurate in this case to say that the sub-carriers's
> devices appear as CE devices to the carrier's carrier.  I
> think the "remote
> CEs" are the ones that appear as CE devices to the C's C.  The
> sub-carrier's devices are just part of an IP access network
> connecting C's
> C and the remote CEs, no?  Perhaps just omit the whole phrase
> in parentheses?

[pk]Yes, you're right, they are transparent to the C's C... I'll omit it.
>
> >  are themselves VRs (which may be instantiated within the
> same device
> > as
> > the VRs of the carrier's carrier) and where the sub-carrier is
> > outsourcing the management of its customers' VPN services.
>
> I'm not sure what value these intermediate VRs (the ones that
> are "owned"
> by the sub-carrier) provide in this case.  If you have
> anything to add
> about that it might help.

[pk] These VRs provide a point of control and aggregation for the sub-carrier, just like a separate router providing transport service.  For example, the sub-carrier may be able to define its customer-facing circuits (usually VCs) on these VRs.

I propose expanding the parenthetical expression, like:
(which may be instantiated within the same device as the VRs of the carrier's carrier, aggregating the connections from the remote CEs)

Does this help?
>
> >  From the carrier's carrier perspective, this is sometimes
> called "VPN
> > wholesaling."  The carrier's carrier may support multiple
> sub-carriers
> > within a single PE device, through this approach using VRs.
>
> I think these 2 sentences apply to C's C in general (all 3
> approaches) so
> you might want to move these statements to the top or bottom
> of the section.

[pk] Yes, I'll do that.
>
>
> >Another approach is where the sub-carrier's VPN services are
> completely
> >transparent to the VRs of the carrier's carrier. This is the
> default case.
> >It is up to the sub-carrier's VPN service to distribute VPN
> reachability
> >among the CEs of its customers.
> >

[pk] Unless I get any objections from the other authors, I think it will be best to simply remove the third case discussed in section 10 (and below), since it is not clearly distinguished from the default case, and does not appear to provide any clear advantages to it.

> >Another approach is for the sub-carrier's VPN service to
> implement the
> >VR
> >architecture, using backbone VRs as described in section
> 5.3. In this
> >approach, the backbone VRs of the sub-carrier can establish
> tunnels to
> >backbone VRs of the carrier's carrier.
>
> Do you really mean that?  I would expect that in this case
> the backbone VRs
> of the sub-carrier would appear to the C's C as CE's, and this would
> connect to "regular" (customer-facing) VRs operated by the
> C's C (and not
> to backbone VRs of the C's C which would face towards the C's C
> backbone).  And in this case tunnels would not usually be
> used because the
> sub-carrier's backbone VR and the C's C VR would usually be directly
> adjacent.  I.e. I am thinking that this case is just the
> "default" case but
> in which the sub-carrier happens to be using backbone VRs
> (which would
> actually be transparent to the C's C).  If you have something
> else in mind
> maybe it needs a bit more explanation.
>
> >  Compared to the first approach, this can reduce the number of VRs
> > needed
> > on the carrier's carrier devices, since the backbone VRs
> can multiplex
> > different VPNs.
>
> Doesn't the C's C need one VR per sub-carrier per POP, regardless?
[pk] Yes, one per "POP" (although that's not really a term defined in this context, we'd probably have to say "PE of the sub-carrier").  I think the third case can provide a reduction in VRs compared to the first case, where it needs one VR per VPN customer of the sub-carrier at best, or one VR per remote CE at worst... But I really think it's not a clear value compared to the second case, so I propose to omit this third case unless another author wants to clarify it.

Thanks and regards,
Paul
>
>
> Thanks, Mark
>
>

------_=_NextPart_001_01C418D7.8AC5CA70-- From exim@www1.ietf.org Fri Apr 2 17:24:27 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 RAA08723 for ; Fri, 2 Apr 2004 17:24:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4x-0001XZ-BM for l3vpn-archive@odin.ietf.org; Fri, 02 Apr 2004 17:23:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MNxYF005917 for l3vpn-archive@odin.ietf.org; Fri, 2 Apr 2004 17:23:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9X4x-0001XM-2x for l3vpn-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:23:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08436 for ; Fri, 2 Apr 2004 17:23:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9X4u-0000MN-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:23:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9WzY-0007CH-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:18:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B9WxV-0006bI-01 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:16:17 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B9WrX-0000Xc-Ex for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:10:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9WrS-0006Dn-Q0; Fri, 02 Apr 2004 17:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Vyu-00053X-Ri for l3vpn@optimus.ietf.org; Fri, 02 Apr 2004 16:13:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29847 for ; Fri, 2 Apr 2004 16:13:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Vyt-0001iN-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 16:13:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9VxC-0001DF-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 16:11:55 -0500 Received: from web21412.mail.yahoo.com ([66.163.170.211]) by ietf-mx with smtp (Exim 4.12) id 1B9Vw0-0000sg-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 16:10:40 -0500 Message-ID: <20040402211040.84520.qmail@web21412.mail.yahoo.com> Received: from [47.234.0.52] by web21412.mail.yahoo.com via HTTP; Fri, 02 Apr 2004 13:10:40 PST Date: Fri, 2 Apr 2004 13:10:40 -0800 (PST) From: Roger Pottier Subject: VPN-IPv4 routes To: l3vpn@ietf.org, mpls@uu.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1168352990-1080940240=:84428" 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: , List-Id: List-Post: List-Help: List-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,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --0-1168352990-1080940240=:84428 Content-Type: text/plain; charset=us-ascii Hi, RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI (Type code=15). I saw an implementation, sending both the path attributes in the same UPDATE. If they are present in the same UPDATE, and it also has a BGP Extended Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted as, for those VRFs which are importing those route targets? Roger --------------------------------- Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-1168352990-1080940240=:84428 Content-Type: text/html; charset=us-ascii
Hi,
 
 RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI
 and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI (Type code=15). I saw an implementation, sending both the path attributes in the same
 UPDATE.
 
 If they are present in the same UPDATE, and it also has a BGP Extended Community
 attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted as, for
 those VRFs which are importing those route targets?
 
Roger

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-1168352990-1080940240=:84428-- From exim@www1.ietf.org Fri Apr 2 17:40:50 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 RAA10343 for ; Fri, 2 Apr 2004 17:40:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XKp-00014z-Ae for l3vpn-archive@odin.ietf.org; Fri, 02 Apr 2004 17:40:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32MeNfG004147 for l3vpn-archive@odin.ietf.org; Fri, 2 Apr 2004 17:40:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XKp-00014o-4R for l3vpn-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 17:40:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10340 for ; Fri, 2 Apr 2004 17:40:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9XKm-0003IG-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:40:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9XJx-0003Am-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:39:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9XJW-00032e-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 17:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XJU-0000J6-VI; Fri, 02 Apr 2004 17:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9XIm-00004q-FR for l3vpn@optimus.ietf.org; Fri, 02 Apr 2004 17:38:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10292 for ; Fri, 2 Apr 2004 17:38:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9XIj-000308-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 17:38:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9XHr-0002t7-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 17:37:20 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B9XHT-0002ku-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 17:36:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2004 14:44:28 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i32MaNKj006690; Fri, 2 Apr 2004 14:36:23 -0800 (PST) Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARS57007; Fri, 2 Apr 2004 14:36:20 -0800 (PST) Message-ID: <406DEAE2.9000101@cisco.com> Date: Fri, 02 Apr 2004 14:36:18 -0800 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Pottier CC: l3vpn@ietf.org, mpls@uu.net Subject: Re: VPN-IPv4 routes References: <20040402211040.84520.qmail@web21412.mail.yahoo.com> In-Reply-To: <20040402211040.84520.qmail@web21412.mail.yahoo.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: , List-Id: List-Post: List-Help: List-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 Hi Roger, > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be > interpreted as, for those VRFs which are importing those route > targets? Nope. For unreachable information in any address family none of the attributes (incl BGP ext community attribute) are important and not considered. Remember that the NLRI format there still is RD:IPv4 so it uniquely identifies all by itself which remote destinations became unreachable. In other words checking against RTs would be required on the withdraw only if any other PE would inject new set of RTs for previously advertised VPNv4 routes before withdrawing those apriori. That would be an illegal operation. Cheers, R. > Roger Pottier wrote: > > Hi, > > RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI > and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update > packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI > (Type code=15). I saw an implementation, sending both the path > attributes in the same > UPDATE. > > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted > as, for those VRFs which are importing those route targets? > > Roger > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > > - Enter today From exim@www1.ietf.org Fri Apr 2 18:15:53 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 SAA12347 for ; Fri, 2 Apr 2004 18:15:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xrw-0001PK-FC for l3vpn-archive@odin.ietf.org; Fri, 02 Apr 2004 18:15:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32NEQ9M005175 for l3vpn-archive@odin.ietf.org; Fri, 2 Apr 2004 18:14:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xrm-0001JM-9Q for l3vpn-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 18:14:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12180 for ; Fri, 2 Apr 2004 18:14:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xre-0007Vv-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 18:14:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Xqj-0007Nw-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 18:13:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xpw-0007GC-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 18:12:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xjs-0006j8-6Y; Fri, 02 Apr 2004 18:06:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Xiu-0006R3-GO for l3vpn@optimus.ietf.org; Fri, 02 Apr 2004 18:05:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11286 for ; Fri, 2 Apr 2004 18:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Xir-0006LN-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 18:05:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Xhr-0006D8-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 18:04:12 -0500 Received: from web21407.mail.yahoo.com ([216.136.232.77]) by ietf-mx with smtp (Exim 4.12) id 1B9Xgs-00060P-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 18:03:10 -0500 Message-ID: <20040402230310.39536.qmail@web21407.mail.yahoo.com> Received: from [64.221.212.137] by web21407.mail.yahoo.com via HTTP; Fri, 02 Apr 2004 15:03:10 PST Date: Fri, 2 Apr 2004 15:03:10 -0800 (PST) From: Jeff Helmer Subject: Re: draft-marques-ppvpn-rt-constrain-01 To: Ross Callon , Ronald Bonica , l3vpn@ietf.org In-Reply-To: <4.3.2.20040324171720.0306ea48@zircon.juniper.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-941396483-1080946990=:39038" 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=AWL,FROM_HAS_ULINE_NUMS, HTML_MESSAGE autolearn=no version=2.60 --0-941396483-1080946990=:39038 Content-Type: text/plain; charset=us-ascii Is it conceivable that the route targets used for controlling import of routes into a VRF are expressed using wildcards or a regular expression? For example, to permit all route targets from 1700:100 through 1700:105, one could write a regular expression like "1700:10[0-5]" or something like that. If this is plausible, how does the draft support it? - Jeff Ross Callon wrote: 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 >---------------- Speaking as an individual contributor... I agree. I think that this is a useful document that addresses an issue which will be important as BGP/MPLS IP VPNs continue to be deployed. I am assuming that the references to "RFC2547bis" at some point will need to be updated to refer to "BGP/MPLS IP VPNs". Also, it is not clear to me whether this approach applies equally well to "Using BGP as an Auto-Discovery Mechanism for Provider-provisioned VPNs" draft-ietf-l3vpn-bgpvpn-auto-01.txt. However, I think that these two points can be clarified in the future and should not prevent us from accepting this document in its current form as a working group draft. Thanks, Ross --------------------------------- Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-941396483-1080946990=:39038 Content-Type: text/html; charset=us-ascii
Is it conceivable that the route targets used for controlling import of routes into a VRF are expressed using wildcards or a regular expression? For example, to permit all route targets from 1700:100 through 1700:105, one could write a regular expression like "1700:10[0-5]" or something like that. If this is plausible, how does the draft support it?
 
- Jeff

Ross Callon <rcallon@juniper.net> wrote:
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
>----------------

Speaking as an individual contributor...

I agree. I think that this is a useful document that addresses an
issue which will be important as BGP/MPLS IP VPNs continue
to be deployed.

I am assuming that the references to "RFC2547bis" at some point
will need to be updated to refer to "BGP/MPLS IP VPNs". Also, it is
not clear to me whether this approach applies equally well to "Using
BGP a! s an Auto-Discovery Mechanism for Provider-provisioned VPNs"
draft-ietf-l3vpn-bgpvpn-auto-01.txt.

However, I think that these two points can be clarified in the future and
should not prevent us from accepting this document in its current form
as a working group draft.

Thanks, Ross

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-941396483-1080946990=:39038-- From exim@www1.ietf.org Fri Apr 2 18:58:04 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 SAA14620 for ; Fri, 2 Apr 2004 18:58:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9YWX-0008Gb-4H for l3vpn-archive@odin.ietf.org; Fri, 02 Apr 2004 18:57:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32NuN1B031701 for l3vpn-archive@odin.ietf.org; Fri, 2 Apr 2004 18:56:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9YWM-0008EX-U4 for l3vpn-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 18:56:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14583 for ; Fri, 2 Apr 2004 18:56:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9YWE-0005tp-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 18:56:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9YVI-0005lz-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 18:55:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9YUN-0005eA-00 for l3vpn-web-archive@ietf.org; Fri, 02 Apr 2004 18:54:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9YNk-0007CQ-KO; Fri, 02 Apr 2004 18:47:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9YGw-0006DH-CO for l3vpn@optimus.ietf.org; Fri, 02 Apr 2004 18:40:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13872 for ; Fri, 2 Apr 2004 18:40:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9YGt-0003UP-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 18:40:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9YFv-0003MC-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 18:39:24 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1B9YFc-0003EP-00 for l3vpn@ietf.org; Fri, 02 Apr 2004 18:39:04 -0500 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 i32NcKQ19122; Fri, 2 Apr 2004 18:38:20 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1F3QFDPR; Fri, 2 Apr 2004 18:38:19 -0500 Received: from nortelnetworks.com (potti.engeast.baynetworks.com [47.17.140.52]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D826JN56; Fri, 2 Apr 2004 18:38:19 -0500 Message-ID: <406DF978.A7895018@nortelnetworks.com> Date: Fri, 02 Apr 2004 18:38:32 -0500 From: Rajesh Potti Organization: Nortel Networks X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: raszuk@cisco.com CC: Roger Pottier , l3vpn@ietf.org, mpls@uu.net Subject: Re: VPN-IPv4 routes References: <20040402211040.84520.qmail@web21412.mail.yahoo.com> <406DEAE2.9000101@cisco.com> Content-Type: multipart/alternative; boundary="------------B4F11858145F3ED7AFB9D828" 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: , List-Id: List-Post: List-Help: List-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=HTML_MESSAGE autolearn=no version=2.60 --------------B4F11858145F3ED7AFB9D828 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Robert, Another issue on similiar lines: When MP_REACH_NLRI and MP_UNREACH_NLRI are found in the same UPDATE, is there a particular order enforced? MP_REACH_NLRI has type code 14, and MP_UNREACH_NLRI has type code 15, hence should it be MP_REACH_NLRI followed by MP_UNREACH_NLRI in the same UPDATE. Rajesh Robert Raszuk wrote: > Hi Roger, > > > If they are present in the same UPDATE, and it also has a BGP Extended > > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be > > interpreted as, for those VRFs which are importing those route > > targets? > > Nope. For unreachable information in any address family none of the > attributes (incl BGP ext community attribute) are important and not > considered. Remember that the NLRI format there still is RD:IPv4 so it > uniquely identifies all by itself which remote destinations became > unreachable. > > In other words checking against RTs would be required on the withdraw > only if any other PE would inject new set of RTs for previously > advertised VPNv4 routes before withdrawing those apriori. That would be > an illegal operation. > > Cheers, > R. > > > Roger Pottier wrote: > > > > Hi, > > > > RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI > > and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update > > packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI > > (Type code=15). I saw an implementation, sending both the path > > attributes in the same > > UPDATE. > > > > If they are present in the same UPDATE, and it also has a BGP Extended > > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted > > as, for those VRFs which are importing those route targets? > > > > Roger > > > > ------------------------------------------------------------------------ > > Do you Yahoo!? > > Yahoo! Small Business $15K Web Design Giveaway > > > > - Enter today -- Rajesh Potti. --------------B4F11858145F3ED7AFB9D828 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Robert,

 Another issue on similiar lines:
  When MP_REACH_NLRI and MP_UNREACH_NLRI are found in the same UPDATE, is there a particular order enforced?
  MP_REACH_NLRI has type code 14, and MP_UNREACH_NLRI has type code 15, hence should it be
  MP_REACH_NLRI followed by MP_UNREACH_NLRI in the same UPDATE.

Rajesh

Robert Raszuk wrote:

Hi Roger,

 > If they are present in the same UPDATE, and it also has a BGP Extended
 > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be
 > interpreted as, for those VRFs which are importing those route
 > targets?

Nope. For unreachable information in any address family none of the
attributes (incl BGP ext community attribute) are important and not
considered. Remember that the NLRI format there still is RD:IPv4 so it
uniquely identifies all by itself which remote destinations became
unreachable.

In other words checking against RTs would be required on the withdraw
only if any other PE would inject new set of RTs for previously
advertised VPNv4 routes before withdrawing those apriori. That would be
an illegal operation.

Cheers,
R.

 > Roger Pottier wrote:
 >
> Hi,
>
>  RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI
>  and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update
> packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI
> (Type code=15). I saw an implementation, sending both the path
> attributes in the same
>  UPDATE.
>
> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted
> as, for those VRFs which are importing those route targets?
>
> Roger
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
> <http://us.rd.yahoo.com/evt=23609/*http://promotions.yahoo.com/design_giveaway/static/index2.html>
> - Enter today

-- 
Rajesh Potti.
  --------------B4F11858145F3ED7AFB9D828-- From exim@www1.ietf.org Sat Apr 3 21:15: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 VAA15273 for ; Sat, 3 Apr 2004 21:15:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9xAK-00035K-HI for l3vpn-archive@odin.ietf.org; Sat, 03 Apr 2004 21:15:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i342FG5k011858 for l3vpn-archive@odin.ietf.org; Sat, 3 Apr 2004 21:15:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9xAJ-00035B-Rc for l3vpn-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 21:15:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15259 for ; Sat, 3 Apr 2004 21:15:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9xAH-0000MP-00 for l3vpn-web-archive@ietf.org; Sat, 03 Apr 2004 21:15:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9x9L-0000Fn-00 for l3vpn-web-archive@ietf.org; Sat, 03 Apr 2004 21:14:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9x8V-00009g-00 for l3vpn-web-archive@ietf.org; Sat, 03 Apr 2004 21:13:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9x89-0002ku-IJ; Sat, 03 Apr 2004 21:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9x7Q-0002cF-IG for l3vpn@optimus.ietf.org; Sat, 03 Apr 2004 21:12:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15196 for ; Sat, 3 Apr 2004 21:12:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9x7N-00000P-00 for l3vpn@ietf.org; Sat, 03 Apr 2004 21:12:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9x6R-0007iM-00 for l3vpn@ietf.org; Sat, 03 Apr 2004 21:11:16 -0500 Received: from web21412.mail.yahoo.com ([66.163.170.211]) by ietf-mx with smtp (Exim 4.12) id 1B9x69-0007ck-00 for l3vpn@ietf.org; Sat, 03 Apr 2004 21:10:57 -0500 Message-ID: <20040404021058.12989.qmail@web21412.mail.yahoo.com> Received: from [66.31.70.41] by web21412.mail.yahoo.com via HTTP; Sat, 03 Apr 2004 18:10:58 PST Date: Sat, 3 Apr 2004 18:10:58 -0800 (PST) From: Roger Pottier Subject: Re: VPN-IPv4 routes To: raszuk@cisco.com Cc: l3vpn@ietf.org, mpls@uu.net In-Reply-To: <406DEAE2.9000101@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1356366105-1081044658=:9755" 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: , List-Id: List-Post: List-Help: List-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.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-1356366105-1081044658=:9755 Content-Type: text/plain; charset=us-ascii Hi Robert, If a MP_REACH_NLRI route is advertised with a new set of Route Targets, but the same Route Distinguisher, would not the old VPNv4 route be implicitly removed from all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created and imported into all the new VRFs, as per the new set of RTs. Would it be necessary to send a Withdraw for the old Route Target and an UPDATE for the new Route Target? Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended Communities matter in an UPDATE. Implementations do send Extended community first (type code = 16), followed by MP_REACH_NLRI (14) and then MP_UNREACH_NLRI (15) If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first? Does it depend on the order in which the Path Attributes are present in the UPDATE? Thanks, Roger Robert Raszuk wrote: Hi Roger, > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be > interpreted as, for those VRFs which are importing those route > targets? Nope. For unreachable information in any address family none of the attributes (incl BGP ext community attribute) are important and not considered. Remember that the NLRI format there still is RD:IPv4 so it uniquely identifies all by itself which remote destinations became unreachable. In other words checking against RTs would be required on the withdraw only if any other PE would inject new set of RTs for previously advertised VPNv4 routes before withdrawing those apriori. That would be an illegal operation. Cheers, R. > Roger Pottier wrote: > > Hi, > > RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI > and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update > packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI > (Type code=15). I saw an implementation, sending both the path > attributes in the same > UPDATE. > > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted > as, for those VRFs which are importing those route targets? > > Roger > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > > - Enter today --------------------------------- Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-1356366105-1081044658=:9755 Content-Type: text/html; charset=us-ascii
Hi Robert,
 
 If a MP_REACH_NLRI  route is advertised with a new set of Route  Targets, but the
 same Route Distinguisher,  would not the old VPNv4 route be implicitly  removed from
 all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created
 and imported into all the new VRFs, as per the new set of RTs.
 
 Would it be necessary to send a Withdraw for the old Route Target and an UPDATE
 for the new Route Target?
 
Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended
 Communities matter in an UPDATE. Implementations do send Extended
 community first (type code = 16), followed by MP_REACH_NLRI (14) and then
 MP_UNREACH_NLRI (15)
 
 If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first?
Does it depend on the order in which the Path Attributes are present in the UPDATE?
 
Thanks,
Roger
 

Robert Raszuk <raszuk@cisco.com> wrote:
Hi Roger,

> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be
> interpreted as, for those VRFs which are importing those route
> targets?

Nope. For unreachable information in any address family none of the
attributes (incl BGP ext community attribute) are important and not
considered. Remember that the NLRI format there still is RD:IPv4 so it
uniquely identifies all by itself which remote destinations became
unreachable.

In other words checking against RTs would be required on the withdraw
only if any other PE would inject new set of RTs for previously
advertised VPNv4 routes before withdrawing those apriori. That would be
an illegal operation.

Cheers,
R.

> Roger Pottier wrote:
>
> Hi! ,
>
> RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI
> and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update
> packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI
> (Type code=15). I saw an implementation, sending both the path
> attributes in the same
> UPDATE.
>
> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted
> as, for those VRFs which are importing those route targets?
>
> Roger
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
>
> - Enter today

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today --0-1356366105-1081044658=:9755-- From exim@www1.ietf.org Mon Apr 5 02:56: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 CAA14152 for ; Mon, 5 Apr 2004 02:56: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 1BAO1o-0005MR-UG for l3vpn-archive@odin.ietf.org; Mon, 05 Apr 2004 02:56:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i356uGAD020608 for l3vpn-archive@odin.ietf.org; Mon, 5 Apr 2004 02:56:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO1o-0005MG-No for l3vpn-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 02:56:16 -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 CAA14082 for ; Mon, 5 Apr 2004 02:56:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAO1k-0003sZ-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 02:56:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAO0b-0003aH-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 02:55:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BANz9-0003Jt-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 02:53:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BANz4-0004ed-Sr; Mon, 05 Apr 2004 02:53:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BANv2-00045J-Lg for l3vpn@optimus.ietf.org; Mon, 05 Apr 2004 02:49:16 -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 CAA13751 for ; Mon, 5 Apr 2004 02:49:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BANuy-0002qs-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 02:49:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BANu4-0002lP-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 02:48:17 -0400 Received: from [203.199.93.15] (helo=WS0005.indiatimes.com) by ietf-mx with esmtp (Exim 4.12) id 1BANtW-0002dr-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 02:47:42 -0400 Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id LAA14844; Mon, 5 Apr 2004 11:43:59 +0530 From: "Rohit Gupta" Message-Id: <200404050613.LAA14844@WS0005.indiatimes.com> To: "Roger Pottier", CC: , Reply-To: "Rohit Gupta" Subject: Re: Re: VPN-IPv4 routes Date: Mon, 05 Apr 2004 12:13:07 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_200445112137846930886" MIME-Version: 1.0 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: , List-Id: List-Post: List-Help: List-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=FROM_ENDS_IN_NUMS, HTML_FONTCOLOR_GREEN,HTML_MESSAGE,NORMAL_HTTP_TO_IP autolearn=no version=2.60 --=_MAILER_ATTACH_BOUNDARY1_200445112137846930886 Content-Type: text/plain; charset=us-ascii Hi Rajesh, Please find my comments inlined in RG>> If a MP_REACH_NLRI route is advertised with a new set of Route Targets, but the same Route Distinguisher, would not the old VPNv4 route be implicitly removed from all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created and imported into all the new VRFs, as per the new set of RTs. RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked. RG>> It can work as an implicit withdraw if the new route has the same RTs as before but different path attributes (ORIGIN, LP, MED, ASPATH, etc) RG>> Hope I was clear. Would it be necessary to send a Withdraw for the old Route Target and an UPDATE for the new Route Target? RG>> Depends on what is different from new and the old route. If its the path attributes like LP, ASPATH, NEXT_HOP, etc. which differ then you can as well send an implicit withdraw. But if you want to send the route with new RTs then i guess, you need to withdraw this route. Cheers, Rohit Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended Communities matter in an UPDATE. Implementations do send Extended community first (type code = 16), followed by MP_REACH_NLRI (14) and then MP_UNREACH_NLRI (15) If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first? Does it depend on the order in which the Path Attributes are present in the UPDATE? Thanks, Roger Robert Raszuk <raszuk@cisco.com> wrote: Hi Roger, > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be > interpreted as, for those VRFs which are importing those route > targets? Nope. For unreachable information in any address family none of the attributes (incl BGP ext community attribute) are important and not considered. Remember that the NLRI format there still is RD:IPv4 so it uniquely identifies all by itself which remote destinations became unreachable. In other words checking against RTs would be required on the withdraw only if any other PE would inject new set of RTs for previously advertised VPNv4 routes before withdrawing those apriori. That would be an illegal operation. Cheers, R. > Roger Pottier wrote: > > Hi! , > > RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI > and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update > packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI > (Type code=15). I saw an implementation, sending both the path > attributes in the same > UPDATE. > > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted > as, for those VRFs which are importing those route targets? > > Roger > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > > - Enter today Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter todayIndiatimes Email now powered by APIC Advantage. Help! HelpClick on the image to chat with me --=_MAILER_ATTACH_BOUNDARY1_200445112137846930886 Content-Type: text/html; charset=us-ascii

Hi Rajesh,

Please find my comments inlined in RG>>

 If a MP_REACH_NLRI  route is advertised with a new set of Route  Targets, but the
 same Route Distinguisher,  would not the old VPNv4 route be implicitly  removed from
 all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created
 and imported into all the new VRFs, as per the new set of RTs.
 
RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked.
 
RG>> It can work as an implicit withdraw if the new route has the same RTs as before but different path attributes (ORIGIN, LP, MED, ASPATH, etc)
 
RG>> Hope I was clear.
 
 Would it be necessary to send a Withdraw for the old Route Target and an UPDATE
 for the new Route Target?
 
RG>> Depends on what is different from new and the old route. If its the path attributes like LP, ASPATH, NEXT_HOP, etc. which differ then you can as well send an implicit withdraw. But if you want to send the route with new RTs then i guess, you need to withdraw this route.
 
Cheers,
Rohit
 
Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended
 Communities matter in an UPDATE. Implementations do send Extended
 community first (type code = 16), followed by MP_REACH_NLRI (14) and then
 MP_UNREACH_NLRI (15)
 
 If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first?
Does it depend on the order in which the Path Attributes are present in the UPDATE?
 
Thanks,
Roger


Robert Raszuk <raszuk@cisco.com> wrote:
Hi Roger,

> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be
> interpreted as, for those VRFs which are importing those route
> targets?

Nope. For unreachable information in any address family none of the
attributes (incl BGP ext community attribute) are important and not
considered. Remember that the NLRI format there still is RD:IPv4 so it
uniquely identifies all by itself which remote destinations became
unreachable.

In other words checking against RTs would be required on the withdraw
only if any other PE would inject new set of RTs for previously
advertised VPNv4 routes before withdrawing those apriori. That would be
an illegal operation.

Cheers,
R.

> Roger Pottier wrote:
>
> Hi! ! ! ,
>
> RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI
> and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update
> packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI
> (Type code=15). I saw an implementation, sending both the path
> attributes in the same
> UPDATE.
>
> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted
> as, for those VRFs which are importing those route targets?
>
> Roger
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
>
> - Enter today

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today
Indiatimes Email now powered by APIC Advantage. Help!
Click on the image to chat with me
--=_MAILER_ATTACH_BOUNDARY1_200445112137846930886-- From exim@www1.ietf.org Mon Apr 5 02:56:48 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 CAA14175 for ; Mon, 5 Apr 2004 02:56:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO1t-0005NK-I6 for l3vpn-archive@odin.ietf.org; Mon, 05 Apr 2004 02:56:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i356uLBV020659 for l3vpn-archive@odin.ietf.org; Mon, 5 Apr 2004 02:56:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAO1t-0005N8-As for l3vpn-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 02:56:21 -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 CAA14105 for ; Mon, 5 Apr 2004 02:56:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAO1p-0003tM-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 02:56:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAO0l-0003eO-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 02:55:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BANzE-0003L0-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 02:53:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BANz0-0004ct-TM; Mon, 05 Apr 2004 02:53:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BANlW-0003Aq-9g for l3vpn@optimus.ietf.org; Mon, 05 Apr 2004 02:39:26 -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 CAA13416 for ; Mon, 5 Apr 2004 02:39:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BANlS-0001pm-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 02:39:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BANkh-0001j7-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 02:38:36 -0400 Received: from [203.199.93.15] (helo=WS0005.indiatimes.com) by ietf-mx with esmtp (Exim 4.12) id 1BANk6-0001W3-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 02:37:58 -0400 Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id LAA10836; Mon, 5 Apr 2004 11:33:39 +0530 From: "Rohit Gupta" Message-Id: <200404050603.LAA10836@WS0005.indiatimes.com> To: "Rajesh Potti", CC: "Roger Pottier", , Reply-To: "Rohit Gupta" Subject: Re: Re: VPN-IPv4 routes Date: Mon, 05 Apr 2004 12:02:47 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_2004451122471540383426" MIME-Version: 1.0 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: , List-Id: List-Post: List-Help: List-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=FROM_ENDS_IN_NUMS, HTML_FONTCOLOR_GREEN,HTML_MESSAGE,NORMAL_HTTP_TO_IP autolearn=no version=2.60 --=_MAILER_ATTACH_BOUNDARY1_2004451122471540383426 Content-Type: text/plain; charset=us-ascii No Rajesh, there is nothing in the BGP spec which says that the path attributes should be processed in order of their absolute type codes. There is thus nothing wrong with MP_UNREACH_NLRI coming before MP_REACH_NLRI ~Rohit "Rajesh Potti" wrote: Hi Robert, Another issue on similiar lines: When MP_REACH_NLRI and MP_UNREACH_NLRI are found in the same UPDATE, is there a particular order enforced? MP_REACH_NLRI has type code 14, and MP_UNREACH_NLRI has type code 15, hence should it be MP_REACH_NLRI followed by MP_UNREACH_NLRI in the same UPDATE. Rajesh Robert Raszuk wrote: Hi Roger, > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be > interpreted as, for those VRFs which are importing those route > targets? Nope. For unreachable information in any address family none of the attributes (incl BGP ext community attribute) are important and not considered. Remember that the NLRI format there still is RD:IPv4 so it uniquely identifies all by itself which remote destinations became unreachable. In other words checking against RTs would be required on the withdraw only if any other PE would inject new set of RTs for previously advertised VPNv4 routes before withdrawing those apriori. That would be an illegal operation. Cheers, R. > Roger Pottier wrote: > > Hi, > > RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI > and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update > packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI > (Type code=15). I saw an implementation, sending both the path > attributes in the same > UPDATE. > > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted > as, for those VRFs which are importing those route targets? > > Roger > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > <http://us.rd.yahoo.com/evt=23609/*http://promotions.yahoo.com/design_giveaway/static/index2.html> > - Enter today-- Rajesh Potti. Indiatimes Email now powered by APIC Advantage. Help! HelpClick on the image to chat with me --=_MAILER_ATTACH_BOUNDARY1_2004451122471540383426 Content-Type: text/html; charset=us-ascii

No Rajesh, there is nothing in the BGP spec which says that the path attributes should be processed in order of their absolute type codes.

There is thus nothing wrong with MP_UNREACH_NLRI coming before MP_REACH_NLRI 

~Rohit

"Rajesh Potti" wrote:

Hi Robert,

 Another issue on similiar lines:
  When MP_REACH_NLRI and MP_UNREACH_NLRI are found in the same UPDATE, is there a particular order enforced?
  MP_REACH_NLRI has type code 14, and MP_UNREACH_NLRI has type code 15, hence should it be
  MP_REACH_NLRI followed by MP_UNREACH_NLRI in the same UPDATE.

Rajesh

Robert Raszuk wrote:

Hi Roger,

 > If they are present in the same UPDATE, and it also has a BGP Extended
 > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be
 > interpreted as, for those VRFs which are importing those route
 > targets?

Nope. For unreachable information in any address family none of the
attributes (incl BGP ext community attribute) are important and not
considered. Remember that the NLRI format there still is RD:IPv4 so it
uniquely identifies all by itself which remote destinations became
unreachable.

In other words checking against RTs would be required on the withdraw
only if any other PE would inject new set of RTs for previously
advertised VPNv4 routes before withdrawing those apriori. That would be
an illegal operation.

Cheers,
R.

 > Roger Pottier wrote:
 >
> Hi,
>
>  RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI
>  and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update
> packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI
> (Type code=15). I saw an implementation, sending both the path
> attributes in the same
>  UPDATE.
>
> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted
> as, for those VRFs which are importing those route targets?
>
> Roger
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
> <http://us.rd.yahoo.com/evt=23609/*http://promotions.yahoo.com/design_giveaway/static/index2.html>
> - Enter today

-- 
Rajesh Potti.
 
Indiatimes Email now powered by APIC Advantage. Help!
Click on the image to chat with me
--=_MAILER_ATTACH_BOUNDARY1_2004451122471540383426-- From exim@www1.ietf.org Mon Apr 5 10:23:13 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 KAA03246 for ; Mon, 5 Apr 2004 10:23: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 1BAUzs-00069U-7e for l3vpn-archive@odin.ietf.org; Mon, 05 Apr 2004 10:22:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35EMiVu023649 for l3vpn-archive@odin.ietf.org; Mon, 5 Apr 2004 10:22:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUzs-00069M-1x for l3vpn-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 10:22: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 KAA03203 for ; Mon, 5 Apr 2004 10:22:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUzp-0003xO-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 10:22:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUyv-0003p9-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 10:21:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAUyE-0003hZ-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 10:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUyD-0005Np-OO; Mon, 05 Apr 2004 10:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAUxp-0005DB-DR for l3vpn@optimus.ietf.org; Mon, 05 Apr 2004 10:20:37 -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 KAA03012 for ; Mon, 5 Apr 2004 10:20:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAUxm-0003gL-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 10:20:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAUwx-0003Zt-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 10:19:44 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1BAUwO-0003Qy-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 10:19:08 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.173]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41HVCK; Mon, 5 Apr 2004 10:18:29 -0400 Message-Id: <5.2.0.9.0.20040405101633.03db1438@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 05 Apr 2004 10:18:24 -0400 To: "Paul Knight" , Ross Callon , l3vpn@ietf.org From: Mark Duffy Subject: RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF0C957642@zbl6c004.corpeast .baynetworks.com> 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: , List-Id: List-Post: List-Help: List-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 Paul, Thank you, I am in agreement. --Mark At 12:25 PM 4/2/2004 -0500, Paul Knight wrote: >Hi Mark, > >This helps a lot. See inline below... > > > -----Original Message----- > > From: Mark Duffy > [mailto:mduffy@quarrytech.com] > > Sent: Friday, April 02, 2004 10:33 AM > > To: Knight, Paul [BL60:1A14:EXCH]; Mark Duffy; Ross Callon; > > l3vpn@ietf.org > > Subject: RE: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and > > > > > > > > Paul, this is coming along. But I don't think it is quite there > > yet. Comments below... > > > > > > At 02:11 PM 4/1/2004 -0500, Paul Knight wrote: > > >10. Carrier's Carrier Case > > > > > >In some cases, the customer of a VPN is a service provider or carrier > > >offering VPN services for its own customers. We can > > describe this as a > > >VPN hierarchy, with the "carrier's carrier" providing > > backbone services to > > >a "sub-carrier." The VR model provides several approaches to > > implement > > >this VPN hierarchy. > > > > > >In one approach, tunnels are built from the VRs of the carrier's > > >carrier > > >to the CEs of the customers of the sub-carrier ("remote > > CEs"). In this > > >case, the VRs of the carrier's carrier provide VPN service > > to the remote CEs. > > > > nit: I'd suggest adding '("remote CEs")' as I have done in > > your text just > > above, in order to establish the meaning of that term. > >[pk]Good! > > > > >The sub-carrier provides transport but does not participate > > in the VPN > > >services. This can be particularly useful in cases where the > > sub-carrier's > > >PE or P devices (which appear as CE devices to the carrier's carrier) > > > > It doesn't seem accurate in this case to say that the sub-carriers's > > devices appear as CE devices to the carrier's carrier. I > > think the "remote > > CEs" are the ones that appear as CE devices to the C's C. The > > sub-carrier's devices are just part of an IP access network > > connecting C's > > C and the remote CEs, no? Perhaps just omit the whole phrase > > in parentheses? > >[pk]Yes, you're right, they are transparent to the C's C... I'll omit it. > > > > > are themselves VRs (which may be instantiated within the > > same device > > > as > > > the VRs of the carrier's carrier) and where the sub-carrier is > > > outsourcing the management of its customers' VPN services. > > > > I'm not sure what value these intermediate VRs (the ones that > > are "owned" > > by the sub-carrier) provide in this case. If you have > > anything to add > > about that it might help. > >[pk] These VRs provide a point of control and aggregation for the >sub-carrier, just like a separate router providing transport service. For >example, the sub-carrier may be able to define its customer-facing >circuits (usually VCs) on these VRs. > >I propose expanding the parenthetical expression, like: >(which may be instantiated within the same device as the VRs of the >carrier's carrier, aggregating the connections from the remote CEs) > >Does this help? > > > > > From the carrier's carrier perspective, this is sometimes > > called "VPN > > > wholesaling." The carrier's carrier may support multiple > > sub-carriers > > > within a single PE device, through this approach using VRs. > > > > I think these 2 sentences apply to C's C in general (all 3 > > approaches) so > > you might want to move these statements to the top or bottom > > of the section. > >[pk] Yes, I'll do that. > > > > > > >Another approach is where the sub-carrier's VPN services are > > completely > > >transparent to the VRs of the carrier's carrier. This is the > > default case. > > >It is up to the sub-carrier's VPN service to distribute VPN > > reachability > > >among the CEs of its customers. > > > > >[pk] Unless I get any objections from the other authors, I think it will >be best to simply remove the third case discussed in section 10 (and >below), since it is not clearly distinguished from the default case, and >does not appear to provide any clear advantages to it. > > > >Another approach is for the sub-carrier's VPN service to > > implement the > > >VR > > >architecture, using backbone VRs as described in section > > 5.3. In this > > >approach, the backbone VRs of the sub-carrier can establish > > tunnels to > > >backbone VRs of the carrier's carrier. > > > > Do you really mean that? I would expect that in this case > > the backbone VRs > > of the sub-carrier would appear to the C's C as CE's, and this would > > connect to "regular" (customer-facing) VRs operated by the > > C's C (and not > > to backbone VRs of the C's C which would face towards the C's C > > backbone). And in this case tunnels would not usually be > > used because the > > sub-carrier's backbone VR and the C's C VR would usually be directly > > adjacent. I.e. I am thinking that this case is just the > > "default" case but > > in which the sub-carrier happens to be using backbone VRs > > (which would > > actually be transparent to the C's C). If you have something > > else in mind > > maybe it needs a bit more explanation. > > > > > Compared to the first approach, this can reduce the number of VRs > > > needed > > > on the carrier's carrier devices, since the backbone VRs > > can multiplex > > > different VPNs. > > > > Doesn't the C's C need one VR per sub-carrier per POP, regardless? >[pk] Yes, one per "POP" (although that's not really a term defined in this >context, we'd probably have to say "PE of the sub-carrier"). I think the >third case can provide a reduction in VRs compared to the first case, >where it needs one VR per VPN customer of the sub-carrier at best, or one >VR per remote CE at worst... But I really think it's not a clear value >compared to the second case, so I propose to omit this third case unless >another author wants to clarify it. > >Thanks and regards, >Paul > > > > > > Thanks, Mark > > > > From exim@www1.ietf.org Mon Apr 5 12:09:37 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 MAA11161 for ; Mon, 5 Apr 2004 12:09:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWdt-0003TI-8G for l3vpn-archive@odin.ietf.org; Mon, 05 Apr 2004 12:08:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35G7xHi013178 for l3vpn-archive@odin.ietf.org; Mon, 5 Apr 2004 12:07:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWdi-0003OO-S9 for l3vpn-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 12:07: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 MAA10765 for ; Mon, 5 Apr 2004 12:07:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWdc-0004TZ-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 12:07:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAWTm-0002yU-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 11:57:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAWIp-0000yH-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 11:46:24 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAWIo-0005U5-3D for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 11:46:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWIX-0006qX-Km; Mon, 05 Apr 2004 11:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAWHp-0006RM-G4 for l3vpn@optimus.ietf.org; Mon, 05 Apr 2004 11:45:22 -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 LAA07660 for ; Mon, 5 Apr 2004 11:45:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAWHo-0000k0-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 11:45:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAW78-0006uk-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 11:34:21 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BAVsD-0004XI-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 11:18:53 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i35FHtA06768; Mon, 5 Apr 2004 11:17:55 -0400 (EDT) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <1F3QF9PF>; Mon, 5 Apr 2004 11:17:55 -0400 Message-ID: <8B888AAAAB0FD31189590008C79184431B99F5E8@zbl6c002.corpeast.baynetworks.com> From: "Rajesh Potti" To: "'Rohit Gupta'" , Roger Pottier , raszuk@cisco.com Cc: "'l3vpn@ietf.org'" Subject: RE: Re: VPN-IPv4 routes Date: Mon, 5 Apr 2004 11:17:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41B21.2AD5EC70" 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: , List-Id: List-Post: List-Help: List-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,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN,HTML_MESSAGE, NORMAL_HTTP_TO_IP 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_01C41B21.2AD5EC70 Content-Type: text/plain Hi Rohit, Comments below. If a MP_REACH_NLRI route is advertised with a new set of Route Targets, but the same Route Distinguisher, would not the old VPNv4 route be implicitly removed from all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created and imported into all the new VRFs, as per the new set of RTs. RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked. Though the RT is different, the RD of the route is the same. Since RD Uniquely identifies a route, the RD:IPV4 addresses are same as the old route (with a different RT), should it be not treated as a replace route. The RFC does not clearly specify this, but says an RD Uniquely identifies a route. Thanks, Rajesh RG>> It can work as an implicit withdraw if the new route has the same RTs as before but different path attributes (ORIGIN, LP, MED, ASPATH, etc) RG>> Hope I was clear. Would it be necessary to send a Withdraw for the old Route Target and an UPDATE for the new Route Target? RG>> Depends on what is different from new and the old route. If its the path attributes like LP, ASPATH, NEXT_HOP, etc. which differ then you can as well send an implicit withdraw. But if you want to send the route with new RTs then i guess, you need to withdraw this route. Cheers, Rohit Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended Communities matter in an UPDATE. Implementations do send Extended community first (type code = 16), followed by MP_REACH_NLRI (14) and then MP_UNREACH_NLRI (15) If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first? Does it depend on the order in which the Path Attributes are present in the UPDATE? Thanks, Roger Robert Raszuk wrote: Hi Roger, > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be > interpreted as, for those VRFs which are importing those route > targets? Nope. For unreachable information in any address family none of the attributes (incl BGP ext community attribute) are important and not considered. Remember that the NLRI format there still is RD:IPv4 so it uniquely identifies all by itself which remote destinations became unreachable. In other words checking against RTs would be required on the withdraw only if any other PE would inject new set of RTs for previously advertised VPNv4 routes before withdrawing those apriori. That would be an illegal operation. Cheers, R. > Roger Pottier wrote: > > Hi! ! ! , > > RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI > and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update > packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI > (Type code=15). I saw an implementation, sending both the path > attributes in the same > UPDATE. > > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted > as, for those VRFs which are importing those route targets? > > Roger > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > > - Enter today _____ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today _____ Indiatimes Email now powered by APIC Advantage. Help! My Presence Help Click on the image to chat with me ------_=_NextPart_001_01C41B21.2AD5EC70 Content-Type: text/html Message
Hi Rohit,
 
 
Comments below.
 If a MP_REACH_NLRI  route is advertised with a new set of Route  Targets, but the
 same Route Distinguisher,  would not the old VPNv4 route be implicitly  removed from
 all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created
 and imported into all the new VRFs, as per the new set of RTs.
 
 
RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked. 
 
Though the RT is different, the RD of the route is the same. Since RD Uniquely identifies a route, the RD:IPV4 addresses are same as the old route (with a different RT), should it be not treated as a replace
route. The RFC does not clearly specify this, but says an RD Uniquely identifies a route.
 
Thanks,
Rajesh
 
 
RG>> It can work as an implicit withdraw if the new route has the same RTs as before but different path attributes (ORIGIN, LP, MED, ASPATH, etc)
 
RG>> Hope I was clear.
 
 Would it be necessary to send a Withdraw for the old Route Target and an UPDATE
 for the new Route Target?
 
RG>> Depends on what is different from new and the old route. If its the path attributes like LP, ASPATH, NEXT_HOP, etc. which differ then you can as well send an implicit withdraw. But if you want to send the route with new RTs then i guess, you need to withdraw this route.
 
Cheers,
Rohit
 
Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended
 Communities matter in an UPDATE. Implementations do send Extended
 community first (type code = 16), followed by MP_REACH_NLRI (14) and then
 MP_UNREACH_NLRI (15)
 
 If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first?
Does it depend on the order in which the Path Attributes are present in the UPDATE?
 
Thanks,
Roger


Robert Raszuk <raszuk@cisco.com> wrote:
Hi Roger,

> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be
> interpreted as, for those VRFs which are importing those route
> targets?

Nope. For unreachable information in any address family none of the
attributes (incl BGP ext community attribute) are important and not
considered. Remember that the NLRI format there still is RD:IPv4 so it
uniquely identifies all by itself which remote destinations became
unreachable.

In other words checking against RTs would be required on the withdraw
only if any other PE would inject new set of RTs for previously
advertised VPNv4 routes before withdrawing those apriori. That would be
an illegal operation.

Cheers,
R.

> Roger Pottier wrote:
>
> Hi! ! ! ,
>
> RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI
> and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update
> packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI
> (Type code=15). I saw an implementation, sending both the path
> attributes in the same
> UPDATE.
>
> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted
> as, for those VRFs which are importing those route targets?
>
> Roger
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
>
> - Enter today

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today
Indiatimes Email now powered by APIC Advantage. Help!
Click on the image to chat with me
------_=_NextPart_001_01C41B21.2AD5EC70-- From exim@www1.ietf.org Mon Apr 5 16:46:57 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 QAA05802 for ; Mon, 5 Apr 2004 16:46:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAazG-0005DF-9l for l3vpn-archive@odin.ietf.org; Mon, 05 Apr 2004 16:46:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35KkUY2020038 for l3vpn-archive@odin.ietf.org; Mon, 5 Apr 2004 16:46:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAazG-0005D7-4P for l3vpn-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 16:46:30 -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 QAA05685 for ; Mon, 5 Apr 2004 16:46:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAazE-0000w1-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 16:46:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaS8-0005mt-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 16:12:17 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAaLZ-0004pT-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 16:05:29 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAaLX-0005qc-SS for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 16:05:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaLH-0003h9-Qf; Mon, 05 Apr 2004 16:05:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaKf-0003NP-3p for l3vpn@optimus.ietf.org; Mon, 05 Apr 2004 16:04: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 QAA03489 for ; Mon, 5 Apr 2004 16:04:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaKd-0004cV-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 16:04:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaC8-000354-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 15:55:45 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BAZr2-0000SQ-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 15:33:56 -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 i35JXQl13172 for ; Mon, 5 Apr 2004 12:33:26 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (rcallon-lt.jnpr.net [10.10.132.78]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i35JXKJ22756 for ; Mon, 5 Apr 2004 12:33:20 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040405153120.03170f20@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 05 Apr 2004 15:32:05 -0400 To: l3vpn@ietf.org From: Ross Callon Subject: Re: Last Call, draft-ietf-l3vpn-vpn-vr-01.txt and In-Reply-To: <4.3.2.20040308121300.02d7fdd0@zircon.juniper.net> 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: , List-Id: List-Post: List-Help: List-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.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 This ends the working group last call on draft-ietf-l3vpn-vpn-vr-01.txt and . thanks, Ross At 12:19 PM 3/8/2004 -0500, Ross Callon wrote: >This begins the l3vpn working group last call on > "Network based IP VPN Architecture using Virtual Routers" > >and the associated applicability statement > "Applicability Statement for Virtual Router-based Layer 3 PPVPN Approaches" > . > >The last call will close two weeks from today, Monday March 22, 2004. > >Thanks, Ross > From exim@www1.ietf.org Mon Apr 5 16:46:58 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 QAA05829 for ; Mon, 5 Apr 2004 16:46: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 1BAazH-0005Dn-Tv for l3vpn-archive@odin.ietf.org; Mon, 05 Apr 2004 16:46:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i35KkVDj020069 for l3vpn-archive@odin.ietf.org; Mon, 5 Apr 2004 16:46:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAazH-0005Dc-Qg for l3vpn-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 16:46:31 -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 QAA05689 for ; Mon, 5 Apr 2004 16:46:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAazF-0000wF-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 16:46:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaS9-0005n4-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 16:12:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAaLZ-0004pU-00 for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 16:05:30 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAaLX-0005qb-SV for l3vpn-web-archive@ietf.org; Mon, 05 Apr 2004 16:05:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaLI-0003hM-AM; Mon, 05 Apr 2004 16:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaKf-0003NU-70 for l3vpn@optimus.ietf.org; Mon, 05 Apr 2004 16:04: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 QAA03491 for ; Mon, 5 Apr 2004 16:04:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaKd-0004cZ-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 16:04:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaC8-00035E-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 15:55:45 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BAZr3-0000Sc-00 for l3vpn@ietf.org; Mon, 05 Apr 2004 15:33:57 -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 i35JXRl13175 for ; Mon, 5 Apr 2004 12:33:27 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (rcallon-lt.jnpr.net [10.10.132.78]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i35JXLJ22759 for ; Mon, 5 Apr 2004 12:33:21 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040405153215.031c7ee8@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 05 Apr 2004 15:32:44 -0400 To: l3vpn@ietf.org From: Ross Callon Subject: Re: Last Call on and In-Reply-To: <4.3.2.20040308122021.02e6a228@zircon.juniper.net> 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: , List-Id: List-Post: List-Help: List-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.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 This ends the working group last call on and . thanks, Ross At 12:25 PM 3/8/2004 -0500, Ross Callon wrote: >This begins the l3vpn working group last call on > An Architecture for Provider Provisioned CE-based Virtual > Private Networks using IPsec > >and its associated applicability statement > Applicability Statement for Provider Provisioned CE-based > Virtual Private Networks using IPsec > > >The last call will close two weeks from today, Monday March 22, 2004. > >Thanks, Ross > From exim@www1.ietf.org Tue Apr 6 04:15:22 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 EAA19051 for ; Tue, 6 Apr 2004 04:15:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAljS-0004bT-6R for l3vpn-archive@odin.ietf.org; Tue, 06 Apr 2004 04:14:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i368Esb7017691 for l3vpn-archive@odin.ietf.org; Tue, 6 Apr 2004 04:14:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAljR-0004bG-65 for l3vpn-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 04:14: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 EAA18945 for ; Tue, 6 Apr 2004 04:14:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAljO-0003Mt-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 04:14:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAlLk-0000Tb-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 03:50:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAkyh-00068B-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 03:26:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkyA-0001T5-Cw; Tue, 06 Apr 2004 03:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkxJ-0001BF-9x for l3vpn@optimus.ietf.org; Tue, 06 Apr 2004 03:25:09 -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 DAA15816 for ; Tue, 6 Apr 2004 03:25:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAkxG-0005r8-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 03:25:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAkkZ-0003We-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 03:12:02 -0400 Received: from ganesh.hcltech.com ([202.54.64.2] helo=ganesh.ctd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BAkGs-0000SV-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 02:41:19 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <2LW9M072>; Tue, 6 Apr 2004 12:10:50 +0530 Message-ID: <68C9DA8F50019B4E8622C53811BEE1D6AD5131@kavithai.ctd.hcltech.com> From: "Vijayanand C - CTD, Chennai." To: Rajesh Potti Cc: "'l3vpn@ietf.org'" , "'Rohit Gupta'" , Roger Pottier , raszuk@cisco.com Subject: RE: Re: VPN-IPv4 routes Date: Tue, 6 Apr 2004 12:10:45 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41BA2.169C9930" 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: , List-Id: List-Post: List-Help: List-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.6 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN,HTML_MESSAGE, NORMAL_HTTP_TO_IP 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_01C41BA2.169C9930 Content-Type: text/plain; charset="iso-8859-1" Hi rohit, Multiple RTs can be attached to a VPN-IPv4 route.( section 4.3.1 - draft-ietf-ppvpn-rfc2547bis-04.txt ) Assigning another RT to an existing VPN-IPv4 route would'nt mean an implicit withdraw, but it would mean that the route has one more RT attached to it now. This is an alternative to generating multiple RDs for the same prefix, since this improves BGP scaling. Regards, Vijay -----Original Message----- From: Rajesh Potti [mailto:rpotti@nortelnetworks.com] Sent: Monday, April 05, 2004 8:48 PM To: 'Rohit Gupta'; Roger Pottier; raszuk@cisco.com Cc: 'l3vpn@ietf.org' Subject: RE: Re: VPN-IPv4 routes Hi Rohit, Comments below. If a MP_REACH_NLRI route is advertised with a new set of Route Targets, but the same Route Distinguisher, would not the old VPNv4 route be implicitly removed from all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created and imported into all the new VRFs, as per the new set of RTs. RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked. Though the RT is different, the RD of the route is the same. Since RD Uniquely identifies a route, the RD:IPV4 addresses are same as the old route (with a different RT), should it be not treated as a replace route. The RFC does not clearly specify this, but says an RD Uniquely identifies a route. Thanks, Rajesh RG>> It can work as an implicit withdraw if the new route has the same RTs as before but different path attributes (ORIGIN, LP, MED, ASPATH, etc) RG>> Hope I was clear. Would it be necessary to send a Withdraw for the old Route Target and an UPDATE for the new Route Target? RG>> Depends on what is different from new and the old route. If its the path attributes like LP, ASPATH, NEXT_HOP, etc. which differ then you can as well send an implicit withdraw. But if you want to send the route with new RTs then i guess, you need to withdraw this route. Cheers, Rohit Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended Communities matter in an UPDATE. Implementations do send Extended community first (type code = 16), followed by MP_REACH_NLRI (14) and then MP_UNREACH_NLRI (15) If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first? Does it depend on the order in which the Path Attributes are present in the UPDATE? Thanks, Roger Robert Raszuk wrote: Hi Roger, > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be > interpreted as, for those VRFs which are importing those route > targets? Nope. For unreachable information in any address family none of the attributes (incl BGP ext community attribute) are important and not considered. Remember that the NLRI format there still is RD:IPv4 so it uniquely identifies all by itself which remote destinations became unreachable. In other words checking against RTs would be required on the withdraw only if any other PE would inject new set of RTs for previously advertised VPNv4 routes before withdrawing those apriori. That would be an illegal operation. Cheers, R. > Roger Pottier wrote: > > Hi! ! ! , > > RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI > and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update > packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI > (Type code=15). I saw an implementation, sending both the path > attributes in the same > UPDATE. > > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted > as, for those VRFs which are importing those route targets? > > Roger > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > > - Enter today _____ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today _____ Indiatimes Email now powered by APIC Advantage. Help! My Presence Help Click on the image to chat with me ------_=_NextPart_001_01C41BA2.169C9930 Content-Type: text/html; charset="iso-8859-1" Message
Hi rohit,
Multiple RTs can be attached to a VPN-IPv4 route.( section 4.3.1 - draft-ietf-ppvpn-rfc2547bis-04.txt  )  Assigning another RT to an existing VPN-IPv4 route would'nt mean an implicit withdraw, but it would mean that the route has one more RT attached to it now. This is an alternative to generating multiple RDs for the same prefix, since this improves BGP scaling.
 
Regards,
Vijay
-----Original Message-----
From: Rajesh Potti [mailto:rpotti@nortelnetworks.com]
Sent: Monday, April 05, 2004 8:48 PM
To: 'Rohit Gupta'; Roger Pottier; raszuk@cisco.com
Cc: 'l3vpn@ietf.org'
Subject: RE: Re: VPN-IPv4 routes

Hi Rohit,
 
 
Comments below.
 If a MP_REACH_NLRI  route is advertised with a new set of Route  Targets, but the
 same Route Distinguisher,  would not the old VPNv4 route be implicitly  removed from
 all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created
 and imported into all the new VRFs, as per the new set of RTs.
 
 
RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked. 
 
Though the RT is different, the RD of the route is the same. Since RD Uniquely identifies a route, the RD:IPV4 addresses are same as the old route (with a different RT), should it be not treated as a replace
route. The RFC does not clearly specify this, but says an RD Uniquely identifies a route.
 
Thanks,
Rajesh
 
 
RG>> It can work as an implicit withdraw if the new route has the same RTs as before but different path attributes (ORIGIN, LP, MED, ASPATH, etc)
 
RG>> Hope I was clear.
 
 Would it be necessary to send a Withdraw for the old Route Target and an UPDATE
 for the new Route Target?
 
RG>> Depends on what is different from new and the old route. If its the path attributes like LP, ASPATH, NEXT_HOP, etc. which differ then you can as well send an implicit withdraw. But if you want to send the route with new RTs then i guess, you need to withdraw this route.
 
Cheers,
Rohit
 
Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended
 Communities matter in an UPDATE. Implementations do send Extended
 community first (type code = 16), followed by MP_REACH_NLRI (14) and then
 MP_UNREACH_NLRI (15)
 
 If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first?
Does it depend on the order in which the Path Attributes are present in the UPDATE?
 
Thanks,
Roger


Robert Raszuk <raszuk@cisco.com> wrote:
Hi Roger,

> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be
> interpreted as, for those VRFs which are importing those route
> targets?

Nope. For unreachable information in any address family none of the
attributes (incl BGP ext community attribute) are important and not
considered. Remember that the NLRI format there still is RD:IPv4 so it
uniquely identifies all by itself which remote destinations became
unreachable.

In other words checking against RTs would be required on the withdraw
only if any other PE would inject new set of RTs for previously
advertised VPNv4 routes before withdrawing those apriori. That would be
an illegal operation.

Cheers,
R.

> Roger Pottier wrote:
>
> Hi! ! ! ,
>
> RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI
> and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update
> packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI
> (Type code=15). I saw an implementation, sending both the path
> attributes in the same
> UPDATE.
>
> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted
> as, for those VRFs which are importing those route targets?
>
> Roger
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
>
> - Enter today

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today
Indiatimes Email now powered by APIC Advantage. Help!
Click on the image to chat with me
------_=_NextPart_001_01C41BA2.169C9930-- From exim@www1.ietf.org Tue Apr 6 06:10:58 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 GAA28602 for ; Tue, 6 Apr 2004 06:10: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 1BAnXL-0007sy-Ra for l3vpn-archive@odin.ietf.org; Tue, 06 Apr 2004 06:10:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36AAVRk030313 for l3vpn-archive@odin.ietf.org; Tue, 6 Apr 2004 06:10:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAnXL-0007sn-BE for l3vpn-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 06:10:31 -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 GAA28437 for ; Tue, 6 Apr 2004 06:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAnXH-0001df-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 06:10:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAn6I-0006Nl-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 05:42:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAmoL-0004Zn-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 05:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAmoK-0005J6-OH; Tue, 06 Apr 2004 05: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 1BAmnY-00050y-QP for l3vpn@optimus.ietf.org; Tue, 06 Apr 2004 05:23:12 -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 FAA25854 for ; Tue, 6 Apr 2004 05:23:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAmnV-0004OA-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 05:23:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAmea-0002Zx-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 05:13:58 -0400 Received: from [203.199.93.15] (helo=WS0005.indiatimes.com) by ietf-mx with esmtp (Exim 4.12) id 1BAmGD-0007L9-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 04:48:45 -0400 Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id NAA27387; Tue, 6 Apr 2004 13:39:20 +0530 From: "Rohit Gupta" Message-Id: <200404060809.NAA27387@WS0005.indiatimes.com> To: "Rajesh Potti", "Rohit Gupta", "Roger Pottier", CC: Reply-To: "Rohit Gupta" Subject: Re: RE: Re: VPN-IPv4 routes Date: Tue, 06 Apr 2004 14:08:23 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_200446214823596516649" MIME-Version: 1.0 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: , List-Id: List-Post: List-Help: List-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.6 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_40_50,HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN, HTML_FONTCOLOR_RED,HTML_MESSAGE,NORMAL_HTTP_TO_IP autolearn=no version=2.60 --=_MAILER_ATTACH_BOUNDARY1_200446214823596516649 Content-Type: text/plain; charset=us-ascii Hi Rajesh, . RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked. Though the RT is different, the RD of the route is the same. Since RD Uniquely identifies a route, the RD:IPV4 addresses are same as the old route (with a different RT), should it be not treated as a replace route. The RFC does not clearly specify this, but says an RD Uniquely identifies a route. RG>> When a PE router receives VPN-IPV4 route it doesnt look at the RD before it decides whether it needs to import that route in its VRF or not. Thus even as you say that the RD:IPV4 route will be same, it doesnt matter. BGP will by only looking at the RTs decide whether it needs to import this route or not. Thus a route with a separate RT cannot be treated as an implicit withdraw. Hope am clear. RohitIndiatimes Email now powered by APIC Advantage. Help! HelpClick on the image to chat with me --=_MAILER_ATTACH_BOUNDARY1_200446214823596516649 Content-Type: text/html; charset=us-ascii
Hi Rajesh,
.
 
RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked. 
 
Though the RT is different, the RD of the route is the same. Since RD Uniquely identifies a route, the RD:IPV4 addresses are same as the old route (with a different RT), should it be not treated as a replace
route. The RFC does not clearly specify this, but says an RD Uniquely identifies a route.
 
RG>> When a PE router receives VPN-IPV4 route it doesnt look at the RD before it decides whether it needs to import that route in its VRF or not. Thus even as you say that the RD:IPV4 route will be same, it doesnt matter. BGP will by only looking at the RTs decide whether it needs to import this route or not. Thus a route with a separate RT cannot be treated as an implicit withdraw.
 
Hope am clear.
 
Rohit
Indiatimes Email now powered by APIC Advantage. Help!
Click on the image to chat with me
--=_MAILER_ATTACH_BOUNDARY1_200446214823596516649-- From exim@www1.ietf.org Tue Apr 6 16:09:05 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 QAA23663 for ; Tue, 6 Apr 2004 16:09: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 1BAws9-0008OK-0g for l3vpn-archive@odin.ietf.org; Tue, 06 Apr 2004 16:08:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36K8bwY032257 for l3vpn-archive@odin.ietf.org; Tue, 6 Apr 2004 16:08:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAws8-0008OC-D9 for l3vpn-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 16:08:36 -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 QAA23550 for ; Tue, 6 Apr 2004 16:08:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAws6-0003Fo-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 16:08:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwFi-0004iH-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 15:28:56 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAvRa-0007Q9-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 14:37:06 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAvRZ-0003I4-RY for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 14:37:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvOo-0004Cm-Pe; Tue, 06 Apr 2004 14:34:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAtL7-00061B-7L for l3vpn@optimus.ietf.org; Tue, 06 Apr 2004 12:22:17 -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 LAA27054 for ; Tue, 6 Apr 2004 11:17:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAsKI-0007gG-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 11:17:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BArxm-00041t-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 10:54:10 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BArPH-0000R4-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 10:18:27 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i36EHlL05617; Tue, 6 Apr 2004 10:17:47 -0400 (EDT) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <1F3QG0TY>; Tue, 6 Apr 2004 10:17:46 -0400 Message-ID: <8B888AAAAB0FD31189590008C79184431B99F5EB@zbl6c002.corpeast.baynetworks.com> From: "Rajesh Potti" To: "'Vijayanand C - CTD, Chennai.'" Cc: "'l3vpn@ietf.org'" , "'Rohit Gupta'" , Roger Pottier , raszuk@cisco.com Subject: RE: Re: VPN-IPv4 routes Date: Tue, 6 Apr 2004 10:17:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41BE1.EDF94286" 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: , List-Id: List-Post: List-Help: List-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_30_40, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN,HTML_MESSAGE, NORMAL_HTTP_TO_IP 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_01C41BE1.EDF94286 Content-Type: text/plain Hi Vijay, Yes, multiple RTs can be attached to a VPNv4 route, and it increases scalablility. But the multiple RTs should be present in the same UPDATE. The issue is whether a successive UPDATE (for a vpnv4 route already advertised) would be treated as a Replace route, since it is the same RD:IPv4. If we need a Withdraw for a VPNv4 route followed by an UPDATE with new set of RTs, on RT Change, it might result in less scalablity. Rajesh -----Original Message----- From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com] Sent: Tuesday, April 06, 2004 2:41 AM To: Potti, Rajesh [BL60:SF40:EXCH] Cc: 'l3vpn@ietf.org'; 'Rohit Gupta'; Roger Pottier; raszuk@cisco.com Subject: RE: Re: VPN-IPv4 routes Hi rohit, Multiple RTs can be attached to a VPN-IPv4 route.( section 4.3.1 - draft-ietf-ppvpn-rfc2547bis-04.txt ) Assigning another RT to an existing VPN-IPv4 route would'nt mean an implicit withdraw, but it would mean that the route has one more RT attached to it now. This is an alternative to generating multiple RDs for the same prefix, since this improves BGP scaling. Regards, Vijay -----Original Message----- From: Rajesh Potti [mailto:rpotti@nortelnetworks.com] Sent: Monday, April 05, 2004 8:48 PM To: 'Rohit Gupta'; Roger Pottier; raszuk@cisco.com Cc: 'l3vpn@ietf.org' Subject: RE: Re: VPN-IPv4 routes Hi Rohit, Comments below. If a MP_REACH_NLRI route is advertised with a new set of Route Targets, but the same Route Distinguisher, would not the old VPNv4 route be implicitly removed from all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created and imported into all the new VRFs, as per the new set of RTs. RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked. Though the RT is different, the RD of the route is the same. Since RD Uniquely identifies a route, the RD:IPV4 addresses are same as the old route (with a different RT), should it be not treated as a replace route. The RFC does not clearly specify this, but says an RD Uniquely identifies a route. Thanks, Rajesh RG>> It can work as an implicit withdraw if the new route has the same RTs as before but different path attributes (ORIGIN, LP, MED, ASPATH, etc) RG>> Hope I was clear. Would it be necessary to send a Withdraw for the old Route Target and an UPDATE for the new Route Target? RG>> Depends on what is different from new and the old route. If its the path attributes like LP, ASPATH, NEXT_HOP, etc. which differ then you can as well send an implicit withdraw. But if you want to send the route with new RTs then i guess, you need to withdraw this route. Cheers, Rohit Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended Communities matter in an UPDATE. Implementations do send Extended community first (type code = 16), followed by MP_REACH_NLRI (14) and then MP_UNREACH_NLRI (15) If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first? Does it depend on the order in which the Path Attributes are present in the UPDATE? Thanks, Roger Robert Raszuk wrote: Hi Roger, > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be > interpreted as, for those VRFs which are importing those route > targets? Nope. For unreachable information in any address family none of the attributes (incl BGP ext community attribute) are important and not considered. Remember that the NLRI format there still is RD:IPv4 so it uniquely identifies all by itself which remote destinations became unreachable. In other words checking against RTs would be required on the withdraw only if any other PE would inject new set of RTs for previously advertised VPNv4 routes before withdrawing those apriori. That would be an illegal operation. Cheers, R. > Roger Pottier wrote: > > Hi! ! ! , > > RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI > and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update > packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI > (Type code=15). I saw an implementation, sending both the path > attributes in the same > UPDATE. > > If they are present in the same UPDATE, and it also has a BGP Extended > Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted > as, for those VRFs which are importing those route targets? > > Roger > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > > - Enter today _____ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today _____ Indiatimes Email now powered by APIC Advantage. Help! My Presence Help Click on the image to chat with me ------_=_NextPart_001_01C41BE1.EDF94286 Content-Type: text/html Message
Hi Vijay,
 
 Yes, multiple RTs can be attached to a VPNv4 route, and it increases scalablility. But the multiple RTs should be
 present in the same UPDATE. The issue is whether a successive UPDATE (for a vpnv4 route already advertised) would
 be treated as a Replace route, since it is the same RD:IPv4. If  we need a Withdraw for a VPNv4 route followed by an
 UPDATE with new set of RTs, on RT Change, it might result in less scalablity.
 
Rajesh
-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com]
Sent: Tuesday, April 06, 2004 2:41 AM
To: Potti, Rajesh [BL60:SF40:EXCH]
Cc: 'l3vpn@ietf.org'; 'Rohit Gupta'; Roger Pottier; raszuk@cisco.com
Subject: RE: Re: VPN-IPv4 routes

Hi rohit,
Multiple RTs can be attached to a VPN-IPv4 route.( section 4.3.1 - draft-ietf-ppvpn-rfc2547bis-04.txt  )  Assigning another RT to an existing VPN-IPv4 route would'nt mean an implicit withdraw, but it would mean that the route has one more RT attached to it now. This is an alternative to generating multiple RDs for the same prefix, since this improves BGP scaling.
 
Regards,
Vijay
-----Original Message-----
From: Rajesh Potti [mailto:rpotti@nortelnetworks.com]
Sent: Monday, April 05, 2004 8:48 PM
To: 'Rohit Gupta'; Roger Pottier; raszuk@cisco.com
Cc: 'l3vpn@ietf.org'
Subject: RE: Re: VPN-IPv4 routes

Hi Rohit,
 
 
Comments below.
 If a MP_REACH_NLRI  route is advertised with a new set of Route  Targets, but the
 same Route Distinguisher,  would not the old VPNv4 route be implicitly  removed from
 all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created
 and imported into all the new VRFs, as per the new set of RTs.
 
 
RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked. 
 
Though the RT is different, the RD of the route is the same. Since RD Uniquely identifies a route, the RD:IPV4 addresses are same as the old route (with a different RT), should it be not treated as a replace
route. The RFC does not clearly specify this, but says an RD Uniquely identifies a route.
 
Thanks,
Rajesh
 
 
RG>> It can work as an implicit withdraw if the new route has the same RTs as before but different path attributes (ORIGIN, LP, MED, ASPATH, etc)
 
RG>> Hope I was clear.
 
 Would it be necessary to send a Withdraw for the old Route Target and an UPDATE
 for the new Route Target?
 
RG>> Depends on what is different from new and the old route. If its the path attributes like LP, ASPATH, NEXT_HOP, etc. which differ then you can as well send an implicit withdraw. But if you want to send the route with new RTs then i guess, you need to withdraw this route.
 
Cheers,
Rohit
 
Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended
 Communities matter in an UPDATE. Implementations do send Extended
 community first (type code = 16), followed by MP_REACH_NLRI (14) and then
 MP_UNREACH_NLRI (15)
 
 If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first?
Does it depend on the order in which the Path Attributes are present in the UPDATE?
 
Thanks,
Roger


Robert Raszuk <raszuk@cisco.com> wrote:
Hi Roger,

> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be
> interpreted as, for those VRFs which are importing those route
> targets?

Nope. For unreachable information in any address family none of the
attributes (incl BGP ext community attribute) are important and not
considered. Remember that the NLRI format there still is RD:IPv4 so it
uniquely identifies all by itself which remote destinations became
unreachable.

In other words checking against RTs would be required on the withdraw
only if any other PE would inject new set of RTs for previously
advertised VPNv4 routes before withdrawing those apriori. That would be
an illegal operation.

Cheers,
R.

> Roger Pottier wrote:
>
> Hi! ! ! ,
>
> RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI
> and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update
> packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI
> (Type code=15). I saw an implementation, sending both the path
> attributes in the same
> UPDATE.
>
> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted
> as, for those VRFs which are importing those route targets?
>
> Roger
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
>
> - Enter today

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today
Indiatimes Email now powered by APIC Advantage. Help!
Click on the image to chat with me
------_=_NextPart_001_01C41BE1.EDF94286-- From exim@www1.ietf.org Tue Apr 6 16:09:23 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 QAA23733 for ; Tue, 6 Apr 2004 16:09:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwsR-0008Pt-Ik for l3vpn-archive@odin.ietf.org; Tue, 06 Apr 2004 16:08:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36K8t3m032349 for l3vpn-archive@odin.ietf.org; Tue, 6 Apr 2004 16:08:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAwsR-0008Pg-ES for l3vpn-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 16:08: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 QAA23593 for ; Tue, 6 Apr 2004 16:08:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAwsP-0003I8-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 16:08:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAwG5-0004kS-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 15:29:18 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAvRc-0007R9-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 14:37:08 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAvRc-0003T4-0A for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 14:37:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAvOo-0004CS-3I; Tue, 06 Apr 2004 14:34:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAtL6-00061B-AD for l3vpn@optimus.ietf.org; Tue, 06 Apr 2004 12:22:17 -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 LAA28199 for ; Tue, 6 Apr 2004 11:21:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAsOD-0000e9-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 11:21:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAs7S-0005f5-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 11:04:09 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BArhe-0001sM-00 for l3vpn@ietf.org; Tue, 06 Apr 2004 10:37:27 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i36EadL08199; Tue, 6 Apr 2004 10:36:39 -0400 (EDT) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <1F3QHAYB>; Tue, 6 Apr 2004 10:36:38 -0400 Message-ID: <8B888AAAAB0FD31189590008C79184431B99F5EC@zbl6c002.corpeast.baynetworks.com> From: "Rajesh Potti" To: "'Rohit Gupta'" , raszuk@cisco.com Cc: l3vpn@ietf.org Subject: RE: RE: Re: VPN-IPv4 routes Date: Tue, 6 Apr 2004 10:36:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41BE4.90D683CC" 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: , List-Id: List-Post: List-Help: List-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.6 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN,HTML_FONTCOLOR_RED, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,NORMAL_HTTP_TO_IP 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_01C41BE4.90D683CC Content-Type: text/plain Hi Rohit, The VPNv4 routes are inserted into VRFs based on RT, i agree. Your point is, if the old (RD:IPv4) route was accepted into a VRF due to RT Match, but the new vpnv4 route with RD and IPv4 route the same, does not match the VRF's import Route Target. Almost like, the old route was accepted by route policy, while new route gets rejected by the policy. In this case, new route should not be inserted and the old route should also be removed. This is similiar to the following scenario: Consider Route 1.1.1.1 with community 2:2 was received from a peer. The Route policy does not reject routes with community 2:2, but does reject routes with community 3:3. Now, the peer again sends an UPDATE for 1.1.1.1 with community 3:3. Since the route is rejected by new policy, the old route 1.1.1.1 with community 2:2 should also be removed. I think draft-ietf-l3vpn-rfc2547bis-01.txt (BGP/MPLS IP VPNs) should also mention how Replace Route case is handled for vpnv4 routes, and whether we need a withdraw for an RT change. Thanks, Rajesh -----Original Message----- From: Rohit Gupta [mailto:rohitgupta416@indiatimes.com] Sent: Tuesday, April 06, 2004 4:38 AM To: Potti, Rajesh [BL60:SF40:EXCH]; Rohit Gupta; Roger Pottier; raszuk@cisco.com Cc: l3vpn@ietf.org Subject: Re: RE: Re: VPN-IPv4 routes Hi Rajesh, . RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked. Though the RT is different, the RD of the route is the same. Since RD Uniquely identifies a route, the RD:IPV4 addresses are same as the old route (with a different RT), should it be not treated as a replace route. The RFC does not clearly specify this, but says an RD Uniquely identifies a route. RG>> When a PE router receives VPN-IPV4 route it doesnt look at the RD before it decides whether it needs to import that route in its VRF or not. Thus even as you say that the RD:IPV4 route will be same, it doesnt matter. BGP will by only looking at the RTs decide whether it needs to import this route or not. Thus a route with a separate RT cannot be treated as an implicit withdraw. Hope am clear. Rohit _____ Indiatimes Email now powered by APIC Advantage. Help! My Presence Help Click on the image to chat with me ------_=_NextPart_001_01C41BE4.90D683CC Content-Type: text/html Message
 
Hi Rohit,
 
 The VPNv4 routes are inserted into VRFs based on RT, i agree. Your point is, if the old (RD:IPv4) route was accepted into
 a VRF due to RT Match, but the new vpnv4 route with RD and IPv4 route the same, does not match the VRF's import
 Route Target. Almost like, the old route was accepted by route policy, while new route gets rejected by the policy. In this
 case, new route should not be inserted and the old route should also be removed.
 
 This is similiar to the following scenario:
 
 Consider Route 1.1.1.1 with community 2:2 was received from a peer. The Route policy does not reject routes with
 community 2:2, but does reject routes with community 3:3. Now, the peer again sends an UPDATE for 1.1.1.1 with
 community 3:3. Since the route is rejected by new policy, the old route 1.1.1.1 with community 2:2 should also be
removed.
 
 I think draft-ietf-l3vpn-rfc2547bis-01.txt (BGP/MPLS IP VPNs) should also mention how Replace Route case is
 handled for vpnv4 routes, and whether we need a withdraw for an RT change.
 
Thanks,
Rajesh
 
 
 
 
 
 
-----Original Message-----
From: Rohit Gupta [mailto:rohitgupta416@indiatimes.com]
Sent: Tuesday, April 06, 2004 4:38 AM
To: Potti, Rajesh [BL60:SF40:EXCH]; Rohit Gupta; Roger Pottier; raszuk@cisco.com
Cc: l3vpn@ietf.org
Subject: Re: RE: Re: VPN-IPv4 routes

Hi Rajesh,
.
 
RG>> Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked. 
 
Though the RT is different, the RD of the route is the same. Since RD Uniquely identifies a route, the RD:IPV4 addresses are same as the old route (with a different RT), should it be not treated as a replace
route. The RFC does not clearly specify this, but says an RD Uniquely identifies a route.
 
RG>> When a PE router receives VPN-IPV4 route it doesnt look at the RD before it decides whether it needs to import that route in its VRF or not. Thus even as you say that the RD:IPV4 route will be same, it doesnt matter. BGP will by only looking at the RTs decide whether it needs to import this route or not. Thus a route with a separate RT cannot be treated as an implicit withdraw. 
 
 
 
Hope am clear.
 
Rohit
Indiatimes Email now powered by APIC Advantage. Help!
Click on the image to chat with me
------_=_NextPart_001_01C41BE4.90D683CC-- From exim@www1.ietf.org Tue Apr 6 18:13:20 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 SAA05405 for ; Tue, 6 Apr 2004 18:13:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyoQ-00083d-M4 for l3vpn-archive@odin.ietf.org; Tue, 06 Apr 2004 18:12:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36MCsQn030970 for l3vpn-archive@odin.ietf.org; Tue, 6 Apr 2004 18:12:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAyoQ-00083R-FY for l3vpn-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 18:12:54 -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 SAA05347 for ; Tue, 6 Apr 2004 18:12:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAyoN-0002yV-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 18:12:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAy9D-00046h-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 17:30:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAx73-0005G0-00 for l3vpn-web-archive@ietf.org; Tue, 06 Apr 2004 16:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAx72-0005K5-UY; Tue, 06 Apr 2004 16: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 1BAx6N-00059I-9J for l3vpn@optimus.ietf.org; Tue, 06 Apr 2004 16:23:20 -0400 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25663 for ; Tue, 6 Apr 2004 16:23:16 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BAx5s-0004yB-Tt; Tue, 06 Apr 2004 16:22:48 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , l3vpn mailing list , l3vpn chair , l3vpn chair , l3vpn chair Subject: Document Action: 'Generic Requirements for Provider Provisioned Virtual Private Networks' to Informational RFC Message-Id: Date: Tue, 06 Apr 2004 16:22:48 -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: , List-Id: List-Post: List-Help: List-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.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has approved the following document: - 'Generic Requirements for Provider Provisioned Virtual Private Networks ' as an Informational RFC This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. Working Group Summary Document has been around for a while, first made it ot the IESG in January, 2003. Protocol Quality This document has been reviewed for the IESG by Thomas Narten From exim@www1.ietf.org Tue Apr 13 17:29: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 RAA10068 for ; Tue, 13 Apr 2004 17:29: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 1BDVGq-0005Uh-Mr for l3vpn-archive@odin.ietf.org; Tue, 13 Apr 2004 17:16:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DLGe93021112 for l3vpn-archive@odin.ietf.org; Tue, 13 Apr 2004 17:16:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUr3-0007yT-Q6 for l3vpn-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 16:50: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 QAA06950 for ; Tue, 13 Apr 2004 16:49:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDUr1-0000wJ-00 for l3vpn-web-archive@ietf.org; Tue, 13 Apr 2004 16:49:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDUjR-0000AQ-00 for l3vpn-web-archive@ietf.org; Tue, 13 Apr 2004 16:42:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDUbU-00079a-00 for l3vpn-web-archive@ietf.org; Tue, 13 Apr 2004 16:33:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDToc-0004f7-B8; Tue, 13 Apr 2004 15:43:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTdm-0002rG-Nd for l3vpn@optimus.ietf.org; Tue, 13 Apr 2004 15:32:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01648; Tue, 13 Apr 2004 15:32:12 -0400 (EDT) Message-Id: <200404131932.PAA01648@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-bgp-ipv6-02.txt Date: Tue, 13 Apr 2004 15:32:12 -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: , List-Id: List-Post: List-Help: List-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 : BGP-MPLS VPN extension for IPv6 VPN Author(s) : J. De Clercq, et al. Filename : draft-ietf-l3vpn-bgp-ipv6-02.txt Pages : 12 Date : 2004-4-13 This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method extends the 'BGP/MPLS VPN' method [2547bis] for support of IPv6. In BGP/MPLS VPN, 'Multiprotocol BGP' is used for distributing IPv4 VPN routes over the service provider backbone and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding route distribution in 'Multiprotocol BGP'. This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and using various tunnelling techniques over the core including MPLS, IPsec, IP-in-IP and GRE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-02.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-bgp-ipv6-02.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-bgp-ipv6-02.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-4-13155246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-bgp-ipv6-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgp-ipv6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-13155246.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Wed Apr 14 17:19:18 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 RAA27438 for ; Wed, 14 Apr 2004 17:19:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDren-0001Mk-6X for l3vpn-archive@odin.ietf.org; Wed, 14 Apr 2004 17:10:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ELArTd005244 for l3vpn-archive@odin.ietf.org; Wed, 14 Apr 2004 17:10:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrG6-0001nm-CP for l3vpn-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 16:45:22 -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 QAA24124 for ; Wed, 14 Apr 2004 16:45:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrG4-0001gZ-00 for l3vpn-web-archive@ietf.org; Wed, 14 Apr 2004 16:45:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrDN-0001ER-00 for l3vpn-web-archive@ietf.org; Wed, 14 Apr 2004 16:42:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BDrC7-00012v-02 for l3vpn-web-archive@ietf.org; Wed, 14 Apr 2004 16:41:16 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BDr9g-0008Ij-OR for l3vpn-web-archive@ietf.org; Wed, 14 Apr 2004 16:38:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqGF-0003Fn-9q; Wed, 14 Apr 2004 15:41:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq99-0003ta-0F for l3vpn@optimus.ietf.org; Wed, 14 Apr 2004 15:34:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18380; Wed, 14 Apr 2004 15:34:04 -0400 (EDT) Message-Id: <200404141934.PAA18380@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-gre-ip-2547-02.txt Date: Wed, 14 Apr 2004 15:34:04 -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: , List-Id: List-Post: List-Help: List-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 : Use of PE-PE GRE or IP in BGP/MPLS IP VPNs Author(s) : Y. Rekhter, E. Rosen Filename : draft-ietf-l3vpn-gre-ip-2547-02.txt Pages : 6 Date : 2004-4-14 This draft describes a variation of BGP/MPLS IP VPNs ([BGP-MPLS-VPN]) in which the outermost MPLS label of a VPN packet (the tunnel label) is replaced with either IP or a GRE encapsulation. This enables the VPN packets to be carried over non-MPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-gre-ip-2547-02.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-gre-ip-2547-02.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-gre-ip-2547-02.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-4-14153532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-gre-ip-2547-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-gre-ip-2547-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153532.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Fri Apr 16 17:00:08 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 RAA09355 for ; Fri, 16 Apr 2004 17:00:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaFR-0001u8-Iq for l3vpn-archive@odin.ietf.org; Fri, 16 Apr 2004 16:47:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GKlfju007316 for l3vpn-archive@odin.ietf.org; Fri, 16 Apr 2004 16:47:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEa2G-0003WA-Sb for l3vpn-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 16:34: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 QAA06279 for ; Fri, 16 Apr 2004 16:34: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 1BEa2F-00065D-4T for l3vpn-web-archive@ietf.org; Fri, 16 Apr 2004 16:34:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEa0x-0005ry-00 for l3vpn-web-archive@ietf.org; Fri, 16 Apr 2004 16:32:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEZzQ-0005ZP-00 for l3vpn-web-archive@ietf.org; Fri, 16 Apr 2004 16:31:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZEx-0006rs-5b; Fri, 16 Apr 2004 15:43:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZ99-0005DE-V7 for l3vpn@optimus.ietf.org; Fri, 16 Apr 2004 15:37:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01070; Fri, 16 Apr 2004 15:37:05 -0400 (EDT) Message-Id: <200404161937.PAA01070@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-02.txt Date: Fri, 16 Apr 2004 15:37:05 -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: , List-Id: List-Post: List-Help: List-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 : Using BGP as an Auto-Discovery Mechanism for Provider-provisioned VPNs Author(s) : H. Ould-Brahim, et al. Filename : draft-ietf-l3vpn-bgpvpn-auto-02.txt Pages : 13 Date : 2004-4-16 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 ([VPN-VR]). This mechanism is based on the approach used by [RFC2547-bis] 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-02.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-02.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-02.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-4-16154614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgpvpn-auto-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-16154614.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Mon Apr 19 14:28:32 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 OAA29690 for ; Mon, 19 Apr 2004 14:28: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 1BFdTW-0007wc-MC for l3vpn-archive@odin.ietf.org; Mon, 19 Apr 2004 14:26:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JIQYrW030530 for l3vpn-archive@odin.ietf.org; Mon, 19 Apr 2004 14:26:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFdPJ-0007Ry-VJ for l3vpn-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 14:22: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 OAA29333 for ; Mon, 19 Apr 2004 14:22: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 1BFdPH-0006fE-FB for l3vpn-web-archive@ietf.org; Mon, 19 Apr 2004 14:22:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFdOQ-0006Qr-00 for l3vpn-web-archive@ietf.org; Mon, 19 Apr 2004 14:21:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFdNQ-0006Cq-00 for l3vpn-web-archive@ietf.org; Mon, 19 Apr 2004 14:20:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFdGS-0005UZ-PQ; Mon, 19 Apr 2004 14:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFdCx-0004jL-DE for l3vpn@optimus.ietf.org; Mon, 19 Apr 2004 14:09:27 -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 OAA28657 for ; Mon, 19 Apr 2004 14:09: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 1BFdCu-0003Vp-VI for l3vpn@ietf.org; Mon, 19 Apr 2004 14:09:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFdC8-0003H6-00 for l3vpn@ietf.org; Mon, 19 Apr 2004 14:08:36 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BFdBO-0002xl-00 for l3vpn@ietf.org; Mon, 19 Apr 2004 14:07:51 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i3JI7H5O000491; Mon, 19 Apr 2004 11:07:17 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i3JI7DVM000488; Mon, 19 Apr 2004 11:07:13 -0700 (PDT) Date: Mon, 19 Apr 2004 11:07:13 -0700 (PDT) Message-Id: <200404191807.i3JI7DVM000488@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jeff Helmer Cc: Ross Callon , Ronald Bonica , l3vpn@ietf.org Subject: Re: draft-marques-ppvpn-rt-constrain-01 In-Reply-To: <20040402230310.39536.qmail@web21407.mail.yahoo.com> References: <4.3.2.20040324171720.0306ea48@zircon.juniper.net> <20040402230310.39536.qmail@web21407.mail.yahoo.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid 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: , List-Id: List-Post: List-Help: List-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 Jeff Helmer writes: > Is it conceivable that the route targets used for controlling import > of routes into a VRF are expressed using wildcards or a regular > expression? For example, to permit all route targets from 1700:100 > through 1700:105, one could write a regular expression like > "1700:10[0-5]" or something like that. If this is plausible, how > does the draft support it? - Jeff The draft supports prefixes. i.e. '1700/16'. It treats RTs as addresses and follows the usual conventions to deal w/ addresses. From exim@www1.ietf.org Tue Apr 20 18:29:09 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 SAA03606 for ; Tue, 20 Apr 2004 18:29:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3Xf-0007EG-0g for l3vpn-archive@odin.ietf.org; Tue, 20 Apr 2004 18:16:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3KMGYJv027783 for l3vpn-archive@odin.ietf.org; Tue, 20 Apr 2004 18:16:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG3M7-0004Ei-Ju for l3vpn-web-archive@optimus.ietf.org; Tue, 20 Apr 2004 18:04: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 SAA00429 for ; Tue, 20 Apr 2004 18:04: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 1BG3M4-0004pc-TO for l3vpn-web-archive@ietf.org; Tue, 20 Apr 2004 18:04:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG3LF-0004iF-00 for l3vpn-web-archive@ietf.org; Tue, 20 Apr 2004 18:03:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG3KO-0004bY-00 for l3vpn-web-archive@ietf.org; Tue, 20 Apr 2004 18:02:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2xS-0004e7-E6; Tue, 20 Apr 2004 17:39:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG1x2-0001IS-8b for l3vpn@optimus.ietf.org; Tue, 20 Apr 2004 16:34: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 QAA21852 for ; Tue, 20 Apr 2004 16:34:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG1x0-0001vg-Bh for l3vpn@ietf.org; Tue, 20 Apr 2004 16:34:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG1w8-0001mK-00 for l3vpn@ietf.org; Tue, 20 Apr 2004 16:33:44 -0400 Received: from omzesmtp01.mci.com ([199.249.17.7]) by ietf-mx with esmtp (Exim 4.12) id 1BG1ur-0001TQ-00 for l3vpn@ietf.org; Tue, 20 Apr 2004 16:32:25 -0400 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWH002H4KQSJK@firewall.mci.com> for l3vpn@ietf.org; Tue, 20 Apr 2004 20:25:40 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWH00001KN0XB@dgismtp03.mcilink.com> for l3vpn@ietf.org; Tue, 20 Apr 2004 20:25:40 +0000 (GMT) Received: from XS344V8061681 ([166.32.199.167]) by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWH000AZKP5SJ@dgismtp03.mcilink.com> for l3vpn@ietf.org; Tue, 20 Apr 2004 20:24:41 +0000 (GMT) Date: Tue, 20 Apr 2004 16:24:41 -0400 From: Ronald Bonica Subject: RE: WG Last Call: draft-ietf-l3vpn-gre-ip-2547 To: l3vpn@ietf.org Message-id: <000901c42715$82ec3090$433f573f@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: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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: , List-Id: List-Post: List-Help: List-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: 7bit Content-Transfer-Encoding: 7bit Folks, This ends the last call. The authors have updated the draft based upon your comments and posted it. I have forwarded the updated draft to the IESG. Ron > -----Original Message----- > From: Ronald Bonica [mailto:ronald.p.bonica@mci.com] > Sent: Tuesday, March 23, 2004 9:35 PM > To: 'l3vpn@ietf.org' > Subject: WG Last Call: draft-ietf-l3vpn-gre-ip-2547 > > > Folks, > > This email initiates a WG last call for > http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-gre-ip-25 > 47-01.txt. Last call will end on April 7, 2004 > > ---------------- > Ronald P. Bonica > ---------------- > From exim@www1.ietf.org Thu Apr 22 17:58:09 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 RAA04699 for ; Thu, 22 Apr 2004 17:58:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlv0-0005UX-W4 for l3vpn-archive@odin.ietf.org; Thu, 22 Apr 2004 17:39:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MLdc4l021102 for l3vpn-archive@odin.ietf.org; Thu, 22 Apr 2004 17:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGl8C-00020g-VY for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 16:49:12 -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 QAA28704 for ; Thu, 22 Apr 2004 16:49: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 1BGl89-0006W6-1D for l3vpn-web-archive@ietf.org; Thu, 22 Apr 2004 16:49:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGl6N-0005zO-00 for l3vpn-web-archive@ietf.org; Thu, 22 Apr 2004 16:47:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGl5K-0005gs-00 for l3vpn-web-archive@ietf.org; Thu, 22 Apr 2004 16:46:14 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGl3p-0003Q5-28 for l3vpn-web-archive@ietf.org; Thu, 22 Apr 2004 16:44:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkKK-0006yY-Cs; Thu, 22 Apr 2004 15:57:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk4l-0001Cp-VW for l3vpn@optimus.ietf.org; Thu, 22 Apr 2004 15:41:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22562; Thu, 22 Apr 2004 15:41:33 -0400 (EDT) Message-Id: <200404221941.PAA22562@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-03.txt Date: Thu, 22 Apr 2004 15:41:33 -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: , List-Id: List-Post: List-Help: List-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 : 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. --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-4-22154050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgpvpn-auto-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-22154050.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Apr 22 19:03:26 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 TAA10507 for ; Thu, 22 Apr 2004 19:03: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 1BGn3G-0000oh-AX for l3vpn-archive@odin.ietf.org; Thu, 22 Apr 2004 18:52:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MMqEQo003132 for l3vpn-archive@odin.ietf.org; Thu, 22 Apr 2004 18:52:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmiG-0001DW-Ro for l3vpn-web-archive@optimus.ietf.org; Thu, 22 Apr 2004 18:30: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 SAA08245 for ; Thu, 22 Apr 2004 18:30:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGmiB-0004bm-P0 for l3vpn-web-archive@ietf.org; Thu, 22 Apr 2004 18:30:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGmhB-0004Hs-00 for l3vpn-web-archive@ietf.org; Thu, 22 Apr 2004 18:29:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGmgB-0003vs-00 for l3vpn-web-archive@ietf.org; Thu, 22 Apr 2004 18:28:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGmQh-0000Pu-Qv; Thu, 22 Apr 2004 18:12:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGm5O-0002Y2-LN for l3vpn@optimus.ietf.org; Thu, 22 Apr 2004 17:50:22 -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 RAA04058 for ; Thu, 22 Apr 2004 17:50:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGm5K-0000u2-3U for l3vpn@ietf.org; Thu, 22 Apr 2004 17:50:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGm2P-00003S-00 for l3vpn@ietf.org; Thu, 22 Apr 2004 17:47:18 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BGlyX-0006m5-00 for l3vpn@ietf.org; Thu, 22 Apr 2004 17:43:17 -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 i3MLgnl41912 for ; Thu, 22 Apr 2004 14:42:49 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.28.5.34]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i3MLghJ55192 for ; Thu, 22 Apr 2004 14:42:43 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20040422173959.00b99960@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 22 Apr 2004 17:42:39 -0400 To: l3vpn@ietf.org From: Ross Callon Subject: Last call, draft-ietf-l3vpn-bgpvpn-auto-03.txt 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: , List-Id: List-Post: List-Help: List-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 autolearn=no version=2.60 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: , > >List-Id: >List-Post: >List-Help: >List-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 > > From exim@www1.ietf.org Fri Apr 23 17:18:59 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 RAA13093 for ; Fri, 23 Apr 2004 17:18: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 1BH7rz-0008D7-M4 for l3vpn-archive@odin.ietf.org; Fri, 23 Apr 2004 17:06:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NL5xOl031555 for l3vpn-archive@odin.ietf.org; Fri, 23 Apr 2004 17:05:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7TM-0004g3-LC for l3vpn-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 16:40: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 QAA09902 for ; Fri, 23 Apr 2004 16:40: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 1BH7TK-0001Ve-O3 for l3vpn-web-archive@ietf.org; Fri, 23 Apr 2004 16:40:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7SN-0001DB-00 for l3vpn-web-archive@ietf.org; Fri, 23 Apr 2004 16:39:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BH7RS-0000u9-00 for l3vpn-web-archive@ietf.org; Fri, 23 Apr 2004 16:38:34 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BH7RP-0007to-Po for l3vpn-web-archive@ietf.org; Fri, 23 Apr 2004 16:38:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH6eX-0005NG-56; Fri, 23 Apr 2004 15: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 1BH6a5-0003bY-LZ for l3vpn@optimus.ietf.org; Fri, 23 Apr 2004 15:43: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 PAA04766 for ; Fri, 23 Apr 2004 15:43:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH6a4-0007DC-9z for l3vpn@ietf.org; Fri, 23 Apr 2004 15:43:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH6Z7-0006oJ-00 for l3vpn@ietf.org; Fri, 23 Apr 2004 15:42:26 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BH6X3-00062G-00 for l3vpn@ietf.org; Fri, 23 Apr 2004 15:40:17 -0400 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HWN005E729UK4@firewall.mci.com> for l3vpn@ietf.org; Fri, 23 Apr 2004 19:32:18 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HWN00B0125CVF@dgismtp02.mcilink.com> for l3vpn@ietf.org; Fri, 23 Apr 2004 19:32:18 +0000 (GMT) Received: from XS344V8061891 ([166.32.199.12]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HWN00AJO29BY5@dgismtp02.mcilink.com> for l3vpn@ietf.org; Fri, 23 Apr 2004 19:32:00 +0000 (GMT) Date: Fri, 23 Apr 2004 15:31:56 -0400 From: David McDysan Subject: RE: I-D ACTION:draft-ietf-l3vpn-ppvpn-terminology-00.txt In-reply-to: <200403232046.PAA27293@ietf.org> To: l3vpn@ietf.org Message-id: <000201c42969$a38eb4c0$af3f573f@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: , List-Id: List-Post: List-Help: List-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 While updating the L3 VPN requirements draft, I used this draft as the = basis for aligning terminology. In the interest of completing alignment on terminology, I had a few comments on the subject draft below. Dave The definition of VPN in section 3.9 never does define an intranet nor = an extranet. Also, there is no definition of a site. See PPVPN-req for candidate definitions.=20 The following sentence in section 3.11 on VPWS "The PE's in the core = network are connected via a PW." was unclear. The taxonomy figure in section 4 is not the same as that of the = referenced I-D on generic PPVPN requirements. These should either be aligned, or = the reason for the differences noted. Section 5.4.7, the sentence "This name has dated." appears to be = incomplete, or needs to be rewritten for clarity. Section 6.1, attachment circuit, states that this applies only to L2 = VPNs. The case for access (attachment) to a L3 VPN is missing from the definitions. Since the access to a L3 VPN may be L1 (circuit) or a L2 (virtual circuit), the PPVPN-req requirements draft defines terminology = for an access connection for your consideration to address this gap.=20 > -----Original Message----- > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On=20 > Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, March 23, 2004 3:46 PM > To: IETF-Announce: > Cc: l3vpn@ietf.org > Subject: I-D ACTION:draft-ietf-l3vpn-ppvpn-terminology-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. This draft is a work item of the=20 > Layer 3 Virtual Private Networks Working Group of the IETF. >=20 > Title : PPVPN terminology > Author(s) : L. Andersson > Filename : draft-ietf-l3vpn-ppvpn-terminology-00.txt > Pages : 20 > Date : 2004-3-23 > =09 > The provider provisioned VPN solutions have attracted a great deal > of interest. Memos proposing different and overlapping solutions > have been discussed on the PPVPN mailing list and in the Working > Group meetings. This has lead to the development of a partly new > set of concepts used to describe the set of VPN services. To a > certain extent there is more than one term covering the same > concept and sometimes the same term covers more than one concept. > The terminology needs to be made clearer and more intuitive. This > document seeks to fill at least part of that need. >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ppvpn-ter minology-00.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. 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-ppvpn-terminology-00.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-ppvpn-terminology-00.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. From exim@www1.ietf.org Mon Apr 26 17:11:01 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 RAA23380 for ; Mon, 26 Apr 2004 17:11:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIDBX-00021w-47 for l3vpn-archive@odin.ietf.org; Mon, 26 Apr 2004 16:58:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QKwdxg007798 for l3vpn-archive@odin.ietf.org; Mon, 26 Apr 2004 16:58:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BID0X-0007Nk-6q for l3vpn-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 16:47:17 -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 QAA18642 for ; Mon, 26 Apr 2004 16:47: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 1BID0V-0000Dn-Bk for l3vpn-web-archive@ietf.org; Mon, 26 Apr 2004 16:47:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BICq2-00062P-00 for l3vpn-web-archive@ietf.org; Mon, 26 Apr 2004 16:36:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BICZf-0004bu-00 for l3vpn-web-archive@ietf.org; Mon, 26 Apr 2004 16:19:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBr2-0000m3-UR; Mon, 26 Apr 2004 15:33:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIBkW-0008Iw-Hh for l3vpn@optimus.ietf.org; Mon, 26 Apr 2004 15:26:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13230; Mon, 26 Apr 2004 15:26:38 -0400 (EDT) Message-Id: <200404261926.PAA13230@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-vpn-vr-02.txt Date: Mon, 26 Apr 2004 15:26:37 -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: , List-Id: List-Post: List-Help: List-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 : Network based IP VPN Architecture using Virtual Routers Author(s) : P. Knight, et al. Filename : draft-ietf-l3vpn-vpn-vr-02.txt Pages : 22 Date : 2004-4-26 This draft describes a network-based Virtual Private Network (VPN) architecture using the virtual router (VR) concept. Multiple VRs can exist in a single physical device. A VR emulates all the functionality of a physical router, and therefore inherits all existing mechanisms and tools for configuration, operation, accounting, and maintenance. Any routing protocol can be used to distribute VPN reachability information among VRs, and no VPN- related modifications or extensions are needed to the routing protocol for achieving VPN reachability. Direct VR-to-VR connectivity may be configured through layer-2 links or through IP- or MPLS-based tunnels. Traffic from VRs belonging to different VPNs may be aggregated over a 'backbone VR' network, which greatly simplifies VPN provisioning. This architecture accommodates various backbone deployment scenarios, both where the VPN service provider owns the backbone, and where the VPN service provider obtains backbone service from one or more other service providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-vpn-vr-02.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-vpn-vr-02.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-vpn-vr-02.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-4-26150525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-vpn-vr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-vpn-vr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-26150525.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Thu Apr 29 10:30:52 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 KAA05528 for ; Thu, 29 Apr 2004 10:30:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCP4-00063n-2r for l3vpn-archive@odin.ietf.org; Thu, 29 Apr 2004 10:20:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TEKgUc023296 for l3vpn-archive@odin.ietf.org; Thu, 29 Apr 2004 10:20:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCKt-0003XX-8E for l3vpn-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 10:16:23 -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 KAA04318 for ; Thu, 29 Apr 2004 10:16: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 1BJCKi-00034w-AE for l3vpn-web-archive@ietf.org; Thu, 29 Apr 2004 10:16:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCJk-0002p0-00 for l3vpn-web-archive@ietf.org; Thu, 29 Apr 2004 10:15:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCIk-0002ZP-00 for l3vpn-web-archive@ietf.org; Thu, 29 Apr 2004 10:14:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC37-0002At-UG; Thu, 29 Apr 2004 09:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBsv-0007gP-60 for l3vpn@optimus.ietf.org; Thu, 29 Apr 2004 09:47: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 JAA01743 for ; Thu, 29 Apr 2004 09:47:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBsk-0003Yo-Fn for l3vpn@ietf.org; Thu, 29 Apr 2004 09:47:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBrl-0003J0-00 for l3vpn@ietf.org; Thu, 29 Apr 2004 09:46:18 -0400 Received: from [202.54.124.145] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1BJBqs-0002qJ-00 for l3vpn@ietf.org; Thu, 29 Apr 2004 09:45:22 -0400 Received: (qmail 13757 invoked by uid 510); 29 Apr 2004 12:15:13 -0000 Date: 29 Apr 2004 12:15:13 -0000 Message-ID: <20040429121513.13756.qmail@webmail30.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 29 apr 2004 12:15:13 -0000 MIME-Version: 1.0 From: "Karthikeyan Subramaniam" Reply-To: "Karthikeyan Subramaniam" To: erosen@cisco.com, ppsenak@cisco.com, padma@juniper.net Cc: l3vpn@ietf.org, dasnabendu123@hotmail.com Subject: Sham link query Content-type: multipart/alternative; boundary="Next_1083240913---0-202.54.124.145-13754" 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,HTML_20_30, HTML_IMAGE_ONLY_10,HTML_MESSAGE,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 This is a multipart mime message --Next_1083240913---0-202.54.124.145-13754 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A 
=0AHello,
=0A
=0A    I have doubt in sham= link. Can anybody please address following query.
=0A
=0ALet us assu= me a sham link (unnumbered P2P link) is configured between PE1 and PE2 (int= erconnected via P routers). In OSPF, on physical point-to-point networks, t= he IP destination is always set to the address AllSPFRouters.
=0A
= =0A
=0AConsidering the unnumbered P2P link, what can be the destination = address in OSPF packet and how OSPF packets are addressed from one PE to ot= her PE via sham link????
=0A
=0AThanks in advance,
=0AS.Karthikey= an
=0A
=0A=0A

=0A=0A=0A
=0A

=0A=0A --Next_1083240913---0-202.54.124.145-13754 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =A0=0AHello,=0A=0A I have doubt in sham link. Can anybody please addre= ss following query.=0A=0ALet us assume a sham link (unnumbered P2P link) is= configured between PE1 and PE2 (interconnected via P routers). In OSPF, on= physical point-to-point networks, the IP destination is always set to the = address AllSPFRouters. =0A=0A=0AConsidering the unnumbered P2P link, what c= an be the destination address in OSPF packet and how OSPF packets are addre= ssed from one PE to other PE via sham link???? =0A=0AThanks in advance,=0AS= .Karthikeyan=0A=0A=0A=0A=0A --Next_1083240913---0-202.54.124.145-13754-- From exim@www1.ietf.org Fri Apr 30 11:22:23 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 LAA08020 for ; Fri, 30 Apr 2004 11:22:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZdP-0006wG-MS for l3vpn-archive@odin.ietf.org; Fri, 30 Apr 2004 11:09:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UF93Cb026672 for l3vpn-archive@odin.ietf.org; Fri, 30 Apr 2004 11:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZVj-0005LA-JR for l3vpn-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 11:01: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 LAA06097 for ; Fri, 30 Apr 2004 11:01: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 1BJZVh-000718-6y for l3vpn-web-archive@ietf.org; Fri, 30 Apr 2004 11:01:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZUm-0006y8-00 for l3vpn-web-archive@ietf.org; Fri, 30 Apr 2004 11:00:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJZTx-0006w7-00 for l3vpn-web-archive@ietf.org; Fri, 30 Apr 2004 10:59:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZH9-0002ok-U5; Fri, 30 Apr 2004 10:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZ7S-0000oz-VX for l3vpn@optimus.ietf.org; Fri, 30 Apr 2004 10:36: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 KAA04822 for ; Fri, 30 Apr 2004 10:35: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 1BJZ7Q-0005b3-Kd for l3vpn@ietf.org; Fri, 30 Apr 2004 10:36:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZ6V-0005Zy-00 for l3vpn@ietf.org; Fri, 30 Apr 2004 10:35:04 -0400 Received: from [202.54.124.179] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1BJZ5d-0005Wy-00 for l3vpn@ietf.org; Fri, 30 Apr 2004 10:34:09 -0400 Received: (qmail 1707 invoked by uid 510); 30 Apr 2004 12:49:02 -0000 Date: 30 Apr 2004 12:49:02 -0000 Message-ID: <20040430124902.1706.qmail@webmail10.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 30 apr 2004 12:49:02 -0000 MIME-Version: 1.0 From: "Karthikeyan Subramaniam" Reply-To: "Karthikeyan Subramaniam" To: "Peter Psenak" Cc: erosen@cisco.com, padma@juniper.net, l3vpn@ietf.org, dasnabendu123@hotmail.com Subject: draft-ietf-l3vpn-ospf-2547-01.txt query Content-type: multipart/alternative; boundary="Next_1083329342---0-202.54.124.179-1704" 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: , List-Id: List-Post: List-Help: List-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.3 required=5.0 tests=AWL,HTML_MESSAGE, MSGID_FROM_MTA_HEADER autolearn=no version=2.60 This is a multipart mime message --Next_1083329342---0-202.54.124.179-1704 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHello,
=0A
=0A    As stated in the draft draft-ietf-l= 3vpn-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  standar= d 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 &quo= t;real" AS-external routes
=0A  that may be circulating in th= e VPN. (That is, so that they can be
=0A  distinguished by OSPF fr= om routes which really do not come from
=0A  within the VPN.)"= ;
=0A
=0A  So the query is why do we need to distinguish As-ext= ernal routes from inter-area routes from VPN perspective??? (I guess Type-3= LSAs are generated for proper database synchronization from OSPF perspecti= ve, is there any other reason???)
=0A
=0AThanks in advance
=0AS.Ka= rthikeyan
=0A
=0A
=0A=0A

=0A=0A=0A
=0A

=0A=0A --Next_1083329342---0-202.54.124.179-1704 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello,=0A=0A=A0 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 undesirable; it would be much=0A bet= ter to deliver such routes in type 3 LSAs (as inter-area routes),=0A so t= hat 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 distingui= shed by OSPF from routes 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 ge= nerated for proper database synchronization from OSPF perspective, is there= any other reason???)=0A=0AThanks in advance=0AS.Karthikeyan=0A=0A=0A=0A=0A= =0A --Next_1083329342---0-202.54.124.179-1704-- From exim@www1.ietf.org Fri Apr 30 13:02:15 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 NAA14767 for ; Fri, 30 Apr 2004 13:02:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbLh-00046f-4l for l3vpn-archive@odin.ietf.org; Fri, 30 Apr 2004 12:58:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UGwrVO015780 for l3vpn-archive@odin.ietf.org; Fri, 30 Apr 2004 12:58:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbDF-0002Og-2i for l3vpn-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 12:50:09 -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 MAA13974 for ; Fri, 30 Apr 2004 12:50:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbDD-0007jl-Ai for l3vpn-web-archive@ietf.org; Fri, 30 Apr 2004 12:50:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbCH-0007fV-00 for l3vpn-web-archive@ietf.org; Fri, 30 Apr 2004 12:49:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJbBN-0007b8-00 for l3vpn-web-archive@ietf.org; Fri, 30 Apr 2004 12:48:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJb5S-00010m-2w; Fri, 30 Apr 2004 12:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaxk-0006zw-Uj for l3vpn@optimus.ietf.org; Fri, 30 Apr 2004 12:34:08 -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 MAA13052 for ; Fri, 30 Apr 2004 12:34:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJaxj-0006PR-CC for l3vpn@ietf.org; Fri, 30 Apr 2004 12:34:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJawk-0006LQ-00 for l3vpn@ietf.org; Fri, 30 Apr 2004 12:33:06 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJavo-0006Gh-00 for l3vpn@ietf.org; Fri, 30 Apr 2004 12:32:08 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 924B26D14E4; Fri, 30 Apr 2004 09:32: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 12570-01; Fri, 30 Apr 2004 09:32:06 -0700 (PDT) Received: from redback.com (dhcp-41-22.redback.com [155.53.41.22]) by prattle.redback.com (Postfix) with ESMTP id EEFA66D14E0; Fri, 30 Apr 2004 09:32:05 -0700 (PDT) Message-ID: <40927F7F.94CBB5FC@redback.com> Date: Fri, 30 Apr 2004 09:31:59 -0700 From: Anand Oswal Organization: Redback Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Karthikeyan Subramaniam Cc: l3vpn@ietf.org, dasnabendu123@hotmail.com Subject: Re: draft-ietf-l3vpn-ospf-2547-01.txt query References: <20040430124902.1706.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: , List-Id: List-Post: List-Help: List-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 Karthikeyan, The remote CE routers of the same VPN, need to appear as if they are part of the same OSPF domain, that is why we carry Type 1,2,3 LSAs as Type 3. If you carry all your routes as AS External, how would you know which ones are the "real" Ext routes Thanks Anand Karthikeyan Subramaniam wrote: > > Hello, > > As stated in the draft draft-ietf-l3vpn-ospf-2547-01.txt, > > "Per [VPN], the VPN routes are distributed among the PE routers by > BGP. If the PE uses OSPF to distribute routes to the CE router, the > standard procedures governing BGP/OSPF interactions [OSPF] would > cause routes from one site to be delivered to another as AS-external > > routes (in type 5 LSAs). This is undesirable; it would be much > better to deliver such routes in type 3 LSAs (as inter-area routes), > so that they can be distinguished from any "real" AS-external routes > that may be circulating in the VPN. (That is, so that they can be > distinguished by OSPF from routes which really do not come from > within the VPN.)" > > 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 generated for proper database synchronization from OSPF perspective, is there any other reason???) > > Thanks in advance > S.Karthikeyan From exim@www1.ietf.org Fri Apr 30 13:12:24 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 NAA15418 for ; Fri, 30 Apr 2004 13:12:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbXG-0006cC-CP for l3vpn-archive@odin.ietf.org; Fri, 30 Apr 2004 13:10:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UHAokg025424 for l3vpn-archive@odin.ietf.org; Fri, 30 Apr 2004 13:10:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbNC-0004LF-VE for l3vpn-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 13:00:27 -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 NAA14568 for ; Fri, 30 Apr 2004 13:00:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbNB-0000bx-6x for l3vpn-web-archive@ietf.org; Fri, 30 Apr 2004 13:00:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbMA-0000W4-00 for l3vpn-web-archive@ietf.org; Fri, 30 Apr 2004 12:59:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJbLJ-0000Ro-00 for l3vpn-web-archive@ietf.org; Fri, 30 Apr 2004 12:58:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJb9J-0001tc-PH; Fri, 30 Apr 2004 12:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJb3e-0000UC-4p for l3vpn@optimus.ietf.org; Fri, 30 Apr 2004 12:40: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 MAA13417 for ; Fri, 30 Apr 2004 12:40:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJb3c-0006uf-F1 for l3vpn@ietf.org; Fri, 30 Apr 2004 12:40:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJb2x-0006rn-00 for l3vpn@ietf.org; Fri, 30 Apr 2004 12:39:32 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BJb2J-0006mx-00 for l3vpn@ietf.org; Fri, 30 Apr 2004 12:38:51 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 62B999F0F06; Fri, 30 Apr 2004 09:38:51 -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 14390-03; Fri, 30 Apr 2004 09:38:51 -0700 (PDT) Received: from redback.com (dhcp-41-22.redback.com [155.53.41.22]) by prattle.redback.com (Postfix) with ESMTP id B017C9F0F07; Fri, 30 Apr 2004 09:38:50 -0700 (PDT) Message-ID: <40928113.62B92201@redback.com> Date: Fri, 30 Apr 2004 09:38:43 -0700 From: Anand Oswal Organization: Redback Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Karthikeyan Subramaniam Cc: erosen@cisco.com, ppsenak@cisco.com, padma@juniper.net, l3vpn@ietf.org, dasnabendu123@hotmail.com Subject: Re: Sham link query References: <20040429121513.13756.qmail@webmail30.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: , List-Id: List-Post: List-Help: List-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 Hi Kartikeyan, During sham link configuration (manual) you will specify the sham link endpoint. OSPF packets will be unicast to this destination address. There is also a way to dynamically figure out the sham link endpoint.... Thanks Anand Karthikeyan Subramaniam wrote: > > > Hello, > > I have doubt in sham link. Can anybody please address following query. > > Let us assume a sham link (unnumbered P2P link) is configured between PE1 and PE2 (interconnected via P routers). In OSPF, on physical point-to-point networks, the IP destination is always set to the address AllSPFRouters. > > Considering the unnumbered P2P link, what can be the destination address in OSPF packet and how OSPF packets are addressed from one PE to other PE via sham link???? > > Thanks in advance, > S.Karthikeyan