From nobody Thu Sep 18 16:25:57 2014 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 205171A6F33 for ; Thu, 18 Sep 2014 16:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 bCSWPG_DrjmD for ; Thu, 18 Sep 2014 16:25:51 -0700 (PDT) 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 4B7211A0110 for ; Thu, 18 Sep 2014 16:25:51 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-d8-541b11a2f0ff Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AF.B5.25146.2A11B145; Thu, 18 Sep 2014 19:08:51 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Thu, 18 Sep 2014 19:25:43 -0400 From: Antoni Przygienda To: "bier@ietf.org" Thread-Topic: Kewl Thread-Index: Ac/Tl5qBj8mdr4glTYqeaI6eTGHGhg== Date: Thu, 18 Sep 2014 23:25:42 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F18198137@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F18198137eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXSPn+5iQekQg4OPBS2WztjD5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO7mMywFs9UrZrTNY2tgbFHuYuTkkBAwkVjVf5MZwhaTuHBv PRuILSRwlFGicXZqFyMXkL2cUeLs6sVMIAk2AQuJy9+egjWICChLnD/UyA5iCwvwSrRPa2GB iAtJTJ5/hRHC1pM4v+QYWD2LgKrEmyfHwebwCnhLzFi7A8xmBFr8/dQaMJtZQFzi1pP5TBAH CUgs2XMe6jhRiZeP/7FC2IoS+/qns0PU50vsu7gcaqagxMmZT1gmMArNQjJqFpKyWUjKIOI6 Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypGjtLi1LLcdCPDTYzAwD8mwea4g3HBJ8tDjAIc jEo8vApnJEOEWBPLiitzDzFKc7AoifNqVs8LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBY MEO2/FNERu6U2ZvCP8nO6PyUNet8c2vcef9lVbNmiexQ3TX/z16v8LAm3VfdhalrHlalHGVT 42xNl4mLnLpG6D+DZca8/kZro2uT/10QnF/D+TTbfPUm3Zdns+XmZto2btzz/U6On+ClyV/m RcyXPjjv2MFlCmumPYpx92yf+CK4Q7tNzGGdEktxRqKhFnNRcSIAL3W5rl0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/bier/pJBEhh8iQHISurfXmLWyt9j-76M Subject: [Bier] Kewl 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, 18 Sep 2014 23:25:54 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F18198137eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Little subversive list up already. Kewl (as beer should be). This can be easily misread as the proletarian version of the whiskey work-g= roup though ;-) I think BIER charter will specifically have to state that = "charter encompasses beverages up and to but not more than 12% ABV consumed= responsibly during meetings" ;-) --- tony I have been through some terrible things in my life, some of which actually= happened. --- Mark Twain --_000_2E4BB27CAB87BF43B4207C0E55860F18198137eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Little subversive list up already. Kewl (as beer should be).

 

This can be easily misread as the proletarian version of the= whiskey work-group though ;-)  I think BIER charter will specifically= have to state that “charter encompasses beverages up and to but not more than 12% ABV consumed responsibly during meetings&#= 8221;  ;-)

 

--- tony

 

 

I have been through some terrible things in my life, some of which actually = happened.

--- Mark Twain

 

--_000_2E4BB27CAB87BF43B4207C0E55860F18198137eusaamb103ericsso_-- From nobody Thu Sep 18 22:26:37 2014 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 6DEE91A700D for ; Thu, 18 Sep 2014 22:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 wkRGhgJQ9ktx for ; Thu, 18 Sep 2014 22:26:33 -0700 (PDT) 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 82C771A6F64 for ; Thu, 18 Sep 2014 22:26:33 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k14so1862406wgh.12 for ; Thu, 18 Sep 2014 22:26:32 -0700 (PDT) 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=WasAh/li2tqBBcHbKVdWB64WdKHNDdpQBCSv7sqY4NY=; b=hVuMQya0HtPOKmFWeXy0Dl5FtEUJlsPGwVaK63uUYtuEOo2y8ffucKYzk+N0Biy5Yx zx5zFbMqYTknGNNoSvJZQeW3I7dUlsTYoyKzt8YUkM5hq+8qYOAL12x9j4vp1dvvZtio tOjrAonFTL7gu2dvTCS6jDVkkQfvtvlPNBZDh3krQaEhTet2R7F+hO4Xx25jeIPS5LBC MWSUovb74A+HoghjQQ6w/za1AyO23VThihoDJ9q+Acie9QLxFiWYcNxt/pOJFcgC9Y7l q6TiS0+LvH4+FnMGwo2UEB5+ZWyRvQpiMGnF3V3Ph9UYSohiF4BClR6mVt0uATX6J41B 4Qew== MIME-Version: 1.0 X-Received: by 10.194.108.41 with SMTP id hh9mr9739420wjb.68.1411104392078; Thu, 18 Sep 2014 22:26:32 -0700 (PDT) Received: by 10.180.93.201 with HTTP; Thu, 18 Sep 2014 22:26:31 -0700 (PDT) Date: Thu, 18 Sep 2014 22:26:31 -0700 Message-ID: From: Greg Shepherd To: bier@ietf.org Content-Type: multipart/alternative; boundary=047d7bf10ac007ebdd0503645895 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/mv330mPsi-X2SVj9v6x8z_lfDk4 Subject: [Bier] WELCOME! 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, 19 Sep 2014 05:26:35 -0000 --047d7bf10ac007ebdd0503645895 Content-Type: text/plain; charset=UTF-8 Description There is a need to simplify network operations for multicast services. Current solutions require a tree-building control plane, which maintains 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 include mechanics from legacy use-cases and/or assumptions which may no longer apply to the current deployments. 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. This BOF intends to discuss a new architecture for the forwarding of multicast data packets. The goal is to provide optimal forwarding of multicast packets through a "multicast domain" without requiring an explicit tree-building protocol, nor requiring intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit-string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification. First IDs will be published over the next few days. Cheers, Greg --047d7bf10ac007ebdd0503645895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Description=
There is a need to simplify network operations for multic= ast services. Current solutions require a tree-building control plane, whic= h maintains end-to-end tree state per flow, impacting router state capacity= and network convergence times. Multi-point tree building protocols are oft= en considered complex to deploy and debug and include mechanics from legacy= use-cases and/or assumptions which may no longer apply to the current depl= oyments. When multicast services are transiting a provider network through = an overlay, the core network has a choice to either aggregate customer stat= e into a minimum set of core states resulting in flooding traffic to unwant= ed network end-points, or to map per-customer, per-flow tree state directly= into the provider core state amplifying the network-wide state problem.

This BOF intends to discuss a new ar= chitecture for the forwarding of multicast data packets.=C2=A0 The goal is = to provide optimal forwarding of multicast packets through a "multicas= t domain" without requiring an explicit tree-building protocol, nor re= quiring intermediate nodes to maintain any per-flow state.=C2=A0 This archi= tecture is known as "Bit Index Explicit Replication" (BIER).=C2= =A0 When a multicast data packet enters the domain, the ingress router dete= rmines the set of egress routers to which the packet needs to be sent.=C2= =A0 The ingress router then encapsulates the packet in a BIER header.=C2=A0= The BIER header contains a bit-string in which each bit represents exactly= one egress router in the domain; to forward the packet to a given set of e= gress routers, the bits corresponding to those routers are set in the BIER = header. Elimination of the per-flow state and the explicit tree-building pr= otocols results in a considerable simplification.

= First IDs will be published over the next few days.=C2=A0

<= /div>
Cheers,
Greg
--047d7bf10ac007ebdd0503645895-- From nobody Fri Sep 19 10:50:16 2014 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 EB16D1A0342; Fri, 19 Sep 2014 10:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.906 X-Spam-Level: X-Spam-Status: No, score=-0.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FS_REPLICA=0.994] autolearn=no 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 ZzNAdc3kXOYE; Fri, 19 Sep 2014 10:01:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 507C41A033E; Fri, 19 Sep 2014 10:01:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919170146.13173.27136.idtracker@ietfa.amsl.com> Date: Fri, 19 Sep 2014 10:01:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/To4TOhxuOuhGavq2gVUE6Bg8Me8 X-Mailman-Approved-At: Fri, 19 Sep 2014 10:50:14 -0700 Cc: gjshep@gmail.com, bier@ietf.org Subject: [Bier] New Non-WG Mailing List: BIER -- "Bit Indexed Explicit Replication discussion list" X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 17:01:48 -0000 A new IETF non-working group email list has been created. List address: bier@ietf.org Archive: http://www.ietf.org/mail-archive/web/bier/ To subscribe: https://www.ietf.org/mailman/listinfo/bier Purpose: There is a need to simplify network operations for multicast services. Current solutions require a tree-building control plane, which maintains 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 include mechanics from legacy use-cases and/or assumptions which may no longer apply to the current deployments. 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. This mailing list is for a discussion of this topic and the coordination of a potential BoF on the subject of a new architecture for the forwarding of multicast data packets. The goal is to provide optimal forwarding of multicast packets through a "multicast domain" without requiring an explicit tree-building protocol, nor requiring intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit-string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification. BIER may require extensions to IGPs and BGP in addition to the architecture and encapsulation descriptions. For this reason it is expected that BIER will require a dedicated working group which will focus on the overall architecture and shepherd the work toward consensus in the various other location where work is needed. For additional information, please contact the list administrators. From nobody Tue Sep 23 17:45:13 2014 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 56E4A1A8981 for ; Tue, 23 Sep 2014 17:45:12 -0700 (PDT) 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 6ZFRXNANTpOA for ; Tue, 23 Sep 2014 17:45:11 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AB31A8980 for ; Tue, 23 Sep 2014 17:45:11 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id rd18so5813471iec.16 for ; Tue, 23 Sep 2014 17:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=DdILgufN4MzSQFgLcts/x5LSRQOlvM5laRNZ/94Dn6w=; b=JNV/+mijmKosc266VIPe8eWsZFCvmdeixTqRPktif21wKH9Z0lkhoa3gR8bLjL8MMw vV1nlzfggt+w1n5zDzqnNAIvfbTGGwdSYKpoiYiPXSDWh6eu+dJ8vBT0EU8b2ll9quKu sdcU+NoKz+Nrlbejk910Fn3Wr7NFxC0DcPRpkTSM2y+/bYLZqSl5duYdpUNaslE4S8RE pHj1mjAKuFrCUEVoOMkg3eBAUqcmLLK4QoCt2dkvlCDuQdR9LN6Z3x/wWq3rsA9RXxee 0YKBnigOMKtj6KdsHdUYW3Y4ixWrlm9FQzX7w4D1CDmiqa0Q3/MnH6Y58E6lAS5Kj8Ur 7qRg== X-Received: by 10.50.61.99 with SMTP id o3mr8112674igr.30.1411519510614; Tue, 23 Sep 2014 17:45:10 -0700 (PDT) Received: from [192.168.97.184] ([67.210.160.130]) by mx.google.com with ESMTPSA id sd6sm3027513igb.6.2014.09.23.17.45.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 17:45:10 -0700 (PDT) Message-ID: <54221416.5030007@gmail.com> Date: Tue, 23 Sep 2014 20:45:10 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: bier@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/bier/PeWFiY-e7otdyfpYS0GN8NXbuRc Subject: [Bier] What documents are we starting with? 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, 24 Sep 2014 00:45:12 -0000 Well, I've been here a day or so. Any documents? Tom Taylor From nobody Tue Sep 23 22:31:58 2014 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 622C81A6F2C for ; Tue, 23 Sep 2014 22:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 VwPht9i3ii68 for ; Tue, 23 Sep 2014 22:31:55 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3281A1A35 for ; Tue, 23 Sep 2014 22:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=523; q=dns/txt; s=iport; t=1411536715; x=1412746315; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=darTvUUYzw5QgiCMr8XevG7rkHraskpwRIWDkFTjyq4=; b=RkEBBg3R9+EboXqd4nwxY46TrF4+PG0FkJLwftyU+IpOpNCY27wVgsAg MO0dEAdDBbo80jXQdeIYtOGpKoIFlqrsx2jFEJe/UaROVm6+6QqDQLQIw tAxpqEsuk8WAJGiM5SuC6WfOQv0Z2GT5BAcYCQ7aSSxwInfGQ6DX9MBF2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsKACxWIlStJssW/2dsb2JhbABgg2FXtWUBAQEBAQUBcgGTOAqHTQGBHQF6hAQBAQMBAQEBNzQLBQsLEjQhBiIOBhOIKgMJCA27Eg2HLwETBIYNh0uCLweDLoEdAQSWFIR4ghCPDYZGg2Q7LwGCSQEBAQ X-IronPort-AV: E=Sophos;i="5.04,587,1406592000"; d="scan'208";a="187731749" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 24 Sep 2014 05:31:53 +0000 Received: from ams-iwijnand-8816.cisco.com (ams-iwijnand-8816.cisco.com [10.60.202.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8O5VqDA003877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Sep 2014 05:31:53 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: IJsbrand Wijnands In-Reply-To: <54221416.5030007@gmail.com> Date: Wed, 24 Sep 2014 07:31:50 +0200 Content-Transfer-Encoding: 7bit Message-Id: <41645710-A4EB-4C85-8C8F-94EFA2E4E201@cisco.com> References: <54221416.5030007@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/bier/mC8AHMz-qb6gnYCtmaQsQ5FErgw Cc: bier@ietf.org Subject: Re: [Bier] What documents are we starting with? 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, 24 Sep 2014 05:31:57 -0000 Hi Tom, Here are the first two: https://tools.ietf.org/id/draft-wijnands-bier-architecture-00.txt https://tools.ietf.org/id/draft-wijnands-mpls-bier-encapsulation-00.txt We hope to submit a few more this week, Thx! Ice. On 24 Sep 2014, at 02:45, Tom Taylor wrote: > Well, I've been here a day or so. Any documents? > > Tom Taylor > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Thu Sep 25 13:03:47 2014 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 B7FE01A0143 for ; Thu, 25 Sep 2014 13:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 TTxiGJXRrLuY for ; Thu, 25 Sep 2014 13:03:44 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE4E1A030C for ; Thu, 25 Sep 2014 13:03:43 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id t60so8427573wes.8 for ; Thu, 25 Sep 2014 13:03:42 -0700 (PDT) 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=0KN9awtO44PpwtNXtbMgqjbZ4MJuaYA5iaYD/yDfM9U=; b=zJFx4bnAx5YOJNyTzOe4xqO36wRX8BzNOnHhRwNUp2vljTPyfpAR4bI1ojBJUwY4ZY bDqiz4e0KypE9UyAWp7oPeQeqoNb5lBp4Ws3O2sXugB+ltBxwL+sBWUW5XbFadcY7mMd RM8R1kg5HzbuU/8YjnNQssj3hXgTYr0II7RZ4GZogfUuWf4T1Ta1HysSA4xRtkscUbor Bq7X+arkPxzVcaquNTa/okJxtibJyDupItDXfSz5+BAOv85QRl6kzCF8FbbfoB73ufCu N1CX1F3WzVvCL+82/jxsO0hOqzKwKFQ6/NCIuaqJ3JzPiCaLVPT7ryohRF43FmTQs7GW a5Gg== MIME-Version: 1.0 X-Received: by 10.194.88.167 with SMTP id bh7mr5792491wjb.129.1411675422512; Thu, 25 Sep 2014 13:03:42 -0700 (PDT) Received: by 10.180.93.201 with HTTP; Thu, 25 Sep 2014 13:03:42 -0700 (PDT) Date: Thu, 25 Sep 2014 13:03:42 -0700 Message-ID: From: Greg Shepherd To: bier@ietf.org Content-Type: multipart/alternative; boundary=089e0102f0ca18dd9b0503e94c88 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/7PmOcSe1mXezkmN9QiW0rx1Gip4 Subject: [Bier] BIER Problem Statement 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, 25 Sep 2014 20:03:46 -0000 --089e0102f0ca18dd9b0503e94c88 Content-Type: text/plain; charset=UTF-8 Thanks for joining the list! Sorry for the delay on getting some of these IDs posted. Life can be complicated some times.. The Problem Statement draft is now submitted so please read and respond here on the list, with or without support. We need to get a feel from the community on progressing this work. https://tools.ietf.org/id/draft-shepherd-bier-problem-statement-00.txt I've edited the BoF Wiki removing the IDs which have not yet been submitted to reduce the "where's the draft?" noise, and help us focused on the most important work at this time - problem, arch, and encap. The other two IDs are here: http://tools.ietf.org/html/draft-wijnands-bier-architecture-00 http://tools.ietf.org/html/draft-wijnands-mpls-bier-encapsulation-00 I look forward to hearing from you! Cheers, Greg --089e0102f0ca18dd9b0503e94c88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for joining the list! Sorry for the delay on gettin= g some of these IDs posted. Life can be complicated some times..

The Problem Statement draft is now submitted so please read and re= spond here on the list, with or without support. We need to get a feel from= the community on progressing this work.


I've edited the BoF Wiki removing the IDs= which have not yet been submitted to reduce the "where's the draf= t?" noise, and help us focused on the most important work at this time= - problem, arch, and encap.

The other two IDs are= here:


I look f= orward to hearing from you!

Cheers,
Greg=
--089e0102f0ca18dd9b0503e94c88-- From nobody Thu Sep 25 23:40:25 2014 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 8C8281A1A08 for ; Thu, 25 Sep 2014 23:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 Bf7D5qARPPVK for ; Thu, 25 Sep 2014 23:40:22 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AECB1A02BA for ; Thu, 25 Sep 2014 23:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1200; q=dns/txt; s=iport; t=1411713622; x=1412923222; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bh1cpYAgQLKV2Vd7KqcSh1NJ8JOljLej5leULKZSsCc=; b=mpOy6MgbY2firpjd5QvMMqlWEEIjMPamQtxaK4cAAAk71kG8O7Lw1vRE G2aUjzCuSiRw+zA4NmIfwzOXlUr5OmY5E1rfHlXmIaPY+qgpw3ohaFcSW qB8dBXVHdvZa826cNjF/a+jjP/xUNCcs+kf8x4S+w1ayMC9OqNBUHCI1S 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsKAN8IJVStJssW/2dsb2JhbABgg2FXtjMBAQEBAQEFAXIBknsKh04CgRcBe4QEAQEDAQEBATc0CwULCxI0IQYiDhkUBYgRAwkIDboVDYckAReGEodcgX0zBxaDGIEdBZYahHmCEIFijS2GR4NlOy8BgkkBAQE X-IronPort-AV: E=Sophos;i="5.04,603,1406592000"; d="scan'208";a="185481575" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 26 Sep 2014 06:40:19 +0000 Received: from ams-iwijnand-8816.cisco.com (ams-iwijnand-8816.cisco.com [10.60.202.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q6eI3m002017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Sep 2014 06:40:19 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: IJsbrand Wijnands In-Reply-To: Date: Fri, 26 Sep 2014 08:40:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C7C67A3-459E-43C4-8CC9-1F6317C67181@cisco.com> References: To: bier@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/bier/iwbsE2VBDlGEoGdTQ8vUTrwpGuU Cc: Greg Shepherd Subject: Re: [Bier] BIER Problem Statement 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, 26 Sep 2014 06:40:24 -0000 Hi Folks, One more available: https://tools.ietf.org/id/draft-rosen-l3vpn-mvpn-bier-00.txt Thx, Ice. On 25 Sep 2014, at 22:03, Greg Shepherd wrote: > Thanks for joining the list! Sorry for the delay on getting some of = these IDs posted. Life can be complicated some times.. >=20 > The Problem Statement draft is now submitted so please read and = respond here on the list, with or without support. We need to get a feel = from the community on progressing this work. >=20 > https://tools.ietf.org/id/draft-shepherd-bier-problem-statement-00.txt >=20 > I've edited the BoF Wiki removing the IDs which have not yet been = submitted to reduce the "where's the draft?" noise, and help us focused = on the most important work at this time - problem, arch, and encap. >=20 > The other two IDs are here: >=20 > http://tools.ietf.org/html/draft-wijnands-bier-architecture-00 > http://tools.ietf.org/html/draft-wijnands-mpls-bier-encapsulation-00 >=20 > I look forward to hearing from you! >=20 > Cheers, > Greg > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Fri Sep 26 04:57:36 2014 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 437871A1B3D for ; Fri, 26 Sep 2014 04:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 vW3ugJIHaaMb for ; Fri, 26 Sep 2014 04:57:32 -0700 (PDT) Received: from mail-qa0-x244.google.com (mail-qa0-x244.google.com [IPv6:2607:f8b0:400d:c00::244]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102501A1B3A for ; Fri, 26 Sep 2014 04:57:31 -0700 (PDT) Received: by mail-qa0-f68.google.com with SMTP id f12so1733215qad.3 for ; Fri, 26 Sep 2014 04:57:31 -0700 (PDT) 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=FGlV1jBqlCwY4w6PFzjLugcHbYWCLhB58M5IOyE22rY=; b=e0CXdQNtBkhC3L879YkrYpTVQ174lpUq5V1FRKeyB0+3bXOOo7dby5mVVbwnT4v/Hb rluv6XstmOGL1J5QdwzV6QXAHmxXwcS7/j5uMBebE63z9G2LwAX1ue9XWNycrBs3OycC bZcq+vmKZCv9ilFiSDmsVx8t0K+luXwPnTMS4NnjkcA6wZxsNOCKH3VnvpKYozmLbo5r xYc3GGlRNF3xP+xXE8l7Yg6Srh0yE9Elrp0yfD7VsoFOI1+prBaMb24C0opJU9qce4lt 1T4+Ad04n0KTqEwv2T5g+LXbvL4xQizrNYTVXLpPoZjK5Gjp9A2loKisS6Mi4xoiINTS 59DA== MIME-Version: 1.0 X-Received: by 10.229.212.138 with SMTP id gs10mr26678853qcb.7.1411732651234; Fri, 26 Sep 2014 04:57:31 -0700 (PDT) Received: by 10.140.91.105 with HTTP; Fri, 26 Sep 2014 04:57:31 -0700 (PDT) Date: Fri, 26 Sep 2014 13:57:31 +0200 Message-ID: From: Gregory CAUCHIE To: bier@ietf.org Content-Type: multipart/alternative; boundary=001a11336d5c31fa450503f69fa7 Archived-At: http://mailarchive.ietf.org/arch/msg/bier/fKQBbUUNZ8JWSnSdomjWPxOV_go Subject: Re: [Bier] BIER Problem Statement 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, 26 Sep 2014 11:57:34 -0000 --001a11336d5c31fa450503f69fa7 Content-Type: text/plain; charset=UTF-8 Hi Folks, Really happy to see that discussions became a first reality. I'm hoping it can go forward as the problem satetement tackles some real issues in our live networks. Will do my best to participate in the discussion (even if there is no beer involved at first ;-)). -- Greg --001a11336d5c31fa450503f69fa7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
Hi Folks,


Really happy to see that discussions became a first reality.=
 I'm hoping it can go forward as the problem satetement tackles some re=
al issues in our live networks.
Will do my best to participat=
e in the discussion (even if there is no beer involved at first ;-)).
--
Greg


--001a11336d5c31fa450503f69fa7--


From nobody Fri Sep 26 08:11:32 2014
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 0C4FD1A897C for ; Fri, 26 Sep 2014 08:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Uw2nwLqJKmi7 for ; Fri, 26 Sep 2014 08:11:27 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7341A6FED for ; Fri, 26 Sep 2014 08:11:26 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s8QFBO4w009330 for ; Fri, 26 Sep 2014 16:11:24 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s8QFBLUu009298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 26 Sep 2014 16:11:22 +0100
From: "Adrian Farrel" 
To: 
Date: Fri, 26 Sep 2014 16:11:17 +0100
Message-ID: <051501cfd99c$205b1780$61114680$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac/ZnBisQPBQ9OujR6OJTMN+0P37nw==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20976.006
X-TM-AS-Result: No--3.772-10.0-31-10
X-imss-scan-details: No--3.772-10.0-31-10
X-TMASE-MatchedRID: +zq3ScDhdVw2UEKHDN0wzE0IfQOJvRLRpT/dtVAOQFZ9Q5/gynnG1nX8 6phlSF63EcE+LOiKuIuhGGCt9tM+c08HitdqBBn76Zzj+kMRBrZ9LQinZ4QefL6qvLNjDYTwfyj BJDnutUhQSFbL1bvQASdET58jp62SCyucQo5hB53mMbcCT0v6h9cz3SGiCcqLazD20+nkkDWuVZ gj3WBBoXz2KKXDd293ZXMmYNYUgqoHw4H5RpL90O2xchNPpRCQTf70HMUKRXM0BbzfNgPD+/U6U Ig/Ep+LOeAxECCt14TJ+RZp4bmn0A==
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/4UKYZg-89wkqbiZAEWUz8hrR3IU
Subject: [Bier] MPLS encapsulation
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 15:11:29 -0000

Hello biery people,

I have been scanning
https://datatracker.ietf.org/doc/draft-wijnands-mpls-bier-encapsulation/ and I
have three questions.

I ask these more in the spirit of discovery than because I have a particular
view, so I'll be happy to plant the questions and see you all go off and debate.

1. Bier in the middle of a stack.
As I read the draft, if I have MPLS payload over Bier multicast then I would...
Set bottom of stack in the special purpose label, include Bier header, set "next
protocol" to MPLS.

2. Stacked Bier
Could I set the Bier "next protocol" to Bier?

3. Why a special purpose label rather than a control word?
Since you are already hitting the bottom of stack, wouldn't using the control
word be more consistent?

Cheers,
Adrian


From nobody Fri Sep 26 09:05:27 2014
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 063491A89FC for ; Fri, 26 Sep 2014 09:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 eQ3bxmf-lvR0 for ; Fri, 26 Sep 2014 09:05:16 -0700 (PDT)
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 4E6731A86DE for ; Fri, 26 Sep 2014 09:04:55 -0700 (PDT)
X-AuditID: c6180641-f79916d00000623a-44-542535ecd855
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id FB.3E.25146.CE535245; Fri, 26 Sep 2014 11:46:20 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Fri, 26 Sep 2014 12:04:53 -0400
From: Antoni Przygienda 
To: Gregory CAUCHIE , "bier@ietf.org" 
Thread-Topic: [Bier] BIER Problem Statement
Thread-Index: AQHP2YENcQSCSMHA50+yleaxsSGDwpwTkXbA
Date: Fri, 26 Sep 2014 16:04:53 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181B59E6@eusaamb103.ericsson.se>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.12]
Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F181B59E6eusaamb103ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPoO4bU9UQg9OLLSyWztjDZLH/30Um ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjzMUj7AVNcRWNTVeYGxh3RHcxcnJICJhI HFk2mxXCFpO4cG89WxcjF4eQwFFGiYfd7awQznJGiQv3l7GBVLEJWEhc/vaUGcQWEfCVeHh3 GhOILSygJfFt+R0miLi2xP8Hm1khbCOJxRM+gfWyCKhKfPu7AszmFfCW+P/iLliNkECAxNRL W8FsToFAiSkb/rKD2IxAF30/tQZsJrOAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP6gPlCTmvL7G DFGfL/Hp9BVmiF2CEidnPmGZwCgyC8moWUjKZiEpm8XIARTXlFi/Sx+iRFFiSvdDdghbQ6J1 zlx2ZPEFjOyrGDlKi1PLctONDDcxAqPnmASb4w7GBZ8sDzEKcDAq8fAqRKiECLEmlhVX5h5i lOZgURLn1ayeFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcVW5/acja88cD+EWCXNYPekw S7jZ3AK1+Guss2fJT7nrXLvD+JBW/IMnL80ncH/5KsxwrP3QzxsbrHVTI3R8Vl+RmeanycN6 S/H2dqV3piV7e9MbUlaezTL8t2G5UPcq0fKv/+Y3uq6xKEhyLE+YJcc3e+25eSJPDf81G1zk 2Lqj8keF427j30osxRmJhlrMRcWJAKlPMxJ/AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/WIw2QTQqLYEueL32FMXT8KUj1AA
Subject: Re: [Bier] BIER Problem Statement
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, 26 Sep 2014 16:05:21 -0000

--_000_2E4BB27CAB87BF43B4207C0E55860F181B59E6eusaamb103ericsso_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QmllciBfd2lsbF8gYmUgaW52b2x2ZWQgOy0pICBTb21lIGNsYWltLCB0aGlzIGlzIHRoZSBwcmlt
YXJ5IHRlY2hub2xvZ3kgdGhhdCBicm91Z2h0IHRoaXMgZ3JvdXAgdG9nZXRoZXIgYW5kIG5vdCBJ
UCA7LSkgIExldCB0aGVtIHdhZyB0aGVpciB0b25ndWVzLCB3ZSBnaXZlIHRoZSBxdWVzdGlvbiBk
dWUgY29uc2lkZXJhdGlvbiBpbiBIYXdhaWkgYWxiZWl0IGFuIG9sZCBHZXJtYW4g4oCYU2NobGFn
ZXLigJkgIGRpc3NlbWluYXRlcyBkaXN0dXJiaW5nIHJ1bW9ycw0KDQpodHRwOi8vd3d3LnlvdXR1
YmUuY29tL3dhdGNoP3Y9RUwtblRCaXdkaUUNCg0KTG9vc2UgRW5nbGlzaCB0cmFuc2xhdGlvbjog
4oCcVGhlcmUgaXMgTk8gYmVlciBvbiBIYXdhaWnigJ0uDQoNCkZvciBmb2xrcyBhc2tpbmcgdGhl
bXNlbHZlcyDigJx3aGVyZeKAmXMgdGhlIG90aGVyIGdvb2RpZXPigJ0sICB0aGVyZSBpcyBnb29k
IGFtb3VudCBvZiBhY3Rpdml0eSBvbiBPU1BGL0lTSVMgZHJhZnQgd2l0aCBuZWNlc3NhcnkgaW5m
byBkaXN0cmlidXRpb24gd2hpY2gsIHRoaW5ncyBnb2luZyB3ZWxsICYgY3ljbGVzIGZvdW5kLCB3
aWxsIGhpdCB0aGUgcm9hZC4gIEkgaGF2ZSBvbmUgbW9yZSBvbiBhcHBsaWNhdGlvbiBvZiBCSUVS
IGNvb2tpbmcgaW4gYSBkcmFmdCBidXQgYWdhaW4sIGN5Y2xlcyBhcmUgYWx3YXlzIHRoZSBsaW1p
dGluZyBmYWN0b3IgdG8gYWxsIHRoZSBnb29kIGlkZWFzIGFuZCBiZXN0IGludGVudGlvbnMgb25l
IGhhcmJvcnMNCg0KdGhhbmtzDQoNCi0tLSB0b255DQoNCkZyb206IEJJRVIgW21haWx0bzpiaWVy
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnb3J5IENBVUNISUUNClNlbnQ6IEZy
aWRheSwgU2VwdGVtYmVyIDI2LCAyMDE0IDQ6NTggQU0NClRvOiBiaWVyQGlldGYub3JnDQpTdWJq
ZWN0OiBSZTogW0JpZXJdIEJJRVIgUHJvYmxlbSBTdGF0ZW1lbnQNCg0KDQpIaSBGb2xrcywNCg0K
DQoNCg0KDQpSZWFsbHkgaGFwcHkgdG8gc2VlIHRoYXQgZGlzY3Vzc2lvbnMgYmVjYW1lIGEgZmly
c3QgcmVhbGl0eS4gSSdtIGhvcGluZyBpdCBjYW4gZ28gZm9yd2FyZCBhcyB0aGUgcHJvYmxlbSBz
YXRldGVtZW50IHRhY2tsZXMgc29tZSByZWFsIGlzc3VlcyBpbiBvdXIgbGl2ZSBuZXR3b3Jrcy4N
Cg0KV2lsbCBkbyBteSBiZXN0IHRvIHBhcnRpY2lwYXRlIGluIHRoZSBkaXNjdXNzaW9uIChldmVu
IGlmIHRoZXJlIGlzIG5vIGJlZXIgaW52b2x2ZWQgYXQgZmlyc3QgOy0pKS4NCg0KLS0NCkdyZWcN
Cg==

--_000_2E4BB27CAB87BF43B4207C0E55860F181B59E6eusaamb103ericsso_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv
Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs
InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp
dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD
aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0
dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7
DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2Ug
V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx
LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t
Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0
PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4
dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N
CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz
aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJpZXIgXzxpPjxzcGFuIHN0eWxlPSJmb250LXN0eWxl
Oml0YWxpYyI+d2lsbDwvc3Bhbj48L2k+XyBiZSBpbnZvbHZlZCA7LSkmbmJzcDsgU29tZSBjbGFp
bSwgdGhpcyBpcyB0aGUgcHJpbWFyeSB0ZWNobm9sb2d5DQogdGhhdCBicm91Z2h0IHRoaXMgZ3Jv
dXAgdG9nZXRoZXIgYW5kIG5vdCBJUCA7LSkgJm5ic3A7TGV0IHRoZW0gd2FnIHRoZWlyIHRvbmd1
ZXMsIHdlIGdpdmUgdGhlIHF1ZXN0aW9uIGR1ZSBjb25zaWRlcmF0aW9uIGluIEhhd2FpaSBhbGJl
aXQgYW4gb2xkIEdlcm1hbiDigJhTY2hsYWdlcuKAmSAmbmJzcDtkaXNzZW1pbmF0ZXMgZGlzdHVy
YmluZyBydW1vcnMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBj
b2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1F
TC1uVEJpd2RpRSI+aHR0cDovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PUVMLW5UQml3ZGlFPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u
dCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3
ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkxvb3NlIEVuZ2xpc2ggdHJhbnNsYXRpb246IOKAnFRoZXJlIGlzIE5PIGJlZXIgb24gSGF3
YWlp4oCdLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi
IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Rm9yIGZvbGtzIGFza2luZyB0aGVtc2VsdmVzIOKAnHdoZXJl4oCZ
cyB0aGUgb3RoZXIgZ29vZGllc+KAnSwmbmJzcDsgdGhlcmUgaXMgZ29vZCBhbW91bnQgb2YgYWN0
aXZpdHkgb24gT1NQRi9JU0lTIGRyYWZ0DQogd2l0aCBuZWNlc3NhcnkgaW5mbyBkaXN0cmlidXRp
b24gd2hpY2gsIHRoaW5ncyBnb2luZyB3ZWxsICZhbXA7IGN5Y2xlcyBmb3VuZCwgd2lsbCBoaXQg
dGhlIHJvYWQuICZuYnNwO0kgaGF2ZSBvbmUgbW9yZSBvbiBhcHBsaWNhdGlvbiBvZiBCSUVSIGNv
b2tpbmcgaW4gYSBkcmFmdCBidXQgYWdhaW4sIGN5Y2xlcyBhcmUgYWx3YXlzIHRoZSBsaW1pdGlu
ZyBmYWN0b3IgdG8gYWxsIHRoZSBnb29kIGlkZWFzIGFuZCBiZXN0IGludGVudGlvbnMgb25lIGhh
cmJvcnM8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx
ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj50aGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg
Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj4tLS0gdG9ueQ0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl
PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIi
IGZhY2U9IlRhaG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCSUVSDQogW21haWx0
bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmddIDxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk
Ij5PbiBCZWhhbGYgT2YgPC9zcGFuPg0KPC9iPkdyZWdvcnkgQ0FVQ0hJRTxicj4NCjxiPjxzcGFu
IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IEZyaWRheSwgU2VwdGVt
YmVyIDI2LCAyMDE0IDQ6NTggQU08YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s
ZCI+VG86PC9zcGFuPjwvYj4gYmllckBpZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250
LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBbQmllcl0gQklFUiBQcm9ibGVt
IFN0YXRlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9mb250PjwvcD4NCjxkaXY+DQo8cHJlPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SGkgRm9sa3MsPG86cD48L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdCI+UmVhbGx5IGhhcHB5IHRvIHNlZSB0aGF0IGRpc2N1c3Npb25z
IGJlY2FtZSBhIGZpcnN0IHJlYWxpdHkuIEknbSBob3BpbmcgaXQgY2FuIGdvIGZvcndhcmQgYXMg
dGhlIHByb2JsZW0gc2F0ZXRlbWVudCB0YWNrbGVzIHNvbWUgcmVhbCBpc3N1ZXMgaW4gb3VyIGxp
dmUgbmV0d29ya3MuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZSBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+V2lsbCBkbyBteSBiZXN0IHRvIHBhcnRpY2lw
YXRlIGluIHRoZSBkaXNjdXNzaW9uIChldmVuIGlmIHRoZXJlIGlzIG5vIGJlZXIgaW52b2x2ZWQg
YXQgZmlyc3QgOy0pKS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250
IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dCI+LS08YnI+R3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_2E4BB27CAB87BF43B4207C0E55860F181B59E6eusaamb103ericsso_--


From nobody Fri Sep 26 09:47:38 2014
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 5BBBF1A88E7 for ; Fri, 26 Sep 2014 09:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 r1DIDC9yAjIz for ; Fri, 26 Sep 2014 09:47:34 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35DE1A8033 for ; Fri, 26 Sep 2014 09:47:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=315; q=dns/txt; s=iport; t=1411750055; x=1412959655; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=oRxusiNMc17PcCLBWCNo2M52N3S+JAvNWlbcpuLCBy8=; b=jAlW4tysqj5OspjDt7dOSMRDyGT5qK2k6v8c5k7lRrtYJ1bMJUV2bMXR 0JjNvaLEK/H0BGLFwwOOC7UDLuaYVEOir7mz3Cx86HkKJh5o8Yd4uSoD9 UivEZ5XBXbZVQi4/RIwk5DH092VyMR51j0bb287G3Y5RkFfXYRIJjJc4g s=;
X-IronPort-AV: E=Sophos;i="5.04,604,1406592000"; d="scan'208";a="358504572"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 26 Sep 2014 16:47:34 +0000
Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8QGlXhR026183; Fri, 26 Sep 2014 16:47:33 GMT
Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id E423840A; Fri, 26 Sep 2014 12:47:32 -0400 (EDT)
From: Eric Rosen 
To: adrian@olddog.co.uk
In-reply-to: Your message of Fri, 26 Sep 2014 16:11:17 +0100. <051501cfd99c$205b1780$61114680$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9766.1411750052.1@erosen-lnx>
Date: Fri, 26 Sep 2014 12:47:32 -0400
Message-ID: <9767.1411750052@erosen-lnx>
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/Xo8BigmVEmuOj992PYzbVu0T44c
Cc: bier@ietf.org
Subject: Re: [Bier] MPLS encapsulation
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: erosen@cisco.com
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 16:47:36 -0000

Adrian,

I'm a little confused about your question: are you using the term "special
purpose label" in the sense of RFC 7274 ("Allocating and Retiring
Special-Purpose MPLS Labels")?  If so, there is no use of special purpose
labels (in this sense) being proposed.

Did I misunderstand your question?

Eric




From nobody Fri Sep 26 10:16:44 2014
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 D77C91A8034 for ; Fri, 26 Sep 2014 10:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 V3ek_9gS_zjJ for ; Fri, 26 Sep 2014 10:16:41 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001: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 6D8971A1ABC for ; Fri, 26 Sep 2014 10:16:40 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id x19so13328595ier.1 for ; Fri, 26 Sep 2014 10:16:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:cc:content-type;  bh=KUokno87G6eUmgr5fBVAge5f5WUB8EILg0gQLTPiEIQ=; b=Tqu78xT1pZSzs0s4osNxsDCqDTo+Nk8jxjMw61cXdSsw3hZGq2fS/joUwLHnVnJB3A qVT3Vf/tJ86g2pgCXnUxgEL/ihQVrXER4pULtef9Dw8FfZPnzqYz+FUHvtgOnoBWWy3n +ruQjL4FJcyIK708tUCSTLtkPea0tWn9Y8FLHYn10OSemitKt4K0CTSBuwUvJ+Xc1abB mNEc++BWJ44IJNQPGzi4yzGfYjcoU46EPWzb8JmaSWp2xWAvxVINL3zxnlh5+Oi7Lb5V qyc7+9/JNjqSEg/5f2wT0jC5G1dv/ietHWo/Xzq0ncNkAq0I0ofoRqSrv0gtPMOuRlbx U+7w==
MIME-Version: 1.0
X-Received: by 10.51.17.2 with SMTP id ga2mr22766522igd.2.1411751799823; Fri, 26 Sep 2014 10:16:39 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.166.8 with HTTP; Fri, 26 Sep 2014 10:16:39 -0700 (PDT)
Date: Fri, 26 Sep 2014 19:16:39 +0200
X-Google-Sender-Auth: HU-VZNjFP9si9vMFiCt_1hG9GTY
Message-ID: 
From: Robert Raszuk 
To: "erosen@cisco.com" , IJsbrand Wijnands 
Content-Type: multipart/alternative; boundary=001a113491e48a2a430503fb1443
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/bXBVYVyP0_qaj-r3x_M2RnT3H4g
Cc: bier@ietf.org
Subject: [Bier] One specific transition churn ...
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, 26 Sep 2014 17:16:43 -0000

--001a113491e48a2a430503fb1443
Content-Type: text/plain; charset=UTF-8

Aren't we worried about impact of joins to the controller followed by churn
of rewrite changes on ingress router ?

Worst case is single receivers behind egress router joining and leaving ..
or a lot of them.

In traditional multicast joining the tree is sort of local .. in BIER
entire control plane is impacted.

At min perhaps the draft should introduce stability timers which would
effectively continue to forward given set of groups to the egress routers
even if receivers behind them leaves.

I realize that with BGP multicast procedures we have already stepped out of
multicast native behavior, however BGP has number of build in mechanisms to
well deal with churn. Is the assumption here that the associated signalling
of BIER will be BGP based ?

Rgs,
r.

--001a113491e48a2a430503fb1443
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



<=
/div>
Aren't we worried about impact of joi=
ns to the controller followed by churn of rewrite changes on ingress router=
 ?=C2=A0

Worst case is single receivers behind egress router joining and leav=
ing .. or a lot of them.=C2=A0

=

In traditional multicast joining the tree is s=
ort of local .. in BIER entire control plane is impacted.=C2=A0

At min perhap=
s the draft should introduce stability timers which would effectively conti=
nue to forward given set of groups to the egress routers even if receivers =
behind them leaves.

I realize that with BGP multicast procedures we have alr=
eady stepped out of multicast native behavior, however BGP has number of bu=
ild in mechanisms to well deal with churn. Is the assumption here that the =
associated signalling of BIER will be BGP based ?=C2=A0

Rgs,
r.


--001a113491e48a2a430503fb1443--


From nobody Fri Sep 26 10:29:53 2014
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 0CB961A86F0 for ; Fri, 26 Sep 2014 10:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 ythrWkgN6wkV for ; Fri, 26 Sep 2014 10:29:50 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A4D1A86EA for ; Fri, 26 Sep 2014 10:29:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4810; q=dns/txt; s=iport; t=1411752590; x=1412962190; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b5JAJSLA4RX712CUiGwNqyOisnCZRMd1SHwpsfIL5CQ=; b=ZziicYGZudruKzYa6yB/LgCGAfg6NfyZaBuEaODNJHW/WplJayGbmmf0 E+URdXCcAf4f5/Pd9PewEkfs3HrwZ2XwpnuBunKgXoSGQ5rRJEqy3Hj5b S9SwKkS5FFhosYrdt0h55Z7aoDcZ140S9oozpmHkwDIBk/xhBsbqeQuWr I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4LAHWhJVStJV2b/2dsb2JhbABfgw5TV4VhsFYPAQIFAXIekH2BbYdOAoELFgF7hAQBAQR5EAIBCAQ7BzIUEQIEDgWIPg2/EgEXhhKKDAeDLoEdBY9LghiEOocJgWKTeIFJghpsAYJJAQEB
X-IronPort-AV: E=Sophos; i="5.04,604,1406592000"; d="scan'208,217"; a="81629514"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 26 Sep 2014 17:29:49 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8QHTnTm021395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 17:29:49 GMT
Received: from xmb-aln-x14.cisco.com ([169.254.8.91]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 12:29:49 -0500
From: "IJsbrand Wijnands (iwijnand)" 
To: Robert Raszuk 
Thread-Topic: One specific transition churn ...
Thread-Index: AQHP2a2jJqr094SnM0OiywpFFkGKdZwTq5ZO
Date: Fri, 26 Sep 2014 17:29:48 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_EE6E4363E19D44A1ACDA6C5A16C41DB3ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/c-YA4XJ_hkx1_a55TBoQ0Ukogy0
Cc: "Eric Rosen \(erosen\)" , "bier@ietf.org" , "IJsbrand Wijnands \(iwijnand\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 17:29:52 -0000

--_000_EE6E4363E19D44A1ACDA6C5A16C41DB3ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Robert,

Good question.

As you say, when adding PIM (S,G)/(*,G) join information into BGP we alread=
y crossed a line there.

There is already a draft out there to deal with this: http://tools.ietf.org=
/id/draft-morin-multicast-damping-01.txt

For MVPN, BGP seems like an obvious choice, all the procedures we need are =
already defined. For other use cases we might as well go with some sort of =
SDN controller approach. The attractive proposition of BIER is that the con=
troller only needs to connect to the Ingress and Egress routers. It does no=
t need to connect to the core routers because there is no tree to build :-)=
 This is the beauty of the stateless approach!

Thx,

Ice.

Sent from my iPad

On 26 Sep 2014, at 19:16, "Robert Raszuk" > wrote:


Aren't we worried about impact of joins to the controller followed by churn=
 of rewrite changes on ingress router ?

Worst case is single receivers behind egress router joining and leaving .. =
or a lot of them.

In traditional multicast joining the tree is sort of local .. in BIER entir=
e control plane is impacted.

At min perhaps the draft should introduce stability timers which would effe=
ctively continue to forward given set of groups to the egress routers even =
if receivers behind them leaves.

I realize that with BGP multicast procedures we have already stepped out of=
 multicast native behavior, however BGP has number of build in mechanisms t=
o well deal with churn. Is the assumption here that the associated signalli=
ng of BIER will be BGP based ?

Rgs,
r.

--_000_EE6E4363E19D44A1ACDA6C5A16C41DB3ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Hi Robert,







Good question.







As you say, when adding PIM (S,G)/(*,G) join information into BGP we a=
lready crossed a line there. 







There is already a draft out there to deal with this: http://tools=
.ietf.org/id/draft-morin-multicast-damping-01.txt







For MVPN, BGP seems like an obvious choice, all the procedures we need=
 are already defined. For other use cases we might as well go with some sor=
t of SDN controller approach. The attractive proposition of BIER is that th=
e controller only needs to connect
 to the Ingress and Egress routers. It does not need to connect to the core=
 routers because there is no tree to build :-) This is the beauty of the st=
ateless approach!







Thx,







Ice.



Sent from my iPad




On 26 Sep 2014, at 19:16, "Robert Raszuk" <robert@raszuk.net> wrote:



















Aren't we worried about impact of joins to the=
 controller followed by churn of rewrite changes on ingress router ? <=
/div>






Worst case is single receivers behind egress r=
outer joining and leaving .. or a lot of them. 







In traditional multicast joining the tree is s=
ort of local .. in BIER entire control plane is impacted. 







At min perhaps the draft should introduce stab=
ility timers which would effectively continue to forward given set of group=
s to the egress routers even if receivers behind them leaves.







I realize that with BGP multicast procedures w=
e have already stepped out of multicast native behavior, however BGP has nu=
mber of build in mechanisms to well deal with churn. Is the assumption here=
 that the associated signalling of
 BIER will be BGP based ? 







Rgs,


r.












--_000_EE6E4363E19D44A1ACDA6C5A16C41DB3ciscocom_--


From nobody Fri Sep 26 10:35:41 2014
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 D2A341A8703 for ; Fri, 26 Sep 2014 10:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 Mve665sOXnq6 for ; Fri, 26 Sep 2014 10:35:38 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A436B1A8701 for ; Fri, 26 Sep 2014 10:35:37 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id at20so443670iec.12 for ; Fri, 26 Sep 2014 10:35:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Bdt8VL2C0n7401ZG9Sb7qUqyBOnbjzTJQrp3eXOEf7Q=; b=D2iEQEJTskP3mCFxvYmU2LHHewfQjXeVV+VLkmpOEkzoZyfmQvxbt0Lvy/DYW5q8Qa UdSO34LeFHgvKWAyYuWefHlHYHdXpGbrPyRwk7X0Kbphc5c7YOEX5+tvGYlkMnZsOrIV XWhTfX5ejj1O6okW3DYQ2L7r/dq5ySWo/TpA+jwXHlVnmcKS+x/avXKupTuXXBprpPDK gzz9eB/F4fmQjX2p9z/ktuc+90+ZCukIh2bkP1k6qztQZG5CjyBAiOGEMzDAylXNWGs/ 8KEqUSygNyUV9FmsxpKGZejCsBG9ibzqX8mZ169e3wuNX6jX3jcrYXCAkPsU19BTmLsu tIMA==
MIME-Version: 1.0
X-Received: by 10.50.73.130 with SMTP id l2mr33282432igv.9.1411752937015; Fri, 26 Sep 2014 10:35:37 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.166.8 with HTTP; Fri, 26 Sep 2014 10:35:36 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 26 Sep 2014 19:35:36 +0200
X-Google-Sender-Auth: FFg_ZN6mPAvvGmfJHF3BNPpi3PM
Message-ID: 
From: Robert Raszuk 
To: "IJsbrand Wijnands (iwijnand)" 
Content-Type: multipart/alternative; boundary=089e01160edc5274c50503fb58e2
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/NKsOPnsdkzWTMxqtNCf2VnFptr0
Cc: "Eric Rosen \(erosen\)" , "bier@ietf.org" 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 17:35:40 -0000

--089e01160edc5274c50503fb58e2
Content-Type: text/plain; charset=UTF-8

Hey Ice,

> It does not need to connect to the core routers because
> there is no tree to build :-) This is the beauty of the stateless
> approach!

Well of course .. this is principal element of the BIER architecture.

An interesting question for me is when this "stateless" nature crosses the
cost vs benefit equation ?

Clearly if you have few groups and hand full of receivers (for example of
high bandwith HD TV channels) I hardly see much of BIER advantage. But if
you have 1000s of groups and 100s of egress routers by all means simplicity
is quite obvious.

But it would be highly interesting to find such middle sweet spot in number
of groups/number of receivers expected in the network.

Cheers,
R.


On Fri, Sep 26, 2014 at 7:29 PM, IJsbrand Wijnands (iwijnand)  wrote:

>  Hi Robert,
>
>  Good question.
>
>  As you say, when adding PIM (S,G)/(*,G) join information into BGP we
> already crossed a line there.
>
>  There is already a draft out there to deal with this:
> http://tools.ietf.org/id/draft-morin-multicast-damping-01.txt
>
>  For MVPN, BGP seems like an obvious choice, all the procedures we need
> are already defined. For other use cases we might as well go with some sort
> of SDN controller approach. The attractive proposition of BIER is that the
> controller only needs to connect to the Ingress and Egress routers. It does
> not need to connect to the core routers because there is no tree to build
> :-) This is the beauty of the stateless approach!
>
>  Thx,
>
>  Ice.
>
> Sent from my iPad
>
> On 26 Sep 2014, at 19:16, "Robert Raszuk"  wrote:
>
>
>  Aren't we worried about impact of joins to the controller followed by
> churn of rewrite changes on ingress router ?
>
>  Worst case is single receivers behind egress router joining and leaving
> .. or a lot of them.
>
>  In traditional multicast joining the tree is sort of local .. in BIER
> entire control plane is impacted.
>
>  At min perhaps the draft should introduce stability timers which would
> effectively continue to forward given set of groups to the egress routers
> even if receivers behind them leaves.
>
>  I realize that with BGP multicast procedures we have already stepped out
> of multicast native behavior, however BGP has number of build in mechanisms
> to well deal with churn. Is the assumption here that the associated
> signalling of BIER will be BGP based ?
>
>  Rgs,
> r.
>
>

--089e01160edc5274c50503fb58e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hey Ice,

>=
; It does not need to connect to the core routers because=C2=A0
> there is no=
 tree to build :-) This is the beauty of the stateless=C2=A0
> approach!

Well of course .. this is principal element of=
 the BIER architecture.=C2=A0

An interesting question for me is when this "=
stateless" nature crosses the cost vs benefit equation ?=C2=A0<=
/div>

<=
/div>
Clearly if you =
have few groups and hand full of receivers (for example of high bandwith HD=
 TV channels) I hardly see much of BIER advantage. But if you have 1000s of=
 groups and 100s of egress routers by all means simplicity is quite obvious=
.=C2=A0

But it would be h=
ighly interesting to find such middle sweet spot in number of groups/number=
 of receivers expected in the network.=C2=A0

Cheers,
R.


=
On Fri, Sep 26, 2014 at 7:29 PM, IJsbrand Wijnands (iwijnand) <ice@cisco.com> wrote:







Hi Robert,







Good question.







As you say, when adding PIM (S,G)/(*,G) join information into BGP we a=
lready crossed a line there.=C2=A0







There is already a draft out there to deal with this:=C2=A0http://tools.ietf.org/id/draft-morin-multicast-damping-01.txt






For MVPN, BGP seems like an obvious choice, all the procedures we need=
 are already defined. For other use cases we might as well go with some sor=
t of SDN controller approach. The attractive proposition of BIER is that th=
e controller only needs to connect
 to the Ingress and Egress routers. It does not need to connect to the core=
 routers because there is no tree to build :-) This is the beauty of the st=
ateless approach!







Thx,







Ice.



Sent from my iPad




On 26 Sep 2014, at 19:16, "Robert Raszuk" <robert@raszuk.net> wrote:



















Aren't we worried about impact of joins to the controller followed=
 by churn of rewrite changes on ingress router ?=C2=A0







Worst case is single receivers behind egress router joining and leavin=
g .. or a lot of them.=C2=A0







In traditional multicast joining the tree is sort of local .. in BIER =
entire control plane is impacted.=C2=A0







At min perhaps the draft should introduce stability timers which would=
 effectively continue to forward given set of groups to the egress routers =
even if receivers behind them leaves.







I realize that with BGP multicast procedures we have already stepped o=
ut of multicast native behavior, however BGP has number of build in mechani=
sms to well deal with churn. Is the assumption here that the associated sig=
nalling of
 BIER will be BGP based ?=C2=A0







Rgs,


r.
















--089e01160edc5274c50503fb58e2--


From nobody Fri Sep 26 10:39:48 2014
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 8A5911A8A88 for ; Fri, 26 Sep 2014 10:39:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 kUyfYU7RmoUq for ; Fri, 26 Sep 2014 10:39:42 -0700 (PDT)
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 3E3871A8A6E for ; Fri, 26 Sep 2014 10:39:42 -0700 (PDT)
X-AuditID: c618062d-f79206d0000014d2-f2-54254e880cd4
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 08.5D.05330.88E45245; Fri, 26 Sep 2014 13:31:21 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 26 Sep 2014 13:39:37 -0400
From: Antoni Przygienda 
To: "IJsbrand Wijnands (iwijnand)" , Robert Raszuk 
Thread-Topic: One specific transition churn ...
Thread-Index: AQHP2a+BuVUit1FzlkuzW2MzFDiDwZwTq93Q
Date: Fri, 26 Sep 2014 17:39:36 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.12]
Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F181B5ACFeusaamb103ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLonVrfTTzXEYOEODoulM/YwWay7O4nF 4tWcO8wWTQubmB1YPKb83sjqsWTJTyaP3RsXMAUwR3HZpKTmZJalFunbJXBlTHkyg7mgra7i 04QnbA2M73O7GDk4JARMJJr3xnQxcgKZYhIX7q1n62Lk4hASOMoo8WrSZHYIZzmjxIy3C5hB qtgELCQuf3sKZosIhEtMbO9hAxnELOAr0X5QEiQsLKAnsaHpEStEib7E371f2CBsI4ldx6ex g9gsAqoSZ44sBbN5BbwlthyYzASxq5lRom3jH7D5nAK2Ev8e7gdrZgS67vupNUwgNrOAuMSt J/OZIK4WkFiy5zwzhC0q8fLxP1YIW0lizutrzBD1+RJrPm9hhlgmKHFy5hOWCYyis5CMmoWk bBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkaO0OLUsN93IYBMjMOaOSbDp7mDc 89LyEKMAB6MSD69ChEqIEGtiWXFl7iFGaQ4WJXHeWbXzgoUE0hNLUrNTUwtSi+KLSnNSiw8x MnFwSjUwrth7wDl7huPsTT+TLn/vWKZ7JFlo/6dly6suXL31XTic/ZTIYvGDas6nmo1n/psX vNjXc7Jhyrb7se8/z/hwU73yWdnBvcEGR7fvUayayP9yd8khfa7uZT03JLNWvrz4affj+08e bXdsEYtj6RVV2tb+sizBL3XLgQaBaTXykxrkpfKU/ruYP1NiKc5INNRiLipOBABH+8z5mgIA AA==
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/K9sqWhED6n5D84Kk1SV3KDL41Ts
Cc: "Eric Rosen \(erosen\)" , "bier@ietf.org" 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 17:39:45 -0000

--_000_2E4BB27CAB87BF43B4207C0E55860F181B5ACFeusaamb103ericsso_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Not sure this is a discussion about BIER multicast overlay or BIER layer (l=
ook @ arch). For the multicast overlay the discussion makes sense but it's =
kind of orthogonal to BIER itself.

A BIER layer is in a sense a 'distributed multicast fabric' only, it couldn=
't care whether it even runs IP multicast and people join/leave, it's basic=
ally a way to stitch together BFIRs to BFERs and if it carries something el=
se than IP multicast on it, no damage done (and possibly lots good ;-). In =
a sense it's like PMSI being used for other things in IP beside IP multicas=
t right now.    So don't think about it as "oooh, a G joins, this needs to =
join as a BFER".  Think about a fabric you can put into IP that all of a su=
dden gives you all-inclusive, selective, bi- or unidirectional P-channels i=
n a single shot. If overlay wants to flip BFERs on/off based on a G joining=
, well, their choice, if it just keeps all the PEs together, it's another u=
se & the pruning of the BFER receivers for the PEs that have the G happens =
in overlay sending over BIER 'fabric'.

The 'no tree necessary' is fibbing a little ;-)  It basically piggy-backs o=
n existing SPF today (while the architecture allows possibly other trees in=
 the future to improve the tradeoff of replication vs. avg. path-length to =
deliver a packet).

--- tony

From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand Wijnands (i=
wijnand)
Sent: Friday, September 26, 2014 10:30 AM
To: Robert Raszuk
Cc: Eric Rosen (erosen); bier@ietf.org; IJsbrand Wijnands (iwijnand)
Subject: Re: [Bier] One specific transition churn ...

Hi Robert,

Good question.

As you say, when adding PIM (S,G)/(*,G) join information into BGP we alread=
y crossed a line there.

There is already a draft out there to deal with this: http://tools.ietf.org=
/id/draft-morin-multicast-damping-01.txt

For MVPN, BGP seems like an obvious choice, all the procedures we need are =
already defined. For other use cases we might as well go with some sort of =
SDN controller approach. The attractive proposition of BIER is that the con=
troller only needs to connect to the Ingress and Egress routers. It does no=
t need to connect to the core routers because there is no tree to build :-)=
 This is the beauty of the stateless approach!

Thx,

Ice.

Sent from my iPad

On 26 Sep 2014, at 19:16, "Robert Raszuk" > wrote:

Aren't we worried about impact of joins to the controller followed by churn=
 of rewrite changes on ingress router ?

Worst case is single receivers behind egress router joining and leaving .. =
or a lot of them.

In traditional multicast joining the tree is sort of local .. in BIER entir=
e control plane is impacted.

At min perhaps the draft should introduce stability timers which would effe=
ctively continue to forward given set of groups to the egress routers even =
if receivers behind them leaves.

I realize that with BGP multicast procedures we have already stepped out of=
 multicast native behavior, however BGP has number of build in mechanisms t=
o well deal with churn. Is the assumption here that the associated signalli=
ng of BIER will be BGP based ?

Rgs,
r.

--_000_2E4BB27CAB87BF43B4207C0E55860F181B5ACFeusaamb103ericsso_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











=
Not sure this is a discussion about BIER multica=
st overlay or BIER layer (look @ arch). For the multicast overlay
 the discussion makes sense but it’s kind of orthogonal to BIER itsel=
f. 


=
 


=
A BIER layer is in a sense a ‘distributed =
multicast fabric’ only, it couldn’t care whether it even runs I=
P multicast
 and people join/leave, it’s basically a way to stitch together BFIRs=
 to BFERs and if it carries something else than IP multicast on it, no dama=
ge done (and possibly lots good ;-). In a sense it’s like PMSI being =
used for other things in IP beside IP multicast
 right now.    So don’t think about it as “oooh,=
 a G joins, this needs to join as a BFER”.  Think about a fabric=
 you can put into IP that all of a sudden gives you all-inclusive, selectiv=
e, bi- or unidirectional P-channels in a single shot. If overlay wants
 to flip BFERs on/off based on a G joining, well, their choice, if it just =
keeps all the PEs together, it’s another use & the pruning of the=
 BFER receivers for the PEs that have the G happens in overlay sending over=
 BIER ‘fabric’.



=
 


=
The ‘no tree necessary’ is fibbing a=
 little ;-)  It basically piggy-backs on existing SPF today (while the=
 architecture
 allows possibly other trees in the future to improve the tradeoff of repli=
cation vs. avg. path-length to deliver a packet).



=
 


=
--- tony



=
 








From: BIER
 [mailto:bier-bounces@ietf.org] On Beha=
lf Of 
IJsbrand Wijnands (iwijnand)

Sent: Friday, September 26, =
2014 10:30 AM

To: Robert Raszuk

Cc: Eric Rosen (erosen); bie=
r@ietf.org; IJsbrand Wijnands (iwijnand)

Subject: Re: [Bier] One spec=
ific transition churn ...






 




Hi Robert,






 






Good question.






 






As you say, when adding PIM (S,G)/(*,G) join informa=
tion into BGP we already crossed a line there. 






 






There is already a draft out there to deal with this=
: http://tools.ietf.org/id/draft-morin-multicast-damping-01.txt






 






For MVPN, BGP seems like an obvious choice, all the =
procedures we need are already defined. For other use cases we might as wel=
l go with some sort of SDN controller approach.
 The attractive proposition of BIER is that the controller only needs to co=
nnect to the Ingress and Egress routers. It does not need to connect to the=
 core routers because there is no tree to build :-) This is the beauty of t=
he stateless approach!






 






Thx,






 






Ice.



Sent from my iPad








On 26 Sep 2014, at 19:16, "Robert Raszuk" <robert@raszuk.net> wrote:=















 






Aren't we worried ab=
out impact of joins to the controller followed by churn of rewrite changes =
on ingress router ? 






 






Worst case is single=
 receivers behind egress router joining and leaving .. or a lot of them.&nb=
sp;






 






In traditional multi=
cast joining the tree is sort of local .. in BIER entire control plane is i=
mpacted. 






 






At min perhaps the d=
raft should introduce stability timers which would effectively continue to =
forward given set of groups to the egress routers
 even if receivers behind them leaves.






 






I realize that with =
BGP multicast procedures we have already stepped out of multicast native be=
havior, however BGP has number of build in mechanisms
 to well deal with churn. Is the assumption here that the associated signal=
ling of BIER will be BGP based ? 






 






Rgs,






r.=



















--_000_2E4BB27CAB87BF43B4207C0E55860F181B5ACFeusaamb103ericsso_--


From nobody Fri Sep 26 10:55:02 2014
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 41FC71A9101 for ; Fri, 26 Sep 2014 10:55:02 -0700 (PDT)
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 wL_oY-VUZ6dx for ; Fri, 26 Sep 2014 10:55:00 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::703]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17901A90FC for ; Fri, 26 Sep 2014 10:55:00 -0700 (PDT)
Received: from BY2PR05MB078.namprd05.prod.outlook.com (10.242.38.12) by BY2PR05MB662.namprd05.prod.outlook.com (10.141.221.14) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 26 Sep 2014 17:54:38 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB078.namprd05.prod.outlook.com (10.242.38.12) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 26 Sep 2014 17:54:36 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.136]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.48]) with mapi id 15.00.1034.003; Fri, 26 Sep 2014 17:54:35 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: "erosen@cisco.com" , "adrian@olddog.co.uk" 
Thread-Topic: [Bier] MPLS encapsulation
Thread-Index: AQHP2bDkpNFqmw1t/0KvCx3031PH1ZwTsfVQ
Date: Fri, 26 Sep 2014 17:54:35 +0000
Message-ID: <7f4d67bb417b42db9c65645f455c83af@BY2PR05MB079.namprd05.prod.outlook.com>
References: Your message of Fri, 26 Sep 2014 16:11:17 +0100. <051501cfd99c$205b1780$61114680$@olddog.co.uk> <9767.1411750052@erosen-lnx>
In-Reply-To: <9767.1411750052@erosen-lnx>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [66.129.241.10]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB078;UriScan:;
x-forefront-prvs: 03468CBA43
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(377454003)(13464003)(189002)(85852003)(76482002)(90102001)(2501002)(87936001)(50986999)(76176999)(4396001)(74316001)(19580405001)(19580395003)(83072002)(97736003)(101416001)(2656002)(54356999)(83322001)(86362001)(92566001)(99286002)(66066001)(10300001)(74662003)(33646002)(108616004)(95666004)(80022003)(20776003)(74502003)(107046002)(120916001)(105586002)(31966008)(85306004)(77096002)(79102003)(99396003)(46102003)(81342003)(76576001)(106356001)(77982003)(21056001)(106116001)(81542003)(64706001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB078; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB662;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/5s52uR-jaJLVePjebVlnBHZiIes
Cc: "bier@ietf.org" 
Subject: Re: [Bier] MPLS encapsulation
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, 26 Sep 2014 17:55:02 -0000

Adrian,

It's not a special purpose label, but its semantics (local to the receiving=
 router) is that a BIER header follows, and it's tied to a  t=
uple.

Jeffrey

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Friday, September 26, 2014 12:48 PM
> To: adrian@olddog.co.uk
> Cc: bier@ietf.org
> Subject: Re: [Bier] MPLS encapsulation
>=20
> Adrian,
>=20
> I'm a little confused about your question: are you using the term
> "special
> purpose label" in the sense of RFC 7274 ("Allocating and Retiring
> Special-Purpose MPLS Labels")?  If so, there is no use of special
> purpose
> labels (in this sense) being proposed.
>=20
> Did I misunderstand your question?
>=20
> Eric
>=20
>=20
>=20
>=20


From nobody Fri Sep 26 10:58:11 2014
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 90E291A90FC for ; Fri, 26 Sep 2014 10:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Level: 
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 E8ikTgr5HCIy for ; Fri, 26 Sep 2014 10:58:08 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 4E89D1A1A08 for ; Fri, 26 Sep 2014 10:58:08 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id A85E2BDAFEC00; Fri, 26 Sep 2014 17:58:04 +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 s8QHw7SR030205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 13:58:07 -0400
Received: from US70UWXCHMBA06.zam.alcatel-lucent.com ([169.254.11.223]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 13:58:07 -0400
From: "Dolganow, Andrew (Andrew)" 
To: Robert Raszuk , "erosen@cisco.com" ,  IJsbrand Wijnands 
Thread-Topic: [Bier] One specific transition churn ...
Thread-Index: AQHP2a2n8rED+3/3r0WIxrVy/f0JiJwTs30A
Date: Fri, 26 Sep 2014 17:58:06 +0000
Message-ID: 
References: 
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.4.140807
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_D04B20E15D3EEandrewdolganowalcatellucentcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/xxDHXCc6s7pNuOnVFDWR_z3Ejf0
Cc: "bier@ietf.org" 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 17:58:09 -0000

--_000_D04B20E15D3EEandrewdolganowalcatellucentcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Robert,

You assume that Bier cannot localize this, I personally think there is a wa=
y to make sure that as receivers come and go, we do not need to flood this =
in IGP for BIER =96 especially in MVPN case.

Andrew

On 2014-09-26, 1:16 PM, "Robert Raszuk" wrote:


Aren't we worried about impact of joins to the controller followed by churn=
 of rewrite changes on ingress router ?

Worst case is single receivers behind egress router joining and leaving .. =
or a lot of them.

In traditional multicast joining the tree is sort of local .. in BIER entir=
e control plane is impacted.

At min perhaps the draft should introduce stability timers which would effe=
ctively continue to forward given set of groups to the egress routers even =
if receivers behind them leaves.

I realize that with BGP multicast procedures we have already stepped out of=
 multicast native behavior, however BGP has number of build in mechanisms t=
o well deal with churn. Is the assumption here that the associated signalli=
ng of BIER will be BGP based ?

Rgs,
r.

--_000_D04B20E15D3EEandrewdolganowalcatellucentcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <3BF3C199AD52F84B97FB767010B5A9A9@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable







Robert,







You assume that Bier cannot localize this, I personally think there is=
 a way to make sure that as receivers come and go, we do not need to flood =
this in IGP for BIER =96 especially in MVPN case.







Andrew










On 2014-09-26, 1:16 PM, "Robert Raszuk" wrote:
























Aren't we worried about impact of joins to the=
 controller followed by churn of rewrite changes on ingress router ? <=
/div>






Worst case is single receivers behind egress r=
outer joining and leaving .. or a lot of them. 







In traditional multicast joining the tree is s=
ort of local .. in BIER entire control plane is impacted. 







At min perhaps the draft should introduce stab=
ility timers which would effectively continue to forward given set of group=
s to the egress routers even if receivers behind them leaves.







I realize that with BGP multicast procedures w=
e have already stepped out of multicast native behavior, however BGP has nu=
mber of build in mechanisms to well deal with churn. Is the assumption here=
 that the associated signalling of
 BIER will be BGP based ? 







Rgs,


r.















--_000_D04B20E15D3EEandrewdolganowalcatellucentcom_--


From nobody Fri Sep 26 11:49:42 2014
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 B979E1A0024 for ; Fri, 26 Sep 2014 11:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 DvUqadnQEQRR for ; Fri, 26 Sep 2014 11:49:40 -0700 (PDT)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CBB71A02CF for ; Fri, 26 Sep 2014 11:49:39 -0700 (PDT)
Received: by mail-ig0-f179.google.com with SMTP id l13so70249iga.12 for ; Fri, 26 Sep 2014 11:49:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bWMQGD4OI4j5Oi/SmO3do6Cged29Sw4jFHXzZKHQMLk=; b=QEyiou/xT3TXbFBUEs6VB8vhff2Cji1c1A7rtZL9nng9YPwOVh0wMeP0td1zC6vmVV /nPTHTslOMCElWV8u8kaWGwFhhOad4BJmN6EojpeX614GKdms+auqBS9neYR9BDCxYAm dMoOSYM6zIu2aob1l6+V0XsF/IAKwSQ57YIB78GxFOAQsCLuBB0saAuABtrHn3bTeVXp DT3u7eVB1s3YXYxzxvLYJQOyiDTM2WC7CWEek2kXDqyHqgTjdxWnJPdiezn3qxSfCC0L eUT53W+RJTOEwovfQBLr0I/Vawc5QLsncG6ans20G5jBfJZq8BS31JXZh1w1qPMJ0mGU XQBw==
MIME-Version: 1.0
X-Received: by 10.42.46.81 with SMTP id j17mr26323534icf.54.1411757378714; Fri, 26 Sep 2014 11:49:38 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.166.8 with HTTP; Fri, 26 Sep 2014 11:49:38 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 26 Sep 2014 20:49:38 +0200
X-Google-Sender-Auth: yU2dVeZo8aUs9lTxZyoXAOPVaCg
Message-ID: 
From: Robert Raszuk 
To: "Dolganow, Andrew (Andrew)" 
Content-Type: multipart/alternative; boundary=20cf30223cdf115d4c0503fc61f1
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/AS0NB5luxMPJjFtlxi6apxgGGUM
Cc: "erosen@cisco.com" , "bier@ietf.org" , IJsbrand Wijnands 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 18:49:41 -0000

--20cf30223cdf115d4c0503fc61f1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As far as I understand it no one is targeting use of IGP for signalling of
join requests in BIER overlay. But I am very novice to BIER so may be
missing something :)

My question was specific to whatever signalling is used other then IGP as
well as amount of state transition on ingress specifically number of data
plane rewrite headers changes per sec/min in the worst case scenario.

best,
r.






On Fri, Sep 26, 2014 at 7:58 PM, Dolganow, Andrew (Andrew) <
andrew.dolganow@alcatel-lucent.com> wrote:

>  Robert,
>
>  You assume that Bier cannot localize this, I personally think there is a
> way to make sure that as receivers come and go, we do not need to flood
> this in IGP for BIER =E2=80=93 especially in MVPN case.
>
>  Andrew
>
>   On 2014-09-26, 1:16 PM, "Robert Raszuk" wrote:
>
>
>  Aren't we worried about impact of joins to the controller followed by
> churn of rewrite changes on ingress router ?
>
>  Worst case is single receivers behind egress router joining and leaving
> .. or a lot of them.
>
>  In traditional multicast joining the tree is sort of local .. in BIER
> entire control plane is impacted.
>
>  At min perhaps the draft should introduce stability timers which would
> effectively continue to forward given set of groups to the egress routers
> even if receivers behind them leaves.
>
>  I realize that with BGP multicast procedures we have already stepped out
> of multicast native behavior, however BGP has number of build in mechanis=
ms
> to well deal with churn. Is the assumption here that the associated
> signalling of BIER will be BGP based ?
>
>  Rgs,
> r.
>
>

--20cf30223cdf115d4c0503fc61f1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



As far as I understa=
nd it no one is targeting use of IGP for signalling of join requests in BIE=
R overlay. But I am very novice to BIER so may be missing something :)=C2=
=A0

My question was specific to =
whatever signalling is used other then IGP as well as amount of state trans=
ition on ingress specifically number of data plane rewrite headers changes =
per sec/min in the worst case scenario.

best,
r.






=
On Fri, Sep 26, 2014 at 7:58 PM, Dolganow, Andrew (Andrew) <andrew.dolganow@alcatel-lucent.com> wrote:







Robert,







You assume that Bier cannot localize this, I personally think there is=
 a way to make sure that as receivers come and go, we do not need to flood =
this in IGP for BIER =E2=80=93 especially in MVPN case.







Andrew










On 2014-09-26, 1:16 PM, "Robert Raszuk" wrote:
























Aren't we worried about impact of joins to=
 the controller followed by churn of rewrite changes on ingress router ?=C2=
=A0







Worst case is single receivers behind egress r=
outer joining and leaving .. or a lot of them.=C2=A0







In traditional multicast joining the tree is s=
ort of local .. in BIER entire control plane is impacted.=C2=A0







At min perhaps the draft should introduce stab=
ility timers which would effectively continue to forward given set of group=
s to the egress routers even if receivers behind them leaves.







I realize that with BGP multicast procedures w=
e have already stepped out of multicast native behavior, however BGP has nu=
mber of build in mechanisms to well deal with churn. Is the assumption here=
 that the associated signalling of
 BIER will be BGP based ?=C2=A0







Rgs,


r.



















--20cf30223cdf115d4c0503fc61f1--


From nobody Fri Sep 26 11:55:49 2014
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 7C8D41A1B4D for ; Fri, 26 Sep 2014 11:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 U-O7KX4XMQbn for ; Fri, 26 Sep 2014 11:55:45 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B891A3B9F for ; Fri, 26 Sep 2014 11:55:27 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id lx4so586091iec.32 for ; Fri, 26 Sep 2014 11:55:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=E2DsdDAQMyT2AkZTFgbvPUZ7KzOTdfsTW0hNAugUSgQ=; b=xE5YaEM8qHUdSWVdVo7Gyz0jPs/lx+RfxCybufjAgo4wzueR2uR2dOMCyV7wFpTxTz zD98GV4gPCIwApRocQIC1WvBqSvvd0MWGLELBFBMzx2LRp99mpLu3X9zMmURcyWc/D5a mWY7jAAB8hChK4J3VHRvhwocGEEuWODxb/uzqGQoPGEnAdPog9R5JqlNO/+eVOu/6ghU m7preqkc58ldIiOFhrBVEdMCCPBT3mucOzDg1b5sgVd+xemju0srntQ3EPeQixYm2E77 sHoM5fSfjJV+MPn6Rp0XGGHNgR5LALIKZfQM7fOvsMS2chlpVjycdqZbzgWLxG/NJHPs PsZA==
MIME-Version: 1.0
X-Received: by 10.50.79.201 with SMTP id l9mr16018839igx.17.1411757726726; Fri, 26 Sep 2014 11:55:26 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.166.8 with HTTP; Fri, 26 Sep 2014 11:55:26 -0700 (PDT)
In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>
Date: Fri, 26 Sep 2014 20:55:26 +0200
X-Google-Sender-Auth: xWbbaHDaMV5OMp9InmQsMvmFi1g
Message-ID: 
From: Robert Raszuk 
To: Antoni Przygienda 
Content-Type: multipart/alternative; boundary=089e013cbb8acf83a90503fc754e
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/QIwTXrdF99Kv19WxquhWkrzURz0
Cc: "Eric Rosen \(erosen\)" , "bier@ietf.org" , "IJsbrand Wijnands \(iwijnand\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 18:55:47 -0000

--089e013cbb8acf83a90503fc754e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Tony,

Many thx for the explanation. When I first read the doc I understood it
precisely as you state it below.

But then BIER to me is a special case of SPRING and therefor I find it odd
to have a BOF and define yet one more separate data plane ...

Also I think without control plane example (of say IP multicast) BIER alone
will be hard to progress forward. Each new proposal as far as I see these
days in IETF needs some for of its rationale for existence example :)

So you are correct - my point was not about BIER as DMF, but as specific
example of running IP multicast on top of this. Is this a wrong list to ask
such questions if so I apologies, but Ice recommended I share previously
sent offline question to him to this list.

Cheers,
R.


On Fri, Sep 26, 2014 at 7:39 PM, Antoni Przygienda <
antoni.przygienda@ericsson.com> wrote:

>  Not sure this is a discussion about BIER multicast overlay or BIER layer
> (look @ arch). For the multicast overlay the discussion makes sense but
> it=E2=80=99s kind of orthogonal to BIER itself.
>
>
>
> A BIER layer is in a sense a =E2=80=98distributed multicast fabric=E2=80=
=99 only, it
> couldn=E2=80=99t care whether it even runs IP multicast and people join/l=
eave, it=E2=80=99s
> basically a way to stitch together BFIRs to BFERs and if it carries
> something else than IP multicast on it, no damage done (and possibly lots
> good ;-). In a sense it=E2=80=99s like PMSI being used for other things i=
n IP
> beside IP multicast right now.    So don=E2=80=99t think about it as =E2=
=80=9Coooh, a G
> joins, this needs to join as a BFER=E2=80=9D.  Think about a fabric you c=
an put
> into IP that all of a sudden gives you all-inclusive, selective, bi- or
> unidirectional P-channels in a single shot. If overlay wants to flip BFER=
s
> on/off based on a G joining, well, their choice, if it just keeps all the
> PEs together, it=E2=80=99s another use & the pruning of the BFER receiver=
s for the
> PEs that have the G happens in overlay sending over BIER =E2=80=98fabric=
=E2=80=99.
>
>
>
> The =E2=80=98no tree necessary=E2=80=99 is fibbing a little ;-)  It basic=
ally piggy-backs
> on existing SPF today (while the architecture allows possibly other trees
> in the future to improve the tradeoff of replication vs. avg. path-length
> to deliver a packet).
>
>
>
> --- tony
>
>
>
> *From:* BIER [mailto:bier-bounces@ietf.org] *On Behalf Of *IJsbrand
> Wijnands (iwijnand)
> *Sent:* Friday, September 26, 2014 10:30 AM
> *To:* Robert Raszuk
> *Cc:* Eric Rosen (erosen); bier@ietf.org; IJsbrand Wijnands (iwijnand)
> *Subject:* Re: [Bier] One specific transition churn ...
>
>
>
> Hi Robert,
>
>
>
> Good question.
>
>
>
> As you say, when adding PIM (S,G)/(*,G) join information into BGP we
> already crossed a line there.
>
>
>
> There is already a draft out there to deal with this:
> http://tools.ietf.org/id/draft-morin-multicast-damping-01.txt
>
>
>
> For MVPN, BGP seems like an obvious choice, all the procedures we need ar=
e
> already defined. For other use cases we might as well go with some sort o=
f
> SDN controller approach. The attractive proposition of BIER is that the
> controller only needs to connect to the Ingress and Egress routers. It do=
es
> not need to connect to the core routers because there is no tree to build
> :-) This is the beauty of the stateless approach!
>
>
>
> Thx,
>
>
>
> Ice.
>
> Sent from my iPad
>
>
> On 26 Sep 2014, at 19:16, "Robert Raszuk"  wrote:
>
>
>
> Aren't we worried about impact of joins to the controller followed by
> churn of rewrite changes on ingress router ?
>
>
>
> Worst case is single receivers behind egress router joining and leaving .=
.
> or a lot of them.
>
>
>
> In traditional multicast joining the tree is sort of local .. in BIER
> entire control plane is impacted.
>
>
>
> At min perhaps the draft should introduce stability timers which would
> effectively continue to forward given set of groups to the egress routers
> even if receivers behind them leaves.
>
>
>
> I realize that with BGP multicast procedures we have already stepped out
> of multicast native behavior, however BGP has number of build in mechanis=
ms
> to well deal with churn. Is the assumption here that the associated
> signalling of BIER will be BGP based ?
>
>
>
> Rgs,
>
> r.
>
>

--089e013cbb8acf83a90503fc754e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Tony,

Many thx for the explanation. When I first read the doc I understood i=
t precisely as you state it below.=C2=A0

But then BIER to me is a special case of SPRING and therefor I fin=
d it odd to have a BOF and define yet one more separate data plane ...=C2=
=A0

Also I think without control=
 plane example (of say IP multicast) BIER alone will be hard to progress fo=
rward. Each new proposal as far as I see these days in IETF needs some for =
of its rationale for existence example :)

So you are correct - my point was not about BIER as DMF, but as s=
pecific example of running IP multicast on top of this. Is this a wrong lis=
t to ask such questions if so I apologies, but Ice recommended I share prev=
iously sent offline question to him to this list.

Cheers,
R.


On Fri, S=
ep 26, 2014 at 7:39 PM, Antoni Przygienda <antoni.przygienda@=
ericsson.com> wrote:











Not sure this is a discussion about BIER multicast overlay =
or BIER layer (look @ arch). For the multicast overlay
 the discussion makes sense but it=E2=80=99s kind of orthogonal to BIER its=
elf. 


=C2=A0


A BIER layer is in a sense a =E2=80=98distributed multicast=
 fabric=E2=80=99 only, it couldn=E2=80=99t care whether it even runs IP mul=
ticast
 and people join/leave, it=E2=80=99s basically a way to stitch together BFI=
Rs to BFERs and if it carries something else than IP multicast on it, no da=
mage done (and possibly lots good ;-). In a sense it=E2=80=99s like PMSI be=
ing used for other things in IP beside IP multicast
 right now. =C2=A0=C2=A0=C2=A0So don=E2=80=99t think about it as =E2=80=9Co=
ooh, a G joins, this needs to join as a BFER=E2=80=9D.=C2=A0 Think about a =
fabric you can put into IP that all of a sudden gives you all-inclusive, se=
lective, bi- or unidirectional P-channels in a single shot. If overlay want=
s
 to flip BFERs on/off based on a G joining, well, their choice, if it just =
keeps all the PEs together, it=E2=80=99s another use & the pruning of t=
he BFER receivers for the PEs that have the G happens in overlay sending ov=
er BIER =E2=80=98fabric=E2=80=99.



=C2=A0


The =E2=80=98no tree necessary=E2=80=99 is fibbing a little=
 ;-)=C2=A0 It basically piggy-backs on existing SPF today (while the archit=
ecture
 allows possibly other trees in the future to improve the tradeoff of repli=
cation vs. avg. path-length to deliver a packet).



=C2=A0


--- tony



=C2=A0








 BIER
 [mailto:bier-bo=
unces@ietf.org] On Behalf Of 
IJsbrand Wijnands (iwijnand)

Sent: Friday, September 26, =
2014 10:30 AM

To: Robert Raszuk

Cc: Eric Rosen (erosen); bier@ietf.org; IJsbrand=
 Wijnands (iwijnand)

Subject: Re: [Bier] One spec=
ific transition churn ...






=C2=A0




Hi Robert,






=C2=A0






Good question.






=C2=A0






As you say, when adding PIM (S,G)/(*,G) join informa=
tion into BGP we already crossed a line there.=C2=A0






=C2=A0






There is already a draft out there to deal with this=
:=C2=A0http://tools.ietf.org/id/draft-morin-multicast-damp=
ing-01.txt






=C2=A0






For MVPN, BGP seems like an obvious choice, all the =
procedures we need are already defined. For other use cases we might as wel=
l go with some sort of SDN controller approach.
 The attractive proposition of BIER is that the controller only needs to co=
nnect to the Ingress and Egress routers. It does not need to connect to the=
 core routers because there is no tree to build :-) This is the beauty of t=
he stateless approach!






=C2=A0






Thx,






=C2=A0






Ice.



Sent from my iPad








On 26 Sep 2014, at 19:16, "Robert Raszuk" <robert@raszuk.net> wrote:=















=C2=A0=







Aren't we worrie=
d about impact of joins to the controller followed by churn of rewrite chan=
ges on ingress router ?=C2=A0






=C2=A0=







Worst case is single=
 receivers behind egress router joining and leaving .. or a lot of them.=C2=
=A0






=C2=A0=







In traditional multi=
cast joining the tree is sort of local .. in BIER entire control plane is i=
mpacted.=C2=A0






=C2=A0=







At min perhaps the d=
raft should introduce stability timers which would effectively continue to =
forward given set of groups to the egress routers
 even if receivers behind them leaves.






=C2=A0=







I realize that with =
BGP multicast procedures we have already stepped out of multicast native be=
havior, however BGP has number of build in mechanisms
 to well deal with churn. Is the assumption here that the associated signal=
ling of BIER will be BGP based ?=C2=A0






=C2=A0=







Rgs,






r.






















--089e013cbb8acf83a90503fc754e--


From nobody Fri Sep 26 13:21:44 2014
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 023B61A6FF9 for ; Fri, 26 Sep 2014 13:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 OLbO6AOrPNBO for ; Fri, 26 Sep 2014 13:21:34 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A121A6FF6 for ; Fri, 26 Sep 2014 13:21:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10917; q=dns/txt; s=iport; t=1411762892; x=1412972492; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DrUReMaX1/q0rIq8y5ZnNIOjmGS+q7Z6yQFo7XVd56Q=; b=BVqiNS1r3ywrhLqWvhGjlRSo1j5usizQODVP24W8pOdFjGrBLzVbkTGB aNMMALy5udoQWQdwaDilgsNgK0y25eERjwe/kz38aitOxv/w0brptmDXT eBCuQuNIhfsgxwyxJTNx/rBFN165Sbmd7wYa/2lHv9U84w03/04Ui9E/f 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAL3JJVStJA2D/2dsb2JhbABfgkhGU1fKQAEJh04CgQ0WAXuEBAEBBAEBAWsLEAIBCD8HJwsUEQIEDgWIPg2/IAETBJAaBAeDLoEdBY8pgjqLQ5Vcg2NsgkoBAQE
X-IronPort-AV: E=Sophos; i="5.04,606,1406592000"; d="scan'208,217"; a="81673975"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP; 26 Sep 2014 20:21:31 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8QKLUGt001004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 20:21:30 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.218]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 15:21:30 -0500
From: "Rajiv Asati (rajiva)" 
To: Robert Raszuk 
Thread-Topic: [Bier] One specific transition churn ...
Thread-Index: AQHP2a2mMpvy06CkhEmqaEZSK8nOvJwUB08AgAAOZgD//8XZEQ==
Date: Fri, 26 Sep 2014 20:21:29 +0000
Message-ID: <8CBD33C4-DD8A-4FBE-B08A-94A4EA1B7E11@cisco.com>
References:  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_8CBD33C4DD8A4FBEB08A94A4EA1B7E11ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/8MPwry_YepxLtc_vmzjSeb9P6gA
Cc: "bier@ietf.org" , "Eric Rosen \(erosen\)" , "Dolganow, Andrew \(Andrew\)" , "IJsbrand Wijnands \(iwijnand\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 20:21:37 -0000

--_000_8CBD33C4DD8A4FBEB08A94A4EA1B7E11ciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Robert,

Please see inline,

My question was specific to whatever signalling is used other then IGP as w=
ell as amount of state transition on ingress specifically number of data pl=
ane rewrite headers changes per sec/min in the worst case scenario.

Zero impact on ingress node if membership (for whatever number of S,Gs) on =
any egress node changes from 1000 to 1 or 1 to 500 or whatever number, ever=
y time interval (second, say).

This is because the bit (in bier header) is set per egress node. Another be=
auty of bier. :)

Of course, there is an impact on the ingress node if the membership changes=
 from zero to non-zero number or non-zero to zero on any egress node. The f=
requency of such a change is expected to be on the lower side (depending on=
 the use case*).

But let's say, If there are 1000 egress nodes and each of them experiences =
membership for any of 100 groups going to/from zero every 60 seconds (argua=
bly a rare scenario in use-cases like stock ticker or IPTV) , then there wo=
uld be 1000 rewrite events every 60 seconds on the Ingres node.


As far as I understand it no one is targeting use of IGP for signalling of =
join requests in BIER overlay.

You are right. None so far.


Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services
CITT CTO Office




On Sep 26, 2014, at 2:49 PM, "Robert Raszuk" > wrote:


As far as I understand it no one is targeting use of IGP for signalling of =
join requests in BIER overlay. But I am very novice to BIER so may be missi=
ng something :)

My question was specific to whatever signalling is used other then IGP as w=
ell as amount of state transition on ingress specifically number of data pl=
ane rewrite headers changes per sec/min in the worst case scenario.

best,
r.






On Fri, Sep 26, 2014 at 7:58 PM, Dolganow, Andrew (Andrew) > wrote:
Robert,

You assume that Bier cannot localize this, I personally think there is a wa=
y to make sure that as receivers come and go, we do not need to flood this =
in IGP for BIER =96 especially in MVPN case.

Andrew

On 2014-09-26, 1:16 PM, "Robert Raszuk" wrote:


Aren't we worried about impact of joins to the controller followed by churn=
 of rewrite changes on ingress router ?

Worst case is single receivers behind egress router joining and leaving .. =
or a lot of them.

In traditional multicast joining the tree is sort of local .. in BIER entir=
e control plane is impacted.

At min perhaps the draft should introduce stability timers which would effe=
ctively continue to forward given set of groups to the egress routers even =
if receivers behind them leaves.

I realize that with BGP multicast procedures we have already stepped out of=
 multicast native behavior, however BGP has number of build in mechanisms t=
o well deal with churn. Is the assumption here that the associated signalli=
ng of BIER will be BGP based ?

Rgs,
r.

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier

--_000_8CBD33C4DD8A4FBEB08A94A4EA1B7E11ciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







Hi Robert,







Please see inline,














My question was specific to whatever signalling is used other then IGP as w=
ell as amount of state transition on ingress specifically number of data pl=
ane rewrite headers changes per sec/min in the worst case scenario.











Zero impact on ingress node if membership (for whatever number of S,Gs=
) on any egress node changes from 1000 to 1 or 1 to 500 or whatever number,=
 every time interval (second, say). 







This is because the bit (in bier header) is set per egress node. Anoth=
er beauty of bier. :)







Of course, there is an impact on the ingress node if the membership ch=
anges from zero to non-zero number or non-zero to zero on any egress node. =
The frequency of such a change is expected to be on the lower side (dependi=
ng on the use case*).  







But let's say, If there are 1000 egress nodes and each of them experie=
nces membership for any of 100 groups going to/from zero every 60 seconds (=
arguably a rare scenario in use-cases like stock ticker or IPTV) , then the=
re would be 1000 rewrite events
 every 60 seconds on the Ingres node. 

















As far as I understand it no one is targeting use of IGP for signalling of =
join requests in BIER overlay.










You are right. None so far. 





Cheers,

Rajiv Asati





Distinguished Engineer, Cisco Services



CITT CTO Office























On Sep 26, 2014, at 2:49 PM, "Robert Raszuk" <robert@raszuk.net> wrote:



















As far as I understand it no one is targeting use of IGP for signalling of =
join requests in BIER overlay. But I am very novice to BIER so may be missi=
ng something :) 









My question was specific to whatever signalling is used other then IGP as w=
ell as amount of state transition on ingress specifically number of data pl=
ane rewrite headers changes per sec/min in the worst case scenario.









best,



r.





































On Fri, Sep 26, 2014 at 7:58 PM, Dolganow, Andre=
w (Andrew)
<andrew.dolganow@alcatel-lucent.com> wrote:=







Robert,







You assume that Bier cannot localize this, I personally think there is=
 a way to make sure that as receivers come and go, we do not need to flood =
this in IGP for BIER =96 especially in MVPN case.








Andrew















On 2014-09-26, 1:16 PM, "Robert Raszuk" wrote:
























Aren't we worried about impact of joins to the=
 controller followed by churn of rewrite changes on ingress router ? <=
/div>






Worst case is single receivers behind egress r=
outer joining and leaving .. or a lot of them. 







In traditional multicast joining the tree is s=
ort of local .. in BIER entire control plane is impacted. 







At min perhaps the draft should introduce stab=
ility timers which would effectively continue to forward given set of group=
s to the egress routers even if receivers behind them leaves.







I realize that with BGP multicast procedures w=
e have already stepped out of multicast native behavior, however BGP has nu=
mber of build in mechanisms to well deal with churn. Is the assumption here=
 that the associated signalling of
 BIER will be BGP based ? 







Rgs,


r.
































_______________________________________________

BIER mailing list

BIER@ietf.org

https://www.ie=
tf.org/mailman/listinfo/bier








--_000_8CBD33C4DD8A4FBEB08A94A4EA1B7E11ciscocom_--


From nobody Fri Sep 26 13:25:31 2014
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 3DF971A0243 for ; Fri, 26 Sep 2014 13:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 UfJF9ltIyOSe for ; Fri, 26 Sep 2014 13:25:27 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA8C1A7006 for ; Fri, 26 Sep 2014 13:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17794; q=dns/txt; s=iport; t=1411763127; x=1412972727; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yHpDYYaRWodgE4kS6AtzuV48E0y7pkcwoH79wtoyMww=; b=PWfBynIA1jrIzuVIgON4AC1UIu7DqFw9NVe8SJDBx8c+3+Y2LUik5k0O wn9epibvV1/kZanEy6Br+UIeEwrV1BNjdujuq/pbGeAi7pGjpVJkPt8mh MVS6MzvdJYoyfwsP/7xjAJ/+hYmOQ6CK1lKCuGJ8LcXTE1YL1B+v5i+lA U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkgLAILKJVStJV2Z/2dsb2JhbABfgkhGU1e2NwwBAQEBAQEFAXIBHZB+gW2HTgKBDRYBe4QDAQEBBGcSEAIBCBEBAwEBKAcyFAMGCAIEDgWIPg2/HgEXhhKKDAYBgy6BHQWPS4IYhDqHCYFik3qDY2wBgkkBAQE
X-IronPort-AV: E=Sophos;i="5.04,606,1406592000";  d="scan'208,217";a="358572957"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 26 Sep 2014 20:25:26 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8QKPQCp026696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 20:25:26 GMT
Received: from xmb-aln-x14.cisco.com ([169.254.8.91]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 15:25:26 -0500
From: "IJsbrand Wijnands (iwijnand)" 
To: Robert Raszuk 
Thread-Topic: One specific transition churn ...
Thread-Index: AQHP2a2jJqr094SnM0OiywpFFkGKdZwTq5ZOgABWjgCAABUwAP//xVNx
Date: Fri, 26 Sep 2014 20:25:25 +0000
Message-ID: 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_DA5C56DD22F54E0CA7BA103E84749D69ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/7T_ecL48RNsND_7pKNvzwkBBEWo
Cc: "bier@ietf.org" , "Eric Rosen \(erosen\)" , Antoni Przygienda , "IJsbrand Wijnands \(iwijnand\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 20:25:30 -0000

--_000_DA5C56DD22F54E0CA7BA103E84749D69ciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Robert,

But then BIER to me is a special case of SPRING and therefor I find it odd =
to have a BOF and define yet one more separate data plane ...

BIER is totally unrelated to SPRING, completely different data-plane!

So you are correct - my point was not about BIER as DMF, but as specific ex=
ample of running IP multicast on top of this. Is this a wrong list to ask s=
uch questions if so I apologies, but Ice recommended I share previously sen=
t offline question to him to this list.

This is a good question to ask on this list because BIER requires explicit =
tracking of the receivers, so, good question :-)

Thx

Ice.



Cheers,
R.


On Fri, Sep 26, 2014 at 7:39 PM, Antoni Przygienda > wrote:
Not sure this is a discussion about BIER multicast overlay or BIER layer (l=
ook @ arch). For the multicast overlay the discussion makes sense but it=92=
s kind of orthogonal to BIER itself.

A BIER layer is in a sense a =91distributed multicast fabric=92 only, it co=
uldn=92t care whether it even runs IP multicast and people join/leave, it=
=92s basically a way to stitch together BFIRs to BFERs and if it carries so=
mething else than IP multicast on it, no damage done (and possibly lots goo=
d ;-). In a sense it=92s like PMSI being used for other things in IP beside=
 IP multicast right now.    So don=92t think about it as =93oooh, a G joins=
, this needs to join as a BFER=94.  Think about a fabric you can put into I=
P that all of a sudden gives you all-inclusive, selective, bi- or unidirect=
ional P-channels in a single shot. If overlay wants to flip BFERs on/off ba=
sed on a G joining, well, their choice, if it just keeps all the PEs togeth=
er, it=92s another use & the pruning of the BFER receivers for the PEs that=
 have the G happens in overlay sending over BIER =91fabric=92.

The =91no tree necessary=92 is fibbing a little ;-)  It basically piggy-bac=
ks on existing SPF today (while the architecture allows possibly other tree=
s in the future to improve the tradeoff of replication vs. avg. path-length=
 to deliver a packet).

--- tony

From: BIER [mailto:bier-bounces@ietf.org] On =
Behalf Of IJsbrand Wijnands (iwijnand)
Sent: Friday, September 26, 2014 10:30 AM
To: Robert Raszuk
Cc: Eric Rosen (erosen); bier@ietf.org; IJsbrand Wijn=
ands (iwijnand)
Subject: Re: [Bier] One specific transition churn ...

Hi Robert,

Good question.

As you say, when adding PIM (S,G)/(*,G) join information into BGP we alread=
y crossed a line there.

There is already a draft out there to deal with this: http://tools.ietf.org=
/id/draft-morin-multicast-damping-01.txt

For MVPN, BGP seems like an obvious choice, all the procedures we need are =
already defined. For other use cases we might as well go with some sort of =
SDN controller approach. The attractive proposition of BIER is that the con=
troller only needs to connect to the Ingress and Egress routers. It does no=
t need to connect to the core routers because there is no tree to build :-)=
 This is the beauty of the stateless approach!

Thx,

Ice.

Sent from my iPad

On 26 Sep 2014, at 19:16, "Robert Raszuk" > wrote:

Aren't we worried about impact of joins to the controller followed by churn=
 of rewrite changes on ingress router ?

Worst case is single receivers behind egress router joining and leaving .. =
or a lot of them.

In traditional multicast joining the tree is sort of local .. in BIER entir=
e control plane is impacted.

At min perhaps the draft should introduce stability timers which would effe=
ctively continue to forward given set of groups to the egress routers even =
if receivers behind them leaves.

I realize that with BGP multicast procedures we have already stepped out of=
 multicast native behavior, however BGP has number of build in mechanisms t=
o well deal with churn. Is the assumption here that the associated signalli=
ng of BIER will be BGP based ?

Rgs,
r.


--_000_DA5C56DD22F54E0CA7BA103E84749D69ciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







Hi Robert,











But then BIER to me is a special case of SPRING and therefor I find it odd =
to have a BOF and define yet one more separate data plane ... 











BIER is totally unrelated to SPRING, completely different data-plane!<=
/div>








So you are correct - my point was not about BIER as DMF, but as specific ex=
ample of running IP multicast on top of this. Is this a wrong list to ask s=
uch questions if so I apologies, but Ice recommended I share previously sen=
t offline question to him to this
 list.











This is a good question to ask on this list because BIER requires expl=
icit tracking of the receivers, so, good question :-)







Thx







Ice.




















Cheers,



R.













On Fri, Sep 26, 2014 at 7:39 PM, Antoni Przygien=
da 
<ant=
oni.przygienda@ericsson.com> wrote:








Not sure this is a discussion about BIER multicast overlay =
or BIER layer (look @ arch). For the multicast overlay the discussion
 makes sense but it=92s kind of orthogonal to BIER itself. 


 


A BIER layer is in a sense a =91distributed multicast fabri=
c=92 only, it couldn=92t care whether it even runs IP multicast and
 people join/leave, it=92s basically a way to stitch together BFIRs to BFER=
s and if it carries something else than IP multicast on it, no damage done =
(and possibly lots good ;-). In a sense it=92s like PMSI being used for oth=
er things in IP beside IP multicast
 right now.    So don=92t think about it as =93oooh, a G joi=
ns, this needs to join as a BFER=94.  Think about a fabric you can put=
 into IP that all of a sudden gives you all-inclusive, selective, bi- or un=
idirectional P-channels in a single shot. If overlay wants
 to flip BFERs on/off based on a G joining, well, their choice, if it just =
keeps all the PEs together, it=92s another use & the pruning of the BFE=
R receivers for the PEs that have the G happens in overlay sending over BIE=
R =91fabric=92.



 


The =91no tree necessary=92 is fibbing a little ;-)  I=
t basically piggy-backs on existing SPF today (while the architecture
 allows possibly other trees in the future to improve the tradeoff of repli=
cation vs. avg. path-length to deliver a packet).



 


--- tony



 








 BIER [mailto:bier-bounces@ietf.=
org]
On Behalf Of IJsbrand Wijnan=
ds (iwijnand)

Sent: Friday, September 26, =
2014 10:30 AM

To: Robert Raszuk

Cc: Eric Rosen (erosen); 
bier@ietf.org; IJsbrand Wijnands (iwijnand)

Subject: Re: [Bier] One spec=
ific transition churn ...










 




Hi Robert,






 






Good question.






 






As you say, when adding PIM (S,G)/(*,G) join informa=
tion into BGP we already crossed a line there. 






 






There is already a draft out there to deal with this=
: http://tools.ietf.org/id/draft-morin-multicast-damp=
ing-01.txt






 






For MVPN, BGP seems like an obvious choice, all the =
procedures we need are already defined. For other use cases we might as wel=
l go with some sort of SDN controller approach.
 The attractive proposition of BIER is that the controller only needs to co=
nnect to the Ingress and Egress routers. It does not need to connect to the=
 core routers because there is no tree to build :-) This is the beauty of t=
he stateless approach!






 






Thx,






 






Ice.



Sent from my iPad








On 26 Sep 2014, at 19:16, "Robert Raszuk" <robert@raszuk.net> wrote:=















 =







Aren't we worried ab=
out impact of joins to the controller followed by churn of rewrite changes =
on ingress router ? 






 =







Worst case is single=
 receivers behind egress router joining and leaving .. or a lot of them.&nb=
sp;






 =







In traditional multi=
cast joining the tree is sort of local .. in BIER entire control plane is i=
mpacted. 






 =







At min perhaps the d=
raft should introduce stability timers which would effectively continue to =
forward given set of groups to the egress routers
 even if receivers behind them leaves.






 =







I realize that with =
BGP multicast procedures we have already stepped out of multicast native be=
havior, however BGP has number of build in mechanisms
 to well deal with churn. Is the assumption here that the associated signal=
ling of BIER will be BGP based ? 






 =







Rgs,






r.


































--_000_DA5C56DD22F54E0CA7BA103E84749D69ciscocom_--


From nobody Fri Sep 26 14:01:06 2014
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 9C2EB1A0243 for ; Fri, 26 Sep 2014 14:01:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 SLJ3XNanVjZ5 for ; Fri, 26 Sep 2014 14:01:02 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0063F1A034A for ; Fri, 26 Sep 2014 14:01:01 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id rp18so14635959iec.3 for ; Fri, 26 Sep 2014 14:01:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CiqPLOTPMAEt22SeWEyUX32La76ivfv4rtQxE/UEuR8=; b=HScpbC/F0mcBcKntIpPRpz1PdU5h2Cy1Dq5UaBf1FzVoeeq1G0svWcrd9n4OpDHo6c Y19I7U0AFu260gN72BKWufFlULzjyQXlzZK+FxnDnBGu1hLkEmsM1FuHBRh0++ib23vT Avmt5UjaHSqErBqukyE1ZLHzlaxUCCNl413amtEFXmz5ObzGJk4+sC+PQfHCBaxFHoaZ e1CJUQGZHEPgJDvI53zK0iwcuTUTByzrzquVYJBX/VQo11rVhPJ+IVMykWjjc1PoDuTO S7DOVJMNz/gUbAA3VLJYWlfyGs14mQtOpHPRLc28k+W/b6lEe4cVL+djas14pfuflJ6B 07+g==
MIME-Version: 1.0
X-Received: by 10.43.0.133 with SMTP id nm5mr30376882icb.55.1411765261357; Fri, 26 Sep 2014 14:01:01 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.166.8 with HTTP; Fri, 26 Sep 2014 14:01:01 -0700 (PDT)
In-Reply-To: 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>  
Date: Fri, 26 Sep 2014 23:01:01 +0200
X-Google-Sender-Auth: RsLo7YDQDCYSC-wCm97cwANz5e0
Message-ID: 
From: Robert Raszuk 
To: "IJsbrand Wijnands (iwijnand)" 
Content-Type: multipart/alternative; boundary=bcaec50fe063e8d8610503fe367c
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/tTLVVX5qqJ1sP2GmIOcRXnZrzVs
Cc: "bier@ietf.org" , "Eric Rosen \(erosen\)" , Antoni Przygienda 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 21:01:04 -0000

--bcaec50fe063e8d8610503fe367c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> BIER is totally unrelated to SPRING, completely different data-plane!
>

=E2=80=8BPerhaps it is today, but the question is - does it need to be a ye=
t one
more completely new data-plane ?

Take SPRING IPv6 ... why extension header could not list all egress nodes
as well as =E2=80=8B

=E2=80=8Blist of transit BFRs where replication to said egress nodes is to =
take
place ?

Or going step further .. send list of BFRs (like SNs) and program the
required replication out of band (from controller) avoiding carrying
bitstring or network protocols to build a tree to accomplish easy way of
optimal replication ? Is keeping multicast groups such an overkill for even
an average network device these days ?

Last but not least how is said bitstring to be honored, accepted and used
between domains ? What NNI is to be agreed for BIER to make it usable
between AS under different administrations ?

Thx,
r.

--bcaec50fe063e8d8610503fe367c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


BIER is totally unr=
elated to SPRING, completely different data-plane!

=E2=
=80=8BPerhaps it is today, but the question is - does it need to be a yet o=
ne more completely new data-plane ?=C2=A0

Take SPRING IPv6 ... why extension header could not list all egress =
nodes as well as =E2=80=8B
=C2=A0

Or going step =
further .. send list of BFRs (like SNs) and program the required replicatio=
n out of band (from controller) avoiding carrying bitstring or network prot=
ocols to build a tree to accomplish easy way of optimal replication ? Is ke=
eping multicast groups such an overkill for even an average network device =
these days ?

Last but not least how=
 is said bitstring to be honored, accepted and used between domains ? What =
NNI is to be agreed for BIER to make it usable between AS under different a=
dministrations ?

Thx,
r.



--bcaec50fe063e8d8610503fe367c--


From nobody Fri Sep 26 14:22:32 2014
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 3D3871A0326 for ; Fri, 26 Sep 2014 14:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no
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 g9-LyHupawOL for ; Fri, 26 Sep 2014 14:22:28 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 3B8451A037E for ; Fri, 26 Sep 2014 14:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8QLMJed016672 for ; Fri, 26 Sep 2014 23:22:19 +0200 (CEST)
Received: from [192.168.217.145] (p548907CD.dip0.t-ipconnect.de [84.137.7.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CEFF6369; Fri, 26 Sep 2014 23:22:18 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Carsten Bormann 
Date: Fri, 26 Sep 2014 23:22:15 +0200
X-Mao-Original-Outgoing-Id: 433459334.450171-1337073d9f6270bd0bfa41ec0481a04b
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A1DB1CC-25C8-40B9-9419-4947B1AB2C66@tzi.org>
To: "bier@ietf.org" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/DHtfWQ2aAVRjEBE4A7P-1mGg0BQ
Subject: [Bier] (It's Friday, SCNR)
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, 26 Sep 2014 21:22:30 -0000

http://en.wikipedia.org/wiki/Es_gibt_kein_Bier_auf_Hawaii

Hmm, doesn=92t look good for this BOF at IETF91.

Gr=FC=DFe, Carsten

(Yes, I do plan to make meaningful contributions later.)



From nobody Fri Sep 26 14:32:00 2014
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 986001A0369 for ; Fri, 26 Sep 2014 14:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no
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 T5fCxkjCild2 for ; Fri, 26 Sep 2014 14:31:58 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 AB5D21A0330 for ; Fri, 26 Sep 2014 14:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s8QLVqbY007683; Fri, 26 Sep 2014 23:31:52 +0200 (CEST)
Received: from [192.168.217.145] (p548907CD.dip0.t-ipconnect.de [84.137.7.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 07C1E36B; Fri, 26 Sep 2014 23:31:50 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Carsten Bormann 
In-Reply-To: 
Date: Fri, 26 Sep 2014 23:31:47 +0200
X-Mao-Original-Outgoing-Id: 433459907.796706-0330fb044a58e799cdd96e0ba5d67eca
Content-Transfer-Encoding: quoted-printable
Message-Id: <2ECFE722-CA2D-49B9-8842-5E4003BF2717@tzi.org>
References: 
To: Robert Raszuk 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/mECeiU1iiIzFMfTpOSOjbkbTvyY
Cc: "erosen@cisco.com" , bier@ietf.org, IJsbrand Wijnands 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 21:31:58 -0000

On 26 Sep 2014, at 19:16, Robert Raszuk  wrote:

> Worst case is single receivers behind egress router joining and =
leaving .. or a lot of them.=20

What is the expectation of accuracy here?

If a receiver leaves, the BFER will stop forwarding to that.
How bad is it that the BFER still receives a copy of the packet from the =
BFIR?

(And conversely, what are the join latencies expected here?)

Gr=FC=DFe, Carsten


From nobody Fri Sep 26 14:37:45 2014
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 200AA1A0384 for ; Fri, 26 Sep 2014 14:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 OA4vkRuIVzN2 for ; Fri, 26 Sep 2014 14:37:44 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189EF1A0381 for ; Fri, 26 Sep 2014 14:37:44 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id x19so16530112ier.36 for ; Fri, 26 Sep 2014 14:37:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6CmGFDKR6skn8nOI2/NBfqa9eUh5e881XqsBsKCSgRc=; b=rVvoLt65WNNfn9hfAaRYzSZpZiJn1m8WJN2R9QT3fL20b6If+bj5VVdjZGPmBi7kGn fXgnrGI3PVM/RzBwvXHx9acd2+gVv8b3W8EeNHBAbSrH4joI5t8lw+3gAWVf7/7YhYxx cpmYziqB11PK9lCwvM8+1Nzw+ycQhUEBbyi8BOYU8KzOuJeQCoRUegv2wA/zfTD1Kjej j+k2tedqBk8rm5FPouV+eOD2+McDTts9bf5AYwGoNd32R48X/Qze2Zlb/3Rc1gX5EuV5 EFiKGP1dbSCUslkfB5nuzcxV3cVXAPYkCG2daBIibtlcCNVMnalgXFBLXxIe5ejJX2aL YNoQ==
MIME-Version: 1.0
X-Received: by 10.50.79.132 with SMTP id j4mr17548968igx.9.1411767463497; Fri, 26 Sep 2014 14:37:43 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.166.8 with HTTP; Fri, 26 Sep 2014 14:37:43 -0700 (PDT)
In-Reply-To: <2ECFE722-CA2D-49B9-8842-5E4003BF2717@tzi.org>
References:  <2ECFE722-CA2D-49B9-8842-5E4003BF2717@tzi.org>
Date: Fri, 26 Sep 2014 23:37:43 +0200
X-Google-Sender-Auth: VEldW05zYFAhSdScLsWRedk-SVs
Message-ID: 
From: Robert Raszuk 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=089e01228e0c2ad8b80503febacd
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/vluHdR5j0JIH-5StfRE3QtKvQsk
Cc: "erosen@cisco.com" , "bier@ietf.org" , IJsbrand Wijnands 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 21:37:45 -0000

--089e01228e0c2ad8b80503febacd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Carsten,

> How bad is it that the BFER still receives a
> copy of the packet from the BFIR?

IMHO not bad at all. Hence suggested timer to continue to fwd before
withdraw of the join request by the timer.

Such timer btw can be adaptive to the BFER history.

Cheers,
R.



On Fri, Sep 26, 2014 at 11:31 PM, Carsten Bormann  wrote:

> On 26 Sep 2014, at 19:16, Robert Raszuk  wrote:
>
> > Worst case is single receivers behind egress router joining and leaving
> .. or a lot of them.
>
> What is the expectation of accuracy here?
>
> If a receiver leaves, the BFER will stop forwarding to that.
> How bad is it that the BFER still receives a copy of the packet from the
> BFIR?
>
> (And conversely, what are the join latencies expected here?)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>

--089e01228e0c2ad8b80503febacd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Carsten,

> How bad is it that the BFER still receives a=C2=A0
> copy of the packet from the BFIR?

IMHO =
not bad at all. Hence suggested timer to continue to fwd before withdraw of=
 the join request by the timer.=C2=A0

Such timer b=
tw can be adaptive to the BFER history.

Cheers,R.



On Fri, Sep 26, 2014 at 11:=
31 PM, Carsten Bormann <cabo@tzi.org> wrote:
=
On 26 Sep 2014, at 19:16, Robert Raszuk <robert@raszuk.net> wrote:



> Worst case is single receivers behind egress r=
outer joining and leaving .. or a lot of them.



What is the expectation of accuracy here?



If a receiver leaves, the BFER will stop forwarding to that.

How bad is it that the BFER still receives a copy of the packet from the BF=
IR?



(And conversely, what are the join latencies expected here?)



Gr=C3=BC=C3=9Fe, Carsten







--089e01228e0c2ad8b80503febacd--


From nobody Fri Sep 26 15:55:37 2014
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 9F67C1A1A79 for ; Fri, 26 Sep 2014 15:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 EZkPnDihQ2pd for ; Fri, 26 Sep 2014 15:55:34 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7433E1A016D for ; Fri, 26 Sep 2014 15:55:34 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s8QMtR69012230; Fri, 26 Sep 2014 23:55:27 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s8QMtQ0P012221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Sep 2014 23:55:26 +0100
From: "Adrian Farrel" 
To: 
References: Your message of Fri, 26 Sep 2014 16:11:17 +0100. <051501cfd99c$205b1780$61114680$@olddog.co.uk> <9767.1411750052@erosen-lnx>
In-Reply-To: <9767.1411750052@erosen-lnx>
Date: Fri, 26 Sep 2014 23:55:22 +0100
Message-ID: <065a01cfd9dc$f45f1be0$dd1d53a0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJEQ4owpEnlKLZrSMPhgrZ8vGt/2psrMBwQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20978.003
X-TM-AS-Result: No--9.967-10.0-31-10
X-imss-scan-details: No--9.967-10.0-31-10
X-TMASE-MatchedRID: 9zTThWtzImsDJrf2+hNOhfHkpkyUphL9I6PHNDZGGCIifM7JMNHW6xbf J7EPe6QEbdqXh5h5YmbQDyeNlOoPni0kxsNYPyneTVa+L3Zgqc5Cs7hdHoFFA3oZ5YK74mUQz+m 0nV5FTn3JyxnJ8BruOIJl/jaG2IOv7K35r0y1/56ZroPNdqiG80Crr/LkAQ46RvbmJfuDvy2jxY yRBa/qJX3mXSdV7KK4QiE5bJj38wALbigRnpKlKSPzRlrdFGDwLFKsukeFmPybkTE1ZvI5AAaFN JjMhkzyLRHgWW+PHi4+P6dyzNguJw==
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/w8XaHyP4Kq09hOgHC4egoxwY_nE
Cc: bier@ietf.org
Subject: Re: [Bier] MPLS encapsulation
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 22:55:36 -0000

Sorry Eric,

> 3. Why a special purpose label rather than a control word?
> Since you are already hitting the bottom of stack, wouldn't
> using the control word be more consistent?

Bad choice of words. I was hung up on how he label used is "special" and has
been "specially" designated and advertised. I would have done better to have
been more specific and said "BIER-MPLS" label since that is the term used in
section 2 of the I-D.

My point is that you are advocating the advertisement of a block of labels by
the IGP, and the use of one or more labels on the MPLS stack. And my question:
why do this? You could hit the bottom of stack as normal, use the control word
to identify BIER and put all of the information you need (currently deduced from
the BIER-MPLS label(s) ) into the BIER header.

I'm not saying that would be better. Just asking why the choice you have made.

Cheers,
Adrian

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: 26 September 2014 17:48
> To: adrian@olddog.co.uk
> Cc: bier@ietf.org
> Subject: Re: [Bier] MPLS encapsulation
> 
> Adrian,
> 
> I'm a little confused about your question: are you using the term "special
> purpose label" in the sense of RFC 7274 ("Allocating and Retiring
> Special-Purpose MPLS Labels")?  If so, there is no use of special purpose
> labels (in this sense) being proposed.
> 
> Did I misunderstand your question?
> 
> Eric
> 



From nobody Fri Sep 26 16:31:12 2014
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 5188E1A1A12 for ; Fri, 26 Sep 2014 16:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 PsgU0O8C8lZe for ; Fri, 26 Sep 2014 16:31:09 -0700 (PDT)
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 6805E1A8752 for ; Fri, 26 Sep 2014 16:31:09 -0700 (PDT)
X-AuditID: c618062d-f79206d0000014d2-5f-54259d5ae96f
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 0E.6F.05330.A5D95245; Fri, 26 Sep 2014 19:07:38 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Fri, 26 Sep 2014 19:15:56 -0400
From: Antoni Przygienda 
To: Robert Raszuk 
Thread-Topic: One specific transition churn ...
Thread-Index: AQHP2a+BuVUit1FzlkuzW2MzFDiDwZwTq93QgABarwCAAAMNcA==
Date: Fri, 26 Sep 2014 23:15:56 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181B5D41@eusaamb103.ericsson.se>
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se> 
In-Reply-To: 
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: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F181B5D41eusaamb103ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZXLonXDdqrmqIwbIX0hZLZ+xhslh3dxKL xas5d5gtmhY2MTuweEz5vZHVY8mSn0weuzcuYApgjuKySUnNySxLLdK3S+DKaN43kbHgV0jF lrdT2BsYLwR1MXJySAiYSHz9NoEFwhaTuHBvPRuILSRwlFHifDdnFyMXkL2cUWLG0t+sIAk2 AQuJy9+eMoPYIgKqEp0nHoHZzAL1EkcWrgFrFhbQk9jQ9IgVokZf4u/eL2wQtpPEmYcLmEBs FqDeW783gcV5BbwlPkzfxgaxrIdJ4n3XabChnAKBEqc3tIM1MAJd9/3UGiaIZeISt57MZ4K4 WkBiyZ7zzBC2qMTLx/9YIWwliUlLzwHZHED1+RIn5vpA7BKUODnzCcsERtFZSCbNQqiahaQK IqwpsX6XPkS1osSU7ofsELaGROucuezI4gsY2VcxcpQWp5blphsZbGIExtsxCTbdHYx7Xloe YhTgYFTi4VWIUAkRYk0sK67MPcQozcGiJM47q3ZesJBAemJJanZqakFqUXxRaU5q8SFGJg5O qQbGnYryy3ZV3Vl+J5vLeZV+wax1/7ie6LlxV0+u+XdpSo2x4GPbT8afXWIc+04qnqrZvurz 6fApylE6shMkQnrVNII9YvdLO0R8n60T//PNq63Swg25f7k7PrKXLj+hULCK2326cRWDzZxD O8tPGLrdmnfn349KMyGR4PWiPCsszaTy3qhKvshVYinOSDTUYi4qTgQA+RrqE5gCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/kV6pe1cy-_AHlVutL2Q_AS7ggkw
Cc: "Eric Rosen \(erosen\)" , "bier@ietf.org" , "IJsbrand Wijnands \(iwijnand\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 26 Sep 2014 23:31:11 -0000

--_000_2E4BB27CAB87BF43B4207C0E55860F181B5D41eusaamb103ericsso_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpCdXQgdGhlbiBCSUVSIHRvIG1lIGlzIGEgc3BlY2lhbCBjYXNlIG9mIFNQUklORw0KDQpbVG9u
eSBzYWlkXSAgPz8/ICBMYXN0IEkgY2hlY2tlZCBTUFJJTkcgd2FzIGRlZmluaW5nIGEgdW5pY2Fz
dCBkYXRhcGxhbmUuDQoNCkFsc28gSSB0aGluayB3aXRob3V0IGNvbnRyb2wgcGxhbmUgZXhhbXBs
ZSAob2Ygc2F5IElQIG11bHRpY2FzdCkgQklFUiBhbG9uZSB3aWxsIGJlIGhhcmQgdG8gcHJvZ3Jl
c3MgZm9yd2FyZC4gRWFjaCBuZXcgcHJvcG9zYWwgYXMgZmFyIGFzIEkgc2VlIHRoZXNlIGRheXMg
aW4gSUVURiBuZWVkcyBzb21lIGZvciBvZiBpdHMgcmF0aW9uYWxlIGZvciBleGlzdGVuY2UgZXhh
bXBsZSA6KQ0KDQpbVG9ueSBzYWlkXSAgSSBjb3VsZCBmaWd1cmUgb3V0IGZyb20gRXJpY+KAmXMg
ZHJhZnQgaG93IG1WUE4gaXMgc3VwcG9zZWQgdG8gd29yayBvdmVyIGl0IGFzIGV4YW1wbGUuIEni
gJltIHdvcmtpbmcgb24gYW5vdGhlciBzZXJ2aWNlIGRyYWZ0LiB0aHVzIHNoYWxsIGJlIOKAmG51
ZmYgZXhhbXBsZXMgaW4gc2hvcnQgdGltZS4NCg0KU28geW91IGFyZSBjb3JyZWN0IC0gbXkgcG9p
bnQgd2FzIG5vdCBhYm91dCBCSUVSIGFzIERNRiwgYnV0IGFzIHNwZWNpZmljIGV4YW1wbGUgb2Yg
cnVubmluZyBJUCBtdWx0aWNhc3Qgb24gdG9wIG9mIHRoaXMuIElzIHRoaXMgYSB3cm9uZyBsaXN0
IHRvIGFzayBzdWNoIHF1ZXN0aW9ucyBpZiBzbyBJIGFwb2xvZ2llcywgYnV0IEljZSByZWNvbW1l
bmRlZCBJIHNoYXJlIHByZXZpb3VzbHkgc2VudCBvZmZsaW5lIHF1ZXN0aW9uIHRvIGhpbSB0byB0
aGlzIGxpc3QuDQoNCltUb255IHNhaWRdIG5vLCBhc2tlZCBpbiBtdWx0aWNhc3Qgb3ZlcmxheSBp
dOKAmXMgYSBwZXJmZWN0IHF1ZXN0aW9uLCBpdOKAmXMganVzdCBraW5kIG9mIG9ydGhvZ29uYWwg
dG8gd2hldGhlciB5b3UgcnVuIEJJRVIgbGF5ZXIgSU1PLiBBbnl0aGluZyB0aGF0IGNoYW5nZXMg
Y29yZS1zdGF0ZSBiYXNlZCBvbiBzaW5nbGUgam9pbnMgd2lsbCDigJhzaGFrZSBpdOKAmS4gIFRo
ZSBxdWVzdGlvbiBpcyB3aGF0IGlzIHBlcmNlaXZlZCBhcyDigJhiYWQgc2hha2XigJkuIENvbXB1
dGF0aW9ucyA/IFJlLWFkdmVydGlzaW5nIGluZm9ybWF0aW9uID8NCg0KLS0tIHRvbnkNCg==

--_000_2E4BB27CAB87BF43B4207C0E55860F181B5D41eusaamb103ericsso_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3
RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pjxmb250IHNpemU9IjMiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxmb250IHNpemU9IjMiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QnV0IHRoZW4g
QklFUiB0byBtZSBpcyBhIHNwZWNpYWwgY2FzZSBvZiBTUFJJTkcNCjxvOnA+PC9vOnA+PC9zcGFu
PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48Zm9udCBzaXplPSIyIiBj
b2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0Q7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0eWxlOml0YWxpYyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+PGk+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO2ZvbnQtd2VpZ2h0OmJvbGQ7
Zm9udC1zdHlsZTppdGFsaWMiPltUb255IHNhaWRdICZuYnNwOz8/PyAmbmJzcDtMYXN0IEkgY2hl
Y2tlZCBTUFJJTkcgd2FzIGRlZmluaW5nIGEgdW5pY2FzdCBkYXRhcGxhbmUuDQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz
aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBm
YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFsc28gSSB0aGluayB3aXRob3V0IGNvbnRyb2wg
cGxhbmUgZXhhbXBsZSAob2Ygc2F5IElQIG11bHRpY2FzdCkgQklFUiBhbG9uZSB3aWxsIGJlIGhh
cmQgdG8gcHJvZ3Jlc3MgZm9yd2FyZC4gRWFjaCBuZXcgcHJvcG9zYWwgYXMgZmFyIGFzIEkgc2Vl
IHRoZXNlDQogZGF5cyBpbiBJRVRGIG5lZWRzIHNvbWUgZm9yIG9mIGl0cyByYXRpb25hbGUgZm9y
IGV4aXN0ZW5jZSBleGFtcGxlIDopPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl
PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDtmb250
LXdlaWdodDpib2xkO2ZvbnQtc3R5bGU6aXRhbGljIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L2ZvbnQ+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48Zm9udCBzaXpl
PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0eWxlOml0YWxpYyI+
W1Rvbnkgc2FpZF0gJm5ic3A7SSBjb3VsZCBmaWd1cmUgb3V0IGZyb20gRXJpY+KAmXMgZHJhZnQg
aG93IG1WUE4gaXMgc3VwcG9zZWQNCiB0byB3b3JrIG92ZXIgaXQgYXMgZXhhbXBsZS4gSeKAmW0g
d29ya2luZyBvbiBhbm90aGVyIHNlcnZpY2UgZHJhZnQuIHRodXMgc2hhbGwgYmUg4oCYbnVmZiBl
eGFtcGxlcyBpbiBzaG9ydCB0aW1lLg0KPC9zcGFuPjwvZm9udD48L2k+PC9iPjxmb250IHNpemU9
IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IkNv
dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+U28geW91IGFyZSBjb3JyZWN0IC0gbXkgcG9pbnQgd2FzIG5v
dCBhYm91dCBCSUVSIGFzIERNRiwgYnV0IGFzIHNwZWNpZmljIGV4YW1wbGUgb2YgcnVubmluZyBJ
UCBtdWx0aWNhc3Qgb24gdG9wIG9mIHRoaXMuIElzIHRoaXMgYSB3cm9uZyBsaXN0IHRvDQogYXNr
IHN1Y2ggcXVlc3Rpb25zIGlmIHNvIEkgYXBvbG9naWVzLCBidXQgSWNlIHJlY29tbWVuZGVkIEkg
c2hhcmUgcHJldmlvdXNseSBzZW50IG9mZmxpbmUgcXVlc3Rpb24gdG8gaGltIHRvIHRoaXMgbGlz
dC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i
Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48Zm9udCBzaXplPSIy
IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0Q7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0eWxlOml0YWxpYyI+W1Rv
bnkgc2FpZF0gbm8sIGFza2VkIGluIG11bHRpY2FzdCBvdmVybGF5IGl04oCZcyBhIHBlcmZlY3Qg
cXVlc3Rpb24sIGl04oCZcw0KIGp1c3Qga2luZCBvZiBvcnRob2dvbmFsIHRvIHdoZXRoZXIgeW91
IHJ1biBCSUVSIGxheWVyIElNTy4gQW55dGhpbmcgdGhhdCBjaGFuZ2VzIGNvcmUtc3RhdGUgYmFz
ZWQgb24gc2luZ2xlIGpvaW5zIHdpbGwg4oCYc2hha2UgaXTigJkuICZuYnNwO1RoZSBxdWVzdGlv
biBpcyB3aGF0IGlzIHBlcmNlaXZlZCBhcyDigJhiYWQgc2hha2XigJkuIENvbXB1dGF0aW9ucyA/
IFJlLWFkdmVydGlzaW5nIGluZm9ybWF0aW9uID8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxmb250IHNpemU9IjIiIGNv
bG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3R5bGU6aXRhbGljIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48aT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Zm9udC13ZWlnaHQ6Ym9sZDtm
b250LXN0eWxlOml0YWxpYyI+LS0tIHRvbnkgJm5ic3A7PC9zcGFuPjwvZm9udD48L2k+PC9iPjxm
b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_2E4BB27CAB87BF43B4207C0E55860F181B5D41eusaamb103ericsso_--


From nobody Sat Sep 27 01:09:18 2014
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 ECEE41A1A6B for ; Sat, 27 Sep 2014 01:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 cCyjdenqu8vX for ; Sat, 27 Sep 2014 01:09:15 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B771A1A67 for ; Sat, 27 Sep 2014 01:09:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=461; q=dns/txt; s=iport; t=1411805355; x=1413014955; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=csru/Ha+5YtlY4e2gSFqgQ9zzKtfz6HQb1yA3cLLAUI=; b=X1cGsKJUfB3yX+2hxxZ71lmkR2p2cy0yZ5Sn7lqXpkY2ijKwG2ZIQs7c olt6Th319kF+SNbY9nApFMSpuJhjk+RCOPSLCiVdKf09ixEiGBKYdrQIA 4v8uSd1Pp6fJoSm+aAX3tOuKW1qquPYB1CEDNM189nh+LzwKNO9RobTsK 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiYKAMRvJlStJssW/2dsb2JhbABfg2G2RgUBcpJ/CodOAoEYAXuEBAEBBAEBAWsLBQsLDjgnMAYTG4gjDb8aAReGEooMB4MugR0BBJYdhwmMO4khg2U7L4JKAQEB
X-IronPort-AV: E=Sophos;i="5.04,608,1406592000"; d="scan'208";a="186751807"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 27 Sep 2014 08:09:13 +0000
Received: from ams-iwijnand-8816.cisco.com (ams-iwijnand-8816.cisco.com [10.60.202.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8R897MB014258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Sep 2014 08:09:13 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: IJsbrand Wijnands 
In-Reply-To: <1A1DB1CC-25C8-40B9-9419-4947B1AB2C66@tzi.org>
Date: Sat, 27 Sep 2014 10:09:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1A1DB1CC-25C8-40B9-9419-4947B1AB2C66@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/orLEeNinyloWPyoGm6YW5r-mKiY
Cc: "bier@ietf.org" 
Subject: Re: [Bier] (It's Friday, SCNR)
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, 27 Sep 2014 08:09:17 -0000

Hi Carsten,

How about this solution :-)

http://en.wikipedia.org/wiki/BYOB

Thx,

Ice.


> http://en.wikipedia.org/wiki/Es_gibt_kein_Bier_auf_Hawaii
>=20
> Hmm, doesn=92t look good for this BOF at IETF91.
>=20
> Gr=FC=DFe, Carsten
>=20
> (Yes, I do plan to make meaningful contributions later.)
>=20
>=20
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier


From nobody Sat Sep 27 03:39:28 2014
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 734391A87BD for ; Sat, 27 Sep 2014 03:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 AlWbLc3Dfgp9 for ; Sat, 27 Sep 2014 03:39:24 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB3E1A1AB8 for ; Sat, 27 Sep 2014 03:39:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1835; q=dns/txt; s=iport; t=1411814364; x=1413023964; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0sjF+WX4biBxMq70FLYMNjPqPYSLhQxHEFHDfMmdG00=; b=IiwdxWEj7EkAvZyhNofI4ijO5Fo9X4un5kKHN0kn1uhtNkvq5W4/Nfnt oiBPe8qAqpXdwrQu+V/s5isph8b1xjve23fpRjrruEQcpHyLGpVvv+uCi KMg+9aGhezDnrf2jp2m3WguIioqsPc6MbgjlfF9m5UNQc9nDVGwq2H/hF Y=;
X-IronPort-AV: E=Sophos;i="5.04,609,1406592000"; d="scan'208";a="186815541"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 27 Sep 2014 10:39:23 +0000
Received: from ams-iwijnand-8816.cisco.com (ams-iwijnand-8816.cisco.com [10.60.202.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8RAdKob027699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Sep 2014 10:39:22 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: IJsbrand Wijnands 
In-Reply-To: <065a01cfd9dc$f45f1be0$dd1d53a0$@olddog.co.uk>
Date: Sat, 27 Sep 2014 12:39:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <873A5047-32D7-4AAB-ABE7-FF8C23166C1F@cisco.com>
References: Your message of Fri, 26 Sep 2014 16:11:17 +0100. <051501cfd99c$205b1780$61114680$@olddog.co.uk> <9767.1411750052@erosen-lnx> <065a01cfd9dc$f45f1be0$dd1d53a0$@olddog.co.uk>
To: adrian@olddog.co.uk
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/-KviP4tBSfVRshWieuXL54GamAA
Cc: erosen@cisco.com, bier@ietf.org
Subject: Re: [Bier] MPLS encapsulation
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, 27 Sep 2014 10:39:26 -0000

Hi Adrian,

> My point is that you are advocating the advertisement of a block of =
labels by
> the IGP, and the use of one or more labels on the MPLS stack. And my =
question:
> why do this? You could hit the bottom of stack as normal, use the =
control word
> to identify BIER and put all of the information you need (currently =
deduced from
> the BIER-MPLS label(s) ) into the BIER header.

Just one clarification, in normal operation, we expect just one BIER =
label to be on the stack. Unless we sent a BIER packet over a P2P/FRR =
LSP, then you=92ll see two. But for the BIER procedures, only the BIER =
label is relevant.

> I'm not saying that would be better. Just asking why the choice you =
have made.

Right, but the control word also has to be indicated by the top label, =
right? How would the forwarding plane otherwise know a control word is =
following at the bottom of the stack... So, using the control would just =
mean an additional indirection, while we can have a immediate =
indirection with a BIER-MPLS label.

Thx,

Ice.

>=20
> Cheers,
> Adrian
>=20
>> -----Original Message-----
>> From: Eric Rosen [mailto:erosen@cisco.com]
>> Sent: 26 September 2014 17:48
>> To: adrian@olddog.co.uk
>> Cc: bier@ietf.org
>> Subject: Re: [Bier] MPLS encapsulation
>>=20
>> Adrian,
>>=20
>> I'm a little confused about your question: are you using the term =
"special
>> purpose label" in the sense of RFC 7274 ("Allocating and Retiring
>> Special-Purpose MPLS Labels")?  If so, there is no use of special =
purpose
>> labels (in this sense) being proposed.
>>=20
>> Did I misunderstand your question?
>>=20
>> Eric
>>=20
>=20
>=20
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier


From nobody Sat Sep 27 04:37:15 2014
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 A98011A1A96 for ; Sat, 27 Sep 2014 04:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 qdrhTtF82JE8 for ; Sat, 27 Sep 2014 04:37:11 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891B51A1AE8 for ; Sat, 27 Sep 2014 04:37:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2495; q=dns/txt; s=iport; t=1411817830; x=1413027430; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=9ylc6IS48xJjq9Yry6h1rjdOS6g9r16z7r1fBy7gIU8=; b=ZAcoF6eGBnjs11c6cSbFDiZYxv8N2UWiE/ZfeApMh0CRRa0pBDEae9oB I1DimVJVQfyYjTR9rxFQyGH/N0duhAdNLqf/ra0JcSWf5wYz52KOmG9Ij eJcz1/iOifehKT6V9iVFFINUAzgS2YJBCu2kBYQvH5r6nGTMq8kyqDsyZ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjQKAPugJlStJssW/2dsb2JhbABfg2GPGKZxTAUBcpJ/CodOgRcBe4QDAQEBAwEBAQE3NBALHAECAQIvJx8DBAIIGQmILQgNvxoBF4YSihkQgxiBHQWWHYcJgWKNNYZFg2U7LwGCSQEBAQ
X-IronPort-AV: E=Sophos;i="5.04,609,1406592000"; d="scan'208";a="190904963"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 27 Sep 2014 11:37:08 +0000
Received: from ams-iwijnand-8816.cisco.com (ams-iwijnand-8816.cisco.com [10.60.202.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8RBb65D014703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 27 Sep 2014 11:37:08 GMT
From: IJsbrand Wijnands 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sat, 27 Sep 2014 13:37:00 +0200
References: <20140927113332.3734.38144.idtracker@ietfa.amsl.com>
To: bier@ietf.org
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/Cfiz6RmC1UTmqu5PhNmgK7rzkEM
Subject: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.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: Sat, 27 Sep 2014 11:37:13 -0000

FYI.

Begin forwarded message:

> From: 
> Subject: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
> Date: 27 Sep 2014 13:33:32 GMT+2
> To: 
> Reply-To: 
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
>=20
>        Title           : OSPF Extensions For BIER
>        Authors         : Peter Psenak
>                          Nagendra Kumar
>                          IJsbrand Wijnands
>                          Andrew Dolganow
> 	Filename        : draft-psenak-ospf-bier-extensions-00.txt
> 	Pages           : 6
> 	Date            : 2014-09-27
>=20
> 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.
>=20
>   This document describes the OSPF protocol extension required for =
BIER
>   with MPLS encapsulation.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-psenak-ospf-bier-extensions/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-psenak-ospf-bier-extensions-00
>=20
>=20
> 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.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> 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 Sat Sep 27 06:27:08 2014
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 875CE1A1B11 for ; Sat, 27 Sep 2014 06:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 9fXhDNAbhhha for ; Sat, 27 Sep 2014 06:27:02 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F091A1B18 for ; Sat, 27 Sep 2014 06:27:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14369; q=dns/txt; s=iport; t=1411824422; x=1413034022; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=afTwGhV1PFj7i2x0hIGhtpA9cUb0gwXUkJ/BZpxbMwc=; b=G7B4ofOUIu3eNLG0qjO4XqlikZNLuxeIKaJ/QBuOFXSRKvDlcSZSqSeB /3+ORYRzfMFlGltA6b1MYV0zZtpxNGurC5tZSqjNMiNQIh7bfuDJH1dx9 mpPbfZwTBntp3epkD0TMdqbd8UZ7oy77rKx91hcrzddTbY+fWE7rao3oJ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFADy6JlStJA2F/2dsb2JhbABfgkhGU1uCfcURgW2HTgIZZhYBe4QDAQEBBCNWEAIBCBEDAQIoAwICAjAUCQgCBAENBYg+DakslXgBF5ANEQeCeIFTBZFjhDqHCYFik3qDY2yBSIECAQEB
X-IronPort-AV: E=Sophos; i="5.04,609,1406592000"; d="scan'208,217"; a="81776200"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 27 Sep 2014 13:27:01 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s8RDR1dl025409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Sep 2014 13:27:01 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.166]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Sat, 27 Sep 2014 08:27:00 -0500
From: "Nagendra Kumar Nainar (naikumar)" 
To: Robert Raszuk , "IJsbrand Wijnands (iwijnand)" 
Thread-Topic: [Bier] One specific transition churn ...
Thread-Index: AQHP2cgHxaoM20tboE6sjh+V1W/s35wUOjWAgADQbIA=
Date: Sat, 27 Sep 2014 13:27:00 +0000
Message-ID: 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>   
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.2.140509
x-originating-ip: [10.21.96.121]
Content-Type: multipart/alternative; boundary="_000_D04C317470BA9naikumarciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/P2AihJHmQqsDjIPEVmdw2zQ_QJ0
Cc: "Eric Rosen \(erosen\)" , "bier@ietf.org" , Antoni Przygienda 
Subject: Re: [Bier] One specific transition churn ...
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, 27 Sep 2014 13:27:06 -0000

--_000_D04C317470BA9naikumarciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgUm9iZXJ0LA0KDQpUYWtlIFNQUklORyBJUHY2IC4uLiB3aHkgZXh0ZW5zaW9uIGhlYWRlciBj
b3VsZCBub3QgbGlzdCBhbGwgZWdyZXNzIG5vZGVzIGFzIHdlbGwgYXMg4oCLDQoNCuKAi2xpc3Qg
b2YgdHJhbnNpdCBCRlJzIHdoZXJlIHJlcGxpY2F0aW9uIHRvIHNhaWQgZWdyZXNzIG5vZGVzIGlz
IHRvIHRha2UgcGxhY2UgPw0KDQpPciBnb2luZyBzdGVwIGZ1cnRoZXIgLi4gc2VuZCBsaXN0IG9m
IEJGUnMgKGxpa2UgU05zKSBhbmQgcHJvZ3JhbSB0aGUgcmVxdWlyZWQgcmVwbGljYXRpb24gb3V0
IG9mIGJhbmQgKGZyb20gY29udHJvbGxlcikgYXZvaWRpbmcgY2FycnlpbmcgYml0c3RyaW5nIG9y
IG5ldHdvcmsgcHJvdG9jb2xzIHRvIGJ1aWxkIGEgdHJlZSB0byBhY2NvbXBsaXNoIGVhc3kgd2F5
IG9mIG9wdGltYWwgcmVwbGljYXRpb24gPyBJcyBrZWVwaW5nIG11bHRpY2FzdCBncm91cHMgc3Vj
aCBhbiBvdmVya2lsbCBmb3IgZXZlbiBhbiBhdmVyYWdlIG5ldHdvcmsgZGV2aWNlIHRoZXNlIGRh
eXMgPw0KDQo8TmFnZW5kcmE+IEJpRVIgZG9lc27igJl0IG5lZWQgYW55IElHUCBjYWxjdWxhdGlv
biBmb3IgZXZlcnkgbXVsdGljYXN0IGdyb3VwIGpvaW5lZCBieSBCRkVSLiBJbmZhY3QsIGl0IHNp
bXBseSBsZXZlcmFnZSB0aGUgdW5pY2FzdCB0YWxlIGFuZCBwb3B1bGF0ZSB0aGUgQklGVCB0YWJs
ZS4gU28gaW5zdGVhZCBvZiBwcm9ncmFtbWluZyBkaWZmZXJlbnQgdHJhbnNpdCBub2RlcyBmb3Ig
b3B0aW1hbCByZXBsaWNhdGlvbiBmb3IgZXZlcnkgbmV3IGdyb3VwLCBJIHRoaW5rIGl0IGlzIHNp
bXBsZSB0byBoYXZlIHRoZSB0cmVlIGJ1aWx0IG9uY2UgKHdoaWNoIGRvZXNu4oCZdCBuZWVkIGFk
ZGl0aW9uYWwgU1BGIG90aGVyIHRoYW4gdW5pY2FzdCBjYWxjdWxhdGlvbikgYW5kIHN0aWxsIGFj
aGlldmUgb3B0aW1hbCBmb3J3YXJkaW5nLg0KDQpMYXN0IGJ1dCBub3QgbGVhc3QgaG93IGlzIHNh
aWQgYml0c3RyaW5nIHRvIGJlIGhvbm9yZWQsIGFjY2VwdGVkIGFuZCB1c2VkIGJldHdlZW4gZG9t
YWlucyA/IFdoYXQgTk5JIGlzIHRvIGJlIGFncmVlZCBmb3IgQklFUiB0byBtYWtlIGl0IHVzYWJs
ZSBiZXR3ZWVuIEFTIHVuZGVyIGRpZmZlcmVudCBhZG1pbmlzdHJhdGlvbnMgPw0KDQo8TmFnZW5k
cmE+IEkgdGhpbmsgdGhpcyBpcyBzbGlnaHRseSBjb3ZlcmVkIGluIGJlbG93IGRyYWZ0LA0KDQpo
dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yb3Nlbi1sM3Zwbi1tdnBuLWJpZXItMDAN
Cg0KVGhhbmtzLA0KTmFnZW5kcmENCg0KRnJvbTogInJvYmVydEByYXN6dWsubmV0PG1haWx0bzpy
b2JlcnRAcmFzenVrLm5ldD4iIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1
ay5uZXQ+Pg0KRGF0ZTogRnJpZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTQgYXQgNTowMSBQTQ0KVG86
IElKc2JyYW5kIFdpam5hbmRzIDxpY2VAY2lzY28uY29tPG1haWx0bzppY2VAY2lzY28uY29tPj4N
CkNjOiAiYmllckBpZXRmLm9yZzxtYWlsdG86YmllckBpZXRmLm9yZz4iIDxiaWVyQGlldGYub3Jn
PG1haWx0bzpiaWVyQGlldGYub3JnPj4sICJFcmljIFJvc2VuIChlcm9zZW4pIiA8ZXJvc2VuQGNp
c2NvLmNvbTxtYWlsdG86ZXJvc2VuQGNpc2NvLmNvbT4+LCBBbnRvbmkgUHJ6eWdpZW5kYSA8YW50
b25pLnByenlnaWVuZGFAZXJpY3Nzb24uY29tPG1haWx0bzphbnRvbmkucHJ6eWdpZW5kYUBlcmlj
c3Nvbi5jb20+Pg0KU3ViamVjdDogUmU6IFtCaWVyXSBPbmUgc3BlY2lmaWMgdHJhbnNpdGlvbiBj
aHVybiAuLi4NCg0KQklFUiBpcyB0b3RhbGx5IHVucmVsYXRlZCB0byBTUFJJTkcsIGNvbXBsZXRl
bHkgZGlmZmVyZW50IGRhdGEtcGxhbmUhDQoNCuKAi1BlcmhhcHMgaXQgaXMgdG9kYXksIGJ1dCB0
aGUgcXVlc3Rpb24gaXMgLSBkb2VzIGl0IG5lZWQgdG8gYmUgYSB5ZXQgb25lIG1vcmUgY29tcGxl
dGVseSBuZXcgZGF0YS1wbGFuZSA/DQoNClRha2UgU1BSSU5HIElQdjYgLi4uIHdoeSBleHRlbnNp
b24gaGVhZGVyIGNvdWxkIG5vdCBsaXN0IGFsbCBlZ3Jlc3Mgbm9kZXMgYXMgd2VsbCBhcyDigIsN
Cg0K4oCLbGlzdCBvZiB0cmFuc2l0IEJGUnMgd2hlcmUgcmVwbGljYXRpb24gdG8gc2FpZCBlZ3Jl
c3Mgbm9kZXMgaXMgdG8gdGFrZSBwbGFjZSA/DQoNCk9yIGdvaW5nIHN0ZXAgZnVydGhlciAuLiBz
ZW5kIGxpc3Qgb2YgQkZScyAobGlrZSBTTnMpIGFuZCBwcm9ncmFtIHRoZSByZXF1aXJlZCByZXBs
aWNhdGlvbiBvdXQgb2YgYmFuZCAoZnJvbSBjb250cm9sbGVyKSBhdm9pZGluZyBjYXJyeWluZyBi
aXRzdHJpbmcgb3IgbmV0d29yayBwcm90b2NvbHMgdG8gYnVpbGQgYSB0cmVlIHRvIGFjY29tcGxp
c2ggZWFzeSB3YXkgb2Ygb3B0aW1hbCByZXBsaWNhdGlvbiA/IElzIGtlZXBpbmcgbXVsdGljYXN0
IGdyb3VwcyBzdWNoIGFuIG92ZXJraWxsIGZvciBldmVuIGFuIGF2ZXJhZ2UgbmV0d29yayBkZXZp
Y2UgdGhlc2UgZGF5cyA/DQoNCkxhc3QgYnV0IG5vdCBsZWFzdCBob3cgaXMgc2FpZCBiaXRzdHJp
bmcgdG8gYmUgaG9ub3JlZCwgYWNjZXB0ZWQgYW5kIHVzZWQgYmV0d2VlbiBkb21haW5zID8gV2hh
dCBOTkkgaXMgdG8gYmUgYWdyZWVkIGZvciBCSUVSIHRvIG1ha2UgaXQgdXNhYmxlIGJldHdlZW4g
QVMgdW5kZXIgZGlmZmVyZW50IGFkbWluaXN0cmF0aW9ucyA/DQoNClRoeCwNCnIuDQoNCg==

--_000_D04C317470BA9naikumarciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <24EE0461B1AA904CB3EFF842F96D3BA6@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb2JlcnQs
PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFp
bF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6ICdjb3VyaWVyIG5ldycsIG1vbm9zcGFjZTsg
Zm9udC1zaXplOiBzbWFsbDsgZGlzcGxheTogaW5saW5lOyI+DQpUYWtlIFNQUklORyBJUHY2IC4u
LiB3aHkgZXh0ZW5zaW9uIGhlYWRlciBjb3VsZCBub3QgbGlzdCBhbGwgZWdyZXNzIG5vZGVzIGFz
IHdlbGwgYXMg4oCLPC9kaXY+DQombmJzcDsmbmJzcDsmbmJzcDsNCjxkaXYgY2xhc3M9ImdtYWls
X2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTogJ2NvdXJpZXIgbmV3JywgbW9ub3NwYWNlOyBm
b250LXNpemU6IHNtYWxsOyBkaXNwbGF5OiBpbmxpbmU7Ij4NCuKAi2xpc3Qgb2YgdHJhbnNpdCBC
RlJzIHdoZXJlIHJlcGxpY2F0aW9uIHRvIHNhaWQgZWdyZXNzIG5vZGVzIGlzIHRvIHRha2UgcGxh
Y2UgPyZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVs
dCIgc3R5bGU9ImZvbnQtZmFtaWx5OiAnY291cmllciBuZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6
ZTogc21hbGw7IGRpc3BsYXk6IGlubGluZTsiPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6ICdjb3VyaWVy
IG5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiBzbWFsbDsgZGlzcGxheTogaW5saW5lOyI+DQpP
ciBnb2luZyBzdGVwIGZ1cnRoZXIgLi4gc2VuZCBsaXN0IG9mIEJGUnMgKGxpa2UgU05zKSBhbmQg
cHJvZ3JhbSB0aGUgcmVxdWlyZWQgcmVwbGljYXRpb24gb3V0IG9mIGJhbmQgKGZyb20gY29udHJv
bGxlcikgYXZvaWRpbmcgY2FycnlpbmcgYml0c3RyaW5nIG9yIG5ldHdvcmsgcHJvdG9jb2xzIHRv
IGJ1aWxkIGEgdHJlZSB0byBhY2NvbXBsaXNoIGVhc3kgd2F5IG9mIG9wdGltYWwgcmVwbGljYXRp
b24gPyBJcyBrZWVwaW5nIG11bHRpY2FzdCBncm91cHMNCiBzdWNoIGFuIG92ZXJraWxsIGZvciBl
dmVuIGFuIGF2ZXJhZ2UgbmV0d29yayBkZXZpY2UgdGhlc2UgZGF5cyA/PC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh
bWlseTogJ2NvdXJpZXIgbmV3JywgbW9ub3NwYWNlOyBmb250LXNpemU6IHNtYWxsOyBkaXNwbGF5
OiBpbmxpbmU7Ij4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21h
aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OiAnY291cmllciBuZXcnLCBtb25vc3BhY2U7
IGZvbnQtc2l6ZTogc21hbGw7IGRpc3BsYXk6IGlubGluZTsiPg0KJmx0O05hZ2VuZHJhJmd0OyBC
aUVSIGRvZXNu4oCZdCBuZWVkIGFueSBJR1AgY2FsY3VsYXRpb24gZm9yIGV2ZXJ5IG11bHRpY2Fz
dCBncm91cCBqb2luZWQgYnkgQkZFUi4gSW5mYWN0LCBpdCBzaW1wbHkgbGV2ZXJhZ2UgdGhlIHVu
aWNhc3QgdGFsZSBhbmQgcG9wdWxhdGUgdGhlIEJJRlQgdGFibGUuIFNvIGluc3RlYWQgb2YgcHJv
Z3JhbW1pbmcgZGlmZmVyZW50IHRyYW5zaXQgbm9kZXMgZm9yIG9wdGltYWwgcmVwbGljYXRpb24g
Zm9yIGV2ZXJ5IG5ldyBncm91cCwNCiBJIHRoaW5rIGl0IGlzIHNpbXBsZSB0byBoYXZlIHRoZSB0
cmVlIGJ1aWx0IG9uY2UgKHdoaWNoIGRvZXNu4oCZdCBuZWVkIGFkZGl0aW9uYWwgU1BGIG90aGVy
IHRoYW4gdW5pY2FzdCBjYWxjdWxhdGlvbikgYW5kIHN0aWxsIGFjaGlldmUgb3B0aW1hbCBmb3J3
YXJkaW5nLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIg
c3R5bGU9ImZvbnQtZmFtaWx5OiAnY291cmllciBuZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTog
c21hbGw7IGRpc3BsYXk6IGlubGluZTsiPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6ICdjb3VyaWVyIG5l
dycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiBzbWFsbDsgZGlzcGxheTogaW5saW5lOyI+DQpMYXN0
IGJ1dCBub3QgbGVhc3QgaG93IGlzIHNhaWQgYml0c3RyaW5nIHRvIGJlIGhvbm9yZWQsIGFjY2Vw
dGVkIGFuZCB1c2VkIGJldHdlZW4gZG9tYWlucyA/IFdoYXQgTk5JIGlzIHRvIGJlIGFncmVlZCBm
b3IgQklFUiB0byBtYWtlIGl0IHVzYWJsZSBiZXR3ZWVuIEFTIHVuZGVyIGRpZmZlcmVudCBhZG1p
bmlzdHJhdGlvbnMgPzxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21h
aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OiAnY291cmllciBuZXcnLCBtb25vc3BhY2U7
IGZvbnQtc2l6ZTogc21hbGw7IGRpc3BsYXk6IGlubGluZTsiPg0KPGJyPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6
ICdjb3VyaWVyIG5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiBzbWFsbDsgZGlzcGxheTogaW5s
aW5lOyI+DQombHQ7TmFnZW5kcmEmZ3Q7IEkgdGhpbmsgdGhpcyBpcyBzbGlnaHRseSBjb3ZlcmVk
IGluIGJlbG93IGRyYWZ0LDwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf
ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OiAnY291cmllciBuZXcnLCBtb25vc3BhY2U7IGZv
bnQtc2l6ZTogc21hbGw7IGRpc3BsYXk6IGlubGluZTsiPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6ICdj
b3VyaWVyIG5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiBzbWFsbDsgZGlzcGxheTogaW5saW5l
OyI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yb3Nlbi1sM3Zw
bi1tdnBuLWJpZXItMDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJvc2VuLWwz
dnBuLW12cG4tYmllci0wMDwvYT48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6ICdjb3Vy
aWVyIG5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiBzbWFsbDsgZGlzcGxheTogaW5saW5lOyI+
DQpUaGFua3MsPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0
IiBzdHlsZT0iZm9udC1mYW1pbHk6ICdjb3VyaWVyIG5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXpl
OiBzbWFsbDsgZGlzcGxheTogaW5saW5lOyI+DQpOYWdlbmRyYTwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OiAnY291cmll
ciBuZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogc21hbGw7IGRpc3BsYXk6IGlubGluZTsiPg0K
PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8
ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGln
bjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1M
RUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47
IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRF
Ui1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZv
bnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0
QHJhc3p1ay5uZXQiPnJvYmVydEByYXN6dWsubmV0PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnJvYmVydEByYXN6dWsubmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KPHNw
YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXksIFNlcHRlbWJl
ciAyNiwgMjAxNCBhdCA1OjAxIFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi
PlRvOiA8L3NwYW4+SUpzYnJhbmQgV2lqbmFuZHMgJmx0OzxhIGhyZWY9Im1haWx0bzppY2VAY2lz
Y28uY29tIj5pY2VAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln
aHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86YmllckBpZXRmLm9yZyI+
YmllckBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiaWVyQGlldGYub3Jn
Ij5iaWVyQGlldGYub3JnPC9hPiZndDssICZxdW90O0VyaWMgUm9zZW4gKGVyb3NlbikmcXVvdDsg
Jmx0OzxhIGhyZWY9Im1haWx0bzplcm9zZW5AY2lzY28uY29tIj5lcm9zZW5AY2lzY28uY29tPC9h
PiZndDssIEFudG9uaSBQcnp5Z2llbmRhICZsdDs8YSBocmVmPSJtYWlsdG86YW50b25pLnByenln
aWVuZGFAZXJpY3Nzb24uY29tIj5hbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb208L2E+Jmd0
Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6
IFtCaWVyXSBPbmUgc3BlY2lmaWMgdHJhbnNpdGlvbiBjaHVybiAuLi48YnI+DQo8L2Rpdj4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFz
cz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUg
Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6
MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0iYXV0byI+PHNwYW4+
DQo8ZGl2PkJJRVIgaXMgdG90YWxseSB1bnJlbGF0ZWQgdG8gU1BSSU5HLCBjb21wbGV0ZWx5IGRp
ZmZlcmVudCBkYXRhLXBsYW5lITxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0
IiBzdHlsZT0iZm9udC1mYW1pbHk6J2NvdXJpZXIgbmV3Jyxtb25vc3BhY2U7Zm9udC1zaXplOnNt
YWxsO2Rpc3BsYXk6aW5saW5lIj4NCuKAi1BlcmhhcHMgaXQgaXMgdG9kYXksIGJ1dCB0aGUgcXVl
c3Rpb24gaXMgLSBkb2VzIGl0IG5lZWQgdG8gYmUgYSB5ZXQgb25lIG1vcmUgY29tcGxldGVseSBu
ZXcgZGF0YS1wbGFuZSA/Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJn
bWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6J2NvdXJpZXIgbmV3Jyxtb25vc3BhY2U7
Zm9udC1zaXplOnNtYWxsO2Rpc3BsYXk6aW5saW5lIj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5Oidjb3Vy
aWVyIG5ldycsbW9ub3NwYWNlO2ZvbnQtc2l6ZTpzbWFsbDtkaXNwbGF5OmlubGluZSI+DQpUYWtl
IFNQUklORyBJUHY2IC4uLiB3aHkgZXh0ZW5zaW9uIGhlYWRlciBjb3VsZCBub3QgbGlzdCBhbGwg
ZWdyZXNzIG5vZGVzIGFzIHdlbGwgYXMg4oCLPC9kaXY+DQombmJzcDsNCjxkaXYgY2xhc3M9Imdt
YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTonY291cmllciBuZXcnLG1vbm9zcGFjZTtm
b250LXNpemU6c21hbGw7ZGlzcGxheTppbmxpbmUiPg0K4oCLbGlzdCBvZiB0cmFuc2l0IEJGUnMg
d2hlcmUgcmVwbGljYXRpb24gdG8gc2FpZCBlZ3Jlc3Mgbm9kZXMgaXMgdG8gdGFrZSBwbGFjZSA/
Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBz
dHlsZT0iZm9udC1mYW1pbHk6J2NvdXJpZXIgbmV3Jyxtb25vc3BhY2U7Zm9udC1zaXplOnNtYWxs
O2Rpc3BsYXk6aW5saW5lIj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFz
cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5Oidjb3VyaWVyIG5ldycsbW9ub3Nw
YWNlO2ZvbnQtc2l6ZTpzbWFsbDtkaXNwbGF5OmlubGluZSI+DQpPciBnb2luZyBzdGVwIGZ1cnRo
ZXIgLi4gc2VuZCBsaXN0IG9mIEJGUnMgKGxpa2UgU05zKSBhbmQgcHJvZ3JhbSB0aGUgcmVxdWly
ZWQgcmVwbGljYXRpb24gb3V0IG9mIGJhbmQgKGZyb20gY29udHJvbGxlcikgYXZvaWRpbmcgY2Fy
cnlpbmcgYml0c3RyaW5nIG9yIG5ldHdvcmsgcHJvdG9jb2xzIHRvIGJ1aWxkIGEgdHJlZSB0byBh
Y2NvbXBsaXNoIGVhc3kgd2F5IG9mIG9wdGltYWwgcmVwbGljYXRpb24gPyBJcyBrZWVwaW5nIG11
bHRpY2FzdCBncm91cHMNCiBzdWNoIGFuIG92ZXJraWxsIGZvciBldmVuIGFuIGF2ZXJhZ2UgbmV0
d29yayBkZXZpY2UgdGhlc2UgZGF5cyA/PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNz
PSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6J2NvdXJpZXIgbmV3Jyxtb25vc3Bh
Y2U7Zm9udC1zaXplOnNtYWxsO2Rpc3BsYXk6aW5saW5lIj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5Oidj
b3VyaWVyIG5ldycsbW9ub3NwYWNlO2ZvbnQtc2l6ZTpzbWFsbDtkaXNwbGF5OmlubGluZSI+DQpM
YXN0IGJ1dCBub3QgbGVhc3QgaG93IGlzIHNhaWQgYml0c3RyaW5nIHRvIGJlIGhvbm9yZWQsIGFj
Y2VwdGVkIGFuZCB1c2VkIGJldHdlZW4gZG9tYWlucyA/IFdoYXQgTk5JIGlzIHRvIGJlIGFncmVl
ZCBmb3IgQklFUiB0byBtYWtlIGl0IHVzYWJsZSBiZXR3ZWVuIEFTIHVuZGVyIGRpZmZlcmVudCBh
ZG1pbmlzdHJhdGlvbnMgPzxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0i
Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5Oidjb3VyaWVyIG5ldycsbW9ub3NwYWNl
O2ZvbnQtc2l6ZTpzbWFsbDtkaXNwbGF5OmlubGluZSI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTonY291
cmllciBuZXcnLG1vbm9zcGFjZTtmb250LXNpemU6c21hbGw7ZGlzcGxheTppbmxpbmUiPg0KVGh4
LDwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9
ImZvbnQtZmFtaWx5Oidjb3VyaWVyIG5ldycsbW9ub3NwYWNlO2ZvbnQtc2l6ZTpzbWFsbDtkaXNw
bGF5OmlubGluZSI+DQpyLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_D04C317470BA9naikumarciscocom_--


From nobody Sat Sep 27 07:28:46 2014
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 9DAA91A1B2F for ; Sat, 27 Sep 2014 07:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 GJoefNi9tRQx for ; Sat, 27 Sep 2014 07:28:42 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001: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 2E03A1A1B2C for ; Sat, 27 Sep 2014 07:28:42 -0700 (PDT)
Received: by mail-ig0-f182.google.com with SMTP id hn18so1088938igb.3 for ; Sat, 27 Sep 2014 07:28:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eX+4R+VdyWA95EA4dpzlamFdbf3otY+ISukCDMcUIB4=; b=IGxoLJ5r9cTAV0bpBoeZb642TqGZCDgtYSwelgFE5ralYVAKjp/DWIvM1AYjTWvvSr OBfBtxnAS7gFmA5QKLm4VyQP4Nsg5faRai1VohtR/bvKoIJp06fi/CJn+u7u2eMH4A7l CJksGDOU2sNDszvPxgeroxf0CQKJ8lwstYbD0bdzT8s8zmhey3HfvQfH7sV7HSrFJxTZ V0zh2yDXblISQNreJprxsDG5BS0G8BzDWrtUGzUFWQTLPdBJQNEbHHooL9XjX9tkAddx cjb+B9on5AjGXcRLykmzG5UwciTdUR3v0n//ga2X21ea6KKbnqi6jcqHvR3gJhBFcFrE nQPQ==
MIME-Version: 1.0
X-Received: by 10.42.46.81 with SMTP id j17mr31544040icf.54.1411828121407; Sat, 27 Sep 2014 07:28:41 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.166.8 with HTTP; Sat, 27 Sep 2014 07:28:41 -0700 (PDT)
In-Reply-To: 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>    
Date: Sat, 27 Sep 2014 16:28:41 +0200
X-Google-Sender-Auth: 0YFvHeFX_46Vlk_uCjejeqBB7KQ
Message-ID: 
From: Robert Raszuk 
To: "Nagendra Kumar Nainar (naikumar)" , Antoni Przygienda 
Content-Type: multipart/alternative; boundary=20cf30223cdfa91a9a05040cd9f3
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/iwVwB1Fm3RSpxXoIF9mMNKQWxNI
Cc: "Eric Rosen \(erosen\)" , "bier@ietf.org" , "IJsbrand Wijnands \(iwijnand\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 27 Sep 2014 14:28:44 -0000

--20cf30223cdfa91a9a05040cd9f3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Nagendra,

>  BiER doesn=E2=80=99t need any IGP calculation
> for every multicast group joined by BFER.

I am not talking about IGP. Where is this assumption coming from I do not
know.

All agree that BFER receives a join for new group that has to somehow
travel to BFIR as well as BFIR must adjust its data plane. That is the
churn I was referring to.

Hi Tony,

> [Tony said]  ???  Last I checked SPRING was defining a
> unicast dataplane.

Where does it say so in the SPRING charter ???

http://datatracker.ietf.org/wg/spring/charter/

Cheers,
r.


On Sat, Sep 27, 2014 at 3:27 PM, Nagendra Kumar Nainar (naikumar) <
naikumar@cisco.com> wrote:

>  Hi Robert,
>
>   Take SPRING IPv6 ... why extension header could not list all egress
> nodes as well as =E2=80=8B
>
> =E2=80=8Blist of transit BFRs where replication to said egress nodes is t=
o take
> place ?
>
>   Or going step further .. send list of BFRs (like SNs) and program the
> required replication out of band (from controller) avoiding carrying
> bitstring or network protocols to build a tree to accomplish easy way of
> optimal replication ? Is keeping multicast groups such an overkill for ev=
en
> an average network device these days ?
>
>    BiER doesn=E2=80=99t need any IGP calculation for every mult=
icast
> group joined by BFER. Infact, it simply leverage the unicast tale and
> populate the BIFT table. So instead of programming different transit node=
s
> for optimal replication for every new group, I think it is simple to have
> the tree built once (which doesn=E2=80=99t need additional SPF other than=
 unicast
> calculation) and still achieve optimal forwarding.
>
>   Last but not least how is said bitstring to be honored, accepted and
> used between domains ? What NNI is to be agreed for BIER to make it usabl=
e
> between AS under different administrations ?
>
>    I think this is slightly covered in below draft,
>
>   http://tools.ietf.org/html/draft-rosen-l3vpn-mvpn-bier-00
>
>   Thanks,
>   Nagendra
>
>   From: "robert@raszuk.net" 
> Date: Friday, September 26, 2014 at 5:01 PM
> To: IJsbrand Wijnands 
> Cc: "bier@ietf.org" , "Eric Rosen (erosen)" <
> erosen@cisco.com>, Antoni Przygienda 
> Subject: Re: [Bier] One specific transition churn ...
>
>     BIER is totally unrelated to SPRING, completely different data-plane!
>>
>
>   =E2=80=8BPerhaps it is today, but the question is - does it need to be =
a yet
> one more completely new data-plane ?
>
>   Take SPRING IPv6 ... why extension header could not list all egress
> nodes as well as =E2=80=8B
>
> =E2=80=8Blist of transit BFRs where replication to said egress nodes is t=
o take
> place ?
>
>   Or going step further .. send list of BFRs (like SNs) and program the
> required replication out of band (from controller) avoiding carrying
> bitstring or network protocols to build a tree to accomplish easy way of
> optimal replication ? Is keeping multicast groups such an overkill for ev=
en
> an average network device these days ?
>
>   Last but not least how is said bitstring to be honored, accepted and
> used between domains ? What NNI is to be agreed for BIER to make it usabl=
e
> between AS under different administrations ?
>
>   Thx,
>   r.
>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>

--20cf30223cdfa91a9a05040cd9f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


H=
i Nagendra,

> <Nagendra> BiER doesn=E2=80=99t need any IGP calculation=C2=
=A0
&g=
t; for every multicast group joined by BFER.

I am not talking about IGP. Where=
 is this assumption coming from I do not know.=C2=A0

All agree that BFER receives=
 a join for new group that has to somehow travel to BFIR as well as BFIR mu=
st adjust its data plane. That is the churn I was referring to.=C2=A0

=

Hi Tony,

> [Tony said] =C2=A0???=C2=A0 Last I checked SPR=
ING was defining a=C2=A0
> unicast dataplane=
.

Where do=
es it say so in the SPRING charter ???

http://datatracker.ietf.org/wg/spring/charter/=C2=A0

Cheers,
r.


=

On Sat, Sep 27, 2014 at 3:27 PM, Nagendra Kumar =
Nainar (naikumar) <naikumar@cisco.com> wrote:







Hi Robert,












Take SPRING IPv6 ... why extension header could not list all egress nodes a=
s well as =E2=80=8B

=C2=A0=C2=A0=C2=A0


=E2=80=8Blist of transit BFRs where replication to said egress nodes is to =
take place ?=C2=A0

















Or going step further .. send list of BFRs (like SNs) and program the requi=
red replication out of band (from controller) avoiding carrying bitstring o=
r network protocols to build a tree to accomplish easy way of optimal repli=
cation ? Is keeping multicast groups
 such an overkill for even an average network device these days ?



















<Nagendra> BiER doesn=E2=80=99t need any IGP calculation for every mu=
lticast group joined by BFER. Infact, it simply leverage the unicast tale a=
nd populate the BIFT table. So instead of programming different transit nod=
es for optimal replication for every new group,
 I think it is simple to have the tree built once (which doesn=E2=80=99t ne=
ed additional SPF other than unicast calculation) and still achieve optimal=
 forwarding.

















Last but not least how is said bitstring to be honored, accepted and used b=
etween domains ? What NNI is to be agreed for BIER to make it usable betwee=
n AS under different administrations ?



















<Nagendra> I think this is slightly covered in below draft,

















http://tools.ietf.org/html/draft-rosen-l3vpn-mvpn-bier-00<=
/div>











Thanks,







Nagendra
















From: "robert@raszuk.net" <robert@raszuk.net>

Date: Friday, September 26, 2014 at=
 5:01 PM

To: IJsbrand Wijnands <ice@cisco.com>

Cc: "bier@ietf.org" <bier@ietf.org>, "Eric Rosen (eros=
en)" <erosen@=
cisco.com>, Antoni Przygienda <antoni.przygienda@ericsson.com>

Subject: Re: [Bier] One specific tr=
ansition churn ...























BIER is totally unrelated to SPRING, completely different data-plane!<=
br>















=E2=80=8BPerhaps it is today, but the question is - does it need to be a ye=
t one more completely new data-plane ?=C2=A0

















Take SPRING IPv6 ... why extension header could not list all egress nodes a=
s well as =E2=80=8B

=C2=A0


=E2=80=8Blist of transit BFRs where replication to said egress nodes is to =
take place ?=C2=A0

















Or going step further .. send list of BFRs (like SNs) and program the requi=
red replication out of band (from controller) avoiding carrying bitstring o=
r network protocols to build a tree to accomplish easy way of optimal repli=
cation ? Is keeping multicast groups
 such an overkill for even an average network device these days ?

















Last but not least how is said bitstring to be honored, accepted and used b=
etween domains ? What NNI is to be agreed for BIER to make it usable betwee=
n AS under different administrations ?



















Thx,







r.





















_______________________________________________

BIER mailing list

BIER@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/bier





--20cf30223cdfa91a9a05040cd9f3--


From nobody Sat Sep 27 09:04:01 2014
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 0B53D1A1B9B for ; Sat, 27 Sep 2014 09:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 YLamwJjweKcG for ; Sat, 27 Sep 2014 09:03:58 -0700 (PDT)
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 6995B1A1B9A for ; Sat, 27 Sep 2014 09:03:57 -0700 (PDT)
X-AuditID: c618062d-f79206d0000014d2-0a-542689875550
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 39.BB.05330.78986245; Sat, 27 Sep 2014 11:55:19 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Sat, 27 Sep 2014 12:03:48 -0400
From: Antoni Przygienda 
To: Robert Raszuk , "Nagendra Kumar Nainar (naikumar)" 
Thread-Topic: [Bier] One specific transition churn ...
Thread-Index: AQHP2a+BuVUit1FzlkuzW2MzFDiDwZwTq93QgABarwCAABklgIAACfKAgAETewCAABE8gP//1kEg
Date: Sat, 27 Sep 2014 16:03:47 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181B5F1D@eusaamb103.ericsson.se>
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F181B5F1Deusaamb103ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLonRLe9Uy3EYNMHKYulM/YwWay7O4nF 4tWcO8wWrydOZbNoWtjE7MDqMeX3RlaPJUt+Mnns3riAKYA5issmJTUnsyy1SN8ugSvj0/9b rAVHzCtWTt7B3sD4w7SLkZNDQsBE4kbXOlYIW0ziwr31bF2MXBxCAkcZJZa8usIK4SxnlGi8 /IERpIpNwELi8renzCC2iECCxNXri1hAbGaBeokjC9ewgdjCAqYSsy68Y4GoMZO4svExK4Qd JfH6WgdYnEVAVeLjmqtgc3gFvCVaz3ayg9hCAp+ZJfYsCQaxOQUCJU7cmgMWZwS67vupNUwQ u8Qlbj2ZzwRxtYDEkj3nmSFsUYmXj/9BfaMk8fH3fKBeDqD6fIlFPeYQqwQlTs58wjKBUXQW kkmzEKpmIamCCGtKrN+lD1GtKDGl+yE7hK0h0TpnLjuy+AJG9lWMHKXFqWW56UYGmxiBkXdM gk13B+Oel5aHGAU4GJV4eB88VA0RYk0sK67MPcQozcGiJM47q3ZesJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGjMTz/9R/Cf7wPZRWLugi9q8s7ibD+urbazYtufJFVXSZhh7Pfy+b8O2b rpVNc91gq/FHPv7m0upVcmZBiTUGMue+zeHZVRqks6VV7Opj2+LqiIzXUTsyGt7ZXUgsdehi lHX6w+s9I+8d28QNX3iPfNFd5XoqUf3Rq4WZT19Htd99G8socvWnEktxRqKhFnNRcSIAd9g+ 6J0CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/a55fren01AOdt660BKoDRlMsDDU
Cc: "Eric Rosen \(erosen\)" , "bier@ietf.org" , "IJsbrand Wijnands \(iwijnand\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 27 Sep 2014 16:04:00 -0000

--_000_2E4BB27CAB87BF43B4207C0E55860F181B5F1Deusaamb103ericsso_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2hlcmUgZG9lcyBpdCBzYXkgc28gaW4gdGhlIFNQUklORyBjaGFydGVyID8/Pw0KDQpodHRwOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc3ByaW5nL2NoYXJ0ZXIvDQoNCg0KW1Rvbnkgc2FpZF0g
SSBmYWlsIHRvIHNlZSBhIGxvb3NlIG9yIG5vdCBsb29zZSDigJhzb3VyY2Ugcm91dGXigJkgaW4g
QklFUiBlbmNhcHN1bGF0aW9uLCBvbmx5IGRlc3RpbmF0aW9ucy4gIFVsdGltYXRlbHksIHdlIGNh
biBhcmd1ZSB0aGF0IElFVEYgbmVlZHMgYSBzaW5nbGUgcHJvdG9jb2wgYW5kIGVuY2Fwc3VsYXRp
b24gYW5kIHRyYW5zcG9ydCBhbmQgT0FNIHdvcmtpbmcgZ3JvdXAgY2FsbGVkIOKAmGJpdHMtb24t
dGhlLXdpcmXigJkgb25seS4gIEluIHdpZGVzdCBzZW5zZSwgYW55IGtpbmQgb2Ygb250b2xvZ3kg
Y2FuIGJlIHB1dCBvbiB0b3Agb2YgdGhlIHdvcmxkIGlmIGFyZ3VlZCBmb3IgaXQgc3RyZW51b3Vz
bHkgZW5vdWdoIGFuZCBldmVyeXRoaW5nIG1hZGUgdGhlIHNhbWUg4oCYdGhpbmfigJkuDQoNCi0t
LSB0b255DQo=

--_000_2E4BB27CAB87BF43B4207C0E55860F181B5F1Deusaamb103ericsso_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3
RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
O2NvbG9yOmJsYWNrIj5XaGVyZSBkb2VzIGl0IHNheSBzbyBpbiB0aGUgU1BSSU5HIGNoYXJ0ZXIg
Pz8/PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBj
b2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PGEg
aHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3NwcmluZy9jaGFydGVyLyI+aHR0
cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3NwcmluZy9jaGFydGVyLzwvYT4mbmJzcDs8L3Nw
YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg
Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxmb250IHNpemU9IjIiIGNvbG9yPSIj
MWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RDtmb250LXdlaWdodDpib2xkO2ZvbnQtc3R5bGU6aXRhbGljIj5bVG9ueSBzYWlkXSBJ
IGZhaWwgdG8gc2VlIGEgbG9vc2Ugb3Igbm90IGxvb3NlIOKAmHNvdXJjZSByb3V0ZeKAmSBpbiBC
SUVSDQogZW5jYXBzdWxhdGlvbiwgb25seSBkZXN0aW5hdGlvbnMuJm5ic3A7IFVsdGltYXRlbHks
IHdlIGNhbiBhcmd1ZSB0aGF0IElFVEYgbmVlZHMgYSBzaW5nbGUgcHJvdG9jb2wgYW5kIGVuY2Fw
c3VsYXRpb24gYW5kIHRyYW5zcG9ydCBhbmQgT0FNIHdvcmtpbmcgZ3JvdXAgY2FsbGVkIOKAmGJp
dHMtb24tdGhlLXdpcmXigJkgb25seS4gJm5ic3A7SW4gd2lkZXN0IHNlbnNlLCBhbnkga2luZCBv
ZiBvbnRvbG9neSBjYW4gYmUgcHV0IG9uIHRvcCBvZiB0aGUgd29ybGQgaWYgYXJndWVkDQogZm9y
IGl0IHN0cmVudW91c2x5IGVub3VnaCBhbmQgZXZlcnl0aGluZyBtYWRlIHRoZSBzYW1lIOKAmHRo
aW5n4oCZLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48aT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs
aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Zm9udC13ZWln
aHQ6Ym9sZDtmb250LXN0eWxlOml0YWxpYyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250
PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PGZvbnQgc2l6ZT0iMiIg
Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHlsZTppdGFsaWMiPi0tLSB0
b255DQo8L3NwYW4+PC9mb250PjwvaT48L2I+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi
IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ib2R5Pg0KPC9odG1sPg0K

--_000_2E4BB27CAB87BF43B4207C0E55860F181B5F1Deusaamb103ericsso_--


From nobody Sat Sep 27 09:22:37 2014
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 F12311A1B85 for ; Sat, 27 Sep 2014 09:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 MbwgofYPRy3V for ; Sat, 27 Sep 2014 09:22:32 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0471A1B8E for ; Sat, 27 Sep 2014 09:22:32 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id rd3so4461260pab.6 for ; Sat, 27 Sep 2014 09:22:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Tl80UASGO8Oz5y7hHOnfdOVGZY2bSZIIiHst9xUp8BI=; b=pAneS+PGV4/hTu9asrQMwcK2YsWh8bD5xQyu9ME5gk9MSehWy08zuKf4HxW9pmVdRI kf5F/QfDSfo2w1MyurIF+3SYMznOmN4sLesMo+68Ti8Wq03+Mgj2B62wxWQulHe2aAcM JL0yvIEc+QVoVUZPEYCstcvnsDl1b4RH3XPZzKPkAd++IryC+wzhJOU+uts2UmnidRWw C1nAYXSBBS3izgN2JiGCmrJTL2HHe10oMONW+e/xs0jZgE9qVEKvu2lPzSwwg3Qjp7vh 9Hx0UQ0fktGKa+docQM93aloMVhjhDPCI19dkmDEIhWiZy0gGO0pl1XSOC2jXJnpMShD rSzQ==
X-Received: by 10.68.65.71 with SMTP id v7mr9950228pbs.6.1411834952232; Sat, 27 Sep 2014 09:22:32 -0700 (PDT)
Received: from [10.115.26.212] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id qp9sm7910848pbc.31.2014.09.27.09.22.31 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Sep 2014 09:22:31 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-90D4F96A-8777-4C15-89AC-02077A9E3A5D
Mime-Version: 1.0 (1.0)
From: Dino Farinacci 
X-Mailer: iPhone Mail (12A405)
In-Reply-To: 
Date: Sat, 27 Sep 2014 09:22:29 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <30386970-B544-4BD5-B673-87FB2453F7B9@gmail.com>
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>    
To: "Nagendra Kumar Nainar (naikumar)" 
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/2csz_YEwdm9ZRCd45YAFDo3nkjs
Cc: "Eric Rosen \(erosen\)" , "bier@ietf.org" , "IJsbrand Wijnands \(iwijnand\)" , Robert Raszuk , Antoni Przygienda 
Subject: Re: [Bier] One specific transition churn ...
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, 27 Sep 2014 16:22:34 -0000

--Apple-Mail-90D4F96A-8777-4C15-89AC-02077A9E3A5D
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

> Take SPRING IPv6 ... why extension header could not list all egress nodes a=
s well as =E2=80=8B     =E2=80=8Blist of transit BFRs where replication to s=
aid egress nodes is to take place ?=20

Even though this is a horrible idea since the length of the packet would be s=
o large even past the point where people complain about GRE, VXLAN, and LISP=
 headers adding overhead. And they typically are only 16 bytes. Also, you wo=
uld have to make even more copies of the packet since the SI would have to b=
e smaller when encoding full addresses.=20

But the fact people will have to manage yet another address space (ie BFR-ID=
s) makes you wonder if the OpEx will be any less than the points made in the=
 problem statement ID.=20

Dino=

--Apple-Mail-90D4F96A-8777-4C15-89AC-02077A9E3A5D
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


T=
ake SPRING IPv6 ... why extension header could not list all egress nodes as w=
ell as =E2=80=8B

   


=E2=80=8Blist of transit BFRs where replication to said egress nodes is to t=
ake place ? 

Even though this is a horrible idea si=
nce the length of the packet would be so large even past the point where peo=
ple complain about GRE, VXLAN, and LISP headers adding overhead. And they ty=
pically are only 16 bytes. Also, you would have to make even more copies of t=
he packet since the SI would have to be smaller when encoding full addresses=
. 

But the fact people will have to manage yet=
 another address space (ie BFR-IDs) makes you wonder if the OpEx will be any=
 less than the points made in the problem statement ID. 

=

Dino
=

--Apple-Mail-90D4F96A-8777-4C15-89AC-02077A9E3A5D--


From nobody Sat Sep 27 10:07:39 2014
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 432121A1BD4 for ; Sat, 27 Sep 2014 10:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 CJG5sYLLWJjh for ; Sat, 27 Sep 2014 10:07:34 -0700 (PDT)
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 0EF111A1BB8 for ; Sat, 27 Sep 2014 10:07:33 -0700 (PDT)
X-AuditID: c618062d-f79206d0000014d2-2e-54269876b80f
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A6.CC.05330.67896245; Sat, 27 Sep 2014 12:59:02 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Sat, 27 Sep 2014 13:07:31 -0400
From: Antoni Przygienda 
To: Dino Farinacci , "Nagendra Kumar Nainar (naikumar)" 
Thread-Topic: [Bier] One specific transition churn ...
Thread-Index: AQHP2a+BuVUit1FzlkuzW2MzFDiDwZwTq93QgABarwCAABklgIAACfKAgAETewCAADEHgP//xy7w
Date: Sat, 27 Sep 2014 17:07:30 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181B5F52@eusaamb103.ericsson.se>
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>     <30386970-B544-4BD5-B673-87FB2453F7B9@gmail.com>
In-Reply-To: <30386970-B544-4BD5-B673-87FB2453F7B9@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F181B5F52eusaamb103ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXRPuG7ZDLUQgxu9mhZLZ+xhslh3dxKL Rfvua4wWr+bcYbZ4PXEqm0XTwiZmBzaPKb83snrsnHWX3WPJkp9MHrs3LmAKYInisklJzcks Sy3St0vgynjbs5ul4JBHxcSjGg2MB9y6GDk4JARMJN59C+5i5AQyxSQu3FvP1sXIxSEkcJRR YkHXLiYIZzmjxKmHb5lBqtgELCQuf3sKZosIJEvcXzOTFaSIWWAJo8TxHZfZQBLCAqYSsy68 Y4EoMpO4svExK4QdJXG+bRpYnEVAVeL/sqOMIDavgLfEhv89YHEhgfvMEm/P54PYnAK2Epde XmMHsRmBzvt+ag0TiM0sIC5x68l8JoizBSSW7DnPDGGLSrx8/I8VwlaS+Ph7PjvIl8wC+RKb VxtCrBKUODnzCcsERtFZSCbNQqiahaQKIqwpsX6XPkS1osSU7ofsELaGROucuezI4gsY2Vcx cpQWp5blphsZbGIExuIxCTbdHYx7XloeYhTgYFTi4X3wUDVEiDWxrLgy9xCjNAeLkjjvrNp5 wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYnd98n6xhlddjdee+y8UFm3g6BHy6Hf4etzpQ cNq/vC33zcrnDxe8tuLoEDinLD7hubLoiv46ERvJIz5mJQlft1QWiRQlmK1XVoupTJx5J/3F Ycvjeodmip66Hl5qJOvJvme65KTMmAMx72ssSy4t+VvOXF7wUSe6LdT9TQZHl+nv/06bD4sr sRRnJBpqMRcVJwIAKjGsDaYCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/WMJtexp1pReGUk6aII-Hdw6fYcY
Cc: "Eric Rosen \(erosen\)" , "bier@ietf.org" , "IJsbrand Wijnands \(iwijnand\)" , Robert Raszuk 
Subject: Re: [Bier] One specific transition churn ...
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, 27 Sep 2014 17:07:36 -0000

--_000_2E4BB27CAB87BF43B4207C0E55860F181B5F52eusaamb103ericsso_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCkJ1dCB0aGUgZmFjdCBwZW9wbGUgd2lsbCBoYXZlIHRvIG1hbmFnZSB5ZXQgYW5vdGhlciBh
ZGRyZXNzIHNwYWNlIChpZSBCRlItSURzKSBtYWtlcyB5b3Ugd29uZGVyIGlmIHRoZSBPcEV4IHdp
bGwgYmUgYW55IGxlc3MgdGhhbiB0aGUgcG9pbnRzIG1hZGUgaW4gdGhlIHByb2JsZW0gc3RhdGVt
ZW50IElELg0KDQpEaW5vDQoNCltUb255IHNhaWRdICBIZXkgOy0pICAgeWVwcCwgJCQkIE9wRXgv
Q2FwRXggc3BlbmRpbmcgbGVzcyBvciBzYW1lIGlzIHRoZSBfcmVhbF8gcXVlc3Rpb24gYXMgdG8g
d2hldGhlciBCSUVSIHNob3VsZCBiZSBicmV3ZWQgOy0pICAgTGVzcyByZXBsaWNhdGlvbiA9IGxl
c3MgbW9uZXkgc3BlbnQgb24gQ2FwZVggYnV0IG1WUE4gdXNpbmcgb3RoZXIgUE1TSXMgY2FuIGRv
IHRoYXQuICBOZXcgYWRkcmVzc2luZyA9IG1vcmUgbW9uZXkgc3BlbnQgb24gT3BFeCAoQklFUiBj
b250cm9sbGVycyA7LSkgYnV0IHRoYXQgY2FuIGJlIGhhbmRsZWQgYnkgYXV0b2NvbmZpZ3VyYXRp
b24gYXMgd2VsbCA7LSkgSWYgaW50ZXJlc3RlZCBpbiB0aGF0LCBwaW5nIG1lIHByaXZhdGVseSwg
SSBoYXZlIHNvbWUgYW1vdW50IG9mIHdvcmsgcHV0IGludG8gZmFpcmx5IHJlYWRhYmxlIGZvcm1h
dCBmb3IgdGhhdCBwcm9ibGVtIGRvbmUgYWxyZWFkeS4NCg0KT3ZlcmFsbCwgbWF5YmUgdGhlIHF1
ZXN0aW9uIGlzIGV2ZW4gT3BleC9DYXBleCBydW5uaW5nIGFsbCB0aGUgTUNhc3QgbWFjaGluZXJ5
IG5lY2Vzc2FyeSB0b2RheSAocHJvdG9jb2wgT3BFeCkgZm9yIE1DYXN0IHVuZGVyIG5ldyBzZXJ2
aWNlcyBzdWNoIGFzIG1WUE4gdnMuIGp1c3QgcnVubmluZyBCSUVSIFBNU0kgIHRvIGRvIHRoZSBz
YW1lLiBNeSBkaXN0aW5jdCBmZWVsaW5nIHdhcyB0aGF0IEJJRVIgd2lsbCBiZSBhIHdpbiAoaWYg
YWxsIHRoZSBob29rcyBhcmUgaW4gcGxhY2UgdG8gc2NhbGUgaXQpICYgdGhhdCB3aGF0IGF0dHJh
Y3RlZCBtZSB0byBnZXQgZHJhZ2dlZCBpbnRvIGNvdXBsZSBkaXNjdXNzaW9ucyBvdmVyIGhpZ2gt
cXVhbGl0eSBiZWVyIDstKQ0KDQotLS0gdG9ueQ0KDQo=

--_000_2E4BB27CAB87BF43B4207C0E55860F181B5F52eusaamb103ericsso_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v
bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41
aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl
Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv
Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh
eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv
bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO
LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u
MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0Ij5CdXQgdGhlIGZhY3QgcGVvcGxlIHdpbGwgaGF2ZSB0byBtYW5hZ2Ug
eWV0IGFub3RoZXIgYWRkcmVzcyBzcGFjZSAoaWUgQkZSLUlEcykgbWFrZXMgeW91IHdvbmRlciBp
ZiB0aGUgT3BFeCB3aWxsIGJlIGFueSBsZXNzIHRoYW4gdGhlIHBvaW50cyBtYWRlIGluIHRoZSBw
cm9ibGVtIHN0YXRlbWVudA0KIElELiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNl
PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdCI+RGlubzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIg
ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7
Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0eWxlOml0YWxpYyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9mb250PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PGZvbnQg
c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHlsZTppdGFs
aWMiPltUb255IHNhaWRdICZuYnNwO0hleSA7LSkmbmJzcDsmbmJzcDsgeWVwcCwgJCQkIE9wRXgv
Q2FwRXggc3BlbmRpbmcgbGVzcyBvciBzYW1lIGlzDQogdGhlIF88L3NwYW4+PC9mb250PjwvaT48
L2I+PGI+PGk+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO2ZvbnQtd2VpZ2h0OmJvbGQ7
Zm9udC1zdHlsZTppdGFsaWMiPnJlYWw8L3NwYW4+PC9mb250PjwvaT48L2I+PGI+PGk+PGZvbnQg
c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHlsZTppdGFs
aWMiPl8NCiBxdWVzdGlvbiBhcyB0byB3aGV0aGVyIEJJRVIgc2hvdWxkIGJlIGJyZXdlZCA7LSkm
bmJzcDsmbmJzcDsgTGVzcyByZXBsaWNhdGlvbiA9IGxlc3MgbW9uZXkgc3BlbnQgb24gQ2FwZVgg
YnV0IG1WUE4gdXNpbmcgb3RoZXIgUE1TSXMgY2FuIGRvIHRoYXQuJm5ic3A7IE5ldyBhZGRyZXNz
aW5nID0gbW9yZSBtb25leSBzcGVudCBvbiBPcEV4IChCSUVSIGNvbnRyb2xsZXJzIDstKSBidXQg
dGhhdCBjYW4gYmUgaGFuZGxlZCBieSBhdXRvY29uZmlndXJhdGlvbiBhcyB3ZWxsIDstKQ0KIElm
IGludGVyZXN0ZWQgaW4gdGhhdCwgcGluZyBtZSBwcml2YXRlbHksIEkgaGF2ZSBzb21lIGFtb3Vu
dCBvZiB3b3JrIHB1dCBpbnRvIGZhaXJseSByZWFkYWJsZSBmb3JtYXQgZm9yIHRoYXQgcHJvYmxl
bSBkb25lIGFscmVhZHkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9pPjwvYj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIg
ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7
Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0eWxlOml0YWxpYyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9mb250PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PGZvbnQg
c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHlsZTppdGFs
aWMiPk92ZXJhbGwsIG1heWJlIHRoZSBxdWVzdGlvbiBpcyBldmVuIE9wZXgvQ2FwZXggcnVubmlu
ZyBhbGwgdGhlIE1DYXN0DQogbWFjaGluZXJ5IG5lY2Vzc2FyeSB0b2RheSAocHJvdG9jb2wgT3BF
eCkgZm9yIE1DYXN0IHVuZGVyIG5ldyBzZXJ2aWNlcyBzdWNoIGFzIG1WUE4gdnMuIGp1c3QgcnVu
bmluZyBCSUVSIFBNU0kgJm5ic3A7dG8gZG8gdGhlIHNhbWUuIE15IGRpc3RpbmN0IGZlZWxpbmcg
d2FzIHRoYXQgQklFUiB3aWxsIGJlIGEgd2luIChpZiBhbGwgdGhlIGhvb2tzIGFyZSBpbiBwbGFj
ZSB0byBzY2FsZSBpdCkgJmFtcDsgdGhhdCB3aGF0IGF0dHJhY3RlZCBtZSB0byBnZXQgZHJhZ2dl
ZA0KIGludG8gY291cGxlIGRpc2N1c3Npb25zIG92ZXIgaGlnaC1xdWFsaXR5IGJlZXIgOy0pIDxv
OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxpPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDtmb250LXdlaWdodDpib2xkO2Zv
bnQtc3R5bGU6aXRhbGljIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9pPjwvYj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm
NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0Q7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0eWxlOml0YWxpYyI+LS0tIHRvbnkNCjxvOnA+
PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm
b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m
b250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_2E4BB27CAB87BF43B4207C0E55860F181B5F52eusaamb103ericsso_--


From nobody Sat Sep 27 11:44:22 2014
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 CED431A1BF2 for ; Sat, 27 Sep 2014 11:44:20 -0700 (PDT)
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 jx_KAV7ksxVd for ; Sat, 27 Sep 2014 11:44:19 -0700 (PDT)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABA41A0154 for ; Sat, 27 Sep 2014 11:44:18 -0700 (PDT)
Received: by mail-pd0-f171.google.com with SMTP id y13so14808941pdi.2 for ; Sat, 27 Sep 2014 11:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EzcHzCDK3g0tKZe0p5jQQKd9HChooYYvs2c9OxyQ7vA=; b=ZPkpXCQ/v+0EtR1KV4Ald1+wk13FeoRExi7QFRUOoteBYnBSL4FP8Yc6YgmBwZ9CLj 2Fzhpa5L41kkHYK2gJ2jb51XX63Rj2G52KjJCKO9w0X5Vz0IyRkjjh+ECZg02QchH+g6 DBwoCfveGP42+XDV0SoQ8T2qdSoXeUu0vSACl9NjUM6ku2muDUwfH4CteXdPYgSAVfGX 9SV+I4uS6xIJksv1cDfYzvFqNUmz5sbkMQBC4XT2duoA4dV1duJJPXl8x1ObasAMa2ci vMcczzDmWtQ7e7AGFrJcpx52EjwfhGh2U1SrL9czf0qqTmkH+spBGFnt6mMOU3WavLrL u5Tg==
X-Received: by 10.66.243.208 with SMTP id xa16mr35341909pac.41.1411843458509;  Sat, 27 Sep 2014 11:44:18 -0700 (PDT)
Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id fr7sm8124929pdb.79.2014.09.27.11.44.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Sep 2014 11:44:17 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Dino Farinacci 
In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F181B5F52@eusaamb103.ericsson.se>
Date: Sat, 27 Sep 2014 11:43:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>     <30386970-B544-4BD5-B673-87FB2453F7B9@gmail.com> <2E4BB27CAB87BF43B4207C0E55860F181B5F52@eusaamb103.ericsson.se>
To: Antoni Przygienda 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/WB-WXwwtk8QZTNzs387iETNhYMU
Cc: "Nagendra Kumar Nainar \(naikumar\)" , "bier@ietf.org" , "IJsbrand \(Ice\) Wijnands" , "Eric Rosen \(erosen\)" , Robert Raszuk 
Subject: Re: [Bier] One specific transition churn ...
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, 27 Sep 2014 18:44:21 -0000

> But the fact people will have to manage yet another address space (ie =
BFR-IDs) makes you wonder if the OpEx will be any less than the points =
made in the problem statement ID.=20

Not to mention a new adjacency protocol and mapping between the routes =
the IGP/unicast-routing computes to BFR-IDs. There is a dependency there =
just like there was a dependency of RPF on unicast routing in =
traditional IP multicast.

The clever part of the idea, is to encode a list of things (BFERs) in a =
small encoding space. IMO, better than a general source-route. But that =
comes a cost because you need BFR-IDs and SIs.

I'm also concerned the way this is being marketed. The term "overlay" is =
being used in many places. Well the original definition of overlay means =
you don't have to change the center or core of the network. What is =
being proposed is exactly that, change the core so native replication =
can occur but keep the edges (multicast sourcs and receivers and =
potentially PIM routers at existing domains) untouched.

> Dino
> =20
> [Tony said]  Hey ;-)   yepp, $$$ OpEx/CapEx spending less or same is =
the _real_ question as to whether BIER

Well with enough thrust anything can fly. You want to brew if you are =
really sure people want to taste it. ;-)

> should be brewed ;-)   Less replication =3D less money spent on CapeX =
but mVPN using other PMSIs can do that.

Well traditional IP multicast and MPLS multicast has less replication. =
And mVPNs, as designed, and deployed are limited to specific provider =
and have scaling issue because the functionality in PEs limits the =
number of customers you can really add.

>  New addressing =3D more money spent on OpEx (BIER controllers ;-) but =
that can be handled by autoconfiguration as well ;-) If interested in =
that, ping me privately, I have some amount of work put into fairly =
readable format for that problem done already.

Yes, this argument is used a lot. Build complexity in the system so it =
has a certain level of robustness. Then you hide the complexity with =
network management. If you haven't noticed, we have been trying to =
recently fix network management the last couple of years (read: SDN). =
But it doesn't matter, when things go wrong, you MUST know how the =
protocol works and you must understand the elements involved (network =
entities) and the elements of operation. And things always go wrong.  =
;-)

> Overall, maybe the question is even Opex/Capex running all the MCast =
machinery necessary today (protocol OpEx) for MCast under new services =
such as mVPN vs. just running BIER PMSI  to do the same. My distinct =
feeling was that BIER will be a win (if all the hooks are in place to =
scale it) & that what attracted me to get dragged into couple =
discussions over high-quality beer ;-)
> =20
> --- tony

What is being proposed can be done with typical overlay multicast and I =
know the authors are aware of the multicast work done in the LISP WG. =
When you do a true multicast overlay, then you can put the edges =
ANYWHERE in the network because you don't have to change the core AT =
ALL.

The LISP overlay multicast proposals have traditional signaling =
approaches only to interoperate with IGMP and PIM domains, but there is =
also a signal-free proposal that avoids building distribution trees. And =
you do make use of unicast forwarding (and not BFR forwarding which is a =
completely new data-plane) so OpEx is lowered dramstically because you =
are using legacy/traditional unicast forwarding methods.

Dino



From nobody Sat Sep 27 12:02:16 2014
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 8220E1A1B55 for ; Sat, 27 Sep 2014 12:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Level: 
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 pKnihMuv_XKt for ; Sat, 27 Sep 2014 12:02:13 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 D14EA1A1BB3 for ; Sat, 27 Sep 2014 12:02:13 -0700 (PDT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 5BC822C817CD6 for ; Sat, 27 Sep 2014 19:02:09 +0000 (GMT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s8RJ2BnS027682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 27 Sep 2014 15:02:11 -0400
Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 27 Sep 2014 15:02:11 -0400
Received: from SG70XWXCHMBA03.zap.alcatel-lucent.com ([169.254.3.2]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.03.0195.001; Sun, 28 Sep 2014 03:02:07 +0800
From: "S, Somasundaram (Somasundaram)" 
To: "bier@ietf.org" 
Thread-Topic: BIER Encapsulation..
Thread-Index: Ac/ahYdvK4toTl6uQ0KSE7Bnd0RxXQ==
Date: Sat, 27 Sep 2014 19:02:06 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.253.19.18]
Content-Type: multipart/alternative; boundary="_000_A11CB189CA381D4E8002572EFF81F18B1F6AC570SG70XWXCHMBA03z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/Qggajk15LrpHSpzcgtKt5KumagA
Subject: [Bier] BIER Encapsulation..
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, 27 Sep 2014 19:02:15 -0000

--_000_A11CB189CA381D4E8002572EFF81F18B1F6AC570SG70XWXCHMBA03z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Regarding *draft-wijnands-mpls-bier-encapsulation-00*

Given that  BIER packets packets are MPLS encapsulated (SI is identified ba=
sed on the Label), how would forwarding take place in a pure IGP domain (wh=
ere MPLS is not configured/supported)?

Regards
Somasundaram

--_000_A11CB189CA381D4E8002572EFF81F18B1F6AC570SG70XWXCHMBA03z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Regarding *draft-wijnands-mpls-bier-encapsulation-00=
*


 


Given that  BIER packets packets are MPLS encap=
sulated (SI is identified based on the Label), how would forwarding take pl=
ace in a pure IGP domain (where MPLS is not configured/supported)?



 


Regards


Somasundaram






--_000_A11CB189CA381D4E8002572EFF81F18B1F6AC570SG70XWXCHMBA03z_--


From nobody Sat Sep 27 12:03:28 2014
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 B13441A1B55 for ; Sat, 27 Sep 2014 12:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 ne-97-mhjj0S for ; Sat, 27 Sep 2014 12:03:25 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E871A014B for ; Sat, 27 Sep 2014 12:03:25 -0700 (PDT)
Received: by mail-ig0-f169.google.com with SMTP id uq10so182918igb.4 for ; Sat, 27 Sep 2014 12:03:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=e7KbnNZ3GrUat3BlJkcUnn71ttU19BiDmikWgOQGxeE=; b=lHCJD6kOTG0MbzRG0XelmkxpqRF6Wgiat6dCH8e2QRtjKlZwteYCKxi2FUfatnR2a6 iY2jUULxse60dg8YSx/8LVOVNSOwZykCbUzxW/zPipz0jzPAWe3ReGW0X0O6HbXVDntO ag4OKZFe82laTzVk2zNRZjmaUHfkFkY1/+/8GgpCzroyjrHUP40LKpDvEv+BNeXf+8np sPJ5tM/nbBkTBG0v11erBc1jahohCCaX0xQCiDCSz2tODI9HLCGiI0bdfG6gyfVQqoxG KrUAXRx+8+KCf/A+SjXKocjQuGbK736DkYUtwEI37lv3/FOUwvd9pzUbGkin7OFidk9F FjxA==
MIME-Version: 1.0
X-Received: by 10.42.247.137 with SMTP id mc9mr35423658icb.13.1411844604557; Sat, 27 Sep 2014 12:03:24 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.166.8 with HTTP; Sat, 27 Sep 2014 12:03:24 -0700 (PDT)
In-Reply-To: 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>     <30386970-B544-4BD5-B673-87FB2453F7B9@gmail.com> <2E4BB27CAB87BF43B4207C0E55860F181B5F52@eusaamb103.ericsson.se> 
Date: Sat, 27 Sep 2014 21:03:24 +0200
X-Google-Sender-Auth: fggkgMQTIQ6hbTapJTewhCBtSbs
Message-ID: 
From: Robert Raszuk 
To: Dino Farinacci 
Content-Type: multipart/alternative; boundary=20cf3005db1a220201050410b00e
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/uMCASYuc9SCydYhnYz7Kt9wUI34
Cc: "bier@ietf.org" , "Nagendra Kumar Nainar \(naikumar\)" , Antoni Przygienda , "IJsbrand \(Ice\) Wijnands" , "Eric Rosen \(erosen\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 27 Sep 2014 19:03:26 -0000

--20cf3005db1a220201050410b00e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> What is being proposed can be done with typical overlay multicast and I
> know the authors are aware of the multicast work done in the LISP WG. Whe=
n
> you do a true multicast overlay, then you can put the edges ANYWHERE in t=
he
> network because you don't have to change the core AT ALL.
>

=E2=80=8BAnd that IMO would be much better option all together rather then =
keep
upgrading routers and their OSes all the time :)

Btw while not a BIER question how does LISP m-cast compares with
http://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01

=E2=80=8BOr for that matter with peercasting ? =E2=80=8B

=E2=80=8B- - - =E2=80=8B

=E2=80=8BAs to BIER how is it suppose to work in say DC environment where I=
 run BGP
and no IGP at all ? Just like described here:

http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-07

Thx,
=E2=80=8Br.=E2=80=8B

--20cf3005db1a220201050410b00e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


=C2=A0
What is being proposed can be done with typic=
al overlay multicast and I know the authors are aware of the multicast work=
 done in the LISP WG. When you do a true multicast overlay, then you can pu=
t the edges ANYWHERE in the network because you don't have to change th=
e core AT ALL.

=
=E2=80=8BAnd that IMO would be much better option all together rather then =
keep upgrading routers and their OSes all the time :)

Btw while not a BIER question how=
 does LISP m-cast compares with=C2=A0http://tools.ietf.org/html/draft-marques=
-l3vpn-mcast-edge-01

=E2=80=
=8BOr for that matter with peercasting ? =E2=80=8B

=E2=80=8B- - - =E2=
=80=8B

=E2=80=
=8BAs to BIER how is it suppose to work in say DC environment where I run B=
GP and no IGP at all ? Just like described here:=C2=A0

http://tools.ietf.=
org/html/draft-lapukhov-bgp-routing-large-dc-07

Thx,
=E2=80=8Br.=
=E2=80=8B



--20cf3005db1a220201050410b00e--


From nobody Sat Sep 27 12:58:06 2014
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 E26A31A0ABD for ; Sat, 27 Sep 2014 12:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 BQavIE1w_DMC for ; Sat, 27 Sep 2014 12:58:04 -0700 (PDT)
Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396981A0208 for ; Sat, 27 Sep 2014 12:58:04 -0700 (PDT)
Received: by mail-pd0-f182.google.com with SMTP id y10so3055781pdj.27 for ; Sat, 27 Sep 2014 12:58:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=x20XysR8IXPAhmjNwJroCMQ9P/Gtfl1PiMi5mq3bRq0=; b=o9nG78/S+XLYLser6qivVaeRxwdAD51NRXUBmGcANPbd1K7W6RgJ3odqtCQ92onGfx cM4Gm9t8FfI87M41/D/yPqhUkpYUwqi1ia36ZnRIY9MBVQt0zh/nSNcMIMywIbPTRmM4 WzymsUNrxLGfRCpu2PFDQ2oHkvMc4/aMUlPY96wI/aZltUCAAhqdHzRVzPyBT9Gn3HKu WAzFo5G7GFkWXO1WNvFCge0+H4I5WCo94hsre/8uLtydCmB+hojlKwhAf0/si2BfTsZl SWZwWCgnjHBC0c6Fi8KK8TWOSzXi+ElL0Zi5tFAA0nRUdU6gq3DkQHOL0b3QkwfPhleu MtCQ==
X-Received: by 10.68.202.225 with SMTP id kl1mr44149113pbc.21.1411847883817; Sat, 27 Sep 2014 12:58:03 -0700 (PDT)
Received: from [192.168.1.51] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id xq4sm8290014pac.21.2014.09.27.12.58.02 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Sep 2014 12:58:02 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-51222913-E90C-49A3-99EC-FBA5527AED74
Mime-Version: 1.0 (1.0)
From: Dino Farinacci 
X-Mailer: iPhone Mail (12A405)
In-Reply-To: 
Date: Sat, 27 Sep 2014 12:58:02 -0700
Content-Transfer-Encoding: 7bit
Message-Id: 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>     <30386970-B544-4BD5-B673-87FB2453F7B9@gmail.com> <2E4BB27CAB87BF43B4207C0E55860F181B5F52@eusaamb103.ericsson.se>  
To: Robert Raszuk 
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/2Pfvf13N1ZFbHGjA-TOPkPJs360
Cc: "bier@ietf.org" , "Nagendra Kumar Nainar \(naikumar\)" , Antoni Przygienda , "IJsbrand \(Ice\) Wijnands" , "Eric Rosen \(erosen\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 27 Sep 2014 19:58:06 -0000

--Apple-Mail-51222913-E90C-49A3-99EC-FBA5527AED74
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

>=20
>  does LISP m-cast compares with http://tools.ietf.org/html/draft-marques-l=
3vpn-mcast-edge-01
>=20
> =E2=80=8BOr for that matter with peercasting ? =E2=80=8B

I don't know. I have not read either of them. But as usual there are only so=
 many ways to solve similar problems so there is likely some overlap in the s=
olution space.=20

Dino=

--Apple-Mail-51222913-E90C-49A3-99EC-FBA5527AED74
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


http://tools.ietf.org/html/draf=
t-marques-l3vpn-mcast-edge-01

=E2=80=8B=
Or for that matter with peercasting ? =E2=80=8B

=

I don't know. I have not read either of them. But as usual there are on=
ly so many ways to solve similar problems so there is likely some overlap in=
 the solution space. 

Dino
=

--Apple-Mail-51222913-E90C-49A3-99EC-FBA5527AED74--


From nobody Sat Sep 27 20:49:04 2014
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 2859B1A01D0 for ; Sat, 27 Sep 2014 20:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 TVOc3VOm2TXD for ; Sat, 27 Sep 2014 20:49:00 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C16F1A01A9 for ; Sat, 27 Sep 2014 20:48:59 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJZ60078; Sun, 28 Sep 2014 03:48:57 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 28 Sep 2014 04:48:55 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Sun, 28 Sep 2014 11:48:47 +0800
From: Xuxiaohu 
To: "S, Somasundaram (Somasundaram)" , "bier@ietf.org" 
Thread-Topic: BIER Encapsulation..
Thread-Index: Ac/ahYdvK4toTl6uQ0KSE7Bnd0RxXQARHo9g
Date: Sun, 28 Sep 2014 03:48:46 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC5D8@NKGEML512-MBS.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC5D8NKGEML512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/dPMcELF7OwrXqpofU9B-XZZlEBA
Subject: Re: [Bier] BIER Encapsulation..
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, 28 Sep 2014 03:49:03 -0000

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC5D8NKGEML512MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is a very good question. Since BIER introduces a totally new forwardin=
g paradigm, why not make the BIER encapsulation transport-independent? In o=
ther words, the BIER header is allowed to be contained in an Ethernet heade=
r, an MPLS header, an IP header and etc. Furthermore, the transport is only=
 intended for delivering the BIER-encapsulated packet to the BFR Neighbors =
while the SI and MTID could be directly derived from the BIER header.

Best regards,
Xiaohu

From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of S, Somasundaram (Som=
asundaram)
Sent: Sunday, September 28, 2014 3:02 AM
To: bier@ietf.org
Subject: [Bier] BIER Encapsulation..

Regarding *draft-wijnands-mpls-bier-encapsulation-00*

Given that  BIER packets packets are MPLS encapsulated (SI is identified ba=
sed on the Label), how would forwarding take place in a pure IGP domain (wh=
ere MPLS is not configured/supported)?

Regards
Somasundaram

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC5D8NKGEML512MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











This is a very good question. Since BIER introduces a totally new=
 forwarding paradigm, why not make the BIER encapsulation transport-indepen=
dent? In other words, the BIER header
 is allowed to be contained in an Ethernet header, an MPLS header, an IP he=
ader and etc. Furthermore, the transport is only intended for delivering th=
e BIER-encapsulated packet to the BFR Neighbors while the SI and MTID could=
 be directly derived from the BIER
 header.


 


Best regards,


Xiaohu


 








From: BIER [mailto:bier-bounces@ietf.org]
On Behalf Of S, Somasundaram (Somasundaram)

Sent: Sunday, September 28, 2014 3:02 AM

To: bier@ietf.org

Subject: [Bier] BIER Encapsulation..






 


Regarding *draft-wijnands-mpls-=
bier-encapsulation-00*


 


Given that  BIER packets p=
ackets are MPLS encapsulated (SI is identified based on the Label), how wou=
ld forwarding take place in a pure IGP domain (where MPLS is not configured=
/supported)?



 


Regards


Somasundaram<=
/p>







--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC5D8NKGEML512MBSchi_--


From nobody Sat Sep 27 22:11:28 2014
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 5A1F41A02E7 for ; Sat, 27 Sep 2014 22:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 pwufLXOTm-wb for ; Sat, 27 Sep 2014 22:11:17 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2981A02DE for ; Sat, 27 Sep 2014 22:11:16 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNB82024; Sun, 28 Sep 2014 05:11:14 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 28 Sep 2014 06:11:14 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Sun, 28 Sep 2014 13:11:07 +0800
From: Xuxiaohu 
To: IJsbrand Wijnands , "adrian@olddog.co.uk" 
Thread-Topic: [Bier] MPLS encapsulation
Thread-Index: AQHP2amQQPBQ9OujR6OJTMN+0P37n5wTgHcAgADEqQCAAajKYA==
Date: Sun, 28 Sep 2014 05:11:06 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC602@NKGEML512-MBS.china.huawei.com>
References: Your message of Fri, 26 Sep 2014 16:11:17 +0100. <051501cfd99c$205b1780$61114680$@olddog.co.uk> <9767.1411750052@erosen-lnx> <065a01cfd9dc$f45f1be0$dd1d53a0$@olddog.co.uk> <873A5047-32D7-4AAB-ABE7-FF8C23166C1F@cisco.com>
In-Reply-To: <873A5047-32D7-4AAB-ABE7-FF8C23166C1F@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/1gQpR1tStWokn-87RWo5G95K8tM
Cc: "erosen@cisco.com" , "bier@ietf.org" 
Subject: Re: [Bier] MPLS encapsulation
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, 28 Sep 2014 05:11:23 -0000

> -----Original Message-----
> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand Wijnands
> Sent: Saturday, September 27, 2014 6:39 PM
> To: adrian@olddog.co.uk
> Cc: erosen@cisco.com; bier@ietf.org
> Subject: Re: [Bier] MPLS encapsulation
>=20
> Hi Adrian,
>=20
> > My point is that you are advocating the advertisement of a block of
> > labels by the IGP, and the use of one or more labels on the MPLS stack.=
 And my
> question:
> > why do this? You could hit the bottom of stack as normal, use the
> > control word to identify BIER and put all of the information you need
> > (currently deduced from the BIER-MPLS label(s) ) into the BIER header.

I'm in favor of Adrian's proposal of putting all of the information you nee=
d (i.e., SI and MT-ID information which is currently deduced from the BIER-=
MPLS label) into the BIER header.

> Just one clarification, in normal operation, we expect just one BIER labe=
l to be on
> the stack. Unless we sent a BIER packet over a P2P/FRR LSP, then you'll s=
ee two.
> But for the BIER procedures, only the BIER label is relevant.
>=20
> > I'm not saying that would be better. Just asking why the choice you hav=
e
> made.
>=20
> Right, but the control word also has to be indicated by the top label, ri=
ght? How
> would the forwarding plane otherwise know a control word is following at =
the
> bottom of the stack... So, using the control would just mean an additiona=
l
> indirection, while we can have a immediate indirection with a BIER-MPLS l=
abel.

Provided the SI and MT-ID information is carried within the BIER header, it=
 seems that you only need a way to indicate the MPLS payload is a BIER.

Best regards,
Xiaohu

> Thx,
>=20
> Ice.
>=20
> >
> > Cheers,
> > Adrian
> >
> >> -----Original Message-----
> >> From: Eric Rosen [mailto:erosen@cisco.com]
> >> Sent: 26 September 2014 17:48
> >> To: adrian@olddog.co.uk
> >> Cc: bier@ietf.org
> >> Subject: Re: [Bier] MPLS encapsulation
> >>
> >> Adrian,
> >>
> >> I'm a little confused about your question: are you using the term
> >> "special purpose label" in the sense of RFC 7274 ("Allocating and
> >> Retiring Special-Purpose MPLS Labels")?  If so, there is no use of
> >> special purpose labels (in this sense) being proposed.
> >>
> >> Did I misunderstand your question?
> >>
> >> Eric
> >>
> >
> >
> > _______________________________________________
> > BIER mailing list
> > BIER@ietf.org
> > https://www.ietf.org/mailman/listinfo/bier
>=20
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier


From nobody Sat Sep 27 22:23:37 2014
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 294861A02F7 for ; Sat, 27 Sep 2014 22:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 hVREqiKJhYDu for ; Sat, 27 Sep 2014 22:23:33 -0700 (PDT)
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 E59811A02F5 for ; Sat, 27 Sep 2014 22:23:32 -0700 (PDT)
X-AuditID: c6180641-f79916d00000623a-02-5427427df66f
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 60.0B.25146.D7247245; Sun, 28 Sep 2014 01:04:29 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Sun, 28 Sep 2014 01:23:22 -0400
From: Antoni Przygienda 
To: Xuxiaohu , IJsbrand Wijnands , "adrian@olddog.co.uk" 
Thread-Topic: [Bier] MPLS encapsulation
Thread-Index: AQHP2amQQPBQ9OujR6OJTMN+0P37n5wUSaIAgADEqACAATanAP//vXCA
Date: Sun, 28 Sep 2014 05:23:22 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181B6095@eusaamb103.ericsson.se>
References: Your message of Fri, 26 Sep 2014 16:11:17 +0100. <051501cfd99c$205b1780$61114680$@olddog.co.uk> <9767.1411750052@erosen-lnx> <065a01cfd9dc$f45f1be0$dd1d53a0$@olddog.co.uk> <873A5047-32D7-4AAB-ABE7-FF8C23166C1F@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC602@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC602@NKGEML512-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXSPn26tk3qIwdflihY/em4wWyydsYfJ Yt3dSSwWr+bcYbbYen4VowOrx5TfG1k9Wo68ZfVYsuQnk8eKzSsZA1iiuGxSUnMyy1KL9O0S uDKOLrzHWrBMuWLbuSdMDYw/pLsYOTkkBEwk/v07xgRhi0lcuLeerYuRi0NI4CijxOKG/YwQ znJGiS0PV7CCVLEJWEhc/vaUGcQWESiReLhsNVicWcBLYlrTKjYQW1hATWLj6kusEDXqEntn 3GKHsN0knpzYC2azCKhKLL7xEGwOr4C3xK9HV5kglu1ikvjy8DZQEQcHp0CYxIsTSiA1jEDX fT+1hglil7jErSfzoa4WkFiy5zwzhC0q8fLxP1YIW0ni4+/57BD1OhILdn9ig7C1JZYtfA21 V1Di5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxchRWpxalptuZLiJERhZxyTYHHcwLvhkeYhR gINRiYf3wUPVECHWxLLiytxDjNIcLErivJrV84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MC5cnL/2CIPuHO8HLE9LPYQeXvvHbTW10ebFmVPSB32Ubs9Vrw9k56zPcH+h0PVvb/uGEPtL Pz2FAxmbDW4unBZSG73+6XcNrzsBPyefdj6ktyI9qtVC4GZE0QzXEkbR2+vyj3ze7d++waTi c9acrXyT+yfclXGoyJ2389NhXc3zLbISd+76PFViKc5INNRiLipOBAC8ckIAjQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/1-McvHQPWLBTxMoRWuoITJmZbjE
Cc: "erosen@cisco.com" , "bier@ietf.org" 
Subject: Re: [Bier] MPLS encapsulation
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, 28 Sep 2014 05:23:35 -0000

I'm not sure whether the discussion is about MPLS encaps for BIER or  any B=
IER encaps.=20

For MPLS, one (very good reason) is that we do have _very_ fast MPLS label =
lookup fast-paths, we do not have MT-ID & Set-ID lookup engines.  SetID is =
arguable as being in encaps but a label representing a set in MPLS is simpl=
y extremely natural to MPLS. MT-ID has actually no business in the fast-pat=
h I would say, the scope of validity of MT-ID is in the IGP control plane o=
nly. Building very complicated networking devices has a lot to do with NOT =
having all concepts showing in every piece of software and hardware, someth=
ing also known as rule 5 of RFC1925. =20

Having said that, different encapsulations (BIER over Avian Carriers) can a=
nd will be written and there is nothing that precludes such an encapsulatio=
n to carry arbitrary amount of information on the packet to be processed.=20

As to MPLS ranges, this is something that is fashionable these days, IMO ea=
ch set should have a completely independent label on it but there are trade=
-offs in terms of control plane complexity/protocol packet sizes vs. fast-p=
ath complexity vs. what people already have in silicon and so on.=20

thanks=20

--- tony=20

> -----Original Message-----
> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Xuxiaohu
> Sent: Saturday, September 27, 2014 10:11 PM
> To: IJsbrand Wijnands; adrian@olddog.co.uk
> Cc: erosen@cisco.com; bier@ietf.org
> Subject: Re: [Bier] MPLS encapsulation
>=20
>=20
>=20
> > -----Original Message-----
> > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand
> > Wijnands
> > Sent: Saturday, September 27, 2014 6:39 PM
> > To: adrian@olddog.co.uk
> > Cc: erosen@cisco.com; bier@ietf.org
> > Subject: Re: [Bier] MPLS encapsulation
> >
> > Hi Adrian,
> >
> > > My point is that you are advocating the advertisement of a block of
> > > labels by the IGP, and the use of one or more labels on the MPLS
> > > stack. And my
> > question:
> > > why do this? You could hit the bottom of stack as normal, use the
> > > control word to identify BIER and put all of the information you
> > > need (currently deduced from the BIER-MPLS label(s) ) into the BIER
> header.
>=20
> I'm in favor of Adrian's proposal of putting all of the information you n=
eed
> (i.e., SI and MT-ID information which is currently deduced from the BIER-
> MPLS label) into the BIER header.
>=20
> > Just one clarification, in normal operation, we expect just one BIER
> > label to be on the stack. Unless we sent a BIER packet over a P2P/FRR L=
SP,
> then you'll see two.
> > But for the BIER procedures, only the BIER label is relevant.
> >
> > > I'm not saying that would be better. Just asking why the choice you
> > > have
> > made.
> >
> > Right, but the control word also has to be indicated by the top label,
> > right? How would the forwarding plane otherwise know a control word is
> > following at the bottom of the stack... So, using the control would
> > just mean an additional indirection, while we can have a immediate
> indirection with a BIER-MPLS label.
>=20
> Provided the SI and MT-ID information is carried within the BIER header, =
it
> seems that you only need a way to indicate the MPLS payload is a BIER.
>=20
> Best regards,
> Xiaohu
>=20
> > Thx,
> >
> > Ice.
> >
> > >
> > > Cheers,
> > > Adrian
> > >
> > >> -----Original Message-----
> > >> From: Eric Rosen [mailto:erosen@cisco.com]
> > >> Sent: 26 September 2014 17:48
> > >> To: adrian@olddog.co.uk
> > >> Cc: bier@ietf.org
> > >> Subject: Re: [Bier] MPLS encapsulation
> > >>
> > >> Adrian,
> > >>
> > >> I'm a little confused about your question: are you using the term
> > >> "special purpose label" in the sense of RFC 7274 ("Allocating and
> > >> Retiring Special-Purpose MPLS Labels")?  If so, there is no use of
> > >> special purpose labels (in this sense) being proposed.
> > >>
> > >> Did I misunderstand your question?
> > >>
> > >> Eric
> > >>
> > >
> > >
> > > _______________________________________________
> > > 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
>=20
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier


From nobody Sat Sep 27 22:31:21 2014
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 AA7A01A0308 for ; Sat, 27 Sep 2014 22:31:08 -0700 (PDT)
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,  HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 oE1Qg7P_nJCJ for ; Sat, 27 Sep 2014 22:31:00 -0700 (PDT)
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 79D721A0306 for ; Sat, 27 Sep 2014 22:31:00 -0700 (PDT)
X-AuditID: c6180641-f79916d00000623a-2d-542744452a7f
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4E.0B.25146.54447245; Sun, 28 Sep 2014 01:12:05 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Sun, 28 Sep 2014 01:30:58 -0400
From: Antoni Przygienda 
To: "bier@ietf.org" 
Thread-Topic: BIER for ISIS
Thread-Index: Ac/a2q5axLILfVoyTu6G1KB4i/S2SQ==
Date: Sun, 28 Sep 2014 05:30:58 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181B60B2@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: multipart/mixed; boundary="_004_2E4BB27CAB87BF43B4207C0E55860F181B60B2eusaamb103ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZXLrHT9fVRT3E4P5dHYulM/YwOTB6LFny kymAMYrLJiU1J7MstUjfLoErY+bDvewFHy8yVvRMWMPcwDj7JGMXIyeHhICJxJLjr1ghbDGJ C/fWs3UxcnEICRxllDj7ZQojhLOcUeJXUy87SBWbgIXE5W9PmUFsEQFlifOHGsHiwkDdyxa2 QcWlJWY+u88OYetJtFx5x9TFyMHBIqAq8WOrIUiYV8Bb4lvXMrByRqDW76fWMIHYzALiEree zGeCOEhE4uHF02wQtqjEy8f/oA5Vkvj4ez47RH2mxIG9+1khZgpKnJz5hGUCo9AsJKNmISmb haQMIp4vMbFhJzuErSOxYPcnNghbG+ib18ww9pkDj5kwxV0lel6fg+q1lDi64SLQfC4g+wij xLMvV6GKFCWmdD9kX8DIs4qRo7Q4tSw33chwEyMw7o5JsDnuYFzwyfIQowAHoxIP74OHqiFC rIllxZW5hxilOViUxHk1q+cFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamA88NFZUPS9peM/ d9MJTXzFkW/P7nXadvX1vnaZCSdro2fMPRgd47BkZ/qMfQGnOh4t/j35bIhJzaWwkxX+Jkk1 P46/vcHDWVwQ074hOOv4hrNbjvxOnJsd5+enLFnPeXFqlUTUNOFAkznpt793bd62XeTUtxPF Msf7Ok5WLXqWMeuKdnUpR9YbJZbijERDLeai4kQAgqgd2pwCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/8lQsJGcRsnd-PPU2nylJQD29N84
Subject: [Bier] BIER for ISIS
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, 28 Sep 2014 05:31:08 -0000

--_004_2E4BB27CAB87BF43B4207C0E55860F181B60B2eusaamb103ericsso_
Content-Type: multipart/alternative;
	boundary="_000_2E4BB27CAB87BF43B4207C0E55860F181B60B2eusaamb103ericsso_"

--_000_2E4BB27CAB87BF43B4207C0E55860F181B60B2eusaamb103ericsso_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Attached ISIS procedures & formats for BIER for consumption. Under manual I=
ETF draft submission currently (automatic XML extraction of my authorship p=
robably fell through due to the 'too many consonants' rule ;-)

The minor diffs to OSPF are a mirror of a very fruitful discussion amongst =
the involved parties as to what is the right consensus. Notably the capacit=
y of the IGP to carry BIER domain ID around.

Have a good read and comments welcome

thanks

--- tony




--_000_2E4BB27CAB87BF43B4207C0E55860F181B60B2eusaamb103ericsso_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Attached ISIS procedures & formats for BIER for consumpt=
ion. Under manual IETF draft submission currently (automatic XML extraction=
 of my authorship probably fell through due
 to the ‘too many consonants’ rule ;-) 


 


The minor diffs to OSPF are a mirror of a very fruitful disc=
ussion amongst the involved parties as to what is the right consensus. Nota=
bly the capacity of the IGP to carry BIER
 domain ID around. 


 


Have a good read and comments welcome


 


thanks



 


--- tony


 


 


 






--_000_2E4BB27CAB87BF43B4207C0E55860F181B60B2eusaamb103ericsso_--

--_004_2E4BB27CAB87BF43B4207C0E55860F181B60B2eusaamb103ericsso_
Content-Type: text/plain; name="bier-przygienda-bier-isis-ranges.txt"
Content-Description: bier-przygienda-bier-isis-ranges.txt
Content-Disposition: attachment;
	filename="bier-przygienda-bier-isis-ranges.txt"; size=15848;
	creation-date="Sun, 28 Sep 2014 04:37:32 GMT";
	modification-date="Sun, 28 Sep 2014 05:08:35 GMT"
Content-Transfer-Encoding: base64

CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgQS4gUHJ6eWdpZW5kYQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb24KSW50ZW5kZWQgc3RhdHVzOiBTdGFu
ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDI3LCAyMDE0CkV4cGly
ZXM6IE1hcmNoIDMxLCAyMDE1CgoKICAgICAgICAgICAgICAgICAgICAgICAgIEJJRVIgc3VwcG9y
dCB2aWEgSVNJUwogICAgICAgICAgICAgICAgICBkcmFmdC1wcnp5Z2llbmRhLWJpZXItaXNpcy1y
YW5nZXMtMDAKCkFic3RyYWN0CgogICBTcGVjaWZpY2F0aW9uIG9mIGFuIElTSVMgZXh0ZW5zaW9u
IHRvIHN1cHBvcnQgQklFUiBkb21haW5zLgoKUmVxdWlyZW1lbnRzIExhbmd1YWdlCgogICBUaGUg
a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM
IE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBh
bmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBh
cyBkZXNjcmliZWQgaW4gUkZDIDIxMTkgW1JGQzIxMTldLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoK
ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3
aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQt
RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcK
ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRp
c3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxp
c3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tl
ci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0
IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBi
ZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh
bnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBh
cyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndv
cmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBN
YXJjaCAzMSwgMjAxNS4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxNCBJ
RVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBh
dXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVj
dCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxh
dGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5z
ZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhpcyBk
b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxseSwgYXMg
dGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAog
ICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMg
ZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBk
ZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKCgoKUHJ6eWdpZW5kYSAgICAgICAgICAgICAgIEV4
cGlyZXMgTWFyY2ggMzEsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQt
RHJhZnQgICAgZHJhZnQtcHJ6eWdpZW5kYS1iaWVyLWlzaXMtcmFuZ2VzLTAwICAgIFNlcHRlbWJl
ciAyMDE0CgoKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3
aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGlj
ZW5zZS4KClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIFRlcm1pbm9s
b2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAz
CiAgIDMuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICAgMwogICA0LiAgQ29uY2VwdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgICA0LjEuICBCSUVSIGFzIENhcGFi
aWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgICAgNC4y
LiAgQklFUiBEb21haW4gSWRlbnRpZmllciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuICAgNAogICA1LiAgUHJvY2VkdXJlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAgICA1LjEuICBFbmFibGluZyBhIEJJRVIgRG9tYWlu
ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgICAgNS4yLiAgTGVuZ3Ro
IG9mIEJpdG1hc2tzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAog
ICAgICAgNS4yLjEuICBTcGVjaWFsIENvbnNpZGVyYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAgIDUKICAgICA1LjMuICBFbmNhcHN1bGF0aW9uIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgICAgNS40LiAgTGFiZWwgQWR2ZXJ0aXNl
bWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICAgICAgNS40
LjEuICBTcGVjaWFsIENvbnNpZGVyYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAgIDUKICAgICA1LjUuICBCRlItaWQgQWR2ZXJ0aXNlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgIDYuICBQYWNrZXQgRm9ybWF0cyAgLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICAgIDYuMS4gIEJJRVIgQkZS
IHN1Yi1UTFYgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAg
Ny4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gICA3CiAgIDguICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICA5LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMg
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgQXV0aG9yJ3Mg
QWRkcmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
ICA4CgoxLiAgSW50cm9kdWN0aW9uCgogICBCaXQgSW5kZXggRXhwbGljaXQgUmVwbGljYXRpb24g
KEJJRVIpCiAgIFtJLUQuZHJhZnQtd2lqbmFuZHMtYmllci1hcmNoaXRlY3R1cmUtMDBdIGRlZmlu
ZXMgYW4gYXJjaGl0ZWN0dXJlCiAgIHdoZXJlIGFsbCBpbnRlbmRlZCBtdWx0aWNhc3QgcmVjZWl2
ZXJzIGFyZSBlbmNvZGVkIGFzIGJpdG1hc2sgaW4gdGhlCiAgIE11bHRpY2FzdCBwYWNrZXQgaGVh
ZGVyIHdpdGhpbiBkaWZmZXJlbnQgZW5jYXBzdWxhdGlvbnMgc3VjaCBhcwogICBbSS1ELmRyYWZ0
LXdpam5hbmRzLW1wbHMtYmllci1lbmNhcHN1bGF0aW9uLTAwXS4gIEEgcm91dGVyIHRoYXQKICAg
cmVjZWl2ZXMgc3VjaCBhIHBhY2tldCB3aWxsIGZvcndhcmQgdGhlIHBhY2tldCBiYXNlZCBvbiB0
aGUgQml0CiAgIFBvc2l0aW9uIGluIHRoZSBwYWNrZXQgaGVhZGVyIHRvd2FyZHMgdGhlIHJlY2Vp
dmVyKHMpLCBmb2xsb3dpbmcgYQogICBwcmVjb21wdXRlZCB0cmVlIGZvciBlYWNoIG9mIHRoZSBi
aXRzIGluIHRoZSBwYWNrZXQuICBFYWNoIHJlY2VpdmVyCiAgIGlzIHJlcHJlc2VudGVkIGJ5IGEg
dW5pcXVlIGJpdCBpbiB0aGUgYml0bWFzay4KCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgbmVj
ZXNzYXJ5IGV4dGVuc2lvbnMgdG8gdGhlIGN1cnJlbnRseSBkZXBsb3llZAogICBJU0lTIGZvciBJ
UCBbUkZDNzE0Ml0gcHJvdG9jb2wgdG8gc3VwcG9ydCBkaXN0cmlidXRpb24gb2YgaW5mb3JtYXRp
b24KICAgbmVjZXNzYXJ5IGZvciBvcGVyYXRpb24gb2YgQklFUiBkb21haW5zLiAgVGhpcyBkb2N1
bWVudCBkZWZpbmVzIGEgbmV3CiAgIFRMViB0byBiZSBkaXN0cmlidXRlZCBieSBldmVyeSByb3V0
ZXIgcGFydGljaXBhdGluZyBpbiBzdWNoIEJJRVIKICAgZG9tYWlucy4KCgoKCgoKCgpQcnp5Z2ll
bmRhICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAzMSwgMjAxNSAgICAgICAgICAgICAgICAg
W1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICBkcmFmdC1wcnp5Z2llbmRhLWJpZXItaXNpcy1y
YW5nZXMtMDAgICAgU2VwdGVtYmVyIDIwMTQKCgoyLiAgVGVybWlub2xvZ3kKCiAgIFNvbWUgb2Yg
dGhlIHRlcm1pbm9sb2d5IHNwZWNpZmllZCBpbgogICBbSS1ELmRyYWZ0LXdpam5hbmRzLWJpZXIt
YXJjaGl0ZWN0dXJlLTAwXSBpcyByZXBsaWNhdGVkIGhlcmUgYW5kCiAgIGV4dGVuZGVkIGJ5IG5l
Y2Vzc2FyeSBkZWZpbml0aW9uczoKCiAgIEJJRVI6ICBCaXQgSW5kZXggRXhwbGljaXQgUmVwbGlj
YXRpb24gKFRoZSBvdmVyYWxsIGFyY2hpdGVjdHVyZSBvZgogICAgICBmb3J3YXJkaW5nIG11bHRp
Y2FzdCB1c2luZyBhIEJpdCBQb3NpdGlvbikuCgogICBCSUVSLU9MOiAgQklFUiBPdmVybGF5IFNp
Z25hbGluZy4gIChUaGUgbWV0aG9kIGZvciB0aGUgQkZJUiB0byBsZWFybgogICAgICBhYm91dCBC
RkVSJ3MpLgoKICAgQk06ICBCaXQgTWFzayAoQSBiaXQgc3RyZWFtIG9mIGEgY2VydGFpbiBmaXhl
ZCBsZW5ndGguICBFYWNoIEJpdAogICAgICByZXByZXNlbnRzIGEgcmVjZWl2ZXIpLgoKICAgUC1C
TTogIFBhY2tldCBCaXQgTWFzayAoQSBCaXQgTWFzayBpbmNsdWRlZCBpbiB0aGUgTXVsdGljYXN0
IFBhY2tldCkuCgogICBCUDogIEJpdCBQb3NpdGlvbiAoQSBzaW5nbGUgQml0IGZyb20gdGhlIEJp
dCBNYXNrIHRoYXQgcmVwcmVzZW50cyBhCiAgICAgIHJlY2VpdmVyKS4KCiAgIEJGUjogIEJpdCBG
b3J3YXJkaW5nIFJvdXRlciAoQSByb3V0ZXIgdGhhdCBwYXJ0aWNpcGF0ZXMgaW4gQml0IEluZGV4
CiAgICAgIE11bHRpcG9pbnQgRm9yd2FyZGluZykuCgogICBCRklSOiAgQml0IEZvcndhcmRpbmcg
SW5ncmVzcyBSb3V0ZXIgKFRoZSBpbmdyZXNzIGJvcmRlciByb3V0ZXIgdGhhdAogICAgICBpbnNl
cnRzIHRoZSBCTSBpbnRvIHRoZSBwYWNrZXQpLgoKICAgQkZFUjogIEJpdCBGb3J3YXJkaW5nIEVn
cmVzcyBSb3V0ZXIuICBBIHJvdXRlciB0aGF0IHBhcnRpY2lwYXRlcyBpbgogICAgICBCaXQgSW5k
ZXggRm9yd2FyZGluZyBhcyBsZWFmLiAgRWFjaCBCRkVSIG11c3QgYmUgYSBCRlIuCgogICBCRlQ6
ICBCaXQgRm9yd2FyZGluZyBUcmVlIHVzZWQgdG8gcmVhY2ggYWxsIEJGRVJzIGluIGEgZG9tYWlu
LgoKICAgQklGVDogIEJpdCBJbmRleCBGb3J3YXJkaW5nIFRhYmxlIChBIEJpdCBpbmRleCBmb3J3
YXJkaW5nIHRhYmxlKS4KCiAgIEJNUzogIEJpdCBNYXNrIFNldC4gU2V0IGNvbnRhaW5pbmcgYml0
IHBvc2l0aW9ucyBvZiBhbGwgQkZFUgogICAgICBwYXJ0aWNpcGF0aW5nIGluIGEgc2V0LgoKICAg
Qk1QOiAgQml0IE1hc2sgUG9zaXRpb24sIGEgZ2l2ZW4gYml0IGluIGEgQk1TLgoKMy4gIElBTkEg
Q29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgcmVxdWVzdHMgSUFOQSB0byBhc3NpZ24g
c3ViLVRMViB0eXBlIHZhbHVlcyBmcm9tIHRoZQogICBJU0lTIHJvdXRlciBjYXBhYmlsaXR5IFRM
ViBbUkZDNDk3MV0gcmVnaXN0cnkuCgo0LiAgQ29uY2VwdHMKCgoKCgoKClByenlnaWVuZGEgICAg
ICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDMxLCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAz
XQoMCkludGVybmV0LURyYWZ0ICAgIGRyYWZ0LXByenlnaWVuZGEtYmllci1pc2lzLXJhbmdlcy0w
MCAgICBTZXB0ZW1iZXIgMjAxNAoKCjQuMS4gIEJJRVIgYXMgQ2FwYWJpbGl0eQoKICAgVGhpcyBk
cmFmdCBpbnRyb2R1Y2VzIGEgc3ViLVRMViBpbiB0aGUgcm91dGVyIGNhcGFiaWxpdGVzIFRMVgog
ICBbUkZDNDk3MV0gdG8gZGlzdHJpYnV0ZSB0aGUgaW5mb3JtYXRpb24uICBBbnkgb2YgdGhlIHJv
dXRlcidzCiAgIGxvb3BiYWNrIGFkZHJlc3NlcyB0aGF0IGl0IG9yaWdpbmF0ZXMgYXJlIGNvbnNp
ZGVyZWQgQkZSIHByZWZpeGVzIGFzCiAgIHJlcXVpcmVkIGJ5IFtJLUQuZHJhZnQtd2lqbmFuZHMt
Ymllci1hcmNoaXRlY3R1cmUtMDBdLiAgVGhlIHF1ZXN0aW9uCiAgIHdoZXRoZXIgYSBwYXJ0aWN1
bGFyIGxvb3BiYWNrIGFkZHJlc3MgaXMgcm91dGFibGUgaW4gYSBzcGVjaWZpYwogICB0b3BvbG9n
eSBbUkZDNTEyMF0gY2FuIGJlIHJlc29sdmVkIGJ5CiAgIFtJLUQuZHJhZnQteHUtaXNpcy1yb3V0
YWJsZS1pcC1hZGRyZXNzLTAxXS4KCjQuMi4gIEJJRVIgRG9tYWluIElkZW50aWZpZXIKCiAgIElT
SVMgY2FuIGNhcnJ5IEJJRVIgaW5mb3JtYXRpb24gbm90IG9ubHkgZm9yIGEgc2luZ2xlIEJJRVIg
ZG9tYWluIGJ1dAogICBmb3IgbXVsdGlwbGUsIGRpc3RpbmN0IGRvbWFpbnMuICBUaGlzIGFsbG93
cyB0byBydW4gbWFueSBkaXNqb2ludAogICBCSUVSIGxheWVycyB3aXRoaW4gdGhlIHNhbWUgTXVs
dGktVG9wb2xvZ3kgW1JGQzUxMjBdIGVhc2lseSBpbnN0ZWFkCiAgIG9mIGFsd2F5cyBmb3JjaW5n
IGRpZmZlcmVudCBtdWx0aWNhc3Qgb3ZlcmxheXMgdG8gc2hhcmUgdGhlIGV4YWN0bHkKICAgc2Ft
ZSBzZXQgb2YgQkZScyBhbmQgcmVzb3VyY2VzLiAgTW9yZW92ZXIsIG11bHRpIHRvcG9sb2d5IFtS
RkM1MTIwXQogICBjYW4gYmUgdXNlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgcmVzdHJpY3RpbmcgbGlu
a3MgdGhhdCBjZXJ0YWluIHNldCBvZgogICBCSUVSIGRvbWFpbnMgY2FuIHVzZSBvciBjaGFuZ2Ug
bWV0cmljcyBvZiBzdWNoIGxpbmtzLiAgQSBCSUVSIHNldCBpcwogICB0aGVyZWZvcmUgYWx3YXlz
IHVuaXF1ZWx5IGlkZW50aWZpZWQgYnkgdGhlIHR1cGxlIG9mIHRvcG9sb2d5IFQsCiAgIGRvbWFp
biBEIGl0IGJlbG9uZ3MgdG8gYW5kIGl0cyBudW1iZXIgUywgZGVub3RlZCBhcyA8VCxELFM+LiAg
VGhlCiAgIGRvbWFpbiBpdHNlbGYgaGFzIGFzIGl0cyB1bmlxdWUgYXR0cmlidXRlcyB0aGUgZW5j
YXBzdWxhdGlvbiwgYml0bWFzawogICBsZW5ndGggYW5kIHRoZSB0eXBlIG9mIHRyZWUgaXQgaXMg
dXNpbmcgdG8gZm9yd2FyZCBCSUVSIGZyYW1lcwogICAoY3VycmVudGx5IGFsd2F5cyBTUEYpLgoK
NS4gIFByb2NlZHVyZXMKCjUuMS4gIEVuYWJsaW5nIGEgQklFUiBEb21haW4KCiAgIEEgZ2l2ZW4g
ZG9tYWluIEQgaW4gYSBtdWx0aS10b3BvbG9neSBUIFtSRkM1MTIwXSAoZGVub3RlZCBhcyA8VCxE
PgogICBmcm9tIG5vdyBvbikgaXMgbm9ybWFsbHkgbm90IGFkdmVydGlzZWQgdG8gcHJlc2VydmUg
dGhlIHNjYWxpbmcgb2YKICAgdGhlIHByb3RvY29sIChpLmUuICBJU0lTIGNhcnJpZXMgbm8gVExW
cyBjb250YWluaW5nIGFueSBvZiB0aGUKICAgZWxlbWVudHMgcmVsYXRlZCB0byA8VCxEPikgYW5k
IGlzIGVuYWJsZWQgYnkgYSBmaXJzdCBCSUVSIHN1Yi1UTFYKICAgKFNlY3Rpb24gNi4xKSBjb250
YWluaW5nIDxULEQ+IGJlaW5nIGFkdmVydGlzZWQgaW50byB0aGUgYXJlYS4gIFRoZQogICB0cmln
Z2VyIGl0c2VsZiBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRyYWZ0IGJ1dCBjYW4gYmUg
LmUuZy4gYQogICBWUE4gZGVzaXJpbmcgdG8gaW5pdGlhdGUgYSBkb21haW4gYXMgTVAyTVAgb3Ig
UDJNUCB0cmVlIG9yIGEgQk1QCiAgIGJlaW5nIGFkbWluaXN0cmF0aXZlbHkgYXNzaWduZWQgdG8g
YSBCRkVSIGFuZCBhZHZlcnRpc2VkIHZpYSBCSUVSIFRMVgogICBpbnRvIHRoZSBhcmVhIG9yIGFu
eSBvdGhlciBtZWFucyB3aXRoaW4gTXVsdGljYXN0IEJJRVIgT3ZlcmxheShzKQogICB1c2luZyBC
SUVSIGRvbWFpbnMuCgo1LjIuICBMZW5ndGggb2YgQml0bWFza3MKCiAgIEFsbCByb3V0ZXJzIGlu
IHRoZSBmbG9vZGluZyBzY29wZSBvZiB0aGUgQklFUiBUTFZzIFNIT1VMRCBhZHZlcnRpc2UKICAg
dGhlIHNhbWUgYml0IG1hc2sgbGVuZ3RoIGZvciBhIGdpdmVuIDxULEQ+LiAgQSByb3V0ZXIgZGlz
Y292ZXJpbmcKICAgYml0bWFzayBsZW5ndGhzIGFkdmVydGlzZWQgdGhhdCBhcmUgc2hvcnRlciB0
aGFuIGl0cyBvd24gTVVTVCByZXBvcnQKICAgYSBtaXNjb25maWd1cmF0aW9uIG9mIGEgc3BlY2lm
aWMgPFQsRD4uICBFYWNoIHJvdXRlciBNVVNUIGNvbXB1dGUKICAgQkZUcyBmb3IgPFQsRD4gdXNp
bmcgb25seSByb3V0ZXJzIGhhdmluZyB0aGUgc2FtZSBtYXNrIGxlbmd0aCBhcyBpdHMKICAgb3du
IGFkdmVydGlzZWQgQml0IE1hc2sgTGVuZ3RoIGluIEJJRVIgc3ViLVRMViBmb3IgPFQsRD4uCgoK
ClByenlnaWVuZGEgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDMxLCAyMDE1ICAgICAgICAg
ICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgIGRyYWZ0LXByenlnaWVuZGEtYmll
ci1pc2lzLXJhbmdlcy0wMCAgICBTZXB0ZW1iZXIgMjAxNAoKCjUuMi4xLiAgU3BlY2lhbCBDb25z
aWRlcmF0aW9uCgogICBUaGUgc2FtZSByb3V0ZXIgTUFZIGFkdmVydGlzZSBmb3IgZGlmZmVyZW50
IDxULEQ+IGNvbWJpbmF0aW9ucyB0d28KICAgZGlmZmVyZW50IG1hc2sgbGVuZ3Rocy4gIFRoaXMg
YWxsb3dzIHRvIGNsZWFubHkgZGVsaW5lYXRlIGRvbWFpbnMKICAgY3Jvc3NpbmcgdGhlIHNhbWUg
cm91dGVyIGJ1dCB1c2luZyBkaWZmZXJlbnQgbWFzayBsZW5ndGhzIGluIHRoZQogICBlbmNvZGlu
ZywgZXZlbiB3aXRoaW4gdGhlIHNhbWUgdG9wb2xvZ3kuCgo1LjMuICBFbmNhcHN1bGF0aW9uCgog
ICBTaW5jZSBlbmNhcHN1bGF0aW9uIGlzIGFuIGF0dHJpYnV0ZSBvZiBhIGRvbWFpbiA8VCxEPiBq
dXN0IGxpa2UKICAgYml0bWFzayBsZW5ndGgsIGFsbCBydWxlcyB0aGF0IGFwcGx5IHRvIEJpdG1h
c2sgTGVuZ3RoIHBlcgogICBTZWN0aW9uIDUuMiBhcHBseSB0byBpdCB3ZWxsLgoKNS40LiAgTGFi
ZWwgQWR2ZXJ0aXNlbWVudHMKCiAgIEVhY2ggcm91dGVyIE1BWSBhZHZlcnRpc2Ugd2l0aGluIHRo
ZSBzdWItVExWIG9mIGFuIGFjY29yZGluZyA8VCxEPgogICAoZGVub3RlZCBmdXJ0aGVyIGFzIFRM
VjxULEQ+KSBhIHZhbGlkIHN0YXJ0aW5nIGxhYmVsIHZhbHVlIGFuZCBhIG5vbi0KICAgemVybyBy
YW5nZSBsZW5ndGguICBJdCBNVVNUIGFkdmVydGlzZSBhIHZhbGlkIGxhYmVsIHZhbHVlIGFuZCBh
IG5vbi0KICAgemVybyByYW5nZSBsZW5ndGggSUYgaXQgaGFzIGNvbXB1dGVkIGl0c2VsZiBhcyBi
ZWluZyBvbiB0aGUgQkZUCiAgIHJvb3RlZCBhdCBhbnkgb2YgdGhlIEJGUnMgd2l0aCB2YWxpZCBC
RlItaWRzIChleGNlcHQgaXRzZWxmKQogICBwYXJ0aWNpcGF0aW5nIGluIDxULEQ+LgoKICAgQSBy
b3V0ZXIgQ0FOIHdpdGhkcmF3IGl0cyBUTFY8VCxEPiBpZiBpdCBkb2VzIG5vdCB3YW50IHRvIHBh
cnRpY2lwYXRlCiAgIGluIHRoZSBkb21haW4gZHVlIHRvIHJlc291cmNlIGNvbnN0cmFpbnRzLCBs
YWJlbCBzcGFjZSBvcHRpbWl6YXRpb24sCiAgIGFkbWluaXN0cmF0aXZlIGNvbmZpZ3VyYXRpb24g
b3IgYW55IG90aGVyIHJlYXNvbnMuICBJbiBjYXNlIGEgcm91dGVyCiAgIGFkdmVydGlzZXMgYSBs
YWJlbCByYW5nZSBzaXplIG9mIDAgZm9yIDxULEQ+IGl0IE1VU1QgYmUgZXhjbHVkZWQgZnJvbQog
ICB0aGUgQklFUiBCRlRzIGZvciA8VCxEPi4KCjUuNC4xLiAgU3BlY2lhbCBDb25zaWRlcmF0aW9u
CgogICBBIHJvdXRlciBNVVNUIGFkdmVydGlzZSBhIGZvciA8VCxEPiBsYWJlbCByYW5nZSBzaXpl
IHRoYXQgZ3VhcmFudGVlcwogICB0byBjb3ZlciB0aGUgbWF4aW11bSBCRlItaWQgaW5qZWN0ZWQg
aW50byA8VCxEPiAod2hpY2ggaW1wbGllcyBhCiAgIGNlcnRhaW4gc2V0IGlkIGFzIGRlc2NyaWJl
ZCBpbgogICBbSS1ELmRyYWZ0LXdpam5hbmRzLWJpZXItYXJjaGl0ZWN0dXJlLTAwXSkuICBBbnkg
cm91dGVyIHRoYXQgdmlvbGF0ZXMKICAgdGhpcyBjb25kaXRpb24gTVVTVCBiZSBleGNsdWRlZCBm
cm9tIEJJRVIgQkZUcyBmb3IgPFQsRD4uCgo1LjUuICBCRlItaWQgQWR2ZXJ0aXNlbWVudHMKCiAg
IEVhY2ggQkZFUiBNQVkgYWR2ZXJ0aXNlIHdpdGggaXRzIFRMVjxULEQ+IHRoZSBhY2NvcmRpbmcg
QkZSLWlkIHRoYXQKICAgaXQgaGFzIGFkbWluaXN0cmF0aXZlbHkgY2hvc2VuLgoKICAgSWYgdHdv
IEJGUnMgYWR2ZXJ0aXNlIGluIHRoZWlyIFRMVjxULEQ+IHRoZSBzYW1lIHZhbHVlIGZvciBCRlIt
aWQsCiAgIGFsbCByb3V0ZXJzIE1VU1QgcmVwb3J0IGl0IGFzIG1pc2NvbmZpZ3VyYXRpb24gYW5k
IGRpc3JlZ2FyZCB0aG9zZQogICByb3V0ZXJzIGZvciBhbGwgQklFUiBjYWxjdWxhdGlvbnMgYW5k
IHByb2NlZHVyZXMgdG8gYWxpZ24gd2l0aAogICBbSS1ELmRyYWZ0LXdpam5hbmRzLWJpZXItYXJj
aGl0ZWN0dXJlLTAwXS4gIFN1Y2ggcm91dGVycyB3aXRoCiAgIGNvbGxpZGluZyBhc3NpZ25tZW50
cyBNQVkgc3RpbGwgYWN0IGFzIEJGSVJzIGJ1dCB3aWxsIGJlIG5ldmVyIGFibGUKICAgdG8gcmVj
ZWl2ZSB0cmFmZmljLgoKCgoKUHJ6eWdpZW5kYSAgICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2gg
MzEsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgZHJh
ZnQtcHJ6eWdpZW5kYS1iaWVyLWlzaXMtcmFuZ2VzLTAwICAgIFNlcHRlbWJlciAyMDE0CgoKNi4g
IFBhY2tldCBGb3JtYXRzCgogICBBbGwgSVNJUyBCSUVSIGluZm9ybWF0aW9uIGlzIGNhcnJpZWQg
d2l0aGluIHRoZSByb3V0ZXIgY2FwYWJpbGl0eSBUTFYKICAgW1JGQzQ5NzFdIHdpdGggUyBiaXQg
Y2xlYXIuCgo2LjEuICBCSUVSIEJGUiBzdWItVExWCgogICBUaGlzIHN1Yi1UTFYgY2FycmllcyB0
aGUgaW5mb3JtYXRpb24gZm9yIHRoZSBCSUVSIGRvbWFpbnMgdGhhdCB0aGUKICAgcm91dGVyIHBh
cnRpY2lwYXRlcyBpbiBhcyBCRlIuICBJdCBjYW4gcmVwZWF0IG11bHRpcGxlIHRpbWVzLiAgSWYg
dGhlCiAgIHNhbWUgPFQsRD4gaXMgYWR2ZXJ0aXNlZCBtb3JlIHRoYW4gb25jZSwgdGhlIGZpcnN0
IG9uZSBpbiB0aGUgZmlyc3QKICAgc3ViLVRMViBpbiB0aGUgZnJhZ21lbnQgd2l0aCB0aGUgbG93
ZXN0IElEIE1VU1QgYmUgdXNlZC4KCgogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAg
ICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgICAgMCAxIDIgMyA0IDUgNiA3
IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICAgICst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rCiAgICAgIHwgICAgICAgICAgICAgIFR5cGUgICAgICAgICAgICAgfCAgICAgICAgICAg
ICBMZW5ndGggICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgIE1ULUlEICAg
ICB8ICAgQmllciBEb21haW4gSUQgICAgICAgICAgICAgIHwgICBCaXQgTXNrIExlbiB8CiAgICAg
ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rCiAgICAgIHwgTGJsIFJhbmdlIFNpemV8ICAgICAgICAgICAgICAgICAgICBMYWJl
bCAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICBCRlItaWQg
ICAgICAgICAgICAgICAgICAgICAgfEF8UnxUfCBSZXNlcnYgIHwgIEVuY2FwcyAgICAgICB8CiAg
ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rCgoKCiAgIFR5cGU6ICBUQkQxLgoKICAgTGVuZ3RoOiAgMiBvY3RldHMuCgog
ICBNVC1JRDogIE11bHRpLVRvcG9sb2d5IFtSRkM1MTIwXSwgMSBvY3RldC4KCiAgIEJJRVIgRG9t
YWluIElEOiAgVW5pcXVlIGlkZW50aWZpZXIgZm9yIGEgQklFUiBkb21haW4sIDIgb2N0ZXRzLgoK
ICAgTGFiZWwgUmFuZ2UgU2l6ZTogIE51bWJlciBvZiBsYWJlc3QgaW4gdGhlIHJhbmdlIHVzZWQg
b24KICAgICAgZW5jYXBzdWxhdGlvbiBmb3IgdGhpcyBCSUVSIGRvbWFpbiwgMSBvY3RldC4KCiAg
IExhYmVsOiAgRmlyc3QgbGFiZWwgb2YgdGhlIHJhbmdlIHVzZWQgb24gZW5jYXBzdWxhdGlvbiBm
b3IgdGhpcyBCSUVSCiAgICAgIGRvbWFpbiwgMjAgYml0cy4gIFRoZSBsYWJlbCBpcyB1c2VkIGJ5
IGUuZy4KICAgICAgW0ktRC5kcmFmdC13aWpuYW5kcy1tcGxzLWJpZXItZW5jYXBzdWxhdGlvbi0w
MF0gdG8gZm9yd2FyZCB0cmFmZmljCiAgICAgIHRvIHNldHMgb2YgQkZFUnMuCgogICBMb2NhbCBC
aXRNYXNrIExlbmd0aDogIEJpdG1hc2sgbGVuZ3RoIGZvciB0aGlzIEJGUiBwZXIKICAgICAgW0kt
RC5kcmFmdC13aWpuYW5kcy1iaWVyLWFyY2hpdGVjdHVyZS0wMF0uCgogICBFbmNhcHN1bGF0aW9u
IFR5cGU6ICBUaGUgQklFUiBlbmNhcHN1bGF0aW9uIHR5cGUsIDEgb2N0ZXQuICBBbGxvd2VkCiAg
ICAgIHZhbHVlcyBhcmU6CgoKClByenlnaWVuZGEgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNo
IDMxLCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgIGRy
YWZ0LXByenlnaWVuZGEtYmllci1pc2lzLXJhbmdlcy0wMCAgICBTZXB0ZW1iZXIgMjAxNAoKCiAg
ICAgIDAgIE1QTFMgcGVyIFtJLUQuZHJhZnQtd2lqbmFuZHMtbXBscy1iaWVyLWVuY2Fwc3VsYXRp
b24tMDBdLgoKICAgQSAgSW5kaWNhdGVzIGFkbWluaXN0cmF0aXZlbHkgc2V0IHZhbHVlIGlmIHNl
dCwgb3RoZXJ3aXNlIHRoZSBCRlItaWQKICAgICAgdmFsdWUgTVVTVCBiZSBjb25zaWRlcmVkIGFz
IG5vdCBhc3NpZ25lZCBpbiB0aGlzIFRMVi4KCiAgIFIgIFJlc2VydmVkIGZvciBmdXR1cmUgdXNl
LiAgTVVTVCBiZSAwLgoKICAgVCAgUmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UuICBNVVNUIGJlIDAu
CgogICBSZXNlcnZlZCAgTVVTVCBiZSAwIG9uIHNlbmQsIGlnbm9yZWQgb24gcmVjZWl2ZS4KCjcu
ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIGV4dGVuc2lvbiBkb2VzIG5vdCBpbnRy
b2R1Y2UgYW55IGtub3duIG5ldyBwcm90b2NvbAogICB2dWxuZXJhYmlsaXRpZXMuCgo4LiAgQWNr
bm93bGVkZ2VtZW50cwoKICAgVGhlIGRyYWZ0IGlzIGFsaWduZWQgd2l0aCB0aGUKICAgW0ktRC5k
cmFmdC1rdW1hci1vc3BmLWJpZXItZXh0ZW5zaW9uLTAwXSBkcmFmdCBhcyBmYXIgYXMgdGhlIHBy
b3RvY29sCiAgIG1lY2hhbmlzbXMgb3ZlcmxhcC4KCjkuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoK
ICAgW0ktRC5kcmFmdC1rdW1hci1vc3BmLWJpZXItZXh0ZW5zaW9uLTAwXQogICAgICAgICAgICAg
IFBzZW5haywgUC4gYW5kIElKLiBXaWpuYW5kcywgIk9TUEYgRXh0ZW5zaW9uIGZvciBCaXQgSW5k
ZXgKICAgICAgICAgICAgICBFeHBsaWNpdCBSZXBsaWNhdGlvbiIsIGludGVybmV0LWRyYWZ0IGRy
YWZ0LWlldGYtb3NwZi0KICAgICAgICAgICAgICBwcmVmaXgtbGluay1hdHRyLTAwLnR4dCwgU2Vw
dGVtYmVyIDIwMTQuCgogICBbSS1ELmRyYWZ0LXdpam5hbmRzLWJpZXItYXJjaGl0ZWN0dXJlLTAw
XQogICAgICAgICAgICAgIFdpam5hbmRzLCBJSi4sICJTdGF0ZWxlc3MgTXVsdGljYXN0IHVzaW5n
IEJpdCBJbmRleAogICAgICAgICAgICAgIEV4cGxpY2l0IFJlcGxpY2F0aW9uIEFyY2hpdGVjdHVy
ZSIsIGludGVybmV0LWRyYWZ0IGRyYWZ0LQogICAgICAgICAgICAgIHdpam5hbmRzLWJpZXItYXJj
aGl0ZWN0dXJlLTAwLnR4dCwgRmVicnVhcnkgMjAxNC4KCiAgIFtJLUQuZHJhZnQtd2lqbmFuZHMt
bXBscy1iaWVyLWVuY2Fwc3VsYXRpb24tMDBdCiAgICAgICAgICAgICAgV2lqbmFuZHMgZXQgYWwu
LCBJSi4sICJCaXQgSW5kZXggRXhwbGljaXQgUmVwbGljYXRpb24KICAgICAgICAgICAgICB1c2lu
ZyBNUExTIGVuY2Fwc3VsYXRpb24iLCBpbnRlcm5ldC1kcmFmdCBkcmFmdC13aWpuYW5kcy0KICAg
ICAgICAgICAgICBtcGxzLWJpZXItZW5jYXBzdWxhdGlvbi0wMC50eHQsIEZlYnJ1YXJ5IDIwMTQu
CgogICBbSS1ELmRyYWZ0LXh1LWlzaXMtcm91dGFibGUtaXAtYWRkcmVzcy0wMV0KICAgICAgICAg
ICAgICBDaHVuZHVyaSBldCBhbC4sIFUuLCAiQ2FycnlpbmcgUm91dGFibGUgSVAgQWRkcmVzc2Vz
IGluCiAgICAgICAgICAgICAgSVMtSVMgUm91dGVyIENhcGFiaWxpdHkgVExWIiwgaW50ZXJuZXQt
ZHJhZnQgZHJhZnQteHUtCiAgICAgICAgICAgICAgaXNpcy1yb3V0YWJsZS1pcC1hZGRyZXNzLTAx
LnR4dCwgU2VwdGVtYmVyIDIwMTQuCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdv
cmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50
IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgoKCgoKUHJ6eWdpZW5kYSAg
ICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMzEsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdl
IDddCgwKSW50ZXJuZXQtRHJhZnQgICAgZHJhZnQtcHJ6eWdpZW5kYS1iaWVyLWlzaXMtcmFuZ2Vz
LTAwICAgIFNlcHRlbWJlciAyMDE0CgoKICAgW1JGQzQ5NzFdICBWYXNzZXVyLCBKUC4sIFNoZW4s
IE4uLCBhbmQgUi4gQWdnYXJ3YWwsICJJbnRlcm1lZGlhdGUKICAgICAgICAgICAgICBTeXN0ZW0g
dG8gSW50ZXJtZWRpYXRlIFN5c3RlbSAoSVMtSVMpIEV4dGVuc2lvbnMgZm9yCiAgICAgICAgICAg
ICAgQWR2ZXJ0aXNpbmcgUm91dGVyIEluZm9ybWF0aW9uIiwgUkZDIDQ5NzEsIEp1bHkgMjAwNy4K
CiAgIFtSRkM1MTIwXSAgUHJ6eWdpZW5kYSwgVC4sIFNoZW4sIE4uLCBhbmQgTi4gU2hldGgsICJN
LUlTSVM6IE11bHRpCiAgICAgICAgICAgICAgVG9wb2xvZ3kgKE1UKSBSb3V0aW5nIGluIEludGVy
bWVkaWF0ZSBTeXN0ZW0gdG8KICAgICAgICAgICAgICBJbnRlcm1lZGlhdGUgU3lzdGVtcyAoSVMt
SVNzKSIsIFJGQyA1MTIwLCBGZWJydWFyeSAyMDA4LgoKICAgW1JGQzcxNDJdICBTaGFuZCwgTS4g
YW5kIEwuIEdpbnNiZXJnLCAiUmVjbGFzc2lmaWNhdGlvbiBvZiBSRkMgMTE0MgogICAgICAgICAg
ICAgIHRvIEhpc3RvcmljIiwgUkZDIDcxNDIsIEZlYnJ1YXJ5IDIwMTQuCgpBdXRob3IncyBBZGRy
ZXNzCgogICBUb255IFByenlnaWVuZGEKICAgRXJpY3Nzb24KICAgMzAwIEhvbGdlciBXYXkKICAg
U2FuIEpvc2UsIENBICA5NTEzNAogICBVU0EKCiAgIEVtYWlsOiBhbnRvbmkucHJ6eWdpZW5kYUBl
cmljc3Nvbi5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClByenlnaWVuZGEgICAg
ICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDMxLCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSA4
XQo=

--_004_2E4BB27CAB87BF43B4207C0E55860F181B60B2eusaamb103ericsso_--


From nobody Sun Sep 28 00:19:13 2014
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 C479C1A038A for ; Sun, 28 Sep 2014 00:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 GmHwLAT7tGrv for ; Sun, 28 Sep 2014 00:19:09 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB891A0115 for ; Sun, 28 Sep 2014 00:19:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4152; q=dns/txt; s=iport; t=1411888749; x=1413098349; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lgM/t4kShJwyeuvF5PXKtQ9omGZW0Ww4t0Y/JxBrQ5o=; b=k6vzVRoMSteq1c3c4VhZHW6x0fjJ1Ha4XeuO7cvIeLGIQMDMpNUuq3A5 hH4J5FUImBOcA9kYZY7nXQP7dXIQeJk2oX5r8A3/sbtyCyomixvywVnzL Nl2QcSaRPvFzIQDqpPXbqGs1Zw9azoYbz07WJfMyP80IO2Vmf9GBsgkn3 0=;
X-IronPort-AV: E=Sophos;i="5.04,613,1406592000"; d="scan'208";a="191679780"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 28 Sep 2014 07:19:07 +0000
Received: from [10.61.174.33] ([10.61.174.33]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8S7J3P5009266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Sep 2014 07:19:06 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: IJsbrand Wijnands 
In-Reply-To: 
Date: Sun, 28 Sep 2014 09:19:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <77EEB0EC-1881-4CDE-8D0D-357710CD0CC6@cisco.com>
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>     
To: Robert Raszuk 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/E5oYUEhfiS1C9uT345HnYKul31I
Cc: "bier@ietf.org" , "Nagendra Kumar Nainar \(naikumar\)" , Antoni Przygienda , "Eric Rosen \(erosen\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 28 Sep 2014 07:19:11 -0000

Robert,

> >  BiER doesn=E2=80=99t need any IGP calculation=20
> > for every multicast group joined by BFER.
>=20
> I am not talking about IGP. Where is this assumption coming from I do =
not know.=20

You're missing the point Nagendra is making.

SPRING is Source routing, the path is pre-determined on the ingress and =
forwarded based on the hops included in the packet (not on IGP).

BIER forwarding is based on IGP, the Bits in the BIER header are looked =
up in the IGP on a per hop basis and forwarded accordingly.

If you=E2=80=99re next reply is going to suggest we need source routed =
paths for multicast, work through a couple of examples before pressing =
the send button :-)

Thx,

Ice.

>=20
> All agree that BFER receives a join for new group that has to somehow =
travel to BFIR as well as BFIR must adjust its data plane. That is the =
churn I was referring to.=20
>=20
> Hi Tony,
>=20
> > [Tony said]  ???  Last I checked SPRING was defining a=20
> > unicast dataplane.
>=20
> Where does it say so in the SPRING charter ???
>=20
> http://datatracker.ietf.org/wg/spring/charter/=20
>=20
> Cheers,
> r.
>=20
>=20
> On Sat, Sep 27, 2014 at 3:27 PM, Nagendra Kumar Nainar (naikumar) =
 wrote:
> Hi Robert,
>=20
> Take SPRING IPv6 ... why extension header could not list all egress =
nodes as well as =E2=80=8B     =E2=80=8Blist of transit BFRs where =
replication to said egress nodes is to take place ?=20
>=20
> Or going step further .. send list of BFRs (like SNs) and program the =
required replication out of band (from controller) avoiding carrying =
bitstring or network protocols to build a tree to accomplish easy way of =
optimal replication ? Is keeping multicast groups such an overkill for =
even an average network device these days ?
>=20
>  BiER doesn=E2=80=99t need any IGP calculation for every =
multicast group joined by BFER. Infact, it simply leverage the unicast =
tale and populate the BIFT table. So instead of programming different =
transit nodes for optimal replication for every new group, I think it is =
simple to have the tree built once (which doesn=E2=80=99t need =
additional SPF other than unicast calculation) and still achieve optimal =
forwarding.
>=20
> Last but not least how is said bitstring to be honored, accepted and =
used between domains ? What NNI is to be agreed for BIER to make it =
usable between AS under different administrations ?
>=20
>  I think this is slightly covered in below draft,
>=20
> http://tools.ietf.org/html/draft-rosen-l3vpn-mvpn-bier-00
>=20
> Thanks,
> Nagendra
>=20
> From: "robert@raszuk.net" 
> Date: Friday, September 26, 2014 at 5:01 PM
> To: IJsbrand Wijnands 
> Cc: "bier@ietf.org" , "Eric Rosen (erosen)" =
, Antoni Przygienda 
> Subject: Re: [Bier] One specific transition churn ...
>=20
> BIER is totally unrelated to SPRING, completely different data-plane!
>=20
> =E2=80=8BPerhaps it is today, but the question is - does it need to be =
a yet one more completely new data-plane ?=20
>=20
> Take SPRING IPv6 ... why extension header could not list all egress =
nodes as well as =E2=80=8B   =E2=80=8Blist of transit BFRs where =
replication to said egress nodes is to take place ?=20
>=20
> Or going step further .. send list of BFRs (like SNs) and program the =
required replication out of band (from controller) avoiding carrying =
bitstring or network protocols to build a tree to accomplish easy way of =
optimal replication ? Is keeping multicast groups such an overkill for =
even an average network device these days ?
>=20
> Last but not least how is said bitstring to be honored, accepted and =
used between domains ? What NNI is to be agreed for BIER to make it =
usable between AS under different administrations ?
>=20
> Thx,
> r.
>=20
>=20
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>=20
>=20


From nobody Sun Sep 28 00:34:00 2014
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 8E5541A038D for ; Sun, 28 Sep 2014 00:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 QRXAKXooJXmi for ; Sun, 28 Sep 2014 00:33:56 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70FF1A038C for ; Sun, 28 Sep 2014 00:33:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=545; q=dns/txt; s=iport; t=1411889636; x=1413099236; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aPHVXW8cxE3tD/w99ZnavyuIqja4feexqqiWamElMRs=; b=jnlM+VNbP1c2NtHaYoBynXP6QI8sw+PKrXt1qqP73XME4HpaKpQV6s8L SrBAl5EV+2SmY35Ct6ijbfotlJFOEhvUuk1K4/Y3krxam9bLY21a0IlIi DMfKzU+ixCRmZcG/P7nJZ9wQO7YFVwbze2IS4nCFCGQY3G5bAijBFSwgC A=;
X-IronPort-AV: E=Sophos;i="5.04,613,1406592000"; d="scan'208";a="187614146"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 28 Sep 2014 07:33:54 +0000
Received: from [10.61.174.33] ([10.61.174.33]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8S7Xprd008477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Sep 2014 07:33:53 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: IJsbrand Wijnands 
In-Reply-To: <30386970-B544-4BD5-B673-87FB2453F7B9@gmail.com>
Date: Sun, 28 Sep 2014 09:33:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9D6BC886-365D-4E00-B56A-D71538970967@cisco.com>
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>     <30386970-B544-4BD5-B673-87FB2453F7B9@gmail.com>
To: Dino Farinacci 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/qw4uwweeYO108AiRT-QDhH_9xzU
Cc: "Nagendra Kumar Nainar \(naikumar\)" , "bier@ietf.org" , "Eric Rosen \(erosen\)" , Robert Raszuk , Antoni Przygienda 
Subject: Re: [Bier] One specific transition churn ...
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, 28 Sep 2014 07:33:57 -0000

Hi Dino,

> But the fact people will have to manage yet another address space (ie =
BFR-IDs) makes you wonder if the OpEx will be any less than the points =
made in the problem statement ID.=20

The customers we have talked to do not see this as a big deal. We can =
come up with automated mechanism to assign the BFR-id, but then you have =
yet an other protocol to learn. It does not get any simpler than =
applying this via configuration. Also, configurations are often managed =
centrally and push to the routers.

Thx,

Ice.


From nobody Sun Sep 28 01:01:53 2014
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 13F0C1A039C for ; Sun, 28 Sep 2014 01:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 UWtvZKTlaVIi for ; Sun, 28 Sep 2014 01:01:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A89B1A0396 for ; Sun, 28 Sep 2014 01:01:49 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNB91497; Sun, 28 Sep 2014 08:01:47 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 28 Sep 2014 09:01:46 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Sun, 28 Sep 2014 16:01:39 +0800
From: Xuxiaohu 
To: Antoni Przygienda , IJsbrand Wijnands , "adrian@olddog.co.uk" 
Thread-Topic: [Bier] MPLS encapsulation
Thread-Index: AQHP2amQQPBQ9OujR6OJTMN+0P37n5wTgHcAgADEqQCAAajKYP//kUoAgACbTEA=
Date: Sun, 28 Sep 2014 08:01:39 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC694@NKGEML512-MBS.china.huawei.com>
References: Your message of Fri, 26 Sep 2014 16:11:17 +0100. <051501cfd99c$205b1780$61114680$@olddog.co.uk> <9767.1411750052@erosen-lnx> <065a01cfd9dc$f45f1be0$dd1d53a0$@olddog.co.uk> <873A5047-32D7-4AAB-ABE7-FF8C23166C1F@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC602@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F181B6095@eusaamb103.ericsson.se>
In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F181B6095@eusaamb103.ericsson.se>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/_Irf-_wb96C2S9UbDeWlElhi3Z8
Cc: "erosen@cisco.com" , "bier@ietf.org" 
Subject: Re: [Bier] MPLS encapsulation
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, 28 Sep 2014 08:01:52 -0000

> -----Original Message-----
> From: Antoni Przygienda [mailto:antoni.przygienda@ericsson.com]
> Sent: Sunday, September 28, 2014 1:23 PM
> To: Xuxiaohu; IJsbrand Wijnands; adrian@olddog.co.uk
> Cc: erosen@cisco.com; bier@ietf.org
> Subject: RE: [Bier] MPLS encapsulation
>=20
> I'm not sure whether the discussion is about MPLS encaps for BIER or  any=
 BIER
> encaps.

I'm talking about a generic BIER encapsulation which is transport-independe=
nt.

> For MPLS, one (very good reason) is that we do have _very_ fast MPLS labe=
l
> lookup fast-paths, we do not have MT-ID & Set-ID lookup engines.  SetID i=
s

If I understand it correctly, the intention of the BIER-MPLS label lookup i=
s to find the corresponding SI and MT-ID. By directly carrying the SI and M=
T-ID information in the BIER header, there is no need for that MPLS lookup =
at all even though that lookup is _very_ fast. Furthermore, there is no nee=
d any specific label distribution process for the BIER-MPLS-labels, especia=
lly IGP flooding-based distribution process. BTW, is it efficient to flood =
the BIER-MPLS-label bindings which are actually only meaningful to adjacent=
 BFRs to all IGP peers within the whole IGP domain?

> arguable as being in encaps but a label representing a set in MPLS is sim=
ply
> extremely natural to MPLS. MT-ID has actually no business in the fast-pat=
h I
> would say, the scope of validity of MT-ID is in the IGP control plane onl=
y. Building

Disagree with the above argument. The MT-ID is not only useful in the IGP c=
ontrol plane but also useful in the data plane. Otherwise, how could a BFR =
determine which set of the IP forwarding table entries should be looked up =
for IP packet forwarding? Of course, MPLS-MT is a slightly different since =
the MPLS label itself could be used to indicate which MT's routing table sh=
ould be used. However, to define a transport-independent BIER encapsulation=
, it's better for the MT-ID information to be contained in the BIER header.=
 In addition, wouldn't the BIER-in-MAC be more prevalent than the BIER-in-M=
PLS provided the SI and MT-ID information is contained in the BIER header? =
IMHO, the only irreplaceable use case for BIER-in-MPLS is to use the IGP sh=
ortcut or FA for BIER-encapsulated packet forwarding.

> very complicated networking devices has a lot to do with NOT having all
> concepts showing in every piece of software and hardware, something also
> known as rule 5 of RFC1925.
>=20
> Having said that, different encapsulations (BIER over Avian Carriers) can=
 and will
> be written and there is nothing that precludes such an encapsulation to c=
arry
> arbitrary amount of information on the packet to be processed.

How would you embed the SI and MT-ID in the Ethernet header? Or would you s=
pecify an Ethernet-specific BIER header?

> As to MPLS ranges, this is something that is fashionable these days, IMO =
each set
> should have a completely independent label on it but there are trade-offs=
 in
> terms of control plane complexity/protocol packet sizes vs. fast-path com=
plexity
> vs. what people already have in silicon and so on.

Since the BIER itself requires changes to both control plane and data plane=
 anyway, I have not yet seen any significant advantage of the BIER-MPLS-lab=
el over a BIER header which contains MT-ID and SI information in those term=
s that you have mentioned above.

Best regards,
Xiaohu

> thanks
>=20
> --- tony
>=20
> > -----Original Message-----
> > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Xuxiaohu
> > Sent: Saturday, September 27, 2014 10:11 PM
> > To: IJsbrand Wijnands; adrian@olddog.co.uk
> > Cc: erosen@cisco.com; bier@ietf.org
> > Subject: Re: [Bier] MPLS encapsulation
> >
> >
> >
> > > -----Original Message-----
> > > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand
> > > Wijnands
> > > Sent: Saturday, September 27, 2014 6:39 PM
> > > To: adrian@olddog.co.uk
> > > Cc: erosen@cisco.com; bier@ietf.org
> > > Subject: Re: [Bier] MPLS encapsulation
> > >
> > > Hi Adrian,
> > >
> > > > My point is that you are advocating the advertisement of a block
> > > > of labels by the IGP, and the use of one or more labels on the
> > > > MPLS stack. And my
> > > question:
> > > > why do this? You could hit the bottom of stack as normal, use the
> > > > control word to identify BIER and put all of the information you
> > > > need (currently deduced from the BIER-MPLS label(s) ) into the
> > > > BIER
> > header.
> >
> > I'm in favor of Adrian's proposal of putting all of the information
> > you need (i.e., SI and MT-ID information which is currently deduced
> > from the BIER- MPLS label) into the BIER header.
> >
> > > Just one clarification, in normal operation, we expect just one BIER
> > > label to be on the stack. Unless we sent a BIER packet over a
> > > P2P/FRR LSP,
> > then you'll see two.
> > > But for the BIER procedures, only the BIER label is relevant.
> > >
> > > > I'm not saying that would be better. Just asking why the choice
> > > > you have
> > > made.
> > >
> > > Right, but the control word also has to be indicated by the top
> > > label, right? How would the forwarding plane otherwise know a
> > > control word is following at the bottom of the stack... So, using
> > > the control would just mean an additional indirection, while we can
> > > have a immediate
> > indirection with a BIER-MPLS label.
> >
> > Provided the SI and MT-ID information is carried within the BIER
> > header, it seems that you only need a way to indicate the MPLS payload =
is a
> BIER.
> >
> > Best regards,
> > Xiaohu
> >
> > > Thx,
> > >
> > > Ice.
> > >
> > > >
> > > > Cheers,
> > > > Adrian
> > > >
> > > >> -----Original Message-----
> > > >> From: Eric Rosen [mailto:erosen@cisco.com]
> > > >> Sent: 26 September 2014 17:48
> > > >> To: adrian@olddog.co.uk
> > > >> Cc: bier@ietf.org
> > > >> Subject: Re: [Bier] MPLS encapsulation
> > > >>
> > > >> Adrian,
> > > >>
> > > >> I'm a little confused about your question: are you using the term
> > > >> "special purpose label" in the sense of RFC 7274 ("Allocating and
> > > >> Retiring Special-Purpose MPLS Labels")?  If so, there is no use
> > > >> of special purpose labels (in this sense) being proposed.
> > > >>
> > > >> Did I misunderstand your question?
> > > >>
> > > >> Eric
> > > >>
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> >
> > _______________________________________________
> > BIER mailing list
> > BIER@ietf.org
> > https://www.ietf.org/mailman/listinfo/bier


From nobody Sun Sep 28 02:47:17 2014
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 99F8C1A1A50 for ; Sun, 28 Sep 2014 02:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 eXrMqSTxgt2N for ; Sun, 28 Sep 2014 02:47:13 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42B2B1A1A4F for ; Sun, 28 Sep 2014 02:47:13 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNB98125; Sun, 28 Sep 2014 09:47:11 +0000 (GMT)
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 28 Sep 2014 10:47:08 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Sun, 28 Sep 2014 17:47:01 +0800
From: Xuxiaohu 
To: IJsbrand Wijnands , "bier@ietf.org" 
Thread-Topic: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
Thread-Index: AQHP2kdlfZsbDGYuOEWU1TTOV6liPpwWOVLA
Date: Sun, 28 Sep 2014 09:47:00 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC6E8@NKGEML512-MBS.china.huawei.com>
References: <20140927113332.3734.38144.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/ePaSYr1SZKIOg80wctFqy_m_LnI
Subject: Re: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.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, 28 Sep 2014 09:47:15 -0000

Hi co-authors,

I wonder what's the major motivation of advertising the BIER-MPLS-label ran=
ge and BFR-ID information within a single sub-TLV, especially the sub-TLV o=
f the Extended Prefix TLV. IMHO, the BFR-ID information could be carried ei=
ther within a sub-TLV of the Extended Prefix TLV or within a TLV of the OSP=
F RI LSA. The irreplaceable use case for the former approach is to allow a =
mapping server to advertise BFR-ID to BFR-prefix mappings on behalf of all =
BFERs. No matter which approach would be used, it seems no need to carry th=
e MT-ID field together since the BFR-ID is MT-irrelevant. As for the BIER-M=
PLS-label range, even assume it is proved to be useful in the end (for more=
 details, see my previous emails of today in another thread), it seems bett=
er to advertise that label range within a TLV of the OSPF RI LSA rather tha=
n within a sub-TLV of the Extended Prefix TLV due to the fact that a non-eg=
ress BFR (i.e., transit BFR or BFIR) does not need to be assigned with a ro=
utable IP address acting as BIER-prefix (this is especially true in the ISI=
S case). In other words, this label range information is node-specific, rat=
her than prefix-specific.=20

Best regards,
Xiaohu

> -----Original Message-----
> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand Wijnands
> Sent: Saturday, September 27, 2014 7:37 PM
> To: bier@ietf.org
> Subject: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
>=20
> FYI.
>=20
> Begin forwarded message:
>=20
> > From: 
> > Subject: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
> > Date: 27 Sep 2014 13:33:32 GMT+2
> > To: 
> > Reply-To: 
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
> >
> >
> >        Title           : OSPF Extensions For BIER
> >        Authors         : Peter Psenak
> >                          Nagendra Kumar
> >                          IJsbrand Wijnands
> >                          Andrew Dolganow
> > 	Filename        : draft-psenak-ospf-bier-extensions-00.txt
> > 	Pages           : 6
> > 	Date            : 2014-09-27
> >
> > 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 the OSPF protocol extension required for BIER
> >   with MPLS encapsulation.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-psenak-ospf-bier-extensions/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-psenak-ospf-bier-extensions-00
> >
> >
> > 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.i=
etf.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
>=20
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier


From nobody Sun Sep 28 02:57:33 2014
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 7C6541A1A50 for ; Sun, 28 Sep 2014 02:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 j_elA9jr5UnV for ; Sun, 28 Sep 2014 02:57:30 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0952F1A1A4F for ; Sun, 28 Sep 2014 02:57:29 -0700 (PDT)
Received: by mail-ig0-f178.google.com with SMTP id l13so243285iga.17 for ; Sun, 28 Sep 2014 02:57:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9kcwkxGKnq9sHFpqt5VajyNHcuYRmtfA4UD+rfcbdQQ=; b=NOMVVboWM8s4XJwhORtM5az6yHSuY0N+IzQcD7gnd3yhvUuArGtq0yf9ehY3uOuQ4z mVimJ/0OPTQkkXhrOOebk/LI1VPrZ+SKBbDKjbBKMrXgQuxOQOqzYp4FZJ6eXLHwkkye DQkBPgnSnvZq7lhx+cbasJz7kAWT9O5TCfmPrh9Wy/bfsAUZC+DQeTWjuimFGM5Ysc5s Q8XNn+Oqy6hYhBMGf20QEKL9S3dsQQX68xYQFauRQyDL4d2Xcw1uLRRQe+3OSp/QCFrX 2+mSMFmbKCLqInr+iPgkqMaxH0F5X6dUIdWTJnR+FPMNkeZzsSf/bQDCwffKrAscLrqW ik9A==
MIME-Version: 1.0
X-Received: by 10.43.155.13 with SMTP id lg13mr39153709icc.15.1411898249242; Sun, 28 Sep 2014 02:57:29 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.166.8 with HTTP; Sun, 28 Sep 2014 02:57:29 -0700 (PDT)
In-Reply-To: <77EEB0EC-1881-4CDE-8D0D-357710CD0CC6@cisco.com>
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>      <77EEB0EC-1881-4CDE-8D0D-357710CD0CC6@cisco.com>
Date: Sun, 28 Sep 2014 11:57:29 +0200
X-Google-Sender-Auth: zZXEVD4TBBwTf4Cn5M8bffkYYx4
Message-ID: 
From: Robert Raszuk 
To: IJsbrand Wijnands 
Content-Type: multipart/alternative; boundary=001a11c22eb69b1e8a05041d2d54
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/tGDx1l9s8AIGcaOJwxljFdNZTVA
Cc: "bier@ietf.org" , "Nagendra Kumar Nainar \(naikumar\)" , Antoni Przygienda , "Eric Rosen \(erosen\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 28 Sep 2014 09:57:31 -0000

--001a11c22eb69b1e8a05041d2d54
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

H=E2=80=8Bello Ice,=E2=80=8B


> BIER forwarding is based on IGP, the Bits in the BIER header are looked u=
p
> in the IGP on a per hop basis and forwarded accordingly.
>

=E2=80=8BFor the last 10+ years we both have heard number of real customer =
requests
no to follow IGP for multicast streams.

P2MP RSVP-TE is one example ..

We have also seen number of valid reasons for disjoined distribution of the
*same* streams.

BIER architecture mentions the option to use multi-topology extensions. But
it is not clear to me how the encapsulation carries which MT index given
packet should use at any BFR.
=E2=80=8B
Perhaps the label you are advertising in IGP for the BFR is already a
context label ?

But is MT really sufficient ?

It is not clear to me how I can practically build equivalent of 100 P2MP
RSVP-TE trees for say HD TV with MT.

For the "disjoned" requirement while you can build different topologies and
put different links in it to create N planes the bandwith efficiency of
such solution and the opex to maintain it would be rather close to
nightmare.


> If you=E2=80=99re next reply is going to suggest we need source routed pa=
ths for
> multicast, work through a couple of examples before pressing the send
> button :-)
>

=E2=80=8BYou missed my point. I was talking about the case where you have a=
 hard
requirement to use RSVP-TE like path which segment routing can do. Then at
the end of last segment use bitstring (possibly with SIs) for efficient
replication.

Your current solution replication relies heavily on IGP to make the
forwarding and replication as efficient as possible. But as Dino already
said this is not an OVERLAY at all. Sure it is much better then using
native protocols to build a m-cast tree in the WAN, but it is still very
heavy network centric solution.

And even so not all core network routers need to be BFRs the way I
understand current proposal all edge routers must participate in the IGP
extensions to get any multicast packet sent to it by BIER - isn't it ?

Of course one option is to have OSPF ABR or ISIS L1L2 to act as BIER proxy
and maybe even we will see a draft poping up soon on it :) But again it
will be network centric solution ...

Cheers,
R.

--001a11c22eb69b1e8a05041d2d54
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


H=E2=80=8Bello Ice,=E2=80=8B
=C2=
=A0

BIER forwarding is based on IGP, the Bits in the BIER header are looked up =
in the IGP on a per hop basis and forwarded accordingly.

=E2=80=8BFor the last 10+ years w=
e both have heard number of real customer requests no to follow IGP for mul=
ticast streams.=C2=A0

P2MP RSVP-TE is one example ..=C2=A0

We have also seen number of valid reason=
s for disjoined distribution of the *same* streams.=C2=A0

BIER architecture mention=
s the option to use multi-topology extensions. But it is not clear to me ho=
w the encapsulation carries which MT index given packet should use at any B=
FR.
=E2=80=8B
Per=
haps the label you are advertising in IGP for the BFR is already a context =
label ?

But =
is MT really sufficient ?=C2=A0

It is not clear to me how I can practically build equiv=
alent of 100 P2MP RSVP-TE trees for say HD TV with MT.

For the "disjoned&quo=
t; requirement while you can build different topologies and put different l=
inks in it to create N planes the bandwith efficiency of such solution and =
the opex to maintain it would be rather close to nightmare.=C2=A0
=C2=A0
If you=E2=80=99re next reply is going to suggest we need=
 source routed paths for multicast, work through a couple of examples befor=
e pressing the send button :-)

=E2=80=8BYou missed my point. I was talking about the case =
where you have a hard requirement to use RSVP-TE like path which segment ro=
uting can do. Then at the end of last segment use bitstring (possibly with =
SIs) for efficient replication.=C2=A0

Your current solution replication relies heavily =
on IGP to make the forwarding and replication as efficient as possible. But=
 as Dino already said this is not an OVERLAY at all. Sure it is much better=
 then using native protocols to build a m-cast=C2=A0tree=C2=A0in the WAN, b=
ut it is still very heavy network centric solution.=C2=A0

And even so not all core ne=
twork routers need to be BFRs the way I understand current proposal all edg=
e routers must participate in the IGP extensions to get any multicast packe=
t sent to it by BIER - isn't it ? =C2=A0
<=
br>
Of course one option is to have OSPF ABR o=
r ISIS L1L2 to act as BIER proxy and maybe even we will see a draft poping =
up soon on it :) But again it will be network centric solution ...

Cheers,
R.
<=
div class=3D"gmail_default" style=3D"font-family:'courier new',mono=
space;font-size:small">


--001a11c22eb69b1e8a05041d2d54--


From nobody Sun Sep 28 03:42:33 2014
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 AAA4B1A0394 for ; Sun, 28 Sep 2014 03:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 V6nODqjSvgdn for ; Sun, 28 Sep 2014 03:42:31 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE431A0235 for ; Sun, 28 Sep 2014 03:42:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=695; q=dns/txt; s=iport; t=1411900951; x=1413110551; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=A1C0Bhmx+RR37phP/c5HpDxs1VYG+MZhI+znlgkAKuA=; b=Ot7rCl8znV4W5SHhSE6C1Sys2ipPzyLLGsNiVHnpvHk/U28DIRSRWQsb h4CXTvbrWv7v0Ww4gH3IICMD7IKF18Y3VpFQITCYqXnr6xIMx4i6NXva3 hbE0W6LiBNFiHWA1lyhmpSlSk9w+XkjZKdSURMRjnTdFyhji5oR7VYLXy I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUKAMflJ1StJssW/2dsb2JhbABWCrl7BQFymlcCgRMBe4QEAQEDAXkFCwtGVwaISQi+OwEXhhKJMCkzB4MugR0BBJ0olV2DZTuCeQEBAQ
X-IronPort-AV: E=Sophos;i="5.04,613,1406592000"; d="scan'208";a="191847607"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 28 Sep 2014 10:42:29 +0000
Received: from ams3-vpn-dhcp4102.cisco.com (ams3-vpn-dhcp4102.cisco.com [10.61.80.5]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8SAgQNH010996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Sep 2014 10:42:29 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: IJsbrand Wijnands 
In-Reply-To: 
Date: Sun, 28 Sep 2014 12:42:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "S, Somasundaram (Somasundaram)" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/yMIKhN4jMMDj9wzeIIKXdd1oZFM
Cc: "bier@ietf.org" 
Subject: Re: [Bier] BIER Encapsulation..
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, 28 Sep 2014 10:42:32 -0000

Hi Somasundaram,

> Regarding *draft-wijnands-mpls-bier-encapsulation-00*
> =20
> Given that  BIER packets packets are MPLS encapsulated (SI is =
identified based on the Label), how would forwarding take place in a =
pure IGP domain (where MPLS is not configured/supported)?

There always needs to be some sort of encapsulation to encode the =
BitString. So I don=92t expect BIER to be supported on a native IP =
packets. But you raise a good point, the BIER procedures are agnostic to =
any sort of encapsulation. With MPLS we use the top label to identify =
the SI, which is a nice way to encode it and prevents an additional =
lookup in the forwarding plane.=20

Thx,

Ice.


From nobody Sun Sep 28 04:02:51 2014
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 D6BBC1A0324 for ; Sun, 28 Sep 2014 04:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 bRjITSKRLU35 for ; Sun, 28 Sep 2014 04:02:47 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989261A02BB for ; Sun, 28 Sep 2014 04:02:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3634; q=dns/txt; s=iport; t=1411902166; x=1413111766; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=mk5GFubXBcVSVqYjV6M9eTvQZ+U5oX1pI1h5npjIsgA=; b=Olxo5Vvf49fPzjymhZfnWOUsy+j0LAtV5jAwTt6MiI2IY4o0g3/ht9Ie Hw8VJGHlz4GQaYAksgxkGiCZGUAi+7joWPRSvuOk/pWIgl8aqyRV7ZphD it0bRh87OnY8jvTIOxoJJh3welnhHciUWa/KYBEFNlh8kUsUG1VD5jAjk 4=;
X-IronPort-AV: E=Sophos;i="5.04,613,1406592000"; d="scan'208";a="187754031"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 28 Sep 2014 11:02:44 +0000
Received: from ams3-vpn-dhcp4102.cisco.com (ams3-vpn-dhcp4102.cisco.com [10.61.80.5]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8SB2a1j024396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Sep 2014 11:02:44 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: IJsbrand Wijnands 
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC694@NKGEML512-MBS.china.huawei.com>
Date: Sun, 28 Sep 2014 13:02:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: Your message of Fri, 26 Sep 2014 16:11:17 +0100. <051501cfd99c$205b1780$61114680$@olddog.co.uk> <9767.1411750052@erosen-lnx> <065a01cfd9dc$f45f1be0$dd1d53a0$@olddog.co.uk> <873A5047-32D7-4AAB-ABE7-FF8C23166C1F@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC602@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F181B6095@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC694@NKGEML512-MBS.china.huawei.com>
To: Xuxiaohu 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/YMlkjkqtSNPnoW7c1WTV0K292c4
Cc: "bier@ietf.org" , "adrian@olddog.co.uk" , "erosen@cisco.com" , Antoni Przygienda 
Subject: Re: [Bier] MPLS encapsulation
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, 28 Sep 2014 11:02:49 -0000

Hi Xuxiaohu,

>> For MPLS, one (very good reason) is that we do have _very_ fast MPLS =
label
>> lookup fast-paths, we do not have MT-ID & Set-ID lookup engines.  =
SetID is
>=20
> If I understand it correctly, the intention of the BIER-MPLS label =
lookup is to find the corresponding SI and MT-ID. By directly carrying =
the SI and MT-ID information in the BIER header, there is no need for =
that MPLS lookup at all even though that lookup is _very_ fast. =
Furthermore, there is no need any specific label distribution process =
for the BIER-MPLS-labels, especially IGP flooding-based distribution =
process. BTW, is it efficient to flood the BIER-MPLS-label bindings =
which are actually only meaningful to adjacent BFRs to all IGP peers =
within the whole IGP domain?

All great points.

We always need some sort of encapsulation to store the BIER header. We =
can come up with a new ethertype potentially and skip MPLS. But why =
would we want to introduce yet an other encapsulation when MPLS can =
already solve the problem for us, and, provides great value IMO. Think =
about how we can stick a BIER MPLS packet over a LFA/TE FRR tunnel, etc=85=
 However, you still have a good point and we may work on other ways to =
encapsulate the BIER header. For that reason we have two drafts, and =
architecture draft and an encapsulation draft :-)

The label bindings are flooded indeed. There are features that can make =
use of knowing the labels of your neighbors.

>=20
>> arguable as being in encaps but a label representing a set in MPLS is =
simply
>> extremely natural to MPLS. MT-ID has actually no business in the =
fast-path I
>> would say, the scope of validity of MT-ID is in the IGP control plane =
only. Building
>=20
> Disagree with the above argument. The MT-ID is not only useful in the =
IGP control plane but also useful in the data plane. Otherwise, how =
could a BFR determine which set of the IP forwarding table entries =
should be looked up for IP packet forwarding? Of course, MPLS-MT is a =
slightly different since the MPLS label itself could be used to indicate =
which MT's routing table should be used. However, to define a =
transport-independent BIER encapsulation, it's better for the MT-ID =
information to be contained in the BIER header. In addition, wouldn't =
the BIER-in-MAC be more prevalent than the BIER-in-MPLS provided the SI =
and MT-ID information is contained in the BIER header? IMHO, the only =
irreplaceable use case for BIER-in-MPLS is to use the IGP shortcut or FA =
for BIER-encapsulated packet forwarding.

Lets not throw out the baby with the bath water. If MPLS is used to =
encapsulate the BIER header, lets also use the benefits that MPLS =
provides. If we make the BIER header more generic, we loose those =
advantages.

>> As to MPLS ranges, this is something that is fashionable these days, =
IMO each set
>> should have a completely independent label on it but there are =
trade-offs in
>> terms of control plane complexity/protocol packet sizes vs. fast-path =
complexity
>> vs. what people already have in silicon and so on.
>=20
> Since the BIER itself requires changes to both control plane and data =
plane anyway, I have not yet seen any significant advantage of the =
BIER-MPLS-label over a BIER header which contains MT-ID and SI =
information in those terms that you have mentioned above.

I think avoiding a SI & MT-ID lookup in the data plane by associating a =
different MPLS label with it is significant advantage, it simplifies the =
data-plane and make its faster.

Thx,

Ice.



From nobody Sun Sep 28 04:13:38 2014
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 A94E31A1A4F for ; Sun, 28 Sep 2014 04:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 stZLBRB1swvm for ; Sun, 28 Sep 2014 04:13:09 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D3C1A0394 for ; Sun, 28 Sep 2014 04:13:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3554; q=dns/txt; s=iport; t=1411902789; x=1413112389; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uZifiFF5XLRHuRdIA4X+WOeSdElh2kgdrV+2B7z3MyQ=; b=Ws7z/KAAFcDYOcOVfCONVSuBd6Iz5ZZqxuEDtINFGi9tY/5jXY1KkmXA /PlicoBijzrMq4sv7K4AhM+T2iCZsvDRcwNph+akn53aOF88s3Jq65GTM yrarLGMM6CdThUFF6XFDJNaTXCNDHW7Jz8kkuu4izMuDIcX6MoW0/mHrZ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmQQAODrJ1StJssW/2dsb2JhbABgg2FXtUMFAXKSfwqHSgICAoETAXuEAwEBAQMBAQEBawsFBwQLEQECAQEBKAcnHwMGCAYTCYgtCA2+LAEXhhKJNSQzBwaDKIEdBZYfhwmBYo02hkWDZTsvAYEGgUMBAQE
X-IronPort-AV: E=Sophos;i="5.04,613,1406592000"; d="scan'208";a="187793905"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 28 Sep 2014 11:13:06 +0000
Received: from ams3-vpn-dhcp4102.cisco.com (ams3-vpn-dhcp4102.cisco.com [10.61.80.5]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8SBD6IJ001891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Sep 2014 11:13:06 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: IJsbrand Wijnands 
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC6E8@NKGEML512-MBS.china.huawei.com>
Date: Sun, 28 Sep 2014 13:13:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20140927113332.3734.38144.idtracker@ietfa.amsl.com>  <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC6E8@NKGEML512-MBS.china.huawei.com>
To: Xuxiaohu 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/1JYvMezBzCLYPlqkHcNkjX52SIE
Cc: "bier@ietf.org" 
Subject: Re: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.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, 28 Sep 2014 11:13:22 -0000

Xuxiaohu,

> the ISIS case). In other words, this label range information is =
node-specific, rather than prefix-specific.=20

Why limit your self? I may be beneficial to have two different MT-ID=92s =
(on the same node) to be associated with two different BFR-Prefix=92s. =
The reachability of the BFR=92s is strictly based on an BFR-Prefix =
address, so it makes a lot of sense (IMO), if you have the flexibly to =
choose the address you like to associate with it.

Thx,

Ice.


>=20
> Best regards,
> Xiaohu
>=20
>> -----Original Message-----
>> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand =
Wijnands
>> Sent: Saturday, September 27, 2014 7:37 PM
>> To: bier@ietf.org
>> Subject: [Bier] Fwd: I-D Action: =
draft-psenak-ospf-bier-extensions-00.txt
>>=20
>> FYI.
>>=20
>> Begin forwarded message:
>>=20
>>> From: 
>>> Subject: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
>>> Date: 27 Sep 2014 13:33:32 GMT+2
>>> To: 
>>> Reply-To: 
>>>=20
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>>=20
>>>=20
>>>       Title           : OSPF Extensions For BIER
>>>       Authors         : Peter Psenak
>>>                         Nagendra Kumar
>>>                         IJsbrand Wijnands
>>>                         Andrew Dolganow
>>> 	Filename        : draft-psenak-ospf-bier-extensions-00.txt
>>> 	Pages           : 6
>>> 	Date            : 2014-09-27
>>>=20
>>> 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.
>>>=20
>>>  This document describes the OSPF protocol extension required for =
BIER
>>>  with MPLS encapsulation.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-psenak-ospf-bier-extensions/
>>>=20
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-psenak-ospf-bier-extensions-00
>>>=20
>>>=20
>>> 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.
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> _______________________________________________
>>> 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
>>=20
>> _______________________________________________
>> BIER mailing list
>> BIER@ietf.org
>> https://www.ietf.org/mailman/listinfo/bier


From nobody Sun Sep 28 04:19:04 2014
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 6509C1A1A39 for ; Sun, 28 Sep 2014 04:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 i4yY5EFb_Tg0 for ; Sun, 28 Sep 2014 04:19:00 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3AC1A1A37 for ; Sun, 28 Sep 2014 04:18:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=167; q=dns/txt; s=iport; t=1411903140; x=1413112740; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4v9BFTgSrn3ejGTAlQf78R5PmmaLZ0yrWMtR8glFMp8=; b=YzvjvMtDo1XuvSS28DJUC7KezaFlQJr3d3tsDnaz+04SnhDeq20Y1hO6 I8GrmTN/2vvXqJ5hqRoE8HPBwMvZBpzDLOd5TdTV1b4j/wZgn+vOtRmaa K9T5UvvPXH5H2OrVM0gF58ZAkCFAOS65Zm7Vt9mMLJ5Z08xWKvje35gzz c=;
X-IronPort-AV: E=Sophos;i="5.04,613,1406592000"; d="scan'208";a="192528378"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 28 Sep 2014 11:18:57 +0000
Received: from ams3-vpn-dhcp4102.cisco.com (ams3-vpn-dhcp4102.cisco.com [10.61.80.5]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8SBIuMO027500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Sep 2014 11:18:57 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: IJsbrand Wijnands 
In-Reply-To: 
Date: Sun, 28 Sep 2014 13:18:55 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>      <77EEB0EC-1881-4CDE-8D0D-357710CD0CC6@cisco.com> 
To: Robert Raszuk 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/k8RqPpTWXoaqbqAiaILok3OHGyc
Cc: "bier@ietf.org" , "Nagendra Kumar Nainar \(naikumar\)" , Antoni Przygienda , "Eric Rosen \(erosen\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 28 Sep 2014 11:19:01 -0000

Robert,

You keep re-homing the discussion to a different topic again and again.

The point we are making is that BIER does not belong in SPRING.

Thx,

Ice.


From nobody Sun Sep 28 05:04:16 2014
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 9E1481A1A6C for ; Sun, 28 Sep 2014 05:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 219Cx6HFy8wh for ; Sun, 28 Sep 2014 05:04:12 -0700 (PDT)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BE41A1A79 for ; Sun, 28 Sep 2014 05:03:58 -0700 (PDT)
Received: by mail-ig0-f180.google.com with SMTP id a13so1877553igq.13 for ; Sun, 28 Sep 2014 05:03:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qssSgOelpk8zsniqyGdA/q8i3DVP53YeRaRy1vhsKuc=; b=yNtnqNNNtgl/q6qmOqbM6SOa9jx5keOwTNjbn53YDaN97wcdTUcysa0Bb1NkS7eQK5 vIfRkefav/hc6FMd8ZLaXPETC7O0sH6Tgf/r5FaMluG6SUjqC6G1jUe2J+9/Qyi3HQR9 thPgrGsxZeatyu5NDHO1+BlG1uJlAnmvGMWEiLJCCwGeCado6vokK+CDgXNdk7STiKIy HfPzo0wt6DrLtynOnuXMgeyUcPg/6qND4y+8aEEbQYJK6Gkcwt6zBwmPq9bLrFVw3DKu IlXuFvKc5EWWp/IpfQGPgZkA4OeI+jlcEymIN7nrlH0W9wpEMgMWRcdrpqY6U4GxAtVI P9+w==
MIME-Version: 1.0
X-Received: by 10.43.61.4 with SMTP id wu4mr1048333icb.77.1411905837742; Sun, 28 Sep 2014 05:03:57 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.107.166.8 with HTTP; Sun, 28 Sep 2014 05:03:57 -0700 (PDT)
In-Reply-To: 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>      <77EEB0EC-1881-4CDE-8D0D-357710CD0CC6@cisco.com>  
Date: Sun, 28 Sep 2014 14:03:57 +0200
X-Google-Sender-Auth: avo5GxkFthErMl-Y7jm72Q7fL78
Message-ID: 
From: Robert Raszuk 
To: IJsbrand Wijnands 
Content-Type: multipart/alternative; boundary=bcaec51d2064ea42fd05041ef1a2
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/s-xjO-rLtGkFyTWq3h5atHydTrQ
Cc: "bier@ietf.org" , "Nagendra Kumar Nainar \(naikumar\)" , Antoni Przygienda , "Eric Rosen \(erosen\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 28 Sep 2014 12:04:13 -0000

--bcaec51d2064ea42fd05041ef1a2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=E2=80=8BIce,=E2=80=8B


> You keep re-homing the discussion to a different topic again and again.
>

=E2=80=8BI asked few questions to better understand the proposal. Most of t=
hem have
not been answered so far :)=E2=80=8B


> The point we are making is that BIER does not belong in SPRING.
>

SPRING charter says:

"The SPRING working group will define procedures that
will allow a node to steer a packet along an explicit
route using information attached to the packet and
without the need for per-path state information to be
held at transit nodes. Full explicit control (through loose or strict path
specification) can be achieved in a network comprising only SPRING nodes,
however SPRING must inter-operate through loose routing in existing
networks and may find it advantageous to use loose routing for for other
network applications.=E2=80=8B"

=E2=80=8BWhy I see similarities:=E2=80=8B

* =E2=80=8BBIER adds information (bitstring/SI) to the packets on ingress w=
hich
determine how the packet is to be forwarded via the network nodes. =E2=80=
=8B

* While BIER does not add explicit path one can interpret bitstring as
special case of Loose Path Specification where you indicate just the egress
points or SI-subnets.

Anyway if you want to have a new group for it - make it happen. What to me
is more important however is how the BIER will be useful in practice.

Cheers,
R.

--bcaec51d2064ea42fd05041ef1a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


=E2=80=8BIce,=E2=80=8B
=C2=A0
You keep re-homing the discussion to a different topic ag=
ain and again.

=
=E2=80=8BI asked few questions to better understand the proposal. Most of t=
hem have not been answered so far :)=E2=80=8B
=C2=A0
The point we are making is that BIER does not belong in=
 SPRING.

SPRING=
 charter says:

"The SPR=
ING working group will define procedures that=C2=A0
will allow=
 a node to steer a packet along an explicit=C2=A0
route using =
information attached to the packet and
without the need for pe=
r-path state information to be
held at transit nodes. Full exp=
licit control (through loose or strict path specification) can be achieved =
in a network comprising only SPRING nodes, however SPRING must inter-operat=
e through loose routing in existing networks and may find it advantageous t=
o use loose routing for for other network applications.=E2=80=8B"

=E2=
=80=8BWhy I see similarities:=E2=80=8B

* =E2=80=8BBIER adds information (bitstring/SI) to the packet=
s on ingress which determine how the packet is to be forwarded via the netw=
ork nodes. =E2=80=8B

* While BIER does not add explicit path one can interpret bitstrin=
g as special case of Loose Path Specification where you indicate just the e=
gress points or SI-subnets.

Anyway if you want to have a new group for it - make it hap=
pen. What to me is more important however is how the BIER will be useful in=
 practice.

C=
heers,
R.



--bcaec51d2064ea42fd05041ef1a2--


From nobody Sun Sep 28 05:14:21 2014
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 603E01A02E6 for ; Sun, 28 Sep 2014 05:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 h__wqcHx5OyC for ; Sun, 28 Sep 2014 05:14:15 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CEB81A1A6E for ; Sun, 28 Sep 2014 05:14:15 -0700 (PDT)
Received: by mail-ig0-f178.google.com with SMTP id l13so325598iga.17 for ; Sun, 28 Sep 2014 05:14:14 -0700 (PDT)
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=XHIv9NW318tla8l5lfYjDa2j8345QxqLamb75KfHhyk=; b=aZV2pRpoMGmElE0VKImF9qngMg+7TNXsarTobJlCJJVvsGayL3feb/gCFHg2gwEoQg dZaK99PkE3WGVR1deTW/s6M4OwK0/ji9BDSm55+kMybXuhDWOrrof9TIfth5RXGWZWeM 60Pi4hiW+1YkZlCPRnt4FKjdQo7kjywcGPxKeyIrY8kY7mWbuE4QXQJUmZXqcjsmvLpO F8KLJGADAikjOBKBlgMuyJZPgVA4rkcoupicdIlJaFuqI1Xa02C9HjMa0KnDaWbnu6uc QqKkquZV3D7gSMInsGXudfLLdWR4KuiZ479/jJPmgu9zJ6tYJvTcUdC4+Not9t/R1xEo NIyw==
MIME-Version: 1.0
X-Received: by 10.50.26.66 with SMTP id j2mr23194810igg.45.1411906454806; Sun, 28 Sep 2014 05:14:14 -0700 (PDT)
Received: by 10.107.28.202 with HTTP; Sun, 28 Sep 2014 05:14:14 -0700 (PDT)
In-Reply-To: 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>      <77EEB0EC-1881-4CDE-8D0D-357710CD0CC6@cisco.com>   
Date: Sun, 28 Sep 2014 05:14:14 -0700
Message-ID: 
From: Greg Shepherd 
To: Robert Raszuk 
Content-Type: multipart/alternative; boundary=047d7bd75bb2b1e63605041f169e
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/NiloblZDRHU5dSVb5owdJj5Qec4
Cc: "Nagendra Kumar Nainar \(naikumar\)" , "bier@ietf.org" , IJsbrand Wijnands , "Eric Rosen \(erosen\)" , Antoni Przygienda 
Subject: Re: [Bier] One specific transition churn ...
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: Sun, 28 Sep 2014 12:14:18 -0000

--047d7bd75bb2b1e63605041f169e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks Robert. We've currently asked for a non-WG BoF in HI. Based on the
discussion here on the list, and that in the BoF, the community will make a
decision as to IF this work should be adopted by the IETF, and if so, where
the work should take place. It has been my experience that every WG in the
IETF not specifically working on mcast issues treats any mcast requirements
as the bastard stepchild and those mcast reqs never fully get addressed.

In some cases they've even punted the mcast reqs over to MBONED which is in
OPS and should not be working on protocols. BIER is intended to
specifically address a set of mcast issues. Having a focused community to
addresses them is most likely the fastest path to success.

Greg

On Sun, Sep 28, 2014 at 5:03 AM, Robert Raszuk  wrote:

> =E2=80=8BIce,=E2=80=8B
>
>
>> You keep re-homing the discussion to a different topic again and again.
>>
>
> =E2=80=8BI asked few questions to better understand the proposal. Most of=
 them
> have not been answered so far :)=E2=80=8B
>
>
>> The point we are making is that BIER does not belong in SPRING.
>>
>
> SPRING charter says:
>
> "The SPRING working group will define procedures that
> will allow a node to steer a packet along an explicit
> route using information attached to the packet and
> without the need for per-path state information to be
> held at transit nodes. Full explicit control (through loose or strict pat=
h
> specification) can be achieved in a network comprising only SPRING nodes,
> however SPRING must inter-operate through loose routing in existing
> networks and may find it advantageous to use loose routing for for other
> network applications.=E2=80=8B"
>
> =E2=80=8BWhy I see similarities:=E2=80=8B
>
> * =E2=80=8BBIER adds information (bitstring/SI) to the packets on ingress=
 which
> determine how the packet is to be forwarded via the network nodes. =E2=80=
=8B
>
> * While BIER does not add explicit path one can interpret bitstring as
> special case of Loose Path Specification where you indicate just the egre=
ss
> points or SI-subnets.
>
> Anyway if you want to have a new group for it - make it happen. What to m=
e
> is more important however is how the BIER will be useful in practice.
>
> Cheers,
> R.
>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>

--047d7bd75bb2b1e63605041f169e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks Robert. We've currently asked for a non-WG BoF =
in HI. Based on the discussion here on the list, and that in the BoF, the c=
ommunity will make a decision as to IF this work should be adopted by the I=
ETF, and if so, where the work should take place. It has been my experience=
 that every WG in the IETF not specifically working on mcast issues treats =
any mcast requirements as the bastard stepchild and those mcast reqs never =
fully get addressed.

In some cases they've even punt=
ed the mcast reqs over to MBONED which is in OPS and should not be working =
on protocols. BIER is intended to specifically address a set of mcast issue=
s. Having a focused community to addresses them is most likely the fastest =
path to success.

Greg
=

On Sun, Sep 28, 2014 at 5:03 AM, Robert Rasz=
uk <robert@raszuk.net> wrote:
=

=E2=80=8BIce,=E2=80=8B
=C2=A0
=
You keep re-homing the discussion to a different topic again and again.
=


=E2=80=8BI asked few questions to better u=
nderstand the proposal. Most of them have not been answered so far :)=E2=80=
=8B
=C2=A0
The point we are makin=
g is that BIER does not belong in SPRING.

SPRING charter says:

"The SPRING working group will define procedure=
s that=C2=A0
route using information =
attached to the packet and
without the need for per-path state information to be
=

held at transit =
nodes. Full explicit control (through loose or strict path specification) c=
an be achieved in a network comprising only SPRING nodes, however SPRING mu=
st inter-operate through loose routing in existing networks and may find it=
 advantageous to use loose routing for for other network applications.=E2=
=80=8B"

=E2=80=8BWhy I see similarities:=E2=
=80=8B

* =E2=80=8BBIER adds information (bitstrin=
g/SI) to the packets on ingress which determine how the packet is to be for=
warded via the network nodes. =E2=80=8B

* While BIER does no=
t add explicit path one can interpret bitstring as special case of Loose Pa=
th Specification where you indicate just the egress points or SI-subnets.

Anyway if you want to have a new group for it - make it happe=
n. What to me is more important however is how the BIER will be useful in p=
ractice.

Cheers,
R.



_______________________________________________

BIER mailing list

BIER@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/bier





--047d7bd75bb2b1e63605041f169e--


From nobody Sun Sep 28 05:24:27 2014
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 032EF1A1A6E for ; Sun, 28 Sep 2014 05:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 YLZ8Rv1uaOTW for ; Sun, 28 Sep 2014 05:24:26 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60641A1A6C for ; Sun, 28 Sep 2014 05:24:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=621; q=dns/txt; s=iport; t=1411907065; x=1413116665; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=377YngePwBry0wJxIwGRRHO5qHvvoBSrlJkVxlO9LqQ=; b=kuOB2IEpVUzOj6JYjgwh5tJjXjvvHHnvutJztKbmW68mnXy5fXsnjZxd 0DUnXCwhJL8QTkSDtzVS34jJ3alMa8SsWPSBN4g/rAa4+6/we3GjmVIWO OmholxK50M2vWo4o64o4iDGX9+cmj/8yTxZNNP0Xm8qeSz3ckkMiOZ8ae 0=;
X-IronPort-AV: E=Sophos;i="5.04,614,1406592000"; d="scan'208";a="187851833"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 28 Sep 2014 12:24:23 +0000
Received: from ams3-vpn-dhcp4102.cisco.com (ams3-vpn-dhcp4102.cisco.com [10.61.80.5]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8SCOKUU026500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Sep 2014 12:24:22 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: IJsbrand Wijnands 
In-Reply-To: 
Date: Sun, 28 Sep 2014 14:24:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>      <77EEB0EC-1881-4CDE-8D0D-357710CD0CC6@cisco.com>   
To: Robert Raszuk 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/K05nJ_7aeAMLH0LZ0Jq2JDhQ2NI
Cc: "bier@ietf.org" , "Nagendra Kumar Nainar \(naikumar\)" , Antoni Przygienda , "Eric Rosen \(erosen\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 28 Sep 2014 12:24:27 -0000

Robert,

> =E2=80=8BWhy I see similarities:=E2=80=8B
>=20
> * =E2=80=8BBIER adds information (bitstring/SI) to the packets on =
ingress which determine how the packet is to be forwarded via the =
network nodes. =E2=80=8B

Incorrect, the Bit in the string determines who receives the packet, not =
how it is forwarded.

> * While BIER does not add explicit path one can interpret bitstring as =
special case of Loose Path Specification where you indicate just the =
egress points or SI-subnets.

You mean like a destination IP address in the IP packet is also a loose =
path? I disagree.

Thx,

Ice.=


From nobody Sun Sep 28 05:50:49 2014
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 238A51A1A8A for ; Sun, 28 Sep 2014 05:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xvBnaH6armlh for ; Sun, 28 Sep 2014 05:50:46 -0700 (PDT)
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 7F6BB1A1A81 for ; Sun, 28 Sep 2014 05:50:45 -0700 (PDT)
X-AuditID: c618062d-f79206d0000014d2-3d-5427adb564e2
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 13.B7.05330.5BDA7245; Sun, 28 Sep 2014 08:41:57 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Sun, 28 Sep 2014 08:50:37 -0400
From: Antoni Przygienda 
To: IJsbrand Wijnands , Xuxiaohu 
Thread-Topic: [Bier] MPLS encapsulation
Thread-Index: AQHP2amQQPBQ9OujR6OJTMN+0P37n5wUSaIAgADEqACAATanAP//vXCAgAByN4CAADKCAP//2a3g
Date: Sun, 28 Sep 2014 12:50:37 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181B615C@eusaamb103.ericsson.se>
References: Your message of Fri, 26 Sep 2014 16:11:17 +0100. <051501cfd99c$205b1780$61114680$@olddog.co.uk> <9767.1411750052@erosen-lnx> <065a01cfd9dc$f45f1be0$dd1d53a0$@olddog.co.uk> <873A5047-32D7-4AAB-ABE7-FF8C23166C1F@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC602@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F181B6095@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC694@NKGEML512-MBS.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPlO7WteohBs8fKFr86LnBbLF0xh4m i3V3J7FYvJpzh9li6/lVjA6sHlN+b2T1aDnyltVjyZKfTB4rNq9kDGCJ4rJJSc3JLEst0rdL 4MpYuGsWU8Ee5ooDs5ewNDA+Zupi5OSQEDCR6D/dxQxhi0lcuLeerYuRi0NI4CijxL2G61DO ckaJp3v6WUGq2AQsJC5/ewrWISLgKrHqwBuwOLNApcSBK8/B4sICahIbV19ihahRl9g74xY7 hB0l8XN1D5jNIqAq0TVzFpjNK+AtceD5V0aIZb+ZJXZMO8YGkuAUsJWYdhTiVEag876fWsME sUxc4taT+VAvCEgs2XMe6gVRiZeP/7FC2EoSH3/PZ4eo15FYsPsTG4StLbFs4WtmiMWCEidn PmGZwCg2C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCODTYzA2Domwaa7g3HPS8tDjAIcjEo8 vAuy1UOEWBPLiitzDzFKc7AoifPOqp0XLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRqeDh kVV/TrTdexzjktz6qCO/iO0EQ+Zl9U0OTfb9ggx7uz+uTNzC8He35iat1c6GE3jV5yfui7Nc ye/CnsPHvPlcmGXjujWbI6OCDjzTvjctO/x37cOlSXPnSZ/MtLqw+dSraV22Dy3r73GUxN2e X9O5vKvnkaP9PWXG9z1+vbuvsigW5asosRRnJBpqMRcVJwIA4+IYAY4CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/QhedRijQd4ptHrgnkE6bW2odZeQ
Cc: "adrian@olddog.co.uk" , "erosen@cisco.com" , "bier@ietf.org" 
Subject: Re: [Bier] MPLS encapsulation
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, 28 Sep 2014 12:50:48 -0000

again, the discussion thread IMO to be meaningful needs to be split into 'm=
pls encapsualtion'  OR 'any transport encapsulation'.  I have difficulties =
to follow arguments made otherwise.=20

I am not sure what 'transport independent encapsulation' would be and I thi=
nk it would be interesting to understand whether=20
BIER  is an L3 construct (like an IP frame) or it is an L2(.5) technology s=
uch as is MPLS.=20

--- tony=20


From nobody Sun Sep 28 06:13:25 2014
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 415AF1A1A6B for ; Sun, 28 Sep 2014 06:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Xd7QH44eELF8 for ; Sun, 28 Sep 2014 06:13:20 -0700 (PDT)
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 367921A1AA6 for ; Sun, 28 Sep 2014 06:13:19 -0700 (PDT)
X-AuditID: c618062d-f79206d0000014d2-09-5427b30687df
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D8.F7.05330.603B7245; Sun, 28 Sep 2014 09:04:38 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Sun, 28 Sep 2014 09:13:18 -0400
From: Antoni Przygienda 
To: IJsbrand Wijnands , Robert Raszuk 
Thread-Topic: [Bier] One specific transition churn ...
Thread-Index: AQHP2a+BuVUit1FzlkuzW2MzFDiDwZwTq93QgABarwCAABklgIAACfKAgAETewCAABE8gIABGkwAgAAsQ4CAABbAgIAADJaAgAAFsID//8hCIA==
Date: Sun, 28 Sep 2014 13:13:17 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181B618A@eusaamb103.ericsson.se>
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>      <77EEB0EC-1881-4CDE-8D0D-357710CD0CC6@cisco.com>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXSPny7bZvUQgwefBC2WztjDZLHu7iQW i1dz7jBbvJ44lc2iaWETswOrx5TfG1k9liz5yeSxe+MCpgDmKC6blNSczLLUIn27BK6MJTPv MxZ0cFS0/V/B2sD4hr2LkZNDQsBE4tjzeUwQtpjEhXvr2boYuTiEBI4ySuw70ADlLGeUWPi7 EayDTcBC4vK3p8wgtoiAh8SL/eeZQYqYBToYJY6vuwE2SljAVGLWhXcsEEVmElc2PmaFsOsk dryZBlbDIqAq8e3uBTCbV8BbYuuCLqhts9gknp09CNTAwcEpYCvR8ZUNpIYR6Lzvp9aA1TML iEvcejIf6mwBiSV7zjND2KISLx//Y4WwlSQ+/p7PDjKGWUBTYv0ufYhWRYkp3Q/ZIdYKSpyc +YRlAqPYLCRTZyF0zELSMQtJxwJGllWMHKXFqWW56UYGmxiB0XRMgk13B+Oel5aHGAU4GJV4 eBdkq4cIsSaWFVfmHmKU5mBREuedVTsvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj/aql 89i+KD9LtXpWc7LEYEVyq0vhNfOSuW8OLZ5UFreta5Wms5Pm5ZpLk3iS9ol8/S/wg/NhU8SC 5fUB6Zv0zn87wfRq4a1iDv5/X/4Fnj22dZeQ3dGs2wJHlRc/VOrZ84P9rZCaUnjyVM7EP1lb O3N8PBRWTPAJ/nvCOuXl+bk1Upu65WVKlViKMxINtZiLihMBD4ZRfYcCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/-9BYZFKuHp_jtHEAz7o3dhKxlh8
Cc: "Nagendra Kumar Nainar \(naikumar\)" , "bier@ietf.org" , "Eric Rosen \(erosen\)" 
Subject: Re: [Bier] One specific transition churn ...
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, 28 Sep 2014 13:13:22 -0000

PiA+ICogV2hpbGUgQklFUiBkb2VzIG5vdCBhZGQgZXhwbGljaXQgcGF0aCBvbmUgY2FuIGludGVy
cHJldCBiaXRzdHJpbmcgYXMNCj4gc3BlY2lhbCBjYXNlIG9mIExvb3NlIFBhdGggU3BlY2lmaWNh
dGlvbiB3aGVyZSB5b3UgaW5kaWNhdGUganVzdCB0aGUgZWdyZXNzDQo+IHBvaW50cyBvciBTSS1z
dWJuZXRzLg0KPiANCj4gWW91IG1lYW4gbGlrZSBhIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MgaW4g
dGhlIElQIHBhY2tldCBpcyBhbHNvIGEgbG9vc2UgcGF0aD8gSQ0KPiBkaXNhZ3JlZS4NCj4gDQoN
CltUb255IHNhaWRdICBJIGFncmVlIHdpdGggSWNlLCBhcmd1bWVudCBoZXJlIGhhcyBiZWVuIGxl
ZCBhZCBhYnN1cmR1bS4gV2UgYXJlIGhlcmUgdG8gZXhwbGFpbiwgaGVscCBhbmQgZGlzY3VzcyBh
bmQgYXBwcmVjaWF0ZSBpbnRlcmVzdCBvbiB0aGlzIGxpc3QgYnV0IGluIHRoaXMgY2FzZSBJIHN1
Z2dlc3QgdGhlIGRpc2N1c3Npb24gJ3doaWNoIFdHIGRvZXMgaXQgYmVsb25nIGludG8nIHRvIGJl
IHRha2VuIG9mZiB0aGlzIHRoZSBsaXN0IGN1cnJlbnRseSB0b3dhcmRzIEEtRHMgJiB0aGUgcHJv
cG9uZW50cyBvZiB3aGVyZSBpdCBiZWxvbmdzIG1heSBoYXZlIGEgbGl0dGxlIHBhdGllbmNlIHVu
dGlsIGEgQk9GIGhhcHBlbnMgKGlmKSBhbmQgZW5vdWdoIGludGVyZXN0IGFuZCBjb25zZW5zdXMg
c2hvd3MgKGlmKSBhbmQgYSBXRyBpcyBzdWdnZXN0ZWQgdG8gZm9ybSAoaWYpLiAgDQoNCi0tLSB0
b255IA0KDQoNCg==


From nobody Sun Sep 28 18:32:08 2014
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 9B5841A6F3D for ; Sun, 28 Sep 2014 18:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 5TgC1S0EuwNU for ; Sun, 28 Sep 2014 18:32:04 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C621A6F3A for ; Sun, 28 Sep 2014 18:32:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNC42299; Mon, 29 Sep 2014 01:32:02 +0000 (GMT)
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Sep 2014 02:32:01 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 29 Sep 2014 09:31:57 +0800
From: Xuxiaohu 
To: IJsbrand Wijnands , "S, Somasundaram (Somasundaram)" 
Thread-Topic: [Bier] BIER Encapsulation..
Thread-Index: Ac/ahYdvK4toTl6uQ0KSE7Bnd0RxXQAQE3sAAC+WqVA=
Date: Mon, 29 Sep 2014 01:31:56 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC85D@NKGEML512-MBS.china.huawei.com>
References:  
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/eVTgD6xzrK6Q2cB7jD4fd9U-CRE
Cc: "bier@ietf.org" 
Subject: Re: [Bier] BIER Encapsulation..
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: Mon, 29 Sep 2014 01:32:06 -0000

Hi Ice,

> -----Original Message-----
> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand Wijnands
> Sent: Sunday, September 28, 2014 6:42 PM
> To: S, Somasundaram (Somasundaram)
> Cc: bier@ietf.org
> Subject: Re: [Bier] BIER Encapsulation..
>=20
> Hi Somasundaram,
>=20
> > Regarding *draft-wijnands-mpls-bier-encapsulation-00*
> >
> > Given that  BIER packets packets are MPLS encapsulated (SI is identifie=
d based
> on the Label), how would forwarding take place in a pure IGP domain (wher=
e
> MPLS is not configured/supported)?
>=20
> There always needs to be some sort of encapsulation to encode the BitStri=
ng. So
> I don't expect BIER to be supported on a native IP packets. But you raise=
 a good
> point, the BIER procedures are agnostic to any sort of encapsulation. Wit=
h MPLS
> we use the top label to identify the SI, which is a nice way to encode it=
 and
> prevents an additional lookup in the forwarding plane.

If I understand it correctly, the additional lookup for the MT-ID and SI co=
uld not be prevented by using the BIER MPLS label.

Best regards,
Xiaohu

> Thx,
>=20
> Ice.
>=20
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier


From nobody Sun Sep 28 19:27:58 2014
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 B1E941A6F85 for ; Sun, 28 Sep 2014 19:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 rY_5kwsk9Boz for ; Sun, 28 Sep 2014 19:27:54 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37BBE1A6F84 for ; Sun, 28 Sep 2014 19:27:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNC45210; Mon, 29 Sep 2014 02:27:52 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Sep 2014 03:27:51 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 29 Sep 2014 10:27:47 +0800
From: Xuxiaohu 
To: IJsbrand Wijnands 
Thread-Topic: [Bier] MPLS encapsulation
Thread-Index: AQHP2amQQPBQ9OujR6OJTMN+0P37n5wTgHcAgADEqQCAAajKYP//kUoAgACbTED//8NwAIABeR5g
Date: Mon, 29 Sep 2014 02:27:47 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC897@NKGEML512-MBS.china.huawei.com>
References: Your message of Fri, 26 Sep 2014 16:11:17 +0100. <051501cfd99c$205b1780$61114680$@olddog.co.uk> <9767.1411750052@erosen-lnx> <065a01cfd9dc$f45f1be0$dd1d53a0$@olddog.co.uk> <873A5047-32D7-4AAB-ABE7-FF8C23166C1F@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC602@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F181B6095@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC694@NKGEML512-MBS.china.huawei.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/NdhFwp6in4cQg6sh2Nn0VVrlPpQ
Cc: "bier@ietf.org" , "adrian@olddog.co.uk" , "erosen@cisco.com" , Antoni Przygienda 
Subject: Re: [Bier] MPLS encapsulation
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: Mon, 29 Sep 2014 02:27:56 -0000

Hi Ice,

> -----Original Message-----
> From: IJsbrand Wijnands [mailto:ice@cisco.com]
> Sent: Sunday, September 28, 2014 7:02 PM
> To: Xuxiaohu
> Cc: Antoni Przygienda; adrian@olddog.co.uk; erosen@cisco.com; bier@ietf.o=
rg
> Subject: Re: [Bier] MPLS encapsulation
>=20
> Hi Xuxiaohu,
>=20
> >> For MPLS, one (very good reason) is that we do have _very_ fast MPLS
> >> label lookup fast-paths, we do not have MT-ID & Set-ID lookup
> >> engines.  SetID is
> >
> > If I understand it correctly, the intention of the BIER-MPLS label look=
up is to
> find the corresponding SI and MT-ID. By directly carrying the SI and MT-I=
D
> information in the BIER header, there is no need for that MPLS lookup at =
all even
> though that lookup is _very_ fast. Furthermore, there is no need any spec=
ific
> label distribution process for the BIER-MPLS-labels, especially IGP flood=
ing-based
> distribution process. BTW, is it efficient to flood the BIER-MPLS-label b=
indings
> which are actually only meaningful to adjacent BFRs to all IGP peers with=
in the
> whole IGP domain?
>=20
> All great points.
>=20
> We always need some sort of encapsulation to store the BIER header. We ca=
n
> come up with a new ethertype potentially and skip MPLS. But why would we
> want to introduce yet an other encapsulation when MPLS can already solve =
the
> problem for us, and, provides great value IMO. Think about how we can sti=
ck a

No matter whether the MPLS shim is inserted or not, the BIER encapsulation =
is already there unless you want to use the MPLS shim header to encode the =
BitString as well. Therefore, by encoding the MT-ID and SI information in t=
he BIER header and then encapsulating the BIER with the MAC header, you are=
 actually reduce one encapsulation layer (i.e., the MPLS encapsulation laye=
r), rather than introducing yet another encapsulation layer.=20

> BIER MPLS packet over a LFA/TE FRR tunnel, etc... However, you still have=
 a good

I fully agree there are use cases for BIER-over-MPLS. However, it doesn't m=
ean you couldn't make the BIER encapsulation to be transport-independent.

> point and we may work on other ways to encapsulate the BIER header. For t=
hat
> reason we have two drafts, and architecture draft and an encapsulation dr=
aft :-)

That's great.

> The label bindings are flooded indeed. There are features that can make u=
se of
> knowing the labels of your neighbors.

In other words, the label bindings are only meaning to neighboring LSRs, ri=
ght? If so, it doesn't make much sense to flood the label bindings within t=
he IGP area or domain.

> >> arguable as being in encaps but a label representing a set in MPLS is
> >> simply extremely natural to MPLS. MT-ID has actually no business in
> >> the fast-path I would say, the scope of validity of MT-ID is in the
> >> IGP control plane only. Building
> >
> > Disagree with the above argument. The MT-ID is not only useful in the I=
GP
> control plane but also useful in the data plane. Otherwise, how could a B=
FR
> determine which set of the IP forwarding table entries should be looked u=
p for
> IP packet forwarding? Of course, MPLS-MT is a slightly different since th=
e MPLS
> label itself could be used to indicate which MT's routing table should be=
 used.
> However, to define a transport-independent BIER encapsulation, it's bette=
r for
> the MT-ID information to be contained in the BIER header. In addition, wo=
uldn't
> the BIER-in-MAC be more prevalent than the BIER-in-MPLS provided the SI a=
nd
> MT-ID information is contained in the BIER header? IMHO, the only
> irreplaceable use case for BIER-in-MPLS is to use the IGP shortcut or FA =
for
> BIER-encapsulated packet forwarding.
>=20
> Lets not throw out the baby with the bath water. If MPLS is used to encap=
sulate

I'm not throwing out the baby with the bath water. On the contrary, I hope =
to decouple the baby (i.e., the BIER header) from the bath water (i.e., the=
 transport header) :)

> the BIER header, lets also use the benefits that MPLS provides. If we mak=
e the
> BIER header more generic, we loose those advantages.

IMHO, the BIER-MPLS label doesn't bring you any real benefit: first, by usi=
ng the BIER-MPLS label as an indicator for the MT-ID and SI instead of enco=
ding the MT-ID and SI directly in the BIER-header, you would need additiona=
l lookup for the MT-ID and SI; second, you would have to define different B=
IER header formats for different transport technologies (e.g., BIER-over-MA=
C), unless you want to always use the BIER-in-MPLS for any other transports=
, in other words, you want to make the BIER header and the BIER-MPLS label =
as a mandatory combination for BIER forwarding in any case.; third, it seem=
s that the encapsulation overhead is not reduced by using the MPLS-BIER lab=
el instead of encoding the MT-ID and SI in the BIER header.

> >> As to MPLS ranges, this is something that is fashionable these days,
> >> IMO each set should have a completely independent label on it but
> >> there are trade-offs in terms of control plane complexity/protocol
> >> packet sizes vs. fast-path complexity vs. what people already have in =
silicon
> and so on.
> >
> > Since the BIER itself requires changes to both control plane and data p=
lane
> anyway, I have not yet seen any significant advantage of the BIER-MPLS-la=
bel
> over a BIER header which contains MT-ID and SI information in those terms=
 that
> you have mentioned above.
>=20
> I think avoiding a SI & MT-ID lookup in the data plane by associating a d=
ifferent
> MPLS label with it is significant advantage, it simplifies the data-plane=
 and make
> its faster.

If I understand it correctly, at least the MT-ID lookup in the data plane c=
ould not be avoided by associated different MPLS label unless you could dir=
ectly calculate the corresponding MT-ID according to certain rules.

Best regards,
Xiaohu

> Thx,
>=20
> Ice.
>=20


From nobody Sun Sep 28 20:38:41 2014
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 0DCEA1A6F9A for ; Sun, 28 Sep 2014 20:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 eRQ3kQZEREaN for ; Sun, 28 Sep 2014 20:38:37 -0700 (PDT)
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 454A21A012D for ; Sun, 28 Sep 2014 20:38:37 -0700 (PDT)
X-AuditID: c6180641-f79916d00000623a-06-54287b5bc4fe
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 92.F8.25146.B5B78245; Sun, 28 Sep 2014 23:19:24 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Sun, 28 Sep 2014 23:38:29 -0400
From: Antoni Przygienda 
To: Xuxiaohu , IJsbrand Wijnands 
Thread-Topic: [Bier] MPLS encapsulation
Thread-Index: AQHP2amQQPBQ9OujR6OJTMN+0P37n5wUSaIAgADEqACAATanAP//vXCAgAByN4CAADKCAIABAouA///NXdA=
Date: Mon, 29 Sep 2014 03:38:29 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181B633B@eusaamb103.ericsson.se>
References: Your message of Fri, 26 Sep 2014 16:11:17 +0100. <051501cfd99c$205b1780$61114680$@olddog.co.uk> <9767.1411750052@erosen-lnx> <065a01cfd9dc$f45f1be0$dd1d53a0$@olddog.co.uk> <873A5047-32D7-4AAB-ABE7-FF8C23166C1F@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC602@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F181B6095@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC694@NKGEML512-MBS.china.huawei.com>  <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC897@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC897@NKGEML512-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPoG5MtUaIwbsmNosfPTeYLZbO2MNk se7uJBaLV3PuMFtsPb+K0YHVY8rvjaweLUfesnosWfKTyWPF5pWMASxRXDYpqTmZZalF+nYJ XBkP5r1nKVgtVPHpXEgD4ym+LkZODgkBE4k7k46zQ9hiEhfurWfrYuTiEBI4yihx+d17Jghn OaPE7zUtTCBVbAIWEpe/PWXuYuTgEBFwlZjxURckzCxQKXHgynNmEFtYQE1i4+pLrCC2iIC6 xN4Zt9gh7CSJE2fngdksAqoSxy8cBavhFfCWOPVhKdTi4ywSPetvgQ3iFAiTONz8EsxmBLru +6k1TBDLxCVuPZnPBHG1gMSSPeeZIWxRiZeP/7FC2EoSH3/PZ4eo15FYsPsTG4StLbFs4Wtm iMWCEidnPmGZwCg2C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCPDTYzAuDomwea4g3HBJ8tD jAIcjEo8vAuy1UOEWBPLiitzDzFKc7AoifNqVs8LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cBotVh21ftD9TJSazZwXWhWnPL4/L/uw2k+JwVZNDbH2zPwuXJuipvfqPGdITo099WtaAMp o7o7u3/Pd/IPfs+wIogvpmeT3evFQlsv+8xfpmCu9pPv+EcnlwV/joqzuK1cetdswZO0F3t9 GVNPKa9IXcz46OSCl4mHEv/3Z+x6spLp0/FbMnUMSizFGYmGWsxFxYkA1XhXl4wCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/p-bPf0q8a5baZdlSump_HgMi_OQ
Cc: "adrian@olddog.co.uk" , "erosen@cisco.com" , "bier@ietf.org" 
Subject: Re: [Bier] MPLS encapsulation
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: Mon, 29 Sep 2014 03:38:40 -0000

> > We always need some sort of encapsulation to store the BIER header. We
> > can come up with a new ethertype potentially and skip MPLS. But why
> > would we want to introduce yet an other encapsulation when MPLS can
> > already solve the problem for us, and, provides great value IMO. Think
> > about how we can stick a
>=20
> No matter whether the MPLS shim is inserted or not, the BIER encapsulatio=
n
> is already there unless you want to use the MPLS shim header to encode th=
e
> BitString as well. Therefore, by encoding the MT-ID and SI information in=
 the
> BIER header and then encapsulating the BIER with the MAC header, you are
> actually reduce one encapsulation layer (i.e., the MPLS encapsulation lay=
er),
> rather than introducing yet another encapsulation layer.

 [Tony said]   Consider the 'label'  a simple mapping  of   -> Label. The mapping to label may become more complex later & the=
 label will allow us to 'decouple' the speed of the forwarding from how com=
plicated the necessary control plane gets.  And  you can do  MAC header wit=
h BIER encaps with label  instead of  carrying (MT-ID,Domain-ID,Set-ID) aro=
und which will need changing every time control plane e.g. extends set-id t=
o be 2 bytes or something like this.  Yes, you need to swap the labels on e=
very hop but that's the nature of today's fast lookup technologies like MPL=
S and well entrenched in present silicon.=20

> > The label bindings are flooded indeed. There are features that can
> > make use of knowing the labels of your neighbors.
>=20
> In other words, the label bindings are only meaning to neighboring LSRs,
> right? If so, it doesn't make much sense to flood the label bindings with=
in the
> IGP area or domain.

 [Tony said]  You have to flood the encapsulation type, masklengths & BFR-i=
ds=20
anyway so you may as well put the label in there. It's 4 bytes only with ra=
nge size. Observe=20
other restrictions (e.g. label not being present) for the routers to comput=
e
correct SPFs through all the domain (read the ISIS draft for it). Anyway, =
=20
you would have to implement tons of new logic into OSPF to do link-local=20
signaling correctly for this (and ISIS would need massive extensions unless=
 I missed=20
something new).=20

--- tony =20


From nobody Sun Sep 28 23:36:10 2014
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 358981A6FCD for ; Sun, 28 Sep 2014 23:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level: 
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 wwCaguMRik6q for ; Sun, 28 Sep 2014 23:36:06 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 7CADB1A6FC1 for ; Sun, 28 Sep 2014 23:36:06 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 5F3926AD1A75D; Mon, 29 Sep 2014 06:36:02 +0000 (GMT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s8T6a2Rj017143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 02:36:03 -0400
Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 29 Sep 2014 02:36:03 -0400
Received: from SG70XWXCHMBA03.zap.alcatel-lucent.com ([169.254.3.2]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 14:35:43 +0800
From: "S, Somasundaram (Somasundaram)" 
To: Xuxiaohu , IJsbrand Wijnands 
Thread-Topic: [Bier] BIER Encapsulation..
Thread-Index: Ac/ahYdvK4toTl6uQ0KSE7Bnd0RxXQAQE3sAAC+WqVAAB4SFoA==
Date: Mon, 29 Sep 2014 06:35:43 +0000
Message-ID: 
References:   <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC85D@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC85D@NKGEML512-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.253.19.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/ykGvlmni2BBb6-IkmCAhKr_12gU
Cc: "bier@ietf.org" 
Subject: Re: [Bier] BIER Encapsulation..
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: Mon, 29 Sep 2014 06:36:09 -0000

Hi Xiahou,

	BIER-MPLS label indirectly denotes the SI and MTID (Refer to section 4 poi=
nt 5d in "BIER MPLS Encapsulation"). So by doing a BIER-MPLS label look up,=
 a BFR can make out what the SI and the corresponding MTID it advertised to=
 its peer..=20

	BTW, Given that ASICs do line rate processing, should we really talk about=
 preventing additional lookups as a major advantage? Am assuming that by ta=
lking about preventing lookups, you guys are referring to the possible impa=
ct in the forwarding performance.

Regards
Somasundaram

-----Original Message-----
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]=20
Sent: Monday, September 29, 2014 7:02 AM
To: IJsbrand Wijnands; S, Somasundaram (Somasundaram)
Cc: bier@ietf.org
Subject: RE: [Bier] BIER Encapsulation..

Hi Ice,

> -----Original Message-----
> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand=20
> Wijnands
> Sent: Sunday, September 28, 2014 6:42 PM
> To: S, Somasundaram (Somasundaram)
> Cc: bier@ietf.org
> Subject: Re: [Bier] BIER Encapsulation..
>=20
> Hi Somasundaram,
>=20
> > Regarding *draft-wijnands-mpls-bier-encapsulation-00*
> >
> > Given that  BIER packets packets are MPLS encapsulated (SI is=20
> > identified based
> on the Label), how would forwarding take place in a pure IGP domain=20
> (where MPLS is not configured/supported)?
>=20
> There always needs to be some sort of encapsulation to encode the=20
> BitString. So I don't expect BIER to be supported on a native IP=20
> packets. But you raise a good point, the BIER procedures are agnostic=20
> to any sort of encapsulation. With MPLS we use the top label to=20
> identify the SI, which is a nice way to encode it and prevents an additio=
nal lookup in the forwarding plane.

If I understand it correctly, the additional lookup for the MT-ID and SI co=
uld not be prevented by using the BIER MPLS label.

Best regards,
Xiaohu

> Thx,
>=20
> Ice.
>=20
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier


From nobody Mon Sep 29 00:08:56 2014
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 3D6861A6FDB for ; Mon, 29 Sep 2014 00:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 L3V7AU56CbWF for ; Mon, 29 Sep 2014 00:08:50 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FE51A6F96 for ; Mon, 29 Sep 2014 00:08:49 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNC65005; Mon, 29 Sep 2014 07:08:48 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Sep 2014 08:08:47 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 29 Sep 2014 15:08:41 +0800
From: Xuxiaohu 
To: "S, Somasundaram (Somasundaram)" , IJsbrand Wijnands 
Thread-Topic: [Bier] BIER Encapsulation..
Thread-Index: Ac/ahYdvK4toTl6uQ0KSE7Bnd0RxXQAQE3sAAC+WqVAAB4SFoAADr5/g
Date: Mon, 29 Sep 2014 07:08:41 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC933@NKGEML512-MBS.china.huawei.com>
References:   <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC85D@NKGEML512-MBS.china.huawei.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/burEHmWjAxCTWG0V_K5v05OQUu4
Cc: "bier@ietf.org" 
Subject: Re: [Bier] BIER Encapsulation..
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: Mon, 29 Sep 2014 07:08:55 -0000

> -----Original Message-----
> From: S, Somasundaram (Somasundaram)
> [mailto:somasundaram.s@alcatel-lucent.com]
> Sent: Monday, September 29, 2014 2:36 PM
> To: Xuxiaohu; IJsbrand Wijnands
> Cc: bier@ietf.org
> Subject: RE: [Bier] BIER Encapsulation..
>=20
> Hi Xiahou,
>=20
> 	BIER-MPLS label indirectly denotes the SI and MTID (Refer to section 4 p=
oint
> 5d in "BIER MPLS Encapsulation"). So by doing a BIER-MPLS label look up, =
a BFR
> can make out what the SI and the corresponding MTID it advertised to its =
peer..

Exactly:)

> 	BTW, Given that ASICs do line rate processing, should we really talk abo=
ut
> preventing additional lookups as a major advantage? Am assuming that by
> talking about preventing lookups, you guys are referring to the possible =
impact
> in the forwarding performance.

Ice had said "... With MPLS we use the top label to
> > identify the SI, which is a nice way to encode it and prevents an addit=
ional
> lookup in the forwarding plane...."

According to the above statement, it seems that preventing an additional lo=
okup is deemed as one benefit of using BIER-MPLS labels. I just want to poi=
nt out that the use of the BIER-MPLS labels introduces rather than prevent =
an additional lookup (whether or not that lookup has any significant impact=
 on the forwarding performance), compared to the approach of encoding the M=
T-ID and SI in the BIER header.

Best regards,
Xiaohu

> Regards
> Somasundaram
>=20
> -----Original Message-----
> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
> Sent: Monday, September 29, 2014 7:02 AM
> To: IJsbrand Wijnands; S, Somasundaram (Somasundaram)
> Cc: bier@ietf.org
> Subject: RE: [Bier] BIER Encapsulation..
>=20
> Hi Ice,
>=20
> > -----Original Message-----
> > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand
> > Wijnands
> > Sent: Sunday, September 28, 2014 6:42 PM
> > To: S, Somasundaram (Somasundaram)
> > Cc: bier@ietf.org
> > Subject: Re: [Bier] BIER Encapsulation..
> >
> > Hi Somasundaram,
> >
> > > Regarding *draft-wijnands-mpls-bier-encapsulation-00*
> > >
> > > Given that  BIER packets packets are MPLS encapsulated (SI is
> > > identified based
> > on the Label), how would forwarding take place in a pure IGP domain
> > (where MPLS is not configured/supported)?
> >
> > There always needs to be some sort of encapsulation to encode the
> > BitString. So I don't expect BIER to be supported on a native IP
> > packets. But you raise a good point, the BIER procedures are agnostic
> > to any sort of encapsulation. With MPLS we use the top label to
> > identify the SI, which is a nice way to encode it and prevents an addit=
ional
> lookup in the forwarding plane.
>=20
> If I understand it correctly, the additional lookup for the MT-ID and SI =
could not
> be prevented by using the BIER MPLS label.
>=20
> Best regards,
> Xiaohu
>=20
> > Thx,
> >
> > Ice.
> >
> > _______________________________________________
> > BIER mailing list
> > BIER@ietf.org
> > https://www.ietf.org/mailman/listinfo/bier


From nobody Mon Sep 29 00:47:39 2014
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 69A951A702B for ; Mon, 29 Sep 2014 00:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.636
X-Spam-Level: 
X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 CKWWz73oHMvn for ; Mon, 29 Sep 2014 00:47:34 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33E41A702A for ; Mon, 29 Sep 2014 00:47:33 -0700 (PDT)
Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 29 Sep 2014 09:47:31 +0200
X-IronPort-AV: E=Sophos;i="5.04,618,1406584800"; d="scan'208";a="538197628"
Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 29 Sep 2014 09:47:31 +0200
Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 29 Sep 2014 09:47:31 +0200
From: 
To: 
Date: Mon, 29 Sep 2014 09:47:30 +0200
Thread-Topic: BOF request
Thread-Index: Ac/buZ9PnKhpE23ISv+ZiJ9vJjkyww==
Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E4FB63285E@HE113667.emea1.cds.t-internal.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/2QL9y_YRSUZt1ikGWsJjZik6EIQ
Subject: [Bier] BOF request
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: Mon, 29 Sep 2014 07:47:36 -0000

Hi,

I would really appreciate to have a BOF for BIER.

Cheers, Uwe


Uwe Joorde, FMED411-13=20
Deutsche Telekom Technik GmbH Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe=
is, Carsten M=FCller=20
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE814645262





From nobody Mon Sep 29 02:01:53 2014
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 50FB21A8720 for ; Mon, 29 Sep 2014 02:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 Lln-G87-K8Kd for ; Mon, 29 Sep 2014 02:01:49 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056D51A871E for ; Mon, 29 Sep 2014 02:01:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2360; q=dns/txt; s=iport; t=1411981309; x=1413190909; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Di2WrqHMRUMws1QsPJpHj2jgsgP1/J22l8Pofv2oK8I=; b=U7LZenf8UgE34PUAMRJaFCShx4SmqoUVoXtfAvlpIFmBHVSnU4VyqDoi NbewiUcP6IcluKh1/K70H+EiqfS7HXU9EreeGVQfo3v84Y5jFolPc3qjd f8PWC+VyRfzXoUHhtFGWmfRnn3t30DuzcB0uT36+4CGydW+DLXaoFIlfc Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjAKAJofKVStJssW/2dsb2JhbABWCoNhtmwFAXKSfwqHTgKBIQF7hAMBAQEDAQEBATc0CwUHBAsRBAEBKAcnHwkIBhOINggNv0ABEwSGEokwKTMHBoMogR0BBJ0olV2DZTsvgkoBAQE
X-IronPort-AV: E=Sophos;i="5.04,619,1406592000"; d="scan'208";a="193657869"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 29 Sep 2014 09:01:47 +0000
Received: from ams-iwijnand-8818.cisco.com (ams-iwijnand-8818.cisco.com [10.60.202.89]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8T91krk020606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Sep 2014 09:01:46 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: IJsbrand Wijnands 
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC933@NKGEML512-MBS.china.huawei.com>
Date: Mon, 29 Sep 2014 11:01:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A7C5228-86E6-44DC-80B3-863CE0379E7B@cisco.com>
References:   <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC85D@NKGEML512-MBS.china.huawei.com>  <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC933@NKGEML512-MBS.china.huawei.com>
To: Xuxiaohu 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/Kwlm7xrFmfF4qXGpgaoDNa8PdgI
Cc: "bier@ietf.org" , "S, Somasundaram \(Somasundaram\)" 
Subject: Re: [Bier] BIER Encapsulation..
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: Mon, 29 Sep 2014 09:01:51 -0000

Hi Xiaohu,

> According to the above statement, it seems that preventing an =
additional lookup is deemed as one benefit of using BIER-MPLS labels. I =
just want to point out that the use of the BIER-MPLS labels introduces =
rather than prevent an additional lookup (whether or not that lookup has =
any significant impact on the forwarding performance), compared to the =
approach of encoding the MT-ID and SI in the BIER header.

As long as we use MPLS, there will always be a MPLS label lookup, even =
if we encode the SI and MT-ID in the BIER Header. So why not make that =
lookup count for something?=20

Thx,

Ice.

>=20
> Best regards,
> Xiaohu
>=20
>> Regards
>> Somasundaram
>>=20
>> -----Original Message-----
>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
>> Sent: Monday, September 29, 2014 7:02 AM
>> To: IJsbrand Wijnands; S, Somasundaram (Somasundaram)
>> Cc: bier@ietf.org
>> Subject: RE: [Bier] BIER Encapsulation..
>>=20
>> Hi Ice,
>>=20
>>> -----Original Message-----
>>> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand
>>> Wijnands
>>> Sent: Sunday, September 28, 2014 6:42 PM
>>> To: S, Somasundaram (Somasundaram)
>>> Cc: bier@ietf.org
>>> Subject: Re: [Bier] BIER Encapsulation..
>>>=20
>>> Hi Somasundaram,
>>>=20
>>>> Regarding *draft-wijnands-mpls-bier-encapsulation-00*
>>>>=20
>>>> Given that  BIER packets packets are MPLS encapsulated (SI is
>>>> identified based
>>> on the Label), how would forwarding take place in a pure IGP domain
>>> (where MPLS is not configured/supported)?
>>>=20
>>> There always needs to be some sort of encapsulation to encode the
>>> BitString. So I don't expect BIER to be supported on a native IP
>>> packets. But you raise a good point, the BIER procedures are =
agnostic
>>> to any sort of encapsulation. With MPLS we use the top label to
>>> identify the SI, which is a nice way to encode it and prevents an =
additional
>> lookup in the forwarding plane.
>>=20
>> If I understand it correctly, the additional lookup for the MT-ID and =
SI could not
>> be prevented by using the BIER MPLS label.
>>=20
>> Best regards,
>> Xiaohu
>>=20
>>> Thx,
>>>=20
>>> Ice.
>>>=20
>>> _______________________________________________
>>> BIER mailing list
>>> BIER@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bier


From nobody Mon Sep 29 02:10:35 2014
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 7C8AB1A8726 for ; Mon, 29 Sep 2014 02:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 8yy_ZHrj_7C1 for ; Mon, 29 Sep 2014 02:10:31 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D795E1A0406 for ; Mon, 29 Sep 2014 02:10:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNC80590; Mon, 29 Sep 2014 09:10:29 +0000 (GMT)
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Sep 2014 10:10:28 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 29 Sep 2014 17:10:23 +0800
From: Xuxiaohu 
To: IJsbrand Wijnands 
Thread-Topic: [Bier] BIER Encapsulation..
Thread-Index: Ac/ahYdvK4toTl6uQ0KSE7Bnd0RxXQAQE3sAAC+WqVAAB4SFoAADr5/g//+f4YD//3h94A==
Date: Mon, 29 Sep 2014 09:10:22 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC9A5@NKGEML512-MBS.china.huawei.com>
References:   <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC85D@NKGEML512-MBS.china.huawei.com>  <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC933@NKGEML512-MBS.china.huawei.com> <7A7C5228-86E6-44DC-80B3-863CE0379E7B@cisco.com>
In-Reply-To: <7A7C5228-86E6-44DC-80B3-863CE0379E7B@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/PHKx8ECqzyIOo3mF2bqrDaElzeI
Cc: "bier@ietf.org" , "S, Somasundaram \(Somasundaram\)" 
Subject: Re: [Bier] BIER Encapsulation..
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: Mon, 29 Sep 2014 09:10:33 -0000

Hi Ice,

See my comment inline.

-----Original Message-----
From: IJsbrand Wijnands [mailto:ice@cisco.com]=20
Sent: Monday, September 29, 2014 5:02 PM
To: Xuxiaohu
Cc: S, Somasundaram (Somasundaram); bier@ietf.org
Subject: Re: [Bier] BIER Encapsulation..

Hi Xiaohu,

> According to the above statement, it seems that preventing an additional =
lookup is deemed as one benefit of using BIER-MPLS labels. I just want to p=
oint out that the use of the BIER-MPLS labels introduces rather than preven=
t an additional lookup (whether or not that lookup has any significant impa=
ct on the forwarding performance), compared to the approach of encoding the=
 MT-ID and SI in the BIER header.

As long as we use MPLS, there will always be a MPLS label lookup, even if w=
e encode the SI and MT-ID in the BIER Header. So why not make that lookup c=
ount for something?=20

[Xiaohu] in that case, you only need a way to indicate the MPLS payload is =
a BIER header. BTW, this draft (https://tools.ietf.org/html/draft-xu-mpls-p=
ayload-protocol-identifier-00) describes a very straightforward way to do t=
hat:)

Best regards,
Xiaohu

Thx,

Ice.

>=20
> Best regards,
> Xiaohu
>=20
>> Regards
>> Somasundaram
>>=20
>> -----Original Message-----
>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
>> Sent: Monday, September 29, 2014 7:02 AM
>> To: IJsbrand Wijnands; S, Somasundaram (Somasundaram)
>> Cc: bier@ietf.org
>> Subject: RE: [Bier] BIER Encapsulation..
>>=20
>> Hi Ice,
>>=20
>>> -----Original Message-----
>>> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand=20
>>> Wijnands
>>> Sent: Sunday, September 28, 2014 6:42 PM
>>> To: S, Somasundaram (Somasundaram)
>>> Cc: bier@ietf.org
>>> Subject: Re: [Bier] BIER Encapsulation..
>>>=20
>>> Hi Somasundaram,
>>>=20
>>>> Regarding *draft-wijnands-mpls-bier-encapsulation-00*
>>>>=20
>>>> Given that  BIER packets packets are MPLS encapsulated (SI is=20
>>>> identified based
>>> on the Label), how would forwarding take place in a pure IGP domain=20
>>> (where MPLS is not configured/supported)?
>>>=20
>>> There always needs to be some sort of encapsulation to encode the=20
>>> BitString. So I don't expect BIER to be supported on a native IP=20
>>> packets. But you raise a good point, the BIER procedures are=20
>>> agnostic to any sort of encapsulation. With MPLS we use the top=20
>>> label to identify the SI, which is a nice way to encode it and=20
>>> prevents an additional
>> lookup in the forwarding plane.
>>=20
>> If I understand it correctly, the additional lookup for the MT-ID and=20
>> SI could not be prevented by using the BIER MPLS label.
>>=20
>> Best regards,
>> Xiaohu
>>=20
>>> Thx,
>>>=20
>>> Ice.
>>>=20
>>> _______________________________________________
>>> BIER mailing list
>>> BIER@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bier


From nobody Mon Sep 29 02:28:09 2014
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 172B81A8545 for ; Mon, 29 Sep 2014 02:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 JhofSvYFKljn for ; Mon, 29 Sep 2014 02:28:05 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19FA1A7D82 for ; Mon, 29 Sep 2014 02:28:04 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id b13so3935807wgh.34 for ; Mon, 29 Sep 2014 02:28:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=nSPmxnvImfEHNyKzWY+mDTAlXhAk6p1mKycA4dCI/oU=; b=rIMjU9zDOrx7J5AwxMG2Fjnsw9ARAfTZFC0TvJu6O4Uw+i2f2PWlFq7YXDWOQ62uqx RmhpodqLLayIlTRownB6DB4qpulmYZvVjNO5arvtlRBELqF2ekuLOnqHMYkNFKcMu333 59QrYL1lZ/caXq1yqg5Ag15UrEMFtRBtyHQaW2jL2+m6MFTM6233NyD2jaXQxP7qfqXn 37g2J9KPGllXuqXkRdwzvIUu01yT7vsgaLSUIY68L76uAqPCdAb4cMNtl217QzfkGOnI mf7K3LRU/LOEov6wwTqR5993fX2V7cp3G0OwTXFMgYfAvt5P4qD7d69si++hzr2f9czm XfXA==
X-Received: by 10.194.143.69 with SMTP id sc5mr41628783wjb.26.1411982883396; Mon, 29 Sep 2014 02:28:03 -0700 (PDT)
Received: from [100.73.10.84] ([80.215.202.62]) by mx.google.com with ESMTPSA id ul1sm15080819wjc.9.2014.09.29.02.28.01 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Sep 2014 02:28:02 -0700 (PDT)
Message-ID: <54292620.8090506@gmail.com>
Date: Mon, 29 Sep 2014 11:28:00 +0200
From: Gregory CAUCHIE 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: gjshep@gmail.com, Robert Raszuk 
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>      <77EEB0EC-1881-4CDE-8D0D-357710CD0CC6@cisco.com>    
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090500020901020405090207"
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/SbbG7IroV8R4bDyISKUzOe-XpZk
Cc: "Nagendra Kumar Nainar \(naikumar\)" , "bier@ietf.org" , IJsbrand Wijnands , "Eric Rosen \(erosen\)" , Antoni Przygienda 
Subject: Re: [Bier] One specific transition churn ...
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: Mon, 29 Sep 2014 09:28:08 -0000

This is a multi-part message in MIME format.
--------------090500020901020405090207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

I strongly support the motivation exposed below by Greg Sheperd.

The first lines of SPRING charter states :
    "The ability for a node to specify a forwarding path, other
    than the normal shortest path, that a particular packet
    will traverse, benefits a number of network functions, "

This make me disagree with Robert's view (at least from what I 
understood) as SPRING talks about a construction of a forwarding path 
while BIER talks about creating a list of egress routers and a way of 
coping with the risk of receiving multiple copy of the same packet... 
but in the same time I think I am as curious as Robert about the 
ressemblance/difference/combination of SPRING and BIER. THerefore I 
think that at some point it would be interesting to discuss potential 
interaction/application of BIER and SPRING.

--
Greg Cauchie

Le 28/09/2014 14:14, Greg Shepherd a écrit :
> Thanks Robert. We've currently asked for a non-WG BoF in HI. Based on 
> the discussion here on the list, and that in the BoF, the community 
> will make a decision as to IF this work should be adopted by the IETF, 
> and if so, where the work should take place. It has been my experience 
> that every WG in the IETF not specifically working on mcast issues 
> treats any mcast requirements as the bastard stepchild and those mcast 
> reqs never fully get addressed.
>
> In some cases they've even punted the mcast reqs over to MBONED which 
> is in OPS and should not be working on protocols. BIER is intended to 
> specifically address a set of mcast issues. Having a focused community 
> to addresses them is most likely the fastest path to success.
>
> Greg
>
> On Sun, Sep 28, 2014 at 5:03 AM, Robert Raszuk  > wrote:
>
>     Ice,
>
>         You keep re-homing the discussion to a different topic again
>         and again.
>
>
>     I asked few questions to better understand the proposal. Most of
>     them have not been answered so far :)
>
>         The point we are making is that BIER does not belong in SPRING.
>
>
>     SPRING charter says:
>
>     "The SPRING working group will define procedures that
>     will allow a node to steer a packet along an explicit
>     route using information attached to the packet and
>     without the need for per-path state information to be
>     held at transit nodes. Full explicit control (through loose or
>     strict path specification) can be achieved in a network comprising
>     only SPRING nodes, however SPRING must inter-operate through loose
>     routing in existing networks and may find it advantageous to use
>     loose routing for for other network applications."
>
>     Why I see similarities:
>
>     * BIER adds information (bitstring/SI) to the packets on ingress
>     which determine how the packet is to be forwarded via the network
>     nodes.
>
>     * While BIER does not add explicit path one can interpret
>     bitstring as special case of Loose Path Specification where you
>     indicate just the egress points or SI-subnets.
>
>     Anyway if you want to have a new group for it - make it happen.
>     What to me is more important however is how the BIER will be
>     useful in practice.
>
>     Cheers,
>     R.
>
>
>     _______________________________________________
>     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


--------------090500020901020405090207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi,

    

    I strongly support the motivation exposed below by Greg Sheperd. 

    

    The first lines of SPRING charter states :

       "The ability for a node to specify a forwarding path, other 

       than the normal shortest path, that a particular packet
    

       will traverse, benefits a number of network functions,
    "

    

    This make me disagree with Robert's view (at least from what I
    understood) as SPRING talks about a construction of a forwarding
    path while BIER talks about creating a list of egress routers and a
    way of coping with the risk of receiving multiple copy of the same
    packet... but in the same time I think I am as curious as Robert
    about the ressemblance/difference/combination of SPRING and BIER.
    THerefore I think that at some point it would be interesting to
    discuss potential interaction/application of BIER and SPRING.

    

    --

    Greg Cauchie

    

    
Le 28/09/2014 14:14, Greg Shepherd a
      écrit :

    

    

      
Thanks Robert. We've currently asked for a non-WG
        BoF in HI. Based on the discussion here on the list, and that in
        the BoF, the community will make a decision as to IF this work
        should be adopted by the IETF, and if so, where the work should
        take place. It has been my experience that every WG in the IETF
        not specifically working on mcast issues treats any mcast
        requirements as the bastard stepchild and those mcast reqs never
        fully get addressed.
        


        

        
In some cases they've even punted the mcast reqs over to
          MBONED which is in OPS and should not be working on protocols.
          BIER is intended to specifically address a set of mcast
          issues. Having a focused community to addresses them is most
          likely the fastest path to success.

          


          

          
Greg

            


              
On Sun, Sep 28, 2014 at 5:03 AM,
                Robert Raszuk <robert@raszuk.net>
                wrote:

                

                  

                    

                      

                        

                          
​Ice,​

                        

                        
 

                        
You
                          keep re-homing the discussion to a different
                          topic again and again.

                        

                        


                        

                        

                          
​I asked few
                            questions to better understand the proposal.
                            Most of them have not been answered so far
                            :)​

                        

                        
 

                        

                        
The
                          point we are making is that BIER does not
                          belong in SPRING.

                        

                        


                        

                        

                          
SPRING
                            charter says:

                          


                          

                          
"The SPRING working group
                            will define procedures that 

                          
will allow a node to steer a
                            packet along an explicit 

                          
route using information
                            attached to the packet and

                          
without the need for
                            per-path state information to be

                          
held at transit nodes. Full
                            explicit control (through loose or strict
                            path specification) can be achieved in a
                            network comprising only SPRING nodes,
                            however SPRING must inter-operate through
                            loose routing in existing networks and may
                            find it advantageous to use loose routing
                            for for other network applications.​"

                        

                        

                          


                          

                          
​Why I see
                            similarities:​

                        

                        


                        

                        
* ​BIER adds
                          information (bitstring/SI) to the packets on
                          ingress which determine how the packet is to
                          be forwarded via the network nodes. ​

                        


                        

                        
* While BIER
                          does not add explicit path one can interpret
                          bitstring as special case of Loose Path
                          Specification where you indicate just the
                          egress points or SI-subnets.

                        


                        

                        
Anyway if you
                          want to have a new group for it - make it
                          happen. What to me is more important however
                          is how the BIER will be useful in practice.

                        


                        

                        
Cheers,

                          R.

                        


                        

                      

                    

                  

                  

                  _______________________________________________

                  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


    

    

  


--------------090500020901020405090207--


From nobody Mon Sep 29 02:29:44 2014
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 76D6C1A7D82 for ; Mon, 29 Sep 2014 02:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 hv1K-nryNOuz for ; Mon, 29 Sep 2014 02:29:40 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6507A1A1A18 for ; Mon, 29 Sep 2014 02:29:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2583; q=dns/txt; s=iport; t=1411982981; x=1413192581; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YNuzd3rQedai7laM8Sb05ev29dbSV0+5EbE4O9xbclE=; b=FDsDIRS/LalXlNKlQTnG0DCapMDB1FSK0ikkgsSAD9ivp44mgOBTz1QH mbOo7vSFMAc8Bu07AzPyZAPO9wRmgZbr4TEWDEyE6EViOG+p4HLc648G3 Yp18gfzILRbrvH4s9PUDC8/oKnjp9cVzV9undiTSaAeQd3hIS7UYFyFPQ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjAKALglKVStJssW/2dsb2JhbABWCoNhtm0FAXKSfwyHTAKBIQF7hAMBAQEDAQEBATc0CwwECxEEAQEoBycfCQgGE4g2CA2/TAETBIYSiTApMwcGgyiBHQEElh+HCZVdg2U7L4JKAQEB
X-IronPort-AV: E=Sophos;i="5.04,619,1406592000"; d="scan'208";a="193087063"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 29 Sep 2014 09:29:39 +0000
Received: from ams-iwijnand-8818.cisco.com (ams-iwijnand-8818.cisco.com [10.60.202.89]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8T9TZms024495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Sep 2014 09:29:38 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: IJsbrand Wijnands 
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC9A5@NKGEML512-MBS.china.huawei.com>
Date: Mon, 29 Sep 2014 11:29:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <34992A26-9585-45E7-99E6-B875F5A0F9AE@cisco.com>
References:   <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC85D@NKGEML512-MBS.china.huawei.com>  <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC933@NKGEML512-MBS.china.huawei.com> <7A7C5228-86E6-44DC-80B3-863CE0379E7B@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BC9A5@NKGEML512-MBS.china.huawei.com>
To: Xuxiaohu 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/4UcA7ZgOTzks0w3LmWHDXLTtqBg
Cc: "bier@ietf.org" , "S, Somasundaram \(Somasundaram\)" 
Subject: Re: [Bier] BIER Encapsulation..
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: Mon, 29 Sep 2014 09:29:42 -0000

Xiaohu,

> [Xiaohu] in that case, you only need a way to indicate the MPLS =
payload is a BIER header. BTW, this draft =
(https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier-00)=
 describes a very straightforward way to do that:)

Using a special purpose label to indicate the BIER header is an other =
way of doing it, but, its not adding any value. It is still a label =
lookup that you need to do first, even if this is a special purpose =
label. Its likely this will be from the extended type, so you need two =
labels. I think the problem is much easier solved with a downstream =
assigned label that immediately provides the SI and MT-ID context.

Thx,

Ice.

>=20
> Best regards,
> Xiaohu
>=20
> Thx,
>=20
> Ice.
>=20
>>=20
>> Best regards,
>> Xiaohu
>>=20
>>> Regards
>>> Somasundaram
>>>=20
>>> -----Original Message-----
>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
>>> Sent: Monday, September 29, 2014 7:02 AM
>>> To: IJsbrand Wijnands; S, Somasundaram (Somasundaram)
>>> Cc: bier@ietf.org
>>> Subject: RE: [Bier] BIER Encapsulation..
>>>=20
>>> Hi Ice,
>>>=20
>>>> -----Original Message-----
>>>> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand=20
>>>> Wijnands
>>>> Sent: Sunday, September 28, 2014 6:42 PM
>>>> To: S, Somasundaram (Somasundaram)
>>>> Cc: bier@ietf.org
>>>> Subject: Re: [Bier] BIER Encapsulation..
>>>>=20
>>>> Hi Somasundaram,
>>>>=20
>>>>> Regarding *draft-wijnands-mpls-bier-encapsulation-00*
>>>>>=20
>>>>> Given that  BIER packets packets are MPLS encapsulated (SI is=20
>>>>> identified based
>>>> on the Label), how would forwarding take place in a pure IGP domain=20=

>>>> (where MPLS is not configured/supported)?
>>>>=20
>>>> There always needs to be some sort of encapsulation to encode the=20=

>>>> BitString. So I don't expect BIER to be supported on a native IP=20
>>>> packets. But you raise a good point, the BIER procedures are=20
>>>> agnostic to any sort of encapsulation. With MPLS we use the top=20
>>>> label to identify the SI, which is a nice way to encode it and=20
>>>> prevents an additional
>>> lookup in the forwarding plane.
>>>=20
>>> If I understand it correctly, the additional lookup for the MT-ID =
and=20
>>> SI could not be prevented by using the BIER MPLS label.
>>>=20
>>> Best regards,
>>> Xiaohu
>>>=20
>>>> Thx,
>>>>=20
>>>> Ice.
>>>>=20
>>>> _______________________________________________
>>>> BIER mailing list
>>>> BIER@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/bier
>=20


From nobody Mon Sep 29 05:42:39 2014
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 5ECCF1A6F8F for ; Mon, 29 Sep 2014 05:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 TMGeXB7yuwh1 for ; Mon, 29 Sep 2014 05:42:35 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5887B1A8772 for ; Mon, 29 Sep 2014 05:42:35 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id ho1so1862612wib.17 for ; Mon, 29 Sep 2014 05:42:34 -0700 (PDT)
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=7PywOGg1duDB44rk0jPdYBBb/boHnYrFMqRQa75e5O0=; b=vFakjhbw9cEZQDxhd8STeYkAvp6b+KjRVreu3nu6hyhkw8+rT5z/Zd/oVgafn32AnQ nU0S+zH2+u1DplMeq0qa7laDi7LHOZ+68LWkRfM66FGwINVmfFaTCOKzglNqL/ExEsml Hb5dGP74jukCv3Ylgepugjgrk1w4VpDL2mFBvAjdlL+pdYQ167yPjjUk3x2lOZR/1iID kEO76YvIQUPz/rfpR9tBZz5cwlQGL8CSnEc5+bvUSsIdqv9iOxRHP1LWlbLDfpwe8MnJ QUEpyU1rVL/GLhP+5EvW9ZHcV9KklBpr7qjtZaXUpxXVXK41/KxMgid1Nrazlqz+Qxxy FP+g==
MIME-Version: 1.0
X-Received: by 10.180.76.100 with SMTP id j4mr13387754wiw.51.1411994553334; Mon, 29 Sep 2014 05:42:33 -0700 (PDT)
Received: by 10.180.93.201 with HTTP; Mon, 29 Sep 2014 05:42:33 -0700 (PDT)
In-Reply-To: <30386970-B544-4BD5-B673-87FB2453F7B9@gmail.com>
References:   <2E4BB27CAB87BF43B4207C0E55860F181B5ACF@eusaamb103.ericsson.se>     <30386970-B544-4BD5-B673-87FB2453F7B9@gmail.com>
Date: Mon, 29 Sep 2014 05:42:33 -0700
Message-ID: 
From: Greg Shepherd 
To: Dino Farinacci 
Content-Type: multipart/alternative; boundary=f46d043c7b56c6c35c05043399b1
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/llvfS7McGEgwI_ktiq4hqNXA1vQ
Cc: "bier@ietf.org" , Robert Raszuk , Antoni Przygienda , "IJsbrand Wijnands \(iwijnand\)" , "Nagendra Kumar Nainar \(naikumar\)" , "Eric Rosen \(erosen\)" 
Subject: Re: [Bier] One specific transition churn ...
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: Mon, 29 Sep 2014 12:42:37 -0000

--f46d043c7b56c6c35c05043399b1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 27, 2014 at 9:22 AM, Dino Farinacci  wrote=
:

> Take SPRING IPv6 ... why extension header could not list all egress nodes
> as well as =E2=80=8B
>
> =E2=80=8Blist of transit BFRs where replication to said egress nodes is t=
o take
> place ?
>
> Even though this is a horrible idea since the length of the packet would
> be so large even past the point where people complain about GRE, VXLAN, a=
nd
> LISP headers adding overhead.
>

Can you define "so large"? A BIER domain is well defined set, and not
global.


> And they typically are only 16 bytes. Also, you would have to make even
> more copies of the packet since the SI would have to be smaller when
> encoding full addresses.
>

BIER is explicite replication, as the name implies. The objective is to no
more copies than next-hop neighbors.


> But the fact people will have to manage yet another address space (ie
> BFR-IDs) makes you wonder if the OpEx will be any less than the points ma=
de
> in the problem statement ID.
>

This has yet to come up in any operator discussions. In every case the
perceived benefits out way the challenges.

Greg


> Dino
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>

--f46d043c7b56c6c35c05043399b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Sat, Sep 27, 2014 at 9:22 AM, Dino Farinacci <farin=
acci@gmail.com> wrote:
Take SPRING IPv6 ... why extension header cou=
ld not list all egress nodes as well as =E2=80=8B

=C2=A0=C2=A0=C2=A0


=E2=80=8Blist of transit BFRs where replication to said egress nodes is to =
take place ?=C2=A0

Even though this is a horribl=
e idea since the length of the packet would be so large even past the point=
 where people complain about GRE, VXLAN, and LISP headers adding overhead.<=
/div>

Can you define "so large&q=
uot;? A BIER domain is well defined set, and not global.
=C2=A0
And they typicall=
y are only 16 bytes. Also, you would have to make even more copies of the p=
acket since the SI would have to be smaller when encoding full addresses.=
=C2=A0

BIER is explicite replic=
ation, as the name implies. The objective is to no more copies than next-ho=
p neighbors.
=C2=A0
But the fact people will have to manage yet another address =
space (ie BFR-IDs) makes you wonder if the OpEx will be any less than the p=
oints made in the problem statement ID.=C2=A0
=

This has yet to come up in any operator discussions. In ever=
y case the perceived benefits out way the challenges.

<=
div>Greg
=C2=A0
Dino
<=
/span>

_______________________________________________

BIER mailing list

BIER@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/bier





--f46d043c7b56c6c35c05043399b1--


From nobody Mon Sep 29 10:23:15 2014
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 831C91A8A40 for ; Mon, 29 Sep 2014 10:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level: 
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 V1hy5xu8pdt5 for ; Mon, 29 Sep 2014 10:23:08 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 DA90B1A8A3D for ; Mon, 29 Sep 2014 10:23:03 -0700 (PDT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 3BA0CA91BF771; Mon, 29 Sep 2014 17:23:00 +0000 (GMT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s8THMx6l022966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 13:23:02 -0400
Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 29 Sep 2014 13:23:01 -0400
Received: from SG70XWXCHMBA03.zap.alcatel-lucent.com ([169.254.3.2]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 01:22:58 +0800
From: "S, Somasundaram (Somasundaram)" 
To: IJsbrand Wijnands , "bier@ietf.org" 
Thread-Topic: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
Thread-Index: AQHP2kdn9m4KArrXkUaG4FOSY7lCVJwYXyEg
Date: Mon, 29 Sep 2014 17:22:57 +0000
Message-ID: 
References: <20140927113332.3734.38144.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.253.19.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/GQuny2piTUdgh_kuyN_m9QGMszk
Subject: Re: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.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: Mon, 29 Sep 2014 17:23:13 -0000

Hi Ice,
	Why do we only refer to RFC 4915 for MT-ID but not RFC 5120 where the MT-I=
D is 12 bits?

Regards
Somasundaram

-----Original Message-----
From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand Wijnands
Sent: Saturday, September 27, 2014 5:07 PM
To: bier@ietf.org
Subject: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.txt

FYI.

Begin forwarded message:

> From: 
> Subject: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
> Date: 27 Sep 2014 13:33:32 GMT+2
> To: 
> Reply-To: 
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
>=20
>        Title           : OSPF Extensions For BIER
>        Authors         : Peter Psenak
>                          Nagendra Kumar
>                          IJsbrand Wijnands
>                          Andrew Dolganow
> 	Filename        : draft-psenak-ospf-bier-extensions-00.txt
> 	Pages           : 6
> 	Date            : 2014-09-27
>=20
> 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.
>=20
>   This document describes the OSPF protocol extension required for BIER
>   with MPLS encapsulation.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-psenak-ospf-bier-extensions/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-psenak-ospf-bier-extensions-00
>=20
>=20
> Please note that it may take a couple of minutes from the time of=20
> submission until the htmlized version and diff are available at tools.iet=
f.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> 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=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier


From nobody Mon Sep 29 19:53:07 2014
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 CBF4C1A00C9 for ; Mon, 29 Sep 2014 19:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level: 
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 2v8kCwNAzOQM for ; Mon, 29 Sep 2014 19:53:03 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 64E1A1A00FF for ; Mon, 29 Sep 2014 19:53:00 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id EA023D577403A; Tue, 30 Sep 2014 02:52:58 +0000 (GMT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s8U2qxB6013299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 22:52:59 -0400
Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 29 Sep 2014 22:52:58 -0400
Received: from SG70XWXCHMBA03.zap.alcatel-lucent.com ([169.254.3.2]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 10:52:55 +0800
From: "S, Somasundaram (Somasundaram)" 
To: "S, Somasundaram (Somasundaram)" , IJsbrand Wijnands , "bier@ietf.org" 
Thread-Topic: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
Thread-Index: AQHP2kdn9m4KArrXkUaG4FOSY7lCVJwYXyEggACfTVA=
Date: Tue, 30 Sep 2014 02:52:54 +0000
Message-ID: 
References: <20140927113332.3734.38144.idtracker@ietfa.amsl.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.253.19.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/ms5gLCwpmlv9bAOAe1-v7JK-6lw
Subject: Re: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.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: Tue, 30 Sep 2014 02:53:06 -0000

I take my word back.. I see that there is a Draft submitted for ISIS to tak=
e care of this.. However, I don't see the draft related to ISIS in the Bof =
and hence the confusion..

-----Original Message-----
From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of S, Somasundaram (Som=
asundaram)
Sent: Monday, September 29, 2014 10:53 PM
To: IJsbrand Wijnands; bier@ietf.org
Subject: Re: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.t=
xt

Hi Ice,
	Why do we only refer to RFC 4915 for MT-ID but not RFC 5120 where the MT-I=
D is 12 bits?

Regards
Somasundaram

-----Original Message-----
From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand Wijnands
Sent: Saturday, September 27, 2014 5:07 PM
To: bier@ietf.org
Subject: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.txt

FYI.

Begin forwarded message:

> From: 
> Subject: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
> Date: 27 Sep 2014 13:33:32 GMT+2
> To: 
> Reply-To: 
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
>=20
>        Title           : OSPF Extensions For BIER
>        Authors         : Peter Psenak
>                          Nagendra Kumar
>                          IJsbrand Wijnands
>                          Andrew Dolganow
> 	Filename        : draft-psenak-ospf-bier-extensions-00.txt
> 	Pages           : 6
> 	Date            : 2014-09-27
>=20
> 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.
>=20
>   This document describes the OSPF protocol extension required for BIER
>   with MPLS encapsulation.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-psenak-ospf-bier-extensions/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-psenak-ospf-bier-extensions-00
>=20
>=20
> Please note that it may take a couple of minutes from the time of=20
> submission until the htmlized version and diff are available at tools.iet=
f.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> 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=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
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 nobody Mon Sep 29 20:03:04 2014
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 0A9281A00F4 for ; Mon, 29 Sep 2014 20:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 mtONFcINtnZT for ; Mon, 29 Sep 2014 20:03:01 -0700 (PDT)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92601A00F3 for ; Mon, 29 Sep 2014 20:03:00 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id q58so5239772wes.17 for ; Mon, 29 Sep 2014 20:02:59 -0700 (PDT)
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=xkuSDaNIJcIDRNHKlEtWJLZPqMsDk/gho/TvJx1/iYA=; b=ZxmxkrCTqgBPTbwh74u/j+P5sICahV9zYGWLMqFFr4JjnOJHVUtXQw5IJFsje75jhB RLGvkbiY4wqvZzIw9Gi7hAj4cFT8Mb6oAf/KLLe8HlEJz6brlTB3klwXI4nqWofX0WYM VWgoD25jd2e8t1klZIV6P+FAyGT8r3VSfgjZ9Y1BrM49h8jEEihmJeKNsvZA6elYTkxS PuEKf3XUwBiah6x4fU5mlccVtRVBUKn/QHm34yaV8zY8/n2+80U6Pk5e++4OneVDTTLY Fk+v9h4vzJ3/XCtGDKfUalHjGLMzS+LMUtYgA7nLhN10cx5qDTMgWLxnYv7pl0AYyoOn JmCA==
MIME-Version: 1.0
X-Received: by 10.194.94.73 with SMTP id da9mr49896183wjb.67.1412046179309; Mon, 29 Sep 2014 20:02:59 -0700 (PDT)
Received: by 10.180.93.201 with HTTP; Mon, 29 Sep 2014 20:02:59 -0700 (PDT)
In-Reply-To: 
References: <20140927113332.3734.38144.idtracker@ietfa.amsl.com>   
Date: Mon, 29 Sep 2014 20:02:59 -0700
Message-ID: 
From: Greg Shepherd 
To: "S, Somasundaram (Somasundaram)" 
Content-Type: multipart/alternative; boundary=047d7bb04efeec9d2105043f9e51
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/q5h6dAOAyb901o4EsgIDbvz4FFU
Cc: "bier@ietf.org" , IJsbrand Wijnands 
Subject: Re: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.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: Tue, 30 Sep 2014 03:03:03 -0000

--047d7bb04efeec9d2105043f9e51
Content-Type: text/plain; charset=UTF-8

I'll update the BoF Wiki, thanks.

Greg

On Mon, Sep 29, 2014 at 7:52 PM, S, Somasundaram (Somasundaram) <
somasundaram.s@alcatel-lucent.com> wrote:

> I take my word back.. I see that there is a Draft submitted for ISIS to
> take care of this.. However, I don't see the draft related to ISIS in the
> Bof and hence the confusion..
>
> -----Original Message-----
> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of S, Somasundaram
> (Somasundaram)
> Sent: Monday, September 29, 2014 10:53 PM
> To: IJsbrand Wijnands; bier@ietf.org
> Subject: Re: [Bier] Fwd: I-D Action:
> draft-psenak-ospf-bier-extensions-00.txt
>
> Hi Ice,
>         Why do we only refer to RFC 4915 for MT-ID but not RFC 5120 where
> the MT-ID is 12 bits?
>
> Regards
> Somasundaram
>
> -----Original Message-----
> From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand Wijnands
> Sent: Saturday, September 27, 2014 5:07 PM
> To: bier@ietf.org
> Subject: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
>
> FYI.
>
> Begin forwarded message:
>
> > From: 
> > Subject: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
> > Date: 27 Sep 2014 13:33:32 GMT+2
> > To: 
> > Reply-To: 
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> >        Title           : OSPF Extensions For BIER
> >        Authors         : Peter Psenak
> >                          Nagendra Kumar
> >                          IJsbrand Wijnands
> >                          Andrew Dolganow
> >       Filename        : draft-psenak-ospf-bier-extensions-00.txt
> >       Pages           : 6
> >       Date            : 2014-09-27
> >
> > 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 the OSPF protocol extension required for BIER
> >   with MPLS encapsulation.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-psenak-ospf-bier-extensions/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-psenak-ospf-bier-extensions-00
> >
> >
> > 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
>
> _______________________________________________
> 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
>

--047d7bb04efeec9d2105043f9e51
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'll update the BoF Wiki, thanks.

G=
reg

On=
 Mon, Sep 29, 2014 at 7:52 PM, S, Somasundaram (Somasundaram) <somasundaram.s@alcatel-lucent.com> wrote:
I take my word back.. I see that there is a Draft submi=
tted for ISIS to take care of this.. However, I don't see the draft rel=
ated to ISIS in the Bof and hence the confusion..




-----Original Message-----

From: BIER [mailto:bier-bounces@ie=
tf.org] On Behalf Of S, Somasundaram (Somasundaram)

Sent: Monday, September 29, 2014 10:53 PM

To: IJsbrand Wijnands; bier@ietf.org
Subject: Re: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.t=
xt



Hi Ice,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Why do we only refer to RFC 4915 for MT-ID but =
not RFC 5120 where the MT-ID is 12 bits?



Regards

Somasundaram



-----Original Message-----

From: BIER [mailto:bier-bounces@ie=
tf.org] On Behalf Of IJsbrand Wijnands

Sent: Saturday, September 27, 2014 5:07 PM

To: bier@ietf.org

Subject: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.txt


FYI.



Begin forwarded message:



> From: <internet-drafts@=
ietf.org>

> Subject: I-D Action: draft-psenak-ospf-bier-extensions-00.txt

> Date: 27 Sep 2014 13:33:32 GMT+2

> To: <i-d-announce@ietf.org=
>

> Reply-To: <internet-dra=
fts@ietf.org>

>

>

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: OSPF Extensions For BIER

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =
Peter Psenak

>=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 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 IJsbrand Wijnands

>=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=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-=
psenak-ospf-bier-extensions-00.txt

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: 6

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : 2014-09-27

>

> 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 the OSPF protocol extension requir=
ed for BIER

>=C2=A0 =C2=A0with MPLS encapsulation.

>

>

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-psenak-o=
spf-bier-extensions/

>

> There's also a htmlized version available at:

> http://tools.ietf.org/html/draft-psenak-ospf-bier-e=
xtensions-00

>

>

> 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



_______________________________________________

BIER mailing list

BIER@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/bier



_______________________________________________

BIER mailing list

BIER@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/bier





--047d7bb04efeec9d2105043f9e51--


From nobody Mon Sep 29 20:43:20 2014
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 8F9461A0102 for ; Mon, 29 Sep 2014 20:43:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 9QhHbmLekLhN for ; Mon, 29 Sep 2014 20:43:08 -0700 (PDT)
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 A32A81A00FF for ; Mon, 29 Sep 2014 20:43:07 -0700 (PDT)
X-AuditID: c6180641-f79916d00000623a-f3-5429cde343aa
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 00.39.25146.3EDC9245; Mon, 29 Sep 2014 23:23:47 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Mon, 29 Sep 2014 23:43:05 -0400
From: Antoni Przygienda 
To: "gjshep@gmail.com" , "S, Somasundaram (Somasundaram)" 
Thread-Topic: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.txt
Thread-Index: AQHP2kdlBRTLd2CdcUW4VMc+LzWUcZwYooSAgACfPgCAAALRgP//xPmg
Date: Tue, 30 Sep 2014 03:43:05 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F181B673A@eusaamb103.ericsson.se>
References: <20140927113332.3734.38144.idtracker@ietfa.amsl.com>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.12]
Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F181B673Aeusaamb103ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonUPfxWc0Qgyv9chZLZ+xhstgyJ8/i 1Zw7zBaH9yk4sHi0PtvL6jHl90ZWj52z7rJ7LFnykymAJYrLJiU1J7MstUjfLoEro3XLLdaC NbsYK3a+m8zewLhlK2MXIyeHhICJxLQPN5ggbDGJC/fWs3UxcnEICRxllNhyZw5YQkhgOaPE 7n+KIDabgIXE5W9PmUFsEYFCiaPvmoEGcXAwC7hJHD6aCRIWFvCVOPP3O1RJgMSnj4dZIGw3 iUm7vrOC2CwCqhL95xeC1fAKeEucfv2VGWLvAyaJL5+Wgh3HKRAoMfH/P7AbGIGO+35qDZjN LCAucevJfKijBSSW7DnPDGGLSrx8/I8VwlaSmPP6GjNEfb7Ei1VP2SCWCUqcnPmEZQKj6Cwk o2YhKZuFpGwW2GuaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0VI0dpcWpZbrqR4SZGYOwd k2Bz3MG44JPlIUYBDkYlHt4HLRohQqyJZcWVuYcYpTlYlMR5NavnBQsJpCeWpGanphakFsUX leakFh9iZOLglGpgDC3/YM+kfWjO3HLn9BjXh+ft9ucx3nScM2He+nO7d7FyStw50R/I+P7h vc++v7QMjtYnFfCoTyjIzwpwWcTAclWaR//zEba6LQLGApqVXltUV34xyv6hPiv4iH900Ptp 3X3n3k58H5titet59cP+mvhNxg1HeyYs7zHt+bHv/u5nk89+izgupsRSnJFoqMVcVJwIABUq hOueAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/zFg1BXmV2TSfW1e3yoiaHMl5c5Y
Cc: "bier@ietf.org" , IJsbrand Wijnands 
Subject: Re: [Bier] Fwd: I-D Action: draft-psenak-ospf-bier-extensions-00.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: Tue, 30 Sep 2014 03:43:17 -0000

--_000_2E4BB27CAB87BF43B4207C0E55860F181B673Aeusaamb103ericsso_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U29tYXN1bmRhcmFtLCB5b3UgYXJlIHBlcmZlY3RseSBjb3JyZWN0LCB0aGUgQklFUiBJU0lTIEkg
c3VibWl0dGVkIHNob3dzIDggYml0cyB3aGlsZSBJU0lTIE1ULUlEIGVuZGVkIHVwIGJlaW5nIDEy
IGJpdHMgZmluYWxseSBpbiBSRkM1MTIwIChtb3JlIGVtYmFycmFzc2luZyBnaXZlbiBJ4oCZbSBv
biBhdXRob3LigJlzIGxpc3Qgb2YgdGhlIHNhaWQgUkZDIDstKSBNb3Jlb3ZlciwgYW5vdGhlciBw
ZXJzb24gcG9pbnRlZCBvdXQgdGhhdCB0aGUgdHlwZS9sZW4gZmllbGRzIGVuZGVkIHVwIGJlaW5n
IDE2IGJpdHMgbG9uZyB3aGljaCB3b27igJl0IHdvcmsgaW4gcm91dGVyIGNhcGFiaWxpdGllcy4g
SeKAmWxsIGNvcnJlY3QgYm90aCBhbmQgcmUtc3VibWl0IGJlZm9yZSBCT0YuICBUaGUgZGlzY3Vz
c2lvbiB3aGV0aGVyIEJJRVIgc2hvdWxkIGJlIHBsYWNlZCBpbiBleHRlbmRlZCBUTFZzIGFuZCBw
b3NzaWJseSBzb21ldGhpbmcgZWxzZSB0aGF0IHJvdXRlciBjYXAgaXMgc29tZXRoaW5nIHRoYXQg
aXMgcHJvYmFibHkgd29ydGggaGF2aW5nIG9uY2UgYW5kIGlmIEJJRVIgaXMgdGFkIGZ1cnRoZXIg
YWxvbmcuDQoNCnRoYW5rcyAgZm9yIGNvbW1lbnRzDQoNCi0tLSB0b255DQoNCkZyb206IEJJRVIg
W21haWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnIFNoZXBoZXJk
DQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAyOSwgMjAxNCA4OjAzIFBNDQpUbzogUywgU29tYXN1
bmRhcmFtIChTb21hc3VuZGFyYW0pDQpDYzogYmllckBpZXRmLm9yZzsgSUpzYnJhbmQgV2lqbmFu
ZHMNClN1YmplY3Q6IFJlOiBbQmllcl0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1wc2VuYWstb3Nw
Zi1iaWVyLWV4dGVuc2lvbnMtMDAudHh0DQoNCkknbGwgdXBkYXRlIHRoZSBCb0YgV2lraSwgdGhh
bmtzLg0KDQpHcmVnDQoNCk9uIE1vbiwgU2VwIDI5LCAyMDE0IGF0IDc6NTIgUE0sIFMsIFNvbWFz
dW5kYXJhbSAoU29tYXN1bmRhcmFtKSA8c29tYXN1bmRhcmFtLnNAYWxjYXRlbC1sdWNlbnQuY29t
PG1haWx0bzpzb21hc3VuZGFyYW0uc0BhbGNhdGVsLWx1Y2VudC5jb20+PiB3cm90ZToNCkkgdGFr
ZSBteSB3b3JkIGJhY2suLiBJIHNlZSB0aGF0IHRoZXJlIGlzIGEgRHJhZnQgc3VibWl0dGVkIGZv
ciBJU0lTIHRvIHRha2UgY2FyZSBvZiB0aGlzLi4gSG93ZXZlciwgSSBkb24ndCBzZWUgdGhlIGRy
YWZ0IHJlbGF0ZWQgdG8gSVNJUyBpbiB0aGUgQm9mIGFuZCBoZW5jZSB0aGUgY29uZnVzaW9uLi4N
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJJRVIgW21haWx0bzpiaWVyLWJv
dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP
ZiBTLCBTb21hc3VuZGFyYW0gKFNvbWFzdW5kYXJhbSkNClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVy
IDI5LCAyMDE0IDEwOjUzIFBNDQpUbzogSUpzYnJhbmQgV2lqbmFuZHM7IGJpZXJAaWV0Zi5vcmc8
bWFpbHRvOmJpZXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0JpZXJdIEZ3ZDogSS1EIEFjdGlv
bjogZHJhZnQtcHNlbmFrLW9zcGYtYmllci1leHRlbnNpb25zLTAwLnR4dA0KDQpIaSBJY2UsDQog
ICAgICAgIFdoeSBkbyB3ZSBvbmx5IHJlZmVyIHRvIFJGQyA0OTE1IGZvciBNVC1JRCBidXQgbm90
IFJGQyA1MTIwIHdoZXJlIHRoZSBNVC1JRCBpcyAxMiBiaXRzPw0KDQpSZWdhcmRzDQpTb21hc3Vu
ZGFyYW0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJJRVIgW21haWx0bzpi
aWVyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJl
aGFsZiBPZiBJSnNicmFuZCBXaWpuYW5kcw0KU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAyNywg
MjAxNCA1OjA3IFBNDQpUbzogYmllckBpZXRmLm9yZzxtYWlsdG86YmllckBpZXRmLm9yZz4NClN1
YmplY3Q6IFtCaWVyXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXBzZW5hay1vc3BmLWJpZXItZXh0
ZW5zaW9ucy0wMC50eHQNCg0KRllJLg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KPiBG
cm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmc+Pg0KPiBTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1wc2VuYWstb3NwZi1iaWVyLWV4
dGVuc2lvbnMtMDAudHh0DQo+IERhdGU6IDI3IFNlcCAyMDE0IDEzOjMzOjMyIEdNVCsyDQo+IFRv
OiA8aS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0K
PiBSZXBseS1UbzogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJh
ZnRzQGlldGYub3JnPj4NCj4NCj4NCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl
IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPg0KPg0KPiAg
ICAgICAgVGl0bGUgICAgICAgICAgIDogT1NQRiBFeHRlbnNpb25zIEZvciBCSUVSDQo+ICAgICAg
ICBBdXRob3JzICAgICAgICAgOiBQZXRlciBQc2VuYWsNCj4gICAgICAgICAgICAgICAgICAgICAg
ICAgIE5hZ2VuZHJhIEt1bWFyDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBJSnNicmFuZCBX
aWpuYW5kcw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgQW5kcmV3IERvbGdhbm93DQo+ICAg
ICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LXBzZW5hay1vc3BmLWJpZXItZXh0ZW5zaW9ucy0w
MC50eHQNCj4gICAgICAgUGFnZXMgICAgICAgICAgIDogNg0KPiAgICAgICBEYXRlICAgICAgICAg
ICAgOiAyMDE0LTA5LTI3DQo+DQo+IEFic3RyYWN0Og0KPiAgIEJpdCBJbmRleCBFeHBsaWNpdCBS
ZXBsaWNhdGlvbiAoQklFUikgaXMgYW4gYXJjaGl0ZWN0dXJlIHRoYXQNCj4gICBwcm92aWRlcyBv
cHRpbWFsIG11bHRpY2FzdCBmb3J3YXJkaW5nIHRocm91Z2ggYSAiQklFUiBkb21haW4iIHdpdGhv
dXQNCj4gICByZXF1aXJpbmcgaW50ZXJtZWRpYXRlIHJvdXRlcnMgdG8gbWFpbnRhaW4gYW55IG11
bHRpY2FzdCByZWxhdGVkIHBlci0NCj4gICBmbG93IHN0YXRlLiAgQklFUiBhbHNvIGRvZXMgbm90
IHJlcXVpcmUgYW55IGV4cGxpY2l0IHRyZWUtYnVpbGRpbmcNCj4gICBwcm90b2NvbCBmb3IgaXRz
IG9wZXJhdGlvbi4gIEEgbXVsdGljYXN0IGRhdGEgcGFja2V0IGVudGVycyBhIEJJRVINCj4gICBk
b21haW4gYXQgYSAiQml0LUZvcndhcmRpbmcgSW5ncmVzcyBSb3V0ZXIiIChCRklSKSwgYW5kIGxl
YXZlcyB0aGUNCj4gICBCSUVSIGRvbWFpbiBhdCBvbmUgb3IgbW9yZSAiQml0LUZvcndhcmRpbmcg
RWdyZXNzIFJvdXRlcnMiIChCRkVScykuDQo+ICAgVGhlIEJGSVIgcm91dGVyIGFkZHMgYSBCSUVS
IGhlYWRlciB0byB0aGUgcGFja2V0LiAgVGhlIEJJRVIgaGVhZGVyDQo+ICAgY29udGFpbnMgYSBi
aXQtc3RyaW5nIGluIHdoaWNoIGVhY2ggYml0IHJlcHJlc2VudHMgZXhhY3RseSBvbmUgQkZFUg0K
PiAgIHRvIGZvcndhcmQgdGhlIHBhY2tldCB0by4gIFRoZSBzZXQgb2YgQkZFUnMgdG8gd2hpY2gg
dGhlIG11bHRpY2FzdA0KPiAgIHBhY2tldCBuZWVkcyB0byBiZSBmb3J3YXJkZWQgaXMgZXhwcmVz
c2VkIGJ5IHNldHRpbmcgdGhlIGJpdHMgdGhhdA0KPiAgIGNvcnJlc3BvbmQgdG8gdGhvc2Ugcm91
dGVycyBpbiB0aGUgQklFUiBoZWFkZXIuDQo+DQo+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg
dGhlIE9TUEYgcHJvdG9jb2wgZXh0ZW5zaW9uIHJlcXVpcmVkIGZvciBCSUVSDQo+ICAgd2l0aCBN
UExTIGVuY2Fwc3VsYXRpb24uDQo+DQo+DQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw
YWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9kcmFmdC1wc2VuYWstb3NwZi1iaWVyLWV4dGVuc2lvbnMvDQo+DQo+IFRoZXJlJ3MgYWxzbyBh
IGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1wc2VuYWstb3NwZi1iaWVyLWV4dGVuc2lvbnMtMDANCj4NCj4NCj4gUGxlYXNl
IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg
b2YNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg
YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQo+DQo+
IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN
Cj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1ELUFubm91bmNlIG1haWxp
bmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOkktRC1Bbm5vdW5jZUBpZXRm
Lm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3Vu
Y2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh
ZG93Lmh0bWwgb3INCj4gZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQN
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJJRVIg
bWFpbGluZyBsaXN0DQpCSUVSQGlldGYub3JnPG1haWx0bzpCSUVSQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpCSUVSIG1haWxpbmcgbGlzdA0KQklFUkBp
ZXRmLm9yZzxtYWlsdG86QklFUkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vYmllcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KQklFUiBtYWlsaW5nIGxpc3QNCkJJRVJAaWV0Zi5vcmc8bWFpbHRvOkJJRVJA
aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXINCg0K

--_000_2E4BB27CAB87BF43B4207C0E55860F181B673Aeusaamb103ericsso_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3
RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlNvbWFzdW5kYXJhbSwgeW91IGFyZSBwZXJm
ZWN0bHkgY29ycmVjdCwgdGhlIEJJRVIgSVNJUyBJIHN1Ym1pdHRlZCBzaG93cyA4IGJpdHMgd2hp
bGUgSVNJUyBNVC1JRCBlbmRlZCB1cCBiZWluZyAxMiBiaXRzIGZpbmFsbHkgaW4gUkZDNTEyMCAo
bW9yZSBlbWJhcnJhc3NpbmcgZ2l2ZW4gSeKAmW0NCiBvbiBhdXRob3LigJlzIGxpc3Qgb2YgdGhl
IHNhaWQgUkZDIDstKSBNb3Jlb3ZlciwgYW5vdGhlciBwZXJzb24gcG9pbnRlZCBvdXQgdGhhdCB0
aGUgdHlwZS9sZW4gZmllbGRzIGVuZGVkIHVwIGJlaW5nIDE2IGJpdHMgbG9uZyB3aGljaCB3b27i
gJl0IHdvcmsgaW4gcm91dGVyIGNhcGFiaWxpdGllcy4gSeKAmWxsIGNvcnJlY3QgYm90aCBhbmQg
cmUtc3VibWl0IGJlZm9yZSBCT0YuICZuYnNwO1RoZSBkaXNjdXNzaW9uIHdoZXRoZXIgQklFUiBz
aG91bGQgYmUgcGxhY2VkDQogaW4gZXh0ZW5kZWQgVExWcyBhbmQgcG9zc2libHkgc29tZXRoaW5n
IGVsc2UgdGhhdCByb3V0ZXIgY2FwIGlzIHNvbWV0aGluZyB0aGF0IGlzIHByb2JhYmx5IHdvcnRo
IGhhdmluZyBvbmNlIGFuZCBpZiBCSUVSIGlzIHRhZCBmdXJ0aGVyIGFsb25nLg0KPG86cD48L286
cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0Ij50aGFua3MgJm5ic3A7Zm9yIGNvbW1lbnRzPG86cD48L286cD48L3NwYW4+PC9m
b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIz
IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4t
LS0gdG9ueQ0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj
ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz
aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48
L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0
O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9t
YSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3Nw
YW4+PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij4gQklFUg0KIFttYWlsdG86Ymllci1ib3VuY2VzQGlldGYub3JnXSA8Yj48
c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T24gQmVoYWxmIE9mIDwvc3Bhbj4NCjwvYj5H
cmVnIFNoZXBoZXJkPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6
PC9zcGFuPjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTQgODowMyBQTTxicj4NCjxiPjxz
cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBTLCBTb21hc3VuZGFy
YW0gKFNvbWFzdW5kYXJhbSk8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+
Q2M6PC9zcGFuPjwvYj4gYmllckBpZXRmLm9yZzsgSUpzYnJhbmQgV2lqbmFuZHM8YnI+DQo8Yj48
c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW0Jp
ZXJdIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtcHNlbmFrLW9zcGYtYmllci1leHRlbnNpb25zLTAw
LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJU
aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JJ2xsIHVwZGF0
ZSB0aGUgQm9GIFdpa2ksIHRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBS
b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u
dCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0Ij5HcmVnPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz
aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0Ij5PbiBNb24sIFNlcCAyOSwgMjAxNCBhdCA3OjUyIFBNLCBTLCBTb21hc3VuZGFyYW0gKFNv
bWFzdW5kYXJhbSkgJmx0OzxhIGhyZWY9Im1haWx0bzpzb21hc3VuZGFyYW0uc0BhbGNhdGVsLWx1
Y2VudC5jb20iIHRhcmdldD0iX2JsYW5rIj5zb21hc3VuZGFyYW0uc0BhbGNhdGVsLWx1Y2VudC5j
b208L2E+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIHRha2UgbXkgd29yZCBiYWNrLi4gSSBzZWUgdGhh
dCB0aGVyZSBpcyBhIERyYWZ0IHN1Ym1pdHRlZCBmb3IgSVNJUyB0byB0YWtlIGNhcmUgb2YgdGhp
cy4uIEhvd2V2ZXIsIEkgZG9uJ3Qgc2VlIHRoZSBkcmFmdCByZWxhdGVkIHRvIElTSVMgaW4gdGhl
IEJvZiBhbmQgaGVuY2UgdGhlIGNvbmZ1c2lvbi4uPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFj
ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGJyPg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBCSUVSIFttYWlsdG86PGEgaHJl
Zj0ibWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZyI+Ymllci1ib3VuY2VzQGlldGYub3JnPC9h
Pl0gT24gQmVoYWxmIE9mIFMsIFNvbWFzdW5kYXJhbSAoU29tYXN1bmRhcmFtKTxicj4NClNlbnQ6
IE1vbmRheSwgU2VwdGVtYmVyIDI5LCAyMDE0IDEwOjUzIFBNPGJyPg0KVG86IElKc2JyYW5kIFdp
am5hbmRzOyA8YSBocmVmPSJtYWlsdG86YmllckBpZXRmLm9yZyI+YmllckBpZXRmLm9yZzwvYT48
YnI+DQpTdWJqZWN0OiBSZTogW0JpZXJdIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtcHNlbmFrLW9z
cGYtYmllci1leHRlbnNpb25zLTAwLnR4dDxicj4NCjxicj4NCkhpIEljZSw8YnI+DQombmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgV2h5IGRvIHdlIG9ubHkgcmVmZXIgdG8gUkZDIDQ5MTUgZm9y
IE1ULUlEIGJ1dCBub3QgUkZDIDUxMjAgd2hlcmUgdGhlIE1ULUlEIGlzIDEyIGJpdHM/PGJyPg0K
PGJyPg0KUmVnYXJkczxicj4NClNvbWFzdW5kYXJhbTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogQklFUiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpiaWVy
LWJvdW5jZXNAaWV0Zi5vcmciPmJpZXItYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBP
ZiBJSnNicmFuZCBXaWpuYW5kczxicj4NClNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMjcsIDIw
MTQgNTowNyBQTTxicj4NClRvOiA8YSBocmVmPSJtYWlsdG86YmllckBpZXRmLm9yZyI+YmllckBp
ZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBbQmllcl0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1w
c2VuYWstb3NwZi1iaWVyLWV4dGVuc2lvbnMtMDAudHh0PGJyPg0KPGJyPg0KRllJLjxicj4NCjxi
cj4NCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOjxicj4NCjxicj4NCiZndDsgRnJvbTogJmx0Ozxh
IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0Bp
ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1wc2Vu
YWstb3NwZi1iaWVyLWV4dGVuc2lvbnMtMDAudHh0PGJyPg0KJmd0OyBEYXRlOiAyNyBTZXAgMjAx
NCAxMzozMzozMiBHTVQmIzQzOzI8YnI+DQomZ3Q7IFRvOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmkt
ZC1hbm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPiZndDs8YnI+DQom
Z3Q7IFJlcGx5LVRvOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y
ZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi
cj4NCiZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp
bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K
Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBPU1BGIEV4dGVuc2lvbnMgRm9yIEJJRVI8YnI+DQomZ3Q7
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7OiBQZXRlciBQc2VuYWs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7IE5hZ2VuZHJhIEt1bWFyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBJSnNicmFuZCBXaWpuYW5kczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgQW5kcmV3IERvbGdhbm93PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwO0ZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQt
cHNlbmFrLW9zcGYtYmllci1leHRlbnNpb25zLTAwLnR4dDxicj4NCiZndDsmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDtQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7OiA2PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RhdGUmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTQtMDktMjc8YnI+DQomZ3Q7PGJy
Pg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO0JpdCBJbmRleCBFeHBsaWNp
dCBSZXBsaWNhdGlvbiAoQklFUikgaXMgYW4gYXJjaGl0ZWN0dXJlIHRoYXQ8YnI+DQomZ3Q7Jm5i
c3A7ICZuYnNwO3Byb3ZpZGVzIG9wdGltYWwgbXVsdGljYXN0IGZvcndhcmRpbmcgdGhyb3VnaCBh
ICZxdW90O0JJRVIgZG9tYWluJnF1b3Q7IHdpdGhvdXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3Jl
cXVpcmluZyBpbnRlcm1lZGlhdGUgcm91dGVycyB0byBtYWludGFpbiBhbnkgbXVsdGljYXN0IHJl
bGF0ZWQgcGVyLTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ZmxvdyBzdGF0ZS4mbmJzcDsgQklFUiBh
bHNvIGRvZXMgbm90IHJlcXVpcmUgYW55IGV4cGxpY2l0IHRyZWUtYnVpbGRpbmc8YnI+DQomZ3Q7
Jm5ic3A7ICZuYnNwO3Byb3RvY29sIGZvciBpdHMgb3BlcmF0aW9uLiZuYnNwOyBBIG11bHRpY2Fz
dCBkYXRhIHBhY2tldCBlbnRlcnMgYSBCSUVSPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtkb21haW4g
YXQgYSAmcXVvdDtCaXQtRm9yd2FyZGluZyBJbmdyZXNzIFJvdXRlciZxdW90OyAoQkZJUiksIGFu
ZCBsZWF2ZXMgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtCSUVSIGRvbWFpbiBhdCBvbmUgb3Ig
bW9yZSAmcXVvdDtCaXQtRm9yd2FyZGluZyBFZ3Jlc3MgUm91dGVycyZxdW90OyAoQkZFUnMpLjxi
cj4NCiZndDsmbmJzcDsgJm5ic3A7VGhlIEJGSVIgcm91dGVyIGFkZHMgYSBCSUVSIGhlYWRlciB0
byB0aGUgcGFja2V0LiZuYnNwOyBUaGUgQklFUiBoZWFkZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw
O2NvbnRhaW5zIGEgYml0LXN0cmluZyBpbiB3aGljaCBlYWNoIGJpdCByZXByZXNlbnRzIGV4YWN0
bHkgb25lIEJGRVI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3RvIGZvcndhcmQgdGhlIHBhY2tldCB0
by4mbmJzcDsgVGhlIHNldCBvZiBCRkVScyB0byB3aGljaCB0aGUgbXVsdGljYXN0PGJyPg0KJmd0
OyZuYnNwOyAmbmJzcDtwYWNrZXQgbmVlZHMgdG8gYmUgZm9yd2FyZGVkIGlzIGV4cHJlc3NlZCBi
eSBzZXR0aW5nIHRoZSBiaXRzIHRoYXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2NvcnJlc3BvbmQg
dG8gdGhvc2Ugcm91dGVycyBpbiB0aGUgQklFUiBoZWFkZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsm
bmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIE9TUEYgcHJvdG9jb2wgZXh0
ZW5zaW9uIHJlcXVpcmVkIGZvciBCSUVSPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt3aXRoIE1QTFMg
ZW5jYXBzdWxhdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIElFVEYgZGF0
YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KJmd0OyA8YSBocmVm
PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wc2VuYWstb3NwZi1iaWVy
LWV4dGVuc2lvbnMvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC1wc2VuYWstb3NwZi1iaWVyLWV4dGVuc2lvbnMvPC9hPjxicj4NCiZndDs8
YnI+DQomZ3Q7IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxi
cj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcHNlbmFr
LW9zcGYtYmllci1leHRlbnNpb25zLTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1wc2VuYWstb3NwZi1iaWVyLWV4dGVuc2lvbnMtMDA8L2E+PGJy
Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug
YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mPGJyPg0KJmd0OyBzdWJtaXNzaW9u
IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEg
aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRm
Lm9yZzwvYT4uPGJyPg0KJmd0Ozxicj4NCiZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2
YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iZnRwOi8vZnRw
LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0
Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgSS1ELUFubm91
bmNlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOkktRC1Bbm5vdW5jZUBp
ZXRmLm9yZyI+SS1ELUFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UiIHRhcmdldD0i
X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5j
ZTwvYT48YnI+DQomZ3Q7IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiA8YSBocmVmPSJodHRw
Oi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3
LmlldGYub3JnL3NoYWRvdy5odG1sPC9hPiBvcjxicj4NCiZndDsgPGEgaHJlZj0iZnRwOi8vZnRw
LmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9m
dHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwvYT48YnI+DQo8YnI+DQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkJJRVIgbWFpbGlu
ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciPkJJRVJAaWV0Zi5vcmc8
L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9i
aWVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9iaWVyPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KQklFUiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86
QklFUkBpZXRmLm9yZyI+QklFUkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXI8L2E+PGJyPg0KPGJyPg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpCSUVSIG1haWxp
bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpCSUVSQGlldGYub3JnIj5CSUVSQGlldGYub3Jn
PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
YmllciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vYmllcjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_2E4BB27CAB87BF43B4207C0E55860F181B673Aeusaamb103ericsso_--


From nobody Tue Sep 30 03:27:07 2014
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 29F661A033E for ; Tue, 30 Sep 2014 03:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 P8WKjsVVEzMI for ; Tue, 30 Sep 2014 03:26:58 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0450E1A033C for ; Tue, 30 Sep 2014 03:26:57 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKB72834; Tue, 30 Sep 2014 10:26:56 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 30 Sep 2014 11:26:51 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 30 Sep 2014 18:26:43 +0800
From: Xuxiaohu 
To: "bier@ietf.org" 
Thread-Topic: New Version Notification for draft-xu-bier-encapsulation-00.txt
Thread-Index: AQHP3JVYJAJptSyBSES+iPmVbCBS9JwZeIvw
Date: Tue, 30 Sep 2014 10:26:42 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BD8C5@NKGEML512-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/bier/uckA-H1MB3zN8w7Y-tnQmWC6I7w
Subject: [Bier] FW: New Version Notification for draft-xu-bier-encapsulation-00.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: Tue, 30 Sep 2014 10:27:01 -0000

SGkgYWxsLA0KDQpBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJkcywNClhp
YW9odQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRz
QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNk
YXksIFNlcHRlbWJlciAzMCwgMjAxNCA2OjAwIFBNDQpUbzogc29tYXN1bmRhcmFtLnNAYWxjYXRl
bC1sdWNlbnQuY29tOyBYdXhpYW9odTsgUyBTb21hc3VuZGFyYW07IFh1eGlhb2h1DQpTdWJqZWN0
OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1LWJpZXItZW5jYXBzdWxhdGlv
bi0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteHUtYmllci1lbmNhcHN1
bGF0aW9uLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBYaWFvaHUg
WHUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQteHUt
Ymllci1lbmNhcHN1bGF0aW9uDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJQklFUiBFbmNhcHN1bGF0
aW9uDQpEb2N1bWVudCBkYXRlOgkyMDE0LTA5LTMwDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlz
c2lvbg0KUGFnZXM6CQk2DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl
cm5ldC1kcmFmdHMvZHJhZnQteHUtYmllci1lbmNhcHN1bGF0aW9uLTAwLnR4dA0KU3RhdHVzOiAg
ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LWJpZXItZW5j
YXBzdWxhdGlvbi8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC14dS1iaWVyLWVuY2Fwc3VsYXRpb24tMDANCg0KDQpBYnN0cmFjdDoNCiAgIEJpdCBJbmRl
eCBFeHBsaWNpdCBSZXBsaWNhdGlvbiAoQklFUikgaXMgYSBuZXcgbXVsdGljYXN0IGZvcndhcmRp
bmcNCiAgIHBhcmFkaWdtIHdoaWNoIGRvZXNuJ3QgcmVxdWlyZSBhbiBleHBsaWNpdCB0cmVlLWJ1
aWxkaW5nIHByb3RvY29sIGFuZA0KICAgZG9lc24ndCByZXF1aXJlIGludGVybWVkaWF0ZSByb3V0
ZXJzIHRvIG1haW50YWluIGFueSBtdWx0aWNhc3Qgc3RhdGUuDQogICBUaGlzIGRvY3VtZW50IHBy
b3Bvc2VzIGEgdHJhbnNwb3J0LWluZGVwZWRlbnQgQklFUiBlbmNhcHN1bGF0aW9uDQogICBoZWFk
ZXIgd2hpY2ggaXMgYXBwbGljYWJsZSBpbiBhbnkga2luZCBvZiB0cmFuc3BvcnQgbmV0d29ya3Mu
DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h
eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVu
dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu
aWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==