From RBhatt@ixiacom.com Tue Dec 1 00:20: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 3094028C1C9 for ; Tue, 1 Dec 2009 00:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 u4Jf0HuqUf27 for ; Tue, 1 Dec 2009 00:20:24 -0800 (PST) Received: from ixqw-mail-out.ixiacom.com (ixqw-mail-out.ixiacom.com [66.77.12.12]) by core3.amsl.com (Postfix) with ESMTP id 0081628C1C4 for ; Tue, 1 Dec 2009 00:20:23 -0800 (PST) Received: from ixcaexch07.ixiacom.com ([fe80:0000:0000:0000:0000:5efe:10.200.2.124]) by IXCA-HC2.ixiacom.com ([10.200.2.51]) with mapi; Tue, 1 Dec 2009 00:20:16 -0800 From: Rakesh Bhatt To: "l3vpn@ietf.org" Date: Tue, 1 Dec 2009 00:20:15 -0800 Subject: Query on : draft-ietf-l3vpn-2547bis-mcast-07.txt Thread-Topic: Query on : draft-ietf-l3vpn-2547bis-mcast-07.txt Thread-Index: AcpyXxxcsxivyz3bSkaktwMiyUAzLw== Message-ID: <716209EC190CA740BA799AC4ACCBFB5D1650B6F6AA@IXCAEXCH07.ixiacom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_716209EC190CA740BA799AC4ACCBFB5D1650B6F6AAIXCAEXCH07ixi_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 01 Dec 2009 04:38:16 -0800 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 08:20:26 -0000 --_000_716209EC190CA740BA799AC4ACCBFB5D1650B6F6AAIXCAEXCH07ixi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Team One Question on MVPN -p2mp What should be extended community attribute ( route target ) value for Lea= f AD Route ( type 4 route ). Thanks Rakesh Bhatt --_000_716209EC190CA740BA799AC4ACCBFB5D1650B6F6AAIXCAEXCH07ixi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Team

 

One Question on MVPN –p2mp

 

What should be extended community attribute ( route targ= et ) value  for Leaf AD Route ( type 4 route ).

 

 

Thanks

Rakesh Bhatt

--_000_716209EC190CA740BA799AC4ACCBFB5D1650B6F6AAIXCAEXCH07ixi_-- From yakov@juniper.net Tue Dec 1 05:34:03 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 67C073A6934 for ; Tue, 1 Dec 2009 05:34:03 -0800 (PST) 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 hOee8irIiKnF for ; Tue, 1 Dec 2009 05:34:02 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 44B6028C238 for ; Tue, 1 Dec 2009 05:26:32 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSxUZgES78GtHWXP209uvOVkdJws/fAec@postini.com; Tue, 01 Dec 2009 05:26:25 PST 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.393.1; Tue, 1 Dec 2009 05:24:37 -0800 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, 1 Dec 2009 05:24:37 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 05:24:36 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 05:24:36 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nB1DOZj46966; Tue, 1 Dec 2009 05:24:35 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912011324.nB1DOZj46966@magenta.juniper.net> To: Rakesh Bhatt Subject: Re: Query on : draft-ietf-l3vpn-2547bis-mcast-07.txt In-Reply-To: <716209EC190CA740BA799AC4ACCBFB5D1650B6F6AA@IXCAEXCH07.ixiacom.com> References: <716209EC190CA740BA799AC4ACCBFB5D1650B6F6AA@IXCAEXCH07.ixiacom.com> X-MH-In-Reply-To: Rakesh Bhatt message dated "Tue, 01 Dec 2009 00:20:15 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9322.1259673875.1@juniper.net> Date: Tue, 1 Dec 2009 05:24:35 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 01 Dec 2009 13:24:36.0476 (UTC) FILETIME=[A0A563C0:01CA7289] Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 13:34:03 -0000 Rakesh, > Hi Team > > One Question on MVPN -p2mp > > What should be extended community attribute ( route target ) value for Leaf > AD Route ( type 4 route ). See the following sections in draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt: 9.2.3.2.1. Originating Leaf A-D route into EBGP 9.2.3.4.1. Originating Leaf A-D route into IBGP Yakov. From erosen@cisco.com Thu Dec 3 08:39:27 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 CB3753A676A for ; Thu, 3 Dec 2009 08:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=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 cRJ9CpZD3AK6 for ; Thu, 3 Dec 2009 08:39:25 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6C5DE3A66B4 for ; Thu, 3 Dec 2009 08:39:25 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,336,1257120000"; d="scan'208";a="71888977" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Dec 2009 16:39:16 +0000 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 nB3GdG7g008848; Thu, 3 Dec 2009 16:39:16 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 nB3GdG5g003127; Thu, 3 Dec 2009 11:39:16 -0500 To: Thomas Morin Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 In-reply-to: Your message of Mon, 09 Nov 2009 16:47:58 +0900. <4AF7C92E.4050904@orange-ftgroup.com> Date: Thu, 03 Dec 2009 11:39:16 -0500 Message-ID: <3126.1259858356@erosen-linux> From: Eric Rosen 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, 03 Dec 2009 16:39:27 -0000 Appendix A of the "considerations" draft purports to provide an analysis showing that BGP C-multicast routing provides a more scalable MVPN PE-PE control plane than does PE-PE PIM. However, in addition to errors of fact, the analysis has lots of methodological problems; as a result it does not serve its intended function, which is to support the recommendations of section 3.3.1. Due to the large number of methodological problems, I believe the Appendix should be removed before the draft progresses. I also have to say that I find it peculiar for a PIM scalability analysis to progress without having been last called in any of the multicast WGs. The topic itself seems out of scope for the L3VPN WG. Nevertheless I will try to explain as clearly as I can why I think the analysis is defective. A scalability analysis must show how the utilization of some resource or set of resources on some system increases as some demand or set of demands increases. The appendix proposes two resources to consider: Though the type of processing, messages and states, may vary with the different approaches, we propose here a rough estimation of the load of PEs, in terms of number of messages processed and number of control plane states maintained. A "message processed" being a message being parsed, a lookup being done, and some action being taken (such has updating a control plane or data plane state). This is okay as one of the resources considered. If I understand this correctly, this omits consideration of any messages received that do not result in any "action being taken", and thus omits consideration of any acknowledgment messages or other messages that fall into the category of "transport overhead". It also omits consideration of messages transmitted, thus does not distinguish actions that cause a new message to be sent from actions that do not. So it is not a complete measure of the amount of "messaging", but it is a factor worth considering. A "state maintained" being a multicast state kept in the control plane memory of a PE, related to a interface or a PE being subscribed to a multicast stream. This is also worth considering as an abstract measure of memory resources. However, as we will see, the analysis is not very precise about what it counts as a "state", and this leads to some mistakes. The real methodological problems begin when the analysis attempts to be quantitative: The estimation unit used is the "message.equipment" (or "m.e"): one "message.equipment" corresponding to "one equipment processing one message" (10 m.e being "10 equipments processing each one message", or "5 messages each processed by 2 equipments", or "1 message processed by 10 equipment", etc.). Similarly, for the amount of control plane state, the unit used is "state.equipment" or "s.e". This allow to take into account the fact that a message (or a state) can have be processed (or maintained) by more than one node. This "estimation unit" has no meaning whatsoever, as it does not reflect resource utilization on any system. Suppose there are N systems, each running an algorithm that scales as O(N). Contrast this with an alternative in which a single system does the work of all N, running an algorithm that scales as O(N^2). Other things being equal, the former would be considered to be the more scalable alternative. However, if you use the "estimation unit" of "work.equipment", you would conclude that in both schemes the work scales as O(N^2), and hence that the schemes are equally scalable. If this were a valid methodology, no one would ever have heard of such notions as "distributed routing" or "datagram networks". Use of this peculiar "estimation unit" will always bias the results towards a centralized system and away from a distributed system. Any subsequent revision of Appendix A should eliminate the notion of "s.e." or "m.e." and focus solely on the scaling of the individual systems. Another methodological error is the fact that the analysis focuses heavily on the Source-Specific Multicast mode, even though the number of VPN customer deployments of SSM is quite small when compared to the number of VPN customer deployments of ASM. To support the recommendations of section 3.3, the analysis needs to focus on scenarios that relevant to actual deployments. Some of the analysis of SSM also applies to the ASM procedures for joining/pruning source trees, but this is not made clear, and it's difficult for a reader to know how much of the analysis is relevant to actual deployments. In the most recent rev of the draft, a new section devoted to ASM has been introduced, and this section has its own set of problems, as I will discuss shortly. In addition to the time spent on the virtually irrelevant SSM scenario, much time is spent on examining a "PIM with explicit tracking" scheme, even though no such scheme has been proposed. It's difficult to understand why this straw man is discussed, while other actual proposals for using PIM are not. Another methodological error is that only the messaging needed to join a single (S,G) flow is considered. Thus the analysis ignores any scaling issues that show up as the number of (S,G) flows increases. Since the number of (S,G) flows handled by a Route Reflector will far exceed the number handled by any PE router, failure to consider this particular scaling factor tends to bias the results in favor of a scheme that uses Route Reflectors. Also omitted from consideration are scaling issues that show up as the rate of change of multicast states increases. Another methodological error is that the analysis takes no account of the increased amount of state that must be maintained when C-multicast trees are set up using two different protocols, rather than just one. When PIM is used as the PE-PE control plane, the (C-S,C-G) and (C-*,C-G) states that drive the inter-PE control plane are the same as the one as the drive the CE-PE control plane. When BGP is used, a given multicast state has to be represented both as a PIM state and as a BGP state (C-multicast route). This should really be counted as a doubling (at least) of the number of states that need to be maintained. This is a very conservative estimate, as the BGP states tend to contain much more information (e.g., RTs) than the corresponding PIM states. It's clear that appendix A does not consider both the BGP states and the PIM states, but it's never quite clear just what states it is considering. Another methodological error is that the PE-CE interactions are not taken into account. In many scenarios the PE-PE interactions are just "noise" when compared to the real bottleneck, the PE-CE interactions. The total number of PIM messages processed by a PE includes PIM messages from CEs as well as from PEs. Suppose that by adding BGP, you could reduce this total number of PIM messages by 1%, at the cost of doubling the amount of state you need to maintain. Would that be a good tradeoff? In order to support the recommendations of section 3.3, Appendix A has to show that the tradeoff is a lot better than this. Yet it doesn't even attempt to do so. It's possible to "prove" any conclusion you want by carefully scoping the set of things you look at. For example, if one wanted to prove that BGP is less scalable, one could say "let's compare the two schemes to see how the total number of TCP connections in the network scales as the number of PEs increases". Of course, to produce a valid analysis, one has to look at more than one issue, and one has to demonstrate that one is actually looking at the bottlenecks. This collection of methodological errors is more than enough to send Appendix A "back to the drawing board". If the goal is to make a choice between two protocols by considering which scales best, then all the scaling factors must be considered. Let's take a look now at some of the more detailed issues. Consider the messaging needed by a PE to maintain an (S,G) state in the "steady state". By "steady state", I mean during periods (a) that are longer than the PIM refresh period and (b) in which the PE does not join or prune (S,G). (I think this is similar to what Appendix A calls "baseline processing".) Let's also suppose that the PE has k VRF interfaces over which there are (S,G) receivers. Assuming a typical one-minute PIM refresh time, the number of Join(S,G) PIM messages per minute that the PE receives from the other PEs of the same MVPN in the steady state is either 0 or 1. (Due to PIM Join Suppression, during the steady state only one PE on the LAN sends a Join(S,G), the others receive it. A PE with (S,G) state that sees a Join(S,G) from another PE does not send one itself.) The number of Join(S,G) messages the PE receives over its VRF interfaces is k per minute. So the messages received per minute to support the (S,G) state is either k or k+1. Note that this has no dependence whatsoever on the number of PEs. What if BGP is used instead of PIM for PE-PE control? In that case, no PE-PE message needs to be sent at all, so the number of messages received per minute to support the (S,G) state is k per minute. Even if k is 1, the most one can get is a 50% reduction; if k is 10 that goes down to 10%, if k is 100 that goes down to 1%. Considering the extra state needed to maintain the (S,G) in both PIM form and BGP form, these reductions seem rather modest, to say the least. The methodological problem here is that Appendix A does not consider the PIM overhead on the VRF interfaces. But when BGP C-multicast routing is added, it does not replace the C-PIM instance for a given MVPN, it just reduces by 1 the number of PIM interfaces supported by that C-PIM interface. By ignoring this fact (and by ignoring the cost of adding a second multicast protocol without removing PIM) one makes a small difference look much more significant than it really is. It is not valid for a scalability analysis to focus on just one aspect of the protocols unless it has first shown that that one aspect is the bottleneck. (Actually, adding BGP does not even fully reduce the number of PIM interfaces by even 1, as C-PIM on a PE still needs to keep state for the its "interface" to the other PEs; see, e.g., section 13.2.1 of draft-ietf-l3vpn-2547bis-mcast-bgp.) Appendix A talks of "order of magnitude" differences; that simply doesn't exist. In fact, the analysis of Appendix A fails to demonstrate any real scaling advantage, in the steady state, for one protocol over the other. Some amount of the analysis in Appendix A is devoted to the startup and shutdown transients, when a PE first joins an (S,G) or prunes an (S,G). A rather big deal is made of the "prune override" procedures. I have focused this critique on the steady state, because if the steady state (as I defined it above) is actually reached, the startup/shutdown transients are not very important. I suppose one might disagree with that, but certainly thee has been no analysis showing that the transients are more important than the steady state. It would certainly be interesting to analyze the case where there is so much multicast churn that steady state is never reached. However, that cannot be done by focusing on a single (S,G) over a limited time period. Now let's look specifically at the ASM case. One of the features of the BGP solution is that there is no way, in BGP, to represent the PIM operation of "prune source S off the (*,G) tree". To compensate for this, every PE in a given VPN is forced to keep track of every (S,G) stream for which any PE in that VPN has receivers. This is done by means of the Source Active A-D routes. There are two options that can be used. In one option, where "inter-site shared trees are not used", each PE functions as a C-RP, and then all the PE of a given VPN must exchange information on all the (S,G) streams that they see locally. This option uses BGP to do something that is very similar to what MSDP is used for today. Let me quote from Pekka Savola's review of this procedure: Active source BGP messages. This is a duplication of a similar mechanism in MSDP (RFC3618) which has caused much grief in Internet. Does this meant that when a host does 'nmap -sU 224.0.0.0/4' at a VPN site, this will result in about 268 million BGP active source updates being sent (2^28) in the SP backbone? The only answer to this was to beef up the Security Considerations with some required procedures that will prevent the PE from melting down entirely in this case. Of course, Appendix A's methodology of only considering a single (S,G) prevents it from seeing that this particular BGP option uses a mechanism whose scalability is already known to be poo,r and which the multicast WGs have decided not even to bring forward to IPv6. In the other, more sensible option, a PE originates a Source Active A-D route for an (S,G) only when it receives a C-multicast Join route for that (S,G). However, the Source Active A-D route goes to all the PEs in the VPN, not just to those that have receivers for that (S,G). I believe this means that the amount of state a given PE maintains in the BGP scheme is proportional to the number of (S,G) flows for which any PE in the VPN has receivers. Actually, since the SA route contains the RD of the originating PE, the situation is a bit worse; if (S,G) traffic is sent over the backbone by more than one PE, the other PEs in the same VPN must maintain an (S,G) SA A-D route for each such PE. In the BGP solution, even if a PE has only (*,G) receivers, or even if it has no receivers for G at all, it must maintain state for all the (S,G)s in the MVPN, multiplied by the average number of upstream PEs per source. Strangely, this scaling issue is considered to be insignificant by Appendix A, for the following reasons: when PIM-based C-multicast routing is used there are ... possible control plane state transitions triggered by the reception of (S,G) packets ; such events would induce processing on all PEs joined to G Control plane state transitions triggered by the reception of data packets have not even been mentioned to this point, and no analysis has been given to show whether or not they cause a scaling issue, or whether any such scaling issue is mitigated by the use of BGP. I also really don't see what this has to do with the issue at hand, namely the added state overhead of the Source Active A-D routes. Certainly there is no analysis provided that would show the SA A-D routes trade off in a favorable manner against the data-driven state changes. when PIM-based C-multicast routing is used there are ... possible PIM Assert messages specific to (S,G) ; this would induce a message processing on each PE of the VPN for each PIM Assert message It is true that the Source Active A-D routes eliminate the need for Assert messages. The implication is that this is favorable for BGP; however, there does not appear to be any analysis showing that. The new material on ASM does not appear to contain any analysis at all, just unsupported assertions. Let me also mention a few other, less major, problems in the Appendix: for each PIM Prune message, all PE routers on the LAN work to let the upstream PE determine the answer to the "did the last receiver leave?" question. I believe that only one PE router needs to send a Join in order to override the Prune, as once the others see that Join they reset their Join timers. Of course, actual behavior varies depending on the value of the timer and on the random jitter. We can see that answering the "last receiver leaves" question is a significant proportion of the work that the C-multicast routing building block has to make, and where the approaches differ most. This assertion is made without support. the case where the RT-Constraint mechanisms [RFC4684] is not used is not covered; Since RT-constraint is not a mandatory to implement mechanism, I don't see why this is not covered. Note though that it doesn't really matter in the steady state. >From A.1.1.1. "PIM LAN procedures, by default" +------------+------------+---------------+----------+--------------+ | | upstream | other PEs | RR | total across | | | PE (1) | (total across | (none) | all | | | | (#mvpn_PE-1) | | equipments | | | | PEs) | | | +------------+------------+---------------+----------+--------------+ | first PE | 1 m.e | #MVPN_PE-1 | / | #MVPN_PE m.e | | joins | | m.e | | | +------------+------------+---------------+----------+--------------+ If the above row implies that the "other PEs" must process the join, where "process" is defined (as it is in this Appendix) as "a message being parsed, a lookup being done, and some action being taken (such has updating a control plane or data plane state)", then one the next row is incorrect: +------------+------------+---------------+----------+--------------+ | for *each* | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e | | additional | | m.e | | | | PE joining | | | | | +------------+------------+---------------+----------+--------------+ If a second PE has "processed" the Join(S,G) from the first, then it doesn't need to send a Join if it decides to join (S,G) itself; join suppression will be in effect. The third and fifth columns above are examples of cases where the Appendix misleadingly multiplies by #mvpn_PE. In fact, the number of messages received by a given PE does not increase in proportion to #mvpn_PE. This problem infects the entire set of tables in the Appendix. Section A.1.1.3 The RR has to maintain all the multicast states of all the clients (PEs), as long as those multicast states have a PMSI as input interface. That's way more multicast states than any PE has to maintain. The analysis in this Appendix simply ignores the negative scaling effects due to the large number of RR clients. The claim is made that when a second PE joins (S,G), the upstream PE does not receive a new BGP route. That may or may not be the case. The second PE will always need to send a C-multicast Join route to the RRs; in PIM the second PE might not need to send any message. Whether the RRs will forward the route originated by the second PE depends upon whether that route is more preferable (according to normal BGP procedures) than the route originated by the first PE. A similar observation applies when C-multicast routes are withdrawn. From erosen@cisco.com Thu Dec 3 08:40: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 BF5D13A6878 for ; Thu, 3 Dec 2009 08:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 uANvasy9MIcj for ; Thu, 3 Dec 2009 08:40:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D31BE3A682B for ; Thu, 3 Dec 2009 08:40:12 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,336,1257120000"; d="scan'208";a="71889068" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Dec 2009 16:40:04 +0000 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 nB3Ge4hN009158; Thu, 3 Dec 2009 16:40:04 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 nB3Ge3gd003158; Thu, 3 Dec 2009 11:40:03 -0500 To: Thomas Morin Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 In-reply-to: Your message of Mon, 09 Nov 2009 16:47:58 +0900. <4AF7C92E.4050904@orange-ftgroup.com> Date: Thu, 03 Dec 2009 11:40:03 -0500 Message-ID: <3157.1259858403@erosen-linux> From: Eric Rosen 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, 03 Dec 2009 16:40:13 -0000 I believe that comparing segmented inter-AS P-tunnels with non-segmented inter-AS P-tunnels gives the following comparison matrix: - Scalability for MI-PMSIs: Segmented more scalable - Scalability for S-PMSIs: Comparable scalability - Complexity at ASBRs: segmented more complex (requires ASBRs to have more VPN-specific knowledge, and some options increased configuration at ASBRs) - Independence of tunneling technology from one AS to another: segmented provides this, non-segmented does not. - Compatibility with existing implementations: non-segmented provides this, segmented does not. Looking at these considerations, I would not choose "segmented" as a required feature of the minimal implementation, because I don't think anyone will ever use MI-PMSIs instantiated as segmented inter-AS P-tunnels, and I think the minimal implementation should emphasize simplicity over generality. But whatever the document recommends, it should take all the considerations into account, not just the ones that best support its conclusion. From yakov@juniper.net Tue Dec 8 07:16: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 6166B3A6832 for ; Tue, 8 Dec 2009 07:16:53 -0800 (PST) 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 tFVHmHQdk3gL for ; Tue, 8 Dec 2009 07:16:51 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 3AA3228C140 for ; Tue, 8 Dec 2009 07:16:46 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSx5t06rmaxKxLS6FyZIaiDo6G0cZVBdy@postini.com; Tue, 08 Dec 2009 07:16:38 PST 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.393.1; Tue, 8 Dec 2009 07:08:20 -0800 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, 8 Dec 2009 07:08:20 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 07:08:20 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 07:08:20 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nB8F8Jj31633; Tue, 8 Dec 2009 07:08:20 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912081508.nB8F8Jj31633@magenta.juniper.net> To: erosen@cisco.com Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 In-Reply-To: <3157.1259858403@erosen-linux> References: <3157.1259858403@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Thu, 03 Dec 2009 11:40:03 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23294.1260284899.1@juniper.net> Date: Tue, 8 Dec 2009 07:08:19 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 08 Dec 2009 15:08:20.0341 (UTC) FILETIME=[47401250:01CA7818] Cc: Thomas Morin , 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: Tue, 08 Dec 2009 15:16:53 -0000 Eric, > I believe that comparing segmented inter-AS P-tunnels with non-segmented > inter-AS P-tunnels gives the following comparison matrix: > > - Scalability for MI-PMSIs: Segmented more scalable This is correct. > - Scalability for S-PMSIs: Comparable scalability This is correct, *but only* when C-multicast routing is done with PIM. This is *incorrect* when C-multicast routing is done with BGP, as when BGP is used for C-multicast routing, segmented P-tunnels are more scalable than non-segmented due to the ability to aggregate segmented S-PMSIs with I-PMSIs. > - Complexity at ASBRs: segmented more complex (requires ASBRs to have more > VPN-specific knowledge, and some options increased configuration at ASBRs) To be more precise, depending on whether inter-AS I-PMSI auto-discovery routes are at the granularity of or , the segmented P-tunnels would require either the same or additional configuration on ASBRs as the non-segmented P-tunnels. (Note that the issue of configuration has been already discussed on the mailing list - see http://www.ietf.org/mail-archive/web/l3vpn/current/msg02420.html) > - Independence of tunneling technology from one AS to another: segmented > provides this, non-segmented does not. This is correct. > - Compatibility with existing implementations: non-segmented provides this, > segmented does not. >From Merriam-Webster: Main Entry: compatible 1 : capable of existing together in harmony 2 : capable of cross-fertilizing freely or uniting vegetatively 3 : capable of forming a homogeneous mixture that neither separates nor is altered by chemical interaction 4 : capable of being used in transfusion or grafting without immunological reaction (as agglutination or tissue rejection) 5 : designed to work with another device or system without modification; especially : being a computer designed to operate in the same manner and use the same software as another computer Given the above definition of "compatible", your claim is *incorrect*, as having non-segmented P-tunnels, by itself, does not provide compatibility with "existing implementations". This is because an implementation of non-segmented inter-AS I-PMSI P-tunnels with BGP-based auto-discovery, as specified in draft-ietf-l3vpn-mcast-bgp is *not* compatible with "existing implementations" of non-segmented inter-AS I-PMSI P-tunnels with BGP-based auto-discovery based on MDT-SAFI, even if both of these implementations use non-segmented P-tunnels. Likewise, an implementation of non-segmented S-PMSI P-tunnels with BGP-based auto-discovery, as specified in draft-ietf-l3vpn-mcast-bgp is *not compatible* with an "existing implementation" of non-segmented S-PMSI P-tunnels with UDP-based auto-discovery, even if both these implementations use non-segmented P-tunnels. As a side comment, I would also suggest to revise the following from section 6 of draft-ietf-l3vpn-mvpn-considerations-05: - that implementations support segmented inter-AS tunnels and consider supporting non-segmented inter-AS tunnels (in order to maintain backwards compatibility and for migration) ; to better aling it with the (correct) text in section 3.5 of draft-ietf-l3vpn-mvpn-considerations-05. > Looking at these considerations, I would not choose "segmented" as a > required feature of the minimal implementation, because I don't think anyone > will ever use MI-PMSIs instantiated as segmented inter-AS P-tunnels, and I > think the minimal implementation should emphasize simplicity over > generality. But whatever the document recommends, it should take all the > considerations into account, not just the ones that best support its > conclusion. The document should take all the *valid* considerations into account. Moreover, these considerations should reflect the requirements, as specified in rfc4834. The document does all this. Yakov. From thomas.morin@orange-ftgroup.com Tue Dec 8 08:38:57 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 BB9D028C1FA for ; Tue, 8 Dec 2009 08:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] 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 kzZmdvECBnnl for ; Tue, 8 Dec 2009 08:38:56 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id ABA1828C1F3 for ; Tue, 8 Dec 2009 08:38:55 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 17:38:44 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 17:38:43 +0100 Message-ID: <4B1E8112.6070007@orange-ftgroup.com> Date: Tue, 08 Dec 2009 17:38:42 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091130 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 References: <3157.1259858403@erosen-linux> <200912081508.nB8F8Jj31633@magenta.juniper.net> In-Reply-To: <200912081508.nB8F8Jj31633@magenta.juniper.net> Content-Type: multipart/alternative; boundary="------------090706010407040409080006" X-OriginalArrivalTime: 08 Dec 2009 16:38:43.0720 (UTC) FILETIME=[E7D60880:01CA7824] 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: Tue, 08 Dec 2009 16:38:57 -0000 This is a multi-part message in MIME format. --------------090706010407040409080006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Eric, Yakov, Given your exchange, I would propose to add to section 3.5, a modified version of Eric's points taking also into account Yakov's suggestions and the discussion in June/July (text to be added before the last paragraph of section 3.5, except of course text not included): The following is a summary comparison matrix between the "segmented inter-AS P-tunnels" and "non-segmented inter-AS P-tunnels" approaches: - Scalability for MI-PMSIs: "Segmented inter-AS P-tunnels" more scalable [unmodified] - Scalability for S-PMSIs: Comparable scalability when the "Full per-MVPN PIM peering across an MI-PMSI" approach is used for C-multicast routing; "segmented inter-AS P-tunnels" more scalable when BGP is used for C-multicast routing (due to the ability to aggregate S-PMSIs with I-PMSI when BGP is used for C-multicast routing) [modified to take into account S-PMSI aggregation as discussed in June/July and reminded below] - Configuration at ASBRs: depending on whether segmented P-tunnels have a granularity of source ASBR or source AS, the "segmented inter-AS P-tunnels" approach would require respectively the same or additional configuration on ASBRs as the "non-segmented inter-AS P-tunnels" approach [modified to take into account the discussion in June/July and reminded below] - Independence of tunneling technology from one AS to another: the "segmented inter-AS P-tunnels" approach provides this, the "non-segmented inter-AS P-tunnels" approach does not. [unmodified] - Facilitated co-existence with existing deployments, and providing a lighter engineering in some scenarios : the "non-segmented inter-AS P-tunnels" approach provides this, the "segmented inter-AS P-tunnels" approach does not. [unmodified to avoid the inexact "compatibility" term] Moreover, the sixth item in section 6 "Summary of recommendation" can be rewritten to avoid the inexact term of "backward compatibility": that implementations support segmented inter-AS tunnels and consider supporting non-segmented inter-AS tunnels (in order to facilitate co-existence with existing deployments, and provide a lighter engineering in some scenarios) ; Please send feedback on these proposed changes. Thanks, -Thomas Yakov Rekhter: > Eric, > > >> I believe that comparing segmented inter-AS P-tunnels with non-segmented >> inter-AS P-tunnels gives the following comparison matrix: >> >> - Scalability for MI-PMSIs: Segmented more scalable >> > This is correct. > > >> - Scalability for S-PMSIs: Comparable scalability >> > This is correct, *but only* when C-multicast routing is done with PIM. > > This is *incorrect* when C-multicast routing is done with BGP, as > when BGP is used for C-multicast routing, segmented P-tunnels are > more scalable than non-segmented due to the ability to aggregate > segmented S-PMSIs with I-PMSIs. > > >> - Complexity at ASBRs: segmented more complex (requires ASBRs to have more >> VPN-specific knowledge, and some options increased configuration at ASBRs) >> > To be more precise, depending on whether inter-AS I-PMSI auto-discovery > routes are at the granularity of or MVPN>, the segmented P-tunnels would require either the same or > additional configuration on ASBRs as the non-segmented P-tunnels. > > (Note that the issue of configuration has been already discussed on the mailing > list - seehttp://www.ietf.org/mail-archive/web/l3vpn/current/msg02420.html) > > >> - Independence of tunneling technology from one AS to another: segmented >> provides this, non-segmented does not. >> > This is correct. > > >> - Compatibility with existing implementations: non-segmented provides this, >> segmented does not. >> > From Merriam-Webster: > > Main Entry: compatible > > 1 : capable of existing together in harmony > > 2 : capable of cross-fertilizing freely or uniting vegetatively > 3 : capable of forming a homogeneous mixture that neither separates > nor is altered by chemical interaction > 4 : capable of being used in transfusion or grafting without > immunological reaction (as agglutination or tissue rejection) > 5 : designed to work with another device or system without > modification; especially : being a computer designed to operate > in the same manner and use the same software as another computer > > Given the above definition of "compatible", your claim is *incorrect*, > as having non-segmented P-tunnels, by itself, does not provide > compatibility with "existing implementations". > > This is because an implementation of non-segmented inter-AS I-PMSI > P-tunnels with BGP-based auto-discovery, as specified in > draft-ietf-l3vpn-mcast-bgp is *not* compatible with "existing > implementations" of non-segmented inter-AS I-PMSI P-tunnels with > BGP-based auto-discovery based on MDT-SAFI, even if both of these > implementations use non-segmented P-tunnels. > > Likewise, an implementation of non-segmented S-PMSI P-tunnels with > BGP-based auto-discovery, as specified in draft-ietf-l3vpn-mcast-bgp > is *not compatible* with an "existing implementation" of non-segmented > S-PMSI P-tunnels with UDP-based auto-discovery, even if both these > implementations use non-segmented P-tunnels. > > As a side comment, I would also suggest to revise the following > from section 6 of draft-ietf-l3vpn-mvpn-considerations-05: > > - that implementations support segmented inter-AS tunnels and > consider supporting non-segmented inter-AS tunnels (in order to > maintain backwards compatibility and for migration) ; > > to better aling it with the (correct) text in section 3.5 of > draft-ietf-l3vpn-mvpn-considerations-05. > > >> Looking at these considerations, I would not choose "segmented" as a >> required feature of the minimal implementation, because I don't think anyone >> will ever use MI-PMSIs instantiated as segmented inter-AS P-tunnels, and I >> think the minimal implementation should emphasize simplicity over >> generality. But whatever the document recommends, it should take all the >> considerations into account, not just the ones that best support its >> conclusion. > The document should take all the *valid* considerations into account. > Moreover, these considerations should reflect the requirements, > as specified in rfc4834. The document does all this. > > Yakov. > --------------090706010407040409080006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Eric, Yakov,

Given your exchange, I would propose to add to section 3.5, a modified version of Eric's points taking also into account Yakov's suggestions and the discussion in June/July (text to be added before the last paragraph of section 3.5, except of course text not included):
The following is a summary comparison matrix between the "segmented inter-AS P-tunnels" and "non-segmented inter-AS P-tunnels" approaches:

- Scalability for MI-PMSIs: "Segmented inter-AS P-tunnels" more scalable

[unmodified]

- Scalability for S-PMSIs: Comparable scalability when the "Full per-MVPN PIM peering across an MI-PMSI" approach is used for C-multicast routing; "segmented inter-AS P-tunnels" more scalable when BGP is used for C-multicast routing (due to the ability to aggregate S-PMSIs with I-PMSI when BGP is used for C-multicast routing)

[modified to take into account S-PMSI aggregation as discussed in June/July and reminded below]

- Configuration at ASBRs: depending on whether segmented P-tunnels have a granularity of source ASBR or source AS, the "segmented inter-AS P-tunnels" approach would require respectively the same or additional configuration on ASBRs as the "non-segmented inter-AS P-tunnels" approach

[modified to take into account the discussion in June/July and reminded below]

- Independence of tunneling technology from one AS to another: the "segmented inter-AS P-tunnels" approach provides this, the "non-segmented inter-AS P-tunnels" approach does not.

[unmodified]

- Facilitated co-existence with existing deployments, and providing a lighter engineering in some scenarios : the "non-segmented inter-AS P-tunnels" approach provides this, the "segmented inter-AS P-tunnels" approach does not.

[unmodified to avoid the inexact "compatibility" term]

Moreover, the sixth item in section 6 "Summary of recommendation" can be rewritten to avoid the inexact term of "backward compatibility":
that implementations support segmented inter-AS tunnels and consider supporting non-segmented inter-AS tunnels (in order to facilitate co-existence with existing deployments, and provide a lighter engineering in some scenarios) ;
Please send feedback on these proposed changes.

Thanks,

-Thomas






Yakov Rekhter: 
Eric,

  
I believe that comparing segmented inter-AS P-tunnels with non-segmented
inter-AS P-tunnels gives the following comparison matrix:

- Scalability for MI-PMSIs: Segmented more scalable
    
This is correct.

  
- Scalability for S-PMSIs: Comparable scalability
    
This is correct, *but only* when C-multicast routing is done with PIM.

This is *incorrect* when C-multicast routing is done with BGP, as
when BGP is used for C-multicast routing, segmented P-tunnels are
more scalable than non-segmented due to the ability to aggregate
segmented S-PMSIs with I-PMSIs.

  
- Complexity at ASBRs: segmented more complex (requires ASBRs to have more
  VPN-specific knowledge, and some options increased configuration at ASBRs)
    
To be more precise, depending on whether inter-AS I-PMSI auto-discovery
routes are at the granularity of <source ASBR, MVPN> or <source AS,
MVPN>, the segmented P-tunnels would require either the same or
additional configuration on ASBRs as the non-segmented P-tunnels.

(Note that the issue of configuration has been already discussed on the mailing
list - see http://www.ietf.org/mail-archive/web/l3vpn/current/msg02420.html) 
  
  
- Independence of tunneling technology from one AS to another: segmented
  provides this, non-segmented does not.
    
This is correct.

  
- Compatibility with existing implementations: non-segmented provides this,
  segmented does not.
    
From Merriam-Webster:

   Main Entry: compatible

      1 : capable of existing together in harmony <compatible theories> 
          <compatible people>
      2 : capable of cross-fertilizing freely or uniting vegetatively
      3 : capable of forming a homogeneous mixture that neither separates 
          nor is altered by chemical interaction
      4 : capable of being used in transfusion or grafting without 
          immunological reaction (as agglutination or tissue rejection)
      5 : designed to work with another device or system without 
          modification; especially : being a computer designed to operate 
          in the same manner and use the same software as another computer

Given the above definition of "compatible", your claim is *incorrect*,
as having non-segmented P-tunnels, by itself, does not provide
compatibility with "existing implementations".

This is because an implementation of non-segmented inter-AS I-PMSI
P-tunnels with BGP-based auto-discovery, as specified in
draft-ietf-l3vpn-mcast-bgp is *not* compatible with "existing
implementations" of non-segmented inter-AS I-PMSI P-tunnels with
BGP-based auto-discovery based on MDT-SAFI, even if both of these
implementations use non-segmented P-tunnels.

Likewise, an implementation of non-segmented S-PMSI P-tunnels with
BGP-based auto-discovery, as specified in draft-ietf-l3vpn-mcast-bgp
is *not compatible* with an "existing implementation" of non-segmented
S-PMSI P-tunnels with UDP-based auto-discovery, even if both these
implementations use non-segmented P-tunnels.

As a side comment, I would also suggest to revise the following
from section 6 of draft-ietf-l3vpn-mvpn-considerations-05:

   -  that implementations support segmented inter-AS tunnels and
      consider supporting non-segmented inter-AS tunnels (in order to
      maintain backwards compatibility and for migration) ;

to better aling it with the (correct) text in section 3.5 of
draft-ietf-l3vpn-mvpn-considerations-05.

  
Looking at these considerations, I would not choose "segmented" as a
required feature of the minimal implementation, because I don't think anyone
will ever use MI-PMSIs instantiated as segmented inter-AS P-tunnels, and I
think the minimal implementation should emphasize simplicity over
generality. But whatever the document recommends, it should take all the
considerations into account, not just the ones that best support its
conclusion.    
The document should take all the *valid* considerations into account.
Moreover, these considerations should reflect the requirements,
as specified in rfc4834. The document does all this.

Yakov.
--------------090706010407040409080006-- From yakov@juniper.net Thu Dec 10 07:42:27 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 B2C7B3A672F for ; Thu, 10 Dec 2009 07:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 ZswRJYqxtYtY for ; Thu, 10 Dec 2009 07:42:27 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id D94D53A6A81 for ; Thu, 10 Dec 2009 07:42:25 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSyEW1n0YfXTH+7Io5Y1+pkQoGM6VGlbX@postini.com; Thu, 10 Dec 2009 07:42:16 PST 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.393.1; Thu, 10 Dec 2009 07:35:48 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 07:35:48 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 07:35:48 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 07:35:47 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBAFZlj04113; Thu, 10 Dec 2009 07:35:47 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912101535.nBAFZlj04113@magenta.juniper.net> To: Thomas Morin Subject: "Other PEs" in draft-ietf-l3vpn-mvpn-considerations-05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21893.1260459347.1@juniper.net> Date: Thu, 10 Dec 2009 07:35:47 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 10 Dec 2009 15:35:47.0636 (UTC) FILETIME=[71F0D740:01CA79AE] 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: Thu, 10 Dec 2009 15:42:28 -0000 Thomas, In A.1.1.3 why does the "Other PEs" column show 2 m.e. on first join ? Ditto for each additional PE joining. Yakov. From tnadeau@lucidvision.com Thu Dec 10 12:28:12 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 8E2843A6A5F for ; Thu, 10 Dec 2009 12:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.796 X-Spam-Level: X-Spam-Status: No, score=-3.796 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=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 S2OEsNmWpcJb for ; Thu, 10 Dec 2009 12:28:11 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 5644A3A6A4E for ; Thu, 10 Dec 2009 12:28:11 -0800 (PST) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id E0EF0422D1E4 for ; Thu, 10 Dec 2009 15:27:59 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/alternative; boundary=Apple-Mail-13-849322099 Subject: ONTC-PRISM Newsletter: Call for Papers - Special Issue on Cloud Computing and Data Center Networks Date: Thu, 10 Dec 2009 15:27:59 -0500 Message-Id: <27404495-7069-4E80-A92D-59D88143A63B@lucidvision.com> To: l3vpn@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) 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, 10 Dec 2009 20:28:12 -0000 --Apple-Mail-13-849322099 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii FYI: ONTC-PRISM Newsletter: Call for Papers - Special Issue on Cloud Computing and Data Center Networks Scope: IT services have proliferated significantly through most enterprises and even to end-users. This explosion of IT services has led to the emergence, growth and consolidation of computationally intensive data centers. Data centers are principle network wide entities that are responsible for the successful provisioning and scaling of IT services across disparate users over a heterogenous network. We seek to understand the network-wide design, implementation, architecture and technology aspects of data centers and of emerging applications such as cloud computing. We seek original review articles on technologies, architectures, implementation excercises associated with data centers including cloud computing, distributed and virtual data centers and applications using such infrastructures. Articles must be written as per the format prescribed below. Keywords: Cloud computing, data centers, Carrier Ethernet, MPLS-TP, PBB-TE, Virtualization, Consolidation. Format: up to 3 pages with single column format, Times new roman 10 point font for the text and 8 point font for the figure captions. Submission information: Please send manuscripts to submissions@ontc-prism.org. All articles will be reviewed by the TAB and/or external reviewers. Timeline: Submission Deadline: Dec 31, 2009 Notification: Feb 1, 2010 Issue date: Feb 15, 2010 TAB in-charge: Thomas Nadeau BT Group LLC. About ONTC Prism (www.ontc-prism.org): Prism is a quarterly newsletter aimed at the dissemination of relevant content pertaining to optical and high-speed networks and related growth areas across industry and academia. Prism seeks to promote the growth of optical networking activity by creation of a unified knowledge base and aims to create a communication bridge between industry and academia in terms of research frontiers and complementary strategies for future growth. --Apple-Mail-13-849322099 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii submissions@ontc-prism.org.= All articles will be reviewed by the TAB
and/or external = reviewers.

