From nobody Tue Jan 6 07:22:37 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400C51A1AA1 for ; Tue, 6 Jan 2015 07:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cI-hFWR5LWRJ for ; Tue, 6 Jan 2015 07:22:31 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCE11A1B9B for ; Tue, 6 Jan 2015 07:22:26 -0800 (PST) Received: from [172.29.33.129] (66.129.241.13) by CY1PR0501MB1098.namprd05.prod.outlook.com (25.160.144.140) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 15:22:02 +0000 Message-ID: <54ABFD8F.5030309@juniper.net> Date: Tue, 6 Jan 2015 10:21:51 -0500 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: BIER Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY2PR04CA050.namprd04.prod.outlook.com (10.141.249.168) To CY1PR0501MB1098.namprd05.prod.outlook.com (25.160.144.140) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CY1PR0501MB1098; X-Forefront-PRVS: 0448A97BF2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(199003)(35774003)(189002)(83506001)(33656002)(110136001)(4396001)(80316001)(23676002)(31966008)(97736003)(54356999)(87266999)(50986999)(65816999)(87976001)(21056001)(92566001)(36756003)(59896002)(450100001)(77156002)(62966003)(122386002)(40100003)(77096005)(68736005)(105586002)(229853001)(64706001)(99396003)(46102003)(86362001)(42186005)(20776003)(66066001)(65806001)(120916001)(107046002)(47776003)(106356001)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1098; H:[172.29.33.129]; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2015 15:22:02.1166 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1098 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/imhtLo_mF2qC_WsSB2v9xEaSqj0 Cc: erosen@juniper.net Subject: [Bier] When not all transit nodes support BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:22:34 -0000 The BIER architecture should cover the scenario in which some of the transit routers in a BIER domain are not BFRs (i.e., some of the transit routers do not support BIER). I think this scenario can be covered fairly easily. However, we still assume that the ingress and egress nodes support BIER; the following only handles the case of transit nodes that do not support BIER. Also, the following only handles the case where the "routing underlay" is an SPF-based IGP that computes a tree from each node to all other nodes in the domain. At a given BFR, say BFR B, start with a copy of the IGP-computed shortest path tree from BFR B to each router in the domain. (This tree is computed by the SPF algorithm of the IGP.) Let's call this copy the "BIER-SPF tree rooted at BFR B." BFR B then modifies this BIER-SPF tree as follows. BFR B looks in turn at each of B's child nodes on the BIER-SPF tree. If one of the child nodes does not support BIER, BFR B will remove that node from the tree. The child nodes of the node that has just been removed will be re-parented on the tree, so that BFR B now becomes their parent. BFR B then continues to look at each of its child nodes, including any nodes that have been re-parented to B as a result of the previous step. When all of the child nodes (the original child nodes plus any new ones) have been examined, B's children on the BIER-SPF tree will all be BFRs. When the BIFT is constructed, B's child nodes on the BIER-SPF tree will be the BFR "adjacencies". The F-BMs and outgoing BIER-MPLS labels must be computed appropriately, based on the BIER adjacency. B may now have child nodes that are not "directly connected" to B via layer 2. To send a packet to one of these child nodes, B will have to send the packet through a unicast tunnel. This may be as simple as finding the IGP unicast next hop to the child node, and pushing on (above the BIER-MPLS label advertised by the child) the MPLS label that the IGP next hop has bound to an address of the child node. Of course, the above is not meant as an implementation technique, just as a functional description. A similar technique can be used to provide node protection. I.e., the failed neighbor of BFR B can be removed from B's BIER-SPF tree, and the child nodes of the failed node can be re-parented to B. However, getting the packet from B to the child nodes of the failed node is a bit more complicated, as it may require using a bypass tunnel to get around the failed node. I think something like this should be incorporated into the architecture document. When using a unicast tunnel to get a packet to an "adjacent" BFR, it may be advantageous to (a) set the TTL of the MPLS label entry representing the "tunnel" to a large value, rather than copying the TTL value from the BIER-MPLS label, and (b) when the tunnel labels are popped off, to avoid copying the TTL from the tunnel labels to the BIER-MPLS label. That way, the TTL of the BIER-MPLS label would only control the number of "BFR hops" that the packet may traverse. Comments? From nobody Tue Jan 6 08:11:13 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1381A00DC for ; Tue, 6 Jan 2015 08:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Kr5-EIKQfBg for ; Tue, 6 Jan 2015 08:11:09 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0124.outbound.protection.outlook.com [207.46.100.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4061A00F8 for ; Tue, 6 Jan 2015 08:11:09 -0800 (PST) Received: from [172.29.33.129] (66.129.241.13) by CY1PR0501MB1098.namprd05.prod.outlook.com (25.160.144.140) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 16:11:07 +0000 Message-ID: <54AC0915.4000804@juniper.net> Date: Tue, 6 Jan 2015 11:11:01 -0500 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: BIER Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: CO1PR06CA052.namprd06.prod.outlook.com (10.242.160.42) To CY1PR0501MB1098.namprd05.prod.outlook.com (25.160.144.140) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CY1PR0501MB1098; X-Forefront-PRVS: 0448A97BF2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6049001)(6009001)(199003)(35774003)(189002)(83506001)(33656002)(561944003)(110136001)(4396001)(64126003)(80316001)(23676002)(31966008)(97736003)(54356999)(87266999)(65816999)(50986999)(87976001)(101416001)(21056001)(92566001)(36756003)(59896002)(450100001)(77156002)(62966003)(122386002)(40100003)(77096005)(68736005)(105586002)(229853001)(64706001)(99396003)(46102003)(86362001)(42186005)(20776003)(66066001)(65956001)(65806001)(120916001)(47776003)(107046002)(106356001)(50466002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1098; H:[172.29.33.129]; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2015 16:11:07.1894 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1098 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/ndV1wfaCSiq-lEmWkptmh6temD8 Cc: erosen@juniper.net Subject: [Bier] Optimized explicit tracking for BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:11:12 -0000 As you all know, the use of BIER requires explicit tracking by the multicast flow layer. In particular, to use BIER for MVPN, it is necessary to explicitly track every MVPN C-flow. draft-rosen-l3vpn-mvpn-bier-02 requires that an ingress node originate an S-PMSI A-D for every flow, in order to force each egress node to originate a Leaf A-D route for every flow that it needs to receive. It would be desirable to eliminate the requirement for the ingress nodes to originate all these S-PMSI A-D routes. Here is a proposal that allows an ingress node to request explicit tracking for each individual flow, but doesn't require the ingress node to originate S-PMSI A-D routes for those flows. The proposal is to take one of the flag bits in the PMSI Tunnel attribute(PTA), and define it to be the "Leaf Info Required per Flow" bit (LIR-pF). An ingress PE/ABR/ASBR would set this bit in the PTA of an S-PMSI A-D route. For BIER, this would be the PTA of a (C-*,C-*) S-PMSI A-D route, and the PTA would specify a BIER tunnel. Roughly speaking, the LIR-pF bit means "send me a Leaf A-D route for each C-flow that you expect to receive over the specified tunnel". (Where a C-flow could be either (C-S,C-G) or (C-*,C-G)). For a given C-flow ((C-S,C-G) or (C-*,C-G)) at an egress PE/ABR/ASBR, if the match for reception has LIR-pF set, the egress node must originate a Leaf A-D route. As a reminder, the "route key" field of the NLRI will have the following format: +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Multicast Source Length (1 octet) | +-----------------------------------+ | Multicast Source (Variable) | +-----------------------------------+ | Multicast Group Length (1 octet) | +-----------------------------------+ | Multicast Group (Variable) | +-----------------------------------+ | Ingress PE's IP address | +-----------------------------------+ (stolen from draft-ietf-seamless-mcast). Details: - The "ingress PE" address will be taken from the "originating router" field of the NLRI of the S-PMSI A-D route. - The multicast source and group fields specify the S and G of the (C-S,C-G) being tracked. If a (C-*,C-G) is being tracked, the source field is omitted (length set to 0). - The RD field is constructed as follows: * Take the RD value from the NLRI of the S-PMSI A-D route. * Add 16 to the first byte of the RD. Note that, per RFC4364, every RD begins with a type field that is either 0, 1, or 2. By adding 16 to the first byte of the RD, we force the first byte to be 0x10, 0x11, or 0x12. The presence of one of these values will indicate that the Leaf A-D route was constructed in response to a less specific S-PMSI A-D route that had the LIR-pF bit set. (That is, it distinguishes the routes from "ordinary" MVPN Leaf A-D routes. And since the RD is not 0 or -1, these Leaf A-D routes can also be distinguished from the "global table multicast" Leaf A-D routes of the seamless-mcast draft. These Leaf A-D routes will be accepted and processed even though there is no "corresponding"" S-PMSI A-D route (in the sense required by RFC6514). Of course, an egress node that originates such Leaf A-D routes needs to remember which S-PMSI A-D route caused these Leaf A-D routes to be originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D routes will be withdrawn. Similarly, a Leaf A-D route needs to be withdrawn (either implicitly or explicitly) if the egress node changes its UMH for the flow that is identified in the Leaf A-D route's NLRI. If a particular PTA has both the LIR bit and the LIR-pF bit set, the actions for the LIR-pF bit are taken, and the LIR bit is ignored. In the case where the egress node is a PE, it will know whether it needs to receive a given flow by virtue of its having received a PIM Join for that flow from a CE. In the case where the egress node is not a PE, but border router at a "P-tunnel segmentation boundary", it's a bit more complicated. If such an egress node receives an S-PMSI A-D route with LIR-pF set, it should process it, but also forward it along (as specified in RFC6514 and/or the seamless-mcast draft). It should originate a Leaf A-D route for a specific flow only if it has an installed Leaf A-D route for that flow, received from further downstream. Comments? From nobody Tue Jan 6 10:04:53 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1AB1A0262 for ; Tue, 6 Jan 2015 10:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loqQVLLr-3Lk for ; Tue, 6 Jan 2015 10:04:34 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0051A1B0D for ; Tue, 6 Jan 2015 10:03:45 -0800 (PST) Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY1PR0501MB1093.namprd05.prod.outlook.com (25.160.103.139) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 18:03:44 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.118]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.118]) with mapi id 15.01.0049.002; Tue, 6 Jan 2015 18:03:43 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Eric Rosen , BIER Thread-Topic: [Bier] Optimized explicit tracking for BIER Thread-Index: AQHQKctqWt8tVQuctkW0Tral31F2fJyzYTsg Date: Tue, 6 Jan 2015 18:03:43 +0000 Message-ID: References: <54AC0915.4000804@juniper.net> In-Reply-To: <54AC0915.4000804@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BY1PR0501MB1093; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1093; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51704005)(377454003)(35774003)(13464003)(74316001)(66066001)(1941001)(20776003)(561944003)(31966008)(107046002)(99286002)(106356001)(46102003)(76576001)(105586002)(106116001)(19580405001)(92566001)(86362001)(19580395003)(54606007)(33656002)(87936001)(64706001)(54356999)(21056001)(50986999)(76176999)(2656002)(102836002)(54206007)(2900100001)(120916001)(68736005)(15975445007)(99396003)(97736003)(62966003)(450100001)(77156002)(2950100001)(122556002)(4396001)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1093; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2015 18:03:43.2553 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1093 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/jsHo0ryOBAgJVjQ8LqtxuX8BOsI Cc: Eric Rosen Subject: Re: [Bier] Optimized explicit tracking for BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 18:04:43 -0000 Eric, With this, the egress PE can suppress corresponding C-multicast routes as w= ell. Jeffrey > -----Original Message----- > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Eric C Rosen > Sent: Tuesday, January 06, 2015 11:11 AM > To: BIER > Cc: Eric Rosen > Subject: [Bier] Optimized explicit tracking for BIER >=20 > As you all know, the use of BIER requires explicit tracking by the > multicast flow layer. In particular, to use BIER for MVPN, it is > necessary to explicitly track every MVPN C-flow. > draft-rosen-l3vpn-mvpn-bier-02 requires that an ingress node originate > an S-PMSI A-D for every flow, in order to force each egress node to > originate a Leaf A-D route for every flow that it needs to receive. >=20 > It would be desirable to eliminate the requirement for the ingress nodes > to originate all these S-PMSI A-D routes. >=20 > Here is a proposal that allows an ingress node to request explicit > tracking for each individual flow, but doesn't require the ingress node > to originate S-PMSI A-D routes for those flows. >=20 > The proposal is to take one of the flag bits in the PMSI Tunnel > attribute(PTA), and define it to be the "Leaf Info Required per Flow" > bit (LIR-pF). An ingress PE/ABR/ASBR would set this bit in the PTA of > an S-PMSI A-D route. For BIER, this would be the PTA of a (C-*,C-*) > S-PMSI A-D route, and the PTA would specify a BIER tunnel. >=20 > Roughly speaking, the LIR-pF bit means "send me a Leaf A-D route for > each C-flow that you expect to receive over the specified tunnel". > (Where a C-flow could be either (C-S,C-G) or (C-*,C-G)). >=20 > For a given C-flow ((C-S,C-G) or (C-*,C-G)) at an egress PE/ABR/ASBR, if > the match for reception has LIR-pF set, the egress node must originate a > Leaf A-D route. As a reminder, the "route key" field of the NLRI will > have the following format: >=20 > +-----------------------------------+ > | RD (8 octets) | > +-----------------------------------+ > | Multicast Source Length (1 octet) | > +-----------------------------------+ > | Multicast Source (Variable) | > +-----------------------------------+ > | Multicast Group Length (1 octet) | > +-----------------------------------+ > | Multicast Group (Variable) | > +-----------------------------------+ > | Ingress PE's IP address | > +-----------------------------------+ >=20 > (stolen from draft-ietf-seamless-mcast). Details: >=20 > - The "ingress PE" address will be taken from the "originating router" > field of the NLRI of the S-PMSI A-D route. >=20 > - The multicast source and group fields specify the S and G of the > (C-S,C-G) being tracked. If a (C-*,C-G) is being tracked, the source > field is omitted (length set to 0). >=20 > - The RD field is constructed as follows: >=20 > * Take the RD value from the NLRI of the S-PMSI A-D route. > * Add 16 to the first byte of the RD. >=20 > Note that, per RFC4364, every RD begins with a type field that is either > 0, 1, or 2. By adding 16 to the first byte of the RD, we force the > first byte to be 0x10, 0x11, or 0x12. The presence of one of these > values will indicate that the Leaf A-D route was constructed in response > to a less specific S-PMSI A-D route that had the LIR-pF bit set. (That > is, it distinguishes the routes from "ordinary" MVPN Leaf A-D routes. > And since the RD is not 0 or -1, these Leaf A-D routes can also be > distinguished from the "global table multicast" Leaf A-D routes of the > seamless-mcast draft. These Leaf A-D routes will be accepted and > processed even though there is no "corresponding"" S-PMSI A-D route (in > the sense required by RFC6514). >=20 > Of course, an egress node that originates such Leaf A-D routes needs to > remember which S-PMSI A-D route caused these Leaf A-D routes to be > originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D routes > will be withdrawn. Similarly, a Leaf A-D route needs to be withdrawn > (either implicitly or explicitly) if the egress node changes its UMH for > the flow that is identified in the Leaf A-D route's NLRI. >=20 > If a particular PTA has both the LIR bit and the LIR-pF bit set, the > actions for the LIR-pF bit are taken, and the LIR bit is ignored. >=20 > In the case where the egress node is a PE, it will know whether it needs > to receive a given flow by virtue of its having received a PIM Join for > that flow from a CE. In the case where the egress node is not a PE, but > border router at a "P-tunnel segmentation boundary", it's a bit more > complicated. If such an egress node receives an S-PMSI A-D route with > LIR-pF set, it should process it, but also forward it along (as > specified in RFC6514 and/or the seamless-mcast draft). It should > originate a Leaf A-D route for a specific flow only if it has an > installed Leaf A-D route for that flow, received from further downstream. >=20 > Comments? >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Tue Jan 6 10:24:24 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF82C1A1AEC for ; Tue, 6 Jan 2015 10:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyxfQd25yulB for ; Tue, 6 Jan 2015 10:24:19 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7659B1A0022 for ; Tue, 6 Jan 2015 10:24:19 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-6e-54abd68ac0f7 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 49.DE.03307.A86DBA45; Tue, 6 Jan 2015 13:35:22 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 13:24:17 -0500 From: Albert Tian To: Eric C Rosen , BIER Thread-Topic: [Bier] When not all transit nodes support BIER Thread-Index: AQHQKcScLytKaQglhkC+nnzW6xRjIZyzNh+A Date: Tue, 6 Jan 2015 18:24:17 +0000 Message-ID: References: <54ABFD8F.5030309@juniper.net> In-Reply-To: <54ABFD8F.5030309@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPlG7XtdUhBsfvalosnbGHyWLdhg/M DkweS5b8ZPK43nSVPYApissmJTUnsyy1SN8ugStj3pTX7AWdmhULu7axNjA+Vehi5OSQEDCR 2PbmMxOELSZx4d56ti5GLg4hgSOMEq3zTrFAOMsYJVbMWsEIUsUmoCPxavYDMFtEwFriVfs5 sG5hIHvSnNesEHEbiTUnf0PZRhKfb18Fq2ERUJFYcnsPWJxXwExi2eFJ7CC2kICWxM3+aWwg NqeAtsT+xfvB5jMCXfT91BqwXmYBcYlbT+ZDXSogsWTPeWYIW1Ti5eN/YDNFBfQk5j18xQYR V5L4+Hs+O0SvnsSNqVPYIGxrid4JMDO1JZYtfM0McY+gxMmZT1gmMIrPQrJuFpL2WUjaZyFp n4WkfQEj6ypGjtLi1LLcdCODTYzAuDomwaa7g3HPS8tDjAIcjEo8vBv8V4cIsSaWFVfmHmKU 5mBREuedVTsvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjTdr3cn6b+JVCZRUG0mULw/9v mNQcZfipu3SiptKG8zGLlm9K5mmx8VESEb3jlGzid33xkWeWvTf02FtWlq7YH3+xZu0s667L Gj8TSoxvZpzxcuOredidebLrR2y8ldnde6XfDdRPpDw73H3wf07Lg7ViHzf1sXE3TbuewvXQ LD4w1Owx+2olluKMREMt5qLiRABs0o3jjAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/bier/fhBZF-1kHCb_9w47atU-Sd4xAOw Subject: Re: [Bier] When not all transit nodes support BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 18:24:22 -0000 Hi Eric, Yes this is a very good description of the solution. Comments inlined. Thanks, Albert On 1/6/15, 7:21 AM, "Eric C Rosen" wrote: >The BIER architecture should cover the scenario in which some of the >transit routers in a BIER domain are not BFRs (i.e., some of the transit >routers do not support BIER). I think this scenario can be covered >fairly easily. However, we still assume that the ingress and egress >nodes support BIER; the following only handles the case of transit nodes >that do not support BIER. Also, the following only handles the case >where the "routing underlay" is an SPF-based IGP that computes a tree >from each node to all other nodes in the domain. [Albert] I don=B9t see why we can not handle other type of distribution trees in the same way as SPF trees, if we are using some form of tunneling technology (such as MPLS) to encapsulate the BIER packet over these non-BFRs. If the tree building algorithm is not SPF based, it is possible that a given packet may pass through a given BFR more than once: once through BIER processing, another time as part of a tunnel. However, there should be no forwarding loops. > >At a given BFR, say BFR B, start with a copy of the IGP-computed >shortest path tree from BFR B to each router in the domain. (This tree >is computed by the SPF algorithm of the IGP.) Let's call this copy the >"BIER-SPF tree rooted at BFR B." BFR B then modifies this BIER-SPF tree >as follows. [Albert] The key change here is the definition of a BFR-NBR and BFR-NH in section 6.2 of the architecture document. We now allow a BFR-NH to be non-adjacent in the routing underlay, as long as there is an underlying tunneling technology to deliver packets to the BFR-NH. It maybe more convenient to use BFR-NH in our discussions moving forward, with the knowledge that a BFR-NH may be reachable via a tunnel. In section 6.2 I would suggest we change the section title to BFR Next Hop (BFR-NH). Here is a proposed new definition of BFR-NH: =B3The BFR-NH for a given BFER X from a BFR A, is the first BFR (BIER capable router) on the path from BFR A to BFER X according to the BIER distribution tree." We can also define BFR-NBR as anonymous to BFR-NH and can be non-adjacent according to routing underlay. In section 6.4 the derivation of BIFT from BIRT remains unchanged. In section 6.5 The BIER Forwarding Procedure, we may add to step 4: =B3In case the BFR-NBR is reachable via a tunnel according to the routing underlay, we may need to encapsulate the BIER packet and send it to the tunnel associated with the BFR-NBR." With the above definition of BFR-NH/BFR-NBR, the impact on the rest of the BIER architecture may be minimized. [/Albert] > >BFR B looks in turn at each of B's child nodes on the BIER-SPF tree. > >If one of the child nodes does not support BIER, BFR B will remove that >node from the tree. The child nodes of the node that has just been >removed will be re-parented on the tree, so that BFR B now becomes their >parent. > >BFR B then continues to look at each of its child nodes, including any >nodes that have been re-parented to B as a result of the previous step. > >When all of the child nodes (the original child nodes plus any new ones) >have been examined, B's children on the BIER-SPF tree will all be BFRs. >When the BIFT is constructed, B's child nodes on the BIER-SPF tree will >be the BFR "adjacencies". The F-BMs and outgoing BIER-MPLS labels must >be computed appropriately, based on the BIER adjacency. > >B may now have child nodes that are not "directly connected" to B via >layer 2. To send a packet to one of these child nodes, B will have to >send the packet through a unicast tunnel. This may be as simple as >finding the IGP unicast next hop to the child node, and pushing on >(above the BIER-MPLS label advertised by the child) the MPLS label that >the IGP next hop has bound to an address of the child node. > >Of course, the above is not meant as an implementation technique, just >as a functional description. > >A similar technique can be used to provide node protection. I.e., the >failed neighbor of BFR B can be removed from B's BIER-SPF tree, and the >child nodes of the failed node can be re-parented to B. However, >getting the packet from B to the child nodes of the failed node is a bit >more complicated, as it may require using a bypass tunnel to get around >the failed node. > >I think something like this should be incorporated into the architecture >document. > >When using a unicast tunnel to get a packet to an "adjacent" BFR, it may >be advantageous to (a) set the TTL of the MPLS label entry representing >the "tunnel" to a large value, rather than copying the TTL value from >the BIER-MPLS label, and (b) when the tunnel labels are popped off, to >avoid copying the TTL from the tunnel labels to the BIER-MPLS label. >That way, the TTL of the BIER-MPLS label would only control the number >of "BFR hops" that the packet may traverse. > >Comments? > > >_______________________________________________ >BIER mailing list >BIER@ietf.org >https://www.ietf.org/mailman/listinfo/bier From nobody Tue Jan 6 19:08:11 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AD01A03A8 for ; Tue, 6 Jan 2015 19:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbxafMi4kZT9 for ; Tue, 6 Jan 2015 19:08:05 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893291A0390 for ; Tue, 6 Jan 2015 19:08:04 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 197296ACCFEE; Wed, 7 Jan 2015 03:08:01 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t07381Xw006090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Jan 2015 22:08:01 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 22:08:01 -0500 From: "Dolganow, Andrew (Andrew)" To: Eric C Rosen , BIER Thread-Topic: [SPAM?] [Bier] Optimized explicit tracking for BIER Thread-Index: AQHQKickF8ps0k1UzEKDW3H8nEHgfg== Date: Wed, 7 Jan 2015 03:08:00 +0000 Message-ID: References: <54AC0915.4000804@juniper.net> In-Reply-To: <54AC0915.4000804@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <52AAC4827659054E9CEB02666066FED2@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/RnsmTlNEKDvMj9jnXeFkXIc3of4 Subject: Re: [Bier] [SPAM?] Optimized explicit tracking for BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 03:08:10 -0000 Eric, Happy new Year. Can you please look at the draft I presented in Honolulu: https://tools.ietf.org/html/draft-dolganow-l3vpn-mvpn-expl-track-00, The draft describes how explicit tracking is expected to work in general. As discussed on the list and in Honolulu, explicit tracking in RFC 61513/14 and in RFC6625 (wildcard) requires some clarification - although with some common sense, following the rules outlined in 6513/14 implementers Could achieve explicit tracking for any S-PMSI type. The above draft clarifies things up and allows explicit tracking for any S-PMSI=20 route, including any wildcards, without a need for any new procedures/encodings (the draft we presented clarifies what applies and how in the existing RFCs).=20 This general mechanism for NG-MVPN explicit tracking can be then also used in BIER=20 without a need for any BIER-specific extensions. When the mechanism is used,=20 ingress PE (BFIR) will send an explicit tracking request for whatever it needs a (C-S, C-G)=20 or any type of wildcard depending which C-multicast flows are to use BIER in P-instance).=20 I find the below procedure thus duplicate of what we already have on the table for general explicit Tracking in ng-MVPN - including BIER. Andrew On 2015-01-06, 11:11 AM, "Eric C Rosen" wrote: >As you all know, the use of BIER requires explicit tracking by the >multicast flow layer. In particular, to use BIER for MVPN, it is >necessary to explicitly track every MVPN C-flow. >draft-rosen-l3vpn-mvpn-bier-02 requires that an ingress node originate >an S-PMSI A-D for every flow, in order to force each egress node to >originate a Leaf A-D route for every flow that it needs to receive. > >It would be desirable to eliminate the requirement for the ingress nodes >to originate all these S-PMSI A-D routes. > >Here is a proposal that allows an ingress node to request explicit >tracking for each individual flow, but doesn't require the ingress node >to originate S-PMSI A-D routes for those flows. > >The proposal is to take one of the flag bits in the PMSI Tunnel >attribute(PTA), and define it to be the "Leaf Info Required per Flow" >bit (LIR-pF). An ingress PE/ABR/ASBR would set this bit in the PTA of >an S-PMSI A-D route. For BIER, this would be the PTA of a (C-*,C-*) >S-PMSI A-D route, and the PTA would specify a BIER tunnel. > >Roughly speaking, the LIR-pF bit means "send me a Leaf A-D route for >each C-flow that you expect to receive over the specified tunnel". >(Where a C-flow could be either (C-S,C-G) or (C-*,C-G)). > >For a given C-flow ((C-S,C-G) or (C-*,C-G)) at an egress PE/ABR/ASBR, if >the match for reception has LIR-pF set, the egress node must originate a >Leaf A-D route. As a reminder, the "route key" field of the NLRI will >have the following format: > >+-----------------------------------+ >| RD (8 octets) | >+-----------------------------------+ >| Multicast Source Length (1 octet) | >+-----------------------------------+ >| Multicast Source (Variable) | >+-----------------------------------+ >| Multicast Group Length (1 octet) | >+-----------------------------------+ >| Multicast Group (Variable) | >+-----------------------------------+ >| Ingress PE's IP address | >+-----------------------------------+ > >(stolen from draft-ietf-seamless-mcast). Details: > >- The "ingress PE" address will be taken from the "originating router" >field of the NLRI of the S-PMSI A-D route. > >- The multicast source and group fields specify the S and G of the >(C-S,C-G) being tracked. If a (C-*,C-G) is being tracked, the source >field is omitted (length set to 0). > >- The RD field is constructed as follows: > > * Take the RD value from the NLRI of the S-PMSI A-D route. > * Add 16 to the first byte of the RD. > >Note that, per RFC4364, every RD begins with a type field that is either >0, 1, or 2. By adding 16 to the first byte of the RD, we force the >first byte to be 0x10, 0x11, or 0x12. The presence of one of these >values will indicate that the Leaf A-D route was constructed in response >to a less specific S-PMSI A-D route that had the LIR-pF bit set. (That >is, it distinguishes the routes from "ordinary" MVPN Leaf A-D routes. >And since the RD is not 0 or -1, these Leaf A-D routes can also be >distinguished from the "global table multicast" Leaf A-D routes of the >seamless-mcast draft. These Leaf A-D routes will be accepted and >processed even though there is no "corresponding"" S-PMSI A-D route (in >the sense required by RFC6514). > >Of course, an egress node that originates such Leaf A-D routes needs to >remember which S-PMSI A-D route caused these Leaf A-D routes to be >originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D routes >will be withdrawn. Similarly, a Leaf A-D route needs to be withdrawn >(either implicitly or explicitly) if the egress node changes its UMH for >the flow that is identified in the Leaf A-D route's NLRI. > >If a particular PTA has both the LIR bit and the LIR-pF bit set, the >actions for the LIR-pF bit are taken, and the LIR bit is ignored. > >In the case where the egress node is a PE, it will know whether it needs >to receive a given flow by virtue of its having received a PIM Join for >that flow from a CE. In the case where the egress node is not a PE, but >border router at a "P-tunnel segmentation boundary", it's a bit more >complicated. If such an egress node receives an S-PMSI A-D route with >LIR-pF set, it should process it, but also forward it along (as >specified in RFC6514 and/or the seamless-mcast draft). It should >originate a Leaf A-D route for a specific flow only if it has an >installed Leaf A-D route for that flow, received from further downstream. > >Comments? > > > > > > >_______________________________________________ >BIER mailing list >BIER@ietf.org >https://www.ietf.org/mailman/listinfo/bier From nobody Wed Jan 7 06:54:22 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDB71A7006 for ; Wed, 7 Jan 2015 06:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSfzocXNOFkl for ; Wed, 7 Jan 2015 06:54:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7FD81A87F0 for ; Wed, 7 Jan 2015 06:54:19 -0800 (PST) Received: from BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142) by BY1PR0501MB1301.namprd05.prod.outlook.com (25.160.200.150) with Microsoft SMTP Server (TLS) id 15.1.49.12; Wed, 7 Jan 2015 14:53:56 +0000 Received: from [172.29.33.129] (66.129.241.13) by BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142) with Microsoft SMTP Server (TLS) id 15.1.49.12; Wed, 7 Jan 2015 14:53:54 +0000 Message-ID: <54AD487B.5050302@juniper.net> Date: Wed, 7 Jan 2015 09:53:47 -0500 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Dolganow, Andrew (Andrew)" , BIER References: <54AC0915.4000804@juniper.net> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: DM2PR09CA0034.namprd09.prod.outlook.com (25.160.127.44) To BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; X-DmarcAction: None X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BY1PR0501MB1096; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA: BCL:0; PCL:0; RULEID:(601004); SRVR:BY1PR0501MB1096; X-Forefront-PRVS: 044968D9E1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(189002)(199003)(92566001)(101416001)(33656002)(40100003)(106356001)(59896002)(76176999)(65816999)(87266999)(50986999)(54356999)(23746002)(99396003)(105586002)(4396001)(122386002)(86362001)(36756003)(21056001)(107046002)(87976001)(120916001)(83506001)(80316001)(68736005)(42186005)(77096005)(64706001)(47776003)(20776003)(65806001)(64126003)(62966003)(77156002)(50466002)(66066001)(561944003)(97736003)(31966008)(2950100001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1096; H:[172.29.33.129]; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1096; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2015 14:53:54.7065 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1096 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1301; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/bier/Btwmf_rv4W1BeLc4N2i83yilpC0 Cc: erosen@juniper.net Subject: Re: [Bier] Optimized explicit tracking for BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:54:21 -0000 > I find the below procedure thus duplicate of what we already have on > the table for general explicit Tracking in ng-MVPN - including BIER. If I understand your draft correctly, to invoke explicit tracking for a particular (C-S,C-G) flow, the ingress PE must originate a (C-S,C-G) S-PMSI A-D route. In the proposal described in my message, there is no need for the ingress PE to originate an (C-S,C-G) S-PMSI A-D route for each flow. It originates a single (C-*,C-*) S-PMSI A-D route, and this causes it to receive a Leaf A-D route for each (C-S,C-G). I don't think this duplicates what you have in your draft. > The above draft clarifies things up and allows explicit tracking for any > S-PMSI route, including any wildcards, without a need for any new > procedures/encodings But with a lot more control plane messaging. If we know we're using BIER, we can optimize by eliminating a whole bunch of S-PMSI A-D routes, but that does require some new procedures/encodings. From nobody Wed Jan 7 07:01:40 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF421A90E9 for ; Wed, 7 Jan 2015 07:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXULYj97dNLx for ; Wed, 7 Jan 2015 07:01:33 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8711A90B5 for ; Wed, 7 Jan 2015 07:01:33 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id E64D5253B8D77; Wed, 7 Jan 2015 15:01:28 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t07F1TCc017643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 10:01:30 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 10:01:30 -0500 From: "Dolganow, Andrew (Andrew)" To: Eric C Rosen , BIER Thread-Topic: [Bier] Optimized explicit tracking for BIER Thread-Index: AQHQKom93EdX9TINTE+uy/5YOwzLgpy0wI6A Date: Wed, 7 Jan 2015 15:01:29 +0000 Message-ID: References: <54AC0915.4000804@juniper.net> <54AD487B.5050302@juniper.net> In-Reply-To: <54AD487B.5050302@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <09260325C0DA6B4C8516436E2DC524CA@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/kOYNQ3kKCMbspP1HlKDFCisr8uc Subject: Re: [Bier] Optimized explicit tracking for BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:01:36 -0000 Eric, inline On 2015-01-07, 9:53 AM, "Eric C Rosen" wrote: >> I find the below procedure thus duplicate of what we already have on >> the table for general explicit Tracking in ng-MVPN - including BIER. > >If I understand your draft correctly, to invoke explicit tracking for a >particular (C-S,C-G) flow, the ingress PE must originate a (C-S,C-G) >S-PMSI A-D route. Not necessarily. If, for example, Source PE wants to know of all (C-S, C-G)s, it would simply send explicit tracking for (C-*, C-*), that would make the receiver to respond with ALL (C-S, C-G)s that would match this wildcard S-PMSI (which for BIER would do what you are looking at). > >In the proposal described in my message, there is no need for the >ingress PE to originate an (C-S,C-G) S-PMSI A-D route for each flow. It >originates a single (C-*,C-*) S-PMSI A-D route, and this causes it to >receive a Leaf A-D route for each (C-S,C-G). That is exactly how general (C-*, C-*) tracking works based on draft clarifying 6513/6513/6625. > >I don't think this duplicates what you have in your draft. > >> The above draft clarifies things up and allows explicit tracking for any >> S-PMSI route, including any wildcards, without a need for any new >> procedures/encodings > >But with a lot more control plane messaging. If we know we're using >BIER, we can optimize by eliminating a whole bunch of S-PMSI A-D routes, >but that does require some new procedures/encodings. This does not apply, based on my above explanation. Andrew > > > > > > > > From nobody Wed Jan 7 07:07:02 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AC51A910A for ; Wed, 7 Jan 2015 07:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFnkF3XV7Fpu for ; Wed, 7 Jan 2015 07:06:55 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C781A90E2 for ; Wed, 7 Jan 2015 07:06:54 -0800 (PST) Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by CY1PR0501MB1099.namprd05.prod.outlook.com (25.160.144.141) with Microsoft SMTP Server (TLS) id 15.1.49.12; Wed, 7 Jan 2015 15:06:32 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.118]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.118]) with mapi id 15.01.0049.002; Wed, 7 Jan 2015 15:06:31 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Dolganow, Andrew (Andrew)" , "Eric Rosen" , BIER Thread-Topic: [Bier] Optimized explicit tracking for BIER Thread-Index: AQHQKonWjzlwi/b1R0aFyEcSD6UYjZy0wI2AgAAAgIA= Date: Wed, 7 Jan 2015 15:06:30 +0000 Message-ID: References: <54AC0915.4000804@juniper.net> <54AD487B.5050302@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CY1PR0501MB1099; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1099; x-forefront-prvs: 044968D9E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(199003)(51704005)(189002)(377454003)(377424004)(97736003)(4396001)(31966008)(99286002)(122556002)(21056001)(40100003)(99396003)(120916001)(93886004)(33656002)(101416001)(74316001)(561944003)(76576001)(107046002)(106356001)(106116001)(62966003)(46102003)(107886001)(76176999)(2950100001)(105586002)(54206007)(77156002)(50986999)(15975445007)(68736005)(54356999)(54606007)(2656002)(87936001)(20776003)(66066001)(2900100001)(64706001)(19580405001)(19580395003)(102836002)(86362001)(92566001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1099; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2015 15:06:30.6170 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1099 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/l_vHfEiw8YPZ7Gm6ekold1Pb4xA Subject: Re: [Bier] Optimized explicit tracking for BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:07:02 -0000 Andrew, > That is exactly how general (C-*, C-*) tracking works based on draft > clarifying 6513/6513/6625. Perhaps we missed it, but if that draft is just "clarifying" 6513/6514/6625= , then you would not send individual (C-S,C-G) Leaf AD routes if you did no= t receive corresponding S-PMSI AD routes. If that draft did say that, then it is no longer just a "clarifying" draft. Jeffrey > -----Original Message----- > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Dolganow, Andrew > (Andrew) > Sent: Wednesday, January 07, 2015 10:01 AM > To: Eric Rosen; BIER > Subject: Re: [Bier] Optimized explicit tracking for BIER >=20 > Eric, >=20 > inline >=20 > On 2015-01-07, 9:53 AM, "Eric C Rosen" wrote: >=20 > >> I find the below procedure thus duplicate of what we already have on > >> the table for general explicit Tracking in ng-MVPN - including BIER. > > > >If I understand your draft correctly, to invoke explicit tracking for a > >particular (C-S,C-G) flow, the ingress PE must originate a (C-S,C-G) > >S-PMSI A-D route. >=20 > Not necessarily. If, for example, Source PE wants to know of all (C-S, > C-G)s, it would simply send explicit tracking for (C-*, C-*), that would > make the receiver to respond with ALL (C-S, C-G)s that would match this > wildcard S-PMSI (which for BIER would do what you are looking at). >=20 > > > >In the proposal described in my message, there is no need for the > >ingress PE to originate an (C-S,C-G) S-PMSI A-D route for each flow. > It > >originates a single (C-*,C-*) S-PMSI A-D route, and this causes it to > >receive a Leaf A-D route for each (C-S,C-G). >=20 > That is exactly how general (C-*, C-*) tracking works based on draft > clarifying 6513/6513/6625. > > > >I don't think this duplicates what you have in your draft. > > > >> The above draft clarifies things up and allows explicit tracking for > any > >> S-PMSI route, including any wildcards, without a need for any new > >> procedures/encodings > > > >But with a lot more control plane messaging. If we know we're using > >BIER, we can optimize by eliminating a whole bunch of S-PMSI A-D routes, > >but that does require some new procedures/encodings. >=20 > This does not apply, based on my above explanation. >=20 > Andrew > > > > > > > > > > > > > > > > >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Wed Jan 7 07:14:23 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71C01A9119 for ; Wed, 7 Jan 2015 07:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5gZgHP2_DTQ for ; Wed, 7 Jan 2015 07:14:19 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929161A90EE for ; Wed, 7 Jan 2015 07:14:18 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 585DC42319E04; Wed, 7 Jan 2015 15:14:13 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t07FEEgq021536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 10:14:14 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 10:14:14 -0500 From: "Dolganow, Andrew (Andrew)" To: "Jeffrey (Zhaohui) Zhang" , Eric Rosen , BIER Thread-Topic: [Bier] Optimized explicit tracking for BIER Thread-Index: AQHQKom93EdX9TINTE+uy/5YOwzLgpy0wI2AgAAAgICAAAMPgA== Date: Wed, 7 Jan 2015 15:14:13 +0000 Message-ID: References: <54AC0915.4000804@juniper.net> <54AD487B.5050302@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <055F9FB19218594E8A676CB59A3EDB39@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/ktUkuNgQf7RWJcX8sdiNAuTnUgc Subject: Re: [Bier] Optimized explicit tracking for BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:14:22 -0000 Jeff, What the draft say is you say individual Leaf A-D route if that route would match the received S-PMSI A-D wildcard route for data transmission based on 6625 procedures - see procedures on Receiver PE for wildcard processing in the draft - maybe they need some more text or clarification? Andrew On 2015-01-07, 10:06 AM, "Jeffrey (Zhaohui) Zhang" wrote: >Andrew, > >> That is exactly how general (C-*, C-*) tracking works based on draft >> clarifying 6513/6513/6625. > >Perhaps we missed it, but if that draft is just "clarifying" >6513/6514/6625, then you would not send individual (C-S,C-G) Leaf AD >routes if you did not receive corresponding S-PMSI AD routes. > >If that draft did say that, then it is no longer just a "clarifying" >draft. > >Jeffrey > >> -----Original Message----- >> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Dolganow, Andrew >> (Andrew) >> Sent: Wednesday, January 07, 2015 10:01 AM >> To: Eric Rosen; BIER >> Subject: Re: [Bier] Optimized explicit tracking for BIER >>=20 >> Eric, >>=20 >> inline >>=20 >> On 2015-01-07, 9:53 AM, "Eric C Rosen" wrote: >>=20 >> >> I find the below procedure thus duplicate of what we already have on >> >> the table for general explicit Tracking in ng-MVPN - including BIER. >> > >> >If I understand your draft correctly, to invoke explicit tracking for a >> >particular (C-S,C-G) flow, the ingress PE must originate a (C-S,C-G) >> >S-PMSI A-D route. >>=20 >> Not necessarily. If, for example, Source PE wants to know of all (C-S, >> C-G)s, it would simply send explicit tracking for (C-*, C-*), that would >> make the receiver to respond with ALL (C-S, C-G)s that would match this >> wildcard S-PMSI (which for BIER would do what you are looking at). >>=20 >> > >> >In the proposal described in my message, there is no need for the >> >ingress PE to originate an (C-S,C-G) S-PMSI A-D route for each flow. >> It >> >originates a single (C-*,C-*) S-PMSI A-D route, and this causes it to >> >receive a Leaf A-D route for each (C-S,C-G). >>=20 >> That is exactly how general (C-*, C-*) tracking works based on draft >> clarifying 6513/6513/6625. >> > >> >I don't think this duplicates what you have in your draft. >> > >> >> The above draft clarifies things up and allows explicit tracking for >> any >> >> S-PMSI route, including any wildcards, without a need for any new >> >> procedures/encodings >> > >> >But with a lot more control plane messaging. If we know we're using >> >BIER, we can optimize by eliminating a whole bunch of S-PMSI A-D >>routes, >> >but that does require some new procedures/encodings. >>=20 >> This does not apply, based on my above explanation. >>=20 >> Andrew >> > >> > >> > >> > >> > >> > >> > >> > >>=20 >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier From nobody Wed Jan 7 07:24:22 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EA61A8702 for ; Wed, 7 Jan 2015 07:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taIHEwYgc0b4 for ; Wed, 7 Jan 2015 07:24:09 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312011A87C3 for ; Wed, 7 Jan 2015 07:23:50 -0800 (PST) Received: from [172.29.33.129] (66.129.241.13) by BN3PR0501MB1091.namprd05.prod.outlook.com (25.160.113.13) with Microsoft SMTP Server (TLS) id 15.1.53.17; Wed, 7 Jan 2015 15:23:47 +0000 Message-ID: <54AD4F7B.60001@juniper.net> Date: Wed, 7 Jan 2015 10:23:39 -0500 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Jeffrey (Zhaohui) Zhang" , "Dolganow, Andrew (Andrew)" , BIER References: <54AC0915.4000804@juniper.net> <54AD487B.5050302@juniper.net> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: CY1PR09CA0019.namprd09.prod.outlook.com (25.160.223.29) To BN3PR0501MB1091.namprd05.prod.outlook.com (25.160.113.13) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BN3PR0501MB1091; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN3PR0501MB1091; X-Forefront-PRVS: 044968D9E1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(199003)(105586002)(120916001)(122386002)(99396003)(42186005)(4396001)(65806001)(66066001)(87976001)(46102003)(62966003)(21056001)(92566001)(77156002)(64126003)(47776003)(77096005)(68736005)(20776003)(64706001)(107046002)(2950100001)(97736003)(31966008)(106356001)(40100003)(23746002)(86362001)(93886004)(36756003)(101416001)(83506001)(50466002)(54356999)(76176999)(65816999)(50986999)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1091; H:[172.29.33.129]; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1091; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2015 15:23:47.4139 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1091 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/bYrOJTXRMhihM9pSN5n9p13BMEs Cc: erosen@juniper.net Subject: Re: [Bier] Optimized explicit tracking for BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:24:16 -0000 [Andrew] That is exactly how general (C-*, C-*) tracking works based on draft clarifying 6513/6513/6625. I certainly did not get that from your draft. (I still don't see it in your draft.) [Jeffrey] Perhaps we missed it, but if that draft is just "clarifying" 6513/6514/6625, then you would not send individual (C-S,C-G) Leaf AD routes if you did not receive corresponding S-PMSI AD routes. I agree with Jeffrey; existing procedures from RFCs 6514/6625 do not cause multiple Leaf A-D routes to be sent in response to a single S-PMSI A-D route. If we want this to happen, we do need to modify some of the procedures and encodings. In particular, if one sends a (C-*,C-*) S-PMSI A-D route with LIR set, one can expect to get back a (C-*,C-*) Leaf A-D route. If one wants to get back multiple (C-S,C-G) Leaf A-D routes instead, one needs to use a flag other than LIR. Also, the RFC6514 procedures generally assume that when one receives a Leaf A-D route, its "route key" field will be identical to the NLRI of some S-PMSI A-D route that one has originated. The only exception to this is in the global table multicast procedures of draft-ietf-mpls-seamless-mcast. Use of this sort of procedure in MVPN is new. Fortuitously, it does seem like we are on the same page about what should happen, even if we haven't yet agreed on all the details of how to make it happen ;-) From nobody Wed Jan 7 07:27:36 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F7D1A87C9 for ; Wed, 7 Jan 2015 07:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqfoSglIkFci for ; Wed, 7 Jan 2015 07:27:33 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534911A87ED for ; Wed, 7 Jan 2015 07:27:27 -0800 (PST) Received: from CY1PR0501MB1097.namprd05.prod.outlook.com (25.160.144.139) by CY1PR0501MB1545.namprd05.prod.outlook.com (25.161.161.143) with Microsoft SMTP Server (TLS) id 15.1.49.12; Wed, 7 Jan 2015 15:27:26 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by CY1PR0501MB1097.namprd05.prod.outlook.com (25.160.144.139) with Microsoft SMTP Server (TLS) id 15.1.49.12; Wed, 7 Jan 2015 15:27:25 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.118]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.118]) with mapi id 15.01.0049.002; Wed, 7 Jan 2015 15:27:24 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Dolganow, Andrew (Andrew)" , "Eric Rosen" , BIER Thread-Topic: [Bier] Optimized explicit tracking for BIER Thread-Index: AQHQKonWjzlwi/b1R0aFyEcSD6UYjZy0wI2AgAAAgICAAAMPgIAAAUfA Date: Wed, 7 Jan 2015 15:27:24 +0000 Message-ID: References: <54AC0915.4000804@juniper.net> <54AD487B.5050302@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005003); SRVR:CY1PR0501MB1097; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1097; x-forefront-prvs: 044968D9E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(51704005)(189002)(377454003)(199003)(377424004)(99396003)(74316001)(68736005)(120916001)(31966008)(102836002)(15975445007)(97736003)(77156002)(106116001)(105586002)(106356001)(62966003)(2656002)(87936001)(93886004)(46102003)(2950100001)(2900100001)(122556002)(40100003)(76576001)(66066001)(54356999)(76176999)(50986999)(54606007)(64706001)(20776003)(4396001)(92566001)(99286002)(107886001)(107046002)(19580405001)(101416001)(19580395003)(33656002)(561944003)(54206007)(86362001)(21056001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1097; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2015 15:27:24.6868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1097 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1545; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/bier/Q3CAydhjHEJCkn41h-oBbjdYW6I Subject: Re: [Bier] Optimized explicit tracking for BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:27:36 -0000 Andrew, I read that draft again, and the closest to what you're saying below is the= following: 3.1. S-PMSI A-D route without tunnel information This case applies when S-PMSI A-D route does not exist OR S-PMSI A-D route's Multicast Source and Multicast Group fields do not encode the stream to be tracked. ... Tunnel Type field set to "No tunnel information". However the following section does not talk about it at all: 4.1.1. S-PMSI A-D route without tunnel information Besides, in Eric's email, a different flag bit is used, and the tunnel type= field can be a valid tunnel type istead of "no tunnel info". Additionally, section 4.2 does not really say that individual (C-S,C-G) Lea= f AD routes will be originated. I read it as corresponding wildcard Leaf AD= routes would be originated. Even if the intention is indeed to originate individual (C-S,C-G) Leaf AD r= outes, then definitely more text is needed, and we must not rely on the "no= tunnel info". Instead, a separate indication is needed. Jeffrey > -----Original Message----- > From: Dolganow, Andrew (Andrew) [mailto:andrew.dolganow@alcatel- > lucent.com] > Sent: Wednesday, January 07, 2015 10:14 AM > To: Jeffrey (Zhaohui) Zhang; Eric Rosen; BIER > Subject: Re: [Bier] Optimized explicit tracking for BIER >=20 > Jeff, >=20 > What the draft say is you say individual Leaf A-D route if that route > would match the received S-PMSI A-D wildcard route for data transmission > based on 6625 procedures - see procedures on Receiver PE for wildcard > processing in the draft - maybe they need some more text or > clarification? >=20 > Andrew >=20 > On 2015-01-07, 10:06 AM, "Jeffrey (Zhaohui) Zhang" wrote: >=20 > >Andrew, > > > >> That is exactly how general (C-*, C-*) tracking works based on draft > >> clarifying 6513/6513/6625. > > > >Perhaps we missed it, but if that draft is just "clarifying" > >6513/6514/6625, then you would not send individual (C-S,C-G) Leaf AD > >routes if you did not receive corresponding S-PMSI AD routes. > > > >If that draft did say that, then it is no longer just a "clarifying" > >draft. > > > >Jeffrey > > > >> -----Original Message----- > >> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Dolganow, > Andrew > >> (Andrew) > >> Sent: Wednesday, January 07, 2015 10:01 AM > >> To: Eric Rosen; BIER > >> Subject: Re: [Bier] Optimized explicit tracking for BIER > >> > >> Eric, > >> > >> inline > >> > >> On 2015-01-07, 9:53 AM, "Eric C Rosen" wrote: > >> > >> >> I find the below procedure thus duplicate of what we already have > on > >> >> the table for general explicit Tracking in ng-MVPN - including > BIER. > >> > > >> >If I understand your draft correctly, to invoke explicit tracking > for a > >> >particular (C-S,C-G) flow, the ingress PE must originate a (C-S,C-G) > >> >S-PMSI A-D route. > >> > >> Not necessarily. If, for example, Source PE wants to know of all (C-S, > >> C-G)s, it would simply send explicit tracking for (C-*, C-*), that > would > >> make the receiver to respond with ALL (C-S, C-G)s that would match > this > >> wildcard S-PMSI (which for BIER would do what you are looking at). > >> > >> > > >> >In the proposal described in my message, there is no need for the > >> >ingress PE to originate an (C-S,C-G) S-PMSI A-D route for each flow. > >> It > >> >originates a single (C-*,C-*) S-PMSI A-D route, and this causes it > to > >> >receive a Leaf A-D route for each (C-S,C-G). > >> > >> That is exactly how general (C-*, C-*) tracking works based on draft > >> clarifying 6513/6513/6625. > >> > > >> >I don't think this duplicates what you have in your draft. > >> > > >> >> The above draft clarifies things up and allows explicit tracking > for > >> any > >> >> S-PMSI route, including any wildcards, without a need for any new > >> >> procedures/encodings > >> > > >> >But with a lot more control plane messaging. If we know we're using > >> >BIER, we can optimize by eliminating a whole bunch of S-PMSI A-D > >>routes, > >> >but that does require some new procedures/encodings. > >> > >> This does not apply, based on my above explanation. > >> > >> Andrew > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> _______________________________________________ > >> BIER mailing list > >> BIER@ietf.org > >> https://www.ietf.org/mailman/listinfo/bier From nobody Wed Jan 7 07:44:59 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137F61A9131 for ; Wed, 7 Jan 2015 07:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_99_Jvvtgp2 for ; Wed, 7 Jan 2015 07:44:51 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0129.outbound.protection.outlook.com [207.46.100.129]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2C51A914B for ; Wed, 7 Jan 2015 07:44:51 -0800 (PST) Received: from [172.29.33.129] (66.129.241.13) by BY1PR0501MB1095.namprd05.prod.outlook.com (25.160.103.141) with Microsoft SMTP Server (TLS) id 15.1.49.12; Wed, 7 Jan 2015 15:44:49 +0000 Message-ID: <54AD546B.9040409@juniper.net> Date: Wed, 7 Jan 2015 10:44:43 -0500 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Dolganow, Andrew (Andrew)" , "Jeffrey (Zhaohui) Zhang" , BIER References: <54AC0915.4000804@juniper.net> <54AD487B.5050302@juniper.net> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY2PR04CA043.namprd04.prod.outlook.com (10.141.249.161) To BY1PR0501MB1095.namprd05.prod.outlook.com (25.160.103.141) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BY1PR0501MB1095; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA: BCL:0; PCL:0; RULEID:(601004); SRVR:BY1PR0501MB1095; X-Forefront-PRVS: 044968D9E1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(189002)(199003)(35774003)(105586002)(106356001)(101416001)(4396001)(46102003)(20776003)(47776003)(59896002)(50466002)(64706001)(87976001)(65806001)(66066001)(97736003)(83506001)(107046002)(33656002)(120916001)(99396003)(21056001)(80316001)(40100003)(23746002)(86362001)(122386002)(92566001)(93886004)(31966008)(76176999)(50986999)(87266999)(54356999)(64126003)(65816999)(42186005)(68736005)(77096005)(36756003)(77156002)(62966003)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1095; H:[172.29.33.129]; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1095; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2015 15:44:49.5391 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1095 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/cjuShtqGVeelDAlbwuR1YQkMB_A Cc: erosen@juniper.net Subject: Re: [Bier] Explicit Tracking X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:44:58 -0000 Let me write down how I think explicit tracking should work, and you can tell me whether (a) it's at odds with what's in your draft, or (b) it duplicates what's in your draft, or (c) it extends what's in your draft in a useful way, or (d) it extends what's in your draft in a useless way ;-) (Perhaps this discussion really belongs on the BESS ML, but we might as well continue it here for a little while.) RFC6625 (and other RFCs or RFCs-to-be that update RFC6625) specify a set of rules for finding the S-PMSI A-D route that is the "match for reception" for a given (C-S,C-G) or (C-*,C-G) state. As draft-dolganow-l3vpn-mvpn-expl-track points out, the defintion of "match for reception" needs to be modified as follows: When finding the "match for reception" for a given (C-S,C-G) or (C-*,C-G), ignore any S-PMSI A-D route that has no PMSI Tunnel attribute (PTA), or that has a PTA specifying "no tunnel info". I'd like to propose now to introduce a new notion: the "match for tracking". This differs from the "match for reception" as follows: For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for tracking" is chosen as follows. Ignore any S-PMSI A-D route that has no PTA, or whose PTA does not have either LIR or LIR-pF set. (In particular, DO NOT ignore an S-PMSI A-D route that has a PTA specifying "no tunnel info", but whose LIR or LIR-pF bits are set). Then apply the rules (from RFC6625 and other RFCs or RFCs-to-be that update it) for finding the "match for reception". The result (if any) is the match for tracking". For example, suppose a given PE router, PE1, has chosen PE2 as the "upstream PE" for a given (C-S1,C-G1). And suppose PE1 has installed the following two routes that were originated by PE2: Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a tunnel. Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no tunnel info" and has LIR set. Route1 is (C-S1,C-G1)'s match for reception, and Route2 is (C-S1,C-G1)'s match for tracking. Note that if there is no installed S-PMSI A-D route for (C-S2,C-G2), then Route1 would be (C-S2,C-G2)'s match for reception and also its match for tracking. As another example, suppose PE1 has installed the following two routes that were originated by PE2: Route3: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the PTA specifies a tunnel) Route4: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a tunnel. Then Route 4 is both the "match for reception" and the "match for tracking" for (C-S1,C-G1). Note that for a particular C-flow, the PE1's match for reception might be the same route as its match for tracking, or its match for reception might be a "less specific" route than its match for tracking. But its match for reception can never be a "more specific" route than its match for tracking. Now we have a number of cases to look at: 1. PE1's match for tracking the is same as its match for reception, but neither LIR nor LIR-pF flags are on. In this case, there is no explicit tracking for the C-flow. The match for reception is processed according to existing procedures. 2. PE1's match for tracking is the same as its match for reception, LIR is set, LIR-pF is not set. In this case, existing procedures are followed. 3. PE1's match for tracking is the same as its match for reception, and LIR-pF is set. This case is discussed in a previous message. 4. PE1's match for tracking is not the same as its match for reception. This can only happen if the match for tracking has a PTA specifying "no tunnel info", with either LIR or LIR-pF set. In this case, PE1 must respond both to the match for tracking and to the match for reception. To respond to the match for tracking, PE1 originates one or more Leaf A-D routes; the PTA of each such route will specify "no tunnel info". Construction of the NLRI of the Leaf A-D route is as specified in RFC6514 (if LIR is set) or as specified in the referenced message on the BIER mailing list (if LIR-pF) is set. To respond to the match for reception, existing procedures are used. Note that if LIR or LIR-pF are set in the PTA of the match for reception, PE1 may need to originate a Leaf A-D route corresponding to the match for tracking as well as originating a Leaf A-D route corresponding to the match for reception. I think the above procedures work at an egress PE, but they are not quite right for an egress ABR/ASBR. An egress ABR/ASBR does forward along any S-PMSI A-D routes it gets. If the PTA of the received S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR may change the PTA to specify a different tunnel type. However, we should require that if the PTA specifies "no tunnel info", it is passed along unchanged. Then we can establish the following rule for egress ABRs/ASBRs. Suppose an egress ABR/ASBR receives an S-PMSI A-D route whose NLRI is X, and whose PTA (a) specifies "no tunnel info" and (b) has LIR set. The egress ABR/ASBR should not immediately originate a Leaf A-D route in response. Rather it should wait until it receives a Leaf A-D route whose NLRI contains X in the "route key" field. If it receives such a Leaf A-D route, it redistributes that route, but first it changes that route's RT. The "global administrator" field of the modified RT will be set to the IP address taken either from the S-PMSI A-D route's next hop field, or from its Segmented P2MP Next Hop Extended Community. This will ensure that an egress ABR/ASBR only sends a Leaf A-D route in response to a "match for tracking" if it is on the path to an egress PE for the flow(s) identified in the corresponding S-PMSI A-D route. Comments? From nobody Wed Jan 7 07:48:13 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176421A9150 for ; Wed, 7 Jan 2015 07:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nrVkXeZABYy for ; Wed, 7 Jan 2015 07:47:55 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564C81A8845 for ; Wed, 7 Jan 2015 07:47:55 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 1797428013974; Wed, 7 Jan 2015 15:47:49 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t07Flpb3001389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 10:47:51 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 10:47:51 -0500 From: "Dolganow, Andrew (Andrew)" To: "Jeffrey (Zhaohui) Zhang" , Eric Rosen , BIER Thread-Topic: [Bier] Optimized explicit tracking for BIER Thread-Index: AQHQKom93EdX9TINTE+uy/5YOwzLgpy0wI2AgAAAgICAAAMPgIAAAUfAgAAHcYA= Date: Wed, 7 Jan 2015 15:47:50 +0000 Message-ID: References: <54AC0915.4000804@juniper.net> <54AD487B.5050302@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [135.5.27.16] Content-Type: multipart/mixed; boundary="_004_D0D2BCB865617andrewdolganowalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/923HOcYixQeoohS5vs99iWYsElw Subject: Re: [Bier] Optimized explicit tracking for BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:47:59 -0000 --_004_D0D2BCB865617andrewdolganowalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-ID: <7975CDFEEDAA5C48900A9CC9755D5C8C@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable Let=B9s say the Sender sends S-PMSI A-D (C-*,C-*) route without or with tunnel info (which will be BIER for BIER). I am including what I think would apply to BIER (wildcard request with Leaf info required flag set and BIER =B3tunnel=B2 encoded an dput =B3=8A=B2 for non-applicable text): 4.2: PE receiving S-MPSI A-D route with tracking request, performs procedures defined in section 12.3 of [MVPN-NG] either ... or as consequence of procedures of section 4 of [MVPN-WC] for wildcard stream tracking request with the following modifications: 1. ... 2. If a PE determines that it no longer is to receive traffic for an explicitly tracked multicast stream from the PE that originated explicit tracking for that streams, the PE MUST withdraw the Leaf A-D route originated in response to explicit tracking using standard procedures defined in [MVPN-BGP]. - could apply 3. If a PE determines that it is to receive traffic for an explicitly tracked multicast stream from the PE that originated explicit tracking for that streams, the PE MUST re-originate a Leaf A-D route as defined in [MVPN-BGP]. - this will cause the Leaf A-D per (C-S, C-G) as on Receiver those would map to (C-*, C-*) wildcard (S-PMSI as per procedures of RFC6625. Andrew On 2015-01-07, 10:27 AM, "Jeffrey (Zhaohui) Zhang" wrote: >Andrew, > >I read that draft again, and the closest to what you're saying below is >the following: > >3.1. S-PMSI A-D route without tunnel information > > This case applies when S-PMSI A-D route does not exist OR S-PMSI A-D > route's Multicast Source and Multicast Group fields do not encode the > stream to be tracked. > > ... Tunnel Type field set to "No tunnel information". > >However the following section does not talk about it at all: > >4.1.1. S-PMSI A-D route without tunnel information > >Besides, in Eric's email, a different flag bit is used, and the tunnel >type field can be a valid tunnel type istead of "no tunnel info". > >Additionally, section 4.2 does not really say that individual (C-S,C-G) >Leaf AD routes will be originated. I read it as corresponding wildcard >Leaf AD routes would be originated. > >Even if the intention is indeed to originate individual (C-S,C-G) Leaf AD >routes, then definitely more text is needed, and we must not rely on the >"no tunnel info". Instead, a separate indication is needed. > >Jeffrey > >> -----Original Message----- >> From: Dolganow, Andrew (Andrew) [mailto:andrew.dolganow@alcatel- >> lucent.com] >> Sent: Wednesday, January 07, 2015 10:14 AM >> To: Jeffrey (Zhaohui) Zhang; Eric Rosen; BIER >> Subject: Re: [Bier] Optimized explicit tracking for BIER >>=20 >> Jeff, >>=20 >> What the draft say is you say individual Leaf A-D route if that route >> would match the received S-PMSI A-D wildcard route for data transmission >> based on 6625 procedures - see procedures on Receiver PE for wildcard >> processing in the draft - maybe they need some more text or >> clarification? >>=20 >> Andrew >>=20 >> On 2015-01-07, 10:06 AM, "Jeffrey (Zhaohui) Zhang" wrote: >>=20 >> >Andrew, >> > >> >> That is exactly how general (C-*, C-*) tracking works based on draft >> >> clarifying 6513/6513/6625. >> > >> >Perhaps we missed it, but if that draft is just "clarifying" >> >6513/6514/6625, then you would not send individual (C-S,C-G) Leaf AD >> >routes if you did not receive corresponding S-PMSI AD routes. >> > >> >If that draft did say that, then it is no longer just a "clarifying" >> >draft. >> > >> >Jeffrey >> > >> >> -----Original Message----- >> >> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Dolganow, >> Andrew >> >> (Andrew) >> >> Sent: Wednesday, January 07, 2015 10:01 AM >> >> To: Eric Rosen; BIER >> >> Subject: Re: [Bier] Optimized explicit tracking for BIER >> >> >> >> Eric, >> >> >> >> inline >> >> >> >> On 2015-01-07, 9:53 AM, "Eric C Rosen" wrote: >> >> >> >> >> I find the below procedure thus duplicate of what we already have >> on >> >> >> the table for general explicit Tracking in ng-MVPN - including >> BIER. >> >> > >> >> >If I understand your draft correctly, to invoke explicit tracking >> for a >> >> >particular (C-S,C-G) flow, the ingress PE must originate a (C-S,C-G) >> >> >S-PMSI A-D route. >> >> >> >> Not necessarily. If, for example, Source PE wants to know of all >>(C-S, >> >> C-G)s, it would simply send explicit tracking for (C-*, C-*), that >> would >> >> make the receiver to respond with ALL (C-S, C-G)s that would match >> this >> >> wildcard S-PMSI (which for BIER would do what you are looking at). >> >> >> >> > >> >> >In the proposal described in my message, there is no need for the >> >> >ingress PE to originate an (C-S,C-G) S-PMSI A-D route for each flow. >> >> It >> >> >originates a single (C-*,C-*) S-PMSI A-D route, and this causes it >> to >> >> >receive a Leaf A-D route for each (C-S,C-G). >> >> >> >> That is exactly how general (C-*, C-*) tracking works based on draft >> >> clarifying 6513/6513/6625. >> >> > >> >> >I don't think this duplicates what you have in your draft. >> >> > >> >> >> The above draft clarifies things up and allows explicit tracking >> for >> >> any >> >> >> S-PMSI route, including any wildcards, without a need for any new >> >> >> procedures/encodings >> >> > >> >> >But with a lot more control plane messaging. If we know we're using >> >> >BIER, we can optimize by eliminating a whole bunch of S-PMSI A-D >> >>routes, >> >> >but that does require some new procedures/encodings. >> >> >> >> This does not apply, based on my above explanation. >> >> >> >> Andrew >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> BIER mailing list >> >> BIER@ietf.org >> >> https://www.ietf.org/mailman/listinfo/bier > --_004_D0D2BCB865617andrewdolganowalcatellucentcom_ Content-Type: application/xml; name="default.xml" Content-Description: default.xml Content-Disposition: attachment; filename="default.xml"; size=3222; creation-date="Wed, 07 Jan 2015 15:47:50 GMT"; modification-date="Wed, 07 Jan 2015 15:47:50 GMT" Content-ID: <51248F0778A1BB40BAC5A8534E774C01@exchange.lucent.com> Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF 94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr /4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b 1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH 1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f //H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+ /uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+ AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9 DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6 Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3 6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1 LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl 6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --_004_D0D2BCB865617andrewdolganowalcatellucentcom_ Content-Type: application/xml; name="default[1].xml" Content-Description: default[1].xml Content-Disposition: attachment; filename="default[1].xml"; size=3222; creation-date="Wed, 07 Jan 2015 15:47:50 GMT"; modification-date="Wed, 07 Jan 2015 15:47:50 GMT" Content-ID: Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF 94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr /4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b 1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH 1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f //H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+ /uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+ AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9 DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6 Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3 6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1 LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl 6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --_004_D0D2BCB865617andrewdolganowalcatellucentcom_ Content-Type: application/xml; name="default[2].xml" Content-Description: default[2].xml Content-Disposition: attachment; filename="default[2].xml"; size=3222; creation-date="Wed, 07 Jan 2015 15:47:50 GMT"; modification-date="Wed, 07 Jan 2015 15:47:50 GMT" Content-ID: <5533985937E17644879B260B23C34FB6@exchange.lucent.com> Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF 94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr /4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b 1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH 1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f //H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+ /uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+ AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9 DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6 Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3 6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1 LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl 6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --_004_D0D2BCB865617andrewdolganowalcatellucentcom_-- From nobody Wed Jan 7 07:57:25 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809A01A9138 for ; Wed, 7 Jan 2015 07:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0yM1Izt3T60 for ; Wed, 7 Jan 2015 07:57:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C361A913E for ; Wed, 7 Jan 2015 07:57:05 -0800 (PST) Received: from BN3PR0501MB1089.namprd05.prod.outlook.com (25.160.113.11) by BN3PR0501MB1427.namprd05.prod.outlook.com (25.160.117.149) with Microsoft SMTP Server (TLS) id 15.1.49.12; Wed, 7 Jan 2015 15:56:43 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BN3PR0501MB1089.namprd05.prod.outlook.com (25.160.113.11) with Microsoft SMTP Server (TLS) id 15.1.53.17; Wed, 7 Jan 2015 15:56:41 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.118]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.118]) with mapi id 15.01.0049.002; Wed, 7 Jan 2015 15:56:40 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Dolganow, Andrew (Andrew)" , "Eric Rosen" , BIER Thread-Topic: [Bier] Optimized explicit tracking for BIER Thread-Index: AQHQKonWjzlwi/b1R0aFyEcSD6UYjZy0wI2AgAAAgICAAAMPgIAAAUfAgAAIHgCAAADlYA== Date: Wed, 7 Jan 2015 15:56:40 +0000 Message-ID: References: <54AC0915.4000804@juniper.net> <54AD487B.5050302@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005003); SRVR:BN3PR0501MB1089; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1089; x-forefront-prvs: 044968D9E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(377424004)(24454002)(52314003)(189002)(377454003)(13464003)(40100003)(62966003)(101416001)(93886004)(19580395003)(77156002)(19580405001)(31966008)(97736003)(561944003)(74316001)(54206007)(4396001)(46102003)(105586002)(66066001)(106116001)(102836002)(86362001)(87936001)(15975445007)(99286002)(120916001)(76576001)(107046002)(107886001)(2900100001)(99396003)(2950100001)(21056001)(92566001)(106356001)(50986999)(54356999)(64706001)(122556002)(76176999)(33656002)(54606007)(20776003)(2656002)(68736005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1089; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2015 15:56:40.2918 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1089 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1427; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/bier/y27yOT9Ynv0cghMPCQY7CQdL3zQ Subject: Re: [Bier] Optimized explicit tracking for BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:57:22 -0000 > 3. If a PE determines that it is to receive traffic for an explicitly > tracked multicast stream from the PE that originated explicit tracking > for that streams, the PE MUST re-originate a Leaf A-D route as defined in > [MVPN-BGP]. - this will cause the Leaf A-D per (C-S, C-G) as on Receiver > those would map to (C-*, C-*) wildcard (S-PMSI as per procedures of > RFC6625. While a particular (C-S,C-G) maps to a (C-*,C-*) wildcard, the text does no= t say individual (C-S,C-G) Leaf AD routes will be originated. The 6514/6625= procedures say (C-*,C-*) Leaf AD route will be originated. Anyway, as Eric said, we're now on the same page wrt triggering (C-S,C-G) L= eaf AD w/o requiring corresponding S-PMSI AD route. More text and encoding = are needed to complete that. Jeffrey > -----Original Message----- > From: Dolganow, Andrew (Andrew) [mailto:andrew.dolganow@alcatel- > lucent.com] > Sent: Wednesday, January 07, 2015 10:48 AM > To: Jeffrey (Zhaohui) Zhang; Eric Rosen; BIER > Subject: Re: [Bier] Optimized explicit tracking for BIER >=20 > Let=B9s say the Sender sends S-PMSI A-D (C-*,C-*) route without or with > tunnel info (which will be BIER for BIER). I am including what I think > would apply to BIER (wildcard request with Leaf info required flag set > and > BIER =B3tunnel=B2 encoded an dput =B3=D0=B2 for non-applicable text): >=20 > 4.2: >=20 > PE receiving S-MPSI A-D route with tracking request, performs procedures > defined in section 12.3 of [MVPN-NG] either ... or as consequence of > procedures of section 4 of [MVPN-WC] for wildcard stream tracking > request > with the following modifications: >=20 > 1. ... >=20 > 2. If a PE determines that it no longer is to receive traffic for an > explicitly tracked multicast stream from the PE that originated explicit > tracking for that streams, the PE MUST withdraw the Leaf A-D route > originated in response to explicit tracking using standard procedures > defined in [MVPN-BGP]. - could apply > 3. If a PE determines that it is to receive traffic for an explicitly > tracked multicast stream from the PE that originated explicit tracking > for > that streams, the PE MUST re-originate a Leaf A-D route as defined in > [MVPN-BGP]. - this will cause the Leaf A-D per (C-S, C-G) as on Receiver > those would map to (C-*, C-*) wildcard (S-PMSI as per procedures of > RFC6625. >=20 > Andrew >=20 >=20 >=20 > On 2015-01-07, 10:27 AM, "Jeffrey (Zhaohui) Zhang" wrote: >=20 > >Andrew, > > > >I read that draft again, and the closest to what you're saying below is > >the following: > > > >3.1. S-PMSI A-D route without tunnel information > > > > This case applies when S-PMSI A-D route does not exist OR S-PMSI A-D > > route's Multicast Source and Multicast Group fields do not encode > the > > stream to be tracked. > > > > ... Tunnel Type field set to "No tunnel information". > > > >However the following section does not talk about it at all: > > > >4.1.1. S-PMSI A-D route without tunnel information > > > >Besides, in Eric's email, a different flag bit is used, and the tunnel > >type field can be a valid tunnel type istead of "no tunnel info". > > > >Additionally, section 4.2 does not really say that individual (C-S,C-G) > >Leaf AD routes will be originated. I read it as corresponding wildcard > >Leaf AD routes would be originated. > > > >Even if the intention is indeed to originate individual (C-S,C-G) Leaf > AD > >routes, then definitely more text is needed, and we must not rely on > the > >"no tunnel info". Instead, a separate indication is needed. > > > >Jeffrey > > > >> -----Original Message----- > >> From: Dolganow, Andrew (Andrew) [mailto:andrew.dolganow@alcatel- > >> lucent.com] > >> Sent: Wednesday, January 07, 2015 10:14 AM > >> To: Jeffrey (Zhaohui) Zhang; Eric Rosen; BIER > >> Subject: Re: [Bier] Optimized explicit tracking for BIER > >> > >> Jeff, > >> > >> What the draft say is you say individual Leaf A-D route if that route > >> would match the received S-PMSI A-D wildcard route for data > transmission > >> based on 6625 procedures - see procedures on Receiver PE for wildcard > >> processing in the draft - maybe they need some more text or > >> clarification? > >> > >> Andrew > >> > >> On 2015-01-07, 10:06 AM, "Jeffrey (Zhaohui) Zhang" wrote: > >> > >> >Andrew, > >> > > >> >> That is exactly how general (C-*, C-*) tracking works based on > draft > >> >> clarifying 6513/6513/6625. > >> > > >> >Perhaps we missed it, but if that draft is just "clarifying" > >> >6513/6514/6625, then you would not send individual (C-S,C-G) Leaf AD > >> >routes if you did not receive corresponding S-PMSI AD routes. > >> > > >> >If that draft did say that, then it is no longer just a "clarifying" > >> >draft. > >> > > >> >Jeffrey > >> > > >> >> -----Original Message----- > >> >> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Dolganow, > >> Andrew > >> >> (Andrew) > >> >> Sent: Wednesday, January 07, 2015 10:01 AM > >> >> To: Eric Rosen; BIER > >> >> Subject: Re: [Bier] Optimized explicit tracking for BIER > >> >> > >> >> Eric, > >> >> > >> >> inline > >> >> > >> >> On 2015-01-07, 9:53 AM, "Eric C Rosen" wrote: > >> >> > >> >> >> I find the below procedure thus duplicate of what we already > have > >> on > >> >> >> the table for general explicit Tracking in ng-MVPN - including > >> BIER. > >> >> > > >> >> >If I understand your draft correctly, to invoke explicit tracking > >> for a > >> >> >particular (C-S,C-G) flow, the ingress PE must originate a (C- > S,C-G) > >> >> >S-PMSI A-D route. > >> >> > >> >> Not necessarily. If, for example, Source PE wants to know of all > >>(C-S, > >> >> C-G)s, it would simply send explicit tracking for (C-*, C-*), that > >> would > >> >> make the receiver to respond with ALL (C-S, C-G)s that would match > >> this > >> >> wildcard S-PMSI (which for BIER would do what you are looking at). > >> >> > >> >> > > >> >> >In the proposal described in my message, there is no need for the > >> >> >ingress PE to originate an (C-S,C-G) S-PMSI A-D route for each > flow. > >> >> It > >> >> >originates a single (C-*,C-*) S-PMSI A-D route, and this causes > it > >> to > >> >> >receive a Leaf A-D route for each (C-S,C-G). > >> >> > >> >> That is exactly how general (C-*, C-*) tracking works based on > draft > >> >> clarifying 6513/6513/6625. > >> >> > > >> >> >I don't think this duplicates what you have in your draft. > >> >> > > >> >> >> The above draft clarifies things up and allows explicit > tracking > >> for > >> >> any > >> >> >> S-PMSI route, including any wildcards, without a need for any > new > >> >> >> procedures/encodings > >> >> > > >> >> >But with a lot more control plane messaging. If we know we're > using > >> >> >BIER, we can optimize by eliminating a whole bunch of S-PMSI A-D > >> >>routes, > >> >> >but that does require some new procedures/encodings. > >> >> > >> >> This does not apply, based on my above explanation. > >> >> > >> >> Andrew > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > >> >> _______________________________________________ > >> >> BIER mailing list > >> >> BIER@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/bier > > From nobody Wed Jan 7 08:07:36 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFC01A9163 for ; Wed, 7 Jan 2015 08:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acSGWhNYhX9z for ; Wed, 7 Jan 2015 08:07:21 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6FE1A9167 for ; Wed, 7 Jan 2015 08:07:20 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 1693A603D55A1; Wed, 7 Jan 2015 16:07:15 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t07G7HSR000964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 11:07:17 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 11:07:17 -0500 From: "Dolganow, Andrew (Andrew)" To: Eric C Rosen , "Jeffrey (Zhaohui) Zhang" , BIER Thread-Topic: [Bier] Explicit Tracking Thread-Index: AQHQKpDgK6fpOdop/UqTaUBK+j117py00uKA Date: Wed, 7 Jan 2015 16:07:17 +0000 Message-ID: References: <54AC0915.4000804@juniper.net> <54AD487B.5050302@juniper.net> <54AD546B.9040409@juniper.net> In-Reply-To: <54AD546B.9040409@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-ID: <6A8A8CCDC5CCA848A0D1CC07DBE3EB0F@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/r2YLjxSnxwdLXFmmUIVRNRneEZ0 Subject: Re: [Bier] Explicit Tracking X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:07:25 -0000 Eric, I think we converged. Please correct me: 1. I think we want to have 2 options for wildcard tracking - return to wildcard tracking with wildcard Leaf A-D - return to wildcard tracking with per (C-S, C-G) Leaf A-D Correct? My draft had only one option and clearly there were various assumptions what type of Leaf A-D route you send to Sender PE based on wildcard match. Now to handle two cases I agree we need an extra flag or something to differentiate between response that sends Leaf A-D wildcard route and response that sends Leaf A-D per (C-S, C-G) route. Please note that my draft allows any wildcard tracking, so I assume you not limiting tracking to only (C-*, C-G) wildcard as per below, correct? Since this is a general explicit tracking, I propose we merge the two proposals, so everyone can look at this from general explicit tracking procedures for any case. We probably should then bring this discussion to BLESS. Andrew On 2015-01-07, 10:44 AM, "Eric C Rosen" wrote: >Let me write down how I think explicit tracking should work, and you can >tell me whether (a) it's at odds with what's in your draft, or (b) it >duplicates what's in your draft, or (c) it extends what's in your draft >in a useful way, or (d) it extends what's in your draft in a useless way >;-) > >(Perhaps this discussion really belongs on the BESS ML, but we might as >well continue it here for a little while.) > >RFC6625 (and other RFCs or RFCs-to-be that update RFC6625) specify a >set of rules for finding the S-PMSI A-D route that is the "match for >reception" for a given (C-S,C-G) or (C-*,C-G) state. As >draft-dolganow-l3vpn-mvpn-expl-track points out, the defintion of "match >for reception" needs to be modified as follows: > > When finding the "match for reception" for a given (C-S,C-G) or > (C-*,C-G), ignore any S-PMSI A-D route that has no PMSI Tunnel > attribute (PTA), or that has a PTA specifying "no tunnel info". > >I'd like to propose now to introduce a new notion: the "match for >tracking". This differs from the "match for reception" as follows: > > For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for tracking" > is chosen as follows. Ignore any S-PMSI A-D route that has no PTA, > or whose PTA does not have either LIR or LIR-pF set. (In particular, > DO NOT ignore an S-PMSI A-D route that has a PTA specifying "no > tunnel info", but whose LIR or LIR-pF bits are set). Then apply the > rules (from RFC6625 and other RFCs or RFCs-to-be that update it) for > finding the "match for reception". The result (if any) is the > match for tracking". > >For example, suppose a given PE router, PE1, has chosen PE2 as the >"upstream PE" for a given (C-S1,C-G1). And suppose PE1 has installed >the following two routes that were originated by PE2: > >Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a tunnel. > >Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no tunnel >info" and has LIR set. > >Route1 is (C-S1,C-G1)'s match for reception, and Route2 is (C-S1,C-G1)'s >match for tracking. > >Note that if there is no installed S-PMSI A-D route for (C-S2,C-G2), >then Route1 would be (C-S2,C-G2)'s match for reception and also its >match for tracking. > >As another example, suppose PE1 has installed the following two routes >that were originated by PE2: > >Route3: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the PTA >specifies a tunnel) > >Route4: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a tunnel. > >Then Route 4 is both the "match for reception" and the "match for >tracking" for (C-S1,C-G1). > >Note that for a particular C-flow, the PE1's match for reception might >be the same route as its match for tracking, or its match for reception >might be a "less specific" route than its match for tracking. But its >match for reception can never be a "more specific" route than its match >for tracking. > >Now we have a number of cases to look at: > >1. PE1's match for tracking the is same as its match for reception, but >neither LIR nor LIR-pF flags are on. In this case, there is no explicit >tracking for the C-flow. The match for reception is processed >according to existing procedures. > >2. PE1's match for tracking is the same as its match for reception, LIR >is set, LIR-pF is not set. In this case, existing procedures are >followed. > >3. PE1's match for tracking is the same as its match for reception, and >LIR-pF is set. This case is discussed in a previous message. > >4. PE1's match for tracking is not the same as its match for reception. >This can only happen if the match for tracking has a PTA specifying "no >tunnel info", with either LIR or LIR-pF set. In this case, PE1 must >respond both to the match for tracking and to the match for reception. >To respond to the match for tracking, PE1 originates one or more Leaf >A-D routes; the PTA of each such route will specify "no tunnel info". >Construction of the NLRI of the Leaf A-D route is as specified in >RFC6514 (if LIR is set) or as specified in the referenced message on the >BIER mailing list (if LIR-pF) is set. To respond to the match for >reception, existing procedures are used. Note that if LIR or LIR-pF are >set in the PTA of the match for reception, PE1 may need to originate a >Leaf A-D route corresponding to the match for tracking as well as >originating a Leaf A-D route corresponding to the match for reception. > >I think the above procedures work at an egress PE, but they are not >quite right for an egress ABR/ASBR. An egress ABR/ASBR does forward >along any S-PMSI A-D routes it gets. If the PTA of the received S-PMSI >A-D route specifies a tunnel, the egress ABR/ASBR may change the PTA to >specify a different tunnel type. However, we should require that if the >PTA specifies "no tunnel info", it is passed along unchanged. > >Then we can establish the following rule for egress ABRs/ASBRs. Suppose >an egress ABR/ASBR receives an S-PMSI A-D route whose NLRI is X, and >whose PTA (a) specifies "no tunnel info" and (b) has LIR set. The >egress ABR/ASBR should not immediately originate a Leaf A-D route in >response. Rather it should wait until it receives a Leaf A-D route >whose NLRI contains X in the "route key" field. If it receives such a >Leaf A-D route, it redistributes that route, but first it changes that >route's RT. The "global administrator" field of the modified RT will be >set to the IP address taken either from the S-PMSI A-D route's next hop >field, or from its Segmented P2MP Next Hop Extended Community. > >This will ensure that an egress ABR/ASBR only sends a Leaf A-D route in >response to a "match for tracking" if it is on the path to an egress PE >for the flow(s) identified in the corresponding S-PMSI A-D route. > >Comments? > > > > > From nobody Thu Jan 8 08:00:52 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88C31A8ABC for ; Thu, 8 Jan 2015 08:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKVtd43nukl9 for ; Thu, 8 Jan 2015 08:00:42 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0767.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::767]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2F91A8AD1 for ; Thu, 8 Jan 2015 08:00:40 -0800 (PST) Received: from [172.29.33.129] (66.129.241.13) by BY1PR0501MB1095.namprd05.prod.outlook.com (25.160.103.141) with Microsoft SMTP Server (TLS) id 15.1.49.12; Thu, 8 Jan 2015 16:00:17 +0000 Message-ID: <54AEA989.50803@juniper.net> Date: Thu, 8 Jan 2015 11:00:09 -0500 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Dolganow, Andrew (Andrew)" , "Jeffrey (Zhaohui) Zhang" , BIER References: <54AC0915.4000804@juniper.net> <54AD487B.5050302@juniper.net> <54AD546B.9040409@juniper.net> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BLUPR11CA0022.namprd11.prod.outlook.com (10.141.240.32) To BY1PR0501MB1095.namprd05.prod.outlook.com (25.160.103.141) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BY1PR0501MB1095; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA: BCL:0; PCL:0; RULEID:(601004); SRVR:BY1PR0501MB1095; X-Forefront-PRVS: 0450A714CB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(479174004)(24454002)(35774003)(189002)(199003)(51704005)(377424004)(377454003)(64126003)(76176999)(50986999)(31966008)(92566001)(93886004)(62966003)(77156002)(2950100001)(77096005)(36756003)(42186005)(65816999)(54356999)(23746002)(68736005)(50466002)(122386002)(86362001)(47776003)(20776003)(64706001)(87976001)(65806001)(106356001)(105586002)(4396001)(46102003)(101416001)(99396003)(21056001)(120916001)(1941001)(40100003)(97736003)(66066001)(83506001)(33656002)(107046002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1095; H:[172.29.33.129]; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1095; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2015 16:00:17.0397 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1095 Archived-At: Cc: erosen@juniper.net Subject: Re: [Bier] Explicit Tracking X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:00:47 -0000 On 1/7/2015 11:07 AM, Dolganow, Andrew (Andrew) wrote: > Eric, > > I think we converged. Yes, I don't think we have any real disagreement. > Please note that my draft allows any wildcard tracking, so I assume you > not limiting tracking to only (C-*, C-G) wildcard as per below, correct? I think we are in agreement here, but for clarity we need to distinguish between two different things: - The PIM receive states, which are always either (C-S,C-G) or (C-*,C-G). - The NLRI of the S-PMSI A-D route, which may contain (C-S,C-G), (C-*,C-G), (C-S,C-*), or (C-*,C-*). RFC6625 gives the rules for determining which S-PMSI A-D route matches which PIM receive state. Note, for example, that a PIM receive state of (C-S,C-G) or (C-*,C-G) might match an S-PMSI A-D route whose NLRI contains (C-*,C-*). Or a PIM receive state of (C-S,C-G) might match an S-PMSI A-D route whose NLRI contains (C-S,C-*). Any S-PMSI A-D route should be able to invoke explicit tracking of the receive states that match it. > > Since this is a general explicit tracking, I propose we merge the two > proposals, so everyone can look at this from general explicit tracking > procedures for any case. > > We probably should then bring this discussion to BLESS. Sounds like a good plan (assuming you mean BESS ;-)). > > Andrew > > > > On 2015-01-07, 10:44 AM, "Eric C Rosen" wrote: > >> Let me write down how I think explicit tracking should work, and you can >> tell me whether (a) it's at odds with what's in your draft, or (b) it >> duplicates what's in your draft, or (c) it extends what's in your draft >> in a useful way, or (d) it extends what's in your draft in a useless way >> ;-) >> >> (Perhaps this discussion really belongs on the BESS ML, but we might as >> well continue it here for a little while.) >> >> RFC6625 (and other RFCs or RFCs-to-be that update RFC6625) specify a >> set of rules for finding the S-PMSI A-D route that is the "match for >> reception" for a given (C-S,C-G) or (C-*,C-G) state. As >> draft-dolganow-l3vpn-mvpn-expl-track points out, the defintion of "match >> for reception" needs to be modified as follows: >> >> When finding the "match for reception" for a given (C-S,C-G) or >> (C-*,C-G), ignore any S-PMSI A-D route that has no PMSI Tunnel >> attribute (PTA), or that has a PTA specifying "no tunnel info". >> >> I'd like to propose now to introduce a new notion: the "match for >> tracking". This differs from the "match for reception" as follows: >> >> For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for tracking" >> is chosen as follows. Ignore any S-PMSI A-D route that has no PTA, >> or whose PTA does not have either LIR or LIR-pF set. (In particular, >> DO NOT ignore an S-PMSI A-D route that has a PTA specifying "no >> tunnel info", but whose LIR or LIR-pF bits are set). Then apply the >> rules (from RFC6625 and other RFCs or RFCs-to-be that update it) for >> finding the "match for reception". The result (if any) is the >> match for tracking". >> >> For example, suppose a given PE router, PE1, has chosen PE2 as the >> "upstream PE" for a given (C-S1,C-G1). And suppose PE1 has installed >> the following two routes that were originated by PE2: >> >> Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a tunnel. >> >> Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no tunnel >> info" and has LIR set. >> >> Route1 is (C-S1,C-G1)'s match for reception, and Route2 is (C-S1,C-G1)'s >> match for tracking. >> >> Note that if there is no installed S-PMSI A-D route for (C-S2,C-G2), >> then Route1 would be (C-S2,C-G2)'s match for reception and also its >> match for tracking. >> >> As another example, suppose PE1 has installed the following two routes >> that were originated by PE2: >> >> Route3: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the PTA >> specifies a tunnel) >> >> Route4: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a tunnel. >> >> Then Route 4 is both the "match for reception" and the "match for >> tracking" for (C-S1,C-G1). >> >> Note that for a particular C-flow, the PE1's match for reception might >> be the same route as its match for tracking, or its match for reception >> might be a "less specific" route than its match for tracking. But its >> match for reception can never be a "more specific" route than its match >> for tracking. >> >> Now we have a number of cases to look at: >> >> 1. PE1's match for tracking the is same as its match for reception, but >> neither LIR nor LIR-pF flags are on. In this case, there is no explicit >> tracking for the C-flow. The match for reception is processed >> according to existing procedures. >> >> 2. PE1's match for tracking is the same as its match for reception, LIR >> is set, LIR-pF is not set. In this case, existing procedures are >> followed. >> >> 3. PE1's match for tracking is the same as its match for reception, and >> LIR-pF is set. This case is discussed in a previous message. >> >> 4. PE1's match for tracking is not the same as its match for reception. >> This can only happen if the match for tracking has a PTA specifying "no >> tunnel info", with either LIR or LIR-pF set. In this case, PE1 must >> respond both to the match for tracking and to the match for reception. >> To respond to the match for tracking, PE1 originates one or more Leaf >> A-D routes; the PTA of each such route will specify "no tunnel info". >> Construction of the NLRI of the Leaf A-D route is as specified in >> RFC6514 (if LIR is set) or as specified in the referenced message on the >> BIER mailing list (if LIR-pF) is set. To respond to the match for >> reception, existing procedures are used. Note that if LIR or LIR-pF are >> set in the PTA of the match for reception, PE1 may need to originate a >> Leaf A-D route corresponding to the match for tracking as well as >> originating a Leaf A-D route corresponding to the match for reception. >> >> I think the above procedures work at an egress PE, but they are not >> quite right for an egress ABR/ASBR. An egress ABR/ASBR does forward >> along any S-PMSI A-D routes it gets. If the PTA of the received S-PMSI >> A-D route specifies a tunnel, the egress ABR/ASBR may change the PTA to >> specify a different tunnel type. However, we should require that if the >> PTA specifies "no tunnel info", it is passed along unchanged. >> >> Then we can establish the following rule for egress ABRs/ASBRs. Suppose >> an egress ABR/ASBR receives an S-PMSI A-D route whose NLRI is X, and >> whose PTA (a) specifies "no tunnel info" and (b) has LIR set. The >> egress ABR/ASBR should not immediately originate a Leaf A-D route in >> response. Rather it should wait until it receives a Leaf A-D route >> whose NLRI contains X in the "route key" field. If it receives such a >> Leaf A-D route, it redistributes that route, but first it changes that >> route's RT. The "global administrator" field of the modified RT will be >> set to the IP address taken either from the S-PMSI A-D route's next hop >> field, or from its Segmented P2MP Next Hop Extended Community. >> >> This will ensure that an egress ABR/ASBR only sends a Leaf A-D route in >> response to a "match for tracking" if it is on the path to an egress PE >> for the flow(s) identified in the corresponding S-PMSI A-D route. >> >> Comments? >> >> >> >> >> > From nobody Thu Jan 8 10:38:47 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41581A00A7 for ; Thu, 8 Jan 2015 10:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA9rpYJIxxny for ; Thu, 8 Jan 2015 10:38:43 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC0E1A00A2 for ; Thu, 8 Jan 2015 10:38:42 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 4F0075F6BAA78; Thu, 8 Jan 2015 18:38:37 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t08IcdTF025022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Jan 2015 13:38:39 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 13:38:39 -0500 From: "Dolganow, Andrew (Andrew)" To: Eric C Rosen Thread-Topic: [Bier] Explicit Tracking Thread-Index: AQHQKpWoTyqEtTqfV0yS0FQxecJB3py2twCA///Ydwg= Date: Thu, 8 Jan 2015 18:38:38 +0000 Message-ID: <43A92A17-D11B-4678-B161-356EC3C5BBC9@alcatel-lucent.com> References: <54AC0915.4000804@juniper.net> <54AD487B.5050302@juniper.net> <54AD546B.9040409@juniper.net> , <54AEA989.50803@juniper.net> In-Reply-To: <54AEA989.50803@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jeffrey \(Zhaohui\) Zhang" , BIER Subject: Re: [Bier] Explicit Tracking X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:38:45 -0000 Great thanks. Andrew Sent from my iPhone > On Jan 8, 2015, at 11:00 AM, Eric C Rosen wrote: >=20 >> On 1/7/2015 11:07 AM, Dolganow, Andrew (Andrew) wrote: >> Eric, >>=20 >> I think we converged. >=20 > Yes, I don't think we have any real disagreement. >=20 >> Please note that my draft allows any wildcard tracking, so I assume you >> not limiting tracking to only (C-*, C-G) wildcard as per below, correct? >=20 > I think we are in agreement here, but for clarity we need to distinguish = between two different things: >=20 > - The PIM receive states, which are always either (C-S,C-G) or (C-*,C-G). >=20 > - The NLRI of the S-PMSI A-D route, which may contain (C-S,C-G), (C-*,C-G= ), (C-S,C-*), or (C-*,C-*). >=20 > RFC6625 gives the rules for determining which S-PMSI A-D route matches wh= ich PIM receive state. Note, for example, that a PIM receive state of (C-S= ,C-G) or (C-*,C-G) might match an S-PMSI A-D route whose NLRI contains (C-*= ,C-*). Or a PIM receive state of (C-S,C-G) might match an S-PMSI A-D route= whose NLRI contains (C-S,C-*). >=20 > Any S-PMSI A-D route should be able to invoke explicit tracking of the re= ceive states that match it. >=20 >>=20 >> Since this is a general explicit tracking, I propose we merge the two >> proposals, so everyone can look at this from general explicit tracking >> procedures for any case. >>=20 >> We probably should then bring this discussion to BLESS. >=20 > Sounds like a good plan (assuming you mean BESS ;-)). >=20 >>=20 >> Andrew >>=20 >>=20 >>=20 >>> On 2015-01-07, 10:44 AM, "Eric C Rosen" wrote: >>>=20 >>> Let me write down how I think explicit tracking should work, and you ca= n >>> tell me whether (a) it's at odds with what's in your draft, or (b) it >>> duplicates what's in your draft, or (c) it extends what's in your draft >>> in a useful way, or (d) it extends what's in your draft in a useless wa= y >>> ;-) >>>=20 >>> (Perhaps this discussion really belongs on the BESS ML, but we might as >>> well continue it here for a little while.) >>>=20 >>> RFC6625 (and other RFCs or RFCs-to-be that update RFC6625) specify a >>> set of rules for finding the S-PMSI A-D route that is the "match for >>> reception" for a given (C-S,C-G) or (C-*,C-G) state. As >>> draft-dolganow-l3vpn-mvpn-expl-track points out, the defintion of "matc= h >>> for reception" needs to be modified as follows: >>>=20 >>> When finding the "match for reception" for a given (C-S,C-G) or >>> (C-*,C-G), ignore any S-PMSI A-D route that has no PMSI Tunnel >>> attribute (PTA), or that has a PTA specifying "no tunnel info". >>>=20 >>> I'd like to propose now to introduce a new notion: the "match for >>> tracking". This differs from the "match for reception" as follows: >>>=20 >>> For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for tracking" >>> is chosen as follows. Ignore any S-PMSI A-D route that has no PTA, >>> or whose PTA does not have either LIR or LIR-pF set. (In particular= , >>> DO NOT ignore an S-PMSI A-D route that has a PTA specifying "no >>> tunnel info", but whose LIR or LIR-pF bits are set). Then apply the >>> rules (from RFC6625 and other RFCs or RFCs-to-be that update it) for >>> finding the "match for reception". The result (if any) is the >>> match for tracking". >>>=20 >>> For example, suppose a given PE router, PE1, has chosen PE2 as the >>> "upstream PE" for a given (C-S1,C-G1). And suppose PE1 has installed >>> the following two routes that were originated by PE2: >>>=20 >>> Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a tunnel. >>>=20 >>> Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no tunnel >>> info" and has LIR set. >>>=20 >>> Route1 is (C-S1,C-G1)'s match for reception, and Route2 is (C-S1,C-G1)'= s >>> match for tracking. >>>=20 >>> Note that if there is no installed S-PMSI A-D route for (C-S2,C-G2), >>> then Route1 would be (C-S2,C-G2)'s match for reception and also its >>> match for tracking. >>>=20 >>> As another example, suppose PE1 has installed the following two routes >>> that were originated by PE2: >>>=20 >>> Route3: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the PTA >>> specifies a tunnel) >>>=20 >>> Route4: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a tunnel. >>>=20 >>> Then Route 4 is both the "match for reception" and the "match for >>> tracking" for (C-S1,C-G1). >>>=20 >>> Note that for a particular C-flow, the PE1's match for reception might >>> be the same route as its match for tracking, or its match for reception >>> might be a "less specific" route than its match for tracking. But its >>> match for reception can never be a "more specific" route than its match >>> for tracking. >>>=20 >>> Now we have a number of cases to look at: >>>=20 >>> 1. PE1's match for tracking the is same as its match for reception, but >>> neither LIR nor LIR-pF flags are on. In this case, there is no explici= t >>> tracking for the C-flow. The match for reception is processed >>> according to existing procedures. >>>=20 >>> 2. PE1's match for tracking is the same as its match for reception, LIR >>> is set, LIR-pF is not set. In this case, existing procedures are >>> followed. >>>=20 >>> 3. PE1's match for tracking is the same as its match for reception, and >>> LIR-pF is set. This case is discussed in a previous message. >>>=20 >>> 4. PE1's match for tracking is not the same as its match for reception. >>> This can only happen if the match for tracking has a PTA specifying "no >>> tunnel info", with either LIR or LIR-pF set. In this case, PE1 must >>> respond both to the match for tracking and to the match for reception. >>> To respond to the match for tracking, PE1 originates one or more Leaf >>> A-D routes; the PTA of each such route will specify "no tunnel info". >>> Construction of the NLRI of the Leaf A-D route is as specified in >>> RFC6514 (if LIR is set) or as specified in the referenced message on th= e >>> BIER mailing list (if LIR-pF) is set. To respond to the match for >>> reception, existing procedures are used. Note that if LIR or LIR-pF ar= e >>> set in the PTA of the match for reception, PE1 may need to originate a >>> Leaf A-D route corresponding to the match for tracking as well as >>> originating a Leaf A-D route corresponding to the match for reception. >>>=20 >>> I think the above procedures work at an egress PE, but they are not >>> quite right for an egress ABR/ASBR. An egress ABR/ASBR does forward >>> along any S-PMSI A-D routes it gets. If the PTA of the received S-PMSI >>> A-D route specifies a tunnel, the egress ABR/ASBR may change the PTA to >>> specify a different tunnel type. However, we should require that if th= e >>> PTA specifies "no tunnel info", it is passed along unchanged. >>>=20 >>> Then we can establish the following rule for egress ABRs/ASBRs. Suppos= e >>> an egress ABR/ASBR receives an S-PMSI A-D route whose NLRI is X, and >>> whose PTA (a) specifies "no tunnel info" and (b) has LIR set. The >>> egress ABR/ASBR should not immediately originate a Leaf A-D route in >>> response. Rather it should wait until it receives a Leaf A-D route >>> whose NLRI contains X in the "route key" field. If it receives such a >>> Leaf A-D route, it redistributes that route, but first it changes that >>> route's RT. The "global administrator" field of the modified RT will b= e >>> set to the IP address taken either from the S-PMSI A-D route's next hop >>> field, or from its Segmented P2MP Next Hop Extended Community. >>>=20 >>> This will ensure that an egress ABR/ASBR only sends a Leaf A-D route in >>> response to a "match for tracking" if it is on the path to an egress PE >>> for the flow(s) identified in the corresponding S-PMSI A-D route. >>>=20 >>> Comments? >>=20 From nobody Wed Jan 21 16:24:10 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0281A1AAC for ; Wed, 21 Jan 2015 16:24:08 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfFfBu60dQpl for ; Wed, 21 Jan 2015 16:24:04 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A061A1A88 for ; Wed, 21 Jan 2015 16:24:04 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id n3so35402316wiv.3 for ; Wed, 21 Jan 2015 16:24:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=FZcPr0dW8PfhoAWkR01Mg82H9Dz9/7AwqSNr/RTgG8Q=; b=tiCT12lgEs4ryYEi6fKoGFt0YW+jDbuMSY30B/BXPF6qTVVSXnRz0mPxNRGSUfG3jj wshvczOCq539+dDlqVZDnCTimKXKemk0JaIcTnb5zjCWQpgaqAefBWrBttK8HtPlgFTa tq/3RWddprNmdnnV5EEGqkuQLQmLm5b7BPQCPQZtOw/Zx13QxcynCtWdbzTCIsyyEwlg lxEdWG07hQ7eG3WqWJrPn5TqQyjZqRUaa3LQKnUMTa/m51VCsME49Qj4ui4yMjgJmPRh TUbVSMwsLRQG1UFjIHgB+U/L9kWZUbQaq0KGIFmq312ME3zvOmS+gQHNuCGAgJtZwhhE D7+Q== MIME-Version: 1.0 X-Received: by 10.180.87.42 with SMTP id u10mr34446390wiz.51.1421886242994; Wed, 21 Jan 2015 16:24:02 -0800 (PST) Received: by 10.180.207.180 with HTTP; Wed, 21 Jan 2015 16:24:02 -0800 (PST) Date: Wed, 21 Jan 2015 16:24:02 -0800 Message-ID: From: Greg Shepherd To: "bier@ietf.org" Content-Type: multipart/alternative; boundary=f46d044280f06cc257050d32b0f7 Archived-At: Subject: [Bier] Upcoming milestones X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 00:24:08 -0000 --f46d044280f06cc257050d32b0f7 Content-Type: text/plain; charset=UTF-8 This is taken from the notes in our interim call last year. I've included milestones which are still open. Other drafts are on track (thanks!) and have been omitted here. ---------- problem statement; Author - Greg - confirmed Andrew to contribute more. next-revision - Jan 31. Andrew, Ron, if you have proposed text please forward to me soon, thanks! uses-case draft: Editor; Ice - Interim. :Do we have an official owner of this draft? TonyP EVPN use case - Early Jan: Some has come in, thanks. Albert LISP - early Jan - :? Andrew - highlight BIER advantages. : Any text yet Andrew? Ron - deployments and migration : Ron? ospf; Author; peter next revision before Dallas Call for adoption Dallas LC 2015 isis; Author; tony next revision early Feb. Call for adoption Dallas LC 2015 Tony - adopt changes to [sub]domain in arch draft new draft for deployment and migration. Ice, Albert, Jeffery, Andrew, Greg not to pollute the arch draft. how to cope with multiple bit-mask sizes how to mitigate non-BIER supporting routers. GS - any work on this to share? compression drafts; Author - Albert. request for comments. Charter Discussion Authors - Greg, Eric, Andrew, Tony. Reviewers - Ross, Wim. first revision - end of Jan 2014. GS - end is near. I'll request a timeslot in Dallas whether it's an official WG or our second BoF. But we need to keep the ball moving either way. Thanks!, Greg --f46d044280f06cc257050d32b0f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is taken from=C2=A0the notes in our=C2=A0interim = call last year. I've included milestones which are still open. Other dr= afts are on track (thanks!) and have been omitted here.
=

