From erosen@cisco.com Mon Mar 4 11:58:09 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A90C21F8F16 for ; Mon, 4 Mar 2013 11:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Asa+2Y9A+fip for ; Mon, 4 Mar 2013 11:58:08 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8E821F8F15 for ; Mon, 4 Mar 2013 11:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13685; q=dns/txt; s=iport; t=1362427087; x=1363636687; h=to:subject:reply-to:date:message-id:from; bh=6D80Cnh4FSuBRWwNSvusTAjG9SfGVBNcfgjFEO+2tyY=; b=TpDKCtoqb+k2ojZqO4DGf7SWRDWGeKgPhl021VtwbXXTAk4hVKoBn4a4 V7ueWgmn6TIouYxVkPHhAcZjDqfVNpFr/ZN6ulOZ+VtPOyUqiLyzvn8Z2 N8jEKgsqfRg5tHCEgvofg1HTCPwiKf7XLgkEwLmuBJ05ncy6Y+hvf9aL5 o=; X-IronPort-AV: E=Sophos;i="4.84,781,1355097600"; d="scan'208";a="12235884" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 04 Mar 2013 19:58:06 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r24Jw5Yj028180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Mar 2013 19:58:05 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r24Jw4aS004997; Mon, 4 Mar 2013 14:58:04 -0500 To: L3VPN Subject: comments on draft-zzhang-mboned-mvpn-global-table-mcast-00.txt Date: Mon, 04 Mar 2013 14:58:04 -0500 Message-ID: <4996.1362427084@erosen-linux> From: Eric Rosen X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 19:58:09 -0000 This draft proposes to use BGP-MVPN procedures to support "Global Table Multicast" (GTM). I fully support this, but I have some questions and comments on the draft. Although the draft name contains "mboned" and not "l3vpn", the L3VPN WG seems like the best place to have a detailed discussion of a draft that makes use of MVPN procedures. - The procedures given in this draft for GTM differ from the procedures for GTM that are provided in draft-ietf-mpls-seamless-mcast-06.txt. There should be some text explicitly pointing this out, and the seamless-mcast draft should be listed in the Informative References section. Further, the mvpn-global-table-mcast should make it clear whether it is being offered as a replacement for the GTM part of the seamless-mcast draft, or whether it is being offered as another possible option. - Assuming that the procedures in the mvpn-global-table-mcast draft are being offered as another possible option, the question arises as to whether the two options can co-exist in the same backbone network. This should be addressed in the draft. I think the answer is that the two procedures can co-exist, as long as it is made clear (somehow) which option is to be used for which ASM groups, and which option is to be used for which (S,G) SSM flows. The two options make different uses of the Leaf A-D routes, but it is always possible to tell from the NLRI of a Leaf A-D route which set of procedures governs the use of that particular Leaf A-D route. This should be mentioned. - In the MVPN procedures, VRFs are configured with import and export RTs. The I-PMSI A-D routes, S-PMSI A-D routes, and Source Active A-D routes carry at least some of the export RTs of the VRFs from which they are originated, following rules laid out in RFC 6514. The draft doesn't talk about this at all, and it's not clear whether or not it is expected that the global tables will have import and export RTs. Is it required that the I-PMSI, S-PMSI, and Source Active A-D routes originated from the global table will carry RTs, and that these RTs will constrain the distribution of the routes? If not required, is it prohibited, or is it optional? If there are no RTs, how does a "BR" (the term used by the draft to mean, roughly, "PE") know whether a particular A-D route needs to be imported into its global table? Or does every global table have to import every I-PMSI, S-PMSI, and Source Active A-D route that has no RTs? I think this has to be addressed explicitly, as I don't think the answers are determined by just saying "use the MVPN procedures". - The draft does seem to assume that a BR will originate an Intra-AS I-PMSI A-D route for the global table, if that BR plays the role of "ingress PE". This raises the question of whether it is allowable to include a PMSI Tunnel attribute in these routes. If an Intra-AS I-PMSI A-D route specifies an inclusive P-tunnel, every BR in the network that can play the role of "egress PE" for GTM needs to join that inclusive P-tunnel, whether or not it is interested in receiving any multicast data from the originator of the route. I'm not sure if this is a good idea in the context of GTM. There may be different points of view about whether the use of inclusive tunnels make sense for GTM, but the draft should certainly call attention to this issue. One could also ask whether Intra-AS I-PMSI A-D routes are really needed for GTM at all. - Unless it is the intention to disallow the use of wildcard S-PMSI A-D routes, RFC 6625 should be added to the list of normative references, and it would be a good idea to at least mention that wildcard S-PMSI A-D routes may be used for GTM. - The claim is made that "With Global Table Multicast implemented by BGP-MVPN procedures, all the features/characteristics of BGP-MVPN apply, including ... support for PIM-DM ... BSR and AUTO-RP as RP-to-group mapping protocols". I don't believe that MVPN supports PIM-DM; RFC 6513 declares support for PIM-DM to be outside its scope. I don't think the MVPN RFCs mention Auto-RP at all. - The MVPN specs distinguish between the "Upstream Multicast Hop" (UMH) and the "Upstream PE". The draft doesn't stick to the terminology of the MVPN specs, but instead uses the term "RPF route", which is never actually defined. In some cases, the term "RPF route" seems to mean what RFCs 6513 and 6625 call a "UMH-eligible route". But the draft often doesn't seem to distinguish between the UMH and the Upstream PE. In particular, some of the new procedures specified in section 3.2 seem to work only if the UMH and the Upstream PE are the same (see below), even though this is not generally the case. I think it would be better to stick to the terminology of the MVPN specs, and to avoid terms like "RPF route" that are not precisely defined. - The draft does not actually say anywhere that a BR SHOULD attach a VRF Route Import extended community and a Source AS extended community to the UMH-eligible routes that it originates from the global table. While one could say that this falls under the category of "just use the MVPN procedures", it would be better to mention this explicitly. - With regard to the statement: "By default, RD 0:0 is used when advertising A-D routes for Global Table Multicast, though an implementation MAY support the configuration and use of a different RD value." * "RD 0:0" is not a notation defined in any RFC. I assume it means "RD whose value is 64 bits of zero", but it would be better to say that. * When you say "MAY support the configuration and use of a different RD value", please specify whether you mean "each BR may use a unique RD value for its global table", or "all BRs must use the same RD value for their global tables, but it can be configured to be other than zero." It would also be worth discussing whether there is any possible advantage to using an RD other than zero. - It should be pointed out that the MVPN procedures for Single Forwarder Selection will not work for GTM, as those procedures presuppose that every VRF has a unique RD, and that this RD is part of the NLRI of the "UMH-eligible" routes. In GTM, the UMH-eligible routes are will be of AFI/SAFI 1/1, 2/1, 1/2,or 2/2, and these routes do not have RTs. This means that GTM can only be supported on platforms that can implement the procedures of RFC 6513 section 9.1.1 (label-based RPF check). - With regard to the following paragraph from section 3.1: In the simple reference scenario above, it is assumed that the BRs learn RPF routes from non-BRs via eBGP or IGP. The assumption is to illustrate the analogy to a true VPN environment. In another deployment scenario, the BRs could have learned the RPF routes over those iBGP sessions to non-BRs. If the BRs act as RRs and reflect the RPF routes to other BRs with polices to attach VRF Route Import Extended Community and Source AS Extended Community, BGP-MVPN procedures can still be used as described earlier. I don't really get the point here. The protocol by which the non-BR advertises routes to the BR doesn't seem relevant at all; whatever the protocol is, the BR should attach the extended communities when it redistributes the routes via BGP. In any case, I would avoid the phrase "act as an RR"; this phrase is not well-defined. - I'm not sure I understand the use case scenario of section 3.2: There is a full-mesh of IBGP sessions among provider routers GW1/BR1/BR2/GW2. EBGP sessions run between CPE1/GW1 and between CPE2/GW2. Border routers BR1/BR2 run BGP-MVPN procedures for Global Table Multicast. GW1 learns of BGP route to the src from CPE1 and advertises it to BRx/GW2. In this scenario, is GW1 putting itself in as the next hop of the route to "src"? If not, what is the next hop? Because GW1 does not run MVPN, BR2's route to the src (learned from GW1 instead of BR1) does not have the VRF Route Import Extended Community. Therefore, it would not be able to correctly attach a Route Target Extended Community corresponding to BR1 in its C-Multicast Routes. In this scenario, is there an assumption that the data path from BR2 to GW1 passes through BR1? This is not stated, and is not indicated in the diagram, but otherwise I don't see why BR2's C-multicast routes should be targeted to BR1. But if the data path from BR2 to GW1 passes through BR1, why is GW1 telling BR2 that GW1 itself is the next hop? It would help if the diagram distinguished the physical connections from the BGP sessions. If the unicast data path between GW1 and BR2 does not pass through BR1, but one wants the multicast data path between GW1 and BR2 to pass through BR1, the most obvious solution is to have BR1 originate SAFI-2 routes whose NLRIs match the addresses of the multicast sources behind GW1. Although this isn't mentioned, it seems like a viable option that (a) avoids the need to modify the UMH selection procedures and (b) doesn't depend on or affect the unicast routing. - Section 3.2 proposes a modified procedure for determining the Upstream PE (which would be the "ingress BR" in the terminology of this draft), given a route to the multicast source: o If the route is a BGP route with a VRF Route Import Extended Community, that VRF Route Import Extended Community is used. o If the route is a BGP route without a VRF Route Import Extended Community, get the route to the Next Hop and recurse. I don't understand this second step. Only routes to multicast sources have the extended community. So even if the next hop is itself the ingress BR (i.e., if all the BRs are in the same AS), I don't see how this will work, because MVPN procedures do not require an ingress PE to originate a route to itself with a VRF Route Import extended community attached. (One could make that a requirement, but I don't see it in the draft, and that would certainly be a modification of the MVPN procedures.) In any case, the next hop is not necessarily the ingress BR; the next hop may be an ASBR that is along the path to the ingress BR. Since that ASBR may also be along the path to other ingress BRs, the route to the next hop cannot be carrying a VRF Route Import extended community that identifies any particular ingress BR. o If the route is an IGP route with a RSVP-TE LSP as next hop, and the LSP endpoint is a BR that advertises an Intra-AS I-PMSI A-D route (BR1 in the above example), a VRF Route Import Extended Community is constructed as BR_addr:0 to be associated with the RPF route, where the BR_addr is the Originating Router's IP Address of the Intra-AS I-PMSI A-D route. This will not give the correct result unless the BRs are all in the same IGP domain and are connected through a full mesh of RSVP-TE LSPs. And the final step of the new procedure: If the above procedure does not produce a usable VRF Route Import Extended Community, then the RPF route is considered a local route (vs. a remote route that is associated with a remote BR). If the next hop is not a BR, presumably it's a system that plays the role of an MVPN CE, and it has to be sent a PIM Join rather than a BGP C-multicast Join. However, a BR generally knows which of its interfaces are customer-facing rather than core-facing, and should not sent PIM Joins out its core-facing interfaces. But there are conditions under which the above procedures will cause that to happen. Perhaps the procedures of section 3.2 are intended to have restricted applicability, e.g., only applicable when the "core" contains a single AS or consists of a full mesh of RSVP-TE tunnels. In that case, the draft should clearly state the applicability restrictions. - If there is discussion of modifying the procedure for selecting the UMH, there should be some discussion of whether the procedures in this draft can be used together with the P-tunnel segmentation procedures of draft-ietf-mpls-seamless-mcast. - I can't agree with the statement in the abstract that "no protocol modification/extension is required". While the draft does not define new messages or TLVs, it does specify and/or presuppose procedures that are specific to the case of global table multicast. For instance: * the procedures for selecting the RD to be placed in the I-PMSI, S-PMSI, and Source Active A-D routes are different than the MVPN procedures; * the procedures for deciding which RTs to attach to routes other than C-multicast routes and Leaf A-D routes are not discussed in this draft, but they should be, and I don't see how they can be exactly the same as the MVPN procedures; * the procedure for determining the upstream PE is not the same as the MVPN procedure. These are protocol modifications/extensions, and need to be addressed in a standards track document. From rraszuk@gmail.com Sun Mar 10 21:52:29 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E34121F86C4 for ; Sun, 10 Mar 2013 21:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIY54TCOdtMO for ; Sun, 10 Mar 2013 21:52:28 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 368F921F84CD for ; Sun, 10 Mar 2013 21:52:28 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id bn7so4206538ieb.25 for ; Sun, 10 Mar 2013 21:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=JeEmtcteIcSh/9UDOXvERIv++wVxUFhA9Bbr6RUg788=; b=qk10qTjXlzxi3PVU7nytIDnYkIubPJlJlttJsDajDmdYTPDUF8b9K2LDPIqoHJ+rCQ QNv5CXu6+TJHyUVrT2csTi2v7OyXtHiPYQIwtXeAxo/BG5yrkEKD2g5gwmbbz8ReO5T3 JOmL3mttPdfbTPsc3UrIBdy8FYJM9KwLGo4Oj72Uag1uf4yTtNsVjHfLLa5hlI7wyIpQ tEUWyUtpAtbDQ0JsfbhxQM0seZJqcm2tnXa1bol6SP3xiCxYJteBvcg3QlQxd4JTEAp7 ksvTgMS1Q85jMDkHM02ewHscyO0+NJSa9ypt2HLmNpShkCYire9zK76w54sGpezF2rVQ nrbw== MIME-Version: 1.0 X-Received: by 10.50.47.200 with SMTP id f8mr6008451ign.98.1362977547846; Sun, 10 Mar 2013 21:52:27 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Sun, 10 Mar 2013 21:52:27 -0700 (PDT) Date: Mon, 11 Mar 2013 05:52:27 +0100 X-Google-Sender-Auth: fNx4y38lfRYb_lZvgblf28zuT5A Message-ID: Subject: draft-fang-l3vpn-data-center-interconnect-00 From: Robert Raszuk To: L3VPN Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 04:52:29 -0000 Hi, Reading through draft-fang-l3vpn-data-center-interconnect-00 I would like to clarify one points and comment on section 4.1.2. Abstract says: New Inter-AS solutions are required in certain scenarios, in addition to the existing Inter-AS Options (A, B, C) defined in [RFC4364]. Question: Where in the draft there is any reference to the proposed new "new inter-as solutions" ? In section 4.1.2 the draft says: Cons: vanilla version of Option B is considered less secure in comparision with Option A, due to dynimic routing information exchange is involved. The ASBR scaling may still be issues because ASBR must maintain all VPN routes. ... DCI consideration: Option B is one viable option to be used in DC inter-connection. But it has the same scale concerns as other options on potential large number of routes exchange between WAN and DC. Comment: All of the above cons can be already solved by RFC 4684 (RTC) and RFC 6769 (simple-va). Note that draft-ietf-l3vpn-virtual-hub-04 is also applicable in parallel or in addition to RFC 6769 to help with the potential scaling issue of ASBR option B. -- Overall question ... Can authors clarify what is the point of this draft other then stating obvious ? Best, R. From zzhang@juniper.net Wed Mar 13 15:55:14 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FEB21F8540 for ; Wed, 13 Mar 2013 15:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWM2-8AWUoeD for ; Wed, 13 Mar 2013 15:55:13 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 741FC21F84EF for ; Wed, 13 Mar 2013 15:55:11 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUUEDzn9aPIRubwRpgkL3boZg/dty2333@postini.com; Wed, 13 Mar 2013 15:55:11 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 13 Mar 2013 15:51:13 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 13 Mar 2013 15:51:13 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.187) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 13 Mar 2013 15:53:48 -0700 Received: from mail162-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Mar 2013 22:51:13 +0000 Received: from mail162-co1 (localhost [127.0.0.1]) by mail162-co1-R.bigfish.com (Postfix) with ESMTP id 139293001EB for ; Wed, 13 Mar 2013 22:51:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -13 X-BigFish: PS-13(zz709fI9371I146fI148cI542Iec9N1432I11fbIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail162-co1 (localhost.localdomain [127.0.0.1]) by mail162-co1 (MessageSwitch) id 1363215070858735_16002; Wed, 13 Mar 2013 22:51:10 +0000 (UTC) Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.238]) by mail162-co1.bigfish.com (Postfix) with ESMTP id CF72F1C007E; Wed, 13 Mar 2013 22:51:10 +0000 (UTC) Received: from BY2PRD0510HT001.namprd05.prod.outlook.com (157.56.236.101) by CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 13 Mar 2013 22:51:10 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.54]) by BY2PRD0510HT001.namprd05.prod.outlook.com ([10.255.84.36]) with mapi id 14.16.0275.006; Wed, 13 Mar 2013 22:51:03 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Eric Rosen , "l3vpn@ietf.org" Subject: RE: comments on draft-zzhang-mboned-mvpn-global-table-mcast-00.txt Thread-Topic: comments on draft-zzhang-mboned-mvpn-global-table-mcast-00.txt Thread-Index: AQHOGRMAS3fjr4nQZU2qDG+ZI0fr/piWA0yg Date: Wed, 13 Mar 2013 22:51:02 +0000 Message-ID: <0BF0FCC78340F147BE76A6F5762318A82F948137@BY2PRD0510MB389.namprd05.prod.outlook.com> References: <4996.1362427084@erosen-linux> In-Reply-To: <4996.1362427084@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 22:55:14 -0000 Eric, Thanks for your close review and detailed comments. Please see below. > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Monday, March 04, 2013 2:58 PM > To: L3VPN > Subject: comments on draft-zzhang-mboned-mvpn-global-table-mcast-00.txt >=20 > This draft proposes to use BGP-MVPN procedures to support "Global Table > Multicast" (GTM). I fully support this, but I have some questions and > comments on the draft. Although the draft name contains "mboned" and not > "l3vpn", the L3VPN WG seems like the best place to have a detailed > discussion of a draft that makes use of MVPN procedures. Good to have your support! I originally thought this would go to Mboned, but after thinking about=20 this further, I think L3VPN is the more appropriate WG for this document. >=20 > - The procedures given in this draft for GTM differ from the procedures f= or > GTM that are provided in draft-ietf-mpls-seamless-mcast-06.txt. There > should be some text explicitly pointing this out, and the seamless-mcas= t > draft should be listed in the Informative References section. Further, > the mvpn-global-table-mcast should make it clear whether it is being > offered as a replacement for the GTM part of the seamless-mcast draft, = or > whether it is being offered as another possible option. I will clarify in the next revision that it is different from the other dra= ft, and it is being offered as another possible option. >=20 > - Assuming that the procedures in the mvpn-global-table-mcast draft are > being offered as another possible option, the question arises as to > whether the two options can co-exist in the same backbone network. This > should be addressed in the draft. I think the answer is that the two > procedures can co-exist, as long as it is made clear (somehow) which > option is to be used for which ASM groups, and which option is to be us= ed > for which (S,G) SSM flows. >=20 > The two options make different uses of the Leaf A-D routes, but it is > always possible to tell from the NLRI of a Leaf A-D route which set of > procedures governs the use of that particular Leaf A-D route. This sho= uld > be mentioned. The two options can co-exist. We will spell this out in the next version of= the draft. >=20 > - In the MVPN procedures, VRFs are configured with import and export RTs. > The I-PMSI A-D routes, S-PMSI A-D routes, and Source Active A-D routes > carry at least some of the export RTs of the VRFs from which they are > originated, following rules laid out in RFC 6514. >=20 > The draft doesn't talk about this at all, and it's not clear whether or > not it is expected that the global tables will have import and export > RTs. >=20 > Is it required that the I-PMSI, S-PMSI, and Source Active A-D routes > originated from the global table will carry RTs, and that these RTs wil= l > constrain the distribution of the routes? If not required, is it > prohibited, or is it optional? If there are no RTs, how does a "BR" (t= he > term used by the draft to mean, roughly, "PE") know whether a particula= r > A-D route needs to be imported into its global table? Or does every > global table have to import every I-PMSI, S-PMSI, and Source Active A-D > route that has no RTs? >=20 > I think this has to be addressed explicitly, as I don't think the answe= rs > are determined by just saying "use the MVPN procedures". Thanks for pointing it out. Yes I will clarify that import/export RTs are u= sed for those I/S-PMSI and SA A-D routes. >=20 > - The draft does seem to assume that a BR will originate an Intra-AS I-PM= SI > A-D route for the global table, if that BR plays the role of "ingress P= E". A BR may originate an intra-AS I-PMSI A-D route for the global table but it= is not required, just like in rfc6513/6514/6625. > This raises the question of whether it is allowable to include a PMSI > Tunnel attribute in these routes. If an Intra-AS I-PMSI A-D route > specifies an inclusive P-tunnel, every BR in the network that can play = the > role of "egress PE" for GTM needs to join that inclusive P-tunnel, whet= her > or not it is interested in receiving any multicast data from the > originator of the route. I'm not sure if this is a good idea in the > context of GTM. >=20 > There may be different points of view about whether the use of inclusiv= e > tunnels make sense for GTM, but the draft should certainly call attenti= on > to this issue. >=20 > One could also ask whether Intra-AS I-PMSI A-D routes are really needed > for GTM at all. As mentioned above, use of intra-AS I-PMSI A-D routes is optional. >=20 > - Unless it is the intention to disallow the use of wildcard S-PMSI A-D > routes, RFC 6625 should be added to the list of normative references, a= nd > it would be a good idea to at least mention that wildcard S-PMSI A-D > routes may be used for GTM. Good point. I'll point out that wildcard S-PMSI is applicable and add 6625 = to the reference list. >=20 > - The claim is made that "With Global Table Multicast implemented by > BGP-MVPN procedures, all the features/characteristics of BGP-MVPN apply= , > including ... support for PIM-DM ... BSR and AUTO-RP as RP-to-group > mapping protocols". >=20 > I don't believe that MVPN supports PIM-DM; RFC 6513 declares support fo= r > PIM-DM to be outside its scope. I don't think the MVPN RFCs mention > Auto-RP at all. I will replace the text with the following: With Global Table Multicast implemented by BGP-MVPN procedures, all the features/characteristics of BGP-MVPN apply, including scaling, aggregation, flexible choice of provider tunnels, support for=20 ASM/SSM/Bidir as PE-CE multicast protocol, support for unsolicited flooded data, including support for BSR as RP-to-group mapping=20 protocols, etc. >=20 > - The MVPN specs distinguish between the "Upstream Multicast Hop" (UMH) a= nd > the "Upstream PE". The draft doesn't stick to the terminology of the M= VPN > specs, but instead uses the term "RPF route", which is never actually > defined. In some cases, the term "RPF route" seems to mean what RFCs 6= 513 > and 6625 call a "UMH-eligible route". But the draft often doesn't seem= to > distinguish between the UMH and the Upstream PE. In particular, some o= f > the new procedures specified in section 3.2 seem to work only if the UM= H > and the Upstream PE are the same (see below), even though this is not > generally the case. >=20 > I think it would be better to stick to the terminology of the MVPN spec= s, > and to avoid terms like "RPF route" that are not precisely defined. Sure. I'll fix it in the next revision. >=20 > - The draft does not actually say anywhere that a BR SHOULD attach a VRF > Route Import extended community and a Source AS extended community to t= he > UMH-eligible routes that it originates from the global table. While on= e > could say that this falls under the category of "just use the MVPN > procedures", it would be better to mention this explicitly. I'll mention it explicitly. =09 >=20 > - With regard to the statement: >=20 > "By default, RD 0:0 is used when advertising A-D routes for Globa= l > Table Multicast, though an implementation MAY support the > configuration and use of a different RD value." >=20 > * "RD 0:0" is not a notation defined in any RFC. I assume it means "R= D > whose value is 64 bits of zero", but it would be better to say that. Thanks for pointing that out. Will fix it. >=20 > * When you say "MAY support the configuration and use of a different R= D > value", please specify whether you mean "each BR may use a unique RD > value for its global table", or "all BRs must use the same RD value = for > their global tables, but it can be configured to be other than zero.= " > It would also be worth discussing whether there is any possible adva= ntage > to using an RD other than zero. I'll clarify that it means "each BR may use a unique RD value for its globa= l table". >=20 > - It should be pointed out that the MVPN procedures for Single Forwarder > Selection will not work for GTM, as those procedures presuppose that ev= ery > VRF has a unique RD, and that this RD is part of the NLRI of the > "UMH-eligible" routes. In GTM, the UMH-eligible routes are will be of > AFI/SAFI 1/1, 2/1, 1/2,or 2/2, and these routes do not have RTs. This > means that GTM can only be supported on platforms that can implement th= e > procedures of RFC 6513 section 9.1.1 (label-based RPF check). To be more precise, Single Forwarder Selection can still work for GTM if BG= P Add-Path is used, which allows to propagate multiple UMH-eligible routes = for the same prefix - that should allow Single Forwarder Selection to work. I will clarify that. >=20 > - With regard to the following paragraph from section 3.1: >=20 > In the simple reference scenario above, it is assumed that the BR= s > learn RPF routes from non-BRs via eBGP or IGP. The assumption is= to > illustrate the analogy to a true VPN environment. In another > deployment scenario, the BRs could have learned the RPF routes ov= er > those iBGP sessions to non-BRs. If the BRs act as RRs and reflec= t > the RPF routes to other BRs with polices to attach VRF Route Impo= rt > Extended Community and Source AS Extended Community, BGP-MVPN > procedures can still be used as described earlier. >=20 > I don't really get the point here. The protocol by which the non-BR > advertises routes to the BR doesn't seem relevant at all; whatever the > protocol is, the BR should attach the extended communities when it > redistributes the routes via BGP. You're correct that BRs should attach the ECs. The reason the doc was struc= tured as quoted above is that, there was a comment that in a true VPN envir= onment you'd not have iBGP between PE-CE unless it is the situation as docu= mented in RFC 636. Since this doc is basically saying "use BGP-MVPN protoco= l/procedure", it is good to point out in that case either BRs act as RRs an= d attach the extended communities via policy, or follow the 6368 procedures= . >=20 > In any case, I would avoid the phrase "act as an RR"; this phrase is no= t > well-defined. draft-ietf-mpls-seamless-mcast-06 has "acting as Route Reflectors" :-) Anyw= ay, I'll change it to "BRs are Route Reflectors". >=20 > - I'm not sure I understand the use case scenario of section 3.2: >=20 > There is a full-mesh of IBGP sessions among provider routers > GW1/BR1/BR2/GW2. EBGP sessions run between CPE1/GW1 and between > CPE2/GW2. Border routers BR1/BR2 run BGP-MVPN procedures for Glo= bal > Table Multicast. GW1 learns of BGP route to the src from CPE1 an= d > advertises it to BRx/GW2. >=20 > In this scenario, is GW1 putting itself in as the next hop of the rout= e > to "src"? If not, what is the next hop? Yes it put itself as the next hop. >=20 > Because GW1 does not run MVPN, BR2's route to the src (learned fr= om > GW1 instead of BR1) does not have the VRF Route Import Extended > Community. Therefore, it would not be able to correctly attach a > Route Target Extended Community corresponding to BR1 in its > C-Multicast Routes. >=20 > In this scenario, is there an assumption that the data path from BR2 = to > GW1 passes through BR1? This is not stated, and is not indicated in = the > diagram, but otherwise I don't see why BR2's C-multicast routes shoul= d > be targeted to BR1. For multicast, all traffic has to go through the BRs. >=20 > But if the data path from BR2 to GW1 passes through BR1, why is GW1 > telling BR2 that GW1 itself is the next hop? Multicast traffic has to go through the BRs but the unicast not necessarily= . GW1 is simply advertising itself as the "protocol nexthop" for unicast. >=20 > It would help if the diagram distinguished the physical connections f= rom > the BGP sessions. Sure. Will come up with a better picture. >=20 > If the unicast data path between GW1 and BR2 does not pass through BR= 1, > but one wants the multicast data path between GW1 and BR2 to pass > through BR1, the most obvious solution is to have BR1 originate SAFI-= 2 > routes whose NLRIs match the addresses of the multicast sources behin= d > GW1. Although this isn't mentioned, it seems like a viable option th= at > (a) avoids the need to modify the UMH selection procedures and (b) > doesn't depend on or affect the unicast routing. The scenario is indeed a bit special. With enough tweaking in the UMH selec= tion procedures we can make it work w/o originating SAFI-2 routes, so it wa= s included. Note that even if the UMH routes are not distributed by BGP at = all, the procedure could still work. We can get input from WG on if such scenario is worth supporting. If not, i= t can be taken out of scope. >=20 > - Section 3.2 proposes a modified procedure for determining the Upstream = PE > (which would be the "ingress BR" in the terminology of this draft), giv= en > a route to the multicast source: >=20 > o If the route is a BGP route with a VRF Route Import Extended > Community, that VRF Route Import Extended Community is used. >=20 > o If the route is a BGP route without a VRF Route Import Extended > Community, get the route to the Next Hop and recurse. >=20 > I don't understand this second step. Only routes to multicast sources > have the extended community. So even if the next hop is itself the > ingress BR (i.e., if all the BRs are in the same AS), I don't see how > this will work, because MVPN procedures do not require an ingress PE t= o > originate a route to itself with a VRF Route Import extended community > attached. (One could make that a requirement, but I don't see it in t= he > draft, and that would certainly be a modification of the MVPN > procedures.) It's not required; but if such a route does exist, then it can be used to m= ake that deployment scenario work. >=20 > In any case, the next hop is not necessarily the ingress BR; the next = hop > may be an ASBR that is along the path to the ingress BR. Since that A= SBR > may also be along the path to other ingress BRs, the route to the next > hop cannot be carrying a VRF Route Import extended community that > identifies any particular ingress BR. The idea is that if the ingress BR is on the path to the advertised next ho= p, then we can try to identify that ingress BR. >=20 > o If the route is an IGP route with a RSVP-TE LSP as next hop, an= d > the LSP endpoint is a BR that advertises an Intra-AS I-PMSI A-D > route (BR1 in the above example), a VRF Route Import Extended > Community is constructed as BR_addr:0 to be associated with the > RPF route, where the BR_addr is the Originating Router's IP > Address of the Intra-AS I-PMSI A-D route. >=20 > This will not give the correct result unless the BRs are all in the s= ame > IGP domain and are connected through a full mesh of RSVP-TE LSPs. Right. It does come with restrictions and we can take it out of the scope i= f the WG consensus is that it's not worth specifying. >=20 > And the final step of the new procedure: >=20 > If the above procedure does not produce a usable VRF Route Import > Extended Community, then the RPF route is considered a local rout= e > (vs. a remote route that is associated with a remote BR). >=20 > If the next hop is not a BR, presumably it's a system that plays the > role of an MVPN CE, and it has to be sent a PIM Join rather than a BG= P > C-multicast Join. However, a BR generally knows which of its interfa= ces > are customer-facing rather than core-facing, and should not sent PIM > Joins out its core-facing interfaces. But there are conditions under > which the above procedures will cause that to happen. >=20 > Perhaps the procedures of section 3.2 are intended to have restricted > applicability, e.g., only applicable when the "core" contains a singl= e > AS or consists of a full mesh of RSVP-TE tunnels. In that case, the > draft should clearly state the applicability restrictions. Yes I can clearly state that and even take it out of the scope. >=20 > - If there is discussion of modifying the procedure for selecting the UMH= , > there should be some discussion of whether the procedures in this draft > can be used together with the P-tunnel segmentation procedures of > draft-ietf-mpls-seamless-mcast. >=20 > - I can't agree with the statement in the abstract that "no protocol > modification/extension is required". While the draft does not define n= ew > messages or TLVs, it does specify and/or presuppose procedures that are > specific to the case of global table multicast. For instance: >=20 > * the procedures for selecting the RD to be placed in the I-PMSI, S-PMS= I, > and Source Active A-D routes are different than the MVPN procedures; I don't see the difference? Current MVPN only says use the RD for the VPN. = One can think that for the global table, there is an all-zero RD (or any ot= her unique RD). >=20 > * the procedures for deciding which RTs to attach to routes other than > C-multicast routes and Leaf A-D routes are not discussed in this draf= t, > but they should be, and I don't see how they can be exactly the same = as > the MVPN procedures; I will add text on that (using an all-zero RT, say RT 0:0); but I don't see= how they're different - current MVPN spec allows using configured RTs. One= can think that there is an (auto-configured) RT 0:0 for the global table. >=20 > * the procedure for determining the upstream PE is not the same as the > MVPN procedure. I will clarify that Single Forwarder Selection has its restrictions (not su= pported unless add-path is used), but I think it is still within the curren= t MVPN spec? >=20 > These are protocol modifications/extensions, and need to be addressed i= n a > standards track document. Modulo the special scenario, I don't think the two are that different, but = I'm fine with turning it to standards track. Thanks. Jeffrey=20 From rraszuk@gmail.com Thu Mar 14 12:31:23 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D489A11E80BF for ; Thu, 14 Mar 2013 12:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.452 X-Spam-Level: X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgrmZELALuJb for ; Thu, 14 Mar 2013 12:31:23 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7310011E81B5 for ; Thu, 14 Mar 2013 12:31:23 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id bn7so3436028ieb.39 for ; Thu, 14 Mar 2013 12:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=jxMHcUx+nMrXSUHBBKfZxPGHmJlRaf3Gng1o+xPXBim0ZXNGEvULnhpY8xtXgbCwte 37Q8LU24mx2h0jr65YPiVBZNuv7piFewKVtPOegp0HttOJ31J76/UL4/UzPZF1p759Xs sfqeXgah4mOr0IrE8PfDcDxo46+hh3S9nKhOZtGIeVH3wVQ6N/TDJc3AERJb+lez8XXt sTUtaIlAV8VR1DX/Lg/cc8Eyh6mwqoz0BU42qxflILEa13epQhBnJ4HFcpfr7efgst42 o/ZCysZ3xBEShHKD0ZPEbU0w45S+F7j2eZ5g4oYbCsBMfYnaw2KTth++3SsnBHLqE9wp ZebA== MIME-Version: 1.0 X-Received: by 10.50.5.180 with SMTP id t20mr21060636igt.80.1363289481177; Thu, 14 Mar 2013 12:31:21 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 12:31:21 -0700 (PDT) Date: Thu, 14 Mar 2013 20:31:21 +0100 X-Google-Sender-Auth: YojSpFbfrARxPrf4yI6f3B1yxhU Message-ID: Subject: Is the l3vpn WG meeting cancelled or moved to different room ? From: Robert Raszuk To: L3VPN Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:31:24 -0000 From erosen@cisco.com Thu Mar 21 08:10:48 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482DF21F9123 for ; Thu, 21 Mar 2013 08:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4auelZiZ0fhl for ; Thu, 21 Mar 2013 08:10:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1D76821F90FC for ; Thu, 21 Mar 2013 08:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8431; q=dns/txt; s=iport; t=1363878647; x=1365088247; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=w9bmNqByRftK8ZnDvS2mL3Ofukk6X0x0rW69PdQXm9Q=; b=DVs7ujy51jheJ6zRrxAvhbOZjUf2JtjhKmX+wpTQs1+0w5Dnp6IAHhwW 2NI9igs/6r7H67UJm3Jy/7h+iIdp2l5dTdcY2X5vaLC018RIkWhotK3z7 S1bSH+u0h+BvLIqHHCFyEL8aIIwra/6zFFWdi02NrZ4yYTLEhiwQXXdQ3 4=; X-IronPort-AV: E=Sophos;i="4.84,887,1355097600"; d="scan'208";a="189972110" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 21 Mar 2013 15:10:46 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2LFAjfn018937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Mar 2013 15:10:46 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r2LFAjh9012510; Thu, 21 Mar 2013 11:10:45 -0400 To: "Jeffrey (Zhaohui) Zhang" Subject: Re: comments on draft-zzhang-mboned-mvpn-global-table-mcast-00.txt In-reply-to: Your message of Wed, 13 Mar 2013 22:51:02 -0000. <0BF0FCC78340F147BE76A6F5762318A82F948137@BY2PRD0510MB389.namprd05.prod.outlook.com> Date: Thu, 21 Mar 2013 11:10:45 -0400 Message-ID: <12509.1363878645@erosen-linux> From: Eric Rosen Cc: Eric Rosen , "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:10:48 -0000 Jeffrey> A BR may originate an intra-AS I-PMSI A-D route for the global Jeffrey> table but it is not required, just like in rfc6513/6514/6625. Jeffrey> As mentioned above, use of intra-AS I-PMSI A-D routes is optional. I think the references are not quite clear on whether an Intra-AS I-PMSI A-D route is needed in the case where BGP C-multicast is used but inclusive tunnels are not used. RFC 6514 specifies particular cases in which a PE does not need to originate an Intra-AS I-PMSI A-D route. These cases have to do with the presence or absence of receivers and/or sources in sites attached to the PE, and with whether ingress replication is being used. But there doesn't seem to be a rule saying "you don't have to originate an Intra-AS I-PMSI A-D route if you don't want to use an inclusive P-tunnel". In GTM, I think the use of inclusive tunnels is less likely, and there are potentially a lot more global tables than there are VRFs of any given VPN. So it's more important to avoid originating A-D routes that aren't really needed. Jeffrey> each BR may use a unique RD value for its global table Doesn't that create a problem with regard to the following text from section 11.1.3 ("Constructing the Rest of the C-Multicast Route") of RFC 6514: If the local and the upstream PEs are in the same AS, then the RD of the advertised MCAST-VPN NLRI is set to the RD of the VPN-IP route that contains the address carried in the Multicast Source field. Is it the intention that the C-multicast route NLRI always have an RD of zero, even if the global tables have non-zero RDs? Jeffrey> Single Forwarder Selection can still work for GTM if BGP Add-Path Jeffrey> is used, which allows to propagate multiple UMH-eligible routes for Jeffrey> the same prefix It's not enough to propagate multiple paths to a given prefix, you'd have to make sure you propagate at least one path per ingress PE for that prefix. This gets a little tricky on BGP sessions where the next hop is changed and hence no longer identifies the ingress PE. AS-X | AS-Y | AS-Z | | S--PE1---ASBR1--|--ASBR2--|---ASBR5 | \______/ | | | / \ | | |--PE2---ASBR3--|--ASBR4--|---ASBR6 | | In AS-X, PE1 reports to both ASBR1 and ASBR3 that it has a route to S. Similarly, PE2 reports to both ASBR1 and ASBR3 that it has a route to S. Using add-path, ASBR1 reports both routes to ASBR2, and ASBR3 reports both routes to ASBR4. Now AS-Y has 4 paths to S. The AS-Z ASBRs will see eight paths. This doesn't seem very desirable. One can configure a BGP speaker using add-path to report only the n best paths, but then there is no guarantee that the reported set of paths will contain at least one path via PE1 and at least one path via PE2. I think if we really wanted to pursue this, we'd have devise some new add-path functionality such as the following. Given a set of paths with the same NLRI, look at the set union of the VRF Route Import ECs of those paths. For each value of VRF Route Import EC in that set, report the best path that carries that VRF Route Import EC value. Another alternative would be to export the GTM UMH-eligible routes as SAFI-129 routes, using unique RDs for each global table, and using RTs to cause the routes to be imported into the global tables. But perhaps it would be better just to say that SFS is not supported for GTM. With regard to the use case scenario of section 3.2: > Multicast traffic has to go through the BRs but the unicast not > necessarily. GW1 is simply advertising itself as the "protocol nexthop" > for unicast. In other words, what is desired is a multicast topology that is non-congruent to the unicast topology. That needs to be stated explicitly. Jeffrey> With enough tweaking in the UMH selection procedures we can make it Jeffrey> work w/o originating SAFI-2 routes, so it was included. Note that Jeffrey> even if the UMH routes are not distributed by BGP at all, the Jeffrey> procedure could still work. We can get input from WG on if such Jeffrey> scenario is worth supporting. If not, it can be taken out of scope. I can well imagine that a service provider might want to get this functionality without modifying its procedures for distributing unicast routes, without enabling and configuring SAFI-2, and even without adding the VRF Route Import EC to the UMH-eligible routes. If the tweaked UMH selection procedures only work in a very specific environment, I don't think it is appropriate to standardize them. However, as long as the tweaks are fully specified and the applicability restrictions clearly stated, it could be appropriate to describe the tweaks in an Informational document, especially if some service provider is demanding them. But these environment-specific tweaks have to be clearly distinguished from the procedures that are required for a more general implementation of MVPN-based GTM. Eric> MVPN procedures do not require an ingress PE to originate a route to Eric> itself with a VRF Route Import extended community attached. (One Eric> could make that a requirement, but I don't see it in the draft, and Eric> that would certainly be a modification of the MVPN procedures.) Jeffrey> It's not required; but if such a route does exist, then it can be Jeffrey> used to make that deployment scenario work. If certain procedures will only work when certain route origination policies are in place, the relationship should be clearly stated. (I guess the route origination policies could be called "pre-requisities" rather than "requirements" ;-)) With regard to the following tweak: o If the route is a BGP route with a VRF Route Import Extended Community, that VRF Route Import Extended Community is used. o If the route is a BGP route without a VRF Route Import Extended Community, get the route to the Next Hop and recurse. Thinking about this more, I'm liking it better, but I think it has the following pre-requisites that should be stated explicitly: - If a UMH-eligible route from an ingress BR that is distributed without the VRF Route Import EC, it MUST be distributed to the egress BRs in such a way that the next hop is never changed. - An ingress BR that distributes UMH-eligible routes without the VRF Route Import EC MUST use BGP to distribute a route to itself that does have the VRF Route Import EC. The NLRI MUST contain the same prefix that is used as the next hop in the abovementioned UMH-eligible routes. This route MUST be distributed to all the egress PEs that receive the abovementioned UMH-eligible routes, and at those egress PEs, it MUST be the preferred route to the ingress PE. On the issue of whether GTM requires changes to the MVPN specs (and hence a Standards Track document), I don't want to make too big a deal of the process issue. But the issue is only whether any of the procedures are different than what is described in the MVPN specs, not how different they are or how obvious one thinks the differences are ;-) Jeffrey> current MVPN spec allows using configured RTs. One can think that Jeffrey> there is an (auto-configured) RT 0:0 for the global table. This modifies the default specified in RFC 6514 section 9.1.1, which requires that, by default, the RTs be the same as the ones carried by the "unicast VPN-IP routes" (should be "UMH-eligible routes", actually). Jeffrey> Current MVPN only says use the RD for the VPN. One can think that Jeffrey> for the global table, there is an all-zero RD (or any other unique Jeffrey> RD) Sure, the GTM spec can say something like: "it MUST (or SHOULD or MAY) be possible to configure an RD that is used only for MCAST-VPN A-D routes originated from the global table, and the default value MUST be zero". It's probably also worth pointing out that this is not a legal value for use as a VRF RD, and that, unlike the use of RD zero in seamless-mcast, the use of RD zero in this draft does not modify the semantics of any BGP route in which it appears. Also, I think that something along the lines of section 6.1.2 of the seamless-mcast draft (or perhaps a normative reference to it) should also be included. From wesley.george@twcable.com Thu Mar 21 12:36:41 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CF321F857E for ; Thu, 21 Mar 2013 12:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.487 X-Spam-Level: X-Spam-Status: No, score=0.487 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwtgxkSkD9-w for ; Thu, 21 Mar 2013 12:36:41 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C64DD21F856E for ; Thu, 21 Mar 2013 12:36:40 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,888,1355115600"; d="scan'208";a="45260247" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Mar 2013 15:36:09 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Thu, 21 Mar 2013 15:36:39 -0400 From: "George, Wes" To: "l3vpn@ietf.org" Date: Thu, 21 Mar 2013 15:36:38 -0400 Subject: RE: New Version Notification for draft-gs-vpn-scaling-02.txt Thread-Topic: New Version Notification for draft-gs-vpn-scaling-02.txt Thread-Index: Ac3frcXbuYRlrsEzSiW1a4+SulKhpQg5PFGACXYYHNA= Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923041FC41729@PRVPEXVS15.corp.twcable.com> References: <20121221190248.7928.43288.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923033DAE7041@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923033DAE7041@PRVPEXVS15.corp.twcable.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 19:36:41 -0000 SGVsbG8gYWxsIC0NCg0KQWZ0ZXIgb3VyIHByZXNlbnRhdGlvbiBhdCBJRVRGODYsIHdlIHdhbnRl ZCB0byBmb2xsb3cgdXAgd2l0aCBhIHJlcXVlc3QgZm9yIGZlZWRiYWNrIG9uIHRoaXMgZHJhZnQu DQoNCldlIHRoaW5rIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgYXMgYW4gTDNWUE4gV0cgZG9jdW1lbnQs IGJ1dCBkaWRuJ3QgZ2V0IGdvb2QgZ3VpZGFuY2UgYXMgdG8gd2hldGhlciBpdCdzIHJlYWR5IGZv ciB0aGF0IG9yIG5vdC4NCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBu LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBHZW9yZ2UsIFdlcw0KPiBTZW50OiBG cmlkYXksIEZlYnJ1YXJ5IDAxLCAyMDEzIDEwOjQ3IEFNDQo+IFRvOiBsM3ZwbkBpZXRmLm9yZw0K PiBTdWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ncy12cG4t c2NhbGluZy0wMi50eHQNCj4NCj4gUm9iIFNoYWtpciBhbmQgSSB1cGRhdGVkIHRoaXMgZHJhZnQg bGFzdCBtb250aCwgYnV0IEkganVzdCByZWFsaXplZCB0aGF0DQo+IHdlIG5ldmVyIHNlbnQgbm90 aWZpY2F0aW9uIHRvIHRoZSBsaXN0IHRoYXQgd2UgaGFkIGRvbmUgc28uIFdlIGJlbGlldmUNCj4g dGhhdCB0aGlzIGluY29ycG9yYXRlcyBhbGwgb2YgdGhlIGZlZWRiYWNrIHdlJ3ZlIHJlY2VpdmVk IHRodXMgZmFyLCBhbmQNCj4gd291bGQgbGlrZSB0byBkaXNjdXNzIHRoZSBmdXR1cmUgb2YgdGhl IGRyYWZ0IC0gd2hldGhlciBpdCBzaG91bGQgYmUNCj4gYWRvcHRlZCBhcyBhIFdHIGRvYyBpbiBM M1ZQTiwgb3IgaWYgcGVyaGFwcyBpdCBpcyBiZXR0ZXIgb2ZmIGFzIGFuDQo+IGluZGl2aWR1YWwg ZG9jdW1lbnQsIG9yIGFuIE9wc0FyZWEgZG9jdW1lbnQgb3Igc29tZXRoaW5nLiBJdCdzIGFsc28N Cj4gd29ydGggYXNraW5nIHdoZXRoZXIgdGhlcmUgaXMgdmFsdWUgaW4gZGlzY3Vzc2luZyBpdCBp biBPcmxhbmRvIG9yIGlmIHdlDQo+IGNhbiBqdXN0IGNvbnRpbnVlIGRpc2N1c3Npb24gb24tbGlz dC4NCj4NCj4gSSdkIGFsc28gbGlrZSB0byBzb2xpY2l0IGhlbHAgYm9sc3RlcmluZyB0aGUgbXVs dGljYXN0IHNjYWxlIHNlY3Rpb24gb2YNCj4gdGhlIGRvY3VtZW50LCBlaXRoZXIgaW4gdGV4dCBj b250cmlidXRpb25zIG9yIGluIHBvaW50ZXJzIG9uIGFyZWFzIHdlDQo+IG5lZWQgdG8gY292ZXIs IHRoaW5ncyB3ZSBzaG91bGQgcmVhZCwgZXRjLg0KPg0KPiBBbmQgb2YgY291cnNlIGFkZGl0aW9u YWwgcmV2aWV3IGNvbW1lbnRzIGFyZSBhbHdheXMgd2VsY29tZS4gOi0pDQo+DQo+IFRoYW5rcw0K PiBXZXMgR2VvcmdlIGFuZCBSb2IgU2hha2lyDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAyOjAzIFBN DQo+IFRvOiBHZW9yZ2UsIFdlcw0KPiBDYzogcm9iLnNoYWtpckBidC5jb20NCj4gU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ncy12cG4tc2NhbGluZy0wMi50eHQN Cj4NCj4NCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdzLXZwbi1zY2FsaW5nLTAyLnR4 dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkNCj4gc3VibWl0dGVkIGJ5IFdlc2xleSBHZW9yZ2UgYW5k IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPg0KPiBGaWxlbmFtZTogICAgICAgIGRy YWZ0LWdzLXZwbi1zY2FsaW5nDQo+IFJldmlzaW9uOiAgICAgICAgMDINCj4gVGl0bGU6ICAgICAg ICAgICBJUCBWUE4gU2NhbGluZyBDb25zaWRlcmF0aW9ucw0KPiBDcmVhdGlvbiBkYXRlOiAgIDIw MTItMTItMjENCj4gV0cgSUQ6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gTnVt YmVyIG9mIHBhZ2VzOiAyOQ0KPiBVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdzLXZwbi0NCj4gc2NhbGluZy0wMi50eHQNCj4gU3RhdHVz OiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdzLXZwbi1z Y2FsaW5nDQo+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZ3MtdnBuLXNjYWxpbmctMDINCj4gRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ncy12cG4tc2NhbGluZy0NCj4gMDINCj4NCj4gQWJzdHJh Y3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHNjYWxpbmcgY29uc2lkZXJhdGlvbnMg dW5pcXVlIHRvDQo+ICAgIGltcGxlbWVudGF0aW9uIG9mIExheWVyIDMgKElQKSBWaXJ0dWFsIFBy aXZhdGUgTmV0d29ya3MsIGRpc2N1c3NlcyBhDQo+ICAgIGZldyBiZXN0IHByYWN0aWNlcywgYW5k IGlkZW50aWZpZXMgZ2FwcyBpbiB0aGUgY3VycmVudCB0b29scyBhbmQNCj4gICAgdGVjaG5pcXVl cyB3aGljaCBhcmUgbWFraW5nIGl0IG1vcmUgZGlmZmljdWx0IGZvciBvcGVyYXRvcnMgdG8gY29z dC0NCj4gICAgZWZmZWN0aXZlbHkgc2NhbGUgYW5kIG1hbmFnZSB0aGVpciBMM1ZQTiBkZXBsb3lt ZW50cy4NCj4NCj4NCj4NCj4NCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCg0KDQpUaGlzIEUt bWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBD YWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlk ZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIg Q2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVi eSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcs IG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFj aG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1 bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRo ZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4N Cg== From zzhang@juniper.net Mon Mar 25 09:18:35 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A0521F8D2F for ; Mon, 25 Mar 2013 09:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvL8axxjqKX0 for ; Mon, 25 Mar 2013 09:18:34 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9D821F882C for ; Mon, 25 Mar 2013 09:18:34 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUVB42v+v7skLAtTkTPHGoqxMvBXxEA5X@postini.com; Mon, 25 Mar 2013 09:18:34 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 25 Mar 2013 09:16:27 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 25 Mar 2013 09:16:27 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.15) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 25 Mar 2013 09:25:37 -0700 Received: from mail151-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Mar 2013 16:16:26 +0000 Received: from mail151-tx2 (localhost [127.0.0.1]) by mail151-tx2-R.bigfish.com (Postfix) with ESMTP id 0CBF13400EA for ; Mon, 25 Mar 2013 16:16:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -31 X-BigFish: PS-31(zz9371I148cI542Iec9N1432I1418Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail151-tx2 (localhost.localdomain [127.0.0.1]) by mail151-tx2 (MessageSwitch) id 136422818423758_6022; Mon, 25 Mar 2013 16:16:24 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.232]) by mail151-tx2.bigfish.com (Postfix) with ESMTP id 000164E005C; Mon, 25 Mar 2013 16:16:23 +0000 (UTC) Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Mar 2013 16:16:22 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.54]) by BY2PRD0510HT004.namprd05.prod.outlook.com ([10.255.84.39]) with mapi id 14.16.0275.006; Mon, 25 Mar 2013 16:16:22 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Eric Rosen , "l3vpn@ietf.org" Subject: RE: comments on draft-zzhang-mboned-mvpn-global-table-mcast-00.txt Thread-Topic: comments on draft-zzhang-mboned-mvpn-global-table-mcast-00.txt Thread-Index: AQHOJkZMvsRJ2ATOmkK/d2N5Ztwr6JiwS1Pw Date: Mon, 25 Mar 2013 16:16:22 +0000 Message-ID: <0BF0FCC78340F147BE76A6F5762318A82F95E156@BY2PRD0510MB389.namprd05.prod.outlook.com> References: Your message of Wed, 13 Mar 2013 22:51:02 -0000. <0BF0FCC78340F147BE76A6F5762318A82F948137@BY2PRD0510MB389.namprd05.prod.outlook.com> <12509.1363878645@erosen-linux> In-Reply-To: <12509.1363878645@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 16:18:35 -0000 Eric, > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, March 21, 2013 11:11 AM > To: Jeffrey (Zhaohui) Zhang > Cc: Eric Rosen; l3vpn@ietf.org > Subject: Re: comments on draft-zzhang-mboned-mvpn-global-table-mcast- > 00.txt >=20 > Jeffrey> A BR may originate an intra-AS I-PMSI A-D route for the global > Jeffrey> table but it is not required, just like in rfc6513/6514/6625. >=20 > Jeffrey> As mentioned above, use of intra-AS I-PMSI A-D routes is optiona= l. >=20 > I think the references are not quite clear on whether an Intra-AS I-PMSI = A-D > route is needed in the case where BGP C-multicast is used but inclusive > tunnels are not used. RFC 6514 specifies particular cases in which a PE > does not need to originate an Intra-AS I-PMSI A-D route. These cases hav= e > to do with the presence or absence of receivers and/or sources in sites > attached to the PE, and with whether ingress replication is being used. > But there doesn't seem to be a rule saying "you don't have to originate a= n > Intra-AS I-PMSI A-D route if you don't want to use an inclusive P-tunnel"= . > In GTM, I think the use of inclusive tunnels is less likely, and there > are potentially a lot more global tables than there are VRFs of any given > VPN. So it's more important to avoid originating A-D routes that aren't > really needed. If I understand you correctly, the spec should point out that I-PMSI A-D ro= ute should be avoided, for practical reasons. I will do that. >=20 > Jeffrey> each BR may use a unique RD value for its global table >=20 > Doesn't that create a problem with regard to the following text from > section 11.1.3 ("Constructing the Rest of the C-Multicast Route") of RFC = 6514: >=20 > If the local and the upstream PEs are in the same AS, then the RD of > the advertised MCAST-VPN NLRI is set to the RD of the VPN-IP route > that contains the address carried in the Multicast Source field. >=20 > Is it the intention that the C-multicast route NLRI always have an RD > of zero, even if the global tables have non-zero RDs? Yes. The draft did miss pointing out that all-zero RD is used for C-multica= st routes. Currently the draft says to use all-zero RD for A-D routes by default, but = I'm thinking that we should revert it - use non-zero RDs for A-D routes by = default but allow zero RDs. Using zero RDs has the caveat that it does not = work with GTM procedures in seamless-mpls-mcast. >=20 > Jeffrey> Single Forwarder Selection can still work for GTM if BGP Add-Pat= h > Jeffrey> is used, which allows to propagate multiple UMH-eligible routes = for > Jeffrey> the same prefix >=20 > It's not enough to propagate multiple paths to a given prefix, you'd have= to > make sure you propagate at least one path per ingress PE for that prefix. > This gets a little tricky on BGP sessions where the next hop is changed > and hence no longer identifies the ingress PE. >=20 > AS-X | AS-Y | AS-Z > | | > S--PE1---ASBR1--|--ASBR2--|---ASBR5 > | \______/ | | > | / \ | | > |--PE2---ASBR3--|--ASBR4--|---ASBR6 > | | >=20 > In AS-X, PE1 reports to both ASBR1 and ASBR3 that it has a route to S. > Similarly, PE2 reports to both ASBR1 and ASBR3 that it has a route to S. > Using add-path, ASBR1 reports both routes to ASBR2, and ASBR3 reports > both routes to ASBR4. Now AS-Y has 4 paths to S. The AS-Z ASBRs will se= e > eight paths. This doesn't seem very desirable. One can configure a BGP > speaker using add-path to report only the n best paths, but then there is= no > guarantee that the reported set of paths will contain at least one path > via PE1 and at least one path via PE2. >=20 > I think if we really wanted to pursue this, we'd have devise some new > add-path functionality such as the following. Given a set of paths > with the same NLRI, look at the set union of the VRF Route Import ECs of = those > paths. For each value of VRF Route Import EC in that set, report the best= path > that carries that VRF Route Import EC value. >=20 > Another alternative would be to export the GTM UMH-eligible routes as > SAFI-129 routes, using unique RDs for each global table, and using RTs > to cause the routes to be imported into the global tables. >=20 > But perhaps it would be better just to say that SFS is not supported > for GTM. Thanks for pointing this out. I agree that we should simply say that SFS is= not supported. >=20 > With regard to the use case scenario of section 3.2: >=20 > > Multicast traffic has to go through the BRs but the unicast not > > necessarily. GW1 is simply advertising itself as the "protocol nexthop= " > > for unicast. >=20 > In other words, what is desired is a multicast topology that is > non-congruent to the unicast topology. That needs to be stated > explicitly. It's not that it is "desired" so. It's just that the fact that multicast tr= affic has to go through certain BRs, while unicast may go through some othe= r paths. >=20 > Jeffrey> With enough tweaking in the UMH selection procedures we can make= it > Jeffrey> work w/o originating SAFI-2 routes, so it was included. Note tha= t > Jeffrey> even if the UMH routes are not distributed by BGP at all, the > Jeffrey> procedure could still work. We can get input from WG on if such > Jeffrey> scenario is worth supporting. If not, it can be taken out of sco= pe. >=20 > I can well imagine that a service provider might want to get this > functionality without modifying its procedures for distributing unicast > routes, without enabling and configuring SAFI-2, and even without > adding the VRF Route Import EC to the UMH-eligible routes. >=20 > If the tweaked UMH selection procedures only work in a very specific > environment, I don't think it is appropriate to standardize them. > However, as long as the tweaks are fully specified and the applicability > restrictions clearly stated, it could be appropriate to describe the twea= ks in an > Informational document, especially if some service provider is demanding > them. But these environment-specific tweaks have to be clearly > distinguished from the procedures that are required for a more general > implementation of MVPN-based GTM. Agreed. >=20 > Eric> MVPN procedures do not require an ingress PE to originate a route t= o > Eric> itself with a VRF Route Import extended community attached. (One > Eric> could make that a requirement, but I don't see it in the draft, and > Eric> that would certainly be a modification of the MVPN procedures.) >=20 > Jeffrey> It's not required; but if such a route does exist, then it can b= e > Jeffrey> used to make that deployment scenario work. >=20 > If certain procedures will only work when certain route origination polic= ies > are in place, the relationship should be clearly stated. (I guess the > route origination policies could be called "pre-requisities" rather than > "requirements" ;-)) I will state explicitly which scenarios can be made to work with the tweaks= and what the pre-requisites are. Currently it only spells out the procedur= e on the egress PEs. >=20 > With regard to the following tweak: >=20 > o If the route is a BGP route with a VRF Route Import Extended > Community, that VRF Route Import Extended Community is used. >=20 > o If the route is a BGP route without a VRF Route Import Extende= d > Community, get the route to the Next Hop and recurse. >=20 > Thinking about this more, I'm liking it better, but I think it has the > following pre-requisites that should be stated explicitly: >=20 > - If a UMH-eligible route from an ingress BR that is distributed without = the > VRF Route Import EC, it MUST be distributed to the egress BRs in such a > way that the next hop is never changed. If the ingress BR does distribute the routes with BGP, then just make it a = requirement to attach those ECs like in MVPN case. >=20 > - An ingress BR that distributes UMH-eligible routes without the VRF Rout= e > Import EC MUST use BGP to distribute a route to itself that does have t= he > VRF Route Import EC. The NLRI MUST contain the same prefix that is use= d > as the next hop in the abovementioned UMH-eligible routes. This route When an ingress BR does not distribute all UMH-eligible routes (see above),= then it SHOULD use BGP to distribute the above mentioned route to itself. The keyword "SHOULD" instead of "MUST" comes from the fact that, if no such= route exists, but the ingress BR is the endpoint of RSVP-TE tunnels from o= ther PEs, and the UMH routes use those tunnels, then those PEs can construc= t the VRF Route Import EC as described in the draft. > MUST be distributed to all the egress PEs that receive the abovemention= ed > UMH-eligible routes, and at those egress PEs, it MUST be the preferred > route to the ingress PE. What if it's not the preferred route on an egress PE, but the implementatio= n on that PE can still make use of it? I think that should be allowed. >=20 > On the issue of whether GTM requires changes to the MVPN specs (and hence= a > Standards Track document), I don't want to make too big a deal of the > process issue. But the issue is only whether any of the procedures are > different than what is described in the MVPN specs, not how different > they are or how obvious one thinks the differences are ;-) OK. I think your preference is make it standard track, and optionally docum= ent the special scenario in an informational spec. >=20 > Jeffrey> current MVPN spec allows using configured RTs. One can think tha= t > Jeffrey> there is an (auto-configured) RT 0:0 for the global table. >=20 > This modifies the default specified in RFC 6514 section 9.1.1, which > requires that, by default, the RTs be the same as the ones carried by > the "unicast VPN-IP routes" (should be "UMH-eligible routes", actually). Yes it does modify the default, though using a non-default RT is also allow= ed. >=20 > Jeffrey> Current MVPN only says use the RD for the VPN. One can think > that Jeffrey> for the global table, there is an all-zero RD (or any other > unique RD) >=20 > Sure, the GTM spec can say something like: "it MUST (or SHOULD or MAY) > be possible to configure an RD that is used only for MCAST-VPN A-D routes > originated from the global table, and the default value MUST be zero". > It's probably also worth pointing out that this is not a legal value for = use > as a VRF RD, and that, unlike the use of RD zero in seamless-mcast, the u= se > of RD zero in this draft does not modify the semantics of any BGP route i= n > which it appears. Indeed. As mentioned above, we should change the default behavior (in this = draft) that non-zero RDs should be used in the A-D routes. >=20 > Also, I think that something along the lines of section 6.1.2 of the > seamless-mcast draft (or perhaps a normative reference to it) should > also be included. 6.1.2 talks about three things: 1) Add VRF Route Import EC to unicast routes 2) Inter-area P2MP Segmented Next-Hop Extended Community 3) Determine Ingress PE and then upstream node I assume you're referring to 1). I missed stating it explicitly, though I d= id imply it in section 3.1 and 3.2. I will add it. Thanks. Jeffrey