Timeline:
Submission Deadline: Dec 31, = 2009
Notification: Feb 1, 2010
Issue date: Feb 15, 2010

TAB = in-charge: Thomas Nadeau BT Group LLC.

About ONTC Prism (www.ontc-prism.org): Prism is a = quarterly newsletter
aimed at the dissemination of relevant content = pertaining to optical and
high-speed networks and related growth = areas across industry and academia.
Prism seeks to promote the growth = of optical networking activity by
creation of a unified knowledge = base and aims to create a communication
bridge between industry and = academia in terms of research frontiers and
complementary strategies = for future growth.
= --Apple-Mail-13-849322099-- From thomas.morin@orange-ftgroup.com Fri Dec 11 09:25: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 F14443A687B for ; Fri, 11 Dec 2009 09:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_36=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 qkunKX2d56Dj for ; Fri, 11 Dec 2009 09:25:37 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id CD31E3A67D3 for ; Fri, 11 Dec 2009 09:25:36 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 18:25:21 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 18:25:22 +0100 Message-ID: <4B228081.3060409@orange-ftgroup.com> Date: Fri, 11 Dec 2009 18:25:21 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: "Other PEs" in draft-ietf-l3vpn-mvpn-considerations-05 References: <200912101535.nBAFZlj04113@magenta.juniper.net> In-Reply-To: <200912101535.nBAFZlj04113@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2009 17:25:22.0334 (UTC) FILETIME=[EB2DE3E0:01CA7A86] 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, 11 Dec 2009 17:25:38 -0000 Yakov, Yakov Rekhter: > In A.1.1.3 why does the "Other PEs" column show 2 m.e. on first join ? > Ditto for each additional PE joining. > The "Other PEs" column counts the m.e for all PEs,except for the upstream PE, which is in a separate column. In the BGP case you mention (A.1.1.3) the only PE that processes a message is the upstream PE. The number should thus be 0 m.e and not 2 m.e. The mistake is a left-over from previous versions of this analyses where the recommendation on using RT-constraint in draft-ietf-2547bis-mcast-bgp was not taken into account. In fact, section A.1.1.1 has a similar "off by one" unit mistake : the joiner PE does not itself see and process its own joins, and where the table read "#mVPN_PEs - 1", it should in fact read "#mVPN_PEs - 2". I will update the two tables with correct numbers. -Thomas From mn1921@att.com Fri Dec 11 09:08: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 EC9433A69F4 for ; Fri, 11 Dec 2009 09:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_51=0.6, 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 HRRNDnErKOlP for ; Fri, 11 Dec 2009 09:08:52 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id A61463A69A0 for ; Fri, 11 Dec 2009 09:08:52 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-5.tower-161.messagelabs.com!1260551319!13210554!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 10028 invoked from network); 11 Dec 2009 17:08:39 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Dec 2009 17:08:39 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBBH8ZBp000994 for ; Fri, 11 Dec 2009 12:08:35 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBBH8Wgd000987 for ; Fri, 11 Dec 2009 12:08:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {A4892589-B0D9-459A-833C-9F22C29EB1AA} x-cr-hashedpuzzle: KDE= AxXk Bbb6 CnDj C8pH DkUU FEhv FRyP GP6d HWJk IKzH MKgz P2iZ P8zM QTcz VQZ1; 2; bAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAdABoAG8AbQBhAHMALgBtAG8AcgBpAG4AQABvAHIAYQBuAGcAZQAtAGYAdABnAHIAbwB1AHAALgBjAG8AbQA=; Sosha1_v1; 7; {A4892589-B0D9-459A-833C-9F22C29EB1AA}; bQBuADEAOQAyADEAQABhAHQAdAAuAGMAbwBtAA==; Fri, 11 Dec 2009 17:08:06 GMT; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAGwAMwB2AHAAbgAtAG0AdgBwAG4ALQBjAG8AbgBzAGkAZABlAHIAYQB0AGkAbwBuAHMALQAwADUA Content-class: urn:content-classes:message Subject: draft-ietf-l3vpn-mvpn-considerations-05 Date: Fri, 11 Dec 2009 12:08:06 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200446CE07@misout7msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 Thread-Index: Acp1O0ao6zG7WAmHTMqAD8KxvPngiQAAFm5QAF/E+IAAJwVhYAABU4kQAACY0BAABnS14AAsu16wAAKm7yAAA3cIcAAHkxqwAAbz/qAAAsdU4AAB/pDQAAA/YPAAG9YXMAAAccVwAABSn8AAAI7dAAA0HKXgAAI6KmAAAYeeMAAIpTRgAB6tGoA= From: "NAPIERALA, MARIA H (ATTLABS)" To: "Thomas Morin" X-Mailman-Approved-At: Fri, 11 Dec 2009 09:33:09 -0800 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, 11 Dec 2009 17:12:10 -0000 Hi Thomas, I have several comments on the latest version of the draft: 1. I believe that the draft should contain some analysis on how PIM-SM differs when handled by BGP signaling. The difference is significant enough to warrant at least a theoretical consideration if no significant field experience is available. Currently, vast majority of multicast applications used in the enterprise networks are PIM-SM based. It is important to analyze the BGP translation of pruning source traffic off the shared tree because this is the most significant change from PIM-SM. When BGP is used for PE-PE C-multicast signaling the data-driven PIM-SM state changes are replaced by additional BGP (Source Active) routes and timer-driven PIM messages. Let me point out just few aspects related to those changes that should be considered, starting from timer-driven Prune(S,G,rpt). When a single forwarder selection is the procedure used to avoid sending duplicate packets to MVPN customers during switching from RPT to SPT, the correct setting of the above mentioned timer to prune source traffic off the shared tree is important. It is not going to be trivial to tune such timer in large networks, because it can cause either duplicate traffic (if timer is set too high) or loss of traffic (if timer is set too low). This approach to PIM-SM changes the way the PIM-SM multicast trees are constructed, and it is not known to what extend this can impact existing multicast applications. If the solution to this is to make the timer for sending Prune(S,G,rpt) sufficiently high (to assure that SPT is created) and avoid duplicates sent to customers by having egress PEs discard data packets received from the "wrong" upstream PE, this should be included in MVPN considerations draft. It should be also considered that it may not always be possible for the egress PE to determine the upstream PE, in which case the single forwarder selection has to be used.=20 Regarding Source Active A-D routes, it was pointed out recently and in the past that the amount of BGP state they generate should be analyzed. The Appendix A ignores this important scalability aspect of BGP-signaling.=20 The field experience shows that there are multicast applications used in enterprise VPNs such that only control messages, but no multicast data, are sent across MVPN backbone. When BGP-multicast signaling is used, the Source Active A-D route is originated for every C-(S,G) flow that registers with C-RP and such that the C-RP joins "S" across MVPN backbone, even if no inter-site data is sent for this flow. Hence, the BGP scheme requires not only that for any given C-(S,G) flow that enters MVPN backbone an SA message is announced and maintained by all PEs in a given MVPN, but that SA messages are also announced for flows that never enter the MVPN backbone. 2. The considerations draft should also point out the difference how BGP vs. PIM (used as PE-PE signaling protocol) handles the upstream PE selection in case of multi-homed sources/RPs.=20 Typically, in a layer 3 VPN deployment it is not known whether or not all VRFs of a given VPN have the same best route to a given source. In other words, VRFs routing policies are provisioned independently of each other. If all VRFs of a given MVPN have the same best/ installed route to a multi-homed source/RP then this VPN customer *expects* that the source/RP will be joined via the installed route.=20 When PIM is used as PE-PE C-signaling, the installed route towards the source is always chosen as UHM. If different VRFs have different best routes to C-S or C-RP, the Assert process is a tie breaker. No steady state duplicate traffic is sent across MVPN backbone. Now let's consider BGP as the PE-PE signaling protocol and let's assume the UMH policy is to choose the installed/best route towards C-source or C-RP. If different VRFs have different installed routes to C-S/C-RP then there will be a steady state duplication of traffic across the MVPN backbone (to the same set of PEs if MI-PMSI is used). This also requires that the egress PEs be able to discard data traffic that arrives from the "wrong" upstream PE. Such duplication of traffic might not be operationally acceptable to a service provider because of too much network bandwidth being consumed. The other UMH policy that can be used with BGP signaling where duplicates are not generated, is a single or default forwarder selection. However, single forwarder selection might not choose the installed/best route (to a multi-homed C-S/C-RP) *even* if all VRFs have the same best route to C-S/C-RP. Hence, in a MVPN where all VRFs have the same best path to C-S or C-RP, its multicast traffic might not flow via the best path as is expected by the VPN customer. 3. In section A.1.1.3, why the "each additional PE joining" row for the "upstream PE" column shows "0"? The same question for "upstream PEs" column and the "each PE leaving" row. 4. Why Appendix A assumes that the RT-constraint is deployed when BGP signaling is used? This is not a mandatory implementation. 5. Why Appendix A analyzes PIM LAN procedure with explicit tracking but not the explicit tracking using BGP-signaling?=20 6. The appendix states that "we propose here a rough estimation of the load of PEs". And it is in fact a very *rough* estimation and not even a complete *rough* estimation as it almost dismisses ASM analysis. The appendix treats different and, in fact, not comparable kinds of "processing" as *equal* and uses the same unit "m.e" to measure them.=20 For example, the first row in the table in section A.1.1.1, says that to process the first join on the upstream PE takes "1 m.e" and that the same amount of processing, "1 m.e", is required on every other PE in MVPN. Clearly, the amount of processing on the upstream PE to which the joined is destined is not the same as the "processing" on other PEs. Any other PE than the upstream PE will simply discard this Join because the neighbor address in the PIM Join is not this PE address. While the upstream PE has to create the (s,g) state in the control plane, program the data plane for forwarding, and send Join (s,g) message upstream. This is by any measure much more processing than discarding the Join based on the address. Yet, it is assumed that the resources used in both cases are the same.=20 Another example is the row "each PE leaving" (but last) in the same table in section A.1.1.1. The only processing the upstream PE does is setting a timer for receiving prune-override PIM Join message, and when such PIM join is received it cancels the timer. This is estimated as "2 m.e", yet, this is much less "work" to be done by the upstream PE than in the previous "first PE joins" example. In addition, the column "other PEs" in the row "each PE leaving" states that every other PE in MVPN will also have to do an action worth "2 m.e". Yet, only the PEs that have interested receivers in (s,g) have to perform a task (i.e., randomly generate a join message delay timer and cancel it when they hear a join from another PE; only one of those PEs will send a PIM Join message). The PEs that do need to receive (s,g) traffic will simply drop the (s,g) prune message. Hence, the application of the multiplier #MVPN_PE in this row/column is also not correct. This "problem" of treating not equal actions as equal repeats itself throughout the scaling analysis in the appendix. Such analysis is not only *rough* but misleading, and because of this may lead to wrong conclusions. I believe that unless the appendix A is corrected by removing all not comparable, or even wrong estimations, it should be removed from the draft.=20 Maria From wwwrun@core3.amsl.com Fri Dec 11 10:58:15 2009 Return-Path: X-Original-To: l3vpn@ietf.org Delivered-To: l3vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 767F83A68DA; Fri, 11 Dec 2009 10:58:15 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs' to Proposed Standard Message-Id: <20091211185815.767F83A68DA@core3.amsl.com> Date: Fri, 11 Dec 2009 10:58:15 -0800 (PST) Cc: l3vpn chair , Internet Architecture Board , l3vpn mailing list , RFC Editor 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, 11 Dec 2009 18:58:15 -0000 The IESG has approved the following document: - 'BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs ' as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Ross Callon and Adrian Farrel. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt Technical Summary This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in the related document draft-ietf-l3vpn-2547bis-mcast. Working Group Summary The L3VPN WG has been working on multicast for many years, with significant difficulty coming to consensus. This document is put forth with draft-ietf-l3vpn-2547bis-mcast. Interoperability and default deployment modes are a concern because of the large number of options and features provided in each of these specifications. These concerns are being addressed by draft-ietf-l3vpn-mvpn- considerations, which will be submitted very shortly as well. After much deliberation and consideration in the WG and among relevant stake holders this is the most feasible path forward. Document Quality Many of the options described in this document are implemented and widely deployed. The related document draft-ietf-l3vpn-mvpn- considerations is co-authored by experts from multiple service providers based largely on deployement experience. Personnel Danny McPherson is the Document Shepherd for this document. Ross Callon is is the Responsible Area Director. RFC Editor Note In section 2 ("Introduction"), second paragraph: OLD This document defines a new NLRI, MCAST-VPN NLRI. The MCAST-VPN NLRI is used for MVPN auto-discovery, advertising MVPN to I-PMSI tunnel binding, advertising (C-S, C-G) to S-PMSI tunnel binding, VPN customer multicast routing information exchange among PEs, choosing a single forwarder PE, and for procedures in support of co-locating a C-RP on a PE. NEW This document defines a new NLRI, MCAST-VPN NLRI. The MCAST-VPN NLRI is used for MVPN auto-discovery, advertising MVPN to I-PMSI tunnel binding, advertising (C-S, C-G) to S-PMSI tunnel binding, VPN customer multicast routing information exchange among PEs, choosing a single forwarder PE, and for procedures in support of co-locating a C-RP on a PE. This NLRI does not apply to communications between CE and PE equipment. In section 8 ("PE Distinguisher Labels Attribute"), third paragraph: OLD The attribute is also considered to be malformed if the PE Address field is expected to be an IPv4 address, and the length of the attribute minus 4 is not a multiple of 3, or the PE Address field is expected to be an IPv6 address, and the length of the attribute minus 16 is not a multiple of 3. NEW The attribute is also considered to be malformed if the PE Address field is expected to be an IPv4 address, and the length of the attribute is not a multiple of 7, or the PE Address field is expected to be an IPv6 address, and the length of the attribute is not a multiple of 19. In section 17 ("Security Considerations"), replace first paragraph: OLD The mechanisms described in this document could re-use the existing BGP security mechanisms. NEW The mechanisms described in this document could re-use the existing BGP security mechanisms [RFC4271][RFC4272]. The security model and threats specific to Provider Provisioned VPNs, including L3VPNs, are discussed in [RFC4111]. [MVPN] discusses additional threats specific to the use of multicast in L3VPNs. There is currently work in progress to improve the security of TCP authentication. When the document is finalized as an RFC, the method defined in [draft-ietf-tcpm-tcp-auth-opt] SHOULD be used where authentication of BGP control packets is needed. In Section 18 ("IANA Considerations"), first paragraph: OLD This document defines a new BGP Extended Community called Source AS. This community is 2-octet AS specific, of an extended type, and is transitive. NEW This document defines a new BGP Extended Community called Source AS. This community is of an extended type, and is transitive. This document requests allocation of the Type value for this community from both the Two-octet AS Specific Extended Community and the Four-octet AS Specific Extended Community registries. Moreover, the document requests allocating the same Type value from both of these registries. Please add an informative reference (section 21.2) to RFC4111, RFC4272, and draft-ietf-tcpm-tcp-auth-opt. From erosen@cisco.com Mon Dec 14 07:24:34 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 D9C9028C129 for ; Mon, 14 Dec 2009 07:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 XmyMfYZuOE1b for ; Mon, 14 Dec 2009 07:24:34 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C1D8128C124 for ; Mon, 14 Dec 2009 07:24:33 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,395,1257120000"; d="scan'208";a="74131942" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Dec 2009 15:24:20 +0000 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 nBEFOKLK028195; Mon, 14 Dec 2009 15:24:20 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 nBEFOJ9G004299; Mon, 14 Dec 2009 10:24:19 -0500 To: Yakov Rekhter Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 In-reply-to: Your message of Tue, 08 Dec 2009 07:08:19 -0800. <200912081508.nB8F8Jj31633@magenta.juniper.net> Date: Mon, 14 Dec 2009 10:24:19 -0500 Message-ID: <4298.1260804259@erosen-linux> From: Eric Rosen Cc: erosen@cisco.com, Thomas Morin , 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: Mon, 14 Dec 2009 15:24:35 -0000 Eric> Scalability for S-PMSIs: Comparable scalability Yakov> when C-multicast routing is done with BGP, as when BGP is used for Yakov> C-multicast routing, segmented P-tunnels are more scalable than Yakov> non-segmented due to the ability to aggregate segmented S-PMSIs with Yakov> I-PMSIs. I don't see the relevance of this point. What does "the ability to aggregate segmented S-PMSIs with I-PMSIs" have to do with the scalability of S-PMSIs. Eric> Complexity at ASBRs: segmented more complex (requires ASBRs to have Eric> more VPN-specific knowledge, and some options increased configuration Eric> at ASBRs) Yakov> To be more precise, depending on whether inter-AS I-PMSI auto-discovery Yakov> routes are at the granularity of or MVPN>, the segmented P-tunnels would require either the same or Yakov> additional configuration on ASBRs as the non-segmented P-tunnels. To be even more precise, the more scalable option requires per-MVPN configuration on each ASBR, and even the less scalable option requires more complexity on the ASBRs. Eric> Compatibility with existing implementations: non-segmented provides Eric> this, segmented does not. Yakov> having non-segmented P-tunnels, by itself, does not provide Yakov> compatibility with "existing implementations". It would indeed be more precise to say that non-segmented P-tunnels is a necessary but not always sufficient feature for interworking new deployments with old. Yakov> an implementation of non-segmented inter-AS I-PMSI P-tunnels with Yakov> BGP-based auto-discovery, as specified in draft-ietf-l3vpn-mcast-bgp Yakov> is *not* compatible with "existing implementations" of non-segmented Yakov> inter-AS I-PMSI P-tunnels with BGP-based auto-discovery based on Yakov> MDT-SAFI, even if both of these implementations use non-segmented Yakov> P-tunnels. Actually, I believe these two implementations will interwork correctly, as is, when there is an "option C" interconnect, PIM/MI-PMSI is used as the PE-PE control protocol, S-PMSI Joins are used, and the MI-PMSI is set up using a sparse mode group address. In an "option B" interconnect, new implementations would have to include and parse the "connector attribute" as well as the "RT VRF Import Attribute" in order to interwork with old implementations; a very simple and straightforward interworking technique that is not available with segmented inter-AS P-tunnels. Thomas proposes to change the phrase "in order to maintain backwards compatibility and for migration" to "in order to facilitate co-existence with existing deployments, and provide a lighter engineering in some scenarios". I think it would be better to say "in order to facilitate interworking with and migration from existing deployments, and to provide a simpler solution when the complexity of segmented inter-AS P-tunnels is not needed." From yakov@juniper.net Mon Dec 14 07:56:46 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 C04FE3A686E for ; Mon, 14 Dec 2009 07:56:46 -0800 (PST) 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 EdDsqvi0POET for ; Mon, 14 Dec 2009 07:56:46 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id BC7F83A68D4 for ; Mon, 14 Dec 2009 07:56:40 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKSyZgK/0cvthoktrjNuP56LSQ/URBv7Pd@postini.com; Mon, 14 Dec 2009 07:56:29 PST 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.393.1; Mon, 14 Dec 2009 07:51:25 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 07:51:25 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 07:51:24 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 07:51:24 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBEFpOj67017; Mon, 14 Dec 2009 07:51:24 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912141551.nBEFpOj67017@magenta.juniper.net> To: "NAPIERALA, MARIA H (ATTLABS)" Subject: Re: Fwd: draft-ietf-l3vpn-mvpn-considerations-05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97811.1260805884.1@juniper.net> Date: Mon, 14 Dec 2009 07:51:24 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 14 Dec 2009 15:51:24.0968 (UTC) FILETIME=[4A495A80:01CA7CD5] Cc: Thomas Morin , 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, 14 Dec 2009 15:56:46 -0000 Maria, > 6. The appendix states that "we propose here a rough estimation of the > load of PEs". And it is in fact a very *rough* estimation and not even a > complete *rough* estimation as it almost dismisses ASM analysis. The > appendix treats different and, in fact, not comparable kinds of > "processing" as *equal* and uses the same unit "m.e" to measure them. > For example, the first row in the table in section A.1.1.1, says that to > process the first join on the upstream PE takes "1 m.e" and that the > same amount of processing, "1 m.e", is required on every other PE in > MVPN. Clearly, the amount of processing on the upstream PE to which the > joined is destined is not the same as the "processing" on other PEs. Any > other PE than the upstream PE will simply discard this Join because the > neighbor address in the PIM Join is not this PE address. While the > upstream PE has to create the (s,g) state in the control plane, program > the data plane for forwarding, and send Join (s,g) message upstream. > This is by any measure much more processing than discarding the Join > based on the address. Yet, it is assumed that the resources used in both > cases are the same. To address the above I would propose to replace: Though the type of processing, messages and states, may vary with the different approaches, we propose here a rough estimation of the load of PEs, in terms of number of messages processed and number of control plane states maintained. with the following: Though the overhead of message processing and the state overhead may vary between different approaches, and even within the same approach between different equipments (PEs or RRs), we propose here a rough estimation of the load of PEs, in terms of number of messages processed and number of control plane states maintained. Yakov. From yakov@juniper.net Mon Dec 14 08:09:10 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8503A6898 for ; Mon, 14 Dec 2009 08:09:10 -0800 (PST) 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 XJj5A9c7tO+p for ; Mon, 14 Dec 2009 08:09:09 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 4AB1C3A67E2 for ; Mon, 14 Dec 2009 08:09:08 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSyZjFpvjD5NR1OIEpZOfMaEu89fMdyYO@postini.com; Mon, 14 Dec 2009 08:08:56 PST 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.393.1; Mon, 14 Dec 2009 08:05:16 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 08:05:16 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 08:05:16 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 08:05:16 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBEG5Fj73715; Mon, 14 Dec 2009 08:05:15 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912141605.nBEG5Fj73715@magenta.juniper.net> To: erosen@cisco.com Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 In-Reply-To: <4298.1260804259@erosen-linux> References: <4298.1260804259@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Mon, 14 Dec 2009 10:24:19 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98972.1260806715.1@juniper.net> Date: Mon, 14 Dec 2009 08:05:15 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 14 Dec 2009 16:05:16.0239 (UTC) FILETIME=[39C33DF0:01CA7CD7] Cc: Thomas Morin , 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: Mon, 14 Dec 2009 16:09:10 -0000 Eric, > Eric> Scalability for S-PMSIs: Comparable scalability > > Yakov> when C-multicast routing is done with BGP, as when BGP is used for > Yakov> C-multicast routing, segmented P-tunnels are more scalable than > Yakov> non-segmented due to the ability to aggregate segmented S-PMSIs with > Yakov> I-PMSIs. > > I don't see the relevance of this point. What does "the ability to > aggregate segmented S-PMSIs with I-PMSIs" have to do with the scalability of > S-PMSIs. For one thing, in the multi-AS scenario it allows (downstream) ASes to reduce the overhead due to S-PMSIs by aggregating them into I-PMSIs. In addition, in the multi-AS scenario it allows (downstream) ASes to aggregate P-tunnels of the intra-AS segments of S-PMSIs, thus reducing the overhead due to S-PMSIs. Yakov. From yakov@juniper.net Mon Dec 14 08:27:01 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 2127A3A68F1 for ; Mon, 14 Dec 2009 08:27:01 -0800 (PST) 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 Vwm+3ISTjyOK for ; Mon, 14 Dec 2009 08:27:00 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 65D483A67D1 for ; Mon, 14 Dec 2009 08:26:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSyZnP+QSYkjisZjXLn9NCL2T+MCcHn9E@postini.com; Mon, 14 Dec 2009 08:26:45 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Mon, 14 Dec 2009 08:23:40 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 08:23:40 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 08:23:40 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 08:23:40 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBEGNej84217; Mon, 14 Dec 2009 08:23:40 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912141623.nBEGNej84217@magenta.juniper.net> To: erosen@cisco.com Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 In-Reply-To: <4298.1260804259@erosen-linux> References: <4298.1260804259@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Mon, 14 Dec 2009 10:24:19 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <615.1260807819.1@juniper.net> Date: Mon, 14 Dec 2009 08:23:40 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 14 Dec 2009 16:23:40.0412 (UTC) FILETIME=[CBE6ABC0:01CA7CD9] Cc: Thomas Morin , 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: Mon, 14 Dec 2009 16:27:01 -0000 Eric, > Eric> Compatibility with existing implementations: non-segmented provides > Eric> this, segmented does not. > > Yakov> having non-segmented P-tunnels, by itself, does not provide > Yakov> compatibility with "existing implementations". > > It would indeed be more precise to say that non-segmented P-tunnels is a > necessary but not always sufficient feature for interworking new deployments > with old. > > Yakov> an implementation of non-segmented inter-AS I-PMSI P-tunnels with > Yakov> BGP-based auto-discovery, as specified in draft-ietf-l3vpn-mcast-bgp > Yakov> is *not* compatible with "existing implementations" of non-segmented > Yakov> inter-AS I-PMSI P-tunnels with BGP-based auto-discovery based on > Yakov> MDT-SAFI, even if both of these implementations use non-segmented > Yakov> P-tunnels. > > Actually, I believe these two implementations will interwork correctly, as > is, when there is an "option C" interconnect, PIM/MI-PMSI is used as the > PE-PE control protocol, S-PMSI Joins are used, and the MI-PMSI is set up > using a sparse mode group address. Incorrect. Even if "PIM/MI-PMSI is used as the PE-PE control protocol, S-PMSI Joins are used and the MI-PMSI is set up using a sparse mode group address", an implementation that follows draft-ietf-l3vpn-* will *not* interwork with "existing implementations" as according to *your own draft* (draft-rosen-vpn-mcast) the existing implementation "REQUIRES the use of the MDT-SAFI NLRI (even if PIM-SSM is not used to set up the default MDT)" (while an implemendation that follows draft-ietf-l3vpn-* is not required to use MDT-SAFI NLRI). Yakov. From erosen@cisco.com Tue Dec 15 08:05: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 B5F8A3A6A99 for ; Tue, 15 Dec 2009 08:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 wx1J58-GdTEj for ; Tue, 15 Dec 2009 08:05:31 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9B60F3A6A8D for ; Tue, 15 Dec 2009 08:05:31 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,400,1257120000"; d="scan'208";a="74494934" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Dec 2009 16:05:15 +0000 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 nBFG5EKg021368; Tue, 15 Dec 2009 16:05: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 nBFG5EOx015667; Tue, 15 Dec 2009 11:05:14 -0500 To: Yakov Rekhter Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 In-reply-to: Your message of Mon, 14 Dec 2009 08:05:15 -0800. <200912141605.nBEG5Fj73715@magenta.juniper.net> Date: Tue, 15 Dec 2009 11:05:14 -0500 Message-ID: <15666.1260893114@erosen-linux> From: Eric Rosen Cc: erosen@cisco.com, Thomas Morin , 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, 15 Dec 2009 16:05:32 -0000 Eric> What does "the ability to aggregate segmented S-PMSIs with I-PMSIs" Eric> have to do with the scalability of S-PMSIs. Yakov> For one thing, in the multi-AS scenario it allows (downstream) ASes Yakov> to reduce the overhead due to S-PMSIs by aggregating them into Yakov> I-PMSIs. This means that a downstream provider can use I-PMSIs even if an upstream provider uses S-PMSIs. That may or may not be a useful feature, but it doesn't make the use of S-PMSIs more scalable. Furthermore, this cannot be done using only the purported mandatory features of the considerations draft, it requires optional features. Yakov> In addition, in the multi-AS scenario it allows (downstream) ASes Yakov> to aggregate P-tunnels of the intra-AS segments of S-PMSIs, thus Yakov> reducing the overhead due to S-PMSIs. I don't think the ability to aggregate multiple S-PMSIs into a single P-tunnel has anything to do with I-PMSIs. In addition, non-segmented S-PMSIs can also be aggregated into a single P-tunnel. In a transit AS, the aggregation of multiple S-PMSI intra-AS segments into a single P-tunnel across that transit AS cannot be done using only the purported mandatory features of the considerations draft. I think it is somewhat misleading to say that a certain feature should be mandatory because it has certain properties, if those properties cannot be realized without the implementation of optional features. Yakov> according to *your own draft* (draft-rosen-vpn-mcast) the existing Yakov> implementation "REQUIRES the use of the MDT-SAFI NLRI That just means that an implementation without MDT-SAFI is not compliant with that draft. I don't think I ever said otherwise. From yakov@juniper.net Tue Dec 15 09:06:21 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE833A6AA7 for ; Tue, 15 Dec 2009 09:06:21 -0800 (PST) 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 zYwW+i2gVw7t for ; Tue, 15 Dec 2009 09:06:20 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with SMTP id 5EF103A688F for ; Tue, 15 Dec 2009 09:06:19 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSyfB/c2pIaauXVEu/5Oa+T79qJcf4r03@postini.com; Tue, 15 Dec 2009 09:06:07 PST 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.393.1; Tue, 15 Dec 2009 08:55:41 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 08:55:40 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 08:55:40 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 08:55:40 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBFGtdj27964; Tue, 15 Dec 2009 08:55:39 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912151655.nBFGtdj27964@magenta.juniper.net> To: erosen@cisco.com Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 In-Reply-To: <15666.1260893114@erosen-linux> References: <15666.1260893114@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Tue, 15 Dec 2009 11:05:14 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37970.1260896139.1@juniper.net> Date: Tue, 15 Dec 2009 08:55:39 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 15 Dec 2009 16:55:40.0183 (UTC) FILETIME=[6E963A70:01CA7DA7] Cc: Thomas Morin , 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: Tue, 15 Dec 2009 17:06:22 -0000 Eric, > Eric> What does "the ability to aggregate segmented S-PMSIs with I-PMSIs" > Eric> have to do with the scalability of S-PMSIs. > > Yakov> For one thing, in the multi-AS scenario it allows (downstream) ASes > Yakov> to reduce the overhead due to S-PMSIs by aggregating them into > Yakov> I-PMSIs. > > This means that a downstream provider can use I-PMSIs even if an upstream > provider uses S-PMSIs. That may or may not be a useful feature, but it > doesn't make the use of S-PMSIs more scalable. Sure it does. > Furthermore, this cannot be done using only the purported mandatory features > of the considerations draft, it requires optional features. > > Yakov> In addition, in the multi-AS scenario it allows (downstream) ASes > Yakov> to aggregate P-tunnels of the intra-AS segments of S-PMSIs, thus > Yakov> reducing the overhead due to S-PMSIs. > > I don't think the ability to aggregate multiple S-PMSIs into a single > P-tunnel has anything to do with I-PMSIs. This has to do with scalability of segmented vs non-segmented S-PMSIs. > In addition, non-segmented > S-PMSIs can also be aggregated into a single P-tunnel. By virtue of being non-segmented, non-segmentd S-PMSIs do *not* provide the ability to aggregate P-tunnels of the intra-AS *segments* of S-PMSIs (for one thing, non-segmented S-PMSIs do not have "intra-AS segments"). Yakov. From thomas.morin@orange-ftgroup.com Wed Dec 16 00:30: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 E072F3A6971 for ; Wed, 16 Dec 2009 00:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 z143+VSR0679 for ; Wed, 16 Dec 2009 00:30:52 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id A6D763A696F for ; Wed, 16 Dec 2009 00:30:51 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:30:36 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:30:36 +0100 Message-ID: <4B289AAB.9060107@orange-ftgroup.com> Date: Wed, 16 Dec 2009 09:30:35 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Eric Rosen Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / counting states in both protocols References: <3126.1259858356@erosen-linux> In-Reply-To: <3126.1259858356@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 08:30:36.0084 (UTC) FILETIME=[0A596F40:01CA7E2A] 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, 16 Dec 2009 08:30:53 -0000 Eric, working group, Eric Rosen: [...] > [...] as we will see, the analysis is not very precise about what it > counts as a "state", and this leads to some mistakes. > [...] > Another methodological error is that the analysis takes no account of the > increased amount of state that must be maintained when C-multicast trees are > set up using two different protocols, rather than just one. When PIM is > used as the PE-PE control plane, the (C-S,C-G) and (C-*,C-G) states that > drive the inter-PE control plane are the same as the one as the drive the > CE-PE control plane. When BGP is used, a given multicast state has to be > represented both as a PIM state and as a BGP state (C-multicast route). > This should really be counted as a doubling (at least) of the number of > states that need to be maintained. This is a very conservative estimate, as > the BGP states tend to contain much more information (e.g., RTs) than the > corresponding PIM states. It's clear that appendix A does not consider both > the BGP states and the PIM states, but it's never quite clear just what > states it is considering. In revision -02 of the draft, section A.3 (which is now A.1.1.3) included a change to properly take into account what you describe above, after a similar comment by Maria Napierala we received February 23th 2009. http://tools.ietf.org/rfcdiff?url2=draft-ietf-l3vpn-mvpn-considerations-02.txt#part-l12 I notice now that the correction was lost when A.1.1.3 was revised in -05. Given this: - the table in A.1.1.3 will be corrected, so that a factor 2 is added in columns 2 and 3, and the "total" updated accordingly. - I will also add a note in the introduction to indicate that a state is counted twice when both present in PIM and BGP, and a note to A.1.1.3 indicating that both PIM and BGP states have been accounted for on the receiver PEs and upstream PE. (So, this is in fact not a "methodological error", but a simple counting error.) -Thomas From thomas.morin@orange-ftgroup.com Wed Dec 16 00:33: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 445983A696F for ; Wed, 16 Dec 2009 00:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=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 HKhikAQETDf0 for ; Wed, 16 Dec 2009 00:33:23 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 01E3E3A6A16 for ; Wed, 16 Dec 2009 00:33:22 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:33:08 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:33:07 +0100 Message-ID: <4B289B43.9020200@orange-ftgroup.com> Date: Wed, 16 Dec 2009 09:33:07 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Eric Rosen Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / last receiver leaves References: <3126.1259858356@erosen-linux> In-Reply-To: <3126.1259858356@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 08:33:07.0630 (UTC) FILETIME=[64AD84E0:01CA7E2A] 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, 16 Dec 2009 08:33:24 -0000 Eric, working group, Eric Rosen: > > for each PIM Prune message, all PE routers on the LAN > work to let the upstream PE determine the answer to the > "did the last receiver leave?" question. > > I believe that only one PE router needs to send a Join in order to override > the Prune, as once the others see that Join they reset their Join timers. > Of course, actual behavior varies depending on the value of the timer and > on the random jitter. The text was already clarified in version -04, after your comments from 2009-06-11, and I provided an explanation on 2009-06-19. Previous text: The "did the last receiver leave?" question is thus implicitly replied to by all PE routers, for each PIM Prune message. You had claimed in June that the text "lead one to believe that a Prune(S,G) immediately causes lots of Join(S,G) messages to be sent", which could be argued sense because the phrase "replied to" could be understood a "a message is sent", even though it was not the intent of the text. The text now reads as follows: Thus, for each PIM Prune message, all PE routers work to let the upstream PE determine the answer to the "did the last receiver leave?" question. Indeed, when a PE sends a Prune(S,G): - all PEs parse this message, and try to find a matching state in their TIB ==> reflected by "all PE routers on the LAN work..." (- if a PE finds one, it setup a short timer to send a Prune to override the Join) - if no PE find any, after some delay, the upstream PE can determine that the last receiver has left ==> reflected by "... to let the upstream PE determine the answer to the ``did the last receiver leave?``question" I don't think that the new text carries any wrong or misleading term, since "work" properly designate what the PEs of the MVPN do, without carrying a misleading idea of multiple Join message being sent. If you can explain why you think the revised text above does not properly reflect the PIM Prune override procedures, feel free to suggest a better text (just repeating your comment from June is not helpful). > We can see that answering the "last receiver leaves" > question is a significant proportion of the work that the > C-multicast routing building block has to make, and where > the approaches differ most. > > This assertion is made without support. Ok, the introduction of appendix A is not supposed to carry quantitative conclusions, so let's just say "is part of the work" instead of "is a significant proportion of the work" in this introduction. Thanks, -Thomas From thomas.morin@orange-ftgroup.com Wed Dec 16 00:39:56 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 28C203A694E for ; Wed, 16 Dec 2009 00:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 p16sRcVyzaJl for ; Wed, 16 Dec 2009 00:39:55 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id DCBCB3A6861 for ; Wed, 16 Dec 2009 00:39:54 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:39:40 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:39:39 +0100 Message-ID: <4B289CCB.7090702@orange-ftgroup.com> Date: Wed, 16 Dec 2009 09:39:39 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Eric Rosen Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / PIM with explicit tracking References: <3126.1259858356@erosen-linux> In-Reply-To: <3126.1259858356@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 08:39:39.0878 (UTC) FILETIME=[4E79D060:01CA7E2B] 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, 16 Dec 2009 08:39:56 -0000 Eric, working group, Eric Rosen: > [...] much time is spent on examining a "PIM with explicit tracking" scheme, even > though no such scheme has been proposed. It's difficult to understand why this straw > man is discussed, while other actual proposals for using PIM are not. "PIM-SM" specifications (RFC4601, section 4.3.3, page 36): Although the mechanisms are not specified in this document, it is possible for upstream routers to explicitly track the join membership of individual downstream routers if Join suppression is disabled. A router can advertise its willingness to disable Join suppression by using the T bit in the LAN Prune Delay Hello option. Unless all PIM routers on a link negotiate this capability, explicit tracking and the disabling of the Join suppression mechanism are not possible. Nothing, as far as I know, exclude this modality of PIM from the "Full Per-MVPN PIM Peering Across a MI-PMSI" procedures described in draft-ietf-l3vpn-2547bis-mcast. So we are definitely not "discussing a straw-man". I wonder if you are possibly confusing "PIM-SM specifications" and "a PIM implementation". However, if nobody thinks it is useful to look at this use of PIM with Explicit tracking, then we can certainly remove it. As far as "other actual proposal for PIM", I guess you may be referring to proposals in draft-rosen-l3vpn-mvpn-mspmsi: of course, they are not in the scope of this document, which is restricted to the solutions described in draft-ietf-l3vpn-2547bis-mcast and draft-ietf-l3vpn-2547bis-mcast-bgp. -Thomas PS: Let me note that you did not bring up this up during the LC in June, and that this comment is not related to any new content in the revisions made since this LC. From thomas.morin@orange-ftgroup.com Wed Dec 16 00:40:12 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 018CB3A6AA0 for ; Wed, 16 Dec 2009 00:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.225, 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 a7WUyiwR7uRg for ; Wed, 16 Dec 2009 00:40:11 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id AAFD13A6A84 for ; Wed, 16 Dec 2009 00:40:10 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:39:56 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:39:55 +0100 Message-ID: <4B289CDB.8090404@orange-ftgroup.com> Date: Wed, 16 Dec 2009 09:39:55 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Eric Rosen Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / RT Constraint recommendation References: <3126.1259858356@erosen-linux> In-Reply-To: <3126.1259858356@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 08:39:55.0862 (UTC) FILETIME=[5800C760:01CA7E2B] 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, 16 Dec 2009 08:40:12 -0000 Eric, working group, Eric Rosen: > the case where the RT-Constraint mechanisms [RFC4684] is > not used is not covered; > > Since RT-constraint is not a mandatory to implement mechanism, I don't see > why this is not covered. You omitted the first part of the sentence you quoted, which actually provides the answer: following the recommendation of [I-D.ietf-l3vpn-2547bis-mcast-bgp] the case where the RT-Constraint mechanisms [RFC4684] is not used is not covered; Here is the corresponding quote in draft-ieft-2547bis-mcast-bgp (which you happen co-author) : 16. Scalability Considerations A PE should use Route Target Constrain [RT-CONSTRAIN] to advertise the Route Targets that the PE uses for the VRF Route Imports extended community (note that doing this requires just a single Route Target Constraint advertisement by the PE). This allows each C-multicast route to reach only the relevant PE, rather than all the PEs participating the an MVPN. Hence the considerations document does not cover the case where the RT-Constraint mechanism is not used. -Thomas PS: Let me note that you did not bring up this up during the LC in June, and that this comment is not related to any new content in the revisions made since this LC. From thomas.morin@orange-ftgroup.com Wed Dec 16 00:42:39 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 937953A67D8 for ; Wed, 16 Dec 2009 00:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.180, 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 AHjwkFKUwJy7 for ; Wed, 16 Dec 2009 00:42:38 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 2A1AB3A6782 for ; Wed, 16 Dec 2009 00:42:38 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:42:24 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:42:23 +0100 Message-ID: <4B289D6F.7080507@orange-ftgroup.com> Date: Wed, 16 Dec 2009 09:42:23 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Eric Rosen Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / totals across equipments References: <3126.1259858356@erosen-linux> In-Reply-To: <3126.1259858356@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 08:42:23.0439 (UTC) FILETIME=[AFF73DF0:01CA7E2B] 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, 16 Dec 2009 08:42:39 -0000 Eric, working group, Eric Rosen: > > A scalability analysis must show how the utilization of some resource or set > of resources on some system increases as some demand or set of demands > increases. The appendix proposes two resources to consider: > > Though the type of processing, messages and states, may vary with the > different approaches, we propose here a rough estimation of the load > of PEs, in terms of number of messages processed and number of > control plane states maintained. A "message processed" being a > message being parsed, a lookup being done, and some action being > taken (such has updating a control plane or data plane state). > > This is okay as one of the resources considered. If I understand this > correctly, this omits consideration of any messages received that do not > result in any "action being taken", and thus omits consideration of any > acknowledgment messages or other messages that fall into the category of > "transport overhead". It also omits consideration of messages transmitted, > thus does not distinguish actions that cause a new message to be sent from > actions that do not. So it is not a complete measure of the amount of > "messaging", but it is a factor worth considering. Yes, you could always think about refining and distinguishing more, but with a goal of looking at the orders of magnitude, I think the document already balances this aspect finely. > A "state maintained" being a multicast state kept in the control plane > memory of a PE, related to a interface or a PE being subscribed to a > multicast stream. > > This is also worth considering as an abstract measure of memory resources. Ok. > The real methodological problems begin when the analysis attempts to be > quantitative: > > The estimation unit used is the "message.equipment" (or "m.e"): one > "message.equipment" corresponding to "one equipment processing one > message" (10 m.e being "10 equipments processing each one message", > or "5 messages each processed by 2 equipments", or "1 message > processed by 10 equipment", etc.). Similarly, for the amount of > control plane state, the unit used is "state.equipment" or "s.e". > This allow to take into account the fact that a message (or a state) > can have be processed (or maintained) by more than one node. > > This "estimation unit" has no meaning whatsoever, as it does not reflect > resource utilization on any system. Suppose there are N systems, each > running an algorithm that scales as O(N). Contrast this with an alternative > in which a single system does the work of all N, running an algorithm that > scales as O(N^2). Other things being equal, the former would be considered > to be the more scalable alternative. However, if you use the "estimation > unit" of "work.equipment", you would conclude that in both schemes the work > scales as O(N^2), and hence that the schemes are equally scalable. If this > were a valid methodology, no one would ever have heard of such notions as > "distributed routing" or "datagram networks". Use of this peculiar > "estimation unit" will always bias the results towards a centralized system > and away from a distributed system. > > Any subsequent revision of Appendix A should eliminate the notion of "s.e." > or "m.e." and focus solely on the scaling of the individual systems. You already brought up a slightly different form of this argument six month ago during WG LC (June 11th). You could certainly claim that your argument "has not been addressed" and thus deserves being repeated, but the issue is that you did not care about answering me in the thread that followed on this particular point (my last email from July 10th), thus artificially delaying the resolution of this point. But, for the sake of completeness, here are elements that justify how the study is currently done: - as explained in revision -04, the choice of using these units is motivated; we need some efficient way to compare BGP and PIM on a common ground, even though the type and amount of "invididual systems" concerned by the processing of one message are not the same (sometimes only the upstream PE, sometimes only RRs, sometimes all PEs, sometimes a mix) - your argument is abstract and does not prove that the comparison done in our specific case are irrelevant - contrary to the imaginary example you take, we are looking at two distributed systems, and we observe orders of magnitude of difference (in that sense, you are beating a strawman with your example) - your argument of "no meaning whatsoever" would hold if we were looking at individual numbers like O(N**2) and saying "this is big" in the absolute, but we don't do and only do comparisons based on these estimation units - in last revisions, we reviewed the text and tables of Appendix A, and other sections, so that when a counting is mentioned and refers to a total across multiple equipement, we make sure that the reader will not be mislead into believing that we talk about a count for a given PE I can concede to you that there may be more than one way to analyze the scalability of C-multicast routing options (and Appendix A.1 proposes one of them). But the opportunity was missed to explore what an alternative way of doing the analysis would bring, as after the document went for the LC this summer you did not answer me in the thread that followed on this particular point (my last email from July 10th) ; you did not suggest a different approach until today (~6 month after). Moreover, other than from you, there were no objections to the way the analysis is done. Given all that, it is too late to request that the whole analysis be redone. -Thomas From thomas.morin@orange-ftgroup.com Wed Dec 16 00:47:54 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 45BF43A6782 for ; Wed, 16 Dec 2009 00:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] 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 Wize+0FfQcpG for ; Wed, 16 Dec 2009 00:47:53 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id A0FEB3A692C for ; Wed, 16 Dec 2009 00:47:52 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:47:38 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:47:37 +0100 Message-ID: <4B289EA9.2090500@orange-ftgroup.com> Date: Wed, 16 Dec 2009 09:47:37 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Eric Rosen Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / PIM LAN procedures References: <3126.1259858356@erosen-linux> In-Reply-To: <3126.1259858356@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 08:47:37.0719 (UTC) FILETIME=[6B4A9070:01CA7E2C] 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, 16 Dec 2009 08:47:54 -0000 Eric, working group, Eric Rosen: > > From A.1.1.1. "PIM LAN procedures, by default" > > +------------+------------+---------------+----------+--------------+ > | | upstream | other PEs | RR | total across | > | | PE (1) | (total across | (none) | all | > | | | (#mvpn_PE-1) | | equipments | > | | | PEs) | | | > +------------+------------+---------------+----------+--------------+ > | first PE | 1 m.e | #MVPN_PE-1 | / | #MVPN_PE m.e | > | joins | | m.e | | | > +------------+------------+---------------+----------+--------------+ >[...] In the sequence above the first PE joining results in all PEs processing a message (except the PE joining): - the upstream PE processes the Join and ends up propagating the state upstream and setting up forwarding state - the other PEs parse the message, and lookup their TIB to possibly find an (S,G) state; they find none and discard the information in this Join) ; note that they don't have any (S,G) state at this point >[...] > > +------------+------------+---------------+----------+--------------+ > | for *each* | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e | > | additional | | m.e | | | > | PE joining | | | | | > +------------+------------+---------------+----------+--------------+ > For each subsequent PE joining (second line in the table, quoted above): - the joining PE is transitioning its Upstream (S,G) state machine from NotJoined to Joined, and thus sends a Join (RFC 4601, section 4.5.7, p.73) - for other PEs that are already joined to (S,G) : parse the message, and lookup their TIB to find an (S,G) state, find one, and reset their timer to further delay the moment at which they would send their Join - for the other PEs that are not joined to (S,G) : parse the message, and lookup their TIB to try find an (S,G) state, find none, and discard the information in this Join) [...] > If a second PE has "processed" the Join(S,G) from the first, then it doesn't > need to send a Join if it decides to join (S,G) itself; As PIM procedures are specified (RFC 4601, section 4.5.7, p.73), even if the second PE had initially processed a message (parsed, done a lookup, discarded) from the first joining PE, this PE will still send a Join when it starts to need to send (S,G) traffic towards a CE. > > If the [first] row implies that the "other PEs" must process the join, where > "process" is defined (as it is in this Appendix) as "a message being parsed, > a lookup being done, and some action being taken (such has updating a > control plane or data plane state)", then one the [second] row is incorrect: Let's look at your reasoning, and how it could hold: - if you want to ignore that the definition of "process" includes "discarding a message" as "an action being taken", then yes, your reasoning would hold ("if first [row] implies, [..] then second row is incorrect"), but your reasoning would actually be of low interest, because in that case the first row would be invalid too... - if we count as one m.e when a PE parses a Join or Prune for which it is not the upstream, does a lookup for the corresponding (S,G) to finally discard the message, then the *two* rows are both valid The "(such has updating a control plane or data plane state)" phrase is, obviously, a non-exhaustive list of examples. When assessing the processing done by PEs, we have to reflect the work done by a PE to identify it can discard a message because it does not have any (S,G) state, after parsing the Join or Prune and doing a lookup in its TIB. We can certainly add "or discard the information in the message" in the list of examples. I see this sentence has a typo ("has"' instead of "as"), which possibly was the source of confusion : it will be fixed too. So, to avoid propagating any confusion any further, we can update the document as follows: A "message processed" being a message being parsed, a lookup being done, and some action being taken (such as, for instance, updating a control plane or data plane state or discarding the information in the message). > > The third and fifth columns above are examples of cases where the Appendix > misleadingly multiplies by #mvpn_PE. > As we see above, the #mVPN_PEs order of magnitude is definitely correct for each PE joining. Now, if we let's look at when PE leave: - each PE leaving causes a Prune to be sent (RFC 4601, section 4.5.7, end of p.73) - PEs that are joined to (S,G), parse the message, try to find an (S,G) state in their TIB, find one, and then setup a short timer to send a Prune to override the Join - PEs that are not joined to (S,G), parse the message, try to find an (S,G) state in their TIB, find none, and decide they can discard the information - the upstream PE parses the message, matches it with its (S,G) state, setups a timer and : - in the "last PE leaving" case, after a delay stop forwarding traffic - else, will not stop forwarding because of the Join sent by another PE to override the Prune The #mVPN_PEs factor here also correctly reflects the amount of work done by PEs. > > In fact, the number of messages received by a given PE does not increase in proportion to #mvpn_PE. > The content of Appendix A certainly does not imply that "the number of messages received by a given PE increases in proportion to #mvpn_PE". The #mVPN_PE factor is for the total across all PEs, not for a given PE. ( this exact same comment was in your email from June 11th, and I already replied to you June 19th : you deliberately ignored my reply, I don't think it is fair to again further propagate such irrelevant implicit claims on what the document says...) > > This problem infects the entire set of tables in the Appendix. > See above, your point is only right if you tweak what "processing a message" means up to the point of being irrelevant and not accounting for all the processing done by PEs on a LAN. Let me now highlight that the points about "prune override" and "join suppression" in your recent email where forming a large part of your comments during the LC in June, and where fueling your claims of "incorrectness" of the analysis (such as the claim that the "join suppression" was not taken into account). By not providing a precise quote of what exactly would have been "incorrect" until last week -- despite multiple requests to you to provide them, and despite the multiple clarifications I provided on the fact that "join suppression" and "prune override" where relevantly accounted for -- you have artificially delayed the clarification of this issue for roughly six months. -Thomas From thomas.morin@orange-ftgroup.com Wed Dec 16 00:51:11 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 556563A6782 for ; Wed, 16 Dec 2009 00:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 3jDOKaQhWAgJ for ; Wed, 16 Dec 2009 00:51:10 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 2D3423A692C for ; Wed, 16 Dec 2009 00:51:09 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:50:55 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 09:50:54 +0100 Message-ID: <4B289F6E.3020509@orange-ftgroup.com> Date: Wed, 16 Dec 2009 09:50:54 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Eric Rosen Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / ASM References: <3126.1259858356@erosen-linux> In-Reply-To: <3126.1259858356@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 08:50:54.0358 (UTC) FILETIME=[E07F4B60:01CA7E2C] 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, 16 Dec 2009 08:51:11 -0000 Eric, working group, Eric Rosen: > > Another methodological error is the fact that the analysis focuses heavily > on the Source-Specific Multicast mode, [...] You made this comment in June, and the document has since precisely been revised to cover ASM (section A.1.2). Still claiming that "the analysis focuses heavily on the Source-Specific Multicast mode" is just misleading. The only reason why A.1.2 (on ASM) it is smaller than A.1.1 (on SSM) is because it avoids being redundant, for the portion of the procedures for the setup and maintenance of one (S,G) SPT state or one (*,G), that are common with one (S,G) SSM state. > [...] To support the recommendations of section > 3.3, the analysis needs to focus on scenarios that relevant to actual > deployments. Some of the analysis of SSM also applies to the ASM procedures > for joining/pruning source trees, but this is not made clear, and it's > difficult for a reader to know how much of the analysis is relevant to > actual deployments. I think that the introduction of A.1.2 is clear on this: PEs will generally have to maintain one shared tree, plus one source tree for each source sending toward G; each tree resulting in an amount of processing and state maintenance similar to what is described in the scenario in Appendix A.1.1, We can make it even clearer by adding : - in the start of section A.1.2 (ASM): The conclusion in A.1.1 are reused in this section, for the parts that are common to the setup and maintenance of states related to a source tree or a shared tree. - in the introduction of section A.1.1 (on SSM): For all options provided for C-multicast routing, the procedures to setup and maintain a shortest path tree toward the source of an SSM group are the same than the procedures used to setup and maintain a shortest path tree toward an RP or a non-SSM source ; the results of this section are thus re-used in section A.1.2. > > [...] In addition to the time spent on the virtually irrelevant SSM scenario, [...] > This statement looks to me as totally abusive: - SSM by itself is certainly not an "irrelevant scenario" ; one-to-many-receivers applications certainly are part the applications of enterprise VPN customers (look at section 4.1 and 4.1.1 of RFC4834) ; at the very least you'd need to support such a claim with actual data... - as explained above, many results from the SSM case are reused in the ASM case, the behavior related to the maintenance of a tree on the the shortest path to a source or RP being common So, this "time" is not spent unwisely... > > Now let's look specifically at the ASM case. > > One of the features of the BGP solution is that there is no way, in BGP, > to represent the PIM operation of "prune source S off the (*,G) tree". > To compensate for this, every PE in a given VPN is forced to keep track of > every (S,G) stream for which any PE in that VPN has receivers. This is done > by means of the Source Active A-D routes. > > There are two options that can be used. In one option, where "inter-site > shared trees are not used", each PE functions as a C-RP, and then all the PE > of a given VPN must exchange information on all the (S,G) streams that they > see locally. This option uses BGP to do something that is very similar to > what MSDP is used for today. Let me quote from Pekka Savola's review of > this procedure: > > Active source BGP messages. This is a duplication of a > similar mechanism in MSDP (RFC3618) which has caused > much grief in Internet. Does this meant that when a > host does 'nmap -sU 224.0.0.0/4' at a VPN site, this > will result in about 268 million BGP active source > updates being sent (2^28) in the SP backbone? > > The only answer to this was to beef up the Security Considerations with > some required procedures that will prevent the PE from melting down entirely > in this case. Of course, Appendix A's methodology of only considering a > single (S,G) prevents it from seeing that this particular BGP option > uses a mechanism whose scalability is already known to be poor and which > the multicast WGs have decided not even to bring forward to IPv6. Let me note that the potential security issues of this way of supporting ASM with BGP-based C-multicast routing, is one of the reasons identified in section 4 of the document that lead us to make the recommendation that this approach should not be the only one implemented. Do you want us to remind this in Appendix A.1.2 ? ( The other claim you have that the scaling analysis in Appendix A should be extended to look at more than a single (S,G) : I will address this in a separate email. ) > In the other, more sensible option, a PE originates a Source Active A-D > route for an (S,G) only when it receives a C-multicast Join route for that > (S,G). However, the Source Active A-D route goes to all the PEs in the VPN, > not just to those that have receivers for that (S,G). I believe this means > that the amount of state a given PE maintains in the BGP scheme is > proportional to the number of (S,G) flows for which any PE in the VPN has > receivers. Actually, since the SA route contains the RD of the originating > PE, the situation is a bit worse; if (S,G) traffic is sent over the backbone > by more than one PE, the other PEs in the same VPN must maintain an (S,G) SA > A-D route for each such PE. > > In the BGP solution, even if a PE has only (*,G) receivers, or even if it > has no receivers for G at all, it must maintain state for all the (S,G)s in > the MVPN, multiplied by the average number of upstream PEs per source. You are correct that for each source sending to a group, there may be one S-A A-D route per PE upstream for this source. I will update the text accordingly. Let's also note that this won't change the orders of magnitude. (What you say in the rest of your comment is already mentioned in A.1.2.) > Strangely, this scaling issue is considered to be insignificant by Appendix > A, for the following reasons: Your claim that this scaling issue would be "considered insignificant" is not supported. Your "following reasons" is only followed by stuff related to PIM, and I find nothing in A.1.2 indicating we would downplay the dependency of BGP of the number of sources (and not either for PIM actually). > > when PIM-based C-multicast routing is used there are > ... possible control plane state transitions triggered by > the reception of (S,G) packets ; such events would induce > processing on all PEs joined to G > > Control plane state transitions triggered by the reception of data packets > have not even been mentioned to this point, and no analysis has been given > to show whether or not they cause a scaling issue, or whether any such > scaling issue is mitigated by the use of BGP. I also really don't see what > this has to do with the issue at hand, namely the added state overhead of > the Source Active A-D routes. When saying "I also really don't see what this has to do with the issue at hand" and mentioning Source Active A-D routes you are attempting to redefine the scope of the section you comment. To avoid confusion, I will address your claims on the overhead of per-source routes or messages in a separate message. > Certainly there is no analysis provided that > would show the SA A-D routes trade off in a favorable manner against the > data-driven state changes. > > when PIM-based C-multicast routing is used there are ... > possible PIM Assert messages specific to (S,G) ; this would > induce a message processing on each PE of the VPN for each > PIM Assert message > > It is true that the Source Active A-D routes eliminate the need for Assert > messages. The implication is that this is favorable for BGP; however, there > does not appear to be any analysis showing that. I don't share with you that what we state implies that the comparison with the corresponding mechanisms in PIM would be "favorable for BGP". The goal for this section is to thoroughly assess the load put on BGP or PIM as C-multicast routing protocols in the ASM case. The hard part is to find a way to compare very distinct mechanisms in PIM and BGP (as you said, one relies on dataplane driven events where the other does not, and one relies on an Assert mechanisms where the other does not, and one does not rely on BGP S-A A-D messages where the other does not). And the key is to get something meaningful in the context of A.1 (scalability wrt. number of PEs) taking into account the mechanisms in play for both PIM and BGP protocols, with hypothesis that are relevant for an operator trying to choose between the two. I think that the section properly explains why the orders of magnitude for a increased number of PEs are essentially the same for ASM than the one found for SSM. That said, precise suggestions to amend this subsection are still welcome. ( However, note that we would be wrong to give too much weight to the scenario your focus on right above ("if a PE has only (*,G) receivers, or if it has no receivers for G at all") as it is not that useful for an operator willing chose a C-multicast routing option for a deployment, and looking at the PE-PE scalability and dimensioning aspect of the issue, because you cannot count on some PEs on the MVPN not having (*,G) state or having (*,G) state but no (S,G) state, since this depends on customer multicast policy and activity. ) > The new material on ASM does not appear to contain any analysis at all, just > unsupported assertions. I don't think this is true, and your comments certainly don't support this claim. (But without anything more explicit from you, your claim is just not refutable...) That said, we can possibly make A.1.2 better, and all suggestions are welcome. (easier if we don't get an artificial 6 month delay before we get some usable feedback) -Thomas From thomas.morin@orange-ftgroup.com Wed Dec 16 06:02:12 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 2923A3A6881 for ; Wed, 16 Dec 2009 06:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] 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 bNQJql7OlEZJ for ; Wed, 16 Dec 2009 06:02:11 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 8CF323A681C for ; Wed, 16 Dec 2009 06:02:10 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 15:01:54 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 15:01:52 +0100 Message-ID: <4B28E84F.4000604@orange-ftgroup.com> Date: Wed, 16 Dec 2009 15:01:51 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Eric Rosen Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / section A.1.1.3 References: <3126.1259858356@erosen-linux> In-Reply-To: <3126.1259858356@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 14:01:52.0192 (UTC) FILETIME=[516ED400:01CA7E58] 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, 16 Dec 2009 14:02:12 -0000 Eric, working group, Eric Rosen: > Section A.1.1.3 > > The RR has to maintain all the multicast states of all the clients (PEs), as > long as those multicast states have a PMSI as input interface. That's way more multicast states than any PE has to maintain. More exactly, each RR, has to keep the states of all the PEs in its cluster. Note that this is not specific to multicast, but already true with unicast. > The analysis in this Appendix simply ignores the negative scaling effects due to the large number > of RR clients. > I think the analysis in A.1.1.3 properly takes into account the "number of RR clients": the "total state maintained" for RRs (last line of the table, fourth column) includes a 2x#R_PE factor, corresponding to each PE being a client of two RRs. As far as "negative scaling effects" are concerned, this is your own "conclusion". Based on the analysis, section A.1.1 concludes that the different approaches for C-multicast all have to overall maintain an amount of state comparable in order of magnitude (linear with the number of PEs), but spread differently on the different types of equipments. (let me also note that this specific comment above could have been done during the LC in June, but wasn't) > The claim is made that when a second PE joins (S,G), the upstream PE does > not receive a new BGP route. That may or may not be the case. The second > PE will always need to send a C-multicast Join route to the RRs; > in PIM the second PE might not need to send any message. This assertion on PIM is incorrect: RFC4601, section 4.5.7, end of p.73 : when JoinDesired transitions to true a Join is always sent. > Whether the RRs will forward > the route originated by the second PE depends upon whether that route is > more preferable (according to normal BGP procedures) than the route > originated by the first PE. This is incomplete : - for a re-advertisement to happen, the route need to be more preferable *and* have different attributes - we have to take into account the aggregation done by RRs (described in section 11.4 of draft-ietf-l3vpn-2547bis-mcast-bgp) - for each RR, whether or not he might have to re-advertise will depend on which clusters the "second PE" and "upstream PE" are in (More on this below...) > A similar observation applies when C-multicast > routes are withdrawn. (yes, similar, and especially with the same correction to make on the PIM side : a Prune is always sent when JoinDesired transitions to False for a said (S,G) because the last CE has left this stream, RFC4601 section 4.5.7, end of p.73) Now, to go back on the computation in section A.1.1.3 on BGP, you are correct that the current text does not yet properly reflects the cases where an RR may re-advertises a route they were already advertising. Let's look practically at the attributes that could vary : - next-hop : updates of the value of this attribute do not "follow" PE advertisements, being rewritten by the RR when aggregating C-multicast routes having same NLRI (section 11.4 of draft-ietf-l3vpn-2547bis-mcast-bgp) ; the advertisements made by different RRs may lead to updates of the value of this attribute - ORIGINATOR_ID : updates of the value of this attributes do not "follow" PE advertisements, as the RR rewrite it when aggregating C-multicast routes having same NLRI; the advertisements made by different RRs may lead possibly to updates of the value of this attribute, given that each RR would set ORIGINATOR_ID to a value of its own - CLUSTER_LIST : the value of this attribute only varies between clusters, changes of the value of this attributes does not "follow" PE advertisements, and only advertisements made by different RRs may lead possibly to updates of the value of this attribute - LOCAL_PREF : the value of this attribute is determined locally, this is true both for the routes advertized by each PE (which could all be configured to use the same value) and for a route that results from the aggregation by an RR of the route with the same NLRI advertised by the PEs of his cluster (the RRs could also be configured to use a local pref independent from the local_pref of the routes advertised to him) ; updates of the value of this attribute don't "follow" PE or RR advertisements Let's keep in mind that these attributes don't play any active role in C-multicast routing (contrary to the role they play in unicast). Other BGP attributes do not have, AFAIK, any particular reason to be set for C-multicast routes, and if they were, an RR (or ASBR for attributes relevant for inter-AS) could overwrite these values when aggregating these routes. Given the above, for a said C-multicast Source Tree Join (S,G) NLRI, what may force an RR to re-advertise the route with different attributes to the upstream PE would be the case of an RR of another cluster advertising a route better than its current best route. If we consider our (#R_PE -1 ) joining a said (S,G), one after the other after the first PE joining, some of these events may thus lead to a re-advertisement to the upstream PE, but the number of times this can happen is at worse the number of RRs in clusters having receivers ; plus one because of the same route for the local cluster. Given that we look at scalability with an increased number of PEs, we need to consider the possibility where all clusters have a receiver PE. With these elements in mind, it seems to me that the section A.1.1.3 need to be updated, along with an explanation in the lines of the one provided above, so that the second column reads like this: +------------+---------- | | upstream | | PE (1) | | | | | | +------------+---------- | first PE | 2 m.e | joins | (unchanged) +------------+---------- | for *each* | between 0 | additional | and 2 m.e (was zero) | PE joining | | | +------------+---------- | baseline | 0 | processing | (unchanged) | over a | | period T | +------------+---------- | for *each* | between 0 | PE leaving | and 2 m.e (was zero) | | +------------+---------- | the last | 2 m.e (unchanged) | PE leaves | +------------+---------- | total for | at most | #R_PE PEs | #RRs m.e (was 4 m.e) | | | | | | | | +------------+---------- (for clarity, the cells in lines 2,4 and 6 would also need to point to the explanation) Note that between "4 m.e" and "at most #RRs", we do not change the order of magnitude when the number of PE increases. This is not a "surprise" given the aggregation made by RRs. -Thomas PS: Let me also note, again, that your comment could have been done during the LC in June, but wasn't. From thomas.morin@orange-ftgroup.com Wed Dec 16 07:12: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 8E3893A691B for ; Wed, 16 Dec 2009 07:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.129, 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 B3cmrCWX2oUh for ; Wed, 16 Dec 2009 07:12:47 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 22AFC3A680F for ; Wed, 16 Dec 2009 07:12:45 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 16:12:30 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 16:12:30 +0100 Message-ID: <4B28F8DD.1020704@orange-ftgroup.com> Date: Wed, 16 Dec 2009 16:12:29 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Eric Rosen Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / PE-CE References: <3126.1259858356@erosen-linux> In-Reply-To: <3126.1259858356@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 15:12:30.0389 (UTC) FILETIME=[2F985E50:01CA7E62] 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, 16 Dec 2009 15:12:52 -0000 Eric, working group, Eric Rosen: > Another methodological error is that the PE-CE interactions are not taken > into account. In many scenarios the PE-PE interactions are just "noise" > when compared to the real bottleneck, the PE-CE interactions. The total > number of PIM messages processed by a PE includes PIM messages from CEs as > well as from PEs. This is a comment you had already made during the LC in June, a short thread followed on this point, and I provided reasons explaining why covering PE-CE aspects would not be a relevant extension to Appendix A. Unfortunately, you left my email from July 10th without a reply. > Suppose that by adding BGP, you could reduce this total > number of PIM messages by 1%, at the cost of doubling the amount of state > you need to maintain. Would that be a good tradeoff? Come on, Eric, who do you think will buy such a cheap tradesman trick ?... ;-) > In order to support > the recommendations of section 3.3, Appendix A has to show that the > tradeoff is a lot better than this. Yet it doesn't even attempt to do so. The scope of Appendix A is to provide insight to the arguments in section 3.3 which aim at comparing the C-multicast PE-PE multicast routing options, by looking at scalability with an increased number of PEs, and the cost of a PE joining or leaving. What you only did in your recent comments is build a specific scenario where you show that PE-CE is "the bottleneck". It certainly does not mean that this is always the case. And the concluding recommendations do address the case when PE-CE would be the bottleneck (as explained below). Thus, I stand that what is said in section 3.3 or Appendix A for these matters does not mandate extending the scope of the PE-PE scaling analysis to the PE-CE overhead. > > The methodological problem here is that Appendix A does not consider > the PIM > overhead on the VRF interfaces. But when BGP C-multicast routing is > added, > it does not replace the C-PIM instance for a given MVPN, it just > reduces by > 1 the number of PIM interfaces supported by that C-PIM interface. By > ignoring this fact (and by ignoring the cost of adding a second multicast > protocol without removing PIM) one makes a small difference look much more > significant than it really is. It is not valid for a scalability analysis > to focus on just one aspect of the protocols unless it has first shown > that > that one aspect is the bottleneck. I have already explained in the past, and again in the beginning of this email, why PE-CE is not part of the analysis in Appendix A. What *you* are doing is focusing on "steady state" (with a definition of steady state that is probably not relevant by the way) to convince us that PE-CE is the bottleneck. While the analysis in A.1 is precisely *not* focusing on steady state or non-steady state, but looking at both, so I don't think why we would have to show that any is the bottleneck. > In fact, the analysis of Appendix A fails to demonstrate any real > scaling advantage, in the steady state, for one protocol over the other. Appendix A does not "fail" to do what you suggest, since it does not need to do so and not claim doing so. Now, when you say that PE-CE may sometimes be a significant factor of the overall load due to multicast routing, I think this is reasonable, which is why the following text was added to a new sub -section of section 3.3 (section 3.3.2): The overhead associated with the PE-CE exchange of C-multicast routing is independent of the choice of the mechanism used for the PE-PE C-multicast routing. Therefore, the impact of the PE-CE C-multicast routing overhead on the overall system scalability is independent of the protocol used for PE-PE signaling, and therefore is not relevant when comparing the different approaches proposed for the PE-PE C-multicast routing. This is true even if in some operational contexts the PE-CE C-multicast routing overhead is a significant factor in the overall system overhead. Furthermore, to reflect your point that PE-CE may in some cases be an important factor, and to also reflect the fact that actually a provider will have to pounder each argument in its own deployment context, I propose to replace the following from 3.3.7: In the meantime, this recommendation would enable service providers to choose between the first and the fourth mechanism, without this choice being constrained by vendors implementation choices. with: In the meantime, this recommendation would enable a service provider to choose between the first and the fourth mechanism, without this choice being constrained by vendors implementation choices, and taking into account the peculiarities of its own deployment context by pondering the weight of the different factors into account. -Thomas From thomas.morin@orange-ftgroup.com Wed Dec 16 07:20:27 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 B45453A6994 for ; Wed, 16 Dec 2009 07:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] 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 rSqpiHNFcqr9 for ; Wed, 16 Dec 2009 07:20:25 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 32B843A6991 for ; Wed, 16 Dec 2009 07:20:25 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 16:20:10 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 16:20:10 +0100 Message-ID: <4B28FAA9.1090304@orange-ftgroup.com> Date: Wed, 16 Dec 2009 16:20:09 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Eric Rosen Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / C-multicast routing dynamics References: <3126.1259858356@erosen-linux> In-Reply-To: <3126.1259858356@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 15:20:10.0182 (UTC) FILETIME=[41A73660:01CA7E63] 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, 16 Dec 2009 15:20:28 -0000 Eric, working group, Let me first note that these comments quoted below are not specific to new content added in releases -04/-05 and should have been done during the LC in June. Eric Rosen: [...] > Also omitted from consideration are scaling issues that show up > as the rate of change of multicast states increases. No, section A.2 describes the cost of one individual PE joining and leaving, which provide the required insight to compare the behavior of the different C-multicast routing protocols for different rates of change of multicast subscription by PEs. (This section details what was briefly mentioned in the end of section A.4 since version -00 of the WG draft) > Some amount of the analysis in Appendix A is devoted to the startup and > shutdown transients, when a PE first joins an (S,G) or prunes an (S,G). Indeed... > A rather big deal is made of the "prune override" procedures. ( I don't think that the analysis focuses more on the "prune override" procedures than on any other PIM or BGP procedures. Please be more explicit. ) > I have focused this critique on the steady state, because if the > steady state (as I defined > it above) is actually reached, the startup/shutdown transients are not > very > important. I suppose one might disagree with that, but certainly thee has > been no analysis showing that the transients are more important than the > steady state. The statements above are "surprising": - first, you imply that "a steady state" may be "reached" : this certainly does not take into account that PEs joining and leaving is something that, unlike unicast routing changes, happens following customer multicast application use patterns and customer routing policy (by the way, "transient" is probably not the best term, since it is most often used for unicast routing which has specific dynamics) - second, you state that "thee has been no analysis showing that the transients are more important than the steady state" : * this is certainly true, but at the same time, there is nothing is the analysis that claim that * and the reverse (steady state more important than dynamic events) is the basis for your claim that we do not take into account the PE-CE side, but certainly has not been shown either Given the above, let me remind you of the following : Appendix A looks both at the transient scenario with some join/leave ("for each additional PE joining/leaving")*and* the steady state scenario ("baseline processing over a period T"), where for some period no PE joins or leaves. If we were to constrain the analysis to*only* the scenario "where no PE joins or leaves" (that is purely imaginary by the way, as such a period must at least start with a period where some PE join a streams, and would have an end too), we would precisely loose generality and irrelevantly narrow the scope. > It would certainly be interesting to analyze the case where there is > so much > multicast churn that steady state is never reached. However, that > cannot be > done by focusing on a single (S,G) over a limited time period. (The above statement is unsupported.) -Thomas From yakov@juniper.net Wed Dec 16 07:21:31 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 AAE093A6984 for ; Wed, 16 Dec 2009 07:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_41=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 BDpFPdBhQ0Cj for ; Wed, 16 Dec 2009 07:21:29 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with SMTP id 201493A682C for ; Wed, 16 Dec 2009 07:21:26 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSyj659kjwuNhlAOPP8YOleCvwzc0Nzhp@postini.com; Wed, 16 Dec 2009 07:21:15 PST 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.393.1; Wed, 16 Dec 2009 07:13:10 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 07:13:09 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 07:13:09 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 07:13:09 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBGFD8j71754; Wed, 16 Dec 2009 07:13:09 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912161513.nBGFD8j71754@magenta.juniper.net> To: "NAPIERALA, MARIA H (ATTLABS)" Subject: Re: Fwd: draft-ietf-l3vpn-mvpn-considerations-05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53280.1260976388.1@juniper.net> Date: Wed, 16 Dec 2009 07:13:08 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 16 Dec 2009 15:13:09.0419 (UTC) FILETIME=[46DBDFB0:01CA7E62] Cc: Thomas Morin , 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, 16 Dec 2009 15:21:31 -0000 Maria, > Clearly, the amount of processing on the upstream PE to which the > joined is destined is not the same as the "processing" on other PEs. Any > other PE than the upstream PE will simply discard this Join because the > neighbor address in the PIM Join is not this PE address. The last sentence above is incorrect. Specifically, some other than the upstream PE can *not* "simply discard" the Join(C-S, C-G)/Join(C-*, C-G) just "because the neighbor address in the Join is not this PE address", as that other PE may wish to propagate a Join(C-S, C-G)/Join(C-*, C-G) upstream. >From 4.5.7 of rfc4601: If a router wishes to propagate a Join(S,G) upstream, it must also watch for messages on its upstream interface from other routers on that subnet, and these may modify its behavior. Yakov. From mn1921@att.com Wed Dec 16 08:39:10 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598FA3A67AB for ; Wed, 16 Dec 2009 08:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.988 X-Spam-Level: X-Spam-Status: No, score=-105.988 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 ZonkYEoAdY-3 for ; Wed, 16 Dec 2009 08:39:09 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 77B963A67FA for ; Wed, 16 Dec 2009 08:39:09 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-12.tower-167.messagelabs.com!1260981532!26860742!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 18544 invoked from network); 16 Dec 2009 16:38:53 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2009 16:38:53 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBGGcmas031301; Wed, 16 Dec 2009 11:38:48 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBGGchMX031244; Wed, 16 Dec 2009 11:38:44 -0500 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: Fwd: draft-ietf-l3vpn-mvpn-considerations-05 Date: Wed, 16 Dec 2009 11:38:45 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200451C7A0@misout7msgusr7e.ugd.att.com> In-Reply-To: <200912161513.nBGFD8j71754@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: draft-ietf-l3vpn-mvpn-considerations-05 Thread-Index: Acp+Y3tc0isAOBkaQz6gTjpISVsJDQACoExA References: <200912161513.nBGFD8j71754@magenta.juniper.net> From: "NAPIERALA, MARIA H (ATTLABS)" To: "Yakov Rekhter" Cc: Thomas Morin , 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, 16 Dec 2009 16:39:10 -0000 Yakov, as Thomas correctly stated in one the e-mails he sent today: "the other PEs parse the message, and lookup their TIB to possibly=20 find an (S,G) state; they find none and discard the information in this=20 Join) ; note that they don't have any (S,G) state at this point" This is what I meant. Maria > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Yakov Rekhter > Sent: Wednesday, December 16, 2009 10:13 AM > To: NAPIERALA, MARIA H (ATTLABS) > Cc: Thomas Morin; l3vpn@ietf.org > Subject: Re: Fwd: draft-ietf-l3vpn-mvpn-considerations-05 >=20 > Maria, >=20 > > Clearly, the amount of processing on the upstream PE to which the > > joined is destined is not the same as the "processing" on other PEs. > Any > > other PE than the upstream PE will simply discard this Join because > the > > neighbor address in the PIM Join is not this PE address. >=20 > The last sentence above is incorrect. Specifically, some other than > the upstream PE can *not* "simply discard" the Join(C-S, C-G)/Join(C-*, > C-G) > just "because the neighbor address in the Join is not this PE > address", as that other PE may wish to propagate a > Join(C-S, C-G)/Join(C-*, C-G) upstream. >=20 > From 4.5.7 of rfc4601: >=20 > If a router wishes to propagate a Join(S,G) upstream, it must also > watch for messages on its upstream interface from other routers on > that subnet, and these may modify its behavior. >=20 > Yakov. From thomas.morin@orange-ftgroup.com Wed Dec 16 09:11:12 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 687633A67A4 for ; Wed, 16 Dec 2009 09:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.829 X-Spam-Level: X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] 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 BXAG2nk60jIn for ; Wed, 16 Dec 2009 09:11:08 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 535613A69EE for ; Wed, 16 Dec 2009 09:11:06 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 18:10:50 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 18:10:49 +0100 Message-ID: <4B291498.6060105@orange-ftgroup.com> Date: Wed, 16 Dec 2009 18:10:48 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Maria Napierala Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / M.Napierala's comments References: <2F1DE4DFCFF32144B771BD2C246E6A200446CE07@misout7msgusr7e.ugd.att.com> In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A200446CE07@misout7msgusr7e.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2009 17:10:49.0468 (UTC) FILETIME=[B6F9DBC0:01CA7E72] 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, 16 Dec 2009 17:11:12 -0000 Maria, working group, Find below some replies to some of your comments. But first of all : correct me if I'm wrong, but it does not seem to me that any of them is specific to changes made to the document since the WG Last Call in June.... ?? NAPIERALA, MARIA H (ATTLABS): > I have several comments on the latest version of the draft: > > 1. I believe that the draft should contain some analysis on how PIM-SM > differs when handled by BGP signaling. The difference is significant > enough to warrant at least a theoretical consideration if no significant > field experience is available. Currently, vast majority of multicast > applications used in the enterprise networks are PIM-SM based. It is > important to analyze the BGP translation of pruning source traffic off > the shared tree because this is the most significant change from PIM-SM. > "significant enough to warrant" ... but not worth making the suggestion six month after the LC ? ;-) > When BGP is used for PE-PE C-multicast signaling the data-driven PIM-SM > state changes are replaced by additional BGP (Source Active) routes and > timer-driven PIM messages. Let me point out just few aspects related to > those changes that should be considered, starting from timer-driven > Prune(S,G,rpt). > > When a single forwarder selection is the procedure used to avoid sending > duplicate packets to MVPN customers during switching from RPT to SPT, > the correct setting of the above mentioned timer to prune source traffic > off the shared tree is important. It is not going to be trivial to tune > such timer in large networks, because it can cause either duplicate > traffic (if timer is set too high) or loss of traffic (if timer is set > too low). This approach to PIM-SM changes the way the PIM-SM multicast > trees are constructed, and it is not known to what extend this can > impact existing multicast applications. > If the solution to this is to make the timer for sending Prune(S,G,rpt) > sufficiently high (to assure that SPT is created) and avoid duplicates > sent to customers by having egress PEs discard data packets received > from the "wrong" upstream PE, this should be included in MVPN > considerations draft. I personnally agree with you it would be reasonable that the draft recommends implementing these procedures ( http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-09#section-9.1.1 ) Let's propose this to the working group (keeping in mind the delay after WG LC...). > It should be also considered that it may not > always be possible for the egress PE to determine the upstream PE, in > which case the single forwarder selection has to be used. > > Regarding Source Active A-D routes, it was pointed out recently and in > the past that the amount of BGP state they generate should be analyzed. > The Appendix A ignores this important scalability aspect of > BGP-signaling. > ( I'll comment on this one in a later email, in reply to Eric Rosen comments) > The field experience shows that there are multicast applications used in > enterprise VPNs such that only control messages, but no multicast data, > are sent across MVPN backbone. When BGP-multicast signaling is used, the > Source Active A-D route is originated for every C-(S,G) flow that > registers with C-RP and such that the C-RP joins "S" across MVPN > backbone, even if no inter-site data is sent for this flow. Hence, the > BGP scheme requires not only that for any given C-(S,G) flow that enters > MVPN backbone an SA message is announced and maintained by all PEs in a > given MVPN, but that SA messages are also announced for flows that never > enter the MVPN backbone. > What you state above it true only with one way of using the BGP approach to support ASM (the one in section 14 of draft-ietf-l3vpn-2547bis-mcast-bgp)? The other way (section 13) does not have this effect, and happens to indirectly be the one recommended by draft-ietf-l3vpn-mvpn-considerations (because it is the one of the two not requiring an RP function co-located in the PE). So well, I'm not sure that this point would be very important to cover. > 2. The considerations draft should also point out the difference how BGP > vs. PIM (used as PE-PE signaling protocol) handles the upstream PE > selection in case of multi-homed sources/RPs. > > Typically, in a layer 3 VPN deployment it is not known whether or not > all VRFs of a given VPN have the same best route to a given source. In > other words, VRFs routing policies are provisioned independently of each > other. If all VRFs of a given MVPN have the same best/ installed route > to a multi-homed source/RP then this VPN customer *expects* that the > source/RP will be joined via the installed route. > > When PIM is used as PE-PE C-signaling, the installed route towards the > source is always chosen as UHM. This is not my understanding, to quote draft-ietf-l3vpn-2547bis-mcast-09, section-5.1.3: The default procedure, which MUST be implemented, is to select the route whose corresponding upstream PE address is numerically highest, where a 32-bit IP address is treated as a 32 bit unsigned integer. Call this the "default upstream PE selection". [...] Another procedure, which SHOULD be implemented, is to use the Installed UMH Route as the Selected UMH Route. > If different VRFs have different best > routes to C-S or C-RP, the Assert process is a tie breaker. No steady > state duplicate traffic is sent across MVPN backbone. > > Now let's consider BGP as the PE-PE signaling protocol and let's assume > the UMH policy is to choose the installed/best route towards C-source or > C-RP. Given the above, why is this assumption relevant ? > If different VRFs have different installed routes to C-S/C-RP then > there will be a steady state duplication of traffic across the MVPN > backbone (to the same set of PEs if MI-PMSI is used). This also requires > that the egress PEs be able to discard data traffic that arrives from > the "wrong" upstream PE. Such duplication of traffic might not be > operationally acceptable to a service provider because of too much > network bandwidth being consumed. I don't think this is a relevant drawback : - if a provider chooses the non-default UMH selection you mention, it is likely that he is fine with the bandwidth aspect, and has made sure the vendors implement the procedures to discard data traffic that arrives from the "wrong" upstream PE . - see above for the suggestion to recommend implementing the procedures required to discard data traffic that arrives from the "wrong" upstream PE (making it easier for the provider to make sure that it is ok for him to use the non-default UMH selection you mention ). > The other UMH policy that can be used > with BGP signaling where duplicates are not generated, is a single or > default forwarder selection. However, single forwarder selection might > not choose the installed/best route (to a multi-homed C-S/C-RP) *even* > if all VRFs have the same best route to C-S/C-RP. Hence, in a MVPN where > all VRFs have the same best path to C-S or C-RP, its multicast traffic > might not flow via the best path as is expected by the VPN customer. > See above. > 3. In section A.1.1.3, why the "each additional PE joining" row for the > "upstream PE" column shows "0"? The same question for "upstream PEs" > column and the "each PE leaving" row. > See reply to Eric Rosen "draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / section A.1.1.3". > 4. Why Appendix A assumes that the RT-constraint is deployed when BGP > signaling is used? This is not a mandatory implementation. > > See reply to Eric Rosen "draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / RT Constraint recommendation". > 5. Why Appendix A analyzes PIM LAN procedure with explicit tracking but > not the explicit tracking using BGP-signaling? > I'm not sure as what you call "explicit tracking using BGP-signaling". There is, AFAIK, no such thing as "explicit tracking" in the BGP procedures for C-multicast routing, and Appendix A is only about C-multicast routing options. ( Possibly you refer to the case where BGP auto-discovery procedures are used to allow a PE to know about which PEs would be leaves of S-PMSI tunnels ?) > 6. The appendix states that "we propose here a rough estimation of the > load of PEs". And it is in fact a very *rough* estimation and not even a > complete *rough* estimation as it almost dismisses ASM analysis. On "almost dismisses ASM analysis", see reply to Eric Rosen "draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / ASM". > The appendix treats different and, in fact, not comparable kinds of > "processing" as *equal* and uses the same unit "m.e" to measure them. > On "non comparable" I disagree; moreover this is not something having been brought up by anyone until now, AFAICT. > For example, the first row in the table in section A.1.1.1, says that to > process the first join on the upstream PE takes "1 m.e" and that the > same amount of processing, "1 m.e", is required on every other PE in > MVPN. Clearly, the amount of processing on the upstream PE to which the > joined is destined is not the same as the "processing" on other PEs. > > Any other PE than the upstream PE will simply discard this Join because the > neighbor address in the PIM Join is not this PE address. See correction by Yakov, which you acknowledged, and let me point out that, if you write "simply discard this Join because the neighbor address in the PIM Join is not this PE address" while you mean "parse + lookup in TIB + discard", then I disagree with you because that "parse + lookup in TIB" does not seem to me as insignificant. > While the > upstream PE has to create the (s,g) state in the control plane, program > the data plane for forwarding, and send Join (s,g) message upstream. > This is by any measure much more processing than discarding the Join > based on the address. (see above, PE that are not the upstream have more to do than merely discarding the Join based on the upstream address ). That said it is true that among the upstream PE for the first join, the upstream PE for later joins or the PEs that have (S,G) state, and the other PEs that have no (S,G) state, not all of them have the exact amount of processing to do. Where I'm not sure is about, when some equipment has more to do than another one, "how much more" it is ; it seems to me that it is in fact likely to be very much vendor specific. > Yet, it is assumed that the resources used in both > cases are the same. > Well the idea is to accept this approximation, and document it. The introduction of Appendix A already provides such an explanation, and your comment would lead to think of improving it. I see that this is what Yakov Rekhter as suggested, and I think that this is a good idea. > Another example is the row "each PE leaving" (but last) in the same > table in section A.1.1.1. The only processing the upstream PE does is > setting a timer for receiving prune-override PIM Join message, and when > such PIM join is received it cancels the timer. This is estimated as > "2 m.e" Not exactly, the "2 m.e" includes the processing of the Prune *and* the processing of the Join send by one PE to override the Prune. > , yet, this is much less "work" to be done by the upstream PE > than in the previous "first PE joins" example. (see above with reference to how we can reasonably take into account "how much less" work it is) > In addition, the column > "other PEs" in the row "each PE leaving" states that every other PE in > MVPN will also have to do an action worth "2 m.e". Yet, only the PEs > that have interested receivers in (s,g) have to perform a task (i.e., > randomly generate a join message delay timer and cancel it when they > hear a join from another PE; only one of those PEs will send a PIM Join > message). The PEs that do need to receive (s,g) traffic will simply drop > the (s,g) prune message. > This is not exact. (see the correction brought up by Yakov, for the details) > Hence, the application of the multiplier > #MVPN_PE in this row/column is also not correct. > (it is correct: see the reply to Eric Rosen "draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / PIM LAN procedures") > This "problem" of treating not equal actions as equal repeats itself > throughout the scaling analysis in the appendix. Such analysis is not > only *rough* but misleading, and because of this may lead to wrong > conclusions. I believe that unless the appendix A is corrected by > removing all not comparable, or even wrong estimations, it should be > removed from the draft. ...but you only find this suggestion worth enough bring brought forward only six month or so after the WG LC... ;-) I think that the proposed modification to the introduction of Appendix A made by Yakov is much more reasonable (copy-pasted below for easier follow up) : Though the overhead of message processing and the state overhead may vary between different approaches, and even within the same approach between different equipments (PEs or RRs), we propose here a rough estimation of the load of PEs, in terms of number of messages processed and number of control plane states maintained. -Thomas From mn1921@att.com Wed Dec 16 10:58: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 EAB4E3A6A19 for ; Wed, 16 Dec 2009 10:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.991 X-Spam-Level: X-Spam-Status: No, score=-105.991 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, 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 05HOABEsp5PK for ; Wed, 16 Dec 2009 10:58:39 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 098583A69C6 for ; Wed, 16 Dec 2009 10:58:39 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-8.tower-129.messagelabs.com!1260989903!37204200!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 7762 invoked from network); 16 Dec 2009 18:58:24 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2009 18:58:24 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBGIwK8B002740 for ; Wed, 16 Dec 2009 13:58:20 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBGIwFc0002705 for ; Wed, 16 Dec 2009 13:58:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {3BCFFDA4-C652-47C4-9299-649772EBEDB9} x-cr-hashedpuzzle: B4Rv Cr5j ETwk EduZ FO46 FhGN GGhH Ghme H5HB Kb23 NnA1 OY6W PNND Qgj9 TSVL UQes; 2; bAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAdABoAG8AbQBhAHMALgBtAG8AcgBpAG4AQABvAHIAYQBuAGcAZQAtAGYAdABnAHIAbwB1AHAALgBjAG8AbQA=; Sosha1_v1; 7; {3BCFFDA4-C652-47C4-9299-649772EBEDB9}; bQBuADEAOQAyADEAQABhAHQAdAAuAGMAbwBtAA==; Wed, 16 Dec 2009 18:57:59 GMT; UgBFADoAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbAAzAHYAcABuAC0AbQB2AHAAbgAtAGMAbwBuAHMAaQBkAGUAcgBhAHQAaQBvAG4AcwAtADAANQAgAC8AIABNAC4ATgBhAHAAaQBlAHIAYQBsAGEAJwBzACAAYwBvAG0AbQBlAG4AdABzAA== Content-class: urn:content-classes:message Subject: RE: draft-ietf-l3vpn-mvpn-considerations-05 / M.Napierala's comments Date: Wed, 16 Dec 2009 13:57:59 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200451C8AE@misout7msgusr7e.ugd.att.com> In-Reply-To: <4B291498.6060105@orange-ftgroup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 / M.Napierala's comments Thread-Index: Acp+csFhDUTG/gPqQBWv8WrbLM948gAAoxzg References: <2F1DE4DFCFF32144B771BD2C246E6A200446CE07@misout7msgusr7e.ugd.att.com> <4B291498.6060105@orange-ftgroup.com> From: "NAPIERALA, MARIA H (ATTLABS)" To: "Thomas Morin" , 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, 16 Dec 2009 18:58:41 -0000 Thomas, > > 1. I believe that the draft should contain some analysis on how PIM- > SM > > differs when handled by BGP signaling. The difference is significant > > enough to warrant at least a theoretical consideration if no > significant > > field experience is available. Currently, vast majority of multicast > > applications used in the enterprise networks are PIM-SM based. It is > > important to analyze the BGP translation of pruning source traffic > off > > the shared tree because this is the most significant change from PIM- > SM. > > >=20 > "significant enough to warrant" ... but not worth making the suggestion > six month after the LC ? ;-) You must recall that the request to analyze the BGP translation of pruning source traffic off the shared tree in MVPN-consideration draft was made several times by Eric Rosen (as well as by me) in the past. I don't think that this significant change from PIM-SM procedures can be ignored. > > When BGP is used for PE-PE C-multicast signaling the data-driven PIM- > SM > > state changes are replaced by additional BGP (Source Active) routes > and > > timer-driven PIM messages. Let me point out just few aspects related > to > > those changes that should be considered, starting from timer-driven > > Prune(S,G,rpt). > > > > When a single forwarder selection is the procedure used to avoid > sending > > duplicate packets to MVPN customers during switching from RPT to SPT, > > the correct setting of the above mentioned timer to prune source > traffic > > off the shared tree is important. It is not going to be trivial to > tune > > such timer in large networks, because it can cause either duplicate > > traffic (if timer is set too high) or loss of traffic (if timer is > set > > too low). This approach to PIM-SM changes the way the PIM-SM > multicast > > trees are constructed, and it is not known to what extend this can > > impact existing multicast applications. > > If the solution to this is to make the timer for sending > Prune(S,G,rpt) > > sufficiently high (to assure that SPT is created) and avoid > duplicates > > sent to customers by having egress PEs discard data packets received > > from the "wrong" upstream PE, this should be included in MVPN > > considerations draft. >=20 >=20 > I personnally agree with you it would be reasonable that the draft > recommends implementing these procedures ( > http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-09#section- > 9.1.1 ) Good. > > It should be also considered that it may not > > always be possible for the egress PE to determine the upstream PE, in > > which case the single forwarder selection has to be used. > > >=20 >=20 > > Regarding Source Active A-D routes, it was pointed out recently and > in > > the past that the amount of BGP state they generate should be > analyzed. > > The Appendix A ignores this important scalability aspect of > > BGP-signaling. > > >=20 > ( I'll comment on this one in a later email, in reply to Eric Rosen > comments) OK > > The field experience shows that there are multicast applications used > in > > enterprise VPNs such that only control messages, but no multicast > data, > > are sent across MVPN backbone. When BGP-multicast signaling is used, > the > > Source Active A-D route is originated for every C-(S,G) flow that > > registers with C-RP and such that the C-RP joins "S" across MVPN > > backbone, even if no inter-site data is sent for this flow. Hence, > the > > BGP scheme requires not only that for any given C-(S,G) flow that > enters > > MVPN backbone an SA message is announced and maintained by all PEs in > a > > given MVPN, but that SA messages are also announced for flows that > never > > enter the MVPN backbone. > > >=20 > What you state above it true only with one way of using the BGP > approach > to support ASM (the one in section 14 of > draft-ietf-l3vpn-2547bis-mcast-bgp)? > The other way (section 13) does not have this effect, and happens to > indirectly be the one recommended by > draft-ietf-l3vpn-mvpn-considerations (because it is the one of the two > not requiring an RP function co-located in the PE). >=20 No, what I stated above applies to section 13 (I did not even considered the implications of section 14..). The inter-site shared trees are used. When a PE receives C-multicast Join route (which triggers Source Active A-D route) it does not necessarily mean that data was actually sent across MVPN backbone. We see a lot of applications behaving that way in the field. =20 >=20 > > 2. The considerations draft should also point out the difference how > BGP > > vs. PIM (used as PE-PE signaling protocol) handles the upstream PE > > selection in case of multi-homed sources/RPs. > > > > Typically, in a layer 3 VPN deployment it is not known whether or not > > all VRFs of a given VPN have the same best route to a given source. > In > > other words, VRFs routing policies are provisioned independently of > each > > other. If all VRFs of a given MVPN have the same best/ installed > route > > to a multi-homed source/RP then this VPN customer *expects* that the > > source/RP will be joined via the installed route. > > > > When PIM is used as PE-PE C-signaling, the installed route towards > the > > source is always chosen as UHM. >=20 > This is not my understanding, to quote > draft-ietf-l3vpn-2547bis-mcast-09, section-5.1.3: >=20 > The default procedure, which MUST be implemented, is to select the > route whose corresponding upstream PE address is numerically > highest, > where a 32-bit IP address is treated as a 32 bit unsigned integer. > Call this the "default upstream PE selection". >=20 > [...] >=20 > Another procedure, which SHOULD be implemented, is to use the > Installed UMH Route as the Selected UMH Route. >=20 >=20 > > If different VRFs have different best > > routes to C-S or C-RP, the Assert process is a tie breaker. No steady > > state duplicate traffic is sent across MVPN backbone. > > > > Now let's consider BGP as the PE-PE signaling protocol and let's > assume > > the UMH policy is to choose the installed/best route towards C-source > or > > C-RP. >=20 > Given the above, why is this assumption relevant ? >=20 > > If different VRFs have different installed routes to C-S/C-RP then > > there will be a steady state duplication of traffic across the MVPN > > backbone (to the same set of PEs if MI-PMSI is used). This also > requires > > that the egress PEs be able to discard data traffic that arrives from > > the "wrong" upstream PE. Such duplication of traffic might not be > > operationally acceptable to a service provider because of too much > > network bandwidth being consumed. >=20 > I don't think this is a relevant drawback : > - if a provider chooses the non-default UMH selection you mention, it > is likely that he is fine with the bandwidth aspect, and has made sure > the vendors implement the procedures to discard data traffic that > arrives from the "wrong" upstream PE. Why not to state it? This does not come for free and requires "strong" RPF check i.e., checking the upstream PE. Are you aware of any such implementations?=20 > - see above for the suggestion to recommend implementing the procedures > required to discard data traffic that arrives from the "wrong" upstream > PE (making it easier for the provider to make sure that it is ok for > him > to use the non-default UMH selection you mention ). >=20 >=20 > > The other UMH policy that can be used > > with BGP signaling where duplicates are not generated, is a single or > > default forwarder selection. However, single forwarder selection > might > > not choose the installed/best route (to a multi-homed C-S/C-RP) > *even* > > if all VRFs have the same best route to C-S/C-RP. Hence, in a MVPN > where > > all VRFs have the same best path to C-S or C-RP, its multicast > traffic > > might not flow via the best path as is expected by the VPN customer. > > >=20 > See above. Same as above for me also. =20 > > 3. In section A.1.1.3, why the "each additional PE joining" row for > the > > "upstream PE" column shows "0"? The same question for "upstream PEs" > > column and the "each PE leaving" row. > > >=20 > See reply to Eric Rosen "draft-ietf-l3vpn-mvpn-considerations-05 / > Appendix A / section A.1.1.3". OK. I will read and reply there. =20 > > 4. Why Appendix A assumes that the RT-constraint is deployed when BGP > > signaling is used? This is not a mandatory implementation. > > > > >=20 > See reply to Eric Rosen "draft-ietf-l3vpn-mvpn-considerations-05 / > Appendix A / RT Constraint recommendation". I will read it. > > 5. Why Appendix A analyzes PIM LAN procedure with explicit tracking > but > > not the explicit tracking using BGP-signaling? > > >=20 > I'm not sure as what you call "explicit tracking using BGP-signaling". >=20 > There is, AFAIK, no such thing as "explicit tracking" in the BGP > procedures for C-multicast routing, and Appendix A is only about > C-multicast routing options. Well, in that case, PIM LAN procedure with explicit tracking should be removed also. Why would you do explicit tracking of receivers when using PIM? =20 >=20 > > 6. The appendix states that "we propose here a rough estimation of > the > > load of PEs". And it is in fact a very *rough* estimation and not > even a > > complete *rough* estimation as it almost dismisses ASM analysis. >=20 > On "almost dismisses ASM analysis", see reply to Eric Rosen > "draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / ASM". OK. I will read and reply there. =20 > > The appendix treats different and, in fact, not comparable kinds of > > "processing" as *equal* and uses the same unit "m.e" to measure them. > > >=20 > On "non comparable" I disagree; moreover this is not something having > been brought up by anyone until now, AFAICT. >=20 >=20 > > For example, the first row in the table in section A.1.1.1, says that > to > > process the first join on the upstream PE takes "1 m.e" and that the > > same amount of processing, "1 m.e", is required on every other PE in > > MVPN. Clearly, the amount of processing on the upstream PE to which > the > > joined is destined is not the same as the "processing" on other PEs. > > > > Any other PE than the upstream PE will simply discard this Join > because the > > neighbor address in the PIM Join is not this PE address. >=20 > See correction by Yakov, which you acknowledged, and let me point out > that, if you write "simply discard this Join because the neighbor > address in the PIM Join is not this PE address" while you mean "parse + > lookup in TIB + discard", then I disagree with you because that "parse > + > lookup in TIB" does not seem to me as insignificant. First of all, this is still not the same amount of work that the upstream PE has to perform, i.e., to create the (S,G) state, propagate it upstream, and set up the forwarding state. Second, this is still just *discarding* the massage based on two things: "I am not the upstream router" and "I don't have (S,G) state". This is all the work the "other PE" has to do in this case. You cannot claim that this is equal with what the upstream PE has to do, right? Third, regarding the workload on the upstream PE when BGP signaling is used, how is BGP processing accounted for? All the work that upstream PE needs to do in PIM signaling case has also to be done in BGP signaling case. But with BGP signaling, upstream PE has also to perform the BGP processing (and *parsing*), including the best path selection. I don't see this being accounted for at all on PEs. If you worry so much about the work a PE has to do to *discard* a message, why would you ignore a significant amount of BGP related work a PE? =20 > > While the > > upstream PE has to create the (s,g) state in the control plane, > program > > the data plane for forwarding, and send Join (s,g) message upstream. > > This is by any measure much more processing than discarding the Join > > based on the address. >=20 > (see above, PE that are not the upstream have more to do than merely > discarding the Join based on the upstream address ). See my comment above also. > That said it is true that among the upstream PE for the first join, the > upstream PE for later joins or the PEs that have (S,G) state, and the > other PEs that have no (S,G) state, not all of them have the exact > amount of processing to do. >=20 > Where I'm not sure is about, when some equipment has more to do than > another one, "how much more" it is ; it seems to me that it is in fact > likely to be very much vendor specific. That is why I believe that attempting such an analysis as in Appendix A is not a right way to go. And this is why I recommend removing it from the draft.=20 >=20 > > Yet, it is assumed that the resources used in both > > cases are the same. > > >=20 > Well the idea is to accept this approximation, and document it. This is precisely the problem. Such approximations are quite arbitrary and the danger is that an analysis made of such approximations might lead to wrong conclusions.=20 >=20 > The introduction of Appendix A already provides such an explanation, > and > your comment would lead to think of improving it. I see that this is > what Yakov Rekhter as suggested, and I think that this is a good idea. But improving the *description* of the issue will not solve the issue itself. >=20 > > Another example is the row "each PE leaving" (but last) in the same > > table in section A.1.1.1. The only processing the upstream PE does is > > setting a timer for receiving prune-override PIM Join message, and > when > > such PIM join is received it cancels the timer. This is estimated as > > "2 m.e" >=20 > Not exactly, the "2 m.e" includes the processing of the Prune *and* the > processing of the Join send by one PE to override the Prune. >=20 > > , yet, this is much less "work" to be done by the upstream PE > > than in the previous "first PE joins" example. >=20 > (see above with reference to how we can reasonably take into account > "how much less" work it is) >=20 >=20 > > In addition, the column > > "other PEs" in the row "each PE leaving" states that every other PE > in > > MVPN will also have to do an action worth "2 m.e". Yet, only the PEs > > that have interested receivers in (s,g) have to perform a task (i.e., > > randomly generate a join message delay timer and cancel it when they > > hear a join from another PE; only one of those PEs will send a PIM > Join > > message). The PEs that do need to receive (s,g) traffic will simply > drop > > the (s,g) prune message. > > >=20 > This is not exact. > (see the correction brought up by Yakov, for the details) See my reply above. > > Hence, the application of the multiplier > > #MVPN_PE in this row/column is also not correct. > > >=20 > (it is correct: see the reply to Eric Rosen > "draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / PIM LAN > procedures") >=20 >=20 > > This "problem" of treating not equal actions as equal repeats itself > > throughout the scaling analysis in the appendix. Such analysis is not > > only *rough* but misleading, and because of this may lead to wrong > > conclusions. I believe that unless the appendix A is corrected by > > removing all not comparable, or even wrong estimations, it should be > > removed from the draft. >=20 > ...but you only find this suggestion worth enough bring brought forward > only six month or so after the WG LC... ;-) The analysis kept changing, so I waited until it is finalized (at least by the author). I believe that it is more important to make the draft as accurate as possible than worry about the timing. I don't think anybody would want that important scaling conclusions in an IETF document be based on *rough approximations*. >=20 > I think that the proposed modification to the introduction of Appendix > A > made by Yakov is much more reasonable (copy-pasted below for easier > follow up) : >=20 > Though the overhead of message processing and the state overhead > may vary between different approaches, and even within the same > approach between different equipments (PEs or RRs), we propose > here a rough estimation of the load of PEs, in terms of number > of messages processed and number of control plane states > maintained. >=20 See my comment above on this. =20 > -Thomas From yakov@juniper.net Wed Dec 16 11:27:01 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 C2AC93A6842 for ; Wed, 16 Dec 2009 11:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_41=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 pT5SpUoornkk for ; Wed, 16 Dec 2009 11:27:00 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with SMTP id B84323A69FC for ; Wed, 16 Dec 2009 11:26:58 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSyk0dA89P7545ViTzooNeRAVltzrorbY@postini.com; Wed, 16 Dec 2009 11:26:46 PST 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.393.1; Wed, 16 Dec 2009 11:23:11 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:23:10 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:23:10 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:23:10 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBGJN9j30307; Wed, 16 Dec 2009 11:23:10 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912161923.nBGJN9j30307@magenta.juniper.net> To: Thomas Morin Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / PIM LAN procedures In-Reply-To: <4B289EA9.2090500@orange-ftgroup.com> References: <3126.1259858356@erosen-linux> <4B289EA9.2090500@orange-ftgroup.com> X-MH-In-Reply-To: Thomas Morin message dated "Wed, 16 Dec 2009 09:47:37 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78167.1260991389.1@juniper.net> Date: Wed, 16 Dec 2009 11:23:09 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 16 Dec 2009 19:23:10.0273 (UTC) FILETIME=[34108B10:01CA7E85] Cc: Eric Rosen , 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, 16 Dec 2009 19:27:01 -0000 Thomas, > Eric, working group, > > Eric Rosen: > > > > From A.1.1.1. "PIM LAN procedures, by default" > > > > +------------+------------+---------------+----------+--------------+ > > | | upstream | other PEs | RR | total across | > > | | PE (1) | (total across | (none) | all | > > | | | (#mvpn_PE-1) | | equipments | > > | | | PEs) | | | > > +------------+------------+---------------+----------+--------------+ > > | first PE | 1 m.e | #MVPN_PE-1 | / | #MVPN_PE m.e | > > | joins | | m.e | | | > > +------------+------------+---------------+----------+--------------+ > >[...] > > In the sequence above the first PE joining results in all PEs processing > a message (except the PE joining): > - the upstream PE processes the Join and ends up propagating the state > upstream and setting up forwarding state > - the other PEs parse the message, and lookup their TIB to possibly > find an (S,G) state; they find none and discard the information in this > Join) ; note that they don't have any (S,G) state at this point > > >[...] > > > > +------------+------------+---------------+----------+--------------+ > > | for *each* | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e | > > | additional | | m.e | | | > > | PE joining | | | | | > > +------------+------------+---------------+----------+--------------+ > > > > For each subsequent PE joining (second line in the table, quoted above): > - the joining PE is transitioning its Upstream (S,G) state machine > from NotJoined to Joined, and thus sends a Join (RFC 4601, section > 4.5.7, p.73) > - for other PEs that are already joined to (S,G) : parse the message, > and lookup their TIB to find an (S,G) state, find one, and reset their > timer to further delay the moment at which they would send their Join > - for the other PEs that are not joined to (S,G) : parse the message, > and lookup their TIB to try find an (S,G) state, find none, and discard > the information in this Join) > > > [...] > > If a second PE has "processed" the Join(S,G) from the first, then it > doesn't > > need to send a Join if it decides to join (S,G) itself; > > As PIM procedures are specified (RFC 4601, section 4.5.7, p.73), even if > the second PE had initially processed a message (parsed, done a lookup, > discarded) from the first joining PE, this PE will still send a Join > when it starts to need to send (S,G) traffic towards a CE. Just to add, from 4.5.7 of rfc4601: If a router wishes to propagate a Join(S,G) upstream, it must also watch for messages on its upstream interface from other routers on that subnet, and these may modify its behavior. If it sees a Join(S,G) to the correct upstream neighbor, it should suppress its own Join(S,G). which means that in order to suppress its own Join, the router should be in the state where it "wishes to propagate a Join (S,G) upstream". Clearly, that until the second PE receives Join from downstream, the second PE is *not* in the state where it "wishes" to propagate a Join upstream, and thus will *not* suppress its first Join. Yakov. From yakov@juniper.net Wed Dec 16 11:41:04 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 DDADB3A6800 for ; Wed, 16 Dec 2009 11:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 5ND3VDs8efvZ for ; Wed, 16 Dec 2009 11:41:04 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with SMTP id 366C83A6822 for ; Wed, 16 Dec 2009 11:41:02 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSyk3wKS8e0+AfxMAjR/HWrH/7z93HIXA@postini.com; Wed, 16 Dec 2009 11:40:50 PST 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.393.1; Wed, 16 Dec 2009 11:35:41 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:35:40 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:35:40 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:35:40 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBGJZej37195; Wed, 16 Dec 2009 11:35:40 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912161935.nBGJZej37195@magenta.juniper.net> To: Thomas Morin Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / C-multicast routing dynamics In-Reply-To: <4B28FAA9.1090304@orange-ftgroup.com> References: <3126.1259858356@erosen-linux> <4B28FAA9.1090304@orange-ftgroup.com> X-MH-In-Reply-To: Thomas Morin message dated "Wed, 16 Dec 2009 16:20:09 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79639.1260992139.1@juniper.net> Date: Wed, 16 Dec 2009 11:35:39 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 16 Dec 2009 19:35:40.0508 (UTC) FILETIME=[F33D51C0:01CA7E86] Cc: Eric Rosen , 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, 16 Dec 2009 19:41:05 -0000 Thomas, > Eric, working group, > > Let me first note that these comments quoted below are not specific to > new content added in releases -04/-05 and should have been done during > the LC in June. > > Eric Rosen: > [...] > > Also omitted from consideration are scaling issues that show up > > as the rate of change of multicast states increases. > > No, section A.2 describes the cost of one individual PE joining and > leaving, which provide the required insight to compare the behavior of > the different C-multicast routing protocols for different rates of > change of multicast subscription by PEs. On the topic of scaling "as the rate of change of multicast states increases" that Eric brough in his e-mail, let's keep in mind that the rate of change of multicast state is of practical significance only when it starts to impose a non-neglidgeable load on the control plane. You covered this in section 3.3.5 already. So, Eric's claim that this is "omitted from consideration" is incorrect. Yakov. From mn1921@att.com Wed Dec 16 11:52:34 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 B66B53A68BC for ; Wed, 16 Dec 2009 11:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.293 X-Spam-Level: X-Spam-Status: No, score=-106.293 tagged_above=-999 required=5 tests=[AWL=0.307, 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 cQ0SgfgrTm+q for ; Wed, 16 Dec 2009 11:52:34 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id DA0773A6894 for ; Wed, 16 Dec 2009 11:52:33 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-14.tower-161.messagelabs.com!1260993138!19822041!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 4223 invoked from network); 16 Dec 2009 19:52:19 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2009 19:52:19 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBGJqEu6007344 for ; Wed, 16 Dec 2009 14:52:14 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBGJqAqN007285 for ; Wed, 16 Dec 2009 14:52:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / RTConstraint recommendation Date: Wed, 16 Dec 2009 14:52:12 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200451C91C@misout7msgusr7e.ugd.att.com> In-Reply-To: <4B289CDB.8090404@orange-ftgroup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / RTConstraint recommendation Thread-Index: Acp+K2AWGqAIks0nReqFRbIHqe87xQAXX1Fg References: <3126.1259858356@erosen-linux> <4B289CDB.8090404@orange-ftgroup.com> From: "NAPIERALA, MARIA H (ATTLABS)" To: "Thomas Morin" , "L3VPN" , "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: Wed, 16 Dec 2009 19:52:34 -0000 RG9lcyB0aGlzIG1lYW4gdGhhdCBCR1AgQy1tdWx0aWNhc3Qgc2lnbmFsaW5nIHNob3VsZCBuZXZl ciBiZSBkZXBsb3llZCB3aXRob3V0IFJULUNvbnN0cmFpbnQgYmVjYXVzZSBvdGhlcndpc2UgaXQg d291bGQgbm90IHdvcmsgY29ycmVjdGx5L3dvdWxkIG5vdCBzY2FsZT8NCg0KTWFyaWENCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIFRob21hcyBN b3Jpbg0KPiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE2LCAyMDA5IDM6NDAgQU0NCj4gVG86 IEwzVlBOOyBFcmljIFJvc2VuDQo+IFN1YmplY3Q6IFJlOiBkcmFmdC1pZXRmLWwzdnBuLW12cG4t Y29uc2lkZXJhdGlvbnMtMDUgLyBBcHBlbmRpeCBBIC8NCj4gUlRDb25zdHJhaW50IHJlY29tbWVu ZGF0aW9uDQo+IA0KPiBFcmljLCB3b3JraW5nIGdyb3VwLA0KPiANCj4gRXJpYyBSb3NlbjoNCj4g ID4gICAgICAgIHRoZSBjYXNlIHdoZXJlIHRoZSBSVC1Db25zdHJhaW50IG1lY2hhbmlzbXMgW1JG QzQ2ODRdIGlzDQo+ICA+ICAgICAgICBub3QgdXNlZCBpcyBub3QgY292ZXJlZDsNCj4gID4NCj4g ID4gU2luY2UgUlQtY29uc3RyYWludCBpcyBub3QgYSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IG1l Y2hhbmlzbSwgSQ0KPiBkb24ndCBzZWUNCj4gID4gd2h5IHRoaXMgaXMgbm90IGNvdmVyZWQuDQo+ IA0KPiBZb3Ugb21pdHRlZCB0aGUgZmlyc3QgcGFydCBvZiB0aGUgc2VudGVuY2UgeW91IHF1b3Rl ZCwgd2hpY2ggYWN0dWFsbHkNCj4gcHJvdmlkZXMgdGhlIGFuc3dlcjoNCj4gDQo+ICAgICAgICBm b2xsb3dpbmcgdGhlIHJlY29tbWVuZGF0aW9uIG9mIFtJLUQuaWV0Zi1sM3Zwbi0yNTQ3YmlzLW1j YXN0LQ0KPiBiZ3BdDQo+ICAgICAgICB0aGUgY2FzZSB3aGVyZSB0aGUgUlQtQ29uc3RyYWludCBt ZWNoYW5pc21zIFtSRkM0Njg0XSBpcyBub3QNCj4gdXNlZA0KPiBpcyBub3QNCj4gICAgICAgIGNv dmVyZWQ7DQo+IA0KPiBIZXJlIGlzIHRoZSBjb3JyZXNwb25kaW5nIHF1b3RlIGluIGRyYWZ0LWll ZnQtMjU0N2Jpcy1tY2FzdC1iZ3AgKHdoaWNoDQo+IHlvdSBoYXBwZW4gY28tYXV0aG9yKSA6DQo+ IA0KPiAgICAgMTYuIFNjYWxhYmlsaXR5IENvbnNpZGVyYXRpb25zDQo+IA0KPiAgICAgQSBQRSBz aG91bGQgdXNlIFJvdXRlIFRhcmdldCBDb25zdHJhaW4gW1JULUNPTlNUUkFJTl0gdG8gYWR2ZXJ0 aXNlDQo+ICAgICB0aGUgUm91dGUgVGFyZ2V0cyB0aGF0IHRoZSBQRSB1c2VzIGZvciB0aGUgVlJG IFJvdXRlIEltcG9ydHMNCj4gZXh0ZW5kZWQNCj4gICAgIGNvbW11bml0eSAobm90ZSB0aGF0IGRv aW5nIHRoaXMgcmVxdWlyZXMganVzdCBhIHNpbmdsZSBSb3V0ZSBUYXJnZXQNCj4gICAgIENvbnN0 cmFpbnQgYWR2ZXJ0aXNlbWVudCBieSB0aGUgUEUpLiBUaGlzIGFsbG93cyBlYWNoIEMtbXVsdGlj YXN0DQo+ICAgICByb3V0ZSB0byByZWFjaCBvbmx5IHRoZSByZWxldmFudCBQRSwgcmF0aGVyIHRo YW4gYWxsIHRoZSBQRXMNCj4gICAgIHBhcnRpY2lwYXRpbmcgdGhlIGFuIE1WUE4uDQo+IA0KPiBI ZW5jZSB0aGUgY29uc2lkZXJhdGlvbnMgZG9jdW1lbnQgZG9lcyBub3QgY292ZXIgdGhlIGNhc2Ug d2hlcmUgdGhlDQo+IFJULUNvbnN0cmFpbnQgbWVjaGFuaXNtIGlzIG5vdCB1c2VkLg0KPiANCj4g LVRob21hcw0KPiANCj4gUFM6IExldCBtZSBub3RlIHRoYXQgeW91IGRpZCBub3QgYnJpbmcgdXAg dGhpcyB1cCBkdXJpbmcgdGhlIExDIGluDQo+IEp1bmUsDQo+IGFuZCB0aGF0IHRoaXMgY29tbWVu dCBpcyBub3QgcmVsYXRlZCB0byBhbnkgbmV3IGNvbnRlbnQgaW4gdGhlDQo+IHJldmlzaW9ucw0K PiBtYWRlIHNpbmNlIHRoaXMgTEMuDQo+IA0KDQo= From mn1921@att.com Wed Dec 16 13:16:59 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 A6C0E3A6A98 for ; Wed, 16 Dec 2009 13:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.344 X-Spam-Level: X-Spam-Status: No, score=-106.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 gtYgOaQWV1-V for ; Wed, 16 Dec 2009 13:16:58 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id ADA483A6A97 for ; Wed, 16 Dec 2009 13:16:58 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-12.tower-167.messagelabs.com!1260998203!26877233!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 10615 invoked from network); 16 Dec 2009 21:16:43 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2009 21:16:43 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBGLGdi4032215 for ; Wed, 16 Dec 2009 16:16:39 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBGLGYux032151 for ; Wed, 16 Dec 2009 16:16:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 Date: Wed, 16 Dec 2009 16:16:36 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> In-Reply-To: <4B28E84F.4000604@orange-ftgroup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 Thread-Index: Acp+WF6X19mBAQCxSGuqq7bOpMWjTQANavlw References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> From: "NAPIERALA, MARIA H (ATTLABS)" To: "Thomas Morin" , "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, 16 Dec 2009 21:16:59 -0000 VGhvbWFzLA0KDQpyZWdhcmRpbmcgbXkgcXVlc3Rpb246ICJJbiBzZWN0aW9uIEEuMS4xLjMsIHdo eSB0aGUgJ2VhY2ggYWRkaXRpb25hbCBQRSBqb2luaW5nJyByb3cgZm9yIHRoZSAndXBzdHJlYW0g UEUnIGNvbHVtbiBzaG93cyAiMCI/IiwgeW91IHBvaW50ZWQgbWUgdG8gdGhpcyBlLW1haWwuDQpQ bGVhc2Ugc2VlIG15IHJlcGxpZXMgaW4tbGluZS4NCg0KTWFyaWENCg0KDQo+IE5vdywgdG8gZ28g YmFjayBvbiB0aGUgY29tcHV0YXRpb24gaW4gIHNlY3Rpb24gQS4xLjEuMyBvbiBCR1AsIHlvdSBh cmUNCj4gY29ycmVjdCB0aGF0IHRoZSBjdXJyZW50IHRleHQgZG9lcyBub3QgeWV0IHByb3Blcmx5 IHJlZmxlY3RzIHRoZSBjYXNlcw0KPiB3aGVyZSBhbiBSUiBtYXkgcmUtYWR2ZXJ0aXNlcyBhIHJv dXRlIHRoZXkgd2VyZSBhbHJlYWR5IGFkdmVydGlzaW5nLg0KPiBMZXQncyBsb29rIHByYWN0aWNh bGx5IGF0IHRoZSBhdHRyaWJ1dGVzIHRoYXQgY291bGQgdmFyeSA6DQo+IA0KPiAgICAtIG5leHQt aG9wIDogdXBkYXRlcyBvZiB0aGUgdmFsdWUgb2YgdGhpcyBhdHRyaWJ1dGUgZG8gbm90ICJmb2xs b3ciDQo+IFBFIGFkdmVydGlzZW1lbnRzLCBiZWluZyByZXdyaXR0ZW4gYnkgdGhlIFJSIHdoZW4g YWdncmVnYXRpbmcNCj4gQy1tdWx0aWNhc3Qgcm91dGVzIGhhdmluZyBzYW1lIE5MUkkgKHNlY3Rp b24gMTEuNCBvZg0KPiBkcmFmdC1pZXRmLWwzdnBuLTI1NDdiaXMtbWNhc3QtYmdwKSA7IHRoZSBh ZHZlcnRpc2VtZW50cyBtYWRlIGJ5DQo+IGRpZmZlcmVudCBSUnMgbWF5IGxlYWQgdG8gdXBkYXRl cyBvZiB0aGUgdmFsdWUgb2YgdGhpcyBhdHRyaWJ1dGUNCg0KVGhpcyBkb2VzIG5vdCBoZWxwIGlu IHJvdXRlIGFnZ3JlZ2F0aW9uIGJlY2F1c2UgUlIgYXBwbGllcyB0aGUgT1JJR0lOQVRPUl9JRCB0 byBlYWNoIGNsaWVudCdzL2VncmVzcyBQRSByb3V0ZS4NCg0KPiAgICAtIE9SSUdJTkFUT1JfSUQg OiB1cGRhdGVzIG9mIHRoZSB2YWx1ZSBvZiB0aGlzIGF0dHJpYnV0ZXMgZG8gbm90DQo+ICJmb2xs b3ciIFBFIGFkdmVydGlzZW1lbnRzLCBhcyB0aGUgUlIgcmV3cml0ZSBpdCB3aGVuIGFnZ3JlZ2F0 aW5nIEMtDQo+IG11bHRpY2FzdCByb3V0ZXMgaGF2aW5nIHNhbWUgTkxSSTsgdGhlIGFkdmVydGlz ZW1lbnRzIG1hZGUgYnkgZGlmZmVyZW50DQo+IFJScyBtYXkgbGVhZCBwb3NzaWJseSB0byB1cGRh dGVzIG9mIHRoZSB2YWx1ZSBvZiB0aGlzIGF0dHJpYnV0ZSwgZ2l2ZW4NCj4gdGhhdCBlYWNoIFJS IHdvdWxkIHNldCBPUklHSU5BVE9SX0lEIHRvIGEgdmFsdWUgb2YgaXRzIG93bg0KPiANCg0KUmVn YXJkaW5nIHJvdXRlICphZ2dyZWdhdGlvbiogdGhlIGRyYWZ0LWlldGYtbDN2cG4tMjU0N2Jpcy1t Y2FzdC1iZ3AtMDggb25seSBzdGF0ZXMgdGhlIGZvbGxvd2luZzoNCg0KICAgIlRvIGZ1cnRoZXIg cmVkdWNlIHRoZSByb3V0aW5nIGNodXJuIGR1ZSB0byBDLW11bHRpY2FzdCByb3V0ZXMgY2hhbmdl cw0KICAgYSBSb3V0ZSBSZWZsZWN0b3IgdGhhdCByZS1hZHZlcnRpc2VzIGEgQy1tdWx0aWNhc3Qg cm91dGUgU0hPVUxEIHNldA0KICAgdGhlIE5leHQgSG9wIGZpZWxkIG9mIHRoZSBNUF9SRUFDSF9O TFJJIGF0dHJpYnV0ZSBvZiB0aGUgcm91dGUgdG8gYW4NCiAgIElQIGFkZHJlc3Mgb2YgdGhlIFJv dXRlIFJlZmxlY3Rvci4gTGlrZXdpc2UsIGFuIEFTQlIgdGhhdCByZS0NCiAgIGFkdmVydGlzZXMg YSBDLW11bHRpY2FzdCByb3V0ZSBTSE9VTEQgc2V0IHRoZSBOZXh0IEhvcCBmaWVsZCBvZiB0aGUN CiAgIE1QX1JFQUNIX05MUkkgYXR0cmlidXRlIG9mIHRoZSByb3V0ZSB0byBhbiBJUCBhZGRyZXNz IG9mIHRoZSBBU0JSLiINCg0KSXQgc3RhdGVzIG5vdGhpbmcgYWJvdXQgc2V0dGluZyBPUklHSU5B VE9SX0lEIHRvIHNlbGYgb24gUlIuIA0KDQpNYXJpYQ0K From raszuk@cisco.com Wed Dec 16 15:28:45 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 57A2F3A6AA5 for ; Wed, 16 Dec 2009 15:28:45 -0800 (PST) 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 OjKCKrMCMdUZ for ; Wed, 16 Dec 2009 15:28:44 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 7C6283A68C8 for ; Wed, 16 Dec 2009 15:28:44 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikHAJ77KEurRN+J/2dsb2JhbACEC5R2pR6BHAgBhVuQB4EvgipSBA X-IronPort-AV: E=Sophos;i="4.47,409,1257120000"; d="scan'208";a="63824789" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 16 Dec 2009 23:28:30 +0000 Received: from [192.168.1.57] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBGNSTgk015353; Wed, 16 Dec 2009 23:28:29 GMT Message-ID: <4B296D1C.6000001@cisco.com> Date: Thu, 17 Dec 2009 00:28:28 +0100 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "NAPIERALA, MARIA H (ATTLABS)" Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Morin , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 23:28:45 -0000 Hi Maria, Excellent point. Looking back at the archive of this WG I have been pointing out this issue in the past, but it was always never addressed. It seems that for this mvpn solution to work classic "bgp route reflectors" would not do the right job. They should be replaced with "multicast control aggregation" devices which would have to support it's own set of requirements and it's own advertisement rules. In fact draft already recommends to use such devices as a standalone control plane boxes. Therefor before proceeding in this WG I would like to either see all references to BGP route reflectors use removed. Alternatively they could be replaced with the new term describing their newly defined and apparently required functionality for any form of sensible operation of the proposed herein solution. Cheers, R. > Thomas, > > regarding my question: "In section A.1.1.3, why the 'each additional PE joining' row for the 'upstream PE' column shows "0"?", you pointed me to this e-mail. > Please see my replies in-line. > > Maria > > >> Now, to go back on the computation in section A.1.1.3 on BGP, you are >> correct that the current text does not yet properly reflects the cases >> where an RR may re-advertises a route they were already advertising. >> Let's look practically at the attributes that could vary : >> >> - next-hop : updates of the value of this attribute do not "follow" >> PE advertisements, being rewritten by the RR when aggregating >> C-multicast routes having same NLRI (section 11.4 of >> draft-ietf-l3vpn-2547bis-mcast-bgp) ; the advertisements made by >> different RRs may lead to updates of the value of this attribute > > This does not help in route aggregation because RR applies the ORIGINATOR_ID to each client's/egress PE route. > >> - ORIGINATOR_ID : updates of the value of this attributes do not >> "follow" PE advertisements, as the RR rewrite it when aggregating C- >> multicast routes having same NLRI; the advertisements made by different >> RRs may lead possibly to updates of the value of this attribute, given >> that each RR would set ORIGINATOR_ID to a value of its own >> > > Regarding route *aggregation* the draft-ietf-l3vpn-2547bis-mcast-bgp-08 only states the following: > > "To further reduce the routing churn due to C-multicast routes changes > a Route Reflector that re-advertises a C-multicast route SHOULD set > the Next Hop field of the MP_REACH_NLRI attribute of the route to an > IP address of the Route Reflector. Likewise, an ASBR that re- > advertises a C-multicast route SHOULD set the Next Hop field of the > MP_REACH_NLRI attribute of the route to an IP address of the ASBR." > > It states nothing about setting ORIGINATOR_ID to self on RR. > > Maria From mn1921@att.com Wed Dec 16 16:39: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 122113A6ABF for ; Wed, 16 Dec 2009 16:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.08 X-Spam-Level: X-Spam-Status: No, score=-106.08 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 FnUi3pm1nlba for ; Wed, 16 Dec 2009 16:39:27 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 5CA253A6AB8 for ; Wed, 16 Dec 2009 16:39:27 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1261010351!29782588!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 1891 invoked from network); 17 Dec 2009 00:39:12 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2009 00:39:12 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBH0d8lv015773 for ; Wed, 16 Dec 2009 19:39:08 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBH0d00N015757 for ; Wed, 16 Dec 2009 19:39:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / PIM LANprocedures Date: Wed, 16 Dec 2009 19:39:02 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200457F855@misout7msgusr7e.ugd.att.com> In-Reply-To: <4B289EA9.2090500@orange-ftgroup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / PIM LANprocedures Thread-Index: Acp+LHTyPrGgXiRMQp6n/wExTN/ooAAhCiww References: <3126.1259858356@erosen-linux> <4B289EA9.2090500@orange-ftgroup.com> From: "NAPIERALA, MARIA H (ATTLABS)" To: "Thomas Morin" , "L3VPN" , "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: Thu, 17 Dec 2009 00:39:29 -0000 VGhvbWFzLA0KDQpMZXQgbWUgcmVzdGF0ZSBzb21lIG9mIHRoZSBjb21tZW50cyBmcm9tIG15IG9y aWdpbmFsIGUtbWFpbCBzaW5jZSB5b3Ugc2FpZCB0aGF0IHNvbWUgb2YgdGhlbSB5b3UgYWRkcmVz c2VkIGluIHRoZSByZXBsaWVzIHRvIEVyaWMuIFRoaXMgaXMgKGZyYWdtZW50cykgb2Ygb25lIG9m IHRob3NlIGUtbWFpbHMuDQoNCk1hcmlhDQoNCg0KPiAgPg0KPiAgPiAgICArLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLQ0KPiAt LS0rDQo+ICA+ICAgIHwgICAgICAgICAgICB8IHVwc3RyZWFtICAgfCBvdGhlciBQRXMgICAgIHwg UlIgICAgICAgfCB0b3RhbA0KPiBhY3Jvc3MgfA0KPiAgPiAgICB8ICAgICAgICAgICAgfCBQRSAo MSkgICAgIHwgKHRvdGFsIGFjcm9zcyB8IChub25lKSAgIHwgYWxsDQo+IHwNCj4gID4gICAgfCAg ICAgICAgICAgIHwgICAgICAgICAgICB8ICgjbXZwbl9QRS0xKSAgfCAgICAgICAgICB8IGVxdWlw bWVudHMNCj4gfA0KPiAgPiAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgUEVzKSAgICAg ICAgICB8ICAgICAgICAgIHwNCj4gfA0KPiAgPiAgICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLQ0KPiAtLS0rDQo+ICA+ICAg IHwgZmlyc3QgUEUgICB8IDEgbS5lICAgICAgfCAjTVZQTl9QRS0xICAgIHwgLyAgICAgICAgfCAj TVZQTl9QRQ0KPiBtLmUgfA0KPiAgPiAgICB8IGpvaW5zICAgICAgfCAgICAgICAgICAgIHwgbS5l ICAgICAgICAgICB8ICAgICAgICAgIHwNCj4gfA0KPiAgPiAgICArLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLQ0KPiAtLS0rDQo+ ICA+Wy4uLl0NCj4gDQo+IEluIHRoZSBzZXF1ZW5jZSBhYm92ZSB0aGUgZmlyc3QgUEUgam9pbmlu ZyByZXN1bHRzIGluIGFsbCBQRXMNCj4gcHJvY2Vzc2luZw0KPiBhIG1lc3NhZ2UgKGV4Y2VwdCB0 aGUgUEUgam9pbmluZyk6DQo+ICAgLSB0aGUgdXBzdHJlYW0gUEUgcHJvY2Vzc2VzIHRoZSBKb2lu IGFuZCBlbmRzIHVwIHByb3BhZ2F0aW5nIHRoZQ0KPiAgICAgc3RhdGUgdXBzdHJlYW0gYW5kIHNl dHRpbmcgdXAgZm9yd2FyZGluZyBzdGF0ZQ0KPiAgIC0gdGhlIG90aGVyIFBFcyBwYXJzZSB0aGUg bWVzc2FnZSwgYW5kIGxvb2t1cCB0aGVpciBUSUIgdG8gcG9zc2libHkNCj4gZmluZCBhbiAoUyxH KSBzdGF0ZTsgdGhleSBmaW5kIG5vbmUgYW5kIGRpc2NhcmQgdGhlIGluZm9ybWF0aW9uIGluIHRo aXMNCj4gSm9pbikgOyBub3RlIHRoYXQgdGhleSBkb24ndCBoYXZlIGFueSAoUyxHKSBzdGF0ZSBh dCB0aGlzIHBvaW50DQoNClRoZSBwcm9jZXNzaW5nIGRlc2NyaWJlZCB1bmRlciB0aGUgZmlyc3Qg YnVsbGV0IGFib3ZlIGFsc28gbWVhbnMgc2V0dGluZyB1cCAocyxnKSBzdGF0ZSBpbiB0aGUgY29u dHJvbCBwbGFuZS4gIEkgYXNzdW1lIHRoaXMgaXMgd2hhdCB5b3UgbWVhbiBieSAicHJvY2Vzc2lu ZyIgdnMuICJwYXJzaW5nIiB1bmRlciB0aGUgc2Vjb25kIGJ1bGxldC4gKEJUVywgaWYgdGhpcyBu ZWVkcyB0byBiZSBhbmFseXplZCBkb3duIHRvIHRoZSBsZXZlbCBvZiAqcGFyc2luZyogb2YgdGhl IG1lc3NhZ2VzLCBsZXQncyBiZSBpdC4uKS4NCkNsZWFybHksIHdvcmtsb2FkIHVuZGVyIHRoZSBm aXJzdCBidWxsZXQgaXMgbm90IHRoZSBzYW1lIGFtb3VudCBvZiB3b3JrIGFzIHRoYXQgZGVzY3Jp YmVkIHVuZGVyIHRoZSBzZWNvbmQgYnVsbGV0LiBUaGUgc2Vjb25kIGJ1bGxldCBpcyBqdXN0ICpk aXNjYXJkaW5nKiB0aGUgbWFzc2FnZSBiYXNlZCBvbiB0d28gdGhpbmdzOiAiSSBhbSBub3QgdGhl IHVwc3RyZWFtIHJvdXRlciIgYW5kICJJIGRvbid0IGhhdmUgKFMsRykgc3RhdGUiLiBJdCBjYW5u b3QgYmUgY2xhaW1lZCB0aGF0IHRoaXMgaXMgZXF1YWwgd2l0aCB3aGF0IHRoZSB1cHN0cmVhbSBQ RSBoYXMgdG8gZG8uDQoNCkxldCdzIGNvbXBhcmUgaXQgd2l0aCB0aGUgZmlyc3Qgcm93ICJmaXJz dCBQRSBqb2lucyIgb2YgdGFibGUgaW4gc2VjdGlvbiBBLjEuMS4zLiBpLmUuLCB3aXRoIHRoZSB3 b3JrbG9hZCBvbiB0aGUgdXBzdHJlYW0gUEUgd2hlbiBCR1Agc2lnbmFsaW5nIGlzIHVzZWQuIEFs bCB0aGUgd29yayB0aGF0IHVwc3RyZWFtIFBFIG5lZWRzIHRvIGRvIGluIFBJTSBzaWduYWxpbmcg Y2FzZSBhbHNvIG5lZWRzIHRvIGJlIGRvbmUgaW4gQkdQIHNpZ25hbGluZyBjYXNlLiBCdXQgd2l0 aCBCR1Agc2lnbmFsaW5nLCB1cHN0cmVhbSBQRSBoYXMgYWxzbyB0byBwZXJmb3JtIHRoZSBCR1Ag cHJvY2Vzc2luZyAoYW5kICpwYXJzaW5nKiksIGluY2x1ZGluZyB0aGUgYmVzdCBwYXRoIHNlbGVj dGlvbi4gSSBkb24ndCBzZWUgdGhpcyBiZWluZyBhY2NvdW50ZWQgZm9yIGF0IGFsbCBvbiBQRXMu DQpJZiB5b3Ugd29ycnkgc28gbXVjaCBhYm91dCB0aGUgd29yayBhIFBFIGhhcyB0byBkbyB0byAq ZGlzY2FyZCogYSBtZXNzYWdlLCB3aHkgd291bGQgeW91IGlnbm9yZSBhIHNpZ25pZmljYW50IGFt b3VudCBvZiBCR1AgcmVsYXRlZCB3b3JrIG9uIGEgUEU/DQoNCg0KDQo+ICA+ICAgICstLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0t DQo+IC0tLSsNCj4gID4gICAgfCBmb3IgKmVhY2gqIHwgMSBtLmUgICAgICB8ICNtdnBuX1BFLTEg ICAgfCAvICAgICAgICB8ICNtdnBuX1BFDQo+IG0uZSB8DQo+ICA+ICAgIHwgYWRkaXRpb25hbCB8 ICAgICAgICAgICAgfCBtLmUgICAgICAgICAgIHwgICAgICAgICAgfA0KPiB8DQo+ICA+ICAgIHwg UEUgam9pbmluZyB8ICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0KPiB8 DQo+ICA+ICAgICstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tKy0tLS0tLS0tLS0tDQo+IC0tLSsNCj4gID4NCj4gDQo+IEZvciBlYWNoIHN1YnNlcXVl bnQgUEUgam9pbmluZyAoc2Vjb25kIGxpbmUgaW4gdGhlIHRhYmxlLCBxdW90ZWQNCj4gYWJvdmUp Og0KPiAgICAtIHRoZSBqb2luaW5nIFBFIGlzIHRyYW5zaXRpb25pbmcgaXRzIFVwc3RyZWFtIChT LEcpIHN0YXRlIG1hY2hpbmUNCj4gZnJvbSBOb3RKb2luZWQgdG8gSm9pbmVkLCBhbmQgdGh1cyBz ZW5kcyBhIEpvaW4gKFJGQyA0NjAxLCBzZWN0aW9uDQo+IDQuNS43LCBwLjczKQ0KPiAgICAtIGZv ciBvdGhlciBQRXMgdGhhdCBhcmUgYWxyZWFkeSBqb2luZWQgdG8gKFMsRykgOiBwYXJzZSB0aGUN Cj4gbWVzc2FnZSwNCj4gYW5kIGxvb2t1cCB0aGVpciBUSUIgdG8gZmluZCBhbiAoUyxHKSBzdGF0 ZSwgZmluZCBvbmUsIGFuZCByZXNldCB0aGVpcg0KPiB0aW1lciB0byBmdXJ0aGVyIGRlbGF5IHRo ZSBtb21lbnQgYXQgd2hpY2ggdGhleSB3b3VsZCBzZW5kIHRoZWlyIEpvaW4NCj4gICAgLSBmb3Ig dGhlIG90aGVyIFBFcyB0aGF0IGFyZSBub3Qgam9pbmVkIHRvIChTLEcpIDogcGFyc2UgdGhlDQo+ IG1lc3NhZ2UsDQo+IGFuZCBsb29rdXAgdGhlaXIgVElCIHRvIHRyeSBmaW5kIGFuIChTLEcpIHN0 YXRlLCBmaW5kIG5vbmUsIGFuZCBkaXNjYXJkDQo+IHRoZSBpbmZvcm1hdGlvbiBpbiB0aGlzIEpv aW4pDQoNClRoZSB3b3JrbG9hZCBvbiB0aGUgdXBzdHJlYW0gUEUgKGFuZCBvdGhlciBQRXMgdGhh dCBhbHJlYWR5IGhhdmUgKFMsRykgc3RhdGUpIGluIHRoaXMgY2FzZSBpcyBzaWduaWZpY2FudGx5 IGxlc3MgdGhhbiBpbiB0aGUgY2FzZSBvZiAidGhlIGZpcnN0IFBFIGpvaW5pbmciIHNpbmNlIHRo ZSBQRXMgYWxyZWFkeSBoYXZlIHRoZSAoUyxHKSBzdGF0ZS4gQnV0IGl0IGlzIGVzdGltYXRlZCBh cyB0aGUgc2FtZS4gT24gdGhvc2UgUEVzIHRoYXQgZG8gbm90IGhhdmUgKFMsRykgdGhlcmUgaXMg ZXZlbiBsZXNzIHdvcmsuIFlldCwgYWxsIGlzIGVzdGltYXRlZCBhcyB0aGUgc2FtZSBhbW91bnQg b2Ygd29yay4gDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsM3Zw bi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmDQo+IE9mIFRob21hcyBNb3Jpbg0KPiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE2LCAy MDA5IDM6NDggQU0NCj4gVG86IEwzVlBOOyBFcmljIFJvc2VuDQo+IFN1YmplY3Q6IFJlOiBkcmFm dC1pZXRmLWwzdnBuLW12cG4tY29uc2lkZXJhdGlvbnMtMDUgLyBBcHBlbmRpeCBBIC8gUElNDQo+ IExBTnByb2NlZHVyZXMNCj4gDQo+IEVyaWMsIHdvcmtpbmcgZ3JvdXAsDQo+IA0KPiBFcmljIFJv c2VuOg0KPiAgPg0KPiAgPiBGcm9tIEEuMS4xLjEuICAiUElNIExBTiBwcm9jZWR1cmVzLCBieSBk ZWZhdWx0Ig0KPiAgPg0KPiAgPiAgICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLQ0KPiAtLS0rDQo+ICA+ICAgIHwgICAgICAg ICAgICB8IHVwc3RyZWFtICAgfCBvdGhlciBQRXMgICAgIHwgUlIgICAgICAgfCB0b3RhbA0KPiBh Y3Jvc3MgfA0KPiAgPiAgICB8ICAgICAgICAgICAgfCBQRSAoMSkgICAgIHwgKHRvdGFsIGFjcm9z cyB8IChub25lKSAgIHwgYWxsDQo+IHwNCj4gID4gICAgfCAgICAgICAgICAgIHwgICAgICAgICAg ICB8ICgjbXZwbl9QRS0xKSAgfCAgICAgICAgICB8IGVxdWlwbWVudHMNCj4gfA0KPiAgPiAgICB8 ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgUEVzKSAgICAgICAgICB8ICAgICAgICAgIHwNCj4g fA0KPiAgPiAgICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLSstLS0tLS0tLS0tLQ0KPiAtLS0rDQo+ICA+ICAgIHwgZmlyc3QgUEUgICB8IDEgbS5l ICAgICAgfCAjTVZQTl9QRS0xICAgIHwgLyAgICAgICAgfCAjTVZQTl9QRQ0KPiBtLmUgfA0KPiAg PiAgICB8IGpvaW5zICAgICAgfCAgICAgICAgICAgIHwgbS5lICAgICAgICAgICB8ICAgICAgICAg IHwNCj4gfA0KPiAgPiAgICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLQ0KPiAtLS0rDQo+ICA+Wy4uLl0NCj4gDQo+IEluIHRo ZSBzZXF1ZW5jZSBhYm92ZSB0aGUgZmlyc3QgUEUgam9pbmluZyByZXN1bHRzIGluIGFsbCBQRXMN Cj4gcHJvY2Vzc2luZw0KPiBhIG1lc3NhZ2UgKGV4Y2VwdCB0aGUgUEUgam9pbmluZyk6DQo+ICAg LSB0aGUgdXBzdHJlYW0gUEUgcHJvY2Vzc2VzIHRoZSBKb2luIGFuZCBlbmRzIHVwIHByb3BhZ2F0 aW5nIHRoZQ0KPiBzdGF0ZQ0KPiB1cHN0cmVhbSBhbmQgc2V0dGluZyB1cCBmb3J3YXJkaW5nIHN0 YXRlDQo+ICAgLSB0aGUgb3RoZXIgUEVzIHBhcnNlIHRoZSBtZXNzYWdlLCBhbmQgbG9va3VwIHRo ZWlyIFRJQiB0byBwb3NzaWJseQ0KPiBmaW5kIGFuIChTLEcpIHN0YXRlOyB0aGV5IGZpbmQgbm9u ZSBhbmQgZGlzY2FyZCB0aGUgaW5mb3JtYXRpb24gaW4gdGhpcw0KPiBKb2luKSA7IG5vdGUgdGhh dCB0aGV5IGRvbid0IGhhdmUgYW55IChTLEcpIHN0YXRlIGF0IHRoaXMgcG9pbnQNCj4gDQo+ICA+ Wy4uLl0NCj4gID4NCj4gID4gICAgKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0NCj4gLS0tKw0KPiAgPiAgICB8IGZvciAqZWFj aCogfCAxIG0uZSAgICAgIHwgI212cG5fUEUtMSAgICB8IC8gICAgICAgIHwgI212cG5fUEUNCj4g bS5lIHwNCj4gID4gICAgfCBhZGRpdGlvbmFsIHwgICAgICAgICAgICB8IG0uZSAgICAgICAgICAg fCAgICAgICAgICB8DQo+IHwNCj4gID4gICAgfCBQRSBqb2luaW5nIHwgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgfCAgICAgICAgICB8DQo+IHwNCj4gID4gICAgKy0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0NCj4gLS0tKw0K PiAgPg0KPiANCj4gRm9yIGVhY2ggc3Vic2VxdWVudCBQRSBqb2luaW5nIChzZWNvbmQgbGluZSBp biB0aGUgdGFibGUsIHF1b3RlZA0KPiBhYm92ZSk6DQo+ICAgIC0gdGhlIGpvaW5pbmcgUEUgaXMg dHJhbnNpdGlvbmluZyBpdHMgVXBzdHJlYW0gKFMsRykgc3RhdGUgbWFjaGluZQ0KPiBmcm9tIE5v dEpvaW5lZCB0byBKb2luZWQsIGFuZCB0aHVzIHNlbmRzIGEgSm9pbiAoUkZDIDQ2MDEsIHNlY3Rp b24NCj4gNC41LjcsIHAuNzMpDQo+ICAgIC0gZm9yIG90aGVyIFBFcyB0aGF0IGFyZSBhbHJlYWR5 IGpvaW5lZCB0byAoUyxHKSA6IHBhcnNlIHRoZQ0KPiBtZXNzYWdlLA0KPiBhbmQgbG9va3VwIHRo ZWlyIFRJQiB0byBmaW5kIGFuIChTLEcpIHN0YXRlLCBmaW5kIG9uZSwgYW5kIHJlc2V0IHRoZWly DQo+IHRpbWVyIHRvIGZ1cnRoZXIgZGVsYXkgdGhlIG1vbWVudCBhdCB3aGljaCB0aGV5IHdvdWxk IHNlbmQgdGhlaXIgSm9pbg0KPiAgICAtIGZvciB0aGUgb3RoZXIgUEVzIHRoYXQgYXJlIG5vdCBq b2luZWQgdG8gKFMsRykgOiBwYXJzZSB0aGUNCj4gbWVzc2FnZSwNCj4gYW5kIGxvb2t1cCB0aGVp ciBUSUIgdG8gdHJ5IGZpbmQgYW4gKFMsRykgc3RhdGUsIGZpbmQgbm9uZSwgYW5kIGRpc2NhcmQN Cj4gdGhlIGluZm9ybWF0aW9uIGluIHRoaXMgSm9pbikNCj4gDQo+IA0KPiBbLi4uXQ0KPiAgPiBJ ZiBhIHNlY29uZCBQRSBoYXMgInByb2Nlc3NlZCIgdGhlIEpvaW4oUyxHKSBmcm9tIHRoZSBmaXJz dCwgdGhlbiBpdA0KPiBkb2Vzbid0DQo+ICA+IG5lZWQgdG8gc2VuZCBhIEpvaW4gaWYgaXQgZGVj aWRlcyB0byBqb2luIChTLEcpIGl0c2VsZjsNCj4gDQo+IEFzIFBJTSBwcm9jZWR1cmVzIGFyZSBz cGVjaWZpZWQgKFJGQyA0NjAxLCBzZWN0aW9uIDQuNS43LCBwLjczKSwgZXZlbg0KPiBpZg0KPiB0 aGUgc2Vjb25kIFBFIGhhZCBpbml0aWFsbHkgcHJvY2Vzc2VkIGEgbWVzc2FnZSAocGFyc2VkLCBk b25lIGEgbG9va3VwLA0KPiBkaXNjYXJkZWQpIGZyb20gdGhlIGZpcnN0IGpvaW5pbmcgUEUsIHRo aXMgUEUgd2lsbCBzdGlsbCBzZW5kIGEgSm9pbg0KPiB3aGVuIGl0IHN0YXJ0cyB0byBuZWVkIHRv IHNlbmQgKFMsRykgdHJhZmZpYyB0b3dhcmRzIGEgQ0UuDQo+IA0KPiANCj4gDQo+ICA+DQo+ICA+ IElmIHRoZSBbZmlyc3RdIHJvdyBpbXBsaWVzIHRoYXQgdGhlICJvdGhlciBQRXMiIG11c3QgcHJv Y2VzcyB0aGUNCj4gam9pbiwgd2hlcmUNCj4gID4gInByb2Nlc3MiIGlzIGRlZmluZWQgKGFzIGl0 IGlzIGluIHRoaXMgQXBwZW5kaXgpIGFzICJhIG1lc3NhZ2UgYmVpbmcNCj4gcGFyc2VkLA0KPiAg PiBhIGxvb2t1cCBiZWluZyBkb25lLCBhbmQgc29tZSBhY3Rpb24gYmVpbmcgdGFrZW4gKHN1Y2gg aGFzIHVwZGF0aW5nDQo+IGENCj4gID4gY29udHJvbCBwbGFuZSBvciBkYXRhIHBsYW5lIHN0YXRl KSIsIHRoZW4gb25lIHRoZSBbc2Vjb25kXSByb3cgaXMNCj4gaW5jb3JyZWN0Og0KPiANCj4gTGV0 J3MgbG9vayBhdCB5b3VyIHJlYXNvbmluZywgYW5kIGhvdyBpdCBjb3VsZCBob2xkOg0KPiAtIGlm IHlvdSB3YW50IHRvIGlnbm9yZSB0aGF0IHRoZSBkZWZpbml0aW9uIG9mICJwcm9jZXNzIiBpbmNs dWRlcw0KPiAiZGlzY2FyZGluZyBhIG1lc3NhZ2UiIGFzICJhbiBhY3Rpb24gYmVpbmcgdGFrZW4i LCB0aGVuIHllcywgeW91cg0KPiByZWFzb25pbmcgd291bGQgaG9sZCAoImlmIGZpcnN0IFtyb3dd IGltcGxpZXMsIFsuLl0gdGhlbiBzZWNvbmQgcm93IGlzDQo+IGluY29ycmVjdCIpLCBidXQgeW91 ciByZWFzb25pbmcgd291bGQgYWN0dWFsbHkgYmUgb2YgbG93IGludGVyZXN0LA0KPiBiZWNhdXNl IGluIHRoYXQgY2FzZSB0aGUgZmlyc3Qgcm93IHdvdWxkIGJlIGludmFsaWQgdG9vLi4uDQo+IC0g aWYgd2UgY291bnQgYXMgb25lIG0uZSB3aGVuIGEgUEUgcGFyc2VzIGEgSm9pbiBvciBQcnVuZSBm b3Igd2hpY2ggaXQNCj4gaXMgbm90IHRoZSB1cHN0cmVhbSwgZG9lcyBhIGxvb2t1cCBmb3IgdGhl IGNvcnJlc3BvbmRpbmcgKFMsRykgdG8NCj4gZmluYWxseSBkaXNjYXJkIHRoZSBtZXNzYWdlLCB0 aGVuIHRoZSAqdHdvKiByb3dzIGFyZSBib3RoIHZhbGlkDQo+IA0KPiBUaGUgIihzdWNoIGhhcyB1 cGRhdGluZyBhIGNvbnRyb2wgcGxhbmUgb3IgZGF0YSBwbGFuZSBzdGF0ZSkiIHBocmFzZQ0KPiBp cywNCj4gb2J2aW91c2x5LCBhIG5vbi1leGhhdXN0aXZlIGxpc3Qgb2YgZXhhbXBsZXMuIFdoZW4g YXNzZXNzaW5nIHRoZQ0KPiBwcm9jZXNzaW5nIGRvbmUgYnkgUEVzLCB3ZSBoYXZlIHRvIHJlZmxl Y3QgdGhlIHdvcmsgZG9uZSBieSBhIFBFIHRvDQo+IGlkZW50aWZ5IGl0IGNhbiBkaXNjYXJkIGEg bWVzc2FnZSBiZWNhdXNlIGl0IGRvZXMgbm90IGhhdmUgYW55IChTLEcpDQo+IHN0YXRlLCBhZnRl ciBwYXJzaW5nIHRoZSBKb2luIG9yIFBydW5lIGFuZCBkb2luZyBhIGxvb2t1cCBpbiBpdHMgVElC Lg0KPiANCj4gV2UgY2FuIGNlcnRhaW5seSBhZGQgIm9yIGRpc2NhcmQgdGhlIGluZm9ybWF0aW9u IGluIHRoZSBtZXNzYWdlIiBpbiB0aGUNCj4gbGlzdCBvZiBleGFtcGxlcy4NCj4gSSBzZWUgdGhp cyBzZW50ZW5jZSBoYXMgYSB0eXBvICgiaGFzIicgaW5zdGVhZCBvZiAiYXMiKSwgd2hpY2ggcG9z c2libHkNCj4gd2FzIHRoZSBzb3VyY2Ugb2YgY29uZnVzaW9uIDogaXQgd2lsbCBiZSBmaXhlZCB0 b28uDQo+IA0KPiBTbywgdG8gYXZvaWQgcHJvcGFnYXRpbmcgYW55IGNvbmZ1c2lvbiBhbnkgZnVy dGhlciwgd2UgY2FuIHVwZGF0ZSB0aGUNCj4gZG9jdW1lbnQgYXMgZm9sbG93czoNCj4gDQo+ICAg ICBBICJtZXNzYWdlIHByb2Nlc3NlZCIgYmVpbmcgYSBtZXNzYWdlIGJlaW5nIHBhcnNlZCwgYSBs b29rdXAgYmVpbmcNCj4gZG9uZSwgYW5kIHNvbWUgYWN0aW9uIGJlaW5nDQo+ICAgICB0YWtlbiAo c3VjaCBhcywgZm9yIGluc3RhbmNlLCB1cGRhdGluZyBhIGNvbnRyb2wgcGxhbmUgb3IgZGF0YQ0K PiBwbGFuZSBzdGF0ZSBvciBkaXNjYXJkaW5nIHRoZQ0KPiAgICAgaW5mb3JtYXRpb24gaW4gdGhl IG1lc3NhZ2UpLg0KPiANCj4gDQo+ICA+DQo+ICA+IFRoZSB0aGlyZCBhbmQgZmlmdGggY29sdW1u cyBhYm92ZSBhcmUgZXhhbXBsZXMgb2YgY2FzZXMgd2hlcmUgdGhlDQo+IEFwcGVuZGl4DQo+ICA+ IG1pc2xlYWRpbmdseSBtdWx0aXBsaWVzIGJ5ICNtdnBuX1BFLg0KPiAgPg0KPiANCj4gDQo+IEFz IHdlIHNlZSBhYm92ZSwgdGhlICNtVlBOX1BFcyBvcmRlciBvZiBtYWduaXR1ZGUgaXMgZGVmaW5p dGVseSBjb3JyZWN0DQo+IGZvciBlYWNoIFBFIGpvaW5pbmcuDQo+IA0KPiBOb3csIGlmIHdlIGxl dCdzIGxvb2sgYXQgd2hlbiBQRSBsZWF2ZToNCj4gLSBlYWNoIFBFIGxlYXZpbmcgY2F1c2VzIGEg UHJ1bmUgdG8gYmUgc2VudCAoUkZDIDQ2MDEsIHNlY3Rpb24gNC41LjcsDQo+IGVuZCBvZiBwLjcz KQ0KPiAtIFBFcyB0aGF0IGFyZSBqb2luZWQgdG8gKFMsRyksIHBhcnNlIHRoZSBtZXNzYWdlLCB0 cnkgdG8gZmluZCBhbiAoUyxHKQ0KPiBzdGF0ZSBpbiB0aGVpciBUSUIsIGZpbmQgb25lLCBhbmQg dGhlbiBzZXR1cCBhIHNob3J0IHRpbWVyIHRvIHNlbmQgYQ0KPiBQcnVuZSB0byBvdmVycmlkZSB0 aGUgSm9pbg0KPiAtIFBFcyB0aGF0IGFyZSBub3Qgam9pbmVkIHRvIChTLEcpLCBwYXJzZSB0aGUg bWVzc2FnZSwgdHJ5IHRvIGZpbmQgYW4NCj4gKFMsRykgc3RhdGUgaW4gdGhlaXIgVElCLCBmaW5k IG5vbmUsIGFuZCBkZWNpZGUgdGhleSBjYW4gZGlzY2FyZCB0aGUNCj4gaW5mb3JtYXRpb24NCj4g LSB0aGUgdXBzdHJlYW0gUEUgcGFyc2VzIHRoZSBtZXNzYWdlLCBtYXRjaGVzIGl0IHdpdGggaXRz IChTLEcpIHN0YXRlLA0KPiBzZXR1cHMgYSB0aW1lciBhbmQgOg0KPiAgICAtIGluIHRoZSAibGFz dCBQRSBsZWF2aW5nIiBjYXNlLCBhZnRlciBhIGRlbGF5IHN0b3AgZm9yd2FyZGluZw0KPiB0cmFm ZmljDQo+ICAgIC0gZWxzZSwgd2lsbCBub3Qgc3RvcCBmb3J3YXJkaW5nIGJlY2F1c2Ugb2YgdGhl IEpvaW4gc2VudCBieSBhbm90aGVyDQo+IFBFIHRvIG92ZXJyaWRlIHRoZSBQcnVuZQ0KPiANCj4g DQo+IFRoZSAjbVZQTl9QRXMgZmFjdG9yIGhlcmUgYWxzbyBjb3JyZWN0bHkgcmVmbGVjdHMgdGhl IGFtb3VudCBvZiB3b3JrDQo+IGRvbmUgYnkgUEVzLg0KPiANCj4gDQo+ICA+DQo+ICA+IEluIGZh Y3QsIHRoZSBudW1iZXIgb2YgbWVzc2FnZXMgcmVjZWl2ZWQgYnkgYSBnaXZlbiBQRSBkb2VzIG5v dA0KPiBpbmNyZWFzZSBpbiBwcm9wb3J0aW9uIHRvICNtdnBuX1BFLg0KPiAgPg0KPiANCj4gVGhl IGNvbnRlbnQgb2YgQXBwZW5kaXggQSBjZXJ0YWlubHkgZG9lcyBub3QgaW1wbHkgdGhhdCAidGhl IG51bWJlciBvZg0KPiBtZXNzYWdlcw0KPiByZWNlaXZlZCBieSBhIGdpdmVuIFBFIGluY3JlYXNl cyBpbiBwcm9wb3J0aW9uIHRvICNtdnBuX1BFIi4NCj4gDQo+IFRoZSAjbVZQTl9QRSBmYWN0b3Ig aXMgZm9yIHRoZSB0b3RhbCBhY3Jvc3MgYWxsIFBFcywgbm90IGZvciBhIGdpdmVuDQo+IFBFLg0K PiANCj4gKCB0aGlzIGV4YWN0IHNhbWUgY29tbWVudCB3YXMgaW4geW91ciBlbWFpbCBmcm9tIEp1 bmUgMTF0aCwgYW5kIEkNCj4gYWxyZWFkeSByZXBsaWVkIHRvIHlvdSBKdW5lIDE5dGggOiB5b3Ug ZGVsaWJlcmF0ZWx5IGlnbm9yZWQgbXkgcmVwbHksIEkNCj4gZG9uJ3QgdGhpbmsgaXQgaXMgZmFp ciB0byBhZ2FpbiBmdXJ0aGVyIHByb3BhZ2F0ZSBzdWNoIGlycmVsZXZhbnQNCj4gaW1wbGljaXQg Y2xhaW1zIG9uIHdoYXQgdGhlIGRvY3VtZW50IHNheXMuLi4pDQo+IA0KPiANCj4gID4NCj4gID4g VGhpcyBwcm9ibGVtIGluZmVjdHMgdGhlIGVudGlyZSBzZXQgb2YgdGFibGVzIGluIHRoZSBBcHBl bmRpeC4NCj4gID4NCj4gDQo+IFNlZSBhYm92ZSwgeW91ciBwb2ludCBpcyBvbmx5IHJpZ2h0IGlm IHlvdSB0d2VhayB3aGF0ICJwcm9jZXNzaW5nIGENCj4gbWVzc2FnZSIgbWVhbnMgdXAgdG8gdGhl IHBvaW50IG9mIGJlaW5nIGlycmVsZXZhbnQgYW5kIG5vdCBhY2NvdW50aW5nDQo+IGZvciBhbGwg dGhlIHByb2Nlc3NpbmcgZG9uZSBieSBQRXMgb24gYSBMQU4uDQo+IA0KPiBMZXQgbWUgbm93IGhp Z2hsaWdodCB0aGF0IHRoZSBwb2ludHMgYWJvdXQgInBydW5lIG92ZXJyaWRlIiBhbmQgImpvaW4N Cj4gc3VwcHJlc3Npb24iIGluIHlvdXIgcmVjZW50IGVtYWlsIHdoZXJlIGZvcm1pbmcgYSBsYXJn ZSBwYXJ0IG9mIHlvdXINCj4gY29tbWVudHMgZHVyaW5nIHRoZSBMQyBpbiBKdW5lLCBhbmQgd2hl cmUgZnVlbGluZyB5b3VyIGNsYWltcyBvZg0KPiAiaW5jb3JyZWN0bmVzcyIgb2YgdGhlIGFuYWx5 c2lzIChzdWNoIGFzIHRoZSBjbGFpbSB0aGF0IHRoZSAiam9pbg0KPiBzdXBwcmVzc2lvbiIgd2Fz IG5vdCB0YWtlbiBpbnRvIGFjY291bnQpLiAgQnkgbm90IHByb3ZpZGluZyBhIHByZWNpc2UNCj4g cXVvdGUgb2Ygd2hhdCBleGFjdGx5IHdvdWxkIGhhdmUgYmVlbiAiaW5jb3JyZWN0IiB1bnRpbCBs YXN0IHdlZWsgLS0NCj4gZGVzcGl0ZSBtdWx0aXBsZSByZXF1ZXN0cyB0byB5b3UgdG8gcHJvdmlk ZSB0aGVtLCBhbmQgZGVzcGl0ZSB0aGUNCj4gbXVsdGlwbGUgY2xhcmlmaWNhdGlvbnMgSSBwcm92 aWRlZCBvbiB0aGUgZmFjdCB0aGF0ICJqb2luIHN1cHByZXNzaW9uIg0KPiBhbmQgInBydW5lIG92 ZXJyaWRlIiB3aGVyZSByZWxldmFudGx5IGFjY291bnRlZCBmb3IgLS0geW91IGhhdmUNCj4gYXJ0 aWZpY2lhbGx5IGRlbGF5ZWQgdGhlIGNsYXJpZmljYXRpb24gb2YgdGhpcyBpc3N1ZSBmb3Igcm91 Z2hseSBzaXgNCj4gbW9udGhzLg0KPiANCj4gLVRob21hcw0K From thomas.morin@orange-ftgroup.com Thu Dec 17 05:25:06 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 98B4C3A67EA for ; Thu, 17 Dec 2009 05:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] 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 Puqs-EhUi9LO for ; Thu, 17 Dec 2009 05:25:05 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 6FF9A3A68F1 for ; Thu, 17 Dec 2009 05:25:05 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 14:24:47 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 14:24:47 +0100 Message-ID: <4B2A311E.8060002@orange-ftgroup.com> Date: Thu, 17 Dec 2009 14:24:46 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H (ATTLABS)" , L3VPN Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / M.Napierala's comments References: <2F1DE4DFCFF32144B771BD2C246E6A200446CE07@misout7msgusr7e.ugd.att.com> <4B291498.6060105@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C8AE@misout7msgusr7e.ugd.att.com> In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A200451C8AE@misout7msgusr7e.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2009 13:24:47.0205 (UTC) FILETIME=[4DA68150:01CA7F1C] 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, 17 Dec 2009 13:25:06 -0000 Maria, NAPIERALA, MARIA H (ATTLABS): >>> This "problem" of treating not equal actions as equal repeats itself >>> throughout the scaling analysis in the appendix. Such analysis is not >>> >>> only *rough* but misleading, and because of this may lead to wrong >>> conclusions. I believe that unless the appendix A is corrected by >>> removing all not comparable, or even wrong estimations, it should be >>> removed from the draft. >>> >> ...but you only find this suggestion worth enough being brought forward >> >> only six month or so after the WG LC... ;-) >> > The analysis kept changing, so I waited until it is finalized (at least > by the author). I believe that it is more important to make the draft as > accurate as possible than worry about the timing. This is not the usual understanding of "Last-Call", to say the least ! I've got no more comment on this except suggest reading the BCPs describing the IETF process... ( Oh, in fact, let me also add for the sake of precision that it is just totally false to state that "the analysis kept changing", since it had mostly only editorial changes between draft-morin-l3vpn-mvpn-considerations-03, in July 2008, and the time the WG LC was made. The particular part you care about here has been _strictly_ unchanged in the draft since July 2008. ) -Thomas From yakov@juniper.net Thu Dec 17 05:59: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 A502028C12C for ; Thu, 17 Dec 2009 05:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 EflPk8cL5RPn for ; Thu, 17 Dec 2009 05:59:17 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with SMTP id 28A9828C124 for ; Thu, 17 Dec 2009 05:59:16 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSyo5JVpOoSxqQ4C9zidu06E1QvXgQmj0@postini.com; Thu, 17 Dec 2009 05:59:03 PST 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.393.1; Thu, 17 Dec 2009 05:52:38 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 05:52:37 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 05:52:37 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 05:52:37 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBHDqbj62561; Thu, 17 Dec 2009 05:52:37 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912171352.nBHDqbj62561@magenta.juniper.net> To: "NAPIERALA, MARIA H (ATTLABS)" Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / M.Napierala's comments In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A200451C8AE@misout7msgusr7e.ugd.att.com> References: <2F1DE4DFCFF32144B771BD2C246E6A200446CE07@misout7msgusr7e.ugd.att.com> <4B291498.6060105@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C8AE@misout7msgusr7e.ugd.att.com> X-MH-In-Reply-To: "NAPIERALA, MARIA H (ATTLABS)" message dated "Wed, 16 Dec 2009 13:57:59 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <81507.1261057957.1@juniper.net> Date: Thu, 17 Dec 2009 05:52:37 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 17 Dec 2009 13:52:37.0643 (UTC) FILETIME=[314F1DB0:01CA7F20] Cc: Thomas Morin , 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: Thu, 17 Dec 2009 13:59:18 -0000 Maria, Maria> The field experience shows that there are multicast applications used in Maria> enterprise VPNs such that only control messages, but no multicast data, Maria> are sent across MVPN backbone. When BGP-multicast signaling is used, the Maria> Source Active A-D route is originated for every C-(S,G) flow that Maria> registers with C-RP and such that the C-RP joins "S" across MVPN Maria> backbone, even if no inter-site data is sent for this flow. Hence, the Maria> BGP scheme requires not only that for any given C-(S,G) flow that enters Maria> MVPN backbone an SA message is announced and maintained by all PEs in a Maria> given MVPN, but that SA messages are also announced for flows that never Maria> enter the MVPN backbone. By definition the MVPN service is a Layer 3 service, and as such it does not distinguish whether customer's IP multicast packets carry some application specific control information, or whether they are the data traffic of a particular application. Thus from the MVPN service point of view there is no different between a customer multicast flow that carries control traffic of a particular application and a customer multicast flow that carries data traffic of that application. Given the above, if C-RP joins "S" across the MVPN backbone for a particular (C-S, C-G), that means that *contrary to your claim above*, the (C-S, C-G) traffic/flow is going to flow from "S" towards C-RP, and it is going to flow *across the MVPN backbone*. And as I said above, from the MVPN service point of view it is just a multicast flow, irrespective of whether this flow carries some application control information or a data of this application. Thomas> What you state above it true only with one way of using the BGP Thomas> approach to support ASM (the one in section 14 of Thomas> draft-ietf-l3vpn-2547bis-mcast-bgp)? Thomas> Thomas> The other way (section 13) does not have this effect, and happens to Thomas> indirectly be the one recommended by Thomas> draft-ietf-l3vpn-mvpn-considerations (because it is the one of the two Thomas> not requiring an RP function co-located in the PE). Maria> No, what I stated above applies to section 13 (I did not Maria> even considered the implications of section 14..). The Maria> inter-site shared trees are used. When a PE receives Maria> C-multicast Join route (which triggers Source Active A-D Maria> route) it does not necessarily mean that data was actually Maria> sent across MVPN backbone. Incorrect. This is because for a PE to receive a Source Tree Join C-multicast route for (C-S, C-G), it would require the PE that originates this route to first receive PIM Join (C-S, C-G) from one of its CEs, and that, in turn, would first require (C-S, C-G) to be sent across the MVPN backbone. Therefore, this (C-S, C-G) has to be sent across the MVPN backbone prior to the PE receiving the Source Tree Join C-multicast route. Yakov. From yakov@juniper.net Thu Dec 17 06:19:34 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 3E3A33A6AD2 for ; Thu, 17 Dec 2009 06:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 X2sCA1nP7gWt for ; Thu, 17 Dec 2009 06:19:33 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with SMTP id 7E40C3A6892 for ; Thu, 17 Dec 2009 06:19:31 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSyo95C8xxNXBKfRuUKMAI5TOh+BasEbt@postini.com; Thu, 17 Dec 2009 06:19:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Thu, 17 Dec 2009 06:14:44 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 06:14:43 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 06:14:43 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 06:14:43 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBHEEhj72179; Thu, 17 Dec 2009 06:14:43 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912171414.nBHEEhj72179@magenta.juniper.net> To: "NAPIERALA, MARIA H (ATTLABS)" Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / RTConstraint recommendation In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A200451C91C@misout7msgusr7e.ugd.att.com> References: <3126.1259858356@erosen-linux> <4B289CDB.8090404@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C91C@misout7msgusr7e.ugd.att.com> X-MH-In-Reply-To: "NAPIERALA, MARIA H (ATTLABS)" message dated "Wed, 16 Dec 2009 14:52:12 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83439.1261059282.1@juniper.net> Date: Thu, 17 Dec 2009 06:14:42 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 17 Dec 2009 14:14:43.0423 (UTC) FILETIME=[478916F0:01CA7F23] Cc: Eric Rosen , Thomas Morin , 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: Thu, 17 Dec 2009 14:19:34 -0000 Maria, > Does this mean that BGP C-multicast signaling should never be deployed > without RT-Constraint because otherwise it would not work correctly/would > not scale? BGP C-multicast signaling works correctly without RT-Constraint. The scale at which a service provider can start wanting RT constraint is very much dependent on the scale of deployment and performance of the equipments used. Yakov. > Maria > > > -----Original Message----- > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > > Of Thomas Morin > > Sent: Wednesday, December 16, 2009 3:40 AM > > To: L3VPN; Eric Rosen > > Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / > > RTConstraint recommendation > > > > Eric, working group, > > > > Eric Rosen: > > > the case where the RT-Constraint mechanisms [RFC4684] is > > > not used is not covered; > > > > > > Since RT-constraint is not a mandatory to implement mechanism, I > > don't see > > > why this is not covered. > > > > You omitted the first part of the sentence you quoted, which actually > > provides the answer: > > > > following the recommendation of [I-D.ietf-l3vpn-2547bis-mcast- > > bgp] > > the case where the RT-Constraint mechanisms [RFC4684] is not > > used > > is not > > covered; > > > > Here is the corresponding quote in draft-ieft-2547bis-mcast-bgp (which > > you happen co-author) : > > > > 16. Scalability Considerations > > > > A PE should use Route Target Constrain [RT-CONSTRAIN] to advertise > > the Route Targets that the PE uses for the VRF Route Imports > > extended > > community (note that doing this requires just a single Route Target > > Constraint advertisement by the PE). This allows each C-multicast > > route to reach only the relevant PE, rather than all the PEs > > participating the an MVPN. > > > > Hence the considerations document does not cover the case where the > > RT-Constraint mechanism is not used. > > > > -Thomas > > > > PS: Let me note that you did not bring up this up during the LC in > > June, > > and that this comment is not related to any new content in the > > revisions > > made since this LC. > > > > From mn1921@att.com Thu Dec 17 08:14:11 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 AF4BE3A6AD2 for ; Thu, 17 Dec 2009 08:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.37 X-Spam-Level: X-Spam-Status: No, score=-106.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 JTkUxRCK+6o0 for ; Thu, 17 Dec 2009 08:14:04 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 4DB153A681E for ; Thu, 17 Dec 2009 08:14:03 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-13.tower-161.messagelabs.com!1261066427!23032977!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 27887 invoked from network); 17 Dec 2009 16:13:48 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2009 16:13:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBHGDhl2009402; Thu, 17 Dec 2009 11:13:43 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBHGDd4w009364; Thu, 17 Dec 2009 11:13:40 -0500 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: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / RTConstraint recommendation Date: Thu, 17 Dec 2009 11:13:41 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200457FA64@misout7msgusr7e.ugd.att.com> In-Reply-To: <200912171414.nBHEEhj72179@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / RTConstraint recommendation Thread-Index: Acp/I/Hj9qVrredfRCmX6dBuAb8MdgAD7D9Q References: <3126.1259858356@erosen-linux> <4B289CDB.8090404@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C91C@misout7msgusr7e.ugd.att.com> <200912171414.nBHEEhj72179@magenta.juniper.net> From: "NAPIERALA, MARIA H (ATTLABS)" To: "Yakov Rekhter" Cc: Eric Rosen , Thomas Morin , 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: Thu, 17 Dec 2009 16:14:11 -0000 That is what I thought, in which case the consideration draft should consider both BGP C-multicast signaling scenarios: with and without using RT-Constraint. Maria > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Thursday, December 17, 2009 9:15 AM > To: NAPIERALA, MARIA H (ATTLABS) > Cc: Thomas Morin; L3VPN; Eric Rosen > Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / > RTConstraint recommendation >=20 > Maria, >=20 > > Does this mean that BGP C-multicast signaling should never be > deployed > > without RT-Constraint because otherwise it would not work > correctly/would > > not scale? >=20 > BGP C-multicast signaling works correctly without RT-Constraint. >=20 > The scale at which a service provider can start wanting RT constraint > is very much dependent on the scale of deployment and performance > of the equipments used. >=20 > Yakov. >=20 >=20 > > Maria > > > > > -----Original Message----- > > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > Behalf > > > Of Thomas Morin > > > Sent: Wednesday, December 16, 2009 3:40 AM > > > To: L3VPN; Eric Rosen > > > Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / > > > RTConstraint recommendation > > > > > > Eric, working group, > > > > > > Eric Rosen: > > > > the case where the RT-Constraint mechanisms [RFC4684] is > > > > not used is not covered; > > > > > > > > Since RT-constraint is not a mandatory to implement mechanism, I > > > don't see > > > > why this is not covered. > > > > > > You omitted the first part of the sentence you quoted, which > actually > > > provides the answer: > > > > > > following the recommendation of [I-D.ietf-l3vpn-2547bis- > mcast- > > > bgp] > > > the case where the RT-Constraint mechanisms [RFC4684] is not > > > used > > > is not > > > covered; > > > > > > Here is the corresponding quote in draft-ieft-2547bis-mcast-bgp > (which > > > you happen co-author) : > > > > > > 16. Scalability Considerations > > > > > > A PE should use Route Target Constrain [RT-CONSTRAIN] to > advertise > > > the Route Targets that the PE uses for the VRF Route Imports > > > extended > > > community (note that doing this requires just a single Route > Target > > > Constraint advertisement by the PE). This allows each C- > multicast > > > route to reach only the relevant PE, rather than all the PEs > > > participating the an MVPN. > > > > > > Hence the considerations document does not cover the case where the > > > RT-Constraint mechanism is not used. > > > > > > -Thomas > > > > > > PS: Let me note that you did not bring up this up during the LC in > > > June, > > > and that this comment is not related to any new content in the > > > revisions > > > made since this LC. > > > > > > > From John.E.Drake2@boeing.com Thu Dec 17 08:26:17 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 408663A69BC for ; Thu, 17 Dec 2009 08:26:17 -0800 (PST) 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_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRw+dIkImAgY for ; Thu, 17 Dec 2009 08:26:16 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 371A63A69BD for ; Thu, 17 Dec 2009 08:26:16 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nBHGPvvf016665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 08:25:57 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nBHGPve9026882; Thu, 17 Dec 2009 08:25:57 -0800 (PST) Received: from xch-swht-02.sw.nos.boeing.com (xch-swht-02.sw.nos.boeing.com [129.172.142.5]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nBHGPvcZ026878 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 17 Dec 2009 08:25:57 -0800 (PST) Received: from XCH-SW-03V.sw.nos.boeing.com ([129.172.197.23]) by xch-swht-02.sw.nos.boeing.com ([129.172.142.5]) with mapi; Thu, 17 Dec 2009 08:25:57 -0800 From: "Drake, John E" To: "NAPIERALA, MARIA H (ATTLABS)" , Yakov Rekhter Date: Thu, 17 Dec 2009 08:25:55 -0800 Subject: RE: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /RTConstraint recommendation Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /RTConstraint recommendation Thread-Index: Acp/I/Hj9qVrredfRCmX6dBuAb8MdgAD7D9QAAB5yNA= Message-ID: <83C701404B004C4094B604670B3F5FFA395C58AB35@XCH-SW-03V.sw.nos.boeing.com> References: <3126.1259858356@erosen-linux><4B289CDB.8090404@orange-ftgroup.c om><2F1DE4DFCFF32144B771BD2C246E6A200451C91C@misout7msgusr7e.ugd.att.com><200912171414.nBHEEhj72179@magenta.juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A200457FA64@misout7msgusr7e.ugd.att.com> In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A200457FA64@misout7msgusr7e.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Eric Rosen , Thomas Morin , 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: Thu, 17 Dec 2009 16:26:17 -0000 Would it be possible to call the question?=20 > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org]=20 > On Behalf Of NAPIERALA, MARIA H (ATTLABS) > Sent: Thursday, December 17, 2009 8:14 AM > To: Yakov Rekhter > Cc: Eric Rosen; Thomas Morin; L3VPN > Subject: RE: draft-ietf-l3vpn-mvpn-considerations-05 /=20 > Appendix A /RTConstraint recommendation=20 >=20 > That is what I thought, in which case the consideration draft=20 > should consider both BGP C-multicast signaling scenarios:=20 > with and without using RT-Constraint. >=20 > Maria >=20 > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Thursday, December 17, 2009 9:15 AM > > To: NAPIERALA, MARIA H (ATTLABS) > > Cc: Thomas Morin; L3VPN; Eric Rosen > > Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /=20 > > RTConstraint recommendation > >=20 > > Maria, > >=20 > > > Does this mean that BGP C-multicast signaling should never be > > deployed > > > without RT-Constraint because otherwise it would not work > > correctly/would > > > not scale? > >=20 > > BGP C-multicast signaling works correctly without RT-Constraint. > >=20 > > The scale at which a service provider can start wanting RT=20 > constraint=20 > > is very much dependent on the scale of deployment and=20 > performance of=20 > > the equipments used. > >=20 > > Yakov. > >=20 > >=20 > > > Maria > > > > > > > -----Original Message----- > > > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On > > Behalf > > > > Of Thomas Morin > > > > Sent: Wednesday, December 16, 2009 3:40 AM > > > > To: L3VPN; Eric Rosen > > > > Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 /=20 > Appendix A > / > > > > RTConstraint recommendation > > > > > > > > Eric, working group, > > > > > > > > Eric Rosen: > > > > > the case where the RT-Constraint mechanisms=20 > [RFC4684] is > > > > > not used is not covered; > > > > > > > > > > Since RT-constraint is not a mandatory to implement=20 > mechanism, > I > > > > don't see > > > > > why this is not covered. > > > > > > > > You omitted the first part of the sentence you quoted, which > > actually > > > > provides the answer: > > > > > > > > following the recommendation of [I-D.ietf-l3vpn-2547bis- > > mcast- > > > > bgp] > > > > the case where the RT-Constraint mechanisms [RFC4684] is > not > > > > used > > > > is not > > > > covered; > > > > > > > > Here is the corresponding quote in draft-ieft-2547bis-mcast-bgp > > (which > > > > you happen co-author) : > > > > > > > > 16. Scalability Considerations > > > > > > > > A PE should use Route Target Constrain [RT-CONSTRAIN] to > > advertise > > > > the Route Targets that the PE uses for the VRF=20 > Route Imports=20 > > > > extended > > > > community (note that doing this requires just a single Route > > Target > > > > Constraint advertisement by the PE). This allows each C- > > multicast > > > > route to reach only the relevant PE, rather than all the PEs > > > > participating the an MVPN. > > > > > > > > Hence the considerations document does not cover the case where > the > > > > RT-Constraint mechanism is not used. > > > > > > > > -Thomas > > > > > > > > PS: Let me note that you did not bring up this up=20 > during the LC in=20 > > > > June, and that this comment is not related to any new=20 > content in=20 > > > > the revisions made since this LC. > > > > > > > > > > > = From thomas.morin@orange-ftgroup.com Thu Dec 17 09:56:58 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4C83A67DB for ; Thu, 17 Dec 2009 09:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_51=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 GogkygiFzxEc for ; Thu, 17 Dec 2009 09:56:57 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 9969E3A68EA for ; Thu, 17 Dec 2009 09:56:56 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 18:56:38 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 18:56:37 +0100 Message-ID: <4B2A70D5.1030608@orange-ftgroup.com> Date: Thu, 17 Dec 2009 18:56:37 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: "NAPIERALA, MARIA H (ATTLABS)" , L3VPN Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / M.Napierala's comments References: <2F1DE4DFCFF32144B771BD2C246E6A200446CE07@misout7msgusr7e.ugd.att.com> <4B291498.6060105@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C8AE@misout7msgusr7e.ugd.att.com> In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A200451C8AE@misout7msgusr7e.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2009 17:56:37.0821 (UTC) FILETIME=[4788FED0:01CA7F42] 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, 17 Dec 2009 17:56:58 -0000 Maria, working group, Maria: > > > If the solution to this is to make the timer for sending > > > > Prune(S,G,rpt) sufficiently high (to assure that SPT is created) and avoid > > > > duplicates sent to customers by having egress PEs discard data packets received > > > from the "wrong" upstream PE, this should be included in MVPN > > > considerations draft. > > > > > > > I personnally agree with you it would be reasonable that the draft > > recommends implementing these procedures ( > > http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-09#section- > > 9.1.1 ) > > > Good Ok. We can propose this to the working group, supposing noone disagrees despite this coming far after WG LC. >>> 2. The considerations draft should also point out the difference how BGP >>> >>> vs. PIM (used as PE-PE signaling protocol) handles the upstream PE >>> selection in case of multi-homed sources/RPs. >>> >>> Typically, in a layer 3 VPN deployment it is not known whether or >>> not >>> >>> all VRFs of a given VPN have the same best route to a given source. In >>> other words, VRFs routing policies are provisioned independently of each >>> >>> other. If all VRFs of a given MVPN have the same best/ installed route >>> >>> to a multi-homed source/RP then this VPN customer *expects* that the >>> source/RP will be joined via the installed route. >>> >>> When PIM is used as PE-PE C-signaling, the installed route towards the >>> >>> source is always chosen as UHM. >>> >> This is not my understanding, to quote >> draft-ietf-l3vpn-2547bis-mcast-09, section-5.1.3: >> >> The default procedure, which MUST be implemented, is to select the >> route whose corresponding upstream PE address is numerically highest, >> where a 32-bit IP address is treated as a 32 bit unsigned integer. >> Call this the "default upstream PE selection". >> >> [...] >> >> Another procedure, which SHOULD be implemented, is to use the >> Installed UMH Route as the Selected UMH Route. >> >> >> >>> If different VRFs have different best >>> routes to C-S or C-RP, the Assert process is a tie breaker. No steady >>> >>> state duplicate traffic is sent across MVPN backbone. >>> >>> Now let's consider BGP as the PE-PE signaling protocol and let's assume >>> >>> the UMH policy is to choose the installed/best route towards C-source or >>> >>> C-RP. >>> >> Given the above, why is this assumption relevant ? >> >> >>> If different VRFs have different installed routes to C-S/C-RP then >>> there will be a steady state duplication of traffic across the MVPN >>> backbone (to the same set of PEs if MI-PMSI is used). This also requires >>> >>> that the egress PEs be able to discard data traffic that arrives from >>> >>> the "wrong" upstream PE. Such duplication of traffic might not be >>> operationally acceptable to a service provider because of too much >>> network bandwidth being consumed. >>> >> I don't think this is a relevant drawback : >> - if a provider chooses the non-default UMH selection you mention, it >> is likely that he is fine with the bandwidth aspect, and has made sure >> the vendors implement the procedures to discard data traffic that >> arrives from the "wrong" upstream PE. >> > Why not to state it? At this point in the process the question is "why state it ?" rather than "why not" (supposing we have a question to ask) > This does not come for free and requires "strong" RPF check i.e., checking the upstream PE. Are you aware of any such implementations? (ask your vendors) >> - see above for the suggestion to recommend implementing the procedures >> >> required to discard data traffic that arrives from the "wrong" upstream >> >> PE (making it easier for the provider to make sure that it is ok for >> him to use the non-default UMH selection you mention ). >> Isn't it sufficient ? >>> 5. Why Appendix A analyzes PIM LAN procedure with explicit tracking but >>> >>> not the explicit tracking using BGP-signaling? >>> >>> >> I'm not sure as what you call "explicit tracking using BGP-signaling". >> >> There is, AFAIK, no such thing as "explicit tracking" in the BGP >> procedures for C-multicast routing, and Appendix A is only about >> C-multicast routing options. >> > Well, in that case, PIM LAN procedure with explicit tracking should be > removed also. Why would you do explicit tracking of receivers when using > PIM? Well, see my reply to Eric Rosen "draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / PIM with explicit tracking": - there is perfect rationale to cover it (part of RFC4601 => part of the PIM-based C-multicast routing options) - at the same time, if there is consensus that it is not useful I don't mind removing it -Thomas From mn1921@att.com Thu Dec 17 11:59:23 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 AD79D3A69F8 for ; Thu, 17 Dec 2009 11:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.395 X-Spam-Level: X-Spam-Status: No, score=-106.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 SKYjyEtVJnIp for ; Thu, 17 Dec 2009 11:59:23 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id F057F3A690E for ; Thu, 17 Dec 2009 11:59:22 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-7.tower-167.messagelabs.com!1261079946!21680510!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 12364 invoked from network); 17 Dec 2009 19:59:07 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2009 19:59:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBHJx2wP000424; Thu, 17 Dec 2009 14:59:03 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBHJx0iD000403; Thu, 17 Dec 2009 14:59:00 -0500 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: draft-ietf-l3vpn-mvpn-considerations-05 / M.Napierala's comments Date: Thu, 17 Dec 2009 14:59:02 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200457FC84@misout7msgusr7e.ugd.att.com> In-Reply-To: <200912171352.nBHDqbj62561@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 / M.Napierala's comments Thread-Index: Acp/IRx9BW0jxCgwS9S+gYWYLTB70QAMjAiw References: <2F1DE4DFCFF32144B771BD2C246E6A200446CE07@misout7msgusr7e.ugd.att.com> <4B291498.6060105@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C8AE@misout7msgusr7e.ugd.att.com> <200912171352.nBHDqbj62561@magenta.juniper.net> From: "NAPIERALA, MARIA H (ATTLABS)" To: "Yakov Rekhter" Cc: Thomas Morin , 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: Thu, 17 Dec 2009 19:59:23 -0000 Yakov, > Given the above, if C-RP joins "S" across the MVPN backbone for a > particular (C-S, C-G), that means that *contrary to your claim above*, > the (C-S, C-G) traffic/flow is going to flow from "S" towards C-RP, > and it is going to flow *across the MVPN backbone*. And as I said Actually, the multicast traffic does not necessarily flow across the MVPN backbone. Customers use techniques (like multicast ttl-threshold) to keep multicast data traffic local to a site. We see this happening frequently.=20 > above, from the MVPN service point of view it is just a multicast > flow, irrespective of whether this flow carries some application > control information or a data of this application.=20 This is not what I meant, i.e., that the flow itself carries some "control" information. I meant that the traffic does no flow at all, as I explained above. =20 Maria From thomas.morin@orange-ftgroup.com Fri Dec 18 07:02: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 588AE3A6A89 for ; Fri, 18 Dec 2009 07:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=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 FrVh-aFL0rH2 for ; Fri, 18 Dec 2009 07:02:35 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id D156D3A67FB for ; Fri, 18 Dec 2009 07:02:34 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 16:02:19 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 16:02:18 +0100 Message-ID: <4B2B9979.4070708@orange-ftgroup.com> Date: Fri, 18 Dec 2009 16:02:17 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: L3VPN , Eric Rosen Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / looking at multiple (S,G) References: <3126.1259858356@erosen-linux> In-Reply-To: <3126.1259858356@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2009 15:02:18.0072 (UTC) FILETIME=[1773B580:01CA7FF3] 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, 18 Dec 2009 15:02:36 -0000 Eric, working group, In different parts of the document (quoted below) you claim that the scaling analysis should consider scalability with an increased number of sources sending to a group. Before looking at the relevance question, let's see how it relates to the current state of the document. Section 3.3 of the document relates to scalability with an increased number of PEs, and refers to the scaling analysis in Appendix A.1 "Scalability with an increased number of PEs". Given this, claiming that not doing a scaling analysis with an increased number of (S,G) is "a methodological error" in this scaling analysis is not correct. That "scaling with an increased number of (S,G)" should be studied is something that noone has proposed to do yet, as far as I can tell. Now, that said, let's try to see how interesting it would be to consider looking more at this aspect: - in your comments, you insist on the linear dependency of BGP C-multicast routing with the number of (S,G), but scaling linearly with the number of sources sending to a group is not a peculiarity of the BGP Source Active auto-discovery mechanism, but is also common for PIM-SM SPTs and SSM trees (whether they are carried across the provider core through PIM and BGP, by the way) - "the number of sources sending to a group", or the number of SPTs or SSM trees, is not something typically under the control of the provider, as it completely depends on the multicast routing policy and subscriptions patterns of each MVPN customer; so it should be obvious to anyone that the provider will have to prepare its network to scale with these unknowns in mind and put bounds to the amount of per-source state on his PEs (and RRs) ; this is true independently of whether PIM-SM or BGP is used for C-multicast routing (and true whether or not MSDP is used in that deployment) - note also also that "scaling with reference to the number of sources" is trivially extrapolated from the single (S,G) case - as far as RR are concerned (a point on which you focus below): having an amount of state to maintain on RRs that scales linearly with the scale of deployments and customer routes is not unusual, especially when it offers scaling advantages Given the above, I don't think it is obvious that looking at scalability with the number of sources sending to a group, will be helpful for a provider to choose the protocol he will use for PE-PE C-multicast routing. Speaking for myself as a contributor, these elements explain why I did not contribute a scaling study for an increased number of sources. "//Your mileage may vary", but we are six month after WG LC.... -Thomas PS: a few more comments below Eric Rosen: > Another methodological error is that only the messaging needed to join a > single (S,G) flow is considered. Thus the analysis ignores any scaling > issues that show up as the number of (S,G) flows increases. Since the > number of (S,G) flows handled by a Route Reflector will far exceed the > number handled by any PE router, (This is not exact, as a said PE could use different RRs for different VPNs.) > failure to consider this particular scaling > factor tends to bias the results in favor of a scheme that uses Route > Reflectors. [...] I disagree: as said, above, PIM approaches are subject to the same type of linear dependency with the number of (S,G). [...] > Let's take a look now at some of the more detailed issues. > > [...] let's look specifically at the ASM case. > > One of the features of the BGP solution is that there is no way, in BGP, > to represent the PIM operation of "prune source S off the (*,G) tree". > To compensate for this, every PE in a given VPN is forced to keep track of > every (S,G) stream for which any PE in that VPN has receivers. This is done > by means of the Source Active A-D routes. > > > There are two options that can be used. In one option, where "inter-site > shared trees are not used", each PE functions as a C-RP, and then all the PE > of a given VPN must exchange information on all the (S,G) streams that they > see locally. This option uses BGP to do something that is very similar to > what MSDP is used for today. Let me quote from Pekka Savola's review of > this procedure: > > Active source BGP messages. This is a duplication of a > similar mechanism in MSDP (RFC3618) which has caused > much grief in Internet. Does this meant that when a > host does 'nmap -sU 224.0.0.0/4' at a VPN site, this > will result in about 268 million BGP active source > updates being sent (228) in the SP backbone? > > The only answer to this was to beef up the Security Considerations with > some required procedures that will prevent the PE from melting down entirely > in this case. Of course, Appendix A's methodology of only considering a > single (S,G) prevents it from seeing that this particular BGP option > uses a mechanism whose scalability is already known to be poo,r and which > the multicast WGs have decided not even to bring forward to IPv6.[...] > Your are generalizing Pekka's comment on a *security* issue MSDP *in the Internet*, to the issue of *scaling* in a multicast VPN context. I think this is an abusive generalization of his quote, and that it does not help much seeing why draft-ietf-l3vpn-mvpn-considerations should look at scaling with reference to the number of sources. Nobody objects that security issues related to the amount of "per source" state is a legitimate concern, but that does not mechanically make it an interesting scalability question in our context. Second, let me note that you replied yourself to Pekka Savola to his comment, by referring to security mechanisms common to PIM and BGP, that allows to control the amount of multicast state in PEs. > In the other, more sensible option, a PE originates a Source Active A-D > route for an (S,G) only when it receives a C-multicast Join route for that > (S,G). However, the Source Active A-D route goes to all the PEs in the VPN, > not just to those that have receivers for that (S,G). I believe this means > that the amount of state a given PE maintains in the BGP scheme is > proportional to the number of (S,G) flows for which any PE in the VPN has > receivers. Actually, since the SA route contains the RD of the originating > PE, the situation is a bit worse; if (S,G) traffic is sent over the backbone > by more than one PE, the other PEs in the same VPN must maintain an (S,G) SA > A-D route for each such PE. > > In the BGP solution, even if a PE has only (*,G) receivers, or even if it > has no receivers for G at all, it must maintain state for all the (S,G)s in > the MVPN, multiplied by the average number of upstream PEs per source. > [...] > Strangely, this scaling issue is considered to be insignificant by Appendix > A [...] (See start of this email) From thomas.morin@orange-ftgroup.com Fri Dec 18 12:50:31 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 133A83A6ABC for ; Fri, 18 Dec 2009 12:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 0ZQhqUSDCDuL for ; Fri, 18 Dec 2009 12:50:30 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id DD6CB3A69BF for ; Fri, 18 Dec 2009 12:50:29 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 21:49:58 +0100 Received: from [10.193.116.45] ([10.193.116.45]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 21:49:57 +0100 Message-ID: <4B2BEAF5.4020609@orange-ftgroup.com> Date: Fri, 18 Dec 2009 21:49:57 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: Maria Napierala , L3VPN Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2009 20:49:57.0954 (UTC) FILETIME=[A8E91A20:01CA8023] 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, 18 Dec 2009 20:50:31 -0000 Maria, NAPIERALA, MARIA H (ATTLABS): >> - ORIGINATOR_ID : updates of the value of this attributes do not >> "follow" PE advertisements, as the RR rewrite it when aggregating C- >> multicast routes having same NLRI; the advertisements made by different >> RRs may lead possibly to updates of the value of this attribute, given >> that each RR would set ORIGINATOR_ID to a value of its own >> > > Regarding route *aggregation* the draft-ietf-l3vpn-2547bis-mcast-bgp-08 only states the following: > > "To further reduce the routing churn due to C-multicast routes changes > a Route Reflector that re-advertises a C-multicast route SHOULD set > the Next Hop field of the MP_REACH_NLRI attribute of the route to an > IP address of the Route Reflector. Likewise, an ASBR that re- > advertises a C-multicast route SHOULD set the Next Hop field of the > MP_REACH_NLRI attribute of the route to an IP address of the ASBR." > > It states nothing about setting ORIGINATOR_ID to self on RR. It also says: [...] C-multicast routes for a given (S,G) of a given MVPN originated by PEs that are clients of a given Route Reflector are aggregated by the Route Reflector. [...] A BGP aggregated route is a route originated by the BGP peer doing the aggregation, why would it carry another ORIGINATOR_ID than the one of the BGP peer doing the aggregation (here the RR) ? -Thomas From thomas.morin@orange-ftgroup.com Fri Dec 18 13:02:46 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 F2D883A6ACC for ; Fri, 18 Dec 2009 13:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.136, 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 cPEzP7FxWtXi for ; Fri, 18 Dec 2009 13:02:44 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id DE0283A6AC3 for ; Fri, 18 Dec 2009 13:02:42 -0800 (PST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 22:02:24 +0100 Received: from [10.193.116.45] ([10.193.116.45]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 22:02:24 +0100 Message-ID: <4B2BEDDF.3090308@orange-ftgroup.com> Date: Fri, 18 Dec 2009 22:02:23 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1pre Thunderbird/3.0 MIME-Version: 1.0 To: Robert Raszuk , L3VPN Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B296D1C.6000001@cisco.com> In-Reply-To: <4B296D1C.6000001@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2009 21:02:24.0183 (UTC) FILETIME=[65B29C70:01CA8025] 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, 18 Dec 2009 21:02:46 -0000 Hello Robert, Robert Raszuk: > > It seems that for this mvpn solution to work classic "bgp route > reflectors" would not do the right job. You challenge the fact that BGP MVPN would not work with "classic" bgp route reflectors: why do it after the specs are long gone out of the working group ? how does it relate to the current discussion ? (supposing it is even relevant to claim that, and pending some definition of "classic"...) > They should be replaced with "multicast control aggregation" devices > which would have to support it's own set of requirements and it's own > advertisement rules. (Your claim is vague enough to not be even refutable, but:) What is true is that the aggregation done by RR for mVPN following section 11.4 of draft-ietf-l3vpn-2547bis-mcast-bgp relies on mechanisms already defined in other specs. > In fact draft already recommends to use such devices as a standalone > control plane boxes. What in fact is written in the draft is this: In the higher scale scenarios, it may be required to adapt the route reflector infrastructure to the MVPN routing load by using, for example: o a separation of resources for unicast and multicast VPN routing: using dedicated MVPN Route Reflector(s) (or using dedicated MVPN BGP sessions or dedicated MVPN BGP instances) ; o the deployment of additional route reflector resources, for example increasing the processing resources on existing route reflectors or deployment of additional route reflectors. Among the above, the most straightforward approach is to consider the introduction of route reflectors dedicated to the MVPN service and dimension them accordingly to the need of that service (but doing so is not required and is left as an operator engineering decision). So : - this text refers to the use of RRs following draft-ietf-l3vpn-2547bis-mcast-bgp, but *not* to anything like "multicast control aggregation devices" which, as you say, would "have to support it's own set of requirements and it's own advertisement rules" - the reasons for suggesting the use of RRs or dedicated RRs are purely *quantitative* (scale) and *not qualitative* as you suggest. Cheers, -Thomas >> Thomas, >> >> regarding my question: "In section A.1.1.3, why the 'each additional >> PE joining' row for the 'upstream PE' column shows "0"?", you pointed >> me to this e-mail. >> Please see my replies in-line. >> >> Maria >> >> >>> Now, to go back on the computation in section A.1.1.3 on BGP, you are >>> correct that the current text does not yet properly reflects the cases >>> where an RR may re-advertises a route they were already advertising. >>> Let's look practically at the attributes that could vary : >>> >>> - next-hop : updates of the value of this attribute do not "follow" >>> PE advertisements, being rewritten by the RR when aggregating >>> C-multicast routes having same NLRI (section 11.4 of >>> draft-ietf-l3vpn-2547bis-mcast-bgp) ; the advertisements made by >>> different RRs may lead to updates of the value of this attribute >> >> This does not help in route aggregation because RR applies the >> ORIGINATOR_ID to each client's/egress PE route. >> >>> - ORIGINATOR_ID : updates of the value of this attributes do not >>> "follow" PE advertisements, as the RR rewrite it when aggregating C- >>> multicast routes having same NLRI; the advertisements made by different >>> RRs may lead possibly to updates of the value of this attribute, given >>> that each RR would set ORIGINATOR_ID to a value of its own >>> >> >> Regarding route *aggregation* the >> draft-ietf-l3vpn-2547bis-mcast-bgp-08 only states the following: >> >> "To further reduce the routing churn due to C-multicast routes >> changes >> a Route Reflector that re-advertises a C-multicast route SHOULD set >> the Next Hop field of the MP_REACH_NLRI attribute of the route to an >> IP address of the Route Reflector. Likewise, an ASBR that re- >> advertises a C-multicast route SHOULD set the Next Hop field of the >> MP_REACH_NLRI attribute of the route to an IP address of the ASBR." >> >> It states nothing about setting ORIGINATOR_ID to self on RR. >> Maria > From raszuk@cisco.com Fri Dec 18 13:12: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 4E04C3A67F8 for ; Fri, 18 Dec 2009 13:12:36 -0800 (PST) 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 SWEYhEyy4XmZ for ; Fri, 18 Dec 2009 13:12:35 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3483C3A6AB7 for ; Fri, 18 Dec 2009 13:12:24 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsFALJ+K0urRN+K/2dsb2JhbACECpR/pWuBHAgBhVuQHYEvgi1SBA X-IronPort-AV: E=Sophos;i="4.47,420,1257120000"; d="scan'208";a="122191844" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 18 Dec 2009 21:12:09 +0000 Received: from [192.168.1.57] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBILC8UQ006431; Fri, 18 Dec 2009 21:12:08 GMT Message-ID: <4B2BF022.8020505@cisco.com> Date: Fri, 18 Dec 2009 22:12:02 +0100 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Morin Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B2BEAF5.4020609@orange-ftgroup.com> In-Reply-To: <4B2BEAF5.4020609@orange-ftgroup.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 21:12:36 -0000 Hi Thomas, > [...] C-multicast routes for a given (S,G) of a given MVPN > originated by PEs that are clients of > a given Route Reflector are aggregated by the Route Reflector. [...] > > A BGP aggregated route is a route originated by the BGP peer doing the > aggregation, why would it carry another ORIGINATOR_ID than the one of > the BGP peer doing the aggregation (here the RR) ? Because RR behavior is very well already defined in RFC 4456 which says: ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type code 9. This attribute is 4 bytes long and it will be created by an RR in reflecting a route. This attribute will carry the BGP Identifier of the originator of the route in the local AS. Here RR is doing _aggregation_ and not _origination_ of the route. Sorry but this is not the same. C-multicast routes are originated by the PEs and to be compliant to RFC 4456 each time best path shifts from one PE to the other the RR should reflect it to all of it's clients with new corresponding to the new best path ORIGINATOR_ID. Cheers, R. From raszuk@cisco.com Fri Dec 18 13:19:55 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 088973A67A8 for ; Fri, 18 Dec 2009 13:19:55 -0800 (PST) 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 pU5G11CLsNBA for ; Fri, 18 Dec 2009 13:19:53 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B78AC3A68C2 for ; Fri, 18 Dec 2009 13:19:52 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsFAAuBK0urRN+J/2dsb2JhbACECpR/pXaBHAgBhVuQIYEvgi1SBA X-IronPort-AV: E=Sophos;i="4.47,420,1257120000"; d="scan'208";a="122193926" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 18 Dec 2009 21:19:38 +0000 Received: from [192.168.1.57] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBILJaAA007484; Fri, 18 Dec 2009 21:19:37 GMT Message-ID: <4B2BF1E2.3070102@cisco.com> Date: Fri, 18 Dec 2009 22:19:30 +0100 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Morin Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B296D1C.6000001@cisco.com> <4B2BEDDF.3090308@orange-ftgroup.com> In-Reply-To: <4B2BEDDF.3090308@orange-ftgroup.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 21:19:55 -0000 Thomas, My comments were concerning scaling the solution to be able to support real network's demands. Not some theoretical ones. And the proposed solution of using RRs as aggregators of c-multicast routes is not what RR RFC 4456 specifies for reflection rules. Cheers, R. > Hello Robert, > > Robert Raszuk: > > >> It seems that for this mvpn solution to work classic "bgp route >> reflectors" would not do the right job. > > You challenge the fact that BGP MVPN would not work with "classic" bgp > route reflectors: why do it after the specs are long gone out of the > working group ? how does it relate to the current discussion ? > > (supposing it is even relevant to claim that, and pending some > definition of "classic"...) > > >> They should be replaced with "multicast control aggregation" devices >> which would have to support it's own set of requirements and it's own >> advertisement rules. > > > (Your claim is vague enough to not be even refutable, but:) > What is true is that the aggregation done by RR for mVPN following > section 11.4 of draft-ietf-l3vpn-2547bis-mcast-bgp relies on mechanisms > already defined in other specs. > > >> In fact draft already recommends to use such devices as a standalone >> control plane boxes. > > > What in fact is written in the draft is this: > > In the higher scale scenarios, it may be > required to adapt the route reflector infrastructure to the MVPN > routing load by using, for example: > > o a separation of resources for unicast and multicast VPN routing: > using dedicated MVPN Route Reflector(s) (or using dedicated MVPN > BGP sessions or dedicated MVPN BGP instances) ; > > o the deployment of additional route reflector resources, for > example increasing the processing resources on existing route > reflectors or deployment of additional route reflectors. > > Among the above, the most straightforward approach is to consider the > introduction of route reflectors dedicated to the MVPN service and > dimension them accordingly to the need of that service (but doing so > is not required and is left as an operator engineering decision). > > > So : > - this text refers to the use of RRs following > draft-ietf-l3vpn-2547bis-mcast-bgp, but *not* to anything like > "multicast control aggregation devices" which, as you say, would "have > to support it's own set of requirements and it's own advertisement rules" > - the reasons for suggesting the use of RRs or dedicated RRs are purely > *quantitative* (scale) and *not qualitative* as you suggest. > > Cheers, > > -Thomas > > > > >>> Thomas, >>> >>> regarding my question: "In section A.1.1.3, why the 'each additional >>> PE joining' row for the 'upstream PE' column shows "0"?", you pointed >>> me to this e-mail. >>> Please see my replies in-line. >>> >>> Maria >>> >>> >>>> Now, to go back on the computation in section A.1.1.3 on BGP, you are >>>> correct that the current text does not yet properly reflects the cases >>>> where an RR may re-advertises a route they were already advertising. >>>> Let's look practically at the attributes that could vary : >>>> >>>> - next-hop : updates of the value of this attribute do not "follow" >>>> PE advertisements, being rewritten by the RR when aggregating >>>> C-multicast routes having same NLRI (section 11.4 of >>>> draft-ietf-l3vpn-2547bis-mcast-bgp) ; the advertisements made by >>>> different RRs may lead to updates of the value of this attribute >>> >>> This does not help in route aggregation because RR applies the >>> ORIGINATOR_ID to each client's/egress PE route. >>> >>>> - ORIGINATOR_ID : updates of the value of this attributes do not >>>> "follow" PE advertisements, as the RR rewrite it when aggregating C- >>>> multicast routes having same NLRI; the advertisements made by different >>>> RRs may lead possibly to updates of the value of this attribute, given >>>> that each RR would set ORIGINATOR_ID to a value of its own >>>> >>> >>> Regarding route *aggregation* the >>> draft-ietf-l3vpn-2547bis-mcast-bgp-08 only states the following: >>> >>> "To further reduce the routing churn due to C-multicast routes >>> changes >>> a Route Reflector that re-advertises a C-multicast route SHOULD set >>> the Next Hop field of the MP_REACH_NLRI attribute of the route to an >>> IP address of the Route Reflector. Likewise, an ASBR that re- >>> advertises a C-multicast route SHOULD set the Next Hop field of the >>> MP_REACH_NLRI attribute of the route to an IP address of the ASBR." >>> >>> It states nothing about setting ORIGINATOR_ID to self on RR. >>> Maria >> > From yakov@juniper.net Mon Dec 21 06:17:10 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9423E3A6A0B for ; Mon, 21 Dec 2009 06:17:10 -0800 (PST) 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 XQACSMzsWrcC for ; Mon, 21 Dec 2009 06:17:09 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with SMTP id 37E4B3A67D9 for ; Mon, 21 Dec 2009 06:17:08 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSy+DUpxkqLzTIcFAlPM0OHJC2124g6PD@postini.com; Mon, 21 Dec 2009 06:16:53 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Mon, 21 Dec 2009 06:13:24 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 06:13:24 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 06:13:24 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 06:13:24 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBLEDNj02373; Mon, 21 Dec 2009 06:13:23 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912211413.nBLEDNj02373@magenta.juniper.net> To: Thomas Morin Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / looking at multiple (S, G) In-Reply-To: <4B2B9979.4070708@orange-ftgroup.com> References: <3126.1259858356@erosen-linux> <4B2B9979.4070708@orange-ftgroup.com> X-MH-In-Reply-To: Thomas Morin message dated "Fri, 18 Dec 2009 16:02:17 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <47821.1261404803.1@juniper.net> Date: Mon, 21 Dec 2009 06:13:23 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 21 Dec 2009 14:13:24.0067 (UTC) FILETIME=[C1E35330:01CA8247] Cc: Eric Rosen , 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: Mon, 21 Dec 2009 14:17:10 -0000 Thomas, > Eric, working group, > > In different parts of the document (quoted below) you claim that the > scaling analysis should consider scalability with an increased number of > sources sending to a group. > > Before looking at the relevance question, let's see how it relates to > the current state of the document. > Section 3.3 of the document relates to scalability with an increased > number of PEs, and refers to the scaling analysis in Appendix A.1 > "Scalability with an increased number of PEs". Given this, claiming that > not doing a scaling analysis with an increased number of (S,G) is "a > methodological error" in this scaling analysis is not correct. > > That "scaling with an increased number of (S,G)" should be studied is > something that noone has proposed to do yet, as far as I can tell. > > Now, that said, let's try to see how interesting it would be to consider > looking more at this aspect: > - in your comments, you insist on the linear dependency of BGP > C-multicast routing with the number of (S,G), but scaling linearly with > the number of sources sending to a group is not a peculiarity of the BGP > Source Active auto-discovery mechanism, but is also common for PIM-SM > SPTs and SSM trees (whether they are carried across the provider core > through PIM and BGP, by the way) > - "the number of sources sending to a group", or the number of SPTs or > SSM trees, is not something typically under the control of the provider, > as it completely depends on the multicast routing policy and > subscriptions patterns of each MVPN customer; so it should be obvious to > anyone that the provider will have to prepare its network to scale with > these unknowns in mind and put bounds to the amount of per-source state > on his PEs (and RRs) ; this is true independently of whether PIM-SM or > BGP is used for C-multicast routing (and true whether or not MSDP is > used in that deployment) Just to add to the point above, the following from Security Considerations section of draft-ietf-l3vpn-2547bis-mcast-09.txt: In particular, an implementation SHOULD provide mechanisms that allow a SP to place limitations on the following: - total number of (C-*,C-G) and/or (C-S,C-G) states per VRF And as you mentioned above, "this is true independently of whether PIM-SM or BGP is used for C-multicast routing (and true whether or not MSDP is used in that deployment)" Yakov. From yakov@juniper.net Mon Dec 21 06:20: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 BACDA3A6A0F for ; Mon, 21 Dec 2009 06:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 uVz14whfGhps for ; Mon, 21 Dec 2009 06:20:46 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with SMTP id 78D1B3A6A0E for ; Mon, 21 Dec 2009 06:20:45 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSy+EJ5o+ImSV499taXKkWj5SUlvrNCvX@postini.com; Mon, 21 Dec 2009 06:20:31 PST 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.393.1; Mon, 21 Dec 2009 06:16:26 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 06:16:26 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 06:16:25 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 06:16:25 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBLEGPj03527; Mon, 21 Dec 2009 06:16:25 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912211416.nBLEGPj03527@magenta.juniper.net> To: raszuk@cisco.com Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 In-Reply-To: <4B2BF022.8020505@cisco.com> References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B2BEAF5.4020609@orange-ftgroup.com> <4B2BF022.8020505@cisco.com> X-MH-In-Reply-To: Robert Raszuk message dated "Fri, 18 Dec 2009 22:12:02 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48208.1261404985.1@juniper.net> Date: Mon, 21 Dec 2009 06:16:25 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 21 Dec 2009 14:16:25.0270 (UTC) FILETIME=[2DE4B560:01CA8248] Cc: Thomas Morin , 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: Mon, 21 Dec 2009 14:20:47 -0000 Robert, > Hi Thomas, > > > [...] C-multicast routes for a given (S,G) of a given MVPN > > originated by PEs that are clients of > > a given Route Reflector are aggregated by the Route Reflector. [...] > > > > A BGP aggregated route is a route originated by the BGP peer doing the > > aggregation, why would it carry another ORIGINATOR_ID than the one of > > the BGP peer doing the aggregation (here the RR) ? > > Because RR behavior is very well already defined in RFC 4456 which says: > > ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type > code 9. This attribute is 4 bytes long and it will be created by an > RR in reflecting a route. This attribute will carry the BGP > Identifier of the originator of the route in the local AS. > > Here RR is doing _aggregation_ and not _origination_ of the route. Sorry > but this is not the same. As the RR performs the aggregation, it is *the RR* that originates the *aggregated route*. Yakov. From raszuk@cisco.com Mon Dec 21 06:55:17 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 95FD33A69E7 for ; Mon, 21 Dec 2009 06:55:17 -0800 (PST) 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 XG47isAPAVsi for ; Mon, 21 Dec 2009 06:55:16 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CB9643A6825 for ; Mon, 21 Dec 2009 06:55:16 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUGAJsaL0urRN+K/2dsb2JhbACZAKdOgRwIAZN/hC4E X-IronPort-AV: E=Sophos;i="4.47,431,1257120000"; d="scan'208";a="65817791" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 21 Dec 2009 14:55:01 +0000 Received: from [192.168.1.57] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBLEsxWg015190; Mon, 21 Dec 2009 14:55:00 GMT Message-ID: <4B2F8C43.2000500@cisco.com> Date: Mon, 21 Dec 2009 15:54:59 +0100 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B2BEAF5.4020609@orange-ftgroup.com> <4B2BF022.8020505@cisco.com> <200912211416.nBLEGPj03527@magenta.juniper.net> In-Reply-To: <200912211416.nBLEGPj03527@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Morin , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 14:55:17 -0000 Yakov, The spec started with just talking about setting the next hop to self on the RR, then is was discovered that this is not sufficient and ORIGINATOR_ID was added. Now we have a case where this is not really a route reflector as definition of reflection means to receive a path and *reflect* such path to the clients/non-clients. Now this "RR" is an originator of the C-multicast routes ... I think it would be much better to call it correctly ... as already proposed to call it "C-multicast route aggregator" or perhaps just "C-multicast route proxy" - in any case it is clear that IBGP aggregation and route origination by a control plane only RR is a new network function - not that common in IP or even in VPN networks. Now regardless of the name where can one find a definition of such IBGP aggregation ? As an example: should such "IBGP aggregation device" remove local preference if it is send by the PEs along with c-multicast routes ? If not having two such IBGP aggregation devices which is likely to be the practical case may still generate unnecessary churn on all PEs involved. Robert. > Robert, > >> Hi Thomas, >> >>> [...] C-multicast routes for a given (S,G) of a given MVPN >>> originated by PEs that are clients of >>> a given Route Reflector are aggregated by the Route Reflector. [...] >>> >>> A BGP aggregated route is a route originated by the BGP peer doing the >>> aggregation, why would it carry another ORIGINATOR_ID than the one of >>> the BGP peer doing the aggregation (here the RR) ? >> Because RR behavior is very well already defined in RFC 4456 which says: >> >> ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type >> code 9. This attribute is 4 bytes long and it will be created by an >> RR in reflecting a route. This attribute will carry the BGP >> Identifier of the originator of the route in the local AS. >> >> Here RR is doing _aggregation_ and not _origination_ of the route. Sorry >> but this is not the same. > > As the RR performs the aggregation, it is *the RR* that originates > the *aggregated route*. > > Yakov. > From yakov@juniper.net Mon Dec 21 07:08:42 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 699563A693E for ; Mon, 21 Dec 2009 07:08:42 -0800 (PST) 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 PmRgSTz3-35e for ; Mon, 21 Dec 2009 07:08:41 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with SMTP id C70C93A68A4 for ; Mon, 21 Dec 2009 07:08:39 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSy+PZ5aw5Z+toCvwwd6ckwP7TuI+v3O3@postini.com; Mon, 21 Dec 2009 07:08:25 PST 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.393.1; Mon, 21 Dec 2009 07:05:39 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 07:05:39 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 07:05:39 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 07:05:39 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBLF5dj20847; Mon, 21 Dec 2009 07:05:39 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200912211505.nBLF5dj20847@magenta.juniper.net> To: raszuk@cisco.com Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 In-Reply-To: <4B296D1C.6000001@cisco.com> References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B296D1C.6000001@cisco.com> X-MH-In-Reply-To: Robert Raszuk message dated "Thu, 17 Dec 2009 00:28:28 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <52973.1261407939.1@juniper.net> Date: Mon, 21 Dec 2009 07:05:39 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 21 Dec 2009 15:05:39.0201 (UTC) FILETIME=[0E92CF10:01CA824F] Cc: Thomas Morin , 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: Mon, 21 Dec 2009 15:08:42 -0000 Robert, > Therefor before proceeding in this WG I would like to either see all > references to BGP route reflectors use removed. Alternatively they could > be replaced with the new term describing their newly defined and > apparently required functionality for any form of sensible operation of > the proposed herein solution. Let me remind you that modifying the ORIGINATOR_ID and Next_hop attributes by Route Reflectors (by setting up the ORIGINATOR_ID attribute to self) is by no means new to C-multicast routing. From rfc4684, section 3.2: i. When advertising RT membership NLRI to a route-reflector client, the Originator attribute shall be set to the router-id of the advertiser, and the Next-hop attribute shall be set of the local address for that session. Interestingly enough at the time this rfc was published, you did *not* raise any objections/concerns to Route Reflectors modifying the ORIGINATOR_ID and the Next_Hop attributes (by setting both of them to self). Moreover, at that time you did *not* request that in rfc4684 "all references to BGP route reflectors use removed". You did *not* request to replace all references to BGP route reflectors in that rfc "with the new term". All this is especially interesting since you are one of the co-authors of rfc4684. Yakov. From raszuk@cisco.com Mon Dec 21 07:20:37 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 B53CF3A6A1C for ; Mon, 21 Dec 2009 07:20:37 -0800 (PST) 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 5xO9lkf27Yvg for ; Mon, 21 Dec 2009 07:20:36 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8B5363A6969 for ; Mon, 21 Dec 2009 07:20:36 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUGAHcgL0urRN+J/2dsb2JhbACZAKdcgRwIAZQBhC4E X-IronPort-AV: E=Sophos;i="4.47,431,1257120000"; d="scan'208";a="65834567" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 21 Dec 2009 15:20:13 +0000 Received: from [192.168.1.57] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBLFKBJN007386; Mon, 21 Dec 2009 15:20:12 GMT Message-ID: <4B2F922A.9070307@cisco.com> Date: Mon, 21 Dec 2009 16:20:10 +0100 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B296D1C.6000001@cisco.com> <200912211505.nBLF5dj20847@magenta.juniper.net> In-Reply-To: <200912211505.nBLF5dj20847@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Morin , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 15:20:37 -0000 Yakov, The goals of overwriting Originator_ID by the RR in RFC4684 are totally different then those described in mvpn spec. To quote: The first of these route advertisement rules is designed such that the originator of an RT membership NLRI does not drop an RT membership NLRI that is reflected back to it, thus allowing the route reflector to use this RT membership NLRI in order to signal the client that it should distribute VPN routes with the specific target towards the reflector. So it has no bearing on limiting the churn of RTs ... contrary it makes sure that reflected NLRI is just not dropped. On the other hand in current mvpn draft the goal is to stabilize the control plane behavior to make it comparable with alternative solutions to the same application space. Cheers, R. > Robert, > >> Therefor before proceeding in this WG I would like to either see all >> references to BGP route reflectors use removed. Alternatively they could >> be replaced with the new term describing their newly defined and >> apparently required functionality for any form of sensible operation of >> the proposed herein solution. > > Let me remind you that modifying the ORIGINATOR_ID and Next_hop > attributes by Route Reflectors (by setting up the ORIGINATOR_ID > attribute to self) is by no means new to C-multicast routing. From > rfc4684, section 3.2: > > i. When advertising RT membership NLRI to a route-reflector client, > the Originator attribute shall be set to the router-id of the > advertiser, and the Next-hop attribute shall be set of the local > address for that session. > > Interestingly enough at the time this rfc was published, you did > *not* raise any objections/concerns to Route Reflectors modifying > the ORIGINATOR_ID and the Next_Hop attributes (by setting both of > them to self). > > Moreover, at that time you did *not* request that in rfc4684 "all > references to BGP route reflectors use removed". You did *not* > request to replace all references to BGP route reflectors in that > rfc "with the new term". > > All this is especially interesting since you are one of the co-authors > of rfc4684. > > Yakov. From wwwrun@core3.amsl.com Mon Dec 21 09:28:49 2009 Return-Path: X-Original-To: l3vpn@ietf.org Delivered-To: l3vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 625393A6A64; Mon, 21 Dec 2009 09:28:49 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Subject: Protocol Action: 'OSPFv3 as a PE-CE routing protocol' to Proposed Standard Message-Id: <20091221172849.625393A6A64@core3.amsl.com> Date: Mon, 21 Dec 2009 09:28:49 -0800 (PST) Cc: l3vpn chair , Internet Architecture Board , l3vpn mailing list , RFC Editor 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, 21 Dec 2009 17:28:49 -0000 The IESG has approved the following document: - 'OSPFv3 as a PE-CE routing protocol ' as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Ross Callon and Adrian Farrel. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ospfv3-pece-04.txt Technical Summary 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 very similar to the previously-specified approached for OSPFv2. Working Group Summary No controversy reported (see PROTO writeup by Danny McPherson in the ID Tracker). There were no objections during the WG Last Call on the document, and the utility of this specification is straight-forward, as well as both obvious and intuitive. Document Quality No known implementations. Personnel Danny McPherson is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. RFC Editor Note All references to [BGP-EXTCOMM-IPV6] should be replaced by a references to [RFC5701]. In the informative references section (11.2), please remove the reference to [BGP-EXTCOMM-IPV6]. Please add a reference to RFC5701 in the normative references section (11.1). From mn1921@att.com Mon Dec 21 10:17:08 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 AAE6C3A6A9F for ; Mon, 21 Dec 2009 10:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.416 X-Spam-Level: X-Spam-Status: No, score=-106.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 UkrV0iKzG-Zv for ; Mon, 21 Dec 2009 10:17:07 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id AF39028C121 for ; Mon, 21 Dec 2009 10:16:57 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1261419400!35833223!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 29172 invoked from network); 21 Dec 2009 18:16:40 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Dec 2009 18:16:40 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBLIGbbD003648 for ; Mon, 21 Dec 2009 13:16:37 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBLIGaUR003641 for ; Mon, 21 Dec 2009 13:16:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 Date: Mon, 21 Dec 2009 13:16:35 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A2004580452@misout7msgusr7e.ugd.att.com> In-Reply-To: <4B2BEAF5.4020609@orange-ftgroup.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 Thread-Index: AcqAI7iCPqzZ5H9AQ6ulRjiQRusvtACRXDqw References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B2BEAF5.4020609@orange-ftgroup.com> From: "NAPIERALA, MARIA H (ATTLABS)" To: "Thomas Morin" , "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: Mon, 21 Dec 2009 18:17:08 -0000 VGhvbWFzLA0KDQo+IA0KPiBNYXJpYSwNCj4gDQo+IE5BUElFUkFMQSwgTUFSSUEgSCAoQVRUTEFC Uyk6DQo+ID4+ICAgICAtIE9SSUdJTkFUT1JfSUQgOiB1cGRhdGVzIG9mIHRoZSB2YWx1ZSBvZiB0 aGlzIGF0dHJpYnV0ZXMgZG8gbm90DQo+ID4+ICJmb2xsb3ciIFBFIGFkdmVydGlzZW1lbnRzLCBh cyB0aGUgUlIgcmV3cml0ZSBpdCB3aGVuIGFnZ3JlZ2F0aW5nIEMtDQo+ID4+IG11bHRpY2FzdCBy b3V0ZXMgaGF2aW5nIHNhbWUgTkxSSTsgdGhlIGFkdmVydGlzZW1lbnRzIG1hZGUgYnkNCj4gZGlm ZmVyZW50DQo+ID4+IFJScyBtYXkgbGVhZCBwb3NzaWJseSB0byB1cGRhdGVzIG9mIHRoZSB2YWx1 ZSBvZiB0aGlzIGF0dHJpYnV0ZSwNCj4gZ2l2ZW4NCj4gPj4gdGhhdCBlYWNoIFJSIHdvdWxkIHNl dCBPUklHSU5BVE9SX0lEIHRvIGEgdmFsdWUgb2YgaXRzIG93bg0KPiA+Pg0KPiAgPg0KPiA+IFJl Z2FyZGluZyByb3V0ZSAqYWdncmVnYXRpb24qIHRoZSBkcmFmdC1pZXRmLWwzdnBuLTI1NDdiaXMt bWNhc3QtYmdwLQ0KPiAwOCBvbmx5IHN0YXRlcyB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ID4gICAg ICJUbyBmdXJ0aGVyIHJlZHVjZSB0aGUgcm91dGluZyBjaHVybiBkdWUgdG8gQy1tdWx0aWNhc3Qg cm91dGVzDQo+IGNoYW5nZXMNCj4gPiAgICAgYSBSb3V0ZSBSZWZsZWN0b3IgdGhhdCByZS1hZHZl cnRpc2VzIGEgQy1tdWx0aWNhc3Qgcm91dGUgU0hPVUxEDQo+IHNldA0KPiA+ICAgICB0aGUgTmV4 dCBIb3AgZmllbGQgb2YgdGhlIE1QX1JFQUNIX05MUkkgYXR0cmlidXRlIG9mIHRoZSByb3V0ZSB0 bw0KPiBhbg0KPiA+ICAgICBJUCBhZGRyZXNzIG9mIHRoZSBSb3V0ZSBSZWZsZWN0b3IuIExpa2V3 aXNlLCBhbiBBU0JSIHRoYXQgcmUtDQo+ID4gICAgIGFkdmVydGlzZXMgYSBDLW11bHRpY2FzdCBy b3V0ZSBTSE9VTEQgc2V0IHRoZSBOZXh0IEhvcCBmaWVsZCBvZg0KPiB0aGUNCj4gPiAgICAgTVBf UkVBQ0hfTkxSSSBhdHRyaWJ1dGUgb2YgdGhlIHJvdXRlIHRvIGFuIElQIGFkZHJlc3Mgb2YgdGhl DQo+IEFTQlIuIg0KPiA+DQo+ID4gSXQgc3RhdGVzIG5vdGhpbmcgYWJvdXQgc2V0dGluZyBPUklH SU5BVE9SX0lEIHRvIHNlbGYgb24gUlIuDQo+IA0KPiBJdCBhbHNvIHNheXM6DQo+IA0KPiAgICAg ICBbLi4uXSBDLW11bHRpY2FzdCByb3V0ZXMgZm9yIGEgZ2l2ZW4gKFMsRykgb2YgYSBnaXZlbiBN VlBODQo+IG9yaWdpbmF0ZWQgYnkgUEVzIHRoYXQgYXJlIGNsaWVudHMgb2YNCj4gICAgICAgYSBn aXZlbiBSb3V0ZSBSZWZsZWN0b3IgYXJlIGFnZ3JlZ2F0ZWQgYnkgdGhlIFJvdXRlIFJlZmxlY3Rv ci4NCj4gWy4uLl0NCj4gDQoNCllvdSBvbWl0dGVkIHZlcnkgaW1wb3J0YW50IHRleHQgZnJvbSB0 aGUgc2FtZSBzZWN0aW9uIDExLjQgdGhhdCBwcmVjZWRlcyB0aGUgb25lIHlvdSBxdW90ZWQsIG5h bWVseToNCg0KICAiTm90ZSB0aGF0IEMtbXVsdGljYXN0IHJvdXRlcyBhcmUgImRlIGZhY3RvIiBh Z2dyZWdhdGVkIGJ5IEJHUC4gVGhpcw0KICAgaXMgYmVjYXVzZSB0aGUgTUNBU1QtVlBOIE5MUklz IGFkdmVydGlzZWQgYnkgbXVsdGlwbGUgUEVzLCBmb3IgYSBDLQ0KICAgbXVsdGljYXN0IHJvdXRl IGZvciBhIHBhcnRpY3VsYXIgQy1TIGFuZCBDLUcgKG9yIGEgcGFydGljdWxhciBDLSogYW5kDQog ICBDLUcpIG9mIGEgZ2l2ZW4gTVZQTiBhcmUgaWRlbnRpY2FsLiINCg0KVGhpcyBpcyB0aGUgcm91 dGUgYWdncmVnYXRpb24gdGhlIHRleHQgeW91IHF1b3RlZCByZWZlcnMgdG8uIA0KDQpSZWdhcmRp bmcgdGhlIHJvdXRpbmcgKmNodXJuKiwgc2VjdGlvbiAxMS40IHNheXMgZnVydGhlciBkb3duIHRo YXQ6DQoNCiAg4oCdVG8gZnVydGhlciByZWR1Y2UgdGhlIHJvdXRpbmcgY2h1cm4gZHVlIHRvIEMt bXVsdGljYXN0IHJvdXRlcyBjaGFuZ2VzDQogICBhIFJvdXRlIFJlZmxlY3RvciB0aGF0IHJlLWFk dmVydGlzZXMgYSBDLW11bHRpY2FzdCByb3V0ZSBTSE9VTEQgc2V0DQogICB0aGUgTmV4dCBIb3Ag ZmllbGQgb2YgdGhlIE1QX1JFQUNIX05MUkkgYXR0cmlidXRlIG9mIHRoZSByb3V0ZSB0byBhbg0K ICAgSVAgYWRkcmVzcyBvZiB0aGUgUm91dGUgUmVmbGVjdG9yLiINCg0KV2hpY2gsIGluIGZhY3Qs IGRvZXNu4oCZdCByZWR1Y2Ugcm91dGluZyBjaHVybi4gDQoNCk1hcmlhDQoNCg== From rahul@juniper.net Mon Dec 21 10:59: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 BB7C628C129 for ; Mon, 21 Dec 2009 10:59:24 -0800 (PST) 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 T42gY2m42Pec for ; Mon, 21 Dec 2009 10:59:23 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with SMTP id B3EF43A68F4 for ; Mon, 21 Dec 2009 10:59:21 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSy/FeftJvQ8qQuxEkQEYeLgBoSbr+VzK@postini.com; Mon, 21 Dec 2009 10:59:07 PST 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.393.1; Mon, 21 Dec 2009 10:54:29 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 10:54:29 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 10:54:28 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 10:54:28 -0800 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBLIsSj07165; Mon, 21 Dec 2009 10:54:28 -0800 (PST) (envelope-from rahul@juniper.net) Date: Mon, 21 Dec 2009 10:54:28 -0800 From: Rahul Aggarwal To: "NAPIERALA, MARIA H (ATTLABS)" Subject: RE: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A2004580452@misout7msgusr7e.ugd.att.com> Message-ID: <20091221104548.N69632@sapphire.juniper.net> References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B2BEAF5.4020609@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A2004580452@misout7msgusr7e.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: QUOTED-PRINTABLE X-OriginalArrivalTime: 21 Dec 2009 18:54:28.0708 (UTC) FILETIME=[05FF5240:01CA826F] Cc: Thomas Morin , 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: Mon, 21 Dec 2009 18:59:24 -0000 Maria, On Mon, 21 Dec 2009, NAPIERALA, MARIA H (ATTLABS) wrote: > Thomas, > > > > > Maria, > > > > NAPIERALA, MARIA H (ATTLABS): > > >> - ORIGINATOR_ID : updates of the value of this attributes do not > > >> "follow" PE advertisements, as the RR rewrite it when aggregating C- > > >> multicast routes having same NLRI; the advertisements made by > > different > > >> RRs may lead possibly to updates of the value of this attribute, > > given > > >> that each RR would set ORIGINATOR_ID to a value of its own > > >> > > > > > > Regarding route *aggregation* the draft-ietf-l3vpn-2547bis-mcast-bgp- > > 08 only states the following: > > > > > > "To further reduce the routing churn due to C-multicast routes > > changes > > > a Route Reflector that re-advertises a C-multicast route SHOULD > > set > > > the Next Hop field of the MP_REACH_NLRI attribute of the route to > > an > > > IP address of the Route Reflector. Likewise, an ASBR that re- > > > advertises a C-multicast route SHOULD set the Next Hop field of > > the > > > MP_REACH_NLRI attribute of the route to an IP address of the > > ASBR." > > > > > > It states nothing about setting ORIGINATOR_ID to self on RR. > > > > It also says: > > > > [...] C-multicast routes for a given (S,G) of a given MVPN > > originated by PEs that are clients of > > a given Route Reflector are aggregated by the Route Reflector. > > [...] > > > > You omitted very important text from the same section 11.4 that precedes = the one you quoted, namely: > > "Note that C-multicast routes are "de facto" aggregated by BGP. This > is because the MCAST-VPN NLRIs advertised by multiple PEs, for a C- > multicast route for a particular C-S and C-G (or a particular C-* and > C-G) of a given MVPN are identical." > > This is the route aggregation the text you quoted refers to. > > Regarding the routing *churn*, section 11.4 says further down that: > > =E2=80=9DTo further reduce the routing churn due to C-multicast routes = changes > a Route Reflector that re-advertises a C-multicast route SHOULD set > the Next Hop field of the MP_REACH_NLRI attribute of the route to an > IP address of the Route Reflector." > > Which, in fact, doesn=E2=80=99t reduce routing churn. > Incorrect. The text you quoted *does* reduce routing churn due to C-multicast route changes. This is because it ensures that a Route Reflector advertises a C-multicast route, for a given (C-S/*, C-G) only when it receives the first route for the (C-S/*. C-G) from a client. It also ensures that a Route Reflector doesn't withdraw a C-multicast route for a given (C-S/*, C-G) as long as it has at least one route from a client for the (C-S/*, C-G). rahul From raszuk@cisco.com Mon Dec 21 11:12: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 1EAA53A67FA for ; Mon, 21 Dec 2009 11:12:47 -0800 (PST) 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=[AWL=0.000, 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 4I8jdekLNED7 for ; Mon, 21 Dec 2009 11:12:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8B2323A6893 for ; Mon, 21 Dec 2009 11:12:35 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQGACJXL0urRN+J/2dsb2JhbACECpRyqEyBHAgBhVuOTYEvgi1SBA X-IronPort-AV: E=Sophos;i="4.47,432,1257120000"; d="scan'208";a="123355798" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 21 Dec 2009 19:11:17 +0000 Received: from [192.168.1.57] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBLJBGpX017053; Mon, 21 Dec 2009 19:11:16 GMT Message-ID: <4B2FC853.4050208@cisco.com> Date: Mon, 21 Dec 2009 20:11:15 +0100 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Rahul Aggarwal Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B2BEAF5.4020609@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A2004580452@misout7msgusr7e.ugd.att.com> <20091221104548.N69632@sapphire.juniper.net> In-Reply-To: <20091221104548.N69632@sapphire.juniper.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Thomas Morin , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 19:12:47 -0000 Rahul, >> Regarding the routing *churn*, section 11.4 says further down that: >> >> ”To further reduce the routing churn due to C-multicast routes changes >> a Route Reflector that re-advertises a C-multicast route SHOULD set >> the Next Hop field of the MP_REACH_NLRI attribute of the route to an >> IP address of the Route Reflector." >> >> Which, in fact, doesn’t reduce routing churn. >> > > Incorrect. The text you quoted *does* reduce routing churn due to > C-multicast route changes. This is because it ensures that a Route > Reflector advertises a C-multicast route, for a given (C-S/*, C-G) only > when it receives the first route for the (C-S/*. C-G) from a client. It > also ensures that a Route Reflector doesn't withdraw a C-multicast route > for a given (C-S/*, C-G) as long as it has at least one route from a > client for the (C-S/*, C-G). Incorrect. As Maria have said correctly *the* quoted text does not reduce routing churn. The procedure you are spelling out are not reflected in the above paragraph. At least not in version 8 of the draft-ietf-l3vpn-2547bis-mcast-bgp. Thx, R. From rahul@juniper.net Mon Dec 21 11:23:58 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03823A692A for ; Mon, 21 Dec 2009 11:23:58 -0800 (PST) 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 QXplLHAC3MCG for ; Mon, 21 Dec 2009 11:23:58 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with SMTP id B6BE83A6892 for ; Mon, 21 Dec 2009 11:23:56 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSy/LPHoAptk9J6pbvQa3eDc6pOvtm/Ni@postini.com; Mon, 21 Dec 2009 11:23:42 PST 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.393.1; Mon, 21 Dec 2009 11:20:37 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 11:20:37 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 11:20:36 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 11:20:36 -0800 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBLJKaj18380; Mon, 21 Dec 2009 11:20:36 -0800 (PST) (envelope-from rahul@juniper.net) Date: Mon, 21 Dec 2009 11:20:36 -0800 From: Rahul Aggarwal To: Robert Raszuk Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 In-Reply-To: <4B2FC853.4050208@cisco.com> Message-ID: <20091221111529.G69632@sapphire.juniper.net> References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B2BEAF5.4020609@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A2004580452@misout7msgusr7e.ugd.att.com> <20091221104548.N69632@sapphire.juniper.net> <4B2FC853.4050208@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: QUOTED-PRINTABLE X-OriginalArrivalTime: 21 Dec 2009 19:20:36.0895 (UTC) FILETIME=[ACB5AAF0:01CA8272] Cc: Thomas Morin , 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: Mon, 21 Dec 2009 19:23:58 -0000 Robert, On Mon, 21 Dec 2009, Robert Raszuk wrote: > Rahul, > > >> Regarding the routing *churn*, section 11.4 says further down that: > >> > >> =E2=80=9DTo further reduce the routing churn due to C-multicast rout= es changes > >> a Route Reflector that re-advertises a C-multicast route SHOULD set > >> the Next Hop field of the MP_REACH_NLRI attribute of the route to a= n > >> IP address of the Route Reflector." > >> > >> Which, in fact, doesn=E2=80=99t reduce routing churn. > >> > > > > Incorrect. The text you quoted *does* reduce routing churn due to > > C-multicast route changes. This is because it ensures that a Route > > Reflector advertises a C-multicast route, for a given (C-S/*, C-G) only > > when it receives the first route for the (C-S/*. C-G) from a client. It > > also ensures that a Route Reflector doesn't withdraw a C-multicast rout= e > > for a given (C-S/*, C-G) as long as it has at least one route from a > > client for the (C-S/*, C-G). > > Incorrect. > > As Maria have said correctly *the* quoted text does not reduce routing > churn. > > The procedure you are spelling out are not reflected in the above > paragraph. At least not in version 8 of the > draft-ietf-l3vpn-2547bis-mcast-bgp. > That is an incorrect interpretation of the text in section 11.4. The procedure I spelled out follows from the text in section 11.4. rahul From mn1921@att.com Mon Dec 21 11:52: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 E7AD33A681C for ; Mon, 21 Dec 2009 11:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.132 X-Spam-Level: X-Spam-Status: No, score=-106.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 jGLSNrPRHtiE for ; Mon, 21 Dec 2009 11:52:24 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id B824F3A67FA for ; Mon, 21 Dec 2009 11:52:23 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-7.tower-146.messagelabs.com!1261425125!8773683!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 16333 invoked from network); 21 Dec 2009 19:52:05 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Dec 2009 19:52:05 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBLJq331008165; Mon, 21 Dec 2009 14:52:03 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBLJpx88008086; Mon, 21 Dec 2009 14:51:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /sectionA.1.1.3 Date: Mon, 21 Dec 2009 14:52:00 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A20045804CC@misout7msgusr7e.ugd.att.com> In-Reply-To: <20091221111529.G69632@sapphire.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /sectionA.1.1.3 Thread-Index: AcqCcywZmgKKtOXCSM2nDxPARZbC5gAA3NDQ References: <3126.1259858356@erosen-linux><4B28E84F.4000604@orange-ftgroup.com><2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com><4B2BEAF5.4020609@orange-ftgroup.com><2F1DE4DFCFF32144B771BD2C246E6A2004580452@misout7msgusr7e.ugd.att.com><20091221104548.N69632@sapphire.juniper.net><4B2FC853.4050208@cisco.com> <20091221111529.G69632@sapphire.juniper.net> From: "NAPIERALA, MARIA H (ATTLABS)" To: "Rahul Aggarwal" , "Robert Raszuk" Cc: Thomas Morin , 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: Mon, 21 Dec 2009 19:52:25 -0000 UmFodWwsDQoNCnRoZSBSb3V0ZSBSZWZsZWN0b3IgYWR2ZXJ0aXplcyB0aGUgZmlyc3QgQy1tdWx0 aWNhc3QgKFMvKixHKSBKb2luIHJvdXRlIGFuZCBhbnkgc3Vic2VxdWVudCBDLW11bHRpY2FzdCAo Uy8qLEcpIEpvaW4gcm91dGUgaWYgaXQgaXMgYmV0dGVyIHRoYW4gcHJldmlvdXNseSBzZWxlY3Rl ZCwgd2l0aCB0aGUgY29ycmVzcG9uZGluZyB0byB0aGUgbmV3IGJlc3Qgcm91dGUgT1JJR0lOQVRP Ul9JRC4NCg0KV2hpY2ggdGV4dCBpbiBzZWN0aW9uIDExLjQgc3RhdGVzIG90aGVyd2lzZT8NCg0K TWFyaWENCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGwzdnBuLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYN Cj4gT2YgUmFodWwgQWdnYXJ3YWwNCj4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAyMSwgMjAwOSAy OjIxIFBNDQo+IFRvOiBSb2JlcnQgUmFzenVrDQo+IENjOiBUaG9tYXMgTW9yaW47IEwzVlBODQo+ IFN1YmplY3Q6IFJlOiBkcmFmdC1pZXRmLWwzdnBuLW12cG4tY29uc2lkZXJhdGlvbnMtMDUgLyBB cHBlbmRpeCBBDQo+IC9zZWN0aW9uQS4xLjEuMw0KPiANCj4gDQo+IFJvYmVydCwNCj4gDQo+IE9u IE1vbiwgMjEgRGVjIDIwMDksIFJvYmVydCBSYXN6dWsgd3JvdGU6DQo+IA0KPiA+IFJhaHVsLA0K PiA+DQo+ID4gPj4gUmVnYXJkaW5nIHRoZSByb3V0aW5nICpjaHVybiosIHNlY3Rpb24gMTEuNCBz YXlzIGZ1cnRoZXIgZG93bg0KPiB0aGF0Og0KPiA+ID4+DQo+ID4gPj4gICDigJ1UbyBmdXJ0aGVy IHJlZHVjZSB0aGUgcm91dGluZyBjaHVybiBkdWUgdG8gQy1tdWx0aWNhc3Qgcm91dGVzDQo+IGNo YW5nZXMNCj4gPiA+PiAgICBhIFJvdXRlIFJlZmxlY3RvciB0aGF0IHJlLWFkdmVydGlzZXMgYSBD LW11bHRpY2FzdCByb3V0ZSBTSE9VTEQNCj4gc2V0DQo+ID4gPj4gICAgdGhlIE5leHQgSG9wIGZp ZWxkIG9mIHRoZSBNUF9SRUFDSF9OTFJJIGF0dHJpYnV0ZSBvZiB0aGUgcm91dGUNCj4gdG8gYW4N Cj4gPiA+PiAgICBJUCBhZGRyZXNzIG9mIHRoZSBSb3V0ZSBSZWZsZWN0b3IuIg0KPiA+ID4+DQo+ ID4gPj4gV2hpY2gsIGluIGZhY3QsIGRvZXNu4oCZdCByZWR1Y2Ugcm91dGluZyBjaHVybi4NCj4g PiA+Pg0KPiA+ID4NCj4gPiA+IEluY29ycmVjdC4gVGhlIHRleHQgeW91IHF1b3RlZCAqZG9lcyog cmVkdWNlIHJvdXRpbmcgY2h1cm4gZHVlIHRvDQo+ID4gPiBDLW11bHRpY2FzdCByb3V0ZSBjaGFu Z2VzLiBUaGlzIGlzIGJlY2F1c2UgaXQgZW5zdXJlcyB0aGF0IGEgUm91dGUNCj4gPiA+IFJlZmxl Y3RvciBhZHZlcnRpc2VzIGEgQy1tdWx0aWNhc3Qgcm91dGUsIGZvciBhIGdpdmVuIChDLVMvKiwg Qy1HKQ0KPiBvbmx5DQo+ID4gPiB3aGVuIGl0IHJlY2VpdmVzIHRoZSBmaXJzdCByb3V0ZSBmb3Ig dGhlIChDLVMvKi4gQy1HKSBmcm9tIGENCj4gY2xpZW50LiBJdA0KPiA+ID4gYWxzbyBlbnN1cmVz IHRoYXQgYSBSb3V0ZSBSZWZsZWN0b3IgZG9lc24ndCB3aXRoZHJhdyBhIEMtbXVsdGljYXN0DQo+ IHJvdXRlDQo+ID4gPiBmb3IgYSBnaXZlbiAoQy1TLyosIEMtRykgYXMgbG9uZyBhcyBpdCBoYXMg YXQgbGVhc3Qgb25lIHJvdXRlIGZyb20NCj4gYQ0KPiA+ID4gY2xpZW50IGZvciB0aGUgKEMtUy8q LCBDLUcpLg0KPiA+DQo+ID4gSW5jb3JyZWN0Lg0KPiA+DQo+ID4gQXMgTWFyaWEgaGF2ZSBzYWlk IGNvcnJlY3RseSAqdGhlKiBxdW90ZWQgdGV4dCBkb2VzIG5vdCByZWR1Y2UNCj4gcm91dGluZw0K PiA+IGNodXJuLg0KPiA+DQo+ID4gVGhlIHByb2NlZHVyZSB5b3UgYXJlIHNwZWxsaW5nIG91dCBh cmUgbm90IHJlZmxlY3RlZCBpbiB0aGUgYWJvdmUNCj4gPiBwYXJhZ3JhcGguIEF0IGxlYXN0IG5v dCBpbiB2ZXJzaW9uIDggb2YgdGhlDQo+ID4gZHJhZnQtaWV0Zi1sM3Zwbi0yNTQ3YmlzLW1jYXN0 LWJncC4NCj4gPg0KPiANCj4gVGhhdCBpcyBhbiBpbmNvcnJlY3QgaW50ZXJwcmV0YXRpb24gb2Yg dGhlIHRleHQgaW4gc2VjdGlvbiAxMS40LiBUaGUNCj4gcHJvY2VkdXJlIEkgc3BlbGxlZCBvdXQg Zm9sbG93cyBmcm9tIHRoZSB0ZXh0IGluIHNlY3Rpb24gMTEuNC4NCj4gDQo+IA0KPiByYWh1bA0K From robert@raszuk.net Mon Dec 21 11:56:21 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B943A6AA9 for ; Mon, 21 Dec 2009 11:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t91sxES44lz5 for ; Mon, 21 Dec 2009 11:56:20 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A09303A6AA6 for ; Mon, 21 Dec 2009 11:56:20 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,432,1257120000"; d="scan'208";a="65929288" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 21 Dec 2009 19:56:04 +0000 Received: from [192.168.1.57] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nBLJu3B1021787; Mon, 21 Dec 2009 19:56:03 GMT Message-ID: <4B2FD2D2.9030206@raszuk.net> Date: Mon, 21 Dec 2009 20:56:02 +0100 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Rahul Aggarwal Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / sectionA.1.1.3 References: <3126.1259858356@erosen-linux> <4B28E84F.4000604@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com> <4B2BEAF5.4020609@orange-ftgroup.com> <2F1DE4DFCFF32144B771BD2C246E6A2004580452@misout7msgusr7e.ugd.att.com> <20091221104548.N69632@sapphire.juniper.net> <4B2FC853.4050208@cisco.com> <20091221111529.G69632@sapphire.juniper.net> In-Reply-To: <20091221111529.G69632@sapphire.juniper.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Robert Raszuk , Thomas Morin , L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 19:56:21 -0000 Rahul, >>>> Regarding the routing *churn*, section 11.4 says further down that: >>>> >>>> ”To further reduce the routing churn due to C-multicast routes changes >>>> a Route Reflector that re-advertises a C-multicast route SHOULD set >>>> the Next Hop field of the MP_REACH_NLRI attribute of the route to an >>>> IP address of the Route Reflector." >>>> >>>> Which, in fact, doesn’t reduce routing churn. >>>> >>> Incorrect. The text you quoted *does* reduce routing churn due to >>> C-multicast route changes. This is because it ensures that a Route >>> Reflector advertises a C-multicast route, for a given (C-S/*, C-G) only >>> when it receives the first route for the (C-S/*. C-G) from a client. It >>> also ensures that a Route Reflector doesn't withdraw a C-multicast route >>> for a given (C-S/*, C-G) as long as it has at least one route from a >>> client for the (C-S/*, C-G). >> Incorrect. >> >> As Maria have said correctly *the* quoted text does not reduce routing >> churn. >> >> The procedure you are spelling out are not reflected in the above >> paragraph. At least not in version 8 of the >> draft-ietf-l3vpn-2547bis-mcast-bgp. >> > > That is an incorrect interpretation of the text in section 11.4. The > procedure I spelled out follows from the text in section 11.4. > Unfortunately not. Route reflector advertises *best* path not the *first* path. The text as stated today does not accomplish C-multicast routes aggregation. Also the concept of path virtualization you are essentially recommending at the withdraw is new. Moreover it makes the use of route reflector "aggregators" a mandatory device in the solution. Btw how service provider interested in the service and having full mesh of IBGP provide any c-multicast aggregation ? How about service provider which uses confederations ? I think this thread has reached it's limits. The discussion about route reflection as described in section 11.4 should take place on IDR list. I bet vast majority of the members of L3VPN WG do not even read emails when the subject contains "mvpn" part :). Cheers and Happy Holidays, R. From rahul@juniper.net Tue Dec 22 15:06:28 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 AE62C3A68EA for ; Tue, 22 Dec 2009 15:06:28 -0800 (PST) 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_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n0MTpJjy3fV for ; Tue, 22 Dec 2009 15:06:27 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with SMTP id C5B1E3A67E7 for ; Tue, 22 Dec 2009 15:05:57 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSzFQxccc7WFul5CEzsU/g3QwEUxA7vPI@postini.com; Tue, 22 Dec 2009 15:06:11 PST 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.393.1; Tue, 22 Dec 2009 15:03:32 -0800 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, 22 Dec 2009 15:03:31 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Dec 2009 15:03:31 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Dec 2009 15:03:31 -0800 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nBMN3Vj37525; Tue, 22 Dec 2009 15:03:31 -0800 (PST) (envelope-from rahul@juniper.net) Date: Tue, 22 Dec 2009 15:03:31 -0800 From: Rahul Aggarwal To: "NAPIERALA, MARIA H (ATTLABS)" Subject: RE: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /sectionA.1.1.3 In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A20045804CC@misout7msgusr7e.ugd.att.com> Message-ID: <20091222144315.T2504@sapphire.juniper.net> References: <3126.1259858356@erosen-linux><4B28E84F.4000604@orange-ftgroup.com><2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com><4B2BEAF5.4020609@orange-ftgroup.com><2F1DE4DFCFF32144B771BD2C246E6A2004580452@misout7msgusr7e.ugd.att.com><20091221104548.N69632@sapphire.juniper.net><4B2FC853.4050208@cisco.com> <20091221111529.G69632@sapphire.juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A20045804CC@misout7msgusr7e.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="X-UNKNOWN" Content-Transfer-Encoding: QUOTED-PRINTABLE X-OriginalArrivalTime: 22 Dec 2009 23:03:31.0413 (UTC) FILETIME=[FAF4E850:01CA835A] Cc: Robert Raszuk , Thomas Morin , 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: Tue, 22 Dec 2009 23:06:28 -0000 Maria, On Mon, 21 Dec 2009, NAPIERALA, MARIA H (ATTLABS) wrote: > Rahul, > > the Route Reflector advertizes the first C-multicast (S/*,G) Join route a= nd any > subsequent C-multicast (S/*,G) Join route if it is better than previously > selected, No. As specified in section 11.4 the Route Reflector advertises an aggregated C-multicast route. > with the corresponding to the new best route ORIGINATOR_ID. > > Which text in section 11.4 states otherwise? > The entire text in section 11.4 describes how a Route Reflector aggregates C-multicast routes. At least two vendors with an inter-operable implementation have had no trouble interpreting section 11.4. So despite your mis-interpretations the spec is serving its purpose. And finally, I am done repeating myself. rahul > Maria > > > > -----Original Message----- > > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > > Of Rahul Aggarwal > > Sent: Monday, December 21, 2009 2:21 PM > > To: Robert Raszuk > > Cc: Thomas Morin; L3VPN > > Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A > > /sectionA.1.1.3 > > > > > > Robert, > > > > On Mon, 21 Dec 2009, Robert Raszuk wrote: > > > > > Rahul, > > > > > > >> Regarding the routing *churn*, section 11.4 says further down > > that: > > > >> > > > >> =E2=80=9DTo further reduce the routing churn due to C-multicast = routes > > changes > > > >> a Route Reflector that re-advertises a C-multicast route SHOULD > > set > > > >> the Next Hop field of the MP_REACH_NLRI attribute of the route > > to an > > > >> IP address of the Route Reflector." > > > >> > > > >> Which, in fact, doesn=E2=80=99t reduce routing churn. > > > >> > > > > > > > > Incorrect. The text you quoted *does* reduce routing churn due to > > > > C-multicast route changes. This is because it ensures that a Route > > > > Reflector advertises a C-multicast route, for a given (C-S/*, C-G) > > only > > > > when it receives the first route for the (C-S/*. C-G) from a > > client. It > > > > also ensures that a Route Reflector doesn't withdraw a C-multicast > > route > > > > for a given (C-S/*, C-G) as long as it has at least one route from > > a > > > > client for the (C-S/*, C-G). > > > > > > Incorrect. > > > > > > As Maria have said correctly *the* quoted text does not reduce > > routing > > > churn. > > > > > > The procedure you are spelling out are not reflected in the above > > > paragraph. At least not in version 8 of the > > > draft-ietf-l3vpn-2547bis-mcast-bgp. > > > > > > > That is an incorrect interpretation of the text in section 11.4. The > > procedure I spelled out follows from the text in section 11.4. > > > > > > rahul > > From mn1921@att.com Tue Dec 22 15:50:46 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 65CB13A68C6 for ; Tue, 22 Dec 2009 15:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.121 X-Spam-Level: X-Spam-Status: No, score=-106.121 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 qfaOCO8TlrIg for ; Tue, 22 Dec 2009 15:50:45 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 732183A6867 for ; Tue, 22 Dec 2009 15:50:45 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-5.tower-129.messagelabs.com!1261525827!23537293!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 26373 invoked from network); 22 Dec 2009 23:50:28 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Dec 2009 23:50:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBMNoOqV017588; Tue, 22 Dec 2009 18:50:24 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBMNoJv9017561; Tue, 22 Dec 2009 18:50:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /sectionA.1.1.3 Date: Tue, 22 Dec 2009 18:49:56 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200463340D@misout7msgusr7e.ugd.att.com> In-Reply-To: <20091222144315.T2504@sapphire.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /sectionA.1.1.3 Thread-Index: AcqDW19tQvx+DrQXRaSTGymvJNXF/wABU/aw References: <3126.1259858356@erosen-linux><4B28E84F.4000604@orange-ftgroup.com><2F1DE4DFCFF32144B771BD2C246E6A200451C9E0@misout7msgusr7e.ugd.att.com><4B2BEAF5.4020609@orange-ftgroup.com><2F1DE4DFCFF32144B771BD2C246E6A2004580452@misout7msgusr7e.ugd.att.com><20091221104548.N69632@sapphire.juniper.net><4B2FC853.4050208@cisco.com> <20091221111529.G69632@sapphire.juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A20045804CC@misout7msgusr7e.ugd.att.com> <20091222144315.T2504@sapphire.juniper.net> From: "NAPIERALA, MARIA H (ATTLABS)" To: "Rahul Aggarwal" Cc: Robert Raszuk , Thomas Morin , 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: Tue, 22 Dec 2009 23:50:46 -0000 UmFodWwsDQoNCj4gPiB0aGUgUm91dGUgUmVmbGVjdG9yIGFkdmVydGl6ZXMgdGhlIGZpcnN0IEMt bXVsdGljYXN0IChTLyosRykgSm9pbg0KPiByb3V0ZSBhbmQgYW55DQo+ID4gc3Vic2VxdWVudCBD LW11bHRpY2FzdCAoUy8qLEcpIEpvaW4gcm91dGUgaWYgaXQgaXMgYmV0dGVyIHRoYW4NCj4gcHJl dmlvdXNseQ0KPiA+IHNlbGVjdGVkLA0KPiANCj4gTm8uIEFzIHNwZWNpZmllZCBpbiBzZWN0aW9u IDExLjQgdGhlIFJvdXRlIFJlZmxlY3RvciBhZHZlcnRpc2VzIGFuDQo+IGFnZ3JlZ2F0ZWQgQy1t dWx0aWNhc3Qgcm91dGUuDQo+IA0KPiA+IHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgdG8gdGhlIG5l dyBiZXN0IHJvdXRlIE9SSUdJTkFUT1JfSUQuDQoNCllvdSBjb252ZW5pZW50bHkgb21pdHRlZCB0 aGlzIHN0YXRlbWVudC4uDQoNCj4gVGhlIGVudGlyZSB0ZXh0IGluIHNlY3Rpb24gMTEuNCBkZXNj cmliZXMgaG93IGEgUm91dGUgUmVmbGVjdG9yDQo+IGFnZ3JlZ2F0ZXMgQy1tdWx0aWNhc3Qgcm91 dGVzLg0KDQpXZWxsLCB0aGlzIGRvZXNuJ3QgYW5zd2VyIG15IHF1ZXN0aW9uLg0KDQo+IEF0IGxl YXN0IHR3byB2ZW5kb3JzIHdpdGggYW4gaW50ZXItb3BlcmFibGUgaW1wbGVtZW50YXRpb24gaGF2 ZSBoYWQgbm8NCj4gdHJvdWJsZSBpbnRlcnByZXRpbmcgc2VjdGlvbiAxMS40LiBTbyBkZXNwaXRl IHlvdXIgbWlzLWludGVycHJldGF0aW9ucw0KPiB0aGUgc3BlYyBpcyBzZXJ2aW5nIGl0cyBwdXJw b3NlLg0KDQpJIG5ldmVyIHNhaWQgdGhhdCBzZWN0aW9uIDExLjQgKGFzIGl0IGlzIHdyaXR0ZW4p IHByb2R1Y2VzIG5vbi1pbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4NCiAgDQo+IEFuZCBm aW5hbGx5LCBJIGFtIGRvbmUgcmVwZWF0aW5nIG15c2VsZi4NCg0KU2FtZSBmb3IgbWUuDQoNCk1h cmlhDQoNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBsM3Zw bi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24NCj4g QmVoYWxmDQo+ID4gPiBPZiBSYWh1bCBBZ2dhcndhbA0KPiA+ID4gU2VudDogTW9uZGF5LCBEZWNl bWJlciAyMSwgMjAwOSAyOjIxIFBNDQo+ID4gPiBUbzogUm9iZXJ0IFJhc3p1aw0KPiA+ID4gQ2M6 IFRob21hcyBNb3JpbjsgTDNWUE4NCj4gPiA+IFN1YmplY3Q6IFJlOiBkcmFmdC1pZXRmLWwzdnBu LW12cG4tY29uc2lkZXJhdGlvbnMtMDUgLyBBcHBlbmRpeCBBDQo+ID4gPiAvc2VjdGlvbkEuMS4x LjMNCj4gPiA+DQo+ID4gPg0KPiA+ID4gUm9iZXJ0LA0KPiA+ID4NCj4gPiA+IE9uIE1vbiwgMjEg RGVjIDIwMDksIFJvYmVydCBSYXN6dWsgd3JvdGU6DQo+ID4gPg0KPiA+ID4gPiBSYWh1bCwNCj4g PiA+ID4NCj4gPiA+ID4gPj4gUmVnYXJkaW5nIHRoZSByb3V0aW5nICpjaHVybiosIHNlY3Rpb24g MTEuNCBzYXlzIGZ1cnRoZXIgZG93bg0KPiA+ID4gdGhhdDoNCj4gPiA+ID4gPj4NCj4gPiA+ID4g Pj4gICDDouKCrMKdVG8gZnVydGhlciByZWR1Y2UgdGhlIHJvdXRpbmcgY2h1cm4gZHVlIHRvIEMt bXVsdGljYXN0DQo+IHJvdXRlcw0KPiA+ID4gY2hhbmdlcw0KPiA+ID4gPiA+PiAgICBhIFJvdXRl IFJlZmxlY3RvciB0aGF0IHJlLWFkdmVydGlzZXMgYSBDLW11bHRpY2FzdCByb3V0ZQ0KPiBTSE9V TEQNCj4gPiA+IHNldA0KPiA+ID4gPiA+PiAgICB0aGUgTmV4dCBIb3AgZmllbGQgb2YgdGhlIE1Q X1JFQUNIX05MUkkgYXR0cmlidXRlIG9mIHRoZQ0KPiByb3V0ZQ0KPiA+ID4gdG8gYW4NCj4gPiA+ ID4gPj4gICAgSVAgYWRkcmVzcyBvZiB0aGUgUm91dGUgUmVmbGVjdG9yLiINCj4gPiA+ID4gPj4N Cj4gPiA+ID4gPj4gV2hpY2gsIGluIGZhY3QsIGRvZXNuw6LigqzihKJ0IHJlZHVjZSByb3V0aW5n IGNodXJuLg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSW5jb3JyZWN0LiBUaGUg dGV4dCB5b3UgcXVvdGVkICpkb2VzKiByZWR1Y2Ugcm91dGluZyBjaHVybiBkdWUNCj4gdG8NCj4g PiA+ID4gPiBDLW11bHRpY2FzdCByb3V0ZSBjaGFuZ2VzLiBUaGlzIGlzIGJlY2F1c2UgaXQgZW5z dXJlcyB0aGF0IGENCj4gUm91dGUNCj4gPiA+ID4gPiBSZWZsZWN0b3IgYWR2ZXJ0aXNlcyBhIEMt bXVsdGljYXN0IHJvdXRlLCBmb3IgYSBnaXZlbiAoQy1TLyosDQo+IEMtRykNCj4gPiA+IG9ubHkN Cj4gPiA+ID4gPiB3aGVuIGl0IHJlY2VpdmVzIHRoZSBmaXJzdCByb3V0ZSBmb3IgdGhlIChDLVMv Ki4gQy1HKSBmcm9tIGENCj4gPiA+IGNsaWVudC4gSXQNCj4gPiA+ID4gPiBhbHNvIGVuc3VyZXMg dGhhdCBhIFJvdXRlIFJlZmxlY3RvciBkb2Vzbid0IHdpdGhkcmF3IGEgQy0NCj4gbXVsdGljYXN0 DQo+ID4gPiByb3V0ZQ0KPiA+ID4gPiA+IGZvciBhIGdpdmVuIChDLVMvKiwgQy1HKSBhcyBsb25n IGFzIGl0IGhhcyBhdCBsZWFzdCBvbmUgcm91dGUNCj4gZnJvbQ0KPiA+ID4gYQ0KPiA+ID4gPiA+ IGNsaWVudCBmb3IgdGhlIChDLVMvKiwgQy1HKS4NCj4gPiA+ID4NCj4gPiA+ID4gSW5jb3JyZWN0 Lg0KPiA+ID4gPg0KPiA+ID4gPiBBcyBNYXJpYSBoYXZlIHNhaWQgY29ycmVjdGx5ICp0aGUqIHF1 b3RlZCB0ZXh0IGRvZXMgbm90IHJlZHVjZQ0KPiA+ID4gcm91dGluZw0KPiA+ID4gPiBjaHVybi4N Cj4gPiA+ID4NCj4gPiA+ID4gVGhlIHByb2NlZHVyZSB5b3UgYXJlIHNwZWxsaW5nIG91dCBhcmUg bm90IHJlZmxlY3RlZCBpbiB0aGUgYWJvdmUNCj4gPiA+ID4gcGFyYWdyYXBoLiBBdCBsZWFzdCBu b3QgaW4gdmVyc2lvbiA4IG9mIHRoZQ0KPiA+ID4gPiBkcmFmdC1pZXRmLWwzdnBuLTI1NDdiaXMt bWNhc3QtYmdwLg0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+IFRoYXQgaXMgYW4gaW5jb3JyZWN0IGlu dGVycHJldGF0aW9uIG9mIHRoZSB0ZXh0IGluIHNlY3Rpb24gMTEuNC4NCj4gVGhlDQo+ID4gPiBw cm9jZWR1cmUgSSBzcGVsbGVkIG91dCBmb2xsb3dzIGZyb20gdGhlIHRleHQgaW4gc2VjdGlvbiAx MS40Lg0KPiA+ID4NCj4gPiA+DQo+ID4gPiByYWh1bA0KPiA+DQo+ID4NCg== From erosen@cisco.com Wed Dec 23 08:03:55 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 182E53A699A for ; Wed, 23 Dec 2009 08:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 bxuOx1xlTqcK for ; Wed, 23 Dec 2009 08:03:54 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E6DB53A6897 for ; Wed, 23 Dec 2009 08:03:53 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,442,1257120000"; d="scan'208";a="76259713" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Dec 2009 16:03:34 +0000 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 nBNG3Ykx015983; Wed, 23 Dec 2009 16:03:34 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 nBNG3VNV001989; Wed, 23 Dec 2009 11:03:31 -0500 To: Yakov Rekhter Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 In-reply-to: Your message of Tue, 15 Dec 2009 08:55:39 -0800. <200912151655.nBFGtdj27964@magenta.juniper.net> Date: Wed, 23 Dec 2009 11:03:31 -0500 Message-ID: <1988.1261584211@erosen-linux> From: Eric Rosen Cc: erosen@cisco.com, Thomas Morin , 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: Wed, 23 Dec 2009 16:03:55 -0000 Yakov> By virtue of being non-segmented, non-segmented S-PMSIs do *not* Yakov> provide the ability to aggregate P-tunnels of the intra-AS *segments* Yakov> of S-PMSIs (for one thing, non-segmented S-PMSIs do not have "intra-AS Yakov> segments"). Well, by that logic one could say that non-segmented S-PMSIs are more scalable on the grounds that they require fewer segments ;-) This would fit right in with the logic of Appendix A ;-) Note that there are Carrier's Carrier techniques that can be used to aggregate S-PMSIs through a transit AS when the S-PMSIs are not segmented. Eric> a downstream provider can use I-PMSIs even if an upstream provider Eric> uses S-PMSIs. That may or may not be a useful feature, but it doesn't Eric> make the use of S-PMSIs more scalable. Yakov> Sure it does. I can't wait to see the multi-provider deployment in which one provider decides to improve scale by using I-PMSIs and the other provider decides to improve scale by using S-PMSIs ;-) From erosen@cisco.com Wed Dec 23 11:31:34 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 A0CA63A6A06 for ; Wed, 23 Dec 2009 11:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 Z5Eiby0FHOOD for ; Wed, 23 Dec 2009 11:31:33 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A333D3A685E for ; Wed, 23 Dec 2009 11:31:33 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.47,444,1257120000"; d="scan'208";a="76302624" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Dec 2009 19:31:13 +0000 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 nBNJVDsg004750; Wed, 23 Dec 2009 19:31: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 nBNJVBBx014292; Wed, 23 Dec 2009 14:31:11 -0500 To: Rahul Aggarwal Subject: Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /sectionA.1.1.3 In-reply-to: Your message of Tue, 22 Dec 2009 15:03:31 -0800. <20091222144315.T2504@sapphire.juniper.net> Date: Wed, 23 Dec 2009 14:31:11 -0500 Message-ID: <14291.1261596671@erosen-linux> From: Eric Rosen Cc: Robert Raszuk , Thomas Morin , 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: Wed, 23 Dec 2009 19:48:37 -0000 > As specified in section 11.4 the Route Reflector advertises an aggregated > C-multicast route. Well, section 11.4 says: C-multicast routes are "de facto" aggregated by BGP. This is because the MCAST-VPN NLRIs advertised by multiple PEs, for a C- multicast route for a particular C-S and C-G (or a particular C-* and C-G) of a given MVPN are identical. The use of "de facto" means that no new procedures are required, and that the "aggregation" is the same as BGP automatically does in all cases where two different routes have the same NLRI. It is a very creative interpretation to suggest this requires the RR to originate a new route rather than to distribute a route received from a PE. > two vendors with an inter-operable implementation have had no > trouble interpreting section 11.4 Note that different interpretations of section 11.4 will still interoperate. It's a bit odd to say that no one has had trouble interpreting it when at the same time you're telling folks that they are misinterpreting it ;-) I think what we're really talking about here is an implementation optimization that is interesting, but that is not required for interoperability, and that might or might not be worth doing. Ordinarily, this sort of optimization would be considered to be a local matter, not something about which there has to be WG consensus. It's only the presence of Appendix A that forces us to get bogged down in unproductive discussions of such details, as we now have to argue about whether the so-called analysis there is to be based only on what the specifications require or also on what implementations are likely to do. From mn1921@att.com Thu Dec 24 06:56:58 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE1A3A69F4 for ; Thu, 24 Dec 2009 06:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 Xxdj1hSbIaOo for ; Thu, 24 Dec 2009 06:56:57 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 449893A69E5 for ; Thu, 24 Dec 2009 06:56:56 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mn1921@att.com X-Msg-Ref: server-3.tower-146.messagelabs.com!1261666595!8078878!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 32672 invoked from network); 24 Dec 2009 14:56:36 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Dec 2009 14:56:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBOEuZJX007005; Thu, 24 Dec 2009 09:56:35 -0500 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBOEuUmf006965; Thu, 24 Dec 2009 09:56:30 -0500 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: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /sectionA.1.1.3 Date: Thu, 24 Dec 2009 09:56:31 -0500 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200463371C@misout7msgusr7e.ugd.att.com> In-Reply-To: <14291.1261596671@erosen-linux> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A /sectionA.1.1.3 Thread-Index: AcqEBoE679mG8MeUSzyMDp4OxehK1gAom9HQ References: Your message of Tue, 22 Dec 2009 15:03:31 -0800. <20091222144315.T2504@sapphire.juniper.net> <14291.1261596671@erosen-linux> From: "NAPIERALA, MARIA H (ATTLABS)" To: , "Rahul Aggarwal" Cc: Robert Raszuk , Thomas Morin , 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: Thu, 24 Dec 2009 14:56:58 -0000 > It's only the presence > of Appendix A that forces us to get bogged down in unproductive discussions > of such details, as we now have to argue about whether the so-called > analysis there is to be based only on what the specifications require > or also on what implementations are likely to do. =20 Ditto! Maria