----------

problem statement;
Author - Greg - confirmed=
= Andre= w to contribute more.
next-revision - Jan 31.
Andrew, Ron, if yo= u have proposed text please forward to me soon, thanks!


use= s-case draft:
Editor; Ice - Interim. :Do we have an official owner of this= draft?
TonyP EVPN use case - Early Jan: =C2=A0Some has come in, thanks.
Albert LISP - early Jan - :?
Andrew - highlight=C2=A0BI= ER=C2=A0advantages. : Any text yet Andrew?
Ron - deployments and migration= : Ron?

ospf;
Author; peter
next revision before Dallas
Call for adoption Dallas
LC 2015
isis;Author; tony
next re= vision early Feb.
Call for adoption Dallas
LC 2015
Tony - adopt changes to [sub]domain in arc= h draft

new draft for deployment and migra= tion.
= Ice, Albert, Jeffery, Andrew, Greg
not to pollute the arch draft.
how to cope with mult= iple bit-mask sizes
how to mitigate non-BIER=C2=A0support= ing routers.
GS - any work on this to share?=C2=A0

compression drafts;
Author - = Albert.
request for comments.

Charter Discussion
Authors - Greg, Eric, Andrew, Tony.
Reviewers - Ross, Wim= .
firs= t revision - end of Jan 2014.
GS - end is near. I'= ;ll request a timeslot in Dallas=C2=A0whether it's an=C2=A0official WG = or our second BoF. But we need to keep the ball moving either way.

