Moving forward on VR draft

From l3vpn-bounces@ietf.org Mon Nov 1 12:07:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04328 for ; Mon, 1 Nov 2004 12:07:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COftN-0004TR-RR for l3vpn-web-archive@ietf.org; Mon, 01 Nov 2004 12:22:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfME-00006n-3c; Mon, 01 Nov 2004 11:48:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COezi-0003Tf-7N for l3vpn@megatron.ietf.org; Mon, 01 Nov 2004 11:25:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28402 for ; Mon, 1 Nov 2004 11:25:20 -0500 (EST) Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfEb-0002vw-0B for l3vpn@ietf.org; Mon, 01 Nov 2004 11:40:48 -0500 Received: from g9jbq.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for l3vpn@ietf.org; Mon, 1 Nov 2004 17:24:33 +0100 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Nov 2004 17:24:32 +0100 Message-Id: From: "Leymann, Nicolai" To: l3vpn@ietf.org Date: Mon, 1 Nov 2004 17:24:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Leymann, Nicolai" Subject: Multicast in L3 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Dear all, As mentioned earlier on the list we are currently looking into deployment scenarios for IP-Multicast in VPN environments, with the main focus on a single provider implementation (up til now no multidomain multicast VPNs spanning several ISPs). Our main scenario at the moment consists of only a small number of VPNs - something in the range between one and five - and a limited number of sites per mVPN as well (about 15-20). This is a rather small deployment scenario where most of the problems which are described later do not occur. In order to fulfil our basic requirements (which means: we do need a solution which we can use and deploy within the next few weeks/month) draft-rosen-vpn-mcast-06.txt is the only possibility which is available now. This draft provides a solution for a limited deployment of IP-Multicast in L3 VPNs and also provides some interoperability between different vendors. In our case draft-rosen-vpn-mcast-06.txt works; PIM-SM as routing protocol in the core is fine. I noticed that there was a long discussion about supporting PIM-SSM as a core routing protocol. I think there are two different aspects which has to be considered. One is related to the number of multicast states in the core and the other to the addressing mechanisms. >From the operational point of view the handling of multicast addresses can be quite painful (e.g. if you have multicast traffic in the core which is not related to mVPN). Hence the use of PIM-SSM as a core routing protocol can be useful even if the number of states rises. PIM-SSM removes the risk of address collisions. This results in a more stable core and eases the address management. The general problem I see is the limited scalability of the current solutions and the fact, that MPLS transport is not supported. The scaling problems do occur in several different domains depending of the amount of traffic, number of mVPNs and number of sites per mVPN. If multi-provider scenarios are also taken into account scaling (and/or addressing) gets worse. For mid-term deployment the goal should be a interoperable and scalable solution which enables the use of MPLS features like TE and the transport of IP-Multicast over MPLS (no GRE/Multicast encapsulation/routing in the provider core). Replication in the core should be done as late as possible (no ingress replication), therefor the support of point to multipoint LSPs should be preferred. It is also important, that there is agreement on one solution which is supported by several vendors. best regards Nic -- Nicolai Leymann EMail: nicolai.leymann@t-systems.com T-Systems System Integration, Berlin Tel/Fax: ++49-30-3497-3570/-3571 ET52 Mobil: ++49-170-2275345 Senior Experte IP-Technologien Goslarer Ufer 35, 10589 Berlin, Germany From l3vpn-bounces@ietf.org Thu Nov 4 09:43:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25748 for ; Thu, 4 Nov 2004 09:43:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPj5O-0005rW-HV for l3vpn-web-archive@ietf.org; Thu, 04 Nov 2004 09:59:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPioC-0006QR-46; Thu, 04 Nov 2004 09:41:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPiWX-0003HD-60 for l3vpn@megatron.ietf.org; Thu, 04 Nov 2004 09:23:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24078 for ; Thu, 4 Nov 2004 09:23:35 -0500 (EST) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPim4-0005KG-T1 for l3vpn@ietf.org; Thu, 04 Nov 2004 09:39:41 -0500 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 04 Nov 2004 06:23:05 -0800 X-BrightmailFiltered: true X-Ironport-AV: i="3.86,120,1096873200"; d="scan'208"; a="31725965:sNHT41451482" Received: from proton.jnpr.net ([10.10.2.37]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Nov 2004 06:23:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Nov 2004 09:23:02 -0500 Message-ID: <1E8ACF422ADD1A458AAFFAD2E6FF70C874017B@proton.jnpr.net> Thread-Topic: Last call: draft-ietf-l3vpn-mgt-fwk Thread-Index: AcStd1sSHhwsvnGfTF+9PhEUzVgkzgVAhakg From: "Ronald Bonica" To: X-OriginalArrivalTime: 04 Nov 2004 14:23:05.0205 (UTC) FILETIME=[CC903250:01C4C279] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Subject: RE: Last call: draft-ietf-l3vpn-mgt-fwk 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable This email ends the last call. I will send it on to the IESG with a request for publication as an informational RFC. Ron > -----Original Message----- > From: Ronald Bonica > Sent: Friday, October 08, 2004 4:43 PM > To: 'l3vpn@ietf.org' > Subject: Last call: draft-ietf-l3vpn-mgt-fwk >=20 > Folks, >=20 > The email begins a WG last call on draft-ietf-l3vpn-mgt-fwk. Last call > will end 2 weeks from today, on 10/22/2004. >=20 > Ron From l3vpn-bounces@ietf.org Fri Nov 5 04:42:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21248 for ; Fri, 5 Nov 2004 04:42:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0rg-0006AO-0s for l3vpn-web-archive@ietf.org; Fri, 05 Nov 2004 04:58:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0S4-0005rD-54; Fri, 05 Nov 2004 04:32:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0Mh-0004t0-0C for l3vpn@megatron.ietf.org; Fri, 05 Nov 2004 04:26:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19608 for ; Fri, 5 Nov 2004 04:26:36 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0cO-0005oI-N3 for l3vpn@ietf.org; Fri, 05 Nov 2004 04:42:53 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp8.clb.oleane.net with ESMTP id iA59Q6mw008651 for ; Fri, 5 Nov 2004 10:26:07 +0100 Message-Id: <200411050926.iA59Q6mw008651@smtp8.clb.oleane.net> From: "Gunther Palmer" To: Date: Fri, 5 Nov 2004 10:26:03 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01C4C321.DA993FB0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTDGXhd9zbHAl+gRVKbcfV/XbF+0g== X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Subject: SSL VPN Conference: Call for proposals 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 This is a multi-part message in MIME format. ------=_NextPart_000_00CA_01C4C321.DA993FB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . How to provide SSL-based remote access to a broad range of Web and legacy applications? . What about application performance and requirements? . Are encrypted application tunnelling issues solved? . What differences with IPsec VPNs? These questions, among others, will be tackled by the most recognised experts in this field during the SSL VPN Conference to be held in Paris from April 5 to 8, 2005 The call for proposal dead line has been extended to November 30. Details at: http://www.upperside.fr/sslvpn05/sslvpn05intro.htm ------=_NextPart_000_00CA_01C4C321.DA993FB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

