From erosen@cisco.com Thu Jul 9 10:02:47 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 8936728C1FD for ; Thu, 9 Jul 2009 10:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 5gInhp1I64qM for ; Thu, 9 Jul 2009 10:02:46 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C21B728C179 for ; Thu, 9 Jul 2009 10:02:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,374,1243814400"; d="scan'208";a="211710755" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2009 17:03:02 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n69H31QX015318; Thu, 9 Jul 2009 13:03:01 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n69H31B7007746; Thu, 9 Jul 2009 17:03:01 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 n69H30fJ005353; Thu, 9 Jul 2009 13:03:01 -0400 To: Thomas Morin Subject: Re: LC comments on considerations extranet section In-reply-to: Your message of Fri, 19 Jun 2009 18:02:02 +0200. <4A3BB67A.3060002@orange-ftgroup.com> Date: Thu, 09 Jul 2009 13:03:00 -0400 Message-ID: <5352.1247158980@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=240; t=1247158981; x=1248022981; 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:=20Re=3A=20LC=20comments=20on=20considerations=20e xtranet=20section=20 |Sender:=20 |To:=20Thomas=20Morin=20; bh=qdzviRUrZiZHf+8M5KdMV7EueDlTR7RN89/O5Ad6s3U=; b=mzK3mJojJe0+b80NYho1klZQwySgYN41UcVjKQftv0sJr5zUt/vKxyFkbd rQavEWM39Xw/zX7mNhmbkjfaASpkOrBoozt02Ku6UVa+g/wZinvm2HyDp43I WyLEtRP+4E; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: L3VPN 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: Thu, 09 Jul 2009 17:02:47 -0000 > But I have to agree with you that, since draft-ietf-l3vpn-2547bis-mcast > has unfortunately finally not included Extranet, this section 3.3.6 is > in a delicate position. I don't mind removing it. Good, I guess that's settled. From erosen@cisco.com Thu Jul 9 10:06:29 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 B297128C1F4 for ; Thu, 9 Jul 2009 10:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 nEDK9VlKEou2 for ; Thu, 9 Jul 2009 10:06:28 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 433D228C1D6 for ; Thu, 9 Jul 2009 10:06:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,374,1243814400"; d="scan'208";a="184471620" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2009 17:06:55 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n69H6t3M018257; Thu, 9 Jul 2009 13:06:55 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n69H6tDD010109; Thu, 9 Jul 2009 17:06:55 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 n69H6tpq005415; Thu, 9 Jul 2009 13:06:55 -0400 To: Thomas Morin Subject: Re: LC comment on "considerations" inter-AS section In-reply-to: Your message of Fri, 19 Jun 2009 18:01:58 +0200. <4A3BB676.502@orange-ftgroup.com> Date: Thu, 09 Jul 2009 13:06:55 -0400 Message-ID: <5414.1247159215@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7946; t=1247159215; x=1248023215; 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:=20Re=3A=20LC=20comment=20on=20=22considerations=2 2=20inter-AS=20section=20 |Sender:=20 |To:=20Thomas=20Morin=20; bh=alIRz0pVmjtr+anqjs81Sj4/TNQ6/RWUKaEwdzYpFn4=; b=uDX2Uy9jOFFoX41hOaJ63d6pJXR+R/mJmMy0fTTc+8PMIv2vx/DMo8UAAE 0vC89tzRFiz5p/a/NiCVqqs6Vc61kFDSKSbpRdCpzvg45fHWA0Hr+PahVjY7 y7eappfqgU; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: erosen@cisco.com, L3VPN 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: Thu, 09 Jul 2009 17:06:29 -0000 Thomas> without considering S-PMSIs, there is already a big scaling Thomas> advantage compared to the non-segmented approach (number of I-PMSI Thomas> tunnels in an AS independent of the number of PEs in the remote Thomas> ASes) If one is using one of the options that does not use I-PMSIs, this "big scaling advantage" disappears entirely. So if this is your main basis for requiring segmented P-tunnels, the requirement should be restricted to deployments that use I-PMSIs. By the way, can you explain how, if you use segmented I-PMSIs, you apply the procedures of section 9.1.1 of draft-ietf-l3vpn-mcast-08? Eric> A segmented S-PMSI carries traffic from only one PE, so the number of Eric> S-PMSIs used by an MVPN is still limited only by the total number of Eric> PEs in the MVPN. Thomas> the only limit is virtually the number of C-multicast streams. I was assuming that all the streams from a given PE/MVPN would be aggregated, but you are correct to point out that that is not necessarily the case. This just further supports my point, the segmented inter-AS P-tunnel scheme does not provide any scalability advantage for S-PMSIs. Thomas> aggregation of multiple tunnels into one tunnel does not require Thomas> upstream assigned labels, except possibly if the tunnels are shared Thomas> between distinct VPNs If a number of tunnels (even from the same VPN) are aggregated into a single tunnel when going from the entry ASBR to the exit ASBR of a given AS, please explain how the tunnels are deaggregated at the exit ASBR. In the case of S-PMSIs traversing an intermediate transit AS, an entry ASBR might want to aggregate all the S-PMSIs of a given MVPN into a single P-tunnel that reaches a set of exit ASBRs. However, that should not require each exit ASBR in the set to forward all the traffic of all the S-PMSIs. After all, a given S-PMSI might not have receivers downstream of a given exit ASBR. (Actually, it is not completely clear to me that the spec for segmented S-PMSIs gives you a way to prevent the S-PMSI's data packets from going to each AS containing its MVPN, even in the absence of aggregation, whether or not that AS has any receivers for those data packets. However, that would seem to be a desirable, even essential, feature, that might be a valid "consideration".) Eric> To get the desired scaling improvement, one must aggregate a number of Eric> intra-AS segments of inter-AS tunnels into a single intra-AS P-tunnel. Eric> I don't believe there is a specification of the method for doing this Eric> in a fully automated fashion. Thomas> you could also say that there is no spec of a method for deciding to Thomas> put traffic on an S-PMSI; but that wouldn't be relevant Indeed, that wouldn't be relevant, so I'm not sure why you brought it up. Thomas> it doesn't seem to me that something would preclude automation of Thomas> the merging, this is a purely local decision matter The point is that there are scalability claims that are purely theoretical, in that is it not actually known how to achieve them. This seems like something worth mentioning when lauding the alleged scalability of a particular scheme. Yakov> Let's examine your claim that "in order to use the segmented inter-AS Yakov> procedures, each ASBR must be preconfigured with the MVPNs whose Yakov> trees pass through it". Yakov> it is clear that the only item that involves configuration on ASBRs Yakov> is the RD The configuration in question is the association of an RD with a particular MVPN. The spec doesn't say exactly how you do this, presumably it means providing an RD and then providing a list of RTs, such that, by default at least, the RD is to be used when an Inter-AS I-PMSI A-D route aggregates a set of Intra-AS I-PMSI A-D routes that each carry that exact set of RTs. Yakov> your claim above that "ASBR must be pre-configured with the Yakov> MVPNs whose trees pass through it" totally ignores the fact that Yakov> it applies only to one particular option (option (1) above). Your Yakov> claim is *incorrect* in the context of option (2). I stand corrected, there is indeed an option that does not require the above-mentioned configuration on each ASBR. When that option is used, multiple non-comparable Inter-AS I-PMSI A-D routes may be advertised for a given I-PMSI, which would lead to the use of multiple P-tunnels for that I-PMSI. So the correct statement would be: "the goal of having a single Inter-AS I-PMSI A-D route per MVPN per source AS cannot be met without preconfiguring the ASBRs". I think the corrected statement should be mentioned in any discussion of the scalability of the segmented P-tunnel scheme. Yakov> What is correct though is that section 8.2.1.1 that you refer to is Yakov> incomplete/incorrect. It's hard to believe this wasn't picked up during the extensive review that the docs got during last call. Certainly this needs to be fixed. I'll see if we can get the co-authors to agree on some replacement text. BTW, speaking of things that should have been picked up during last call, section 9.2 of draft-ietf-l3vpn-2547bis-mcast-bgp-07 is a bit confusing, as it does contain the statement: "An ASBR MUST be configured with a set of (import) Route Targets (RTs) that specifies the set of MVPNs supported by the ASBR." This could easily be interpreted as meaning that an ASBR must be configured with a set or RTs specifying the set of MVPNs supported by the ASBR ;-) Later in the paragraph it says: "instead of being configured, the ASBR MAY obtain this set of (import) Route Targets (RTs) by using Route Target Constrain" I think the intention is probably that the ASBR MUST be configurable with the abovementioned set of RTs, but that configuration of the RTs is only required if RT Constrain has not been deployed for those RTs. If that is the actual intention, it should be stated more clearly. There are other paragraphs in that section that use the term "(auto-)configured", and do not make it very clear as to just what the conditions are under which explicit configuration is required. This should be taken into account by the "considerations" document. Also, the following two paragraphs of section 9.2.1 of mcast-bgp-07 would seem to be worth noting in the "considerations" draft: + The default policy for aggregation of Intra-AS I-PMSI A-D routes into an Inter-AS I-PMSI A-D route is that a given Inter-AS I-PMSI A-D route aggregates only the Intra-AS I-PMSI A-D routes that carry exactly the same set of RTs (note that this set may have just one RT). In this case an Inter-AS I-PMSI A-D route originated by an ASBR carries exactly the same RT(s) as the RT(s) carried by the Intra-AS I-PMSI A-D routes that the ASBR aggregates into that Inter-AS I-PMSI A-D route. An implementation MUST support the default policy for aggregation of Intra-AS I- PMSI A-D routes into an Inter-AS I-PMSI A-D route. + The default policy for aggregation could be modified via configuration on the ASBR. An implementation MAY support such functionality. Modified policy MUST include rules for constructing RTs carried by the Inter-AS I-PMSI A-D routes originated by the ASBR. I think this means the following: if the Intra-AS I-PMSI A-D routes of a given MVPN do not all have exactly the same set of RTs, then the ASBRs must be explicitly configured with the "modified policy" for that MVPN. So if there are Inter-AS extranets, Inter-AS Hub and Spoke MVPNS, or any Inter-AS "non-vanilla" MVPNs, explicit configuration on the ASBRs is required for segmented P-tunnels but not for unsegmented P-tunnels. This also seems like something worth noting in the "considerations" draft. From erosen@cisco.com Thu Jul 9 10:13:24 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 859C33A6AA7 for ; Thu, 9 Jul 2009 10:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ldcEYO3D2dIQ for ; Thu, 9 Jul 2009 10:13:23 -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 83CAA3A67CF for ; Thu, 9 Jul 2009 10:13:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,374,1243814400"; d="scan'208";a="49891821" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2009 17:13:50 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n69HDoDk008149; Thu, 9 Jul 2009 13:13:50 -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 n69HDoX6004093; Thu, 9 Jul 2009 17:13:50 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 n69HDoAo005504; Thu, 9 Jul 2009 13:13:50 -0400 To: Thomas Morin Subject: Re: LC Comments on "considerations" scaling analysis In-reply-to: Your message of Fri, 19 Jun 2009 18:01:52 +0200. <4A3BB670.9040407@orange-ftgroup.com> Date: Thu, 09 Jul 2009 13:13:50 -0400 Message-ID: <5503.1247159630@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1991; t=1247159630; x=1248023630; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20LC=20Comments=20on=20=22considerations= 22=20scaling=20analysis=20 |Sender:=20 |To:=20Thomas=20Morin=20; bh=yVxXKoJSN32RxCl2JYue+F//0p95eg/YvEsZAGQaCbc=; b=WIf05ru9X09cFxdPXEvjwBk3R8VoDPy+Y+jHihUihe9A/7jIJN3hDbm27f SQm3Ih9yBYuI1tSJF1hYXgMSd5GTztg0znh4JsheJdpdZJSO1jnsqHLJLQNA wvhYUI0mmK; Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Eric Rosen , L3VPN 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: Thu, 09 Jul 2009 17:13:24 -0000 If you are going to recommend one scheme over another based on a scalability analysis, then the analysis must take into account all the scaling factors. You do not have the option of saying "I didn't consider memory utilization, that's out of scope", or "I didn't consider sparse mode, that's out of scope (even though it is an important factor in virtualyl every deployment)". Further, if you want to draw any conclusions whatsoever based on the analysis of a small subset of the scalability issues, you have to show that that subset contains the bottleneck issues. If the MVPN bottleneck is PE-CE PIM, then you can't say "I'm only considering PE-PE PIM, PE-CE PIM is out of scope". It also helps if the analysis uses a measure of "resource utilization" that has some practical meaning. The sum of the number of cycles expended by all routers has no practical meaning at all; if it did, no one would ever have heard of such notions as "distributed computing" or "datagram networks". If you do a scalability analysis without attending to any of this, the analysis is simply irrelevant, if it happens to be correct within its limited scope. Of course, if you are doing a purely theoretical analysis, with no intended practical application, then of course you can focus in on any isolated issue that you choose. However, I don't think the IETF is the proper publication venue for that. A further issue is that the analysis provided in Appendix A of the "considerations" draft is not correct even within its limited scope, for all the reasons I have detailed in a prior message. These mostly have to do with the failure to properly understand the effects of join suppression. But I'm not sure it's worthwhile to repeat all those points again as part of the same last call. I will just reiterate my request for Appendix A to be removed and for any recommendations depending upon it to be removed. From thomas.morin@orange-ftgroup.com Fri Jul 10 08:54:36 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 452953A693B for ; Fri, 10 Jul 2009 08:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 en2vbIvf46eF for ; Fri, 10 Jul 2009 08:54:35 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 722B028C31B for ; Fri, 10 Jul 2009 08:54:30 -0700 (PDT) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 17:54:56 +0200 Received: from [10.193.15.68] ([10.193.15.68]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 17:54:56 +0200 Message-ID: <4A57644F.8030605@orange-ftgroup.com> Date: Fri, 10 Jul 2009 17:54:55 +0200 From: Thomas Morin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: L3VPN Subject: Re: LC Comments on "considerations" scaling analysis References: <5503.1247159630@erosen-linux> In-Reply-To: <5503.1247159630@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2009 15:54:56.0491 (UTC) FILETIME=[C58273B0:01CA0176] Cc: Eric Rosen 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, 10 Jul 2009 15:54:36 -0000 Hi Eric, working group, Eric Rosen: > I will just reiterate my request for Appendix A to be removed and for any > recommendations depending upon it to be removed. > Indeed, your email only consists in reiterating the arguments of your previous email on the subject. (Ok, not only, I admit: you also use bigger words to sound more convincing.) What I see is that: - your claims that about the analysis in Appendix A are abusive (you still did not produce any quote of something that would be incorrect, and did not address my reply to your claims of incorrectness) - the scalability-related observations of this analysis are used elsewhere in the document among other arguments, not alone, and lead to recommendations that are well balanced between theoretical aspects and practical aspects ("[recommendation] that implementations support both the BGP-based and the full per MPVN PIM peering solutions for PE-PE transmission of customer multicast routing until further operational experience is gained with both solutions") So, I don't see a rationale to follow your request. I have a few more precise comments inlined below (I'll take the time of trying to address your different comment, even if I honestly find them quite abusive, and even if experience tells me that you are unlikely to reply). -Thomas Eric Rosen: > If you are going to recommend one scheme over another based on a scalability > analysis, then the analysis must take into account all the scaling factors. > You do not have the option of saying "I didn't consider memory utilization, > that's out of scope", (I don't get why you say this, memory utilization due to mVPN routing state maintenance *is* accounted for in the analysis in Appendix A) > or "I didn't consider sparse mode, that's out of scope > (even though it is an important factor in virtualyl every deployment)". > Please let me remind you that SSM is a subset of PIM Sparse Mode, so the scenario through which a scalability comparison is made in Appendix A is certainly "sparse mode" ("sparse", if I may insist, as opposed to "dense"). The subset of sparse-mode being looked at in this scenarios (SPTs) happens to be used in most non-SSM deployments, which is why this scenario certainly is relevant beyond SSM alone. If you think that you can make a useful contribution to the document by looking at a non-ASM case, then please go ahead (e.g. something that would result in exposing orders of magnitude significantly different that the one we obtained). > Further, if you want to draw any conclusions whatsoever based on the > analysis of a small subset of the scalability issues, you have to show that > that subset contains the bottleneck issues. If the MVPN bottleneck is PE-CE > PIM, then you can't say "I'm only considering PE-PE PIM, PE-CE PIM is out of > scope". > I am not the one saying that PE-CE PIM is out of scope. The working group charter and the drafts on mVPN being worked on in the WG, do not cover the PE-CE part. The cases where PE-CE scaling is an issue are *not* specific to mVPN, and logically happens to be addressed in the PIM Working group. Following your claim, we would end up saying that "since CE-PE is the bottleneck, then we don't need anything special on the PE-PE side, and then all options for PE-PE mVPN routing can be thus said to scale equally well, and well... let's say that this is true even for deployments will no particular CE-PE scaling issue". And we would totally miss out the fact that (a) for the PE-PE scaling part we have different options with different scaling characteristics impacting *real* deployment scenarios and (b) that the CE-PE scaling part can find solutions on its own. *That* would be irrelevant. > It also helps if the analysis uses a measure of "resource utilization" that > has some practical meaning. The sum of the number of cycles expended by all > routers has no practical meaning at all; if it did, no one would ever have > heard of such notions as "distributed computing" or "datagram networks". > I totally agree with you that a total across multiple equipments has not an interesting meaning in itself. For instance, the total amount of time a message is processed, across all equipements, is in O(#PEx#PEs-joined-to-(S,G)) has no meaning *in itself*. It is not a big or small number intrinsically. It is only when you compare "the total with option X" and "the total with option Y" that you get something carrying a meaning. And... this is what we do: *comparisons* between comparable numbers. I stand that the comparison done is meaningful. (feel free to suggest a better measure, but it seems to me that the *comparison* will lead to very similar results) > If you do a scalability analysis without attending to any of this, the > analysis is simply irrelevant > "If,..., if ..." That makes many "if"s, in your email, for such a strong judgment. > Of course, if you are doing a purely theoretical analysis, with no intended > practical application, then of course you can focus in on any isolated issue > that you choose. However, I don't think the IETF is the proper publication > venue for that. > Oh, big words again... The analysis in appendix A is not purely theoretical, and your claim on the relevance of the analysis does not appear to me as founded. So, while I don't think I am in a position to discuss of the appropriateness of publication by the IETF of a document that I myself co-edit, let me just remind that there has been consensus in this working group to adopt this document, including Appendix A, and that the only comments on the list on this section where made by you, one week before the end of WG last call (nearly seven month after WG adoption). > A further issue is that the analysis provided in Appendix A of the > "considerations" draft is not correct even within its limited scope, for all > the reasons I have detailed in a prior message. These mostly have to do > with the failure to properly understand the effects of join suppression. > But I'm not sure it's worthwhile to repeat all those points again as part of > the same last call. > Except that I extensively replied to you to point some mistakes you made, and explain that "join suppression" is actually taken into account in the analysis. It would be worthwhile if you were able to point at something precise that you think is incorrect (ie. quote and show why/how incorrect). From daniel@olddog.co.uk Fri Jul 10 09:39:53 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 3EC593A6950 for ; Fri, 10 Jul 2009 09:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 AEfq2J4-6Z-f for ; Fri, 10 Jul 2009 09:39:52 -0700 (PDT) Received: from mx-relay.netfirms.com (167-mail-static.netfirms.com [70.35.18.167]) by core3.amsl.com (Postfix) with SMTP id 797863A693A for ; Fri, 10 Jul 2009 09:39:52 -0700 (PDT) Received: (qmail 13977 invoked from network); 10 Jul 2009 16:33:40 -0000 Received: from unknown (HELO Firefly) (dk@redback911.com@81.140.15.32) by q6-relay-norm.netfirms.com with SMTP; 10 Jul 2009 16:33:40 -0000 X-Remote-Host: unknown X-RBL-Msg: none From: "Daniel King" To: Subject: IETF-75 l3vpn agenda (tentative) Date: Fri, 10 Jul 2009 17:33:29 +0100 Message-ID: <000401ca017c$291cdb90$7b5692b0$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoBfChKu1e4GNX+RryWxuKSNXVEXw== Content-Language: en-us 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, 10 Jul 2009 16:39:53 -0000 Hello all, We have uploaded the current IETF-75 l3vpn agenda: http://www.ietf.org/proceedings/09jul/agenda/l3vpn.txt If your presenting during the session please send me your slides no later than Friday, July 24. Br, Dan. From thomas.morin@orange-ftgroup.com Fri Jul 10 10:04:20 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 7EC5528C29B for ; Fri, 10 Jul 2009 10:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 YlLZttdP8SMe for ; Fri, 10 Jul 2009 10:04:19 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 00B063A6E73 for ; Fri, 10 Jul 2009 10:04:08 -0700 (PDT) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 19:04:09 +0200 Received: from [10.193.15.68] ([10.193.15.68]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 19:04:09 +0200 Message-ID: <4A577487.1080808@orange-ftgroup.com> Date: Fri, 10 Jul 2009 19:04:07 +0200 From: Thomas Morin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: erosen@cisco.com Subject: Re: LC comment on "considerations" inter-AS section References: <5414.1247159215@erosen-linux> In-Reply-To: <5414.1247159215@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2009 17:04:09.0340 (UTC) FILETIME=[70CCEBC0:01CA0180] Cc: L3VPN 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, 10 Jul 2009 17:04:20 -0000 Eric, working group, Taking a bit perspective, let me try to summarize why we pursue this thread: - the possible P-tunnel aggregation doable with the segmented inter-AS approach is currently *not* mentioned in the document (and thus not a "claim" of the document as you suggest below) - you brought up this point about P-tunnel aggregation and debate on the associated scaling benefits, this is indeed an additional potential argument for the segmented approach, and thus only tipping the balance just slightly further in favor of that approach (thus, not in the direction of changing the conclusions) From there we have two choices: a - do not talk about this additional potential advantage of the segmented approach b - talk about it and identify the conditions when it provides an advantage for the segmented approach and on what ASBRs need to do for this benefit to happen, and evaluate when the advantage is big or small For sake of completeness, I guess we should go the (b) way and consolidate the different observations made to add content in section 3.5. Other opinions are welcome. That said, a few elements with reference to the points you brought up: - on whether or not aggregation benefits S-PMSI: P-tunnel aggregation in the segmented approach is not only provided for I-PMSI, but also for S-PMSI, and described in section 12.2.1 of draft-ietf-2547bis-mcast-bgp - on whether or not you can avoid sending traffic uselessly in other ASes : this is mentioned in section 9.2.3.6 of draft-ietf-2547bis-mcast-bgp (the whole supersection is on I-PMSI route processing, but the text in 9.2.3.6 would apply equally well to S-PMSIs, possibly an improvement to bring there) - some other questions you ask me are answered, or should be answered in draft-ietf-2547bis-mcast and/or draft-ietf-2547bis-mcast-bgp: if they are not, the fix would be supposed to be made there, and not in draft-ietf-l3vpn-mvpn-considerations -Thomas From root@core3.amsl.com Fri Jul 10 10:15: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 4B3B43A6858; Fri, 10 Jul 2009 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l3vpn-mvpn-considerations-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090710171501.4B3B43A6858@core3.amsl.com> Date: Fri, 10 Jul 2009 10:15: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: Fri, 10 Jul 2009 17:15:01 -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 : Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution Author(s) : T. Morin, et al. Filename : draft-ietf-l3vpn-mvpn-considerations-04.txt Pages : 33 Date : 2009-07-10 More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks. To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-considerations-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-mvpn-considerations-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-10100821.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Jul 10 14:15: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 9A4E63A6E93; Fri, 10 Jul 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l3vpn-ospfv3-pece-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090710211501.9A4E63A6E93@core3.amsl.com> Date: Fri, 10 Jul 2009 14:15: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: Fri, 10 Jul 2009 21:15:01 -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 : OSPFv3 as a PE-CE routing protocol Author(s) : P. Pillay-Esnault, et al. Filename : draft-ietf-l3vpn-ospfv3-pece-03.txt Pages : 21 Date : 2009-07-10 Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ospfv3-pece-03.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-ospfv3-pece-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-10141418.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 13 10:30:03 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 51E7A28C55A; Mon, 13 Jul 2009 10:30: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-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713173003.51E7A28C55A@core3.amsl.com> Date: Mon, 13 Jul 2009 10:30: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: Mon, 13 Jul 2009 17:30:03 -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-03.txt Pages : 24 Date : 2009-7-13 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-7-13101532.I-D@ietf.org> --NextPart-- From erosen@cisco.com Tue Jul 14 09:12:29 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 52F3428C346 for ; Tue, 14 Jul 2009 09:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 ABkdqIlxP4wI for ; Tue, 14 Jul 2009 09:12:28 -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 121B428C358 for ; Tue, 14 Jul 2009 09:12:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,398,1243814400"; d="scan'208";a="50388550" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2009 16:10:35 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6EGAZtd020449; Tue, 14 Jul 2009 12:10:35 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6EGAYol006160; Tue, 14 Jul 2009 16:10:35 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 n6EGAYXp019556; Tue, 14 Jul 2009 12:10:34 -0400 To: Thomas Morin Subject: Re: LC comment on "considerations" inter-AS section In-reply-to: Your message of Fri, 10 Jul 2009 19:04:07 +0200. <4A577487.1080808@orange-ftgroup.com> Date: Tue, 14 Jul 2009 12:10:34 -0400 Message-ID: <19555.1247587834@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1974; t=1247587835; x=1248451835; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20LC=20comment=20on=20=22considerations=2 2=20inter-AS=20section=20 |Sender:=20 |To:=20Thomas=20Morin=20; bh=MWmGXmDbMz9e0LB9lEJ4z5fczfRjojPBWIiMVNDHre8=; b=kMA1bZzrnFOykgsZxpxl0fIOiUcGR1ejoJB0R+DAcd8SzjE8D7WeDL/DoM CMOyFn6aznJiBk+X2tAI1Pf5HPwK7BiL0+O41H7hqWvaq4gOVx95IJZz7cKA /ufDDhbWap; Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: erosen@cisco.com, L3VPN 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: Tue, 14 Jul 2009 16:12:29 -0000 > on whether or not you can avoid sending traffic uselessly [on S-PMSIs] in other > ASes : this is mentioned in section 9.2.3.6 of > draft-ietf-2547bis-mcast-bgp (the whole supersection is on I-PMSI route > processing, but the text in 9.2.3.6 would apply equally well to S-PMSIs, > possibly an improvement to bring there) I thought the policy of the "considerations" draft was to take account only of what is written in the base specs, not of "possible improvements". Obviously this policy is not being applied in an even-handed manner. Even if we grant that 9.2.3.6 could be applied to S-PMSIs, there doesn't seem to be anything in the existing specs that prevents an S-PMSI A-D route from creating intra-AS segments connecting the ASBRs in all ASes of the VPN, whether or not the multicast flow or flows bound to the PMSI are needed. The procedure of 9.2.3.6 allows an ASBR to dynamically create a set of filters for each P-tunnel, based on the C-multicast routes that are passing through the ASBR. (This seems to make certain assumptions about the deployment.) Then these filters have to be applied to data packets arriving on that P-tunnel. Creating LSP tunnels that aren't needed, and then applying IP-based filtering to the MPLS packets traveling on those tunnels, does not seem to me to be a particularly good scaling technique. But let me guess, S-PMSI scaling is out of scope, right? ;-) > you brought up this point about P-tunnel aggregation and debate on the > associated scaling benefits, this is indeed an additional potential > argument for the segmented approach Sure, just explain how one does it in practice, and why it can't also be done with the non-segmented approach. > some other questions you ask me are answered, or should be answered in > draft-ietf-2547bis-mcast and/or draft-ietf-2547bis-mcast-bgp No doubt those issues are all out of scope ;-) From thomas.morin@orange-ftgroup.com Wed Jul 15 00:59:20 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 3504A3A6B29 for ; Wed, 15 Jul 2009 00:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 bjEC8wrKlVjD for ; Wed, 15 Jul 2009 00:59:19 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id D71AD3A6AD4 for ; Wed, 15 Jul 2009 00:59:18 -0700 (PDT) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 09:58:46 +0200 Received: from [10.193.15.68] ([10.193.15.68]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 09:58:45 +0200 Message-ID: <4A5D8C34.5040801@orange-ftgroup.com> Date: Wed, 15 Jul 2009 09:58:44 +0200 From: Thomas Morin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: erosen@cisco.com Subject: Re: LC comment on "considerations" inter-AS section References: <19555.1247587834@erosen-linux> In-Reply-To: <19555.1247587834@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2009 07:58:45.0668 (UTC) FILETIME=[14099640:01CA0522] Cc: L3VPN 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, 15 Jul 2009 07:59:20 -0000 Hi Eric, working group, Eric Rosen: >> on whether or not you can avoid sending traffic uselessly [on S-PMSIs] in other >> ASes : this is mentioned in section 9.2.3.6 of >> draft-ietf-2547bis-mcast-bgp (the whole supersection is on I-PMSI route >> processing, but the text in 9.2.3.6 would apply equally well to S-PMSIs, >> possibly an improvement to bring there) >> > > I thought the policy of the "considerations" draft was to take account only > of what is written in the base specs, not of "possible improvements". > Obviously this policy is not being applied in an even-handed manner. > Not at all, my comment that you quote was a contribution to the discussion you started about P-tunnel aggregation, which is not yet covered by the draft. If we find that this point has to be covered, like for the rest of the document, we'll only talk about stuff that is described in WG specifications. > But let me guess, S-PMSI scaling is out of scope, right? ;-) > [...] > > No doubt those issues are all out of scope ;) As co-editor of the document, I would greatly appreciate if you could extend the scope of *your* comments beyond irony and smileys, to include constructive and motivated propositions to amend the document. For what relates to the discussion in this thread (inter-AS and P-tunnel aggregation): - whether you find something in the document that you disagree with ; if yes, then please quote and explain what you find incorrect - or you think that something is missing, and then ideally a contribution would be the best, or at least guidelines on what we should add along with a rationale on why it is important to cover Thank you, -Thomas From zubair.ahmad@orange-ftgroup.com Wed Jul 15 12:56:05 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 9906328C162 for ; Wed, 15 Jul 2009 12:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] 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 T037D4zG+QxP for ; Wed, 15 Jul 2009 12:56:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 4549028C14E for ; Wed, 15 Jul 2009 12:56:02 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 7D69437438B for ; Wed, 15 Jul 2009 21:55:23 +0200 (CEST) Received: from PWEXCB10.usa.francetelecom.fr (unknown [10.112.0.68]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 1AA3370002 for ; Wed, 15 Jul 2009 21:55:23 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0586.2CF23780" Subject: MPLS 2009 Conference - Washington DC (Oct 25-28) Date: Wed, 15 Jul 2009 15:55:17 -0400 Message-ID: <7C5C5ED440632B4DAE601971324975F505870C@PWEXCB10.usa.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS 2009 Conference - Washington DC (Oct 25-28) Thread-Index: AcoFhizfefp1xt8TSbKw9SzoQq8YJw== From: To: 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, 15 Jul 2009 19:56:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0586.2CF23780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As many of the topics in the annual MPLS conference have been of interest= to members of the L3VPN working group in the past, I wanted to indicate that the conference program has been published and the= registration is now open=2E Regards, Zubair=20 PROGRAM ANNOUNCEMENT AND REGISTRATION FOR MPLS 2009 - OCTOBER 25-28,= WASHINGTON DC Registration for MPLS2009 (October 25-28, Omni Shoreham Hotel in= Washington), the 12th annualInternational Conference on MPLS and related new technologies is now open at: http://www=2Eisocore=2Ecom/mpls2009/registration/attendees=2Ehtm= =20 MPLS 2009 will include an extensive four day program consisting of= tutorials, technical sessions, panels, and exhibits=2E The key topics to be discussed at this year's conference include: Scaling MPLS, MPLS= transport profile, Carrier Ethernet/MPLS deployments and experiences, Future technologies, Multicast and MPLS, Mobile and wireless backhaul,= Resiliency, and OAM aspects, GMPLS, and emerging applications=2E The complete program is available at: http://www=2Eisocore=2Ecom/mpls2009/program/technical_sessions=2Ehtm= =20 The event will also have an exhibit floor, where leading network equipment= manufacturers will showcase their new offerings, the list of current sponsors is available at: http://www=2Eisocore=2Ecom/mpls2009/sponsors/sponsors=2Ehtm =20 The conference hotel is the Omni Shoreham Hotel in Washington DC=2E Please= note that there are only a limited number of rooms available this year at a reduced rate=2E Reservations can be made at: http://www=2Eisocore=2Ecom/mpls2009/hotel=2Ehtm =20 Isocore once again will showcase live the readiness of leading network= technologies at the Public Interop demonstration on October 29 at Isocore Internetworking Lab=2E The details are available at - http://www= =2Eisocore=2Ecom/mpls2009/program/inter_op=2Ehtm =20 =20 ********************************* This message and any attachments (the "message") are confidential and= intended solely for the addressees=2E=20 Any unauthorised use or dissemination is prohibited=2E Messages are susceptible to alteration=2E=20 France Telecom Group shall not be liable for the message if altered,= changed or falsified=2E If you are not the intended addressee of this message, please cancel it= immediately and inform the sender=2E ******************************** ------_=_NextPart_001_01CA0586.2CF23780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As many of= the topics in the annual MPLS conference have been of interest to members= of the L3VPN working group in the past, I wanted= to
indicate that the conference program has been published and the= registration is now open=2E