Thanks!,
= Greg
--f46d044280f06cc257050d32b0f7-- From nobody Wed Jan 21 16:51:10 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28ED1A8AE9 for ; Wed, 21 Jan 2015 16:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF0TZtXRUpND for ; Wed, 21 Jan 2015 16:51:07 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9579E1A8AE8 for ; Wed, 21 Jan 2015 16:51:06 -0800 (PST) Received: from BY2PR05MB077.namprd05.prod.outlook.com (10.242.38.11) by BY2PR05MB616.namprd05.prod.outlook.com (10.141.218.155) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 00:51:05 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB077.namprd05.prod.outlook.com (10.242.38.11) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 00:51:03 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.238]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.238]) with mapi id 15.01.0059.007; Thu, 22 Jan 2015 00:51:03 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "gjshep@gmail.com" , "bier@ietf.org" Thread-Topic: [Bier] Upcoming milestones Thread-Index: AQHQNdnB8+RAos7na0+wEYnPnrOe4ZzLTvFQ Date: Thu, 22 Jan 2015 00:51:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:BY2PR05MB077; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB077; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(41574002)(101416001)(87936001)(33656002)(106116001)(74316001)(19300405004)(106356001)(19580405001)(2656002)(105586002)(19580395003)(76176999)(19625215002)(107886001)(68736005)(86362001)(2950100001)(99286002)(15975445007)(2900100001)(92566002)(122556002)(54356999)(50986999)(54606007)(66066001)(102836002)(97736003)(40100003)(64706001)(76576001)(2501002)(16236675004)(54206007)(77156002)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB077; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BY2PR05MB07917337CC8478662DAE9D8D4490BY2PR05MB079namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2015 00:51:03.0827 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB077 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB616; X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Bier] Upcoming milestones X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 00:51:08 -0000 --_000_BY2PR05MB07917337CC8478662DAE9D8D4490BY2PR05MB079namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWJvdXQgdGhlIGZvbGxvd2luZzoNCg0KDQrDmCAgbmV3IGRyYWZ0IGZvciBkZXBsb3ltZW50IGFu ZCBtaWdyYXRpb24uDQpJY2UsIEFsYmVydCwgSmVmZmVyeSwgQW5kcmV3LCBHcmVnDQpub3QgdG8g cG9sbHV0ZSB0aGUgYXJjaCBkcmFmdC4NCmhvdyB0byBjb3BlIHdpdGggbXVsdGlwbGUgYml0LW1h c2sgc2l6ZXMNCmhvdyB0byBtaXRpZ2F0ZSBub24tQklFUiBzdXBwb3J0aW5nIHJvdXRlcnMuDQoN CkVyaWMgcG9zdGVkIHNvbWUgdGhvdWdodHMgb24gdGhlIG1haWxpbmcgbGlzdCBhbmQgbG9va3Mg bGlrZSBpdOKAmXMgYmV0dGVyIHRvIGp1c3QgaW5jbHVkZSBpbiB0aGUgYXJjaCBkcmFmdC4NCg0K SmVmZnJleQ0KDQpGcm9tOiBCSUVSIFttYWlsdG86Ymllci1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgR3JlZyBTaGVwaGVyZA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIxLCAyMDE1 IDc6MjQgUE0NClRvOiBiaWVyQGlldGYub3JnDQpTdWJqZWN0OiBbQmllcl0gVXBjb21pbmcgbWls ZXN0b25lcw0KDQpUaGlzIGlzIHRha2VuIGZyb20gdGhlIG5vdGVzIGluIG91ciBpbnRlcmltIGNh bGwgbGFzdCB5ZWFyLiBJJ3ZlIGluY2x1ZGVkIG1pbGVzdG9uZXMgd2hpY2ggYXJlIHN0aWxsIG9w ZW4uIE90aGVyIGRyYWZ0cyBhcmUgb24gdHJhY2sgKHRoYW5rcyEpIGFuZCBoYXZlIGJlZW4gb21p dHRlZCBoZXJlLg0KDQotLS0tLS0tLS0tDQoNCnByb2JsZW0gc3RhdGVtZW50Ow0KQXV0aG9yIC0g R3JlZyAtIGNvbmZpcm1lZA0KQW5kcmV3IHRvIGNvbnRyaWJ1dGUgbW9yZS4NCm5leHQtcmV2aXNp b24gLSBKYW4gMzEuDQpBbmRyZXcsIFJvbiwgaWYgeW91IGhhdmUgcHJvcG9zZWQgdGV4dCBwbGVh c2UgZm9yd2FyZCB0byBtZSBzb29uLCB0aGFua3MhDQoNCnVzZXMtY2FzZSBkcmFmdDoNCkVkaXRv cjsgSWNlIC0gSW50ZXJpbS4gOkRvIHdlIGhhdmUgYW4gb2ZmaWNpYWwgb3duZXIgb2YgdGhpcyBk cmFmdD8NClRvbnlQIEVWUE4gdXNlIGNhc2UgLSBFYXJseSBKYW46ICBTb21lIGhhcyBjb21lIGlu LCB0aGFua3MuDQpBbGJlcnQgTElTUCAtIGVhcmx5IEphbiAtIDo/DQpBbmRyZXcgLSBoaWdobGln aHQgQklFUiBhZHZhbnRhZ2VzLiA6IEFueSB0ZXh0IHlldCBBbmRyZXc/DQpSb24gLSBkZXBsb3lt ZW50cyBhbmQgbWlncmF0aW9uIDogUm9uPw0Kb3NwZjsNCkF1dGhvcjsgcGV0ZXINCm5leHQgcmV2 aXNpb24gYmVmb3JlIERhbGxhcw0KQ2FsbCBmb3IgYWRvcHRpb24gRGFsbGFzDQpMQyAyMDE1DQoN CmlzaXM7DQpBdXRob3I7IHRvbnkNCm5leHQgcmV2aXNpb24gZWFybHkgRmViLg0KQ2FsbCBmb3Ig YWRvcHRpb24gRGFsbGFzDQpMQyAyMDE1DQpUb255IC0gYWRvcHQgY2hhbmdlcyB0byBbc3ViXWRv bWFpbiBpbiBhcmNoIGRyYWZ0DQoNCm5ldyBkcmFmdCBmb3IgZGVwbG95bWVudCBhbmQgbWlncmF0 aW9uLg0KSWNlLCBBbGJlcnQsIEplZmZlcnksIEFuZHJldywgR3JlZw0Kbm90IHRvIHBvbGx1dGUg dGhlIGFyY2ggZHJhZnQuDQpob3cgdG8gY29wZSB3aXRoIG11bHRpcGxlIGJpdC1tYXNrIHNpemVz DQpob3cgdG8gbWl0aWdhdGUgbm9uLUJJRVIgc3VwcG9ydGluZyByb3V0ZXJzLg0KR1MgLSBhbnkg d29yayBvbiB0aGlzIHRvIHNoYXJlPw0KDQpjb21wcmVzc2lvbiBkcmFmdHM7DQpBdXRob3IgLSBB bGJlcnQuDQpyZXF1ZXN0IGZvciBjb21tZW50cy4NCg0KQ2hhcnRlciBEaXNjdXNzaW9uDQpBdXRo b3JzIC0gR3JlZywgRXJpYywgQW5kcmV3LCBUb255Lg0KUmV2aWV3ZXJzIC0gUm9zcywgV2ltLg0K Zmlyc3QgcmV2aXNpb24gLSBlbmQgb2YgSmFuIDIwMTQuDQpHUyAtIGVuZCBpcyBuZWFyLiBJJ2xs IHJlcXVlc3QgYSB0aW1lc2xvdCBpbiBEYWxsYXMgd2hldGhlciBpdCdzIGFuIG9mZmljaWFsIFdH IG9yIG91ciBzZWNvbmQgQm9GLiBCdXQgd2UgbmVlZCB0byBrZWVwIHRoZSBiYWxsIG1vdmluZyBl aXRoZXIgd2F5Lg0KDQpUaGFua3MhLA0KR3JlZw0K --_000_BY2PR05MB07917337CC8478662DAE9D8D4490BY2PR05MB079namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAz IDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0K CXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAx O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDo5MjE3OTUwNDc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjUyMTI1Nzg4IC0xNzI3MTkxNDQgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OlNpbVN1bjsNCgltc28tYmlkaS1mb250LWZhbWlseTpIZWx2ZXRpY2E7 DQoJY29sb3I6YmxhY2s7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5BYm91dCB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPm5ldyBkcmFmdCBmb3IgZGVwbG95bWVudCBhbmQgbWlncmF0aW9uLjxicj4N CkljZSwgQWxiZXJ0LCBKZWZmZXJ5LCBBbmRyZXcsIEdyZWc8YnI+DQpub3QgdG8gcG9sbHV0ZSB0 aGUgYXJjaCBkcmFmdC48YnI+DQpob3cgdG8gY29wZSB3aXRoIG11bHRpcGxlIGJpdC1tYXNrIHNp emVzPGJyPg0KaG93IHRvIG1pdGlnYXRlIG5vbi1CSUVSJm5ic3A7c3VwcG9ydGluZyByb3V0ZXJz Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FcmljIHBvc3RlZCBzb21lIHRob3VnaHRzIG9uIHRo ZSBtYWlsaW5nIGxpc3QgYW5kIGxvb2tzIGxpa2UgaXTigJlzIGJldHRlciB0byBqdXN0IGluY2x1 ZGUgaW4gdGhlIGFyY2ggZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5KZWZmcmV5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g QklFUiBbbWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ R3JlZyBTaGVwaGVyZDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjEsIDIw MTUgNzoyNCBQTTxicj4NCjxiPlRvOjwvYj4gYmllckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBbQmllcl0gVXBjb21pbmcgbWlsZXN0b25lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+VGhpcyBpcyB0YWtlbiBmcm9tJm5ic3A7dGhlIG5vdGVzIGluIG91ciZuYnNwO2lu dGVyaW0gY2FsbCBsYXN0IHllYXIuIEkndmUgaW5jbHVkZWQgbWlsZXN0b25lcyB3aGljaCBhcmUg c3RpbGwgb3Blbi4gT3RoZXIgZHJhZnRzIGFyZSBvbiB0cmFjayAodGhhbmtzISkgYW5kIGhhdmUg YmVlbiBvbWl0dGVkDQogaGVyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPi0t LS0tLS0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnByb2JsZW0gc3RhdGVt ZW50Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkF1dGhvciAtIEdyZWcgLSBjb25m aXJtZWQ8YnI+DQpBbmRyZXcgdG8gY29udHJpYnV0ZSBtb3JlLjxicj4NCm5leHQtcmV2aXNpb24g LSBKYW4gMzEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbmRyZXcsIFJvbiwgaWYg eW91IGhhdmUgcHJvcG9zZWQgdGV4dCBwbGVhc2UgZm9yd2FyZCB0byBtZSBzb29uLCB0aGFua3Mh PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PnVzZXMtY2FzZSBkcmFmdDo8YnI+DQpFZGl0b3I7IEljZSAtIEludGVyaW0uIDo8L3NwYW4+RG8g d2UgaGF2ZSBhbiBvZmZpY2lhbCBvd25lciBvZiB0aGlzIGRyYWZ0PzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PlRvbnlQIEVWUE4gdXNlIGNhc2UgLSBFYXJseSBKYW46ICZuYnNwO1NvbWUgaGFzIGNvbWUgaW4s IHRoYW5rcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPkFsYmVydCBMSVNQIC0gZWFybHkgSmFuIC0gOj88YnI+DQpBbmRyZXcgLSBo aWdobGlnaHQmbmJzcDtCSUVSJm5ic3A7YWR2YW50YWdlcy4gOiBBbnkgdGV4dCB5ZXQgQW5kcmV3 Pzxicj4NClJvbiAtIGRlcGxveW1lbnRzIGFuZCBtaWdyYXRpb24gOiBSb24/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+b3NwZjs8YnI+DQpBdXRob3I7IHBldGVyPGJyPg0KbmV4dCBy ZXZpc2lvbiBiZWZvcmUgRGFsbGFzPGJyPg0KQ2FsbCBmb3IgYWRvcHRpb24gRGFsbGFzPGJyPg0K TEMgMjAxNTxicj4NCjxicj4NCmlzaXM7PGJyPg0KQXV0aG9yOyB0b255PGJyPg0KbmV4dCByZXZp c2lvbiBlYXJseSBGZWIuPGJyPg0KQ2FsbCBmb3IgYWRvcHRpb24gRGFsbGFzPGJyPg0KTEMgMjAx NTxicj4NClRvbnkgLSBhZG9wdCBjaGFuZ2VzIHRvIFtzdWJdZG9tYWluIGluIGFyY2ggZHJhZnQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPm5ldyBkcmFmdCBmb3IgZGVwbG95bWVu dCBhbmQgbWlncmF0aW9uLjxicj4NCkljZSwgQWxiZXJ0LCBKZWZmZXJ5LCBBbmRyZXcsIEdyZWc8 YnI+DQpub3QgdG8gcG9sbHV0ZSB0aGUgYXJjaCBkcmFmdC48YnI+DQpob3cgdG8gY29wZSB3aXRo IG11bHRpcGxlIGJpdC1tYXNrIHNpemVzPGJyPg0KaG93IHRvIG1pdGlnYXRlIG5vbi1CSUVSJm5i c3A7c3VwcG9ydGluZyByb3V0ZXJzLjxicj4NCjwvc3Bhbj5HUyAtIGFueSB3b3JrIG9uIHRoaXMg dG8gc2hhcmU/Jm5ic3A7PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Y29tcHJlc3Npb24gZHJhZnRzOzxicj4NCkF1dGhvciAtIEFsYmVydC48YnI+DQpyZXF1ZXN0IGZv ciBjb21tZW50cy48YnI+DQo8YnI+DQpDaGFydGVyIERpc2N1c3Npb248YnI+DQpBdXRob3JzIC0g R3JlZywgRXJpYywgQW5kcmV3LCBUb255Ljxicj4NClJldmlld2VycyAtIFJvc3MsIFdpbS48YnI+ DQpmaXJzdCByZXZpc2lvbiAtIGVuZCBvZiBKYW4gMjAxNC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5HUyAtIGVuZCBpcyBuZWFyLiBJJ2xsIHJlcXVlc3QgYSB0aW1lc2xvdCBpbiBE YWxsYXMmbmJzcDt3aGV0aGVyIGl0J3MgYW4mbmJzcDtvZmZpY2lhbCBXRyBvciBvdXIgc2Vjb25k IEJvRi4gQnV0IHdlIG5lZWQgdG8ga2VlcCB0aGUgYmFsbCBtb3ZpbmcgZWl0aGVyIHdheS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoYW5rcyEsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+R3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR05MB07917337CC8478662DAE9D8D4490BY2PR05MB079namprd_-- From nobody Thu Jan 22 12:19:53 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3268F1A87A1 for ; Thu, 22 Jan 2015 12:19:51 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4RVUxjg4v7C for ; Thu, 22 Jan 2015 12:19:48 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369041A8720 for ; Thu, 22 Jan 2015 12:19:48 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id a1so3821559wgh.12 for ; Thu, 22 Jan 2015 12:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MCBcl5Q0p5E8ShlL1Oz8w3jHGclW93nPHjNJToiLW6I=; b=IioL8hSfm1n0n7oMzyiUHc4XlefoGviMXn9kXxOnJn1YhC9QFSrwftQtJ4QUGcOKem bWhAiRGkttgTNw+39zYr28o9lXrCNvpeOYKTpML0OWlQjL6G0GRs/642y/vD7hpFd7oF /zsC7TzK0biRIvpxG0bbwYuEkasNE61UiPlC5EU6gQmVS0cH2TZ1LgraDUGVfbZgjAvw ivpgFxAL39Jec7ghMVoIWdEYYy1X89bGqYvGCH30RmsJrz36mfqJB2xjZN3bJ4J+yHc5 HR9Y60v6TaClA4vRwMw+S/UfbKp0DnlSuiGb9itvi7v6+MYLAixNVnnSel1+NFWwoThO 7dZQ== MIME-Version: 1.0 X-Received: by 10.180.75.111 with SMTP id b15mr1354088wiw.36.1421957986643; Thu, 22 Jan 2015 12:19:46 -0800 (PST) Received: by 10.180.207.180 with HTTP; Thu, 22 Jan 2015 12:19:46 -0800 (PST) In-Reply-To: References: Date: Thu, 22 Jan 2015 12:19:46 -0800 Message-ID: From: Greg Shepherd To: "Jeffrey (Zhaohui) Zhang" Content-Type: multipart/alternative; boundary=f46d043be216adf58b050d43647b Archived-At: Cc: "bier@ietf.org" Subject: Re: [Bier] Upcoming milestones X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 20:19:51 -0000 --f46d043be216adf58b050d43647b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sounds great, thanks! On Wed, Jan 21, 2015 at 4:51 PM, Jeffrey (Zhaohui) Zhang wrote: > About the following: > > > > =C3=98 new draft for deployment and migration. > Ice, Albert, Jeffery, Andrew, Greg > not to pollute the arch draft. > how to cope with multiple bit-mask sizes > how to mitigate non-BIER supporting routers. > > > > Eric posted some thoughts on the mailing list and looks like it=E2=80=99s= better > to just include in the arch draft. > > > > Jeffrey > > > > *From:* BIER [mailto:bier-bounces@ietf.org] *On Behalf Of *Greg Shepherd > *Sent:* Wednesday, January 21, 2015 7:24 PM > *To:* bier@ietf.org > *Subject:* [Bier] Upcoming milestones > > > > This is taken from the notes in our interim call last year. I've included > milestones which are still open. Other drafts are on track (thanks!) and > have been omitted here. > > > > ---------- > > > > problem statement; > > Author - Greg - confirmed > Andrew to contribute more. > next-revision - Jan 31. > > Andrew, Ron, if you have proposed text please forward to me soon, thanks! > > > > uses-case draft: > Editor; Ice - Interim. :Do we have an official owner of this draft? > > TonyP EVPN use case - Early Jan: Some has come in, thanks. > > Albert LISP - early Jan - :? > Andrew - highlight BIER advantages. : Any text yet Andrew? > Ron - deployments and migration : Ron? > > ospf; > Author; peter > next revision before Dallas > Call for adoption Dallas > LC 2015 > > isis; > Author; tony > next revision early Feb. > Call for adoption Dallas > LC 2015 > Tony - adopt changes to [sub]domain in arch draft > > > > new draft for deployment and migration. > Ice, Albert, Jeffery, Andrew, Greg > not to pollute the arch draft. > how to cope with multiple bit-mask sizes > how to mitigate non-BIER supporting routers. > GS - any work on this to share? > > compression drafts; > Author - Albert. > request for comments. > > Charter Discussion > Authors - Greg, Eric, Andrew, Tony. > Reviewers - Ross, Wim. > first revision - end of Jan 2014. > > GS - end is near. I'll request a timeslot in Dallas whether it's > an official WG or our second BoF. But we need to keep the ball moving > either way. > > > > Thanks!, > > Greg > --f46d043be216adf58b050d43647b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds great, thanks!

=
On Wed, Jan 21, 2015 at 4:51 PM, Jeffrey (Zhaohu= i) Zhang <zzhang@juniper.net> wrote:

About the following:

=C2=A0

=C3=98=C2=A0 new draft for deployment and migr= ation.
Ice, Albert, Jeffery, Andrew, Greg
not to pollute the arch draft.
how to cope with multiple bit-mask sizes
how to mitigate non-BIER=C2=A0supporting routers.

=C2=A0

Eric posted some thoughts on the mail= ing list and looks like it=E2=80=99s better to just include in the arch dra= ft.

=C2=A0

Jeffrey

=C2=A0

From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Greg Shepherd
Sent: Wednesday, January 21, 2015 7:24 PM
To: bier@ietf.org=
Subject: [Bier] Upcoming milestones

=C2=A0

This is taken from=C2=A0the notes in o= ur=C2=A0interim call last year. I've included milestones which are stil= l open. Other drafts are on track (thanks!) and have been omitted here.

=C2=A0

----------

=C2=A0

problem statement;

Author - Greg - confirmed
Andrew to contribute more.
next-revision - Jan 31.

Andrew, Ron, if you h= ave proposed text please forward to me soon, thanks!

=C2=A0

uses-case draft:
Editor; Ice - Interim. :Do we have an official owner of this draft?<= u>