• = How to provide SSL-based remote access to a broad range of Web and legacy applications?
• = What about application performance and requirements?
• = Are encrypted application tunnelling issues solved?
• = What differences with IPsec VPNs?

These questions, among others, will be tackled by the most recognised = experts in this field during the SSL VPN = Conference to be held in Paris from April 5 to 8, 2005

The call for proposal dead line has been = extended to November 30.

Details = at:

http://www.upperside.fr/sslvpn05/sslvpn05intro.htm

Hi Thomas,

Your note in the ID tracker (https://datatracker.ietf.org/public/pidtracker.cgi= )
on the VR draft(s) is:

[Note]: '2004-08-25: draft-ietf-l3vpn-as-vr-01.txt = &
draft-ietf-l3vpn-vpn-vr-02.txt go together. Need to = better understand
what wording/changes are needed to make clear that = these documents are
not a protocol spec from which one can achieve = interoperability.
' added by Thomas Narten> [end Note]

As editor of draft-ietf-l3vpn-vpn-vr-02.txt, I had = thought we had covered this by moving the draft to an Informational = track instead of Proposed Standard.

I'll be happy to insert text in the Abstract and/or = Introduction of each of these drafts if it is needed to proceed. = (Working with editor of the Applicability Statement (AS-VR) to update = that one.)

Do you expect that it will be necessary to change the = requirements language (i.e. MUSTs, etc.) within the text of the = drafts?

Both drafts were completed before the latest IPR = statements were mandated. Will the IPR statements need to be = updated, and other boilerplate items? I'd like to do all the = changes at once to get this finished ASAP.

Regards,
Paul Knight

Standards Advisor, Nortel Networks
Advanced Technology - Strategic Protocols & = Standards
+1 978-288-6414

------_=_NextPart_001_01C4C5AA.829A1FEC-- From l3vpn-bounces@ietf.org Mon Nov 8 11:35:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27927 for ; Mon, 8 Nov 2004 11:35:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCUn-0006Da-Mi for l3vpn-web-archive@ietf.org; Mon, 08 Nov 2004 11:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRCCp-0000Yy-HI; Mon, 08 Nov 2004 11:17:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRC1I-0003IQ-C5 for l3vpn@megatron.ietf.org; Mon, 08 Nov 2004 11:05:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24479 for ; Mon, 8 Nov 2004 11:05:25 -0500 (EST) Received: from e3.ny.us.ibm.com ([32.97.182.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRC1r-0005Gy-C9 for l3vpn@ietf.org; Mon, 08 Nov 2004 11:06:03 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iA8G4qCO717656 for ; Mon, 8 Nov 2004 11:04:52 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA8G4qxl272474 for ; Mon, 8 Nov 2004 11:04:52 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iA8G4qw0005452 for ; Mon, 8 Nov 2004 11:04:52 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-218-229.mts.ibm.com [9.65.218.229]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iA8G4pHL005410; Mon, 8 Nov 2004 11:04:52 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.12.10/8.12.5) with ESMTP id iA8G4RO0023644; Mon, 8 Nov 2004 11:04:27 -0500 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.12.10/8.12.10/Submit) with ESMTP id iA8G4R81023640; Mon, 8 Nov 2004 11:04:27 -0500 Message-Id: <200411081604.iA8G4R81023640@cichlid.raleigh.ibm.com> To: "Paul Knight" In-Reply-To: Message from paul.knight@nortelnetworks.com of "Mon, 08 Nov 2004 10:49:19 EST." <6204FDDE129D364D8040A98BCCB290EF11B0C12D@zbl6c004.corpeast.baynetworks.com> Date: Mon, 08 Nov 2004 11:04:27 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: l3vpn@ietf.org Subject: Re: Moving forward on VR draft 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Hi Paul. > As editor of draft-ietf-l3vpn-vpn-vr-02.txt, I had thought we had covered > this by moving the draft to an Informational track instead of Proposed > Standard. Here are some comments I sent just to the chairs a while back (note that I have the same general issue for both VR and the IPsec CE documents).: Thomas Narten writes: > I'm still not quite sure what to do with these. What concerns me (at a > high level) is that the docs were put forth as PS documents, but after > discussion, we just decided to make them info. But the documents have > not been revised, so the text is still exactly the same. > For the VR documents, I think it is important that it be made clear > that they are not a protocol specification, because we won't get > interoperability out of them. There are several ways to do that (some > more work than others). E.g., does it make sense to use > MUST/MAY/SHOULD language? I doubt it. Also, does one need an > "applicability statement" for an architecture? Again, I'm not at all > sure. > One other possibility is to add some sort of big note (IESG note? > applicability?) that clearly states that these documents are an > architecture and are not a protocol specification, and thus, two > implementations from the documents are unlikely to interoperate. Or > something like that. But some folk might not like that, as it makes it > even more clear that this is not a "spec". But this would be the least > work, and I'm not sure that continuing to iterate on these is all that > useful. Also, I see there is: draft-ietf-l3vpn-vr-mib-02.txt What are the plans for this document? How much sense does it make to have a MIB for an architecture? Is it complete enough to be useful (I've not looked at this MIB in detail, so maybe the questions here is a bit uninformed). > I'll be happy to insert text in the Abstract and/or Introduction of each of > these drafts if it is needed to proceed. (Working with editor of the > Applicability Statement (AS-VR) to update that one.) > Do you expect that it will be necessary to change the requirements language > (i.e. MUSTs, etc.) within the text of the drafts? This is open for discussion, per above. > Both drafts were completed before the latest IPR statements were mandated. > Will the IPR statements need to be updated, and other boilerplate items? > I'd like to do all the changes at once to get this finished ASAP. Yes, the new IPR text would be needed on a respin. But I assume this is just an editorial change. Thomas From l3vpn-bounces@ietf.org Wed Nov 10 15:58:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01566 for ; Wed, 10 Nov 2004 15:58:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzZK-0006oc-CD for l3vpn-web-archive@ietf.org; Wed, 10 Nov 2004 15:59:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzKP-0007kM-A2; Wed, 10 Nov 2004 15:44:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRyut-0000aG-Rd for l3vpn@megatron.ietf.org; Wed, 10 Nov 2004 15:18:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22828 for ; Wed, 10 Nov 2004 15:18:05 -0500 (EST) Received: from ns.ft.solteria.net ([210.142.173.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRyvr-00044L-SH for l3vpn@ietf.org; Wed, 10 Nov 2004 15:19:11 -0500 Received: from Satoru_T40p.ft.solteria.net (localhost [127.0.0.1]) by ns.ft.solteria.net (Postfix) with ESMTP id 96D5D38712 for ; Thu, 11 Nov 2004 05:17:14 +0900 (JST) Message-Id: <5.1.1.11.2.20041111031041.043dca50@localhost> X-Sender: satoru@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1J Jr5-rev2 Date: Thu, 11 Nov 2004 05:17:11 +0900 To: l3vpn@ietf.org From: "S.Matsushima" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: Multicast in IP-VPN requirements 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Hi, I've read the multicast-vpn requirement draft that was presented in l3vpn-wg meeting yesterday. First of all, I fully agree with the consideration of section 3.2.9 and 3.2.10 in the document. So, I would like to be more concrete both section's consideration. From operator's point of view, SP want to get the scenario of unchange forwarding plane of MDT. For instance, use of existing unicast LSP such as LDP-LSP and/or BGP-LSP are applicable for the transport of VPN multicast distribution. There are some reason of above: - There are requirements from customer, which hope quickly deployment of multicast service. But our MPLS backbone is unaware of IP multicast. - The reason of why unaware of IP multicast is that in the case of use PIM as MDT setup, we can't through multicast packets on our backbone, due to unlikely there are shared media among P and PE. This is some reason of our operational aspects. - On the other hand, in the case of P2MP-TE LSP solution as MDT, it has some issues and premature technology to deploy real service backbone. These mean that the multicast IP-VPN solution is need to keep same forwarding plane for MDT. In addition, supporting some Inter-AS scenario and extranet, existing BGP-LSP technique is really applicable. Finally, I would like to say that the explanation and/or recommendation is needed to putting the which technique is right way to right place. Regards, -- Satoru Matsushima, Japan Telecom From l3vpn-bounces@ietf.org Wed Nov 10 17:33:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12532 for ; Wed, 10 Nov 2004 17:33:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS12d-0000yu-63 for l3vpn-web-archive@ietf.org; Wed, 10 Nov 2004 17:34:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0s0-0001wE-K2; Wed, 10 Nov 2004 17:23:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0nq-0000yF-2o for l3vpn@megatron.ietf.org; Wed, 10 Nov 2004 17:18:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11332 for ; Wed, 10 Nov 2004 17:18:54 -0500 (EST) Received: from bgslc11.burtongroup.com ([63.99.125.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0oq-0000fy-UN for l3vpn@ietf.org; Wed, 10 Nov 2004 17:20:02 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 10 Nov 2004 17:18:09 -0500 From: Irwin Lazar To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Subject: Multicast & MPLS 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Folks, If any of you are interested in submitting a presentation proposal for MPLScon on multicast in VPLS/MPLS environments please let me know. I=B9m planning to have a round-table specifically focused on this issue, with various scenarios being explored (both within VPLS as well as in RFC-2547 environments). MPLScon is May 16-18 in NYC. The call for presentations is available at http://www.mplscon.com/speaker/submit_pres.html if you=B9d like more info about the conference. Thanks, Irwin From l3vpn-bounces@ietf.org Tue Nov 23 16:00:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28304 for ; Tue, 23 Nov 2004 16:00:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWhpQ-0003hl-7A for l3vpn-web-archive@ietf.org; Tue, 23 Nov 2004 16:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWhBk-0000a8-72; Tue, 23 Nov 2004 15:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgx3-0007pm-4B; Tue, 23 Nov 2004 15:07:49 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17229; Tue, 23 Nov 2004 15:07:46 -0500 (EST) Message-Id: <200411232007.PAA17229@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 23 Nov 2004 15:07:46 -0500 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-security-framework-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 X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --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 : Security Framework for Provider Provisioned Virtual Private Networks Author(s) : L. Fang Filename : draft-ietf-l3vpn-security-framework-03.txt Pages : 43 Date : 2004-11-23 This draft addresses security aspects pertaining to Provider Provisioned Virtual Private Networks (PPVPNs). We first describe the security threats that are relevant in the context of PPVPNs, and the defensive techniques that can be used to combat those threats. We consider security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. We also describe how these security attacks should be detected and reported. We then discuss the possible user requirements in terms of security in a PPVPN service. These user requirements translate into corresponding requirements for the providers. 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, we define a template that may be used to analyze the security characteristics of a specific PPVPN technology and describe them in a manner consistent with this framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-security-framework-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-security-framework-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-security-framework-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-23142139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-security-framework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-security-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-23142139.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Wed Nov 24 02:26:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13940 for ; Wed, 24 Nov 2004 02:26:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrbL-0003Gf-Bv for l3vpn-web-archive@ietf.org; Wed, 24 Nov 2004 02:30:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrSn-0007oF-Ib; Wed, 24 Nov 2004 02:21:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrQF-0006gX-G2 for l3vpn@megatron.ietf.org; Wed, 24 Nov 2004 02:18:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07356 for ; Wed, 24 Nov 2004 02:18:37 -0500 (EST) Received: from web60908.mail.yahoo.com ([216.155.196.84]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWrU2-00028j-Qn for l3vpn@ietf.org; Wed, 24 Nov 2004 02:22:36 -0500 Received: (qmail 42905 invoked by uid 60001); 24 Nov 2004 07:18:04 -0000 Message-ID: <20041124071804.42903.qmail@web60908.mail.yahoo.com> Received: from [202.144.106.188] by web60908.mail.yahoo.com via HTTP; Wed, 24 Nov 2004 07:18:04 GMT Date: Wed, 24 Nov 2004 07:18:04 +0000 (GMT) From: Spice Sylvia To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA07356 Subject: question on l3vpn RT constraints draft 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Hi, In the framework of this draft, specifically when one needs attachement identifiers for multihomed site in L2VPN case, If is the NLRI, could constitute a possible NLRI? In other words (say for the L2VPN case), when a site is advertised from one location and another L2 circuit to the site is advertised as from another location, could one have something of the form: a. use the BGP decision process and collapse into due to the path length. b. only the one selected in a is propogated to peers from the peer at which it is collapsed (best is chosen) c. the fact that one has a path to implies one can also have a path to via the peer from which is learns and specifically setup and LSP when needed? d. the other option ofcourse, for the L2VPN case is to use different as numbers for each of the end points attachement identifiers which makes things easy. I have also read some documents by some vendors who claim that the same AS number can be used at 2 different sites in the L3VPN case. I would like to know how such vendors plan to handle backdoor links running BGP between these sites? -brgds Sylvia =09 ___________________________________________________________=20 Moving house? Beach bar in Thailand? New Wardrobe? Win =A310k with Yahoo!= Mail to make your dream a reality.=20 Get Yahoo! Mail www.yahoo.co.uk/10k From l3vpn-bounces@ietf.org Wed Nov 24 03:57:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00264 for ; Wed, 24 Nov 2004 03:57:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWt26-0006j3-4k for l3vpn-web-archive@ietf.org; Wed, 24 Nov 2004 04:01:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWswF-0003qh-6U; Wed, 24 Nov 2004 03:55:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWst0-0002K2-J6 for l3vpn@megatron.ietf.org; Wed, 24 Nov 2004 03:52:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29849 for ; Wed, 24 Nov 2004 03:52:24 -0500 (EST) 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.33) id 1CWswq-0005wz-6L for l3vpn@ietf.org; Wed, 24 Nov 2004 03:56:24 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 24 Nov 2004 01:57:46 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAO8pq9h019399; Wed, 24 Nov 2004 00:51:52 -0800 (PST) Received: from [10.10.10.69] (sjc-rraszuk-vpn1.cisco.com [10.25.90.226]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AZG74082; Wed, 24 Nov 2004 00:58:16 -0800 (PST) Message-ID: <41A44BA5.30105@cisco.com> Date: Wed, 24 Nov 2004 00:51:49 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Spice Sylvia References: <20041124071804.42903.qmail@web60908.mail.yahoo.com> In-Reply-To: <20041124071804.42903.qmail@web60908.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA29849 Cc: l3vpn@ietf.org Subject: Re: question on l3vpn RT constraints draft 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Hi, > In other words (say for the L2VPN case), when a site > is advertised In rt-constrain spec we do not advertise sites. We advertise PE's import=20 policy. It does not really matter what sites are attached behind the=20 PEs as route targets itself create an policy abstraction already for us=20 not to have to consider the external sites connected to such PEs. > L2 circuit to the site is advertised as Further rt-constrain is not an autodiscovery proposal in any form and we=20 do not intend to advertise circuits. > a. use the BGP decision process and collapse RT> into due to the path length. BGP decision process does not modify NLRIs > c. the fact that one has a path to implies > one can also have a path to via the peer > from which is learns and specifically setup > and LSP when needed? That's exactly why sending should be sufficient. > I have also read some documents by some vendors who > claim that the same AS number can be used at 2 > different sites in the L3VPN case. I would like to > know how such vendors plan to handle backdoor links > running BGP between these sites? Essentially that would be a multihomed site. In those cases (when=20 AS_PATH has been altered) use of SOO is the solution to prevent routing=20 loops. Cheers, R. > Spice Sylvia wrote: > > Hi, >=20 > In the framework of this draft, specifically when one > needs attachement identifiers for multihomed site in > L2VPN case, >=20 > If is the NLRI, could constitute > a possible NLRI? >=20 > In other words (say for the L2VPN case), when a site > is advertised from one location and another > L2 circuit to the site is advertised as > from another location, could one have something of the > form: >=20 > a. use the BGP decision process and collapse RT> into due to the path length. >=20 > b. only the one selected in a is propogated to peers > from the peer at which it is collapsed (best is > chosen) >=20 > c. the fact that one has a path to implies > one can also have a path to via the peer > from which is learns and specifically setup > and LSP when needed? >=20 > d. the other option ofcourse, for the L2VPN case is to > use different as numbers for each of the end points > attachement identifiers which makes things easy. >=20 > I have also read some documents by some vendors who > claim that the same AS number can be used at 2 > different sites in the L3VPN case. I would like to > know how such vendors plan to handle backdoor links > running BGP between these sites? >=20 > -brgds > Sylvia >=20 >=20 > =09 > ___________________________________________________________=20 > Moving house? Beach bar in Thailand? New Wardrobe? Win =A310k with Yaho= o! Mail to make your dream a reality.=20 > Get Yahoo! Mail www.yahoo.co.uk/10k >=20 >=20 From l3vpn-bounces@ietf.org Wed Nov 24 04:57:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04982 for ; Wed, 24 Nov 2004 04:57:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWtyJ-0006Bn-23 for l3vpn-web-archive@ietf.org; Wed, 24 Nov 2004 05:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWtt1-0002yc-5d; Wed, 24 Nov 2004 04:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWtq1-0001QF-39 for l3vpn@megatron.ietf.org; Wed, 24 Nov 2004 04:53:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04686 for ; Wed, 24 Nov 2004 04:53:22 -0500 (EST) Received: from web60908.mail.yahoo.com ([216.155.196.84]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWttr-0005kJ-AC for l3vpn@ietf.org; Wed, 24 Nov 2004 04:57:23 -0500 Received: (qmail 64381 invoked by uid 60001); 24 Nov 2004 09:52:53 -0000 Message-ID: <20041124095253.64379.qmail@web60908.mail.yahoo.com> Received: from [202.144.106.188] by web60908.mail.yahoo.com via HTTP; Wed, 24 Nov 2004 09:52:53 GMT Date: Wed, 24 Nov 2004 09:52:53 +0000 (GMT) From: Spice Sylvia To: raszuk@cisco.com In-Reply-To: <41A44BA5.30105@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 8bit Cc: l3vpn@ietf.org Subject: Re: question on l3vpn RT constraints draft 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 8bit --- Robert Raszuk wrote: > Hi, > > > In other words (say for the L2VPN case), when a > site > > is advertised > > In rt-constrain spec we do not advertise sites. We > advertise PE's import > policy. It does not really matter what sites are > attached behind the > PEs as route targets itself create an policy > abstraction already for us > not to have to consider the external sites connected > to such PEs. > > > L2 circuit to the site is advertised as RT> > > Further rt-constrain is not an autodiscovery > proposal in any form and we > do not intend to advertise circuits. > > > a. use the BGP decision process and collapse as, > > RT> into due to the path length. > > BGP decision process does not modify NLRIs yes, i mixed up some terms, but 1st let me clarify some points, from the draft: In order to achieve this we will rely on ASa and ASi generating a NLRI consisting of ( RT membership information ). Receipt of such an advertisement by one of the ASes in the network will signal the need to distribute VPN routes containing this Route Target community to the peer that advertised this route. a. what is the AS# that ASa and ASi have to signal to their peers? b. will ASa and ASi not know the best path to get from ASa to ASi? Hence they do not need to signal peers which are not a part of the best path, correct? c. in other words as far as i can see, ASa will send a along the best path it sees to AS-i, and ASi will send a along the best path it sees to AS-a ? Is my understanding correct? d. What if I wish to use a suboptimal path/link/circuit to AS-i from AS-a (the path along which the as,rt goes is the direction in which traffic will flow for that RT from AS-a to AS-i, is that correct)? -brgds Sylvia ___________________________________________________________ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Wed Nov 24 08:55:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24514 for ; Wed, 24 Nov 2004 08:55:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWxg8-0005E7-EA for l3vpn-web-archive@ietf.org; Wed, 24 Nov 2004 08:59:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWxXG-0004eE-9U; Wed, 24 Nov 2004 08:50:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWxRa-0002uT-Pp for l3vpn@megatron.ietf.org; Wed, 24 Nov 2004 08:44:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23736 for ; Wed, 24 Nov 2004 08:44:24 -0500 (EST) 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.33) id 1CWxVR-00044s-EN for l3vpn@ietf.org; Wed, 24 Nov 2004 08:48:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 24 Nov 2004 05:48:57 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAODhm9N008059; Wed, 24 Nov 2004 05:43:48 -0800 (PST) Received: from [10.82.242.95] (rtp-vpn2-607.cisco.com [10.82.242.95]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AZG85135; Wed, 24 Nov 2004 05:50:10 -0800 (PST) Message-ID: <41A4900D.4020209@cisco.com> Date: Wed, 24 Nov 2004 05:43:41 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Spice Sylvia References: <20041124095253.64379.qmail@web60908.mail.yahoo.com> In-Reply-To: <20041124095253.64379.qmail@web60908.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: question on l3vpn RT constraints draft 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit > a. what is the AS# that ASa and ASi have to signal to > their peers? As number in the NLRI is the AS# of the PE which advertises such a NLRI. For ASa this is ASa's number and for ASi - ASi AS number. > b. will ASa and ASi not know the best path to get from > ASa to ASi? Hence they do not need to signal peers > which are not a part of the best path, correct? > > c. in other words as far as i can see, ASa will send a > along the best path it sees to AS-i, and ASi > will send a along the best path it sees to > AS-a ? Is my understanding correct? No ASa will send and ASi will send NLRIs. > d. What if I wish to use a suboptimal > path/link/circuit to AS-i from AS-a (the path along > which the as,rt goes is the direction in which traffic > will flow for that RT from AS-a to AS-i, is that > correct)? You can use multipath and apply the received advertisement from any number of peer's ASBRs. Cheers, R. From l3vpn-bounces@ietf.org Wed Nov 24 09:28:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27391 for ; Wed, 24 Nov 2004 09:28:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWyC1-0008M6-T6 for l3vpn-web-archive@ietf.org; Wed, 24 Nov 2004 09:32:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWy37-0003Bl-Da; Wed, 24 Nov 2004 09:23:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWxwJ-0001qb-EM for l3vpn@megatron.ietf.org; Wed, 24 Nov 2004 09:16:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26265 for ; Wed, 24 Nov 2004 09:16:09 -0500 (EST) Received: from web60910.mail.yahoo.com ([216.155.196.86]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWy01-000797-Vd for l3vpn@ietf.org; Wed, 24 Nov 2004 09:20:12 -0500 Received: (qmail 68889 invoked by uid 60001); 24 Nov 2004 14:15:29 -0000 Message-ID: <20041124141529.68885.qmail@web60910.mail.yahoo.com> Received: from [202.144.106.188] by web60910.mail.yahoo.com via HTTP; Wed, 24 Nov 2004 14:15:29 GMT Date: Wed, 24 Nov 2004 14:15:29 +0000 (GMT) From: Spice Sylvia To: raszuk@cisco.com In-Reply-To: <41A4900D.4020209@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 8bit Cc: l3vpn@ietf.org Subject: Re: question on l3vpn RT constraints draft 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 8bit --- Robert Raszuk wrote: > > a. what is the AS# that ASa and ASi have to signal > to > > their peers? > > As number in the NLRI is the AS# of the PE which > advertises such a NLRI. > For ASa this is ASa's number and for ASi - ASi AS > number. fine seems I was right the 1st time then... then why do you say that: "Further rt-constrain is not an autodiscovery proposal in any form ...." seems to me that is exactly what you are doing here. you are autodiscovering VPN members across ASes. " Receipt of such an advertisement by one of the ASes in the network will signal the need to distribute VPN routes containing this Route Target community to the peer that advertised this route." > > > b. will ASa and ASi not know the best path to get > from > > ASa to ASi? Hence they do not need to signal peers > > which are not a part of the best path, correct? > > > > c. in other words as far as i can see, ASa will > send a > > along the best path it sees to AS-i, and > ASi > > will send a along the best path it sees > to > > AS-a ? Is my understanding correct? > > No ASa will send and ASi will send > NLRIs. > So in the given example, AS-a would receive multiple paths to AS-i,RT via each of the paths and choose the best path based on BGP decison process? -brgds Sylvia ___________________________________________________________ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Thu Nov 25 06:12:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29420 for ; Thu, 25 Nov 2004 06:12:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXHc4-0000Eh-66 for l3vpn-web-archive@ietf.org; Thu, 25 Nov 2004 06:16:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXHWw-0007iQ-Gw; Thu, 25 Nov 2004 06:11:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXHVI-00073O-3F for l3vpn@megatron.ietf.org; Thu, 25 Nov 2004 06:09:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29212 for ; Thu, 25 Nov 2004 06:09:33 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXHZL-0000Aj-Im for l3vpn@ietf.org; Thu, 25 Nov 2004 06:13:48 -0500 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Nov 2004 12:09:31 +0100 Received: from l-dhcp-3492-3.rd.francetelecom.fr ([10.193.15.63]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Nov 2004 12:09:31 +0100 From: Thomas Morin To: L3VPN Content-Type: multipart/alternative; boundary="=-du8bm9GErK2j1C4RlEn9" Organization: France Telecom R&D CORE/CPN Date: Thu, 25 Nov 2004 12:09:30 +0100 Message-Id: <1101380971.7648.84.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-OriginalArrivalTime: 25 Nov 2004 11:09:31.0539 (UTC) FILETIME=[3CF42630:01C4D2DF] X-Spam-Score: 1.0 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: Multicast in VPN requirement work 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 X-Spam-Score: 1.0 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 --=-du8bm9GErK2j1C4RlEn9 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, In the last weeks, many people confirmed their interest in contributing to our requirement draft about multicast in VPNs and there seems to be an agreement to make this draft a WG document. We propose to conduct further work on the draft offline (dedicated list) and come back to the list to discuss next revision. Please contact me if you wish to participate in discussions about this draft. Thank you, -Thomas -- == Thomas MORIN - France Telecom R&D/CORE/CPN == Tel.: +33(0) 2 96 05 37 34 - www.francetelecom.com/rd -- --=-du8bm9GErK2j1C4RlEn9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

In the last weeks, many people confirmed their interest in contributing to our requirement draft about multicast in VPNs and there seems to be an agreement to make this draft a WG document.

We propose to conduct further work on the draft offline (dedicated list) and come back to the list to discuss next revision.

Please contact me if you wish to participate in discussions about this draft.

Thank you,

-Thomas

--
== Thomas MORIN - France Telecom R&D/CORE/CPN
== Tel.: +33(0) 2 96 05 37 34 - www.francetelecom.com/rd
--

--=-du8bm9GErK2j1C4RlEn9-- From l3vpn-bounces@ietf.org Thu Nov 25 07:12:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05283 for ; Thu, 25 Nov 2004 07:12:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXIY6-0001jE-Oc for l3vpn-web-archive@ietf.org; Thu, 25 Nov 2004 07:16:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXIPz-0003dG-R6; Thu, 25 Nov 2004 07:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXIPE-0003Q5-TX for l3vpn@megatron.ietf.org; Thu, 25 Nov 2004 07:07:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04890 for ; Thu, 25 Nov 2004 07:07:22 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXIT4-0001bE-0z for l3vpn@ietf.org; Thu, 25 Nov 2004 07:11:37 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I7Q005OOHM6T8@szxga02-in.huawei.com> for l3vpn@ietf.org; Thu, 25 Nov 2004 20:06:07 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTP id <0I7Q00LKWHM6JF@szxga02-in.huawei.com> forl3vpn@ietf.org; Thu, 25 Nov 2004 20:06:06 +0800 (CST) Received: from l04955 ([10.110.67.7]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTPA id <0I7Q00584HQB07@szxml01-in.huawei.com>; Thu, 25 Nov 2004 20:08:35 +0800 (CST) Date: Thu, 25 Nov 2004 20:08:16 +0800 From: lidefeng <77cronux.leed0621@huawei.com> To: Thomas Morin , L3VPN Message-id: <001101c4d2e7$72845510$07436e0a@l04955> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_G46d+pItBwCK5KQnXLFSWw)" X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.007 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com References: <1101380971.7648.84.camel@wintermute> X-Spam-Score: 1.8 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: Re: Multicast in VPN requirement work 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 X-Spam-Score: 1.8 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. --Boundary_(ID_G46d+pItBwCK5KQnXLFSWw) Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7BIT I would like to participate in the discussion. ----- Original Message ----- From: Thomas Morin To: L3VPN Sent: Thursday, November 25, 2004 7:09 PM Subject: Multicast in VPN requirement work Hi, In the last weeks, many people confirmed their interest in contributing to our requirement draft about multicast in VPNs and there seems to be an agreement to make this draft a WG document. We propose to conduct further work on the draft offline (dedicated list) and come back to the list to discuss next revision. Please contact me if you wish to participate in discussions about this draft. Thank you, -Thomas -- == Thomas MORIN - France Telecom R&D/CORE/CPN == Tel.: +33(0) 2 96 05 37 34 - www.francetelecom.com/rd -- --Boundary_(ID_G46d+pItBwCK5KQnXLFSWw) Content-type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBDSEFSU0VUPVVURi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI4MDAuMTEwNiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPkkg d291bGQgbGlrZSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgDQpkaXNjdXNzaW9uLjwvRk9OVD48L0RJ Vj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZU OiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsg TUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj4tLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5E OiAjZTRlNGU0OyBGT05UOiA5cHQg5a6L5L2TOyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8 L0I+IA0KICA8QSB0aXRsZT10aG9tYXMubW9yaW5AcmQuZnJhbmNldGVsZWNvbS5jb20gDQogIGhy ZWY9Im1haWx0bzp0aG9tYXMubW9yaW5AcmQuZnJhbmNldGVsZWNvbS5jb20iPlRob21hcyBNb3Jp bjwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlRvOjwvQj4g PEEgdGl0bGU9bDN2cG5AaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpsM3ZwbkBpZXRmLm9yZyI+ TDNWUE48L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TZW50 OjwvQj4gVGh1cnNkYXksIE5vdmVtYmVyIDI1LCAyMDA0IDc6MDkgDQogIFBNPC9ESVY+DQogIDxE SVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlN1YmplY3Q6PC9CPiBNdWx0aWNhc3QgaW4g VlBOIHJlcXVpcmVtZW50IA0KICB3b3JrPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPkhpLDxCUj48 QlI+SW4gdGhlIGxhc3Qgd2Vla3MsIG1hbnkgcGVvcGxlIGNvbmZpcm1lZCB0aGVpciANCiAgaW50 ZXJlc3QgaW4gY29udHJpYnV0aW5nIHRvIG91ciByZXF1aXJlbWVudCBkcmFmdCBhYm91dCBtdWx0 aWNhc3QgaW4gVlBOcyBhbmQgDQogIHRoZXJlIHNlZW1zIHRvIGJlIGFuIGFncmVlbWVudCB0byBt YWtlIHRoaXMgZHJhZnQgYSBXRyBkb2N1bWVudC48QlI+PEJSPldlIA0KICBwcm9wb3NlIHRvIGNv bmR1Y3QgZnVydGhlciB3b3JrIG9uIHRoZSBkcmFmdCBvZmZsaW5lIChkZWRpY2F0ZWQgbGlzdCkg YW5kIGNvbWUgDQogIGJhY2sgdG8gdGhlIGxpc3QgdG8gZGlzY3VzcyBuZXh0IHJldmlzaW9uLjxC Uj48QlI+UGxlYXNlIGNvbnRhY3QgbWUgaWYgeW91IA0KICB3aXNoIHRvIHBhcnRpY2lwYXRlIGlu IGRpc2N1c3Npb25zIGFib3V0IHRoaXMgZHJhZnQuPEJSPjxCUj5UaGFuayANCiAgeW91LDxCUj48 QlI+LVRob21hczxCUj4NCiAgPFRBQkxFIGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0 aD0iMTAwJSI+DQogICAgPFRCT0RZPg0KICAgIDxUUj4NCiAgICAgIDxURD4NCiAgICAgICAgPFRB QkxFIGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0aD0iMTAwJSI+DQogICAgICAgICAg PFRCT0RZPg0KICAgICAgICAgIDxUUj4NCiAgICAgICAgICAgIDxURD48QlI+PFRUPjxGT05UIGNv bG9yPSNjMGMwYzA+LS08L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgICAgICAgICAgICBj b2xvcj0jYzBjMGMwPj09PC9GT05UPjwvVFQ+PFRUPjxCPiA8L0I+PC9UVD48Qj5UaG9tYXMgTU9S SU48L0I+IC0gDQogICAgICAgICAgICAgIDxGT05UIGNvbG9yPSMwMDAwODA+RnJhbmNlIFRlbGVj b20gDQogICAgICAgICAgICAgIFImYW1wO0QvQ09SRS9DUE48L0ZPTlQ+PEJSPjxUVD48Rk9OVCAN CiAgICAgICAgICAgICAgY29sb3I9I2MwYzBjMD49PTwvRk9OVD48L1RUPjxUVD4gPC9UVD48Rk9O VCBzaXplPTI+VGVsLjogKzMzKDApIDIgDQogICAgICAgICAgICAgIDk2IDA1IDM3IDM0IC0gd3d3 LmZyYW5jZXRlbGVjb20uY29tL3JkPC9GT05UPjxCUj48VFQ+PEZPTlQgDQogICAgICAgICAgICAg IGNvbG9yPSNjMGMwYzA+LS08L0ZPTlQ+PC9UVD4gDQogIDwvVEQ+PC9UUj48L1RCT0RZPjwvVEFC TEU+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hU TUw+DQo= --Boundary_(ID_G46d+pItBwCK5KQnXLFSWw)--