Regards,
Zubair=

PROGRAM ANNOUNCEMENT AND REGISTRATION FOR MPLS 2009 -= OCTOBER 25-28, WASHINGTON DC

Registration for MPLS2009= (October 25-28, Omni Shoreham Hotel in Washington), the 12th= annualInternational Conference on MPLS and related
new technologies is= now open at:

http://www= =2Eisocore=2Ecom/mpls2009/registration/attendees=2Ehtm

MPLS 2009= will include an extensive four day program consisting of tutorials,= technical sessions, panels, and exhibits=2E The key topics to
be= discussed at this year's conference include: Scaling MPLS, MPLS transport= profile, Carrier Ethernet/MPLS deployments and experiences,
Future= technologies, Multicast and MPLS, Mobile and wireless backhaul,= Resiliency, and OAM aspects, GMPLS, and emerging applications=2E= The
complete program is available at:

http://www=2Eisocore=2Ecom/mpls2009/program/technical_sessions= =2Ehtm

The event will also have an exhibit floor, where leading= network equipment manufacturers will showcase their new offerings, the= list of
current sponsors is available at:

http://www=2Eisocore=2Ecom/mpls2009/sponsors/sponsors= =2Ehtm

The conference hotel is the Omni Shoreham Hotel in= Washington DC=2E Please note that there are only a limited number of rooms= available this year
at a reduced rate=2E Reservations can be made= at:

http://www=2Eisocore=2Ecom/mpls2009/hotel= =2Ehtm

Isocore once again will showcase live the readiness of= leading network technologies at the Public Interop demonstration on= October 29 at
Isocore Internetworking Lab=2E The details are available= at - http://www=2Eisocore= =2Ecom/mpls2009/program/inter_op=2Ehtm

 
 
*********************************
This message and any attachments (the "message") are confidential and= intended solely for the addressees=2E
Any unauthorised use or dissemination is prohibited=2E
Messages are susceptible to alteration=2E
France Telecom Group shall not be liable for the message if altered,= changed or falsified=2E
If you are not the intended addressee of this message, please cancel it= immediately and inform the sender=2E
********************************
------_=_NextPart_001_01CA0586.2CF23780-- From erosen@cisco.com Fri Jul 17 07:15:18 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 1923A3A6856 for ; Fri, 17 Jul 2009 07:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 PK+L9BcWp0NN for ; Fri, 17 Jul 2009 07:15:16 -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 B6FE33A67E5 for ; Fri, 17 Jul 2009 07:15:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,417,1243814400"; d="scan'208";a="50804432" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Jul 2009 14:14:38 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6HEEc3f023507; Fri, 17 Jul 2009 10:14:38 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6HEEcR9025616; Fri, 17 Jul 2009 14:14:38 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 n6HEEbYV023015; Fri, 17 Jul 2009 10:14:37 -0400 To: l3vpn@ietf.org Subject: Comments on draft-raggarwa-l3vpn-bgp-mvpn-extranet-00.txt Date: Fri, 17 Jul 2009 10:14:37 -0400 Message-ID: <23014.1247840077@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19576; t=1247840078; x=1248704078; 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:=20Comments=20on=20draft-raggarwa-l3vpn-bgp-mvpn-e xtranet-00.txt |Sender:=20 |To:=20l3vpn@ietf.org; bh=UIrAOmO6Qtn4XJ8b8cvSAXllrneaMX+UTqSWEJBLZvY=; b=xog83Ybn4ZLqaT59F1Pyl+zJmjjFAsLv5/JMf9Z/h0qcL2Nt52CW+HaW9J Wp5qinlOtG6Fy9Hev1q3zh2UAx3HXK1Dhggr0ZpErmTbsJ4w9X12PHPWcmEL rn9IF/qZYY; 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: Fri, 17 Jul 2009 14:15:18 -0000 I have a number of comments on this draft. I've placed them in-line, look for lines beginning with ****. 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. 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 procedures in section 8 of draft-rosen-l3vpn-mvpn-mspmsi do not **** have the strong address restriction, but only the weak one. 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". 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? 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. 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. 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. 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. 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? **** 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. 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. 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? **** 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. 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 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. 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. 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. **** 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. **** 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. **** 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. From erosen@cisco.com Thu Jul 23 08:22:52 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 BAE7A3A6A62 for ; Thu, 23 Jul 2009 08:22:52 -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 N329yqvg0AvH for ; Thu, 23 Jul 2009 08:22:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 818C43A6856 for ; Thu, 23 Jul 2009 08:22:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,255,1246838400"; d="scan'208";a="51507428" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2009 15:21:15 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6NFLFqd004099; Thu, 23 Jul 2009 11:21:15 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6NFLFSv019993; Thu, 23 Jul 2009 15:21:15 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 n6NFLFkS016641; Thu, 23 Jul 2009 11:21:15 -0400 To: l3vpn@ietf.org Subject: Wildcard bindings for S-PMSIs X-Mailer: MH-E 8.0.3; nmh 1.2; GNU Emacs 22.1.1 Date: Thu, 23 Jul 2009 11:21:15 -0400 Message-ID: <16640.1248362475@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2988; t=1248362475; x=1249226475; 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:=20Wildcard=20bindings=20for=20S-PMSIs |Sender:=20 |To:=20l3vpn@ietf.org; bh=yAWfxGW2LL4TvzVMJnuaB2dU/WBToVJLRCRBE73Sq9o=; b=iTznHUnBSTfkGLBJgCPDZqeK0o810eF18wrgxJEUuz/TXW+i3tm9OLvu07 BA5CUB3WA7E6c0iMmbBnLizdZeLeM71PKjEyJ69fJ3ewWQwYAZMrbBGTFOg1 m60sbEmxzY; 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: Thu, 23 Jul 2009 15:22:52 -0000 I have read draft-rekhter-mvpn-wildcard-spmsi-00.txt with interest. I am glad to see others in the WG show interest in the use of "wild cards", as this capability has been documented for quite some time in draft-rosen-l3vpn-mvpn-mspmsi, sections 4, 5, and 6. Mostly draft-rekhter is compatible with draft-rosen, though the former specifies only a subset of what is specified in the latter. There are a couple of substantive, though minor, differences which should be discussed by the WG. - In draft-rosen, a (*,G) wild card is only legal when G is in the ASM group address range. In draft-rekhter, this restriction is not imposed, My thinking here is that if G is not an ASM group, there is no real use for (*,G) and its appearance is most likely an error. However, if anyone knows of a practical application for (*,G) wild card when G is an SSM group, it would be interesting to learn of it. - In draft-rosen, procedures are defined for using the (*,*) wild card only when the S-PMSI is instantiated by a bidirectional P-tunnel. In draft-rekhter, the (*,*) wild card is allowed when the S-PMSI is instantiated by a unidirectional P-tunnel. On reflection, this does seem like it could be useful, especially if there is no I-PMSI and one is using a BGP control plane. - In draft-rekhter, it is suggested (though not stated explicitly) that the wild cards are useful for assigning BIDIR-PIM C-flows to S-PMSIs that are instantiated by unidirectional P-tunnels. This is omitted from draft-rosen. Perhaps the use of wild cards in this manner may be useful if BIDIR-PIM is supported using the procedures of section 11.1 of draft- ietf-l3vpn-2547bis-mcast-08. I don't think it would be useful if BIDIR-PIM is supported using the procedures of section 11.2 of draft-ietf- l3vpn-2547bis-mcast-08. This needs to be clarified. These are good points to discuss, but generally if one publishes a draft that is largely a subset of an existing draft, one is expected at least to reference the existing draft, to point out the differences, and to explain why a new draft might be needed. I don't see any other substantive differences, or indeed any major disagreement. Draft-rehkter has copied the encoding for the S-PMSI A-D routes from draft-rosen. The main difference is that draft-rekhter has a much more limited scope: - The spec in draft-rekhter only covers the case where BGP is the PE-PE control plane, while the spec in draft-rosen covers both that case and the case where PIM is the PE-PE control plane. (And for the case where PIM is the PE-PE control plane, also covers the use of the S-PMSI Join messages.) - The spec in draft-rekhter does not cover the use of wild cards with bidirectional P-tunnels. The text in draft-rekhter that justifies the use of wild cards is not cut-and-pasted from draft-rosen, but doesn't seem to say anything significantly different. From mnapierala@att.com Thu Jul 23 13:51:38 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 0521E3A6B87 for ; Thu, 23 Jul 2009 13:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 vmFvmqk7fJW4 for ; Thu, 23 Jul 2009 13:51:37 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with SMTP id 019FB3A6849 for ; Thu, 23 Jul 2009 13:51:36 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mnapierala@att.com X-Msg-Ref: server-3.tower-161.messagelabs.com!1248382089!11286643!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 25597 invoked from network); 23 Jul 2009 20:48:09 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Jul 2009 20:48:09 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6NKm8LB027531 for ; Thu, 23 Jul 2009 16:48:09 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6NKm61J027516 for ; Thu, 23 Jul 2009 16:48:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Wildcard bindings for S-PMSIs Date: Thu, 23 Jul 2009 16:48:04 -0400 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A20031E4548@misout7msgusr7e.ugd.att.com> In-Reply-To: <16640.1248362475@erosen-linux> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wildcard bindings for S-PMSIs Thread-Index: AcoLqfApRiqr1o3rTKOB9rhVa50jlAALLELg References: <16640.1248362475@erosen-linux> From: "NAPIERALA, MARIA H, ATTLABS" To: , 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: Thu, 23 Jul 2009 20:51:38 -0000 I agree with this assessment. The wildcard encoding in draft-rekhter-mvpn-wildcard-spmsi is identical to that already defined in draft-rosen-l3vpn-mvpn-mspmsi, along with its most significant usage. Also, it is not necessary to restrict the usage of the wildcard bindings for S-PMSIs to BGP-only MVPN signaling, which is what draft-rekhter-mvpn-wildcard-spmsi does, quote: "The procedures specified in this document assume that BGP is used for transmission of MVPN customers' routing information within the service provider(s) infrastructure."=20 The draft-rosen-l3vpn-mvpn-mspmsi does not impose such a restriction. It is very confusing for network operators if multiple drafts exist that define the same functionality in exactly the same way. This does not promote the interoperability of the same functionality between router vendors.=20 Maria > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Eric Rosen > Sent: Thursday, July 23, 2009 11:21 AM > To: l3vpn@ietf.org > Subject: Wildcard bindings for S-PMSIs >=20 > I have read draft-rekhter-mvpn-wildcard-spmsi-00.txt with interest. I > am > glad to see others in the WG show interest in the use of "wild cards", > as > this capability has been documented for quite some time in > draft-rosen-l3vpn-mvpn-mspmsi, sections 4, 5, and 6. >=20 > Mostly draft-rekhter is compatible with draft-rosen, though the former > specifies only a subset of what is specified in the latter. There are > a > couple of substantive, though minor, differences which should be > discussed > by the WG. >=20 > - In draft-rosen, a (*,G) wild card is only legal when G is in the ASM > group > address range. In draft-rekhter, this restriction is not imposed, >=20 > My thinking here is that if G is not an ASM group, there is no real > use > for (*,G) and its appearance is most likely an error. However, if > anyone > knows of a practical application for (*,G) wild card when G is an SSM > group, it would be interesting to learn of it. >=20 > - In draft-rosen, procedures are defined for using the (*,*) wild card > only > when the S-PMSI is instantiated by a bidirectional P-tunnel. In > draft-rekhter, the (*,*) wild card is allowed when the S-PMSI is > instantiated by a unidirectional P-tunnel. >=20 > On reflection, this does seem like it could be useful, especially if > there is no I-PMSI and one is using a BGP control plane. >=20 > - In draft-rekhter, it is suggested (though not stated explicitly) that > the > wild cards are useful for assigning BIDIR-PIM C-flows to S-PMSIs that > are > instantiated by unidirectional P-tunnels. This is omitted from > draft-rosen. Perhaps the use of wild cards in this manner may be > useful > if BIDIR-PIM is supported using the procedures of section 11.1 of > draft- > ietf-l3vpn-2547bis-mcast-08. I don't think it would be useful if > BIDIR-PIM is supported using the procedures of section 11.2 of draft- > ietf- > l3vpn-2547bis-mcast-08. This needs to be clarified. >=20 > These are good points to discuss, but generally if one publishes a > draft > that is largely a subset of an existing draft, one is expected at least > to > reference the existing draft, to point out the differences, and to > explain > why a new draft might be needed. >=20 > I don't see any other substantive differences, or indeed any major > disagreement. Draft-rehkter has copied the encoding for the S-PMSI A-D > routes from draft-rosen. The main difference is that draft-rekhter has > a > much more limited scope: >=20 > - The spec in draft-rekhter only covers the case where BGP is the PE-PE > control plane, while the spec in draft-rosen covers both that case > and the > case where PIM is the PE-PE control plane. (And for the case where > PIM is > the PE-PE control plane, also covers the use of the S-PMSI Join > messages.) >=20 > - The spec in draft-rekhter does not cover the use of wild cards with > bidirectional P-tunnels. >=20 > The text in draft-rekhter that justifies the use of wild cards is not > cut-and-pasted from draft-rosen, but doesn't seem to say anything > significantly different. >=20 >=20 >=20 From yakov@juniper.net Tue Jul 28 22:57:26 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 5D19E3A6A45 for ; Tue, 28 Jul 2009 22:57:26 -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 QxJNaLx6ul-8 for ; Tue, 28 Jul 2009 22:57:25 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id E09CF3A6809 for ; Tue, 28 Jul 2009 22:57:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSm/kxSjI6q2hvzQ73hHI5r67m8vDSQM5@postini.com; Tue, 28 Jul 2009 22:57:26 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; Tue, 28 Jul 2009 22:51:02 -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); Tue, 28 Jul 2009 22:51:01 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 22:51:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jul 2009 22:51:00 -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 n6T5p0d00842; Tue, 28 Jul 2009 22:51:00 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200907290551.n6T5p0d00842@magenta.juniper.net> To: erosen@cisco.com Subject: Re: Wildcard bindings for S-PMSIs In-Reply-To: <16640.1248362475@erosen-linux> References: <16640.1248362475@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Thu, 23 Jul 2009 11:21:15 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <87930.1248846660.1@juniper.net> Date: Tue, 28 Jul 2009 22:51:00 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 29 Jul 2009 05:51:00.0793 (UTC) FILETIME=[8D32FA90:01CA1010] 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: Wed, 29 Jul 2009 05:57:26 -0000 Eric, > I have read draft-rekhter-mvpn-wildcard-spmsi-00.txt with interest. I am > glad to see others in the WG show interest in the use of "wild cards", as > this capability has been documented for quite some time in > draft-rosen-l3vpn-mvpn-mspmsi, sections 4, 5, and 6. Just for the record, the authors of MVPN and BGP-MVPN specs discussed the use of wildcards well before you published draft-rosen-l3vpn-mvpn-msmsi. > Mostly draft-rekhter is compatible with draft-rosen, though the former > specifies only a subset of what is specified in the latter. There are a Yes, draft-rekhter specifies only a subset of what is specified in draft-rosen, as the latter specifies not just the use of wild cards, but plenty of other stuff as well. However, if we focus on just the wildcard part of draft-rosen, then your claim that draft-rekhter "specifies only a subset of what is specified" in draft-rosen is incorrect. More on this below. > couple of substantive, though minor, differences which should be discussed > by the WG. > > - - In draft-rosen, a (*,G) wild card is only legal when G is in the ASM group > address range. In draft-rekhter, this restriction is not imposed, > > My thinking here is that if G is not an ASM group, there is no real use > for (*,G) and its appearance is most likely an error. However, if anyone > knows of a practical application for (*,G) wild card when G is an SSM > group, it would be interesting to learn of it. In draft-rekhter a (*, G) wildcard is legal when G is either in the ASM range, or in the Bidir range. Both are useful. > - - In draft-rosen, procedures are defined for using the (*,*) wild card only > when the S-PMSI is instantiated by a bidirectional P-tunnel. In > draft-rekhter, the (*,*) wild card is allowed when the S-PMSI is > instantiated by a unidirectional P-tunnel. > > On reflection, this does seem like it could be useful, especially if > there is no I-PMSI and one is using a BGP control plane. You just provided an example that shows that contrary to your claim, what is in draft-rekhter is *more* than "only a subset" of what is in draft-rosen. > - - In draft-rekhter, it is suggested (though not stated explicitly) that the > wild cards are useful for assigning BIDIR-PIM C-flows to S-PMSIs that are > instantiated by unidirectional P-tunnels. This is omitted from > draft-rosen. Now you provided yet another example that shows that contrary to your claim, what is in draft-rekhter is *more* than "only a subset" of what is in draft-rosen. Yet another example that shows that contrary to your claim, what is in draft-rekhter is *more* than "only a subset" of what is in draft-rosen is the ability to bind (C-S, C-G) flows flowing on C-SPT to a (C-*, C-G) S-PMSI. Moreover, (C-S, C-*) S-PMSI in the -01 version of the draft is yet another example that shows that contrary to your claim, what is in draft-rekhter is *more* than "only a subset" of what is in draft-rosen. > Perhaps the use of wild cards in this manner may be useful > if BIDIR-PIM is supported using the procedures of section 11.1 of draft- > ietf-l3vpn-2547bis-mcast-08. So, we agreed on that. > I don't think it would be useful if > BIDIR-PIM is supported using the procedures of section 11.2 of draft-ietf- > l3vpn-2547bis-mcast-08. This needs to be clarified. While you "don't think it would be useful if BIDIR-PIM is supported using the procedures of section 11.2", I think to the contrary. Namely that the wildcard is useful for assigninng BIDIR-PIM C-flows to S-PMSIs that are instantiated by unidirectional P-tunnels using the procedures of section 11.2. > These are good points to discuss, but generally if one publishes a draft > that is largely a subset of an existing draft, one is expected at least to > reference the existing draft, to point out the differences, and to explain > why a new draft might be needed. Your claim about "a subset", as illustrated above, is incorrect. > I don't see any other substantive differences, or indeed any major > disagreement. Draft-rehkter has copied the encoding for the S-PMSI A-D > routes from draft-rosen. Wrt the encoding, both draft-rekhter and draft-rosen rely on the encoding specified in BGP-MVPN. Both draft-rosen and draft-rekhter use the 0/0 prefix encoding to indicate the "match all" semantics. Use of the 0/0 prefix encoding to indicate the "match all semantics" well predates draft-rosen. > The main difference is that draft-rekhter has a > much more limited scope: Your claim that "draft-rekhter has a much more limited scope", is incorrect, as draft-rekhter covers quite a few cases that are not in draft-rosen. > - - The spec in draft-rekhter only covers the case where BGP is the PE-PE > control plane, while the spec in draft-rosen covers both that case and the > case where PIM is the PE-PE control plane. (And for the case where PIM is > the PE-PE control plane, also covers the use of the S-PMSI Join messages.) > > - - The spec in draft-rekhter does not cover the use of wild cards with > bidirectional P-tunnels. This is because according to 6.4.4 of draft-ietf-l3vpn-2547bis-mcast-08.txt: Specification of the procedures for assigning C-flows to mLDP MP2MP LSPs that serve as P-tunnels is outside the scope of this document. > The text in draft-rekhter that justifies the use of wild cards is not > cut-and-pasted from draft-rosen, but doesn't seem to say anything > significantly different. Wrt "doesn't seem to say anything significantly different", I disagree, as the text in draft-rekhter is specified in terms of the changes to the currently specified procedures in BGP-MVPN for handling S-PMSI, while the text in draft-rosen does *not*. Yakov. From Mark.Fine@alcatel-lucent.com Wed Jul 29 08:35:32 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 A5F573A6EA3 for ; Wed, 29 Jul 2009 08:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 XgSogVQJRlct for ; Wed, 29 Jul 2009 08:35:32 -0700 (PDT) Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 003433A696F for ; Wed, 29 Jul 2009 08:35:31 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id n6TFZXNo027378 for ; Wed, 29 Jul 2009 10:35:33 -0500 Received: from usmovdsc10.eng.timetra.com ([172.22.216.4]) by usdalsbhs01.ad3.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 10:35:33 -0500 Message-Id: <4F8E3575-36C6-47EB-A641-E827AA4ADB82@alcatel-lucent.com> From: Mark Fine To: l3vpn@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Discoverable MVPN Configuration with BGP Auto-Discovery Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 08:35:28 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 29 Jul 2009 15:35:33.0230 (UTC) FILETIME=[360028E0:01CA1062] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 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, 29 Jul 2009 15:35:32 -0000 The following draft and slides were presented this morning at the l3vpn session in Stockholm: http://www.ietf.org/proceedings/75/slides/l3vpn-2.pdf http://tools.ietf.org/html/draft-mfine-l3vpn-mvpn-cfg-00 This work is motivated by real multi-vendor non-interoperability issues experienced in lab that were raised at the last l3vpn session in San Francisco. The authors are interested in comments and feedback, especially with respect to open issues: * Should BGP attributes be used instead of size-constrained BGP extended communities? * Should configuration TLVs be used instead of static configuration bitfields? (e.g., like in RFC 5561 "LDP Capabilities") * How should PE's that do not advertise MVPN auto-discovery routes be handled? (e.g., S-PMSI only configurations) Thanks! Mark From erosen@cisco.com Fri Jul 31 11:47:13 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 003CE28C320 for ; Fri, 31 Jul 2009 11:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_82=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 IEf7WslJktI5 for ; Fri, 31 Jul 2009 11:47:12 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8812228C321 for ; Fri, 31 Jul 2009 11:47:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,303,1246838400"; d="scan'208";a="52432563" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2009 18:47:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6VIlD3Q002784; Fri, 31 Jul 2009 14:47:13 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6VIlCRK013570; Fri, 31 Jul 2009 18:47:13 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 n6VIlC8I001632; Fri, 31 Jul 2009 14:47:12 -0400 To: Yakov Rekhter Subject: Re: Wildcard bindings for S-PMSIs In-reply-to: Your message of Tue, 28 Jul 2009 22:51:00 -0700. <200907290551.n6T5p0d00842@magenta.juniper.net> Date: Fri, 31 Jul 2009 14:47:12 -0400 Message-ID: <1631.1249066032@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3414; t=1249066033; x=1249930033; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20Wildcard=20bindings=20for=20S-PMSIs=20 |Sender:=20 |To:=20Yakov=20Rekhter=20; bh=mp48ghX+01NUcnCXK8Xdw6Vs+RycwAWEu4DxbBb1kW4=; b=k9cxPSzVnsD41oTV1qPAKF8NQvH0ADdcXs6DBzhYV7r6GK/E8Avog3E98C ilmg08vbUwUSjo0YFodEHLApVV70bWO2kYRVyRuQVLQRPbhe3CiALMMHYUVj vrseZIW5/W; Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: erosen@cisco.com, l3vpn@ietf.org 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: Fri, 31 Jul 2009 18:47:13 -0000 Yakov> In draft-rekhter a (*, G) wildcard is legal when G is either in the Yakov> ASM range, or in the Bidir range. I don't think there is any such thing as "the Bidir range", as Bidir is just a form of ASM. Draft-rekhter seems to allow (*,G) when G is in the SSM range, which is what I think is questionable. Yakov> Wrt "doesn't seem to say anything significantly different", I Yakov> disagree,as the text in draft-rekhter is specified in terms of the Yakov> changes to the currently specified procedures in BGP-MVPN for Yakov> handling S-PMSI, while the text in draft-rosen does *not* Let's not confuse "saying something differently" with "saying something different". In draft-rosen, the procedures are specified in terms of the multicast states of the mVRF. I believe this results in the same behavior, but the applicability is not restricted only to the case where BGP is used. That's one of the reasons that draft-rekhter is just a subset of the "wild card" specification of draft-rekhter. Eric> - The spec in draft-rekhter does not cover the use of wild cards with Eric> bidirectional P-tunnels. Yakov> This is because according to 6.4.4 of draft-ietf-l3vpn-2547bis- Yakov> mcast-08.txt: "Specification of the procedures for assigning C-flows to mLDP MP2MP LSPs that serve as P-tunnels is outside the scope of this document." I don't follow this line of reasoning; you omitted an important topic from one document because that topic is outside the scope of some other document? Well, let me call your attention to section 4.3 of mcast-bgp-07: Usage of other values of the Multicast Source Length and Multicast Group Length fields [other than 32 for IPv4 and 128 for IPv6] is outside the scope of this document. So by your own reasoning, the entirety of draft-rekhter should be omitted ;-) > the wildcard is useful for assigning BIDIR-PIM C-flows > to S-PMSIs that are instantiated by unidirectional P-tunnels using > the procedures of section 11.2. I don't think the existing specifications are sufficient to determine just how this would work. Perhaps you could say more about this. > Moreover, (C-S, C-*) S-PMSI in the -01 version of the draft is yet > another example that shows that contrary to your claim, what is in > draft-rekhter is *more* than "only a subset" of what is in draft-rosen. I can't wait to see all the new stuff that's going to be hurriedly stuffed into the -02 version! ;-) Could you explain the use case for (C-S, C-*)? > Use of the 0/0 prefix encoding to indicate the "match all semantics" well > predates draft-rosen. Good thing I didn't try to file a patent on it ;-) > Just for the record, the authors of MVPN and BGP-MVPN specs discussed the > use of wildcards well before you published draft-rosen-l3vpn-mvpn-mspmsi. Absolutely correct. However, some of the authors took longer than others to appreciate the usefulness of the wild card specification. I certainly hope that everyone who's ever discussed MVPN will not decide to issue a new draft that is primarily a paraphrase of an existing draft. I think the generally accepted procedure for someone who disagrees with a few details of a draft is to raise the issues on the mailing list, not to pretend that the draft doesn't exist. From robert@raszuk.net Fri Jul 31 13:34:40 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 E55873A6905 for ; Fri, 31 Jul 2009 13:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_82=0.6, MIME_QP_LONG_LINE=1.396] 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 PLed4BzV9mnc for ; Fri, 31 Jul 2009 13:34:40 -0700 (PDT) Received: from smh03.opentransfer.com (smh03.opentransfer.com [98.130.1.171]) by core3.amsl.com (Postfix) with ESMTP id D48BC3A6DD8 for ; Fri, 31 Jul 2009 13:34:28 -0700 (PDT) Received: from smh03.opentransfer.com (smh03.opentransfer.com [127.0.0.1]) by smh03.opentransfer.com (Postfix) with ESMTP id 0983D9E31D7; Fri, 31 Jul 2009 16:13:29 -0400 (EDT) Received: (from mail@localhost) by smh03.opentransfer.com (8.13.8/8.13.8/Submit) id n6VKDSTd009182; Fri, 31 Jul 2009 16:13:28 -0400 X-Authentication-Warning: smh03.opentransfer.com: mail set sender to robert@raszuk.net using -f Received: from webmail7.opentransfer.com (unknown [69.49.230.6]) by smh03.opentransfer.com (Postfix) with ESMTP id 7D6AB9E31A9; Fri, 31 Jul 2009 16:13:28 -0400 (EDT) Received: from webmail7.opentransfer.com (webmail7.opentransfer.com [127.0.0.1]) by webmail7.opentransfer.com (8.13.8/8.13.8) with ESMTP id n6VKPjE3019009; Fri, 31 Jul 2009 16:25:45 -0400 Received: (from nobody@localhost) by webmail7.opentransfer.com (8.13.8/8.13.8/Submit) id n6VKPjVA019008; Fri, 31 Jul 2009 16:25:45 -0400 X-Authentication-Warning: webmail7.opentransfer.com: nobody set sender to robert@raszuk.net using -f Received: from aavg40.neoplus.adsl.tpnet.pl (aavg40.neoplus.adsl.tpnet.pl [83.6.40.40]) by webmail.opentransfer.com (Horde MIME library) with HTTP; for ; Fri, 31 Jul 2009 16:25:45 -0400 Message-ID: <20090731162545.b7nqt7qc54wowcg8@webmail.opentransfer.com> Date: Fri, 31 Jul 2009 16:25:45 -0400 From: robert@raszuk.net To: l3vpn@ietf.org Subject: Re: Wildcard bindings for S-PMSIs References: <1631.1249066032@erosen-linux> In-Reply-To: <1631.1249066032@erosen-linux> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-Originating-IP: 83.6.40.40 Cc: Yakov Rekhter , erosen@cisco.com 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, 31 Jul 2009 20:34:41 -0000 Hello, > I certainly hope that everyone who's ever discussed MVPN will not decide = to > issue a new draft that is primarily a paraphrase of an existing draft. = I > think the generally accepted procedure for someone who disagrees with a f= ew > details of a draft is to raise the issues on the mailing list, not = to > pretend that the draft doesn't exist. Extremely well said. In fact it is clear that unlike it was alluded to me by Area Director =20 this week there are no personal issues ... it is Juniper Networks =20 which tries to continue to ride on other's ideas, fit it to their =20 needs/internal politics and issue a new drafts which are just a subset =20 of already existing drafts and what it worse claim that those are =20 novel. This practice seems to become a standard between various IETF =20 WGs. In this particular topic a correct comment of Ice during an L3VPN WG =20 meeting to at least make a comparison of existing draft-rosen to =20 draft-rekhter was said to be a "moot point" by Rahul and "not needed" =20 by Yakov. I for that matter agree 100% with comments made by Ice that =20 such comparison should be made to this WG before proceeding any further. And Yakov's reply on the list to the posted questions few hours before =20 the WG meeting just not to give Eric a chance to comment is IMHO just =20 bad taste (to say at least). It is unfortunate, but so easy to observe. Such practice of Juniper Networks is unfortunately not unique to L3VPN =20 WG. The IDR WG just heard the same issue where proposal has been made =20 to define a subset of already proposed RFC (RT-Constrain) in the form =20 of RT-Constrain-Lite which in fact does contradicts with the original =20 RFC. There are more examples but I will not mention them at this point. I do hope that mvpn and L3VPN will have a chance to work on real =20 practical solution which would provide some real benefit to service =20 providers rather then trying to fit the believes of single vendor view =20 and their internal political goals. Cheers, R. > Yakov> In draft-rekhter a (*, G) wildcard is legal when G is either in the > Yakov> ASM range, or in the Bidir range. > > I don't think there is any such thing as "the Bidir range", as Bidir is ju= st > a form of ASM. Draft-rekhter seems to allow (*,G) when G is in the S= SM > range, which is what I think is questionable. > > Yakov> Wrt "doesn't seem to say anything significantly different", = I > Yakov> disagree,as the text in draft-rekhter is specified in terms of t= he > Yakov> changes to the currently specified procedures in BGP-MVPN f= or > Yakov> handling S-PMSI, while the text in draft-rosen does *not* > > Let's not confuse "saying something differently" with "saying somethi= ng > different". > > In draft-rosen, the procedures are specified in terms of the multica= st > states of the mVRF. I believe this results in the same behavior, but t= he > applicability is not restricted only to the case where BGP is used. That= 's > one of the reasons that draft-rekhter is just a subset of the "wild car= d" > specification of draft-rekhter. > > Eric> - The spec in draft-rekhter does not cover the use of wild cards wit= h > Eric> bidirectional P-tunnels. > > Yakov> This is because according to 6.4.4 of draft-ietf-l3vpn-2547bis- > Yakov> mcast-08.txt: > > "Specification of the procedures for assigning C-flows to mLDP MP2MP > LSPs that serve as P-tunnels is outside the scope of this document." > > I don't follow this line of reasoning; you omitted an important topic fr= om > one document because that topic is outside the scope of some other documen= t? > > Well, let me call your attention to section 4.3 of mcast-bgp-07: > > Usage of other values of the Multicast Source Length and Multicast Gro= up > Length fields [other than 32 for IPv4 and 128 for IPv6] is outside t= he > scope of this document. > > So by your own reasoning, the entirety of draft-rekhter should be omitt= ed > ;-) > >> the wildcard is useful for assigning BIDIR-PIM C-flows >> to S-PMSIs that are instantiated by unidirectional P-tunnels using >> the procedures of section 11.2. > > I don't think the existing specifications are sufficient to determine ju= st > how this would work. Perhaps you could say more about this. > >> Moreover, (C-S, C-*) S-PMSI in the -01 version of the draft is yet >> another example that shows that contrary to your claim, what is in >> draft-rekhter is *more* than "only a subset" of what is in draft-rosen. > > I can't wait to see all the new stuff that's going to be hurriedly stuff= ed > into the -02 version! ;-) > > Could you explain the use case for (C-S, C-*)? > >> Use of the 0/0 prefix encoding to indicate the "match all semantics" wel= l >> predates draft-rosen. > > Good thing I didn't try to file a patent on it ;-) > >> Just for the record, the authors of MVPN and BGP-MVPN specs discussed th= e >> use of wildcards well before you published draft-rosen-l3vpn-mvpn-mspmsi. > > Absolutely correct. However, some of the authors took longer than others = to > appreciate the usefulness of the wild card specification. > > I certainly hope that everyone who's ever discussed MVPN will not decide = to > issue a new draft that is primarily a paraphrase of an existing draft. = I > think the generally accepted procedure for someone who disagrees with a f= ew > details of a draft is to raise the issues on the mailing list, not = to > pretend that the draft doesn't exist. > > > > > > > > > > >