TonyP EVPN use case - Early Jan: =C2= =A0Some has come in, thanks.

Albert = LISP - early Jan - :?
Andrew - highlight=C2=A0BIER=C2=A0advantages. : Any text yet Andrew?
Ron - deployments and migration : Ron?

ospf;
Author; peter
next revision before Dallas
Call for adoption Dallas
LC 2015

isis;
Author; tony
next revision early Feb.
Call for adoption Dallas
LC 2015
Tony - adopt changes to [sub]domain in arch draft

=C2=A0

new draft for deployment and migration= .
Ice, Albert, Jeffery, Andrew, Greg
not to pollute the arch draft.
how to cope with multiple bit-mask sizes
how to mitigate non-BIER=C2=A0supporting routers.
GS - any work on this to share?=C2=A0

compression drafts;
Author - Albert.
request for comments.

Charter Discussion
Authors - Greg, Eric, Andrew, Tony.
Reviewers - Ross, Wim.
first revision - end of Jan 2014.

GS - end is near. I'll request a t= imeslot in Dallas=C2=A0whether it's an=C2=A0official WG or our second B= oF. But we need to keep the ball moving either way.

=C2=A0

Thanks!,

Greg


--f46d043be216adf58b050d43647b-- From nobody Tue Jan 27 12:55:10 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB841A8AA2 for ; Tue, 27 Jan 2015 12:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aKsSL7ORTag for ; Tue, 27 Jan 2015 12:55:07 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C301A8A93 for ; Tue, 27 Jan 2015 12:55:06 -0800 (PST) Received: from CY1PR0501MB1097.namprd05.prod.outlook.com (25.160.144.139) by CY1PR0501MB1577.namprd05.prod.outlook.com (25.161.161.151) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 20:55:06 +0000 Received: from [172.29.33.34] (66.129.241.13) by CY1PR0501MB1097.namprd05.prod.outlook.com (25.160.144.139) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 20:55:04 +0000 Message-ID: <54C7FB1C.4060701@juniper.net> Date: Tue, 27 Jan 2015 15:54:52 -0500 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: BIER Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY2PR03CA070.namprd03.prod.outlook.com (10.141.249.43) To CY1PR0501MB1097.namprd05.prod.outlook.com (25.160.144.139) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CY1PR0501MB1097; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:CY1PR0501MB1097; X-Forefront-PRVS: 046985391D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(64126003)(83506001)(23676002)(80316001)(122386002)(87976001)(450100001)(62966003)(40100003)(86362001)(33656002)(50986999)(77156002)(54356999)(87266999)(42186005)(110136001)(229853001)(46102003)(47776003)(92566002)(65956001)(66066001)(65806001)(50466002)(77096005)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1097; H:[172.29.33.34]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1097; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2015 20:55:04.8557 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1097 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1577; X-OriginatorOrg: juniper.net Archived-At: Cc: erosen@juniper.net Subject: [Bier] architecture rev 3 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 20:55:08 -0000 I've just posted rev 3 of the architecture draft. In this rev, I've tried to clarify a number of issues having to do with the BitStringLength, and have added a section about choosing the BitStringLength, and what to do when there is a BitStringLength mismatch between a BFR and its next hop BFR. I don't know if I've correctly captured the consensus (or if there is a consensus to capture), but hopefully what we do or do not agree on will become clearer ;-) I have also added a section incorporating the "What if not all nodes support BIER" material outlined in my Jan 6 message to the mailing list. (Albert Tian, in his reply to my message, had an excellent suggestion for how to integrate that material seamlessly into the architecture. However, for the time being I thought it might be better to call attention to it explicitly by keeping it in a separate section.) From nobody Tue Jan 27 16:07:08 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061F81AC3D6 for ; Tue, 27 Jan 2015 16:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARKcdA67pAg7 for ; Tue, 27 Jan 2015 16:07:05 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CFE1AC3D5 for ; Tue, 27 Jan 2015 16:07:05 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 142so7676258ykq.4 for ; Tue, 27 Jan 2015 16:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RxkljDHtEbSNFo13KsKipocPOS2V4iavrhy2Pw4Osxo=; b=lz/Cpaim8eMSYf5vjmCwiT5ekuoEMstmajJDrtJDpDwbMUyGEbqoW8JyycdnxsVq5N Ztryel0jS8U6PpHDTTQ/eKdSrOrVvlyYPDaSqVGXulr8KiIEC40fA2Rei64kqpdJscA2 tYlMIOMiRggfrhc+uTge3Cry0Yo3sdXYBInCi/XRyf8P8VKjW/UVtSfDph5XVIohQO5Q 3Emel1yWZJbNrpVF7rDVrf6aA1ZTuWSZBA428jo0xFAsVbll8CT1b7dY9VPf0XTKSkWH qoq8AsUC+tOgxll9u2H0i+aM3kX7lFQ1bKKa1grCN0yvBf5mmICy4U9nHrbrggsiaq1k XVRQ== MIME-Version: 1.0 X-Received: by 10.236.14.135 with SMTP id d7mr117969yhd.3.1422403624932; Tue, 27 Jan 2015 16:07:04 -0800 (PST) Received: by 10.170.133.80 with HTTP; Tue, 27 Jan 2015 16:07:04 -0800 (PST) Date: Tue, 27 Jan 2015 19:07:04 -0500 Message-ID: From: Alia Atlas To: bier@ietf.org Content-Type: multipart/alternative; boundary=089e013a1a12ca9ae7050dab2649 Archived-At: Subject: [Bier] BOF deadline approaching X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 00:07:07 -0000 --089e013a1a12ca9ae7050dab2649 Content-Type: text/plain; charset=UTF-8 I am still waiting to see an updated problem-statement and use-cases. I would strongly encourage making a BoF request - working group forming; it isn't clear to me that there will be sufficient progress before Dallas to be certain of agreeing on a charter. Putting in a BoF request, assuming it is approved of course, makes sure that there is meeting time scheduled. The deadlne is Feb 6. Regards, Alia --089e013a1a12ca9ae7050dab2649 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am still waiting to see an updated problem-statement and= use-cases.
I would strongly encourage making a BoF request - working g= roup forming;
it isn't clear to me that there will be suffici= ent progress before Dallas to be
certain of agreeing on a charter= .

