From l3vpn-bounces@ietf.org Mon Jul 04 12:04:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpTQa-0007hk-BB; Mon, 04 Jul 2005 12:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpTQY-0007hW-Rw for l3vpn@megatron.ietf.org; Mon, 04 Jul 2005 12:04:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05599 for ; Mon, 4 Jul 2005 12:04:08 -0400 (EDT) Received: from web304.biz.mail.mud.yahoo.com ([68.142.199.180]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DpTr5-0007AO-9j for l3vpn@ietf.org; Mon, 04 Jul 2005 12:31:40 -0400 Received: (qmail 27472 invoked by uid 60001); 4 Jul 2005 16:03:49 -0000 Message-ID: <20050704160349.27470.qmail@web304.biz.mail.mud.yahoo.com> Received: from [221.221.9.49] by web304.biz.mail.mud.yahoo.com via HTTP; Mon, 04 Jul 2005 09:03:49 PDT Date: Mon, 4 Jul 2005 09:03:49 -0700 (PDT) From: Joseph Laria To: Adrian Farrel , l3vpn@ietf.org In-Reply-To: <0d1401c578e1$9dac59e0$7f849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 8bit Cc: jlaria@levelstream.com Subject: Re: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hi Adrian, Thanks for your thoughtful comments. I've replied in-line below. Regards. Joe Laria --- Adrian Farrel wrote: > Hi, > > A few brief comments. Nothing very important. > > I-D should indicate intended status. > Since you have suggested that the OID is > "experimental" perhaps this I-D > is also Experimental? I disagree. Rather the I-D would be informational. The VR MIB would likely go under mib-2 as does the vpnTcMIB. This change would be incorporated in the next version of the draft. > > Most mentions of "MIB" should read "MIB module" I agree and will encorporate your suggestion in the next version of the draft. > > Nice to indicate (in a comment and not using square > brackets) the RFC > number of imports. > (e.g. see draft-ietf-ccamp-gmpls-te-mib-09.txt) I agree, but I this follows the style of other drafts in the WG. > > vrName Description clause has spare period and line > break. I agree and will encorporate your suggestion in the next version of the draft. > > vrRpTrigger Description appears to repeat itself. I agree and will encorporate your suggestion in the next version of the draft. > > vrRpTrigger > "Bits 4-7 are reserved for future use." > I think the BITS syntax is not constrained to be > exactly 8 bits. So you > don't need this sentence. I agree and will encorporate your suggestion in the next version of the draft. > > vrActiveVRs > "vrStatOperationalStatus" should read "vrOperStatus" I agree and will encorporate your suggestion in the next version of the draft. > > vrRpStatus > Shouldn't this have Syntax BITS and a back pointer > to vrRpTrigger? > Better still would be to define a Textual Convention > for them both to use. I agree and will encorporate your suggestion in the next version of the draft. > > vrRouterAddress > Are you sure that this cannot be configured per VR? The VR router addresses are indexed by VR. They can be configured per VR. > > All Notifications return vrRowStatus. I would have > expected vrOperStatus. > Seems, however, to be unnecessary as the status can > be deduced from the > trap type. I agree, but it seems unnecessary as the status can be deduced from the trap type. > > vrUp and vrDown > The Description clauses should refer explicitly to > vrOperStatus I agree and will encorporate your suggestion in the next version of the draft. > > vrMaxRoutesExceeded > Isn't there a danger of Notification storms with > this Notification? > The definition of vrMaxRoutes is such that > vrStatRouteEntries could never > exceed it. So when you reach vrMaxRoutes, each new > attempt to add a route > will cause a new Notification. I agree and will encorporate your suggestion in the next version of the draft. > > You should probably reference as normative the RFCs > from which you import > things. > That will include the new RFC4001. > Also VPN-TC-STD-MIB in draft-ietf-l3vpn-tc-mib. This > is pretty important > as this I-D must not go to RFC before that one does. I agree and will encorporate your suggestion in the next version of the draft. > > Cheers, > Adrian > > ----- Original Message ----- > From: "Ron Bonica" > To: > Sent: Wednesday, June 22, 2005 10:16 PM > Subject: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 > > > > Folks, > > > > This message begins a working group last call on > > draft-ietf-l3vpn-vr-mib. The last call will end on > > July 8. > > > > Ron > > > > > > -------- Original Message -------- > > Subject: I-D ACTION:draft-ietf-l3vpn-vr-mib-03.txt > > Date: Wed, 22 Jun 2005 15:50:01 -0400 > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: l3vpn@ietf.org > > > > 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 : Virtual Router Management Information Base > Using SMIv2 > > Author(s) : E. Stelzer, et al. > > Filename : draft-ietf-l3vpn-vr-mib-03.txt > > Pages : 21 > > Date : 2005-6-22 > > > > This memo defines a portion of the Management > Information Base (MIB) > > for use with network management protocols in > TCP/IP based internets. > > In particular, it defines objects for managing > networks using Virtual > > Routers (VR). > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-vr-mib-03.txt > > > > > > > > > > > > > From l3vpn-bounces@ietf.org Tue Jul 05 13:52:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprbB-0003rP-1O; Tue, 05 Jul 2005 13:52:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dprb8-0003qX-B2 for l3vpn@megatron.ietf.org; Tue, 05 Jul 2005 13:52:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29910 for ; Tue, 5 Jul 2005 13:52:40 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dps0v-0006Kf-Od for l3vpn@ietf.org; Tue, 05 Jul 2005 14:19:25 -0400 Received: from du-069-0326.access.clara.net ([217.158.145.72] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1DprZr-0008ZI-Fd; Tue, 05 Jul 2005 18:51:24 +0100 Message-ID: <036e01c5818a$7f141660$db849ed9@Puppy> From: "Adrian Farrel" To: "Joseph Laria" , References: <20050704160349.27470.qmail@web304.biz.mail.mud.yahoo.com> Date: Tue, 5 Jul 2005 18:32:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: jlaria@levelstream.com Subject: Re: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hi Joseph, Thanks for the response. Cutting down to just a couple of points. > > vrRouterAddress > > Are you sure that this cannot be configured per VR? > The VR router addresses are indexed by VR. They can > be configured per VR. OK, but you are in the vrStatTable which is all read-only. That means that you cannot configure this item. This may be your intention, but if so, I'm not clear how you do set the address. > > All Notifications return vrRowStatus. I would have > > expected vrOperStatus. > > Seems, however, to be unnecessary as the status can > > be deduced from the trap type. > I agree, but it seems unnecessary as the status can be > deduced from the trap type. OK. So does that mean you will remove vrRowStatus and not include vrOperStatus? Regards, Adrian From l3vpn-bounces@ietf.org Wed Jul 06 16:36:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGd8-00049z-Da; Wed, 06 Jul 2005 16:36:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGd4-00046A-LF; Wed, 06 Jul 2005 16:36:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24239; Wed, 6 Jul 2005 16:36:20 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqH48-0004jo-3a; Wed, 06 Jul 2005 17:04:20 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DqGd3-0007Rn-Sf; Wed, 06 Jul 2005 16:36:21 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 06 Jul 2005 16:36:21 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: l3vpn@ietf.org Subject: Last Call: 'Constrained VPN Route Distribution' to Proposed Standard X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org The IESG has received a request from the Layer 3 Virtual Private Networks WG to consider the following document: - 'Constrained VPN Route Distribution ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-07-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt From l3vpn-bounces@ietf.org Thu Jul 07 01:04:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqOZ0-0007c9-CT; Thu, 07 Jul 2005 01:04:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqOYv-0007bt-8S for l3vpn@megatron.ietf.org; Thu, 07 Jul 2005 01:04:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04688 for ; Thu, 7 Jul 2005 01:04:36 -0400 (EDT) Received: from web30312.mail.mud.yahoo.com ([68.142.201.230]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DqP00-0003U4-Ja for l3vpn@ietf.org; Thu, 07 Jul 2005 01:32:39 -0400 Received: (qmail 94266 invoked by uid 60001); 7 Jul 2005 05:04:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=X3JWHRkJqTbPCgZfBITelz/kg4C8i4gjfZfQEP6dqdjEywWpC4mjM3iIGxrGbBfhpMBf7BjQZwqWOb6MjnHzek+f7NJ494sc9Xtmmz/XTrMZcpAmV/F8PQsOBaOirQgHbwBgpjSH2No5+JiXtxHEsLCzsNlcVc/sJZvw7MC59ho= ; Message-ID: <20050707050425.94264.qmail@web30312.mail.mud.yahoo.com> Received: from [63.201.35.117] by web30312.mail.mud.yahoo.com via HTTP; Wed, 06 Jul 2005 22:04:25 PDT Date: Wed, 6 Jul 2005 22:04:25 -0700 (PDT) From: Sam Hancock To: Adrian Farrel , Joseph Laria , l3vpn@ietf.org In-Reply-To: <036e01c5818a$7f141660$db849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 4.0 (++++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 8bit Cc: jlaria@levelstream.com Subject: Re: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hello Adrian, Please see my comments inline with the questions. Cheers, Sam> --- Adrian Farrel wrote: > Hi Joseph, > > Thanks for the response. > Cutting down to just a couple of points. > > > > vrRouterAddress > > > Are you sure that this cannot be configured per VR? > > The VR router addresses are indexed by VR. They can > > be configured per VR. > > OK, but you are in the vrStatTable which is all read-only. That means that > you cannot configure this item. > This may be your intention, but if so, I'm not clear how you do set the > address. > The address is configured at the interface level, and then interfaces are attached to the VR via the vrIfConfigTable. > > > All Notifications return vrRowStatus. I would have > > > expected vrOperStatus. > > > Seems, however, to be unnecessary as the status can > > > be deduced from the trap type. > > I agree, but it seems unnecessary as the status can be > > deduced from the trap type. > > OK. So does that mean you will remove vrRowStatus and not include > vrOperStatus? All notifications return vrRowStatus to assist in finding the vrId. Since the vrId is a not-accessible, the vrRowStatus was added to the varbind list. The vrOperStatus seemed redundant to the vrUp and vrDown notifications--although it could serve similar role in deriving the vrId. > > Regards, > Adrian > > > From l3vpn-bounces@ietf.org Thu Jul 07 01:56:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPMt-0002WS-UL; Thu, 07 Jul 2005 01:56:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPMm-0002Pp-75 for l3vpn@megatron.ietf.org; Thu, 07 Jul 2005 01:56:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08751 for ; Thu, 7 Jul 2005 01:56:06 -0400 (EDT) Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqPnr-0001hS-Q6 for l3vpn@ietf.org; Thu, 07 Jul 2005 02:24:10 -0400 Received: from spark.hss.co.in (localhost [127.0.0.1]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j675pAZN022054 for ; Thu, 7 Jul 2005 11:21:10 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j675p94f022051 for ; Thu, 7 Jul 2005 11:21:09 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id j675un501550 for ; Thu, 7 Jul 2005 11:26:50 +0530 (IST) To: l3vpn@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Swati Gupta SBBD Date: Thu, 7 Jul 2005 11:23:05 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 07/07/2005 11:25:47 AM, Serialize complete at 07/07/2005 11:25:47 AM Content-Type: multipart/alternative; boundary="=_alternative 00210F5B65257037_=" X-Spam-Score: 0.2 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: Doubts related to draft-ietf-l3vpn-rfc2547bis-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org This is a multipart message in MIME format. --=_alternative 00210F5B65257037_= Content-Type: text/plain; charset="US-ASCII" Hi, I was going through IETF draft for L3 VPN - " draft-ietf-l3vpn-rfc2547bis-03.txt " and in that i am having some doubts. 1. Section 4.3.2 - Route distribution Among PEs by BGP In this on Page 20, it talks about assigning labels. So, in the 2nd point i.e. assigning a label per Outgoing Attachment Circuit (AC), it says that no VRF lookup is required but ARP lookup will be done for data link encapsulation. This ARP lookup is needed in all the 3 cases to get the MAC address of the attached CE device ? So, in this case, from Label Information Base, we can directly get attachment circuit and data link encapsulation information. Please correct me if i am wrong somewhere. 2. Section 5 - Forwarding On page 25, regarding forwarding, it discusses 2 cases- (1) ingress & egress attachment circuits are on the same PE and associated with the same VRF and (2) both are associated with different VRFs. I am not able to make out how this comes about. Please clarify. Its urgently required Thanks in advance Swati *********************** FSS-Private *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." --=_alternative 00210F5B65257037_= Content-Type: text/html; charset="US-ASCII"
Hi,

I was going through IETF draft for L3 VPN - " draft-ietf-l3vpn-rfc2547bis-03.txt " and in that i am having some doubts.

1. Section 4.3.2  - Route distribution Among PEs by BGP

        In this on Page 20, it talks about assigning labels. So, in the 2nd point i.e. assigning a label per Outgoing Attachment Circuit (AC), it says that no VRF                 lookup is required but  ARP lookup will be done for data link encapsulation. This ARP lookup is needed in all the 3 cases to get the MAC address of         the attached CE device ?  So, in this case, from Label Information Base, we can directly get attachment circuit and data link encapsulation information.
        Please correct me if i am wrong somewhere.

2. Section 5 - Forwarding

        On page 25, regarding forwarding, it discusses 2 cases- (1) ingress & egress attachment circuits are on the same PE and associated with the same         VRF and  (2) both are associated with different VRFs.
        I am not able to make out how this comes about.


Please clarify. Its urgently required

Thanks in advance

Swati

***********************  FSS-Private   *********************** 
"DISCLAIMER: This message is proprietary to Flextronics Software 
Systems Limited (FSS) and is intended solely for the use of the  
individual to whom it is addressed. It may contain  privileged or 
confidential information and should not be circulated or used for 
any purpose other than for what it is intended. If you have received 
this message in  error, please notify the originator immediately. 
If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
the contents of this message.  FSS  accepts no  responsibility  for
loss or damage arising from the use of  the information transmitted
by this email including damage from virus."
--=_alternative 00210F5B65257037_=-- From l3vpn-bounces@ietf.org Thu Jul 07 02:20:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPk4-0007pq-HM; Thu, 07 Jul 2005 02:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPk0-0007oJ-ON for l3vpn@megatron.ietf.org; Thu, 07 Jul 2005 02:20:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28527 for ; Thu, 7 Jul 2005 02:20:07 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqQB7-0006mv-Qd for l3vpn@ietf.org; Thu, 07 Jul 2005 02:48:11 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 06 Jul 2005 23:20:05 -0700 X-IronPort-AV: i="3.93,267,1115017200"; d="scan'208"; a="292562735:sNHT29562668" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j676K2vM027339; Wed, 6 Jul 2005 23:20:02 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 23:20:04 -0700 Received: from [10.21.83.65] ([10.21.83.65]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 23:20:04 -0700 Message-ID: <42CCC991.3020104@cisco.com> Date: Wed, 06 Jul 2005 23:20:01 -0700 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Swati Gupta SBBD References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2005 06:20:04.0619 (UTC) FILETIME=[E9FE75B0:01C582BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: Doubts related to draft-ietf-l3vpn-rfc2547bis-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hey Swati, > 1. Section 4.3.2 - Route distribution Among PEs by BGP > > In this on Page 20, it talks about assigning labels. So, in the > 2nd point i.e. assigning a label per Outgoing Attachment Circuit (AC), > it says that no VRF lookup is required but ARP lookup > will be done for data link encapsulation. This ARP lookup is needed in > all the 3 cases to get the MAC address of the attached CE device > ? So, in this case, from Label Information Base, we can directly get > attachment circuit and data link encapsulation information. > Please correct me if i am wrong somewhere. ARP will be needed in all three cases. The difference is that in first and third case other system components are responsible for it. I think authors just listed the directly involved system components in the draft. > 2. Section 5 - Forwarding > > On page 25, regarding forwarding, it discusses 2 cases- (1) > ingress & egress attachment circuits are on the same PE and associated > with the same VRF and (2) both are associated with different VRFs. > I am not able to make out how this comes about. Oh that is very simple :) It basically describes the case where the result of your best IP lookup in the incoming vrf indicated that the packet needs to be switched back to the some local attachment circuits in the same vrf or in any other vrf of the same PE. Essentially it means that there are deployment scenarios where you don't need to impose any labels on the packets to switch between VPN sites attached to a given PE. Notice that is also says that it is an implementation choice if the egress vrf needs to do any lookup or not if we are doing local vrf to vrf switching within the same PE. Let me know if you have any more questions .. Cheers, R. From l3vpn-bounces@ietf.org Thu Jul 07 09:22:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWLA-0002Er-G2; Thu, 07 Jul 2005 09:22:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWL8-0002E8-Pn for l3vpn@megatron.ietf.org; Thu, 07 Jul 2005 09:22:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05495 for ; Thu, 7 Jul 2005 09:22:52 -0400 (EDT) Received: from wm11.inbox.com ([208.50.6.11]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DqWmH-0007PK-Pt for l3vpn@ietf.org; Thu, 07 Jul 2005 09:51:01 -0400 Received: from inbox.com (127.0.0.1:25) by inbox.com with [InBox.Com ESMTP Server] id <507070021759.WM11> for from ; Thu, 7 Jul 2005 5:22:29 AM -0800 Mime-Version: 1.0 Date: Thu, 7 Jul 2005 05:22:27 -0800 Message-ID: <0CAFFF9F552.000000FDgn_sudarsanreddy@inbox.com> From: naga sudarsanreddy To: l3vpn@ietf.org X-Mailer: IBISIT WebMail Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Subject: RE: L3vpn Digest, Vol 15, Issue 2 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org hello friends, i want informatoinr regarding vpn.please send material regarding vpn. ur's amiable, sudarsan > -----Original Message----- > From: l3vpn-request=40ietf.org > To: l3vpn=40ietf.org > Subject: L3vpn Digest, Vol 15, Issue 2 > > Send L3vpn mailing list submissions to > =09l3vpn=40ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > =09https://www1.ietf.org/mailman/listinfo/l3vpn > or, via email, send a message with subject or body 'help' to > =09l3vpn-request=40ietf.org > > You can reach the person managing the list at > =09l3vpn-owner=40ietf.org > > When replying, please edit your Subject line so it is more specific > than =22Re: Contents of L3vpn digest...=22 > > > Today's Topics: > > 1. Re: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 (Adrian Farrel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 5 Jul 2005 18:32:07 +0100 > From: =22Adrian Farrel=22 > Subject: Re: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 > To: =22Joseph Laria=22 , > Cc: jlaria=40levelstream.com > Message-ID: <036e01c5818a=247f141660=24db849ed9=40Puppy> > Content-Type: text/plain;=09charset=3D=22iso-8859-1=22 > > Hi Joseph, > > Thanks for the response. > Cutting down to just a couple of points. > > > > vrRouterAddress > > > Are you sure that this cannot be configured per VR? > > The VR router addresses are indexed by VR. They can > > be configured per VR. > > OK, but you are in the vrStatTable which is all read-only. That means > that > you cannot configure this item. > This may be your intention, but if so, I'm not clear how you do set the > address. > > > > All Notifications return vrRowStatus. I would have > > > expected vrOperStatus. > > > Seems, however, to be unnecessary as the status can > > > be deduced from the trap type. > > I agree, but it seems unnecessary as the status can be > > deduced from the trap type. > > OK. So does that mean you will remove vrRowStatus and not include > vrOperStatus? > > Regards, > Adrian > > > > > ------------------------------ > > _______________________________________________ > L3vpn mailing list > L3vpn=40ietf.org > https://www1.ietf.org/mailman/listinfo/l3vpn > > > End of L3vpn Digest, Vol 15, Issue 2 > ************************************= From l3vpn-bounces@ietf.org Fri Jul 08 10:08:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqtWe-0008OG-J9; Fri, 08 Jul 2005 10:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqtWc-0008O7-Vj for l3vpn@megatron.ietf.org; Fri, 08 Jul 2005 10:08:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04294 for ; Fri, 8 Jul 2005 10:08:17 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqtxz-00021A-PY for l3vpn@ietf.org; Fri, 08 Jul 2005 10:36:38 -0400 Received: from du-069-0161.access.clara.net ([217.158.132.161] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DqtWP-000PXX-8y; Fri, 08 Jul 2005 15:08:06 +0100 Message-ID: <05b301c583c6$cdca2ef0$db849ed9@Puppy> From: "Adrian Farrel" To: "Sam Hancock" , "Joseph Laria" , References: <20050707050425.94264.qmail@web30312.mail.mud.yahoo.com> Date: Fri, 8 Jul 2005 14:26:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: jlaria@levelstream.com Subject: Re: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org OK Sam, Clear. Adrian ----- Original Message ----- From: "Sam Hancock" To: "Adrian Farrel" ; "Joseph Laria" ; Cc: Sent: Thursday, July 07, 2005 6:04 AM Subject: Re: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 > Hello Adrian, > Please see my comments inline with the questions. > Cheers, > Sam> > > --- Adrian Farrel wrote: > > > Hi Joseph, > > > > Thanks for the response. > > Cutting down to just a couple of points. > > > > > > vrRouterAddress > > > > Are you sure that this cannot be configured per VR? > > > The VR router addresses are indexed by VR. They can > > > be configured per VR. > > > > OK, but you are in the vrStatTable which is all read-only. That means that > > you cannot configure this item. > > This may be your intention, but if so, I'm not clear how you do set the > > address. > > > > The address is configured at the interface level, and then interfaces are > attached to the VR via the vrIfConfigTable. > > > > > All Notifications return vrRowStatus. I would have > > > > expected vrOperStatus. > > > > Seems, however, to be unnecessary as the status can > > > > be deduced from the trap type. > > > I agree, but it seems unnecessary as the status can be > > > deduced from the trap type. > > > > OK. So does that mean you will remove vrRowStatus and not include > > vrOperStatus? > > All notifications return vrRowStatus to assist in finding the vrId. Since the > vrId is a not-accessible, the vrRowStatus was added to the varbind list. The > vrOperStatus seemed redundant to the vrUp and vrDown notifications--although it > could serve similar role in deriving the vrId. > > > > > Regards, > > Adrian > > > > > > > > > > From l3vpn-bounces@ietf.org Mon Jul 11 15:32:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds418-0001jp-QG; Mon, 11 Jul 2005 15:32:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds417-0001jQ-E7 for l3vpn@megatron.ietf.org; Mon, 11 Jul 2005 15:32:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14495 for ; Mon, 11 Jul 2005 15:32:33 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds4T8-0005tz-5e for l3vpn@ietf.org; Mon, 11 Jul 2005 16:01:35 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 20:32:15 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 20:32:13 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 11 Jul 2005 15:32:12 -0400 Received: from [172.25.42.177] ([172.25.42.177]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 15:32:12 -0400 Message-ID: <42D2C93B.6090201@juniper.net> Date: Mon, 11 Jul 2005 15:32:11 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org, Ross Callon , Rick Wilder , Ronald Bonica X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2005 19:32:12.0117 (UTC) FILETIME=[3C3E2050:01C5864F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: Subject: IETF 63 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Folks, If you want time on the L3VPN agenda for IETF 63, please email Ross, Rick and I privately. Ron From l3vpn-bounces@ietf.org Tue Jul 12 23:55:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYLA-0002mv-Mo; Tue, 12 Jul 2005 23:55:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYL8-0002mq-Jd for l3vpn@megatron.ietf.org; Tue, 12 Jul 2005 23:55:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23073 for ; Tue, 12 Jul 2005 23:55:15 -0400 (EDT) Received: from vms048pub.verizon.net ([206.46.252.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsYnS-0003fC-NH for l3vpn@ietf.org; Wed, 13 Jul 2005 00:24:35 -0400 Received: from [192.168.0.6] ([70.19.137.160]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IJJ002STS7QBRO1@vms048.mailsrvcs.net> for l3vpn@ietf.org; Tue, 12 Jul 2005 22:55:04 -0500 (CDT) Date: Tue, 12 Jul 2005 23:54:32 -0400 From: Mark Duffy In-reply-to: <200506271516.j5RFGAZs025568@rtp-core-2.cisco.com> To: erosen@cisco.com, l3vpn@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed References: <200506271516.j5RFGAZs025568@rtp-core-2.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: Subject: Re: Last call: draft-ietf-l3vpn-ipsec-2547-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hi Eric, and thanks for updating this draft and addressing my comments. The document looks ready to go to me; I'd like to see it get published. I put a few minor comments and responses inline below. --Mark At 11:16 AM -0400 6/27/05, Eric Rosen wrote: ... >Mark> It's great to see this document move forward! > >For some value of "move", I guess ;-) > >Mark> I have several comments, below. (They are relative to the -03 draft, >Mark> which appeared shortly after the last call was issued.) > >Well, sorry about the long delay to respond ;-( The -04 version of the draft >is now available, containing modifications (as indicated below) in response >to the last call comments. > >Some of the issues have to do with the fact that the document does not >always specify enough detail to do interoperable implementations. For >example, it calls for the use of a BGP Extended Communities attribute, but >doesn't define it. > >But I don't think it is worthwhile pinning down all these details unless and >until an implementation is actually to be done. Therefore I propose to >rename the draft to "Architecture for the Use of PE-PE IPsec Tunnels in >BGP/MPLS IP VPNs", and to omit the specification of additional details at >this time. Sounds fine to me. At the time I wrote these comments I was planning to do an implementation. Since then my employment affiliation has changed and likewise my plans ;-) >Mark> In sect. 2.2, 2nd paragraph, it says "In an RFC2547 VPN environment, >Mark> it makes most sense to place control of the policies with the egress >Mark> PE router." I don't necessarily disagree with this but I believe the >Mark> document should offer some arguments in support of this statement, >Mark> since it is the basis for much of what follows. Just because this is >Mark> convenient to implement doesn't necessarily mean it is the most >Mark> desirable. > >Mark> In 2.2, 3rd paragraph, I don't understand what the last sentence >Mark> means: "(However, in this sort of application the ingress PE and the >Mark> egress PE are NOT really independent entities which might conceivably >Mark> have different security policies.)" Perhaps it can be reworded. > >This section of the document does appear to be a bit confusing. Basically, >we are trying to deal with three situations: > >1. Ingress PE A is configured to use policy P on traffic to egress PE B, and > egress PE B is configured to use policy P on traffic from ingress PE A. > > In this case no special signaling of policy is needed. > >2. Ingress PE A is configured to use policy P on traffic to egress PE B, but > PE B has no policy configuration with respect to traffic from PE A. > > In this case, no special signaling of policy is needed, as the ingress > will apply its configured policy, and the egress will either go along > with it, or else will not be able to receive the traffic. > >3. Egress PE B is configured to use policy P on traffic from ingress PE A, > but PE A has no policy configuration with respect to traffic to PE B. > > In this case, the only way to get traffic to flow is to have B signal its > policy to A. So we propose to have BGP-based signaling for this case. > >I've tried to clear this up. Looks good to me in the current draft. >Mark> The document calls (sect. 2.3) for using an Extended Community to >Mark> signal the requirement to use IPsec for certain VPN routes. But it is >Mark> vague on exactly what the semantics should be and there is no >Mark> allocation of a community type. As such this does not do much to >Mark> encourage interoperable implementations. I don't know, maybe this is >Mark> par for the course for Experimental RFC status? Or should it be >Mark> specified further now? > >I don't think this is worth specifying unless and until an implementation is >underway. ok >Mark> Besides using the (rather blunt, IMO) technique of not accepting labeled >Mark> packets from outside the SP's network, it is difficult (impossible?) >Mark> to create a mixed environment where some traffic is protected by IPsec >Mark> and some is not. This is because there is no way of knowing which PE >Mark> the unprotected traffic came from, and hence no way of making sure >Mark> traffic that was supposed to be protected isn't slipped in with the >Mark> unprotected. If the draft could address this problem in some way >Mark> (perhaps a lowered expectation of supporting such a mixed environment) >Mark> it would be more credible. > >I've tried to make it clearer that if one does not use the "blunt" >technique, one has to protect intra-provider PE-PE tunnels as well as >inter-provider tunnels with IPsec. ok, looks fine >Mark> In sect 2.6 para 3, discussing whether IPsec SAs should be per-PE-pair >Mark> or per-VPN it says "Since the SA is PE-to-PE, NOT CE-to-CE, having a >Mark> different SA for each VPN does not provide any additional security." >Mark> While I agree that per-PE-pair seems to be the right granularity for >Mark> other reasons, I disagree with the statement about not providing >Mark> additional security. Sharing an SA across multiple VPNs allows an >Mark> adversary who can send traffic within one VPN and also sniff the PE-PE >Mark> link to mount a known-plaintext attack against the encryption. > >Interesting. I've rewritten the paragraph as follows: > > A number of different VPNs might need to have traffic carried > from a particular ingress PE to a particular egress PE. It is > thus natural to ask whether there should be one SA between the > pair of PEs, or n SAs between the pair of PEs, where n is the > number of VPNs. Clearly, scalability is improved by having only > a single SA for each pair of PEs. So the question is whether > there is a significant security advantage to having a distinct > SA for each VPN. Since the SA is PE-to-PE, NOT CE-to-CE, having > a different SA for each VPN does not provide any additional > privacy. On the other hand, when multiple VPNs share an SA, the > compromise of a key has a greater impact, and an attack on the > security of one VPN may become an attack on the security of all > the VPNs sharing the SA. Nevertheless, the use of one SA for > multiple VPNs seems to be a reasonable tradeoff of additional > overhead against additional security. I don't disagree with any of that, especially that it's the right tradeoff, but it still misses the original point I was trying to make which was arguing that there may in fact be a security vulnerability created by this sharing of SAs. This may create a vulnerability to a "known plaintext attack" or more accurately, a "chosen plaintext attack." I.e. a user within one of the VPNs, who has access to sniff the encrypted traffic, could send plaintext of her choosing and observe the resulting ciphertext. This can make it easier to break the cipher. So not only does it broaden the *impact* of a crypto compromise (as you describe), it might actually provide a new avenue of attack. I suppose the susceptibility to this depends on the cipher used and it may well be that this is not an issue with popular modern ciphers but that's really beyond my knowledge. Maybe it's purely an academic concern. Since you've changed "does not provide any additional security" to "does not provide any additional privacy", maybe that is good enough. >Mark> In sect 2.6 para 6 it says that the PE router should deliver the >Mark> MPLS-in-IP (or GRE) packet to the IPsec module, along with the >Mark> corresponding IPsec Extended Community value. What is reason for >Mark> passing the extended community? What information does it convey that >Mark> the IPsec module would need? > >I think this is just an error, so I've removed the requirement that the >IPsec Extended Community value be passed. > >Mark> Re sect 2.6: Assuming a given PE device implements IPsec for other >Mark> applications, how is the IKE Responder to determine the purpose of a >Mark> given SA (so that it knows how to process packets received from the >Mark> SA, and so it knows that it can send VPN packets on the SA)? If the >Mark> negotiated traffic selectors are for protocol MPLS-in-IP, it could >Mark> *perhaps* deduce this. But that's an even bigger stretch if the SA is >Mark> negotiated for protocol GRE. There are other possible solutions, >Mark> perhaps deducing the SA is for BGP/MPLS VPN use if the signalling is >Mark> directed to the IP address that is advertised as the BGP next hop >Mark> address. Another possibility might be to define an IKE payload to >Mark> convey this. In any event, calling out one specific mechanism would >Mark> encourage interoperable implementations. > >I'm not sure I understand why the egress PE needs to know that a particular >SA is for BGP/MPLS VPN use. The packets that emerge from the IPsec tunnel >are MPLS packets which are then processed normally. The MPLS label >indicates the disposition of the packet. Sorry, I didn't state the issue very clearly. Agreed that the traffic arriving on the tunnel is self-describing. When two PEs negotiate (via IKE) an SA, they specify the traffic to be covered. For the use described in this memo that traffic will typically be described by the triple {pe1 address, pe2 address, protocol = mpls-in-ip} (or protocol = gre). To negotiate this, they will each have policy indicating that they should accept traffic matching that triple only if it is IPsec protected. Thus *all* mpls-in-ip (or all gre) traffic between the pair of PE addresses must now use IPsec, even if it is not l3vpn traffic. Is this a problem? In some cases it might be. However, IPsec/IKE doesn't provide any general mechanism to avoid that. Anyway, I withdraw the comment. >Mark> In sect. 2.7, item b.iii, it describes case iii relative to item b.ii >Mark> ("... but case ii does not apply"). I suspect that not every reader >Mark> ;-) would reach the same conclusion as to what case this actually >Mark> covers. Can the case be spelled out more specifically? I think >Mark> replacing "but case ii does not apply" with "indicating that IPsec is >Mark> to be used in all cases" would do the trick. > >Fixed. thanks > >Mark> The last 2 paragraphs of sect. 2.7 are very implementation-oriented. >Mark> I don't see that they really add much to the document; I'd consider >Mark> removing them. > >I think they emphasize cautions that need to be taken by the implementation >to avoid errors that would defeat the security measures provided by the >protocols. So I prefer to leave them in if there is no strong objection to >them. ok 1 new nit: In sect 2.2, "If the egress PE is configured to use IPsec but the egress PE is not", I think the second "egress" in the phrase is supposed to be "ingress". Best regards, --Mark From l3vpn-bounces@ietf.org Wed Jul 13 06:43:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsehi-0001kV-At; Wed, 13 Jul 2005 06:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsehg-0001hD-RM for l3vpn@megatron.ietf.org; Wed, 13 Jul 2005 06:43:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24907 for ; Wed, 13 Jul 2005 06:42:57 -0400 (EDT) Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsfA3-0002Wb-Bn for l3vpn@ietf.org; Wed, 13 Jul 2005 07:12:20 -0400 Received: from spark.hss.co.in (localhost [127.0.0.1]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j6DAbg6l008954 for ; Wed, 13 Jul 2005 16:07:44 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id j6DAbeNB008939 for ; Wed, 13 Jul 2005 16:07:41 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id j6DAhAn04557 for ; Wed, 13 Jul 2005 16:13:10 +0530 (IST) To: l3vpn@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Swati Gupta SBBD Date: Wed, 13 Jul 2005 16:09:41 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 13/07/2005 04:12:08 PM, Serialize complete at 13/07/2005 04:12:08 PM Content-Type: multipart/alternative; boundary="=_alternative 003B451A6525703D_=" X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: Doubt related to draft-ietf-l3vpn-rfc2547bis-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org This is a multipart message in MIME format. --=_alternative 003B451A6525703D_= Content-Type: text/plain; charset="US-ASCII" Hi, I am having a doubt in the following L3 VPN draft " draft-ietf-l3vpn-rfc2547bis-03.txt". Section 5 - Forwarding On page 25, regarding forwarding, it discusses 2 cases- (1) ingress & egress attachment circuits are on the same PE and associated with the same VRF and (2) both are associated with different VRFs. The first case is clear to me but the second one raised doubts in my mind related to VRFs. Please this scenario of ingress & egress VRF lookup with an example? Thanks in advance Swati *********************** FSS-Private *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." --=_alternative 003B451A6525703D_= Content-Type: text/html; charset="US-ASCII"
Hi,

I am having a doubt in the following L3 VPN draft " draft-ietf-l3vpn-rfc2547bis-03.txt".

Section 5 - Forwarding

On page 25, regarding forwarding, it discusses 2 cases-
(1)  ingress & egress attachment circuits are on the same PE and associated with the same VRF and  
(2) both are associated with different VRFs.


The first case is clear to me but the second one raised doubts in my mind related to VRFs. Please this scenario of ingress & egress VRF lookup with an example?

 
Thanks in advance
Swati



***********************  FSS-Private   *********************** 
"DISCLAIMER: This message is proprietary to Flextronics Software 
Systems Limited (FSS) and is intended solely for the use of the  
individual to whom it is addressed. It may contain  privileged or 
confidential information and should not be circulated or used for 
any purpose other than for what it is intended. If you have received 
this message in  error, please notify the originator immediately. 
If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
the contents of this message.  FSS  accepts no  responsibility  for
loss or damage arising from the use of  the information transmitted
by this email including damage from virus."
--=_alternative 003B451A6525703D_=-- From l3vpn-bounces@ietf.org Thu Jul 14 15:52:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9km-0008UN-R6; Thu, 14 Jul 2005 15:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9iq-0007hB-Ap; Thu, 14 Jul 2005 15:50:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13725; Thu, 14 Jul 2005 15:50:14 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtABL-0008Re-BZ; Thu, 14 Jul 2005 16:19:48 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dt9ie-0006Ho-Fs; Thu, 14 Jul 2005 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jul 2005 15:50:04 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-ppvpn-mcast-reqts-01.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --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 : Requirements for Multicast in L3 Provider-Provisioned VPNs Author(s) : T. Morin Filename : draft-ietf-l3vpn-ppvpn-mcast-reqts-01.txt Pages : 39 Date : 2005-7-14 This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within L3 Provider Provisioned virtual private networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ppvpn-mcast-reqts-01.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-ppvpn-mcast-reqts-01.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-ppvpn-mcast-reqts-01.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: <2005-7-14151453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-ppvpn-mcast-reqts-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-ppvpn-mcast-reqts-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-14151453.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Fri Jul 15 13:50:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUKp-0007cZ-3F; Fri, 15 Jul 2005 13:50:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUKn-0007Yk-2U; Fri, 15 Jul 2005 13:50:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28520; Fri, 15 Jul 2005 13:50:47 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtUne-0002dw-DO; Fri, 15 Jul 2005 14:20:38 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j6FHnef13106; Fri, 15 Jul 2005 10:49:40 -0700 (PDT) Message-Id: <200507151749.j6FHnef13106@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 15 Jul 2005 10:49:40 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: l3vpn@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4110 on A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4110 Title: A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) Author(s): R. Callon, M. Suzuki Status: Informational Date: July 2005 Mailbox: rcallon@juniper.net, suzuki.muneyoshi@lab.ntt.co.jp Pages: 82 Characters: 204159 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l3vpn-framework-00.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4110.txt This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050715104134.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4110 --OtherAccess Content-Type: Message/External-body; name="rfc4110.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050715104134.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Fri Jul 15 14:07:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUaV-00068x-Rx; Fri, 15 Jul 2005 14:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUaU-00064B-AC; Fri, 15 Jul 2005 14:07:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00352; Fri, 15 Jul 2005 14:07:00 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtV3K-0003R0-OF; Fri, 15 Jul 2005 14:36:52 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j6FI5If20795; Fri, 15 Jul 2005 11:05:18 -0700 (PDT) Message-Id: <200507151805.j6FI5If20795@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 15 Jul 2005 11:05:17 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: l3vpn@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4111 on Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4111 Title: Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) Author(s): L. Fang, Ed. Status: Informational Date: July 2005 Mailbox: luyuanfang@att.com Pages: 45 Characters: 106626 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l3vpn-security-framework-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4111.txt This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology. This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050715104953.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4111 --OtherAccess Content-Type: Message/External-body; name="rfc4111.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050715104953.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Mon Jul 18 10:59:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuX5P-0000fm-Mb; Mon, 18 Jul 2005 10:59:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuX5O-0000fB-AM for l3vpn@megatron.ietf.org; Mon, 18 Jul 2005 10:59:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18651 for ; Mon, 18 Jul 2005 10:59:12 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuXYp-0006u3-6Q for l3vpn@ietf.org; Mon, 18 Jul 2005 11:29:40 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 15:58:55 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 15:58:54 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Jul 2005 10:58:53 -0400 Received: from [172.25.42.177] ([172.25.42.177]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 10:58:53 -0400 Message-ID: <42DBC3AC.70800@juniper.net> Date: Mon, 18 Jul 2005 10:58:52 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org References: <42B9D54A.1010908@juniper.net> In-Reply-To: <42B9D54A.1010908@juniper.net> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 14:58:53.0453 (UTC) FILETIME=[36C4D3D0:01C58BA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: Re: WG LAST CALL draft-ietf-l3vpn-vr-mib-03 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Folks, This ends the last call. If the authors could produce a new version of the draft that addresses all comments, we will forward it on to the IESG. Ron Ron Bonica wrote: > Folks, > > This message begins a working group last call on > draft-ietf-l3vpn-vr-mib. The last call will end on > July 8. > > Ron > > From l3vpn-bounces@ietf.org Mon Jul 18 12:59:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuYxo-0000Zu-BJ; Mon, 18 Jul 2005 12:59:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuYxn-0000Zp-2D for l3vpn@megatron.ietf.org; Mon, 18 Jul 2005 12:59:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27971 for ; Mon, 18 Jul 2005 12:59:28 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuZRF-0006oe-Vm for l3vpn@ietf.org; Mon, 18 Jul 2005 13:29:58 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 18 Jul 2005 09:59:22 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,297,1115017200"; d="scan'208"; a="2318826:sNHT20604520" Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6IGxLVu025255; Mon, 18 Jul 2005 12:59:21 -0400 (EDT) Message-Id: <200507181659.j6IGxLVu025255@rtp-core-2.cisco.com> To: Mark Duffy In-reply-to: Your message of Tue, 12 Jul 2005 23:54:32 -0400. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 18 Jul 2005 12:59:21 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: l3vpn@ietf.org Subject: Re: Last call: draft-ietf-l3vpn-ipsec-2547-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org > A number of different VPNs might need to have traffic carried > from a particular ingress PE to a particular egress PE. It is > thus natural to ask whether there should be one SA between the > pair of PEs, or n SAs between the pair of PEs, where n is the > number of VPNs. Clearly, scalability is improved by having only > a single SA for each pair of PEs. So the question is whether > there is a significant security advantage to having a distinct > SA for each VPN. Since the SA is PE-to-PE, NOT CE-to-CE, having > a different SA for each VPN does not provide any additional > privacy. On the other hand, when multiple VPNs share an SA, the > compromise of a key has a greater impact, and an attack on the > security of one VPN may become an attack on the security of all > the VPNs sharing the SA. Nevertheless, the use of one SA for > multiple VPNs seems to be a reasonable tradeoff of additional > overhead against additional security. Mark> I don't disagree with any of that, especially that it's the right Mark> tradeoff, but it still misses the original point I was trying to Mark> make which was arguing that there may in fact be a security Mark> vulnerability created by this sharing of SAs. This may create a Mark> vulnerability to a "known plaintext attack" or more accurately, a Mark> "chosen plaintext attack." I.e. a user within one of the VPNs, who Mark> has access to sniff the encrypted traffic, could send plaintext of Mark> her choosing and observe the resulting ciphertext. This can make it Mark> easier to break the cipher. So not only does it broaden the *impact* Mark> of a crypto compromise (as you describe), it might actually provide a Mark> new avenue of attack. I did get your point, and that's what I meant by saying "at attack on the security of one VPN may become an attack on the security of all the VPNs sharing the SA". The known sort of plaintext attack you describe ordinarily attacks the security of a single VPN, but with several VPNs sharing an SA, it attacks the security of all of them. I didn't want to mention explicitly the sort of attack you describe, because I don't want to have to discuss it with the security ADs when the doc is reviewed ;-) > When two PEs > negotiate (via IKE) an SA, they specify the traffic to be covered. > For the use described in this memo that traffic will typically be > described by the triple {pe1 address, pe2 address, protocol = > mpls-in-ip} (or protocol = gre). To negotiate this, they will each > have policy indicating that they should accept traffic matching that > triple only if it is IPsec protected. Thus *all* mpls-in-ip (or all > gre) traffic between the pair of PE addresses must now use IPsec, > even if it is not l3vpn traffic. Good point, this is certainly something that should be mentioned. So I guess there'll be one more spin of this draft. > Is this a problem? In some cases it might be. I don't think this would be a problem in practice; you could always use a different source address for the non-VPN traffic if you need to. From l3vpn-bounces@ietf.org Mon Jul 18 23:18:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duicj-000899-8D; Mon, 18 Jul 2005 23:18:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duici-00088H-0z for l3vpn@megatron.ietf.org; Mon, 18 Jul 2005 23:18:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12754 for ; Mon, 18 Jul 2005 23:18:21 -0400 (EDT) Received: from vms046pub.verizon.net ([206.46.252.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duj6F-0000Bk-98 for l3vpn@ietf.org; Mon, 18 Jul 2005 23:48:56 -0400 Received: from [192.168.0.6] ([70.19.138.165]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IJU002XCUIJNY41@vms046.mailsrvcs.net> for l3vpn@ietf.org; Mon, 18 Jul 2005 22:18:21 -0500 (CDT) Date: Mon, 18 Jul 2005 23:15:49 -0400 From: Mark Duffy In-reply-to: <200507181659.j6IGxLVu025255@rtp-core-2.cisco.com> To: erosen@cisco.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed References: <200507181659.j6IGxLVu025255@rtp-core-2.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: l3vpn@ietf.org, Mark Duffy Subject: Re: Last call: draft-ietf-l3vpn-ipsec-2547-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org At 12:59 PM -0400 7/18/05, Eric Rosen wrote: >... >I did get your point, and that's what I meant by saying "at attack on the >security of one VPN may become an attack on the security of all the VPNs >sharing the SA". The known sort of plaintext attack you describe ordinarily >attacks the security of a single VPN, but with several VPNs sharing an SA, >it attacks the security of all of them. I didn't want to mention explicitly >the sort of attack you describe, because I don't want to have to discuss it >with the security ADs when the doc is reviewed ;-) My slant on it was that in this case the sender of the chosen plaintext doesn't have to "attack" her own vpn, she has privileged access to that vpn and can just directly send any text she wants. That said, I'm ok with the text as it stands. > > >> When two PEs >> negotiate (via IKE) an SA, they specify the traffic to be covered. >> For the use described in this memo that traffic will typically be >> described by the triple {pe1 address, pe2 address, protocol = >> mpls-in-ip} (or protocol = gre). To negotiate this, they will each >> have policy indicating that they should accept traffic matching that >> triple only if it is IPsec protected. Thus *all* mpls-in-ip (or all >> gre) traffic between the pair of PE addresses must now use IPsec, >> even if it is not l3vpn traffic. > >Good point, this is certainly something that should be mentioned. So I >guess there'll be one more spin of this draft. Don't do so on my account. If you're spinning the doc anyway go ahead and mention it. But my original comment that led to this was somewhat confused and I agree that this isn't a big problem (if it is even a problem at all). And I agree it can be avoided by using a different address as mentioned below. --Mark > >> Is this a problem? In some cases it might be. > >I don't think this would be a problem in practice; you could always use a >different source address for the non-VPN traffic if you need to. From l3vpn-bounces@ietf.org Thu Jul 21 04:04:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvW2c-0004zQ-I1; Thu, 21 Jul 2005 04:04:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvW2U-0004rl-DO; Thu, 21 Jul 2005 04:04:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10317; Thu, 21 Jul 2005 04:03:55 -0400 (EDT) Received: from [218.249.29.198] (helo=center.njtu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvWW5-00044r-6y; Thu, 21 Jul 2005 04:34:57 -0400 Received: from zhanghk (remotehost [127.0.0.1]) by mail.student.njtu.edu.cn (ecMail) with ESMTP id 494CE18C19F; Thu, 21 Jul 2005 16:21:00 +0800 (CST) Date: Thu, 21 Jul 2005 16:05:18 +0800 From: "HKzhang@center.njtu.edu.cn" To: "internet-drafts" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon315360726562_=====" Message-Id: <20050721082100.494CE18C19F@mail.student.njtu.edu.cn> X-Spam-Score: 1.1 (+) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 Cc: rcallon , rick , l3vpn Subject: Re:l3vpn-vr-macast-01 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org This is a multi-part message in MIME format. --=====001_Dragon315360726562_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQpXZSBoYXZlIHVwZGF0ZWQgb3VyIGRyYWZ0IHRvIDAxIHZlcnNpb24gYmFzZWQgb24gdGhl IGNvbW1lbnRzLiANCkJlc3QgcmVnYXJkcyB3aXRoIG1hbnkgdGhhbmtzDQogCQkJCQ0KDQqhoaGh oaGhoaGhoaGhoaGhSEt6aGFuZw0KoaGhoaGhoaGhoaGhoaGhoUhLemhhbmdAY2VudGVyLm5qdHUu ZWR1LmNuDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUtMDctMjENCg== --=====001_Dragon315360726562_===== Content-Type: application/octet-stream; name="draft-zhang-l3vpn-vr-mcast-01.txt" Content-Disposition: attachment; filename="draft-zhang-l3vpn-vr-mcast-01.txt" Content-Transfer-Encoding: base64 DQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhvbmct S2UgWmhhbmcNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgQ2h1bi1ZdWUgWmhvdQ0KRXhwaXJhdGlvbiBEYXRlOiBKYW51YXJ5IDIwMDYgICAgICAgICAg ICAgICAgICAgICBCaW5nLVlpIFpoYW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQmVpamluZyBKaWFvdG9uZyBVbml2ZXJzaXR5DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVuLUh1aSBMaXUNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3BlbmNlciBEYXdraW5zDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sTHRk Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1 bHkgMjAwNQ0KDQoNCiAgICAgICAgICAgTXVsdGljYXN0IGluIFZpcnR1YWwgUm91dGVyLWJhc2Vk IElQIFZQTnMgDQoNCg0KICAgICAgICAgICAgICA8ZHJhZnQtemhhbmctbDN2cG4tdnItbWNhc3Qt MDEudHh0Pg0KDQoNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBCeSBzdWJtaXR0aW5nIHRo aXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkgDQogICBh cHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBp cyBhd2FyZSANCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3 aGljaCBoZSBvciBzaGUgYmVjb21lcyANCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBh Y2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRz IGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgDQogICBU YXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3Rl IHRoYXQgDQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3Vt ZW50cyBhcyANCiAgIEludGVybmV0LURyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBk cmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggDQogICBtb250aHMgYW5k IG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50 cyANCiAgIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1E cmFmdHMgYXMgcmVmZXJlbmNlIA0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRo YW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVy bmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvMWlk LWFic3RyYWN0cy5odG1sDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBE aXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwuDQoNCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhl IHByb2NlZHVyZXMgcmVxdWlyZWQgdG8gYmUgaW1wbGVtZW50ZWQgDQogICBmb3IgSVAgbXVsdGlj YXN0IHRyYWZmaWMgdG8gdHJhdmVsIGZyb20gb25lIFZQTiBzaXRlIHRvIGFub3RoZXIgDQogICB3 aXRoaW4gYSBWUi1WUE4gKFZpcnR1YWwgUm91dGVyLWJhc2VkIElQIFZQTikuSXQgZGV0YWlscyB0 aGUgDQogICBzb2x1dGlvbiBhY2NvcmRpbmcgdG8gcHJvY2VzcyBpbiBsb2NhbCBjdXN0b21lciBz aXRlcywgZXN0YWJsaXNoaW5nIA0KICAgb2YgbXVsdGljYXN0IGRpc3RyaWJ1dGlvbiB0cmVlcyBp biBTUCBuZXR3b3JrcyBhbmQgZm9yd2FyZGluZyBvZiANCiAgIG11bHRpY2FzdCBkYXRhIHBhY2tl dHMuDQoNCg0KSG9uZy1LZSBaaGFuZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjAw NiAgICAgICAgICAgICAgIFtQYWdlIDFdDQoNCgwNCkludGVybmV0IERyYWZ0ICAgIE11bHRpY2Fz dCBpbiBWaXJ0dWFsIFJvdXRlci1iYXNlZCBJUCBWUE5zICAgIEp1bHkgMjAwNQ0KDQoNCiAgIFRo aXMgZG9jdW1lbnQgaXMgYmFzZWQgb24gUmVxdWlyZW1lbnRzIGZvciBNdWx0aWNhc3QgaW4gDQog ICBMMyBQcm92aWRlci1Qcm92aXNpb25lZCBWUE5zIFtNUkVRVF0gYW5kIHNwZWNpZmljYXRpb24g b2YgDQogICBOZXR3b3JrIGJhc2VkIElQIFZQTiBBcmNoaXRlY3R1cmUgdXNpbmcgVmlydHVhbCBS b3V0ZXJzIFtWUi1WUE5dIA0KICAgdGhhdCBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgYW5kIGRlcGxv eWVkLg0KDQoNCkNvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudA0KDQogICBUaGUga2V5 IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5P VCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFu ZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBh cyBkZXNjcmliZWQgaW4gUkZDLTIxMTkgW0tFWVdPUkRTXS4NCg0KDQpUYWJsZSBvZiBDb250ZW50 cw0KDQogICAgMSAgICAgIEludHJvZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjMNCiAgICAyICAgICAgVGVybWlub2xvZ3kuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMw0KICAgIDMgICAgICBWUiBkZXBs b3ltZW50IHNjZW5hcmlvcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40DQog ICAgNCAgICAgIEF1dG8tZGlzY292ZXJ5IG9mIFZQTiBtZW1iZXJzaGlwLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjQNCiAgICA1ICAgICAgUHJvY2VkdXJlcyBmb3IgbXVsdGljYXN0IGluIFZS LVZQTnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNQ0KICAgIDUuMSAgICBFbmNhcHN1bGF0aW9u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQogICAgNS4x LjEgIEVuY2Fwc3VsYXRpb24gaW4gR1JFLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjUNCiAgICA1LjEuMiAgRW5jYXBzdWxhdGlvbiBpbiBJUC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNQ0KICAgIDUuMS4zICBFbmNhcHN1bGF0aW9uIGluIE1Q TFMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICAgNS4xLjQgIElu dGVyb3BlcmFiaWxpdHkuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjYNCiAgICA1LjIgICAgTXVsdGljYXN0IHNvdXJjZSByb3V0aW5nIHRhYmxlIGluIFZSLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNw0KICAgIDUuMyAgICBSb3V0aW5nIGluIGxvY2FsIFZQTiBzaXRl cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43DQogICAgNS40ICAgIFJvdXRpbmcg aW4gU1AgTmV0d29ya3MuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjgNCiAg ICA1LjUgICAgTXVsdGljYXN0IERhdGEgRm9yd2FyZGluZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uOA0KICAgIDYgICAgICBTY2FsYWJpbGl0eSBDb25zaWRlcmF0aW9ucy4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45DQogICAgNyAgICAgIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkNCiAgICA4ICAg ICAgQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4xMA0KICAgIDkgICAgICBOb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwDQogICAgMTAgICAgIEluZm9ybWF0aXZlIFJlZmVyZW5j ZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCiAgICAxMSAgICAgQXV0 aG9ycycgQWRkcmVzc2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4x MA0KICAgIDEyICAgICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50Li4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjExDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhvbmctS2UgWmhh bmcsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDIwMDYgICAgICAgICAgICAgICBbUGFn ZSAyXQ0KDQoMDQpJbnRlcm5ldCBEcmFmdCAgICBNdWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXIt YmFzZWQgSVAgVlBOcyAgICBKdWx5IDIwMDUNCg0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0KICAgW01S RVFUXSBkZXNjcmliZXMgUmVxdWlyZW1lbnRzIGZvciBNdWx0aWNhc3QgaW4gTDMgDQogICBwcm92 aWRlci1wcm92aXNpb25lZCBWUE5zLiBbVlItVlBOXSBzcGVjaWZpZXMgYSBuZXR3b3JrIGJhc2Vk IA0KICAgSVAgVlBOIGFyY2hpdGVjdHVyZSB1c2luZyBWaXJ0dWFsIFJvdXRlcnMsIHdoaWNoIGhh dmUgYmVlbiANCiAgIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCBieSBzb21lIHZlbmRvcnMgYW5k IHNlcnZpY2UgcHJvdmlkZXJzLiANCiAgIEJhc2VkIG9uIHRoZW0sIHRoaXMgZG9jdW1lbnQgc3Bl Y2lmaWVzIHRoZSBwcm9jZWR1cmVzIHJlcXVpcmVkIA0KICAgdG8gYmUgaW1wbGVtZW50ZWQgZm9y IElQIG11bHRpY2FzdCB0cmFmZmljIHRvIHRyYXZlbCBmcm9tIG9uZSANCiAgIFZQTiBzaXRlIHRv IGFub3RoZXIgd2l0aGluIGEgVlItVlBOIChWaXJ0dWFsIFJvdXRlci1iYXNlZCBJUCBWUE4pLiAN CiAgIEl0IGRldGFpbHMgdGhlIHNvbHV0aW9uIGFjY29yZGluZyB0byBwcm9jZXNzIGluIGxvY2Fs IHNpdGVzLCANCiAgIGVzdGFibGlzaGluZyBvZiBtdWx0aWNhc3QgZGlzdHJpYnV0aW9uIHRyZWVz IGluIFNQIG5ldHdvcmtzIGFuZCANCiAgIGZvcndhcmRpbmcgb2YgbXVsdGljYXN0IGRhdGEgcGFj a2V0cy4gVGhlIHJldmVyc2Ugc2hvcnRlc3QgcGF0aCANCiAgIHRyZWVzIGFyZSBlc3RhYmxpc2hl ZCBpbiBTUCBuZXR3b3JrcywgYW5kIHRoZSBWUnMgd2l0aCBtdWx0aWNhc3QgDQogICBzZXJ2aWNl IHJlcXVpcmVtZW50cyBhY3QgYXMgdGhlIHRyZWUncyBsZWFmIG5vZGVzIGFuZCBqb2luL2xlYXZl IA0KICAgbXVsdGljYXN0IGdyb3VwcyBkeW5hbWljYWxseS4gVGhpcyBzb2x1dGlvbiBpcyBhIHRy YWRlb2ZmIGJldHdlZW4gDQogICBzY2FsYWJpbGl0eSBhbmQgZmxleGliaWxpdHkgb2Ygcm91dGVy IG9wdGltaXphdGlvbiwgd2hpY2ggZW5zdXJlcyANCiAgIGJhbmR3aWR0aCByZXNvdXJjZSB1dGls aXphdGlvbiBpbiBjb3JlIG5ldHdvcmtzLg0KDQoNCjIuIFRlcm1pbm9sb2d5DQoNCiAgIEhlcmUg d2UgaW50cm9kdWNlIHNvbWUgZ2VuZXJhbCB0ZXJtcyBmb3IgY29uY2VwdHMgdGhhdCBhcHBlYXIg aW4gdGhpcw0KICAgTXVsdGljYXN0IHNvbHV0aW9uIG9mIFZpcnR1YWwgUm91dGVyLWJhc2VkIElQ IFZQTnMuIA0KDQogICBQbGVhc2UgcmVmZXIgdG8gdGhlIFtQUFZQTi1URVJNXSBkb2N1bWVudCBm b3IgZGV0YWlscyBhYm91dCANCiAgIHRlcm1pbm9sb2d5IHNwZWNpZmljYWxseSByZWxldmFudCB0 byBWUE4gYXNwZWN0cy4gICAgDQoNCiAgIEluIGFkZGl0aW9uIHRvIHRoZSB0ZXJtaW5vbG9neSB1 c2VkIGluIFtNUkVRVF0sIHRoaXMgZG9jdW1lbnQgDQogICB1c2VzIHRoZSBmb2xsb3dpbmcgdGVy bXM6DQoNCiAgIC0gR1JFOiBHZW5lcmljIFJvdXRlIEVuY2Fwc3VsYXRpb24sIHdoaWNoIHNwZWNp ZmllcyBhIHByb3RvY29sIGZvciANCiAgICAgICAgICBlbmNhcHN1bGF0aW9uIG9mIGFuIGFyYml0 cmFyeSBuZXR3b3JrIGxheWVyIHByb3RvY29sIG92ZXIgDQogICAgICAgICAgYW5vdGhlciBhcmJp dHJhcnkgbmV0d29yayBsYXllciBwcm90b2NvbC4NCg0KICAgLSBQRSA6IFByb3ZpZGVyIEVkZ2UN Cg0KICAgLSBDRSA6IEN1c3RvbWVyIEVkZ2UNCg0KICAgLSBTUCA6IFNlcnZpY2UgUHJvdmlkZXIN Cg0KICAgLSBQSU06IFByb3RvY29sIEluZGVwZW5kZW50IE11bHRpY2FzdA0KDQogICAtIFJQIDog UmVuZGV6dm91cyBQb2ludCB3aGljaCBpcyBhIHNoYXJlZCByb290IGZvciBldmVyeSBtdWx0aWNh c3QgDQogICAgICAgICAgZ3JvdXAsIHNvdXJjZXMgb24gdGhlIHNhbWUgZ3JvdXAgc2VuZCB0aGVp ciB0cmFmZmljIHRvIHRoZSBSUCANCiAgICAgICAgICBhbmQgdGhlbiBmb3J3YXJkZWQgdG8gcmVj ZWl2ZXJzIGRvd24gYSBzaGFyZWQgZGlzdHJpYnV0aW9uIA0KICAgICAgICAgIHRyZWUuDQoNCg0K DQpIb25nLUtlIFpoYW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyMDA2ICAgICAg ICAgICAgICAgW1BhZ2UgM10NCg0KDA0KSW50ZXJuZXQgRHJhZnQgICAgTXVsdGljYXN0IGluIFZp cnR1YWwgUm91dGVyLWJhc2VkIElQIFZQTnMgICAgSnVseSAyMDA1DQoNCg0KICAgLSBHIDogIGRl bm90ZXMgYSBtdWx0aWNhc3QgZ3JvdXAuICAgDQoNCiAgIC0gUyA6ICBkZW5vdGVzIGEgbXVsdGlj YXN0IHNvdXJjZS4gDQoNCiAgIC0gUC1Hcm91cDogYSBncm91cCBhZGRyZXNzIGluIHRoZSBTUCdz IGFkZHJlc3Mgc3BhY2UuDQoNCiAgIC0gQy1Hcm91cDogYSBncm91cCBhZGRyZXNzIGluIGEgVlBO J3MgYWRkcmVzcyBzcGFjZS4NCg0KDQozLiBWUiBkZXBsb3ltZW50IHNjZW5hcmlvcw0KDQogICBJ biBWUi1WUE5zLCBWUE4gY3VzdG9tZXIgc2l0ZXMgYWNjZXNzIHRvIHNlcnZpY2UgcHJvdmlkZXIg YmFja2JvbmUgDQogICB2aWEgdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBDdXN0b21lciBFZGdlKENF KSBhbmQgVmlydHVhbCBSb3V0ZXIoVlIpLiANCiAgIENFIGNhbiBjb25uZWN0IHRvIFZSIHZpYSBh bnkgYWNjZXNzIGxpbmssIHRoZW4gZm9yd2FyZCBhbGwgDQogICBub24tbG9jYWwgc2VydmljZSB0 byBWUi4gVlJzIGJlbG9uZ2luZyB0byB0aGUgc2FtZSBWUE4gZG9tYWluIG11c3QgDQogICBkaXNj b3ZlciBWUE4gbWVtYmVyc2hpcCBhbmQgZGlzdHJpYnV0ZSByZWFjaGFiaWxpdHkgaW5mb3JtYXRp b24uIA0KICAgVlJzIG9ubHkgbWFpbnRhaW4gcm91dGUgc3RhdGUgZm9yIHRoZSBWUE5zIHRoZXkg YmVsb25nIHRvLiANCiAgIFRoZXJlIGNhbiBleGlzdCBtdWx0aXBsZSBWUnMgb24gb25lIFByb3Zp ZGVyIEVkZ2UoUEUpIGRldmljZS4NCg0KICAgVGhyZWUgbWFpbiBWUiBkZXBsb3ltZW50IHNjZW5h cmlvcyBjYW4gYmUgdXNlZCBmb3IgYnVpbGRpbmcgdmlydHVhbCANCiAgIHByaXZhdGUgbmV0d29y a3MgYXMgZGVzY3JpYmVkIGluIFtWUi1WUE5dOg0KDQogICAgICAxKSBWUiB0byBWUiBjb25uZWN0 aXZpdHkgb3ZlciBhIGxheWVyIDIgY29ubmVjdGlvbjsNCiAgICAgIDIpIFZSIHRvIFZSIGNvbm5l Y3Rpdml0eSB0dW5uZWxlZCBvdmVyIGFuIElQIG9yIE1QTFMgbmV0d29yazsNCiAgICAgIDMpIEFn Z3JlZ2F0aW5nIG11bHRpcGxlIFZScyBvdmVyIGEgYmFja2JvbmUgVlIuDQoNCiAgIFRoZSBhYm92 ZSBWUiBkZXBsb3ltZW50IHNjZW5hcmlvcyBjYW4gY29leGlzdCBvbiBhIHNpbmdsZSBQRSBhbmQg DQogICB0aGV5IGFyZSBub3QgbXV0dWFsbHkgZXhjbHVzaXZlLg0KDQogICBGb3Igc3VwcG9ydCBv ZiBtdWx0aWNhc3QsIHRoZSB2aXJ0dWFsIHJvdXRlciBoYXMgZXhhY3RseSB0aGUgc2FtZSANCiAg IG1lY2hhbmlzbXMgYXMgYSBwaHlzaWNhbCByb3V0ZXIgZW50aXJlbHkuIEFsbCBleGlzdGluZyBy b3V0aW5nIA0KICAgcHJvdG9jb2xzIGNhbiBiZSB1c2VkIHVubW9kaWZpZWQgb24gVlIsIGJldHdl ZW4gVlJzIG9yIGJldHdlZW4gVlIgDQogICBhbmQgQ0UuIE1vcmVvdmVyLCBtdWx0aWNhc3QgdHJh ZmZpYyBjYW4gYmUgZm9yd2FyZGVkIHRocm91Z2ggSVAgDQogICBvciBNUExTIGJhc2VkIHR1bm5l bHMuDQoNCiAgIFRoaXMgbXVsdGljYXN0IHNvbHV0aW9uIG9mIFZSLVZQTnMgZml0cyBmb3IgYWxs IGFib3ZlIFZSIGRlcGxveW1lbnQNCiAgIHNjZW5hcmlvcyB3aXRob3V0IGFueSBhZGRpdGlvbmFs IGNvbmZpZ3VyYXRpb24gb3IgYW55IGltcGFjdCBvbiB0aGUgDQogICBiYWNrYm9uZSBWUnMgaW4g U1AgbmV0d29ya3MuDQoNCg0KNC4gQXV0by1EaXNjb3Zlcnkgb2YgVlBOIG1lbWJlcnNoaXANCg0K ICAgVGhlIGZpcnN0IHN0ZXAgdG8gc3VwcG9ydCBWUE4gbXVsdGljYXN0IGlzIEF1dG8tRGlzY292 ZXJ5IG9mIFZQTiANCiAgIG1lbWJlcnNoaXAsIHZhbGlkYXRpb24gYW5kIGRpc3RyaWJ1dGlvbiBv ZiByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24uDQogICBJdCBpcyByZXF1aXJlZCB0byBzZWxlY3Qg YXBwcm9wcmlhdGUgUEUgZm9yIGN1c3RvbWVyIHNpdGVzLCANCiAgIGRpc3RyaWJ1dGUgaWRlbnRp ZmllciBmb3IgVlBOLCBjb25maWd1cmUgVlIgb24gY29ycmVsYXRpdmUgUEUsIA0KICAgYWRkIHRo ZSBWUiB0byB0aGUgVlBOIGNvbm5lY3RlZCwgYW5kIGZvcndhcmQgcGFja2V0cyBmb3IgdGhhdCBW UE4uDQoNCg0KSG9uZy1LZSBaaGFuZywgZXQgYWwuICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjAw NiAgICAgICAgICAgICAgIFtQYWdlIDRdDQoNCgwNCkludGVybmV0IERyYWZ0ICAgIE11bHRpY2Fz dCBpbiBWaXJ0dWFsIFJvdXRlci1iYXNlZCBJUCBWUE5zICAgIEp1bHkgMjAwNQ0KDQoNCiAgIFRo ZSBtZWNoYW5pc20gdG8gZGlzdHJpYnV0ZSBtZW1iZXJzaGlwLCB0b3BvbG9neSwgYW5kIHR1bm5l bCANCiAgIGluZm9ybWF0aW9uIGFtb25nIFZScyB3aGljaCBhcmUgbWVtYmVycyBvZiB0aGUgc2Ft ZSBWUE4gaXMgdGhlIHNhbWUgDQogICBhcyBmb3IgdW5pY2FzdCBpbiBbVlItVlBOXS4gIkF1dG8t ZGlzY292ZXJ5IiBjYW4gYmUgYWNoaWV2ZWQgdGhyb3VnaCANCiAgIGV4cGxpY2l0IGNvbmZpZ3Vy YXRpb24sIGRpcmVjdG9yeSBzZXJ2ZXIgYXBwcm9hY2gsIHBpZ2d5YmFja2luZyANCiAgIGluZm9y bWF0aW9uIHVzaW5nIGV4dGVuZGVkIEJHUCBwcm90b2NvbHMgb3Igb3RoZXIgYXBwcm9hY2hlcy4N Cg0KDQo1LiBQcm9jZWR1cmVzIGZvciBtdWx0aWNhc3QgaW4gVlItVlBOcw0KDQoNCjUuMSBFbmNh cHN1bGF0aW9uDQoNCiAgIFRoaXMgbXVsdGljYXN0IHNvbHV0aW9uIG9mIFZSLVZQTnMgdXNlcyB0 aGUgc2FtZSBlbmNhcHN1bGF0aW9uIA0KICAgbWV0aG9kcyBhcyBsaXN0ZWQgaW4gW01WUE4tN10u IFRoZXNlIGFsc28gYXBwbHkgdG8gdGhlIE1QTFMtaW4tSVAgDQogICBhbmQgTVBMUy1pbi1HUkUg ZW5jYXBzdWxhdGlvbiBtZXRob2RzLg0KDQoNCjUuMS4xIEVuY2Fwc3VsYXRpb24gaW4gR1JFDQoN CiAgIEdSRSBlbmNhcHN1bGF0aW9uIGNhbiBiZSB1c2VkIHdoZW4gZm9yd2FyZGluZyBtdWx0aWNh c3QgdHJhZmZpYyANCiAgIHRocm91Z2ggU1AgbmV0d29yay4gVGhlIElQIFByb3RvY29sIE51bWJl ciBmaWVsZCBpbiB0aGUgSVAgSGVhZGVyIA0KICAgYW5kIHRoZSBQcm90b2NvbCBUeXBlIGZpZWxk IG9mIHRoZSBHUkUgSGVhZGVyIGZvbGxvd3MgW01WUE4tN10uDQogICBUaGUgZm9sbG93aW5nIGRp YWdyYW0gc2hvd3MgdGhlIHByb2dyZXNzaW9uIG9mIHRoZSBwYWNrZXQgYXMgaXQgDQogICBlbnRl cnMgYW5kIGxlYXZlcyB0aGUgc2VydmljZSBwcm92aWRlciBuZXR3b3JrLg0KDQoNCiAgIFBhY2tl dHMgcmVjZWl2ZWQgICAgICAgIFBhY2tldHMgaW4gdHJhbnNpdCAgICAgIFBhY2tldHMgZm9yd2Fy ZGVkDQogICBhdCBpbmdyZXNzIFZSICAgICAgICAgICBpbiB0aGUgc2VydmljZSAgICAgICAgICBi eSBlZ3Jlc3MgVlJzDQogICAgICAgICAgICAgICAgICAgICAgICAgICBwcm92aWRlciBuZXR3b3Jr DQoNCiAgICsrPT09PT09PT09PT09PSsrICAgICAgICsrPT09PT09PT09PT09PSsrICAgICAgICsr PT09PT09PT09PT09PSsrDQogICB8fCBDLVBheWxvYWQgICB8fCAgICAgICB8fCBDLVBheWxvYWQg ICB8fCAgICAgICB8fCBDLVBheWxvYWQgICB8fA0KICAgKys9PT09PT09PT09PT09KysgPj4+Pj4g Kys9PT09PT09PT09PT09KysgPj4+Pj4gKys9PT09PT09PT09PT09KysNCiAgIHx8IEMtSVAgSGVh ZGVyIHx8ICAgICAgIHx8IEMtSVAgSGVhZGVyIHx8ICAgICAgIHx8IEMtSVAgSGVhZGVyIHx8DQog ICArKz09PT09PT09PT09PT0rKyAgICAgICArKz09PT09PT09PT09PT0rKyAgICAgICArKz09PT09 PT09PT09PT0rKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIEdSRSAgICAgIHwg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgIFAtSVAgSGVhZGVyICB8DQogICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKw0KDQoNCjUuMS4yIEVuY2Fwc3VsYXRpb24gaW4g SVANCg0KICAgSVAtaW4tSVAgZW5jYXBzdWxhdGlvbiBjYW4gYWxzbyBiZSB1c2VkLiBUaGUgcGFy YW1ldGVyIGFib3V0IElQIA0KICAgUHJvdG9jb2wgTnVtYmVyIGZpZWxkIGZvbGxvd3MgW01WUE4t N10uIFRoZSBmb2xsb3dpbmcgZGlhZ3JhbSBzaG93cyANCiAgIHRoZSBwcm9ncmVzc2lvbiBvZiB0 aGUgcGFja2V0IGFzIGl0IGVudGVycyBhbmQgbGVhdmVzIHRoZSBzZXJ2aWNlDQogICBwcm92aWRl ciBuZXR3b3JrLg0KDQoNCkhvbmctS2UgWmhhbmcsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51 YXJ5IDIwMDYgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDQoMDQpJbnRlcm5ldCBEcmFmdCAgICBN dWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQgSVAgVlBOcyAgICBKdWx5IDIwMDUNCg0K DQogICBQYWNrZXRzIHJlY2VpdmVkICAgICAgICBQYWNrZXRzIGluIHRyYW5zaXQgICAgICBQYWNr ZXRzIGZvcndhcmRlZA0KICAgYXQgaW5ncmVzcyBWUiAgICAgICAgICAgaW4gdGhlIHNlcnZpY2Ug ICAgICAgICAgYnkgZWdyZXNzIFZScw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJvdmlk ZXIgbmV0d29yaw0KDQogICArKz09PT09PT09PT09PT0rKyAgICAgICArKz09PT09PT09PT09PT0r KyAgICAgICArKz09PT09PT09PT09PT0rKw0KICAgfHwgQy1QYXlsb2FkICAgfHwgICAgICAgfHwg Qy1QYXlsb2FkICAgfHwgICAgICAgfHwgQy1QYXlsb2FkICAgfHwNCiAgICsrPT09PT09PT09PT09 PSsrID4+Pj4+ICsrPT09PT09PT09PT09PSsrID4+Pj4+ICsrPT09PT09PT09PT09PSsrDQogICB8 fCBDLUlQIEhlYWRlciB8fCAgICAgICB8fCBDLUlQIEhlYWRlciB8fCAgICAgICB8fCBDLUlQIEhl YWRlciB8fA0KICAgKys9PT09PT09PT09PT09KysgICAgICAgKys9PT09PT09PT09PT09KysgICAg ICAgKys9PT09PT09PT09PT09KysNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFAtSVAg SGVhZGVyICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKw0K DQoNCjUuMS4zIEVuY2Fwc3VsYXRpb24gaW4gTVBMUw0KDQogICBJZiB0aGUgUCByb3V0ZXJzIGlu IFNQIG5ldHdvcmtzIHN1cHBvcnQgTVBMUyBhbmQgZXh0ZW5kZWQgUlNWUCANCiAgIHByb3RvY29s LCBNUExTIGVuY2Fwc3VsYXRpb24gY2FuIGJlIHVzZWQuIFRoZSBtdWx0aWNhc3QgZGlzdHJpYnV0 aW9uDQogICB0cmVlcyBjYW4gYmUgY29uc3RydWN0ZWQgYnkgUDJNUCBNUExTIExTUCBtZWNoYW5p c20sIGFuZCBhZGRpdGlvbmFsIA0KICAgTVBMUyBlbmNhcHN1bGF0aW9uIHByb2NlZHVyZXMgYXJl IHVzZWQsIGFzIHNwZWNpZmllZCBpbiANCiAgIFtSU1ZQLVRFLVAyTVBdLg0KDQoNCiAgIFBhY2tl dHMgcmVjZWl2ZWQgICAgICAgIFBhY2tldHMgaW4gdHJhbnNpdCAgICAgIFBhY2tldHMgZm9yd2Fy ZGVkDQogICBhdCBpbmdyZXNzIFZSICAgICAgICAgICBpbiB0aGUgc2VydmljZSAgICAgICAgICBi eSBlZ3Jlc3MgVlJzDQogICAgICAgICAgICAgICAgICAgICAgICAgICBwcm92aWRlciBuZXR3b3Jr DQoNCiAgICsrPT09PT09PT09PT09PSsrICAgICAgICsrPT09PT09PT09PT09PSsrICAgICAgICsr PT09PT09PT09PT09PSsrDQogICB8fCBDLVBheWxvYWQgICB8fCAgICAgICB8fCBDLVBheWxvYWQg ICB8fCAgICAgICB8fCBDLVBheWxvYWQgICB8fA0KICAgKys9PT09PT09PT09PT09KysgPj4+Pj4g Kys9PT09PT09PT09PT09KysgPj4+Pj4gKys9PT09PT09PT09PT09KysNCiAgIHx8IEMtSVAgSGVh ZGVyIHx8ICAgICAgIHx8IEMtSVAgSGVhZGVyIHx8ICAgICAgIHx8IEMtSVAgSGVhZGVyIHx8DQog ICArKz09PT09PT09PT09PT0rKyAgICAgICArKz09PT09PT09PT09PT0rKyAgICAgICArKz09PT09 PT09PT09PT0rKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBQLU1QTFMgSGVhZGVyIHwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rDQoNCg0KNS4xLjQg SW50ZXJvcGVyYWJpbGl0eQ0KDQogICBJbiBhIFZSLVZQTiwgYWxsIFZpcnR1YWwgUm91dGVycyBp biB0aGUgVlBOIG11c3QgYWdyZWUgb24gdGhlIG1ldGhvZCANCiAgIG9mIGVuY2Fwc3VsYXRpb24u IEl0IGNhbiBiZSBhY2hpZXZlZCBlaXRoZXIgYnkgY29uZmlndXJhdGlvbiBvciANCiAgIGJ5IG1l YW5zIG9mIHNvbWUgZGlzY292ZXJ5IHByb3RvY29scy4gSGVyZSwgR1JFIGVuY2Fwc3VsYXRpb24g aXMgDQogICBzdWdnZXN0ZWQgdG8gYmUgdXNlZCBkdWUgdG8gaXRzIHNpbXBsZSBhbmQgbG93ZXIg cGF5bG9hZC4NCg0KDQoNCg0KDQoNCg0KDQpIb25nLUtlIFpoYW5nLCBldCBhbC4gICAgICAgIEV4 cGlyZXMgSmFudWFyeSAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCg0KDA0KSW50ZXJuZXQg RHJhZnQgICAgTXVsdGljYXN0IGluIFZpcnR1YWwgUm91dGVyLWJhc2VkIElQIFZQTnMgICAgSnVs eSAyMDA1DQoNCg0KNS4xIE11bHRpY2FzdCByb3V0aW5nIHByb3RvY29scw0KDQogICBJdCBpcyBu ZWNlc3NhcnkgdG8gZGVwbG95IG11bHRpY2FzdCByb3V0aW5nIHByb3RvY29scyBpbiBsb2NhbCBW UE4gDQogICBzaXRlcywgQ0VzIGFuZCBQRXMuIEluIHRoaXMgc29sdXRpb24sIGFsbCBtdWx0aWNh c3Qgcm91dGluZyANCiAgIHByb3RvY29scyB3aXRoIHRoZSBtZWNoYW5pc20gb2YgSm9pbiBhbmQg UHJ1bmUgY2FuIGJlIHVzZWQuIEhvd2V2ZXIsIA0KICAgdGhpcyBkb2N1bWVudCBvbmx5IGNvbnNp ZGVycyB0aGUgdXNlIG9mIFBJTS1iYXNlZCBwcm90b2NvbHMsIA0KICAgaW5jbHVkaW5nIFBJTS1T TSwgUElNLVNTTSwgUElNLURNIG9yIFBJTS1CaWRpci4gDQoNCg0KNS4yIE11bHRpY2FzdCBzb3Vy Y2Ugcm91dGluZyB0YWJsZSBpbiBWUg0KDQogICBJbiB0aGlzIHNvbHV0aW9uLCBpbiBvcmRlciB0 byBkZWNpZGUgd2hldGhlciB0aGVyZSBleGlzdHMgbXVsdGljYXN0IA0KICAgcmVxdWlyZW1lbnRz IGZyb20gbG9jYWwgVlBOIHNpdGVzLCBldmVyeSBWUiBzaG91bGQgc3RvcmUgYSBtdWx0aWNhc3QN CiAgIHNvdXJjZSByb3V0aW5nIHRhYmxlIGNvbnN0cnVjdGVkIGJ5IHJlYWNoYWJpbGl0eSBpbmZv cm1hdGlvbiANCiAgIGRpc3RyaWJ1dGVkIGJ5IFZScyB0aHJvdWdoIGRpZmZlcmVudCBtZWNoYW5p c21zIHN1Y2ggYXMgc3RhdGljIA0KICAgcm91dGluZywgdHJhZGl0aW9uYWwgdW5pY2FzdCByb3V0 aW5nIG9yIG11bHRpY2FzdCBwcm90b2NvbC4gVGhpcyANCiAgIHRhYmxlIHJlY29yZHMgcmVhY2hh YmlsaXR5IGluZm9ybWF0aW9uIG9mIGV2ZXJ5IG11bHRpY2FzdCBzb3VyY2UgUyANCiAgIHdoaWNo IHRoZSBWUiBpcyBpbnRlcmVzdGVkIGluIGFuZCB0aGUgcmVsYXRpdmUgVlIsIHRoYXQgaXMgKFMs IFZSKS4NCg0KDQo1LjMgUm91dGluZyBpbiBsb2NhbCBWUE4gc2l0ZXMgDQoNCiAgIE11bHRpY2Fz dCByb3V0aW5nIHByb3RvY29scyBtdXN0IGJlIHJ1bm5pbmcgaW4gYSBsb2NhbCBWUE4gc2l0ZS4g DQogICBJbiB0aGlzIHNvbHV0aW9uLCBpdCBpcyBhbiBpbXBvcnRhbnQgY2hhcmFjdGVyaXN0aWMg dGhhdCBlYWNoIFZSIA0KICAgYmVjb21lcyBhIFBJTSBhZGphY2VuY3kgb2YgdGhlIENFIGNvbm5l Y3RlZCwgYnV0IENFcyBhdCBkaWZmZXJlbnQgDQogICBzaXRlcyBkbyBub3QgYmVjb21lIFBJTSBh ZGphY2VuY2llcyBvZiBlYWNoIG90aGVyLCBhbmQgVlJzIA0KICAgaW4gdGhlIHNhbWUgUEUgZG8g bm90IGJlY29tZSBQSU0gYWRqYWNlbmNpZXMgdG8gZWFjaCBvdGhlciwgZWl0aGVyLg0KDQogICBF dmVyeSBWUiBpbiBhIFZSLVZQTiBhY3RzIGFzIGEgcHJveHkgU291cmNlL1JQIFtQMk1QXSBmb3Ig aXRzIA0KICAgY29ubmVjdGVkIFZQTiBzaXRlcy4gVGhlIHByb3h5IFNvdXJjZS9SUCBjb25uZWN0 IHRvIHRoZSBtdWx0aWNhc3QgDQogICBzb3VyY2UgaW4gdGhlIFZQTiBkaXJlY3RseSBvciB2aWEg Q0VzLiBTaW5jZSBlYWNoIFZSIGFjdHMgYXMgDQogICBhIHByb3h5LVNvdXJjZS9SUCBpbiBpdHMg VlBOIGZvciBpdHMgY29ubmVjdGVkIFZQTiBzaXRlcywgDQogICBhbiBpbmRlcGVuZGVudCBtdWx0 aWNhc3QgdHJlZSBjYW4gYmUgZm9ybWVkIHdpdGhpbiBhIGN1c3RvbWVyIHNpdGUgDQogICByZWdh cmRsZXNzIG9mIG11bHRpY2FzdCB0cmVlcyBjb25mb3JtYXRpb24gd2l0aGluIG90aGVyIHNpdGVz Lg0KDQogICBGcm9tIHRoZSB2aWV3IG9mIFNQLCB0aGUgUHJveHkgU291cmNlL1JQIGlzIHRoZSBw cm94eSBvZiBhbGwgDQogICBtdWx0aWNhc3Qgc291cmNlcyB3aXRoaW4gYSBsb2NhbCBWUE4gc2l0 ZS4gRnJvbSB0aGUgdmlldyBvZiBhIFZQTiANCiAgIHNpdGUsIHRoZSBQcm94eSBTb3VyY2UvUlAg aXMgdGhlIFJQIG9mIGFsbCBtdWx0aWNhc3QgdHJlZXMgd2l0aGluIA0KICAgdGhlIGxvY2FsIFZQ TiBzaXRlLCBpLmUuIGFsbCByb3V0ZSBzdGF0ZXMgc3VjaCBhcyAoQy1Tb3VyY2UsQy1Hcm91cCkg DQogICBhbmQgKCosQy1Hcm91cCkgYXNzZW1ibGUgdG8gUlAgdmlhIFBJTSBKb2luL1BydW5lIG1l c3NhZ2VzLiBIZXJlLCANCiAgIGEgQy1Tb3VyY2UgYWRkcmVzcyBpcyBhIG11bHRpY2FzdCBzb3Vy Y2UgYWRkcmVzcyBpbiB0aGUgbG9jYWwgVlBOIA0KICAgc2l0ZSwgYW5kIGEgQy1ncm91cCBhZGRy ZXNzIGlzIGEgbXVsdGljYXN0IGdyb3VwIGFkZHJlc3MgaW4gYSBWUE4ncyANCiAgIGFkZHJlc3Mg c3BhY2UuIA0KDQogICBBY3RpbmcgYXMgdGhlIFByb3h5IFNvdXJjZSBtZWFucyB0aGF0IFZSIG11 c3QgYmUgdGhlIGVncmVzcyBvZiBhbGwgDQogICBtdWx0aWNhc3QgdHJhZmZpYyB0byByZW1vdGUg c2l0ZXMuIEFjdGluZyBhcyB0aGUgUlAgbWVhbnMgdGhhdCBhbGwgDQogICBtdWx0aWNhc3Qgc291 cmNlcyB3aXRoaW4gdGhlIFZQTiBzaXRlcyBtdXN0IHJlZ2lzdGVyIHRvIFZSLCBhbmQgVlIgDQog ICBtdXN0IGJlIHRoZSBpbmdyZXNzIG9mIGFsbCBtdWx0aWNhc3QgdHJhZmZpYyBmcm9tIHJlbW90 ZSBzaXRlcy4gDQoNCkhvbmctS2UgWmhhbmcsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDIwMDYgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDQoMDQpJbnRlcm5ldCBEcmFmdCAgICBNdWx0 aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQgSVAgVlBOcyAgICBKdWx5IDIwMDUNCg0KDQo1 LjQgUm91dGluZyBpbiBTUCBOZXR3b3Jrcw0KDQogICBGaXJzdCB3ZSBkZWZpbmUgdGhhdCBTb3Vy Y2UtVlIgaXMgYSBWUiBjb25uZWN0ZWQgdG8gYSBjdXN0b21lciBWUE4gDQogICBzaXRlIHdoaWNo IGhhcyBtdWx0aWNhc3Qgc291cmNlcy4gQWNjb3JkaW5nIHRvIFZQTiBtZW1iZXJzaGlwIGFuZCAN CiAgIHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbiwgaXQgY2FuIGNvbnN0cnVjdCBTaG9ydGVzdCBQ YXRoIFRyZWVzICANCiAgIGJldHdlZW4gVlJzIGluIGEgVlItVlBOLCB3aGljaCBhcmUgcm9vdGVk IGF0IGV2ZXJ5IFNvdXJjZS1WUiBhbmQgDQogICBhZGRyZXNzZWQgb24gUC1Hcm91cCBpbiB0aGUg U1AncyBhZGRyZXNzIHNwYWNlLiBBIHNob3J0ZXN0IHBhdGggdHJlZSANCiAgIChTb3VyY2UtVlIs IFAtR3JvdXApIGNhbiBiZSBzZXR1cCB1c2luZyBQSU0tYmFzZWQgcHJvdG9jb2xzIG9yIA0KICAg TVBMUyBQMk1QIHR1bm5lbC4gQWxsIG11bHRpY2FzdCB0cmFmZmljIGZyb20gYSBTb3VyY2UtVlIg dG8gDQogICBvdGhlciBWUnMgc2hhcmUgdGhlIHRyZWUgKFNvdXJjZS1WUiAsUC1Hcm91cCkgaW4g dGhlIFNQIG5ldHdvcmsuIA0KICAgSGVyZSwgYSBQLUdyb3VwIGFkZHJlc3MgaXMgYSBtdWx0aWNh c3QgZ3JvdXAgYWRkcmVzcyBpbiBhIFNQJ3MgDQogICBhZGRyZXNzIHNwYWNlLCB3aGljaCByZXBy ZXNlbnRzIGFsbCBvdGhlciBWUnMgcmVxdWlyZWQgdG8gcmVjZWl2ZSANCiAgIHRoZSBtdWx0aWNh c3QgdHJhZmZpYyBmcm9tIGEgU291cmNlLVZSLg0KDQogICBXaGVuIHRoZXJlIGlzIGEgU291cmNl LVZSIGFjdGluZyBhcyBhIFByb3h5IFNvdXJjZS9SUCBvZiBhIGN1c3RvbWVyIA0KICAgc2l0ZSB0 byByZWNlaXZlIG11bHRpY2FzdCBwYWNrZXRzIGZyb20gdGhlIHNpdGUsIGl0IGVuY2Fwc3VsYXRl cyANCiAgIHRoZSBwYWNrZXRzIGluIEdSRSBvciBpbiBJUCwgYW5kIHRoZSB0cmFmZmljIHdpbGwg YnJvYWRjYXN0IHRvIGFsbCANCiAgIFZScyBhY3RpbmcgYXMgbGVhZiBub2RlcyBpbiB0aGUgc2Ft ZSBWUE4gYWxvbmcgdGhlIFNob3J0ZXN0IFBhdGggDQogICBUcmVlLg0KDQoNCjUuNSBNdWx0aWNh c3QgRGF0YSBGb3J3YXJkaW5nDQoNCiAgIEFmdGVyIGEgVlIgYWN0aW5nIGFzIGEgbGVhZiBub2Rl IGhhcyByZWNlaXZlZCB0aGUgZmlyc3QgcGFja2V0IGZyb20gDQogICBTb3VyY2UtVlIsIGl0IGV4 dHJhY3RzIGJhc2ljIGluZm9ybWF0aW9uIGluIGVuY2Fwc3VsYXRlZCBwYWNrZXRzLCANCiAgIHRo YXQgYXJlIFNvdXJjZS1WUiBhZGRyZXNzIGFuZCBQLUdyb3VwIGFkZHJlc3MsIHRoZW4gZGVjaWRl cyB3aGV0aGVyIA0KICAgaXQgaGFzIG11bHRpY2FzdCByZXF1aXJlbWVudCBmcm9tIHRoZSBTb3Vy Y2UtVlIuIElmIHRoZXJlIGlzIG5vIA0KICAgbXVsdGljYXN0IHJlY2VpdmVyIGluIHRoZSBsb2Nh bCBWUE4gc2l0ZXMgaXQgc2VydmVkLCB0aGUgVlIgZGlzY2FyZHMgDQogICBtdWx0aWNhc3QgcGFj a2V0cyBhbmQgcHJ1bmVzIGZyb20gbXVsdGljYXN0IHRyZWUgKFNvdXJjZS1WUiwgUC1Hcm91cCkN CiAgIHRvIHJlamVjdCB0cmFmZmljIGZyb20gdGhpcyBTb3VyY2UtVlIuIEEgbGVhZiBWUiB3aGlj aCBoYXMgYmVlbiANCiAgIHBydW5lZCBmcm9tIHRyZWVzIHNob3VsZCBzdG9yZSB0aGUgc3RhdGUg aW5mb3JtYXRpb24gb2YgDQogICAoU291cmNlLVZSLCBQLUdyb3VwKS4gQXMgc29vbiBhcyBhIGxv Y2FsIHNpdGUgY29ubmVjdGluZyB0byANCiAgIHRoZSBwcnVuZWQgbGVhZiBWUiBuZWVkcyB0byBy ZWNlaXZlIGFueSBDLVNvdXJjZSB0cmFmZmljIHByb3hpZWQgDQogICBieSB0aGUgU291cmNlLVZS LCB0aGUgcHJ1bmVkIGxlYWYgVlIgc2hvdWxkIGV4cGxpY2l0bHkgam9pbiB0aGUgdHJlZSANCiAg IGFnYWluLCB0aGVuIHJlY2VpdmUgbXVsdGljYXN0IHBhY2tldHMgZnJvbSB0aGUgU291cmNlLVZS Lg0KDQogICBFdmVyeSBWUiBhY3RpbmcgYXMgbGVhZiBub2RlcyByZXBlYXRzIHRoZXNlIG9wZXJh dGlvbnMsIHRodXMgDQogICBtdWx0aWNhc3QgcGFja2V0cyBmcm9tIGEgU291cmNlLVZSIGFyZSBm b3J3YXJkZWQgb25seSB0byB0aG9zZSBWUnMgDQogICB3aGljaCByZXF1aXJlIHRvIHJlY2VpdmUg bXVsdGljYXN0IHRyYWZmaWMgZnJvbSB0aGUgU291cmNlLVZSLiANCiAgIEV2ZXJ5IFZSIGNhbiBi ZSBzb3VyY2UgKGkuZS4gcm9vdCkgb3IgcmVjZWl2ZXIgKGkuZS4gbGVhZikgb2YgDQogICBhIHNo b3J0ZXN0IHBhdGggdHJlZSwgYW5kIGRpZmZlcmVudCB0cmVlcyBhcmUgaWRlbnRpZmllZCBieSAN CiAgIChTb3VyY2UtVlIsIFAtR3JvdXApLg0KDQogICBXaGVuIGEgY2VydGFpbiBsZWFmIFZSIGhh cyBuZXcgbXVsdGljYXN0IHJlcXVpcmVtZW50cyB0byBtdWx0aWNhc3QNCiAgIHNvdXJjZSBDLVNv dXJjZSwgaXQgY2hlY2tzIHRoZSBtdWx0aWNhc3Qgc291cmNlIHJvdXRpbmcgdGFibGUgdG8gZ2V0 IA0KICAgdGhlIHJlbGF0aW9uIGJldHdlZW4gQy1Tb3VyY2UgYW5kIFNvdXJjZS1WUi4gSWYgdGhl IGxlYWYgVlIgaGFzIGJlZW4gDQoNCg0KDQpIb25nLUtlIFpoYW5nLCBldCBhbC4gICAgICAgIEV4 cGlyZXMgSmFudWFyeSAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgOF0NCg0KDA0KSW50ZXJuZXQg RHJhZnQgICAgTXVsdGljYXN0IGluIFZpcnR1YWwgUm91dGVyLWJhc2VkIElQIFZQTnMgICAgSnVs eSAyMDA1DQoNCg0KICAgb24gdGhlIHRyZWUgKFNvdXJjZS1WUiwgUC1Hcm91cCksIGl0IGNvbnRp bnVlcyByZWNlaXZpbmcgcGFja2V0cyANCiAgIGZyb20gU291cmNlLVZSIHdpdGhvdXQgYWRkaXRp b25hbCBwcm9jZXNzaW5nLiBJZiB0aGlzIGxlYWYgVlIgaGFzIA0KICAgcHJ1bmVkIGl0c2VsZiBm cm9tIHRoZSB0cmVlIHJvb3RlZCBvbiBTb3VyY2UtVlIsIGl0IHNlbmRzIEpvaW4gDQogICBtZXNz YWdlIHRvIHRoZSB0cmVlLCB0aGVuIGJlZ2lucyB0byByZWNlaXZlIGVuY2Fwc3VsYXRlZCBwYWNr ZXRzIA0KICAgZnJvbSBTb3VyY2UtVlIuDQoNCiAgIEFmdGVyIHJlY2VpdmluZyBwYWNrZXRzLCBW UiBkZWNhcHN1bGF0ZXMgYW5kIHJlY292ZXJzIG11bHRpY2FzdCANCiAgIHBhY2tldHMsIHRoZW4g Zm9yd2FyZHMgdGhlbSB0byBsb2NhbCByZWNlaXZlcnMgb3IgZGlzY2FyZHMgdGhlbSANCiAgIGFj Y29yZGluZyB0byBsb2NhbCBtdWx0aWNhc3QgZm9yd2FyZGluZyB0YWJsZS4gDQoNCiAgIEZyb20g dGhlIGFib3ZlLW1lbnRpb25lZCwgdGhlIHByb2Nlc3Npbmcgb2YgbXVsdGljYXN0IHRyZWVzIGFu ZCANCiAgIHBhY2tldHMgYmV0d2VlbiBWUnMgaW4gYSBWUE4gaXMgZHJpdmVkIGJ5IG11bHRpY2Fz dCByZWNlaXZpbmcgDQogICByZXF1aXJlbWVudHMgb2YgbGVhZiBWUnMgZnJvbSBhIEMtc291cmNl LCB3aGlsZSBpbmRlcGVuZGVudCANCiAgIG9mIGxvY2FsIHN0YXRlIG9mIChDLXNvdXJjZSwgQy1H cm91cCkuIE9ubHkgYWZ0ZXIgbXVsdGljYXN0IA0KICAgdHJhZmZpYyBmcm9tIFNvdXJjZS1WUiBy ZWFjaCBsZWFmIFZScyB3aXRoIG11bHRpY2FzdCByZWNlaXZpbmcgDQogICByZXF1aXJlbWVudHMg dGhyb3VnaCB0aGUgdHJlZSwgbGVhZiBWUnMgZGVjaWRlIHdoZXRoZXIgdG8NCiAgIGRpc2NhcmQg b3IgZm9yd2FyZCBtdWx0aWNhc3QgcGFja2V0cyB0byBsb2NhbCBDLUdyb3VwIGFjY29yZGluZyB0 byANCiAgIGxvY2FsIHN0YXRlIG9mIChDLVNvdXJjZSxDLUdyb3VwKS4NCg0KDQo2LiBTY2FsYWJp bGl0eSBDb25zaWRlcmF0aW9ucw0KDQogICBTY2FsYWJpbGl0eSBpcyBhIGtleSByZXF1aXJlbWVu dCBmb3IgbXVsdGljYXN0IFZQTiBzb2x1dGlvbnMuIA0KICAgR2VuZXJhbGx5LCBlZmZpY2llbnQg bXVsdGljYXN0IHJvdXRpbmcgYW5kIHNjYWxhYmlsaXR5IGFyZSBjb21wZXRpbmcgDQogICBnb2Fs cy4gVGhlIFNQIGhhcyBubyBjb250cm9sIG92ZXIgdGhlIG51bWJlciBvZiBtdWx0aWNhc3QgZ3Jv dXBzIGluIA0KICAgdGhlIFZQTnMgYW5kIGFtb3VudCBvZiByb3V0ZSBzdGF0ZXMuIEluIHRoaXMg c29sdXRpb24sIGFsbCBtdWx0aWNhc3QgDQogICB0cmVlcyAoU291cmNlLVZSLCBQLUdyb3VwKSBp biBTUCBuZXR3b3JrcyBhcmUgU2hvcnRlc3QgUGF0aCBUcmVlcy4gDQogICBUaGUgbnVtYmVyIG9m IHRyZWVzIHJvb3RlZCBvbiBWUnMgaXMgcmVsYXRpdmVseSBzdGF0aWMuIFRoZSBQLUdyb3VwIA0K ICAgYWRkcmVzcyBjYW4gYmUgY29uZmlndXJlZCBieSBhZG1pbmlzdHJhdG9yIG9yIGF1dG8tc2Vs ZWN0ZWQgaW4gDQogICBjZXJ0YWluIHJhbmdlIGFuZCB0aGUgUC1Hcm91cCBhZGRyZXNzIGNhbiBi ZSB0aGUgc2FtZSBmb3IgZGlmZmVyZW50IA0KICAgc291cmNlIFZScyBpbiB0aGUgc2FtZSBWUi1W UE4uIFRodXMgdGhlIG51bWJlciBvZiB0cmVlcyANCiAgIChTb3VyY2UtVlIsIFAtR3JvdXApIGlu IFNQIG5ldHdvcmtzIHdpbGwgbmVpdGhlciBleGNlZWQgdGhlIG51bWJlciANCiAgIG9mIFZScyBu b3IgY2hhbmdlIHdpdGggdGhlIG51bWJlciBvZiBjdXN0b21lcnMsIHRoZSBudW1iZXIgb2YgDQog ICBDLVNvdXJjZSBhbmQgQy1Hcm91cCwgb3IgdGhlIHRvcG9sb2d5IG9mIGxvY2FsIHRyZWVzIA0K ICAgKEMtU291cmNlLCBDLUdyb3VwKSBpbiBsb2NhbCBzaXRlcy4gU28gaXQgbm90IG9ubHkgcmVk dWNlcyBwYXlsb2FkIA0KICAgb24gU1AgbmV0d29ya3MgZWZmZWN0aXZlbHkgYnV0IGFsc28gaW1w cm92ZXMgc2NhbGFiaWxpdHkuDQoNCg0KNy4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAg U2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGlzY3Vzc2VkIGluIFtWUi1WUE5dIGFwcGx5IHRvIHRo aXMgZG9jdW1lbnQuDQogICBGcm9tIGEgcm91dGUgZGVwbG95bWVudCBzdGFuZHBvaW50LCB0aGUg aXNvbGF0aW9uIGJldHdlZW4gZGlmZmVyZW50IA0KICAgVlBOcyBpcyBjcnVjaWFsLiBJbiB0aGlz IHNvbHV0aW9uLCBwcm9jZXNzaW5nIGluIFNQIG5ldHdvcmsgd2lsbCBiZSANCg0KICAgaW1wbGVt ZW50ZWQgaW4gdGhvc2UgVlJzIGJlbG9uZ2luZyB0byB0aGUgc2FtZSBWUE4uIEl0IGNhbiBnZXQg Z29vZA0KICAgaXNvbGF0aW9uIHBlcmZvcm1hbmNlIGJlY2F1c2UgZXZlcnkgVlBOIGhhcyBwcml2 YXRlIG11bHRpY2FzdCBhZGRyZXNzDQogICBzcGFjZS4gSWYgb25seSB0aGUgd2hvbGUgc3lzdGVt IGlzb2xhdGVzIFZScyBpbiB0aGUgc2FtZSBQRSByZWxpYWJseSwNCiAgIHRoZSBzZWN1cml0eSB3 aWxsIHJlYWNoIGFuIGFjY2VwdGFibGUgbGV2ZWwuDQoNCkhvbmctS2UgWmhhbmcsIGV0IGFsLiAg ICAgICAgRXhwaXJlcyBKYW51YXJ5IDIwMDYgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDQoMDQpJ bnRlcm5ldCBEcmFmdCAgICBNdWx0aWNhc3QgaW4gVmlydHVhbCBSb3V0ZXItYmFzZWQgSVAgVlBO cyAgICBKdWx5IDIwMDUNCg0KDQo4LiBBY2tub3dsZWRnbWVudA0KDQogICBXZSB3b3VsZCBsaWtl IHRvIHRoYW5rIFF1YW4tTGluIExpLCBFbi1IdWkgTGl1LCBZdWUgWmhhbmcsIFNodWFpIEdhbyAN CiAgIGFuZCBZYS1qdWFuIFFpbiBmb3IgdGhlaXIgdmFsdWFibGUgY29tbWVudHMgYW5kIHN1Z2dl c3Rpb25zIG9uIA0KICAgdGhpcyBkb2N1bWVudC4NCg0KDQo5LiBOb3JtYXRpdmUgUmVmZXJlbmNl cw0KDQogICBbUFBWUE4tVEVSTV0gICJQcm92aWRlciBQcm92aXNpb25lZCBWUE4gdGVybWlub2xv Z3kiLCBMLiBBbmRlcnNzb28sIA0KICAgICAgICAgICAgICAgVC4gTWFkc2VuLCBTZXB0ZW1iZXIg MjAwNCwgDQogICAgICAgICAgICAgICBkcmFmdC1pZXRmLWwzdnBuLXBwdnBuLXRlcm1pbm9sb2d5 LTA0DQoNCjEwLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtNUkVRVF0gICAgIlJlcXVp cmVtZW50cyBmb3IgTXVsdGljYXN0IGluIEwzIFByb3ZpZGVyLVByb3Zpc2lvbmVkDQogICAgICAg ICAgICAgIFZQTnMiLCBULiBNb3JpbiwgRWQuICxGcmFuY2UgVGVsZWNvbSBSJkQsIEZlYnJ1YXJ5 IDIwMDUsDQogICAgICAgICAgICAgIGRyYWZ0LWlldGYtbDN2cG4tcHB2cG4tbWNhc3QtcmVxdHMt MDAudHh0DQogICBbVlItVlBOXSAgICJOZXR3b3JrIGJhc2VkIElQIFZQTiBBcmNoaXRlY3R1cmUg dXNpbmcgVmlydHVhbCBSb3V0ZXJzIiwgDQogICAgICAgICAgICAgIFBhdWwgS25pZ2h0LCBIYW1p ZCBPdWxkLUJyYWhpbSwgQnJ5YW4gR2xlZXNvbiwgDQogICAgICAgICAgICAgIEFwcmlsIDIwMDQs IGRyYWZ0LWlldGYtbDN2cG4tdnBuLXZyLTAyLnR4dCANCiAgIFtNVlBOLTddICAgIk11bHRpY2Fz dCBpbiBNUExTL0JHUCBWUE5zIiwgRS4gUm9zZW4uIGV0LiBhbC4sIE1heSAyMDA0DQogICAgICAg ICAgICAgIGRyYWZ0LXJvc2VuLXZwbi1tY2FzdC0wNy50eHQNCiAgIFtQMk1QXSAgICAgIkJHUC9N UExTIElQIE11bHRpY2FzdCBWUE5zIiwgU2Vpc2hvIFlhc3VrYXdhIGV0LiBhbC4sIA0KICAgICAg ICAgICAgICBPY3RvYmVyIDIwMDQsIGRyYWZ0LXlhc3VrYXdhLWwzdnBuLXAybXAtbWNhc3QtMDAu dHh0DQoNCg0KMTEuIEF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBIb25nLUtlIFpoYW5nDQogICBJ UCBsYWIsIEJlaWppbmcgSmlhb1RvbmcgVW5pdi4NCiAgIEJlaWppbmcsIENoaW5hLCAxMDAwNDQN CiAgIFRlbDogKzg2LTEwLTUxNjg1Njc3IA0KICAgRW1haWw6IGhremhhbmdAY2VudGVyLm5qdHUu ZWR1LmNuDQoNCiAgIENodW4tWXVlIFpob3UsIEJpbmctWWkgWmhhbmcNCiAgIElQIGxhYiwgQmVp amluZyBKaWFvVG9uZyBVbml2Lg0KICAgQmVpamluZywgQ2hpbmEsIDEwMDA0NA0KICAgRW1haWw6 IHpob3VjaHVueXVlQGhvdG1haWwuY29tDQogICAgICAgICAgYmluZ3lpemhhbmdAaG90bWFpbC5j b20NCg0KICAgRW4tSHVpIExJVQ0KICAgSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCiAg IEJlaWppbmcsIENoaW5hLCAxMDAwODUNCiAgIFRlbDogKzg2LTEwLTgyODgyNDk1DQogICBGYXg6 ICs4Ni0xMC04Mjg4MjUzNw0KICAgRW1haWw6IExFSDEwODE0QGh1YXdlaS5jb20NCg0KDQpIb25n LWtlIFpoYW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyMDA2ICAgICAgICAgICAg ICBbUGFnZSAxMF0NCg0KDA0KSW50ZXJuZXQgRHJhZnQgICAgTXVsdGljYXN0IGluIFZpcnR1YWwg Um91dGVyLWJhc2VkIElQIFZQTnMgICAgSnVseSAyMDA1DQoNCg0KICAgU3BlbmNlciBEYXdraW5z DQogICBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KICAgVFgsIFVTQSwgNzUwNzUNCiAg IEVtYWlsOiBzZGF3a2luc0BmdXR1cmV3ZWkuY29tDQoNCg0KMTIuIEludGVsbGVjdHVhbCBQcm9w ZXJ0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5n IHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBS aWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVydGFp biB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJl ZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNl IHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBu b3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5kZW50 IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAgb24g dGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNh biBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJUFIg ZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBhc3N1 cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9m IGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1p c3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxl bWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5l ZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5 IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9y IHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhh dCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQN CiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhl IElFVEYgYXQgaWV0Zi0NCiAgIGlwckBpZXRmLm9yZy4NCg0KDQpGdWxsIENvcHlyaWdodCBOb3Rp Y2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuICBUaGlz IGRvY3VtZW50IGlzIA0KICAgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVz dHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1ANCiAgIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0 aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyDQogICByaWdodHMuDQoNCiAg IFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBw cm92aWRlZA0KICAgb24gYW4gIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUg T1JHQU5JWkFUSU9OIEhFL1NIRQ0KICAgUkVQUkVTRU5UUyBPUiBJUyBTUE9OU09SRUQgQlkgKElG IEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORA0KICAgVEhFIElOVEVSTkVUIEVOR0lORUVS SU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsDQogICBFWFBSRVNTIE9SIElN UExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQNCiAg IFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkg UklHSFRTIE9SDQogICBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBP UiBGSVRORVNTIEZPUiBBDQogICBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KDQpIb25nLUtlIFpo YW5nLCBldCBhbC4gICAgICAgIEV4cGlyZXMgSmFudWFyeSAyMDA2ICAgICAgICAgICAgICBbUGFn ZSAxMV0NCg0KDQo= --=====001_Dragon315360726562_=====-- From l3vpn-bounces@ietf.org Thu Jul 21 18:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvjs3-0005vy-Ed; Thu, 21 Jul 2005 18:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvjrg-0005oW-FB; Thu, 21 Jul 2005 18:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22524; Thu, 21 Jul 2005 18:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvkLm-0006AY-MN; Thu, 21 Jul 2005 19:21:11 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dvjre-0004Yx-54; Thu, 21 Jul 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 21 Jul 2005 18:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-gre-ip-2547-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --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 Virtual Private Networks Author(s) : Y. Rekhter, et al. Filename : draft-ietf-l3vpn-gre-ip-2547-04.txt Pages : 13 Date : 2005-7-21 This draft describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE). The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-gre-ip-2547-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-gre-ip-2547-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-gre-ip-2547-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-21171858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-gre-ip-2547-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-gre-ip-2547-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-21171858.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Fri Jul 22 05:45:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvu5i-0000Mi-I3; Fri, 22 Jul 2005 05:45:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvu5g-0000Lq-Gf for l3vpn@megatron.ietf.org; Fri, 22 Jul 2005 05:45:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26794 for ; Fri, 22 Jul 2005 05:45:09 -0400 (EDT) Received: from wm20.inbox.com ([208.50.6.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DvuZs-0004rM-Vb for l3vpn@ietf.org; Fri, 22 Jul 2005 06:16:26 -0400 Received: from inbox.com (127.0.0.1:25) by inbox.com with [inbox.com smtp server] id <507220003994.WM20> for from ; Fri, 22 Jul 2005 1:45:04 AM -0800 Mime-Version: 1.0 Date: Fri, 22 Jul 2005 01:45:02 -0800 Message-ID: From: naga sudarsanreddy To: l3vpn@ietf.org, grundke@cs.dal.ca, srini@cs.dal.ca, farrag@cs.dal.ca X-Mailer: INBOX.COM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: quoted-printable Cc: Subject: vpn X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org sir, send me a research topic in vpn.my guide asking do project in multicasting in vpn.send a details about vpn.= From l3vpn-bounces@ietf.org Fri Jul 22 20:31:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7vh-0007rv-K1; Fri, 22 Jul 2005 20:31:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw7vf-0007qM-Jh for l3vpn@megatron.ietf.org; Fri, 22 Jul 2005 20:31:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14113 for ; Fri, 22 Jul 2005 20:31:45 -0400 (EDT) Received: from web308.biz.mail.mud.yahoo.com ([68.142.199.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dw8Pz-0007oZ-OU for l3vpn@ietf.org; Fri, 22 Jul 2005 21:03:09 -0400 Received: (qmail 30956 invoked by uid 60001); 23 Jul 2005 00:31:30 -0000 Message-ID: <20050723003130.30954.qmail@web308.biz.mail.mud.yahoo.com> Received: from [63.203.204.200] by web308.biz.mail.mud.yahoo.com via HTTP; Fri, 22 Jul 2005 17:31:30 PDT Date: Fri, 22 Jul 2005 17:31:30 -0700 (PDT) From: Rick Wilder To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-377298548-1122078690=:30925" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt. X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --0-377298548-1122078690=:30925 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit L3VPN participants, This begins a two-week last call for comments on draft-ietf-l3vpn-gre-ip-2547-04.txt. Rick --0-377298548-1122078690=:30925 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
L3VPN participants,
 
 
This begins a two-week last call for comments on draft-ietf-l3vpn-gre-ip-2547-04.txt.
 
Rick
 
 
 
 

 
--0-377298548-1122078690=:30925-- From l3vpn-bounces@ietf.org Fri Jul 22 21:11:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw8YV-0007md-Od; Fri, 22 Jul 2005 21:11:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw8YU-0007lN-4Z for l3vpn@megatron.ietf.org; Fri, 22 Jul 2005 21:11:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16746; Fri, 22 Jul 2005 21:11:51 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw92o-0000kD-NT; Fri, 22 Jul 2005 21:43:15 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 23 Jul 2005 02:11:43 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 23 Jul 2005 02:11:42 +0100 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Jul 2005 21:11:40 -0400 Received: from [172.24.235.3] ([172.24.235.3]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 21:11:39 -0400 Message-ID: <42E1994B.9070307@juniper.net> Date: Fri, 22 Jul 2005 21:11:39 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: agenda@ietf.org, l3vpn@ietf.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2005 01:11:39.0795 (UTC) FILETIME=[7ADE6630:01C58F23] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Subject: *Draft* Agenda - IETF 63L3VPN WG X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Layer 3 Virtual Private Networks (Internet Area) Monday, August 1 at 16:30-18:00 ============================== Chairs: Ross Callon Rick Wilder Ron Bonica Agenda: 16:30-16:40 Document Status Review - Ross Callon 16:40-17:00 Multicast VPN Requirements - Thomas Morin draft-ietf-l3vpn-ppvpn-mcast-reqts-01 17:00-17:15 Multicast VPN Solution - Rahul Aggarwal draft-ietf-l3vpn-2547bis-mcast-00 17:15-17:30 Multicast VPN MIB - Tom Nadeau draft-svaidya-mcast-vpn-mib-02 17:30-17:45 Virtual Router Multicast Solution - Hong-Ke Zhang draft-zhang-l3vpn-vr-multicast 17:45-17:55 Inter AS option for BGP/MPLS IP VPN - Marko Kulmala draft-kulmala-l3vpn-interas-option-d-00 From l3vpn-bounces@ietf.org Mon Jul 25 04:44:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwyZp-0002G3-Ny; Mon, 25 Jul 2005 04:44:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwyZp-0002Fy-32 for l3vpn@megatron.ietf.org; Mon, 25 Jul 2005 04:44:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28289 for ; Mon, 25 Jul 2005 04:44:43 -0400 (EDT) Received: from web25308.mail.ukl.yahoo.com ([217.12.10.80]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dwz4X-0000t2-K8 for l3vpn@ietf.org; Mon, 25 Jul 2005 05:16:36 -0400 Received: (qmail 84027 invoked by uid 60001); 25 Jul 2005 08:44:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=C0SUZnJ+1RoKWeP7JFsAvYujdH5pGDaiM1ZlOwgCcU7dNxoHGYAb4WplLKEojURQhEnuYlShHR7Jb3ubNHgB6jTuZkmXN9HUei8t3AMSbjpo7eYAYu5/YVkPjCXyPdGbj64aoNHKPEwzKsOFhIVYsqTSmB1Apr3N7GY8sUXXDh4= ; Message-ID: <20050725084420.84025.qmail@web25308.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25308.mail.ukl.yahoo.com via HTTP; Mon, 25 Jul 2005 09:44:19 BST Date: Mon, 25 Jul 2005 09:44:19 +0100 (BST) From: John Smith To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 8bit Subject: RTs when importing routes into a VRF X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hi, Should a PE router, while advertising the BGP routes to an EBGP peer, strip off the RTs or should the RTs remain attached? PE ----- CE <--BGP--> We have 2 routers running EBGP. CE is in VRF, and has import target of 1:1. PE recives a route 10/8 from a remote PE with RTs 1:1 and 2:2. Should the PE router keep the RTs attached along with the BGP UPDATEs when it announces the route to the CE BGP peer? I think it should. Thanks, John ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Mon Jul 25 21:36:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEMf-0007At-C8; Mon, 25 Jul 2005 21:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6Qn-00027r-Tq for l3vpn@megatron.ietf.org; Mon, 25 Jul 2005 13:07:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07759 for ; Mon, 25 Jul 2005 13:07:55 -0400 (EDT) Received: from web307.biz.mail.mud.yahoo.com ([68.142.199.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dx6ve-0001U0-4r for l3vpn@ietf.org; Mon, 25 Jul 2005 13:39:53 -0400 Received: (qmail 38265 invoked by uid 60001); 25 Jul 2005 17:07:38 -0000 Message-ID: <20050725170737.38263.qmail@web307.biz.mail.mud.yahoo.com> Received: from [218.80.152.36] by web307.biz.mail.mud.yahoo.com via HTTP; Mon, 25 Jul 2005 10:07:37 PDT Date: Mon, 25 Jul 2005 10:07:37 -0700 (PDT) From: Joseph Laria To: internet-drafts@ietf.org, l3vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-802967879-1122311257=:36936" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8e09a9838b5d5fc403683e84b112cba8 X-Mailman-Approved-At: Mon, 25 Jul 2005 21:36:12 -0400 Cc: Subject: draft-ietf-l3vpn-vr-mib-04 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --0-802967879-1122311257=:36936 Content-Type: text/plain; charset=iso-8859-1 Content-Id: Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi, Attached is the Last Call version of draft-ietf-l3vpn-vr-mib. The Virtual Router MIB is a work item of the Provider Provisioned Virtual Private Networks (L3) Working Group. Title: Virtual Router Management Information Base Using SMIv2 Author(s): Elwin Stelzer, Sam Hancock, Benson Schliesser, Joseph Laria Filename: draft-ietf-l3vpn-vr-mib-04.txt Pages: XX Date: July 2005 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). The changes which have been made reflect the comments received during last call. These include: 1. Move the VR-MIB from the expermental branch to mib-2 2. Create a textual convention for vrRPTrigger syntax 3. Add a vrMaxRouteExceeded Trap Enabled object to prevent notification storms when the max routes are exceeded. 4. Correct several formatting and miscellaneous typos identified from last call comments. Thanks. Joe Laria --0-802967879-1122311257=:36936 Content-Type: text/plain; name="draft-ietf-l3vpn-vr-mib-04.txt" Content-Description: 1590955209-draft-ietf-l3vpn-vr-mib-04.txt Content-Disposition: inline; filename="draft-ietf-l3vpn-vr-mib-04.txt" INTERNET-DRAFT Elwin Stelzer draft-ietf-l3vpn-vr-mib-04.txt Corona Networks, Inc. Expires: January 2006 Sam Hancock ACM Systems Benson Schliesser SAVVIS Communications Joseph Laria (Ed.) Level Stream Research July 2005 Virtual Router Management Information Base Using SMIv2 Status of this Memo This document is an Internet-Draft. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a product of the IETF's Layer 3 Virtual Private Network (l3vpn) working group. Comments should be addressed to WG's mailing list at l3vpn@ietf.org. The charter for l3vpn may be found at http://www.ietf.org/html.charters/l3vpn-charter.html Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). Layer-3 VPN Group Expires January 2006 [Page 1] Draft Virtual Router MIB module July 2005 Table of Contents 1.0 Terminology 2.0 Introduction 3.0 The Internet-Standard Management Framework 4.0 Overview of the Virtual Router MIB Module 4.1 SNMP Contexts for Management for Virtual Routers 4.2 VR Indexing 4.3 Creation and Deletion of VRs 4.4 Administrative and Operational Status of VRs 4.4.1 VR Routing Protocol Trigger 4.5 Binding interfaces to a VR 4.6 Setting per VR limits 4.7 Per VR Statistics 4.8 Traps 4.9 Usability Considerations 4.9.1 Multiple Agents 4.9.2 Provisioning vs. Monitoring 5.0 Sample VR MIB module Configuration Scenario 5.1 Creation of a VR 6.0 Definition of the Virtual Router MIB Module 7.0 Acknowledgments 8.0 Security Considerations 9.0 References 9.1 Normative References 9.2 Informative References 10.0 Authors' Addresses 11.0 Intellectual Property Considerations 12.0 Full Copyright Statement 13.0 IANA Considerations for L3VPN-VR-MIB module 1.0 Terminology This document uses terminology defined in [PPVPN-FW] and [PPVPN-VR]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [RFC2119]. 2.0 Introduction This memo defines a MIB module for the Virtual Router [PPVPN-VR, PPVPN-VR-AS] model of Provider Provisioned VPNs [PPVPN-FW]. Following are the goals, in defining this MIB module: - To have a means for Service Providers to provision VPN service for subscribers, at the PE device. - To make the agent-side implementation simple, by not modifying the existing standard MIB modules. - Define all the gluing tables that are needed toward this end. Layer-3 VPN Group Expires January 2006 [Page 2] Draft Virtual Router MIB module July 2005 3.0 The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB module objects are generally accessed through the Simple Network Management (SNMP) Protocol. Objects in a MIB module are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 4.0 Overview of the Virtual Router MIB Module 4.1 SNMP Contexts for Management for Virtual Routers There is a need for a single agent to manage multiple Virtual Routers. The Architecture for describing SNMP Management Frameworks [RFC3411] provides a way to support such cases. Managing multiple virtual routers requires that the PE management plane be subdivided into logical VR management domains. In the VR model of PPVPNs a single PE device may contain many virtual routers. Different management entities SHOULD be able to manage specific virtual routers and associated services. The Service Provider MUST be able to manage all virtual routers and associated services. Using SNMP contexts to group a collection of management information provides the following benefits: (1) Uses a standard framework defined by the IETF, allowing the product to remain flexible to all implementations of virtual router devices. (a) Use SNMPv2c Community String's (b) Use SNMPv3 contextName's (2) Prevents vendors from having to modify the standard MIBs, allowing the implementation to remain standards compliant. (3) Provides a framework that will work for RIP, OSPF, IS-IS, BGP, IP-FORWARDING, MPLS, and any other MIB module that can be administratively grouped with a VR. Layer-3 VPN Group Expires January 2006 [Page 3] Draft Virtual Router MIB module July 2005 The SNMP context for the Virtual Router instance can be specified in the VrConfigTable. The VrContextName columnar object is used to set the SNMPv2c Community String or the SNMPv3 contextName for a given VR. A virtual router context represents the set of MIB module objects that could be administratively grouped within a VR. For example, each VR would maintain its own instance of routing protocol MIB module tables. However, the ADMIN context would contain single instances of objects and tables that pertain to system wide configuration such as the Entity, Interfaces, and ATM MIB modules. A management system using the SNMP context of a particular virtual router MUST be able to manage the virtual router without disrupting other virtual routers in the same PE device. For example, a PE can be subdivided into two 2 VRs running the OSPF routing protocol. Each VR will maintain a unique instance of the OSPF-MIB. Therefore, the ospfAreaTable of VR-A is distinct from the ospfAreaTable of VR-B. +-----------------------------------------------------------------+ | +------------------------------------------------------------+ | | | SNMP entity (including Engine, Applications) | | | | | | | | example contextNames: | | | | | | | | "vr01" "vr09" "admin" | | | | --------- --------- ------------ | | | | | | | | | | +------|------------------|-------------------|--------------+ | | | | | | | +------|------------------|-------------------|--------------+ | | | MIB | instrumentation | | | | | | +---v------------+ +---v------------+ +----v-----------+ | | | | | context=vr01 | | context=vr09 | | context=admin | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | OSPF MIB | | | | OSPF MIB | | | | VR MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | BGP MIB | | | | BGP MIB | | | | ATM MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | IP MIB | | | | IP MIB | | | | ENTITY MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | other MIB | | | | other MIB | | | | IF MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | ... | | ... | | ... | | | +-----------------------------------------------------------------+ Layer-3 VPN Group Expires January 2006 [Page 4] Draft Virtual Router MIB module July 2005 Filtering mechanisms based on the SNMP context of a particular virtual router may implemented to allow different management entities to manage those objects and services provisioned the 'Admin' context. 4.2 VR Indexing While the standard protocol MIB module tables are instantiated in the context specified using SNMP contexts, there may be tables that are defined with the VRID as index. The VRID is of local significance to a particular PE device, and need not be globally unique. Thus a particular VRID value assigned to a VR in one PE device may indicate a different VR in another PE device. The VRID has an Unsigned32 value, and this value is assigned by the management station. To aid the management station in assigning a VRID without conflict, the management station can get the 'NextAvailableVRID' from the PE device. A SNMP manager SHOULD NOT assume global significance of any VRID value other than 0. For those MIB module tables instantiated in the virtual router context, indexing can only be assumed unique for that particular VR. However those indices in the "ADMIN" context are unique across the entire system, including all VRs. 4.3 Creation and Deletion of VRs The VR Config Table is used for this purpose. This is a read-create table and adding an entry into this table will create a VR. Removing an entry from this table marks the deletion of a VR. VRID 0 is assigned to the Administrative VR, which exists by default, and need not be created. Deletion of the Administrative VR will not be permitted. The VRID of the Administrative VR (VRID 0) should be a reserved VRID number. VRID 0 could be termed the "null VR" and it could be the context that manages the resource pool of unattached interfaces. Routing would then not exist in the context of Administrative VR. 4.4 Administrative and Operational Status of VRs VRs can be administratively turned down. When this is done, no packet forwarding via the VR takes place. VrOperStatus denotes the operational status of a VR. Currently the VrOperStatus is expected to change along the VrAdminStatus unless an error condition exists. Layer-3 VPN Group Expires January 2006 [Page 5] Draft Virtual Router MIB module July 2005 4.4.1 VR Routing Protocol Trigger A construct for independently instantiating routing protocol instances for each VR may be useful a solution especially in a PE router where scaling of resources would be necessary. VrRpTrigger object represents the Routing Protocol (RP) triggers on a VR and is it meant to be used to initiate or shutdown routing protocols on a VR. 4.5 Binding interfaces to a VR Interfaces are bound to a VR, using vrIfConfigTable. This is a read-write table, and note that interfaces are not created through this table. The vrIfConfigTable MIB module table is used to indicated the relationship between interfaces and virtual router IDs. For each interface present in the system, this table is used to provide the mapping from IfIndex to a unique VR. The table show which interfaces are ?attached or connected? to a virtual router. An interface can not be attached to more than one VR. The "Admin" VR could be used to manage the resource pool of unattached interfaces. However interfaces would not be attached to VRID 0. 4.6 Setting per VR limits VRs consume resources on a device, and hence the following parameters defined in vrConfigTable are used to specify an upper bound of resource utilization: VrMaxRoutes - Specify the maximum number of routes that will be permitted in VR. This includes all routes, such as the statically configured routes, and the routes learnt via dynamic routing protocols. 4.7 Per VR Statistics In addition to those statistics available through the VR instantiated MIB module tables, there are some per-VR statistics available through vrStatTable. 4.8 Traps This memo defines that VrUp and VrDown traps are generated just after VrOperStatus leaves, or just before it enters, the down state, respectively. (1) A transition into the down state will occur when an error is detected on a VR instance. (2) Departing the down state generally indicates that the VR is going to up, which is considered a "healthy" state. An exception to the above generation of VrUp/VrDown traps on changes in VrOperStatus, occurs when an VR is "flapping", i.e., when it is rapidly oscillating between the up and down states. If traps were generated for each such oscillation, the network and the network management system would be flooded with unnecessary traps. In such a situation, the agent should limit the rate at which it generates traps. This memo defines that enabling and disabling the VR traps is achieved by setting the VrTrapEnable to true(1) or false(2), respectively. By default, this object should have the value true(1). Layer-3 VPN Group Expires January 2006 [Page 6] Draft Virtual Router MIB module July 2005 On some devices where system memory is limited, there may be a need to restrict the maximum number of routes allowed on the system. This memo defines vrMaxRoutesExceeded trap to indicate when vrStatRouteEntries exceeds the maximum limit. There is a danger of notification storms with this type of notification. The definition of vrMaxRoutes is such that vrStatRouteEntries could never exceed it. So whenever vrMaxRoutes has been reached, each new attempt to add a route will cause a new Notification. In order to prevent notification storms of this type, this memo also defines and the enabling and disabling of this trap which is acheived by setting the VrMaxRouteTrapEnable to true(1) or false(2), respectively. By default, this object should have the value true(1). 4.9 Usability Considerations 4.9.1 Multiple Agents The MIB module is based upon the premise that a single SNMP agent should represent every virtual router on a physical router. An alternative approach would be to deploy a separate SNMP agent for each virtual router. Creating multiple agents for use by the administrator (Service Provider) could be done, for instance by binding to different ports or addresses on the P-node. However from a resource perspective, it is more efficient to use a single agent and multiplex based on the community/context as described in this document. In either case, though, a VR-MIB module is needed to map each VR to its respective agent or context. There could be a case where a separate agent per VR may be useful, though not as a replacement for the VR-MIB module. If the platform supports instantiation of an agent *within* the VR then the VPN user could query stats, etc., from that agent. This would not be a replacement for the VR-MIB module because (in addition to the above points) the Service Provider may very well not have reachability/connectivity (not to mention uniqueness in addressing) into the VPN. For example, the Service Provider may not have management-network access to the customers' networks. 4.9.2 Provisioning vs. Monitoring The VR-MIB module goes to some length the support configuration using SNMP. Other MIB modules tend to be for monitoring purposes, with an occasional read-write variable. There is value in having configuration capabilities in this MIB module. The VR-MIB module fills in a gap, allowing for creation of the VR, while the VR context MIB modules allow for configuration of the VR itself. This might prove useful, perhaps even allowing for interoperable management tools. Some Service Provider may intend to use it only for monitoring. This is because there may be other mechanisms available to them for configuration of a specific platforms, such as Corba or XML interfaces that they may find more valuable for this function. Layer-3 VPN Group Expires January 2006 [Page 7] Draft Virtual Router MIB module July 2005 5.0 Sample VR MIB module Configuration Scenario 5.1 Creation of a VR Creating VR instances can be achieved using the following example. (1) Get the next available Virtual Router Id using the NextAvailableVrId, to create a VR: Using a context with 'read' access for system level entities. GetRequest { NextAvailableVrId.0 } Response { NextAvailableVrId.0 = 5555 } (2) In VrConfigTable, create VR Instance using VrRowStatus: Using a context with 'read-write' access for system level entities SetRequest { VrRowStatus.5555 createAndGo(4), VrName.5555 "BigTelcoVR", VrContextName.5555 "vr5555", VrTrapEnable.5555 true(1), VrAdminStatus.5555 up(1) } Layer-3 VPN Group Expires January 2006 [Page 8] Draft Virtual Router MIB module July 2005 6.0 Definition of the Virtual Router MIB Module -- -- VIRTUAL-ROUTER-MIB -- VIRTUAL-ROUTER-MIB DEFINITIONS ::= BEGIN IMPORTS InterfaceIndex FROM IF-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- RFC Ed.: VPN-TC-STD-MIB in Last Call in L3VPN WG VPNId FROM VPN-TC-STD-MIB OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF Unsigned32, OBJECT-TYPE, MODULE-IDENTITY, TimeTicks, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI TruthValue, DisplayString, RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC; virtualRouterMIB MODULE-IDENTITY LAST-UPDATED "200507221200Z" ORGANIZATION "IETF L3VPN WG" CONTACT-INFO " Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 USA Phone: +1-408-519-3832 Email: elwinietf@yahoo.com Samuel Hancock ACM Systems 3034 Gold Canal Drive Rancho Cordova, CA 95670 USA Phone: +1-916-463-7949 Email: hancoc_s@yahoo.com Benson Schliesser SAVVIS Communications 1 Savvis Parkway Town and Country, MO 63017 USA Phone: +1-314-628-7036 Email: bensons@savvis.net Joseph Laria (Editor) Level Stream Research Wilmington, MA 01887 USA Phone: +1-978-223-9908 Email: jlaria@levelstream.com " Layer-3 VPN Group Expires January 2006 [Page 9] Draft Virtual Router MIB module July 2005 DESCRIPTION "The MIB module is the definition of the managed objects for the Virtual Router." REVISION "200507221200Z" -- 22 July 2005 12:00:00 GMT DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { mib-2 xxxx } -- To be assigned -- RFC Ed.: replace xxxx with IANA-assigned number & remove this note -- -- Textual conventions -- VrIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Virtual Router Identifier. VRID 0 is reserved for the Administrative VR and cannot be used to create VR's. " SYNTAX Unsigned32 (0..4294967295) VrRpTriggerBitCode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This object represents Routing Protocol (RP) Triggers on a Virtual Router. The BITS represent an Action-code that specifies the action on the Routing Protocols. The actions are: initiate or shutdown. When encoding the RP using the BITS construct, the value is encoded as an OCTET STRING where the first bit (bit 0) is the highest bit of the octet. Bits 0-3 may be specified in any combination to allow multiple Routing Protocols to be acted on simultaneously or individually. " SYNTAX BITS { rip (0), ospf(1), bgp (2), isis (3) } Layer-3 VPN Group Expires January 2006 [Page 10] Draft Virtual Router MIB module July 2005 -- -- Node definitions -- vrMIBObjects OBJECT IDENTIFIER ::= { virtualRouterMIB 1 } vrConfig OBJECT IDENTIFIER ::= { vrMIBObjects 1 } vrConfigScalars OBJECT IDENTIFIER ::= { vrConfig 1 } vrConfigNextAvailableVrId OBJECT-TYPE SYNTAX VrIdentifier MAX-ACCESS read-only STATUS current DESCRIPTION "The next available Virtual Router Id (index). This object provides a hint for the vrID value to use when administratively creating a new vrConfigEntry. A GET of this object returns the next available vrId value to be used to create an entry in the associated vrConfigTable; or zero, if no valid vrId value is available. A value of zero(0) indicates that it is not possible to create a new vrConfigEntry This object also returns a value of zero when it is the lexicographic successor of a varbind presented in an SNMP GETNEXT or GETBULK request, for which circumstance it is assumed that ifIndex allocation is unintended. Successive GETs will typically return different values, thus avoiding collisions among cooperating management clients seeking to create table entries simultaneously. Unless specified otherwise by its MAX-ACCESS and DESCRIPTION clauses, an object of this type is read-only, and a SET of such an object returns a notWritable error." ::= { vrConfigScalars 1 } vrConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF VrConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is for creating the new Virtual Routers." ::= { vrConfig 2 } Layer-3 VPN Group Expires January 2006 [Page 11] Draft Virtual Router MIB module July 2005 vrConfigEntry OBJECT-TYPE SYNTAX VrConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entries in this table can be added/deleted using the vrRowStatus." INDEX { vrId } ::= { vrConfigTable 1 } VrConfigEntry ::= SEQUENCE { vrId VrIdentifier, vrRowStatus RowStatus, vrName DisplayString, vrContextName DisplayString, vrTrapEnable TruthValue, vrMaxRoutes Unsigned32, vrAdminStatus INTEGER, vrVpnId VPNId, vrRpTrigger VrRpTriggerBitCode, vrMaxRoutesTrapEnable TruthValue } vrId OBJECT-TYPE SYNTAX VrIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique id of this virtual router instance. A Virtual Router cannot not be created with vrId = 0. VRID 0 is reserved for the Administrative VR. " ::= { vrConfigEntry 1 } vrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status column has three defined values: - `active', which indicates that the conceptual row is available for use by the managed device; Layer-3 VPN Group Expires January 2006 [Page 12] Draft Virtual Router MIB module July 2005 - `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row." ::= { vrConfigEntry 2 } vrName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The Name of the Virtual Router." ::= { vrConfigEntry 3 } vrContextName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The SNMPv2 Community String or SNMPv3 contextName denotes the VR 'context' and is used to logically separate the MIB module management." ::= { vrConfigEntry 4 } vrTrapEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This objects is used to enable the generation of the VrUp and VrDown traps. true(1) - VR Traps Enabled false(2) - VR Traps Disabled" DEFVAL { true } ::= { vrConfigEntry 5 } vrMaxRoutes OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the maximum number of routes that this VR can support. The default value is 4 Gig (meaning unlimited)." DEFVAL { 4294967295 } ::= { vrConfigEntry 6 } Layer-3 VPN Group Expires January 2006 [Page 13] Draft Virtual Router MIB module July 2005 vrAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), testing(3), unknown(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the Virtual Router." DEFVAL { down } ::= { vrConfigEntry 7 } vrVpnId OBJECT-TYPE SYNTAX VPNId MAX-ACCESS read-create STATUS current DESCRIPTION "The Virtual Private Network Identifier of the Virtual Router." ::= { vrConfigEntry 8 } vrRpTrigger OBJECT-TYPE SYNTAX VrRpTriggerBitCode MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents Routing Protocol (RP) Triggers on a Virtual Router and it meant to be used to initiate or shutdown routing protocols on a VR. Multiple RPs can be acted on simultaneously. Also, individual RPs can be brought up in steps, which should not affect the RPs that were running. The BITS represent an Action-code that specifies what action is to be performed for the RPs. The actions are: initiate(1) or shutdown(0). The running status of an RP shall be available in the VR stats table's vrRpStatus, which has a similar format, but represents the status. Bits 0-3 may be specified in any combination. Individual routing protocols may be enabled and disabled independently. Protocols are enabled by setting the respective BIT and are disabled by resetting the BIT. So, for example, to enable RIP and BGP protocols the vrRpTrigger bits 0 and 2 need to be set, and as encoded as 10100000. All zeros should be interpreted as all protocols disable. " DEFVAL { '00000000'b } ::= { vrConfigEntry 9 } Layer-3 VPN Group Expires January 2006 [Page 14] Draft Virtual Router MIB module July 2005 vrMaxRoutesTrapEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This objects is used to enable the generation of the VR Max Routes Exceeded traps. true(1) - VR Max Routes Exceeded Traps Enabled false(2) - VR Max Routes Exceeded Traps Disabled" DEFVAL { true } ::= { vrConfigEntry 10 } vrStat OBJECT IDENTIFIER ::= { vrMIBObjects 2 } vrStatScalars OBJECT IDENTIFIER ::= { vrStat 1 } vrConfiguredVRs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRs configured on this network element." ::= { vrStatScalars 1 } vrActiveVRs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRs that are active on the network element. These are VRs for which the vrStatOperStatus = up(1)" ::= { vrStatScalars 2 } vrStatTable OBJECT-TYPE SYNTAX SEQUENCE OF VrStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains statistics for the Virtual Router." ::= { vrStat 2 } vrStatEntry OBJECT-TYPE SYNTAX VrStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table a per vrId." INDEX { vrId } ::= { vrStatTable 1 } Layer-3 VPN Group Expires January 2006 [Page 15] Draft Virtual Router MIB module July 2005 VrStatEntry ::= SEQUENCE { vrStatRouteEntries Unsigned32, vrStatFIBEntries Unsigned32, vrStatUpTime TimeTicks, vrOperStatus INTEGER, vrRpStatus VrRpTriggerBitCode, vrRouterAddressType InetAddressType, vrRouterAddress InetAddress } vrStatRouteEntries OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of routes for this VR." ::= { vrStatEntry 1 } vrStatFIBEntries OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of FIB Entries for this VR." ::= { vrStatEntry 2 } vrStatUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time in (in hundredths of a second) since this VR entry has been operational." ::= { vrStatEntry 3 } vrOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), unknown(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of the Virtual Router." ::= { vrStatEntry 4 } Layer-3 VPN Group Expires January 2006 [Page 16] Draft Virtual Router MIB module July 2005 vrRpStatus OBJECT-TYPE SYNTAX VrRpTriggerBitCode MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the status of Routing Protocols on this VR corresponding to the list of RP specified in vrRpTrigger. The BITS represent an Action-code that specifies the status of the RPs. The status are: initiated (1) or shutdown (0). Initiated status is indicated when the respective BIT value is 1 and indicates shutdown when the respective BIT value is 0. Bits 0-3 may appear in any combination to indicate that RPs may be enabled and disabled independently or that multiple RP are acted on simultaneously. " ::= { vrStatEntry 5 } vrRouterAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Router Address Type of this VR." ::= { vrStatEntry 6 } vrRouterAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Router Address of this VR. It is derived from one of the interfaces. If loopback interface is present, the loopback interface address can be used. However, loopback interface is optional." ::= { vrStatEntry 7 } vrIfConfig OBJECT IDENTIFIER ::= { vrMIBObjects 3 } vrIfConfigScalars OBJECT IDENTIFIER ::= { vrIfConfig 1 } vrIfConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF VrIfConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is for configuring VR Interfaces." ::= { vrIfConfig 2 } Layer-3 VPN Group Expires January 2006 [Page 17] Draft Virtual Router MIB module July 2005 vrIfConfigEntry OBJECT-TYPE SYNTAX VrIfConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table correspond to the entries in the ifTable that apply to the Virtual Router." INDEX { vrId, vrIfId } ::= { vrIfConfigTable 1 } VrIfConfigEntry ::= SEQUENCE { vrIfId InterfaceIndex, vrIfConfigRowStatus RowStatus } vrIfId OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Virtual Router Interface Index." ::= { vrIfConfigEntry 1 } vrIfConfigRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION " This object is used to create, delete or modify a row in this table." ::= { vrIfConfigEntry 2 } -- ******************************************************************* -- Module Traps/Notifications -- ******************************************************************* vrNotificationsPrefix OBJECT IDENTIFIER ::= { vrMIBObjects 4 } vrNotifications OBJECT IDENTIFIER ::= { vrNotificationsPrefix 0 } vrUp NOTIFICATION-TYPE OBJECTS { vrOperStatus } STATUS current DESCRIPTION "This notification is generated when the specified VR is about to be initialized or change the VR's operational status from down to up." ::= { vrNotifications 1 } Layer-3 VPN Group Expires January 2006 [Page 18] Draft Virtual Router MIB module July 2005 vrDown NOTIFICATION-TYPE OBJECTS { vrOperStatus } STATUS current DESCRIPTION "This notification is generated when the specified VR's operational status is about to go down." ::= { vrNotifications 2 } vrMaxRoutesExceeded NOTIFICATION-TYPE OBJECTS { vrRowStatus, vrMaxRoutes, vrStatRouteEntries } STATUS current DESCRIPTION "This notification is generated when the specified VR has exceeded the maximum number of routes specified. " ::= { vrNotifications 3 } -- ******************************************************************* -- Module Compliance/Conformance Statements -- ******************************************************************* vrConformance OBJECT IDENTIFIER ::= { virtualRouterMIB 2 } vrCompliances OBJECT IDENTIFIER ::= { vrConformance 1 } vrMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement the VIRTUAL-ROUTER-MIB. Implementation of this MIB module is strongly recommended for any platform targeted for a carrier-class environment. When this MIB module is implemented with support for read-create, then such an implementation can claim full compliance. Such devices can then be both monitored and configured with this MIB." MODULE -- this module MANDATORY-GROUPS { vrConfigGroup, vrStatGroup, vrIfGroup, vrNotificationGroup } ::= { vrCompliances 1 } vrGroups OBJECT IDENTIFIER ::= { vrConformance 2 } vrConfigGroup OBJECT-GROUP OBJECTS { vrRowStatus, vrName, vrContextName, vrTrapEnable, vrMaxRoutes, vrAdminStatus, vrVpnId, vrRpTrigger, vrMaxRoutesTrapEnable, vrConfigNextAvailableVrId } STATUS current DESCRIPTION "A collection of attributes that support provisioning of a virtual router." ::= { vrGroups 1 } Layer-3 VPN Group Expires January 2006 [Page 19] Draft Virtual Router MIB module July 2005 vrStatGroup OBJECT-GROUP OBJECTS { vrConfiguredVRs, vrActiveVRs, vrStatRouteEntries, vrStatFIBEntries, vrStatUpTime, vrOperStatus, vrRpStatus, vrRouterAddress, vrRouterAddressType } STATUS current DESCRIPTION "A collection of attributes that contain stats about the virtual router." ::= { vrGroups 2 } vrIfGroup OBJECT-GROUP OBJECTS { vrIfConfigRowStatus } STATUS current DESCRIPTION "A collection of attributes that support provisioning of a virtual router interfaces." ::= { vrGroups 3 } vrNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { vrUp, vrDown, vrMaxRoutesExceeded } STATUS current DESCRIPTION "A collection of traps that are supported by the VR." ::= { vrGroups 4 } END 7.0 Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. Special thanks to Joan Cucchiara for providing valuable comments on this MIB. 8.0 Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: Layer-3 VPN Group Expires January 2006 [Page 20] Draft Virtual Router MIB module July 2005 The Administrative VR provides visibility into and control over multiple VPNs. As such, security considerations for implementations of the Administrative VR and associated control plane(s) are critical to the security of the VPNs supported on each PE device. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: Use of any vrContextName MUST be allowed in the Administrative VR. Additional authentication and security mechanisms SHOULD be used for SNMP access in the Administrative VR. VRs other than the Administrative VR MUST NOT have access to other VR's Instantiated MIB modules, and MAY have access to their own instantiated MIB modules. In VRs other than the Administrative VR, access to that VR's instantiated MIB modules MAY be permitted via that VR's vrContextName. Use of any vrContextName other than that assigned to the accessed VR MUST result in an error, and implementations SHOULD provide a logging mechanism for such events. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Layer-3 VPN Group Expires January 2006 [Page 21] Draft Virtual Router MIB module July 2005 9.0 References 9.1 Normative References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [VPNTCMIB] B. Schliesser, and T. Nadeau, "Definition of Textual Conventions for Provider Provisioned Virtual Private Network (PPVPN) Management.", Internet Draft , May 2004. 9.2 Informative References [RFC2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [PPVPN-FW] R. Callon, et al., "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", draft-ietf-l3vpn-framework-00.txt, March 2003. [PPVPN-VR] P. Knight, et al., "Network based IP VPN Architecture using Virtual Routers", draft-ietf-l3vpn-vpn-vr-02.txt, April 2004. [PPVPN-VR-AS] A. Nagarajan, et al., "Applicability Statement for Virtual Router-based Layer 3 PPVPN approaches", draft-ietf-l3vpn-as-vr-01.txt, March 2004. Layer-3 VPN Group Expires January 2006 [Page 22] Draft Virtual Router MIB module July 2005 10.0 Authors' Addresses Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 USA Phone: +1-408-519-3832 Email: elwinietf@yahoo.com Samuel Hancock ACM Systems 3034 Gold Canal Drive Rancho Cordova, CA 94123 USA Phone: +1-916-463-7949 Email: hancoc_s@yahoo.com Benson Schliesser SAVVIS Communications 1 Savvis Parkway Town and Country, MO 63017 USA Phone: +1-314-628-7036 Email: bensons@savvis.net Joseph Laria Level Stream Research Wilmington, MA 01887 USA Phone: +1-978-223-9908 Email: jlaria@levelstream.com 11.0 Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Layer-3 VPN Group Expires January 2006 [Page 23] Draft Virtual Router MIB module July 2005 12.0 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13.0 IANA Considerations for L3VPN-VR-MIB Module The IANA is requested to assign { mib-2 XXXX } to the L3VPN-VR-MIB module specified in this document. Layer-3 VPN Group Expires January 2006 [Page 24] --0-802967879-1122311257=:36936-- From l3vpn-bounces@ietf.org Wed Jul 27 04:18:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxh7r-0007zR-8V; Wed, 27 Jul 2005 04:18:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxh7p-0007zJ-AM for l3vpn@megatron.ietf.org; Wed, 27 Jul 2005 04:18:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06827 for ; Wed, 27 Jul 2005 04:18:46 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxhd1-0003FB-0V for l3vpn@ietf.org; Wed, 27 Jul 2005 04:51:05 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 10:18:44 +0200 Received: from l-dhcp-5407-1.rd.francetelecom.fr ([10.193.15.72]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 10:18:44 +0200 From: Thomas Morin To: L3VPN Content-Type: multipart/mixed; boundary="=-/ZQOGMWDAOqk2f7OMQQ5" Organization: France Telecom R&D Date: Wed, 27 Jul 2005 10:18:56 +0200 Message-Id: <1122452337.19757.23.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 27 Jul 2005 08:18:44.0811 (UTC) FILETIME=[CE3889B0:01C59283] X-Spam-Score: 1.2 (+) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Subject: Multicast VPN Survey X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org --=-/ZQOGMWDAOqk2f7OMQQ5 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, Here is the Multicast VPN survey that we prepared to complement draft-ietf-l3vpn-ppvpn-mcast-reqts with relevant informations about scalability expectations and priorities. Please broadcast this survey to organizations and/or people that you know may be interested in the deployments of such solutions. Completed surveys sould be send, before September 15th, to Daniel King , who will anonymise the answers. Thank you very much, -Thomas Morin --=-/ZQOGMWDAOqk2f7OMQQ5 Content-Disposition: attachment; filename=IETF-L3VPN-Multicast-VPN-Survey.txt Content-Type: text/plain; name=IETF-L3VPN-Multicast-VPN-Survey.txt; charset=us-ascii Content-Transfer-Encoding: 7bit Multicast VPN Survey - July 2005 1. Presentation 1.1 Context and goal Current work in the l3vpn IETF Working group include the definition of requirements for Multicast in L3VPNs and the specifications of multicast VPN solutions. In this perspective, the authors of the requirement draft [draft-ietf-l3vpn-ppvpn-mcast-reqts] are initiating a survey to better detail requirements, and especially scalability requirements. A summary of the results of this survey will be included in the requirements document which should serve as guidelines for solution design. The scope of this survey is multicast in L3VPNs: the mechanisms setup by a VPN provider to carry customer multicast traffic of customers. 1.2 Answering this survey This survey will hopefuly be answered by ISPs planing to offer a multicast VPN service, and possibly by VPN customers having a need for such a service (not all questions of this survey will be relevant in that later case). If your are an ISP, the answers should relate not to what you'd expect today, but more to what you see as a longer term target for such a service. For scalability figures, please answer what you think you would need to support in the longer term. If you expect many significantly different deployments, it is possible to answer the survey multiple times. Please answer as much questions as possible, but feel free to ommit answers if the question aren't relevant for you. 1.3 Sending the results Once completed, we'd appreciate that you send the document to Daniel King , who will anonymize the survey results before forwarding them to the L3VPN WG multicast VPN requirement drafts authors. Please have completed surveys sent before September 15th, 2005. Thank you very much ! 2. Questions This survey is divided into three parts. The first one relates to quantitative questions that can be quickly answered by a simple figure (numbers of multicast PEs, of multicast VPNs,...), and the second one is made of qualitative questions regarding the expected use of the service (features, dynamicity, client application use case patterns...). In the last part you can express more in detail considerations you may have about multicast VPN deployments, including for instance specific use cases you think may highlight specific important points. 2.1 Quantitative questions Here, we are just expecting rough figures and orders of magnitude, such as: 20k, tens of thousands, hundreds, ~7500, O(10^2), etc. 2.1.1 Deployment and offer 1. Number of VPNs for which multicast is made available * total: ....... * per PE: ....... If inter-AS and/or inter-provider context is relevant for you: * per AS : ...... * per provider : ...... 2. CEs per VPN per PE, for which multicast is enabled: .......... 3. number of PEs per VPN with multicast enabled (source or receiver): .......... 4. number of PEs with multicast service enabled: .......... 2.1.2 Parameters related to customer applications and usage patterns 1. Number of PEs connected to multicast receivers: .......... 2. Number of PEs connected to multicast sources: .......... 3. Number of multicast (*,G) or (S,G) sourced ... * ...per VPN: .......... * ...per PE: .......... * ...per CE: .......... 2.2 Qualitative questions 2.2.1 Expected VPN customer applications 1. Type of multicast applications Mutlicast applications deployed over a multicast VPN can be differentiated depending on many criterias, such as, for instance: real-time or not, bandwidth, receiver-source structure (one-to-many, many-to-many, many-to-few...), sensitivity to packet loss, number of streams... Please give examples of some possible applications, in the following form : realtime or not / number of sources / number of receivers / bandwidth / packet-loss sensitive / streams per application For instance: real-time / few and known / many in unknown locations / tens of Mbps / loss sensitive / hundreds of streams a) ........ b) ........ c) ......... ... 2. Dynamics * Do you expect customer applications that are sensitive to multicast join/latency (time to receive/leave a stream) ? ........ * What kind of frequency do you expect for mcast routing changes, at the PE level ? (eg. "not more than XX leave and joins per hour") ........ * Predictability of sources and receivers locations: do you expect to be able, for each said multicast VPN customer, to have an a priori on the location of customer sources and/or receivers ? ........ 3. Customer side protocols: among the following, please chose which you'd expect to support at the CE-PE level (y/n) ? * PIM-SM: * PIM-SSM: * Bidir PIM: * IGMP(v2/v3): * MLDv2: * PIM-DM: 4. Would you plan to support multicast in a carrier's carrier context ? ........ 2.2.1 Network Considerations 1. Do you have PE for which reachability is less good than others (costly or scarce bandwidth) ? ........ 2. Do you think some VPNs of your customers may have same or close sets of PEs, and may thus possibly benefit from using the same PE-to-PE point to multipoint tunnels ? ........ 3. Do you plan to deploy multicast VPNs in a multi-AS context ? ........ 4. Do you plan to deploy multicast VPNs in a multi-provider context ? ........ 2.2.1 Relative Importance on different aspects Please rate the following items according to their relative importance - from 1 (Unimportant) to 5 (Important). * Seamless interoperability with the current unicast model: ... * Multicast VPN must not impose additional requirements on CE devices: ... * Re-use of existing multicast protocols for multcast traffic transport over the provider core network: ... * Support of TE features such as bandwidth reservation and admission control: ... * Provide the same level of security for both the customer and the SP as available with unicast VPNs: ... * Support for global Internet multicast (emission/reception): ... * Support for Extranet (having a VRF in more than one multicast VPN): ... 3. Specific considerations you may want to express ........... --=-/ZQOGMWDAOqk2f7OMQQ5-- From l3vpn-bounces@ietf.org Thu Jul 28 00:46:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy0Hf-0003T6-H3; Thu, 28 Jul 2005 00:46:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy0Hd-0003T1-TQ for l3vpn@megatron.ietf.org; Thu, 28 Jul 2005 00:46:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03372 for ; Thu, 28 Jul 2005 00:46:10 -0400 (EDT) Received: from web25304.mail.ukl.yahoo.com ([217.12.10.76]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dy0mw-0006oJ-0e for l3vpn@ietf.org; Thu, 28 Jul 2005 01:18:40 -0400 Received: (qmail 86024 invoked by uid 60001); 28 Jul 2005 04:45:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZkSeT0AjyWidqnGpt53Rl4MlFz09/7cPhgCaBpPKNjieRp0/w28aJ6uw80fPNRTiyw9eqltp5bHIAGVc/9uZtwRjKunNAIryqzfvtjB5Q2JV+Y6jrUs1FkzDNTT/eiW6v3OUjir9Yy8jejx/nQapozfrKtYHlk8qppbbclVd6Y4= ; Message-ID: <20050728044547.86020.qmail@web25304.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25304.mail.ukl.yahoo.com via HTTP; Thu, 28 Jul 2005 05:45:47 BST Date: Thu, 28 Jul 2005 05:45:47 +0100 (BST) From: John Smith To: l3vpn@ietf.org, raszuk@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 8bit Cc: Subject: Doubt in draft-ietf-l3vpn-rfc2547bis-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Hi, I was going through draft-ietf-l3vpn-rfc2547bis-03.txt and there is a point thats not clear to me. It says that the route origin ext community is used "to uniquely identify the set of routes learned from a particular site". However, what isnt clear to me from reading this is whether a route can have multiple instances of this community? Is it possible for a route to carry soo:1:1 and soo:2:2. If yes, then should this route be advertised to a BGP CE peer if that peer is associated with soo:1:1 Similarly, this route would also not be announced to a BGP peer associated with the following SOOs: soo:2:2 and soo:1:1 and soo:2:2 This raises another question. What if a site is associated with SOO soo:1:1 and soo:2:2 and a MPBGP peer recieves a route with soo:1:1. In this case, should the route be advertised or not? Thanks, John ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com From l3vpn-bounces@ietf.org Thu Jul 28 05:20:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy4Yl-000499-Iv; Thu, 28 Jul 2005 05:20:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy4YT-00042l-76 for l3vpn@megatron.ietf.org; Thu, 28 Jul 2005 05:19:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08734 for ; Thu, 28 Jul 2005 05:19:50 -0400 (EDT) Received: from web26708.mail.ukl.yahoo.com ([217.146.176.71]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dy53t-0005oa-2A for l3vpn@ietf.org; Thu, 28 Jul 2005 05:52:22 -0400 Received: (qmail 21286 invoked by uid 60001); 28 Jul 2005 09:19:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lNmbTdEWy03bgakJCQy/PzhG/0BHxaIIbzfy3DjNodYlWdimqm/T++WJXLsUN8futylmggNni6oVJswjZxUtekEzsOAX37uiUBbHrL+CGHOqSfAty2rK8TU/vCp9yS9zeYOdZMhm6B7akiZ/6U1DPw9XC0WrU8LJVxndNamH6hY= ; Message-ID: <20050728091936.21284.qmail@web26708.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web26708.mail.ukl.yahoo.com via HTTP; Thu, 28 Jul 2005 10:19:36 BST Date: Thu, 28 Jul 2005 10:19:36 +0100 (BST) From: Spice Sylvia To: John Smith , l3vpn@ietf.org In-Reply-To: <20050728044547.86020.qmail@web25304.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 8bit Cc: Subject: Re: Doubt in draft-ietf-l3vpn-rfc2547bis-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Can a site be associated with 2 SOOs? --- John Smith wrote: > Hi, > > I was going through > draft-ietf-l3vpn-rfc2547bis-03.txt and there is a > point thats not > clear to me. > > It says that the route origin ext community is used > "to uniquely identify the set of > routes learned from a particular site". > > However, what isnt clear to me from reading this is > whether a route can have multiple > instances of this community? Is it possible for a > route to carry soo:1:1 and soo:2:2. > > If yes, then should this route be advertised to a > BGP CE peer if that peer is associated > with soo:1:1 > > Similarly, this route would also not be announced to > a BGP peer associated with the > following SOOs: > > soo:2:2 > and soo:1:1 and soo:2:2 > > This raises another question. What if a site is > associated with SOO soo:1:1 and soo:2:2 > and a MPBGP peer recieves a route with soo:1:1. > > In this case, should the route be advertised or not? > > Thanks, > John > > > > ___________________________________________________________ > > How much free photo storage do you get? Store your > holiday > snaps for FREE with Yahoo! Photos > http://uk.photos.yahoo.com > > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Thu Jul 28 05:49:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy517-0003Z0-52; Thu, 28 Jul 2005 05:49:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy515-0003Yp-4E for l3vpn@megatron.ietf.org; Thu, 28 Jul 2005 05:49:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10906 for ; Thu, 28 Jul 2005 05:49:24 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy5WV-0006qP-Dq for l3vpn@ietf.org; Thu, 28 Jul 2005 06:21:56 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 28 Jul 2005 11:49:16 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6S9n0Ds006126; Thu, 28 Jul 2005 11:49:13 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 11:49:11 +0200 Received: from [10.10.10.52] ([10.25.90.226]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Jul 2005 11:49:10 +0200 Message-ID: <42E8AA10.4050108@cisco.com> Date: Thu, 28 Jul 2005 02:49:04 -0700 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Smith References: <20050728044547.86020.qmail@web25304.mail.ukl.yahoo.com> In-Reply-To: <20050728044547.86020.qmail@web25304.mail.ukl.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2005 09:49:10.0973 (UTC) FILETIME=[9AE0E6D0:01C59359] X-Spam-Score: 0.7 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: Doubt in draft-ietf-l3vpn-rfc2547bis-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org John, In my opinion the logical AND should be used when checking SOO value and as soon as at least one match is found the route should not be allowed back to the site. Cheers, R. > Hi, > > I was going through draft-ietf-l3vpn-rfc2547bis-03.txt and there is a point thats not > clear to me. > > It says that the route origin ext community is used "to uniquely identify the set of > routes learned from a particular site". > > However, what isnt clear to me from reading this is whether a route can have multiple > instances of this community? Is it possible for a route to carry soo:1:1 and soo:2:2. > > If yes, then should this route be advertised to a BGP CE peer if that peer is associated > with soo:1:1 > > Similarly, this route would also not be announced to a BGP peer associated with the > following SOOs: > > soo:2:2 > and soo:1:1 and soo:2:2 > > This raises another question. What if a site is associated with SOO soo:1:1 and soo:2:2 > and a MPBGP peer recieves a route with soo:1:1. > > In this case, should the route be advertised or not? > > Thanks, > John > > > > ___________________________________________________________ > How much free photo storage do you get? Store your holiday > snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com > From l3vpn-bounces@ietf.org Thu Jul 28 08:04:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy77L-0002P2-VI; Thu, 28 Jul 2005 08:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy77K-0002OH-G6 for l3vpn@megatron.ietf.org; Thu, 28 Jul 2005 08:04:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19681 for ; Thu, 28 Jul 2005 08:04:01 -0400 (EDT) Received: from web25307.mail.ukl.yahoo.com ([217.12.10.79]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dy7cl-0002cz-PV for l3vpn@ietf.org; Thu, 28 Jul 2005 08:36:33 -0400 Received: (qmail 47799 invoked by uid 60001); 28 Jul 2005 12:03:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Iuvf68S7XExi9nibczNOgR7fm5ghfWkQlf8gTnHKBFYyuP50OGlhvf69RRlzIUhchz464OYuRKCXvE0aUfkUJVGTBYhrNAgZHRXQATvhW0XcCDLa0SGO0btKze6wOL05QZe8+CEmn3C2i+bldgpWzea4E/mT8+PLdI/MTLn4OAQ= ; Message-ID: <20050728120351.47797.qmail@web25307.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25307.mail.ukl.yahoo.com via HTTP; Thu, 28 Jul 2005 13:03:51 BST Date: Thu, 28 Jul 2005 13:03:51 +0100 (BST) From: John Smith To: raszuk@cisco.com, l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 8bit Cc: Subject: Re: Doubt in draft-ietf-l3vpn-rfc2547bis-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org And just another doubt! I have set an incoming routemap for a VRF where i set a SOO and/or some other extended communities. Now, i redistribute some static routes and some connected routes. Now, these routes have "technically" not been learnt through a BGP peer. SHould I in such cases, also attach these extended communities (SOO, etc). I do this for the routes that i learn from a BGP peer. Am i required to do the same for the redistributed routes, etc? Thanks, John ----- Original Message ----- From: "Robert Raszuk" To: "John Smith" Cc: Sent: Thursday, July 28, 2005 3:19 PM Subject: Re: Doubt in draft-ietf-l3vpn-rfc2547bis-03.txt > John, > > In my opinion the logical AND should be used when checking SOO value and > as soon as at least one match is found the route should not be allowed > back to the site. > > Cheers, > R. > >> Hi, >> >> I was going through draft-ietf-l3vpn-rfc2547bis-03.txt and there is a point thats not >> clear to me. >> >> It says that the route origin ext community is used "to uniquely identify the set of >> routes learned from a particular site". >> >> However, what isnt clear to me from reading this is whether a route can have multiple >> instances of this community? Is it possible for a route to carry soo:1:1 and soo:2:2. >> >> If yes, then should this route be advertised to a BGP CE peer if that peer is associated >> with soo:1:1 >> >> Similarly, this route would also not be announced to a BGP peer associated with the >> following SOOs: >> >> soo:2:2 >> and soo:1:1 and soo:2:2 >> >> This raises another question. What if a site is associated with SOO soo:1:1 and soo:2:2 >> and a MPBGP peer recieves a route with soo:1:1. >> >> In this case, should the route be advertised or not? >> >> Thanks, >> John >> >> >> >> ___________________________________________________________ >> How much free photo storage do you get? Store your holiday >> snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com >> > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Thu Jul 28 10:50:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy9iJ-0002ul-NR; Thu, 28 Jul 2005 10:50:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy9iH-0002ri-OI for l3vpn@megatron.ietf.org; Thu, 28 Jul 2005 10:50:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02930 for ; Thu, 28 Jul 2005 10:50:19 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyADk-0007su-Li for l3vpn@ietf.org; Thu, 28 Jul 2005 11:22:54 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 28 Jul 2005 16:50:11 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6SEnTEE029756; Thu, 28 Jul 2005 16:50:08 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 16:50:07 +0200 Received: from [10.10.10.52] ([10.61.160.138]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Jul 2005 16:50:07 +0200 Message-ID: <42E8F09D.3040600@cisco.com> Date: Thu, 28 Jul 2005 07:50:05 -0700 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Smith References: <20050728120351.47797.qmail@web25307.mail.ukl.yahoo.com> In-Reply-To: <20050728120351.47797.qmail@web25307.mail.ukl.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2005 14:50:07.0220 (UTC) FILETIME=[A53D8B40:01C59383] X-Spam-Score: 1.7 (+) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: Doubt in draft-ietf-l3vpn-rfc2547bis-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org John, I don't think SOO needs to be applied for static & connected routes. R. > And just another doubt! > > I have set an incoming routemap for a VRF where i set a SOO and/or some other extended > communities. Now, i redistribute some static routes and some connected routes. Now, these > routes have "technically" not been learnt through a BGP peer. SHould I in such cases, > also attach these extended communities (SOO, etc). > > I do this for the routes that i learn from a BGP peer. Am i required to do the same for > the redistributed routes, etc? > > Thanks, > John > > ----- Original Message ----- > From: "Robert Raszuk" > To: "John Smith" > Cc: > Sent: Thursday, July 28, 2005 3:19 PM > Subject: Re: Doubt in draft-ietf-l3vpn-rfc2547bis-03.txt > > > >>John, >> >>In my opinion the logical AND should be used when checking SOO value and >>as soon as at least one match is found the route should not be allowed >>back to the site. >> >>Cheers, >>R. >> >> >>>Hi, >>> >>>I was going through draft-ietf-l3vpn-rfc2547bis-03.txt and there is a point thats not >>>clear to me. >>> >>>It says that the route origin ext community is used "to uniquely identify the set of >>>routes learned from a particular site". >>> >>>However, what isnt clear to me from reading this is whether a route can have multiple >>>instances of this community? Is it possible for a route to carry soo:1:1 and soo:2:2. >>> >>>If yes, then should this route be advertised to a BGP CE peer if that peer is > > associated > >>>with soo:1:1 >>> >>>Similarly, this route would also not be announced to a BGP peer associated with the >>>following SOOs: >>> >>>soo:2:2 >>>and soo:1:1 and soo:2:2 >>> >>>This raises another question. What if a site is associated with SOO soo:1:1 and > > soo:2:2 > >>>and a MPBGP peer recieves a route with soo:1:1. >>> >>>In this case, should the route be advertised or not? >>> >>>Thanks, >>>John >>> >>> >>> >>>___________________________________________________________ >>>How much free photo storage do you get? Store your holiday >>>snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com >>> >> > > > > > > ___________________________________________________________ > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com > From l3vpn-bounces@ietf.org Thu Jul 28 11:01:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy9sb-0006TW-FF; Thu, 28 Jul 2005 11:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy9sZ-0006RO-W7 for l3vpn@megatron.ietf.org; Thu, 28 Jul 2005 11:01:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03726 for ; Thu, 28 Jul 2005 11:00:57 -0400 (EDT) Received: from web25303.mail.ukl.yahoo.com ([217.12.10.75]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DyAO2-0008Cw-Ue for l3vpn@ietf.org; Thu, 28 Jul 2005 11:33:32 -0400 Received: (qmail 79606 invoked by uid 60001); 28 Jul 2005 15:00:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zSMtwUNVmfd9Ld5Q9EOAxR17Oc5W0lqldk3r+WEiOBwKgPTUphsmwg1G6bze5n4UvedpuI95PFwlGmvdftofIrP13t9ZX2zYkF9T5xEZf6L/L6LyMYPJabv852qBJBQ/rGQMz6GZZGlLGx2JHuTBuhTFkW8GS2C9JooLJux5mOg= ; Message-ID: <20050728150045.79599.qmail@web25303.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25303.mail.ukl.yahoo.com via HTTP; Thu, 28 Jul 2005 16:00:37 BST Date: Thu, 28 Jul 2005 16:00:37 +0100 (BST) From: John Smith To: raszuk@cisco.com, l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 8bit Cc: Subject: Re: Doubt in draft-ietf-l3vpn-rfc2547bis-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org As always, you've been of great help. Thanks, John ----- Original Message ----- From: "Robert Raszuk" To: "John Smith" Cc: Sent: Thursday, July 28, 2005 8:20 PM Subject: Re: Doubt in draft-ietf-l3vpn-rfc2547bis-03.txt > John, > > I don't think SOO needs to be applied for static & connected routes. > > R. > >> And just another doubt! >> >> I have set an incoming routemap for a VRF where i set a SOO and/or some other extended >> communities. Now, i redistribute some static routes and some connected routes. Now, these >> routes have "technically" not been learnt through a BGP peer. SHould I in such cases, >> also attach these extended communities (SOO, etc). >> >> I do this for the routes that i learn from a BGP peer. Am i required to do the same for >> the redistributed routes, etc? >> >> Thanks, >> John >> >> ----- Original Message ----- >> From: "Robert Raszuk" >> To: "John Smith" >> Cc: >> Sent: Thursday, July 28, 2005 3:19 PM >> Subject: Re: Doubt in draft-ietf-l3vpn-rfc2547bis-03.txt >> >> >> >>>John, >>> >>>In my opinion the logical AND should be used when checking SOO value and >>>as soon as at least one match is found the route should not be allowed >>>back to the site. >>> >>>Cheers, >>>R. >>> >>> >>>>Hi, >>>> >>>>I was going through draft-ietf-l3vpn-rfc2547bis-03.txt and there is a point thats not >>>>clear to me. >>>> >>>>It says that the route origin ext community is used "to uniquely identify the set of >>>>routes learned from a particular site". >>>> >>>>However, what isnt clear to me from reading this is whether a route can have multiple >>>>instances of this community? Is it possible for a route to carry soo:1:1 and soo:2:2. >>>> >>>>If yes, then should this route be advertised to a BGP CE peer if that peer is >> >> associated >> >>>>with soo:1:1 >>>> >>>>Similarly, this route would also not be announced to a BGP peer associated with the >>>>following SOOs: >>>> >>>>soo:2:2 >>>>and soo:1:1 and soo:2:2 >>>> >>>>This raises another question. What if a site is associated with SOO soo:1:1 and >> >> soo:2:2 >> >>>>and a MPBGP peer recieves a route with soo:1:1. >>>> >>>>In this case, should the route be advertised or not? >>>> >>>>Thanks, >>>>John >>>> >>>> >>>> >>>>___________________________________________________________ >>>>How much free photo storage do you get? Store your holiday >>>>snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com >>>> >>> >> >> >> >> >> >> ___________________________________________________________ >> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com >> ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Fri Jul 29 15:18:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyaNY-00055b-3a; Fri, 29 Jul 2005 15:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyaNW-00052S-5q for l3vpn@megatron.ietf.org; Fri, 29 Jul 2005 15:18:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02261 for ; Fri, 29 Jul 2005 15:18:39 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyatE-000315-Vq for l3vpn@ietf.org; Fri, 29 Jul 2005 15:51:29 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2005 12:18:32 -0700 X-IronPort-AV: i="3.95,153,1120460400"; d="scan'208"; a="651910346:sNHT38043226" Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6TJIQul022788 for ; Fri, 29 Jul 2005 12:18:26 -0700 (PDT) Received: from cisco.com (dhcp-hrn-64-100-233-141.cisco.com [64.100.233.141]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA02798 for ; Fri, 29 Jul 2005 12:18:32 -0700 (PDT) Message-ID: <42EA8107.1010104@cisco.com> Date: Fri, 29 Jul 2005 15:18:31 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org In reviewing draft-ietf-l3vpn-gre-ip-2547-04.txt, I noted the following that requires some clarification: >4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE > > The following description is not meant to specify an implementation > strategy; any implementation procedure which produces the same result > is acceptable. > > When an ingress PE router receives a packet from a CE router, it > looks up the packet's destination IP address in a VRF that is > associated with packet's ingress attachment circuit. This enables > the (ingress) PE router to find a VPN-IP route. The VPN-IP route > will have an associated VPN route label and an associated BGP Next > Hop. The label is pushed on the packet. Then an IP (or IP+GRE) > encapsulation header is prepended to the packet, creating an > MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. It appears that the ingress PE can choose to use MPLS-in-IP or MPLS-in- GRE implying that the egress MUST be able to perform both forms of decapsulation. If the egress PE can only perform one form of decapsulation, how does the ingress PE determine which form of encapsulation is preferred or required? The IP source > address field of the encapsulation header will be an address of the > ingress PE router itself. The IP destination address field of the > encapsulation header will contain the value of the associated BGP > Next Hop; this will be an IP address of the egress PE router. QoS > information can be copied from the VPN packet to the GRE/IP tunnel > header so that required forwarding behaviors can be maintained at > each hop along the forwarding path. > The effect is to dynamically create an IP (or GRE) tunnel between the > ingress and egress PE routers. Presumably, the ingress PE and/or egress PE are also capable of forwarding packets via label switched paths (either between themselves or to other PE's or ASBR's). In a mixed environment, its conceivable that two PE's could only communicate via GRE or IP while a third could use an LSP to the one or the other PE. What means does the ingress PE use to determine that the LSP should be used verses the GRE or IP encap? > No apriori configuration of the > remote tunnel endpoints is needed. Note that these tunnels SHOULD > NOT be IGP-visible links, and routing adjacencies SHOULD NOT be > supported across these tunnel. Note also that the set of remote > tunnel endpoints is not known in advance, but is learned dynamically > via the BGP distribution of VPN-IP routes. The IP address of the > remote tunnel endpoints is carried in the Network Address of the Next > Hop field of the MP_REACH_NLRI BGP attribute [4] This model assumes that the Network Address of the Next Hop field is the destination tunnel address. This may or may not be true. The provider may in fact want the externally accessible tunnel address to be distinct from the Next Hop address for a variety of reasons including security, transitive tunnels, etc. How does the egress PE indicate to the ingress PE that the tunnel should NOT be built to the Next Hop address, but to a designated tunnel address assigned on the egress PE? Likewise, how does an ASBR determine that traffic to prefixes to a peer ASBR should not be tunneled while prefixes to a peer PE should be tunneled. Seems that some form of signaling is required which is not defined in this draft. Scott Wainner Message: 1 Date: Fri, 22 Jul 2005 17:31:30 -0700 (PDT) From: Rick Wilder Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt. To: l3vpn@ietf.org Message-ID: <20050723003130.30954.qmail@web308.biz.mail.mud.yahoo.com> Content-Type: text/plain; charset="iso-8859-1" L3VPN participants, This begins a two-week last call for comments on draft-ietf-l3vpn-gre-ip-2547-04.txt. Rick From l3vpn-bounces@ietf.org Fri Jul 29 16:22:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybNY-0007Mr-25; Fri, 29 Jul 2005 16:22:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybNW-0007LF-0L for l3vpn@megatron.ietf.org; Fri, 29 Jul 2005 16:22:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06998 for ; Fri, 29 Jul 2005 16:22:43 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DybtB-0004p6-U3 for l3vpn@ietf.org; Fri, 29 Jul 2005 16:55:33 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2005 22:22:32 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6TKMSDg015190; Fri, 29 Jul 2005 22:22:28 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 22:22:27 +0200 Received: from [10.10.10.52] ([10.25.90.226]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 22:22:23 +0200 Message-ID: <42EA8FF9.6020708@cisco.com> Date: Fri, 29 Jul 2005 13:22:17 -0700 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Wainner References: <42EA8107.1010104@cisco.com> In-Reply-To: <42EA8107.1010104@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2005 20:22:24.0370 (UTC) FILETIME=[3B1EF520:01C5947B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-gre-ip-2547-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Scott, The question is valid and the automated solution to the problem has been proposed many times :) Just for the reference please look at the below draft: http://community.roxen.com/developers/idocs/drafts/draft-raggarwa-ppvpn-tunnel-encap-sig-01.html Before we finalize the automated way the provisioning tools are responsible for selecting the encapsulation of choice. Cheers, R. > In reviewing draft-ietf-l3vpn-gre-ip-2547-04.txt, I noted the following > that requires some clarification: > >> 4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE >> >> The following description is not meant to specify an implementation >> strategy; any implementation procedure which produces the same result >> is acceptable. >> >> When an ingress PE router receives a packet from a CE router, it >> looks up the packet's destination IP address in a VRF that is >> associated with packet's ingress attachment circuit. This enables >> the (ingress) PE router to find a VPN-IP route. The VPN-IP route >> will have an associated VPN route label and an associated BGP Next >> Hop. The label is pushed on the packet. Then an IP (or IP+GRE) >> encapsulation header is prepended to the packet, creating an >> MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. > > > It appears that the ingress PE can choose to use MPLS-in-IP or MPLS-in- > GRE implying that the egress MUST be able to perform both forms of > decapsulation. If the egress PE can only perform one form of > decapsulation, > how does the ingress PE determine which form of encapsulation is preferred > or required? > > The IP source > >> address field of the encapsulation header will be an address of the >> ingress PE router itself. The IP destination address field of the >> encapsulation header will contain the value of the associated BGP >> Next Hop; this will be an IP address of the egress PE router. QoS >> information can be copied from the VPN packet to the GRE/IP tunnel >> header so that required forwarding behaviors can be maintained at >> each hop along the forwarding path. > > >> The effect is to dynamically create an IP (or GRE) tunnel between the >> ingress and egress PE routers. > > > Presumably, the ingress PE and/or egress PE are also capable of forwarding > packets via label switched paths (either between themselves or to other > PE's or ASBR's). In a mixed environment, its conceivable that two PE's > could only communicate via GRE or IP while a third could use an LSP to the > one or the other PE. What means does the ingress PE use to determine > that the LSP should be used verses the GRE or IP encap? > >> No apriori configuration of the >> remote tunnel endpoints is needed. Note that these tunnels SHOULD >> NOT be IGP-visible links, and routing adjacencies SHOULD NOT be >> supported across these tunnel. Note also that the set of remote >> tunnel endpoints is not known in advance, but is learned dynamically >> via the BGP distribution of VPN-IP routes. The IP address of the >> remote tunnel endpoints is carried in the Network Address of the Next >> Hop field of the MP_REACH_NLRI BGP attribute [4] > > > This model assumes that the Network Address of the Next Hop field is the > destination tunnel address. This may or may not be true. The provider > may in fact want the externally accessible tunnel address to be distinct > from the Next Hop address for a variety of reasons including security, > transitive tunnels, etc. How does the egress PE indicate to the ingress > PE that the tunnel should NOT be built to the Next Hop address, but to > a designated tunnel address assigned on the egress PE? Likewise, how > does an ASBR determine that traffic to prefixes to a peer ASBR should > not be tunneled while prefixes to a peer PE should be tunneled. > > Seems that some form of signaling is required which is not defined in this > draft. > > Scott Wainner > > > > Message: 1 > Date: Fri, 22 Jul 2005 17:31:30 -0700 (PDT) > From: Rick Wilder > Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt. > To: l3vpn@ietf.org > Message-ID: <20050723003130.30954.qmail@web308.biz.mail.mud.yahoo.com> > Content-Type: text/plain; charset="iso-8859-1" > > L3VPN participants, > > > This begins a two-week last call for comments on > draft-ietf-l3vpn-gre-ip-2547-04.txt. > > Rick > > > From l3vpn-bounces@ietf.org Fri Jul 29 16:43:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dybhe-0003lp-71; Fri, 29 Jul 2005 16:43:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dybhc-0003lk-7Y for l3vpn@megatron.ietf.org; Fri, 29 Jul 2005 16:43:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08177 for ; Fri, 29 Jul 2005 16:43:29 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DycDK-0005Jl-Lp for l3vpn@ietf.org; Fri, 29 Jul 2005 17:16:20 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2005 13:43:22 -0700 Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6TKhLJL029982; Fri, 29 Jul 2005 13:43:21 -0700 (PDT) Received: from cisco.com (dhcp-hrn-64-100-233-141.cisco.com [64.100.233.141]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA13175; Fri, 29 Jul 2005 13:43:20 -0700 (PDT) Message-ID: <42EA94E7.30103@cisco.com> Date: Fri, 29 Jul 2005 16:43:19 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: raszuk@cisco.com References: <42EA8107.1010104@cisco.com> <42EA8FF9.6020708@cisco.com> In-Reply-To: <42EA8FF9.6020708@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-gre-ip-2547-04.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org Robert Raszuk wrote: > Scott, > > The question is valid and the automated solution to the problem has > been proposed many times :) > > Just for the reference please look at the below draft: > > http://community.roxen.com/developers/idocs/drafts/draft-raggarwa-ppvpn-tunnel-encap-sig-01.html or alternatively .. http://www.ietf.org/internet-drafts/draft-nalawade-kapoor-tunnel-safi-03.txt Nevertheless, something must be signaled by the egress PE. > > > Before we finalize the automated way the provisioning tools are > responsible for selecting the encapsulation of choice. Certainly, a provisioning tool could specify the use of GRE, IP, or LSP encap; however, it would have to be done on a per peer basis. In addition, a distinct tunnel end-point cannot be distinguished from the Next Hop address without reverting back to statically configuring IP tunnel end-points. Seems these requirements defeat the purpose of the draft. Scott > > > Cheers, > R. > > > >> In reviewing draft-ietf-l3vpn-gre-ip-2547-04.txt, I noted the >> following that requires some clarification: >> >>> 4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE >>> >>> The following description is not meant to specify an implementation >>> strategy; any implementation procedure which produces the same result >>> is acceptable. >>> >>> When an ingress PE router receives a packet from a CE router, it >>> looks up the packet's destination IP address in a VRF that is >>> associated with packet's ingress attachment circuit. This enables >>> the (ingress) PE router to find a VPN-IP route. The VPN-IP route >>> will have an associated VPN route label and an associated BGP Next >>> Hop. The label is pushed on the packet. Then an IP (or IP+GRE) >>> encapsulation header is prepended to the packet, creating an >>> MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. >> >> >> >> It appears that the ingress PE can choose to use MPLS-in-IP or MPLS-in- >> GRE implying that the egress MUST be able to perform both forms of >> decapsulation. If the egress PE can only perform one form of >> decapsulation, >> how does the ingress PE determine which form of encapsulation is >> preferred >> or required? >> >> The IP source >> >>> address field of the encapsulation header will be an address of the >>> ingress PE router itself. The IP destination address field of the >>> encapsulation header will contain the value of the associated BGP >>> Next Hop; this will be an IP address of the egress PE router. QoS >>> information can be copied from the VPN packet to the GRE/IP tunnel >>> header so that required forwarding behaviors can be maintained at >>> each hop along the forwarding path. >> >> >> >>> The effect is to dynamically create an IP (or GRE) tunnel between the >>> ingress and egress PE routers. >> >> >> >> Presumably, the ingress PE and/or egress PE are also capable of >> forwarding >> packets via label switched paths (either between themselves or to other >> PE's or ASBR's). In a mixed environment, its conceivable that two PE's >> could only communicate via GRE or IP while a third could use an LSP >> to the >> one or the other PE. What means does the ingress PE use to determine >> that the LSP should be used verses the GRE or IP encap? >> >>> No apriori configuration of the >>> remote tunnel endpoints is needed. Note that these tunnels SHOULD >>> NOT be IGP-visible links, and routing adjacencies SHOULD NOT be >>> supported across these tunnel. Note also that the set of remote >>> tunnel endpoints is not known in advance, but is learned dynamically >>> via the BGP distribution of VPN-IP routes. The IP address of the >>> remote tunnel endpoints is carried in the Network Address of the Next >>> Hop field of the MP_REACH_NLRI BGP attribute [4] >> >> >> >> This model assumes that the Network Address of the Next Hop field is the >> destination tunnel address. This may or may not be true. The provider >> may in fact want the externally accessible tunnel address to be distinct >> from the Next Hop address for a variety of reasons including security, >> transitive tunnels, etc. How does the egress PE indicate to the ingress >> PE that the tunnel should NOT be built to the Next Hop address, but to >> a designated tunnel address assigned on the egress PE? Likewise, how >> does an ASBR determine that traffic to prefixes to a peer ASBR should >> not be tunneled while prefixes to a peer PE should be tunneled. >> >> Seems that some form of signaling is required which is not defined in >> this >> draft. >> >> Scott Wainner >> >> >> >> Message: 1 >> Date: Fri, 22 Jul 2005 17:31:30 -0700 (PDT) >> From: Rick Wilder >> Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt. >> To: l3vpn@ietf.org >> Message-ID: <20050723003130.30954.qmail@web308.biz.mail.mud.yahoo.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> L3VPN participants, >> >> >> This begins a two-week last call for comments on >> draft-ietf-l3vpn-gre-ip-2547-04.txt. >> >> Rick >> >> >> > >