From danny@tcb.net Wed Apr 1 06:56: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 AEAEA3A6CA9 for ; Wed, 1 Apr 2009 06:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk1pl9nHcrE6 for ; Wed, 1 Apr 2009 06:56:37 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 0A5743A6B7B for ; Wed, 1 Apr 2009 06:56:37 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 61B312684EA; Wed, 1 Apr 2009 07:57:37 -0600 (MDT) Received: from jchouinard-sim-102.eng.ellacoya.com (97-122-114-19.hlrn.qwest.net [97.122.114.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 01 Apr 2009 07:57:37 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.114.19; client-port=49211; syn-fingerprint=65535:55:1:64:M1408,N,W3,N,N,T,S; data-bytes=0 Message-Id: <12758A32-1D66-403E-85CA-55ED9D099684@tcb.net> From: Danny McPherson To: Kenji Kumaki In-Reply-To: <49D2C388.7080605@kddilabs.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: L3VPN @IETF 74 Draft Minutes Date: Wed, 1 Apr 2009 07:57:36 -0600 References: <49D2C388.7080605@kddilabs.jp> X-Mailer: Apple Mail (2.930.3) Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 13:56:37 -0000 On Mar 31, 2009, at 7:29 PM, Kenji Kumaki wrote: > Hi, > > In terms of draft-ietf-l3vpn-e2e-rsvp-te-reqts, > I sent an email for the status of this draft to L3VPN WG on Mar 18th. Ahh, yes: "Last IETF, I got a lot of comments from David McDysan of verizon. So, I will update them by the beginning of May. After that, we will start the LC." Thanks, looking forward to the update. -danny From yakov@juniper.net Wed Apr 1 08:02:14 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 8922C3A6DEE for ; Wed, 1 Apr 2009 08:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 20+RA8JqQ5UD for ; Wed, 1 Apr 2009 08:02:13 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id B0DBC3A6DD2 for ; Wed, 1 Apr 2009 08:02:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSdOCKAHoylEpXYq4xYDuisimdrwyfEW2@postini.com; Wed, 01 Apr 2009 08:03:11 PDT 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.340.0; Wed, 1 Apr 2009 07:58:27 -0700 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, 1 Apr 2009 07:58:27 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 07:58:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 07:58:26 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n31EwQM36332; Wed, 1 Apr 2009 07:58:26 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200904011458.n31EwQM36332@magenta.juniper.net> To: "NAPIERALA, MARIA H, ATTLABS" Subject: Re: draft-ietf-l3vpn-2547bis-mcast-bgp section 13 In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A2002188810@misout7msgusr7e.ugd.att.com> References: <2F1DE4DFCFF32144B771BD2C246E6A20020A4A20@misout7msgusr7e.ugd.att.com> <20090312120413.O8009@sapphire.juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A2002188810@misout7msgusr7e.ugd.att.com> X-MH-In-Reply-To: "NAPIERALA, MARIA H, ATTLABS" message dated "Tue, 17 Mar 2009 12:46:56 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44583.1238597906.1@juniper.net> Date: Wed, 1 Apr 2009 07:58:26 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 01 Apr 2009 14:58:26.0690 (UTC) FILETIME=[4FB8DE20:01C9B2DA] Cc: rahul@juniper.net, 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, 01 Apr 2009 15:02:14 -0000 Maria, >>> It seems to me that trying to avoid duplicates with single forwarder >>> election (when BGP-signaling is used) is becoming complex and has >>> side, and may not be worth solving ... >>> >>> I am not referring to single forwarder election. Section 9.1 of >>> [MVPN] describes discarding packets from the unexpected UMH, >>> irrespective of whether single forwarder election is used or not and >>> that is what I am referring to. >> >> That is exactly what I meant, namely, that single forwarder election >> (with BGP as signaling protocol) cannot resolve duplicates by itself but >> always requires the "strong" RPF check (i.e., identifying the PE that >> transmitted the packet). Your claim is incorrect wrt steady state, as in a steady state single forwarder election with BGP as a signaling protocol does eliminate/resolve duplicates by itself. Without the ability to discard packets from the unexpected UMH, (without what you call "the strong RPF check") duplicates may exist during transients (e.g., RPT to SPT switchover), but such duplicates may exist with PIM as a signaling protocol as well. And as mentioned above, with this ability (with "the strong RPF check") such duplicates will be suppressed with BGP as the C-multicast signaling protocol. >> There are other side effects of single forwarder election and >> BGP-signaling (I will send an example in a separate e-mail). >> >> Hence, the statement in section 9.1.2 of [MVPN]: >> >> "One difference in effect between this procedure and the procedure of >> section 9.1.1 is that this procedure sends only one copy of each packet >> to each egress PE, rather than sending multiple copies and forcing the >> egress PE to discard all but one" >> >> is not true when BGP-signaling is used. Your claim is incorrect, and here is why. Let's look at the whole section 9.1.2 of [MVPN] (not just the paragraph you quoted above): 9.1.2. Single Forwarder Selection Section 5.1 specifies a procedure for choosing a "default upstream PE selection", such that (except during routing transients) all PEs will choose the same default upstream PE. To ensure that duplicate packets are not sent through the backbone (except during routing transients), an ingress PE does not forward to the backbone any (C-S,C-G) multicast data packet it receives from a CE, unless the PE is the default upstream PE selection. One difference in effect between this procedure and the procedure of section 9.1.1 is that this procedure sends only one copy of each packet to each egress PE, rather than sending multiple copies and forcing the egress PE to discard all but one. >From the text above it should be (abundantly) clear that section 9.1.2 talks about a steady state, *not* about transients, and in a steady state single forwarder election with BGP as a signaling protocol does eliminate duplicates by itself. >>> Please see Yakov's email on the clarifying changes to the text >>> in section 13.1. >> >> The new proposal for SA withdrawal is as follows: >> >> "Whenever as a result of receiving a withdrawal of the previousely >> advertise Source Tree Join C-multicast route for (C-S, C-G), the >> PE is going to remove the S-PMSI/I-PMSI from the outgoing interface >> list of the (C-S, C-G) state, the local PE MUST also withdraw >> the Source Active A-D route for (C-S, C-G), if such a route has >> been advertised." >> >> What happens if "S" stops sending and (S,G) state is deleted on the >> upstream PE before it receives a withdrawal of (S,G) Join route? >> According to the condition as stated above, the SA A-D route for >> (S,G) will not be withdrawn. How about the following modified text: "Whenever the PE deletes the (C-S, C-G) state, or whenever the PE, as a result of receiving a withdrawal of the previousely advertise Source Tree Join C-multicast route for (C-S, C-G), is going to remove the S-PMSI/I-PMSI from the outgoing interface list of the (C-S, C-G) state, the PE MUST also withdraw the Source Active A-D route for (C-S, C-G), if such a route has been advertised by the PE." Yakov. From mnapierala@att.com Thu Apr 2 08:44:51 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 4594F3A6985 for ; Thu, 2 Apr 2009 08:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.267 X-Spam-Level: X-Spam-Status: No, score=-106.267 tagged_above=-999 required=5 tests=[AWL=0.332, 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 vg1qv4y8onVU for ; Thu, 2 Apr 2009 08:44:50 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id E3CC93A6A2B for ; Thu, 2 Apr 2009 08:44:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mnapierala@att.com X-Msg-Ref: server-2.tower-167.messagelabs.com!1238687128!10904185!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 28957 invoked from network); 2 Apr 2009 15:45:29 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-2.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Apr 2009 15:45:29 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n32FjSgF010323; Thu, 2 Apr 2009 11:45:28 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n32FjNuu010249; Thu, 2 Apr 2009 11:45:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-l3vpn-2547bis-mcast-bgp section 13 Date: Thu, 2 Apr 2009 11:45:20 -0400 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A20023636E6@misout7msgusr7e.ugd.att.com> In-Reply-To: <200904011458.n31EwQM36332@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-2547bis-mcast-bgp section 13 Thread-Index: Acmy2v0FnvB1RAXoSBm8IXcaQMiDhQAzqegQ References: <2F1DE4DFCFF32144B771BD2C246E6A20020A4A20@misout7msgusr7e.ugd.att.com> <20090312120413.O8009@sapphire.juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A2002188810@misout7msgusr7e.ugd.att.com> <200904011458.n31EwQM36332@magenta.juniper.net> From: "NAPIERALA, MARIA H, ATTLABS" To: "Yakov Rekhter" Cc: rahul@juniper.net, 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, 02 Apr 2009 15:44:51 -0000 Yakov, > Without the ability to discard packets from the unexpected UMH, > (without what you call "the strong RPF check") duplicates may exist > during transients (e.g., RPT to SPT switchover), but such duplicates > may exist with PIM as a signaling protocol as well. And as mentioned > above, with this ability (with "the strong RPF check") such duplicates > will be suppressed with BGP as the C-multicast signaling protocol. In a *transient* state only few duplicates are generated, which is generally acceptable to multicast applications.=20 The multicast scenario and how it is handled by BGP-multicast, which I described, is not a case of a *transient* state. Let me explain: The BGP implementation of the scenario forces SPT-to-RPT switchover which is quite different from the familiar RPT-to-SPT switchover. I believe that such a switchover should be avoided in the first place. In fact, such SPT-to-RPT switchover does not happen in PIM because (as defined in RFC4601) all receivers will stay on SPT as long as the source is active.=20 As Rahul described in his e-mail (and I agree with it), the only solution to avoid packet loss is to delay sending (S,G) Prune towards the source "S". The delay of this Prune will have to be long enough to give time for the (*,G) Join to be delivered to C-RP: -First, this delay has to be long enough for Source-Active A-D route to be withdrawn and for egress PEs to change their forwarding to receive "S" traffic on RPT. This might take seconds, especially if multiple RRs are in the path, which itself poses a question whether the amount of duplicates will be acceptable.=20 -But more importantly this delay cannot be just in seconds but should last several minutes. PIM allows for, at least, 210 sec (3.5 min) for an interface to time out, taking into account that some Join(s) might not be delivered. The switchback to RPT should allow similar amount of time before pruning (S,G) since the (*,G) Join that performs the switchback to RPT is being send to customer's network over which SP has no control, and there is no guarantee that the 1st (*,G) Join will be delivered. Since the source "S" can be active and there are active listeners, its flow cannot be interrupted. The reliance on discarding duplicates in this case is necessary (as Rahul correctly stated).=20 Hence, it is quite clear that multicast forwarding with BGP-signaling requires "strong" or "UMH-based" RPF check. > >> There are other side effects of single forwarder election and > >> BGP-signaling (I will send an example in a separate e-mail). The other side effect of single forwarder election and BGP-signaling is that it might trigger different trees than VPN customer expects. Here is one example: =20 RP---R3 | | R1---PE1-- ... --PE2---\ ... S R2---PE4-- ... --PE3---/ Source "S" is dually connected to PE2 and PE3.=20 Assume that PE2's, PE1's, and PE4's best path to "S" is via PE2. -RP sends (S,G) Join to PE2 and PE2 sends Join directly to "S"=20 -R1, R2, R3 send (*,G) Joins towards RP=20 -R1, R2, R3 switch to SPT and single forwarder election chooses PE3 as the upstream PE Hence, SPT will be as follows: S / \ R3---RP---PE2--PE3---PE4---R2 |=09 PE1 | R1 while VPN customer expected SPT not to include S--PE3 path, as follows: =09 S =20 | =20 R3---RP---PE2---PE4---R2 =20 | PE1=20 | R1 =09 This is an issue because VPN customers expect multicast to follow VRF routing policy. =20 When PIM is used as a signaling protocol the SPT will be as expected because there will be no (S,G) Joins send to PE3 and thus there will be no Asserts. > >> Hence, the statement in section 9.1.2 of [MVPN]: > >> > >> "One difference in effect between this procedure and the procedure > of > >> section 9.1.1 is that this procedure sends only one copy of each > packet > >> to each egress PE, rather than sending multiple copies and forcing > the > >> egress PE to discard all but one" > >> > >> is not true when BGP-signaling is used. >=20 > Your claim is incorrect, and here is why. Let's look at the whole > section 9.1.2 of [MVPN] (not just the paragraph you quoted above): >=20 > 9.1.2. Single Forwarder Selection >=20 > Section 5.1 specifies a procedure for choosing a "default upstream PE > selection", such that (except during routing transients) all PEs will > choose the same default upstream PE. To ensure that duplicate > packets are not sent through the backbone (except during routing > transients), an ingress PE does not forward to the backbone any > (C-S,C-G) multicast data packet it receives from a CE, unless the PE > is the default upstream PE selection. >=20 > One difference in effect between this procedure and the procedure of > section 9.1.1 is that this procedure sends only one copy of each > packet to each egress PE, rather than sending multiple copies and > forcing the egress PE to discard all but one. >=20 > From the text above it should be (abundantly) clear that section > 9.1.2 talks about a steady state, *not* about transients, and in a > steady state single forwarder election with BGP as a signaling > protocol does eliminate duplicates by itself. As I explained above the switching from SPT to RPT using BGP-signaling would not generate *merely* a transient state. >=20 > >>> Please see Yakov's email on the clarifying changes to the text > >>> in section 13.1. > >> > >> The new proposal for SA withdrawal is as follows: > >> > >> "Whenever as a result of receiving a withdrawal of the previousely > >> advertise Source Tree Join C-multicast route for (C-S, C-G), the > >> PE is going to remove the S-PMSI/I-PMSI from the outgoing > interface > >> list of the (C-S, C-G) state, the local PE MUST also withdraw > >> the Source Active A-D route for (C-S, C-G), if such a route has > >> been advertised." > >> > >> What happens if "S" stops sending and (S,G) state is deleted on the > >> upstream PE before it receives a withdrawal of (S,G) Join route? > >> According to the condition as stated above, the SA A-D route for > >> (S,G) will not be withdrawn. >=20 > How about the following modified text: >=20 > "Whenever the PE deletes the (C-S, C-G) state, or whenever the > PE, as a result of receiving a withdrawal of the previousely > advertise Source Tree Join C-multicast route for (C-S, C-G), > is going to remove the S-PMSI/I-PMSI from the outgoing interface > list of the (C-S, C-G) state, the PE MUST also withdraw the > Source Active A-D route for (C-S, C-G), if such a route has > been advertised by the PE." This means that an upstream PE may have (S,G) Join route(s) but no (S,G) PIM state. Doesn't this imply an inconsistency between PIM and BGP since the (S,G) Join route (quote from [BGP-MVPN]) "'correspond' to the PIM (S,G) state"? Maria From yakov@juniper.net Mon Apr 6 13:57:51 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 CA9C13A69A8 for ; Mon, 6 Apr 2009 13:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 1JiXwCeUFF3f for ; Mon, 6 Apr 2009 13:57:50 -0700 (PDT) Received: from chip3og56.obsmtp.com (chip3og56.obsmtp.com [64.18.14.177]) by core3.amsl.com (Postfix) with ESMTP id 359DC3A6885 for ; Mon, 6 Apr 2009 13:57:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob56.postini.com ([64.18.6.12]) with SMTP ID DSNKSdptDcRGsRbF4nXquQxzrb0HsJMGEyqh@postini.com; Mon, 06 Apr 2009 13:58:56 PDT 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.340.0; Mon, 6 Apr 2009 13:57:53 -0700 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, 6 Apr 2009 13:57:52 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 13:57:52 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 13:57:51 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n36KvpM40533; Mon, 6 Apr 2009 13:57:51 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200904062057.n36KvpM40533@magenta.juniper.net> To: "NAPIERALA, MARIA H, ATTLABS" Subject: Re: draft-ietf-l3vpn-2547bis-mcast-bgp section 13 In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A20023636E6@misout7msgusr7e.ugd.att.com> References: <2F1DE4DFCFF32144B771BD2C246E6A20020A4A20@misout7msgusr7e.ugd.att.com> <20090312120413.O8009@sapphire.juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A2002188810@misout7msgusr7e.ugd.att.com> <200904011458.n31EwQM36332@magenta.juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A20023636E6@misout7msgusr7e.ugd.att.com> X-MH-In-Reply-To: "NAPIERALA, MARIA H, ATTLABS" message dated "Thu, 02 Apr 2009 11:45:20 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38095.1239051471.1@juniper.net> Date: Mon, 6 Apr 2009 13:57:51 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 06 Apr 2009 20:57:51.0371 (UTC) FILETIME=[5956CDB0:01C9B6FA] 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: Mon, 06 Apr 2009 20:57:51 -0000 Maria, > > Without the ability to discard packets from the unexpected UMH, > > (without what you call "the strong RPF check") duplicates may exist > > during transients (e.g., RPT to SPT switchover), but such duplicates > > may exist with PIM as a signaling protocol as well. And as mentioned > > above, with this ability (with "the strong RPF check") such duplicates > > will be suppressed with BGP as the C-multicast signaling protocol. > > In a *transient* state only few duplicates are generated, which is > generally acceptable to multicast applications. > The multicast scenario and how it is handled by BGP-multicast, which I > described, is not a case of a *transient* state. Let me explain: > The BGP implementation of the scenario forces SPT-to-RPT switchover > which is quite different from the familiar RPT-to-SPT switchover. I > believe that such a switchover should be avoided in the first place. In > fact, such SPT-to-RPT switchover does not happen in PIM because (as > defined in RFC4601) all receivers will stay on SPT as long as the source > is active. First of all, you are contradicting your own requirements. This is because on one hand you say above that SPT-to-RPT should be avoided "as long as the source is active", which means that it should be avoided irrespective of whether there are any receivers that switch to SPT. Yet on another hand you require MVPN "not trigger unexpected (C-S, C-G) states in customer's network" (see Section 5 of your draft draft-mnapierala-mvpn-part-reqt-02.txt). If indeed SPT-to-RPT switchover is to be avoided, even if there are no more receivers that switch to SPT, then this may result in a situation where the MVPN customer network will have an unexpected (C-S, C-G) state. Second, please consider the following example: C-RP C-S | | CE1 CE2 | | PE1 PE2 PE3 PE4 | | CE3 CE4 | | Rcv1 Rcv2 Assume that initially DRs connected to both Rcv1 and Rcv2 join RPT (by sending Join(C-*, C-G) towards C-RP). When the DR connected to Rcv1 receives the first (C-S, C-G) packet, the DR switches to SPT (by sending Join(C-S, C-G) towards C-S). However, the DR connected to Rcv2 stays on RPT (and does not switch to SPT). Later on, Rcv1 goes away. Please point to the *specific* procedures in rfc4601 (section number does not count as a "specific procedure") that would result in preserving SPT (and specifically preserving (C-S, C-G) state on PE2) after Rcv1 goes away. > As Rahul described in his e-mail (and I agree with it), the only > solution to avoid packet loss is to delay sending (S,G) Prune towards > the source "S". The delay of this Prune will have to be long enough to > give time for the (*,G) Join to be delivered to C-RP: > - -First, this delay has to be long enough for Source-Active A-D route to > be withdrawn and for egress PEs to change their forwarding to receive > "S" traffic on RPT. This might take seconds, especially if multiple RRs > are in the path, which itself poses a question whether the amount of > duplicates will be acceptable. > > - -But more importantly this delay cannot be just in seconds but should > last several minutes. PIM allows for, at least, 210 sec (3.5 min) for an > interface to time out, taking into account that some Join(s) might not > be delivered. The switchback to RPT should allow similar amount of time > before pruning (S,G) since the (*,G) Join that performs the switchback > to RPT is being send to customer's network over which SP has no control, > and there is no guarantee that the 1st (*,G) Join will be delivered. > Since the source "S" can be active and there are active listeners, its > flow cannot be interrupted. The reliance on discarding duplicates in > this case is necessary (as Rahul correctly stated). > Hence, it is quite clear that multicast forwarding with BGP-signaling > requires "strong" or "UMH-based" RPF check. Your last claim above is incorrect. > > >> There are other side effects of single forwarder election and > > >> BGP-signaling (I will send an example in a separate e-mail). > > The other side effect of single forwarder election and BGP-signaling is > that it might trigger different trees than VPN customer expects. Here is > one example: > > RP---R3 > | > | > R1---PE1-- ... --PE2---\ > ... S > R2---PE4-- ... --PE3---/ > > > Source "S" is dually connected to PE2 and PE3. > Assume that PE2's, PE1's, and PE4's best path to "S" is via PE2. > > - -RP sends (S,G) Join to PE2 and PE2 sends Join directly to "S" > - -R1, R2, R3 send (*,G) Joins towards RP > - -R1, R2, R3 switch to SPT and single forwarder election chooses PE3 as > the upstream PE Let me remind you of the following text from Section 5.1.3 of draft-ietf-l3vpn-2547bis-mcast-08.txt Another procedure, which SHOULD be implemented, is to use the Installed UMH Route as the Selected UMH Route. in which case PE2 (and not PE3, as you claim above) will be chosen as the forwarder (as PE2's, PE1's, and PE4's best path to "S" is via PE2, and not via PE3), and so the rest does not apply. > Hence, SPT will be as follows: > > S > / \ > R3---RP---PE2--PE3---PE4---R2 > | > PE1 > | > R1 > > while VPN customer expected SPT not to include S--PE3 path, as follows: > > S > | > R3---RP---PE2---PE4---R2 > | > PE1 > | > R1 > > This is an issue because VPN customers expect multicast to follow VRF > routing policy. > > When PIM is used as a signaling protocol the SPT will be as expected > because there will be no (S,G) Joins send to PE3 and thus there will be > no Asserts. As you know quite well, use of PIM for C-multicast signaling, as specified in draft-ietf-l3vpn-2547bis-mcast-08.txt, can result in a situation where multicast will *not* follow the VRF routing policy, and the SPT may not be "as expected". Using your example above, let's assume that that PE1's best path to "S" is via PE2, but PE4's best path to "S" is via PE3. In this case Asserts will result in either PE2 or PE3 being the forwarder, which in turn will result in violation of the VRF routing policy on either PE1 or PE4, and the SPT *not* being "as expected". > > >> Hence, the statement in section 9.1.2 of [MVPN]: > > >> > > >> "One difference in effect between this procedure and the procedure of > > >> section 9.1.1 is that this procedure sends only one copy of each packet > > >> to each egress PE, rather than sending multiple copies and forcing the > > >> egress PE to discard all but one" > > >> > > >> is not true when BGP-signaling is used. > > > > Your claim is incorrect, and here is why. Let's look at the whole > > section 9.1.2 of [MVPN] (not just the paragraph you quoted above): > > > > 9.1.2. Single Forwarder Selection > > > > Section 5.1 specifies a procedure for choosing a "default upstream PE > > selection", such that (except during routing transients) all PEs will > > choose the same default upstream PE. To ensure that duplicate > > packets are not sent through the backbone (except during routing > > transients), an ingress PE does not forward to the backbone any > > (C-S,C-G) multicast data packet it receives from a CE, unless the PE > > is the default upstream PE selection. > > > > One difference in effect between this procedure and the procedure of > > section 9.1.1 is that this procedure sends only one copy of each > > packet to each egress PE, rather than sending multiple copies and > > forcing the egress PE to discard all but one. > > > > From the text above it should be (abundantly) clear that section > > 9.1.2 talks about a steady state, *not* about transients, and in a > > steady state single forwarder election with BGP as a signaling > > protocol does eliminate duplicates by itself. > > As I explained above the switching from SPT to RPT using BGP-signaling > would not generate *merely* a transient state. > > > >>> Please see Yakov's email on the clarifying changes to the text > > >>> in section 13.1. > > >> > > >> The new proposal for SA withdrawal is as follows: > > >> > > >> "Whenever as a result of receiving a withdrawal of the previousely > > >> advertise Source Tree Join C-multicast route for (C-S, C-G), the > > >> PE is going to remove the S-PMSI/I-PMSI from the outgoing interface > > >> list of the (C-S, C-G) state, the local PE MUST also withdraw > > >> the Source Active A-D route for (C-S, C-G), if such a route has > > >> been advertised." > > >> > > >> What happens if "S" stops sending and (S,G) state is deleted on the > > >> upstream PE before it receives a withdrawal of (S,G) Join route? > > >> According to the condition as stated above, the SA A-D route for > > >> (S,G) will not be withdrawn. > > > > How about the following modified text: > > > > "Whenever the PE deletes the (C-S, C-G) state, or whenever the > > PE, as a result of receiving a withdrawal of the previousely > > advertise Source Tree Join C-multicast route for (C-S, C-G), > > is going to remove the S-PMSI/I-PMSI from the outgoing interface > > list of the (C-S, C-G) state, the PE MUST also withdraw the > > Source Active A-D route for (C-S, C-G), if such a route has > > been advertised by the PE." > > This means that an upstream PE may have (S,G) Join route(s) but no (S,G) > PIM state. Doesn't this imply an inconsistency between PIM and BGP since > the (S,G) Join route (quote from [BGP-MVPN]) "'correspond' to the PIM > (S,G) state"? What makes you think that the text I proposed mean "that an upstream PE may have (S,G) Join route(s) but no (S,G) PIM state" ? Yakov. From zubair.ahmad@orange-ftgroup.com Mon Apr 6 20:03:05 2009 Return-Path: X-Original-To: l3vpn@core3.amsl.com Delivered-To: l3vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701453A6D3A for ; Mon, 6 Apr 2009 20:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.013 X-Spam-Level: **** X-Spam-Status: No, score=4.013 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, MY_CID_AND_ARIAL2=1.46, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIxFKWwfTvRH for ; Mon, 6 Apr 2009 20:02:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 5F8003A6928 for ; Mon, 6 Apr 2009 20:02:57 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 44B396802A; Tue, 7 Apr 2009 05:04:02 +0200 (CEST) Received: from PWEXCB10.usa.francetelecom.fr (unknown [10.112.0.68]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5205868002; Tue, 7 Apr 2009 05:04:01 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C9B72D.8016D120" Subject: MPLS 2009 - Call for Presentation Abstracts. Date: Mon, 6 Apr 2009 23:04:00 -0400 Message-ID: <7C5C5ED440632B4DAE601971324975F5BCE0D6@PWEXCB10.usa.francetelecom.fr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: MPLS 2009 - Call for Presentation Abstracts. Thread-Index: Acm3LIhtqAxv8uwISBWt1Ij9tksGsA== From: To: X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 03:03:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B72D.8016D120 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9B72D.8016D120" ------_=_NextPart_002_01C9B72D.8016D120 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, The MPLS 2009 International Conference, the 12th Annual International Conference on MPLS and Related Technologies, will be held October 25 - 28, 2009, in Washington, DC=2E The Technical Program Committee is soliciting an abstract summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics=2E=20 Presentations addressing new technologies and operational experience are being solicited from network equipment vendors, service/transport providers, the research community, government agencies, and enterprise users=2E=20 Some or all of these topics have been of interest to the L3VPN WG in the past, and I wanted to indicate that the call for presentation abstracts is now open=2E If you are interested in further information or want to submit a presentation abstract, please see the following URL: http://www=2Eisocore=2Ecom/mpls2009/call_for_papers/cfp=2Ehtm =20 In particular, the topics of Next Gen Multicast VPN, Deployment Experiences (Scaling, Performance & Security), IPv6 for L3VPNs, Fast Routing Convergence and High Availability for L3 VPNs are of interest=2E Regards, Zubair=20 (Member Technical Program Committee, MPLS 2009 Conference) =20 Zubair Ahmad Orange Business Services Network Technology & Architecture 13775 McLearen Road, Oak Hill VA Phone: 703-375-8152 Fax: 703-375-8099 Mobile Phone: 703-981-0892 http://www=2Eorange-business=2Ecom =20 =20 ********************************* This message and any attachments (the "message") are confidential and= intended solely for the addressees=2E=20 Any unauthorised use or dissemination is prohibited=2E Messages are susceptible to alteration=2E=20 France Telecom Group shall not be liable for the message if altered,= changed or falsified=2E If you are not the intended addressee of this message, please cancel it= immediately and inform the sender=2E ******************************** ------_=_NextPart_002_01C9B72D.8016D120 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

The MPLS 2009 International Conference, the= 12th=20 Annual International Conference on MPLS and Related Technologies, will be= held=20 October 25 - 28, 2009, in Washington, DC=2E The Technical Program Committee= is=20 soliciting an abstract summarizing a proposed presentation representing=20 original/unpublished work covering cutting-edge topics=2E

Presentations addressing new technologies= and=20 operational experience are being solicited from network equipment vendors,= =20 service/transport providers, the research community, government agencies,= and=20 enterprise users=2E

Some or all of these topics have been of= interest to=20 the L3VPN WG in the past,= and I=20 wanted to indicate that the call for presentation abstracts is now open=2E= If you=20 are interested in further information or want to submit a presentation= abstract,=20 please see the following URL:

http://www=2Eisocore=2Ecom/mpls2009/call_for_papers/cfp= =2Ehtm

In particular, the topics of Next Gen= =20 Multicast VPN, Deployment Experiences (Scaling, Performance &= =20 Security), IPv6 for L3VPNs,= Fast=20 Routing Convergence and High Availability for L3 VPNs are of=20 interest=2E

Regards,
Zubair=20
(Member=20 Technical Program Committee, MPLS 2009= Conference)

3D""

Zubair= Ahmad
Orange Business= Services
Network=20 Technology & Architecture
13775 McLearen Road, Oak Hill VA
Phone:= =20            =20 703-375-8152
Fax:         &= nbsp;       703-375-8099
Mobile=20 Phone:   703-981-0892
http://www=2Eorange-business= =2Ecom

 
*********************************
This message and any attachments (the "message") are confidential and= intended solely for the addressees=2E
Any unauthorised use or dissemination is prohibited=2E
Messages are susceptible to alteration=2E
France Telecom Group shall not be liable for the message if altered,= changed or falsified=2E
If you are not the intended addressee of this message, please cancel it= immediately and inform the sender=2E
********************************
------_=_NextPart_002_01C9B72D.8016D120-- ------_=_NextPart_001_01C9B72D.8016D120 Content-Type: image/bmp; name="Orange Logo.bmp" Content-Transfer-Encoding: base64 Content-ID: <840123402@07042009-3053> Content-Description: Orange Logo.bmp Content-Location: Orange%20Logo.bmp Qk02EwAAAAAAADYEAAAoAAAAXgAAACgAAAABAAgAAAAAAAAPAAAAAAAAAAAAAAABAAAAAQAA//// AABm/wAAZf8AAwIDAABj/wAAZP8AAGD/AFZVVgD19fUAAFn/APj4+ACLi4sA/v7+ANzq/wAAXP8A Em7/AIGBgQBaWVoAPT09APHx8QDC2v8A0tHSAMne/wC+vr4Ah4eHAImJiQAcGxwAdnV2AE1MTQDo 6OgAVZb/AARl/wDh7f8AFnH/AGppagDb29sAMTExAD2F/wD8/PwAAF7/AAsKCwC1tbUAlpaWAPb2 9gCbm5sAEhESAEZFRgAaGRoAPYn/AElISQAUExQALS0tAPPz8wDy8vIAn5+fAP39/QAYFxgACGb/ APX6/wCAf4AAZqH/ACAfIACOjo4A7OzsAOrz/wDAwMAAQEBAAJmZmQAGBQYAtNH/AN7e3gCysrIA yMfIAOLi4gAGaP8AQYn/AJSUlACMjIwA7u7uAOfx/wAWFRYAp6enALq6ugCpqakA+/v7ABpz/wAv Ly8ANjY2AJGRkQBSUVIAysnKAOrq6gAAYv8Alb7/AKjJ/wC91/8AERARANzc3ADg4OAAIyIjABAP EAArKisAAF//AB8eHwAMCwwAmJiYAF5dXgBoZ2gAcXBxAIq3/wBtpf8AJCMkAIGy/wAiISIAh7b/ AJnB/wCgoKAA5ubmANfn/wDOzc4AeHd4AJC7/wDN4P8ASEdIACEgIQApKCkADg0OAIiIiABmZWYA CGj/ACUkJQBYV1gABwYHAF9eXwDNzM0AxsXGAK7N/wC41P8AHHX/ALCwsAB7ensAfXx9ANfX1wAV FBUADQwNAPDw8ADU09QAcqn/ANXU1QACY/8ADw4PABMSEwD5/P8A0M/QAKXI/wAXFhcAHh0eAHBv cADCwcIAjbn/ACcmJwBNkf8ARo//AERDRABubW4AQof/AGKf/wBjYmMAo6OjAK6urgACZf8Akr3/ AHRzdACsy/8AXp3/ABp0/wAsKywAAFb/AGBfYAAqKSoAMn//AJKSkgDZ2dkANDQ0AJ2dnQAdHB0A ZWRlAGdmZwALaf8AOzs7ANTl/wAnev8ApKSkAAUEBQABZP8Ae7H/ADeF/wAIBwgAqsz/AMTDxAC/ 2P8AJHX/AARe/wDMy8wA/f//AABh/wCFs/8A+Pv/AEaL/wBkY2QAcqf/AEFBQQABYv8AncP/AFBP UAAObP8AU5L/AFCV/wA5gv8AOIX/AHx7fAB7rv8AC2z/ALHP/wCfxv8Axt3/ANHj/wAoeP8ALnr/ ACt+/wAtfv8Adq3/AFeX/wBfmv8AhISEAE+U/wCPvP8AA2j/AAFh/wBVmf8Aw8LDAENCQwA6iP8A CGv/AIq4/wAmJSYAC2P/AAkICQCkx/8ACgkKAC2A/wBKkP8AAWX/AOTk5ABdXF0AIXj/AAEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQVmvDknBQEBAQEBAQEBAQEAAAAAAAAAAAATa5ZkYHg3CmoyUIAM EHsKAAAjgqQAAFkLABk4Lb0jAE04MlcjPy6PL9YdAAAAAAEBAQEFAgEBAQIBAQECAgECAQICAQEC BCHGIA30gQUBAgIBAQEBAQEAAAAAAAAAAABsAxlIPgOoTZeGd2NRnWMIAAB/A1B1ADONSANYFXwR QUQ2HTGAPi+ZkigbAAAAAAEBBSdKSicCAgQCAc0EBScEAgUEAQIEZjCJ6DwAkw4nwu0nBQEBAQEA AAAAAAAAAACFGwAAkTJsMbeoNhiLpKAKAFQzEW9DAFY7EKAKALYVjGgsdFhMW4dMHAMsAAAAAAEC OXJAT3AGxBT6DjAW4V1ftHCaXIoUogk8FJ9P4Ak8diBzIQQBAQEAAAAAAAAAAAAACEdrZwMpHLM+ C1AReI8/AJ7BSCISACQ7GXw0ADU1O0TqWBJlUo8za1EKAAAAAAEObgBteQCmSwAwsYgg0IkApYgN Br8AHksArYkAnzAAbegWMAYBAQEAAAAAAAAAAAC2fQM9hUgACy1Bi/dTeAMHF7IaACkomVfcFQON dzMcWpBpkm8idANHUWWeAAAAAAFmXxYJDr7GSwDyCXNA4+gAJa0NBr8A63kgyg86eXKY2//lIQIB AQEAAAAAAAAAAAALA0EAEz53AKw4GjsACwd7VvELAE7TUWwsALhjUNOOADZjl4M1E/4aLyIKAAAA AAEGFBQJCXqIpQAlsYFuRXoApa12CckA2V2+DvZPq3IARd86eQ4BAQEAAAAAAAAAAAAsA1FGIgNS AAATEwAAAABUPwAAAAAADEeGAAArPwwAAAAIPwAAAABOEwAAAAAAAAEO3QBu0gBuJQB6rubO5HAA 2l7MHukA+x4AoaYA7KEA2CU6rg4BAQEAAAAAAAAAAAAIgJBgMk0AAAAAAAAAAAAAAAAAAAAADEI7 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEF1/iYz9UEMHZferRfT09dXG3IiToUD5WaOhbicg5tT0Bz HwXCqgEAAAAAAAAAAAAAAEmOPwAAAAAAAAAAAAAAAAAAAAAAAE4IAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEBBAZVVQYE7YHUD5XuVSEGBfwEH4o5BAWVirwfSgVmIVX2S6LD7wQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQFcBAEBAgUCBQEB BAQBAQICAgQFAQECXAUCAgEBBAavk5Nw5wYAAAAAAAAAAAA3VAoKCgwAAABJRjcmAAAdlE4ADFQM JiYAAFQ3AABJIzcAACuUYgwAAFuUkQAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQLzig853gEAAAAAAAAAAAAqMrkaOFfwABkoGi4zHT5kmxp0FX1iIqMACFc2AGpkLRIdFWWXUAcI EC2bPXQAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECBAUCBQEAAAAAAAAAAAAY A0yLUzOCSRprTlloFz1YACIyUn4jB7AANblDuGSSkRxDp1c0F0Q+bwsAu/kAAAEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAYA0YAABl+WpZTADZERv1DamQc x5BhB7AANGcquxp4G6y1E0cbM2CGSSr+ltMAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEAAAAAAAAAAAB/AxsLEHERHWhRACyEIzEtuiodSChhB2UANJwqnTgYGXEuaQOj 6kEmLi3RKkkAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAA AAAZAy4HvYSHE8VTAENEd3xZhxJsWigjhQM+KgOpUmjAR342GyhSELMVb4NIQroAAAEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAYA0YAJlaDCBxBACl7Pykk Z0KORhEdGGpZL6cKACqCPY0ASQdxfWkAqbdnQhUAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAYA2kpf0SyAAAAAAAAAAAAAAAAdSodAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAA AAAAAAAsGnE9nNZGAAAAAAAAAAAAAAAAy/UVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAKNTQ1CgAAAAAAAAAA AAAAAAAAJjQ3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA== ------_=_NextPart_001_01C9B72D.8016D120-- From mnapierala@att.com Wed Apr 8 10:22: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 0A8AF3A681D for ; Wed, 8 Apr 2009 10:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.704 X-Spam-Level: X-Spam-Status: No, score=-105.704 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, J_CHICKENPOX_61=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 BaCe63FXPO6m for ; Wed, 8 Apr 2009 10:22:56 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id C4AE53A6E53 for ; Wed, 8 Apr 2009 10:22:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mnapierala@att.com X-Msg-Ref: server-15.tower-129.messagelabs.com!1239211443!17969775!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 13587 invoked from network); 8 Apr 2009 17:24:03 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Apr 2009 17:24:03 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n38HO24I000480; Wed, 8 Apr 2009 13:24:02 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n38HNtjc000424; Wed, 8 Apr 2009 13:23:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-l3vpn-2547bis-mcast-bgp section 13 Date: Wed, 8 Apr 2009 13:23:52 -0400 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200245D62F@misout7msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: draft-ietf-l3vpn-2547bis-mcast-bgp section 13 Thread-Index: Acm2+ofNY6QhPPmUQ8KfWCYH54gazQAJcy5QAAH4SJAAFpxCsAAAOM2QADpCErAAABF3QA== From: "NAPIERALA, MARIA H, ATTLABS" To: "Yakov Rekhter" , "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, 08 Apr 2009 17:22:58 -0000 Yakov, > First of all, you are contradicting your own requirements. This is > because on one hand you say above that SPT-to-RPT should be avoided > "as long as the source is active", which means that it should be > avoided irrespective of whether there are any receivers that switch > to SPT. Yet on another hand you require MVPN "not trigger unexpected > (C-S, C-G) states in customer's network" (see Section 5 of your > draft draft-mnapierala-mvpn-part-reqt-02.txt). If indeed SPT-to-RPT > switchover is to be avoided, even if there are no more receivers > that switch to SPT, then this may result in a situation where the > MVPN customer network will have an unexpected (C-S, C-G) state. Well, you opposed this draft, so are you now supporting it? > Second, please consider the following example: >=20 > C-RP C-S > | | > CE1 CE2 > | | > PE1 PE2 >=20 > PE3 PE4 > | | > CE3 CE4 > | | > Rcv1 Rcv2 >=20 > Assume that initially DRs connected to both Rcv1 and Rcv2 join RPT > (by sending Join(C-*, C-G) towards C-RP). When the DR connected to > Rcv1 receives the first (C-S, C-G) packet, the DR switches to SPT > (by sending Join(C-S, C-G) towards C-S). However, the DR connected > to Rcv2 stays on RPT (and does not switch to SPT). Later on, Rcv1 > goes away. >=20 > Please point to the *specific* procedures in rfc4601 (section number > does not count as a "specific procedure") that would result in > preserving SPT (and specifically preserving (C-S, C-G) state on > PE2) after Rcv1 goes away. RFC 4601, section 4.6.1. "(S,G) Assert Message State Machine": AssertTrackingDesired(S,G,I) =3D (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) ) (+) ( pim_include(*,G) (-) pim_exclude(S,G) ) (-) lost_assert(*,G) (+) joins(S,G) ) ) OR (local_receiver_include(S,G,I) =3D=3D TRUE AND (I_am_DR(I) OR (AssertWinner(S,G,I) =3D=3D me))) OR ((RPF_interface(S) =3D=3D I) AND (JoinDesired(S,G) =3D=3D = TRUE)) OR ((RPF_interface(RP(G)) =3D=3D I) AND (JoinDesired(*,G) =3D=3D = TRUE) AND (SPTbit(S,G) =3D=3D FALSE)) ... Transitions from NoInfo State ... Receive Acceptable Assert with RPT bit clear AND AssertTrackingDesired(S,G,I)=3D=3DTRUE We're interested in (S,G) Asserts, either because I is a downstream interface for which we have (S,G) or (*,G) forwarding state, or because I is the upstream interface for S and we have (S,G) forwarding state. The received assert has a better metric than our own, so we do not win the Assert. We transition to "I am Assert Loser" and perform Actions A6 (below). ... (S,G) Assert State machine Actions ... A6: Store new assert winner as AssertWinner(S,G,I) and assert winner metric as AssertWinnerMetric(S,G,I). Set Assert Timer to Assert_Time. If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) =3D=3D = true) set SPTbit(S,G) to TRUE. >=20 > > As Rahul described in his e-mail (and I agree with it), the only > > solution to avoid packet loss is to delay sending (S,G) Prune towards > > the source "S". The delay of this Prune will have to be long enough > to > > give time for the (*,G) Join to be delivered to C-RP: > > - -First, this delay has to be long enough for Source-Active A-D > route to > > be withdrawn and for egress PEs to change their forwarding to receive > > "S" traffic on RPT. This might take seconds, especially if multiple > RRs > > are in the path, which itself poses a question whether the amount of > > duplicates will be acceptable. > > > > - -But more importantly this delay cannot be just in seconds but > should > > last several minutes. PIM allows for, at least, 210 sec (3.5 min) for > an > > interface to time out, taking into account that some Join(s) might > not > > be delivered. The switchback to RPT should allow similar amount of > time > > before pruning (S,G) since the (*,G) Join that performs the > switchback > > to RPT is being send to customer's network over which SP has no > control, > > and there is no guarantee that the 1st (*,G) Join will be delivered. > > Since the source "S" can be active and there are active listeners, > its > > flow cannot be interrupted. The reliance on discarding duplicates in > > this case is necessary (as Rahul correctly stated). > > Hence, it is quite clear that multicast forwarding with BGP-signaling > > requires "strong" or "UMH-based" RPF check. >=20 > Your last claim above is incorrect. Why? >=20 > > > >> There are other side effects of single forwarder election and > > > >> BGP-signaling (I will send an example in a separate e-mail). > > > > The other side effect of single forwarder election and BGP-signaling > is > > that it might trigger different trees than VPN customer expects. Here > is > > one example: > > > > RP---R3 > > | > > | > > R1---PE1-- ... --PE2---\ > > ... S > > R2---PE4-- ... --PE3---/ > > > > > > Source "S" is dually connected to PE2 and PE3. > > Assume that PE2's, PE1's, and PE4's best path to "S" is via PE2. > > > > - -RP sends (S,G) Join to PE2 and PE2 sends Join directly to "S" > > - -R1, R2, R3 send (*,G) Joins towards RP > > - -R1, R2, R3 switch to SPT and single forwarder election chooses PE3 > as > > the upstream PE >=20 > Let me remind you of the following text from Section 5.1.3 of > draft-ietf-l3vpn-2547bis-mcast-08.txt >=20 > Another procedure, which SHOULD be implemented, is to use the > Installed UMH Route as the Selected UMH Route. >=20 > in which case PE2 (and not PE3, as you claim above) will be chosen as > the forwarder (as PE2's, PE1's, and PE4's best path to "S" is via PE2, > and not via PE3), and so the rest does not apply. If "Installed UMH Route" procedure is chosen and MI-PMSI is used it would generate duplicates if say PE1 choose PE2 as UMH and PE3 chooses PE4 as UMH. This would not be the case in PIM since the Assert would choose either PE3 or PE4 as a single forwarder. =20 =20 > > Hence, SPT will be as follows: > > > > S > > / \ > > R3---RP---PE2--PE3---PE4---R2 > > | > > PE1 > > | > > R1 > > > > while VPN customer expected SPT not to include S--PE3 path, as > follows: > > > > S > > | > > R3---RP---PE2---PE4---R2 > > | > > PE1 > > | > > R1 > > > > This is an issue because VPN customers expect multicast to follow VRF > > routing policy. > > > > When PIM is used as a signaling protocol the SPT will be as expected > > because there will be no (S,G) Joins send to PE3 and thus there will > be > > no Asserts. >=20 > As you know quite well, use of PIM for C-multicast signaling, as > specified in draft-ietf-l3vpn-2547bis-mcast-08.txt, can result > in a situation where multicast will *not* follow the VRF routing > policy, and the SPT may not be "as expected". >=20 > Using your example above, let's assume that that PE1's best path > to "S" is via PE2, but PE4's best path to "S" is via PE3. In this > case Asserts will result in either PE2 or PE3 being the forwarder, > which in turn will result in violation of the VRF routing policy > on either PE1 or PE4, and the SPT *not* being "as expected". My example meant to illustrate something different, namely, that with Assert, when all PEs/VRFs have the same routing policy, the correct upstream PE will be chosen. This is not the case with single forwarder election and BGP-signaling.=20 > > > > > > How about the following modified text: > > > > > > "Whenever the PE deletes the (C-S, C-G) state, or whenever the > > > PE, as a result of receiving a withdrawal of the previousely > > > advertise Source Tree Join C-multicast route for (C-S, C-G), > > > is going to remove the S-PMSI/I-PMSI from the outgoing > interface > > > list of the (C-S, C-G) state, the PE MUST also withdraw the > > > Source Active A-D route for (C-S, C-G), if such a route has > > > been advertised by the PE." > > > > This means that an upstream PE may have (S,G) Join route(s) but no > (S,G) > > PIM state. Doesn't this imply an inconsistency between PIM and BGP > since > > the (S,G) Join route (quote from [BGP-MVPN]) "'correspond' to the PIM > > (S,G) state"? >=20 > What makes you think that the text I proposed mean "that an upstream PE > may have (S,G) Join route(s) but no (S,G) PIM state" ? The first condition "Whenever the PE deletes the (C-S, C-G) state [...]" implies the creation of such a state (i.e., existence of (S,G) join route but no (S,G) PIM state) on upstream PE. Maria From mnapierala@att.com Wed Apr 8 11:50:14 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 8E9263A6E8F for ; Wed, 8 Apr 2009 11:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.273 X-Spam-Level: X-Spam-Status: No, score=-106.273 tagged_above=-999 required=5 tests=[AWL=0.326, 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 o8UA2QZsnDKK for ; Wed, 8 Apr 2009 11:50:13 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 570A83A6E6E for ; Wed, 8 Apr 2009 11:50:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mnapierala@att.com X-Msg-Ref: server-15.tower-167.messagelabs.com!1239216677!8497472!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 19348 invoked from network); 8 Apr 2009 18:51:18 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Apr 2009 18:51:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n38IpHTi000906 for ; Wed, 8 Apr 2009 14:51:17 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n38IpDe8000861 for ; Wed, 8 Apr 2009 14:51:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 11.4 Date: Wed, 8 Apr 2009 14:51:13 -0400 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200245D71B@misout7msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 11.4 Thread-Index: Acm4er3Kedyf+ocHS1eReeskvjY6BAAACV3g From: "NAPIERALA, MARIA H, ATTLABS" To: "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, 08 Apr 2009 18:50:14 -0000 Question on section 11.4 of draft-ietf-l3vpn-2547bis-mcast-bgp-06 : How does the following (quote from section 11.4): "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. reduces route churn?=20 Maria From yakov@juniper.net Wed Apr 8 11:57: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 85DC93A6E77 for ; Wed, 8 Apr 2009 11:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 P2MAKURT9XYf for ; Wed, 8 Apr 2009 11:57:26 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 38A8B28C1DB for ; Wed, 8 Apr 2009 11:57:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSdzz2eYVfOPfQrfBaz5bRpNfPuVzndAD@postini.com; Wed, 08 Apr 2009 11:58:34 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Wed, 8 Apr 2009 11:56:55 -0700 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, 8 Apr 2009 11:56:55 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Apr 2009 11:56:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 11:56:54 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n38IusM11716; Wed, 8 Apr 2009 11:56:54 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200904081856.n38IusM11716@magenta.juniper.net> To: "NAPIERALA, MARIA H, ATTLABS" Subject: Re: draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 11.4 In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A200245D71B@misout7msgusr7e.ugd.att.com> References: <2F1DE4DFCFF32144B771BD2C246E6A200245D71B@misout7msgusr7e.ugd.att.com> X-MH-In-Reply-To: "NAPIERALA, MARIA H, ATTLABS" message dated "Wed, 08 Apr 2009 14:51:13 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32198.1239217014.1@juniper.net> Date: Wed, 8 Apr 2009 11:56:54 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 08 Apr 2009 18:56:54.0161 (UTC) FILETIME=[C887F010:01C9B87B] Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 18:57:27 -0000 Maria, > Question on section 11.4 of draft-ietf-l3vpn-2547bis-mcast-bgp-06 > : > > How does the following (quote from section 11.4): > > "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. > > reduces route churn? By aggregating C-multicast routes. Yakov. From mnapierala@att.com Wed Apr 8 11:59: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 0AB8E3A6EAC for ; Wed, 8 Apr 2009 11:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.003 X-Spam-Level: X-Spam-Status: No, score=-106.003 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 VRQmPSWwUiIM for ; Wed, 8 Apr 2009 11:59:05 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 385BE3A6EA9 for ; Wed, 8 Apr 2009 11:59:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mnapierala@att.com X-Msg-Ref: server-8.tower-161.messagelabs.com!1239217210!17808289!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 10853 invoked from network); 8 Apr 2009 19:00:11 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-8.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Apr 2009 19:00:11 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n38J0AcN006983; Wed, 8 Apr 2009 15:00:10 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n38J09iw006968; Wed, 8 Apr 2009 15:00:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 11.4 Date: Wed, 8 Apr 2009 15:00:08 -0400 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A200245D73D@misout7msgusr7e.ugd.att.com> In-Reply-To: <200904081856.n38IusM11716@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 11.4 Thread-Index: Acm4fAksNCBVSgA3Rti/HwZ+Js++0AAABe9g References: <2F1DE4DFCFF32144B771BD2C246E6A200245D71B@misout7msgusr7e.ugd.att.com> <200904081856.n38IusM11716@magenta.juniper.net> From: "NAPIERALA, MARIA H, ATTLABS" To: "Yakov Rekhter" Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 18:59:06 -0000 What does it mean "aggregating C-multicast routes"? Maria > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Wednesday, April 08, 2009 2:57 PM > To: NAPIERALA, MARIA H, ATTLABS > Cc: L3VPN > Subject: Re: draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 11.4 >=20 > Maria, >=20 > > Question on section 11.4 of draft-ietf-l3vpn-2547bis-mcast-bgp-06 > > 06.txt> : > > > > How does the following (quote from section 11.4): > > > > "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. > > > > reduces route churn? >=20 > By aggregating C-multicast routes. >=20 > Yakov. From robert@raszuk.net Wed Apr 8 13:25: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 CEE883A689E for ; Wed, 8 Apr 2009 13:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN2pm-TVcKLK for ; Wed, 8 Apr 2009 13:25:34 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id A4EE43A6A40 for ; Wed, 8 Apr 2009 13:25:33 -0700 (PDT) Received: (qmail 32384 invoked by uid 399); 8 Apr 2009 20:26:35 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.24.12.89) by mail37.opentransfer.com with SMTP; 8 Apr 2009 20:26:35 -0000 Message-ID: <49DD0879.7070100@raszuk.net> Date: Wed, 08 Apr 2009 13:26:33 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 11.4 References: <2F1DE4DFCFF32144B771BD2C246E6A200245D71B@misout7msgusr7e.ugd.att.com> <200904081856.n38IusM11716@magenta.juniper.net> In-Reply-To: <200904081856.n38IusM11716@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Wed, 08 Apr 2009 20:25:34 -0000 Hi Yakov, Do you mean that by aggregation of C-multicast routes that you are going to propose modification to SAFI independent route reflector code which today does advertise the best path among received for a given net regardless of the next hop policy ? Thx, R. > Maria, > >> Question on section 11.4 of draft-ietf-l3vpn-2547bis-mcast-bgp-06 >> : >> >> How does the following (quote from section 11.4): >> >> "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. >> >> reduces route churn? > > By aggregating C-multicast routes. > > Yakov. > > From tme@multicasttech.com Mon Apr 13 18:42: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 F22793A6A06 for ; Mon, 13 Apr 2009 18:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.979 X-Spam-Level: X-Spam-Status: No, score=-102.979 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, 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 pvTFHhbYi0cB for ; Mon, 13 Apr 2009 18:42:45 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 50A653A6800 for ; Mon, 13 Apr 2009 18:42:45 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 5B1A439456EA for ; Mon, 13 Apr 2009 19:03:57 -0400 (EDT) Message-Id: From: Marshall Eubanks To: l3vpn@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: test, please ignore Date: Mon, 13 Apr 2009 19:03:57 -0400 X-Mailer: Apple Mail (2.930.3) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 01:42:46 -0000 test, please ignore From danny@tcb.net Mon Apr 20 15:46: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 BC8903A6941 for ; Mon, 20 Apr 2009 15:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.329 X-Spam-Level: X-Spam-Status: No, score=0.329 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_20=-0.74, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEokK5Hf8q8E for ; Mon, 20 Apr 2009 15:46:40 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 0D1303A695C for ; Mon, 20 Apr 2009 15:46:40 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 25A182684EA; Mon, 20 Apr 2009 16:47:56 -0600 (MDT) Received: from jchouinard-sim-104.eng.ellacoya.com (97-122-117-204.hlrn.qwest.net [97.122.117.204]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l3vpn@ietf.org; Mon, 20 Apr 2009 16:47:56 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.117.204; client-port=60694; syn-fingerprint=65535:55:1:64:M1408,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: l3vpn@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: L3VPN @IETF 74 Draft Minutes Date: Mon, 20 Apr 2009 16:47:55 -0600 References: X-Mailer: Apple Mail (2.930.3) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 22:46:40 -0000 On Mar 31, 2009, at 10:47 AM, Danny McPherson wrote: > http://www.ietf.org/proceedings/09mar/minutes/l3vpn.txt Folks, Last call for comments on these minutes ended about 10 days ago. I'm surprised the person indicated here, or no one in the room, knows who this is under item 3: "- Questioner Male from Cisco: How would this work with PIM-based solutions?" Beyond that, I've got a couple corrections and plan to post the final minutes later this week. Last chance for input. Thanks! -danny From dward@cisco.com Thu Apr 23 14:06: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 15CC13A7312; Thu, 23 Apr 2009 14:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4VnoSDy0qf9M; Thu, 23 Apr 2009 14:06:05 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C3E063A72BE; Thu, 23 Apr 2009 14:06:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,237,1238976000"; d="scan'208,217";a="42590613" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Apr 2009 21:07:22 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3NL7MYe006773; Thu, 23 Apr 2009 17:07:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3NL7MS4025418; Thu, 23 Apr 2009 21:07:22 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 17:07:22 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 17:07:21 -0400 Message-Id: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> From: David Ward To: softwires@ietf.org, l3vpn@ietf.org, pwe3@ietf.org, Ralph Droms , Jari Arkko Content-Type: multipart/alternative; boundary=Apple-Mail-6-220634604 Mime-Version: 1.0 (Apple Message framework v930.3) Subject: WG LC softwire-lb Date: Thu, 23 Apr 2009 16:07:19 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Apr 2009 21:07:21.0896 (UTC) FILETIME=[7E6BC280:01C9C457] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1275; t=1240520842; x=1241384842; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20WG=20LC=20softwire-lb |Sender:=20 |To:=20softwires@ietf.org,=20l3vpn@ietf.org,=20pwe3@ietf.or g,=0A=20=20=20=20=20=20=20=20Ralph=20Droms=20,=20Jari=20Arkko=20; bh=YHBPf2MZluD4AJ4bzzOApyLxmi6XzDJ/2uuyDX1GuMw=; b=h5P3sauBsJ6RGQ0ukhh9v2mevtTYsMBSqZbXbUBD+Qd2SmIfmP06153evy J7sdgI2PeADwXT9cdQ33mz4CytTxnCMu8U+JwPZQdoYQshZl/I8DGeDItrw9 Nl8Lgmii1I; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Mailman-Approved-At: Thu, 23 Apr 2009 14:40:19 -0700 Cc: Alain Durand , Carlos Pignataro , David Ward , Clarence Filsfils X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 21:06:06 -0000 --Apple-Mail-6-220634604 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All - Following the last IETF meeting all comments have been addressed in: http://tools.ietf.org/html/draft-ietf-softwire-lb-02 The authors have requested a WG LC and I have added L3VPN and PWE3 that may be interested and have comments on the technology. Please send back all comments by May 7, 2009. Thanks DWard, Alain --Apple-Mail-6-220634604 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit All -
Following the last IETF meeting all comments have been addressed in:



The authors have requested a WG LC and I have added L3VPN and PWE3 that may be interested and have comments on the technology. Please send back all comments by May 7, 2009.

Thanks

DWard, Alain
--Apple-Mail-6-220634604-- From robert@raszuk.net Fri Apr 24 01:37: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 2B1513A69C2 for ; Fri, 24 Apr 2009 01:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5PiseV5ZR8j for ; Fri, 24 Apr 2009 01:37:11 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id D46B03A698D for ; Fri, 24 Apr 2009 01:37:10 -0700 (PDT) Received: (qmail 3738 invoked by uid 399); 24 Apr 2009 08:31:48 -0000 Received: from unknown (HELO ?172.30.29.64?) (80.187.215.123) by mail37.opentransfer.com with SMTP; 24 Apr 2009 08:31:48 -0000 Message-ID: <49F178ED.2080905@raszuk.net> Date: Fri, 24 Apr 2009 01:31:41 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Ward Subject: Re: WG LC softwire-lb References: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> In-Reply-To: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Carlos Pignataro , l3vpn@ietf.org, Clarence Filsfils , Ralph Droms , Alain Durand , Jari Arkko , softwires@ietf.org, pwe3@ietf.org 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: Fri, 24 Apr 2009 08:37:11 -0000 Hi David, Perhaps I may have missed the discussion on this in the other WGs but I have two comments/questions ... * Why the decision on enhancing the load balancing capability of IP encapsulated packet has to be signaled as opposed to be a local matter of the ingress router performing encapsulation ? * Reg use of GRE key for the purpose of load balancing I must say that GRE key has already been proposed in number of solutions today. Therefor overloading more on it may be impractical. Did authors analyzed use of Sequence Numbers in GRE header instead for the purpose of increasing effectiveness of load-balancing by the transit nodes ? Cheers, R. > All - > Following the last IETF meeting all comments have been addressed in: > > http://tools.ietf.org/html/draft-ietf-softwire-lb-02 > > The authors have requested a WG LC and I have added L3VPN and PWE3 that > may be interested and have comments on the technology. Please send back > all comments by May 7, 2009. > > Thanks > > DWard, Alain From root@core3.amsl.com Mon Apr 27 07:45:01 2009 Return-Path: X-Original-To: l3vpn@ietf.org Delivered-To: l3vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 764EC28C11C; Mon, 27 Apr 2009 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090427144501.764EC28C11C@core3.amsl.com> Date: Mon, 27 Apr 2009 07:45:01 -0700 (PDT) Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 14:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs Author(s) : R. Aggarwal, et al. Filename : draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt Pages : 61 Date : 2009-04-27 This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-27073025.I-D@ietf.org> --NextPart-- From robert@raszuk.net Mon Apr 27 08:05:15 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 373673A6FAB for ; Mon, 27 Apr 2009 08:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0kFVDXgr8XN for ; Mon, 27 Apr 2009 08:05:14 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 4671E3A6FB1 for ; Mon, 27 Apr 2009 08:05:14 -0700 (PDT) Received: (qmail 31573 invoked by uid 399); 27 Apr 2009 15:06:34 -0000 Received: from unknown (HELO ?192.168.1.54?) (83.5.245.124) by mail37.opentransfer.com with SMTP; 27 Apr 2009 15:06:34 -0000 Message-ID: <49F5C9F5.20004@raszuk.net> Date: Mon, 27 Apr 2009 08:06:29 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: l3vpn@ietf.org Subject: Re: I-D Action:draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt References: <20090427144501.764EC28C11C@core3.amsl.com> In-Reply-To: <20090427144501.764EC28C11C@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 27 Apr 2009 15:05:15 -0000 Hi, I have few question on section 11.4 which has not been addressed by authors yet. Hence a BGP Route Reflector or ASBR that receives multiple such routes with the same NLRI will re-advertise only one of these routes to other BGP speakers. ... 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. Question 1: * If we are considering route reflection as defined in RFC4456 to what value such described in section 11.4 route reflector will set the ORIGINATOR_ID ? - If it will not set it to the best path as it would be per default bgp behavior to which reflected path it would be set ? First received ? - If it will set it to the best bgp path among those carrying the same set of C-multicast routes spec should clarify that each subsequent new best path election will result in new advertisement of same C-multicast route. Question 2: * When route reflector will withdraw advertised C-multicast route ? - Would it withdraw only when last valid path attached to given C-multicast route is withdrawn from it by the PE ? - Would it need to send implicit withdraw when best path get's withdrawn and new path selected as best to reflect to ORIGINATOR_ID value ? Thx, R. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. > > > Title : BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs > Author(s) : R. Aggarwal, et al. > Filename : draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt > Pages : 61 > Date : 2009-04-27 > From tme@americafree.tv Mon Apr 27 13:59: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 9E7B528C141 for ; Mon, 27 Apr 2009 13:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXxQ1Na1gZ3Y for ; Mon, 27 Apr 2009 13:59:51 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id ECC5028C166 for ; Mon, 27 Apr 2009 13:59:50 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 51A473AEA286 for ; Mon, 27 Apr 2009 17:01:11 -0400 (EDT) Message-Id: From: Marshall Eubanks To: l3vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Fwd: 75th IETF - Working Group/BOF Scheduling Date: Mon, 27 Apr 2009 17:01:09 -0400 References: <20090427145627.971283A6CBC@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Mon, 27 Apr 2009 14:28:01 -0700 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, 27 Apr 2009 20:59:52 -0000 Note well... Begin forwarded message: > From: IETF Agenda > Date: April 27, 2009 10:56:27 AM EDT > To: Working Group Chairs > Cc: irsg@isi.edu, bofchairs@ietf.org > Subject: 75th IETF - Working Group/BOF Scheduling > > ----------------------------------------------------------------- > 75th IETF =96 Stockholm, Sweden > Meeting Dates: July 26-31, 2009 > Host: .SE > ----------------------------------------------------------------- > IETF meetings start Monday morning and run through Friday mid-=20 > afternoon > (15:15). > > We are accepting scheduling requests for all Working Groups and BOFs > starting. The milestones and deadlines for scheduling-related =20 > activities > are as follows: > > NOTE: cutoff dates are subject to change. > > May 25, Monday - Cutoff date for requests to schedule Working Group > meetings and for preliminary BOF proposals to ADs at 17:00 PDT (24:00 > UTC/GMT). > June 8, Monday - Cutoff date for requests to Area Directors to =20 > schedule > BOFs at 17:00 PDT (24:00 UTC/GMT). > June 15, Monday - Cutoff date for Area Directors to approve BOFs at =20= > 17:00 > PDT (24:00 UTC/GMT). > June 19, Friday - Preliminary agenda published for comment. > July 1, Wednesday - Cutoff date for requests to reschedule Working =20 > Group > and BOF meetings 17:00 PDT (24:00 UTC/GMT). > July 6, Monday - Final agenda to be published. > July 15, Wednesday - Draft Working Group agendas due by 17:00 PT =20 > (24:00 > UTC/GMT). > July 20, Monday - Revised Working Group agendas due by 17:00 PT (24:00 > UTC/GMT). > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions using =20= > the > "IETF Meeting Session Request Tool," a Web-based tool for submitting =20= > all > of the information that the Secretariat requires to schedule your > sessions. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > Please include the acronym of your BOF in the subject line of the =20 > message, > and include all of the information specified in item (4) of =20 > "Requesting > Meeting Sessions at IETF Meetings" in the body. (This document is > included below.) > > Submitting Session Agendas > > For the convenience of meeting attendees, we ask that you submit the > agendas for your Working Group sessions as early as possible. Draft > Working Group agendas are due Wednesday, July 15 by 17:00 PDT (24:00 > UTC/GMT). Revised Working Group agendas are due no later than Monday, > July 20 at 17:00 PDT (24:00 UTC/GMT). The proposed agenda for a BOF > session should be submitted along with your request for a session. =20= > Please > be sure to copy your Area Director on that message. > > Please submit the agendas for your Working Group sessions using the =20= > "IETF > Meeting Materials Management Tool," a Web-based tool for making your > meeting agenda, minutes, and presentation slides available to the > community before, during, and after an IETF meeting. If you are a BOF > chair, then you may use the tool to submit a revised agenda as well as > other materials for your BOF once the BOF has been approved. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi > > Additional information about this tool is available at: > > http://www.ietf.org/instructions/meeting_materials_tool.html > > Agendas submitted via the tool will be available to the public on the > "IETF Meeting Materials" Web page as soon as they are submitted. > > The URL for the "IETF 75 Meeting Materials" Web page is: > > = https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D75= > > If you are a Working Group chair, then you already have accounts on =20= > the > "IETF Meeting Session Request Tool" and the "IETF Meeting Materials > Management Tool." The same User ID and password will work for both =20= > tools. > If you are a BOF chair who is not also a Working Group chair, then =20= > you > will be given an account on the "IETF Meeting Materials Management =20 > Tool" > when your BOF has been approved. If you require assistance in using > either tool, or wish to report a bug, then please send a message to: > ietf-action@ietf.org. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience, comprehensive information on requesting meeting > sessions at IETF 75 is presented below: > > 1. Requests to schedule Working Group sessions should be submitted =20 > using > the "IETF Meeting Session Request Tool," a Web-based tool for =20 > submitting > all of the information required by the Secretariat to schedule your > sessions. The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > If you require an account on this tool, or assistance in using it, =20 > then > please send a message to ietf-action@ietf.org. If you are unable to =20= > use > the tool, then you may send your request via e-mail to =20 > agenda@ietf.org, > with a copy to the appropriate Area Director(s). > > Requests to schedule BOF sessions must be sent to agenda@ietf.org =20 > with a > copy to the appropriate Area Director(s). > > When submitting a Working Group or BOF session request by e-mail, =20 > please > include the Working Group or BOF acronym in the Subject line. > > 2. BOFs will NOT be scheduled unless the Area Director(s) approved > request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, =20 > CHAIR(S) > NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL > DESCRIPTION, and the information requested in (4) below. (Please =20 > read the > BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before > requesting a session for a BOF.) > > 3. A Working Group may request either one or two sessions. If your > Working Group requires more than two sessions, then your request =20 > must be > approved by an Area Director. Additional sessions will be assigned, =20= > based > on availability, after Wednesday, July 1 at 17:00 PDT (24:00 UTC/=20 > GMT), the > cut-off date for requests to reschedule a session. > > 4. You MUST provide the following information before a Working Group =20= > or > BOF session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance (figures from the 74th IETF meeting are > included at the end of this message): > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 1 1/2 hours > - 2 hours > - 2 1/2 hours > > For more information on scheduling Working Group and BOF sessions, =20 > please > refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and =20 > Procedures" > (http://www.ietf.org/rfc/rfc2418.txt). > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience please find here a list of the IETF Area =20 > Directors > with their e-mail addresses: > > IETF Chair > Russ Housley > > Applications Area (app) > Lisa Dusseault > Alexey Melnikov > > Internet Area (int) > Jari Arkko > Ralph Droms > > Operations & Management Area (ops) > Ronald Bonica > Dan Romascanu > > Real-time Applications and Infrastructure Area (rai) > Cullen Jennings > Robert Sparks > > Routing Area (rtg) > Ross Callon > Adrian Farrel > > Security Area (sec) > Pasi Eronen > Tim Polk > > Transport Area (tsv) > Lars Eggert > Magnus Westerlund > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 74th IETF Meeting Attendance Number > > 6ai 189 > 6lowpan NO SHEETS > 6man 138 > alto 112 > ancp 21 > apparea 92 > atoca 77 > autoconf 34 > avt 77 > avt (2nd session) 65 > behave 150 > behave (2nd session) 116 > bliss 64 > bmwg 23 > capwap 16 > ccamp 76 > ccamp (2nd session) 55 > csi 16 > dccp 18 > dhc 50 > dime 31 > dkim 46 > dnsop 90 > drinks 69 > dtnrg 44 > ecrit 80 > emu 35 > fecframe 17 > forces 20 > geopriv 68 > grow 75 > hiprg 38 > hokey 40 > httpbis 25 > idnabis 70 > idnabis (2nd session) 41 > idr 127 > intarea 207 > ipfix 32 > ippm 46 > ipsecme 44 > isms 25 > keyprov 24 > kitten 11 > krb-wg 26 > l2vpn 149 > l3vpn 48 > ledbat 30 > lisp 176 > manet 45 > mboned 37 > mediactrl 47 > mext 96 > mif 68 > mip4 35 > mipshop 57 > mmox 77 > mmusic 75 > morg 15 > mpls 144 > mpls (2nd session) 135 > msec 30 > nea 28 > netconf 39 > netext 68 > netmod 25 > netmod (2nd session) 32 > nfsv4 22 > nsis 23 > oauth 105 > opsarea 86 > opsec 24 > ospf 34 > p2prg 99 > p2psip 71 > pce 63 > pcn 24 > pim 41 > pkix 50 > pmol 27 > pre8prob 44 > pwe3 115 > radext 19 > rtgarea 122 > rmt 12 > roll 69 > rrg 106 > rtgwg 112 > saag 116 > sasl 24 > savi 60 > shara 155 > sidr 77 > sieve 17 > simple 69 > sip 126 > sip (2nd session) 117 > sipping 92 > softwire 73 > speermint 63 > storm 14 > tcpm 33 > tcpm (2nd session) 59 > tictoc 37 > tls 44 > trill 55 > tsvarea 72 > tsvwg 47 > v6ops 126 > v6ops (second session) 65 > vcarddav 18 > xcon 48 > xmpp2 86 > yam 41 > Regards Marshall Eubanks CEO / AmericaFree.TV From yakov@juniper.net Tue Apr 28 14:49:49 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 A56D23A686C for ; Tue, 28 Apr 2009 14:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 EqCTl5HUNTFg for ; Tue, 28 Apr 2009 14:49:48 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id 2D4FC3A67EF for ; Tue, 28 Apr 2009 14:49:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob59.postini.com ([64.18.6.12]) with SMTP ID DSNKSfd6TWh50pS6oTVg0hlTJjvlmkNlNZ8Z@postini.com; Tue, 28 Apr 2009 14:51:10 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 28 Apr 2009 14:37:16 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 14:37:15 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 14:37:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 14:37:14 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3SLbEM72426; Tue, 28 Apr 2009 14:37:14 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200904282137.n3SLbEM72426@magenta.juniper.net> To: "NAPIERALA, MARIA H, ATTLABS" Subject: Re: draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 11.4 In-Reply-To: <2F1DE4DFCFF32144B771BD2C246E6A200245D73D@misout7msgusr7e.ugd.att.com> References: <2F1DE4DFCFF32144B771BD2C246E6A200245D71B@misout7msgusr7e.ugd.att.com> <200904081856.n38IusM11716@magenta.juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A200245D73D@misout7msgusr7e.ugd.att.com> X-MH-In-Reply-To: "NAPIERALA, MARIA H, ATTLABS" message dated "Wed, 08 Apr 2009 15:00:08 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27151.1240954634.1@juniper.net> Date: Tue, 28 Apr 2009 14:37:14 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 28 Apr 2009 21:37:14.0974 (UTC) FILETIME=[7F3E7FE0:01C9C849] 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: Tue, 28 Apr 2009 21:49:49 -0000 Maria, Maria: How does the following (quote from section 11.4): Maria: Maria: To further reduce the routing churn due to C-multicast routes changes Maria: a Route Reflector that re-advertises a C-multicast route SHOULD set Maria: the Next Hop field of the MP_REACH_NLRI attribute of the route to an Maria: IP address of the Route Reflector. Likewise, an ASBR that re- Maria: advertises a C-multicast route SHOULD set the Next Hop field of the Maria: MP_REACH_NLRI attribute of the route to an IP address of the ASBR. Maria: Maria: reduces route churn? Yakov: By aggregating C-multicast routes. Maria: What does it mean "aggregating C-multicast routes"? Since in the context of this document C-multicast routes are carried in BGP, it should be abundantly clear that in the context of this document "aggregating C-multicast routes" means "aggregating BGP routes". The term "aggregating BGP routes" is covered in rfc4271 (BGP-4) section 9.2.2.2. Yakov. From robert@raszuk.net Tue Apr 28 15:09: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 F0E263A67BD for ; Tue, 28 Apr 2009 15:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vqDXuqqX1pv for ; Tue, 28 Apr 2009 15:09:40 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 0538F3A686C for ; Tue, 28 Apr 2009 15:09:39 -0700 (PDT) Received: (qmail 21727 invoked by uid 399); 28 Apr 2009 22:11:00 -0000 Received: from unknown (HELO ?192.168.1.53?) (83.24.27.31) by mail37.opentransfer.com with SMTP; 28 Apr 2009 22:11:00 -0000 Message-ID: <49F77EF3.1040306@raszuk.net> Date: Tue, 28 Apr 2009 15:10:59 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 11.4 References: <2F1DE4DFCFF32144B771BD2C246E6A200245D71B@misout7msgusr7e.ugd.att.com> <200904081856.n38IusM11716@magenta.juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A200245D73D@misout7msgusr7e.ugd.att.com> <200904282137.n3SLbEM72426@magenta.juniper.net> In-Reply-To: <200904282137.n3SLbEM72426@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Tue, 28 Apr 2009 22:09:41 -0000 Hi Yakov, > Since in the context of this document C-multicast routes are carried > in BGP, it should be abundantly clear that in the context of this > document "aggregating C-multicast routes" means "aggregating BGP > routes". The term "aggregating BGP routes" is covered in rfc4271 > (BGP-4) section 9.2.2.2. You are incorrect about "abundantly clear" part. The section 9 of base BGP spec RFC4271 as well as section 8 of RFC4456 describing BGP route reflection behavior has been modified between lines to fit your new model of "C-multicast routes aggregation" by the route reflector. [Some of the details are listed in my former mail to this WG]. Those modifications to standard BGP behavior (as per the above RFCs) has not been explained to the WG and before we proceed with this draft any further I would request that such omission and changes to BGP will be addressed by new document in IDR WG proposing new model of BGP route reflection for the purpose of reflecting and aggregating C-multicast routes. Cheers, R. > Maria, > > Maria: How does the following (quote from section 11.4): > Maria: > Maria: To further reduce the routing churn due to C-multicast routes changes > Maria: a Route Reflector that re-advertises a C-multicast route SHOULD set > Maria: the Next Hop field of the MP_REACH_NLRI attribute of the route to an > Maria: IP address of the Route Reflector. Likewise, an ASBR that re- > Maria: advertises a C-multicast route SHOULD set the Next Hop field of the > Maria: MP_REACH_NLRI attribute of the route to an IP address of the ASBR. > Maria: > Maria: reduces route churn? > > Yakov: By aggregating C-multicast routes. > > Maria: What does it mean "aggregating C-multicast routes"? > > Since in the context of this document C-multicast routes are carried > in BGP, it should be abundantly clear that in the context of this > document "aggregating C-multicast routes" means "aggregating BGP > routes". The term "aggregating BGP routes" is covered in rfc4271 > (BGP-4) section 9.2.2.2. > > Yakov. From shane@castlepoint.net Tue Apr 28 19:18: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 00F713A68BD; Tue, 28 Apr 2009 19:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.743 X-Spam-Level: X-Spam-Status: No, score=-0.743 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqI0L2YAnovk; Tue, 28 Apr 2009 19:18:20 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 3C6C33A6CB7; Tue, 28 Apr 2009 19:18:20 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0E5672684EA; Tue, 28 Apr 2009 20:19:42 -0600 (MDT) Received: from mbpw.castlepoint.net (71-215-65-246.hlrn.qwest.net [71.215.65.246]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 28 Apr 2009 20:19:41 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.65.246; client-port=3438; syn-fingerprint=65535:55:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Message-Id: <62A59F1D-C92B-49A3-A1DC-25676E83B855@castlepoint.net> From: Shane Amante To: l3vpn@ietf.org, l2vpn@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Poll on BGP IPv4 Address Specific Extended Community Date: Tue, 28 Apr 2009 20:19:26 -0600 X-Mailer: Apple Mail (2.930.3) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 02:18:21 -0000 Hello, It appears as if IANA has allocated an "IPv4 Address Specific" BGP Extended Community to two different Internet Drafts, which are on their way to becoming Proposed Standards. 1) The Ext Community 0x010A was allocated as an "IPv4 address- specific Layer-2 VPN Identifier" in the following draft: http://tools.ietf.org/html/draft-ietf-l2vpn-signaling-08#section-6 2) The Ext Community 0x010A was *also* allocated as "VRF Route Import" in the following draft: http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-bgp-06#section-18 The chairs of L3VPN & L2VPN intend to work with IANA to correct this error and ensure a unique Ext Community value is assigned to both drafts. We would like to ask those who have implemented either 'draft- ietf-l2vpn-signaling' or 'draft-ietf-l3vpn-2547bis-mcast-bgp' to inform us of what is their status of their implementation. Our intent is to then ask IANA to assign a new Extended Community for the draft that has the least number of implementations. Your response may be public or private. Private responses should go to either or both WG chairs in L3VPN or L2VPN. The deadline for this poll is ~3 weeks and will close on 5/22/2009. If you have an implementation of draft-ietf-l2vpn-signaling, please provide the following information: 1. Organization 1.1. Organization URL(s) 2. Status: 2.1 [ ] Development 2.2 [ ] Alpha 2.3 [ ] Beta 2.4 [ ] Generally Available 2.5 [ ] Other (describe): 3. Privacy: 3.1 [ ] Yes [ ] No May we publish your identity and Organization? If you have an implementation of draft-ietf-l3vpn-2547bis-mcast-bgp, please provide the following information: 1. Organization 1.1. Organization URL(s) 2. Status: 2.1 [ ] Development 2.2 [ ] Alpha 2.3 [ ] Beta 2.4 [ ] Generally Available 2.5 [ ] Other (describe): 3. Privacy: 3.1 [ ] Yes [ ] No May we publish your identity and Organization? Thanks, Shane, Vach, Danny & Marshall From mnapierala@att.com Wed Apr 29 05:14: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 904C43A6D7D for ; Wed, 29 Apr 2009 05:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.303 X-Spam-Level: X-Spam-Status: No, score=-106.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 MJc4K4pbJH49 for ; Wed, 29 Apr 2009 05:14:51 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 994043A6D71 for ; Wed, 29 Apr 2009 05:14:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mnapierala@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1241007372!23902307!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 22624 invoked from network); 29 Apr 2009 12:16:12 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Apr 2009 12:16:12 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3TCGC0n013268; Wed, 29 Apr 2009 08:16:12 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3TCG9n3013260; Wed, 29 Apr 2009 08:16:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 11.4 Date: Wed, 29 Apr 2009 08:16:08 -0400 Message-ID: <2F1DE4DFCFF32144B771BD2C246E6A20026D6E06@misout7msgusr7e.ugd.att.com> In-Reply-To: <200904282137.n3SLbEM72426@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-l3vpn-2547bis-mcast-bgp-06 section 11.4 Thread-Index: AcnIS3ZHYOqIheCpQx6V/Fc2wIEQXQAeFZgg References: <2F1DE4DFCFF32144B771BD2C246E6A200245D71B@misout7msgusr7e.ugd.att.com> <200904081856.n38IusM11716@magenta.juniper.net> <2F1DE4DFCFF32144B771BD2C246E6A200245D73D@misout7msgusr7e.ugd.att.com> <200904282137.n3SLbEM72426@magenta.juniper.net> From: "NAPIERALA, MARIA H, ATTLABS" To: "Yakov Rekhter" Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 12:14:52 -0000 Yakov, > Since in the context of this document C-multicast routes are carried > in BGP, it should be abundantly clear that in the context of this > document "aggregating C-multicast routes" means "aggregating BGP > routes". The term "aggregating BGP routes" is covered in rfc4271 > (BGP-4) section 9.2.2.2. >=20 Since the "aggregation" takes place on the RR, could clarify what is the ORIGINATOR_ID of those "aggregated" routes?=20 Thanks. Maria From root@core3.amsl.com Wed Apr 29 06:00:02 2009 Return-Path: X-Original-To: l3vpn@ietf.org Delivered-To: l3vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1D71A3A6EFC; Wed, 29 Apr 2009 06:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l3vpn-mvpn-considerations-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090429130002.1D71A3A6EFC@core3.amsl.com> Date: Wed, 29 Apr 2009 06:00:02 -0700 (PDT) Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution Author(s) : T. Morin, et al. Filename : draft-ietf-l3vpn-mvpn-considerations-03.txt Pages : 32 Date : 2009-04-29 More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks. To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-considerations-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l3vpn-mvpn-considerations-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-29055428.I-D@ietf.org> --NextPart-- From thomas.morin@orange-ftgroup.com Wed Apr 29 07:01: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 0901D28C251 for ; Wed, 29 Apr 2009 07:01:40 -0700 (PDT) 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_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlX7zpo5waEv for ; Wed, 29 Apr 2009 07:01:39 -0700 (PDT) Received: from p-mail1b.rd.francetelecom.com (p-mail1b.rd.francetelecom.com [194.167.105.13]) by core3.amsl.com (Postfix) with ESMTP id 46CD828C26D for ; Wed, 29 Apr 2009 07:00:58 -0700 (PDT) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 16:02:02 +0200 Received: from [10.193.15.31] ([10.193.15.31]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 16:02:01 +0200 Subject: [Fwd: New Version Notification for draft-ietf-l3vpn-mvpn-considerations-03] From: Thomas Morin To: L3VPN Content-Type: multipart/mixed; boundary="=-/m1g1bGNZI/QNTxiSjgg" Organization: France Telecom R&D - Orange Labs Date: Wed, 29 Apr 2009 16:02:00 +0200 Message-Id: <1241013720.346.70.camel@l-at11168.FTRD> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-OriginalArrivalTime: 29 Apr 2009 14:02:01.0578 (UTC) FILETIME=[119AC4A0:01C9C8D3] X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 14:01:40 -0000 --=-/m1g1bGNZI/QNTxiSjgg Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi folks, A new version of draft-ietf-l3vpn-mvpn-considerations has just been posted. Apart from adding the conclusions on bidir-PIM to the "Summary of recommendations" section, the rest is essentially editorial comments (typo/syntax, consistency in notations, references updates, some reformulations). Cheers, -Thomas --=-/m1g1bGNZI/QNTxiSjgg Content-Disposition: inline Content-Description: Message =?ISO-8859-1?Q?transf=E9r=E9?= - New Version Notification for draft-ietf-l3vpn-mvpn-considerations-03 Content-Type: message/rfc822 Received: from ftrdsmtp4.rd.francetelecom.fr ([10.192.128.49]) by FTRDMEL2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 14:56:23 +0200 Received: from omfeda08.si.francetelecom.fr ([10.98.3.82]) by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 14:56:23 +0200 Received: from omfeda12.si.francetelecom.fr (unknown [10.98.77.164]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 31DAA70005 for ; Wed, 29 Apr 2009 14:55:53 +0200 (CEST) Received: from omfeda12.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id B637F70273 for ; Wed, 29 Apr 2009 14:55:52 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])by relais-inet.francetelecom.com (ESMTP service) with ESMTP id 863B1702A6for ; Wed, 29 Apr 2009 14:55:52 +0200 (CEST) Received: by core3.amsl.com (Postfix, from userid 30)id B2D783A6EF0; Wed, 29 Apr 2009 05:54:28 -0700 (PDT) From: IETF I-D Submission Tool To: thomas.morin@orange-ftgroup.com Cc: benjamin.niven-jenkins@bt.com, y.kamite@ntt.com, raymond.zhang@bt.com, n.leymann@telekom.de, nabil.n.bitar@verizon.com Subject: New Version Notification for draft-ietf-l3vpn-mvpn-considerations-03 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Message-Id: <20090429125428.B2D783A6EF0@core3.amsl.com> Date: Wed, 29 Apr 2009 05:54:28 -0700 (PDT) X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:N SM:1 X-imss-tmaseResult: TT:1 TS:4.7045 TC:1F TRN:16 TV:5.6.1016(16610.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:3 M:1 S:3 R:1 (0.0000 0.0000) Return-Path: wwwrun@core3.amsl.com X-OriginalArrivalTime: 29 Apr 2009 12:56:23.0256 (UTC) FILETIME=[E62E8580:01C9C8C9] Content-Transfer-Encoding: 7bit A new version of I-D, draft-ietf-l3vpn-mvpn-considerations-03.txt has been successfuly submitted by Thomas Morin and posted to the IETF repository. Filename: draft-ietf-l3vpn-mvpn-considerations Revision: 03 Title: Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution Creation_date: 2009-04-29 WG ID: l3vpn Number_of_pages: 32 Abstract: More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks. To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. The IETF Secretariat. --=-/m1g1bGNZI/QNTxiSjgg-- From cpignata@cisco.com Wed Apr 29 08:22: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 9CCB03A67F3; Wed, 29 Apr 2009 08:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=-0.263, 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 tB1MBWoEcw4U; Wed, 29 Apr 2009 08:22:17 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 1E3063A715A; Wed, 29 Apr 2009 08:22:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3TFNbX4025253; Wed, 29 Apr 2009 11:23:37 -0400 (EDT) Received: from [64.102.157.114] (dhcp-64-102-157-114.cisco.com [64.102.157.114]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3TFNaJe023981; Wed, 29 Apr 2009 11:23:37 -0400 (EDT) Message-ID: <49F870F8.9070301@cisco.com> Date: Wed, 29 Apr 2009 11:23:36 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: robert@raszuk.net Subject: Re: [Softwires] WG LC softwire-lb References: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> <49F178ED.2080905@raszuk.net> In-Reply-To: <49F178ED.2080905@raszuk.net> X-Enigmail-Version: 0.95.7 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org, Clarence Filsfils , Ralph Droms , Alain Durand , pwe3@ietf.org, David Ward , softwires@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 15:22:18 -0000 Hi Robert, Thank you for your comments, please see inline. On 4/24/2009 4:31 AM, Robert Raszuk wrote: > Hi David, > > Perhaps I may have missed the discussion on this in the other WGs but I > have two comments/questions ... > > * Why the decision on enhancing the load balancing capability of IP > encapsulated packet has to be signaled as opposed to be a local matter > of the ingress router performing encapsulation ? This is because the load-balancing field is signaled (see RFC5512), so using for lb it needs signaling of a block to avoid collisions. Note also the context from the title, lb for Mesh Softwires. For the L2TPv3 case, and from , the only encapsulating header field that is always there is the Session ID (Cookie is optional), which is signaled; the case for GRE is equivalent, but also please see below. If it's only a local matter, the encapsulating header's fields could not be used and you would be limited to playing with e.g., the source IP address. > > * Reg use of GRE key for the purpose of load balancing I must say that > GRE key has already been proposed in number of solutions today. Therefor > overloading more on it may be impractical. Did authors analyzed use of > Sequence Numbers in GRE header instead for the purpose of increasing > effectiveness of load-balancing by the transit nodes ? Yes, it was considered, but we need a field that can be used for flow identification. From RFC2890, the seq # MUST be used by the receiver to establish packet transmission order, so it's incompatible with a per-flow use. The GRE Key's semantics from RFC2890 match this use, : The Key field contains a four octet number which was inserted by the encapsulator. The actual method by which this Key is obtained is beyond the scope of the document. The Key field is intended to be used for identifying an individual traffic flow within a tunnel. Thanks, -- Carlos. > > Cheers, > R. > > >> All - >> Following the last IETF meeting all comments have been addressed in: >> >> http://tools.ietf.org/html/draft-ietf-softwire-lb-02 >> >> The authors have requested a WG LC and I have added L3VPN and PWE3 that >> may be interested and have comments on the technology. Please send back >> all comments by May 7, 2009. >> >> Thanks >> >> DWard, Alain > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >