From danny@tcb.net Tue Aug 4 04:04:43 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D36A28C34A for ; Tue, 4 Aug 2009 04:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry6l2vv9A8dQ for ; Tue, 4 Aug 2009 04:04:43 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 4AEA928C355 for ; Tue, 4 Aug 2009 04:04:13 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 3B43E2684EA; Tue, 4 Aug 2009 05:04:06 -0600 (MDT) Received: from 10-1-15-7.aa.arbor.net (division.aa.arbor.net [204.181.64.4]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l3vpn@ietf.org; Tue, 04 Aug 2009 05:04:05 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: From: Danny McPherson To: l3vpn@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: WG Courtesy Reminder Date: Tue, 4 Aug 2009 05:03:48 -0600 X-Mailer: Apple Mail (2.935.3) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 11:04:43 -0000 Folks, I feel a bit silly having to remind folks here of this, but it seems necessary given some activity on the mailing list as of late. Let's please ensure postings to the list remain of a professional and constructive nature, and avoid personal attacks or other general nastiness that detracts from the aim of producing quality interoperable standards. We've made a considerable amount of progress in the past 12 months, and we should all attempt to capitalize on the teamwork and cooperation that's enabled that to work in a positive and effective manner going forward. Thanks in advance for your continued cooperation! -danny & Marshall From root@core3.amsl.com Tue Aug 4 11:00:01 2009 Return-Path: X-Original-To: l3vpn@ietf.org Delivered-To: l3vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DC58B3A69F9; Tue, 4 Aug 2009 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-e2e-rsvp-te-reqts-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090804180001.DC58B3A69F9@core3.amsl.com> Date: Tue, 4 Aug 2009 11:00:01 -0700 (PDT) Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 18:00:02 -0000 --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 supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN Author(s) : K. Kumaki, Y. Kamite, R. Zhang Filename : draft-ietf-l3vpn-e2e-rsvp-te-reqts-04.txt Pages : 24 Date : 2009-8-4 Today, customers expect to run triple play services through BGP/MPLS IP-VPNs. Some Service Providers will deploy services that request QoS guarantees from a local CE to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for end-to-end QOS and reserving adequate bandwidth continue to increase. Service Providers can use both MPLS and an MPLS-TE LSP to meet the service objectives. This document describes service provider requirements for supporting customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-e2e-rsvp-te-reqts-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-l3vpn-e2e-rsvp-te-reqts-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-8-4105024.I-D@ietf.org> --NextPart-- From ke-kumaki@kddilabs.jp Tue Aug 4 16:57:09 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEEF3A7114 for ; Tue, 4 Aug 2009 16:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZJqPaJAQW2w for ; Tue, 4 Aug 2009 16:57:09 -0700 (PDT) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id E39B13A684D for ; Tue, 4 Aug 2009 16:57:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 1FA41EC8E0 for ; Wed, 5 Aug 2009 08:57:05 +0900 (JST) Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [172.19.98.10]) by mandala.kddilabs.jp (Postfix) with ESMTP id CB058EC8C2 for ; Wed, 5 Aug 2009 08:57:04 +0900 (JST) Received: from [127.0.0.1] (ova138.vpn.kddilabs.jp [172.19.112.138]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id A91501E0002 for ; Wed, 5 Aug 2009 08:57:04 +0900 (JST) Message-ID: <4A78CAD4.7000007@kddilabs.jp> Date: Wed, 05 Aug 2009 08:57:08 +0900 From: Kenji Kumaki User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: l3vpn@ietf.org Subject: draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 23:57:09 -0000 Hello co-chairs and WG. I recently submitted a new version of draft-ietf-l3vpn-e2e-rsvp-te-reqts-04.txt http://tools.ietf.org/html/draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 This document describes service provider requirements for supporting customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN. The document has had a number of updates, but unfortunately the authors were not able to attend and present the work at the recent WG session in Stockholm. The authors believe we have addressed all issues raised on list and in private discussions. We think the document is now complete and we would like to ask the chairs to consider last calling and progressing to publication. Thank you. Kenji From daniel@olddog.co.uk Fri Aug 7 06:11:58 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858413A6A66 for ; Fri, 7 Aug 2009 06:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQvJWbXCISrW for ; Fri, 7 Aug 2009 06:11:58 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id A609A3A692C for ; Fri, 7 Aug 2009 06:11:57 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id n77DBgkk029733; Fri, 7 Aug 2009 14:11:47 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id n77DBfpR029714; Fri, 7 Aug 2009 14:11:41 +0100 From: "Daniel King" To: Subject: IETF-75 Draft L3VPN Minutes Date: Fri, 7 Aug 2009 14:11:41 +0100 Message-ID: <001801ca1760$9b14eea0$d13ecbe0$@co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CA1768.FCD956A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoXYJp8tQpnREegRnG7Y92VPfE77Q== Content-Language: en-gb X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:11:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01CA1768.FCD956A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello L3VPN'rs, The draft minutes for our IETF-75 meeting have been uploaded to: http://www.ietf.org/proceedings/75/minutes/l3vpn.html Please suggest any corrections by August 21, 2009. Br, Dan. ------=_NextPart_000_0019_01CA1768.FCD956A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello L3VPN'rs,

 

The draft minutes for our IETF-75 meeting have = been uploaded to:

 

http://www= .ietf.org/proceedings/75/minutes/l3vpn.html

 

Please suggest any corrections by August 21, = 2009.

 

Br, Dan.

 

------=_NextPart_000_0019_01CA1768.FCD956A0-- From danny@tcb.net Tue Aug 11 19:11:00 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A713A68B5 for ; Tue, 11 Aug 2009 19:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 969sVGqXFf8x for ; Tue, 11 Aug 2009 19:11:00 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id E5EA23A63EC for ; Tue, 11 Aug 2009 19:10:59 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 7F64D2684EA; Tue, 11 Aug 2009 20:09:36 -0600 (MDT) Received: from 10-1-15-12.aa.arbor.net (division.aa.arbor.net [204.181.64.1]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l3vpn@ietf.org; Tue, 11 Aug 2009 20:09:36 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: From: Danny McPherson To: l3vpn@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-39--1038969720 Mime-Version: 1.0 (Apple Message framework v935.3) Subject: WG Last Call: draft-ietf-l3vpn-e2e-rsvp-te-reqts-04.txt Date: Tue, 11 Aug 2009 07:50:53 -0600 References: <20090804180001.DC58B3A69F9@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 02:11:00 -0000 --Apple-Mail-39--1038969720 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Folks, Please consider today the start of a two-week WG Last Call for this document. Feedback should be provided to the authors and/or mailing list ASAP. Last Call ends August 28, 2009. Thanks! -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: August 4, 2009 12:00:01 PM MDT > To: i-d-announce@ietf.org > Cc: l3vpn@ietf.org > Subject: I-D ACTION:draft-ietf-l3vpn-e2e-rsvp-te-reqts-04.txt > Reply-To: internet-drafts@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 : Requirements for supporting Customer RSVP and RSVP-TE over > a BGP/MPLS IP-VPN > Author(s) : K. Kumaki, Y. Kamite, R. Zhang > Filename : draft-ietf-l3vpn-e2e-rsvp-te-reqts-04.txt > Pages : 24 > Date : 2009-8-4 > > Today, customers expect to run triple play services through BGP/MPLS > IP-VPNs. Some Service Providers will deploy services that request > QoS > guarantees from a local CE to a remote CE across the network. As a > result, the application (e.g., voice, video, bandwidth-guaranteed > data pipe, etc.) requirements for end-to-end QOS and reserving > adequate bandwidth continue to increase. > > Service Providers can use both MPLS and an MPLS-TE LSP to meet the > service objectives. This document describes service provider > requirements for supporting customer RSVP and RSVP-TE over a > BGP/MPLS IP-VPN. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-e2e-rsvp-te-reqts-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --Apple-Mail-39--1038969720 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-8-4105024.I-D@ietf.org>

--Apple-Mail-39--1038969720 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-39--1038969720-- From yakov@juniper.net Mon Aug 17 03:53:21 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55FB28C27C for ; Mon, 17 Aug 2009 03:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CGHVZa8-+bI for ; Mon, 17 Aug 2009 03:53:19 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 53DE328C285 for ; Mon, 17 Aug 2009 03:53:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSok2o3Dvy1ULL25Y9tNeBbp7PCnI0pj7@postini.com; Mon, 17 Aug 2009 03:53:24 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 17 Aug 2009 03:49:50 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 03:49:50 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 03:49:50 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 03:49:49 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n7HAnnd20191; Mon, 17 Aug 2009 03:49:49 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200908171049.n7HAnnd20191@magenta.juniper.net> To: erosen@cisco.com Subject: Re: Comments on draft-raggarwa-l3vpn-bgp-mvpn-extranet-00.txt In-Reply-To: <23014.1247840077@erosen-linux> References: <23014.1247840077@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Fri, 17 Jul 2009 10:14:37 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20815.1250506189.1@juniper.net> Date: Mon, 17 Aug 2009 03:49:49 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 17 Aug 2009 10:49:49.0265 (UTC) FILETIME=[713FF410:01CA1F28] Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 10:53:21 -0000 Eric, > I have a number of comments on this draft. I've placed them in-line, look > for lines beginning with ****. response in-line... > 2. Introduction > > This document describes clarifications to the procedures in [BGP- > > **** Fess up, the document specifies new procedures, not merely > **** "clarifications" to procedures already specified ;-) I don't think > **** there's any reason to try to hide that. > > **** Most of the procedures are analogous (as well they should be) to > **** procedures described in section 8 of draft-rosen-l3vpn-mvpn-mspmsi- > **** 04.txt ("extranet with PIM control plane". There are a few differences > **** that are worthy of discussion. > > MVPN] for supporting extranets. The procedures specified in this > document assume that BGP is used for transmission of MVPN customers' > multicast routing information within the service provider(s) > infrastructure [BGP-MVPN]. > > The extranet functionality is a requirement of RFC4834 [RFC4834] > (section 5.1.6) and allows a VPN site to receive or send multicast > traffic from sites (or to sites) of another VPN. > > 3. Extranet Service Model > > In the context of MVPN the term "extranet" refers to the ability for > multicast sources in one VPN to send multicast traffic to multicast > receivers in other VPN(s). Such multicast sources are referred to as > "extranet sources". The multicast groups to which the extranet > sources generate traffic are referred to as "extranet groups". The > receivers that receive multicast traffic from extranet sources are > referred to as "extranet receivers". > > The IP addresses used by extranet sources MUST NOT overlap with the > **** "extranet sources and RPs", I think. That is correct. It is reflected in the -01 version. > IP addresses used by VPNs that receive multicast traffic from such > sources. > > **** I think this is too strong a restriction. Suppose company X is > **** providing some content to company Y and some entirely different content > **** to company Z. And suppose this is done in source-specific mode (SSM), > **** where Y gets its content from X's source S1 and Z gets its content from > **** X's source S2. > > **** Clearly Y cannot have its own "intranet" system with source address S1, > **** and Z cannot have its own "intranet" system with source address S2. > **** Let's call this the "weak overlap restriction". Violation of the weak > **** overlap restriction would cause the address S1 to be ambiguous in VPN Y > **** and would cause the address S2 to be ambiguous in VPN Z. > > **** However, the draft poses a stronger restriction, viz., that Y should > **** not be able to have an intranet source S2 and that Z should not be able > **** to have an intranet source S1. Let's call this the "strong" overlap > **** restriction. > > **** I don't think the strong overlap restriction is either necessary or > **** desirable. As long as the weak overlap restriction is in effect, > **** there's no reason why VPN Y should not have an intranet system with > **** address S2 or who VPN Z should not have an intranet system with address > **** S1. No ambiguity would result. > > **** If I were the SP connecting X, Y, and Z, I don't think I would want to > **** tell company Y "sorry, you can't use address S2 in your internal > **** network, because X is using S2 to send content to Z". The folks over > **** at company Y will probably say "we don't care what X uses to send > **** content to Z, what does that have to do with us?" So I'm not sure the > **** strong overlap restriction is deployable in practice. The "weak overlap restriction" is not sufficient. To illustrate why, consider a scenario where both company X and company Y provide some (multicast) content to company Z, and assume that this is done in the SSM mode, where Z receives its content from X's source S1, and from Y's source S2. In this case S1 can not be the same as S2, and this constrain is not covered by the "weak overlap restriction". See also -01 version, as it clarifies this issue. > **** The procedures in section 8 of draft-rosen-l3vpn-mvpn-mspmsi do not > **** have the strong address restriction, but only the weak one. First of all, reading section 8 of draft-rosen-l3vpn-mvpn-mspmsi I was not able to find any references to the "weak" restriction. Second, as I illustrated above, the "weak" restriction is not sufficient. > Moreover, in the case of PIM-SM in ASM mode addresses used > by extranet groups MUST NOT overlap with the group addresses used by > VPNs that have receivers for the extranet groups. > > **** Again, this seems too strong. In a given VPN, a given group address > **** either has extranet sources or it doesn't. But I don't see why the SP > **** should tell company Y "you can't use group address G internally; X is > **** already using G to talk to Z". If both X and Y provide *two* different contents to Z using ASM, and if X uses C-G1, and Y uses C-G2, then C-G1 can not be the same as C-G2, as otherwise Z would not be able to distinguish between the two. See also -01 version, as it clarifies this issue. > 4. Routing Exchange in Support of Extranets > > VRFs in the VPN that wish to access multicast extranet sources in > other VPNs MUST be able to import the "necessary" unicast and BGP > MVPN auto-discovery routes advertised by other PEs for VPNs that > contain the extranet sources. > > The "necessary" routes are the routes required by VRFs to receive > multicast traffic for extranet sources and groups from other VPNs. > This includes unicast VPN-IP routes to extranet sources, as well as > BGP MVPN Source Active auto-discovery routes for extranet sources and > groups. It also includes Intra-AS, Inter-AS and S-PMSI auto- > discovery routes that carry P-Tunnel attributes for P-Tunnels used by > the other VPNs for sending multicast traffic for multicast sources > and groups. Following describes procedures that ensure that the > necessary routes can be imported. > > Case 1: PIM-SM in SSM mode. In this scenario a necessary condition > for (C-S,C-G) traffic received on a particular VRF to be forwarded > downstream is for the VRF to have a VPN-IP route to C-S. In other > > **** It took me a little while to understand what "received on a particular > **** VRF" means. I think "received on a particular VRF" is supposed to mean > **** "received on an interface not associated with the VRF", i.e., received > **** from the backbone or from a local interface that is associated with a > **** different VRF. I also think "forwarded downstream" means "forwarded > **** over an interface that is associated with the VRF". Is that a correct > **** interpretation? Yes, this is correct interpretation. > words the route to C-S must be advertised in the extranet. If this > condition is not satisfied the traffic is discarded by the VRF when > received from a CE. > > **** "Discarded by the VRF"? Do you mean that the traffic is discarded > **** before it is seen by the VRF's C-PIM instance, or that it is processed > **** by the C-PIM instance and then discarded as having come from the wrong > **** RPF interface"? > > **** It seems to me that case 1 does not "describe procedures that ensure > **** that the necessary routes can be imported", as was promised in the > **** paragraph before case 1. It describes a procedure for discarding > **** packets when the necessary routes have not been imported. See -01 version. > Case 2: PIM-SM in ASM mode. To fit the ASM model, if a given C-G is > in the extranet, then the C-RP for that C-G and all the C-Ss sending > to that C-G should be in the extranet as well (or to be more precise, > all the VPN-IP routes to C-RP and these C-Ss have to advertised in > the extranet). Note that for a given C-G that is part of the extranet > formed by several VPNs, C-Ss for that C-G may be present in any of > these VPNs. > > **** This is the strong overlap restriction again. No, it is not - it just allows sources for a given (extranet) group C-G that is in the ASM range to be located in multiple MVPNs. > VRFs connected to the sites that have extranet receivers for a given > extranet source MUST be able to import a VPN-IP route to that source. > This could be accomplished by either (a) setting the appropriate RTs > that control import of VPN-IP routes on the VRFs connected to the > receivers, or (b) setting the appropriate RTs that control export of > VPN-IP routes on the VRF connected to the source. > > **** In the likely case that you only want a VRF connected to extranet > **** receivers to import a select set of routes from the other VPN, you > **** likely need a separate 'extranet' RT as import RT for the VRF, and a > **** means of exporting the RT with specific routes at the sender VRF. > > Note that as long as the Source Active auto-discovery routes and S- > PMSI auto-discovery routes use the default setting for their RTs, > setting up the appropriate RTs for VPN-IP routes, as described above, > would also result in the appropriate import of Source Active auto- > discovery routes, and S-PMSI auto-discovery routes. > > **** I'm not sure there's a default covering the case in which different > **** VPN-IP routes carry different RTs. A reference to the relevant section > **** of [BGP-MVPN] would be useful. See -01 version. > In addition, VRFs connected to the sites that have extranet receivers > for a given extranet source MUST be able to import I-PMSI auto- > discovery route originated by the VRF connected to the source. This > could be accomplished by either (a) setting the appropriate RTs that > control import of I-PMSI auto-discovery routes on the VRFs connected > to the receivers, or (b) setting the appropriate RTs that control > export of I-PMSI auto-discovery routes on the VRF connected to the > source. > > **** Note that if the A-D routes do not have at least one RT in common with > **** the VPN-IP routes, then option 2 of section 6.2 will fail. However, > **** nothing in this section seems to require that the A-D routes and the > **** VPN-IP routes have any RT in common. I think the section requires that > **** the A-D routes and the VPN-IP routes each get imported into a > **** particular set of VRFs, but that doesn't require that they have any RT > **** in common. See -01 version. > If a given VRF connected to a given extranet source uses P2MP RSVP-TE > as an inclusive P-tunnel to carry (multicast) traffic from that > source, then this VRF MUST also be able to import intra-AS I-PMSI > auto-discovery routes originated by the VRFs connected to the sites > that have extranet receivers for that source. > > **** If you use option 1 of section 6.1, then presumably there's an RSVP-TE > **** P2MP LSP for intranet traffic, and a separate one for extranet > **** traffic. How does the headend PE know which of the other PEs need to > **** be added to which of the two LSPs? The headend PE knows this based on its import policies and the RTs carried by the intra-AS I-PMSI A-D routes originated by the other PEs. > **** An overall comment on the structure of this section: note that unlike > **** case 1, case 2 does discuss the import/export of the VPN-IP routes to > **** the C-S or C-RP. However, case 2 does not discuss the discard of > **** packets when VPN-IP routes to the C-S or C-RP are not present in the > **** VRF. I'm not sure this way of organizing the text is right, as the > **** topic (importing/exporting the right set of unicast routes) is not > **** really any different for SSM than it is for ASM, and the rules for > **** discarding multicast data packets when the necessary VPN-IP routes are > **** not present also do not seem to be different for SSM than for ASM. > > > 5. Multicast Extranet over Selective P-tunnels > > Procedures in [BGP-MVPN] along with the routing exchange > clarifications described in the previous section, are sufficient to > support the scenario when the multicast extranet traffic is carried > over selective P-tunnels (P-tunnels advertised by S-PMSI auto- > discovery routes). > > **** For aggregated S-PMSIs, I think this is only correct if the strong > **** overlap restriction holds. If only the weak overlap restriction holds, > **** then we could have the following situation. VPN1 might have (S1,G) and > **** (S2,G) sources. VPN2 might have (S1,G) sources, but might receive > **** (S2,G) traffic from VPN1. So VPN1 might transmit (S1,G) and (S2,G) on > **** one aggregated S-PMSI, while VPN2 transmits (S1,G) on a different > **** S-PMSI. VPN2's receiving VRFs would have to know to discard the (S1,G) > **** traffic from VPN1. I think these discard procedures are the same that > **** you need for option 2 of section 6.2. See -01 version. > 6. Multicast Extranet over Inclusive P-tunnels > > There are (at least) three possible ways to support extranet > multicast over inclusive P-tunnels. > > **** Probably some text like that in section 8.5 of draft-rosen-l3vpn-mvpn- > **** mspmsi is needed, to cover the case where extranet traffic flows from > **** one VRF to another on the same PE. See -01 version. > 6.1. Option 1 > > **** I note that this is a model that is not discussed in section 8 of > **** draft-rosen-l3vpn-mvpn-mspmsi. > > Each VRF that has set of extranet sources being part of that VRF uses > not one, but two inclusive P-tunnels for sending multicast traffic. > The first one is used for sending multicast traffic from the non > extranet sources; the second is used for sending multicast traffic > from the extranet sources. Each of these P-tunnels will be advertised > by its own I-PMSI auto-discovery route. Therefore, these two routes > MUST NOT use the same RD. The distribution scope of the second route > SHOULD include all the VRFs that are within the scope of the first > route, plus all the other VRFs that have the extranet receivers for > the extranet sources of the VRF that originates the route. > > **** So if VPN X has any sources that have been designated as extranet > **** sources, any VRF in VPN X needs to join two I-PMSIs. Even the VRFs in > **** X that do not need to receive the extranet traffic still need to join > **** the extranet PMSI. This doesn't seem right; why should a VRF have to > **** join a second I-PMSI if it doesn't need to receive any traffic from > **** outside its own VPN? Even in the absence of any extranets, it is quite possible for a VRF to receive (multicast) traffic on I-PMSI for which the VRF has no downstream receivers. The situation above is no different. > **** If VPN X needs to source some extranet traffic to VPN Y and some > **** different extranet traffic to VPN Z, then we either need to ensure that > **** the strong overlap restriction holds or else the receiver VRFs need to > **** apply the packet discard procedure described in section 6.2. The receiver VRFs need to apply the packet discard procedures described in section 6.2. See -01 version. > To carry (C-S, C-G) multicast traffic the PE by default should use > the P-tunnel that has been advertised in the I-PMSI auto-discovery > route that has the same set of RTs as the VPN-IP route to C-S > advertised by the PE. > > **** Some guidance covering the non-default case would be helpful ;-) > > A special case of this option is the scenario where the set of > extranet sources within a given VRF is the same as the set of > multicast sources within that VRF. In this case there is no need to > have two P-tunnels - one P-tunnel would suffice. As a result only one > I-PMSI auto-discovery route would need to be originated by that VRF. > > > 6.2. Option 2 > > **** I believe this corresponds to the "red method" described in section 8.2 > **** of (you guessed it) draft-rosen-l3vpn-mvpn-mspmsi. > > Each VRF has just one inclusive P-tunnel that is used to send data > originated by the sites connected to that VRF. In this case if the > set of extranet multicast sources are part of that VRF, then all > other VRFs that are part of the extranet must be able to receive data > on that P-tunnel (all these VRFs must be able import the I-PMSI auto- > discovery route that advertises this P-tunnel). > > A VRF that is receiving traffic on an inclusive P-tunnel from the > extranet sources connected to another VRF may also receive on that P- > tunnel the non-extranet traffic from that VRF. Such traffic will be > dropped by the receiving VRF anyway if it doesn't have (C-S, C-G) > > **** or (C-*,C-G) state Correct. See -01 version. > forwarding state for this non-extranet traffic. The receiving VRF may > have forwarding state for such traffic if the address space for the > non-extranet sources connected to the sending VRF overlaps with the > address space of the sources in the receiving VRF's VPN. To take care > of this case the receiving VRF MUST be able to drop the non-extranet > traffic if it arrives on the unexpected P-Tunnel. The following > describes how the unexpected P-Tunnel is determined. > > When the local PE receives from other PEs (multicast) traffic > corresponding to the (multicast) state advertised in the C-multicast > route originated by the local PE, the PE MUST discard (and not > forward) this traffic if it was received on a P-tunnel that is > advertised by an I-PMSI auto-discovery route whose RTs form an empty > intersection with the RTs carried in the VPN-IP route for the address > carried in the Multicast Source field of MCAST-VPN NLRI. This check > is in addition to the checks specified in section 9.1 of [MVPN-ARCH]. > > **** I don't think the check as stated is precisely correct. I think the > **** condition for NOT discarding traffic should be "the intersection of the > **** set of RTs carried by the VPN-IP route and the set of RTs carried by > **** the I-PMSI A-D route contains one of the import RTs of the VRF". the > **** intersection being non-null does not imply that both the A-D route and > **** the VPN-IP route were actually imported into the VRF. That is correct. See -01 version. > Note that for the above procedure to work, there should be a > consistent choice with respect to handling import/export of VPN-IP > routes and I-PMSI auto-discovery routes. That is, either (a) the > import/export of both types of routes should be controlled by setting > the appropriate RTs on the VRFs connected to the receivers, or (b) > the import/export of both types of routes should be controlled by > setting the appropriate RTs on the VRF connected to the source. > > > **** I don't really follow this. In this model, the multicast data traffic > **** is carried in the I-PMSI of the VPN containing the transmitters, call > **** it "VPN red". If some other VPN, "VPN blue", has receivers then the > **** blue VRFs have to be configured to import both red and blue routes. I > **** don't see how you can set this up properly without explicit > **** configuration at the receiver end. > > **** It's highly unlikely that you will want the blue VRFs to import all the > **** red routes, as this would allow blue hosts to unicast to red hosts. So > **** it's more likely you will need a distinct RT to mark the red routes > **** that are supposed to be imported by the blue VRFs. So there will > **** generally be configuration at both ends. Your claim about "there will generally be configuration at both ends" is incorrect. This could be "set up properly without explicit configuration at the receiver end" by (selectively) adding RT-blue to *some* of the "red" routes. This way all the "blue" routes will carry RT-blue, all the "red" routes will carry RT-red, and some of the "red" routes will also carry RT-blue (in addition to RT-red). > 7. Option 3 > > Each VRF that has set of extranet multicast sources being part of > that VRF is a root of as many inclusive P-tunnels as the number of > MVPNs in the extranet. A given (C-S, C-G) multicast traffic has to be > sent over each of these P-tunnels. From the point of view of the > number of P-tunnels, and the amount of replication required this is > the least desirable option, and is included here just for the sake of > completeness. > > **** This is essentially the "blue method" of section 8.3 of > **** draft-...-mspmsi. While this model does have the disadvantage of > **** causing the ingress PE to transmit multicast data on two or more > **** P-tunnels, it has the advantage of being the only option that does not > **** require either (a) the strong overlap restriction, or (b) configuration > **** at the receiver end. Your claim that it is "the only option that does not require either (a) the strong overlap restriction, or (b) configuration at the receiver end" is incorrect, as other the options specified in the draft require neither the strong overlap restriction, nor configuration at the receiver end. > **** We have found this model to be favored by providers who are managing > **** content distribution, because they can configure just the transmitter > **** end (the ingress PE) in order to determine which receivers are allowed > **** to receive a given transmission. To allow the content to be sent to a > **** new VPN, the new VPN's RT just has to be added to the set of RTs > **** carried by the routes originated by the ingress PE. Note that this scenario assumes that *all* the sites on the new VPN can receive the content. It does not cover the case where only *some* of the sites in the new VPN can receive the content. > **** This model has the further advantage of being the only model that > **** delivers to the receiver VRFs only the extranet traffic that the > **** receiver VRFs really need. I.e., a receiver VRF in a given VPN > **** doesn't get extranet traffic that is for some other VPN , and it > **** doesn't the intranet traffic of any other VPN. The claimed advantage is incorrect. This is because since this model uses I-PMSI, then *by definition* this model may result in a situation where some of the VRFs will receive the extranet traffic that the receivers in these VRFs do not need. Your claim about "being the only model" is also incorrect. This is because the S-PMSI model also accomplishes does in fact allow to deliver to the receiver VRFs only the extranet traffic that the receiver VRFs really need. > **** For these reasons, I think this option is preferable to "option 1". > > 11. References > > 11.2. Informative References > > **** I think there is sufficient overlap with the pre-existing "Extranet > **** over PIM" material in draft-rosen-...-mspmsi to warrant an informative > **** reference to it. On that we should agree to disagree. But your comments have been acknowledged in the -01 version. Yakov. From erosen@cisco.com Mon Aug 24 08:12:10 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5DF3A6E62 for ; Mon, 24 Aug 2009 08:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbNVy4jJ7uf2 for ; Mon, 24 Aug 2009 08:12:08 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F276A3A6DB6 for ; Mon, 24 Aug 2009 08:12:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,266,1249257600"; d="scan'208";a="55288592" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Aug 2009 15:12:12 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7OFCBdK007889; Mon, 24 Aug 2009 11:12:11 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7OFCAA0026065; Mon, 24 Aug 2009 15:12:10 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n7OFCAmm021820; Mon, 24 Aug 2009 11:12:10 -0400 To: l3vpn@ietf.org Subject: New work items X-Mailer: MH-E 8.2; nmh 1.2; GNU Emacs 23.1.1 Date: Mon, 24 Aug 2009 11:12:10 -0400 Message-ID: <21819.1251126730@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1792; t=1251126731; x=1251990731; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20New=20work=20items |Sender:=20 |To:=20l3vpn@ietf.org; bh=F2xkJBKF1cBu2INVQ6E+9YxkhMfzebtAr7k/AnuBOr8=; b=e5iX3ojM8P6+QXOjZltVjj1X1VOKdbArsUc04f5lkRfEfcOwxrAQ+60tfg IIqOnQIDOcgCB/i6/FVw9heZ3gJNeP719C20xl0ngwGvu3qETfjHl5Mdf0wR WjEJ9tWj0V; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 15:12:10 -0000 I read the following in the L3VPN WG minutes: Danny McPherson: There is work. There are things that need to be considered. We should revisit our milestones now that the MVPN documents have been submitted to the IESG, that was a gate for an official new work in the WG, now we can consider new work items. I am glad to see that it is finally time to consider new work items. I have been collecting a bunch of new work items for some time in draft-rosen- l3vpn-mvpn-mspmsi: - S-PMSI Join extensions (for MPLS and for MVPNv6) - Wild card support in S-PMSI A-D routes and S-PMSI Joins - Finish the specification for the use of bidirectional P-tunnels - Using PIM as PE-PE control plane, but without using MI-PMSI (i.e., eliminating the use of trees that only carry control packets) - Extranet support using PIM control plane - Offering MVPN service with PIM control plane in concert with unicast "Hub and Spoke" VPN service and anycast-source service. I think the draft mentioned above is an excellent basis for future work. That draft could really be turned into a half dozen or so different drafts, each addressing a particular topic, if the WG prefers that approach. (I kept them all in one document primarily to make it easier for me to manage during the period when the WG was not considering new work items.) So I would like to propose each of the above-listed items as a new work item for the WG. I would also like to solicit feedback about the above-mentioned document, e.g., is it acceptable as a WG draft, would it be better to split it up and ask each this question about each part, does anyone have any technical comments on it? Feedback from other than the usual suspects would be especially valuable ;-) From wwwrun@core3.amsl.com Tue Aug 25 13:46:45 2009 Return-Path: X-Original-To: l3vpn@ietf.org Delivered-To: l3vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6BB9C3A6C92; Tue, 25 Aug 2009 13:46:45 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-l3vpn-2547bis-mcast (Multicast in MPLS/BGP IP VPNs) to Proposed Standard Message-Id: <20090825204645.6BB9C3A6C92@core3.amsl.com> Date: Tue, 25 Aug 2009 13:46:45 -0700 (PDT) Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 20:46:45 -0000 The IESG has received a request from the Layer 3 Virtual Private Networks WG (l3vpn) to consider the following document: - 'Multicast in MPLS/BGP IP VPNs ' 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 substantive comments to the ietf@ietf.org mailing lists by 2009-09-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-2547bis-mcast-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13184&rfc_flag=0 From wwwrun@core3.amsl.com Tue Aug 25 13:47:12 2009 Return-Path: X-Original-To: l3vpn@ietf.org Delivered-To: l3vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6F41628C290; Tue, 25 Aug 2009 13:47:12 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-l3vpn-2547bis-mcast-bgp (BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs) to Proposed Standard Message-Id: <20090825204712.6F41628C290@core3.amsl.com> Date: Tue, 25 Aug 2009 13:47:12 -0700 (PDT) Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 20:47:12 -0000 The IESG has received a request from the Layer 3 Virtual Private Networks WG (l3vpn) to consider the following document: - 'BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs ' 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 substantive comments to the ietf@ietf.org mailing lists by 2009-09-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15061&rfc_flag=0