Putting in a BoF request, assuming it is approve= d of course, makes sure
that there is meeting time scheduled.

The deadlne is Feb 6.

Regard= s,
Alia
--089e013a1a12ca9ae7050dab2649-- From nobody Tue Jan 27 20:56:46 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AA71ACD2E for ; Tue, 27 Jan 2015 20:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1coVsYBxQTZ2 for ; Tue, 27 Jan 2015 20:56:42 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6677B1ACD2C for ; Tue, 27 Jan 2015 20:56:42 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-66-54c80cfbdb7f Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 25.5D.25146.BFC08C45; Tue, 27 Jan 2015 23:11:08 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 23:56:41 -0500 From: Antoni Przygienda To: Eric C Rosen , BIER Thread-Topic: [Bier] architecture rev 3 Thread-Index: AQHQOnONkSZu5H1OBEmErq8HOIriC5zU9B1A Date: Wed, 28 Jan 2015 04:56:40 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F18233BCE@eusaamb103.ericsson.se> References: <54C7FB1C.4060701@juniper.net> In-Reply-To: <54C7FB1C.4060701@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyuXRPiO4fnhMhBrfXMlksnbGHyWLdhg/M DkweS5b8ZPK43nSVPYApissmJTUnsyy1SN8ugSvj0sJHLAXdAhXz/+9ma2D8yNPFyMkhIWAi cbNjHhOELSZx4d56NhBbSOAIo8T6xVZdjFxA9nJGiW+L77CCJNgELCQuf3vKDGKLCFhLvGo/ B9YsLKAmcWHCaqAaDqC4usTTr/UQppHE3PV2IBUsAqoS337uYAGxeQW8JV5eOMAMsUpL4srC drApnALaEp33DrKD2IxA53w/tQYsziwgLnHryXyoMwUkluw5zwxhi0q8fPyPFcJWkpi09Bwr RL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYb GW5iBEbCMQk2xx2MCz5ZHmIU4GBU4uE1eHA8RIg1say4MvcQozQHi5I4b9mVgyFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGCsL9M9mLZH6H7p86ryUG53Cm2fVpqy7rtx+K8Mw7Vmk5d7P OgvO7VKs2GG3JqTp2tF7Z1/F3efuTQu07v7xi8FHvVq/Rqp3d/jWlmnXNz3r3pxYcJW/2KhU 4e+2Q7whvOFPvpQyLOM29/6X/I5V5pXGeknZbu3pQr9U3/gtrT9xeMch9XON65VYijMSDbWY i4oTAV3ILsFlAgAA Archived-At: Subject: Re: [Bier] architecture rev 3 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 04:56:44 -0000 read, agree with all.=20 1. I don't think that MUST'ing of a specific mapping on the node to a speci= fic bitstringlength is necessary (i.e. it is sufficient but not necessary).= A node can easily compute the bitstringlength that all support & it prefer= s or otherwise use 256 (this in case of IGP). =20 2. The draft is still non-committal whether encapsualtion translation (besi= de bitstring length for same encapsulation type) is supported by architectu= re. I think it should not, given that we imply then that every BFR MUST sup= port all encapsulations lest it cannot forward to the next neighbor.=20 3. The unicast tunneling is indeed clever and seems to hold up on first rea= d.=20 thanks =20 --- tony=20 > -----Original Message----- > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Eric C Rosen > Sent: Tuesday, January 27, 2015 12:55 PM > To: BIER > Cc: erosen@juniper.net > Subject: [Bier] architecture rev 3 >=20 > I've just posted rev 3 of the architecture draft. >=20 > In this rev, I've tried to clarify a number of issues having to do with t= he > BitStringLength, and have added a section about choosing the BitStringLen= gth, > and what to do when there is a BitStringLength mismatch between a BFR and= its > next hop BFR. >=20 > I don't know if I've correctly captured the consensus (or if there is a c= onsensus > to capture), but hopefully what we do or do not agree on will become clea= rer ;-) >=20 > I have also added a section incorporating the "What if not all nodes supp= ort > BIER" material outlined in my Jan 6 message to the mailing list. > (Albert Tian, in his reply to my message, had an excellent suggestion f= or how to > integrate that material seamlessly into the architecture. > However, for the time being I thought it might be better to call attentio= n to it > explicitly by keeping it in a separate section.) >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Fri Jan 30 05:45:28 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7050B1A0366 for ; Fri, 30 Jan 2015 05:45:25 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z69jUusVcgRn for ; Fri, 30 Jan 2015 05:45:23 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A471A0055 for ; Fri, 30 Jan 2015 05:45:22 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id u56so27257798wes.0 for ; Fri, 30 Jan 2015 05:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=FNXuMiWUUwZlmNonvAJmrBR46Zpl6Dmp+NZrIa1DL1o=; b=Wc2nRUR8poEY14nljzFeDJjBED9yXS/JlMzcZxTYa+92tGzCh08SK2n4sx0Ed9Si6B 6m34VAexf63pA7boNIZWlXCSmeQ9xUYm524E+jNxV5v4mfqf1hVE74AWhh0Czq/WnEs2 tkTA/a4ScNvNp8qi7UYctDquZ+LxgyS3VUONgoXM02qzrCH2YZr8XHJfxNfIB+/c7XcA EO8JO885SBj2J42ZX6JcOxCjAZplszOpqqiNP16b8nZCw5AHwKmcmERZFTVQhhWiDRyP cxw4o3GDv3C9QnXfHUgXjtxJRwh9kH63o+nIkh6Ywf9/AMyI3oHDC0h3ePMp8O0TWM2T HElg== MIME-Version: 1.0 X-Received: by 10.181.28.168 with SMTP id jp8mr5097156wid.40.1422625520707; Fri, 30 Jan 2015 05:45:20 -0800 (PST) Received: by 10.180.207.180 with HTTP; Fri, 30 Jan 2015 05:45:20 -0800 (PST) Date: Fri, 30 Jan 2015 05:45:20 -0800 Message-ID: From: Greg Shepherd To: "bier@ietf.org" Content-Type: multipart/alternative; boundary=001a1137fb78cf6d73050dded0ba Archived-At: Subject: [Bier] New Version Notification for draft-shepherd-bier-problem-statement-01.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 13:45:25 -0000 --001a1137fb78cf6d73050dded0ba Content-Type: text/plain; charset=UTF-8 BIER, Please read and review the updated problem statement draft. I believe I captured much of the input I received since the 00. The overall structure is the same, but I've expanded section 2 with a more complete list of problems related to the current set of multicast solutions. If you see something missing or that needs correcting please let me know. Thanks!, Greg ---------- Forwarded message ---------- A new version of I-D, draft-shepherd-bier-problem-statement-01.txt has been successfully submitted by Greg Shepherd and posted to the IETF repository. Name: draft-shepherd-bier-problem-statement Revision: 01 Title: Bit Indexed Explicit Replication (BIER) Problem Statement Document date: 2015-01-30 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-shepherd-bier-problem-statement-01.txt Status: https://datatracker.ietf.org/doc/draft-shepherd-bier-problem-statement/ Htmlized: http://tools.ietf.org/html/draft-shepherd-bier-problem-statement-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-shepherd-bier-problem-statement-01 Abstract: There is a need to simplify network operations for multicast services. Current solutions require a tree-building control plane to build and maintain end-to-end tree state per flow, impacting router state capacity and network convergence times. Multi-point tree building protocols are often considered complex to deploy and debug and may include mechanics from legacy use-cases and/or assumptions which no longer apply to the current use-cases. When multicast services are transiting a provider network through an overlay, the core network has a choice to either aggregate customer state into a minimum set of core states resulting in flooding traffic to unwanted network end-points, or to map per-customer, per-flow tree state directly into the provider core state amplifying the network-wide state problem. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a1137fb78cf6d73050dded0ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
BIER,

Please read and review the update= d problem statement draft. I believe I captured much of the input I receive= d since the 00. The overall structure is the same, but I've expanded se= ction 2 with a more complete list of problems related to the current set of= multicast solutions.

If you see something missing= or that needs correcting please let me know.

Than= ks!,
Greg

---------- For= warded message ----------
A new version of I-D, draft-shepherd-bier-prob= lem-statement-01.txt
has been successfully submitted by Greg Shepherd and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-shepherd-bier-problem-s= tatement
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bit Indexed Explicit Replication (= BIER) Problem Statement
Document date:=C2=A0 2015-01-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-shepherd-bier-problem-stat= ement-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/draft-shepherd-bier-problem-statement/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.iet= f.org/html/draft-shepherd-bier-problem-statement-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-shepherd-bier-problem-statement-= 01

Abstract:
=C2=A0 =C2=A0There is a need to simplify network operations for multicast =C2=A0 =C2=A0services.=C2=A0 Current solutions require a tree-building cont= rol plane to
=C2=A0 =C2=A0build and maintain end-to-end tree state per flow, impacting r= outer
=C2=A0 =C2=A0state capacity and network convergence times.=C2=A0 Multi-poin= t tree
=C2=A0 =C2=A0building protocols are often considered complex to deploy and = debug
=C2=A0 =C2=A0and may include mechanics from legacy use-cases and/or assumpt= ions
=C2=A0 =C2=A0which no longer apply to the current use-cases.=C2=A0 When mul= ticast
=C2=A0 =C2=A0services are transiting a provider network through an overlay,= the
=C2=A0 =C2=A0core network has a choice to either aggregate customer state i= nto a
=C2=A0 =C2=A0minimum set of core states resulting in flooding traffic to un= wanted
=C2=A0 =C2=A0network end-points, or to map per-customer, per-flow tree stat= e
=C2=A0 =C2=A0directly into the provider core state amplifying the network-w= ide
=C2=A0 =C2=A0state problem.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a1137fb78cf6d73050dded0ba-- From nobody Fri Jan 30 13:34:25 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5551A8788 for ; Fri, 30 Jan 2015 13:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Sm7OOPTPuf3 for ; Fri, 30 Jan 2015 13:34:22 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0121A1A59 for ; Fri, 30 Jan 2015 13:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2564; q=dns/txt; s=iport; t=1422653662; x=1423863262; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Bs6hByFw9iUJClQjb+p1mxx+jlmpOqk8L18Tr3IYa2c=; b=J4t3fbseI/lqj1+qg1HYfrM2V16BGWgLUzdVFOeoGgfuet/vjiizFFv5 qdN9OcZgklIZLghl8y2Z0WjODTeZUsNN93GDRi0B5LyufU6cddvgZj+Tk GP4pZ4N08ofjPB7oyX1r365bmmcfHPX2jTxkr39CV4LjM+YM1gFxqvfOB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DdBQBN+MtU/5BdJa1agwZSVAUEwkWCGwqFcQKBHkMBAQEBAX2EDQEBBAEBATc0HQEIEiQ3CxcEAQYDAgQTCYgjCAWxCKUhAQEBAQYBAQEBAQEcj3oFhCkFjwGDToVXgRc2gk2CQ4YDgjyDPSKDbm8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,493,1418083200"; d="scan'208";a="119179260" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP; 30 Jan 2015 21:34:21 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0ULYLVa022709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 30 Jan 2015 21:34:21 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.219]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 30 Jan 2015 15:34:21 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: "bier@ietf.org" Thread-Topic: I-D Action: draft-kumar-bier-use-cases-01.txt Thread-Index: AQHQPMz+jx3swazQFUqZLUzgeYCdipzZQCoA Date: Fri, 30 Jan 2015 21:34:20 +0000 Message-ID: In-Reply-To: <20150130204021.30418.24378.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.250.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <9813B2721D45354F89666903C53A3D1C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Bier] FW: I-D Action: draft-kumar-bier-use-cases-01.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 21:34:24 -0000 Hi, Below is the updated version of BIER use case draft. Please read and share your comments. Regards, Nagendra On 1/30/15, 3:40 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : BIER Use Cases > Authors : Nagendra Kumar > Rajiv Asati > Mach(Guoyi) Chen > Xiaohu Xu > Andrew Dolganow > Tony Przygienda > Arkadiy Gulko > Filename : draft-kumar-bier-use-cases-01.txt > Pages : 11 > Date : 2015-01-30 > >Abstract: > Bit Index Explicit Replication (BIER) is an architecture that > provides optimal multicast forwarding through a "BIER domain" without > requiring intermediate routers to maintain any multicast related per- > flow state. BIER also does not require any explicit tree-building > protocol for its operation. A multicast data packet enters a BIER > domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the > BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). > The BFIR router adds a BIER header to the packet. The BIER header > contains a bit-string in which each bit represents exactly one BFER > to forward the packet to. The set of BFERs to which the multicast > packet needs to be forwarded is expressed by setting the bits that > correspond to those routers in the BIER header. > > This document describes some of the use-cases for BIER. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-kumar-bier-use-cases/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-kumar-bier-use-cases-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-bier-use-cases-01 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Jan 30 23:31:01 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9741E1A8896 for ; Fri, 30 Jan 2015 23:31:00 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YToIpKZp7qia for ; Fri, 30 Jan 2015 23:30:59 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98A61A8894 for ; Fri, 30 Jan 2015 23:30:58 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id a1so30490900wgh.0 for ; Fri, 30 Jan 2015 23:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0f8rtSAc/vhsu59bYyoQs2ISORdM/tB3vvcDbe7zxK0=; b=PWwkhDQ8kxfNAsIs+/OPtKBP1WaU6YstpBSuysZ9EINZbGVXp7Jv0beD0n9v8P381b apyA4Cj+slH5Blbptip5xpRN8jLjJuM8PpMQVmZ7cF1QjHdDw60rM4BMicsfK17jY+Sw GPKyiBNr9WLz2iqBWkaYhOnvGmiv6k3YWmN4UrUxfaVZEk1cyCuaYqPj7oIvFcPhd6gp xgcuMLsf9J2xU8rvcWxNilwQCM9NKpistJNk2uza3MUcB14NKk9Sg0eC6Fl3qf/G0r/w hEdTjN9l/Z714xl2kUy4woD9jqUumOQoGVDIqZfjxg5PPfzMCekxeSYgqXp5xVK2xoQ2 rkhQ== MIME-Version: 1.0 X-Received: by 10.180.90.177 with SMTP id bx17mr2245094wib.36.1422689457542; Fri, 30 Jan 2015 23:30:57 -0800 (PST) Received: by 10.180.207.180 with HTTP; Fri, 30 Jan 2015 23:30:57 -0800 (PST) In-Reply-To: References: Date: Fri, 30 Jan 2015 23:30:57 -0800 Message-ID: From: Greg Shepherd To: Alia Atlas Content-Type: multipart/alternative; boundary=f46d043c7dd2be19d9050dedb3d3 Archived-At: Cc: "bier@ietf.org" Subject: Re: [Bier] BOF deadline approaching X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 07:31:00 -0000 --f46d043c7dd2be19d9050dedb3d3 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 27, 2015 at 4:07 PM, Alia Atlas wrote: > I am still waiting to see an updated problem-statement and use-cases. > Posted > I would strongly encourage making a BoF request - working group forming; > I made a request for a slot last week. My view in the tools has BIER as an option - possibly a placeholder for a pending WG formation, I'm not sure. Can you confirm that this request is sufficient to allocate a slot for BIER, BoF or WG, or if I need to also make a request for a BIER BoF? Thanks, Greg > it isn't clear to me that there will be sufficient progress before Dallas > to be > certain of agreeing on a charter. > > Putting in a BoF request, assuming it is approved of course, makes sure > that there is meeting time scheduled. > > The deadlne is Feb 6. > > Regards, > Alia > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > --f46d043c7dd2be19d9050dedb3d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 27, 2015 at 4:07 PM, Alia Atlas <akatlas@gmai= l.com> wrote:
I am still waitin= g to see an updated problem-statement and use-cases.

Posted
=C2=A0
I would strongly encourage making a BoF request - wo= rking group forming;

I made a r= equest for a slot last week. My view in the tools has BIER as an option - p= ossibly a placeholder for a pending WG formation, I'm not sure. Can you= confirm that this request is sufficient to allocate a slot for BIER, BoF o= r WG, or if I need to also make a request for a BIER BoF?

Thanks,
Greg
=C2=A0
it isn't clear to me that there will be = sufficient progress before Dallas to be
certain of agreeing on a = charter.
=C2=A0
Putting in a BoF request, assuming it is approv= ed of course, makes sure
that there is meeting time scheduled.

The deadlne is Feb 6.

Regar= ds,
Alia

_______________________________________________
BIER mailing list
BIER@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/bier


--f46d043c7dd2be19d9050dedb3d3-- From nobody Sat Jan 31 12:02:05 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F811A1AEC for ; Sat, 31 Jan 2015 12:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xukljRy5f8lC for ; Sat, 31 Jan 2015 12:02:01 -0800 (PST) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95CC1A1A17 for ; Sat, 31 Jan 2015 12:02:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id B394826F78 for ; Sat, 31 Jan 2015 12:02:00 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-12.clppva.east.verizon.net [70.106.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 3507826F77 for ; Sat, 31 Jan 2015 12:02:00 -0800 (PST) Message-ID: <54CD34A5.1090706@joelhalpern.com> Date: Sat, 31 Jan 2015 15:01:41 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "bier@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Bier] planning X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 20:02:02 -0000 I have read the latest versions of the BIER problem statement and BEIR use case drafts. I am still looking for a document that discusses (and preferably answers, but at least discusses) the cost of introducing a new data plane to address the problems, and the net benefit from doing so. I expect that the introduction of BIER can be justified. But I can not find where this is discussed. Yours, Joel From nobody Sat Jan 31 12:34:46 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A181A1A82 for ; Sat, 31 Jan 2015 12:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KMSb4ZP_2_d for ; Sat, 31 Jan 2015 12:34:43 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8E01A1A66 for ; Sat, 31 Jan 2015 12:34:42 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id bj1so65961428pad.1 for ; Sat, 31 Jan 2015 12:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=B+WQxaTLiVCBlyXMJ3iF6A27Ug3SUJubJcifW/SmXAw=; b=jvHyZTEv9SBEidLtlhzRmxPj9na1HCTuV2X4NzBBwG2Vm1QNR0NbpATRUxxE340ab6 5+ZFMd2nNEZ3o2/RBihyu3bxiP27k0CrFM8zb9lY5vLzyinr2abRmgcg5N//BsO1FGjI Bv2VrSGMDgWzKJouhuHwpyxdgg26EFsLWGBTOvW7U6CWazGfrmQWVUZwR+peORDmwMJm AsbdQ3tClyMCKqxlpi2aCoKU3xJ80Wmi5TSR73m6yqquWZavKcJrJqs94ibVbRRbwmEs htJ+QoynScpE8FX+y0xbvDWmoj1p7piME0WmJ54qjbcXYISvgFaLNgd0/3lqHwgOqEZF FLRw== X-Received: by 10.70.32.195 with SMTP id l3mr17948912pdi.41.1422736482254; Sat, 31 Jan 2015 12:34:42 -0800 (PST) Received: from [10.121.199.39] ([166.170.36.116]) by mx.google.com with ESMTPSA id h6sm14489020pdp.15.2015.01.31.12.34.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Jan 2015 12:34:41 -0800 (PST) References: <54CD34A5.1090706@joelhalpern.com> Mime-Version: 1.0 (1.0) In-Reply-To: <54CD34A5.1090706@joelhalpern.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4C60E3F0-01E9-45F5-8318-ED71AD459BCC@gmail.com> X-Mailer: iPhone Mail (11D167) From: Greg Shepherd Date: Sat, 31 Jan 2015 12:34:39 -0800 To: "Joel M. Halpern" Archived-At: Cc: "bier@ietf.org" Subject: Re: [Bier] planning X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 20:34:45 -0000 A cost analysis of any solution must include a description of the solution. T= his certainly does not belong in a problem statement draft. Sent from my iPhone > On Jan 31, 2015, at 12:01, "Joel M. Halpern" wrote: >=20 > I have read the latest versions of the BIER problem statement and BEIR use= case drafts. >=20 > I am still looking for a document that discusses (and preferably answers, b= ut at least discusses) the cost of introducing a new data plane to address t= he problems, and the net benefit from doing so. > I expect that the introduction of BIER can be justified. But I can not fi= nd where this is discussed. >=20 > Yours, > Joel >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Sat Jan 31 13:10:22 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA381A1EF6 for ; Sat, 31 Jan 2015 13:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eatyJ15ao0d7 for ; Sat, 31 Jan 2015 13:10:19 -0800 (PST) Received: from mxb1.tigertech.net (mxb1.tigertech.net [208.80.4.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4A21A0381 for ; Sat, 31 Jan 2015 13:10:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 5BB67D402B9; Sat, 31 Jan 2015 13:10:19 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-12.clppva.east.verizon.net [70.106.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id A7FC3D401CD; Sat, 31 Jan 2015 13:10:18 -0800 (PST) Message-ID: <54CD44A7.4060201@joelhalpern.com> Date: Sat, 31 Jan 2015 16:09:59 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Greg Shepherd References: <54CD34A5.1090706@joelhalpern.com> <4C60E3F0-01E9-45F5-8318-ED71AD459BCC@gmail.com> In-Reply-To: <4C60E3F0-01E9-45F5-8318-ED71AD459BCC@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "bier@ietf.org" Subject: Re: [Bier] planning X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 21:10:20 -0000 I do not know what draft it belongs in. I named those two drafts because they, plus the architectural draft (which also seems the wrong place) are the ones I have available to understand the question. While the details of the solution are still subject to debate, there is as far as I can tell general agreement on the shape of the solution we want to work on. Which is, I think, a good thing. From my experience, without some discussion of how the costs relate to the benefits, the IESG is likely to have significant difficulty chartering work with a known high deployment cost. Maybe we can get this chartered anyway? Yours, Joel On 1/31/15 3:34 PM, Greg Shepherd wrote: > A cost analysis of any solution must include a description of the solution. This certainly does not belong in a problem statement draft. > > Sent from my iPhone > >> On Jan 31, 2015, at 12:01, "Joel M. Halpern" wrote: >> >> I have read the latest versions of the BIER problem statement and BEIR use case drafts. >> >> I am still looking for a document that discusses (and preferably answers, but at least discusses) the cost of introducing a new data plane to address the problems, and the net benefit from doing so. >> I expect that the introduction of BIER can be justified. But I can not find where this is discussed. >> >> Yours, >> Joel >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > From d2@d2consulting.co.uk Sat Jan 31 17:24:12 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D881A7011 for ; Sat, 31 Jan 2015 17:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdiE8LuEzv53 for ; Sat, 31 Jan 2015 17:24:08 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E561A7009 for ; Sat, 31 Jan 2015 17:24:08 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id rd3so67368011pab.3 for ; Sat, 31 Jan 2015 17:24:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=kYpc91Nirohw5a0AwwyixysTEip2G9bNFsfkykmUmn8=; b=mcPOv64JcUnrR7qBdk6s3mCQ9BpG1Uu4Q7r2rZVLZV9InPRP3U+SXzvqGpJ9IbHRAF AESIJh95zCiM5WpI/B4e7PypLO+QkvYMbL3LgzlhpRffhKb5TlBcUKlkBMpxz8q+AFgb U/Tx8idQvg/qNQzn4vJ4I+PI7JcbQhF3olnwtmObzwzMsMm+1bSCeRF5iJC4YdAwVsqp IisQnaAily7kV0JAjd7ZvZ7vrxiypT4FuAhsj8bIuwwuQKPTmySvTVJikdv8twYsIkzu qZ6qizYrzQCfEieOBIGrg6MTuGymF3Wi0/cXzk34/0sSqyPqP6bOI5VuYz+dAQlOmLeR EqzA== X-Gm-Message-State: ALoCoQlj+2KJ7oYzZaWvNhrItJlLID36Cu+23Tt87x51YzVrHRT8xhnPcApU5nT12oBxmQei65o2 X-Received: by 10.68.203.226 with SMTP id kt2mr18818174pbc.141.1422753848207; Sat, 31 Jan 2015 17:24:08 -0800 (PST) MIME-Version: 1.0 Sender: d2@d2consulting.co.uk Received: by 10.70.61.198 with HTTP; Sat, 31 Jan 2015 17:23:48 -0800 (PST) In-Reply-To: References: <20150130204021.30418.24378.idtracker@ietfa.amsl.com> From: "Robinson, Dom" Date: Sun, 1 Feb 2015 01:23:48 +0000 X-Google-Sender-Auth: d8rt6O6UIKfEgjBHb4NLO5nkBdA Message-ID: To: "Nagendra Kumar Nainar (naikumar)" Content-Type: multipart/alternative; boundary=047d7b15ab37b9c38b050dfcb18f Archived-At: Cc: "bier@ietf.org" Subject: Re: [Bier] FW: I-D Action: draft-kumar-bier-use-cases-01.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 01:25:40 -0000 --047d7b15ab37b9c38b050dfcb18f Content-Type: text/plain; charset=UTF-8 Hi guys - i wonder if it would be worth extending the IPTV section to embrace content pre-placement in not only IPTV, but OTT and even big-software update and other such CDN activity: I stay close to IP Multicast specifically for this use case, and I always think it is interesting that while live/linear is an obvious Multicast candidate, pre-placing content in many caches that is known to be 'about to be heavily requested' is actually an extremely valuable capability - even if it is not live.... Just a thought. While i am a n00b to the formality of an IETF draft, if you like i would be happy to try to extend that IPTV paragraph to try to explain that 'CDN' focussed use case...? Let me know - ill try to contribute before the start of next week.... Kind regards Dom On 30 January 2015 at 21:34, Nagendra Kumar Nainar (naikumar) < naikumar@cisco.com> wrote: > Hi, > > Below is the updated version of BIER use case draft. > > Please read and share your comments. > > Regards, > Nagendra > > > > On 1/30/15, 3:40 PM, "internet-drafts@ietf.org" > wrote: > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : BIER Use Cases > > Authors : Nagendra Kumar > > Rajiv Asati > > Mach(Guoyi) Chen > > Xiaohu Xu > > Andrew Dolganow > > Tony Przygienda > > Arkadiy Gulko > > Filename : draft-kumar-bier-use-cases-01.txt > > Pages : 11 > > Date : 2015-01-30 > > > >Abstract: > > Bit Index Explicit Replication (BIER) is an architecture that > > provides optimal multicast forwarding through a "BIER domain" without > > requiring intermediate routers to maintain any multicast related per- > > flow state. BIER also does not require any explicit tree-building > > protocol for its operation. A multicast data packet enters a BIER > > domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the > > BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). > > The BFIR router adds a BIER header to the packet. The BIER header > > contains a bit-string in which each bit represents exactly one BFER > > to forward the packet to. The set of BFERs to which the multicast > > packet needs to be forwarded is expressed by setting the bits that > > correspond to those routers in the BIER header. > > > > This document describes some of the use-cases for BIER. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-kumar-bier-use-cases/ > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-kumar-bier-use-cases-01 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=draft-kumar-bier-use-cases-01 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > -- Dom Robinson Co-Founder, Director and Creative Firestarter @ id3as-company ltd Innovation, Development, Architecture, Strategy for IT, Cloud and StreamingMedia Projects uk.linkedin.com/in/domrobinson Also Contributing Editor for www.StreamingMedia.com http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm --047d7b15ab37b9c38b050dfcb18f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi guys - i wonder if it would be worth extending the IPTV= section to embrace content pre-placement in not only IPTV, but OTT and eve= n big-software update and other such CDN activity: I stay close to IP Multi= cast specifically for this use case, and I always think it is interesting t= hat while live/linear is an obvious Multicast candidate, pre-placing conten= t in many caches that is known to be 'about to be heavily requested'= ; is actually an extremely valuable capability - even if it is not live....=

Just a thought.

While i am a n= 00b to the formality of an IETF draft, if you like i would be happy to try = to extend that IPTV paragraph to try to explain that 'CDN' focussed= use case...?

Let me know - ill try to contribute = before the start of next week....

Kind regards=C2= =A0

Dom

=
On 30 January 2015 at 21:34, Nagendra Kumar Nain= ar (naikumar) <naikumar@cisco.com> wrote:
Hi,

Below is the updated version of BIER use case draft.

Please read and share your comments.

Regards,
Nagendra



On 1/30/15, 3:40 PM, "inte= rnet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: BIER Use Cases
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Nagendra Kumar
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Rajiv Asati
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Mach(Guoyi) Chen
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Xiaohu Xu
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Andrew Dolganow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Tony Przygienda
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Arkadiy Gulko
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= kumar-bier-use-cases-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-01-30
>
>Abstract:
>=C2=A0 =C2=A0Bit Index Explicit Replication (BIER) is an architecture t= hat
>=C2=A0 =C2=A0provides optimal multicast forwarding through a "BIER= domain" without
>=C2=A0 =C2=A0requiring intermediate routers to maintain any multicast r= elated per-
>=C2=A0 =C2=A0flow state.=C2=A0 BIER also does not require any explicit = tree-building
>=C2=A0 =C2=A0protocol for its operation.=C2=A0 A multicast data packet = enters a BIER
>=C2=A0 =C2=A0domain at a "Bit-Forwarding Ingress Router" (BFI= R), and leaves the
>=C2=A0 =C2=A0BIER domain at one or more "Bit-Forwarding Egress Rou= ters" (BFERs).
>=C2=A0 =C2=A0The BFIR router adds a BIER header to the packet.=C2=A0 Th= e BIER header
>=C2=A0 =C2=A0contains a bit-string in which each bit represents exactly= one BFER
>=C2=A0 =C2=A0to forward the packet to.=C2=A0 The set of BFERs to which = the multicast
>=C2=A0 =C2=A0packet needs to be forwarded is expressed by setting the b= its that
>=C2=A0 =C2=A0correspond to those routers in the BIER header.
>
>=C2=A0 =C2=A0This document describes some of the use-cases for BIER. >
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-kumar-bier-use-c= ases/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-kumar-bier-use-cases-01
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-bier= -use-cases-01
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp:/= /ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>I-D-Announce mailing list
>I-D-Announce@ietf.org
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
BIER mailing list
BIER@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/bier



--
Dom Robinson
Co-Founder,= Director and Creative Firestarter @ id3as-company ltd
Innovation= , Development, Architecture, Strategy
for IT, Cloud and Streaming= Media Projects

Also Contributing Editor for=C2=A0www.StreamingMedia.com
--047d7b15ab37b9c38b050dfcb18f--