From nobody Sun Feb 1 01:49:30 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241CE1A87A2 for ; Sun, 1 Feb 2015 01:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0YQYuW7vVj0A for ; Sun, 1 Feb 2015 01:49:26 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B16491A8799 for ; Sun, 1 Feb 2015 01:49:24 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t119nLP1010997; Sun, 1 Feb 2015 09:49:22 GMT Received: from 950129200 (089144218126.atnat0027.highway.a1.net [89.144.218.126]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t119nKSA010982 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2015 09:49:21 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , "'Greg Shepherd'" References: <54CD34A5.1090706@joelhalpern.com> <4C60E3F0-01E9-45F5-8318-ED71AD459BCC@gmail.com> <54CD44A7.4060201@joelhalpern.com> In-Reply-To: <54CD44A7.4060201@joelhalpern.com> Date: Sun, 1 Feb 2015 09:49:19 -0000 Message-ID: <019f01d03e04$5afe7040$10fb50c0$@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: AQHbkIa7lMlb8KdIQpy+1SWTxa0EcQF5uSXVAobyO1QCWQrs9pySGF/g Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21296.006 X-TM-AS-Result: No--32.165-10.0-31-10 X-imss-scan-details: No--32.165-10.0-31-10 X-TMASE-MatchedRID: cxtZ8fwm3r8v2k3M27J31pJrW03DacWENDhesTGU0QvSYAzZ6KmqWv6e 1CkYILgfE51SW+g7Foo1pM8JV+Ai9FI3mP8aC0PBdXz3l78F3Yl4nU6KtjDMA1eilmPI7oJlKEi lpp/NgyAAeO2G8bDRjbcM7XmcaNnTZ59AB9pURzl/HPKCjG4GGAiBYiT9V2dSkzE2kM4b6HqK61 Q63RemBBXS+gzjJyCY+igTcz6o/va6x2PC25NEZszWN98iBBeGTGyd6AixReS1eX0jEQ9c6mTe3 SuP9AHU0Y4Q9rlCBLuZLeMMuLkTeQi0xaFtKyGqfh/0N74LJALJOJysDBbflmrhyhOS2sZfciKf aFfvUqvenJ7daGHZETeT288mssTU6n7m2EGKFgRsG7r4Qh7N3Pi4nVERfgwdZlEaNLFSLwNyk3S T5ewjmcSC6D6Lu66psnByWtg5LXS+9Go4BgFPZnBRIrj8R47F4PxBuU3oo1UUl9bvAS7WQDWmu/ DjYT3q92KCjPDIokCWJcbpNaIEAPs6AFvEdeZfHPCema1j/6vEkmLzgU2Kepsoi2XrUn/JyeMtM D9QOgAfACoClnjRoWLHjeGkjh9X13sCf7FGZdb6C0ePs7A07QKmARN5PTKc Archived-At: Cc: bier@ietf.org Subject: Re: [Bier] planning 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: Sun, 01 Feb 2015 09:49:28 -0000 "Cost" might not need to be analysed in a "total dollars" way, but we should be able to give some indications at this stage of the likelihood of changes needed. For example: - minor mod to software that can be performed incrementally - mod to all software in the network - hardware upgrade at the network edges - hardware upgrade across the whole network This *does* require an understanding of the direction of the solution, but not of the fine details of the solution. In many ways this situation is analogous to the introduction of MPLS a few years ago. And without knowing the exact mechanisms involved, we can have an idea of how this will roll out into existing networks. Certainly, this type of question is something that exercises the IETF when considering new technology, especially at the lower layers. On the other hand, Joel, you need to understand that this work is currently being proposed as Experimental. In that context, one of the outputs of the experiment could be the answer to these questions. Adrian > -----Original Message----- > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 31 January 2015 21:10 > To: Greg Shepherd > Cc: bier@ietf.org > Subject: Re: [Bier] planning > > I do not know what draft it belongs in. I named those two drafts > because they, plus the architectural draft (which also seems the wrong > place) are the ones I have available to understand the question. > > While the details of the solution are still subject to debate, there is > as far as I can tell general agreement on the shape of the solution we > want to work on. Which is, I think, a good thing. > > From my experience, without some discussion of how the costs relate to > the benefits, the IESG is likely to have significant difficulty > chartering work with a known high deployment cost. Maybe we can get > this chartered anyway? > > Yours, > Joel > > On 1/31/15 3:34 PM, Greg Shepherd wrote: > > A cost analysis of any solution must include a description of the solution. This > certainly does not belong in a problem statement draft. > > > > Sent from my iPhone > > > >> On Jan 31, 2015, at 12:01, "Joel M. Halpern" wrote: > >> > >> I have read the latest versions of the BIER problem statement and BEIR use > case drafts. > >> > >> I am still looking for a document that discusses (and preferably answers, but at > least discusses) the cost of introducing a new data plane to address the > problems, and the net benefit from doing so. > >> I expect that the introduction of BIER can be justified. But I can not find where > this is discussed. > >> > >> Yours, > >> Joel > >> > >> _______________________________________________ > >> BIER mailing list > >> BIER@ietf.org > >> https://www.ietf.org/mailman/listinfo/bier > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Mon Feb 2 03:06:12 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3001A00D4 for ; Mon, 2 Feb 2015 03:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ9bbHWxzTtm for ; Mon, 2 Feb 2015 03:06:02 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6A01A00CA for ; Mon, 2 Feb 2015 03:06:02 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id rd3so81048765pab.9 for ; Mon, 02 Feb 2015 03:06:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=dRjoW5s2mUO4OU1D9bmEJ2IcnIrbHaDb1C1CziQUE40=; b=fUzPi8qkKiofEeFjEvDgHmxcteNIf7vjTe3501pMuZgrm8X0z41yiYh64+k3zTb7Jd GLrUIQTX2hWVOFgLvx77ZbRaYQ3oCbH7C/ddSgFN36HWi76eAzzY+6OQQcFz7mNo5c1G CipxUS5xoJkPtgwz5hQ3sXES7AljJOl+FOd3GdjXbFwGHOBMKxdnw1lAHpN+d5AiPYZ4 ycOgk9y3ncOqn+eFN05hZAJFM5DyBFc1LY9eOoUm23Van4o38U1BUjWaKzRaX/+4smwR Y4F54iY9QSixyTLwuETu81GmcR2ptYOWJfVYKp2SmDwaC6JBDLtMZ+lIot/mmxZqlUoW AC9Q== X-Gm-Message-State: ALoCoQnxIDYWlOBbllEXXW5oJBbx0F16NeUVahGsGZHuNNQEBNMAvQwzQXed/y3gTgxUa5YUqXT8 X-Received: by 10.70.88.79 with SMTP id be15mr7145196pdb.126.1422875161529; Mon, 02 Feb 2015 03:06:01 -0800 (PST) MIME-Version: 1.0 Sender: d2@d2consulting.co.uk Received: by 10.70.61.198 with HTTP; Mon, 2 Feb 2015 03:05:41 -0800 (PST) In-Reply-To: References: <20150130204021.30418.24378.idtracker@ietfa.amsl.com> From: "Robinson, Dom" Date: Mon, 2 Feb 2015 11:05:41 +0000 X-Google-Sender-Auth: aS_QR76yYCcxHYdjVIGngRr-8cw Message-ID: To: "Nagendra Kumar Nainar (naikumar)" Content-Type: multipart/alternative; boundary=e89a8ff1c24e903fd8050e18f0d9 Archived-At: Cc: Greg Shepherd , "bier@ietf.org" Subject: Re: [Bier] FW: I-D Action: draft-kumar-bier-use-cases-01.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 11:06:10 -0000 --e89a8ff1c24e903fd8050e18f0d9 Content-Type: text/plain; charset=UTF-8 (Greg - I am not sure if i eventually got allowed to post this - i cant see it in my own inbox although i did receive a mail from the BIER mailer asking me to confirm, which i did.. Perhaps I have to post again: so please see comment below (assuming this makes it) else can you guys perhaps forward my input to the list? Dom On 1 February 2015 at 01:23, Robinson, Dom wrote: > Hi guys - i wonder if it would be worth extending the IPTV section to > embrace content pre-placement in not only IPTV, but OTT and even > big-software update and other such CDN activity: I stay close to IP > Multicast specifically for this use case, and I always think it is > interesting that while live/linear is an obvious Multicast candidate, > pre-placing content in many caches that is known to be 'about to be heavily > requested' is actually an extremely valuable capability - even if it is not > live.... > > Just a thought. > > While i am a n00b to the formality of an IETF draft, if you like i would > be happy to try to extend that IPTV paragraph to try to explain that 'CDN' > focussed use case...? > > Let me know - ill try to contribute before the start of next week.... > > Kind regards > > Dom > > On 30 January 2015 at 21:34, Nagendra Kumar Nainar (naikumar) < > naikumar@cisco.com> wrote: > >> Hi, >> >> Below is the updated version of BIER use case draft. >> >> Please read and share your comments. >> >> Regards, >> Nagendra >> >> >> >> On 1/30/15, 3:40 PM, "internet-drafts@ietf.org" > > >> wrote: >> >> > >> >A New Internet-Draft is available from the on-line Internet-Drafts >> >directories. >> > >> > >> > Title : BIER Use Cases >> > Authors : Nagendra Kumar >> > Rajiv Asati >> > Mach(Guoyi) Chen >> > Xiaohu Xu >> > Andrew Dolganow >> > Tony Przygienda >> > Arkadiy Gulko >> > Filename : draft-kumar-bier-use-cases-01.txt >> > Pages : 11 >> > Date : 2015-01-30 >> > >> >Abstract: >> > Bit Index Explicit Replication (BIER) is an architecture that >> > provides optimal multicast forwarding through a "BIER domain" without >> > requiring intermediate routers to maintain any multicast related per- >> > flow state. BIER also does not require any explicit tree-building >> > protocol for its operation. A multicast data packet enters a BIER >> > domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the >> > BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). >> > The BFIR router adds a BIER header to the packet. The BIER header >> > contains a bit-string in which each bit represents exactly one BFER >> > to forward the packet to. The set of BFERs to which the multicast >> > packet needs to be forwarded is expressed by setting the bits that >> > correspond to those routers in the BIER header. >> > >> > This document describes some of the use-cases for BIER. >> > >> > >> >The IETF datatracker status page for this draft is: >> >https://datatracker.ietf.org/doc/draft-kumar-bier-use-cases/ >> > >> >There's also a htmlized version available at: >> >http://tools.ietf.org/html/draft-kumar-bier-use-cases-01 >> > >> >A diff from the previous version is available at: >> >http://www.ietf.org/rfcdiff?url2=draft-kumar-bier-use-cases-01 >> > >> > >> >Please note that it may take a couple of minutes from the time of >> >submission >> >until the htmlized version and diff are available at tools.ietf.org. >> > >> >Internet-Drafts are also available by anonymous FTP at: >> >ftp://ftp.ietf.org/internet-drafts/ >> > >> >_______________________________________________ >> >I-D-Announce mailing list >> >I-D-Announce@ietf.org >> >https://www.ietf.org/mailman/listinfo/i-d-announce >> >Internet-Draft directories: http://www.ietf.org/shadow.html >> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier >> > > > > -- > Dom Robinson > Co-Founder, Director and Creative Firestarter @ id3as-company ltd > Innovation, Development, Architecture, Strategy > for IT, Cloud and StreamingMedia Projects > uk.linkedin.com/in/domrobinson > > Also Contributing Editor for www.StreamingMedia.com > http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm > -- Dom Robinson Co-Founder, Director and Creative Firestarter @ id3as-company ltd Innovation, Development, Architecture, Strategy for IT, Cloud and StreamingMedia Projects uk.linkedin.com/in/domrobinson Also Contributing Editor for www.StreamingMedia.com http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm --e89a8ff1c24e903fd8050e18f0d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Greg - I am not sure if i eventually got allowed to post = this - i cant see it in my own inbox although i did receive a mail from the= BIER mailer asking me to confirm, which i did..=C2=A0

P= erhaps I have to post again: so please see comment below (assuming this mak= es it) else can you guys perhaps forward my input to the list?
Dom

On 1 February 2015 at 01:23, Robinson, Dom <= ;Dom@id3as.co.uk&g= t; wrote:
Hi guys= - i wonder if it would be worth extending the IPTV section to embrace cont= ent pre-placement in not only IPTV, but OTT and even big-software update an= d other such CDN activity: I stay close to IP Multicast specifically for th= is use case, and I always think it is interesting that while live/linear is= an obvious Multicast candidate, pre-placing content in many caches that is= known to be 'about to be heavily requested' is actually an extreme= ly valuable capability - even if it is not live....

Just= a thought.

While i am a n00b to the formality of = an IETF draft, if you like i would be happy to try to extend that IPTV para= graph to try to explain that 'CDN' focussed use case...?
=
Let me know - ill try to contribute before the start of next= week....

Kind regards=C2=A0

<= div>Dom

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

Below is the updated version of BIER use case draft.

Please read and share your comments.

Regards,
Nagendra



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

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

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



--
Dom Robinson
Co-Founder, Director and Creative Firestarter @ id3as-c= ompany ltd
Innovation, Development, Architecture, Strategy
<= div>for IT, Cloud and StreamingMedia Projects

Also Contributing Editor for=C2=A0www.StreamingMedia.com=



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

Also Contributing Editor for=C2=A0www.StreamingMedia.com
--e89a8ff1c24e903fd8050e18f0d9-- From nobody Mon Feb 2 05:00:26 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2491A039A for ; Mon, 2 Feb 2015 05:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_DBL_ABUSE_REDIR=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 hdAcAVjoMzyc for ; Mon, 2 Feb 2015 05:00:19 -0800 (PST) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA19C1A03A0 for ; Mon, 2 Feb 2015 05:00:18 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id l61so38825044wev.8 for ; Mon, 02 Feb 2015 05:00:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:date:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type; bh=4HtV+KPfX+b0bWfc0/1Di3h2ijofqE+nLQ87GF7Vqrs=; b=fWUSyADBN8qdJzGEAdmCMFq7yDukGVy267YWx0z+rIw1T8ZiEs2HNeziaEjrE0ckha BcALLnzbap/AOy2BADFq/xbkBTOW8TDGk6UpeXJmlrrLea46gYfHA0Y3v0CgX7LUXFKm FPlZy5+I8FVVLRa1DsgSScDpXACSG2/CfKhrw3G5r1/Re969N7nUfmS6TwytYOj2D49j 6YcgncbwNC3msz+y5yk2/ratAxOJdamZlvLjirZYE2peOexhTrsQ+YehuV30pXS2c9F/ 81CeKamBDHo8ZN78oBJBHBR4QR/ZyWR9XXTA3CMcQM2/HZvw60jgFMy+KqPmG/x1LXOs WcoQ== X-Gm-Message-State: ALoCoQm3tldE8kxYyXgtlxqcWAe7FTNRFYMw6C9pPMgkW/RUKdzj8rBQSegFd9N5qJrf4bhta18w X-Received: by 10.194.52.66 with SMTP id r2mr41922074wjo.61.1422882017355; Mon, 02 Feb 2015 05:00:17 -0800 (PST) Received: from [192.168.0.8] (cpc12-brig17-2-0-cust88.3-3.cable.virginm.net. [86.26.134.89]) by mx.google.com with ESMTPSA id kj8sm2382014wjc.29.2015.02.02.05.00.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Feb 2015 05:00:16 -0800 (PST) Sender: "Robinson, Dom" From: Dom Robinson X-Google-Original-From: Dom Robinson Date: Mon, 2 Feb 2015 13:00:14 +0000 To: "=?utf-8?Q?bier=40ietf.org?=" Message-ID: <62A44EE9552A463F9C81E16F620C3B03@d2consulting.co.uk> In-Reply-To: References: <20150130204021.30418.24378.idtracker@ietfa.amsl.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="54cf74de_64af49b_1d2" Archived-At: Cc: "Nagendra Kumar Nainar \(naikumar\)" , IJsbrand Wijnands , Greg Shepherd Subject: Re: [Bier] FW: I-D Action: draft-kumar-bier-use-cases-01.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 13:00:24 -0000 --54cf74de_64af49b_1d2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks Ice / Greg =20 Ok here is my first n00b stab at extending the text. I possibly need to r= ead up on text formatting (use of brackets and terms like =E2=80=98layer4= =E2=80=99) but perhaps let me share this as a way to refine the logic of = what i feel could be included. My key thinking is that we are trying to a= void specifically involving IGMP and MBGP while still =E2=80=98allowing t= hem=E2=80=99 and yet to open up for SDN / application layer control plane= over-lay if a CDN operator wants to build that and still support BIER=E2= =80=A6 < feeling timid among such an esteemed crowd :) > =E2=80=94=E2=80=94 3.3. IPTV, OTT and CDN Services =20 IPTV is a service, well known for its characteristics of allowing both li= ve and on-demand delivery of media traffic over Managed IP networks. =20 =20 Over The Top (OTT) is a similar service, well known for its characteristi= cs of allowing live and on-demand delivery of media traffic between IP do= mains, where the source is often on an external network relative to the r= eceivers. =20 Content Delivery Networks (CDN) operators provide layer 4 applications, a= nd often some degree of managed layer 3 IP network, that enable media to = be securely and reliably delivered to many receivers. In some models they= may place applications within third party networks, or they may place th= ose applications at the edges of their own managed network peerings and s= imilar inter-domain connections. CDNs provide capabilities to help publis= hers scale to meet large audience demand. Their applications are not limi= ted to audio and video delivery, but may include static and dynamic web c= ontent, or optimized delivery for Massive Multiplayer Gaming and similar.= Most publishers will use a CDN for public Internet delivery, and some pu= blishers will use a CDN internally within their IPTV networks to resolve = layer 4 complexity. =20 =20 In a typical IPTV environment the egress routers connecting to the receiv= ers will build the tree towards the ingress router connecting to the IPTV= servers. The egress routers would rely on IGMP/MLD (static or dynamic) = to learn about the receiver's interest in one or more multicast group/cha= nnels. Interestingly, BIER could allows provisioning any new multicast g= roup/channel by only modifying the channel mapping on ingress routers. T= his is deemed beneficial for the linear IPTV video broadcasting in which = every receivers behind every egress PE routers would receive the IPTV vid= eo traffic. =20 With BIER, there is no need of tree building from egress to ingress. =46u= rther, any addition of new channel or new egress routers can be directly = controlled from ingress router. When a new channel is included, the mult= icast group is mapped to Bit string that includes all egress routers. In= gress router would start sending the new channel and deliver it to all eg= ress routers. As it can be observed, there is no need for static IGMP pr= ovisioning in each egress routers whenever a new channel/stream is added.= Instead, it can be controlled from ingress router itself by configuring= the new group to Bit Mask mapping on ingress router. =20 In OTT services the receivers will often be on remote domains. These rece= ivers may connect to the egress routers of a managed CDN that supports BI= ER. This will enable the CDN to efficiently deliver the content to many e= gress locations, in turn providing internal optimization. =20 =20 Where these egress routers connect directly to the Ingress BIER routers o= f downstream domains then a continuity of the scaling that BIER offers co= uld be provided. This may rely on MBGP interoperation (or similar) betwee= n the egress of one domain and the ingress of the next domain, or some ot= her SDN control plane may prove a more effective and simpler way to deplo= y BIER. =46or a single CDN operator this could be well managed in the Lay= er 4 applications that they provide and it may be that the initial receiv= er in a remote domain is actually an application operated by the CDN whic= h in turn acts as a source for the Ingress BIER router in that remote dom= ain, and by doing so keeps the BIER more descrete on a domain by domain b= asis. --- =20 Looking forward to learning (a lot) from the feedback=21 Hope it is useful=E2=80=A6 Dom Co-=46ounder, Director and Creative =46irestarter =40 id3as-company ltd Innovation, Development, Architecture, Strategy for IT, Cloud and StreamingMedia Projects http://www.linkedin.com/in/domrobinson Contributing Editor for StreamingMedia http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm Book out now on Wiley.com =E2=80=9CAdvanced Content Delivery, Streaming, = and Cloud Services=E2=80=9D : http://bit.ly/1r1ttEG (http://eu.wiley.com/= WileyCDA/WileyTitle/productCd-1118575210,descCd-buy.html=3Fdmmspid=3D2552= 6142&dmmsmid=3D88793&dmmsuid=3D2334962) On Monday, 2 =46ebruary 2015 at 11:55, IJsbrand Wijnands wrote: > Hi Dom, > =20 > Your email made it to the list just fine. > =20 > I think your use-case makes sense. Since the content is driven from the= source side, the operator can just identify the CDN=E2=80=99s and push t= he content to it. What is nice is that you don=E2=80=99t need to make the= CDN=E2=80=99s pre-join a multicast tree in order to push the data to it.= There could also be a nice SDN user interface to it as well :-) > =20 > Why don=E2=80=99t you go ahead with preparing the text and we=E2=80=99l= l add the content with you as co-author, ok=3F > =20 > Thx, > =20 > Ice. > =20 > > On 02 =46eb 2015, at 12:05, Robinson, Dom wrote: > > (Greg - I am not sure if i eventually got allowed to post this - i ca= nt see it in my own inbox although i did receive a mail from the BIER mai= ler asking me to confirm, which i did.. =20 > > =20 > > Perhaps I have to post again: so please see comment below (assuming t= his makes it) else can you guys perhaps forward my input to the list=3F > > =20 > > Dom > > =20 > > On 1 =46ebruary 2015 at 01:23, Robinson, Dom wrote: > > > Hi guys - i wonder if it would be worth extending the IPTV section = to embrace content pre-placement in not only IPTV, but OTT and even big-s= oftware update and other such CDN activity: I stay close to IP Multicast = specifically for this use case, and I always think it is interesting that= while live/linear is an obvious Multicast candidate, pre-placing content= in many caches that is known to be 'about to be heavily requested' is ac= tually an extremely valuable capability - even if it is not live.... > > > =20 > > > Just a thought. > > > =20 > > > While i am a n00b to the formality of an IET=46 draft, if you like = i would be happy to try to extend that IPTV paragraph to try to explain t= hat 'CDN' focussed use case...=3F > > > =20 > > > Let me know - ill try to contribute before the start of next week..= .. > > > =20 > > > Kind regards =20 > > > =20 > > > Dom > > > =20 > > > On 30 January 2015 at 21:34, Nagendra Kumar Nainar (naikumar) wrote: > > > > Hi, > > > > =20 > > > > Below is the updated version of BIER use case draft. > > > > =20 > > > > Please read and share your comments. > > > > =20 > > > > Regards, > > > > Nagendra > > > > =20 > > > > =20 > > > > =20 > > > > On 1/30/15, 3:40 PM, =22internet-drafts=40ietf.org (mailto:intern= et-drafts=40ietf.org)=22 > > > > wrote: > > > > =20 > > > > > > > > > >A New Internet-Draft is available from the on-line Internet-Draf= ts > > > > >directories. > > > > > > > > > > > > > > > Title : BIER Use Cases > > > > > Authors : Nagendra Kumar > > > > > Rajiv Asati > > > > > Mach(Guoyi) Chen > > > > > Xiaohu Xu > > > > > Andrew Dolganow > > > > > Tony Przygienda > > > > > Arkadiy Gulko > > > > > =46ilename : draft-kumar-bier-use-cases-01.txt > > > > > Pages : 11 > > > > > Date : 2015-01-30 > > > > > > > > > >Abstract: > > > > > Bit Index Explicit Replication (BIER) is an architecture that= > > > > > provides optimal multicast forwarding through a =22BIER domai= n=22 without > > > > > requiring intermediate routers to maintain any multicast rela= ted per- > > > > > flow state. BIER also does not require any explicit tree-bui= lding > > > > > protocol for its operation. A multicast data packet enters a= BIER > > > > > domain at a =22Bit-=46orwarding Ingress Router=22 (B=46IR), a= nd leaves the > > > > > BIER domain at one or more =22Bit-=46orwarding Egress Routers= =22 (B=46ERs). > > > > > The B=46IR router adds a BIER header to the packet. The BIER= header > > > > > contains a bit-string in which each bit represents exactly on= e B=46ER > > > > > to forward the packet to. The set of B=46ERs to which the mu= lticast > > > > > packet needs to be forwarded is expressed by setting the bits= that > > > > > correspond to those routers in the BIER header. > > > > > > > > > > This document describes some of the use-cases for BIER. > > > > > > > > > > > > > > >The IET=46 datatracker status page for this draft is: > > > > >https://datatracker.ietf.org/doc/draft-kumar-bier-use-cases/ > > > > > > > > > >There's also a htmlized version available at: > > > > >http://tools.ietf.org/html/draft-kumar-bier-use-cases-01 > > > > > > > > > >A diff from the previous version is available at: > > > > >http://www.ietf.org/rfcdiff=3Furl2=3Ddraft-kumar-bier-use-cases-= 01 > > > > > > > > > > > > > > >Please note that it may take a couple of minutes from the time o= f > > > > >submission > > > > >until the htmlized version and diff are available at tools.ietf.= org (http://tools.ietf.org/). > > > > > > > > > >Internet-Drafts are also available by anonymous =46TP at: > > > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > > > >I-D-Announce mailing list > > > > >I-D-Announce=40ietf.org (mailto:I-D-Announce=40ietf.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 > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > > > BIER mailing list > > > > BIER=40ietf.org (mailto:BIER=40ietf.org) > > > > https://www.ietf.org/mailman/listinfo/bier > > > =20 > > > =20 > > > =20 > > > -- =20 > > > Dom Robinson > > > Co-=46ounder, Director and Creative =46irestarter =40 id3as-company= ltd > > > Innovation, Development, Architecture, Strategy > > > for IT, Cloud and StreamingMedia Projects > > > uk.linkedin.com/in/domrobinson (http://uk.linkedin.com/in/domrobins= on) > > > =20 > > > Also Contributing Editor for www.StreamingMedia.com (http://www.str= eamingmedia.com/) > > > http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm > > > =20 > > > =20 > > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > -- =20 > > Dom Robinson > > Co-=46ounder, Director and Creative =46irestarter =40 id3as-company l= td > > Innovation, Development, Architecture, Strategy > > for IT, Cloud and StreamingMedia Projects > > uk.linkedin.com/in/domrobinson (http://uk.linkedin.com/in/domrobinson= ) > > =20 > > Also Contributing Editor for www.StreamingMedia.com (http://www.strea= mingmedia.com/) > > http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm > > =20 > > =20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > BIER mailing list > > BIER=40ietf.org (mailto:BIER=40ietf.org) > > https://www.ietf.org/mailman/listinfo/bier > =20 --54cf74de_64af49b_1d2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thanks Ice / Greg

Ok here is my first n00b stab a= t extending the text. I possibly need to read up on text formatting (use = of brackets and terms like =E2=80=98layer4=E2=80=99) but perhaps let me s= hare this as a way to refine the logic of what i feel could be included. = My key thinking is that we are trying to avoid specifically involving IGM= P and MBGP while still =E2=80=98allowing them=E2=80=99 and yet to open up= for SDN / application layer control plane over-lay if a CDN operator wan= ts to build that and still support BIER=E2=80=A6

< feeling timid among such an esteemed crowd :) >

=E2=80=94=E2=80=94

<=21--=5Bif gte mso 9=5D> 0 0 1 519 2961 id3as-company ltd 24 6 3474 14.0 <=21=5Bendif=5D--> <=21--=5Bif gte mso 9=5D> Normal 0 false false false EN-US JA X-NONE <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--> <=21--=5Bif gte mso 10=5D> <=21=5Bendif=5D--> <=21--Start=46ragment-->

3.3.  IPTV, OTT and CDN Services

IPTV is a service, well known for its characteristics of allowing both live and on-demand delivery of media tra= ffic over Managed IP networks.

 

Over The Top (OTT) is a similar= service, well known for its characteristics of allowing live and on-deman= d delivery of media traffic between IP domains, where the source is often o= n an external network relative to the receivers.

 

Content Delivery Networks (CDN)= operators provide layer 4 applications, and often some degree of managed = layer 3 IP network, that enable media to be securely and reliably delivered to = many receivers. In some models they may place applications within third party networks, or they may place those applications at the edges of their own managed network peerings and similar inter-domain connections. CDNs provi= de capabilities to help publishers scale to meet large audience demand. Thei= r applications are not limited to audio and video delivery, but may include= static and dynamic web content, or optimized delivery for Massive Multipl= ayer Gaming and similar. Most publishers will use a CDN for public Internet delivery, and some publishers will use a CDN internally within their IPTV= networks to resolve layer 4 complexity.

 

 

In a typical IPTV environment the egress = routers connecting to the receivers will build the tree towards the ingress route= r connecting to the IPTV servers.  The egress routers would rely on IGMP/MLD (static or dynamic) to learn about = the receiver's interest in one or more multicast group/channels.  Intere= stingly, BIER could allows provisioning any new multicast group/channel by only modifying the channel mapping on ingress routers.  This is deemed beneficial for the linear IPTV video broadcasting in which every receiver= s behind every egress PE routers would receive the IPTV video traffic.=

 

With BIER, there is no need of tree build= ing from egress to ingress. =46urther, any addition of new channel or new egress r= outers can be directly controlled from ingress router.  When a new channel is included, the multicast group is mapped to Bit string that includes all egress routers.  Ingress router would start sending the new channel and deliver it to all egress routers.  As it can be observed, there is no need for static IGMP provisioning in each egress routers when= ever a new channel/stream is added.  Instead, it can be controlled from ingress router itself by configuring the new group= to Bit Mask mapping on ingress router.

 

In OTT services the receivers w= ill often be on remote domains. These receivers may connect to the egress rou= ters of a managed CDN that supports BIER. This will enable the CDN to efficien= tly deliver the content to many egress locations, in turn providing internal = optimization.

 

Where these egress routers conn= ect directly to the Ingress BIER routers of downstream domains then a continu= ity of the scaling that BIER offers could be provided. This may rely on MBGP interoperation (or similar) between the egress of one domain and the ingr= ess of the next domain, or some other SDN control plane may prove a more effecti= ve and simpler way to deploy BIER. =46or a single CDN operator this could be wel= l managed in the Layer 4 applications that they provide and it may be that = the initial receiver in a remote domain is actually an application operated b= y the CDN which in turn acts as a source for the Ingress BIER router in that re= mote domain, and by doing so keeps the BIER more descrete on a domain by domai= n basis.


---

<=21--End=46ragment-->

Looking forward to learning (a l= ot) from the feedback=21

Hope it is useful=E2=80= =A6

Dom

Co-=46ounder, = Director and Creative =46irestarter =40 id3as-company ltd
Innovation, Development, Architecture, St= rategy
for IT, Cloud and S= treamingMedia Projects
http= ://www.linkedin.com/in/domrobinson

<= /div>
Book out now on Wiley.com =E2=80=9CA= dvanced Content Delivery, Streaming, and Cloud Services=E2=80=9D :=  http://bit.ly/1r1ttEG

=20

On Monday, 2 =46ebruar= y 2015 at 11:55, IJsbrand Wijnands wrote:

Hi Dom,

You= r email made it to the list just fine.

I think y= our use-case makes sense. Since the content is driven from the source sid= e, the operator can just identify the CDN=E2=80=99s and push the content = to it. What is nice is that you don=E2=80=99t need to make the CDN=E2=80=99= s pre-join a multicast tree in order to push the data to it. There could = also be a nice SDN user interface to it as well :-)

<= div>Why don=E2=80=99t you go ahead with preparing the text and we=E2=80=99= ll add the content with you as co-author, ok=3F

= Thx,

Ice.

On 02 =46eb 2015, at 12:05, Robinson, Dom <Dom=40id3as.co.uk> wrote:
=
(Greg - I am not sure if i eventual= ly got allowed to post this - i cant see it in my own inbox although i di= d receive a mail from the BIER mailer asking me to confirm, which i did..=  

Perhaps I have to post again: so please see com= ment below (assuming this makes it) else can you guys perhaps forward my = input to the list=3F

Dom

On 1 =46ebruary 2015 at 01:23, Robinson, Dom <= Dom=40id= 3as.co.uk> wrote:
Hi guys - i wonder if it would be worth extending the I= PTV section to embrace content pre-placement in not only IPTV, but OTT an= d even big-software update and other such CDN activity: I stay close to I= P Multicast specifically for this use case, and I always think it is inte= resting that while live/linear is an obvious Multicast candidate, pre-pla= cing content in many caches that is known to be 'about to be heavily requ= ested' is actually an extremely valuable capability - even if it is not l= ive....

Just a thought.

While= i am a n00b to the formality of an IET=46 draft, if you like i would be = happy to try to extend that IPTV paragraph to try to explain that 'CDN' f= ocussed use case...=3F

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

Kin= d regards 

Dom
On 30 January 2015 at 21:34, Nagendra Kumar Nainar (naikumar) <naikumar=40cisco.com> wrote:
Hi,

Below is the updated version of BIER use case draft.

Please read and share your comments.

Regards,
Nagendra



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

>
>A New Internet-Draft is available from the on-line Internet-Drafts >directories.
>
>
>        Title          &= nbsp;: BIER Use Cases
>        Authors         = : Nagendra Kumar
>                   =       Rajiv Asati
>                   =       Mach(Guoyi) Chen
>                   =       Xiaohu Xu
>                   =       Andrew Dolganow
>                   =       Tony Przygienda
>                   =       Arkadiy Gulko
>       =46ilename        : dr= aft-kumar-bier-use-cases-01.txt
>       Pages          &n= bsp;: 11
>       Date          &nb= sp; : 2015-01-30
>
>Abstract:
>   Bit Index Explicit Replication (BIER) is an architecture= that
>   provides optimal multicast forwarding through a =22BIER = domain=22 without
>   requiring intermediate routers to maintain any multicast= related per-
>   flow state.  BIER also does not require any explici= t tree-building
>   protocol for its operation.  A multicast data packe= t enters a BIER
>   domain at a =22Bit-=46orwarding Ingress Router=22 (B=46I= R), and leaves the
>   BIER domain at one or more =22Bit-=46orwarding Egress Ro= uters=22 (B=46ERs).
>   The B=46IR router adds a BIER header to the packet. = ; The BIER header
>   contains a bit-string in which each bit represents exact= ly one B=46ER
>   to forward the packet to.  The set of B=46ERs to wh= ich the multicast
>   packet needs to be forwarded is expressed by setting the= bits that
>   correspond to those routers in the BIER header.
>
>   This document describes some of the use-cases for BIER.<= br> >
>
>The IET=46 datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ku= mar-bier-use-cases/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-kumar-bier-u= se-cases-01
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff=3Furl2=3D= draft-kumar-bier-use-cases-01
>
>
>Please note that it may take a couple of minutes from the time of
= >submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous =46TP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<= br> >I-D-Announce mailing list
>I-D-Announce=40ietf.org
>https://www.ietf.org/mailman/listinfo/i-d-announce<= /a>
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
BIER mailing list
BIER=40iet= f.org
https://www.ietf.org/mailman/listinfo/bier



<= /div>--
<= /span>Dom Robinson
Co-=46ounder, Director and Creative =46irestarter = =40 id3as-company ltd
Innovation, Development, Architecture, St= rategy
for IT, Cloud and StreamingMedia Projects

Also Contrib= uting Editor for www.StreamingMedia.com



--
=
Dom Robinson
Co-=46ounder, Director an= d Creative =46irestarter =40 id3as-company ltd
Innovation, Deve= lopment, Architecture, Strategy
for IT, Cloud and StreamingMedi= a Projects
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
BIE= R mailing list
BIER=40ietf.org<= /a>
https:/= /www.ietf.org/mailman/listinfo/bier

 =20 =20 =20 =20
=20

--54cf74de_64af49b_1d2-- From nobody Mon Feb 2 06:17:41 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801E11A1A30 for ; Mon, 2 Feb 2015 06:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK2aYES3NFmd for ; Mon, 2 Feb 2015 06:17:36 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724701A1A6E for ; Mon, 2 Feb 2015 06:15:13 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id y19so38938755wgg.11 for ; Mon, 02 Feb 2015 06:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fN2rp17efzTzV4rE4KVa5cznc00YaTeknMfpxzO6WHw=; b=CS0zKX00rI/RBCLXDIV1nz8Qcpchyf6dOmXxLRu8kLxlpHrBVZ/RFril2HSW8LfB4K Gk/j5BR9qSdmKX+D3l1W3VVoGUIM5hCm+hi83UAQapKy0UVrYkKEuYpEkbUCfhAC+ZO1 UzI1oEv2n666cbJq5B2hP9d3cBI226380Oa5IT5/PLZPGE6x1r4ccnpB8uFmKXAK2LaK ZpRdBiYECCAHMDZYeS2P6WqDpa9Bp8YAyxlf7dmezh/oMH7kmnzoXkTZPS9wQu5/d0ST CnJnTBcn4ZJSusvBoldF9NXvs8XjEK6mC295uFmGMu9ItHrJZY+BA2ZA9Yoc48xNNc9K Lolw== MIME-Version: 1.0 X-Received: by 10.180.20.238 with SMTP id q14mr17849573wie.51.1422886512265; Mon, 02 Feb 2015 06:15:12 -0800 (PST) Received: by 10.180.207.180 with HTTP; Mon, 2 Feb 2015 06:15:12 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Feb 2015 06:15:12 -0800 Message-ID: From: Greg Shepherd To: Alia Atlas Content-Type: multipart/alternative; boundary=bcaec53f34471e902e050e1b9509 Archived-At: Cc: "bier@ietf.org" Subject: Re: [Bier] BOF deadline approaching X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 14:17:38 -0000 --bcaec53f34471e902e050e1b9509 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 30, 2015 at 11:30 PM, Greg Shepherd wrote: > On Tue, Jan 27, 2015 at 4:07 PM, Alia Atlas wrote: > >> I am still waiting to see an updated problem-statement and use-cases. >> > > Posted > > >> I would strongly encourage making a BoF request - working group forming; >> > > I made a request for a slot last week. My view in the tools has BIER as an > option - possibly a placeholder for a pending WG formation, I'm not sure. > Can you confirm that this request is sufficient to allocate a slot for > BIER, BoF or WG, or if I need to also make a request for a BIER BoF? > Any clarity on the schedule request? > >> it isn't clear to me that there will be sufficient progress before Dallas >> to be >> certain of agreeing on a charter. >> > In our interim meeting we targeted the end of Jan for both the Problem Statement and the Use Cases draft - both of which were rev'd and published on target. What other progress do we need to pursue? I'm working on a draft charter now and hope to have something to review this week. Thanks for your help, Greg > >> > Putting in a BoF request, assuming it is approved of course, makes sure >> that there is meeting time scheduled. >> >> The deadlne is Feb 6. >> >> Regards, >> Alia >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier >> >> > --bcaec53f34471e902e050e1b9509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 30, 2015 at 11:30 PM, Greg Shepherd <gjshep@g= mail.com> wrote:
On Tue, Jan 27, 2015 at 4:07 PM, Alia Atlas <akatlas@gmail.com><= /span> wrote:
I am st= ill waiting to see an updated problem-statement and use-cases.

Posted
=C2=A0
I would strongly e= ncourage making a BoF request - working group forming;

I made a request for a slot last week. My vi= ew in the tools has BIER as an option - possibly a placeholder for a pendin= g WG formation, I'm not sure. Can you confirm that this request is suff= icient to allocate a slot for BIER, BoF or WG, or if I need to also make a = request for a BIER BoF?

=
Any clarity on the schedule request?

=C2=A0
it isn't clear to me that there will be suffi= cient progress before Dallas to be
certain of agreeing on a chart= er.

=
In our interim meeting we targeted the end of Jan for both the P= roblem Statement and the Use Cases draft - both of which were rev'd and= published on target. What other progress do we need to pursue?
<= br>
I'm working on a draft charter now and hope to have somet= hing to review this week.

Thanks for your help,
Greg
=C2=A0
=C2=A0
Putting in a BoF request, assuming it is= approved of course, makes sure
that there is meeting time schedu= led.

The deadlne is Feb 6.

Regards,
Alia

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



--bcaec53f34471e902e050e1b9509-- From nobody Mon Feb 2 08:36:14 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686951A872B for ; Mon, 2 Feb 2015 08:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwAMEDdgcg0V for ; Mon, 2 Feb 2015 08:36:09 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B2A1A8733 for ; Mon, 2 Feb 2015 08:35:24 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 1DAE9FFE9A911 for ; Mon, 2 Feb 2015 16:35:18 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t12GZJNH013614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Feb 2015 11:35:19 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 11:35:19 -0500 From: "Dolganow, Andrew (Andrew)" To: "gjshep@gmail.com" , "bier@ietf.org" Thread-Topic: [Bier] Upcoming milestones Thread-Index: AQHQPwY7GVotnf3sukW5yYYHnqTR2w== Date: Mon, 2 Feb 2015 16:35:18 +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.7.141117 x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_D0F50ED867B49andrewdolganowalcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Bier] Upcoming milestones X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 16:36:11 -0000 --_000_D0F50ED867B49andrewdolganowalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable inline On 2015-01-21, 7:24 PM, "Greg Shepherd" wrote: This is taken from the notes in our interim call last year. I've included m= ilestones which are still open. Other drafts are on track (thanks!) and hav= e been omitted here. ---------- problem statement; Author - Greg - confirmed Andrew to contribute more. next-revision - Jan 31. Andrew, Ron, if you have proposed text please forward to me soon, thanks! I will send you some comments, text today. uses-case draft: Editor; Ice - Interim. :Do we have an official owner of this draft? TonyP EVPN use case - Early Jan: Some has come in, thanks. Albert LISP - early Jan - :? Andrew - highlight BIER advantages. : Any text yet Andrew? Yes, the text is there in the latest draft. Andrew Ron - deployments and migration : Ron? ospf; Author; peter next revision before Dallas Call for adoption Dallas LC 2015 isis; Author; tony next revision early Feb. Call for adoption Dallas LC 2015 Tony - adopt changes to [sub]domain in arch draft new draft for deployment and migration. Ice, Albert, Jeffery, Andrew, Greg not to pollute the arch draft. how to cope with multiple bit-mask sizes how to mitigate non-BIER supporting routers. GS - any work on this to share? compression drafts; Author - Albert. request for comments. Charter Discussion Authors - Greg, Eric, Andrew, Tony. Reviewers - Ross, Wim. first revision - end of Jan 2014. GS - end is near. I'll request a timeslot in Dallas whether it's an officia= l WG or our second BoF. But we need to keep the ball moving either way. Thanks!, Greg --_000_D0F50ED867B49andrewdolganowalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <24AAD2E17FF5F444968A8EF8871B2E09@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
inline

On 2015-01-21, 7:24 PM, "Greg Shepherd" wrote:

This is taken from the notes in our interim call last year. I= 've included milestones which are still open. Other drafts are on track (th= anks!) and have been omitted here.

----------

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

I will send you some comments, text today.


=
=
uses-case draft:
Edito= r; Ice - Interim. :Do we have an official owner of this draft?
= TonyP EVPN use case - Early Jan:  Some has come in, thanks.
= Albert LISP - early Jan - :?
Andre= w - highlight BIER advantages. : Any text= yet Andrew?

Yes, the text is there in the latest draft.

Andrew

Ron -= deployments and migration : Ron?

= ospf;
Autho= r; peter
next = revision before Dallas
Call = for adoption Dallas
LC 20= 15

isis;=
Autho= r; tony
next = revision early Feb.
Call = for adoption Dallas
LC 20= 15
Tony = - adopt changes to [sub]domain in arch draft
=
= new draft for deployment and migration.
Ice, = Albert, Jeffery, Andrew, Greg
not t= o pollute the arch draft.
how t= o cope with multiple bit-mask sizes
how t= o mitigate non-BIER supporting routers.=
GS - any work on this to share? 

compr= ession drafts;
Autho= r - Albert.
reque= st for comments.

Chart= er Discussion
Autho= rs - Greg, Eric, Andrew, Tony.
Revie= wers - Ross, Wim.
first= revision - end of Jan 2014.
GS - end is near. I'll request a timeslot in Dallas whether it's a= n official WG or our second BoF. But we need to keep the ball moving e= ither way.

Thanks!,
Greg
 --_000_D0F50ED867B49andrewdolganowalcatellucentcom_-- From nobody Mon Feb 2 08:53:35 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74041A802D for ; Mon, 2 Feb 2015 08:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Xvj1wQwfrDr for ; Mon, 2 Feb 2015 08:53:26 -0800 (PST) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC5C1A1AFB for ; Mon, 2 Feb 2015 08:53:26 -0800 (PST) Received: by mail-yh0-f49.google.com with SMTP id v1so16387981yhn.8 for ; Mon, 02 Feb 2015 08:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nj4wMFJrYyRd9lJ/I5Cl0l87FHuJKa3a5p3h1oW+794=; b=X7Rot8G/YVQPssHCMlJxbRubtoPtU/MDB77bku0kI2ILSD5lARxVHj9MkKsasQPh4I gi4TzWlUWxctQ91Icpd+H6sajfxVd2CLPUXVpO8mYI6h4X8fMxFG2e0LlG9HoLMFun3U o7zzTBxJUPMZrb8z9dLw8c75GfcbzqN8kNGzgrMduhBQha5cXXcjWgmELuOkbjh0zYAW HmdyD/z5aj0b2JjqlXp3BYWQucxQ1axvgZk2KAs0dCYvJD4QloWBa8U0EGRz3YNwQ73A znA2fyYXLNq9SgA0CLuAJQDqQDqHUALPGURvRHAZPQZS02tID5QUw1sWG74dG9GK/RDo m+mw== MIME-Version: 1.0 X-Received: by 10.236.203.108 with SMTP id e72mr8864522yho.48.1422896005616; Mon, 02 Feb 2015 08:53:25 -0800 (PST) Received: by 10.170.133.80 with HTTP; Mon, 2 Feb 2015 08:53:25 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Feb 2015 11:53:25 -0500 Message-ID: From: Alia Atlas To: Greg Shepherd Content-Type: multipart/alternative; boundary=089e0160b506f798d2050e1dca14 Archived-At: Cc: "bier@ietf.org" Subject: Re: [Bier] BOF deadline approaching X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 16:53:30 -0000 --089e0160b506f798d2050e1dca14 Content-Type: text/plain; charset=UTF-8 Hi Greg, On Mon, Feb 2, 2015 at 9:15 AM, Greg Shepherd wrote: > On Fri, Jan 30, 2015 at 11:30 PM, Greg Shepherd wrote: > >> On Tue, Jan 27, 2015 at 4:07 PM, Alia Atlas wrote: >> >>> I am still waiting to see an updated problem-statement and use-cases. >>> >> >> Posted >> >> >>> I would strongly encourage making a BoF request - working group forming; >>> >> >> I made a request for a slot last week. My view in the tools has BIER as >> an option - possibly a placeholder for a pending WG formation, I'm not >> sure. Can you confirm that this request is sufficient to allocate a slot >> for BIER, BoF or WG, or if I need to also make a request for a BIER BoF? >> > > Any clarity on the schedule request? > I do see the request in the sessions - but am not sure that'll work since bier isn't a WG. I did put a placeholder on the BOF page. > it isn't clear to me that there will be sufficient progress before Dallas >>> to be >>> certain of agreeing on a charter. >>> >> > In our interim meeting we targeted the end of Jan for both the Problem > Statement and the Use Cases draft - both of which were rev'd and published > on target. What other progress do we need to pursue? > I am certainly happy to see the work progressing on schedule. That's a good sign. I intend to review these drafts this week. I really want to have a clear discussion of the deployment costs vs benefits of the technology; does BIER enable new capabilities due to scale changes? Again - I haven't read the updated problem statement yet so I hope this is there. > I'm working on a draft charter now and hope to have something to review > this week. > I'm certainly happy to see a draft charter. Do be aware that it will likely be tightened up and focused on defining the solution. Thanks, Alia > Thanks for your help, > Greg > > >> >>> >> Putting in a BoF request, assuming it is approved of course, makes sure >>> that there is meeting time scheduled. >>> >>> The deadlne is Feb 6. >>> >>> Regards, >>> Alia >>> >>> _______________________________________________ >>> BIER mailing list >>> BIER@ietf.org >>> https://www.ietf.org/mailman/listinfo/bier >>> >>> >> > --089e0160b506f798d2050e1dca14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

On Mon, Feb 2, 2015 at 9:15 AM, Greg Shepherd <gjshep@gmail.com= > wrote:
<= span class=3D"">On Fri, Jan 30, 2015 at 11:30 PM, Greg Shepherd <gjshep@g= mail.com> wrote:
On Tue, Jan 27, 2015 at 4:07 PM, Alia Atlas <akatlas@gmail= .com> wrote:
I am= still waiting to see an updated problem-statement and use-cases.

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

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

<= div>Any clarity on the schedule request?

I do see the request in the sessions - but am not sur= e that'll work since bier isn't a WG.=C2=A0
I did put a p= laceholder on the BOF page.
=C2=A0
it isn't clear to me that there will be s= ufficient progress before Dallas to be
certain of agreeing on a c= harter.
=
In our interim meeting we targeted the end of Jan for= both the Problem Statement and the Use Cases draft - both of which were re= v'd and published on target. What other progress do we need to pursue?<= /div>

I am certainly happ= y to see the work progressing on schedule.=C2=A0 That's a good sign.=C2= =A0 I intend to review these
drafts this week.=C2=A0 I really wan= t to have a clear discussion of the deployment costs vs benefits of the tec= hnology;
does BIER enable new capabilities due to scale changes?= =C2=A0 Again - I haven't read the updated problem statement yet
so I hope this is there.=C2=A0
=C2=A0
I'm working on a draft charter now and hope t= o have something to review this week.
<= div>
I'm certainly happy to see a draft charter.=C2=A0 Do= be aware that it will likely be tightened up and focused on defining
=
the solution.

Thanks,
Alia
=C2=A0
Thanks for your help,
Greg
=C2=A0
=C2=A0
<= /div>
Putting in a BoF request, assuming it is approved of co= urse, makes sure
that there is meeting time scheduled.
=
The deadlne is Feb 6.

Regards,
Alia

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




--089e0160b506f798d2050e1dca14-- From nobody Mon Feb 2 08:56:28 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CD71A8708 for ; Mon, 2 Feb 2015 08:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2KRVOeUQ_Yf for ; Mon, 2 Feb 2015 08:56:23 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B811A03A5 for ; Mon, 2 Feb 2015 08:56:23 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-f1-54cf4ce0b7d3 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 27.33.25146.0EC4FC45; Mon, 2 Feb 2015 11:09:37 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Mon, 2 Feb 2015 11:56:22 -0500 From: Antoni Przygienda To: "bier@ietf.org" Thread-Topic: New Version Notification for draft-przygienda-bier-isis-ranges-02.txt Thread-Index: AQHQPu9tK1qQsy7d20GNQa12rTg9d5zdlFWg Date: Mon, 2 Feb 2015 16:56:21 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F18236532@eusaamb103.ericsson.se> References: <20150202135155.30530.90655.idtracker@ietfa.amsl.com> In-Reply-To: <20150202135155.30530.90655.idtracker@ietfa.amsl.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyuXRPiO5Dn/MhBhvzLJbO2MPkwOixZMlP pgDGKC6blNSczLLUIn27BK6M7v0LmQr28VQ0df9iaWCcwtPFyMkhIWAi8eXyVkYIW0ziwr31 bF2MXBxCAkcYJb7dOsAE4SxjlJjct4gNpIpNwELi8renzCC2iICyxPlDjewgtrBAiMTs+UtY IeKhEkt+LGWHsI0kDm/vANvAIqAi8XHyMRYQm1fAW+Lq7PVgNUICjhLNh4+B2ZwCThKHmm8y gdiMQBd9P7UGzGYWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/scKYStJfPw9H2gOB1C9psT6XfoQ rYoSU7ofskOsFZQ4OfMJywRG0VlIps5C6JiFpGMWko4FjCyrGDlKi1PLctONDDcxAoP+mASb 4w7GBZ8sDzEKcDAq8fB+WH8uRIg1say4MvcQozQHi5I4b9mVgyFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGC3WHZ/Hn/030UEvgvWX7XmbTu6a8iDOs2e1zCoKwvmlJZq4nu95s0+P0Vvl q/Vpg0sBX/t3CZdOv7nIQurYpduP0gyKp9w/3W1udVgx9JVw6FqlLSzGTj/npj5JVgsOLVyu vZAlo8axOclI/MMk77YVJUH2Hmx6q2duevlFP0XKeK3khRUTlFiKMxINtZiLihMBw0C981sC AAA= Archived-At: Subject: [Bier] FW: New Version Notification for draft-przygienda-bier-isis-ranges-02.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, 02 Feb 2015 16:56:25 -0000 Zm9yIGdlbmVyYWwgY29uc3VtcHRpb24uIGNvbW1lbnRzIGFwcHJlY2lhdGVkLiB0aGFua3MuIHRv bnkgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5 LCBGZWJydWFyeSAwMiwgMjAxNSA1OjUyIEFNDQpUbzogSmVmZnJleSBaaGFuZzsgU2FtIEFsZHJp bjsgQW50b25pIFByenlnaWVuZGE7IExlcyBHaW5zYmVyZzsgQW50b25pIFByenlnaWVuZGE7IExl cyBHaW5zYmVyZzsgU2FtIEFsZHJpbjsgSmVmZnJleSBaaGFuZw0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1wcnp5Z2llbmRhLWJpZXItaXNpcy1yYW5nZXMtMDIu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXByenlnaWVuZGEtYmllci1pc2lz LXJhbmdlcy0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVG9ueSBQ cnp5Z2llbmRhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRy YWZ0LXByenlnaWVuZGEtYmllci1pc2lzLXJhbmdlcw0KUmV2aXNpb246CTAyDQpUaXRsZToJCUJJ RVIgc3VwcG9ydCB2aWEgSVNJUw0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wMS0zMA0KR3JvdXA6CQlJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTMNClVSTDogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wcnp5Z2llbmRhLWJpZXItaXNpcy1y YW5nZXMtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtcHJ6eWdpZW5kYS1iaWVyLWlzaXMtcmFuZ2VzLw0KSHRtbGl6ZWQ6ICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXByenlnaWVuZGEtYmllci1pc2lzLXJh bmdlcy0wMg0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LXByenlnaWVuZGEtYmllci1pc2lzLXJhbmdlcy0wMg0KDQpBYnN0cmFjdDoNCiAgIFNw ZWNpZmljYXRpb24gb2YgYW4gSVNJUyBleHRlbnNpb24gdG8gc3VwcG9ydCBCSUVSIGRvbWFpbnMg YW5kIHN1Yi0NCiAgIGRvbWFpbnMuDQoNCg0K From nobody Mon Feb 2 09:01:35 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8941A6FFA for ; Mon, 2 Feb 2015 09:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziBoCEVcbQbS for ; Mon, 2 Feb 2015 09:01:27 -0800 (PST) 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 6AD461A6FF0 for ; Mon, 2 Feb 2015 09:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6433; q=dns/txt; s=iport; t=1422896486; x=1424106086; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=2bBUNLIoJRWxHha+lkYzqWGTUsvNRketXdJ+ezcXO7A=; b=TY1LX90aFxEBjXq8YTuRbfyYlo9LZdMxZzW2UBQFL5/eZMRz0HLNPMi/ mRSCMT5Hnqj7XjZ/5zG5vVRgt49V2dbG+6HiiKlqfUD36aadqAa3Wy/K6 8UnfWEPRZwHMHQqxmvdBjkrKYpjBY9MrZnuZsr9w4HK9GTliPtkA3nqPz 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A9CQCtrM9U/xbLJq1bg1hZsiQFAXaRPgEJhXECgWEBAQEBAX2EDQEBAwEBAQFrCwULCw4xBycfEQYTG4gKCA3WNAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhgSJcAQHgxaBEwWNJoUxhVeBF4MDgkSIQYM9IoNvPTEBgkEBAQE X-IronPort-AV: E=Sophos;i="5.09,507,1418083200"; d="scan'208,217";a="336651637" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 02 Feb 2015 17:01:23 +0000 Received: from ams-iwijnand-8817.cisco.com (ams-iwijnand-8817.cisco.com [10.60.202.88]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t12H1LcY012607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2015 17:01:22 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_40098671-F42A-43E7-AFBB-7E60310D80E1" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: IJsbrand Wijnands In-Reply-To: Date: Mon, 2 Feb 2015 18:01:21 +0100 Message-Id: <3FF683F3-8FA8-460A-8A03-5CA24063DE98@cisco.com> References: To: Alia Atlas X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Greg Shepherd , "bier@ietf.org" Subject: Re: [Bier] BOF deadline approaching X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 17:01:33 -0000 --Apple-Mail=_40098671-F42A-43E7-AFBB-7E60310D80E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alia, > I am certainly happy to see the work progressing on schedule. That's = a good sign. I intend to review these > drafts this week. I really want to have a clear discussion of the = deployment costs vs benefits of the technology; > does BIER enable new capabilities due to scale changes? Again - I = haven't read the updated problem statement yet > so I hope this is there.=20 Please also checkout the updated use-case draft, = (https://tools.ietf.org/id/draft-kumar-bier-use-cases-01.txt = ), that = should help you answer the above question. Thx, Ice. > =20 > I'm working on a draft charter now and hope to have something to = review this week. >=20 > I'm certainly happy to see a draft charter. Do be aware that it will = likely be tightened up and focused on defining > the solution. >=20 > Thanks, > Alia > =20 > Thanks for your help, > Greg > =20 > =20 > Putting in a BoF request, assuming it is approved of course, makes = sure > that there is meeting time scheduled. >=20 > The deadlne is Feb 6. >=20 > Regards, > Alia >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier = >=20 >=20 >=20 >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier --Apple-Mail=_40098671-F42A-43E7-AFBB-7E60310D80E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Alia,

I am certainly happy to see the work progressing on = schedule.  That's a good sign.  I intend to review = these
drafts this week.  I really want to have = a clear discussion of the deployment costs vs benefits of the = technology;
does BIER enable new capabilities due = to scale changes?  Again - I haven't read the updated problem = statement yet
so I hope this is = there. 

Please also checkout the updated use-case draft, = (https://tools.ietf.org/id/draft-kumar-bier-use-cases-01.txt= ), that should help you answer the above question.

Thx,

Ice.

 
I'm working on a draft charter now and = hope to have something to review this = week.

I'm certainly happy to see a draft = charter.  Do be aware that it will likely be tightened up and = focused on defining
the solution.

Thanks,
Alia
 
Thanks = for your help,
Greg
 
 
Putting in a BoF request, assuming it is approved of course, = makes sure
that there is meeting time = scheduled.

The = deadlne is Feb 6.

Regards,
Alia

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




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

= --Apple-Mail=_40098671-F42A-43E7-AFBB-7E60310D80E1-- From nobody Mon Feb 2 09:09:28 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091AF1A876B for ; Mon, 2 Feb 2015 09:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWIjfonVDW2G for ; Mon, 2 Feb 2015 09:09:22 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A314D1A8726 for ; Mon, 2 Feb 2015 09:09:21 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id y19so40006802wgg.2 for ; Mon, 02 Feb 2015 09:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CBYqo7KmmQtdMrW76U/OWOc5tsA8496NoLv4sPk+Fnk=; b=fFijIU3aU0sM21oSZMA28o+86MDvfasacscvZlaOA5el4c+kwLKzNi/tWsJClIiQIe 6gxfTZ7sgY3B6o7gkCOqg78eg0nwhQWN6gn1ydDO/v3ybP36xxQthEKufqoIidI4HhX7 9iAvNL0RrXTEQkCCeyGuc2cdL6IUdzFDa0Riau5v/8aYZAYUeK6AjrxQAOh4yC85CzhA PLCe2kv0B/Tyqoy8AInRUgnlt9VwcmrnW0Dt3G9myc04P2JEThRMA9arZtm43+eRZuw5 BIqypwYQL7OsWguFkG/TOKT8Tp8SkTHOdeZ29krDTymD3WhEOSqa45P8IUrhCEcoWQ6E iyYg== MIME-Version: 1.0 X-Received: by 10.180.87.42 with SMTP id u10mr26203252wiz.51.1422896959353; Mon, 02 Feb 2015 09:09:19 -0800 (PST) Received: by 10.180.207.180 with HTTP; Mon, 2 Feb 2015 09:09:19 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Feb 2015 09:09:19 -0800 Message-ID: From: Greg Shepherd To: Alia Atlas Content-Type: multipart/alternative; boundary=f46d044280f0d07e20050e1e03be Archived-At: Cc: "bier@ietf.org" Subject: Re: [Bier] BOF deadline approaching X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 17:09:25 -0000 --f46d044280f0d07e20050e1e03be Content-Type: text/plain; charset=UTF-8 Inline: On Mon, Feb 2, 2015 at 8:53 AM, Alia Atlas wrote: > Hi Greg, > > On Mon, Feb 2, 2015 at 9:15 AM, Greg Shepherd wrote: > >> On Fri, Jan 30, 2015 at 11:30 PM, Greg Shepherd wrote: >> >>> On Tue, Jan 27, 2015 at 4:07 PM, Alia Atlas wrote: >>> >>>> I am still waiting to see an updated problem-statement and use-cases. >>>> >>> >>> Posted >>> >>> >>>> I would strongly encourage making a BoF request - working group forming; >>>> >>> >>> I made a request for a slot last week. My view in the tools has BIER as >>> an option - possibly a placeholder for a pending WG formation, I'm not >>> sure. Can you confirm that this request is sufficient to allocate a slot >>> for BIER, BoF or WG, or if I need to also make a request for a BIER BoF? >>> >> >> Any clarity on the schedule request? >> > > I do see the request in the sessions - but am not sure that'll work since > bier isn't a WG. > Okay, so no definitive answer means I need to also request a BoF session, right? The deadline is approaching. > I did put a placeholder on the BOF page. > For my submission I'm guessing? > it isn't clear to me that there will be sufficient progress before Dallas >>>> to be >>>> certain of agreeing on a charter. >>>> >>> >> In our interim meeting we targeted the end of Jan for both the Problem >> Statement and the Use Cases draft - both of which were rev'd and published >> on target. What other progress do we need to pursue? >> > > I am certainly happy to see the work progressing on schedule. That's a > good sign. I intend to review these > drafts this week. I really want to have a clear discussion of the > deployment costs vs benefits of the technology; > does BIER enable new capabilities due to scale changes? Again - I haven't > read the updated problem statement yet > so I hope this is there. > What precisely are you expecting to be quantified under 'cost'? If we're talking development/purchase cost of equipment I'm confused a bit as to where the IETF has taken on this roll in the past. Can you clarify? > I'm working on a draft charter now and hope to have something to review >> this week. >> > > I'm certainly happy to see a draft charter. Do be aware that it will > likely be tightened up and focused on defining > the solution. > Will do, thanks!, Greg > Thanks, > Alia > > >> Thanks for your help, >> Greg >> >> >>> >>>> >>> Putting in a BoF request, assuming it is approved of course, makes sure >>>> that there is meeting time scheduled. >>>> >>>> The deadlne is Feb 6. >>>> >>>> Regards, >>>> Alia >>>> >>>> _______________________________________________ >>>> BIER mailing list >>>> BIER@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bier >>>> >>>> >>> >> > --f46d044280f0d07e20050e1e03be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Inline:

On Mon, Feb 2, 2015 at 8:53 AM, Alia Atlas <= ;akatlas@gmail.com> wrote:
Hi = Greg,

On Mon, Feb 2, 2015 at 9:15 AM, Greg Shepherd &l= t;gjshep@gmail.com> wrote:
On Fri, Jan 30, 2015 at 11:30 PM, Greg Shepherd <gjshep@gmail.com>= wrote:
On Tue, Jan= 27, 2015 at 4:07 PM, Alia Atlas <akatlas@gmail.com> wrote:<= br>
I am still waiting to see an upd= ated problem-statement and use-cases.

Posted
=C2=A0
<= div dir=3D"ltr">
I would strongly encourage making a BoF request - work= ing group forming;

I mad= e a request for a slot last week. My view in the tools has BIER as an optio= n - possibly a placeholder for a pending WG formation, I'm not sure. Ca= n you confirm that this request is sufficient to allocate a slot for BIER, = BoF or WG, or if I need to also make a request for a BIER BoF?
<= /div>

Any clarity on the sched= ule request?

I do see the request in the sessions - but am not sure that'll work si= nce bier isn't a WG.=C2=A0
Okay, so no definitive answer means I need to also request a Bo= F session, right? The deadline is approaching.
=C2=A0
I did put a placeholder on the BOF page.

For my submission I'm g= uessing?
=C2=A0
=
=
it isn't clear to me that t= here will be sufficient progress before Dallas to be
certain of a= greeing on a charter.

In our interim meeting we targeted the = end of Jan for both the Problem Statement and the Use Cases draft - both of= which were rev'd and published on target. What other progress do we ne= ed to pursue?

I am certainly happy to see the work progressing on schedule.=C2=A0 That&= #39;s a good sign.=C2=A0 I intend to review these
drafts this wee= k.=C2=A0 I really want to have a clear discussion of the deployment costs v= s benefits of the technology;
does BIER enable new capabilities d= ue to scale changes?=C2=A0 Again - I haven't read the updated problem s= tatement yet
so I hope this is there.=C2=A0

What precisely are you expecting to be q= uantified under 'cost'? If we're talking development/purchase c= ost of equipment I'm confused a bit as to where the IETF has taken on t= his roll in the past. Can you clarify?
=C2=A0
I&= #39;m working on a draft charter now and hope to have something to review t= his week.

I&= #39;m certainly happy to see a draft charter.=C2=A0 Do be aware that it wil= l likely be tightened up and focused on defining
the solution.

Will do, thanks!,
Greg
=C2=A0
Thanks,=
Alia
=C2=A0
Thanks for your help,
Greg
=C2=A0=
=C2=A0
Putting in a BoF request, ass= uming it is approved of course, makes sure
that there is meeting = time scheduled.

The deadlne is Feb 6.
Regards,
Alia

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





--f46d044280f0d07e20050e1e03be-- From nobody Mon Feb 2 09:23:17 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7852F1A8797 for ; Mon, 2 Feb 2015 09:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GXctcjYosTM for ; Mon, 2 Feb 2015 09:22:52 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53D31A87A1 for ; Mon, 2 Feb 2015 09:22:52 -0800 (PST) Received: by mail-yk0-f182.google.com with SMTP id q9so22422297ykb.13 for ; Mon, 02 Feb 2015 09:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jHYyAtdIyaORIjubJEfbaFMLmcrY3McF44tFRTIuL6U=; b=JbrIVu6JkKJ2ak7JO6oZy3NnGHUvwuW0nmFwnTCRrHC15Sid848I8zuNrnZDobZrvm Iix0N+4Ixa/cm9EooX2U0agpnFqvBmbetRb5rIdhqK5i4LVge+t0ZnktasG69zAElfuS eDj3p+sWkMnSydVllnzc9NfVUZn6vyrwWVci10pH8BAz1+Oe6SFQk4lbskZn6MCzhKCa le9tO/xkV+EvTsHgbNKIjsQE/PIow+gYIUiN6agjI/+lwzu6PyfmBmlnJqV9mhYzXObb obWGgtCX2T+xG1bYu122YxEeNKrOGDil5Bjs9q2Q6ezkRZTzD4FyMhvSeaPctwSqAEk/ /b5A== MIME-Version: 1.0 X-Received: by 10.170.119.195 with SMTP id l186mr7779580ykb.51.1422897771819; Mon, 02 Feb 2015 09:22:51 -0800 (PST) Received: by 10.170.133.80 with HTTP; Mon, 2 Feb 2015 09:22:51 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Feb 2015 12:22:51 -0500 Message-ID: From: Alia Atlas To: Greg Shepherd Content-Type: multipart/alternative; boundary=001a1137941c3db81a050e1e34ba Archived-At: Cc: "bier@ietf.org" Subject: Re: [Bier] BOF deadline approaching X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 17:23:02 -0000 --001a1137941c3db81a050e1e34ba Content-Type: text/plain; charset=UTF-8 Hi Greg, On Mon, Feb 2, 2015 at 12:09 PM, Greg Shepherd wrote: > Inline: > > On Mon, Feb 2, 2015 at 8:53 AM, Alia Atlas wrote: > >> Hi Greg, >> >> On Mon, Feb 2, 2015 at 9:15 AM, Greg Shepherd wrote: >> >>> On Fri, Jan 30, 2015 at 11:30 PM, Greg Shepherd >>> wrote: >>> >>>> On Tue, Jan 27, 2015 at 4:07 PM, Alia Atlas wrote: >>>> >>>>> I am still waiting to see an updated problem-statement and use-cases. >>>>> >>>> >>>> Posted >>>> >>>> >>>>> I would strongly encourage making a BoF request - working group >>>>> forming; >>>>> >>>> >>>> I made a request for a slot last week. My view in the tools has BIER as >>>> an option - possibly a placeholder for a pending WG formation, I'm not >>>> sure. Can you confirm that this request is sufficient to allocate a slot >>>> for BIER, BoF or WG, or if I need to also make a request for a BIER BoF? >>>> >>> >>> Any clarity on the schedule request? >>> >> >> I do see the request in the sessions - but am not sure that'll work since >> bier isn't a WG. >> > > Okay, so no definitive answer means I need to also request a BoF session, > right? The deadline is approaching. > > >> I did put a placeholder on the BOF page. >> > > For my submission I'm guessing? > Yes - it should be ok, but if you wanted to update the description and guess of people, that'd be great. > > >> it isn't clear to me that there will be sufficient progress before Dallas >>>>> to be >>>>> certain of agreeing on a charter. >>>>> >>>> >>> In our interim meeting we targeted the end of Jan for both the Problem >>> Statement and the Use Cases draft - both of which were rev'd and published >>> on target. What other progress do we need to pursue? >>> >> >> I am certainly happy to see the work progressing on schedule. That's a >> good sign. I intend to review these >> drafts this week. I really want to have a clear discussion of the >> deployment costs vs benefits of the technology; >> does BIER enable new capabilities due to scale changes? Again - I >> haven't read the updated problem statement yet >> so I hope this is there. >> > > What precisely are you expecting to be quantified under 'cost'? If we're > talking development/purchase cost of equipment I'm confused a bit as to > where the IETF has taken on this roll in the past. Can you clarify? > Of course, it's not the purchase cost or development cost of equipment! We're not the ones evaluating whether to buy for a particular network or develop for it. It's a question of whether the impact of a new data-plane is worth the problems being solved. The short form of the question is whether there's a non-trivial market for this that have problems motivating such a solution or are we talking about complicating a very narrow and sensitive part of the architecture for something that won't gain traction. I am sensitive to the arguments about innovation needing time to evolve and for the benefits to be clear, which is why I'm willing to work on an Experimental charter. One item in the charter should be describing the experiment and how to evaluate the results. I'm working on a draft charter now and hope to have something to review >>> this week. >>> >> >> I'm certainly happy to see a draft charter. Do be aware that it will >> likely be tightened up and focused on defining >> the solution. >> > > Will do, thanks!, > Thanks, Alia > Greg > > >> Thanks, >> Alia >> >> >>> Thanks for your help, >>> Greg >>> >>> >>>> >>>>> >>>> Putting in a BoF request, assuming it is approved of course, makes sure >>>>> that there is meeting time scheduled. >>>>> >>>>> The deadlne is Feb 6. >>>>> >>>>> Regards, >>>>> Alia >>>>> >>>>> _______________________________________________ >>>>> BIER mailing list >>>>> BIER@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/bier >>>>> >>>>> >>>> >>> >> > --001a1137941c3db81a050e1e34ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

On Mon, Feb 2, 2015 at 12:09 PM, Greg Shepherd &l= t;gjshep@gmail.com> wrote:
Inli= ne:

On Mon, Feb 2, 2015 at 8:53 AM, Alia Atlas <akatlas@gmail.com&g= t; wrote:
Hi Greg= ,

On Mon= , Feb 2, 2015 at 9:15 AM, Greg Shepherd <gjshep@gmail.com> wr= ote:
On Fri, Jan 3= 0, 2015 at 11:30 PM, Greg Shepherd <gjshep@gmail.com> wrote:<= br>
On Tue, Jan 27, 2015 at 4:= 07 PM, Alia Atlas <akatlas@gmail.com> wrote:
I am still waiting to see an updated problem-st= atement and use-cases.

Posted<= /div>
=C2=A0
I would strongly encourage making a BoF request - working group formi= ng;

I made a request for= a slot last week. My view in the tools has BIER as an option - possibly a = placeholder for a pending WG formation, I'm not sure. Can you confirm t= hat this request is sufficient to allocate a slot for BIER, BoF or WG, or i= f I need to also make a request for a BIER BoF?

Any clarity on the schedule request?

I do see the r= equest in the sessions - but am not sure that'll work since bier isn= 9;t a WG.=C2=A0

<= div>Okay, so no definitive answer means I need to also request a BoF sessio= n, right? The deadline is approaching.
=C2=A0
I did put a placeholder on the BOF page.=

For my subm= ission I'm guessing?

Yes - it should be ok, but if you = wanted to update the description and guess of people, that'd be great.<= /div>
=C2=A0
=C2= =A0
=
=
it isn't clear to me that there will be sufficient progress = before Dallas to be
certain of agreeing on a charter.
=

In our interim meeting we targeted the end of Jan for both the Problem S= tatement and the Use Cases draft - both of which were rev'd and publish= ed on target. What other progress do we need to pursue?

I am certainly happy to see the= work progressing on schedule.=C2=A0 That's a good sign.=C2=A0 I intend= to review these
drafts this week.=C2=A0 I really want to have a = clear discussion of the deployment costs vs benefits of the technology;
does BIER enable new capabilities due to scale changes?=C2=A0 Again = - I haven't read the updated problem statement yet
so I hope = this is there.=C2=A0

What precisely are you expecting to be quantified under 'cost&= #39;? If we're talking development/purchase cost of equipment I'm c= onfused a bit as to where the IETF has taken on this roll in the past. Can = you clarify?

Of cou= rse, it's not the purchase cost or development cost of equipment!=C2=A0= We're not the ones evaluating whether to buy for a particular network = or develop for it.=C2=A0 It's a question of whether the impact of a new= data-plane is worth the problems being solved.=C2=A0 The short form of the= question is
whether there's a non-trivial market for this th= at have problems motivating such a solution or are we talking about complic= ating a very narrow
and sensitive part of the architecture for so= mething that won't gain traction.

I am sensiti= ve to the arguments about innovation needing time to evolve and for the ben= efits to be clear, which is why I'm willing to=C2=A0
work on = an Experimental charter.=C2=A0 One item in the charter should be describing= the experiment and how to evaluate the results.
=C2=A0

I'm working on = a draft charter now and hope to have something to review this week.

I'm certainly h= appy to see a draft charter.=C2=A0 Do be aware that it will likely be tight= ened up and focused on defining
the solution.

Will do, thanks!,

Thanks,
Alia
=C2=A0
Greg
=C2=A0
Thanks,
Alia
<= span>
=C2=A0
Thanks for your help,=
Greg
=C2=A0
=
=C2=A0
Putting in a BoF request, assuming it is approved of course, = makes sure
that there is meeting time scheduled.

The deadlne is Feb 6.

Regards,
= Alia

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






--001a1137941c3db81a050e1e34ba-- From nobody Mon Feb 2 09:34:09 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200E21A87D9 for ; Mon, 2 Feb 2015 09:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb_y-nyafLAV for ; Mon, 2 Feb 2015 09:34:00 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E0C1A87AF for ; Mon, 2 Feb 2015 09:33:55 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id w55so35066044wes.5 for ; Mon, 02 Feb 2015 09:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0tWMdlYDjmSxeVzvE7r+0QnjHsreMeAIrW851qFxf3g=; b=j6yUQAZdnRRQgkcHD0X8JB5nx9zDtLVm3nQf3zlKZjy7NfqeWbmmbAeQQPFsfj/NUs rXntsk1U2JZ3Xr7ha3JE1HEqwL0MrOINQ9JNjmRer46J4gAQjVnDbwe6QwDWxjU954Em LMRe9G9pPM8OHaDei/AH1A8uCF/w13jOXpsl0Ii0c5KmQCH5rHd8HSzitYTR53QEg8Y/ wJjZGVkjfd8IzcBCClJlxxblAjGJJWggwWojJZSYMzlC8BMjTV3L8iqp6pON3Mwn66NU kkf2TgClSQKV2++pqpWF88Ba0MTzKzktuykRqHcNMTJC3YNKQmv0/dqlufrbiSTwa7wO HZxQ== MIME-Version: 1.0 X-Received: by 10.181.9.107 with SMTP id dr11mr8343069wid.40.1422898434171; Mon, 02 Feb 2015 09:33:54 -0800 (PST) Received: by 10.180.207.180 with HTTP; Mon, 2 Feb 2015 09:33:54 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Feb 2015 09:33:54 -0800 Message-ID: From: Greg Shepherd To: Alia Atlas Content-Type: multipart/alternative; boundary=001a113602acb866dd050e1e5b8c Archived-At: Cc: "bier@ietf.org" Subject: Re: [Bier] BOF deadline approaching X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 17:34:06 -0000 --001a113602acb866dd050e1e5b8c Content-Type: text/plain; charset=UTF-8 Inline: On Mon, Feb 2, 2015 at 9:22 AM, Alia Atlas wrote: > Hi Greg, > > On Mon, Feb 2, 2015 at 12:09 PM, Greg Shepherd wrote: > >> Inline: >> >> On Mon, Feb 2, 2015 at 8:53 AM, Alia Atlas wrote: >> >>> Hi Greg, >>> >>> On Mon, Feb 2, 2015 at 9:15 AM, Greg Shepherd wrote: >>> >>>> On Fri, Jan 30, 2015 at 11:30 PM, Greg Shepherd >>>> wrote: >>>> >>>>> On Tue, Jan 27, 2015 at 4:07 PM, Alia Atlas wrote: >>>>> >>>>>> I am still waiting to see an updated problem-statement and use-cases. >>>>>> >>>>> >>>>> Posted >>>>> >>>>> >>>>>> I would strongly encourage making a BoF request - working group >>>>>> forming; >>>>>> >>>>> >>>>> I made a request for a slot last week. My view in the tools has BIER >>>>> as an option - possibly a placeholder for a pending WG formation, I'm not >>>>> sure. Can you confirm that this request is sufficient to allocate a slot >>>>> for BIER, BoF or WG, or if I need to also make a request for a BIER BoF? >>>>> >>>> >>>> Any clarity on the schedule request? >>>> >>> >>> I do see the request in the sessions - but am not sure that'll work >>> since bier isn't a WG. >>> >> >> Okay, so no definitive answer means I need to also request a BoF session, >> right? The deadline is approaching. >> >> >>> I did put a placeholder on the BOF page. >>> >> >> For my submission I'm guessing? >> > > Yes - it should be ok, but if you wanted to update the description and > guess of people, that'd be great. > You didn't answer the first question, and this answer is still a bit soft. I've already requested a slot as per the online tool BUT this was as a WG I believe - no confirmation either way. I will go ahead and ALSO request a BoF slot and let the IESG sort it out. I will then update the BoF placeholder you started with updated info. If this is NOT the recommended path forward please let me know soon or it will be done. > >> >>> it isn't clear to me that there will be sufficient progress before >>>>>> Dallas to be >>>>>> certain of agreeing on a charter. >>>>>> >>>>> >>>> In our interim meeting we targeted the end of Jan for both the Problem >>>> Statement and the Use Cases draft - both of which were rev'd and published >>>> on target. What other progress do we need to pursue? >>>> >>> >>> I am certainly happy to see the work progressing on schedule. That's a >>> good sign. I intend to review these >>> drafts this week. I really want to have a clear discussion of the >>> deployment costs vs benefits of the technology; >>> does BIER enable new capabilities due to scale changes? Again - I >>> haven't read the updated problem statement yet >>> so I hope this is there. >>> >> >> What precisely are you expecting to be quantified under 'cost'? If we're >> talking development/purchase cost of equipment I'm confused a bit as to >> where the IETF has taken on this roll in the past. Can you clarify? >> > > Of course, it's not the purchase cost or development cost of equipment! > We're not the ones evaluating whether to buy for a particular network or > develop for it. It's a question of whether the impact of a new data-plane > is worth the problems being solved. > Ok, then how do we quantify 'impact'? Adding a new data-plane should have no impact on existing data-planes, outside of the cost of equipment. What am I missing? > The short form of the question is > whether there's a non-trivial market for this that have problems > motivating such a solution or are we talking about complicating a very > narrow > and sensitive part of the architecture for something that won't gain > traction. > Understood. The size of the turnout at the last BoF seems a pretty solid indication that the current multicast solutions have issues, to say the least. This seems to indicate a community need. But ultimately the 'impact' would need to have a defined solution. Defining a solution is the role of a WG, correct? > I am sensitive to the arguments about innovation needing time to evolve > and for the benefits to be clear, which is why I'm willing to > work on an Experimental charter. > As we spoke before, the final definition of Experimental vs Standards track would take place at the time of final publishing of the work, based on community support. Has this changed? > One item in the charter should be describing the experiment and how to > evaluate the results. > Great. Can you point me to a solid definition of 'impact' so I can better target an experiment designed to quantify this? Thanks!, Greg > > I'm working on a draft charter now and hope to have something to review >>>> this week. >>>> >>> >>> I'm certainly happy to see a draft charter. Do be aware that it will >>> likely be tightened up and focused on defining >>> the solution. >>> >> >> Will do, thanks!, >> > > Thanks, > Alia > > >> Greg >> >> >>> Thanks, >>> Alia >>> >>> >>>> Thanks for your help, >>>> Greg >>>> >>>> >>>>> >>>>>> >>>>> Putting in a BoF request, assuming it is approved of course, makes sure >>>>>> that there is meeting time scheduled. >>>>>> >>>>>> The deadlne is Feb 6. >>>>>> >>>>>> Regards, >>>>>> Alia >>>>>> >>>>>> _______________________________________________ >>>>>> BIER mailing list >>>>>> BIER@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/bier >>>>>> >>>>>> >>>>> >>>> >>> >> > --001a113602acb866dd050e1e5b8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Inline:

On Mon, Feb 2, 2015 at 9:22 AM, Alia Atlas <= ;akatlas@gmail.com> wrote:
Hi = Greg,

On Mon, Feb 2, 2015 at 12:09 PM, Greg Shepherd <= gjshep@gmail.com&= gt; wrote:
Inline= :

On Mon= , Feb 2, 2015 at 8:53 AM, Alia Atlas <akatlas@gmail.com> wro= te:
Hi Greg,

On Mon, Feb 2, 2015= at 9:15 AM, Greg Shepherd <gjshep@gmail.com> wrote:
On Fri, Jan 30, 2015 at 11= :30 PM, Greg Shepherd <gjshep@gmail.com> wrote:
On Tue, Jan 27, 2015 at 4:07 PM, Alia = Atlas <akatlas@gmail.com> wrote:
<= div dir=3D"ltr">I am still waiting to see an updated problem-statement and = use-cases.

Posted
<= div>=C2=A0
I woul= d strongly encourage making a BoF request - working group forming;

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

Any clarity on the schedule request?

I do see the request in th= e sessions - but am not sure that'll work since bier isn't a WG.=C2= =A0

Okay, so= no definitive answer means I need to also request a BoF session, right? Th= e deadline is approaching.
=C2=A0
I did put a placeholder on the BOF page.

For my submission I'm guessing= ?

Yes - it should be ok, but if you wanted to update the descri= ption and guess of people, that'd be great.

You didn't answer the first question, and = this answer is still a bit soft. I've already requested a slot as per t= he online tool BUT this was as a WG I believe - no confirmation either way.= I will go ahead and ALSO request a BoF slot and let the IESG sort it out. = I will then update the BoF placeholder you started with updated info. If th= is is NOT the recommended path forward please let me know soon or it will b= e done.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div class=3D"gmail_quote">
=C2=A0
it isn't clear to me= that there will be sufficient progress before Dallas to be
certa= in of agreeing on a charter.

In our interim meeting we target= ed the end of Jan for both the Problem Statement and the Use Cases draft - = both of which were rev'd and published on target. What other progress d= o we need to pursue?

I am certainly happy to see the work progressing on schedule.=C2= =A0 That's a good sign.=C2=A0 I intend to review these
drafts= this week.=C2=A0 I really want to have a clear discussion of the deploymen= t costs vs benefits of the technology;
does BIER enable new capab= ilities due to scale changes?=C2=A0 Again - I haven't read the updated = problem statement yet
so I hope this is there.=C2=A0
<= /div>

What precisely are you e= xpecting to be quantified under 'cost'? If we're talking develo= pment/purchase cost of equipment I'm confused a bit as to where the IET= F has taken on this roll in the past. Can you clarify?

Of course, it's not the purc= hase cost or development cost of equipment!=C2=A0 We're not the ones ev= aluating whether to buy for a particular network or develop for it.=C2=A0 I= t's a question of whether the impact of a new data-plane is worth the p= roblems being solved.

Ok, then how do we quantify 'impact'? Adding a new data-plane sh= ould have no impact on existing data-planes, outside of the cost of equipme= nt. What am I missing?
=C2=A0
=C2=A0 The short form of the question is
whether there's a = non-trivial market for this that have problems motivating such a solution o= r are we talking about complicating a very narrow
and sensitive p= art of the architecture for something that won't gain traction.

Understood. The size of th= e turnout at the last BoF seems a pretty solid indication that the current = multicast solutions have issues, to say the least. This seems to indicate a= community need. But ultimately the 'impact' would need to have a d= efined solution. Defining a solution is the role of a WG, correct?
=C2=A0
I am sensitive to the argumen= ts about innovation needing time to evolve and for the benefits to be clear= , which is why I'm willing to=C2=A0
work on an Experimental c= harter.=C2=A0

As we= spoke before, the final definition of Experimental vs Standards track woul= d take place at the time of final publishing of the work, based on communit= y support. Has this changed?
=C2=A0
One item in the charter should be describing the experiment and ho= w to evaluate the results.

Great. Can you point me to a solid definition of 'impact' s= o I can better target an experiment designed to quantify this?
Thanks!,
Greg
=C2=A0

<= div dir=3D"ltr">
<= div>I'm working on a draft charter now and hope to have something to re= view this week.

<= div>I'm certainly happy to see a draft charter.=C2=A0 Do be aware that = it will likely be tightened up and focused on defining
the soluti= on.

Will do,= thanks!,

Th= anks,
Alia
=C2=A0
Greg
=C2=A0
Thanks,
Alia
=C2=A0
Thanks for your help,
Greg
=C2= =A0
=C2=A0
Putting in a BoF request, = assuming it is approved of course, makes sure
that there is meeti= ng time scheduled.

The deadlne is Feb 6.

Regards,
Alia

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







--001a113602acb866dd050e1e5b8c-- From nobody Mon Feb 2 09:39:02 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5591A87D4 for ; Mon, 2 Feb 2015 09:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.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, SPF_PASS=-0.001, URIBL_DBL_ABUSE_REDIR=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuxVzpGKTnbJ for ; Mon, 2 Feb 2015 09:38:54 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845BF1A87CB for ; Mon, 2 Feb 2015 09:38:54 -0800 (PST) Received: by mail-yk0-f172.google.com with SMTP id 9so22488288ykp.3 for ; Mon, 02 Feb 2015 09:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nPqQ38EnL93azBk0Dm8pXw5h4Nls0awXT2t+inGX2uI=; b=sWRi8jRkahys+UR8o3CyeB5NPRjV5tWFu5n+0cOXfE37EU+kpWYsBxSEn8zGKfgRiZ oBBnVZua6DRSindCVagRwW40YlyiFDGX0eoJ4r2MLJ7M/aSQSaCm5oCwz/2tyWVtOqn1 fI1N/7Vzq3R4606Kn+VWx0Zv+W2YBmt/GONuhBEgQYie6oeB/s5EmJ/xKladpfvPyq4u AShvTQ0kfaoV2AQlJMXyK+oDK+GTWotOsF04IoD4GaniwVuFGwMMn8K9/ZOp7vN7FIku A7KoiQkdgCtO2Tiklz5oVQSZoxszTR8jTjq7F2/ewDGsXHDLXPWgeYoQp5ntQrI+27Q/ Iq1w== MIME-Version: 1.0 X-Received: by 10.236.14.135 with SMTP id d7mr8649016yhd.3.1422898733730; Mon, 02 Feb 2015 09:38:53 -0800 (PST) Received: by 10.170.133.80 with HTTP; Mon, 2 Feb 2015 09:38:53 -0800 (PST) In-Reply-To: <62A44EE9552A463F9C81E16F620C3B03@d2consulting.co.uk> References: <20150130204021.30418.24378.idtracker@ietfa.amsl.com> <62A44EE9552A463F9C81E16F620C3B03@d2consulting.co.uk> Date: Mon, 2 Feb 2015 12:38:53 -0500 Message-ID: From: Alia Atlas To: Dom Robinson Content-Type: multipart/alternative; boundary=089e013a1a1293578a050e1e6d68 Archived-At: Cc: "Nagendra Kumar Nainar \(naikumar\)" , "bier@ietf.org" , IJsbrand Wijnands , Greg Shepherd Subject: Re: [Bier] FW: I-D Action: draft-kumar-bier-use-cases-01.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 17:38:59 -0000 --089e013a1a1293578a050e1e6d68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dom, On Mon, Feb 2, 2015 at 8:00 AM, Dom Robinson wrote: > Thanks Ice / Greg > > Ok here is my first n00b stab at extending the text. I possibly need to > read up on text formatting (use of brackets and terms like =E2=80=98layer= 4=E2=80=99) but > perhaps let me share this as a way to refine the logic of what i feel cou= ld > be included. My key thinking is that we are trying to avoid specifically > involving IGMP and MBGP while still =E2=80=98allowing them=E2=80=99 and y= et to open up for > SDN / application layer control plane over-lay if a CDN operator wants to > build that and still support BIER=E2=80=A6 > > < feeling timid among such an esteemed crowd :) > > Your contributions and willingness to engage are quite welcome. Don't feel timid - we were all new at one time and we all have experience in different areas. Regards, Alia > =E2=80=94=E2=80=94 > > *3.3. IPTV, OTT and CDN Services* > > IPTV is a service, well known for its characteristics of allowing both > live and on-demand delivery of media traffic over Managed IP networks. > > > > Over The Top (OTT) is a similar service, well known for its > characteristics of allowing live and on-demand delivery of media traffic > between IP domains, where the source is often on an external network > relative to the receivers. > > > > Content Delivery Networks (CDN) operators provide layer 4 applications, > and often some degree of managed layer 3 IP network, that enable media to > be securely and reliably delivered to many receivers. In some models they > may place applications within third party networks, or they may place tho= se > applications at the edges of their own managed network peerings and simil= ar > inter-domain connections. CDNs provide capabilities to help publishers > scale to meet large audience demand. Their applications are not limited t= o > audio and video delivery, but may include static and dynamic web content, > or optimized delivery for Massive Multiplayer Gaming and similar. Most > publishers will use a CDN for public Internet delivery, and some publishe= rs > will use a CDN internally within their IPTV networks to resolve layer 4 > complexity. > > > > > > In a typical IPTV environment the egress routers connecting to the > receivers will build the tree towards the ingress router connecting to th= e > IPTV servers. The egress routers would rely on IGMP/MLD (static or > dynamic) to learn about the receiver's interest in one or more multicast > group/channels. Interestingly, BIER could allows provisioning any new > multicast group/channel by only modifying the channel mapping on ingress > routers. This is deemed beneficial for the linear IPTV video broadcastin= g > in which every receivers behind every egress PE routers would receive the > IPTV video traffic. > > > > With BIER, there is no need of tree building from egress to ingress. > Further, any addition of new channel or new egress routers can be directl= y > controlled from ingress router. When a new channel is included, the > multicast group is mapped to Bit string that includes all egress routers. > Ingress router would start sending the new channel and deliver it to all > egress routers. As it can be observed, there is no need for static IGMP > provisioning in each egress routers whenever a new channel/stream is > added. Instead, it can be controlled from ingress router itself by > configuring the new group to Bit Mask mapping on ingress router. > > > > In OTT services the receivers will often be on remote domains. These > receivers may connect to the egress routers of a managed CDN that support= s > BIER. This will enable the CDN to efficiently deliver the content to many > egress locations, in turn providing internal optimization. > > > > Where these egress routers connect directly to the Ingress BIER routers o= f > downstream domains then a continuity of the scaling that BIER offers coul= d > be provided. This may rely on MBGP interoperation (or similar) between th= e > egress of one domain and the ingress of the next domain, or some other SD= N > control plane may prove a more effective and simpler way to deploy BIER. > For a single CDN operator this could be well managed in the Layer 4 > applications that they provide and it may be that the initial receiver in= a > remote domain is actually an application operated by the CDN which in tur= n > acts as a source for the Ingress BIER router in that remote domain, and b= y > doing so keeps the BIER more descrete on a domain by domain basis. > > > --- > > Looking forward to learning (a lot) from the feedback! > > Hope it is useful=E2=80=A6 > > Dom > > Co-Founder, Director and Creative Firestarter @ id3as-company ltd > Innovation, Development, Architecture, Strategy > for IT, Cloud and StreamingMedia Projects > http://www.linkedin.com/in/domrobinson > > Contributing Editor for StreamingMedia > http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm > > Book out now on Wiley.com =E2=80=9CAdvanced Content Delivery, Streaming, = and Cloud > Services=E2=80=9D : http://bit.ly/1r1ttEG > > > On Monday, 2 February 2015 at 11:55, IJsbrand Wijnands wrote: > > Hi Dom, > > Your email made it to the list just fine. > > I think your use-case makes sense. Since the content is driven from the > source side, the operator can just identify the CDN=E2=80=99s and push th= e content > to it. What is nice is that you don=E2=80=99t need to make the CDN=E2=80= =99s pre-join a > multicast tree in order to push the data to it. There could also be a nic= e > SDN user interface to it as well :-) > > Why don=E2=80=99t you go ahead with preparing the text and we=E2=80=99ll = add the content > with you as co-author, ok? > > Thx, > > Ice. > > On 02 Feb 2015, at 12:05, Robinson, Dom wrote: > > (Greg - I am not sure if i eventually got allowed to post this - i cant > see it in my own inbox although i did receive a mail from the BIER mailer > asking me to confirm, which i did.. > > Perhaps I have to post again: so please see comment below (assuming this > makes it) else can you guys perhaps forward my input to the list? > > Dom > > On 1 February 2015 at 01:23, Robinson, Dom wrote: > > Hi guys - i wonder if it would be worth extending the IPTV section to > embrace content pre-placement in not only IPTV, but OTT and even > big-software update and other such CDN activity: I stay close to IP > Multicast specifically for this use case, and I always think it is > interesting that while live/linear is an obvious Multicast candidate, > pre-placing content in many caches that is known to be 'about to be heavi= ly > requested' is actually an extremely valuable capability - even if it is n= ot > live.... > > Just a thought. > > While i am a n00b to the formality of an IETF draft, if you like i would > be happy to try to extend that IPTV paragraph to try to explain that 'CDN= ' > focussed use case...? > > Let me know - ill try to contribute before the start of next week.... > > Kind regards > > Dom > > On 30 January 2015 at 21:34, Nagendra Kumar Nainar (naikumar) < > naikumar@cisco.com> wrote: > > Hi, > > Below is the updated version of BIER use case draft. > > Please read and share your comments. > > Regards, > Nagendra > > > > On 1/30/15, 3:40 PM, "internet-drafts@ietf.org" > wrote: > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : BIER Use Cases > > Authors : Nagendra Kumar > > Rajiv Asati > > Mach(Guoyi) Chen > > Xiaohu Xu > > Andrew Dolganow > > Tony Przygienda > > Arkadiy Gulko > > Filename : draft-kumar-bier-use-cases-01.txt > > Pages : 11 > > Date : 2015-01-30 > > > >Abstract: > > Bit Index Explicit Replication (BIER) is an architecture that > > provides optimal multicast forwarding through a "BIER domain" without > > requiring intermediate routers to maintain any multicast related per- > > flow state. BIER also does not require any explicit tree-building > > protocol for its operation. A multicast data packet enters a BIER > > domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the > > BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). > > The BFIR router adds a BIER header to the packet. The BIER header > > contains a bit-string in which each bit represents exactly one BFER > > to forward the packet to. The set of BFERs to which the multicast > > packet needs to be forwarded is expressed by setting the bits that > > correspond to those routers in the BIER header. > > > > This document describes some of the use-cases for BIER. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-kumar-bier-use-cases/ > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-kumar-bier-use-cases-01 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-bier-use-cases-01 > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > > > > -- > Dom Robinson > Co-Founder, Director and Creative Firestarter @ id3as-company ltd > Innovation, Development, Architecture, Strategy > for IT, Cloud and StreamingMedia Projects > uk.linkedin.com/in/domrobinson > > Also Contributing Editor for www.StreamingMedia.com > > http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm > > > > > -- > Dom Robinson > Co-Founder, Director and Creative Firestarter @ id3as-company ltd > Innovation, Development, Architecture, Strategy > for IT, Cloud and StreamingMedia Projects > uk.linkedin.com/in/domrobinson > > Also Contributing Editor for www.StreamingMedia.com > > http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm > _______________________________________________ > 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 > > --089e013a1a1293578a050e1e6d68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dom,

On Mon, Feb 2, 2015 at 8:00 AM, Dom Robinson <= Dom@id3as.co.uk>= ; wrote:
Thanks Ice / Greg

Ok here is my first n00b stab at = extending the text. I possibly need to read up on text formatting (use of b= rackets and terms like =E2=80=98layer4=E2=80=99) but perhaps let me share t= his as a way to refine the logic of what i feel could be included. My key t= hinking is that we are trying to avoid specifically involving IGMP and MBGP= while still =E2=80=98allowing them=E2=80=99 and yet to open up for SDN / a= pplication layer control plane over-lay if a CDN operator wants to build th= at and still support BIER=E2=80=A6

< feeling ti= mid among such an esteemed crowd :) >

<= div>Your contributions and willingness to engage are quite welcome.=C2=A0 D= on't feel timid - we were all new at one time
and we all have= experience in different areas.


Reg= ards,
Alia=C2=A0

=C2=A0
=E2=80=94=E2=80=94

=

3.3.=C2=A0 IPTV, OTT and CDN Services

IPTV is a service, well known for its characteristics of allowing both live and on-demand delivery of media traff= ic over Managed IP networks.

=C2=A0

Over The Top (OTT) is a similar service, well known for its characteristics of allowing live and on-demand delivery of media traffic between IP domains, where the source is often on = an external network relative to the receivers.

=C2=A0

Content Delivery Networks (CDN) operators provide layer 4 applications, and often some degree of managed la= yer 3 IP network, that enable media to be securely and reliably delivered to ma= ny receivers. In some models they may place applications within third party networks, or they may place those applications at the edges of their own managed network peerings and similar inter-domain connections. CDNs provide capabilities to help publishers scale to meet large audience demand. Their applications are not limited to audio and video delivery, but may include static and dynamic web content, or optimized delivery for Massive Multiplay= er Gaming and similar. Most publishers will use a CDN for public Internet delivery, and some publishers will use a CDN internally within their IPTV networks to resolve layer 4 complexity.

=C2=A0

=C2=A0

In a typical IPTV environment the egress routers connecting to the receivers will build the tree towards the ingress router connecting to the IPTV servers.=C2=A0 The egress routers would rely on IGMP/MLD (static or dynamic) to learn about th= e receiver's interest in one or more multicast group/channels.=C2=A0 Inte= restingly, BIER could allows provisioning any new multicast group/channel by only modifying the channel mapping on ingress routers.=C2=A0 This is deemed beneficial for the linear IPTV video broadcasting in which every receivers behind every egress PE routers would receive the IPTV video traffic.=

=C2=A0

With BIER, there is no need of tree building from egress to ingress. Further, any addition of new channel or new egress route= rs can be directly controlled from ingress router.=C2=A0 When a new channel is included, the multicast group is mapped to Bit string that includes all egress routers.=C2=A0 Ingress router would start sending the new channel and deliver it to all egress routers.=C2=A0 As it can be observed, there is no need for static IGMP provisioning in each egress routers whenev= er a new channel/stream is added.=C2=A0 Instead, it can be controlled from ingress router itself by configuring the new group t= o Bit Mask mapping on ingress router.

=C2=A0

In OTT services the receivers will often be on remote domains. These receivers may connect to the egress route= rs of a managed CDN that supports BIER. This will enable the CDN to efficientl= y deliver the content to many egress locations, in turn providing internal op= timization.

=C2=A0

Where these egress routers connect directly to the Ingress BIER routers of downstream domains then a continuit= y of the scaling that BIER offers could be provided. This may rely on MBGP interoperation (or similar) between the egress of one domain and the ingres= s of the next domain, or some other SDN control plane may prove a more effective= and simpler way to deploy BIER. For a single CDN operator this could be well managed in the Layer 4 applications that they provide and it may be that th= e initial receiver in a remote domain is actually an application operated by = the CDN which in turn acts as a source for the Ingress BIER router in that remo= te domain, and by doing so keeps the BIER more descrete on a domain by domain basis.


---


Looking forward to learning (a lot= ) from the feedback!

Hope it is useful=E2=80=A6

Dom

Co-Founder, Director and Creat= ive Firestarter @ id3as-company ltd
Innovation= , Development, Architecture, Strategy
for IT, = Cloud and StreamingMedia Projects
http://www.linkedin.com/in/domrobinson

Book out now on Wiley.com =E2=80=9CAdvance= d Content Delivery, Streaming, and Cloud Services=E2=80=9D :=C2=A0http://bit.ly/1r1ttEG

=20

On Monday, 2 February 2015 at 11= :55, IJsbrand Wijnands wrote:

Hi Dom,

Your email m= ade it to the list just fine.

I think your use-cas= e makes sense. Since the content is driven from the source side, the operat= or can just identify the CDN=E2=80=99s and push the content to it. What is = nice is that you don=E2=80=99t need to make the CDN=E2=80=99s pre-join a mu= lticast tree in order to push the data to it. There could also be a nice SD= N user interface to it as well :-)

Why don=E2=80= =99t you go ahead with preparing the text and we=E2=80=99ll add the content= with you as co-author, ok?

Thx,

Ice.

On 02 Feb 2015, at 12:05, Robinson, Dom <Dom@id3as.co.uk> wrote:
<= br>
(Greg - I am not sure if i eventually got allowed = to post this - i cant see it in my own inbox although i did receive a mail = from the BIER mailer asking me to confirm, which i did..=C2=A0

Perhaps I have to post again: so please see comment below (assuming = this makes it) else can you guys perhaps forward my input to the list?

Dom

On 1 February 2015 at 01:= 23, Robinson, Dom <Dom@id3as.co.uk> wrote:
Hi guys - i wonder if it would be worth ext= ending the IPTV section to embrace content pre-placement in not only IPTV, = but OTT and even big-software update and other such CDN activity: I stay cl= ose to IP Multicast specifically for this use case, and I always think it i= s interesting that while live/linear is an obvious Multicast candidate, pre= -placing content in many caches that is known to be 'about to be heavil= y requested' is actually an extremely valuable capability - even if it = is not live....

Just a thought.

While i am a n00b to the formality of an IETF draft, if you like i would b= e happy to try to extend that IPTV paragraph to try to explain that 'CD= N' focussed use case...?

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

K= ind regards=C2=A0

Dom
On 30 January 2015 at 21:34, Nagendra Kumar Nainar (naikumar) <nai= kumar@cisco.com> wrote:
Hi,=

Below is the updated version of BIER use case draft.

Please read and share your comments.

Regards,
Nagendra



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

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

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



<= span>--
Dom Robi= nson
Co-Founder, Director and Creative Firestarter @ id3as-company ltd<= /div>
Innovation, Development, Architecture, Strategy
for IT,= Cloud and StreamingMedia Projects



--
<= span>Dom Robinson
Co-Founder, Director and Creative= Firestarter @ id3as-company ltd
Innovation, Development, Archite= cture, Strategy
for IT, Cloud and StreamingMedia Projects
uk.l= inkedin.com/in/domrobinson

Also Contributing E= ditor for=C2=A0www.StreamingMedia.com
_______________________________________________
BIER mailing list
BIER@ietf.org
https://= www.ietf.org/mailman/listinfo/bier
=20 =20 =20 =20
=20


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


--089e013a1a1293578a050e1e6d68-- From nobody Mon Feb 2 16:04:47 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369911A8715 for ; Mon, 2 Feb 2015 16:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=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 nyMowyhz0MJ9 for ; Mon, 2 Feb 2015 16:04:26 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8559F1A8748 for ; Mon, 2 Feb 2015 16:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52561; q=dns/txt; s=iport; t=1422921853; x=1424131453; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=9A8Ko6q9AMuI36PaJ1M37cj1sR/bkRhVZgB9F3AXN6w=; b=NQo6m2fqZcNHamLXMuYaNTr3z/CDQimBcC6Au+RYeh24hMkRpL2XCQzD G8tYT4dPXh1VpKavUkffKdWP2lpUI/u0Ljx7XHhPZysRnpt3wP4Oq98Er J1adG6eIg2VfL06aowTwkhiUByfMuyaNqFJz08kEkNU8gNGbdUvF2LBax g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BjBwDMD9BU/4YNJK1QCoJDQ1JZBIUCvS8TPIFGGQENhBiBC0oCgR1DAQEBAQF9hAwBAQEEAQEBFxMcJAELEgEIBwoBAgECIQEGKAYLFAMFAQgCBAENBQmIEAMRCAXBao5ADYVwAQEBAQEBAQEBAQEBAQEBAQEBAQEBF40/D4FIBgMBBgIBKxMNBAYBCYIkTIEwBY0mgWODToINggSBRoEXNoJNgkSFRD0Dgj2DPSKBWyccgVBvAQoBdgkXIn4BAQE X-IronPort-AV: E=Sophos;i="5.09,509,1418083200"; d="scan'208,217";a="119901948" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP; 03 Feb 2015 00:04:12 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1304CPf001907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 00:04:12 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.18]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 18:04:11 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: Dom Robinson , "bier@ietf.org" Thread-Topic: [Bier] FW: I-D Action: draft-kumar-bier-use-cases-01.txt Thread-Index: AQHQPMz+jx3swazQFUqZLUzgeYCdipzZQCoAgAImRgCAAjTogIAADfwAgAASBQCAAGWsAA== Date: Tue, 3 Feb 2015 00:04:11 +0000 Message-ID: In-Reply-To: <62A44EE9552A463F9C81E16F620C3B03@d2consulting.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.214.251] Content-Type: multipart/alternative; boundary="_000_D0F57A9461853naikumarciscocom_" MIME-Version: 1.0 Archived-At: Cc: Greg Shepherd , "IJsbrand Wijnands \(iwijnand\)" Subject: Re: [Bier] FW: I-D Action: draft-kumar-bier-use-cases-01.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 00:04:37 -0000 --_000_D0F57A9461853naikumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dom, Thanks for the text. I will work on getting it into the use case and includ= e you as co-author. Thanks, Nagendra From: Dom Robinson > Date: Monday, February 2, 2015 at 8:00 AM To: "bier@ietf.org" > Cc: Nagendra Kumar Nainar >, = Greg Shepherd >, IJsbrand Wijnand= s > Subject: Re: [Bier] FW: I-D Action: draft-kumar-bier-use-cases-01.txt Thanks Ice / Greg Ok here is my first n00b stab at extending the text. I possibly need to rea= d up on text formatting (use of brackets and terms like =91layer4=92) but p= erhaps let me share this as a way to refine the logic of what i feel could = be included. My key thinking is that we are trying to avoid specifically in= volving IGMP and MBGP while still =91allowing them=92 and yet to open up fo= r SDN / application layer control plane over-lay if a CDN operator wants to= build that and still support BIER=85 < feeling timid among such an esteemed crowd :) > =97=97 3.3. IPTV, OTT and CDN Services IPTV is a service, well known for its characteristics of allowing both live= and on-demand delivery of media traffic over Managed IP networks. Over The Top (OTT) is a similar service, well known for its characteristics= of allowing live and on-demand delivery of media traffic between IP domain= s, where the source is often on an external network relative to the receive= rs. Content Delivery Networks (CDN) operators provide layer 4 applications, and= often some degree of managed layer 3 IP network, that enable media to be s= ecurely and reliably delivered to many receivers. In some models they may p= lace applications within third party networks, or they may place those appl= ications at the edges of their own managed network peerings and similar int= er-domain connections. CDNs provide capabilities to help publishers scale t= o meet large audience demand. Their applications are not limited to audio a= nd video delivery, but may include static and dynamic web content, or optim= ized delivery for Massive Multiplayer Gaming and similar. Most publishers w= ill use a CDN for public Internet delivery, and some publishers will use a = CDN internally within their IPTV networks to resolve layer 4 complexity. In a typical IPTV environment the egress routers connecting to the receiver= s will build the tree towards the ingress router connecting to the IPTV ser= vers. The egress routers would rely on IGMP/MLD (static or dynamic) to lea= rn about the receiver's interest in one or more multicast group/channels. = Interestingly, BIER could allows provisioning any new multicast group/chann= el by only modifying the channel mapping on ingress routers. This is deeme= d beneficial for the linear IPTV video broadcasting in which every receiver= s behind every egress PE routers would receive the IPTV video traffic. With BIER, there is no need of tree building from egress to ingress. Furthe= r, any addition of new channel or new egress routers can be directly contro= lled from ingress router. When a new channel is included, the multicast gr= oup is mapped to Bit string that includes all egress routers. Ingress rout= er would start sending the new channel and deliver it to all egress routers= . As it can be observed, there is no need for static IGMP provisioning in = each egress routers whenever a new channel/stream is added. Instead, it ca= n be controlled from ingress router itself by configuring the new group to = Bit Mask mapping on ingress router. In OTT services the receivers will often be on remote domains. These receiv= ers may connect to the egress routers of a managed CDN that supports BIER. = This will enable the CDN to efficiently deliver the content to many egress = locations, in turn providing internal optimization. Where these egress routers connect directly to the Ingress BIER routers of = downstream domains then a continuity of the scaling that BIER offers could = be provided. This may rely on MBGP interoperation (or similar) between the = egress of one domain and the ingress of the next domain, or some other SDN = control plane may prove a more effective and simpler way to deploy BIER. Fo= r a single CDN operator this could be well managed in the Layer 4 applicati= ons that they provide and it may be that the initial receiver in a remote d= omain is actually an application operated by the CDN which in turn acts as = a source for the Ingress BIER router in that remote domain, and by doing so= keeps the BIER more descrete on a domain by domain basis. --- Looking forward to learning (a lot) from the feedback! Hope it is useful=85 Dom Co-Founder, Director and Creative Firestarter @ id3as-company ltd Innovation, Development, Architecture, Strategy for IT, Cloud and StreamingMedia Projects http://www.linkedin.com/in/domrobinson Contributing Editor for StreamingMedia http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm Book out now on Wiley.com =93Advanced Content Delivery, Streaming, and Clou= d Services=94 : http://bit.ly/1r1ttEG On Monday, 2 February 2015 at 11:55, IJsbrand Wijnands wrote: Hi Dom, Your email made it to the list just fine. I think your use-case makes sense. Since the content is driven from the sou= rce side, the operator can just identify the CDN=92s and push the content t= o it. What is nice is that you don=92t need to make the CDN=92s pre-join a = multicast tree in order to push the data to it. There could also be a nice = SDN user interface to it as well :-) Why don=92t you go ahead with preparing the text and we=92ll add the conten= t with you as co-author, ok? Thx, Ice. On 02 Feb 2015, at 12:05, Robinson, Dom > wrote: (Greg - I am not sure if i eventually got allowed to post this - i cant see= it in my own inbox although i did receive a mail from the BIER mailer aski= ng me to confirm, which i did.. Perhaps I have to post again: so please see comment below (assuming this ma= kes it) else can you guys perhaps forward my input to the list? Dom On 1 February 2015 at 01:23, Robinson, Dom > wrote: Hi guys - i wonder if it would be worth extending the IPTV section to embra= ce content pre-placement in not only IPTV, but OTT and even big-software up= date and other such CDN activity: I stay close to IP Multicast specifically= for this use case, and I always think it is interesting that while live/li= near is an obvious Multicast candidate, pre-placing content in many caches = that is known to be 'about to be heavily requested' is actually an extremel= y valuable capability - even if it is not live.... Just a thought. While i am a n00b to the formality of an IETF draft, if you like i would be= happy to try to extend that IPTV paragraph to try to explain that 'CDN' fo= cussed use case...? Let me know - ill try to contribute before the start of next week.... Kind regards Dom On 30 January 2015 at 21:34, Nagendra Kumar Nainar (naikumar) > wrote: Hi, Below is the updated version of BIER use case draft. Please read and share your comments. Regards, Nagendra On 1/30/15, 3:40 PM, "internet-drafts@ietf.org" > wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : BIER Use Cases > Authors : Nagendra Kumar > Rajiv Asati > Mach(Guoyi) Chen > Xiaohu Xu > Andrew Dolganow > Tony Przygienda > Arkadiy Gulko > Filename : draft-kumar-bier-use-cases-01.txt > Pages : 11 > Date : 2015-01-30 > >Abstract: > Bit Index Explicit Replication (BIER) is an architecture that > provides optimal multicast forwarding through a "BIER domain" without > requiring intermediate routers to maintain any multicast related per- > flow state. BIER also does not require any explicit tree-building > protocol for its operation. A multicast data packet enters a BIER > domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the > BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). > The BFIR router adds a BIER header to the packet. The BIER header > contains a bit-string in which each bit represents exactly one BFER > to forward the packet to. The set of BFERs to which the multicast > packet needs to be forwarded is expressed by setting the bits that > correspond to those routers in the BIER header. > > This document describes some of the use-cases for BIER. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-kumar-bier-use-cases/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-kumar-bier-use-cases-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-bier-use-cases-01 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier -- Dom Robinson Co-Founder, Director and Creative Firestarter @ id3as-company ltd Innovation, Development, Architecture, Strategy for IT, Cloud and StreamingMedia Projects uk.linkedin.com/in/domrobinson Also Contributing Editor for www.StreamingMedia.com http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm -- Dom Robinson Co-Founder, Director and Creative Firestarter @ id3as-company ltd Innovation, Development, Architecture, Strategy for IT, Cloud and StreamingMedia Projects uk.linkedin.com/in/domrobinson Also Contributing Editor for www.StreamingMedia.com http://www.streamingmediaglobal.com/Authors/4268-Dom-Robinson.htm _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier --_000_D0F57A9461853naikumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <30979059FE054B4280DBFF3D61379714@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Dom,

Thanks for the text. I will work on getting it into the use case and i= nclude you as co-author.

Thanks,
Nagendra

From: Dom Robinson <Dom@id3as.co.uk>
Date: Monday, February 2, 2015 at 8= :00 AM
To: "bier@ietf.org" <bier@i= etf.org>
Cc: Nagendra Kumar Nainar <naikumar@cisco.com>, Greg Shepherd = <gjshep@gmail.com>, IJsbrand = Wijnands <ice@cisco.com>
Subject: Re: [Bier] FW: I-D Action:= draft-kumar-bier-use-cases-01.txt

Thanks Ice / Greg

Ok here is my first n00b stab at extending the text. I possibly need t= o read up on text formatting (use of brackets and terms like =91layer4=92) = but perhaps let me share this as a way to refine the logic of what i feel c= ould be included. My key thinking is that we are trying to avoid specifically involving IGMP and MBGP while sti= ll =91allowing them=92 and yet to open up for SDN / application layer contr= ol plane over-lay if a CDN operator wants to build that and still support B= IER=85

< feeling timid among such an esteemed crowd :) >

=97=97

3.3.  IPTV, OTT and CDN Services

IPTV is a service, well known for its charact= eristics of allowing both live and on-demand delivery of media traffic over Managed IP networks.

 

Over The Top (OTT) is a similar ser= vice, well known for its characteristics of allowing live and on-demand del= ivery of media traffic between IP domains, where the source is often on an external network relative to t= he receivers.

 

Content Delivery Networks (CDN) ope= rators provide layer 4 applications, and often some degree of managed layer= 3 IP network, that enable media to be securely and reliably delivered to many receivers. In some models th= ey may place applications within third party networks, or they may place th= ose applications at the edges of their own managed network peerings and sim= ilar inter-domain connections. CDNs provide capabilities to help publishers scale to meet large audience deman= d. Their applications are not limited to audio and video delivery, but may = include static and dynamic web content, or optimized delivery for Massive M= ultiplayer Gaming and similar. Most publishers will use a CDN for public Internet delivery, and some publisher= s will use a CDN internally within their IPTV networks to resolve layer 4 c= omplexity.

 

 

In a typical IPTV environment the egress rout= ers connecting to the receivers will build the tree towards the ingress rou= ter connecting to the IPTV servers.  The egress routers would rely on IGMP/MLD (static or dynamic) to learn abo= ut the receiver's interest in one or more multicast group/channels.  I= nterestingly, BIER could allows provisioning any new multicast group/channe= l by only modifying the channel mapping on ingress routers.  This is deemed beneficial for the linear IPTV vi= deo broadcasting in which every receivers behind every egress PE routers wo= uld receive the IPTV video traffic.

 

With BIER, there is no need of tree building = from egress to ingress. Further, any addition of new channel or new egress = routers can be directly controlled from ingress router.  When a new channel is included, the multicast g= roup is mapped to Bit string that includes all egress routers.  Ingres= s router would start sending the new channel and deliver it to all egress r= outers.  As it can be observed, there is no need for static IGMP provisioning in each egress routers whenever a new ch= annel/stream is added.  Instead, it can be controlled from ingress rou= ter itself by configuring the new group to Bit Mask mapping on ingress rout= er.

 

In OTT services the receivers will = often be on remote domains. These receivers may connect to the egress route= rs of a managed CDN that supports BIER. This will enable the CDN to efficiently deliver the content to many = egress locations, in turn providing internal optimization.

 

Where these egress routers connect = directly to the Ingress BIER routers of downstream domains then a continuit= y of the scaling that BIER offers could be provided. This may rely on MBGP interoperation (or similar) betwe= en the egress of one domain and the ingress of the next domain, or some oth= er SDN control plane may prove a more effective and simpler way to deploy B= IER. For a single CDN operator this could be well managed in the Layer 4 applications that they provide and it= may be that the initial receiver in a remote domain is actually an applica= tion operated by the CDN which in turn acts as a source for the Ingress BIE= R router in that remote domain, and by doing so keeps the BIER more descrete on a domain by domain basis.<= o:p>


---


Looking forward to learning (a lot) from the feedback!

Hope it is useful=85

Dom

Co-F= ounder, Director and Creative Firestarter @ id3as-company ltd
Innovation, Developme= nt, Architecture, Strategy
for IT, Cloud and Str= eamingMedia Projects
http://www.linkedin.com/in= /domrobinson

Book out now on Wiley.com =93Advanced Content Delivery,= Streaming, and Cloud Services=94 : http://bit.ly/1r1ttEG

On Monday, 2 February 2015 at 11:55, IJsbrand = Wijnands wrote:

Hi Dom,

Your email made it to the list just fine.

I think your use-case makes sense. Since the content is driven from th= e source side, the operator can just identify the CDN=92s and push the cont= ent to it. What is nice is that you don=92t need to make the CDN=92s pre-jo= in a multicast tree in order to push the data to it. There could also be a nice SDN user interface to it as well :-= )

Why don=92t you go ahead with preparing the text and we=92ll add the c= ontent with you as co-author, ok?

Thx,

Ice.

On 02 Feb 2015, at 12:05, Robinson, Dom <Dom@id3as.co.uk> wrote:

(Greg - I am not sure if i eventually got allowed to post = this - i cant see it in my own inbox although i did receive a mail from the= BIER mailer asking me to confirm, which i did.. 

Perhaps I have to post again: so please see comment below (assuming th= is makes it) else can you guys perhaps forward my input to the list?

Dom

On 1 February 2015 at 01:23, Robinson, Dom <Dom@id3as.co.uk> wrote:
Hi guys - i wonder if it would be worth extending the IPTV= section to embrace content pre-placement in not only IPTV, but OTT and eve= n big-software update and other such CDN activity: I stay close to IP Multi= cast specifically for this use case, and I always think it is interesting that while live/linear is an obvious = Multicast candidate, pre-placing content in many caches that is known to be= 'about to be heavily requested' is actually an extremely valuable capabili= ty - even if it is not live....

Just a thought.

While i am a n00b to the formality of an IETF draft, if you like i wou= ld be happy to try to extend that IPTV paragraph to try to explain that 'CD= N' focussed use case...?

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

Kind regards 

Dom

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

Below is the updated version of BIER use case draft.

Please read and share your comments.

Regards,
Nagendra



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

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>        Title          &nb= sp;: BIER Use Cases
>        Authors         : = Nagendra Kumar
>                    &= nbsp;     Rajiv Asati
>                    &= nbsp;     Mach(Guoyi) Chen
>                    &= nbsp;     Xiaohu Xu
>                    &= nbsp;     Andrew Dolganow
>                    &= nbsp;     Tony Przygienda
>                    &= nbsp;     Arkadiy Gulko
>       Filename        : draft-= kumar-bier-use-cases-01.txt
>       Pages          &nbs= p;: 11
>       Date           = ; : 2015-01-30
>
>Abstract:
>   Bit Index Explicit Replication (BIER) is an architecture t= hat
>   provides optimal multicast forwarding through a "BIER= domain" without
>   requiring intermediate routers to maintain any multicast r= elated 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" (BFI= R), and leaves the
>   BIER domain at one or more "Bit-Forwarding Egress Rou= ters" (BFERs).
>   The BFIR router adds a BIER header to the packet.  Th= e 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 b= its that
>   correspond to those routers in the BIER header.
>
>   This document describes some of the use-cases for BIER. >
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-kumar-bier-use-c= ases/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-kumar-bier-use-cases-01
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-bier= -use-cases-01
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp:/= /ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>I-D-Announce mailing list
>I-D-Announce= @ietf.org
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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



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

Also Contributing Editor for www.StreamingMedia.com



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

Also Contributing Editor for www.StreamingMedia.com
_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org= /mailman/listinfo/bier


 --_000_D0F57A9461853naikumarciscocom_-- From nobody Fri Feb 6 15:02:21 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2281A889F for ; Fri, 6 Feb 2015 15:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTvFZFSE1f1v for ; Fri, 6 Feb 2015 15:02:17 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0521A8893 for ; Fri, 6 Feb 2015 15:02:16 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id u56so10970845wes.10 for ; Fri, 06 Feb 2015 15:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=9Dsng5Iex92Xwin1vmrddUKSLhyH8pO1fz3ldb+1oAE=; b=x1UPpGkvQc1l1Q17dffaNcZ6akajSxVWjRo76vjYyOMqlsMleAT6i4xZYgw+9miYiq NPYdH2Vck7dGjNjjPIFOfl7JhW6roGnloTZ9MsDfM8BdAVJdMc2xa8aZ0f1hvYlSZ+tj Tfiu1vT7inH8B56/GglbaKWdsNeJ+taNKCvepcQGvJprZdQxm4bGCoTqylPW1767ATy7 CvzhGHw7WDDknhgLtuXV7VcCpDP/ASWEdFWmiOW+kHb6z7baLj4XifjwKnQnXSIZZROO 0lFJ+042rq0082VdES9zeMTbv8+Q8Fw/H8axYHn2j4SVJsTZbTV7zyP11dDm22o7k+RQ GL7A== MIME-Version: 1.0 X-Received: by 10.180.90.177 with SMTP id bx17mr8167127wib.36.1423263734936; Fri, 06 Feb 2015 15:02:14 -0800 (PST) Received: by 10.180.207.180 with HTTP; Fri, 6 Feb 2015 15:02:14 -0800 (PST) In-Reply-To: <20150206230133.20880.55336.idtracker@ietfa.amsl.com> References: <20150206230133.20880.55336.idtracker@ietfa.amsl.com> Date: Fri, 6 Feb 2015 15:02:14 -0800 Message-ID: From: Greg Shepherd To: "bier@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7dd257bb0c050e7369ba Archived-At: Subject: [Bier] Fwd: New Version Notification for draft-shepherd-bier-problem-statement-02.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gjshep@gmail.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 23:02:19 -0000 --f46d043c7dd257bb0c050e7369ba Content-Type: text/plain; charset=UTF-8 Rev'd with some great input from Andrew. Cheers, Greg ---------- Forwarded message ---------- From: Date: Fri, Feb 6, 2015 at 3:01 PM Subject: New Version Notification for draft-shepherd-bier-problem-statement-02.txt To: Greg Shepherd , Andrew Dolganow < andrew.dolganow@alcatel-lucent.com>, "arkadiy.gulko@thomsonreuters.com" < arkadiy.gulko@thomsonreuters.com> A new version of I-D, draft-shepherd-bier-problem-statement-02.txt has been successfully submitted by Greg Shepherd and posted to the IETF repository. Name: draft-shepherd-bier-problem-statement Revision: 02 Title: Bit Indexed Explicit Replication (BIER) Problem Statement Document date: 2015-02-06 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-shepherd-bier-problem-statement-02.txt Status: https://datatracker.ietf.org/doc/draft-shepherd-bier-problem-statement/ Htmlized: http://tools.ietf.org/html/draft-shepherd-bier-problem-statement-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-shepherd-bier-problem-statement-02 Abstract: There is a need to simplify network operations for multicast services. Current solutions require a tree-building control plane to build and maintain end-to-end tree state per flow, impacting router state capacity and network convergence times. Multi-point tree building protocols are often considered complex to deploy and debug and may include mechanics from legacy use-cases and/or assumptions which no longer apply to the current use-cases. When multicast services are transiting a provider network through an overlay, the core network has a choice to either aggregate customer state into a minimum set of core states resulting in flooding traffic to unwanted network end-points, or to map per-customer, per-flow tree state directly into the provider core state amplifying the network-wide state problem. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --f46d043c7dd257bb0c050e7369ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rev'd with some great input from Andrew.

Cheers,
Greg

-----= ----- Forwarded message ----------
From: <= /b> <inter= net-drafts@ietf.org>
Date: Fri, Feb 6, 2015 at 3:01 PM
= Subject: New Version Notification for draft-shepherd-bier-problem-statement= -02.txt
To: Greg Shepherd <gjshep= @gmail.com>, Andrew Dolganow <andrew.dolganow@alcatel-lucent.com>, "arkadiy.gulko@thomsonreuters.= com" <arkad= iy.gulko@thomsonreuters.com>



A new version of I-D, draft-shepherd-bier-problem-statement-02.txt
has been successfully submitted by Greg Shepherd and posted to the
IETF repository.

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

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




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

The IETF Secretariat


--f46d043c7dd257bb0c050e7369ba-- From nobody Tue Feb 10 08:32:15 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DBE1A1A34 for ; Tue, 10 Feb 2015 08:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKi4sjHYlOGQ for ; Tue, 10 Feb 2015 08:32:10 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F4E1A1A40 for ; Tue, 10 Feb 2015 08:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2546; q=dns/txt; s=iport; t=1423585930; x=1424795530; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ycmWD4lK6X4/z7uvSRtF1JLCU5HNHIJbfIv87HV+HK4=; b=Uh4uGbTm3dUb3YiiGWMfcVXf0TCnlnokW8YHACSLUSjnemCqsdKhgIQh blLvOiccTZhCf7ACBwRq1w0RJnZAirkqTh5jmZWxlFMOXEQDq6lY2FOiR oBmhzE1kGFaaogcYO6Rk0T2vrmKovI3Dh7TzI3HfISCJ15BupOKtkKVpN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DpBQClMdpU/49dJa1cgwZSVQUEwGmCHAqFcQKBIEMBAQEBAQF8hA0BAQQBAQE3NB0BCBIkNwsXBAEGAwIEEwmIJAgFqkmmKAEBAQEGAQEBAQEBHI95BYQqBY8gg1GFXYEYNoJNiFuGACKDbm8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,551,1418083200"; d="scan'208";a="122271225" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP; 10 Feb 2015 16:32:09 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1AGW8PV014667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Feb 2015 16:32:09 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.147]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 10 Feb 2015 10:32:08 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: "bier@ietf.org" Thread-Topic: I-D Action: draft-kumar-bier-use-cases-02.txt Thread-Index: AQHQRT+L5f7DcNoDDESJn0kbKsAVmZzqJHyA Date: Tue, 10 Feb 2015 16:32:07 +0000 Message-ID: In-Reply-To: <20150210144029.31685.58153.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.120.171] Content-Type: text/plain; charset="us-ascii" Content-ID: <2D481FCDF0FCA9448FCA5D425504659B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Bier] FW: I-D Action: draft-kumar-bier-use-cases-02.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, 10 Feb 2015 16:32:14 -0000 Hi, Please find the updated version below. Thanks, Nagendra On 2/10/15, 9:40 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : BIER Use Cases > Authors : Nagendra Kumar > Rajiv Asati > Mach(Guoyi) Chen > Xiaohu Xu > Andrew Dolganow > Tony Przygienda > Arkadiy Gulko > Dom Robinson > Filename : draft-kumar-bier-use-cases-02.txt > Pages : 12 > Date : 2015-02-10 > >Abstract: > Bit Index Explicit Replication (BIER) is an architecture that > provides optimal multicast forwarding through a "BIER domain" without > requiring intermediate routers to maintain any multicast related per- > flow state. BIER also does not require any explicit tree-building > protocol for its operation. A multicast data packet enters a BIER > domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the > BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). > The BFIR router adds a BIER header to the packet. The BIER header > contains a bit-string in which each bit represents exactly one BFER > to forward the packet to. The set of BFERs to which the multicast > packet needs to be forwarded is expressed by setting the bits that > correspond to those routers in the BIER header. > > This document describes some of the use-cases for BIER. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-kumar-bier-use-cases/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-kumar-bier-use-cases-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-bier-use-cases-02 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Feb 11 12:44:37 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F42271A86E1 for ; Wed, 11 Feb 2015 12:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGVV46gdaV5s for ; Wed, 11 Feb 2015 12:44:31 -0800 (PST) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000111A88B0 for ; Wed, 11 Feb 2015 12:44:27 -0800 (PST) Received: by mail-yh0-f48.google.com with SMTP id t59so2568375yho.7 for ; Wed, 11 Feb 2015 12:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=pkGGKJ1Lq3TjXeXkWfyJGaC/OEs8q84uf6V5ztVF8ow=; b=MxZifx4rU0Wc7oXwVVt0VLKxMSLla81vIwVRF5Bvpuaw4PSKUgWlh9A5FFh3qswArn 4DcvrlB5S67a8n1bNxzYjnelD978sRBjVtWvMwmkgNM3WLfjK8RFZZelYlyFUqngAI4x zvEE3Uyg/7aRL9Ng2J/E3lFoCmZ7wB1CArONGRBQh72w55qOL8Sz/uvNLqAgpOYtR/1C AkgisNBB+4u5jP39tfnZolfSCGS71mGWc4BuYB94k/zSbb/J4QT5OTPRKcL7dNgvNehd TZj2nU18iHn50KhujZydSd/K/sHamgqBtCNw+rhqKXXAulJEWIyoiAxBuH+7BaLzsH6P BUYg== MIME-Version: 1.0 X-Received: by 10.170.153.8 with SMTP id u8mr449514ykc.52.1423687465973; Wed, 11 Feb 2015 12:44:25 -0800 (PST) Received: by 10.170.133.80 with HTTP; Wed, 11 Feb 2015 12:44:25 -0800 (PST) Date: Wed, 11 Feb 2015 15:44:25 -0500 Message-ID: From: Alia Atlas To: "bier@ietf.org" Content-Type: multipart/alternative; boundary=001a113a5baaae3fdd050ed61121 Archived-At: Cc: Adrian Farrel , Alvaro Retana Subject: [Bier] proposed BIER charter 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, 11 Feb 2015 20:44:36 -0000 --001a113a5baaae3fdd050ed61121 Content-Type: text/plain; charset=UTF-8 I have been working on getting a charter together for BIER with the intent of pushing for it to be chartered before the Dallas IETF. This has not yet gone through IESG review and it may have some aspects updated. Please send comments here. The charter can be found at http://datatracker.ietf.org/doc/charter-ietf-bier/ and is included below as well. WG Chairs: Greg Shepherd Tony Przygienda In conventional IP multicast forwarding, the packets of a given multicast "flow" are forwarded along a tree that has been constructed for the specific purpose of carrying that flow. This requires transit nodes to maintain state on a per-flow basis, and requires the transit nodes to participate in multicast-specific tree building protocols. The flow to which a packet belongs is determined by its IP source and destination address fields. BIER (Bit Index Explicit Replication) is an alternative method of multicast forwarding. It does not require any multicast-specific trees, and hence does not require any multicast-specific tree building protocols. Within a given "BIER domain", an ingress node encapsulates a multicast data packet in a "BIER header". The BIER header identifies the packet's egress nodes in that domain. Each possible egress node is represented by a a single bit within a bitstring; to send a packet to a particular set of egress nodes, the ingress node sets the bits for each of those egress nodes, and clears the other bits in the bistring. Each packet can then be forwarded along the unicast shortest path tree from the ingress node to the egress nodes. Thus there are no per-flow forwarding entries. Due to the particular sensitivity of adding new significant functionality into the data-plane at high link speeds, the BIER work will progress as Experimental. As described in item (9) below, the work may become Standards Track once there is sufficient experience with the benefits and downsides of the technology. BIER is initially chartered to do experimental work on this new multicast forwarding mechanism as follows: 1) BIER architecture: The WG will publish an architecture, based upon draft-wijnands-bier-architecture-04. It will include the normative algorithm for how BIER packet forwarding is done. It will specify the information that is required by a BIER header to support BIER forwarding. 2) BIER encapsulation: The working group should assume that the technology will need to be embedded in the data plane and operate at the highest packet line speeds. The WG will publish a document defining an MPLS-based encapsulation based upon draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need to have a high-quality and stable RFC for a new data-plane encapsulation, the MPLS-based encapsulation draft shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. As a secondary focus, the WG may also work on one non-MPLS data-plane encapsulation. This draft also shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. This draft must focus on and include the following details: a) What is the applicability of the encapsulation and for which use-cases is this encapsulation required? b) Does this proposed encapsulation imply any changes to the MPLS-based encapsulation? c) What design choices have been made for the encapsulation type and the included fields. d) The proposed encapsulation with considerations given to at least OAM, Class of Service, security, fragmentation, TTL. 3) Transition Mechanisms: The WG will describe how BIER can be partially deployed and still provide useful functionality. A minimum of the necessary mechanisms to support incremental deployment and/or managing different BIER mask-length compatibility may be defined. Each such mechanism must include an applicability statement to differentiate its necessity from other proposed mechanisms. 4) Applicability Statements: The WG will work on a document describing how BIER can be applied to multicast L3VPN and to EVPN. This draft will describe what mechanism is used to communicate the group membership between the ingress router and the egress routers, what scalability considerations may arise, and any deployment considerations. 5) Use Case: The WG may produce one use-case document that clearly articulates the potential benefits of BIER for different use-cases. This would be based upon draft-kumar-bier-use-cases-01. 6) OAM: The WG will describe how OAM will work in a BIER domain and what simplifications BIER offers for managing the multicast traffic. A strong preference will be given to extensions to existing protocols. 7) Management models: The WG may work on YANG models and, if needed, MIB modules to support common manageability. 8) IGP extensions. When a BIER domain falls within a "link state IGP"" network, the information needed to set up the BIER forwarding tables (e.g., the mapping between a given bit position and a given egress router) may be carried in the link state advertisements of the IGP. The link state advertisments may also carry other information related to forwarding (e.g., the IGP may support multiple topologies, in which case it may be necessary to advertise which topologies are to be used for BIER forwarding). Any necessary extensions to the IGP will be specified by the WG, in cooperation with the ISIS and OSPF WGs. 9) Deployment Experience: Once there is deployment experience, the WG will produce a document describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms. Ideally, this should also contain an analysis of the impact and benefit of the new BIER data-plane to the overall Internet architecture. This document is intended to be used to evaluate whether to recharter BIER to produce Standards Track RFCs. The BIER working group will coordinate with several different working groups and must include the relevant other working groups during working group last call on the relevant drafts. BIER will coordinate with MPLS on the MPLS-based encapsulation and associated MPLS-based OAM mechanisms. BIER will coordinate with ISIS and OSPF on extensions to flood BIER-related information. BIER will coordinate with BESS and IDR on the applicability of existing BGP-based mechanisms for providing multicast group membership information. Regards, Alia --001a113a5baaae3fdd050ed61121 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have been working on getting a charter together for BIER= with the intent of pushing for it to be chartered before the Dallas IETF.= =C2=A0 This has not yet gone through IESG review and it may have some aspec= ts updated.

Please send comments here.



WG Chairs:
=C2=A0 Tony Pr= zygienda <tonysietf@gmail.com= >


In conventional IP multicast f= orwarding, the packets of a given
multicast "flow" are = forwarded along a tree that has been constructed
for the specific= purpose of carrying that flow.=C2=A0 This requires transit
nodes= to maintain state on a per-flow basis, and requires the transit
= nodes to participate in multicast-specific tree building protocols.
The flow to which a packet belongs is determined by its IP source and
destination address fields.

BIER (Bit Inde= x Explicit Replication) is an alternative method of
multicast for= warding.=C2=A0 It does not require any multicast-specific
trees, = and hence does not require any multicast-specific tree building
p= rotocols.=C2=A0 Within a given "BIER domain", an ingress node enc= apsulates
a multicast data packet in a "BIER header".= =C2=A0 The BIER header
identifies the packet's egress nodes i= n that domain.=C2=A0 Each possible
egress node is represented by = a a single bit within a bitstring; to
send a packet to a particul= ar set of egress nodes, the ingress node
sets the bits for each o= f those egress nodes, and clears the other
bits in the bistring.= =C2=A0 Each packet can then be forwarded along the
unicast shorte= st path tree from the ingress node to the egress nodes.
Thus ther= e are no per-flow forwarding entries.

Due to the p= articular sensitivity of adding new significant
functionality int= o the data-plane at high link speeds, the BIER work
will progress= as Experimental.=C2=A0 As described in item (9) below, the
work = may become Standards Track once there is sufficient experience
wi= th the benefits and downsides of the technology.

B= IER is initially chartered to do experimental work on this new
mu= lticast forwarding mechanism as follows:

=C2=A0 = =C2=A01) BIER architecture: The WG will publish an architecture, based
=C2=A0 =C2=A0upon draft-wijnands-bier-architecture-04.=C2=A0 It will = include the
=C2=A0 =C2=A0normative algorithm for how BIER packet = forwarding is done.=C2=A0 It
=C2=A0 =C2=A0will specify the inform= ation that is required by a BIER header to
=C2=A0 =C2=A0support B= IER forwarding.

=C2=A0 =C2=A02) BIER encapsulation= : The working group should assume that the
=C2=A0 =C2=A0technolog= y will need to be embedded in the data plane and operate
=C2=A0 = =C2=A0at the highest packet line speeds.=C2=A0 The WG will publish a docume= nt
=C2=A0 =C2=A0defining an MPLS-based encapsulation based upon
=C2=A0 =C2=A0draft-wijnands-mpls-bier-encapsulation-02. Due to the= critical need
=C2=A0 =C2=A0to have a high-quality and stable RFC= for a new data-plane
=C2=A0 =C2=A0encapsulation, the MPLS-based = encapsulation draft shall wait after
=C2=A0 =C2=A0WGLC and not pr= ogress to IETF Last Call until there are two
=C2=A0 =C2=A0indepen= dent interoperable implementations.

=C2=A0 =C2=A0A= s a secondary focus, the WG may also work on one non-MPLS
=C2=A0 = =C2=A0data-plane encapsulation.=C2=A0 This draft also shall wait after WGLC=
=C2=A0 =C2=A0and not progress to IETF Last Call until there are = two independent
=C2=A0 =C2=A0interoperable implementations.=C2=A0= This draft must focus on and
=C2=A0 =C2=A0include the following = details:

=C2=A0 =C2=A0 =C2=A0 =C2=A0a) What is the= applicability of the encapsulation and for which
=C2=A0 =C2=A0 = =C2=A0 =C2=A0use-cases is this encapsulation required?

=
=C2=A0 =C2=A0 =C2=A0 =C2=A0b) Does this proposed encapsulation imply a= ny changes to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0MPLS-based encapsula= tion?

=C2=A0 =C2=A0 =C2=A0 =C2=A0c) What design ch= oices have been made for the encapsulation
=C2=A0 =C2=A0 =C2=A0 = =C2=A0type and the included fields.

=C2=A0 =C2=A0 = =C2=A0 =C2=A0d) The proposed encapsulation with considerations given to at<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0least OAM, Class of Service, security,= fragmentation, TTL.

=C2=A0 =C2=A03) Transition Me= chanisms: The WG will describe how BIER can be
=C2=A0 =C2=A0parti= ally deployed and still provide useful functionality. =C2=A0A
=C2= =A0 =C2=A0minimum of the necessary mechanisms to support incremental
<= div>=C2=A0 =C2=A0deployment and/or managing different BIER mask-length comp= atibility
=C2=A0 =C2=A0may be defined.=C2=A0 Each such mechanism = must include an applicability
=C2=A0 =C2=A0statement to different= iate its necessity from other proposed
=C2=A0 =C2=A0mechanisms.

=C2=A0 =C2=A04) Applicability Statements: The WG wi= ll work on a document
=C2=A0 =C2=A0describing how BIER can be app= lied to multicast L3VPN and to EVPN.
=C2=A0 =C2=A0This draft will= describe what mechanism is used to communicate the
=C2=A0 =C2=A0= group membership between the ingress router and the egress routers,
=C2=A0 =C2=A0what scalability considerations may arise, and any deployme= nt
=C2=A0 =C2=A0considerations.=C2=A0

= =C2=A0 =C2=A05) Use Case: The WG may produce one use-case document that cle= arly
=C2=A0 =C2=A0articulates the potential benefits of BIER for = different use-cases.
=C2=A0 =C2=A0This would be based upon draft-= kumar-bier-use-cases-01.

=C2=A0 =C2=A06) OAM: The = WG will describe how OAM will work in a BIER domain and
=C2=A0 = =C2=A0what simplifications BIER offers for managing the multicast
=C2=A0 =C2=A0traffic.=C2=A0 A strong preference will be given to extension= s to
=C2=A0 =C2=A0existing protocols.

= =C2=A0 =C2=A07) Management models: The WG may work on YANG models and, if n= eeded,
=C2=A0 =C2=A0MIB modules to support common manageability.<= /div>

=C2=A0 =C2=A08) IGP extensions.=C2=A0 When a BIER = domain falls within a "link state IGP""
=C2=A0 =C2= =A0network, the information needed to set up the BIER forwarding tables
=C2=A0 =C2=A0(e.g., the mapping between a given bit position and a g= iven egress
=C2=A0 =C2=A0router) may be carried in the link state= advertisements of the IGP.=C2=A0 The
=C2=A0 =C2=A0link state adv= ertisments may also carry other information related to
=C2=A0 =C2= =A0forwarding (e.g., the IGP may support multiple topologies, in which case=
=C2=A0 =C2=A0it may be necessary to advertise which topologies a= re to be used for BIER
=C2=A0 =C2=A0forwarding).=C2=A0 Any necess= ary extensions to the IGP will be specified by
=C2=A0 =C2=A0the W= G, in cooperation with the ISIS and OSPF WGs.

=C2= =A0 =C2=A09) Deployment Experience: Once there is deployment experience, th= e
=C2=A0 =C2=A0WG will produce a document describing the benefits= , problems, and
=C2=A0 =C2=A0trade-offs for using BIER instead of= traditional multicast
=C2=A0 =C2=A0forwarding mechanisms.=C2=A0 = Ideally, this should also contain an
=C2=A0 =C2=A0analysis of the= impact and benefit of the new BIER data-plane to
=C2=A0 =C2=A0th= e overall Internet architecture.=C2=A0 This document is intended to be
=C2=A0 =C2=A0used to evaluate whether to recharter BIER to produce St= andards
=C2=A0 =C2=A0Track RFCs.

The BIE= R working group will coordinate with several different working
gr= oups and must include the relevant other working groups during
wo= rking group last call on the relevant drafts.=C2=A0 BIER will coordinate
with MPLS on the MPLS-based encapsulation and associated MPLS-based=
OAM mechanisms.=C2=A0 BIER will coordinate with ISIS and OSPF on= extensions
to flood BIER-related information.=C2=A0 BIER will co= ordinate with BESS and
IDR on the applicability of existing BGP-b= ased mechanisms for
providing multicast group membership informat= ion.

Regards,
Alia
--001a113a5baaae3fdd050ed61121-- From nobody Wed Feb 11 19:20:58 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3683C1A1BE4 for ; Wed, 11 Feb 2015 19:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVsqBheeKMtY for ; Wed, 11 Feb 2015 19:20:48 -0800 (PST) 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 25FFC1A1BE8 for ; Wed, 11 Feb 2015 19:20:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPE60724; Thu, 12 Feb 2015 03:20:45 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Feb 2015 03:20:43 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 12 Feb 2015 11:20:39 +0800 From: Xuxiaohu To: Alia Atlas , "bier@ietf.org" Thread-Topic: [Bier] proposed BIER charter Thread-Index: AQHQRjuRN28IQ+IMmk2R5cKY4QcqFpzsTHDQ Date: Thu, 12 Feb 2015 03:20:38 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031@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.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Adrian Farrel , Alvaro Retana Subject: Re: [Bier] proposed BIER charter 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, 12 Feb 2015 03:20:53 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031NKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGhhdmUgYSBjb21tZW50IHdpdGggcmVnYXJkIHRvIHRoZSBCSUVSIGVuY2Fw c3VsYXRpb24uIFRoZXJlIHdlcmUgc29tZSBkaXNjdXNzaW9ucyBhYm91dCB0aGUgY29tcGFyaXNv biBiZXR3ZWVuIHRoZSBNUExTLWJhc2VkIEJJRVIgZW5jYXBzdWxhdGlvbiBhbmQgdGhlIG5vbi1N UExTLWJhc2VkIEJJRVIgZW5jYXBzdWxhdGlvbiBwcmV2aW91c2x5LiBIb3dldmVyLCBpdOKAmXMg dGlsbCBxdWVzdGlvbmFibGUgd2hldGhlciB0aGUgTVBMUy1iYXNlZCBvcHRpb24gaXMgYmV0dGVy IHRoYW4gdGhlIG5vbi1NUExTLWJhc2VkIG9wdGlvbiBpbmRlZWQuIElNSE8sIHRoZSBCSUVSIGxh eWVyIGlzIGV4YWN0bHkgYSB0b3RhbGx5IG5ldyBORVRXT1JLIExBWUVSIGFuZCB0aGVyZWZvcmUg dGhlIEJJRVIgaGVhZGVyIGlzIGJldHRlciB0byBiZSBkZXNpZ25lZCBhcyBhIGNvbXBsZXRlIG5l dHdvcmsgbGF5ZXIgaGVhZGVyIGZyb20gdGhlIGJlZ2lubmluZywgcmF0aGVyIHRoYW4gY291cGxp bmcgaXQgd2l0aCBhbiBNUExTIGxhYmVsIHNvIGFzIHRvIGJlIGNhcGFibGUgb2YgYWN0aW5nIGFz IGEgY29tcGxldGUgbmV0d29yayBsYXllciBoZWFkZXIsIHdoaWNoIGlzIHNwZWNpYWxseSBtZWFu aW5nZnVsIGluIHRoZSBub24tTVBMUyBuZXR3b3JrIGVudmlyb25tZW50cy4gVGhlcmVmb3JlLCBp dCBzZWVtcyBtb3JlIHJlYXNvbmFibGUgdG8gYWxsb3cgdGhlIFdHIHRvIHdvcmsgb24gdGhlIE1Q TFMtYmFzZWQgYW5kIG5vbi1NUExTLWJhc2VkIGVuY2Fwc3VsYXRpb24gb3B0aW9ucyBjb25jdXJy ZW50bHkgYW5kIHRoZW4gdG8gYWxsb3cgdGhlIFdHIG9yIHRoZSBtYXJrZXQgdG8gbWFrZSBhIGNo b2ljZSBiZXR3ZWVuIHRoZW0gbGF0dGVyLCByYXRoZXIgdGhhbiBwaWNraW5nIG9uZSBoYXN0aWx5 IHdpdGhvdXQgZGVlcGx5IGludmVzdGlnYXRpbmcgdGhlIHByb3MgYW5kIGNvbnMgb2YgZWFjaCBv cHRpb24uIEFmdGVyIGFsbCwgd2UgYXJlIGRlc2lnbmluZyBhIHRvdGFsbHkgbmV3IE5FVFdPUksg TEFZRVIgd2hpY2ggaXMgaW50ZW5kZWQgdG8gcHJvdmlkZSBzdGF0ZWxlc3MgbXVsdGljYXN0IHNl cnZpY2UsIHJhdGhlciB0aGFuIGFub3RoZXIgbmV3IGFwcGxpY2F0aW9uIG9mIHRoZSBNUExTIHRl Y2hub2xvZ3kuDQoNCkp1c3QgbXkgdHdvIGNlbnRzLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUN Cg0KRnJvbTogQklFUiBbbWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEFsaWEgQXRsYXMNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMiwgMjAxNSA0OjQ0IEFNDQpU bzogYmllckBpZXRmLm9yZw0KQ2M6IEFkcmlhbiBGYXJyZWw7IEFsdmFybyBSZXRhbmENClN1Ympl Y3Q6IFtCaWVyXSBwcm9wb3NlZCBCSUVSIGNoYXJ0ZXINCg0KSSBoYXZlIGJlZW4gd29ya2luZyBv biBnZXR0aW5nIGEgY2hhcnRlciB0b2dldGhlciBmb3IgQklFUiB3aXRoIHRoZSBpbnRlbnQgb2Yg cHVzaGluZyBmb3IgaXQgdG8gYmUgY2hhcnRlcmVkIGJlZm9yZSB0aGUgRGFsbGFzIElFVEYuICBU aGlzIGhhcyBub3QgeWV0IGdvbmUgdGhyb3VnaCBJRVNHIHJldmlldyBhbmQgaXQgbWF5IGhhdmUg c29tZSBhc3BlY3RzIHVwZGF0ZWQuDQoNClBsZWFzZSBzZW5kIGNvbW1lbnRzIGhlcmUuDQoNClRo ZSBjaGFydGVyIGNhbiBiZSBmb3VuZCBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2NoYXJ0ZXItaWV0Zi1iaWVyLw0KYW5kIGlzIGluY2x1ZGVkIGJlbG93IGFzIHdlbGwuDQoNCg0K V0cgQ2hhaXJzOg0KICBHcmVnIFNoZXBoZXJkICA8Z2pzaGVwQGdtYWlsLmNvbTxtYWlsdG86Z2pz aGVwQGdtYWlsLmNvbT4+DQogIFRvbnkgUHJ6eWdpZW5kYSA8dG9ueXNpZXRmQGdtYWlsLmNvbTxt YWlsdG86dG9ueXNpZXRmQGdtYWlsLmNvbT4+DQoNCg0KSW4gY29udmVudGlvbmFsIElQIG11bHRp Y2FzdCBmb3J3YXJkaW5nLCB0aGUgcGFja2V0cyBvZiBhIGdpdmVuDQptdWx0aWNhc3QgImZsb3ci IGFyZSBmb3J3YXJkZWQgYWxvbmcgYSB0cmVlIHRoYXQgaGFzIGJlZW4gY29uc3RydWN0ZWQNCmZv ciB0aGUgc3BlY2lmaWMgcHVycG9zZSBvZiBjYXJyeWluZyB0aGF0IGZsb3cuICBUaGlzIHJlcXVp cmVzIHRyYW5zaXQNCm5vZGVzIHRvIG1haW50YWluIHN0YXRlIG9uIGEgcGVyLWZsb3cgYmFzaXMs IGFuZCByZXF1aXJlcyB0aGUgdHJhbnNpdA0Kbm9kZXMgdG8gcGFydGljaXBhdGUgaW4gbXVsdGlj YXN0LXNwZWNpZmljIHRyZWUgYnVpbGRpbmcgcHJvdG9jb2xzLg0KVGhlIGZsb3cgdG8gd2hpY2gg YSBwYWNrZXQgYmVsb25ncyBpcyBkZXRlcm1pbmVkIGJ5IGl0cyBJUCBzb3VyY2UgYW5kDQpkZXN0 aW5hdGlvbiBhZGRyZXNzIGZpZWxkcy4NCg0KQklFUiAoQml0IEluZGV4IEV4cGxpY2l0IFJlcGxp Y2F0aW9uKSBpcyBhbiBhbHRlcm5hdGl2ZSBtZXRob2Qgb2YNCm11bHRpY2FzdCBmb3J3YXJkaW5n LiAgSXQgZG9lcyBub3QgcmVxdWlyZSBhbnkgbXVsdGljYXN0LXNwZWNpZmljDQp0cmVlcywgYW5k IGhlbmNlIGRvZXMgbm90IHJlcXVpcmUgYW55IG11bHRpY2FzdC1zcGVjaWZpYyB0cmVlIGJ1aWxk aW5nDQpwcm90b2NvbHMuICBXaXRoaW4gYSBnaXZlbiAiQklFUiBkb21haW4iLCBhbiBpbmdyZXNz IG5vZGUgZW5jYXBzdWxhdGVzDQphIG11bHRpY2FzdCBkYXRhIHBhY2tldCBpbiBhICJCSUVSIGhl YWRlciIuICBUaGUgQklFUiBoZWFkZXINCmlkZW50aWZpZXMgdGhlIHBhY2tldCdzIGVncmVzcyBu b2RlcyBpbiB0aGF0IGRvbWFpbi4gIEVhY2ggcG9zc2libGUNCmVncmVzcyBub2RlIGlzIHJlcHJl c2VudGVkIGJ5IGEgYSBzaW5nbGUgYml0IHdpdGhpbiBhIGJpdHN0cmluZzsgdG8NCnNlbmQgYSBw YWNrZXQgdG8gYSBwYXJ0aWN1bGFyIHNldCBvZiBlZ3Jlc3Mgbm9kZXMsIHRoZSBpbmdyZXNzIG5v ZGUNCnNldHMgdGhlIGJpdHMgZm9yIGVhY2ggb2YgdGhvc2UgZWdyZXNzIG5vZGVzLCBhbmQgY2xl YXJzIHRoZSBvdGhlcg0KYml0cyBpbiB0aGUgYmlzdHJpbmcuICBFYWNoIHBhY2tldCBjYW4gdGhl biBiZSBmb3J3YXJkZWQgYWxvbmcgdGhlDQp1bmljYXN0IHNob3J0ZXN0IHBhdGggdHJlZSBmcm9t IHRoZSBpbmdyZXNzIG5vZGUgdG8gdGhlIGVncmVzcyBub2Rlcy4NClRodXMgdGhlcmUgYXJlIG5v IHBlci1mbG93IGZvcndhcmRpbmcgZW50cmllcy4NCg0KRHVlIHRvIHRoZSBwYXJ0aWN1bGFyIHNl bnNpdGl2aXR5IG9mIGFkZGluZyBuZXcgc2lnbmlmaWNhbnQNCmZ1bmN0aW9uYWxpdHkgaW50byB0 aGUgZGF0YS1wbGFuZSBhdCBoaWdoIGxpbmsgc3BlZWRzLCB0aGUgQklFUiB3b3JrDQp3aWxsIHBy b2dyZXNzIGFzIEV4cGVyaW1lbnRhbC4gIEFzIGRlc2NyaWJlZCBpbiBpdGVtICg5KSBiZWxvdywg dGhlDQp3b3JrIG1heSBiZWNvbWUgU3RhbmRhcmRzIFRyYWNrIG9uY2UgdGhlcmUgaXMgc3VmZmlj aWVudCBleHBlcmllbmNlDQp3aXRoIHRoZSBiZW5lZml0cyBhbmQgZG93bnNpZGVzIG9mIHRoZSB0 ZWNobm9sb2d5Lg0KDQpCSUVSIGlzIGluaXRpYWxseSBjaGFydGVyZWQgdG8gZG8gZXhwZXJpbWVu dGFsIHdvcmsgb24gdGhpcyBuZXcNCm11bHRpY2FzdCBmb3J3YXJkaW5nIG1lY2hhbmlzbSBhcyBm b2xsb3dzOg0KDQogICAxKSBCSUVSIGFyY2hpdGVjdHVyZTogVGhlIFdHIHdpbGwgcHVibGlzaCBh biBhcmNoaXRlY3R1cmUsIGJhc2VkDQogICB1cG9uIGRyYWZ0LXdpam5hbmRzLWJpZXItYXJjaGl0 ZWN0dXJlLTA0LiAgSXQgd2lsbCBpbmNsdWRlIHRoZQ0KICAgbm9ybWF0aXZlIGFsZ29yaXRobSBm b3IgaG93IEJJRVIgcGFja2V0IGZvcndhcmRpbmcgaXMgZG9uZS4gIEl0DQogICB3aWxsIHNwZWNp ZnkgdGhlIGluZm9ybWF0aW9uIHRoYXQgaXMgcmVxdWlyZWQgYnkgYSBCSUVSIGhlYWRlciB0bw0K ICAgc3VwcG9ydCBCSUVSIGZvcndhcmRpbmcuDQoNCiAgIDIpIEJJRVIgZW5jYXBzdWxhdGlvbjog VGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGFzc3VtZSB0aGF0IHRoZQ0KICAgdGVjaG5vbG9neSB3 aWxsIG5lZWQgdG8gYmUgZW1iZWRkZWQgaW4gdGhlIGRhdGEgcGxhbmUgYW5kIG9wZXJhdGUNCiAg IGF0IHRoZSBoaWdoZXN0IHBhY2tldCBsaW5lIHNwZWVkcy4gIFRoZSBXRyB3aWxsIHB1Ymxpc2gg YSBkb2N1bWVudA0KICAgZGVmaW5pbmcgYW4gTVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9uIGJhc2Vk IHVwb24NCiAgIGRyYWZ0LXdpam5hbmRzLW1wbHMtYmllci1lbmNhcHN1bGF0aW9uLTAyLiBEdWUg dG8gdGhlIGNyaXRpY2FsIG5lZWQNCiAgIHRvIGhhdmUgYSBoaWdoLXF1YWxpdHkgYW5kIHN0YWJs ZSBSRkMgZm9yIGEgbmV3IGRhdGEtcGxhbmUNCiAgIGVuY2Fwc3VsYXRpb24sIHRoZSBNUExTLWJh c2VkIGVuY2Fwc3VsYXRpb24gZHJhZnQgc2hhbGwgd2FpdCBhZnRlcg0KICAgV0dMQyBhbmQgbm90 IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d28NCiAgIGluZGVw ZW5kZW50IGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLg0KDQogICBBcyBhIHNlY29uZGFy eSBmb2N1cywgdGhlIFdHIG1heSBhbHNvIHdvcmsgb24gb25lIG5vbi1NUExTDQogICBkYXRhLXBs YW5lIGVuY2Fwc3VsYXRpb24uICBUaGlzIGRyYWZ0IGFsc28gc2hhbGwgd2FpdCBhZnRlciBXR0xD DQogICBhbmQgbm90IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0 d28gaW5kZXBlbmRlbnQNCiAgIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLiAgVGhpcyBk cmFmdCBtdXN0IGZvY3VzIG9uIGFuZA0KICAgaW5jbHVkZSB0aGUgZm9sbG93aW5nIGRldGFpbHM6 DQoNCiAgICAgICBhKSBXaGF0IGlzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBlbmNhcHN1bGF0 aW9uIGFuZCBmb3Igd2hpY2gNCiAgICAgICB1c2UtY2FzZXMgaXMgdGhpcyBlbmNhcHN1bGF0aW9u IHJlcXVpcmVkPw0KDQogICAgICAgYikgRG9lcyB0aGlzIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24g aW1wbHkgYW55IGNoYW5nZXMgdG8gdGhlDQogICAgICAgTVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9u Pw0KDQogICAgICAgYykgV2hhdCBkZXNpZ24gY2hvaWNlcyBoYXZlIGJlZW4gbWFkZSBmb3IgdGhl IGVuY2Fwc3VsYXRpb24NCiAgICAgICB0eXBlIGFuZCB0aGUgaW5jbHVkZWQgZmllbGRzLg0KDQog ICAgICAgZCkgVGhlIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24gd2l0aCBjb25zaWRlcmF0aW9ucyBn aXZlbiB0byBhdA0KICAgICAgIGxlYXN0IE9BTSwgQ2xhc3Mgb2YgU2VydmljZSwgc2VjdXJpdHks IGZyYWdtZW50YXRpb24sIFRUTC4NCg0KICAgMykgVHJhbnNpdGlvbiBNZWNoYW5pc21zOiBUaGUg V0cgd2lsbCBkZXNjcmliZSBob3cgQklFUiBjYW4gYmUNCiAgIHBhcnRpYWxseSBkZXBsb3llZCBh bmQgc3RpbGwgcHJvdmlkZSB1c2VmdWwgZnVuY3Rpb25hbGl0eS4gIEENCiAgIG1pbmltdW0gb2Yg dGhlIG5lY2Vzc2FyeSBtZWNoYW5pc21zIHRvIHN1cHBvcnQgaW5jcmVtZW50YWwNCiAgIGRlcGxv eW1lbnQgYW5kL29yIG1hbmFnaW5nIGRpZmZlcmVudCBCSUVSIG1hc2stbGVuZ3RoIGNvbXBhdGli aWxpdHkNCiAgIG1heSBiZSBkZWZpbmVkLiAgRWFjaCBzdWNoIG1lY2hhbmlzbSBtdXN0IGluY2x1 ZGUgYW4gYXBwbGljYWJpbGl0eQ0KICAgc3RhdGVtZW50IHRvIGRpZmZlcmVudGlhdGUgaXRzIG5l Y2Vzc2l0eSBmcm9tIG90aGVyIHByb3Bvc2VkDQogICBtZWNoYW5pc21zLg0KDQogICA0KSBBcHBs aWNhYmlsaXR5IFN0YXRlbWVudHM6IFRoZSBXRyB3aWxsIHdvcmsgb24gYSBkb2N1bWVudA0KICAg ZGVzY3JpYmluZyBob3cgQklFUiBjYW4gYmUgYXBwbGllZCB0byBtdWx0aWNhc3QgTDNWUE4gYW5k IHRvIEVWUE4uDQogICBUaGlzIGRyYWZ0IHdpbGwgZGVzY3JpYmUgd2hhdCBtZWNoYW5pc20gaXMg dXNlZCB0byBjb21tdW5pY2F0ZSB0aGUNCiAgIGdyb3VwIG1lbWJlcnNoaXAgYmV0d2VlbiB0aGUg aW5ncmVzcyByb3V0ZXIgYW5kIHRoZSBlZ3Jlc3Mgcm91dGVycywNCiAgIHdoYXQgc2NhbGFiaWxp dHkgY29uc2lkZXJhdGlvbnMgbWF5IGFyaXNlLCBhbmQgYW55IGRlcGxveW1lbnQNCiAgIGNvbnNp ZGVyYXRpb25zLg0KDQogICA1KSBVc2UgQ2FzZTogVGhlIFdHIG1heSBwcm9kdWNlIG9uZSB1c2Ut Y2FzZSBkb2N1bWVudCB0aGF0IGNsZWFybHkNCiAgIGFydGljdWxhdGVzIHRoZSBwb3RlbnRpYWwg YmVuZWZpdHMgb2YgQklFUiBmb3IgZGlmZmVyZW50IHVzZS1jYXNlcy4NCiAgIFRoaXMgd291bGQg YmUgYmFzZWQgdXBvbiBkcmFmdC1rdW1hci1iaWVyLXVzZS1jYXNlcy0wMS4NCg0KICAgNikgT0FN OiBUaGUgV0cgd2lsbCBkZXNjcmliZSBob3cgT0FNIHdpbGwgd29yayBpbiBhIEJJRVIgZG9tYWlu IGFuZA0KICAgd2hhdCBzaW1wbGlmaWNhdGlvbnMgQklFUiBvZmZlcnMgZm9yIG1hbmFnaW5nIHRo ZSBtdWx0aWNhc3QNCiAgIHRyYWZmaWMuICBBIHN0cm9uZyBwcmVmZXJlbmNlIHdpbGwgYmUgZ2l2 ZW4gdG8gZXh0ZW5zaW9ucyB0bw0KICAgZXhpc3RpbmcgcHJvdG9jb2xzLg0KDQogICA3KSBNYW5h Z2VtZW50IG1vZGVsczogVGhlIFdHIG1heSB3b3JrIG9uIFlBTkcgbW9kZWxzIGFuZCwgaWYgbmVl ZGVkLA0KICAgTUlCIG1vZHVsZXMgdG8gc3VwcG9ydCBjb21tb24gbWFuYWdlYWJpbGl0eS4NCg0K ICAgOCkgSUdQIGV4dGVuc2lvbnMuICBXaGVuIGEgQklFUiBkb21haW4gZmFsbHMgd2l0aGluIGEg Imxpbmsgc3RhdGUgSUdQIiINCiAgIG5ldHdvcmssIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgdG8g c2V0IHVwIHRoZSBCSUVSIGZvcndhcmRpbmcgdGFibGVzDQogICAoZS5nLiwgdGhlIG1hcHBpbmcg YmV0d2VlbiBhIGdpdmVuIGJpdCBwb3NpdGlvbiBhbmQgYSBnaXZlbiBlZ3Jlc3MNCiAgIHJvdXRl cikgbWF5IGJlIGNhcnJpZWQgaW4gdGhlIGxpbmsgc3RhdGUgYWR2ZXJ0aXNlbWVudHMgb2YgdGhl IElHUC4gIFRoZQ0KICAgbGluayBzdGF0ZSBhZHZlcnRpc21lbnRzIG1heSBhbHNvIGNhcnJ5IG90 aGVyIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8NCiAgIGZvcndhcmRpbmcgKGUuZy4sIHRoZSBJR1Ag bWF5IHN1cHBvcnQgbXVsdGlwbGUgdG9wb2xvZ2llcywgaW4gd2hpY2ggY2FzZQ0KICAgaXQgbWF5 IGJlIG5lY2Vzc2FyeSB0byBhZHZlcnRpc2Ugd2hpY2ggdG9wb2xvZ2llcyBhcmUgdG8gYmUgdXNl ZCBmb3IgQklFUg0KICAgZm9yd2FyZGluZykuICBBbnkgbmVjZXNzYXJ5IGV4dGVuc2lvbnMgdG8g dGhlIElHUCB3aWxsIGJlIHNwZWNpZmllZCBieQ0KICAgdGhlIFdHLCBpbiBjb29wZXJhdGlvbiB3 aXRoIHRoZSBJU0lTIGFuZCBPU1BGIFdHcy4NCg0KICAgOSkgRGVwbG95bWVudCBFeHBlcmllbmNl OiBPbmNlIHRoZXJlIGlzIGRlcGxveW1lbnQgZXhwZXJpZW5jZSwgdGhlDQogICBXRyB3aWxsIHBy b2R1Y2UgYSBkb2N1bWVudCBkZXNjcmliaW5nIHRoZSBiZW5lZml0cywgcHJvYmxlbXMsIGFuZA0K ICAgdHJhZGUtb2ZmcyBmb3IgdXNpbmcgQklFUiBpbnN0ZWFkIG9mIHRyYWRpdGlvbmFsIG11bHRp Y2FzdA0KICAgZm9yd2FyZGluZyBtZWNoYW5pc21zLiAgSWRlYWxseSwgdGhpcyBzaG91bGQgYWxz byBjb250YWluIGFuDQogICBhbmFseXNpcyBvZiB0aGUgaW1wYWN0IGFuZCBiZW5lZml0IG9mIHRo ZSBuZXcgQklFUiBkYXRhLXBsYW5lIHRvDQogICB0aGUgb3ZlcmFsbCBJbnRlcm5ldCBhcmNoaXRl Y3R1cmUuICBUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGJlDQogICB1c2VkIHRvIGV2YWx1 YXRlIHdoZXRoZXIgdG8gcmVjaGFydGVyIEJJRVIgdG8gcHJvZHVjZSBTdGFuZGFyZHMNCiAgIFRy YWNrIFJGQ3MuDQoNClRoZSBCSUVSIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb29yZGluYXRlIHdpdGgg c2V2ZXJhbCBkaWZmZXJlbnQgd29ya2luZw0KZ3JvdXBzIGFuZCBtdXN0IGluY2x1ZGUgdGhlIHJl bGV2YW50IG90aGVyIHdvcmtpbmcgZ3JvdXBzIGR1cmluZw0Kd29ya2luZyBncm91cCBsYXN0IGNh bGwgb24gdGhlIHJlbGV2YW50IGRyYWZ0cy4gIEJJRVIgd2lsbCBjb29yZGluYXRlDQp3aXRoIE1Q TFMgb24gdGhlIE1QTFMtYmFzZWQgZW5jYXBzdWxhdGlvbiBhbmQgYXNzb2NpYXRlZCBNUExTLWJh c2VkDQpPQU0gbWVjaGFuaXNtcy4gIEJJRVIgd2lsbCBjb29yZGluYXRlIHdpdGggSVNJUyBhbmQg T1NQRiBvbiBleHRlbnNpb25zDQp0byBmbG9vZCBCSUVSLXJlbGF0ZWQgaW5mb3JtYXRpb24uICBC SUVSIHdpbGwgY29vcmRpbmF0ZSB3aXRoIEJFU1MgYW5kDQpJRFIgb24gdGhlIGFwcGxpY2FiaWxp dHkgb2YgZXhpc3RpbmcgQkdQLWJhc2VkIG1lY2hhbmlzbXMgZm9yDQpwcm92aWRpbmcgbXVsdGlj YXN0IGdyb3VwIG1lbWJlcnNoaXAgaW5mb3JtYXRpb24uDQoNClJlZ2FyZHMsDQpBbGlhDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031NKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBhbGws PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSBhIGNvbW1lbnQgd2l0 aCByZWdhcmQgdG8gdGhlIEJJRVIgZW5jYXBzdWxhdGlvbi4gVGhlcmUgd2VyZSBzb21lIGRpc2N1 c3Npb25zIGFib3V0IHRoZSBjb21wYXJpc29uIGJldHdlZW4gdGhlIE1QTFMtYmFzZWQgQklFUiBl bmNhcHN1bGF0aW9uDQogYW5kIHRoZSBub24tTVBMUy1iYXNlZCBCSUVSIGVuY2Fwc3VsYXRpb24g cHJldmlvdXNseS4gSG93ZXZlciwgaXTigJlzIHRpbGwgcXVlc3Rpb25hYmxlIHdoZXRoZXIgdGhl IE1QTFMtYmFzZWQgb3B0aW9uIGlzIGJldHRlciB0aGFuIHRoZSBub24tTVBMUy1iYXNlZCBvcHRp b24gaW5kZWVkLiBJTUhPLCB0aGUgQklFUiBsYXllciBpcyBleGFjdGx5IGEgdG90YWxseSBuZXcg TkVUV09SSyBMQVlFUiBhbmQgdGhlcmVmb3JlIHRoZSBCSUVSIGhlYWRlciBpcw0KIGJldHRlciB0 byBiZSBkZXNpZ25lZCBhcyBhIGNvbXBsZXRlIG5ldHdvcmsgbGF5ZXIgaGVhZGVyIGZyb20gdGhl IGJlZ2lubmluZywgcmF0aGVyIHRoYW4gY291cGxpbmcgaXQgd2l0aCBhbiBNUExTIGxhYmVsIHNv IGFzIHRvIGJlIGNhcGFibGUgb2YgYWN0aW5nIGFzIGEgY29tcGxldGUgbmV0d29yayBsYXllciBo ZWFkZXIsIHdoaWNoIGlzIHNwZWNpYWxseSBtZWFuaW5nZnVsIGluIHRoZSBub24tTVBMUyBuZXR3 b3JrIGVudmlyb25tZW50cy4gVGhlcmVmb3JlLA0KIGl0IHNlZW1zIG1vcmUgcmVhc29uYWJsZSB0 byBhbGxvdyB0aGUgV0cgdG8gd29yayBvbiB0aGUgTVBMUy1iYXNlZCBhbmQgbm9uLU1QTFMtYmFz ZWQgZW5jYXBzdWxhdGlvbiBvcHRpb25zIGNvbmN1cnJlbnRseSBhbmQgdGhlbiB0byBhbGxvdyB0 aGUgV0cgb3IgdGhlIG1hcmtldCB0byBtYWtlIGEgY2hvaWNlIGJldHdlZW4gdGhlbSBsYXR0ZXIs IHJhdGhlciB0aGFuIHBpY2tpbmcgb25lIGhhc3RpbHkgd2l0aG91dCBkZWVwbHkgaW52ZXN0aWdh dGluZw0KIHRoZSBwcm9zIGFuZCBjb25zIG9mIGVhY2ggb3B0aW9uLiBBZnRlciBhbGwsIHdlIGFy ZSBkZXNpZ25pbmcgYSB0b3RhbGx5IG5ldyBORVRXT1JLIExBWUVSIHdoaWNoIGlzIGludGVuZGVk IHRvIHByb3ZpZGUgc3RhdGVsZXNzIG11bHRpY2FzdCBzZXJ2aWNlLCByYXRoZXIgdGhhbiBhbm90 aGVyIG5ldyBhcHBsaWNhdGlvbiBvZiB0aGUgTVBMUyB0ZWNobm9sb2d5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KdXN0IG15IHR3byBjZW50cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+WGlhb2h1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJJ RVIgW21haWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFs aWEgQXRsYXM8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE1IDQ6 NDQgQU08YnI+DQo8Yj5Ubzo8L2I+IGJpZXJAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IEFkcmlh biBGYXJyZWw7IEFsdmFybyBSZXRhbmE8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0JpZXJdIHByb3Bv c2VkIEJJRVIgY2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JIGhhdmUgYmVlbiB3b3JraW5nIG9uIGdldHRpbmcgYSBjaGFydGVyIHRvZ2V0aGVyIGZvciBC SUVSIHdpdGggdGhlIGludGVudCBvZiBwdXNoaW5nIGZvciBpdCB0byBiZSBjaGFydGVyZWQgYmVm b3JlIHRoZSBEYWxsYXMgSUVURi4mbmJzcDsgVGhpcyBoYXMgbm90IHlldCBnb25lIHRocm91Z2gg SUVTRyByZXZpZXcgYW5kIGl0IG1heSBoYXZlIHNvbWUgYXNwZWN0cyB1cGRhdGVkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBzZW5kIGNvbW1lbnRzIGhl cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGNoYXJ0ZXIg Y2FuIGJlIGZvdW5kIGF0IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv Y2hhcnRlci1pZXRmLWJpZXIvIj4NCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hh cnRlci1pZXRmLWJpZXIvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5hbmQgaXMgaW5jbHVkZWQg YmVsb3cgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V0cgQ2hhaXJzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgR3JlZyBTaGVwaGVyZCAmbmJzcDsmbHQ7PGEgaHJlZj0i bWFpbHRvOmdqc2hlcEBnbWFpbC5jb20iPmdqc2hlcEBnbWFpbC5jb208L2E+Jmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgVG9ueSBQcnp5Z2llbmRhICZsdDs8YSBocmVmPSJtYWlsdG86 dG9ueXNpZXRmQGdtYWlsLmNvbSI+dG9ueXNpZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SW4gY29udmVudGlvbmFsIElQIG11bHRpY2FzdCBmb3J3YXJkaW5nLCB0aGUg cGFja2V0cyBvZiBhIGdpdmVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPm11bHRpY2FzdCAmcXVvdDtm bG93JnF1b3Q7IGFyZSBmb3J3YXJkZWQgYWxvbmcgYSB0cmVlIHRoYXQgaGFzIGJlZW4gY29uc3Ry dWN0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Zm9yIHRoZSBzcGVjaWZpYyBwdXJwb3NlIG9mIGNh cnJ5aW5nIHRoYXQgZmxvdy4mbmJzcDsgVGhpcyByZXF1aXJlcyB0cmFuc2l0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPm5vZGVzIHRvIG1haW50YWluIHN0YXRlIG9uIGEgcGVyLWZsb3cgYmFzaXMsIGFu ZCByZXF1aXJlcyB0aGUgdHJhbnNpdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5ub2RlcyB0byBwYXJ0 aWNpcGF0ZSBpbiBtdWx0aWNhc3Qtc3BlY2lmaWMgdHJlZSBidWlsZGluZyBwcm90b2NvbHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBmbG93IHRvIHdoaWNoIGEgcGFja2V0IGJlbG9uZ3MgaXMg ZGV0ZXJtaW5lZCBieSBpdHMgSVAgc291cmNlIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5kZXN0 aW5hdGlvbiBhZGRyZXNzIGZpZWxkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkJJRVIgKEJpdCBJbmRleCBFeHBsaWNpdCBSZXBsaWNhdGlvbikgaXMg YW4gYWx0ZXJuYXRpdmUgbWV0aG9kIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPm11bHRpY2FzdCBm b3J3YXJkaW5nLiZuYnNwOyBJdCBkb2VzIG5vdCByZXF1aXJlIGFueSBtdWx0aWNhc3Qtc3BlY2lm aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dHJlZXMsIGFuZCBoZW5jZSBkb2VzIG5vdCByZXF1aXJl IGFueSBtdWx0aWNhc3Qtc3BlY2lmaWMgdHJlZSBidWlsZGluZzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5wcm90b2NvbHMuJm5ic3A7IFdpdGhpbiBhIGdpdmVuICZxdW90O0JJRVIgZG9tYWluJnF1b3Q7 LCBhbiBpbmdyZXNzIG5vZGUgZW5jYXBzdWxhdGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmEgbXVs dGljYXN0IGRhdGEgcGFja2V0IGluIGEgJnF1b3Q7QklFUiBoZWFkZXImcXVvdDsuJm5ic3A7IFRo ZSBCSUVSIGhlYWRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5pZGVudGlmaWVzIHRoZSBwYWNrZXQn cyBlZ3Jlc3Mgbm9kZXMgaW4gdGhhdCBkb21haW4uJm5ic3A7IEVhY2ggcG9zc2libGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+ZWdyZXNzIG5vZGUgaXMgcmVwcmVzZW50ZWQgYnkgYSBhIHNpbmdsZSBi aXQgd2l0aGluIGEgYml0c3RyaW5nOyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5zZW5kIGEgcGFj a2V0IHRvIGEgcGFydGljdWxhciBzZXQgb2YgZWdyZXNzIG5vZGVzLCB0aGUgaW5ncmVzcyBub2Rl PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPnNldHMgdGhlIGJpdHMgZm9yIGVhY2ggb2YgdGhvc2UgZWdy ZXNzIG5vZGVzLCBhbmQgY2xlYXJzIHRoZSBvdGhlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5iaXRz IGluIHRoZSBiaXN0cmluZy4mbmJzcDsgRWFjaCBwYWNrZXQgY2FuIHRoZW4gYmUgZm9yd2FyZGVk IGFsb25nIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj51bmljYXN0IHNob3J0ZXN0IHBhdGggdHJl ZSBmcm9tIHRoZSBpbmdyZXNzIG5vZGUgdG8gdGhlIGVncmVzcyBub2Rlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+VGh1cyB0aGVyZSBhcmUgbm8gcGVyLWZsb3cgZm9yd2FyZGluZyBlbnRyaWVzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RHVlIHRvIHRo ZSBwYXJ0aWN1bGFyIHNlbnNpdGl2aXR5IG9mIGFkZGluZyBuZXcgc2lnbmlmaWNhbnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+ZnVuY3Rpb25hbGl0eSBpbnRvIHRoZSBkYXRhLXBsYW5lIGF0IGhpZ2gg bGluayBzcGVlZHMsIHRoZSBCSUVSIHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+d2lsbCBwcm9n cmVzcyBhcyBFeHBlcmltZW50YWwuJm5ic3A7IEFzIGRlc2NyaWJlZCBpbiBpdGVtICg5KSBiZWxv dywgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPndvcmsgbWF5IGJlY29tZSBTdGFuZGFyZHMgVHJh Y2sgb25jZSB0aGVyZSBpcyBzdWZmaWNpZW50IGV4cGVyaWVuY2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+d2l0aCB0aGUgYmVuZWZpdHMgYW5kIGRvd25zaWRlcyBvZiB0aGUgdGVjaG5vbG9neS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJJRVIgaXMgaW5p dGlhbGx5IGNoYXJ0ZXJlZCB0byBkbyBleHBlcmltZW50YWwgd29yayBvbiB0aGlzIG5ldzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5tdWx0aWNhc3QgZm9yd2FyZGluZyBtZWNoYW5pc20gYXMgZm9sbG93 czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyAmbmJzcDsxKSBCSUVSIGFyY2hpdGVjdHVyZTogVGhlIFdHIHdpbGwgcHVibGlzaCBhbiBhcmNo aXRlY3R1cmUsIGJhc2VkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDt1cG9uIGRy YWZ0LXdpam5hbmRzLWJpZXItYXJjaGl0ZWN0dXJlLTA0LiZuYnNwOyBJdCB3aWxsIGluY2x1ZGUg dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtub3JtYXRpdmUgYWxnb3JpdGht IGZvciBob3cgQklFUiBwYWNrZXQgZm9yd2FyZGluZyBpcyBkb25lLiZuYnNwOyBJdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7d2lsbCBzcGVjaWZ5IHRoZSBpbmZvcm1hdGlvbiB0 aGF0IGlzIHJlcXVpcmVkIGJ5IGEgQklFUiBoZWFkZXIgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7ICZuYnNwO3N1cHBvcnQgQklFUiBmb3J3YXJkaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOzIpIEJJRVIgZW5jYXBz dWxhdGlvbjogVGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGFzc3VtZSB0aGF0IHRoZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7dGVjaG5vbG9neSB3aWxsIG5lZWQgdG8gYmUgZW1i ZWRkZWQgaW4gdGhlIGRhdGEgcGxhbmUgYW5kIG9wZXJhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7ICZuYnNwO2F0IHRoZSBoaWdoZXN0IHBhY2tldCBsaW5lIHNwZWVkcy4mbmJzcDsgVGhl IFdHIHdpbGwgcHVibGlzaCBhIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAm bmJzcDtkZWZpbmluZyBhbiBNUExTLWJhc2VkIGVuY2Fwc3VsYXRpb24gYmFzZWQgdXBvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ZHJhZnQtd2lqbmFuZHMtbXBscy1iaWVyLWVu Y2Fwc3VsYXRpb24tMDIuIER1ZSB0byB0aGUgY3JpdGljYWwgbmVlZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsgJm5ic3A7dG8gaGF2ZSBhIGhpZ2gtcXVhbGl0eSBhbmQgc3RhYmxlIFJGQyBm b3IgYSBuZXcgZGF0YS1wbGFuZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ZW5j YXBzdWxhdGlvbiwgdGhlIE1QTFMtYmFzZWQgZW5jYXBzdWxhdGlvbiBkcmFmdCBzaGFsbCB3YWl0 IGFmdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtXR0xDIGFuZCBub3QgcHJv Z3Jlc3MgdG8gSUVURiBMYXN0IENhbGwgdW50aWwgdGhlcmUgYXJlIHR3bzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsgJm5ic3A7aW5kZXBlbmRlbnQgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRh dGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsgJm5ic3A7QXMgYSBzZWNvbmRhcnkgZm9jdXMsIHRoZSBXRyBtYXkgYWxzbyB3b3JrIG9u IG9uZSBub24tTVBMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ZGF0YS1wbGFu ZSBlbmNhcHN1bGF0aW9uLiZuYnNwOyBUaGlzIGRyYWZ0IGFsc28gc2hhbGwgd2FpdCBhZnRlciBX R0xDPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDthbmQgbm90IHByb2dyZXNzIHRv IElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d28gaW5kZXBlbmRlbnQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2ludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLiZu YnNwOyBUaGlzIGRyYWZ0IG11c3QgZm9jdXMgb24gYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyAmbmJzcDtpbmNsdWRlIHRoZSBmb2xsb3dpbmcgZGV0YWlsczo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2EpIFdoYXQgaXMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIGVuY2Fwc3VsYXRpb24gYW5k IGZvciB3aGljaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt1c2UtY2FzZXMgaXMgdGhpcyBlbmNhcHN1bGF0aW9uIHJlcXVpcmVkPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7YikgRG9lcyB0aGlzIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24gaW1wbHkgYW55IGNoYW5n ZXMgdG8gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O01QTFMtYmFzZWQgZW5jYXBzdWxhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2MpIFdoYXQgZGVz aWduIGNob2ljZXMgaGF2ZSBiZWVuIG1hZGUgZm9yIHRoZSBlbmNhcHN1bGF0aW9uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgYW5kIHRoZSBpbmNs dWRlZCBmaWVsZHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkKSBUaGUgcHJvcG9zZWQgZW5jYXBzdWxh dGlvbiB3aXRoIGNvbnNpZGVyYXRpb25zIGdpdmVuIHRvIGF0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xlYXN0IE9BTSwgQ2xhc3Mgb2YgU2VydmljZSwg c2VjdXJpdHksIGZyYWdtZW50YXRpb24sIFRUTC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDszKSBUcmFuc2l0aW9uIE1lY2hhbmlz bXM6IFRoZSBXRyB3aWxsIGRlc2NyaWJlIGhvdyBCSUVSIGNhbiBiZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsgJm5ic3A7cGFydGlhbGx5IGRlcGxveWVkIGFuZCBzdGlsbCBwcm92aWRlIHVz ZWZ1bCBmdW5jdGlvbmFsaXR5LiAmbmJzcDtBPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAm bmJzcDttaW5pbXVtIG9mIHRoZSBuZWNlc3NhcnkgbWVjaGFuaXNtcyB0byBzdXBwb3J0IGluY3Jl bWVudGFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtkZXBsb3ltZW50IGFuZC9v ciBtYW5hZ2luZyBkaWZmZXJlbnQgQklFUiBtYXNrLWxlbmd0aCBjb21wYXRpYmlsaXR5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDttYXkgYmUgZGVmaW5lZC4mbmJzcDsgRWFjaCBz dWNoIG1lY2hhbmlzbSBtdXN0IGluY2x1ZGUgYW4gYXBwbGljYWJpbGl0eTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsgJm5ic3A7c3RhdGVtZW50IHRvIGRpZmZlcmVudGlhdGUgaXRzIG5lY2Vz c2l0eSBmcm9tIG90aGVyIHByb3Bvc2VkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJz cDttZWNoYW5pc21zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7ICZuYnNwOzQpIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50czogVGhlIFdHIHdp bGwgd29yayBvbiBhIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtk ZXNjcmliaW5nIGhvdyBCSUVSIGNhbiBiZSBhcHBsaWVkIHRvIG11bHRpY2FzdCBMM1ZQTiBhbmQg dG8gRVZQTi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO1RoaXMgZHJhZnQgd2ls bCBkZXNjcmliZSB3aGF0IG1lY2hhbmlzbSBpcyB1c2VkIHRvIGNvbW11bmljYXRlIHRoZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7Z3JvdXAgbWVtYmVyc2hpcCBiZXR3ZWVuIHRo ZSBpbmdyZXNzIHJvdXRlciBhbmQgdGhlIGVncmVzcyByb3V0ZXJzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsgJm5ic3A7d2hhdCBzY2FsYWJpbGl0eSBjb25zaWRlcmF0aW9ucyBtYXkgYXJp c2UsIGFuZCBhbnkgZGVwbG95bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7 Y29uc2lkZXJhdGlvbnMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7NSkgVXNlIENhc2U6IFRoZSBXRyBtYXkgcHJvZHVj ZSBvbmUgdXNlLWNhc2UgZG9jdW1lbnQgdGhhdCBjbGVhcmx5PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyAmbmJzcDthcnRpY3VsYXRlcyB0aGUgcG90ZW50aWFsIGJlbmVmaXRzIG9mIEJJRVIg Zm9yIGRpZmZlcmVudCB1c2UtY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJz cDtUaGlzIHdvdWxkIGJlIGJhc2VkIHVwb24gZHJhZnQta3VtYXItYmllci11c2UtY2FzZXMtMDEu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsg Jm5ic3A7NikgT0FNOiBUaGUgV0cgd2lsbCBkZXNjcmliZSBob3cgT0FNIHdpbGwgd29yayBpbiBh IEJJRVIgZG9tYWluIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7d2hhdCBz aW1wbGlmaWNhdGlvbnMgQklFUiBvZmZlcnMgZm9yIG1hbmFnaW5nIHRoZSBtdWx0aWNhc3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO3RyYWZmaWMuJm5ic3A7IEEgc3Ryb25nIHBy ZWZlcmVuY2Ugd2lsbCBiZSBnaXZlbiB0byBleHRlbnNpb25zIHRvPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyAmbmJzcDtleGlzdGluZyBwcm90b2NvbHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7NykgTWFuYWdlbWVudCBt b2RlbHM6IFRoZSBXRyBtYXkgd29yayBvbiBZQU5HIG1vZGVscyBhbmQsIGlmIG5lZWRlZCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO01JQiBtb2R1bGVzIHRvIHN1cHBvcnQgY29t bW9uIG1hbmFnZWFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7OCkgSUdQIGV4dGVuc2lvbnMuJm5ic3A7IFdoZW4gYSBC SUVSIGRvbWFpbiBmYWxscyB3aXRoaW4gYSAmcXVvdDtsaW5rIHN0YXRlIElHUCZxdW90OyZxdW90 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7bmV0d29yaywgdGhlIGluZm9ybWF0 aW9uIG5lZWRlZCB0byBzZXQgdXAgdGhlIEJJRVIgZm9yd2FyZGluZyB0YWJsZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyhlLmcuLCB0aGUgbWFwcGluZyBiZXR3ZWVuIGEgZ2l2 ZW4gYml0IHBvc2l0aW9uIGFuZCBhIGdpdmVuIGVncmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsgJm5ic3A7cm91dGVyKSBtYXkgYmUgY2FycmllZCBpbiB0aGUgbGluayBzdGF0ZSBhZHZl cnRpc2VtZW50cyBvZiB0aGUgSUdQLiZuYnNwOyBUaGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7ICZuYnNwO2xpbmsgc3RhdGUgYWR2ZXJ0aXNtZW50cyBtYXkgYWxzbyBjYXJyeSBvdGhlciBp bmZvcm1hdGlvbiByZWxhdGVkIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtm b3J3YXJkaW5nIChlLmcuLCB0aGUgSUdQIG1heSBzdXBwb3J0IG11bHRpcGxlIHRvcG9sb2dpZXMs IGluIHdoaWNoIGNhc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2l0IG1heSBi ZSBuZWNlc3NhcnkgdG8gYWR2ZXJ0aXNlIHdoaWNoIHRvcG9sb2dpZXMgYXJlIHRvIGJlIHVzZWQg Zm9yIEJJRVI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2ZvcndhcmRpbmcpLiZu YnNwOyBBbnkgbmVjZXNzYXJ5IGV4dGVuc2lvbnMgdG8gdGhlIElHUCB3aWxsIGJlIHNwZWNpZmll ZCBieTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7dGhlIFdHLCBpbiBjb29wZXJh dGlvbiB3aXRoIHRoZSBJU0lTIGFuZCBPU1BGIFdHcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDs5KSBEZXBsb3ltZW50IEV4cGVy aWVuY2U6IE9uY2UgdGhlcmUgaXMgZGVwbG95bWVudCBleHBlcmllbmNlLCB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO1dHIHdpbGwgcHJvZHVjZSBhIGRvY3VtZW50IGRlc2Ny aWJpbmcgdGhlIGJlbmVmaXRzLCBwcm9ibGVtcywgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyAmbmJzcDt0cmFkZS1vZmZzIGZvciB1c2luZyBCSUVSIGluc3RlYWQgb2YgdHJhZGl0aW9u YWwgbXVsdGljYXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtmb3J3YXJkaW5n IG1lY2hhbmlzbXMuJm5ic3A7IElkZWFsbHksIHRoaXMgc2hvdWxkIGFsc28gY29udGFpbiBhbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7YW5hbHlzaXMgb2YgdGhlIGltcGFjdCBh bmQgYmVuZWZpdCBvZiB0aGUgbmV3IEJJRVIgZGF0YS1wbGFuZSB0bzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsgJm5ic3A7dGhlIG92ZXJhbGwgSW50ZXJuZXQgYXJjaGl0ZWN0dXJlLiZuYnNw OyBUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGJlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyAmbmJzcDt1c2VkIHRvIGV2YWx1YXRlIHdoZXRoZXIgdG8gcmVjaGFydGVyIEJJRVIgdG8g cHJvZHVjZSBTdGFuZGFyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO1RyYWNr IFJGQ3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGUgQklFUiB3b3JraW5nIGdyb3VwIHdpbGwgY29vcmRpbmF0ZSB3aXRoIHNldmVyYWwgZGlmZmVy ZW50IHdvcmtpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Z3JvdXBzIGFuZCBtdXN0IGluY2x1ZGUg dGhlIHJlbGV2YW50IG90aGVyIHdvcmtpbmcgZ3JvdXBzIGR1cmluZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj53b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiB0aGUgcmVsZXZhbnQgZHJhZnRzLiZuYnNw OyBCSUVSIHdpbGwgY29vcmRpbmF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj53aXRoIE1QTFMgb24g dGhlIE1QTFMtYmFzZWQgZW5jYXBzdWxhdGlvbiBhbmQgYXNzb2NpYXRlZCBNUExTLWJhc2VkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPk9BTSBtZWNoYW5pc21zLiZuYnNwOyBCSUVSIHdpbGwgY29vcmRp bmF0ZSB3aXRoIElTSVMgYW5kIE9TUEYgb24gZXh0ZW5zaW9uczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij50byBmbG9vZCBCSUVSLXJlbGF0ZWQgaW5mb3JtYXRpb24uJm5ic3A7IEJJRVIgd2lsbCBjb29y ZGluYXRlIHdpdGggQkVTUyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SURSIG9uIHRoZSBhcHBs aWNhYmlsaXR5IG9mIGV4aXN0aW5nIEJHUC1iYXNlZCBtZWNoYW5pc21zIGZvcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5wcm92aWRpbmcgbXVsdGljYXN0IGdyb3VwIG1lbWJlcnNoaXAgaW5mb3JtYXRp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxpYTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031NKGEML512MBSchi_-- From nobody Wed Feb 11 22:26:41 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6C91A9042 for ; Wed, 11 Feb 2015 22:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaOT7ergLvlz for ; Wed, 11 Feb 2015 22:26:37 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F471A9077 for ; Wed, 11 Feb 2015 22:26:36 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-7d-54dbe7c85df1 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E5.71.25146.8C7EBD45; Thu, 12 Feb 2015 00:37:45 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Thu, 12 Feb 2015 01:26:35 -0500 From: Antoni Przygienda To: Xuxiaohu , "bier@ietf.org" Thread-Topic: [Bier] proposed BIER charter Thread-Index: AQHQRjuQYyjkJ/or3U2D1i8/o65ffZzsrRkA///c+uA= Date: Thu, 12 Feb 2015 06:26:34 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1824AFFB@eusaamb103.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031@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.12] Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F1824AFFBeusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXSPn+7J57dDDM78ZbZYOmMPk8XW86sY HZg8Wo68ZfVYsuQnUwBTFJdNSmpOZllqkb5dAlfG8R+9zAXzgiu+Pt/P0sD4I6CLkZNDQsBE 4vTpP4wQtpjEhXvr2boYuTiEBI4wShz5tIgRwlnOKHH93nlmkCo2AQuJy9+egtkiAs4SbV8W sIDYwgKaEr2X9rBBxLUkNt5fzwRhW0m0fFsOtoFFQFXiQ+MBsHpeAW+Ju18eMkMsmMMocf/R OVaQBKdAmMShgwvBmhmBTvp+ag2YzSwgLnHryXwmiFMFJJbsgThIQkBU4uXjf6wQtpLEnNfX mCHq8yUaH3QzQywTlDg58wnLBEaRWUhGzUJSNgtJ2SxGDqC4psT6XfoQJYoSU7ofskPYGhKt c+ayI4svYGRfxchRWpxalptuZLiJERg/xyTYHHcwLvhkeYhRgINRiYf3w73bIUKsiWXFlbmH GKU5WJTEecuuHAwREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwOh72E5hbdWRg+/3ypy5dph3 ycUnt2qjLTNs8kwTuz2fPhMskti46Z3G/6wNh3IebDSXXSPw58IcXb2gY/nOKyJ4W88EPjjM 66zeVLrjq8tdldAWhUe7s5Y23l3Df+T9nUmcf48bSezfly116lOdB4P2fMcVAn671LaV6Ol8 N7ZV01yQb7dj8XIlluKMREMt5qLiRAAnUy/QgAIAAA== Archived-At: Subject: Re: [Bier] proposed BIER charter 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, 12 Feb 2015 06:26:39 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F1824AFFBeusaamb103ericsso_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PGhhdCB0eXBlPeKAnXdnIGNoYWly4oCdPg0KDQpJTUhPLCB0aGUgQklFUiBsYXllciBpcyBleGFj dGx5IGEgdG90YWxseSBuZXcgTkVUV09SSyBMQVlFUg0KW1Rvbnkgc2FpZF0gWHV4aWFvaHUsIHRo YXQgYWxsIGRlcGVuZHMgaG93IElQIGNlbnRyaWMgb25lIHNlZXMgaXQuIEl0IGNhbiBiZSBjb25z aWRlcmVkIGxheWVyIDIuNSBhcyB3ZWxsIGdpdmVuIGl0IGRvZXNu4oCZdCBldmVuIGhhdmUgdG8g Y2FycnkgSVAgZnJhbWVzLg0KYW5kIHRoZXJlZm9yZSB0aGUgQklFUiBoZWFkZXIgaXMgYmV0dGVy IHRvIGJlIGRlc2lnbmVkIGFzIGEgY29tcGxldGUgbmV0d29yayBsYXllciBoZWFkZXIgZnJvbSB0 aGUgYmVnaW5uaW5nLCByYXRoZXIgdGhhbiBjb3VwbGluZyBpdCB3aXRoIGFuIE1QTFMgbGFiZWwg c28gYXMgdG8gYmUgY2FwYWJsZSBvZiBhY3RpbmcgYXMgYSBjb21wbGV0ZSBuZXR3b3JrIGxheWVy IGhlYWRlciwgd2hpY2ggaXMgc3BlY2lhbGx5IG1lYW5pbmdmdWwgaW4gdGhlIG5vbi1NUExTIG5l dHdvcmsgZW52aXJvbm1lbnRzLiBUaGVyZWZvcmUsIGl0IHNlZW1zIG1vcmUgcmVhc29uYWJsZSB0 byBhbGxvdyB0aGUgV0cgdG8gd29yayBvbiB0aGUgTVBMUy1iYXNlZCBhbmQgbm9uLU1QTFMtYmFz ZWQgZW5jYXBzdWxhdGlvbiBvcHRpb25zIGNvbmN1cnJlbnRseQ0KW1Rvbnkgc2FpZF0gSSBkbyBO T1Qgc2VlIGFueXdoZXJlIGluIHRoZSBjaGFydGVyIHRoYXQgYm90aCBDQU5OT1QgYmUgd29ya2Vk IG9uIGNvbmN1cnJlbnRseS4gQWRkaXRpb25hbCB0aG91Z2h0IGhhcyBiZWVuIHB1dCBpbnRvIHNw ZWNpZnlpbmcgV0hBVCBhIGdlbmVyaWMgZW5jb2RpbmcgZHJhZnQgbmVlZHMgdG8gcHJvdmlkZSBm b3IgaXQgdG8gYmUgaGlnaCBxdWFsaXR5IGFuZCBJIHRoaW5rIHRoZXJlIGlzIGVub3VnaCB3b3Jr IHRvIGJlIGRvbmUgdGhlcmUuIE1QTFMgaXMgc2ltcGx5IHRoZSBtb3N0IHByYWdtYXRpYyBjaG9p Y2Ugb2YgYSBsb25nIG1hdHVyZSBMMi41IHRlY2hub2xvZ3kgdGhhdCBwcm92YWJseSBzb2x2ZXMg bWFueSBsYXJnZS1zY2FsZSBkZXBsb3ltZW50IHByb2JsZW1zLg0KDQo8L2hhdD4NCg== --_000_2E4BB27CAB87BF43B4207C0E55860F1824AFFBeusaamb103ericsso_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5v c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2lt U3VuO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwg bGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPiZsdDtoYXQgdHlwZT3igJ13ZyBjaGFpcuKAnSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5 N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JTUhPLCB0aGUgQklFUiBsYXllciBp cyBleGFjdGx5IGEgdG90YWxseSBuZXcgTkVUV09SSyBMQVlFUg0KPC9zcGFuPjwvZm9udD48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ047 Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0eWxlOml0YWxpYyI+W1Rvbnkgc2FpZF0NCjwvc3Bhbj48 L2ZvbnQ+PC9pPjwvYj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPlh1eGlhb2h1LA0KPC9zcGFuPjwvZm9udD48Yj48aT48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ047Zm9udC13ZWln aHQ6Ym9sZDtmb250LXN0eWxlOml0YWxpYyI+dGhhdCBhbGwgZGVwZW5kcyBob3cgSVAgY2VudHJp YyBvbmUgc2VlcyBpdC4gSXQgY2FuDQogYmUgY29uc2lkZXJlZCBsYXllciAyLjUgYXMgd2VsbCBn aXZlbiBpdCBkb2VzbuKAmXQgZXZlbiBoYXZlIHRvIGNhcnJ5IElQIGZyYW1lcy4gPC9zcGFuPg0K PC9mb250PjwvaT48L2I+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5hbmQgdGhlcmVmb3JlIHRoZSBCSUVSIGhlYWRlciBpcyBiZXR0ZXIgdG8g YmUgZGVzaWduZWQgYXMgYSBjb21wbGV0ZSBuZXR3b3JrIGxheWVyDQogaGVhZGVyIGZyb20gdGhl IGJlZ2lubmluZywgcmF0aGVyIHRoYW4gY291cGxpbmcgaXQgd2l0aCBhbiBNUExTIGxhYmVsIHNv IGFzIHRvIGJlIGNhcGFibGUgb2YgYWN0aW5nIGFzIGEgY29tcGxldGUgbmV0d29yayBsYXllciBo ZWFkZXIsIHdoaWNoIGlzIHNwZWNpYWxseSBtZWFuaW5nZnVsIGluIHRoZSBub24tTVBMUyBuZXR3 b3JrIGVudmlyb25tZW50cy4gVGhlcmVmb3JlLCBpdCBzZWVtcyBtb3JlIHJlYXNvbmFibGUgdG8g YWxsb3cgdGhlIFdHDQogdG8gd29yayBvbiB0aGUgTVBMUy1iYXNlZCBhbmQgbm9uLU1QTFMtYmFz ZWQgZW5jYXBzdWxhdGlvbiBvcHRpb25zIGNvbmN1cnJlbnRseSA8L3NwYW4+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO O2ZvbnQtd2VpZ2h0OmJvbGQ7Zm9udC1zdHlsZTppdGFsaWMiPltUb255IHNhaWRdIEkgZG8gTk9U IHNlZSBhbnl3aGVyZSBpbiB0aGUgY2hhcnRlcg0KIHRoYXQgYm90aCBDQU5OT1QgYmUgd29ya2Vk IG9uIGNvbmN1cnJlbnRseS4gQWRkaXRpb25hbCB0aG91Z2h0IGhhcyBiZWVuIHB1dCBpbnRvIHNw ZWNpZnlpbmcgV0hBVCBhIGdlbmVyaWMgZW5jb2RpbmcgZHJhZnQgbmVlZHMgdG8gcHJvdmlkZSBm b3IgaXQgdG8gYmUgaGlnaCBxdWFsaXR5IGFuZCBJIHRoaW5rIHRoZXJlIGlzIGVub3VnaCB3b3Jr IHRvIGJlIGRvbmUgdGhlcmUuIE1QTFMgaXMgc2ltcGx5IHRoZSBtb3N0IHByYWdtYXRpYyBjaG9p Y2UNCiBvZiBhIGxvbmcgbWF0dXJlIEwyLjUgdGVjaG5vbG9neSB0aGF0IHByb3ZhYmx5IHNvbHZl cyBtYW55IGxhcmdlLXNjYWxlIGRlcGxveW1lbnQgcHJvYmxlbXMuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZsdDsvaGF0Jmd0Ozwvc3Bhbj48L2ZvbnQ+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_2E4BB27CAB87BF43B4207C0E55860F1824AFFBeusaamb103ericsso_-- From nobody Thu Feb 12 01:28:51 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01E81A1B5A for ; Thu, 12 Feb 2015 01:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7sW1F51If7T for ; Thu, 12 Feb 2015 01:28:44 -0800 (PST) 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 B58351A1A6F for ; Thu, 12 Feb 2015 01:28:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPE92686; Thu, 12 Feb 2015 09:28:41 +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; Thu, 12 Feb 2015 09:28:34 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 12 Feb 2015 17:28:28 +0800 From: Xuxiaohu To: Antoni Przygienda , "bier@ietf.org" Thread-Topic: [Bier] proposed BIER charter Thread-Index: AQHQRjuRN28IQ+IMmk2R5cKY4QcqFpzsTHDQ//+6rgCAALQbEA== Date: Thu, 12 Feb 2015 09:28:28 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083061CE@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F1824AFFB@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1824AFFB@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.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083061CENKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Bier] proposed BIER charter 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, 12 Feb 2015 09:28:47 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083061CENKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9ueSwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIHJlc3BvbnNlLiBJZiB0aGUgV0cgaXMg aW50ZW5kZWQgdG8gd29yayBvbiBib3RoIE1QTFMtYmFzZWQgYW5kIG5vbi1NUExTLWJhc2VkIEJJ RVIgZW5jYXBzdWxhdGlvbiBzY2hlbWVzIGNvbmN1cnJlbnRseSwgSSB3b3VsZCBzdWdnZXN0IG1h a2luZyB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byB0aGUgQklFUiBlbmNhcHN1bGF0aW9uIHJlbGF0 ZWQgdGV4dDoNCg0KT0xEOg0KICAgMikgQklFUiBlbmNhcHN1bGF0aW9uOiBUaGUgd29ya2luZyBn cm91cCBzaG91bGQgYXNzdW1lIHRoYXQgdGhlDQogICB0ZWNobm9sb2d5IHdpbGwgbmVlZCB0byBi ZSBlbWJlZGRlZCBpbiB0aGUgZGF0YSBwbGFuZSBhbmQgb3BlcmF0ZQ0KICAgYXQgdGhlIGhpZ2hl c3QgcGFja2V0IGxpbmUgc3BlZWRzLiAgVGhlIFdHIHdpbGwgcHVibGlzaCBhIGRvY3VtZW50DQog ICBkZWZpbmluZyBhbiBNUExTLWJhc2VkIGVuY2Fwc3VsYXRpb24gYmFzZWQgdXBvbg0KICAgZHJh ZnQtd2lqbmFuZHMtbXBscy1iaWVyLWVuY2Fwc3VsYXRpb24tMDIuIER1ZSB0byB0aGUgY3JpdGlj YWwgbmVlZA0KICAgdG8gaGF2ZSBhIGhpZ2gtcXVhbGl0eSBhbmQgc3RhYmxlIFJGQyBmb3IgYSBu ZXcgZGF0YS1wbGFuZQ0KICAgZW5jYXBzdWxhdGlvbiwgdGhlIE1QTFMtYmFzZWQgZW5jYXBzdWxh dGlvbiBkcmFmdCBzaGFsbCB3YWl0IGFmdGVyDQogICBXR0xDIGFuZCBub3QgcHJvZ3Jlc3MgdG8g SUVURiBMYXN0IENhbGwgdW50aWwgdGhlcmUgYXJlIHR3bw0KICAgaW5kZXBlbmRlbnQgaW50ZXJv cGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMuDQoNCiAgIEFzIGEgc2Vjb25kYXJ5IGZvY3VzLCB0aGUg V0cgbWF5IGFsc28gd29yayBvbiBvbmUgbm9uLU1QTFMNCiAgIGRhdGEtcGxhbmUgZW5jYXBzdWxh dGlvbi4gIFRoaXMgZHJhZnQgYWxzbyBzaGFsbCB3YWl0IGFmdGVyIFdHTEMNCiAgIGFuZCBub3Qg cHJvZ3Jlc3MgdG8gSUVURiBMYXN0IENhbGwgdW50aWwgdGhlcmUgYXJlIHR3byBpbmRlcGVuZGVu dA0KICAgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMuICBUaGlzIGRyYWZ0IG11c3QgZm9j dXMgb24gYW5kDQogICBpbmNsdWRlIHRoZSBmb2xsb3dpbmcgZGV0YWlsczoNCg0KICAgICAgIGEp IFdoYXQgaXMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIGVuY2Fwc3VsYXRpb24gYW5kIGZvciB3 aGljaA0KICAgICAgIHVzZS1jYXNlcyBpcyB0aGlzIGVuY2Fwc3VsYXRpb24gcmVxdWlyZWQ/DQoN CiAgICAgICBiKSBEb2VzIHRoaXMgcHJvcG9zZWQgZW5jYXBzdWxhdGlvbiBpbXBseSBhbnkgY2hh bmdlcyB0byB0aGUNCiAgICAgICBNUExTLWJhc2VkIGVuY2Fwc3VsYXRpb24/DQoNCiAgICAgICBj KSBXaGF0IGRlc2lnbiBjaG9pY2VzIGhhdmUgYmVlbiBtYWRlIGZvciB0aGUgZW5jYXBzdWxhdGlv bg0KICAgICAgIHR5cGUgYW5kIHRoZSBpbmNsdWRlZCBmaWVsZHMuDQoNCiAgICAgICBkKSBUaGUg cHJvcG9zZWQgZW5jYXBzdWxhdGlvbiB3aXRoIGNvbnNpZGVyYXRpb25zIGdpdmVuIHRvIGF0DQog ICAgICAgbGVhc3QgT0FNLCBDbGFzcyBvZiBTZXJ2aWNlLCBzZWN1cml0eSwgZnJhZ21lbnRhdGlv biwgVFRMLg0KTkVXOg0KMikgQklFUiBlbmNhcHN1bGF0aW9uOiBUaGUgd29ya2luZyBncm91cCBz aG91bGQgYXNzdW1lIHRoYXQgdGhlDQogICB0ZWNobm9sb2d5IHdpbGwgbmVlZCB0byBiZSBlbWJl ZGRlZCBpbiB0aGUgZGF0YSBwbGFuZSBhbmQgb3BlcmF0ZQ0KICAgYXQgdGhlIGhpZ2hlc3QgcGFj a2V0IGxpbmUgc3BlZWRzLiAgVGhlIFdHIHdpbGwgd29yayBvbiBib3RoIE1QTFMtYmFzZWQNCmFu ZCBub24tTVBMUy1iYXNlZCBCSUVSIGVuY2Fwc3VsYXRpb24gc2NoZW1lcyBhbmQgcHVibGlzaCB0 aGUgY29ycmVzcG9uZGluZyBkb2N1bWVudHMuDQpEdWUgdG8gdGhlIGNyaXRpY2FsIG5lZWQgdG8g aGF2ZSBhIGhpZ2gtcXVhbGl0eSBhbmQgc3RhYmxlIFJGQyBmb3IgYSBuZXcgZGF0YS1wbGFuZQ0K ICAgZW5jYXBzdWxhdGlvbiwgdGhlIEJJRVIgZW5jYXBzdWxhdGlvbiBkcmFmdCBzaGFsbCB3YWl0 IGFmdGVyDQogICBXR0xDIGFuZCBub3QgcHJvZ3Jlc3MgdG8gSUVURiBMYXN0IENhbGwgdW50aWwg dGhlcmUgYXJlIHR3bw0KICAgaW5kZXBlbmRlbnQgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlv bnMuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQoNCg0KDQpGcm9tOiBBbnRvbmkgUHJ6eWdp ZW5kYSBbbWFpbHRvOmFudG9uaS5wcnp5Z2llbmRhQGVyaWNzc29uLmNvbV0NClNlbnQ6IFRodXJz ZGF5LCBGZWJydWFyeSAxMiwgMjAxNSAyOjI3IFBNDQpUbzogWHV4aWFvaHU7IGJpZXJAaWV0Zi5v cmcNClN1YmplY3Q6IFJFOiBbQmllcl0gcHJvcG9zZWQgQklFUiBjaGFydGVyDQoNCjxoYXQgdHlw ZT3igJ13ZyBjaGFpcuKAnT4NCg0KSU1ITywgdGhlIEJJRVIgbGF5ZXIgaXMgZXhhY3RseSBhIHRv dGFsbHkgbmV3IE5FVFdPUksgTEFZRVINCltUb255IHNhaWRdIFh1eGlhb2h1LCB0aGF0IGFsbCBk ZXBlbmRzIGhvdyBJUCBjZW50cmljIG9uZSBzZWVzIGl0LiBJdCBjYW4gYmUgY29uc2lkZXJlZCBs YXllciAyLjUgYXMgd2VsbCBnaXZlbiBpdCBkb2VzbuKAmXQgZXZlbiBoYXZlIHRvIGNhcnJ5IElQ IGZyYW1lcy4NCmFuZCB0aGVyZWZvcmUgdGhlIEJJRVIgaGVhZGVyIGlzIGJldHRlciB0byBiZSBk ZXNpZ25lZCBhcyBhIGNvbXBsZXRlIG5ldHdvcmsgbGF5ZXIgaGVhZGVyIGZyb20gdGhlIGJlZ2lu bmluZywgcmF0aGVyIHRoYW4gY291cGxpbmcgaXQgd2l0aCBhbiBNUExTIGxhYmVsIHNvIGFzIHRv IGJlIGNhcGFibGUgb2YgYWN0aW5nIGFzIGEgY29tcGxldGUgbmV0d29yayBsYXllciBoZWFkZXIs IHdoaWNoIGlzIHNwZWNpYWxseSBtZWFuaW5nZnVsIGluIHRoZSBub24tTVBMUyBuZXR3b3JrIGVu dmlyb25tZW50cy4gVGhlcmVmb3JlLCBpdCBzZWVtcyBtb3JlIHJlYXNvbmFibGUgdG8gYWxsb3cg dGhlIFdHIHRvIHdvcmsgb24gdGhlIE1QTFMtYmFzZWQgYW5kIG5vbi1NUExTLWJhc2VkIGVuY2Fw c3VsYXRpb24gb3B0aW9ucyBjb25jdXJyZW50bHkNCltUb255IHNhaWRdIEkgZG8gTk9UIHNlZSBh bnl3aGVyZSBpbiB0aGUgY2hhcnRlciB0aGF0IGJvdGggQ0FOTk9UIGJlIHdvcmtlZCBvbiBjb25j dXJyZW50bHkuIEFkZGl0aW9uYWwgdGhvdWdodCBoYXMgYmVlbiBwdXQgaW50byBzcGVjaWZ5aW5n IFdIQVQgYSBnZW5lcmljIGVuY29kaW5nIGRyYWZ0IG5lZWRzIHRvIHByb3ZpZGUgZm9yIGl0IHRv IGJlIGhpZ2ggcXVhbGl0eSBhbmQgSSB0aGluayB0aGVyZSBpcyBlbm91Z2ggd29yayB0byBiZSBk b25lIHRoZXJlLiBNUExTIGlzIHNpbXBseSB0aGUgbW9zdCBwcmFnbWF0aWMgY2hvaWNlIG9mIGEg bG9uZyBtYXR1cmUgTDIuNSB0ZWNobm9sb2d5IHRoYXQgcHJvdmFibHkgc29sdmVzIG1hbnkgbGFy Z2Utc2NhbGUgZGVwbG95bWVudCBwcm9ibGVtcy4NCg0KPC9oYXQ+DQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083061CENKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5DaGFyDQoJe21zby1z dHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpwLkJhbGxvb25UZXh0LCBsaS5C YWxsb29uVGV4dCwgZGl2LkJhbGxvb25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQiOw0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTrlrovkvZM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SGkgVG9ueSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhh bmtzIGEgbG90IGZvciB5b3VyIHJlc3BvbnNlLiBJZiB0aGUgV0cgaXMgaW50ZW5kZWQgdG8gd29y ayBvbiBib3RoIE1QTFMtYmFzZWQgYW5kIG5vbi1NUExTLWJhc2VkIEJJRVIgZW5jYXBzdWxhdGlv biBzY2hlbWVzIGNvbmN1cnJlbnRseSwgSQ0KIHdvdWxkIHN1Z2dlc3QgbWFraW5nIHRoZSBmb2xs b3dpbmcgY2hhbmdlIHRvIHRoZSBCSUVSIGVuY2Fwc3VsYXRpb24gcmVsYXRlZCB0ZXh0OjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PTEQ6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsy KSBCSUVSIGVuY2Fwc3VsYXRpb246IFRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBhc3N1bWUgdGhh dCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO3RlY2hub2xvZ3kgd2lsbCBuZWVkIHRvIGJlIGVtYmVk ZGVkIGluIHRoZSBkYXRhIHBsYW5lIGFuZCBvcGVyYXRlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDthdCB0 aGUgaGlnaGVzdCBwYWNrZXQgbGluZSBzcGVlZHMuJm5ic3A7IFRoZSBXRyB3aWxsIHB1Ymxpc2gg YSBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ZGVmaW5pbmcgYW4gTVBMUy1iYXNlZCBlbmNh cHN1bGF0aW9uIGJhc2VkIHVwb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2RyYWZ0LXdpam5hbmRzLW1w bHMtYmllci1lbmNhcHN1bGF0aW9uLTAyLiBEdWUgdG8gdGhlIGNyaXRpY2FsIG5lZWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7ICZuYnNwO3RvIGhhdmUgYSBoaWdoLXF1YWxpdHkgYW5kIHN0YWJsZSBSRkMgZm9yIGEg bmV3IGRhdGEtcGxhbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2VuY2Fwc3VsYXRpb24sIHRoZSBNUExT LWJhc2VkIGVuY2Fwc3VsYXRpb24gZHJhZnQgc2hhbGwgd2FpdCBhZnRlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsg Jm5ic3A7V0dMQyBhbmQgbm90IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJl IGFyZSB0d288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2luZGVwZW5kZW50IGludGVyb3BlcmFibGUgaW1w bGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO0FzIGEgc2Vjb25k YXJ5IGZvY3VzLCB0aGUgV0cgbWF5IGFsc28gd29yayBvbiBvbmUgbm9uLU1QTFM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7ICZuYnNwO2RhdGEtcGxhbmUgZW5jYXBzdWxhdGlvbi4mbmJzcDsgVGhpcyBkcmFmdCBhbHNv IHNoYWxsIHdhaXQgYWZ0ZXIgV0dMQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7YW5kIG5vdCBwcm9ncmVz cyB0byBJRVRGIExhc3QgQ2FsbCB1bnRpbCB0aGVyZSBhcmUgdHdvIGluZGVwZW5kZW50PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyAmbmJzcDtpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4mbmJzcDsgVGhpcyBk cmFmdCBtdXN0IGZvY3VzIG9uIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7aW5jbHVkZSB0aGUgZm9s bG93aW5nIGRldGFpbHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDthKSBXaGF0IGlzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBlbmNhcHN1bGF0aW9uIGFu ZCBmb3Igd2hpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dXNlLWNhc2VzIGlz IHRoaXMgZW5jYXBzdWxhdGlvbiByZXF1aXJlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2IpIERvZXMgdGhpcyBwcm9wb3NlZCBlbmNhcHN1bGF0aW9uIGlt cGx5IGFueSBjaGFuZ2VzIHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtN UExTLWJhc2VkIGVuY2Fwc3VsYXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtjKSBXaGF0IGRlc2lnbiBjaG9pY2VzIGhhdmUgYmVlbiBtYWRlIGZvciB0 aGUgZW5jYXBzdWxhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIGFu ZCB0aGUgaW5jbHVkZWQgZmllbGRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ZCkgVGhlIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24gd2l0aCBjb25zaWRlcmF0 aW9ucyBnaXZlbiB0byBhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFzdCBP QU0sIENsYXNzIG9mIFNlcnZpY2UsIHNlY3VyaXR5LCBmcmFnbWVudGF0aW9uLCBUVEwuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ORVc6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjI0LjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjIpIEJJRVIgZW5jYXBzdWxhdGlvbjogVGhlIHdvcmtpbmcgZ3Jv dXAgc2hvdWxkIGFzc3VtZSB0aGF0IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7dGVjaG5vbG9neSB3 aWxsIG5lZWQgdG8gYmUgZW1iZWRkZWQgaW4gdGhlIGRhdGEgcGxhbmUgYW5kIG9wZXJhdGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7ICZuYnNwO2F0IHRoZSBoaWdoZXN0IHBhY2tldCBsaW5lIHNwZWVkcy4mbmJzcDsg VGhlIFdHIHdpbGwgd29yayBvbiBib3RoIE1QTFMtYmFzZWQNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDozMC4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5hbmQgbm9uLU1QTFMtYmFzZWQgQklFUiBlbmNhcHN1bGF0aW9uIHNjaGVt ZXMgYW5kIHB1Ymxpc2ggdGhlIGNvcnJlc3BvbmRpbmcgZG9jdW1lbnRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDoyNC4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIj5EdWUgdG8gdGhlIGNyaXRpY2FsIG5lZWQgdG8gaGF2ZSBhIGhp Z2gtcXVhbGl0eSBhbmQgc3RhYmxlIFJGQyBmb3IgYSBuZXcgZGF0YS1wbGFuZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsgJm5ic3A7ZW5jYXBzdWxhdGlvbiwgdGhlIEJJRVIgZW5jYXBzdWxhdGlvbiBkcmFmdCBzaGFs bCB3YWl0IGFmdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtXR0xDIGFuZCBub3QgcHJvZ3Jlc3MgdG8g SUVURiBMYXN0IENhbGwgdW50aWwgdGhlcmUgYXJlIHR3bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7aW5k ZXBlbmRlbnQgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFu dG9uaSBQcnp5Z2llbmRhIFttYWlsdG86YW50b25pLnByenlnaWVuZGFAZXJpY3Nzb24uY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxMiwgMjAxNSAyOjI3IFBNPGJy Pg0KPGI+VG86PC9iPiBYdXhpYW9odTsgYmllckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogW0JpZXJdIHByb3Bvc2VkIEJJRVIgY2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7aGF0 IHR5cGU94oCdd2cgY2hhaXLigJ0mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPklNSE8sIHRoZSBCSUVSIGxheWVyIGlzIGV4YWN0bHkgYSB0b3RhbGx5IG5ldyBORVRXT1JL IExBWUVSDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PltUb255IHNhaWRdDQo8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlh1eGlhb2h1LA0KPC9zcGFuPjxiPjxpPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhhdCBh bGwgZGVwZW5kcyBob3cgSVAgY2VudHJpYyBvbmUgc2VlcyBpdC4gSXQgY2FuIGJlIGNvbnNpZGVy ZWQgbGF5ZXIgMi41IGFzIHdlbGwgZ2l2ZW4gaXQgZG9lc27igJl0IGV2ZW4gaGF2ZSB0byBjYXJy eSBJUCBmcmFtZXMuDQo8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+YW5kIHRoZXJlZm9yZSB0aGUgQklFUiBoZWFkZXIgaXMgYmV0dGVyIHRv IGJlIGRlc2lnbmVkIGFzIGEgY29tcGxldGUgbmV0d29yayBsYXllciBoZWFkZXIgZnJvbSB0aGUg YmVnaW5uaW5nLCByYXRoZXIgdGhhbiBjb3VwbGluZyBpdCB3aXRoIGFuIE1QTFMNCiBsYWJlbCBz byBhcyB0byBiZSBjYXBhYmxlIG9mIGFjdGluZyBhcyBhIGNvbXBsZXRlIG5ldHdvcmsgbGF5ZXIg aGVhZGVyLCB3aGljaCBpcyBzcGVjaWFsbHkgbWVhbmluZ2Z1bCBpbiB0aGUgbm9uLU1QTFMgbmV0 d29yayBlbnZpcm9ubWVudHMuIFRoZXJlZm9yZSwgaXQgc2VlbXMgbW9yZSByZWFzb25hYmxlIHRv IGFsbG93IHRoZSBXRyB0byB3b3JrIG9uIHRoZSBNUExTLWJhc2VkIGFuZCBub24tTVBMUy1iYXNl ZCBlbmNhcHN1bGF0aW9uIG9wdGlvbnMNCiBjb25jdXJyZW50bHkgPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVG9ueSBzYWlkXSBJIGRvIE5PVCBzZWUg YW55d2hlcmUgaW4gdGhlIGNoYXJ0ZXIgdGhhdCBib3RoIENBTk5PVCBiZSB3b3JrZWQgb24gY29u Y3VycmVudGx5LiBBZGRpdGlvbmFsIHRob3VnaHQgaGFzIGJlZW4gcHV0IGludG8gc3BlY2lmeWlu Zw0KIFdIQVQgYSBnZW5lcmljIGVuY29kaW5nIGRyYWZ0IG5lZWRzIHRvIHByb3ZpZGUgZm9yIGl0 IHRvIGJlIGhpZ2ggcXVhbGl0eSBhbmQgSSB0aGluayB0aGVyZSBpcyBlbm91Z2ggd29yayB0byBi ZSBkb25lIHRoZXJlLiBNUExTIGlzIHNpbXBseSB0aGUgbW9zdCBwcmFnbWF0aWMgY2hvaWNlIG9m IGEgbG9uZyBtYXR1cmUgTDIuNSB0ZWNobm9sb2d5IHRoYXQgcHJvdmFibHkgc29sdmVzIG1hbnkg bGFyZ2Utc2NhbGUgZGVwbG95bWVudCBwcm9ibGVtcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZsdDsvaGF0Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083061CENKGEML512MBSchi_-- From nobody Thu Feb 12 05:04:33 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8771A8A01; Wed, 11 Feb 2015 13:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TIgHhX3lmOr0; Wed, 11 Feb 2015 13:07:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DD91A8958; Wed, 11 Feb 2015 13:07:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211210741.10579.19687.idtracker@ietfa.amsl.com> Date: Wed, 11 Feb 2015 13:07:41 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Thu, 12 Feb 2015 05:04:31 -0800 Subject: [Bier] Telechat update notice: X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 21:08:02 -0000 Placed on agenda for telechat - 2015-02-19 ID Tracker URL: http://datatracker.ietf.org/doc/charter-ietf-bier/ From nobody Thu Feb 12 05:45:39 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658841A8844; Thu, 12 Feb 2015 05:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUFGH0RGnXxt; Thu, 12 Feb 2015 05:44:55 -0800 (PST) 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 E26651A87D7; Thu, 12 Feb 2015 05:44:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23746; q=dns/txt; s=iport; t=1423748687; x=1424958287; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=WgNFMXmfy3Xzgdx6cC030qyIUJDrnA5e56f8Bpftg1o=; b=PTiTOCNfvJoxJyCajv7fxIQNKLGNqywvVMIZhucG41M3dQiyRc5KDYAC ibKnQa2TJrIq2I6OJvAW82LFVSbQOWEZRkIiqiQd5jYUJVXdNHlsLTaFw Pfa2OiCq2BNW4K+E6YVWVNAbMLQGXs1Z4zE2afmes6PrullcwJ6bFUT1/ Q=; X-IronPort-AV: E=Sophos;i="5.09,565,1418083200"; d="scan'208,217";a="343342597" 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; 12 Feb 2015 13:44:45 +0000 Received: from [64.103.108.91] (dhcp-bdlk10-data-vlan301-64-103-108-91.cisco.com [64.103.108.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1CDijY3020776; Thu, 12 Feb 2015 13:44:45 GMT Message-ID: <54DCAE4F.8050903@cisco.com> Date: Thu, 12 Feb 2015 13:44:47 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alia Atlas , "bier@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070503060100000803070602" Archived-At: Cc: Adrian Farrel , "iesg@ietf.org" , Alvaro Retana Subject: Re: [Bier] proposed BIER charter X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 13:45:22 -0000 This is a multi-part message in MIME format. --------------070503060100000803070602 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Alia I think that you are crossing far too many bridges before you get to them in terms of you expectation of where BIER will be deployed and how it will be implemented. The charter should not include such specific assumptions, particularly given the fast moving changes that are happening in our industry especially in the area of packet forwarding design. I have not seen such assumptions in other charters and I don't think that they have a place in this one. In terms of choice of document stream (experimental vs PS), that is a decision that can be taken at the time of publication when more information will be available in terms of potential market take-up, expected/actual deployment scenarios, breadth of implementation and implementation experience. Whilst this technology may be deployed in the Internet core, it my also be deployed at the edge where a much lower threshold is applicable. I fear that by introducing these caveats the IETF is entrenching the perception that it slows technology down rather than embracing and encouraging innovation. I would therefore suggest removing the text on implementation styles and document stream constraints. - Stewart On 11/02/2015 20:44, Alia Atlas wrote: > I have been working on getting a charter together for BIER with the > intent of pushing for it to be chartered before the Dallas IETF. This > has not yet gone through IESG review and it may have some aspects > updated. > > Please send comments here. > > The charter can be found at > http://datatracker.ietf.org/doc/charter-ietf-bier/ > and is included below as well. > > > WG Chairs: > Greg Shepherd > > Tony Przygienda > > > > In conventional IP multicast forwarding, the packets of a given > multicast "flow" are forwarded along a tree that has been constructed > for the specific purpose of carrying that flow. This requires transit > nodes to maintain state on a per-flow basis, and requires the transit > nodes to participate in multicast-specific tree building protocols. > The flow to which a packet belongs is determined by its IP source and > destination address fields. > > BIER (Bit Index Explicit Replication) is an alternative method of > multicast forwarding. It does not require any multicast-specific > trees, and hence does not require any multicast-specific tree building > protocols. Within a given "BIER domain", an ingress node encapsulates > a multicast data packet in a "BIER header". The BIER header > identifies the packet's egress nodes in that domain. Each possible > egress node is represented by a a single bit within a bitstring; to > send a packet to a particular set of egress nodes, the ingress node > sets the bits for each of those egress nodes, and clears the other > bits in the bistring. Each packet can then be forwarded along the > unicast shortest path tree from the ingress node to the egress nodes. > Thus there are no per-flow forwarding entries. > > Due to the particular sensitivity of adding new significant > functionality into the data-plane at high link speeds, the BIER work > will progress as Experimental. As described in item (9) below, the > work may become Standards Track once there is sufficient experience > with the benefits and downsides of the technology. > > BIER is initially chartered to do experimental work on this new > multicast forwarding mechanism as follows: > > 1) BIER architecture: The WG will publish an architecture, based > upon draft-wijnands-bier-architecture-04. It will include the > normative algorithm for how BIER packet forwarding is done. It > will specify the information that is required by a BIER header to > support BIER forwarding. > > 2) BIER encapsulation: The working group should assume that the > technology will need to be embedded in the data plane and operate > at the highest packet line speeds. The WG will publish a document > defining an MPLS-based encapsulation based upon > draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need > to have a high-quality and stable RFC for a new data-plane > encapsulation, the MPLS-based encapsulation draft shall wait after > WGLC and not progress to IETF Last Call until there are two > independent interoperable implementations. > > As a secondary focus, the WG may also work on one non-MPLS > data-plane encapsulation. This draft also shall wait after WGLC > and not progress to IETF Last Call until there are two independent > interoperable implementations. This draft must focus on and > include the following details: > > a) What is the applicability of the encapsulation and for which > use-cases is this encapsulation required? > > b) Does this proposed encapsulation imply any changes to the > MPLS-based encapsulation? > > c) What design choices have been made for the encapsulation > type and the included fields. > > d) The proposed encapsulation with considerations given to at > least OAM, Class of Service, security, fragmentation, TTL. > > 3) Transition Mechanisms: The WG will describe how BIER can be > partially deployed and still provide useful functionality. A > minimum of the necessary mechanisms to support incremental > deployment and/or managing different BIER mask-length compatibility > may be defined. Each such mechanism must include an applicability > statement to differentiate its necessity from other proposed > mechanisms. > > 4) Applicability Statements: The WG will work on a document > describing how BIER can be applied to multicast L3VPN and to EVPN. > This draft will describe what mechanism is used to communicate the > group membership between the ingress router and the egress routers, > what scalability considerations may arise, and any deployment > considerations. > > 5) Use Case: The WG may produce one use-case document that clearly > articulates the potential benefits of BIER for different use-cases. > This would be based upon draft-kumar-bier-use-cases-01. > > 6) OAM: The WG will describe how OAM will work in a BIER domain and > what simplifications BIER offers for managing the multicast > traffic. A strong preference will be given to extensions to > existing protocols. > > 7) Management models: The WG may work on YANG models and, if needed, > MIB modules to support common manageability. > > 8) IGP extensions. When a BIER domain falls within a "link state IGP"" > network, the information needed to set up the BIER forwarding tables > (e.g., the mapping between a given bit position and a given egress > router) may be carried in the link state advertisements of the > IGP. The > link state advertisments may also carry other information related to > forwarding (e.g., the IGP may support multiple topologies, in which > case > it may be necessary to advertise which topologies are to be used > for BIER > forwarding). Any necessary extensions to the IGP will be specified by > the WG, in cooperation with the ISIS and OSPF WGs. > > 9) Deployment Experience: Once there is deployment experience, the > WG will produce a document describing the benefits, problems, and > trade-offs for using BIER instead of traditional multicast > forwarding mechanisms. Ideally, this should also contain an > analysis of the impact and benefit of the new BIER data-plane to > the overall Internet architecture. This document is intended to be > used to evaluate whether to recharter BIER to produce Standards > Track RFCs. > > The BIER working group will coordinate with several different working > groups and must include the relevant other working groups during > working group last call on the relevant drafts. BIER will coordinate > with MPLS on the MPLS-based encapsulation and associated MPLS-based > OAM mechanisms. BIER will coordinate with ISIS and OSPF on extensions > to flood BIER-related information. BIER will coordinate with BESS and > IDR on the applicability of existing BGP-based mechanisms for > providing multicast group membership information. > > Regards, > Alia > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------070503060100000803070602 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Alia

I think that you are crossing far too many bridges before you get to them
in terms of you expectation of where BIER will be deployed and how
it will be implemented.

The charter should not include such specific assumptions, particularly
given the fast moving changes that are happening in our industry
especially in the area of packet forwarding design.

I have not seen such assumptions in other charters and I don't think
that they have a place in this one.

In terms of choice of document stream (experimental vs PS),
that is a decision that can be taken at the time of publication
when more information will be available in terms of potential
market take-up, expected/actual deployment scenarios,
breadth of implementation and implementation experience.

Whilst this technology may be deployed in the Internet core,
it my also be deployed at the edge where a much lower threshold
is applicable.

I fear that by introducing these caveats the IETF is entrenching the
perception that it slows technology down rather than embracing
and encouraging innovation.

I would therefore suggest removing the text on implementation
styles and document stream constraints.

- Stewart

On 11/02/2015 20:44, Alia Atlas wrote:
I have been working on getting a charter together for BIER with the intent of pushing for it to be chartered before the Dallas IETF.  This has not yet gone through IESG review and it may have some aspects updated.

Please send comments here.

and is included below as well.


WG Chairs:
  Greg Shepherd  <gjshep@gmail.com>
  Tony Przygienda <tonysietf@gmail.com>


In conventional IP multicast forwarding, the packets of a given
multicast "flow" are forwarded along a tree that has been constructed
for the specific purpose of carrying that flow.  This requires transit
nodes to maintain state on a per-flow basis, and requires the transit
nodes to participate in multicast-specific tree building protocols.
The flow to which a packet belongs is determined by its IP source and
destination address fields.

BIER (Bit Index Explicit Replication) is an alternative method of
multicast forwarding.  It does not require any multicast-specific
trees, and hence does not require any multicast-specific tree building
protocols.  Within a given "BIER domain", an ingress node encapsulates
a multicast data packet in a "BIER header".  The BIER header
identifies the packet's egress nodes in that domain.  Each possible
egress node is represented by a a single bit within a bitstring; to
send a packet to a particular set of egress nodes, the ingress node
sets the bits for each of those egress nodes, and clears the other
bits in the bistring.  Each packet can then be forwarded along the
unicast shortest path tree from the ingress node to the egress nodes.
Thus there are no per-flow forwarding entries.

Due to the particular sensitivity of adding new significant
functionality into the data-plane at high link speeds, the BIER work
will progress as Experimental.  As described in item (9) below, the
work may become Standards Track once there is sufficient experience
with the benefits and downsides of the technology.

BIER is initially chartered to do experimental work on this new
multicast forwarding mechanism as follows:

   1) BIER architecture: The WG will publish an architecture, based
   upon draft-wijnands-bier-architecture-04.  It will include the
   normative algorithm for how BIER packet forwarding is done.  It
   will specify the information that is required by a BIER header to
   support BIER forwarding.

   2) BIER encapsulation: The working group should assume that the
   technology will need to be embedded in the data plane and operate
   at the highest packet line speeds.  The WG will publish a document
   defining an MPLS-based encapsulation based upon
   draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need
   to have a high-quality and stable RFC for a new data-plane
   encapsulation, the MPLS-based encapsulation draft shall wait after
   WGLC and not progress to IETF Last Call until there are two
   independent interoperable implementations.

   As a secondary focus, the WG may also work on one non-MPLS
   data-plane encapsulation.  This draft also shall wait after WGLC
   and not progress to IETF Last Call until there are two independent
   interoperable implementations.  This draft must focus on and
   include the following details:

       a) What is the applicability of the encapsulation and for which
       use-cases is this encapsulation required?

       b) Does this proposed encapsulation imply any changes to the
       MPLS-based encapsulation?

       c) What design choices have been made for the encapsulation
       type and the included fields.

       d) The proposed encapsulation with considerations given to at
       least OAM, Class of Service, security, fragmentation, TTL.

   3) Transition Mechanisms: The WG will describe how BIER can be
   partially deployed and still provide useful functionality.  A
   minimum of the necessary mechanisms to support incremental
   deployment and/or managing different BIER mask-length compatibility
   may be defined.  Each such mechanism must include an applicability
   statement to differentiate its necessity from other proposed
   mechanisms.

   4) Applicability Statements: The WG will work on a document
   describing how BIER can be applied to multicast L3VPN and to EVPN.
   This draft will describe what mechanism is used to communicate the
   group membership between the ingress router and the egress routers,
   what scalability considerations may arise, and any deployment
   considerations. 

   5) Use Case: The WG may produce one use-case document that clearly
   articulates the potential benefits of BIER for different use-cases.
   This would be based upon draft-kumar-bier-use-cases-01.

   6) OAM: The WG will describe how OAM will work in a BIER domain and
   what simplifications BIER offers for managing the multicast
   traffic.  A strong preference will be given to extensions to
   existing protocols.

   7) Management models: The WG may work on YANG models and, if needed,
   MIB modules to support common manageability.

   8) IGP extensions.  When a BIER domain falls within a "link state IGP""
   network, the information needed to set up the BIER forwarding tables
   (e.g., the mapping between a given bit position and a given egress
   router) may be carried in the link state advertisements of the IGP.  The
   link state advertisments may also carry other information related to
   forwarding (e.g., the IGP may support multiple topologies, in which case
   it may be necessary to advertise which topologies are to be used for BIER
   forwarding).  Any necessary extensions to the IGP will be specified by
   the WG, in cooperation with the ISIS and OSPF WGs.

   9) Deployment Experience: Once there is deployment experience, the
   WG will produce a document describing the benefits, problems, and
   trade-offs for using BIER instead of traditional multicast
   forwarding mechanisms.  Ideally, this should also contain an
   analysis of the impact and benefit of the new BIER data-plane to
   the overall Internet architecture.  This document is intended to be
   used to evaluate whether to recharter BIER to produce Standards
   Track RFCs.

The BIER working group will coordinate with several different working
groups and must include the relevant other working groups during
working group last call on the relevant drafts.  BIER will coordinate
with MPLS on the MPLS-based encapsulation and associated MPLS-based
OAM mechanisms.  BIER will coordinate with ISIS and OSPF on extensions
to flood BIER-related information.  BIER will coordinate with BESS and
IDR on the applicability of existing BGP-based mechanisms for
providing multicast group membership information.

Regards,
Alia


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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------070503060100000803070602-- From nobody Thu Feb 12 06:51:40 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704351A8BB5 for ; Thu, 12 Feb 2015 06:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQjacL8OhOS8 for ; Thu, 12 Feb 2015 06:51:29 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA2C41A8AB7 for ; Thu, 12 Feb 2015 06:50:43 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id c41so4831043yho.2 for ; Thu, 12 Feb 2015 06:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ab5lK3FdJD8n5+3+6OW4jtNPnr12taVbliehVmLkM5w=; b=TNgPaKwlAegjX1K3/gvYktWeB1X2AaGC4l+kUvnKtt7zHS6gf/1AZhi6XY6xh/0r07 vwWxw25OsHdUaISQPXFPpHqF4nCX7FlJcYCZVHafxExSFaho80xZoPiRLzXS8NWAoJvI fj7hErRQfWb1lHS8PmfDulAUkDfW4sJUcEkdOe1K2ay7YyQdzd3VP/0xVYfxgQyj7kP0 BS5pzzBn/sQ0e2FMKFBdGQC1u8DwYUwg3YHbG0bLkOQYW17hfbwpX1obdj6FqdLbO2tG 6EaopssE5XuAloyegTNeCD0j/YFfYwNGfsV31Qz64NFdI3FbkECxysHVrq6yunTPnFQ8 Ltgw== MIME-Version: 1.0 X-Received: by 10.236.14.168 with SMTP id d28mr4071935yhd.3.1423752643048; Thu, 12 Feb 2015 06:50:43 -0800 (PST) Received: by 10.170.133.197 with HTTP; Thu, 12 Feb 2015 06:50:42 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083061CE@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F1824AFFB@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083061CE@NKGEML512-MBS.china.huawei.com> Date: Thu, 12 Feb 2015 09:50:42 -0500 Message-ID: From: Alia Atlas To: Xuxiaohu Content-Type: multipart/alternative; boundary=089e013a180e897bca050ee53e1e Archived-At: Cc: "bier@ietf.org" , Antoni Przygienda Subject: Re: [Bier] proposed BIER charter 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, 12 Feb 2015 14:51:36 -0000 --089e013a180e897bca050ee53e1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xiaohu, I certainly understand that you are very interested in working on a generic encapsulation for BIER. I do think this may be useful work. The MPLS encapsulation work is further along and has significant benefits in terms of not needing to revisit a number of issues that MPLS already handles. Your proposed changes basically eliminate any indication of what needs to be considered in the generic encapsulation, without any reasoning, and pushes for it to be considered as an equal focus with the MPLS encapsulation. I am already concerned that there's a lot of work for bier to get through. Do you think that the requirements on the generic encapsulation need refining and why? Regards, Alia On Thu, Feb 12, 2015 at 4:28 AM, Xuxiaohu wrote: > Hi Tony, > > > > Thanks a lot for your response. If the WG is intended to work on both > MPLS-based and non-MPLS-based BIER encapsulation schemes concurrently, I > would suggest making the following change to the BIER encapsulation relat= ed > text: > > > > OLD: > > 2) BIER encapsulation: The working group should assume that the > > technology will need to be embedded in the data plane and operate > > at the highest packet line speeds. The WG will publish a document > > defining an MPLS-based encapsulation based upon > > draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need > > to have a high-quality and stable RFC for a new data-plane > > encapsulation, the MPLS-based encapsulation draft shall wait after > > WGLC and not progress to IETF Last Call until there are two > > independent interoperable implementations. > > > > As a secondary focus, the WG may also work on one non-MPLS > > data-plane encapsulation. This draft also shall wait after WGLC > > and not progress to IETF Last Call until there are two independent > > interoperable implementations. This draft must focus on and > > include the following details: > > > > a) What is the applicability of the encapsulation and for which > > use-cases is this encapsulation required? > > > > b) Does this proposed encapsulation imply any changes to the > > MPLS-based encapsulation? > > > > c) What design choices have been made for the encapsulation > > type and the included fields. > > > > d) The proposed encapsulation with considerations given to at > > least OAM, Class of Service, security, fragmentation, TTL. > > NEW: > > 2) BIER encapsulation: The working group should assume that the > > technology will need to be embedded in the data plane and operate > > at the highest packet line speeds. The WG will work on both MPLS-base= d > > and non-MPLS-based BIER encapsulation schemes and publish the > corresponding documents. > > Due to the critical need to have a high-quality and stable RFC for a new > data-plane > > encapsulation, the BIER encapsulation draft shall wait after > > WGLC and not progress to IETF Last Call until there are two > > independent interoperable implementations. > > > > Best regards, > > Xiaohu > > > > > > > > > > *From:* Antoni Przygienda [mailto:antoni.przygienda@ericsson.com] > *Sent:* Thursday, February 12, 2015 2:27 PM > *To:* Xuxiaohu; bier@ietf.org > *Subject:* RE: [Bier] proposed BIER charter > > > > > > > > IMHO, the BIER layer is exactly a totally new NETWORK LAYER > > *[Tony said] *Xuxiaohu, *that all depends how IP centric one sees it. It > can be considered layer 2.5 as well given it doesn=E2=80=99t even have to= carry IP > frames. * > > and therefore the BIER header is better to be designed as a complete > network layer header from the beginning, rather than coupling it with an > MPLS label so as to be capable of acting as a complete network layer > header, which is specially meaningful in the non-MPLS network environment= s. > Therefore, it seems more reasonable to allow the WG to work on the > MPLS-based and non-MPLS-based encapsulation options concurrently > > *[Tony said] I do NOT see anywhere in the charter that both CANNOT be > worked on concurrently. Additional thought has been put into specifying > WHAT a generic encoding draft needs to provide for it to be high quality > and I think there is enough work to be done there. MPLS is simply the mos= t > pragmatic choice of a long mature L2.5 technology that provably solves ma= ny > large-scale deployment problems. * > > > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > --089e013a180e897bca050ee53e1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Xiaohu,

I certainly understand that you= are very interested in working on a generic encapsulation for BIER.=C2=A0 = I do think this may be useful work.=C2=A0 The MPLS encapsulation work is fu= rther along and has significant benefits in terms of not needing to revisit= a number of issues that MPLS already handles. =C2=A0

<= div>Your proposed changes basically eliminate any indication of what needs = to be considered in the generic encapsulation, without any reasoning, and p= ushes for it to be considered as an equal focus with the MPLS encapsulation= .=C2=A0 I am already concerned that there's a lot of work for bier to g= et through.

Do you think that the requirements on = the generic encapsulation need refining and why?

R= egards,
Alia


<= div class=3D"gmail_quote">On Thu, Feb 12, 2015 at 4:28 AM, Xuxiaohu <xux= iaohu@huawei.com> wrote:

Hi Tony,

=C2= =A0

Thanks a l= ot for your response. If the WG is intended to work on both MPLS-based and = non-MPLS-based BIER encapsulation schemes concurrently, I would suggest making the following change to the BIER encapsulation relate= d text:

=C2= =A0

OLD:

=C2=A0 =C2=A02) BIER encapsulat= ion: The working group should assume that the

=C2=A0 =C2=A0technology will ne= ed to be embedded in the data plane and operate

=C2=A0 =C2=A0at the highest pac= ket line speeds.=C2=A0 The WG will publish a document<= /p>

=C2=A0 =C2=A0defining an MPLS-b= ased encapsulation based upon

=C2=A0 =C2=A0draft-wijnands-mpl= s-bier-encapsulation-02. Due to the critical need

=C2=A0 =C2=A0to have a high-qua= lity and stable RFC for a new data-plane

=C2=A0 =C2=A0encapsulation, the= MPLS-based encapsulation draft shall wait after

=C2=A0 =C2=A0WGLC and not progr= ess to IETF Last Call until there are two

=C2=A0 =C2=A0independent intero= perable implementations.

=C2=A0

=C2=A0 =C2=A0As a secondary foc= us, the WG may also work on one non-MPLS

=C2=A0 =C2=A0data-plane encapsu= lation.=C2=A0 This draft also shall wait after WGLC

=C2=A0 =C2=A0and not progress t= o IETF Last Call until there are two independent

=C2=A0 =C2=A0interoperable impl= ementations.=C2=A0 This draft must focus on and

=C2=A0 =C2=A0include the follow= ing details:

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0a) W= hat is the applicability of the encapsulation and for which

=C2=A0 =C2=A0 =C2=A0 =C2=A0use-= cases is this encapsulation required?

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0b) D= oes this proposed encapsulation imply any changes to the

=C2=A0 =C2=A0 =C2=A0 =C2=A0MPLS= -based encapsulation?

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0c) W= hat design choices have been made for the encapsulation

=C2=A0 =C2=A0 =C2=A0 =C2=A0type= and the included fields.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0d) T= he proposed encapsulation with considerations given to at

=C2=A0 =C2=A0 =C2=A0 =C2=A0leas= t OAM, Class of Service, security, fragmentation, TTL.=

NEW= :

2)= BIER encapsulation: The working group should assume that the=

=C2=A0 =C2=A0technology will ne= ed to be embedded in the data plane and operate

=C2=A0 =C2=A0at the high= est packet line speeds.=C2=A0 The WG will work on both MPLS-based

an= d non-MPLS-based BIER encapsulation schemes and publish the corresponding d= ocuments.

Du= e to the critical need to have a high-quality and stable RFC for a new data= -plane

=C2=A0 =C2=A0encapsulati= on, the BIER encapsulation draft shall wait after

<= span class=3D"">

=C2=A0 =C2=A0WGLC and not progr= ess to IETF Last Call until there are two

=C2=A0 =C2=A0independent intero= perable implementations.

=C2=A0

Best regards,<= /u>

Xiaohu

=C2=A0

=C2= =A0

=C2= =A0

=C2= =A0

From: Antoni Przygienda [mailto:antoni.przygienda@ericsson.com= ]
Sent: Thursday, February 12, 2015 2:27 PM
To: Xuxiaohu; bie= r@ietf.org
Subject: RE: [Bier] proposed BIER charter

=C2=A0

<hat ty= pe=3D=E2=80=9Dwg chair=E2=80=9D>

=C2= =A0

IMHO, the = BIER layer is exactly a totally new NETWORK LAYER

[Ton= y said] Xuxiaohu, that all depends how= IP centric one sees it. It can be considered layer 2.5 as well given it do= esn=E2=80=99t even have to carry IP frames.

and theref= ore the BIER header is better to be designed as a complete network layer he= ader from the beginning, rather than coupling it with an MPLS label so as to be capable of acting as a complete network layer header, wh= ich is specially meaningful in the non-MPLS network environments. Therefore= , it seems more reasonable to allow the WG to work on the MPLS-based and no= n-MPLS-based encapsulation options concurrently

[Ton= y said] I do NOT see anywhere in the charter that both CANNOT be worked on = concurrently. Additional thought has been put into specifying WHAT a generic encoding draft needs to provide for it to be high quality a= nd I think there is enough work to be done there. MPLS is simply the most p= ragmatic choice of a long mature L2.5 technology that provably solves many = large-scale deployment problems.

=C2= =A0

</hat&g= t;


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


--089e013a180e897bca050ee53e1e-- From nobody Thu Feb 12 07:13:41 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4356D1A88B2; Thu, 12 Feb 2015 07:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB7scoFiK3uh; Thu, 12 Feb 2015 07:13:33 -0800 (PST) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B921A0266; Thu, 12 Feb 2015 07:13:33 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id z6so4884467yhz.13; Thu, 12 Feb 2015 07:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7bxkyqwU4GA6O0NATsUvn5RUdchmytFqVgrqCCrafdU=; b=qV179tijcnDSqZwOKoKK3oLbykkzKeL85yi0iVuzeQ7SCPw4bV6MS9wMd3colmJjBp fd+FDhEDb40z/F9tRnrNW1zUcAwzfMv9FpPcsOD/3AYFzvyhTlOkQXbGXqi+QpZv5snk Rt4LjkTLo5G5k3WJCJ4kOMEwe9aqBfNLXKlPzhG2qQCW7GiFkksuXmPBZKW0JG18Kvog O91Ym7BL/SDXAF5QC2rIYRbD3YRLZDogG4NBh1l9baeEZxWQ0T2jFwc40HJSwetq1fRH NlQDbZBhN3x+rK1Qht5674NYI28kD21wa/zMag7LpgUfXsK7GGa/mnI6UM3bTFLcVKwG RPuQ== MIME-Version: 1.0 X-Received: by 10.170.207.9 with SMTP id y9mr4732210yke.55.1423754012278; Thu, 12 Feb 2015 07:13:32 -0800 (PST) Received: by 10.170.133.197 with HTTP; Thu, 12 Feb 2015 07:13:32 -0800 (PST) In-Reply-To: <54DCAE4F.8050903@cisco.com> References: <54DCAE4F.8050903@cisco.com> Date: Thu, 12 Feb 2015 10:13:32 -0500 Message-ID: From: Alia Atlas To: stbryant Content-Type: multipart/alternative; boundary=001a113a06b42647a6050ee590ae Archived-At: Cc: Adrian Farrel , "bier@ietf.org" , "iesg@ietf.org" , Alvaro Retana Subject: Re: [Bier] proposed BIER charter 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, 12 Feb 2015 15:13:38 -0000 --001a113a06b42647a6050ee590ae Content-Type: text/plain; charset=UTF-8 Stewart, I certainly appreciate your taking the time to provide feedback. I understand that you are excited by this technology and have urged that innovation needs time and space to be worked on before being evaluated by the harsh realities of the marketplace and interest in deployments. On Thu, Feb 12, 2015 at 8:44 AM, Stewart Bryant wrote: > Alia > > I think that you are crossing far too many bridges before you get to them > in terms of you expectation of where BIER will be deployed and how > it will be implemented. > I did read the use-cases and understand the primary motivation is for MVPN and EVPN which are deployed in the backbone of SP networks that operate at high speeds. Even in data-centers, use of 10G links is common. > The charter should not include such specific assumptions, particularly > given the fast moving changes that are happening in our industry > especially in the area of packet forwarding design. > What specifically are you objecting to? > I have not seen such assumptions in other charters and I don't think > that they have a place in this one. > What specific assumption are you objecting to and what reasoning do you have beyond historical? > In terms of choice of document stream (experimental vs PS), > that is a decision that can be taken at the time of publication > when more information will be available in terms of potential > market take-up, expected/actual deployment scenarios, > breadth of implementation and implementation experience. > At this time, a sufficiently compelling case has not been made to convince that PS is anywhere near appropriate for this change of adding a completely new forwarding algorithm and a fourth encapsulation to go with IPv4, IPv6, and MPLS to the Internet architecture for the next 15+ years. It is true that if that changes between now and when drafts are ready to progress, that can be revisited. There are WGs that have been chartered to do experimental work in the past. I understand that it is disappointing that there wasn't a strong case for more than experimental at this time. I have been extremely clear since the last IETF that I was only considering Experimental for the WG for the initial chartering. Whilst this technology may be deployed in the Internet core, > it my also be deployed at the edge where a much lower threshold > is applicable. > The technology needs to work in both locations - given the use-cases. What specifically are you objecting to? > I fear that by introducing these caveats the IETF is entrenching the > perception that it slows technology down rather than embracing > and encouraging innovation. > By creating a WG for open collaboration and defining an ambitious new forwarding technology, the IETF is not embracing and encouraging innovation? I suppose it's all in the eye of the beholder - but to me it feels like "give an inch and get pushed for a mile". > I would therefore suggest removing the text on implementation > styles and document stream constraints. > IF the encapsulations are specified in a way that two independent interoperable implementations are not available, it both increases the risk that we might end up with two different versions - one Experimental and another through bitter experience that is PS later - and is a poor indication of the lack of industry support and interest in the technology and its use. Regards, Alia > - Stewart > > > On 11/02/2015 20:44, Alia Atlas wrote: > > I have been working on getting a charter together for BIER with the intent > of pushing for it to be chartered before the Dallas IETF. This has not yet > gone through IESG review and it may have some aspects updated. > > Please send comments here. > > The charter can be found at > http://datatracker.ietf.org/doc/charter-ietf-bier/ > and is included below as well. > > > WG Chairs: > Greg Shepherd > Tony Przygienda > > > In conventional IP multicast forwarding, the packets of a given > multicast "flow" are forwarded along a tree that has been constructed > for the specific purpose of carrying that flow. This requires transit > nodes to maintain state on a per-flow basis, and requires the transit > nodes to participate in multicast-specific tree building protocols. > The flow to which a packet belongs is determined by its IP source and > destination address fields. > > BIER (Bit Index Explicit Replication) is an alternative method of > multicast forwarding. It does not require any multicast-specific > trees, and hence does not require any multicast-specific tree building > protocols. Within a given "BIER domain", an ingress node encapsulates > a multicast data packet in a "BIER header". The BIER header > identifies the packet's egress nodes in that domain. Each possible > egress node is represented by a a single bit within a bitstring; to > send a packet to a particular set of egress nodes, the ingress node > sets the bits for each of those egress nodes, and clears the other > bits in the bistring. Each packet can then be forwarded along the > unicast shortest path tree from the ingress node to the egress nodes. > Thus there are no per-flow forwarding entries. > > Due to the particular sensitivity of adding new significant > functionality into the data-plane at high link speeds, the BIER work > will progress as Experimental. As described in item (9) below, the > work may become Standards Track once there is sufficient experience > with the benefits and downsides of the technology. > > BIER is initially chartered to do experimental work on this new > multicast forwarding mechanism as follows: > > 1) BIER architecture: The WG will publish an architecture, based > upon draft-wijnands-bier-architecture-04. It will include the > normative algorithm for how BIER packet forwarding is done. It > will specify the information that is required by a BIER header to > support BIER forwarding. > > 2) BIER encapsulation: The working group should assume that the > technology will need to be embedded in the data plane and operate > at the highest packet line speeds. The WG will publish a document > defining an MPLS-based encapsulation based upon > draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need > to have a high-quality and stable RFC for a new data-plane > encapsulation, the MPLS-based encapsulation draft shall wait after > WGLC and not progress to IETF Last Call until there are two > independent interoperable implementations. > > As a secondary focus, the WG may also work on one non-MPLS > data-plane encapsulation. This draft also shall wait after WGLC > and not progress to IETF Last Call until there are two independent > interoperable implementations. This draft must focus on and > include the following details: > > a) What is the applicability of the encapsulation and for which > use-cases is this encapsulation required? > > b) Does this proposed encapsulation imply any changes to the > MPLS-based encapsulation? > > c) What design choices have been made for the encapsulation > type and the included fields. > > d) The proposed encapsulation with considerations given to at > least OAM, Class of Service, security, fragmentation, TTL. > > 3) Transition Mechanisms: The WG will describe how BIER can be > partially deployed and still provide useful functionality. A > minimum of the necessary mechanisms to support incremental > deployment and/or managing different BIER mask-length compatibility > may be defined. Each such mechanism must include an applicability > statement to differentiate its necessity from other proposed > mechanisms. > > 4) Applicability Statements: The WG will work on a document > describing how BIER can be applied to multicast L3VPN and to EVPN. > This draft will describe what mechanism is used to communicate the > group membership between the ingress router and the egress routers, > what scalability considerations may arise, and any deployment > considerations. > > 5) Use Case: The WG may produce one use-case document that clearly > articulates the potential benefits of BIER for different use-cases. > This would be based upon draft-kumar-bier-use-cases-01. > > 6) OAM: The WG will describe how OAM will work in a BIER domain and > what simplifications BIER offers for managing the multicast > traffic. A strong preference will be given to extensions to > existing protocols. > > 7) Management models: The WG may work on YANG models and, if needed, > MIB modules to support common manageability. > > 8) IGP extensions. When a BIER domain falls within a "link state > IGP"" > network, the information needed to set up the BIER forwarding tables > (e.g., the mapping between a given bit position and a given egress > router) may be carried in the link state advertisements of the IGP. The > link state advertisments may also carry other information related to > forwarding (e.g., the IGP may support multiple topologies, in which case > it may be necessary to advertise which topologies are to be used for > BIER > forwarding). Any necessary extensions to the IGP will be specified by > the WG, in cooperation with the ISIS and OSPF WGs. > > 9) Deployment Experience: Once there is deployment experience, the > WG will produce a document describing the benefits, problems, and > trade-offs for using BIER instead of traditional multicast > forwarding mechanisms. Ideally, this should also contain an > analysis of the impact and benefit of the new BIER data-plane to > the overall Internet architecture. This document is intended to be > used to evaluate whether to recharter BIER to produce Standards > Track RFCs. > > The BIER working group will coordinate with several different working > groups and must include the relevant other working groups during > working group last call on the relevant drafts. BIER will coordinate > with MPLS on the MPLS-based encapsulation and associated MPLS-based > OAM mechanisms. BIER will coordinate with ISIS and OSPF on extensions > to flood BIER-related information. BIER will coordinate with BESS and > IDR on the applicability of existing BGP-based mechanisms for > providing multicast group membership information. > > Regards, > Alia > > > _______________________________________________ > BIER mailing listBIER@ietf.orghttps://www.ietf.org/mailman/listinfo/bier > > > > -- > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > --001a113a06b42647a6050ee590ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stewart,

I certainly appreciate your taking the time to provide feedba= ck.=C2=A0 I understand that you
are excited= by this technology and have urged that innovation needs time and space
to be worked on before being evaluated by the = harsh realities of the marketplace and=C2=A0
interest in deployments.

On Thu, Feb 12, 2015 at 8:44 AM, Stewart Bryant <stbrya= nt@cisco.com> wrote:
=20 =20 =20
Alia

I think that you are crossing far too many bridges before you get to them
in terms of you expectation of where BIER will be deployed and how it will be implemented.

I did read the use-cases and understand the primary motivation is for MV= PN=C2=A0
and EVPN which are deployed in the backbone of SP networ= ks that operate at
high speeds.=C2=A0 Even in data-centers, use o= f 10G links is common.
=C2=A0
The charter should not incl= ude such specific assumptions, particularly
given the fast moving changes that are happening in our industry
especially in the area of packet forwarding design.

What specifically are you objecting to?=C2= =A0
=C2=A0
I have not seen such assumptions in other char= ters and I don't think
that they have a place in this one.
=
What specific assumption are you objecting to and what reaso= ning do you have
beyond historical?
=C2=A0
In t= erms of choice of document stream (experimental vs PS),
that is a decision that can be taken at the time of publication
when more information will be available in terms of potential
market take-up, expected/actual deployment scenarios,
breadth of implementation and implementation experience.

At this time, a sufficiently compelling= case has not been made to convince that
PS is anywhere near appr= opriate for this change of adding a completely new forwarding=C2=A0
algorithm and a fourth =C2=A0encapsulation to go with IPv4, IPv6, and MP= LS to the Internet=C2=A0
architecture for the next 15+ years.=C2= =A0

It is true that if that changes between now an= d when drafts are ready to progress, that can
be revisited.
=

There are WGs that have been chartered to do experiment= al work in the past.=C2=A0 I understand
that it is disappointing = that there wasn't a strong case for more than experimental at this time= .
=C2=A0
I have been extremely clear since the last IET= F that I was only considering Experimental for=C2=A0
the WG for t= he initial chartering.

<= div bgcolor=3D"#FFFFFF" text=3D"#000000">
Whilst this technology may be deployed in the Internet core,
it my also be deployed at the edge where a much lower threshold
is applicable.

The te= chnology needs to work in both locations - given the use-cases.=C2=A0 What = specifically are
you objecting to?
=C2=A0
I fea= r that by introducing these caveats the IETF is entrenching the
perception that it slows technology down rather than embracing
and encouraging innovation.

By creating a WG for open collaboration and defining an ambitious ne= w forwarding technology,
the IETF is not embracing and encouragin= g innovation?=C2=A0 I suppose it's all in the eye of the
beho= lder - but to me it feels like "give an inch and get pushed for a mile= ".=C2=A0
=C2=A0
I would therefore suggest removing the text on implementation
styles and document stream constraints.
<= div>
IF the encapsulations are specified in a way that two in= dependent interoperable implementations
are not available, it bot= h increases the risk that we might end up with two different versions - one=
Experimental and another through bitter experience that is PS la= ter - and is a poor indication of
the lack of industry support an= d interest in the technology and its use.
=C2=A0
Regard= s,
Alia


- Stewart


On 11/02/2015 20:44, Alia Atlas wrote:
=20
I have been working on getting a charter together for BIER with the intent of pushing for it to be chartered before the Dallas IETF.=C2=A0 This has not yet gone through IESG review and it may have some aspects updated.

Please send comments here.

and is included below as well.


WG Chairs:
=C2=A0 Greg Shepherd =C2=A0<gjshep@gmail.com>
=C2=A0 Tony Przygienda <tonysietf@gmail.com>


In conventional IP multicast forwarding, the packets of a given
multicast "flow" are forwarded along a tree that= has been constructed
for the specific purpose of carrying that flow.=C2=A0 This requires transit
nodes to maintain state on a per-flow basis, and requires the transit
nodes to participate in multicast-specific tree building protocols.
The flow to which a packet belongs is determined by its IP source and
destination address fields.

BIER (Bit Index Explicit Replication) is an alternative method of
multicast forwarding.=C2=A0 It does not require any multicast-specific
trees, and hence does not require any multicast-specific tree building
protocols.=C2=A0 Within a given "BIER domain", a= n ingress node encapsulates
a multicast data packet in a "BIER header".=C2= =A0 The BIER header
identifies the packet's egress nodes in that domain.= =C2=A0 Each possible
egress node is represented by a a single bit within a bitstring; to
send a packet to a particular set of egress nodes, the ingress node
sets the bits for each of those egress nodes, and clears the other
bits in the bistring.=C2=A0 Each packet can then be forwarded along the
unicast shortest path tree from the ingress node to the egress nodes.
Thus there are no per-flow forwarding entries.

Due to the particular sensitivity of adding new significant
functionality into the data-plane at high link speeds, the BIER work
will progress as Experimental.=C2=A0 As described in item (9) below, the
work may become Standards Track once there is sufficient experience
with the benefits and downsides of the technology.

BIER is initially chartered to do experimental work on this new
multicast forwarding mechanism as follows:

=C2=A0 =C2=A01) BIER architecture: The WG will publish an architecture, based
=C2=A0 =C2=A0upon draft-wijnands-bier-architecture-04.=C2= =A0 It will include the
=C2=A0 =C2=A0normative algorithm for how BIER packet forwa= rding is done.=C2=A0 It
=C2=A0 =C2=A0will specify the information that is required= by a BIER header to
=C2=A0 =C2=A0support BIER forwarding.

=C2=A0 =C2=A02) BIER encapsulation: The working group shou= ld assume that the
=C2=A0 =C2=A0technology will need to be embedded in the da= ta plane and operate
=C2=A0 =C2=A0at the highest packet line speeds.=C2=A0 The = WG will publish a document
=C2=A0 =C2=A0defining an MPLS-based encapsulation based up= on
=C2=A0 =C2=A0draft-wijnands-mpls-bier-encapsulation-02. Du= e to the critical need
=C2=A0 =C2=A0to have a high-quality and stable RFC for a n= ew data-plane
=C2=A0 =C2=A0encapsulation, the MPLS-based encapsulation d= raft shall wait after
=C2=A0 =C2=A0WGLC and not progress to IETF Last Call until= there are two
=C2=A0 =C2=A0independent interoperable implementations.

=C2=A0 =C2=A0As a secondary focus, the WG may also work on= one non-MPLS
=C2=A0 =C2=A0data-plane encapsulation.=C2=A0 This draft al= so shall wait after WGLC
=C2=A0 =C2=A0and not progress to IETF Last Call until ther= e are two independent
=C2=A0 =C2=A0interoperable implementations.=C2=A0 This dra= ft must focus on and
=C2=A0 =C2=A0include the following details:

=C2=A0 =C2=A0 =C2=A0 =C2=A0a) What is the applicability of= the encapsulation and for which
=C2=A0 =C2=A0 =C2=A0 =C2=A0use-cases is this encapsulation= required?

=C2=A0 =C2=A0 =C2=A0 =C2=A0b) Does this proposed encapsula= tion imply any changes to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0MPLS-based encapsulation?

=C2=A0 =C2=A0 =C2=A0 =C2=A0c) What design choices have bee= n made for the encapsulation
=C2=A0 =C2=A0 =C2=A0 =C2=A0type and the included fields.

=C2=A0 =C2=A0 =C2=A0 =C2=A0d) The proposed encapsulation w= ith considerations given to at
=C2=A0 =C2=A0 =C2=A0 =C2=A0least OAM, Class of Service, se= curity, fragmentation, TTL.

=C2=A0 =C2=A03) Transition Mechanisms: The WG will describ= e how BIER can be
=C2=A0 =C2=A0partially deployed and still provide useful functionality. =C2=A0A
=C2=A0 =C2=A0minimum of the necessary mechanisms to suppor= t incremental
=C2=A0 =C2=A0deployment and/or managing different BIER mask-length compatibility
=C2=A0 =C2=A0may be defined.=C2=A0 Each such mechanism mus= t include an applicability
=C2=A0 =C2=A0statement to differentiate its necessity from= other proposed
=C2=A0 =C2=A0mechanisms.

=C2=A0 =C2=A04) Applicability Statements: The WG will work= on a document
=C2=A0 =C2=A0describing how BIER can be applied to multica= st L3VPN and to EVPN.
=C2=A0 =C2=A0This draft will describe what mechanism is us= ed to communicate the
=C2=A0 =C2=A0group membership between the ingress router a= nd the egress routers,
=C2=A0 =C2=A0what scalability considerations may arise, an= d any deployment
=C2=A0 =C2=A0considerations.=C2=A0

=C2=A0 =C2=A05) Use Case: The WG may produce one use-case document that clearly
=C2=A0 =C2=A0articulates the potential benefits of BIER fo= r different use-cases.
=C2=A0 =C2=A0This would be based upon draft-kumar-bier-use-cases-01.

=C2=A0 =C2=A06) OAM: The WG will describe how OAM will wor= k in a BIER domain and
=C2=A0 =C2=A0what simplifications BIER offers for managing= the multicast
=C2=A0 =C2=A0traffic.=C2=A0 A strong preference will be gi= ven to extensions to
=C2=A0 =C2=A0existing protocols.

=C2=A0 =C2=A07) Management models: The WG may work on YANG= models and, if needed,
=C2=A0 =C2=A0MIB modules to support common manageability.<= /div>

=C2=A0 =C2=A08) IGP extensions.=C2=A0 When a BIER domain f= alls within a "link state IGP""
=C2=A0 =C2=A0network, the information needed to set up the= BIER forwarding tables
=C2=A0 =C2=A0(e.g., the mapping between a given bit positi= on and a given egress
=C2=A0 =C2=A0router) may be carried in the link state advertisements of the IGP.=C2=A0 The
=C2=A0 =C2=A0link state advertisments may also carry other information related to
=C2=A0 =C2=A0forwarding (e.g., the IGP may support multipl= e topologies, in which case
=C2=A0 =C2=A0it may be necessary to advertise which topolo= gies are to be used for BIER
=C2=A0 =C2=A0forwarding).=C2=A0 Any necessary extensions t= o the IGP will be specified by
=C2=A0 =C2=A0the WG, in cooperation with the ISIS and OSPF= WGs.

=C2=A0 =C2=A09) Deployment Experience: Once there is deplo= yment experience, the
=C2=A0 =C2=A0WG will produce a document describing the ben= efits, problems, and
=C2=A0 =C2=A0trade-offs for using BIER instead of traditio= nal multicast
=C2=A0 =C2=A0forwarding mechanisms.=C2=A0 Ideally, this sh= ould also contain an
=C2=A0 =C2=A0analysis of the impact and benefit of the new= BIER data-plane to
=C2=A0 =C2=A0the overall Internet architecture.=C2=A0 This= document is intended to be
=C2=A0 =C2=A0used to evaluate whether to recharter BIER to produce Standards
=C2=A0 =C2=A0Track RFCs.

The BIER working group will coordinate with several different working
groups and must include the relevant other working groups during
working group last call on the relevant drafts.=C2=A0 BIER will coordinate
with MPLS on the MPLS-based encapsulation and associated MPLS-based
OAM mechanisms.=C2=A0 BIER will coordinate with ISIS and OSPF on extensions
to flood BIER-related information.=C2=A0 BIER will coordinate with BESS and
IDR on the applicability of existing BGP-based mechanisms for
providing multicast group membership information.

Regards,
Alia


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



--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/c=
ri/index.html

--001a113a06b42647a6050ee590ae-- From nobody Thu Feb 12 15:20:35 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474F91A6EE7; Thu, 12 Feb 2015 15:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZlGLMzgdCCM; Thu, 12 Feb 2015 15:20:18 -0800 (PST) Received: from mailout2-trp.thomsonreuters.com (mailout2-trp.thomsonreuters.com [163.231.6.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124161A02BE; Thu, 12 Feb 2015 15:20:16 -0800 (PST) Received: from trpusmneagrly02.int.westgroup.com (relay2 [163.231.22.113]) by mailout2-trp.thomsonreuters.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id t1CNKDDG010965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Feb 2015 23:20:14 GMT Received: from EAGE-ERFPHUB06.ERF.thomson.com (EAGE-ERFPHUB06.erf.thomson.com [163.231.23.45]) by trpusmneagrly02.int.westgroup.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id t1CNKCPH012742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 23:20:13 GMT Received: from C111GTUHMBX56.ERF.thomson.com ([fe80::71e6:8d9e:a7f4:fe91]) by EAGE-ERFPHUB06.ERF.thomson.com ([fe80::5082:a4a:fee9:2e9b%13]) with mapi id 14.03.0158.001; Thu, 12 Feb 2015 17:20:12 -0600 From: To: , Thread-Topic: [Bier] proposed BIER charter Thread-Index: AQHQRjuRMrYFGWrOhUGuXJjtT6R8K5ztbD+AgAAYzAD//7+bgA== Date: Thu, 12 Feb 2015 23:20:11 +0000 Message-ID: <4A496052E7B7E84A9324854763C616FA233CF4DA@C111GTUHMBX56.ERF.thomson.com> References: <54DCAE4F.8050903@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.206.30.4] x-tm-as-product-ver: SMEX-10.2.0.3262-7.500.1018-21168.004 x-tm-as-result: No--38.678300-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_4A496052E7B7E84A9324854763C616FA233CF4DAC111GTUHMBX56ER_" MIME-Version: 1.0 Archived-At: Cc: adrian@olddog.co.uk, bier@ietf.org, iesg@ietf.org, aretana@cisco.com Subject: Re: [Bier] proposed BIER charter 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, 12 Feb 2015 23:20:26 -0000 --_000_4A496052E7B7E84A9324854763C616FA233CF4DAC111GTUHMBX56ER_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxpYSwNCg0KSSBoYXZlIGJlZW4gZW5nYWdlZCB3aXRoIEJJRVIgdGVjaG5vbG9neSBmb3IgdGhl IGxhc3QgeWVhciBhbmQgYSBoYWxmIGZyb20gaXRzIGluY2VwdGlvbi4gSXQgY29tZSBhbG9uZyB3 YXkgYW5kIGl0IHdhcyBub3QgZHJpdmVuIGp1c3QgYmFzZWQgb24gZXhjaXRlbWVudC4gVGhpcyB3 b3JrIGlzIGJhY2tlZCB1cCBieSBjb21taXRtZW50IGZyb20gbWFqb3IgdmVuZG9ycyBhbmQgbXVs dGlwbGUgb3BlcmF0b3JzLiBJIGhhdmUgZGlzY3Vzc2VkIEJJRVIgb24gbXVsdGlwbGUgb2NjYXNp b25zIHdpdGggb3RoZXIgb3BlcmF0b3JzLCB0aGV5IHNob3dlZCBhIGdyZWF0IGludGVyZXN0IGFu ZCBzdHJvbmcgc3VwcG9ydCB3aXRoIG92ZXJhbGwgY29uc2Vuc3VzIHRoYXQgQklFUiB3aWxsIGJ1 aWxkIGEgcmlnaHQgZm91bmRhdGlvbiBmb3IgZWZmaWNpZW50IG11bHRpY2FzdCBkZWxpdmVyeSBm b3Igb3BlcmF0b3JzIHRvIHN0YW5kYXJkaXplLiBJIHByb21vdGVkIEJJRVIgd2l0aGluIFRob21z b24gUmV1dGVycyBvbiB0aGUgQnVzaW5lc3MgYW5kIFRlY2hub2xvZ3kgc2lkZXMgYW5kIGZlZWRi YWNrIHdhcyBvdmVyd2hlbG1pbmcsIHdpdGggaHVnZSBpbnRlcmVzdCBmcm9tIFRob21zb24gUmV1 dGVycyBkZXZlbG9wbWVudCBjb21tdW5pdHkuIEJhc2VkIG9uIG15IGludm9sdmVtZW50IHdpdGgg QklFUiwgSSBzdHJ1Z2dsZSB0byBkZWZpbmUgaXQgYXMgRXhwZXJpbWVudGFsIGFzIHBlciBpbmNs dWRlZCBkZWZpbml0aW9uIGJlbG93IGFuZCBJIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCBTdGV3YXJ0 IG9uIGhpcyBhc3Nlc3NtZW50IG9mIHlvdXIgcHJvcG9zZWQgY2hhcnRlci4gUGxlYXNlIGRvbid0 IHRha2UgaXQgYXMgYSBjcml0aWNpc20sIEkgYW0gdmVyeSBub3ZpY2UgaW4gdGVybXMgb2YgSUVU RiBwcm90b2NvbHMgYW5kIHByb2NlZHVyZXMgYnV0IGFzIHBlciBteSBmaW5kaW5ncyBvZiBJRVRG IGRlZmluaXRpb25zOg0KDQoiV0cgY2hhcnRlcnMgc3RhdGUgdGhlIHNjb3BlIG9mIHdvcmsgZm9y IGdyb3VwLCBhbmQgbGF5IG91dCBnb2FscyBhbmQgbWlsZXN0b25lcyB0aGF0IHNob3cgaG93IHRo aXMgd29yayB3aWxsIGJlIGNvbXBsZXRlZC4iDQoNClRoZSBwcm9wb3NlZCB2ZXJzaW9uIGluIHRo ZSB3YXkgaXQgd2FzIHdyaXR0ZW4gbW9yZSBmb2N1c2luZyBvbiBjb25kaXRpb25hbCBzdGF0ZW1l bnRzIGFuZCBkZXBpY3RzIHNvbWUgdW53aWxsaW5nbmVzcyBvZiBJRVRGIHRvIHByb21vdGUvcHJv Y2VlZCB3aXRoIEJJRVIgYXMgYSBjb21taXR0ZWQgd29yay4NCg0KDQoNClNuYXBzaG90IGZyb20g SUVURi5vcmcNCg0K4oCcNC4yLjEgRXhwZXJpbWVudGFsDQoNClRoZSAiRXhwZXJpbWVudGFsIiBk ZXNpZ25hdGlvbiB0eXBpY2FsbHkgZGVub3RlcyBhIHNwZWNpZmljYXRpb24gdGhhdCBpcyBwYXJ0 IG9mIHNvbWUgcmVzZWFyY2ggb3IgZGV2ZWxvcG1lbnQgZWZmb3J0LiBTdWNoIGEgc3BlY2lmaWNh dGlvbiBpcyBwdWJsaXNoZWQgZm9yIHRoZSBnZW5lcmFsIGluZm9ybWF0aW9uIG9mIHRoZSBJbnRl cm5ldCB0ZWNobmljYWwgY29tbXVuaXR5IGFuZCBhcyBhbiBhcmNoaXZhbCByZWNvcmQgb2YgdGhl IHdvcmssIHN1YmplY3Qgb25seSB0byBlZGl0b3JpYWwgY29uc2lkZXJhdGlvbnMgYW5kIHRvIHZl cmlmaWNhdGlvbiB0aGF0IHRoZXJlIGhhcyBiZWVuIGFkZXF1YXRlIGNvb3JkaW5hdGlvbiB3aXRo IHRoZSBzdGFuZGFyZHMgcHJvY2VzcyAoc2VlIGJlbG93KS4gQW4gRXhwZXJpbWVudGFsIHNwZWNp ZmljYXRpb24gbWF5IGJlIHRoZSBvdXRwdXQgb2YgYW4gb3JnYW5pemVkIEludGVybmV0IHJlc2Vh cmNoIGVmZm9ydCAoZS5nLiwgYSBSZXNlYXJjaCBHcm91cCBvZiB0aGUgSVJURiksIGFuIElFVEYg V29ya2luZyBHcm91cCwgb3IgaXQgbWF5IGJlIGFuIGluZGl2aWR1YWwgY29udHJpYnV0aW9uLuKA nQ0KDQoNCg0KSSB3b3VsZCBsaWtlIHRvIGNvbnRpbnVlIHRvIHByb21vdGUgQklFUiBhbmQgdGFr ZSBhbiBhY3RpdmUgcGFydCBpbiBkZXZlbG9waW5nIG9mIG5ldyBtdWx0aWNhc3QgdGVjaG5vbG9n aWVzIGZvciBteSBjb21wYW55IGFuZCBpbmR1c3RyeSBiZW5lZml0cy4gVGhlcmUgYXJlIHBsZW50 eSBvZiBjaGFsbGVuZ2VzIGluIHRoaXMgYXJlbmEsIGJ1dCBvbmx5IHZpYSBhY3RpdmUgcGFydGlj aXBhdGlvbiB0aGVzZSBjaGFsbGVuZ2VzIGNhbiBiZSByZXNvbHZlZC4gV2UgbmVlZCB0byBzZWUg Y29tbWl0bWVudCBmcm9tIElFVEYgdG8gbW92ZSBCSUVSIGRldmVsb3BtZW50IGZvcndhcmQuDQoN Cg0KDQpSZWdhcmRzLA0KDQpBcmthZGl5DQoNCg0KRnJvbTogQklFUiBbbWFpbHRvOmJpZXItYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsaWEgQXRsYXMNClNlbnQ6IFRodXJzZGF5LCBG ZWJydWFyeSAxMiwgMjAxNSAxMDoxNCBBTQ0KVG86IHN0YnJ5YW50DQpDYzogQWRyaWFuIEZhcnJl bDsgYmllckBpZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZzsgQWx2YXJvIFJldGFuYQ0KU3ViamVjdDog UmU6IFtCaWVyXSBwcm9wb3NlZCBCSUVSIGNoYXJ0ZXINCg0KU3Rld2FydCwNCg0KSSBjZXJ0YWlu bHkgYXBwcmVjaWF0ZSB5b3VyIHRha2luZyB0aGUgdGltZSB0byBwcm92aWRlIGZlZWRiYWNrLiAg SSB1bmRlcnN0YW5kIHRoYXQgeW91DQphcmUgZXhjaXRlZCBieSB0aGlzIHRlY2hub2xvZ3kgYW5k IGhhdmUgdXJnZWQgdGhhdCBpbm5vdmF0aW9uIG5lZWRzIHRpbWUgYW5kIHNwYWNlDQp0byBiZSB3 b3JrZWQgb24gYmVmb3JlIGJlaW5nIGV2YWx1YXRlZCBieSB0aGUgaGFyc2ggcmVhbGl0aWVzIG9m IHRoZSBtYXJrZXRwbGFjZSBhbmQNCmludGVyZXN0IGluIGRlcGxveW1lbnRzLg0KDQpPbiBUaHUs IEZlYiAxMiwgMjAxNSBhdCA4OjQ0IEFNLCBTdGV3YXJ0IEJyeWFudCA8c3RicnlhbnRAY2lzY28u Y29tPG1haWx0bzpzdGJyeWFudEBjaXNjby5jb20+PiB3cm90ZToNCkFsaWENCg0KSSB0aGluayB0 aGF0IHlvdSBhcmUgY3Jvc3NpbmcgZmFyIHRvbyBtYW55IGJyaWRnZXMgYmVmb3JlIHlvdSBnZXQg dG8gdGhlbQ0KaW4gdGVybXMgb2YgeW91IGV4cGVjdGF0aW9uIG9mIHdoZXJlIEJJRVIgd2lsbCBi ZSBkZXBsb3llZCBhbmQgaG93DQppdCB3aWxsIGJlIGltcGxlbWVudGVkLg0KDQpJIGRpZCByZWFk IHRoZSB1c2UtY2FzZXMgYW5kIHVuZGVyc3RhbmQgdGhlIHByaW1hcnkgbW90aXZhdGlvbiBpcyBm b3IgTVZQTg0KYW5kIEVWUE4gd2hpY2ggYXJlIGRlcGxveWVkIGluIHRoZSBiYWNrYm9uZSBvZiBT UCBuZXR3b3JrcyB0aGF0IG9wZXJhdGUgYXQNCmhpZ2ggc3BlZWRzLiAgRXZlbiBpbiBkYXRhLWNl bnRlcnMsIHVzZSBvZiAxMEcgbGlua3MgaXMgY29tbW9uLg0KDQpUaGUgY2hhcnRlciBzaG91bGQg bm90IGluY2x1ZGUgc3VjaCBzcGVjaWZpYyBhc3N1bXB0aW9ucywgcGFydGljdWxhcmx5DQpnaXZl biB0aGUgZmFzdCBtb3ZpbmcgY2hhbmdlcyB0aGF0IGFyZSBoYXBwZW5pbmcgaW4gb3VyIGluZHVz dHJ5DQplc3BlY2lhbGx5IGluIHRoZSBhcmVhIG9mIHBhY2tldCBmb3J3YXJkaW5nIGRlc2lnbi4N Cg0KV2hhdCBzcGVjaWZpY2FsbHkgYXJlIHlvdSBvYmplY3RpbmcgdG8/DQoNCkkgaGF2ZSBub3Qg c2VlbiBzdWNoIGFzc3VtcHRpb25zIGluIG90aGVyIGNoYXJ0ZXJzIGFuZCBJIGRvbid0IHRoaW5r DQp0aGF0IHRoZXkgaGF2ZSBhIHBsYWNlIGluIHRoaXMgb25lLg0KDQpXaGF0IHNwZWNpZmljIGFz c3VtcHRpb24gYXJlIHlvdSBvYmplY3RpbmcgdG8gYW5kIHdoYXQgcmVhc29uaW5nIGRvIHlvdSBo YXZlDQpiZXlvbmQgaGlzdG9yaWNhbD8NCg0KSW4gdGVybXMgb2YgY2hvaWNlIG9mIGRvY3VtZW50 IHN0cmVhbSAoZXhwZXJpbWVudGFsIHZzIFBTKSwNCnRoYXQgaXMgYSBkZWNpc2lvbiB0aGF0IGNh biBiZSB0YWtlbiBhdCB0aGUgdGltZSBvZiBwdWJsaWNhdGlvbg0Kd2hlbiBtb3JlIGluZm9ybWF0 aW9uIHdpbGwgYmUgYXZhaWxhYmxlIGluIHRlcm1zIG9mIHBvdGVudGlhbA0KbWFya2V0IHRha2Ut dXAsIGV4cGVjdGVkL2FjdHVhbCBkZXBsb3ltZW50IHNjZW5hcmlvcywNCmJyZWFkdGggb2YgaW1w bGVtZW50YXRpb24gYW5kIGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2UuDQoNCkF0IHRoaXMgdGlt ZSwgYSBzdWZmaWNpZW50bHkgY29tcGVsbGluZyBjYXNlIGhhcyBub3QgYmVlbiBtYWRlIHRvIGNv bnZpbmNlIHRoYXQNClBTIGlzIGFueXdoZXJlIG5lYXIgYXBwcm9wcmlhdGUgZm9yIHRoaXMgY2hh bmdlIG9mIGFkZGluZyBhIGNvbXBsZXRlbHkgbmV3IGZvcndhcmRpbmcNCmFsZ29yaXRobSBhbmQg YSBmb3VydGggIGVuY2Fwc3VsYXRpb24gdG8gZ28gd2l0aCBJUHY0LCBJUHY2LCBhbmQgTVBMUyB0 byB0aGUgSW50ZXJuZXQNCmFyY2hpdGVjdHVyZSBmb3IgdGhlIG5leHQgMTUrIHllYXJzLg0KDQpJ dCBpcyB0cnVlIHRoYXQgaWYgdGhhdCBjaGFuZ2VzIGJldHdlZW4gbm93IGFuZCB3aGVuIGRyYWZ0 cyBhcmUgcmVhZHkgdG8gcHJvZ3Jlc3MsIHRoYXQgY2FuDQpiZSByZXZpc2l0ZWQuDQoNClRoZXJl IGFyZSBXR3MgdGhhdCBoYXZlIGJlZW4gY2hhcnRlcmVkIHRvIGRvIGV4cGVyaW1lbnRhbCB3b3Jr IGluIHRoZSBwYXN0LiAgSSB1bmRlcnN0YW5kDQp0aGF0IGl0IGlzIGRpc2FwcG9pbnRpbmcgdGhh dCB0aGVyZSB3YXNuJ3QgYSBzdHJvbmcgY2FzZSBmb3IgbW9yZSB0aGFuIGV4cGVyaW1lbnRhbCBh dCB0aGlzIHRpbWUuDQoNCkkgaGF2ZSBiZWVuIGV4dHJlbWVseSBjbGVhciBzaW5jZSB0aGUgbGFz dCBJRVRGIHRoYXQgSSB3YXMgb25seSBjb25zaWRlcmluZyBFeHBlcmltZW50YWwgZm9yDQp0aGUg V0cgZm9yIHRoZSBpbml0aWFsIGNoYXJ0ZXJpbmcuDQoNCldoaWxzdCB0aGlzIHRlY2hub2xvZ3kg bWF5IGJlIGRlcGxveWVkIGluIHRoZSBJbnRlcm5ldCBjb3JlLA0KaXQgbXkgYWxzbyBiZSBkZXBs b3llZCBhdCB0aGUgZWRnZSB3aGVyZSBhIG11Y2ggbG93ZXIgdGhyZXNob2xkDQppcyBhcHBsaWNh YmxlLg0KDQpUaGUgdGVjaG5vbG9neSBuZWVkcyB0byB3b3JrIGluIGJvdGggbG9jYXRpb25zIC0g Z2l2ZW4gdGhlIHVzZS1jYXNlcy4gIFdoYXQgc3BlY2lmaWNhbGx5IGFyZQ0KeW91IG9iamVjdGlu ZyB0bz8NCg0KSSBmZWFyIHRoYXQgYnkgaW50cm9kdWNpbmcgdGhlc2UgY2F2ZWF0cyB0aGUgSUVU RiBpcyBlbnRyZW5jaGluZyB0aGUNCnBlcmNlcHRpb24gdGhhdCBpdCBzbG93cyB0ZWNobm9sb2d5 IGRvd24gcmF0aGVyIHRoYW4gZW1icmFjaW5nDQphbmQgZW5jb3VyYWdpbmcgaW5ub3ZhdGlvbi4N Cg0KQnkgY3JlYXRpbmcgYSBXRyBmb3Igb3BlbiBjb2xsYWJvcmF0aW9uIGFuZCBkZWZpbmluZyBh biBhbWJpdGlvdXMgbmV3IGZvcndhcmRpbmcgdGVjaG5vbG9neSwNCnRoZSBJRVRGIGlzIG5vdCBl bWJyYWNpbmcgYW5kIGVuY291cmFnaW5nIGlubm92YXRpb24/ICBJIHN1cHBvc2UgaXQncyBhbGwg aW4gdGhlIGV5ZSBvZiB0aGUNCmJlaG9sZGVyIC0gYnV0IHRvIG1lIGl0IGZlZWxzIGxpa2UgImdp dmUgYW4gaW5jaCBhbmQgZ2V0IHB1c2hlZCBmb3IgYSBtaWxlIi4NCg0KSSB3b3VsZCB0aGVyZWZv cmUgc3VnZ2VzdCByZW1vdmluZyB0aGUgdGV4dCBvbiBpbXBsZW1lbnRhdGlvbg0Kc3R5bGVzIGFu ZCBkb2N1bWVudCBzdHJlYW0gY29uc3RyYWludHMuDQoNCklGIHRoZSBlbmNhcHN1bGF0aW9ucyBh cmUgc3BlY2lmaWVkIGluIGEgd2F5IHRoYXQgdHdvIGluZGVwZW5kZW50IGludGVyb3BlcmFibGUg aW1wbGVtZW50YXRpb25zDQphcmUgbm90IGF2YWlsYWJsZSwgaXQgYm90aCBpbmNyZWFzZXMgdGhl IHJpc2sgdGhhdCB3ZSBtaWdodCBlbmQgdXAgd2l0aCB0d28gZGlmZmVyZW50IHZlcnNpb25zIC0g b25lDQpFeHBlcmltZW50YWwgYW5kIGFub3RoZXIgdGhyb3VnaCBiaXR0ZXIgZXhwZXJpZW5jZSB0 aGF0IGlzIFBTIGxhdGVyIC0gYW5kIGlzIGEgcG9vciBpbmRpY2F0aW9uIG9mDQp0aGUgbGFjayBv ZiBpbmR1c3RyeSBzdXBwb3J0IGFuZCBpbnRlcmVzdCBpbiB0aGUgdGVjaG5vbG9neSBhbmQgaXRz IHVzZS4NCg0KUmVnYXJkcywNCkFsaWENCg0KDQotIFN0ZXdhcnQNCg0KDQpPbiAxMS8wMi8yMDE1 IDIwOjQ0LCBBbGlhIEF0bGFzIHdyb3RlOg0KSSBoYXZlIGJlZW4gd29ya2luZyBvbiBnZXR0aW5n IGEgY2hhcnRlciB0b2dldGhlciBmb3IgQklFUiB3aXRoIHRoZSBpbnRlbnQgb2YgcHVzaGluZyBm b3IgaXQgdG8gYmUgY2hhcnRlcmVkIGJlZm9yZSB0aGUgRGFsbGFzIElFVEYuICBUaGlzIGhhcyBu b3QgeWV0IGdvbmUgdGhyb3VnaCBJRVNHIHJldmlldyBhbmQgaXQgbWF5IGhhdmUgc29tZSBhc3Bl Y3RzIHVwZGF0ZWQuDQoNClBsZWFzZSBzZW5kIGNvbW1lbnRzIGhlcmUuDQoNClRoZSBjaGFydGVy IGNhbiBiZSBmb3VuZCBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXIt aWV0Zi1iaWVyLw0KYW5kIGlzIGluY2x1ZGVkIGJlbG93IGFzIHdlbGwuDQoNCg0KV0cgQ2hhaXJz Og0KICBHcmVnIFNoZXBoZXJkICA8Z2pzaGVwQGdtYWlsLmNvbTxtYWlsdG86Z2pzaGVwQGdtYWls LmNvbT4+DQogIFRvbnkgUHJ6eWdpZW5kYSA8dG9ueXNpZXRmQGdtYWlsLmNvbTxtYWlsdG86dG9u eXNpZXRmQGdtYWlsLmNvbT4+DQoNCg0KSW4gY29udmVudGlvbmFsIElQIG11bHRpY2FzdCBmb3J3 YXJkaW5nLCB0aGUgcGFja2V0cyBvZiBhIGdpdmVuDQptdWx0aWNhc3QgImZsb3ciIGFyZSBmb3J3 YXJkZWQgYWxvbmcgYSB0cmVlIHRoYXQgaGFzIGJlZW4gY29uc3RydWN0ZWQNCmZvciB0aGUgc3Bl Y2lmaWMgcHVycG9zZSBvZiBjYXJyeWluZyB0aGF0IGZsb3cuICBUaGlzIHJlcXVpcmVzIHRyYW5z aXQNCm5vZGVzIHRvIG1haW50YWluIHN0YXRlIG9uIGEgcGVyLWZsb3cgYmFzaXMsIGFuZCByZXF1 aXJlcyB0aGUgdHJhbnNpdA0Kbm9kZXMgdG8gcGFydGljaXBhdGUgaW4gbXVsdGljYXN0LXNwZWNp ZmljIHRyZWUgYnVpbGRpbmcgcHJvdG9jb2xzLg0KVGhlIGZsb3cgdG8gd2hpY2ggYSBwYWNrZXQg YmVsb25ncyBpcyBkZXRlcm1pbmVkIGJ5IGl0cyBJUCBzb3VyY2UgYW5kDQpkZXN0aW5hdGlvbiBh ZGRyZXNzIGZpZWxkcy4NCg0KQklFUiAoQml0IEluZGV4IEV4cGxpY2l0IFJlcGxpY2F0aW9uKSBp cyBhbiBhbHRlcm5hdGl2ZSBtZXRob2Qgb2YNCm11bHRpY2FzdCBmb3J3YXJkaW5nLiAgSXQgZG9l cyBub3QgcmVxdWlyZSBhbnkgbXVsdGljYXN0LXNwZWNpZmljDQp0cmVlcywgYW5kIGhlbmNlIGRv ZXMgbm90IHJlcXVpcmUgYW55IG11bHRpY2FzdC1zcGVjaWZpYyB0cmVlIGJ1aWxkaW5nDQpwcm90 b2NvbHMuICBXaXRoaW4gYSBnaXZlbiAiQklFUiBkb21haW4iLCBhbiBpbmdyZXNzIG5vZGUgZW5j YXBzdWxhdGVzDQphIG11bHRpY2FzdCBkYXRhIHBhY2tldCBpbiBhICJCSUVSIGhlYWRlciIuICBU aGUgQklFUiBoZWFkZXINCmlkZW50aWZpZXMgdGhlIHBhY2tldCdzIGVncmVzcyBub2RlcyBpbiB0 aGF0IGRvbWFpbi4gIEVhY2ggcG9zc2libGUNCmVncmVzcyBub2RlIGlzIHJlcHJlc2VudGVkIGJ5 IGEgYSBzaW5nbGUgYml0IHdpdGhpbiBhIGJpdHN0cmluZzsgdG8NCnNlbmQgYSBwYWNrZXQgdG8g YSBwYXJ0aWN1bGFyIHNldCBvZiBlZ3Jlc3Mgbm9kZXMsIHRoZSBpbmdyZXNzIG5vZGUNCnNldHMg dGhlIGJpdHMgZm9yIGVhY2ggb2YgdGhvc2UgZWdyZXNzIG5vZGVzLCBhbmQgY2xlYXJzIHRoZSBv dGhlcg0KYml0cyBpbiB0aGUgYmlzdHJpbmcuICBFYWNoIHBhY2tldCBjYW4gdGhlbiBiZSBmb3J3 YXJkZWQgYWxvbmcgdGhlDQp1bmljYXN0IHNob3J0ZXN0IHBhdGggdHJlZSBmcm9tIHRoZSBpbmdy ZXNzIG5vZGUgdG8gdGhlIGVncmVzcyBub2Rlcy4NClRodXMgdGhlcmUgYXJlIG5vIHBlci1mbG93 IGZvcndhcmRpbmcgZW50cmllcy4NCg0KRHVlIHRvIHRoZSBwYXJ0aWN1bGFyIHNlbnNpdGl2aXR5 IG9mIGFkZGluZyBuZXcgc2lnbmlmaWNhbnQNCmZ1bmN0aW9uYWxpdHkgaW50byB0aGUgZGF0YS1w bGFuZSBhdCBoaWdoIGxpbmsgc3BlZWRzLCB0aGUgQklFUiB3b3JrDQp3aWxsIHByb2dyZXNzIGFz IEV4cGVyaW1lbnRhbC4gIEFzIGRlc2NyaWJlZCBpbiBpdGVtICg5KSBiZWxvdywgdGhlDQp3b3Jr IG1heSBiZWNvbWUgU3RhbmRhcmRzIFRyYWNrIG9uY2UgdGhlcmUgaXMgc3VmZmljaWVudCBleHBl cmllbmNlDQp3aXRoIHRoZSBiZW5lZml0cyBhbmQgZG93bnNpZGVzIG9mIHRoZSB0ZWNobm9sb2d5 Lg0KDQpCSUVSIGlzIGluaXRpYWxseSBjaGFydGVyZWQgdG8gZG8gZXhwZXJpbWVudGFsIHdvcmsg b24gdGhpcyBuZXcNCm11bHRpY2FzdCBmb3J3YXJkaW5nIG1lY2hhbmlzbSBhcyBmb2xsb3dzOg0K DQogICAxKSBCSUVSIGFyY2hpdGVjdHVyZTogVGhlIFdHIHdpbGwgcHVibGlzaCBhbiBhcmNoaXRl Y3R1cmUsIGJhc2VkDQogICB1cG9uIGRyYWZ0LXdpam5hbmRzLWJpZXItYXJjaGl0ZWN0dXJlLTA0 LiAgSXQgd2lsbCBpbmNsdWRlIHRoZQ0KICAgbm9ybWF0aXZlIGFsZ29yaXRobSBmb3IgaG93IEJJ RVIgcGFja2V0IGZvcndhcmRpbmcgaXMgZG9uZS4gIEl0DQogICB3aWxsIHNwZWNpZnkgdGhlIGlu Zm9ybWF0aW9uIHRoYXQgaXMgcmVxdWlyZWQgYnkgYSBCSUVSIGhlYWRlciB0bw0KICAgc3VwcG9y dCBCSUVSIGZvcndhcmRpbmcuDQoNCiAgIDIpIEJJRVIgZW5jYXBzdWxhdGlvbjogVGhlIHdvcmtp bmcgZ3JvdXAgc2hvdWxkIGFzc3VtZSB0aGF0IHRoZQ0KICAgdGVjaG5vbG9neSB3aWxsIG5lZWQg dG8gYmUgZW1iZWRkZWQgaW4gdGhlIGRhdGEgcGxhbmUgYW5kIG9wZXJhdGUNCiAgIGF0IHRoZSBo aWdoZXN0IHBhY2tldCBsaW5lIHNwZWVkcy4gIFRoZSBXRyB3aWxsIHB1Ymxpc2ggYSBkb2N1bWVu dA0KICAgZGVmaW5pbmcgYW4gTVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9uIGJhc2VkIHVwb24NCiAg IGRyYWZ0LXdpam5hbmRzLW1wbHMtYmllci1lbmNhcHN1bGF0aW9uLTAyLiBEdWUgdG8gdGhlIGNy aXRpY2FsIG5lZWQNCiAgIHRvIGhhdmUgYSBoaWdoLXF1YWxpdHkgYW5kIHN0YWJsZSBSRkMgZm9y IGEgbmV3IGRhdGEtcGxhbmUNCiAgIGVuY2Fwc3VsYXRpb24sIHRoZSBNUExTLWJhc2VkIGVuY2Fw c3VsYXRpb24gZHJhZnQgc2hhbGwgd2FpdCBhZnRlcg0KICAgV0dMQyBhbmQgbm90IHByb2dyZXNz IHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d28NCiAgIGluZGVwZW5kZW50IGlu dGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLg0KDQogICBBcyBhIHNlY29uZGFyeSBmb2N1cywg dGhlIFdHIG1heSBhbHNvIHdvcmsgb24gb25lIG5vbi1NUExTDQogICBkYXRhLXBsYW5lIGVuY2Fw c3VsYXRpb24uICBUaGlzIGRyYWZ0IGFsc28gc2hhbGwgd2FpdCBhZnRlciBXR0xDDQogICBhbmQg bm90IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d28gaW5kZXBl bmRlbnQNCiAgIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLiAgVGhpcyBkcmFmdCBtdXN0 IGZvY3VzIG9uIGFuZA0KICAgaW5jbHVkZSB0aGUgZm9sbG93aW5nIGRldGFpbHM6DQoNCiAgICAg ICBhKSBXaGF0IGlzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBlbmNhcHN1bGF0aW9uIGFuZCBm b3Igd2hpY2gNCiAgICAgICB1c2UtY2FzZXMgaXMgdGhpcyBlbmNhcHN1bGF0aW9uIHJlcXVpcmVk Pw0KDQogICAgICAgYikgRG9lcyB0aGlzIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24gaW1wbHkgYW55 IGNoYW5nZXMgdG8gdGhlDQogICAgICAgTVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9uPw0KDQogICAg ICAgYykgV2hhdCBkZXNpZ24gY2hvaWNlcyBoYXZlIGJlZW4gbWFkZSBmb3IgdGhlIGVuY2Fwc3Vs YXRpb24NCiAgICAgICB0eXBlIGFuZCB0aGUgaW5jbHVkZWQgZmllbGRzLg0KDQogICAgICAgZCkg VGhlIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24gd2l0aCBjb25zaWRlcmF0aW9ucyBnaXZlbiB0byBh dA0KICAgICAgIGxlYXN0IE9BTSwgQ2xhc3Mgb2YgU2VydmljZSwgc2VjdXJpdHksIGZyYWdtZW50 YXRpb24sIFRUTC4NCg0KICAgMykgVHJhbnNpdGlvbiBNZWNoYW5pc21zOiBUaGUgV0cgd2lsbCBk ZXNjcmliZSBob3cgQklFUiBjYW4gYmUNCiAgIHBhcnRpYWxseSBkZXBsb3llZCBhbmQgc3RpbGwg cHJvdmlkZSB1c2VmdWwgZnVuY3Rpb25hbGl0eS4gIEENCiAgIG1pbmltdW0gb2YgdGhlIG5lY2Vz c2FyeSBtZWNoYW5pc21zIHRvIHN1cHBvcnQgaW5jcmVtZW50YWwNCiAgIGRlcGxveW1lbnQgYW5k L29yIG1hbmFnaW5nIGRpZmZlcmVudCBCSUVSIG1hc2stbGVuZ3RoIGNvbXBhdGliaWxpdHkNCiAg IG1heSBiZSBkZWZpbmVkLiAgRWFjaCBzdWNoIG1lY2hhbmlzbSBtdXN0IGluY2x1ZGUgYW4gYXBw bGljYWJpbGl0eQ0KICAgc3RhdGVtZW50IHRvIGRpZmZlcmVudGlhdGUgaXRzIG5lY2Vzc2l0eSBm cm9tIG90aGVyIHByb3Bvc2VkDQogICBtZWNoYW5pc21zLg0KDQogICA0KSBBcHBsaWNhYmlsaXR5 IFN0YXRlbWVudHM6IFRoZSBXRyB3aWxsIHdvcmsgb24gYSBkb2N1bWVudA0KICAgZGVzY3JpYmlu ZyBob3cgQklFUiBjYW4gYmUgYXBwbGllZCB0byBtdWx0aWNhc3QgTDNWUE4gYW5kIHRvIEVWUE4u DQogICBUaGlzIGRyYWZ0IHdpbGwgZGVzY3JpYmUgd2hhdCBtZWNoYW5pc20gaXMgdXNlZCB0byBj b21tdW5pY2F0ZSB0aGUNCiAgIGdyb3VwIG1lbWJlcnNoaXAgYmV0d2VlbiB0aGUgaW5ncmVzcyBy b3V0ZXIgYW5kIHRoZSBlZ3Jlc3Mgcm91dGVycywNCiAgIHdoYXQgc2NhbGFiaWxpdHkgY29uc2lk ZXJhdGlvbnMgbWF5IGFyaXNlLCBhbmQgYW55IGRlcGxveW1lbnQNCiAgIGNvbnNpZGVyYXRpb25z Lg0KDQogICA1KSBVc2UgQ2FzZTogVGhlIFdHIG1heSBwcm9kdWNlIG9uZSB1c2UtY2FzZSBkb2N1 bWVudCB0aGF0IGNsZWFybHkNCiAgIGFydGljdWxhdGVzIHRoZSBwb3RlbnRpYWwgYmVuZWZpdHMg b2YgQklFUiBmb3IgZGlmZmVyZW50IHVzZS1jYXNlcy4NCiAgIFRoaXMgd291bGQgYmUgYmFzZWQg dXBvbiBkcmFmdC1rdW1hci1iaWVyLXVzZS1jYXNlcy0wMS4NCg0KICAgNikgT0FNOiBUaGUgV0cg d2lsbCBkZXNjcmliZSBob3cgT0FNIHdpbGwgd29yayBpbiBhIEJJRVIgZG9tYWluIGFuZA0KICAg d2hhdCBzaW1wbGlmaWNhdGlvbnMgQklFUiBvZmZlcnMgZm9yIG1hbmFnaW5nIHRoZSBtdWx0aWNh c3QNCiAgIHRyYWZmaWMuICBBIHN0cm9uZyBwcmVmZXJlbmNlIHdpbGwgYmUgZ2l2ZW4gdG8gZXh0 ZW5zaW9ucyB0bw0KICAgZXhpc3RpbmcgcHJvdG9jb2xzLg0KDQogICA3KSBNYW5hZ2VtZW50IG1v ZGVsczogVGhlIFdHIG1heSB3b3JrIG9uIFlBTkcgbW9kZWxzIGFuZCwgaWYgbmVlZGVkLA0KICAg TUlCIG1vZHVsZXMgdG8gc3VwcG9ydCBjb21tb24gbWFuYWdlYWJpbGl0eS4NCg0KICAgOCkgSUdQ IGV4dGVuc2lvbnMuICBXaGVuIGEgQklFUiBkb21haW4gZmFsbHMgd2l0aGluIGEgImxpbmsgc3Rh dGUgSUdQIiINCiAgIG5ldHdvcmssIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgdG8gc2V0IHVwIHRo ZSBCSUVSIGZvcndhcmRpbmcgdGFibGVzDQogICAoZS5nLiwgdGhlIG1hcHBpbmcgYmV0d2VlbiBh IGdpdmVuIGJpdCBwb3NpdGlvbiBhbmQgYSBnaXZlbiBlZ3Jlc3MNCiAgIHJvdXRlcikgbWF5IGJl IGNhcnJpZWQgaW4gdGhlIGxpbmsgc3RhdGUgYWR2ZXJ0aXNlbWVudHMgb2YgdGhlIElHUC4gIFRo ZQ0KICAgbGluayBzdGF0ZSBhZHZlcnRpc21lbnRzIG1heSBhbHNvIGNhcnJ5IG90aGVyIGluZm9y bWF0aW9uIHJlbGF0ZWQgdG8NCiAgIGZvcndhcmRpbmcgKGUuZy4sIHRoZSBJR1AgbWF5IHN1cHBv cnQgbXVsdGlwbGUgdG9wb2xvZ2llcywgaW4gd2hpY2ggY2FzZQ0KICAgaXQgbWF5IGJlIG5lY2Vz c2FyeSB0byBhZHZlcnRpc2Ugd2hpY2ggdG9wb2xvZ2llcyBhcmUgdG8gYmUgdXNlZCBmb3IgQklF Ug0KICAgZm9yd2FyZGluZykuICBBbnkgbmVjZXNzYXJ5IGV4dGVuc2lvbnMgdG8gdGhlIElHUCB3 aWxsIGJlIHNwZWNpZmllZCBieQ0KICAgdGhlIFdHLCBpbiBjb29wZXJhdGlvbiB3aXRoIHRoZSBJ U0lTIGFuZCBPU1BGIFdHcy4NCg0KICAgOSkgRGVwbG95bWVudCBFeHBlcmllbmNlOiBPbmNlIHRo ZXJlIGlzIGRlcGxveW1lbnQgZXhwZXJpZW5jZSwgdGhlDQogICBXRyB3aWxsIHByb2R1Y2UgYSBk b2N1bWVudCBkZXNjcmliaW5nIHRoZSBiZW5lZml0cywgcHJvYmxlbXMsIGFuZA0KICAgdHJhZGUt b2ZmcyBmb3IgdXNpbmcgQklFUiBpbnN0ZWFkIG9mIHRyYWRpdGlvbmFsIG11bHRpY2FzdA0KICAg Zm9yd2FyZGluZyBtZWNoYW5pc21zLiAgSWRlYWxseSwgdGhpcyBzaG91bGQgYWxzbyBjb250YWlu IGFuDQogICBhbmFseXNpcyBvZiB0aGUgaW1wYWN0IGFuZCBiZW5lZml0IG9mIHRoZSBuZXcgQklF UiBkYXRhLXBsYW5lIHRvDQogICB0aGUgb3ZlcmFsbCBJbnRlcm5ldCBhcmNoaXRlY3R1cmUuICBU aGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGJlDQogICB1c2VkIHRvIGV2YWx1YXRlIHdoZXRo ZXIgdG8gcmVjaGFydGVyIEJJRVIgdG8gcHJvZHVjZSBTdGFuZGFyZHMNCiAgIFRyYWNrIFJGQ3Mu DQoNClRoZSBCSUVSIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb29yZGluYXRlIHdpdGggc2V2ZXJhbCBk aWZmZXJlbnQgd29ya2luZw0KZ3JvdXBzIGFuZCBtdXN0IGluY2x1ZGUgdGhlIHJlbGV2YW50IG90 aGVyIHdvcmtpbmcgZ3JvdXBzIGR1cmluZw0Kd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gdGhl IHJlbGV2YW50IGRyYWZ0cy4gIEJJRVIgd2lsbCBjb29yZGluYXRlDQp3aXRoIE1QTFMgb24gdGhl IE1QTFMtYmFzZWQgZW5jYXBzdWxhdGlvbiBhbmQgYXNzb2NpYXRlZCBNUExTLWJhc2VkDQpPQU0g bWVjaGFuaXNtcy4gIEJJRVIgd2lsbCBjb29yZGluYXRlIHdpdGggSVNJUyBhbmQgT1NQRiBvbiBl eHRlbnNpb25zDQp0byBmbG9vZCBCSUVSLXJlbGF0ZWQgaW5mb3JtYXRpb24uICBCSUVSIHdpbGwg Y29vcmRpbmF0ZSB3aXRoIEJFU1MgYW5kDQpJRFIgb24gdGhlIGFwcGxpY2FiaWxpdHkgb2YgZXhp c3RpbmcgQkdQLWJhc2VkIG1lY2hhbmlzbXMgZm9yDQpwcm92aWRpbmcgbXVsdGljYXN0IGdyb3Vw IG1lbWJlcnNoaXAgaW5mb3JtYXRpb24uDQoNClJlZ2FyZHMsDQpBbGlhDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQklFUiBtYWlsaW5nIGxp c3QNCg0KQklFUkBpZXRmLm9yZzxtYWlsdG86QklFUkBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyDQoNCg0KDQoNCi0tDQoNCkZvciBjb3Jwb3Jh dGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQoNCg0KDQpodHRwOi8vd3d3LmNpc2NvLmNvbS93 ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwNCg0KDQoNCg== --_000_4A496052E7B7E84A9324854763C616FA233CF4DAC111GTUHMBX56ER_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6 MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2Vu emI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+QWxpYSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkkgaGF2ZSBiZWVuIGVuZ2FnZWQgd2l0aCBCSUVSIHRlY2hub2xvZ3kgZm9yIHRoZSBs YXN0IHllYXIgYW5kIGEgaGFsZiBmcm9tIGl0cyBpbmNlcHRpb24uIEl0IGNvbWUgYWxvbmcgd2F5 IGFuZCBpdCB3YXMgbm90IGRyaXZlbiBqdXN0IGJhc2VkIG9uIGV4Y2l0ZW1lbnQuIFRoaXMgd29y ayBpcyBiYWNrZWQgdXAgYnkgY29tbWl0bWVudCBmcm9tIG1ham9yIHZlbmRvcnMgYW5kIG11bHRp cGxlIG9wZXJhdG9ycy4NCiBJIGhhdmUgZGlzY3Vzc2VkIEJJRVIgb24gbXVsdGlwbGUgb2NjYXNp b25zIHdpdGggb3RoZXIgb3BlcmF0b3JzLCB0aGV5IHNob3dlZCBhIGdyZWF0IGludGVyZXN0IGFu ZCBzdHJvbmcgc3VwcG9ydCB3aXRoIG92ZXJhbGwgY29uc2Vuc3VzIHRoYXQgQklFUiB3aWxsIGJ1 aWxkIGEgcmlnaHQgZm91bmRhdGlvbiBmb3IgZWZmaWNpZW50IG11bHRpY2FzdCBkZWxpdmVyeSBm b3Igb3BlcmF0b3JzIHRvIHN0YW5kYXJkaXplLiBJIHByb21vdGVkIEJJRVINCiB3aXRoaW4gVGhv bXNvbiBSZXV0ZXJzIG9uIHRoZSBCdXNpbmVzcyBhbmQgVGVjaG5vbG9neSBzaWRlcyBhbmQgZmVl ZGJhY2sgd2FzIG92ZXJ3aGVsbWluZywgd2l0aCBodWdlIGludGVyZXN0IGZyb20gVGhvbXNvbiBS ZXV0ZXJzIGRldmVsb3BtZW50IGNvbW11bml0eS4gQmFzZWQgb24gbXkgaW52b2x2ZW1lbnQgd2l0 aCBCSUVSLCBJIHN0cnVnZ2xlIHRvIGRlZmluZSBpdCBhcyBFeHBlcmltZW50YWwgYXMgcGVyIGlu Y2x1ZGVkIGRlZmluaXRpb24NCiBiZWxvdyBhbmQgSSBjb21wbGV0ZWx5IGFncmVlIHdpdGggU3Rl d2FydCBvbiBoaXMgYXNzZXNzbWVudCBvZiB5b3VyIHByb3Bvc2VkIGNoYXJ0ZXIuIFBsZWFzZSBk b24ndCB0YWtlIGl0IGFzIGEgY3JpdGljaXNtLCBJIGFtIHZlcnkgbm92aWNlIGluIHRlcm1zIG9m IElFVEYgcHJvdG9jb2xzIGFuZCBwcm9jZWR1cmVzIGJ1dCBhcyBwZXIgbXkgZmluZGluZ3Mgb2Yg SUVURiBkZWZpbml0aW9uczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZxdW90O1dHIGNoYXJ0ZXJzIHN0YXRlIHRoZSBzY29wZSBvZiB3b3JrIGZvciBncm91cCwgYW5k IGxheSBvdXQgZ29hbHMgYW5kIG1pbGVzdG9uZXMgdGhhdCBzaG93IGhvdyB0aGlzIHdvcmsgd2ls bCBiZSBjb21wbGV0ZWQuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5UaGUgcHJvcG9zZWQgdmVyc2lvbiBpbiB0aGUgd2F5IGl0IHdhcyB3cml0dGVuIG1vcmUg Zm9jdXNpbmcgb24gY29uZGl0aW9uYWwgc3RhdGVtZW50cyBhbmQgZGVwaWN0cyBzb21lIHVud2ls bGluZ25lc3Mgb2YgSUVURiB0byBwcm9tb3RlL3Byb2NlZWQgd2l0aCBCSUVSIGFzIGEgY29tbWl0 dGVkIHdvcmsuJm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+U25hcHNob3QgZnJvbSBJRVRGLm9yZyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPuKAnDQuMi4xIEV4cGVyaW1lbnRhbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+VGhlICZxdW90O0V4cGVyaW1lbnRhbCZxdW90OyBkZXNpZ25hdGlvbiB0 eXBpY2FsbHkgZGVub3RlcyBhIHNwZWNpZmljYXRpb24gdGhhdCBpcyBwYXJ0IG9mIHNvbWUgcmVz ZWFyY2ggb3IgZGV2ZWxvcG1lbnQgZWZmb3J0LiBTdWNoIGEgc3BlY2lmaWNhdGlvbiBpcyBwdWJs aXNoZWQgZm9yIHRoZSBnZW5lcmFsIGluZm9ybWF0aW9uIG9mIHRoZSBJbnRlcm5ldCB0ZWNobmlj YWwgY29tbXVuaXR5IGFuZCBhcyBhbiBhcmNoaXZhbA0KIHJlY29yZCBvZiB0aGUgd29yaywgc3Vi amVjdCBvbmx5IHRvIGVkaXRvcmlhbCBjb25zaWRlcmF0aW9ucyBhbmQgdG8gdmVyaWZpY2F0aW9u IHRoYXQgdGhlcmUgaGFzIGJlZW4gYWRlcXVhdGUgY29vcmRpbmF0aW9uIHdpdGggdGhlIHN0YW5k YXJkcyBwcm9jZXNzIChzZWUgYmVsb3cpLiBBbiBFeHBlcmltZW50YWwgc3BlY2lmaWNhdGlvbiBt YXkgYmUgdGhlIG91dHB1dCBvZiBhbiBvcmdhbml6ZWQgSW50ZXJuZXQgcmVzZWFyY2ggZWZmb3J0 IChlLmcuLA0KIGEgUmVzZWFyY2ggR3JvdXAgb2YgdGhlIElSVEYpLCBhbiBJRVRGIFdvcmtpbmcg R3JvdXAsIG9yIGl0IG1heSBiZSBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dGlvbi7igJ08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JIHdvdWxkIGxpa2UgdG8gY29udGludWUgdG8gcHJvbW90ZSBCSUVSIGFuZCB0YWtl IGFuIGFjdGl2ZSBwYXJ0IGluIGRldmVsb3Bpbmcgb2YgbmV3IG11bHRpY2FzdCB0ZWNobm9sb2dp ZXMgZm9yIG15IGNvbXBhbnkgYW5kIGluZHVzdHJ5IGJlbmVmaXRzLiBUaGVyZSBhcmUgcGxlbnR5 IG9mIGNoYWxsZW5nZXMgaW4gdGhpcyBhcmVuYSwgYnV0IG9ubHkgdmlhIGFjdGl2ZSBwYXJ0aWNp cGF0aW9uIHRoZXNlDQogY2hhbGxlbmdlcyBjYW4gYmUgcmVzb2x2ZWQuIFdlIG5lZWQgdG8gc2Vl IGNvbW1pdG1lbnQgZnJvbSBJRVRGIHRvIG1vdmUgQklFUiBkZXZlbG9wbWVudCBmb3J3YXJkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+QXJrYWRpeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gQklFUiBbbWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+QWxpYSBBdGxhczxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVi cnVhcnkgMTIsIDIwMTUgMTA6MTQgQU08YnI+DQo8Yj5Ubzo8L2I+IHN0YnJ5YW50PGJyPg0KPGI+ Q2M6PC9iPiBBZHJpYW4gRmFycmVsOyBiaWVyQGlldGYub3JnOyBpZXNnQGlldGYub3JnOyBBbHZh cm8gUmV0YW5hPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQmllcl0gcHJvcG9zZWQgQklFUiBj aGFydGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdGV3 YXJ0LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjZXJ0 YWlubHkgYXBwcmVjaWF0ZSB5b3VyIHRha2luZyB0aGUgdGltZSB0byBwcm92aWRlIGZlZWRiYWNr LiZuYnNwOyBJIHVuZGVyc3RhbmQgdGhhdCB5b3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFyZSBleGNpdGVkIGJ5IHRoaXMgdGVjaG5vbG9neSBh bmQgaGF2ZSB1cmdlZCB0aGF0IGlubm92YXRpb24gbmVlZHMgdGltZSBhbmQgc3BhY2U8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIGJlIHdvcmtl ZCBvbiBiZWZvcmUgYmVpbmcgZXZhbHVhdGVkIGJ5IHRoZSBoYXJzaCByZWFsaXRpZXMgb2YgdGhl IG1hcmtldHBsYWNlIGFuZCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+aW50ZXJlc3QgaW4gZGVwbG95bWVudHMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEZlYiAxMiwgMjAxNSBhdCA4 OjQ0IEFNLCBTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0YnJ5YW50QGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0YnJ5YW50QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGlhPGJy Pg0KPGJyPg0KSSB0aGluayB0aGF0IHlvdSBhcmUgY3Jvc3NpbmcgZmFyIHRvbyBtYW55IGJyaWRn ZXMgYmVmb3JlIHlvdSBnZXQgdG8gdGhlbTxicj4NCmluIHRlcm1zIG9mIHlvdSBleHBlY3RhdGlv biBvZiB3aGVyZSBCSUVSIHdpbGwgYmUgZGVwbG95ZWQgYW5kIGhvdzxicj4NCml0IHdpbGwgYmUg aW1wbGVtZW50ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBkaWQgcmVhZCB0aGUgdXNlLWNhc2VzIGFuZCB1bmRlcnN0YW5k IHRoZSBwcmltYXJ5IG1vdGl2YXRpb24gaXMgZm9yIE1WUE4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCBFVlBOIHdoaWNoIGFyZSBk ZXBsb3llZCBpbiB0aGUgYmFja2JvbmUgb2YgU1AgbmV0d29ya3MgdGhhdCBvcGVyYXRlIGF0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5oaWdoIHNw ZWVkcy4mbmJzcDsgRXZlbiBpbiBkYXRhLWNlbnRlcnMsIHVzZSBvZiAxMEcgbGlua3MgaXMgY29t bW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjaGFydGVyIHNob3VsZCBub3QgaW5jbHVkZSBzdWNo IHNwZWNpZmljIGFzc3VtcHRpb25zLCBwYXJ0aWN1bGFybHk8YnI+DQpnaXZlbiB0aGUgZmFzdCBt b3ZpbmcgY2hhbmdlcyB0aGF0IGFyZSBoYXBwZW5pbmcgaW4gb3VyIGluZHVzdHJ5PGJyPg0KZXNw ZWNpYWxseSBpbiB0aGUgYXJlYSBvZiBwYWNrZXQgZm9yd2FyZGluZyBkZXNpZ24uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2hhdCBzcGVjaWZpY2FsbHkgYXJlIHlvdSBvYmplY3RpbmcgdG8/Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIG5vdCBzZWVuIHN1Y2ggYXNzdW1wdGlvbnMgaW4gb3Ro ZXIgY2hhcnRlcnMgYW5kIEkgZG9uJ3QgdGhpbms8YnI+DQp0aGF0IHRoZXkgaGF2ZSBhIHBsYWNl IGluIHRoaXMgb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgc3BlY2lmaWMgYXNzdW1wdGlv biBhcmUgeW91IG9iamVjdGluZyB0byBhbmQgd2hhdCByZWFzb25pbmcgZG8geW91IGhhdmU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJleW9uZCBo aXN0b3JpY2FsPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRlcm1zIG9mIGNob2ljZSBvZiBkb2N1bWVu dCBzdHJlYW0gKGV4cGVyaW1lbnRhbCB2cyBQUyksIDxicj4NCnRoYXQgaXMgYSBkZWNpc2lvbiB0 aGF0IGNhbiBiZSB0YWtlbiBhdCB0aGUgdGltZSBvZiBwdWJsaWNhdGlvbiA8YnI+DQp3aGVuIG1v cmUgaW5mb3JtYXRpb24gd2lsbCBiZSBhdmFpbGFibGUgaW4gdGVybXMgb2YgcG90ZW50aWFsIDxi cj4NCm1hcmtldCB0YWtlLXVwLCBleHBlY3RlZC9hY3R1YWwgZGVwbG95bWVudCBzY2VuYXJpb3Ms IDxicj4NCmJyZWFkdGggb2YgaW1wbGVtZW50YXRpb24gYW5kIGltcGxlbWVudGF0aW9uIGV4cGVy aWVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgdGhpcyB0aW1lLCBhIHN1ZmZpY2llbnRseSBj b21wZWxsaW5nIGNhc2UgaGFzIG5vdCBiZWVuIG1hZGUgdG8gY29udmluY2UgdGhhdDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UFMgaXMgYW55d2hl cmUgbmVhciBhcHByb3ByaWF0ZSBmb3IgdGhpcyBjaGFuZ2Ugb2YgYWRkaW5nIGEgY29tcGxldGVs eSBuZXcgZm9yd2FyZGluZyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+YWxnb3JpdGhtIGFuZCBhIGZvdXJ0aCAmbmJzcDtlbmNhcHN1bGF0 aW9uIHRvIGdvIHdpdGggSVB2NCwgSVB2NiwgYW5kIE1QTFMgdG8gdGhlIEludGVybmV0Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hcmNo aXRlY3R1cmUgZm9yIHRoZSBuZXh0IDE1JiM0MzsgeWVhcnMuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIHRydWUgdGhhdCBp ZiB0aGF0IGNoYW5nZXMgYmV0d2VlbiBub3cgYW5kIHdoZW4gZHJhZnRzIGFyZSByZWFkeSB0byBw cm9ncmVzcywgdGhhdCBjYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmJlIHJldmlzaXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIFdHcyB0aGF0IGhhdmUgYmVlbiBjaGFy dGVyZWQgdG8gZG8gZXhwZXJpbWVudGFsIHdvcmsgaW4gdGhlIHBhc3QuJm5ic3A7IEkgdW5kZXJz dGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ dGhhdCBpdCBpcyBkaXNhcHBvaW50aW5nIHRoYXQgdGhlcmUgd2Fzbid0IGEgc3Ryb25nIGNhc2Ug Zm9yIG1vcmUgdGhhbiBleHBlcmltZW50YWwgYXQgdGhpcyB0aW1lLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYmVlbiBleHRyZW1l bHkgY2xlYXIgc2luY2UgdGhlIGxhc3QgSUVURiB0aGF0IEkgd2FzIG9ubHkgY29uc2lkZXJpbmcg RXhwZXJpbWVudGFsIGZvciZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+dGhlIFdHIGZvciB0aGUgaW5pdGlhbCBjaGFydGVyaW5nLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldoaWxzdCB0aGlzIHRlY2hub2xvZ3kgbWF5IGJlIGRlcGxveWVkIGluIHRo ZSBJbnRlcm5ldCBjb3JlLDxicj4NCml0IG15IGFsc28gYmUgZGVwbG95ZWQgYXQgdGhlIGVkZ2Ug d2hlcmUgYSBtdWNoIGxvd2VyIHRocmVzaG9sZDxicj4NCmlzIGFwcGxpY2FibGUuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIHRlY2hub2xvZ3kgbmVlZHMgdG8gd29yayBpbiBib3RoIGxvY2F0aW9u cyAtIGdpdmVuIHRoZSB1c2UtY2FzZXMuJm5ic3A7IFdoYXQgc3BlY2lmaWNhbGx5IGFyZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+eW91IG9iamVj dGluZyB0bz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGZlYXIgdGhhdCBieSBpbnRyb2R1Y2luZyB0aGVz ZSBjYXZlYXRzIHRoZSBJRVRGIGlzIGVudHJlbmNoaW5nIHRoZTxicj4NCnBlcmNlcHRpb24gdGhh dCBpdCBzbG93cyB0ZWNobm9sb2d5IGRvd24gcmF0aGVyIHRoYW4gZW1icmFjaW5nPGJyPg0KYW5k IGVuY291cmFnaW5nIGlubm92YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnkgY3JlYXRpbmcg YSBXRyBmb3Igb3BlbiBjb2xsYWJvcmF0aW9uIGFuZCBkZWZpbmluZyBhbiBhbWJpdGlvdXMgbmV3 IGZvcndhcmRpbmcgdGVjaG5vbG9neSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBJRVRGIGlzIG5vdCBlbWJyYWNpbmcgYW5kIGVuY291cmFn aW5nIGlubm92YXRpb24/Jm5ic3A7IEkgc3VwcG9zZSBpdCdzIGFsbCBpbiB0aGUgZXllIG9mIHRo ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YmVo b2xkZXIgLSBidXQgdG8gbWUgaXQgZmVlbHMgbGlrZSAmcXVvdDtnaXZlIGFuIGluY2ggYW5kIGdl dCBwdXNoZWQgZm9yIGEgbWlsZSZxdW90Oy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxk IHRoZXJlZm9yZSBzdWdnZXN0IHJlbW92aW5nIHRoZSB0ZXh0IG9uIGltcGxlbWVudGF0aW9uPGJy Pg0Kc3R5bGVzIGFuZCBkb2N1bWVudCBzdHJlYW0gY29uc3RyYWludHMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SUYgdGhlIGVuY2Fwc3VsYXRpb25zIGFyZSBzcGVjaWZpZWQgaW4gYSB3YXkgdGhhdCB0 d28gaW5kZXBlbmRlbnQgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFyZSBub3QgYXZhaWxhYmxl LCBpdCBib3RoIGluY3JlYXNlcyB0aGUgcmlzayB0aGF0IHdlIG1pZ2h0IGVuZCB1cCB3aXRoIHR3 byBkaWZmZXJlbnQgdmVyc2lvbnMgLSBvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4cGVyaW1lbnRhbCBhbmQgYW5vdGhlciB0aHJvdWdoIGJp dHRlciBleHBlcmllbmNlIHRoYXQgaXMgUFMgbGF0ZXIgLSBhbmQgaXMgYSBwb29yIGluZGljYXRp b24gb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnRoZSBsYWNrIG9mIGluZHVzdHJ5IHN1cHBvcnQgYW5kIGludGVyZXN0IGluIHRoZSB0ZWNobm9s b2d5IGFuZCBpdHMgdXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWxpYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0gU3Rld2FydDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQpPbiAxMS8wMi8yMDE1IDIwOjQ0LCBBbGlhIEF0bGFzIHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGhhdmUgYmVlbiB3b3JraW5nIG9uIGdldHRpbmcgYSBjaGFydGVyIHRv Z2V0aGVyIGZvciBCSUVSIHdpdGggdGhlIGludGVudCBvZiBwdXNoaW5nIGZvciBpdCB0byBiZSBj aGFydGVyZWQgYmVmb3JlIHRoZSBEYWxsYXMgSUVURi4mbmJzcDsgVGhpcyBoYXMgbm90IHlldCBn b25lIHRocm91Z2ggSUVTRyByZXZpZXcgYW5kIGl0IG1heSBoYXZlIHNvbWUgYXNwZWN0cyB1cGRh dGVkLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVh c2Ugc2VuZCBjb21tZW50cyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGNoYXJ0ZXIgY2FuIGJlIGZvdW5kIGF0IDxhIGhyZWY9Imh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLWJpZXIvIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1iaWVyLzwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFu ZCBpcyBpbmNsdWRlZCBiZWxvdyBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XRyBDaGFpcnM6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgR3JlZyBTaGVw aGVyZCAmbmJzcDsmbHQ7PGEgaHJlZj0ibWFpbHRvOmdqc2hlcEBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5nanNoZXBAZ21haWwuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBUb255IFByenlnaWVuZGEgJmx0Ozxh IGhyZWY9Im1haWx0bzp0b255c2lldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dG9ueXNp ZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gY29udmVudGlvbmFsIElQIG11bHRpY2FzdCBmb3J3YXJk aW5nLCB0aGUgcGFja2V0cyBvZiBhIGdpdmVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tdWx0aWNhc3QgJnF1b3Q7ZmxvdyZxdW90OyBhcmUgZm9y d2FyZGVkIGFsb25nIGEgdHJlZSB0aGF0IGhhcyBiZWVuIGNvbnN0cnVjdGVkPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mb3IgdGhlIHNwZWNpZmlj IHB1cnBvc2Ugb2YgY2FycnlpbmcgdGhhdCBmbG93LiZuYnNwOyBUaGlzIHJlcXVpcmVzIHRyYW5z aXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm5v ZGVzIHRvIG1haW50YWluIHN0YXRlIG9uIGEgcGVyLWZsb3cgYmFzaXMsIGFuZCByZXF1aXJlcyB0 aGUgdHJhbnNpdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+bm9kZXMgdG8gcGFydGljaXBhdGUgaW4gbXVsdGljYXN0LXNwZWNpZmljIHRyZWUgYnVp bGRpbmcgcHJvdG9jb2xzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGZsb3cgdG8gd2hpY2ggYSBwYWNrZXQgYmVsb25ncyBpcyBkZXRlcm1p bmVkIGJ5IGl0cyBJUCBzb3VyY2UgYW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5kZXN0aW5hdGlvbiBhZGRyZXNzIGZpZWxkcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QklFUiAoQml0IElu ZGV4IEV4cGxpY2l0IFJlcGxpY2F0aW9uKSBpcyBhbiBhbHRlcm5hdGl2ZSBtZXRob2Qgb2Y8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm11bHRpY2Fz dCBmb3J3YXJkaW5nLiZuYnNwOyBJdCBkb2VzIG5vdCByZXF1aXJlIGFueSBtdWx0aWNhc3Qtc3Bl Y2lmaWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnRyZWVzLCBhbmQgaGVuY2UgZG9lcyBub3QgcmVxdWlyZSBhbnkgbXVsdGljYXN0LXNwZWNpZmlj IHRyZWUgYnVpbGRpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnByb3RvY29scy4mbmJzcDsgV2l0aGluIGEgZ2l2ZW4gJnF1b3Q7QklFUiBkb21h aW4mcXVvdDssIGFuIGluZ3Jlc3Mgbm9kZSBlbmNhcHN1bGF0ZXM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEgbXVsdGljYXN0IGRhdGEgcGFja2V0 IGluIGEgJnF1b3Q7QklFUiBoZWFkZXImcXVvdDsuJm5ic3A7IFRoZSBCSUVSIGhlYWRlcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aWRlbnRpZmll cyB0aGUgcGFja2V0J3MgZWdyZXNzIG5vZGVzIGluIHRoYXQgZG9tYWluLiZuYnNwOyBFYWNoIHBv c3NpYmxlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5lZ3Jlc3Mgbm9kZSBpcyByZXByZXNlbnRlZCBieSBhIGEgc2luZ2xlIGJpdCB3aXRoaW4gYSBi aXRzdHJpbmc7IHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5zZW5kIGEgcGFja2V0IHRvIGEgcGFydGljdWxhciBzZXQgb2YgZWdyZXNzIG5vZGVz LCB0aGUgaW5ncmVzcyBub2RlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5zZXRzIHRoZSBiaXRzIGZvciBlYWNoIG9mIHRob3NlIGVncmVzcyBub2Rl cywgYW5kIGNsZWFycyB0aGUgb3RoZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmJpdHMgaW4gdGhlIGJpc3RyaW5nLiZuYnNwOyBFYWNoIHBhY2tl dCBjYW4gdGhlbiBiZSBmb3J3YXJkZWQgYWxvbmcgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj51bmljYXN0IHNob3J0ZXN0IHBhdGggdHJlZSBm cm9tIHRoZSBpbmdyZXNzIG5vZGUgdG8gdGhlIGVncmVzcyBub2Rlcy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRodXMgdGhlcmUgYXJlIG5vIHBl ci1mbG93IGZvcndhcmRpbmcgZW50cmllcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RHVlIHRvIHRoZSBwYXJ0aWN1bGFyIHNlbnNpdGl2aXR5 IG9mIGFkZGluZyBuZXcgc2lnbmlmaWNhbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZ1bmN0aW9uYWxpdHkgaW50byB0aGUgZGF0YS1wbGFuZSBh dCBoaWdoIGxpbmsgc3BlZWRzLCB0aGUgQklFUiB3b3JrPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aWxsIHByb2dyZXNzIGFzIEV4cGVyaW1lbnRh bC4mbmJzcDsgQXMgZGVzY3JpYmVkIGluIGl0ZW0gKDkpIGJlbG93LCB0aGU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndvcmsgbWF5IGJlY29tZSBT dGFuZGFyZHMgVHJhY2sgb25jZSB0aGVyZSBpcyBzdWZmaWNpZW50IGV4cGVyaWVuY2U8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpdGggdGhlIGJl bmVmaXRzIGFuZCBkb3duc2lkZXMgb2YgdGhlIHRlY2hub2xvZ3kuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJJRVIgaXMgaW5pdGlhbGx5IGNo YXJ0ZXJlZCB0byBkbyBleHBlcmltZW50YWwgd29yayBvbiB0aGlzIG5ldzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bXVsdGljYXN0IGZvcndhcmRp bmcgbWVjaGFuaXNtIGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsxKSBCSUVSIGFyY2hpdGVjdHVyZTog VGhlIFdHIHdpbGwgcHVibGlzaCBhbiBhcmNoaXRlY3R1cmUsIGJhc2VkPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dXBvbiBk cmFmdC13aWpuYW5kcy1iaWVyLWFyY2hpdGVjdHVyZS0wNC4mbmJzcDsgSXQgd2lsbCBpbmNsdWRl IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwO25vcm1hdGl2ZSBhbGdvcml0aG0gZm9yIGhvdyBCSUVSIHBhY2tldCBmb3J3 YXJkaW5nIGlzIGRvbmUuJm5ic3A7IEl0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7d2lsbCBzcGVjaWZ5IHRoZSBpbmZvcm1h dGlvbiB0aGF0IGlzIHJlcXVpcmVkIGJ5IGEgQklFUiBoZWFkZXIgdG88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtzdXBwb3J0 IEJJRVIgZm9yd2FyZGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzIpIEJJRVIgZW5jYXBzdWxhdGlvbjogVGhlIHdv cmtpbmcgZ3JvdXAgc2hvdWxkIGFzc3VtZSB0aGF0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3RlY2hub2xvZ3kgd2ls bCBuZWVkIHRvIGJlIGVtYmVkZGVkIGluIHRoZSBkYXRhIHBsYW5lIGFuZCBvcGVyYXRlPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7YXQgdGhlIGhpZ2hlc3QgcGFja2V0IGxpbmUgc3BlZWRzLiZuYnNwOyBUaGUgV0cgd2lsbCBw dWJsaXNoIGEgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtkZWZpbmluZyBhbiBNUExTLWJhc2VkIGVuY2Fwc3Vs YXRpb24gYmFzZWQgdXBvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2RyYWZ0LXdpam5hbmRzLW1wbHMtYmllci1lbmNhcHN1 bGF0aW9uLTAyLiBEdWUgdG8gdGhlIGNyaXRpY2FsIG5lZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt0byBoYXZlIGEgaGln aC1xdWFsaXR5IGFuZCBzdGFibGUgUkZDIGZvciBhIG5ldyBkYXRhLXBsYW5lPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ZW5j YXBzdWxhdGlvbiwgdGhlIE1QTFMtYmFzZWQgZW5jYXBzdWxhdGlvbiBkcmFmdCBzaGFsbCB3YWl0 IGFmdGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7V0dMQyBhbmQgbm90IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVu dGlsIHRoZXJlIGFyZSB0d288bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtpbmRlcGVuZGVudCBpbnRlcm9wZXJhYmxlIGltcGxl bWVudGF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwO0FzIGEgc2Vjb25kYXJ5IGZvY3VzLCB0aGUgV0cgbWF5IGFs c28gd29yayBvbiBvbmUgbm9uLU1QTFM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtkYXRhLXBsYW5lIGVuY2Fwc3VsYXRpb24u Jm5ic3A7IFRoaXMgZHJhZnQgYWxzbyBzaGFsbCB3YWl0IGFmdGVyIFdHTEM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDthbmQg bm90IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d28gaW5kZXBl bmRlbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDtpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4mbmJzcDsgVGhpcyBk cmFmdCBtdXN0IGZvY3VzIG9uIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2luY2x1ZGUgdGhlIGZvbGxvd2luZyBkZXRh aWxzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthKSBXaGF0IGlzIHRoZSBhcHBsaWNhYmlsaXR5 IG9mIHRoZSBlbmNhcHN1bGF0aW9uIGFuZCBmb3Igd2hpY2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3VzZS1jYXNlcyBpcyB0aGlzIGVuY2Fwc3VsYXRpb24gcmVxdWlyZWQ/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2IpIERvZXMgdGhpcyBwcm9wb3NlZCBlbmNhcHN1bGF0aW9uIGltcGx5IGFueSBj aGFuZ2VzIHRvIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TVBMUy1iYXNlZCBlbmNhcHN1bGF0 aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjKSBXaGF0IGRlc2lnbiBjaG9pY2VzIGhhdmUg YmVlbiBtYWRlIGZvciB0aGUgZW5jYXBzdWxhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlw ZSBhbmQgdGhlIGluY2x1ZGVkIGZpZWxkcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZCkgVGhl IHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24gd2l0aCBjb25zaWRlcmF0aW9ucyBnaXZlbiB0byBhdDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGVhc3QgT0FNLCBDbGFzcyBvZiBTZXJ2aWNlLCBzZWN1cml0 eSwgZnJhZ21lbnRhdGlvbiwgVFRMLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7MykgVHJhbnNpdGlvbiBNZWNoYW5pc21z OiBUaGUgV0cgd2lsbCBkZXNjcmliZSBob3cgQklFUiBjYW4gYmU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtwYXJ0aWFsbHkg ZGVwbG95ZWQgYW5kIHN0aWxsIHByb3ZpZGUgdXNlZnVsIGZ1bmN0aW9uYWxpdHkuICZuYnNwO0E8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDttaW5pbXVtIG9mIHRoZSBuZWNlc3NhcnkgbWVjaGFuaXNtcyB0byBzdXBwb3J0IGlu Y3JlbWVudGFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7ZGVwbG95bWVudCBhbmQvb3IgbWFuYWdpbmcgZGlmZmVyZW50IEJJ RVIgbWFzay1sZW5ndGggY29tcGF0aWJpbGl0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO21heSBiZSBkZWZpbmVkLiZuYnNw OyBFYWNoIHN1Y2ggbWVjaGFuaXNtIG11c3QgaW5jbHVkZSBhbiBhcHBsaWNhYmlsaXR5PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7c3RhdGVtZW50IHRvIGRpZmZlcmVudGlhdGUgaXRzIG5lY2Vzc2l0eSBmcm9tIG90aGVyIHBy b3Bvc2VkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7bWVjaGFuaXNtcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzQpIEFwcGxpY2FiaWxpdHkgU3Rh dGVtZW50czogVGhlIFdHIHdpbGwgd29yayBvbiBhIGRvY3VtZW50PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ZGVzY3JpYmlu ZyBob3cgQklFUiBjYW4gYmUgYXBwbGllZCB0byBtdWx0aWNhc3QgTDNWUE4gYW5kIHRvIEVWUE4u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7VGhpcyBkcmFmdCB3aWxsIGRlc2NyaWJlIHdoYXQgbWVjaGFuaXNtIGlzIHVzZWQg dG8gY29tbXVuaWNhdGUgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Z3JvdXAgbWVtYmVyc2hpcCBiZXR3ZWVuIHRoZSBp bmdyZXNzIHJvdXRlciBhbmQgdGhlIGVncmVzcyByb3V0ZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3doYXQgc2NhbGFi aWxpdHkgY29uc2lkZXJhdGlvbnMgbWF5IGFyaXNlLCBhbmQgYW55IGRlcGxveW1lbnQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDtjb25zaWRlcmF0aW9ucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzUpIFVzZSBDYXNlOiBUaGUgV0cgbWF5 IHByb2R1Y2Ugb25lIHVzZS1jYXNlIGRvY3VtZW50IHRoYXQgY2xlYXJseTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2FydGlj dWxhdGVzIHRoZSBwb3RlbnRpYWwgYmVuZWZpdHMgb2YgQklFUiBmb3IgZGlmZmVyZW50IHVzZS1j YXNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDtUaGlzIHdvdWxkIGJlIGJhc2VkIHVwb24gZHJhZnQta3VtYXItYmllci11 c2UtY2FzZXMtMDEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDs2KSBPQU06IFRoZSBXRyB3aWxsIGRlc2NyaWJlIGhvdyBP QU0gd2lsbCB3b3JrIGluIGEgQklFUiBkb21haW4gYW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7d2hhdCBzaW1wbGlmaWNh dGlvbnMgQklFUiBvZmZlcnMgZm9yIG1hbmFnaW5nIHRoZSBtdWx0aWNhc3Q8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt0cmFm ZmljLiZuYnNwOyBBIHN0cm9uZyBwcmVmZXJlbmNlIHdpbGwgYmUgZ2l2ZW4gdG8gZXh0ZW5zaW9u cyB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwO2V4aXN0aW5nIHByb3RvY29scy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzcpIE1hbmFnZW1lbnQg bW9kZWxzOiBUaGUgV0cgbWF5IHdvcmsgb24gWUFORyBtb2RlbHMgYW5kLCBpZiBuZWVkZWQsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7TUlCIG1vZHVsZXMgdG8gc3VwcG9ydCBjb21tb24gbWFuYWdlYWJpbGl0eS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwOzgpIElHUCBleHRlbnNpb25zLiZuYnNwOyBXaGVuIGEgQklFUiBkb21haW4gZmFsbHMgd2l0 aGluIGEgJnF1b3Q7bGluayBzdGF0ZSBJR1AmcXVvdDsmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtuZXR3b3JrLCB0 aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvIHNldCB1cCB0aGUgQklFUiBmb3J3YXJkaW5nIHRhYmxl czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwOyhlLmcuLCB0aGUgbWFwcGluZyBiZXR3ZWVuIGEgZ2l2ZW4gYml0IHBvc2l0aW9u IGFuZCBhIGdpdmVuIGVncmVzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3JvdXRlcikgbWF5IGJlIGNhcnJpZWQgaW4gdGhl IGxpbmsgc3RhdGUgYWR2ZXJ0aXNlbWVudHMgb2YgdGhlIElHUC4mbmJzcDsgVGhlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 bGluayBzdGF0ZSBhZHZlcnRpc21lbnRzIG1heSBhbHNvIGNhcnJ5IG90aGVyIGluZm9ybWF0aW9u IHJlbGF0ZWQgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDtmb3J3YXJkaW5nIChlLmcuLCB0aGUgSUdQIG1heSBzdXBwb3J0 IG11bHRpcGxlIHRvcG9sb2dpZXMsIGluIHdoaWNoIGNhc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtpdCBtYXkgYmUgbmVj ZXNzYXJ5IHRvIGFkdmVydGlzZSB3aGljaCB0b3BvbG9naWVzIGFyZSB0byBiZSB1c2VkIGZvciBC SUVSPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7Zm9yd2FyZGluZykuJm5ic3A7IEFueSBuZWNlc3NhcnkgZXh0ZW5zaW9ucyB0 byB0aGUgSUdQIHdpbGwgYmUgc3BlY2lmaWVkIGJ5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dGhlIFdHLCBpbiBjb29wZXJh dGlvbiB3aXRoIHRoZSBJU0lTIGFuZCBPU1BGIFdHcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzkpIERlcGxveW1lbnQg RXhwZXJpZW5jZTogT25jZSB0aGVyZSBpcyBkZXBsb3ltZW50IGV4cGVyaWVuY2UsIHRoZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwO1dHIHdpbGwgcHJvZHVjZSBhIGRvY3VtZW50IGRlc2NyaWJpbmcgdGhlIGJlbmVmaXRzLCBw cm9ibGVtcywgYW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7dHJhZGUtb2ZmcyBmb3IgdXNpbmcgQklFUiBpbnN0ZWFkIG9m IHRyYWRpdGlvbmFsIG11bHRpY2FzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2ZvcndhcmRpbmcgbWVjaGFuaXNtcy4mbmJz cDsgSWRlYWxseSwgdGhpcyBzaG91bGQgYWxzbyBjb250YWluIGFuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7YW5hbHlzaXMg b2YgdGhlIGltcGFjdCBhbmQgYmVuZWZpdCBvZiB0aGUgbmV3IEJJRVIgZGF0YS1wbGFuZSB0bzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwO3RoZSBvdmVyYWxsIEludGVybmV0IGFyY2hpdGVjdHVyZS4mbmJzcDsgVGhpcyBkb2N1 bWVudCBpcyBpbnRlbmRlZCB0byBiZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3VzZWQgdG8gZXZhbHVhdGUgd2hldGhlciB0 byByZWNoYXJ0ZXIgQklFUiB0byBwcm9kdWNlIFN0YW5kYXJkczxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1RyYWNrIFJGQ3Mu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBCSUVSIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb29yZGluYXRlIHdpdGggc2V2ZXJhbCBkaWZmZXJl bnQgd29ya2luZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Z3JvdXBzIGFuZCBtdXN0IGluY2x1ZGUgdGhlIHJlbGV2YW50IG90aGVyIHdvcmtpbmcg Z3JvdXBzIGR1cmluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+d29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gdGhlIHJlbGV2YW50IGRyYWZ0cy4m bmJzcDsgQklFUiB3aWxsIGNvb3JkaW5hdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpdGggTVBMUyBvbiB0aGUgTVBMUy1iYXNlZCBlbmNhcHN1 bGF0aW9uIGFuZCBhc3NvY2lhdGVkIE1QTFMtYmFzZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9BTSBtZWNoYW5pc21zLiZuYnNwOyBCSUVSIHdp bGwgY29vcmRpbmF0ZSB3aXRoIElTSVMgYW5kIE9TUEYgb24gZXh0ZW5zaW9uczxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gZmxvb2QgQklFUi1y ZWxhdGVkIGluZm9ybWF0aW9uLiZuYnNwOyBCSUVSIHdpbGwgY29vcmRpbmF0ZSB3aXRoIEJFU1Mg YW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J RFIgb24gdGhlIGFwcGxpY2FiaWxpdHkgb2YgZXhpc3RpbmcgQkdQLWJhc2VkIG1lY2hhbmlzbXMg Zm9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5w cm92aWRpbmcgbXVsdGljYXN0IGdyb3VwIG1lbWJlcnNoaXAgaW5mb3JtYXRpb24uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QWxpYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJJRVIgbWFpbGluZyBsaXN0 PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5CSUVSQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmllciIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmllcjwvYT48 c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286 cD48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxicj4NCjxzcGFuIGNs YXNzPSJob2VuemIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24g Z28gdG86PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjoj ODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOiM4ODg4ODgiPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9k b2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXgu aHRtbDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A496052E7B7E84A9324854763C616FA233CF4DAC111GTUHMBX56ER_-- From nobody Thu Feb 12 16:30:03 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DA41A1B9E; Thu, 12 Feb 2015 16:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2GvDFu6olpR; Thu, 12 Feb 2015 16:29:52 -0800 (PST) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8411A024C; Thu, 12 Feb 2015 16:29:24 -0800 (PST) Received: by mail-yh0-f51.google.com with SMTP id b6so6526200yha.10; Thu, 12 Feb 2015 16:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iWfYUmZtU/X/lqoVQl6z4T2FCM94obsOkLvAystHM9E=; b=J39TNrvE0cUX6eoC7jsR2Pinj6tRcPV+m4RIslKBKu8ndA95d1en24YeGs49/x9mkr aDr0qwEfA3UWj9cL7+hJqqFV4K3wtT7TLaP60LiWkBYPOzUaS82cQARsE2hNs8q49vKE 1MeB5dWezfgRf2jw53NpTmRt1/jHUnJ+Rp/zaBJ5behaiRlRrN0DQPTMVdHhwAEwjTjw d2iksPJcVN3vZuOKxflVveSj5a0UY8Jo3tposfpEsM2uSO7ozLMDtn8Yt7awfeOU6wMy a7hFHWjfdSfAzUveaj3OUugNRC2tRg5aTxCEkUTq6LlnU/xmAU9+OJwiZ8k2QLtdhYgq /R4g== MIME-Version: 1.0 X-Received: by 10.236.97.66 with SMTP id s42mr6623885yhf.38.1423787363889; Thu, 12 Feb 2015 16:29:23 -0800 (PST) Received: by 10.170.133.197 with HTTP; Thu, 12 Feb 2015 16:29:23 -0800 (PST) In-Reply-To: <4A496052E7B7E84A9324854763C616FA233CF4DA@C111GTUHMBX56.ERF.thomson.com> References: <54DCAE4F.8050903@cisco.com> <4A496052E7B7E84A9324854763C616FA233CF4DA@C111GTUHMBX56.ERF.thomson.com> Date: Thu, 12 Feb 2015 19:29:23 -0500 Message-ID: From: Alia Atlas To: Arkadiy Gulko Content-Type: multipart/alternative; boundary=001a11c1d1140f789b050eed54a9 Archived-At: Cc: Alvaro Retana , Adrian Farrel , "bier@ietf.org" , "iesg@ietf.org" , stbryant Subject: Re: [Bier] proposed BIER charter 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, 13 Feb 2015 00:29:59 -0000 --001a11c1d1140f789b050eed54a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Arkadiy, First, we were all new to the IETF once. Your feedback and opinions are quite welcome. WG charters are discussed to get feedback and agreement on the details and scope. I'm delighted to hear of your interest and that of other operators. I did, of course, speak with you before the BoF and know of your involvement in the drafts. Unfortunately, I haven't heard such support expressed in the IETF by operators; obviously vendors' interest can reflect such interest indirectly. I believe that BIER is currently at the stage of a development effort. I have done my best to be clear that there is a path forward from Experimental - but it really really depends on getting some experience with the technology and being more confident of the actual demand. I am trying to provide a WG to get rapid progress on BIER. The other option is to wait and do a second BoF possibly in March or in July and see if there is stronger demand for having the technology and really clear benefits articulated that would drive it. Unfortunately, while the problem-statement and use-cases have improved since the Nov BoF, they are still not sufficiently convincing. This is very ambitious innovative work - which is great - but I have seen many technologies be the excitement of the year and then flounder. If it does catch on, then there is certainly an ability to recharter to the standards track. As you probably noticed, in the proposed charter, there is a item 9, in which your help could be particlarly significant. Regards, Alia On Thu, Feb 12, 2015 at 6:20 PM, wrote: > Alia, > > I have been engaged with BIER technology for the last year and a half fro= m > its inception. It come along way and it was not driven just based on > excitement. This work is backed up by commitment from major vendors and > multiple operators. I have discussed BIER on multiple occasions with othe= r > operators, they showed a great interest and strong support with overall > consensus that BIER will build a right foundation for efficient multicast > delivery for operators to standardize. I promoted BIER within Thomson > Reuters on the Business and Technology sides and feedback was overwhelmin= g, > with huge interest from Thomson Reuters development community. Based on m= y > involvement with BIER, I struggle to define it as Experimental as per > included definition below and I completely agree with Stewart on his > assessment of your proposed charter. Please don't take it as a criticism,= I > am very novice in terms of IETF protocols and procedures but as per my > findings of IETF definitions: > > "WG charters state the scope of work for group, and lay out goals and > milestones that show how this work will be completed." > > The proposed version in the way it was written more focusing on > conditional statements and depicts some unwillingness of IETF to > promote/proceed with BIER as a committed work. > > > > Snapshot from IETF.org > > =E2=80=9C4.2.1 Experimental > > The "Experimental" designation typically denotes a specification that is > part of some research or development effort. Such a specification is > published for the general information of the Internet technical community > and as an archival record of the work, subject only to editorial > considerations and to verification that there has been adequate > coordination with the standards process (see below). An Experimental > specification may be the output of an organized Internet research effort > (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be > an individual contribution.=E2=80=9D > > > > I would like to continue to promote BIER and take an active part in > developing of new multicast technologies for my company and industry > benefits. There are plenty of challenges in this arena, but only via acti= ve > participation these challenges can be resolved. We need to see commitment > from IETF to move BIER development forward. > > > > Regards, > > Arkadiy > > > > > > *From:* BIER [mailto:bier-bounces@ietf.org] *On Behalf Of *Alia Atlas > *Sent:* Thursday, February 12, 2015 10:14 AM > *To:* stbryant > *Cc:* Adrian Farrel; bier@ietf.org; iesg@ietf.org; Alvaro Retana > *Subject:* Re: [Bier] proposed BIER charter > > > > Stewart, > > > > I certainly appreciate your taking the time to provide feedback. I > understand that you > > are excited by this technology and have urged that innovation needs time > and space > > to be worked on before being evaluated by the harsh realities of the > marketplace and > > interest in deployments. > > > > On Thu, Feb 12, 2015 at 8:44 AM, Stewart Bryant > wrote: > > Alia > > I think that you are crossing far too many bridges before you get to them > in terms of you expectation of where BIER will be deployed and how > it will be implemented. > > > > I did read the use-cases and understand the primary motivation is for MVP= N > > and EVPN which are deployed in the backbone of SP networks that operate a= t > > high speeds. Even in data-centers, use of 10G links is common. > > > > The charter should not include such specific assumptions, particularly > given the fast moving changes that are happening in our industry > especially in the area of packet forwarding design. > > > > What specifically are you objecting to? > > > > I have not seen such assumptions in other charters and I don't think > that they have a place in this one. > > > > What specific assumption are you objecting to and what reasoning do you > have > > beyond historical? > > > > In terms of choice of document stream (experimental vs PS), > that is a decision that can be taken at the time of publication > when more information will be available in terms of potential > market take-up, expected/actual deployment scenarios, > breadth of implementation and implementation experience. > > > > At this time, a sufficiently compelling case has not been made to convinc= e > that > > PS is anywhere near appropriate for this change of adding a completely ne= w > forwarding > > algorithm and a fourth encapsulation to go with IPv4, IPv6, and MPLS to > the Internet > > architecture for the next 15+ years. > > > > It is true that if that changes between now and when drafts are ready to > progress, that can > > be revisited. > > > > There are WGs that have been chartered to do experimental work in the > past. I understand > > that it is disappointing that there wasn't a strong case for more than > experimental at this time. > > > > I have been extremely clear since the last IETF that I was only > considering Experimental for > > the WG for the initial chartering. > > > > Whilst this technology may be deployed in the Internet core, > it my also be deployed at the edge where a much lower threshold > is applicable. > > > > The technology needs to work in both locations - given the use-cases. > What specifically are > > you objecting to? > > > > I fear that by introducing these caveats the IETF is entrenching the > perception that it slows technology down rather than embracing > and encouraging innovation. > > > > By creating a WG for open collaboration and defining an ambitious new > forwarding technology, > > the IETF is not embracing and encouraging innovation? I suppose it's all > in the eye of the > > beholder - but to me it feels like "give an inch and get pushed for a > mile". > > > > I would therefore suggest removing the text on implementation > styles and document stream constraints. > > > > IF the encapsulations are specified in a way that two independent > interoperable implementations > > are not available, it both increases the risk that we might end up with > two different versions - one > > Experimental and another through bitter experience that is PS later - and > is a poor indication of > > the lack of industry support and interest in the technology and its use. > > > > Regards, > > Alia > > > > > - Stewart > > > > On 11/02/2015 20:44, Alia Atlas wrote: > > I have been working on getting a charter together for BIER with the > intent of pushing for it to be chartered before the Dallas IETF. This ha= s > not yet gone through IESG review and it may have some aspects updated. > > > > Please send comments here. > > > > The charter can be found at > http://datatracker.ietf.org/doc/charter-ietf-bier/ > > and is included below as well. > > > > > > WG Chairs: > > Greg Shepherd > > Tony Przygienda > > > > > > In conventional IP multicast forwarding, the packets of a given > > multicast "flow" are forwarded along a tree that has been constructed > > for the specific purpose of carrying that flow. This requires transit > > nodes to maintain state on a per-flow basis, and requires the transit > > nodes to participate in multicast-specific tree building protocols. > > The flow to which a packet belongs is determined by its IP source and > > destination address fields. > > > > BIER (Bit Index Explicit Replication) is an alternative method of > > multicast forwarding. It does not require any multicast-specific > > trees, and hence does not require any multicast-specific tree building > > protocols. Within a given "BIER domain", an ingress node encapsulates > > a multicast data packet in a "BIER header". The BIER header > > identifies the packet's egress nodes in that domain. Each possible > > egress node is represented by a a single bit within a bitstring; to > > send a packet to a particular set of egress nodes, the ingress node > > sets the bits for each of those egress nodes, and clears the other > > bits in the bistring. Each packet can then be forwarded along the > > unicast shortest path tree from the ingress node to the egress nodes. > > Thus there are no per-flow forwarding entries. > > > > Due to the particular sensitivity of adding new significant > > functionality into the data-plane at high link speeds, the BIER work > > will progress as Experimental. As described in item (9) below, the > > work may become Standards Track once there is sufficient experience > > with the benefits and downsides of the technology. > > > > BIER is initially chartered to do experimental work on this new > > multicast forwarding mechanism as follows: > > > > 1) BIER architecture: The WG will publish an architecture, based > > upon draft-wijnands-bier-architecture-04. It will include the > > normative algorithm for how BIER packet forwarding is done. It > > will specify the information that is required by a BIER header to > > support BIER forwarding. > > > > 2) BIER encapsulation: The working group should assume that the > > technology will need to be embedded in the data plane and operate > > at the highest packet line speeds. The WG will publish a document > > defining an MPLS-based encapsulation based upon > > draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need > > to have a high-quality and stable RFC for a new data-plane > > encapsulation, the MPLS-based encapsulation draft shall wait after > > WGLC and not progress to IETF Last Call until there are two > > independent interoperable implementations. > > > > As a secondary focus, the WG may also work on one non-MPLS > > data-plane encapsulation. This draft also shall wait after WGLC > > and not progress to IETF Last Call until there are two independent > > interoperable implementations. This draft must focus on and > > include the following details: > > > > a) What is the applicability of the encapsulation and for which > > use-cases is this encapsulation required? > > > > b) Does this proposed encapsulation imply any changes to the > > MPLS-based encapsulation? > > > > c) What design choices have been made for the encapsulation > > type and the included fields. > > > > d) The proposed encapsulation with considerations given to at > > least OAM, Class of Service, security, fragmentation, TTL. > > > > 3) Transition Mechanisms: The WG will describe how BIER can be > > partially deployed and still provide useful functionality. A > > minimum of the necessary mechanisms to support incremental > > deployment and/or managing different BIER mask-length compatibility > > may be defined. Each such mechanism must include an applicability > > statement to differentiate its necessity from other proposed > > mechanisms. > > > > 4) Applicability Statements: The WG will work on a document > > describing how BIER can be applied to multicast L3VPN and to EVPN. > > This draft will describe what mechanism is used to communicate the > > group membership between the ingress router and the egress routers, > > what scalability considerations may arise, and any deployment > > considerations. > > > > 5) Use Case: The WG may produce one use-case document that clearly > > articulates the potential benefits of BIER for different use-cases. > > This would be based upon draft-kumar-bier-use-cases-01. > > > > 6) OAM: The WG will describe how OAM will work in a BIER domain and > > what simplifications BIER offers for managing the multicast > > traffic. A strong preference will be given to extensions to > > existing protocols. > > > > 7) Management models: The WG may work on YANG models and, if needed, > > MIB modules to support common manageability. > > > > 8) IGP extensions. When a BIER domain falls within a "link state IGP"= " > > network, the information needed to set up the BIER forwarding tables > > (e.g., the mapping between a given bit position and a given egress > > router) may be carried in the link state advertisements of the IGP. T= he > > link state advertisments may also carry other information related to > > forwarding (e.g., the IGP may support multiple topologies, in which ca= se > > it may be necessary to advertise which topologies are to be used for > BIER > > forwarding). Any necessary extensions to the IGP will be specified by > > the WG, in cooperation with the ISIS and OSPF WGs. > > > > 9) Deployment Experience: Once there is deployment experience, the > > WG will produce a document describing the benefits, problems, and > > trade-offs for using BIER instead of traditional multicast > > forwarding mechanisms. Ideally, this should also contain an > > analysis of the impact and benefit of the new BIER data-plane to > > the overall Internet architecture. This document is intended to be > > used to evaluate whether to recharter BIER to produce Standards > > Track RFCs. > > > > The BIER working group will coordinate with several different working > > groups and must include the relevant other working groups during > > working group last call on the relevant drafts. BIER will coordinate > > with MPLS on the MPLS-based encapsulation and associated MPLS-based > > OAM mechanisms. BIER will coordinate with ISIS and OSPF on extensions > > to flood BIER-related information. BIER will coordinate with BESS and > > IDR on the applicability of existing BGP-based mechanisms for > > providing multicast group membership information. > > > > Regards, > > Alia > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > > > -- > > For corporate legal information go to: > > > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > --001a11c1d1140f789b050eed54a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Arkadiy,

First, we were all new to t= he IETF once.=C2=A0 Your feedback and opinions are quite welcome.=C2=A0 WG = charters are discussed to get feedback and agreement on the details and sco= pe.

I'm delighted to hear of your interest and= that of other operators.=C2=A0 I did, of course, speak with you before the= BoF and know of your involvement in the drafts.=C2=A0 Unfortunately, I hav= en't heard such support expressed in the IETF by operators; obviously v= endors' interest
can reflect such interest indirectly.
<= div>
I believe that BIER is currently at the stage of a devel= opment effort.=C2=A0 I have done my best to be clear that there is a path f= orward from Experimental - but it really really depends on getting some exp= erience with the technology and being more confident of the actual demand.<= /div>

I am trying to provide a WG to get rapid progress = on BIER.=C2=A0 The other option is to wait and do a second BoF possibly in = March or in July and see if there is stronger demand for having the technol= ogy and really clear benefits articulated that would drive it.=C2=A0 Unfort= unately, while the problem-statement and use-cases have improved since the = Nov BoF, they are still not sufficiently convincing.

This is very ambitious innov= ative work - which is great - but I have seen many technologies be the exci= tement of the year and then flounder.
If it= does catch on, then there is certainly an ability to recharter to the stan= dards track.=C2=A0 As you probably noticed, in the proposed charter, there = is a item 9, in which your help could be particlarly significant.

Regards,
<= div class=3D"gmail_extra">Alia


On Thu, Feb 12, 201= 5 at 6:20 PM, <arkadiy.gulko@thomsonreuters.com> wrote:

Alia,

I have been engaged with BIER technology for the last year and a half fr= om its inception. It come along way and it was not driven just based on exc= itement. This work is backed up by commitment from major vendors and multip= le operators. I have discussed BIER on multiple occasions with other operators, they sho= wed a great interest and strong support with overall consensus that BIER wi= ll build a right foundation for efficient multicast delivery for operators = to standardize. I promoted BIER within Thomson Reuters on the Business and Technology sides and feedback w= as overwhelming, with huge interest from Thomson Reuters development commun= ity. Based on my involvement with BIER, I struggle to define it as Experime= ntal as per included definition below and I completely agree with Stewart on his assessment of your propos= ed charter. Please don't take it as a criticism, I am very novice in te= rms of IETF protocols and procedures but as per my findings of IETF definit= ions:

"WG charters state the scope of work for group, and lay out goals a= nd milestones that show how this work will be completed."

The proposed version in the way it was written more focusing on conditio= nal statements and depicts some unwillingness of IETF to promote/proceed wi= th BIER as a committed work.=C2=A0=C2=A0=C2=A0

=C2=A0

Snapshot from IETF.org

=E2=80=9C4.2.1 Experimental

The "Experimental" designation typically denotes a specificati= on that is part of some research or development effort. Such a specificatio= n is published for the general information of the Internet technical commun= ity and as an archival record of the work, subject only to editorial considerations and to verifi= cation that there has been adequate coordination with the standards process= (see below). An Experimental specification may be the output of an organiz= ed Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an indi= vidual contribution.=E2=80=9D

=C2=A0

I would like to continue to promote BIER and take an active part in deve= loping of new multicast technologies for my company and industry benefits. = There are plenty of challenges in this arena, but only via active participa= tion these challenges can be resolved. We need to see commitment from IETF to move BI= ER development forward.

=C2=A0

Regards,

Arkadiy

=C2=A0

=C2=A0

From: BIER [ma= ilto:bier-bounce= s@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, February 12, 2015 10:14 AM
To: stbryant
Cc: Adrian Farrel; bier@ietf.org; ies= g@ietf.org; Alvaro Retana
Subject: Re: [Bier] proposed BIER charter

=C2=A0

Stewart,

=C2=A0

I certainly appreciate your taking the time to provi= de feedback.=C2=A0 I understand that you

are excited by this technology and have urged that i= nnovation needs time and space

to be worked on before being evaluated by the harsh = realities of the marketplace and=C2=A0

interest in deployments.

=C2=A0

On Thu, Feb 12, 2015 at 8:44 AM, Stewart Bryant <= stbryant@cisco.com<= /a>> wrote:

Alia

I think that you are crossing far too many bridges before you get to them in terms of you expectation of where BIER will be deployed and how
it will be implemented.

=C2=A0

I did read the use-cases and understand the primary = motivation is for MVPN=C2=A0

and EVPN which are deployed in the backbone of SP ne= tworks that operate at

high speeds.=C2=A0 Even in data-centers, use of 10G = links is common.

=C2=A0

The charter should not include such specific assumpt= ions, particularly
given the fast moving changes that are happening in our industry
especially in the area of packet forwarding design.

=C2=A0

What specifically are you objecting to?=C2=A0=

=C2=A0

I have not seen such assumptions in other charters a= nd I don't think
that they have a place in this one.

=C2=A0

What specific assumption are you objecting to and wh= at reasoning do you have

beyond historical?

=C2=A0

In terms of choice of document stream (experimental = vs PS),
that is a decision that can be taken at the time of publication
when more information will be available in terms of potential
market take-up, expected/actual deployment scenarios,
breadth of implementation and implementation experience.

=C2=A0

At this time, a sufficiently compelling case has not= been made to convince that

PS is anywhere near appropriate for this change of a= dding a completely new forwarding=C2=A0

algorithm and a fourth =C2=A0encapsulation to go wit= h IPv4, IPv6, and MPLS to the Internet=C2=A0

architecture for the next 15+ years.=C2=A0=

=C2=A0

It is true that if that changes between now and when= drafts are ready to progress, that can

be revisited.

=C2=A0

There are WGs that have been chartered to do experim= ental work in the past.=C2=A0 I understand

that it is disappointing that there wasn't a str= ong case for more than experimental at this time.

=C2=A0

I have been extremely clear since the last IETF that= I was only considering Experimental for=C2=A0

the WG for the initial chartering.

=C2=A0

Whilst this technology may be deployed in the Intern= et core,
it my also be deployed at the edge where a much lower threshold
is applicable.

=C2=A0

The technology needs to work in both locations - giv= en the use-cases.=C2=A0 What specifically are

you objecting to?

=C2=A0

I fear that by introducing these caveats the IETF is= entrenching the
perception that it slows technology down rather than embracing
and encouraging innovation.

=C2=A0

By creating a WG for open collaboration and defining= an ambitious new forwarding technology,

the IETF is not embracing and encouraging innovation= ?=C2=A0 I suppose it's all in the eye of the

beholder - but to me it feels like "give an inc= h and get pushed for a mile".=C2=A0

=C2=A0

I would therefore suggest removing the text on imple= mentation
styles and document stream constraints.

=C2=A0

IF the encapsulations are specified in a way that tw= o independent interoperable implementations

are not available, it both increases the risk that w= e might end up with two different versions - one

Experimental and another through bitter experience t= hat is PS later - and is a poor indication of

the lack of industry support and interest in the tec= hnology and its use.

=C2=A0

Regards,

Alia

=C2=A0


- Stewart



On 11/02/2015 20:44, Alia Atlas wrote:

I have been working on getting a charter together fo= r BIER with the intent of pushing for it to be chartered before the Dallas = IETF.=C2=A0 This has not yet gone through IESG review and it may have some = aspects updated.

=C2=A0

Please send comments here.

=C2=A0

and is included below as well.

=C2=A0

=C2=A0

WG Chairs:

=C2=A0 Tony Przygienda <tonysietf@gmail.com>

=C2=A0

=C2=A0

In conventional IP multicast forwarding, the packets= of a given

multicast "flow" are forwarded along a tre= e that has been constructed

for the specific purpose of carrying that flow.=C2= =A0 This requires transit

nodes to maintain state on a per-flow basis, and req= uires the transit

nodes to participate in multicast-specific tree buil= ding protocols.

The flow to which a packet belongs is determined by = its IP source and

destination address fields.

=C2=A0

BIER (Bit Index Explicit Replication) is an alternat= ive method of

multicast forwarding.=C2=A0 It does not require any = multicast-specific

trees, and hence does not require any multicast-spec= ific tree building

protocols.=C2=A0 Within a given "BIER domain&qu= ot;, an ingress node encapsulates

a multicast data packet in a "BIER header"= .=C2=A0 The BIER header

identifies the packet's egress nodes in that dom= ain.=C2=A0 Each possible

egress node is represented by a a single bit within = a bitstring; to

send a packet to a particular set of egress nodes, t= he ingress node

sets the bits for each of those egress nodes, and cl= ears the other

bits in the bistring.=C2=A0 Each packet can then be = forwarded along the

unicast shortest path tree from the ingress node to = the egress nodes.

Thus there are no per-flow forwarding entries.

=C2=A0

Due to the particular sensitivity of adding new sign= ificant

functionality into the data-plane at high link speed= s, the BIER work

will progress as Experimental.=C2=A0 As described in= item (9) below, the

work may become Standards Track once there is suffic= ient experience

with the benefits and downsides of the technology.

=C2=A0

BIER is initially chartered to do experimental work = on this new

multicast forwarding mechanism as follows:=

=C2=A0

=C2=A0 =C2=A01) BIER architecture: The WG will publi= sh an architecture, based

=C2=A0 =C2=A0upon draft-wijnands-bier-architecture-0= 4.=C2=A0 It will include the

=C2=A0 =C2=A0normative algorithm for how BIER packet= forwarding is done.=C2=A0 It

=C2=A0 =C2=A0will specify the information that is re= quired by a BIER header to

=C2=A0 =C2=A0support BIER forwarding.<= /p>

=C2=A0

=C2=A0 =C2=A02) BIER encapsulation: The working grou= p should assume that the

=C2=A0 =C2=A0technology will need to be embedded in = the data plane and operate

=C2=A0 =C2=A0at the highest packet line speeds.=C2= =A0 The WG will publish a document

=C2=A0 =C2=A0defining an MPLS-based encapsulation ba= sed upon

=C2=A0 =C2=A0draft-wijnands-mpls-bier-encapsulation-= 02. Due to the critical need

=C2=A0 =C2=A0to have a high-quality and stable RFC f= or a new data-plane

=C2=A0 =C2=A0encapsulation, the MPLS-based encapsula= tion draft shall wait after

=C2=A0 =C2=A0WGLC and not progress to IETF Last Call= until there are two

=C2=A0 =C2=A0independent interoperable implementatio= ns.

=C2=A0

=C2=A0 =C2=A0As a secondary focus, the WG may also w= ork on one non-MPLS

=C2=A0 =C2=A0data-plane encapsulation.=C2=A0 This dr= aft also shall wait after WGLC

=C2=A0 =C2=A0and not progress to IETF Last Call unti= l there are two independent

=C2=A0 =C2=A0interoperable implementations.=C2=A0 Th= is draft must focus on and

=C2=A0 =C2=A0include the following details:

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0a) What is the applicabil= ity of the encapsulation and for which

=C2=A0 =C2=A0 =C2=A0 =C2=A0use-cases is this encapsu= lation required?

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0b) Does this proposed enc= apsulation imply any changes to the

=C2=A0 =C2=A0 =C2=A0 =C2=A0MPLS-based encapsulation?=

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0c) What design choices ha= ve been made for the encapsulation

=C2=A0 =C2=A0 =C2=A0 =C2=A0type and the included fie= lds.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0d) The proposed encapsula= tion with considerations given to at

=C2=A0 =C2=A0 =C2=A0 =C2=A0least OAM, Class of Servi= ce, security, fragmentation, TTL.

=C2=A0

=C2=A0 =C2=A03) Transition Mechanisms: The WG will d= escribe how BIER can be

=C2=A0 =C2=A0partially deployed and still provide us= eful functionality. =C2=A0A

=C2=A0 =C2=A0minimum of the necessary mechanisms to = support incremental

=C2=A0 =C2=A0deployment and/or managing different BI= ER mask-length compatibility

=C2=A0 =C2=A0may be defined.=C2=A0 Each such mechani= sm must include an applicability

=C2=A0 =C2=A0statement to differentiate its necessit= y from other proposed

=C2=A0 =C2=A0mechanisms.

=C2=A0

=C2=A0 =C2=A04) Applicability Statements: The WG wil= l work on a document

=C2=A0 =C2=A0describing how BIER can be applied to m= ulticast L3VPN and to EVPN.

=C2=A0 =C2=A0This draft will describe what mechanism= is used to communicate the

=C2=A0 =C2=A0group membership between the ingress ro= uter and the egress routers,

=C2=A0 =C2=A0what scalability considerations may ari= se, and any deployment

=C2=A0 =C2=A0considerations.=C2=A0

=C2=A0

=C2=A0 =C2=A05) Use Case: The WG may produce one use= -case document that clearly

=C2=A0 =C2=A0articulates the potential benefits of B= IER for different use-cases.

=C2=A0 =C2=A0This would be based upon draft-kumar-bi= er-use-cases-01.

=C2=A0

=C2=A0 =C2=A06) OAM: The WG will describe how OAM wi= ll work in a BIER domain and

=C2=A0 =C2=A0what simplifications BIER offers for ma= naging the multicast

=C2=A0 =C2=A0traffic.=C2=A0 A strong preference will= be given to extensions to

=C2=A0 =C2=A0existing protocols.

=C2=A0

=C2=A0 =C2=A07) Management models: The WG may work o= n YANG models and, if needed,

=C2=A0 =C2=A0MIB modules to support common manageabi= lity.

=C2=A0

=C2=A0 =C2=A08) IGP extensions.=C2=A0 When a BIER do= main falls within a "link state IGP""

=C2=A0 =C2=A0network, the information needed to set = up the BIER forwarding tables

=C2=A0 =C2=A0(e.g., the mapping between a given bit = position and a given egress

=C2=A0 =C2=A0router) may be carried in the link stat= e advertisements of the IGP.=C2=A0 The

=C2=A0 =C2=A0link state advertisments may also carry= other information related to

=C2=A0 =C2=A0forwarding (e.g., the IGP may support m= ultiple topologies, in which case

=C2=A0 =C2=A0it may be necessary to advertise which = topologies are to be used for BIER

=C2=A0 =C2=A0forwarding).=C2=A0 Any necessary extens= ions to the IGP will be specified by

=C2=A0 =C2=A0the WG, in cooperation with the ISIS an= d OSPF WGs.

=C2=A0

=C2=A0 =C2=A09) Deployment Experience: Once there is= deployment experience, the

=C2=A0 =C2=A0WG will produce a document describing t= he benefits, problems, and

=C2=A0 =C2=A0trade-offs for using BIER instead of tr= aditional multicast

=C2=A0 =C2=A0forwarding mechanisms.=C2=A0 Ideally, t= his should also contain an

=C2=A0 =C2=A0analysis of the impact and benefit of t= he new BIER data-plane to

=C2=A0 =C2=A0the overall Internet architecture.=C2= =A0 This document is intended to be

=C2=A0 =C2=A0used to evaluate whether to recharter B= IER to produce Standards

=C2=A0 =C2=A0Track RFCs.

=C2=A0

The BIER working group will coordinate with several = different working

groups and must include the relevant other working g= roups during

working group last call on the relevant drafts.=C2= =A0 BIER will coordinate

with MPLS on the MPLS-based encapsulation and associ= ated MPLS-based

OAM mechanisms.=C2=A0 BIER will coordinate with ISIS= and OSPF on extensions

to flood BIER-related information.=C2=A0 BIER will c= oordinate with BESS and

IDR on the applicability of existing BGP-based mecha= nisms for

providing multicast group membership information.=

=C2=A0

Regards,

Alia

=C2=A0<= /p> 

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




-- 
For corporate legal information go to:
=C2=A0
http://www.cisco.c=
om/web/about/doing_business/legal/cri/index.html

=C2=A0

=C2=A0


--001a11c1d1140f789b050eed54a9-- From nobody Thu Feb 12 18:46:20 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814371A1A97 for ; Thu, 12 Feb 2015 18:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaLmPFL5Qs8w for ; Thu, 12 Feb 2015 18:46:15 -0800 (PST) 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 1650D1A0AF8 for ; Thu, 12 Feb 2015 18:46:13 -0800 (PST) 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 BSO76373; Fri, 13 Feb 2015 02:46:12 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Feb 2015 02:46:11 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 13 Feb 2015 10:46:00 +0800 From: Xuxiaohu To: Alia Atlas Thread-Topic: [Bier] proposed BIER charter Thread-Index: AQHQRjuRN28IQ+IMmk2R5cKY4QcqFpzsTHDQ//+6rgCAALQbEP//2L8AgAFDPqA= Date: Fri, 13 Feb 2015 02:46:00 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083065D1@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F1824AFFB@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083061CE@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.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083065D1NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bier@ietf.org" , Antoni Przygienda Subject: Re: [Bier] proposed BIER charter 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, 13 Feb 2015 02:46:18 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083065D1NKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxpYSwNCg0KSSBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnQgdGhhdCByZXF1aXJlbWVu dHMgYXJlIGVzc2VudGlhbCBmb3IgZGVzaWduaW5nIGFueSBuZXcgZGF0YS1wbGFuZSBlbmNhcHN1 bGF0aW9uLiBJIHdvbmRlciB3aGV0aGVyIHRoZSBCSUVSIFdHIHdvdWxkIHN0aWxsIHdvcmsgb3V0 IGEgZGF0YS1wbGFuZSByZXF1aXJlbWVudCBkb2N1bWVudCBnaXZlbiB0aGUgYXJjaGl0ZWN0dXJl IGRvY3VtZW50IGhhcyBhbHJlYWR5IGJlZW4gdGhlcmUuIElNSE8sIFRob3NlIGZpZWxkcy9lbGVt ZW50cyBvbiB0aGUgZGF0YS1wbGFuZSB3aGljaCBhcmUgZXNzZW50aWFsIGZvciB0aGUgQklFUiBm b3J3YXJkaW5nIGNvdWxkIGJlIHNwZWNpZmllZCBlaXRoZXIgaW4gdGhlIGFyY2hpdGVjdHVyZSBk b2N1bWVudCBvciBpbiB0aGUgZGF0YS1wbGFuZSByZXF1aXJlbWVudCBkb2N1bWVudC4gQXMgc3Vj aCwgYm90aCB0aGUgZ2VuZXJpYyBCSUVSIGVuY2Fwc3VsYXRpb24gc2NoZW1lIGFuZCB0aGUgTVBM Uy1kZXBlbmRhbnQgQklFUiBlbmNhcHN1bGF0aW9uIHNjaGVtZSBzaG91bGQgcmVzcGVjdCB0aG9z ZSBkYXRhLXBsYW5lIHJlcXVpcmVtZW50cy4gSW4gb3RoZXIgd29yZHMsIHRob3NlIG5lY2Vzc2Fy eSBmaWVsZHMvZWxlbWVudHMgZm9yIEJJRVIgZm9yd2FyZGluZyBjb3VsZCBiZSBjb21wbGV0ZWx5 IGNvbnRhaW5lZCBpbiBhIGdlbmVyaWMgQklFUiBoZWFkZXIgb3Igc3ByZWFkIG92ZXIgdGhlIE1Q TFMgaGVhZGVyIGFuZCB0aGUgTVBMUy1kZXBlbmRhbnQgIEJJRVIgaGVhZGVyLiBXaXRoIHRob3Nl IGRhdGEtcGxhbmUgcmVxdWlyZW1lbnRzIHdoaWNoIGFyZSBpbmRlcGVuZGVudCBmcm9tIGFueSBz cGVjaWZpYyBlbmNhcHN1bGF0aW9uIHNjaGVtZSwgd2UgY291bGQgZnVydGhlciBldmFsdWF0ZSB0 aGUgcHJvcyBhbmQgY29ucyBvZiBlYWNoIHNjaGVtZS4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1 DQoNCkZyb206IEFsaWEgQXRsYXMgW21haWx0bzpha2F0bGFzQGdtYWlsLmNvbV0NClNlbnQ6IFRo dXJzZGF5LCBGZWJydWFyeSAxMiwgMjAxNSAxMDo1MSBQTQ0KVG86IFh1eGlhb2h1DQpDYzogQW50 b25pIFByenlnaWVuZGE7IGJpZXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQmllcl0gcHJvcG9z ZWQgQklFUiBjaGFydGVyDQoNClhpYW9odSwNCg0KSSBjZXJ0YWlubHkgdW5kZXJzdGFuZCB0aGF0 IHlvdSBhcmUgdmVyeSBpbnRlcmVzdGVkIGluIHdvcmtpbmcgb24gYSBnZW5lcmljIGVuY2Fwc3Vs YXRpb24gZm9yIEJJRVIuICBJIGRvIHRoaW5rIHRoaXMgbWF5IGJlIHVzZWZ1bCB3b3JrLiAgVGhl IE1QTFMgZW5jYXBzdWxhdGlvbiB3b3JrIGlzIGZ1cnRoZXIgYWxvbmcgYW5kIGhhcyBzaWduaWZp Y2FudCBiZW5lZml0cyBpbiB0ZXJtcyBvZiBub3QgbmVlZGluZyB0byByZXZpc2l0IGEgbnVtYmVy IG9mIGlzc3VlcyB0aGF0IE1QTFMgYWxyZWFkeSBoYW5kbGVzLg0KDQpZb3VyIHByb3Bvc2VkIGNo YW5nZXMgYmFzaWNhbGx5IGVsaW1pbmF0ZSBhbnkgaW5kaWNhdGlvbiBvZiB3aGF0IG5lZWRzIHRv IGJlIGNvbnNpZGVyZWQgaW4gdGhlIGdlbmVyaWMgZW5jYXBzdWxhdGlvbiwgd2l0aG91dCBhbnkg cmVhc29uaW5nLCBhbmQgcHVzaGVzIGZvciBpdCB0byBiZSBjb25zaWRlcmVkIGFzIGFuIGVxdWFs IGZvY3VzIHdpdGggdGhlIE1QTFMgZW5jYXBzdWxhdGlvbi4gIEkgYW0gYWxyZWFkeSBjb25jZXJu ZWQgdGhhdCB0aGVyZSdzIGEgbG90IG9mIHdvcmsgZm9yIGJpZXIgdG8gZ2V0IHRocm91Z2guDQoN CkRvIHlvdSB0aGluayB0aGF0IHRoZSByZXF1aXJlbWVudHMgb24gdGhlIGdlbmVyaWMgZW5jYXBz dWxhdGlvbiBuZWVkIHJlZmluaW5nIGFuZCB3aHk/DQoNClJlZ2FyZHMsDQpBbGlhDQoNCg0KT24g VGh1LCBGZWIgMTIsIDIwMTUgYXQgNDoyOCBBTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5j b208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIFRvbnksDQoNClRoYW5r cyBhIGxvdCBmb3IgeW91ciByZXNwb25zZS4gSWYgdGhlIFdHIGlzIGludGVuZGVkIHRvIHdvcmsg b24gYm90aCBNUExTLWJhc2VkIGFuZCBub24tTVBMUy1iYXNlZCBCSUVSIGVuY2Fwc3VsYXRpb24g c2NoZW1lcyBjb25jdXJyZW50bHksIEkgd291bGQgc3VnZ2VzdCBtYWtpbmcgdGhlIGZvbGxvd2lu ZyBjaGFuZ2UgdG8gdGhlIEJJRVIgZW5jYXBzdWxhdGlvbiByZWxhdGVkIHRleHQ6DQoNCk9MRDoN CiAgIDIpIEJJRVIgZW5jYXBzdWxhdGlvbjogVGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGFzc3Vt ZSB0aGF0IHRoZQ0KICAgdGVjaG5vbG9neSB3aWxsIG5lZWQgdG8gYmUgZW1iZWRkZWQgaW4gdGhl IGRhdGEgcGxhbmUgYW5kIG9wZXJhdGUNCiAgIGF0IHRoZSBoaWdoZXN0IHBhY2tldCBsaW5lIHNw ZWVkcy4gIFRoZSBXRyB3aWxsIHB1Ymxpc2ggYSBkb2N1bWVudA0KICAgZGVmaW5pbmcgYW4gTVBM Uy1iYXNlZCBlbmNhcHN1bGF0aW9uIGJhc2VkIHVwb24NCiAgIGRyYWZ0LXdpam5hbmRzLW1wbHMt Ymllci1lbmNhcHN1bGF0aW9uLTAyLiBEdWUgdG8gdGhlIGNyaXRpY2FsIG5lZWQNCiAgIHRvIGhh dmUgYSBoaWdoLXF1YWxpdHkgYW5kIHN0YWJsZSBSRkMgZm9yIGEgbmV3IGRhdGEtcGxhbmUNCiAg IGVuY2Fwc3VsYXRpb24sIHRoZSBNUExTLWJhc2VkIGVuY2Fwc3VsYXRpb24gZHJhZnQgc2hhbGwg d2FpdCBhZnRlcg0KICAgV0dMQyBhbmQgbm90IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVu dGlsIHRoZXJlIGFyZSB0d28NCiAgIGluZGVwZW5kZW50IGludGVyb3BlcmFibGUgaW1wbGVtZW50 YXRpb25zLg0KDQogICBBcyBhIHNlY29uZGFyeSBmb2N1cywgdGhlIFdHIG1heSBhbHNvIHdvcmsg b24gb25lIG5vbi1NUExTDQogICBkYXRhLXBsYW5lIGVuY2Fwc3VsYXRpb24uICBUaGlzIGRyYWZ0 IGFsc28gc2hhbGwgd2FpdCBhZnRlciBXR0xDDQogICBhbmQgbm90IHByb2dyZXNzIHRvIElFVEYg TGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d28gaW5kZXBlbmRlbnQNCiAgIGludGVyb3BlcmFi bGUgaW1wbGVtZW50YXRpb25zLiAgVGhpcyBkcmFmdCBtdXN0IGZvY3VzIG9uIGFuZA0KICAgaW5j bHVkZSB0aGUgZm9sbG93aW5nIGRldGFpbHM6DQoNCiAgICAgICBhKSBXaGF0IGlzIHRoZSBhcHBs aWNhYmlsaXR5IG9mIHRoZSBlbmNhcHN1bGF0aW9uIGFuZCBmb3Igd2hpY2gNCiAgICAgICB1c2Ut Y2FzZXMgaXMgdGhpcyBlbmNhcHN1bGF0aW9uIHJlcXVpcmVkPw0KDQogICAgICAgYikgRG9lcyB0 aGlzIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24gaW1wbHkgYW55IGNoYW5nZXMgdG8gdGhlDQogICAg ICAgTVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9uPw0KDQogICAgICAgYykgV2hhdCBkZXNpZ24gY2hv aWNlcyBoYXZlIGJlZW4gbWFkZSBmb3IgdGhlIGVuY2Fwc3VsYXRpb24NCiAgICAgICB0eXBlIGFu ZCB0aGUgaW5jbHVkZWQgZmllbGRzLg0KDQogICAgICAgZCkgVGhlIHByb3Bvc2VkIGVuY2Fwc3Vs YXRpb24gd2l0aCBjb25zaWRlcmF0aW9ucyBnaXZlbiB0byBhdA0KICAgICAgIGxlYXN0IE9BTSwg Q2xhc3Mgb2YgU2VydmljZSwgc2VjdXJpdHksIGZyYWdtZW50YXRpb24sIFRUTC4NCk5FVzoNCjIp IEJJRVIgZW5jYXBzdWxhdGlvbjogVGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGFzc3VtZSB0aGF0 IHRoZQ0KICAgdGVjaG5vbG9neSB3aWxsIG5lZWQgdG8gYmUgZW1iZWRkZWQgaW4gdGhlIGRhdGEg cGxhbmUgYW5kIG9wZXJhdGUNCiAgIGF0IHRoZSBoaWdoZXN0IHBhY2tldCBsaW5lIHNwZWVkcy4g IFRoZSBXRyB3aWxsIHdvcmsgb24gYm90aCBNUExTLWJhc2VkDQphbmQgbm9uLU1QTFMtYmFzZWQg QklFUiBlbmNhcHN1bGF0aW9uIHNjaGVtZXMgYW5kIHB1Ymxpc2ggdGhlIGNvcnJlc3BvbmRpbmcg ZG9jdW1lbnRzLg0KRHVlIHRvIHRoZSBjcml0aWNhbCBuZWVkIHRvIGhhdmUgYSBoaWdoLXF1YWxp dHkgYW5kIHN0YWJsZSBSRkMgZm9yIGEgbmV3IGRhdGEtcGxhbmUNCiAgIGVuY2Fwc3VsYXRpb24s IHRoZSBCSUVSIGVuY2Fwc3VsYXRpb24gZHJhZnQgc2hhbGwgd2FpdCBhZnRlcg0KICAgV0dMQyBh bmQgbm90IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d28NCiAg IGluZGVwZW5kZW50IGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLg0KDQpCZXN0IHJlZ2Fy ZHMsDQpYaWFvaHUNCg0KDQoNCg0KRnJvbTogQW50b25pIFByenlnaWVuZGEgW21haWx0bzphbnRv bmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb208bWFpbHRvOmFudG9uaS5wcnp5Z2llbmRhQGVyaWNz c29uLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTIsIDIwMTUgMjoyNyBQTQ0KVG86 IFh1eGlhb2h1OyBiaWVyQGlldGYub3JnPG1haWx0bzpiaWVyQGlldGYub3JnPg0KU3ViamVjdDog UkU6IFtCaWVyXSBwcm9wb3NlZCBCSUVSIGNoYXJ0ZXINCg0KPGhhdCB0eXBlPeKAnXdnIGNoYWly 4oCdPg0KDQpJTUhPLCB0aGUgQklFUiBsYXllciBpcyBleGFjdGx5IGEgdG90YWxseSBuZXcgTkVU V09SSyBMQVlFUg0KW1Rvbnkgc2FpZF0gWHV4aWFvaHUsIHRoYXQgYWxsIGRlcGVuZHMgaG93IElQ IGNlbnRyaWMgb25lIHNlZXMgaXQuIEl0IGNhbiBiZSBjb25zaWRlcmVkIGxheWVyIDIuNSBhcyB3 ZWxsIGdpdmVuIGl0IGRvZXNu4oCZdCBldmVuIGhhdmUgdG8gY2FycnkgSVAgZnJhbWVzLg0KYW5k IHRoZXJlZm9yZSB0aGUgQklFUiBoZWFkZXIgaXMgYmV0dGVyIHRvIGJlIGRlc2lnbmVkIGFzIGEg Y29tcGxldGUgbmV0d29yayBsYXllciBoZWFkZXIgZnJvbSB0aGUgYmVnaW5uaW5nLCByYXRoZXIg dGhhbiBjb3VwbGluZyBpdCB3aXRoIGFuIE1QTFMgbGFiZWwgc28gYXMgdG8gYmUgY2FwYWJsZSBv ZiBhY3RpbmcgYXMgYSBjb21wbGV0ZSBuZXR3b3JrIGxheWVyIGhlYWRlciwgd2hpY2ggaXMgc3Bl Y2lhbGx5IG1lYW5pbmdmdWwgaW4gdGhlIG5vbi1NUExTIG5ldHdvcmsgZW52aXJvbm1lbnRzLiBU aGVyZWZvcmUsIGl0IHNlZW1zIG1vcmUgcmVhc29uYWJsZSB0byBhbGxvdyB0aGUgV0cgdG8gd29y ayBvbiB0aGUgTVBMUy1iYXNlZCBhbmQgbm9uLU1QTFMtYmFzZWQgZW5jYXBzdWxhdGlvbiBvcHRp b25zIGNvbmN1cnJlbnRseQ0KW1Rvbnkgc2FpZF0gSSBkbyBOT1Qgc2VlIGFueXdoZXJlIGluIHRo ZSBjaGFydGVyIHRoYXQgYm90aCBDQU5OT1QgYmUgd29ya2VkIG9uIGNvbmN1cnJlbnRseS4gQWRk aXRpb25hbCB0aG91Z2h0IGhhcyBiZWVuIHB1dCBpbnRvIHNwZWNpZnlpbmcgV0hBVCBhIGdlbmVy aWMgZW5jb2RpbmcgZHJhZnQgbmVlZHMgdG8gcHJvdmlkZSBmb3IgaXQgdG8gYmUgaGlnaCBxdWFs aXR5IGFuZCBJIHRoaW5rIHRoZXJlIGlzIGVub3VnaCB3b3JrIHRvIGJlIGRvbmUgdGhlcmUuIE1Q TFMgaXMgc2ltcGx5IHRoZSBtb3N0IHByYWdtYXRpYyBjaG9pY2Ugb2YgYSBsb25nIG1hdHVyZSBM Mi41IHRlY2hub2xvZ3kgdGhhdCBwcm92YWJseSBzb2x2ZXMgbWFueSBsYXJnZS1zY2FsZSBkZXBs b3ltZW50IHByb2JsZW1zLg0KDQo8L2hhdD4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkJJRVIgbWFpbGluZyBsaXN0DQpCSUVSQGlldGYub3JnPG1h aWx0bzpCSUVSQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9iaWVyDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083065D1NKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsN Cglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnm s6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQWxpYSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnQgdGhh dCByZXF1aXJlbWVudHMgYXJlIGVzc2VudGlhbCBmb3IgZGVzaWduaW5nIGFueSBuZXcgZGF0YS1w bGFuZSBlbmNhcHN1bGF0aW9uLiBJIHdvbmRlciB3aGV0aGVyIHRoZSBCSUVSIFdHIHdvdWxkDQog c3RpbGwgd29yayBvdXQgYSBkYXRhLXBsYW5lIHJlcXVpcmVtZW50IGRvY3VtZW50IGdpdmVuIHRo ZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaGFzIGFscmVhZHkgYmVlbiB0aGVyZS4gSU1ITywgVGhv c2UgZmllbGRzL2VsZW1lbnRzIG9uIHRoZSBkYXRhLXBsYW5lIHdoaWNoIGFyZSBlc3NlbnRpYWwg Zm9yIHRoZSBCSUVSIGZvcndhcmRpbmcgY291bGQgYmUgc3BlY2lmaWVkIGVpdGhlciBpbiB0aGUg YXJjaGl0ZWN0dXJlIGRvY3VtZW50IG9yIGluDQogdGhlIGRhdGEtcGxhbmUgcmVxdWlyZW1lbnQg ZG9jdW1lbnQuIEFzIHN1Y2gsIGJvdGggdGhlIGdlbmVyaWMgQklFUiBlbmNhcHN1bGF0aW9uIHNj aGVtZSBhbmQgdGhlIE1QTFMtZGVwZW5kYW50IEJJRVIgZW5jYXBzdWxhdGlvbiBzY2hlbWUgc2hv dWxkIHJlc3BlY3QgdGhvc2UgZGF0YS1wbGFuZSByZXF1aXJlbWVudHMuIEluIG90aGVyIHdvcmRz LCB0aG9zZSBuZWNlc3NhcnkgZmllbGRzL2VsZW1lbnRzIGZvciBCSUVSIGZvcndhcmRpbmcgY291 bGQNCiBiZSBjb21wbGV0ZWx5IGNvbnRhaW5lZCBpbiBhIGdlbmVyaWMgQklFUiBoZWFkZXIgb3Ig c3ByZWFkIG92ZXIgdGhlIE1QTFMgaGVhZGVyIGFuZCB0aGUgTVBMUy1kZXBlbmRhbnQmbmJzcDsg QklFUiBoZWFkZXIuIFdpdGggdGhvc2UgZGF0YS1wbGFuZSByZXF1aXJlbWVudHMgd2hpY2ggYXJl IGluZGVwZW5kZW50IGZyb20gYW55IHNwZWNpZmljIGVuY2Fwc3VsYXRpb24gc2NoZW1lLCB3ZSBj b3VsZCBmdXJ0aGVyIGV2YWx1YXRlIHRoZSBwcm9zIGFuZCBjb25zDQogb2YgZWFjaCBzY2hlbWUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlhpYW9odTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBBbGlhIEF0bGFzIFttYWlsdG86YWthdGxhc0BnbWFpbC5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE1IDEwOjUxIFBNPGJyPg0K PGI+VG86PC9iPiBYdXhpYW9odTxicj4NCjxiPkNjOjwvYj4gQW50b25pIFByenlnaWVuZGE7IGJp ZXJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtCaWVyXSBwcm9wb3NlZCBCSUVS IGNoYXJ0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WGlhb2h1 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgY2VydGFpbmx5IHVu ZGVyc3RhbmQgdGhhdCB5b3UgYXJlIHZlcnkgaW50ZXJlc3RlZCBpbiB3b3JraW5nIG9uIGEgZ2Vu ZXJpYyBlbmNhcHN1bGF0aW9uIGZvciBCSUVSLiZuYnNwOyBJIGRvIHRoaW5rIHRoaXMgbWF5IGJl IHVzZWZ1bCB3b3JrLiZuYnNwOyBUaGUgTVBMUyBlbmNhcHN1bGF0aW9uIHdvcmsgaXMgZnVydGhl ciBhbG9uZyBhbmQgaGFzIHNpZ25pZmljYW50IGJlbmVmaXRzIGluIHRlcm1zDQogb2Ygbm90IG5l ZWRpbmcgdG8gcmV2aXNpdCBhIG51bWJlciBvZiBpc3N1ZXMgdGhhdCBNUExTIGFscmVhZHkgaGFu ZGxlcy4gJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2 LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5Zb3VyIHByb3Bvc2VkIGNoYW5nZXMgYmFzaWNhbGx5IGVsaW1pbmF0ZSBhbnkg aW5kaWNhdGlvbiBvZiB3aGF0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgaW4gdGhlIGdlbmVyaWMg ZW5jYXBzdWxhdGlvbiwgd2l0aG91dCBhbnkgcmVhc29uaW5nLCBhbmQgcHVzaGVzIGZvciBpdCB0 byBiZSBjb25zaWRlcmVkIGFzIGFuIGVxdWFsIGZvY3VzIHdpdGggdGhlIE1QTFMgZW5jYXBzdWxh dGlvbi4mbmJzcDsNCiBJIGFtIGFscmVhZHkgY29uY2VybmVkIHRoYXQgdGhlcmUncyBhIGxvdCBv ZiB3b3JrIGZvciBiaWVyIHRvIGdldCB0aHJvdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RG8geW91IHRoaW5rIHRoYXQgdGhlIHJlcXVpcmVtZW50 cyBvbiB0aGUgZ2VuZXJpYyBlbmNhcHN1bGF0aW9uIG5lZWQgcmVmaW5pbmcgYW5kIHdoeT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkFsaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBGZWIgMTIsIDIwMTUg YXQgNDoyOCBBTSwgWHV4aWFvaHUgJmx0OzxhIGhyZWY9Im1haWx0bzp4dXhpYW9odUBodWF3ZWku Y29tIiB0YXJnZXQ9Il9ibGFuayI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkhpIFRvbnksPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGEgbG90 IGZvciB5b3VyIHJlc3BvbnNlLiBJZiB0aGUgV0cgaXMgaW50ZW5kZWQgdG8gd29yayBvbiBib3Ro IE1QTFMtYmFzZWQgYW5kDQogbm9uLU1QTFMtYmFzZWQgQklFUiBlbmNhcHN1bGF0aW9uIHNjaGVt ZXMgY29uY3VycmVudGx5LCBJIHdvdWxkIHN1Z2dlc3QgbWFraW5nIHRoZSBmb2xsb3dpbmcgY2hh bmdlIHRvIHRoZSBCSUVSIGVuY2Fwc3VsYXRpb24gcmVsYXRlZCB0ZXh0Ojwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9MRDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyAmbmJzcDsyKSBCSUVSIGVuY2Fwc3VsYXRpb246IFRoZSB3b3JraW5nIGdyb3Vw IHNob3VsZCBhc3N1bWUgdGhhdCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7dGVjaG5vbG9neSB3 aWxsIG5lZWQgdG8gYmUgZW1iZWRkZWQgaW4gdGhlIGRhdGEgcGxhbmUgYW5kIG9wZXJhdGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsgJm5ic3A7YXQgdGhlIGhpZ2hlc3QgcGFja2V0IGxpbmUgc3BlZWRzLiZuYnNw OyBUaGUgV0cgd2lsbCBwdWJsaXNoIGEgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ZGVm aW5pbmcgYW4gTVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9uIGJhc2VkIHVwb248bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsgJm5ic3A7ZHJhZnQtd2lqbmFuZHMtbXBscy1iaWVyLWVuY2Fwc3VsYXRpb24tMDIuIER1ZSB0 byB0aGUgY3JpdGljYWwgbmVlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDt0byBoYXZlIGEgaGlnaC1x dWFsaXR5IGFuZCBzdGFibGUgUkZDIGZvciBhIG5ldyBkYXRhLXBsYW5lPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 ICZuYnNwO2VuY2Fwc3VsYXRpb24sIHRoZSBNUExTLWJhc2VkIGVuY2Fwc3VsYXRpb24gZHJhZnQg c2hhbGwgd2FpdCBhZnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtXR0xDIGFuZCBub3QgcHJvZ3Jl c3MgdG8gSUVURiBMYXN0IENhbGwgdW50aWwgdGhlcmUgYXJlIHR3bzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAm bmJzcDtpbmRlcGVuZGVudCBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7QXMgYSBzZWNvbmRhcnkgZm9jdXMsIHRoZSBXRyBt YXkgYWxzbyB3b3JrIG9uIG9uZSBub24tTVBMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtkYXRhLXBs YW5lIGVuY2Fwc3VsYXRpb24uJm5ic3A7IFRoaXMgZHJhZnQgYWxzbyBzaGFsbCB3YWl0IGFmdGVy IFdHTEM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7YW5kIG5vdCBwcm9ncmVzcyB0byBJRVRGIExhc3Qg Q2FsbCB1bnRpbCB0aGVyZSBhcmUgdHdvIGluZGVwZW5kZW50PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNw O2ludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLiZuYnNwOyBUaGlzIGRyYWZ0IG11c3QgZm9j dXMgb24gYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2luY2x1ZGUgdGhlIGZvbGxvd2luZyBkZXRh aWxzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Ep IFdoYXQgaXMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIGVuY2Fwc3VsYXRpb24gYW5kIGZvciB3 aGljaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VzZS1jYXNlcyBpcyB0aGlz IGVuY2Fwc3VsYXRpb24gcmVxdWlyZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7YikgRG9lcyB0aGlzIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24gaW1w bHkgYW55IGNoYW5nZXMgdG8gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 TVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2MpIFdoYXQgZGVzaWduIGNob2ljZXMgaGF2ZSBiZWVuIG1hZGUg Zm9yIHRoZSBlbmNhcHN1bGF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 dHlwZSBhbmQgdGhlIGluY2x1ZGVkIGZpZWxkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkKSBUaGUgcHJvcG9zZWQgZW5jYXBzdWxhdGlvbiB3aXRo IGNvbnNpZGVyYXRpb25zIGdpdmVuIHRvIGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7bGVhc3QgT0FNLCBDbGFzcyBvZiBTZXJ2aWNlLCBzZWN1cml0eSwgZnJhZ21lbnRhdGlv biwgVFRMLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ORVc6 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1pbmRlbnQ6MjQuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4y KSBCSUVSIGVuY2Fwc3VsYXRpb246IFRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBhc3N1bWUgdGhh dCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7dGVjaG5vbG9neSB3aWxsIG5lZWQgdG8gYmUgZW1i ZWRkZWQgaW4gdGhlIGRhdGEgcGxhbmUgYW5kIG9wZXJhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7 YXQgdGhlIGhpZ2hlc3QgcGFja2V0IGxpbmUgc3BlZWRzLiZuYnNwOyBUaGUgV0cgd2lsbCB3b3Jr IG9uIGJvdGggTVBMUy1iYXNlZA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO3RleHQtaW5kZW50OjMwLjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+YW5kIG5v bi1NUExTLWJhc2VkIEJJRVIgZW5jYXBzdWxhdGlvbiBzY2hlbWVzIGFuZCBwdWJsaXNoIHRoZSBj b3JyZXNwb25kaW5nIGRvY3VtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87dGV4dC1pbmRlbnQ6MjQuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5EdWUg dG8gdGhlIGNyaXRpY2FsIG5lZWQgdG8gaGF2ZSBhIGhpZ2gtcXVhbGl0eSBhbmQgc3RhYmxlIFJG QyBmb3IgYSBuZXcgZGF0YS1wbGFuZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtlbmNhcHN1bGF0aW9u LCB0aGUgQklFUiBlbmNhcHN1bGF0aW9uIGRyYWZ0IHNoYWxsIHdhaXQgYWZ0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsgJm5ic3A7V0dMQyBhbmQgbm90IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGls IHRoZXJlIGFyZSB0d288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7aW5kZXBlbmRlbnQgaW50ZXJvcGVy YWJsZSBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCByZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPlhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBBbnRvbmkNCiBQcnp5Z2llbmRhIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOmFudG9uaS5wcnp5Z2llbmRhQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFudG9u aS5wcnp5Z2llbmRhQGVyaWNzc29uLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEZlYnJ1YXJ5IDEyLCAyMDE1IDI6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+IFh1eGlhb2h1OyA8 YSBocmVmPSJtYWlsdG86YmllckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJpZXJAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbQmllcl0gcHJvcG9zZWQgQklFUiBjaGFy dGVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jmx0O2hhdCB0eXBlPeKAnXdnIGNoYWly4oCdJmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPklNSE8sIHRoZSBCSUVSIGxheWVyIGlzIGV4YWN0bHkgYSB0b3RhbGx5 IG5ldyBORVRXT1JLIExBWUVSDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVG9ueSBzYWlkXQ0KPC9z cGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5YdXhpYW9odSwNCjwvc3Bhbj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRoYXQgYWxsIGRlcGVuZHMgaG93IElQ IGNlbnRyaWMgb25lIHNlZXMgaXQuIEl0IGNhbiBiZSBjb25zaWRlcmVkIGxheWVyIDIuNSBhcyB3 ZWxsIGdpdmVuIGl0IGRvZXNu4oCZdCBldmVuIGhhdmUgdG8gY2FycnkgSVAgZnJhbWVzLg0KPC9z cGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5hbmQgdGhlcmVmb3JlIHRoZSBCSUVSIGhlYWRlciBpcyBiZXR0 ZXIgdG8gYmUgZGVzaWduZWQgYXMgYSBjb21wbGV0ZSBuZXR3b3JrIGxheWVyIGhlYWRlcg0KIGZy b20gdGhlIGJlZ2lubmluZywgcmF0aGVyIHRoYW4gY291cGxpbmcgaXQgd2l0aCBhbiBNUExTIGxh YmVsIHNvIGFzIHRvIGJlIGNhcGFibGUgb2YgYWN0aW5nIGFzIGEgY29tcGxldGUgbmV0d29yayBs YXllciBoZWFkZXIsIHdoaWNoIGlzIHNwZWNpYWxseSBtZWFuaW5nZnVsIGluIHRoZSBub24tTVBM UyBuZXR3b3JrIGVudmlyb25tZW50cy4gVGhlcmVmb3JlLCBpdCBzZWVtcyBtb3JlIHJlYXNvbmFi bGUgdG8gYWxsb3cgdGhlIFdHIHRvIHdvcmsNCiBvbiB0aGUgTVBMUy1iYXNlZCBhbmQgbm9uLU1Q TFMtYmFzZWQgZW5jYXBzdWxhdGlvbiBvcHRpb25zIGNvbmN1cnJlbnRseSA8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5bVG9ueSBzYWlkXSBJIGRvIE5PVCBzZWUgYW55d2hlcmUgaW4gdGhlIGNoYXJ0ZXIg dGhhdCBib3RoIENBTk5PVCBiZSB3b3JrZWQgb24NCiBjb25jdXJyZW50bHkuIEFkZGl0aW9uYWwg dGhvdWdodCBoYXMgYmVlbiBwdXQgaW50byBzcGVjaWZ5aW5nIFdIQVQgYSBnZW5lcmljIGVuY29k aW5nIGRyYWZ0IG5lZWRzIHRvIHByb3ZpZGUgZm9yIGl0IHRvIGJlIGhpZ2ggcXVhbGl0eSBhbmQg SSB0aGluayB0aGVyZSBpcyBlbm91Z2ggd29yayB0byBiZSBkb25lIHRoZXJlLiBNUExTIGlzIHNp bXBseSB0aGUgbW9zdCBwcmFnbWF0aWMgY2hvaWNlIG9mIGEgbG9uZyBtYXR1cmUgTDIuNSB0ZWNo bm9sb2d5DQogdGhhdCBwcm92YWJseSBzb2x2ZXMgbWFueSBsYXJnZS1zY2FsZSBkZXBsb3ltZW50 IHByb2JsZW1zLiA8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDsvaGF0Jmd0Ozwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KQklFUiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QklFUkBpZXRmLm9y ZyI+QklFUkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2JpZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2JpZXI8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083065D1NKGEML512MBSchi_-- From nobody Thu Feb 12 18:58:06 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336D91A1A88 for ; Thu, 12 Feb 2015 18:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIcFnl-bSW0x for ; Thu, 12 Feb 2015 18:58:00 -0800 (PST) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2891A007D for ; Thu, 12 Feb 2015 18:58:00 -0800 (PST) Received: by mail-yh0-f47.google.com with SMTP id b6so6830125yha.6 for ; Thu, 12 Feb 2015 18:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8E3VE3/xQWTWvqzZWWIErcJYsEdwbNMCwvaVyLBr2xc=; b=RQcV3rwsMSN7XKFSglwcQ0l1y05SdL4nMfA7Uf5GByPSQDnKxy0JdhjfPfJ9ie3HDz fgyycC0WwlOGc30O8aFcC1qFHrTpTFs95MtnJsq63ARbEcqOn0YMjIP6ofFOA8zrxn1R k04EBD/zJ3icMX8kattsjOZruyfyq5qwMhG393Kv6Mr13+xpvyMdPEouuOvPkoQ/MLB0 IsT7mFz+N6oAw3ON2fieXBAGyNyMylynC6ScWrAaRomyUP35eGXSkPLgLtNAEDfB6MUx wSi2UgQQVs2iOKOSJTKZfWsrh5hoVBJ6ZzRFDWDBbX1/T9F81heknLjDGnR0LKdEwCiX s94Q== MIME-Version: 1.0 X-Received: by 10.236.13.100 with SMTP id a64mr6518947yha.25.1423796279621; Thu, 12 Feb 2015 18:57:59 -0800 (PST) Received: by 10.170.133.197 with HTTP; Thu, 12 Feb 2015 18:57:59 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083065D1@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F1824AFFB@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083061CE@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083065D1@NKGEML512-MBS.china.huawei.com> Date: Thu, 12 Feb 2015 21:57:59 -0500 Message-ID: From: Alia Atlas To: Xuxiaohu Content-Type: multipart/alternative; boundary=001a11c24e607abc56050eef67e8 Archived-At: Cc: "bier@ietf.org" , Antoni Przygienda Subject: Re: [Bier] proposed BIER charter 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, 13 Feb 2015 02:58:04 -0000 --001a11c24e607abc56050eef67e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Xiaohu, The details of what fields and sizes need to be in the encapsulation should be captured in the architecture draft. In the proposed charter, that is specified in: " 1) BIER architecture: The WG will publish an architecture, based upon draft-wijnands-bier-architecture-04. It will include the normative algorithm for how BIER packet forwarding is done. It will specify the information that is required by a BIER header to support BIER forwarding." As you can probably tell from this charter, I am really steering away from process-style documents in favor of combining requirements with the associated solutions, in terms of minimizing the number of use-case drafts, and so on. At the end of the day, we need RFCs that describe functionality that can be implemented, deployed, and be interoperable. Regards, Alia On Thu, Feb 12, 2015 at 9:46 PM, Xuxiaohu wrote: > Hi Alia, > > > > I fully agree with your point that requirements are essential for > designing any new data-plane encapsulation. I wonder whether the BIER WG > would still work out a data-plane requirement document given the > architecture document has already been there. IMHO, Those fields/elements > on the data-plane which are essential for the BIER forwarding could be > specified either in the architecture document or in the data-plane > requirement document. As such, both the generic BIER encapsulation scheme > and the MPLS-dependant BIER encapsulation scheme should respect those > data-plane requirements. In other words, those necessary fields/elements > for BIER forwarding could be completely contained in a generic BIER heade= r > or spread over the MPLS header and the MPLS-dependant BIER header. With > those data-plane requirements which are independent from any specific > encapsulation scheme, we could further evaluate the pros and cons of each > scheme. > > > > Best regards, > > Xiaohu > > > > *From:* Alia Atlas [mailto:akatlas@gmail.com] > *Sent:* Thursday, February 12, 2015 10:51 PM > *To:* Xuxiaohu > *Cc:* Antoni Przygienda; bier@ietf.org > *Subject:* Re: [Bier] proposed BIER charter > > > > Xiaohu, > > > > I certainly understand that you are very interested in working on a > generic encapsulation for BIER. I do think this may be useful work. The > MPLS encapsulation work is further along and has significant benefits in > terms of not needing to revisit a number of issues that MPLS already > handles. > > > > Your proposed changes basically eliminate any indication of what needs to > be considered in the generic encapsulation, without any reasoning, and > pushes for it to be considered as an equal focus with the MPLS > encapsulation. I am already concerned that there's a lot of work for bie= r > to get through. > > > > Do you think that the requirements on the generic encapsulation need > refining and why? > > > > Regards, > > Alia > > > > > > On Thu, Feb 12, 2015 at 4:28 AM, Xuxiaohu wrote: > > Hi Tony, > > > > Thanks a lot for your response. If the WG is intended to work on both > MPLS-based and non-MPLS-based BIER encapsulation schemes concurrently, I > would suggest making the following change to the BIER encapsulation relat= ed > text: > > > > OLD: > > 2) BIER encapsulation: The working group should assume that the > > technology will need to be embedded in the data plane and operate > > at the highest packet line speeds. The WG will publish a document > > defining an MPLS-based encapsulation based upon > > draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need > > to have a high-quality and stable RFC for a new data-plane > > encapsulation, the MPLS-based encapsulation draft shall wait after > > WGLC and not progress to IETF Last Call until there are two > > independent interoperable implementations. > > > > As a secondary focus, the WG may also work on one non-MPLS > > data-plane encapsulation. This draft also shall wait after WGLC > > and not progress to IETF Last Call until there are two independent > > interoperable implementations. This draft must focus on and > > include the following details: > > > > a) What is the applicability of the encapsulation and for which > > use-cases is this encapsulation required? > > > > b) Does this proposed encapsulation imply any changes to the > > MPLS-based encapsulation? > > > > c) What design choices have been made for the encapsulation > > type and the included fields. > > > > d) The proposed encapsulation with considerations given to at > > least OAM, Class of Service, security, fragmentation, TTL. > > NEW: > > 2) BIER encapsulation: The working group should assume that the > > technology will need to be embedded in the data plane and operate > > at the highest packet line speeds. The WG will work on both MPLS-base= d > > and non-MPLS-based BIER encapsulation schemes and publish the > corresponding documents. > > Due to the critical need to have a high-quality and stable RFC for a new > data-plane > > encapsulation, the BIER encapsulation draft shall wait after > > WGLC and not progress to IETF Last Call until there are two > > independent interoperable implementations. > > > > Best regards, > > Xiaohu > > > > > > > > > > *From:* Antoni Przygienda [mailto:antoni.przygienda@ericsson.com] > *Sent:* Thursday, February 12, 2015 2:27 PM > *To:* Xuxiaohu; bier@ietf.org > *Subject:* RE: [Bier] proposed BIER charter > > > > > > > > IMHO, the BIER layer is exactly a totally new NETWORK LAYER > > *[Tony said] *Xuxiaohu, *that all depends how IP centric one sees it. It > can be considered layer 2.5 as well given it doesn=E2=80=99t even have to= carry IP > frames. * > > and therefore the BIER header is better to be designed as a complete > network layer header from the beginning, rather than coupling it with an > MPLS label so as to be capable of acting as a complete network layer > header, which is specially meaningful in the non-MPLS network environment= s. > Therefore, it seems more reasonable to allow the WG to work on the > MPLS-based and non-MPLS-based encapsulation options concurrently > > *[Tony said] I do NOT see anywhere in the charter that both CANNOT be > worked on concurrently. Additional thought has been put into specifying > WHAT a generic encoding draft needs to provide for it to be high quality > and I think there is enough work to be done there. MPLS is simply the mos= t > pragmatic choice of a long mature L2.5 technology that provably solves ma= ny > large-scale deployment problems. * > > > > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > > --001a11c24e607abc56050eef67e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Xiaohu,

The details of what fields a= nd sizes need to be in the encapsulation should be captured in the architec= ture draft.
In the proposed charter, that is specified in:
<= div>" =C2=A0 1) BIER architecture: The WG will publish an architecture= , based
=C2=A0 =C2=A0upon draft-wijnands-bier-architecture-04.=C2= =A0 It will include the
=C2=A0 =C2=A0normative algorithm for how = BIER packet forwarding is done.=C2=A0 It
=C2=A0 =C2=A0will specif= y the information that is required by a BIER header to
=C2=A0 =C2= =A0support BIER forwarding."

As you can proba= bly tell from this charter, I am really steering away from process-style do= cuments in favor
of combining requirements with the associated so= lutions, in terms of minimizing the number of use-case drafts,
an= d so on.=C2=A0 At the end of the day, we need RFCs that describe functional= ity that can be implemented, deployed,
and be interoperable.

Regards,
Alia


On Thu, Feb 12, 2015 = at 9:46 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi Alia,

=C2= =A0

I fully ag= ree with your point that requirements are essential for designing any new d= ata-plane encapsulation. I wonder whether the BIER WG would still work out a data-plane requirement document given the architecture do= cument has already been there. IMHO, Those fields/elements on the data-plan= e which are essential for the BIER forwarding could be specified either in = the architecture document or in the data-plane requirement document. As such, both the generic BIER encaps= ulation scheme and the MPLS-dependant BIER encapsulation scheme should resp= ect those data-plane requirements. In other words, those necessary fields/e= lements for BIER forwarding could be completely contained in a generic BIER header or spread over the MPLS h= eader and the MPLS-dependant=C2=A0 BIER header. With those data-plane requi= rements which are independent from any specific encapsulation scheme, we co= uld further evaluate the pros and cons of each scheme.

=C2= =A0

Best regar= ds,

Xiaohu<= /u>

=C2= =A0

From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: Thursday, February 12, 2015 10:51 PM
To: Xuxiaohu
Cc: Antoni Przygienda; bier@ietf.org
Subject: Re: [Bier] proposed BIER charter=

=C2=A0

Xiaohu,

=C2=A0

I certainly understand that you= are very interested in working on a generic encapsulation for BIER.=C2=A0 = I do think this may be useful work.=C2=A0 The MPLS encapsulation work is fu= rther along and has significant benefits in terms of not needing to revisit a number of issues that MPLS already handles. = =C2=A0

=C2=A0

Your proposed changes basically= eliminate any indication of what needs to be considered in the generic enc= apsulation, without any reasoning, and pushes for it to be considered as an= equal focus with the MPLS encapsulation.=C2=A0 I am already concerned that there's a lot of work for bier to get thro= ugh.

=C2=A0

Do you think that the requireme= nts on the generic encapsulation need refining and why?

=C2=A0

Regards,

Alia

=C2=A0

=C2=A0

On Thu, Feb 12, 2015 at 4:28 AM= , Xuxiaohu <xux= iaohu@huawei.com> wrote:

Hi Tony,

=C2=A0

Thanks a l= ot for your response. If the WG is intended to work on both MPLS-based and non-MPLS-based BIER encapsulation schemes concurrently, I would suggest ma= king the following change to the BIER encapsulation related text:

=C2=A0

OLD:

=C2=A0 =C2=A02) BIER encapsulat= ion: The working group should assume that the

=C2=A0 =C2=A0technology will ne= ed to be embedded in the data plane and operate

=C2=A0 =C2=A0at the highest pac= ket line speeds.=C2=A0 The WG will publish a document<= /p>

=C2=A0 =C2=A0defining an MPLS-b= ased encapsulation based upon

=C2=A0 =C2=A0draft-wijnands-mpl= s-bier-encapsulation-02. Due to the critical need

=C2=A0 =C2=A0to have a high-qua= lity and stable RFC for a new data-plane

=C2=A0 =C2=A0encapsulation, the= MPLS-based encapsulation draft shall wait after

=C2=A0 =C2=A0WGLC and not progr= ess to IETF Last Call until there are two

=C2=A0 =C2=A0independent intero= perable implementations.

=C2=A0

=C2=A0 =C2=A0As a secondary foc= us, the WG may also work on one non-MPLS

=C2=A0 =C2=A0data-plane encapsu= lation.=C2=A0 This draft also shall wait after WGLC

=C2=A0 =C2=A0and not progress t= o IETF Last Call until there are two independent

=C2=A0 =C2=A0interoperable impl= ementations.=C2=A0 This draft must focus on and

=C2=A0 =C2=A0include the follow= ing details:

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0a) W= hat is the applicability of the encapsulation and for which

=C2=A0 =C2=A0 =C2=A0 =C2=A0use-= cases is this encapsulation required?

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0b) D= oes this proposed encapsulation imply any changes to the

=C2=A0 =C2=A0 =C2=A0 =C2=A0MPLS= -based encapsulation?

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0c) W= hat design choices have been made for the encapsulation

=C2=A0 =C2=A0 =C2=A0 =C2=A0type= and the included fields.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0d) T= he proposed encapsulation with considerations given to at

=C2=A0 =C2=A0 =C2=A0 =C2=A0leas= t OAM, Class of Service, security, fragmentation, TTL.=

NEW:

2) BIER encapsulation: The working group should assume= that the

=C2=A0 =C2=A0technology will ne= ed to be embedded in the data plane and operate

=C2=A0 =C2=A0at the highest pac= ket line speeds.=C2=A0 The WG will work on both MPLS-based

and non-MPLS-based BIER encapsulation schemes and publ= ish the corresponding documents.

Due to the critical need to have a high-quality and st= able RFC for a new data-plane

=C2=A0 =C2=A0encapsulation, the= BIER encapsulation draft shall wait after

=C2=A0 =C2=A0WGLC and not progr= ess to IETF Last Call until there are two

=C2=A0 =C2=A0independent intero= perable implementations.

=C2=A0

Best regards,

Xiaohu

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Antoni Przygienda [mailto:antoni.przygienda@ericsson.com]
Sent: Thursday, February 12, 2015 2:27 PM
To: Xuxiaohu; bie= r@ietf.org
Subject: RE: [Bier] proposed BIER charter

=C2=A0

<hat ty= pe=3D=E2=80=9Dwg chair=E2=80=9D>

=C2=A0

IMHO, the = BIER layer is exactly a totally new NETWORK LAYER

[Ton= y said] Xuxiaohu, that all depends how= IP centric one sees it. It can be considered layer 2.5 as well given it do= esn=E2=80=99t even have to carry IP frames.

and theref= ore the BIER header is better to be designed as a complete network layer he= ader from the beginning, rather than coupling it with an MPLS label so as to be= capable of acting as a complete network layer header, which is specially m= eaningful in the non-MPLS network environments. Therefore, it seems more re= asonable to allow the WG to work on the MPLS-based and non-MPLS-based encapsulation options concurrently

[Ton= y said] I do NOT see anywhere in the charter that both CANNOT be worked on concurrently. Additional thought has been put into specifying WHAT a gener= ic encoding draft needs to provide for it to be high quality and I think th= ere is enough work to be done there. MPLS is simply the most pragmatic choi= ce of a long mature L2.5 technology that provably solves many large-scale deployment problems. =

=C2=A0

</hat&g= t;

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

=C2=A0


--001a11c24e607abc56050eef67e8-- From nobody Thu Feb 12 18:59:03 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7011A1A88 for ; Thu, 12 Feb 2015 18:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iofR160z5FCj for ; Thu, 12 Feb 2015 18:58:58 -0800 (PST) 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 9C1321A1A29 for ; Thu, 12 Feb 2015 18:58:57 -0800 (PST) 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 BSO77019; Fri, 13 Feb 2015 02:58:56 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Feb 2015 02:58:55 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 13 Feb 2015 10:58:42 +0800 From: Xuxiaohu To: Xuxiaohu , Alia Atlas Thread-Topic: [Bier] proposed BIER charter Thread-Index: AQHQRjuRN28IQ+IMmk2R5cKY4QcqFpzsTHDQ//+6rgCAALQbEP//2L8AgAFDPqCAAAymcA== Date: Fri, 13 Feb 2015 02:58:41 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830660F@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F1824AFFB@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083061CE@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.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830660FNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bier@ietf.org" , Antoni Przygienda Subject: Re: [Bier] proposed BIER charter 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, 13 Feb 2015 02:59:02 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830660FNKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 cy90aG9zZSBuZWNlc3NhcnkgZmllbGRzL2VsZW1lbnRzIGZvciBCSUVSIGZvcndhcmRpbmcgY291 bGQgYmUgY29tcGxldGVseSBjb250YWluZWQgaW4gYSBnZW5lcmljIEJJRVIgaGVhZGVyIG9yIHNw cmVhZCBvdmVyIHRoZSBNUExTIGhlYWRlciBhbmQgdGhlIE1QTFMtZGVwZW5kYW50ICBCSUVSIGhl YWRlcg0KLyB0aG9zZSBuZWNlc3NhcnkgZmllbGRzL2VsZW1lbnRzIGZvciBCSUVSIGZvcndhcmRp bmcgY291bGQgYmUgY29tcGxldGVseSBjb250YWluZWQgaW4gYSBnZW5lcmljIEJJRVIgaGVhZGVy IG9yIHNwcmVhZCBvdmVyIHRoZSBNUExTIGhlYWRlciAoZS5nLiwgVFRMIGFuZCBDb1MpIGFuZCB0 aGUgTVBMUy1kZXBlbmRhbnQgIEJJRVIgaGVhZGVyIGFuZCBldmVuIGJlIGluZGlyZWN0bHkgZmln dXJlZCBvdXQgdGhyb3VnaCB0aGUgTVBMUyBsb29rdXAuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9o dQ0KDQpGcm9tOiBYdXhpYW9odQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAxMywgMjAxNSAxMDo0 NiBBTQ0KVG86ICdBbGlhIEF0bGFzJw0KQ2M6IEFudG9uaSBQcnp5Z2llbmRhOyBiaWVyQGlldGYu b3JnDQpTdWJqZWN0OiBSRTogW0JpZXJdIHByb3Bvc2VkIEJJRVIgY2hhcnRlcg0KDQpIaSBBbGlh LA0KDQpJIGZ1bGx5IGFncmVlIHdpdGggeW91ciBwb2ludCB0aGF0IHJlcXVpcmVtZW50cyBhcmUg ZXNzZW50aWFsIGZvciBkZXNpZ25pbmcgYW55IG5ldyBkYXRhLXBsYW5lIGVuY2Fwc3VsYXRpb24u IEkgd29uZGVyIHdoZXRoZXIgdGhlIEJJRVIgV0cgd291bGQgc3RpbGwgd29yayBvdXQgYSBkYXRh LXBsYW5lIHJlcXVpcmVtZW50IGRvY3VtZW50IGdpdmVuIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1l bnQgaGFzIGFscmVhZHkgYmVlbiB0aGVyZS4gSU1ITywgVGhvc2UgZmllbGRzL2VsZW1lbnRzIG9u IHRoZSBkYXRhLXBsYW5lIHdoaWNoIGFyZSBlc3NlbnRpYWwgZm9yIHRoZSBCSUVSIGZvcndhcmRp bmcgY291bGQgYmUgc3BlY2lmaWVkIGVpdGhlciBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50 IG9yIGluIHRoZSBkYXRhLXBsYW5lIHJlcXVpcmVtZW50IGRvY3VtZW50LiBBcyBzdWNoLCBib3Ro IHRoZSBnZW5lcmljIEJJRVIgZW5jYXBzdWxhdGlvbiBzY2hlbWUgYW5kIHRoZSBNUExTLWRlcGVu ZGFudCBCSUVSIGVuY2Fwc3VsYXRpb24gc2NoZW1lIHNob3VsZCByZXNwZWN0IHRob3NlIGRhdGEt cGxhbmUgcmVxdWlyZW1lbnRzLiBJbiBvdGhlciB3b3JkcywgdGhvc2UgbmVjZXNzYXJ5IGZpZWxk cy9lbGVtZW50cyBmb3IgQklFUiBmb3J3YXJkaW5nIGNvdWxkIGJlIGNvbXBsZXRlbHkgY29udGFp bmVkIGluIGEgZ2VuZXJpYyBCSUVSIGhlYWRlciBvciBzcHJlYWQgb3ZlciB0aGUgTVBMUyBoZWFk ZXIgYW5kIHRoZSBNUExTLWRlcGVuZGFudCAgQklFUiBoZWFkZXIuIFdpdGggdGhvc2UgZGF0YS1w bGFuZSByZXF1aXJlbWVudHMgd2hpY2ggYXJlIGluZGVwZW5kZW50IGZyb20gYW55IHNwZWNpZmlj IGVuY2Fwc3VsYXRpb24gc2NoZW1lLCB3ZSBjb3VsZCBmdXJ0aGVyIGV2YWx1YXRlIHRoZSBwcm9z IGFuZCBjb25zIG9mIGVhY2ggc2NoZW1lLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KRnJv bTogQWxpYSBBdGxhcyBbbWFpbHRvOmFrYXRsYXNAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXks IEZlYnJ1YXJ5IDEyLCAyMDE1IDEwOjUxIFBNDQpUbzogWHV4aWFvaHUNCkNjOiBBbnRvbmkgUHJ6 eWdpZW5kYTsgYmllckBpZXRmLm9yZzxtYWlsdG86YmllckBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbQmllcl0gcHJvcG9zZWQgQklFUiBjaGFydGVyDQoNClhpYW9odSwNCg0KSSBjZXJ0YWlubHkg dW5kZXJzdGFuZCB0aGF0IHlvdSBhcmUgdmVyeSBpbnRlcmVzdGVkIGluIHdvcmtpbmcgb24gYSBn ZW5lcmljIGVuY2Fwc3VsYXRpb24gZm9yIEJJRVIuICBJIGRvIHRoaW5rIHRoaXMgbWF5IGJlIHVz ZWZ1bCB3b3JrLiAgVGhlIE1QTFMgZW5jYXBzdWxhdGlvbiB3b3JrIGlzIGZ1cnRoZXIgYWxvbmcg YW5kIGhhcyBzaWduaWZpY2FudCBiZW5lZml0cyBpbiB0ZXJtcyBvZiBub3QgbmVlZGluZyB0byBy ZXZpc2l0IGEgbnVtYmVyIG9mIGlzc3VlcyB0aGF0IE1QTFMgYWxyZWFkeSBoYW5kbGVzLg0KDQpZ b3VyIHByb3Bvc2VkIGNoYW5nZXMgYmFzaWNhbGx5IGVsaW1pbmF0ZSBhbnkgaW5kaWNhdGlvbiBv ZiB3aGF0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgaW4gdGhlIGdlbmVyaWMgZW5jYXBzdWxhdGlv biwgd2l0aG91dCBhbnkgcmVhc29uaW5nLCBhbmQgcHVzaGVzIGZvciBpdCB0byBiZSBjb25zaWRl cmVkIGFzIGFuIGVxdWFsIGZvY3VzIHdpdGggdGhlIE1QTFMgZW5jYXBzdWxhdGlvbi4gIEkgYW0g YWxyZWFkeSBjb25jZXJuZWQgdGhhdCB0aGVyZSdzIGEgbG90IG9mIHdvcmsgZm9yIGJpZXIgdG8g Z2V0IHRocm91Z2guDQoNCkRvIHlvdSB0aGluayB0aGF0IHRoZSByZXF1aXJlbWVudHMgb24gdGhl IGdlbmVyaWMgZW5jYXBzdWxhdGlvbiBuZWVkIHJlZmluaW5nIGFuZCB3aHk/DQoNClJlZ2FyZHMs DQpBbGlhDQoNCg0KT24gVGh1LCBGZWIgMTIsIDIwMTUgYXQgNDoyOCBBTSwgWHV4aWFvaHUgPHh1 eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCkhp IFRvbnksDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXNwb25zZS4gSWYgdGhlIFdHIGlzIGlu dGVuZGVkIHRvIHdvcmsgb24gYm90aCBNUExTLWJhc2VkIGFuZCBub24tTVBMUy1iYXNlZCBCSUVS IGVuY2Fwc3VsYXRpb24gc2NoZW1lcyBjb25jdXJyZW50bHksIEkgd291bGQgc3VnZ2VzdCBtYWtp bmcgdGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gdGhlIEJJRVIgZW5jYXBzdWxhdGlvbiByZWxhdGVk IHRleHQ6DQoNCk9MRDoNCiAgIDIpIEJJRVIgZW5jYXBzdWxhdGlvbjogVGhlIHdvcmtpbmcgZ3Jv dXAgc2hvdWxkIGFzc3VtZSB0aGF0IHRoZQ0KICAgdGVjaG5vbG9neSB3aWxsIG5lZWQgdG8gYmUg ZW1iZWRkZWQgaW4gdGhlIGRhdGEgcGxhbmUgYW5kIG9wZXJhdGUNCiAgIGF0IHRoZSBoaWdoZXN0 IHBhY2tldCBsaW5lIHNwZWVkcy4gIFRoZSBXRyB3aWxsIHB1Ymxpc2ggYSBkb2N1bWVudA0KICAg ZGVmaW5pbmcgYW4gTVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9uIGJhc2VkIHVwb24NCiAgIGRyYWZ0 LXdpam5hbmRzLW1wbHMtYmllci1lbmNhcHN1bGF0aW9uLTAyLiBEdWUgdG8gdGhlIGNyaXRpY2Fs IG5lZWQNCiAgIHRvIGhhdmUgYSBoaWdoLXF1YWxpdHkgYW5kIHN0YWJsZSBSRkMgZm9yIGEgbmV3 IGRhdGEtcGxhbmUNCiAgIGVuY2Fwc3VsYXRpb24sIHRoZSBNUExTLWJhc2VkIGVuY2Fwc3VsYXRp b24gZHJhZnQgc2hhbGwgd2FpdCBhZnRlcg0KICAgV0dMQyBhbmQgbm90IHByb2dyZXNzIHRvIElF VEYgTGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d28NCiAgIGluZGVwZW5kZW50IGludGVyb3Bl cmFibGUgaW1wbGVtZW50YXRpb25zLg0KDQogICBBcyBhIHNlY29uZGFyeSBmb2N1cywgdGhlIFdH IG1heSBhbHNvIHdvcmsgb24gb25lIG5vbi1NUExTDQogICBkYXRhLXBsYW5lIGVuY2Fwc3VsYXRp b24uICBUaGlzIGRyYWZ0IGFsc28gc2hhbGwgd2FpdCBhZnRlciBXR0xDDQogICBhbmQgbm90IHBy b2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d28gaW5kZXBlbmRlbnQN CiAgIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLiAgVGhpcyBkcmFmdCBtdXN0IGZvY3Vz IG9uIGFuZA0KICAgaW5jbHVkZSB0aGUgZm9sbG93aW5nIGRldGFpbHM6DQoNCiAgICAgICBhKSBX aGF0IGlzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBlbmNhcHN1bGF0aW9uIGFuZCBmb3Igd2hp Y2gNCiAgICAgICB1c2UtY2FzZXMgaXMgdGhpcyBlbmNhcHN1bGF0aW9uIHJlcXVpcmVkPw0KDQog ICAgICAgYikgRG9lcyB0aGlzIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24gaW1wbHkgYW55IGNoYW5n ZXMgdG8gdGhlDQogICAgICAgTVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9uPw0KDQogICAgICAgYykg V2hhdCBkZXNpZ24gY2hvaWNlcyBoYXZlIGJlZW4gbWFkZSBmb3IgdGhlIGVuY2Fwc3VsYXRpb24N CiAgICAgICB0eXBlIGFuZCB0aGUgaW5jbHVkZWQgZmllbGRzLg0KDQogICAgICAgZCkgVGhlIHBy b3Bvc2VkIGVuY2Fwc3VsYXRpb24gd2l0aCBjb25zaWRlcmF0aW9ucyBnaXZlbiB0byBhdA0KICAg ICAgIGxlYXN0IE9BTSwgQ2xhc3Mgb2YgU2VydmljZSwgc2VjdXJpdHksIGZyYWdtZW50YXRpb24s IFRUTC4NCk5FVzoNCjIpIEJJRVIgZW5jYXBzdWxhdGlvbjogVGhlIHdvcmtpbmcgZ3JvdXAgc2hv dWxkIGFzc3VtZSB0aGF0IHRoZQ0KICAgdGVjaG5vbG9neSB3aWxsIG5lZWQgdG8gYmUgZW1iZWRk ZWQgaW4gdGhlIGRhdGEgcGxhbmUgYW5kIG9wZXJhdGUNCiAgIGF0IHRoZSBoaWdoZXN0IHBhY2tl dCBsaW5lIHNwZWVkcy4gIFRoZSBXRyB3aWxsIHdvcmsgb24gYm90aCBNUExTLWJhc2VkDQphbmQg bm9uLU1QTFMtYmFzZWQgQklFUiBlbmNhcHN1bGF0aW9uIHNjaGVtZXMgYW5kIHB1Ymxpc2ggdGhl IGNvcnJlc3BvbmRpbmcgZG9jdW1lbnRzLg0KRHVlIHRvIHRoZSBjcml0aWNhbCBuZWVkIHRvIGhh dmUgYSBoaWdoLXF1YWxpdHkgYW5kIHN0YWJsZSBSRkMgZm9yIGEgbmV3IGRhdGEtcGxhbmUNCiAg IGVuY2Fwc3VsYXRpb24sIHRoZSBCSUVSIGVuY2Fwc3VsYXRpb24gZHJhZnQgc2hhbGwgd2FpdCBh ZnRlcg0KICAgV0dMQyBhbmQgbm90IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRo ZXJlIGFyZSB0d28NCiAgIGluZGVwZW5kZW50IGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25z Lg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KDQoNCg0KRnJvbTogQW50b25pIFByenlnaWVu ZGEgW21haWx0bzphbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb208bWFpbHRvOmFudG9uaS5w cnp5Z2llbmRhQGVyaWNzc29uLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTIsIDIw MTUgMjoyNyBQTQ0KVG86IFh1eGlhb2h1OyBiaWVyQGlldGYub3JnPG1haWx0bzpiaWVyQGlldGYu b3JnPg0KU3ViamVjdDogUkU6IFtCaWVyXSBwcm9wb3NlZCBCSUVSIGNoYXJ0ZXINCg0KPGhhdCB0 eXBlPeKAnXdnIGNoYWly4oCdPg0KDQpJTUhPLCB0aGUgQklFUiBsYXllciBpcyBleGFjdGx5IGEg dG90YWxseSBuZXcgTkVUV09SSyBMQVlFUg0KW1Rvbnkgc2FpZF0gWHV4aWFvaHUsIHRoYXQgYWxs IGRlcGVuZHMgaG93IElQIGNlbnRyaWMgb25lIHNlZXMgaXQuIEl0IGNhbiBiZSBjb25zaWRlcmVk IGxheWVyIDIuNSBhcyB3ZWxsIGdpdmVuIGl0IGRvZXNu4oCZdCBldmVuIGhhdmUgdG8gY2Fycnkg SVAgZnJhbWVzLg0KYW5kIHRoZXJlZm9yZSB0aGUgQklFUiBoZWFkZXIgaXMgYmV0dGVyIHRvIGJl IGRlc2lnbmVkIGFzIGEgY29tcGxldGUgbmV0d29yayBsYXllciBoZWFkZXIgZnJvbSB0aGUgYmVn aW5uaW5nLCByYXRoZXIgdGhhbiBjb3VwbGluZyBpdCB3aXRoIGFuIE1QTFMgbGFiZWwgc28gYXMg dG8gYmUgY2FwYWJsZSBvZiBhY3RpbmcgYXMgYSBjb21wbGV0ZSBuZXR3b3JrIGxheWVyIGhlYWRl ciwgd2hpY2ggaXMgc3BlY2lhbGx5IG1lYW5pbmdmdWwgaW4gdGhlIG5vbi1NUExTIG5ldHdvcmsg ZW52aXJvbm1lbnRzLiBUaGVyZWZvcmUsIGl0IHNlZW1zIG1vcmUgcmVhc29uYWJsZSB0byBhbGxv dyB0aGUgV0cgdG8gd29yayBvbiB0aGUgTVBMUy1iYXNlZCBhbmQgbm9uLU1QTFMtYmFzZWQgZW5j YXBzdWxhdGlvbiBvcHRpb25zIGNvbmN1cnJlbnRseQ0KW1Rvbnkgc2FpZF0gSSBkbyBOT1Qgc2Vl IGFueXdoZXJlIGluIHRoZSBjaGFydGVyIHRoYXQgYm90aCBDQU5OT1QgYmUgd29ya2VkIG9uIGNv bmN1cnJlbnRseS4gQWRkaXRpb25hbCB0aG91Z2h0IGhhcyBiZWVuIHB1dCBpbnRvIHNwZWNpZnlp bmcgV0hBVCBhIGdlbmVyaWMgZW5jb2RpbmcgZHJhZnQgbmVlZHMgdG8gcHJvdmlkZSBmb3IgaXQg dG8gYmUgaGlnaCBxdWFsaXR5IGFuZCBJIHRoaW5rIHRoZXJlIGlzIGVub3VnaCB3b3JrIHRvIGJl IGRvbmUgdGhlcmUuIE1QTFMgaXMgc2ltcGx5IHRoZSBtb3N0IHByYWdtYXRpYyBjaG9pY2Ugb2Yg YSBsb25nIG1hdHVyZSBMMi41IHRlY2hub2xvZ3kgdGhhdCBwcm92YWJseSBzb2x2ZXMgbWFueSBs YXJnZS1zY2FsZSBkZXBsb3ltZW50IHByb2JsZW1zLg0KDQo8L2hhdD4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJJRVIgbWFpbGluZyBsaXN0DQpC SUVSQGlldGYub3JnPG1haWx0bzpCSUVSQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9iaWVyDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830660FNKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsN Cglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnm s6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQg OTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+cy90aG9zZSBuZWNl c3NhcnkgZmllbGRzL2VsZW1lbnRzIGZvciBCSUVSIGZvcndhcmRpbmcgY291bGQgYmUgY29tcGxl dGVseSBjb250YWluZWQgaW4gYSBnZW5lcmljIEJJRVIgaGVhZGVyIG9yIHNwcmVhZCBvdmVyIHRo ZSBNUExTIGhlYWRlciBhbmQNCiB0aGUgTVBMUy1kZXBlbmRhbnQmbmJzcDsgQklFUiBoZWFkZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi8gdGhvc2UgbmVjZXNz YXJ5IGZpZWxkcy9lbGVtZW50cyBmb3IgQklFUiBmb3J3YXJkaW5nIGNvdWxkIGJlIGNvbXBsZXRl bHkgY29udGFpbmVkIGluIGEgZ2VuZXJpYyBCSUVSIGhlYWRlciBvciBzcHJlYWQgb3ZlciB0aGUg TVBMUyBoZWFkZXIgKGUuZy4sDQogVFRMIGFuZCBDb1MpIGFuZCB0aGUgTVBMUy1kZXBlbmRhbnQm bmJzcDsgQklFUiBoZWFkZXIgYW5kIGV2ZW4gYmUgaW5kaXJlY3RseSBmaWd1cmVkIG91dCB0aHJv dWdoIHRoZSBNUExTIGxvb2t1cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ WGlhb2h1PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFh1eGlhb2h1DQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAxMywgMjAxNSAxMDo0NiBBTTxicj4NCjxiPlRv OjwvYj4gJ0FsaWEgQXRsYXMnPGJyPg0KPGI+Q2M6PC9iPiBBbnRvbmkgUHJ6eWdpZW5kYTsgYmll ckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0JpZXJdIHByb3Bvc2VkIEJJRVIg Y2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbGlhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2 LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JIGZ1bGx5IGFncmVlIHdpdGggeW91ciBwb2ludCB0aGF0IHJlcXVpcmVtZW50 cyBhcmUgZXNzZW50aWFsIGZvciBkZXNpZ25pbmcgYW55IG5ldyBkYXRhLXBsYW5lIGVuY2Fwc3Vs YXRpb24uIEkgd29uZGVyIHdoZXRoZXIgdGhlIEJJRVIgV0cgd291bGQNCiBzdGlsbCB3b3JrIG91 dCBhIGRhdGEtcGxhbmUgcmVxdWlyZW1lbnQgZG9jdW1lbnQgZ2l2ZW4gdGhlIGFyY2hpdGVjdHVy ZSBkb2N1bWVudCBoYXMgYWxyZWFkeSBiZWVuIHRoZXJlLiBJTUhPLCBUaG9zZSBmaWVsZHMvZWxl bWVudHMgb24gdGhlIGRhdGEtcGxhbmUgd2hpY2ggYXJlIGVzc2VudGlhbCBmb3IgdGhlIEJJRVIg Zm9yd2FyZGluZyBjb3VsZCBiZSBzcGVjaWZpZWQgZWl0aGVyIGluIHRoZSBhcmNoaXRlY3R1cmUg ZG9jdW1lbnQgb3IgaW4NCiB0aGUgZGF0YS1wbGFuZSByZXF1aXJlbWVudCBkb2N1bWVudC4gQXMg c3VjaCwgYm90aCB0aGUgZ2VuZXJpYyBCSUVSIGVuY2Fwc3VsYXRpb24gc2NoZW1lIGFuZCB0aGUg TVBMUy1kZXBlbmRhbnQgQklFUiBlbmNhcHN1bGF0aW9uIHNjaGVtZSBzaG91bGQgcmVzcGVjdCB0 aG9zZSBkYXRhLXBsYW5lIHJlcXVpcmVtZW50cy4gSW4gb3RoZXIgd29yZHMsIHRob3NlIG5lY2Vz c2FyeSBmaWVsZHMvZWxlbWVudHMgZm9yIEJJRVIgZm9yd2FyZGluZyBjb3VsZA0KIGJlIGNvbXBs ZXRlbHkgY29udGFpbmVkIGluIGEgZ2VuZXJpYyBCSUVSIGhlYWRlciBvciBzcHJlYWQgb3ZlciB0 aGUgTVBMUyBoZWFkZXIgYW5kIHRoZSBNUExTLWRlcGVuZGFudCZuYnNwOyBCSUVSIGhlYWRlci4g V2l0aCB0aG9zZSBkYXRhLXBsYW5lIHJlcXVpcmVtZW50cyB3aGljaCBhcmUgaW5kZXBlbmRlbnQg ZnJvbSBhbnkgc3BlY2lmaWMgZW5jYXBzdWxhdGlvbiBzY2hlbWUsIHdlIGNvdWxkIGZ1cnRoZXIg ZXZhbHVhdGUgdGhlIHByb3MgYW5kIGNvbnMNCiBvZiBlYWNoIHNjaGVtZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WGlhb2h1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IEFsaWEgQXRsYXMgWzxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+bWFpbHRvOmFr YXRsYXNAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVh cnkgMTIsIDIwMTUgMTA6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IFh1eGlhb2h1PGJyPg0KPGI+Q2M6 PC9iPiBBbnRvbmkgUHJ6eWdpZW5kYTsgPGEgaHJlZj0ibWFpbHRvOmJpZXJAaWV0Zi5vcmciPmJp ZXJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQmllcl0gcHJvcG9zZWQg QklFUiBjaGFydGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlhp YW9odSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGNlcnRhaW5s eSB1bmRlcnN0YW5kIHRoYXQgeW91IGFyZSB2ZXJ5IGludGVyZXN0ZWQgaW4gd29ya2luZyBvbiBh IGdlbmVyaWMgZW5jYXBzdWxhdGlvbiBmb3IgQklFUi4mbmJzcDsgSSBkbyB0aGluayB0aGlzIG1h eSBiZSB1c2VmdWwgd29yay4mbmJzcDsgVGhlIE1QTFMgZW5jYXBzdWxhdGlvbiB3b3JrIGlzIGZ1 cnRoZXIgYWxvbmcgYW5kIGhhcyBzaWduaWZpY2FudCBiZW5lZml0cyBpbiB0ZXJtcw0KIG9mIG5v dCBuZWVkaW5nIHRvIHJldmlzaXQgYSBudW1iZXIgb2YgaXNzdWVzIHRoYXQgTVBMUyBhbHJlYWR5 IGhhbmRsZXMuICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+WW91ciBwcm9wb3NlZCBjaGFuZ2VzIGJhc2ljYWxseSBlbGltaW5hdGUg YW55IGluZGljYXRpb24gb2Ygd2hhdCBuZWVkcyB0byBiZSBjb25zaWRlcmVkIGluIHRoZSBnZW5l cmljIGVuY2Fwc3VsYXRpb24sIHdpdGhvdXQgYW55IHJlYXNvbmluZywgYW5kIHB1c2hlcyBmb3Ig aXQgdG8gYmUgY29uc2lkZXJlZCBhcyBhbiBlcXVhbCBmb2N1cyB3aXRoIHRoZSBNUExTIGVuY2Fw c3VsYXRpb24uJm5ic3A7DQogSSBhbSBhbHJlYWR5IGNvbmNlcm5lZCB0aGF0IHRoZXJlJ3MgYSBs b3Qgb2Ygd29yayBmb3IgYmllciB0byBnZXQgdGhyb3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRvIHlvdSB0aGluayB0aGF0IHRoZSByZXF1aXJl bWVudHMgb24gdGhlIGdlbmVyaWMgZW5jYXBzdWxhdGlvbiBuZWVkIHJlZmluaW5nIGFuZCB3aHk/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbGlhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFRodSwgRmViIDEyLCAy MDE1IGF0IDQ6MjggQU0sIFh1eGlhb2h1ICZsdDs8YSBocmVmPSJtYWlsdG86eHV4aWFvaHVAaHVh d2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnh1eGlhb2h1QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBUb255LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBh IGxvdCBmb3IgeW91ciByZXNwb25zZS4gSWYgdGhlIFdHIGlzIGludGVuZGVkIHRvIHdvcmsgb24g Ym90aCBNUExTLWJhc2VkIGFuZA0KIG5vbi1NUExTLWJhc2VkIEJJRVIgZW5jYXBzdWxhdGlvbiBz Y2hlbWVzIGNvbmN1cnJlbnRseSwgSSB3b3VsZCBzdWdnZXN0IG1ha2luZyB0aGUgZm9sbG93aW5n IGNoYW5nZSB0byB0aGUgQklFUiBlbmNhcHN1bGF0aW9uIHJlbGF0ZWQgdGV4dDo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PTEQ6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsgJm5ic3A7MikgQklFUiBlbmNhcHN1bGF0aW9uOiBUaGUgd29ya2luZyBn cm91cCBzaG91bGQgYXNzdW1lIHRoYXQgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO3RlY2hub2xv Z3kgd2lsbCBuZWVkIHRvIGJlIGVtYmVkZGVkIGluIHRoZSBkYXRhIHBsYW5lIGFuZCBvcGVyYXRl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2F0IHRoZSBoaWdoZXN0IHBhY2tldCBsaW5lIHNwZWVkcy4m bmJzcDsgVGhlIFdHIHdpbGwgcHVibGlzaCBhIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNw O2RlZmluaW5nIGFuIE1QTFMtYmFzZWQgZW5jYXBzdWxhdGlvbiBiYXNlZCB1cG9uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7ICZuYnNwO2RyYWZ0LXdpam5hbmRzLW1wbHMtYmllci1lbmNhcHN1bGF0aW9uLTAyLiBE dWUgdG8gdGhlIGNyaXRpY2FsIG5lZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7dG8gaGF2ZSBhIGhp Z2gtcXVhbGl0eSBhbmQgc3RhYmxlIFJGQyBmb3IgYSBuZXcgZGF0YS1wbGFuZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyAmbmJzcDtlbmNhcHN1bGF0aW9uLCB0aGUgTVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9uIGRy YWZ0IHNoYWxsIHdhaXQgYWZ0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7V0dMQyBhbmQgbm90IHBy b2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d288bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsgJm5ic3A7aW5kZXBlbmRlbnQgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO0FzIGEgc2Vjb25kYXJ5IGZvY3VzLCB0aGUg V0cgbWF5IGFsc28gd29yayBvbiBvbmUgbm9uLU1QTFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ZGF0 YS1wbGFuZSBlbmNhcHN1bGF0aW9uLiZuYnNwOyBUaGlzIGRyYWZ0IGFsc28gc2hhbGwgd2FpdCBh ZnRlciBXR0xDPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2FuZCBub3QgcHJvZ3Jlc3MgdG8gSUVURiBM YXN0IENhbGwgdW50aWwgdGhlcmUgYXJlIHR3byBpbmRlcGVuZGVudDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAm bmJzcDtpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4mbmJzcDsgVGhpcyBkcmFmdCBtdXN0 IGZvY3VzIG9uIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtpbmNsdWRlIHRoZSBmb2xsb3dpbmcg ZGV0YWlsczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDthKSBXaGF0IGlzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBlbmNhcHN1bGF0aW9uIGFuZCBm b3Igd2hpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1c2UtY2FzZXMgaXMg dGhpcyBlbmNhcHN1bGF0aW9uIHJlcXVpcmVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2IpIERvZXMgdGhpcyBwcm9wb3NlZCBlbmNhcHN1bGF0aW9u IGltcGx5IGFueSBjaGFuZ2VzIHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO01QTFMtYmFzZWQgZW5jYXBzdWxhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjKSBXaGF0IGRlc2lnbiBjaG9pY2VzIGhhdmUgYmVlbiBt YWRlIGZvciB0aGUgZW5jYXBzdWxhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3R5cGUgYW5kIHRoZSBpbmNsdWRlZCBmaWVsZHMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZCkgVGhlIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24g d2l0aCBjb25zaWRlcmF0aW9ucyBnaXZlbiB0byBhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2xlYXN0IE9BTSwgQ2xhc3Mgb2YgU2VydmljZSwgc2VjdXJpdHksIGZyYWdtZW50 YXRpb24sIFRUTC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ TkVXOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50OjI0LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1V UyI+MikgQklFUiBlbmNhcHN1bGF0aW9uOiBUaGUgd29ya2luZyBncm91cCBzaG91bGQgYXNzdW1l IHRoYXQgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO3RlY2hub2xvZ3kgd2lsbCBuZWVkIHRvIGJl IGVtYmVkZGVkIGluIHRoZSBkYXRhIHBsYW5lIGFuZCBvcGVyYXRlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZu YnNwO2F0IHRoZSBoaWdoZXN0IHBhY2tldCBsaW5lIHNwZWVkcy4mbmJzcDsgVGhlIFdHIHdpbGwg d29yayBvbiBib3RoIE1QTFMtYmFzZWQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDozMC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPmFu ZCBub24tTVBMUy1iYXNlZCBCSUVSIGVuY2Fwc3VsYXRpb24gc2NoZW1lcyBhbmQgcHVibGlzaCB0 aGUgY29ycmVzcG9uZGluZyBkb2N1bWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50OjI0LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+ RHVlIHRvIHRoZSBjcml0aWNhbCBuZWVkIHRvIGhhdmUgYSBoaWdoLXF1YWxpdHkgYW5kIHN0YWJs ZSBSRkMgZm9yIGEgbmV3IGRhdGEtcGxhbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ZW5jYXBzdWxh dGlvbiwgdGhlIEJJRVIgZW5jYXBzdWxhdGlvbiBkcmFmdCBzaGFsbCB3YWl0IGFmdGVyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7ICZuYnNwO1dHTEMgYW5kIG5vdCBwcm9ncmVzcyB0byBJRVRGIExhc3QgQ2FsbCB1 bnRpbCB0aGVyZSBhcmUgdHdvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2luZGVwZW5kZW50IGludGVy b3BlcmFibGUgaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QgcmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj5YaWFvaHU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW50b25pDQogUHJ6eWdpZW5kYSBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzphbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5h bnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBGZWJydWFyeSAxMiwgMjAxNSAyOjI3IFBNPGJyPg0KPGI+VG86PC9iPiBYdXhpYW9o dTsgPGEgaHJlZj0ibWFpbHRvOmJpZXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5iaWVyQGll dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0JpZXJdIHByb3Bvc2VkIEJJRVIg Y2hhcnRlcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZsdDtoYXQgdHlwZT3igJ13ZyBjaGFpcuKAnSZndDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JTUhPLCB0aGUgQklFUiBsYXllciBpcyBleGFjdGx5IGEgdG90 YWxseSBuZXcgTkVUV09SSyBMQVlFUg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1Rvbnkgc2FpZF0N Cjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+WHV4aWFvaHUsDQo8L3NwYW4+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj50aGF0IGFsbCBkZXBlbmRzIGhv dyBJUCBjZW50cmljIG9uZSBzZWVzIGl0LiBJdCBjYW4gYmUgY29uc2lkZXJlZCBsYXllciAyLjUg YXMgd2VsbCBnaXZlbiBpdCBkb2VzbuKAmXQgZXZlbiBoYXZlIHRvIGNhcnJ5IElQIGZyYW1lcy4N Cjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YW5kIHRoZXJlZm9yZSB0aGUgQklFUiBoZWFkZXIgaXMg YmV0dGVyIHRvIGJlIGRlc2lnbmVkIGFzIGEgY29tcGxldGUgbmV0d29yayBsYXllciBoZWFkZXIN CiBmcm9tIHRoZSBiZWdpbm5pbmcsIHJhdGhlciB0aGFuIGNvdXBsaW5nIGl0IHdpdGggYW4gTVBM UyBsYWJlbCBzbyBhcyB0byBiZSBjYXBhYmxlIG9mIGFjdGluZyBhcyBhIGNvbXBsZXRlIG5ldHdv cmsgbGF5ZXIgaGVhZGVyLCB3aGljaCBpcyBzcGVjaWFsbHkgbWVhbmluZ2Z1bCBpbiB0aGUgbm9u LU1QTFMgbmV0d29yayBlbnZpcm9ubWVudHMuIFRoZXJlZm9yZSwgaXQgc2VlbXMgbW9yZSByZWFz b25hYmxlIHRvIGFsbG93IHRoZSBXRyB0byB3b3JrDQogb24gdGhlIE1QTFMtYmFzZWQgYW5kIG5v bi1NUExTLWJhc2VkIGVuY2Fwc3VsYXRpb24gb3B0aW9ucyBjb25jdXJyZW50bHkgPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+W1Rvbnkgc2FpZF0gSSBkbyBOT1Qgc2VlIGFueXdoZXJlIGluIHRoZSBjaGFy dGVyIHRoYXQgYm90aCBDQU5OT1QgYmUgd29ya2VkIG9uDQogY29uY3VycmVudGx5LiBBZGRpdGlv bmFsIHRob3VnaHQgaGFzIGJlZW4gcHV0IGludG8gc3BlY2lmeWluZyBXSEFUIGEgZ2VuZXJpYyBl bmNvZGluZyBkcmFmdCBuZWVkcyB0byBwcm92aWRlIGZvciBpdCB0byBiZSBoaWdoIHF1YWxpdHkg YW5kIEkgdGhpbmsgdGhlcmUgaXMgZW5vdWdoIHdvcmsgdG8gYmUgZG9uZSB0aGVyZS4gTVBMUyBp cyBzaW1wbHkgdGhlIG1vc3QgcHJhZ21hdGljIGNob2ljZSBvZiBhIGxvbmcgbWF0dXJlIEwyLjUg dGVjaG5vbG9neQ0KIHRoYXQgcHJvdmFibHkgc29sdmVzIG1hbnkgbGFyZ2Utc2NhbGUgZGVwbG95 bWVudCBwcm9ibGVtcy4gPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7L2hhdCZndDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCkJJRVIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0 Zi5vcmciPkJJRVJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9iaWVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830660FNKGEML512MBSchi_-- From nobody Thu Feb 12 19:14:36 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063961A0378 for ; Thu, 12 Feb 2015 19:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KH36c1bM5qa9 for ; Thu, 12 Feb 2015 19:14:29 -0800 (PST) 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 E91491A0252 for ; Thu, 12 Feb 2015 19:14:27 -0800 (PST) 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 BSO78465; Fri, 13 Feb 2015 03:14:26 +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; Fri, 13 Feb 2015 03:14:25 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 13 Feb 2015 11:14:18 +0800 From: Xuxiaohu To: Alia Atlas Thread-Topic: [Bier] proposed BIER charter Thread-Index: AQHQRjuRN28IQ+IMmk2R5cKY4QcqFpzsTHDQ//+6rgCAALQbEP//2L8AgAFDPqD//4f1gAARBEjQ Date: Fri, 13 Feb 2015 03:14:17 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830662B@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306031@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F1824AFFB@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083061CE@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083065D1@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.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830662BNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bier@ietf.org" , Antoni Przygienda Subject: Re: [Bier] proposed BIER charter 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, 13 Feb 2015 03:14:33 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830662BNKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxpYSwNCg0KSSBsaWtlIHlvdXIgYXBwcm9hY2ggb2Ygc3RlZXJpbmcgYXdheSBmcm9tIHBy b2Nlc3Mtc3R5bGUgZG9jdW1lbnRzLiBJdOKAmXMgYW4gZWZmaWNpZW50IHdheS4gSGVuY2UsIHRo ZSBnZW5lcmljIEJJRVIgZW5jYXBzdWxhdGlvbiBkb2MgYW5kIHRoZSBNUExTLWRlcGVuZGFudCBC SUVSIGVuY2Fwc3VsYXRpb24gZG9jIG5lZWQgdG8gZm9sbG93IHRoZSBhcmNoaXRlY3R1cmUgZG9j LiBUaGF04oCZcyB0byBzYXksIGFueSBmdW5jdGlvbmFsaXR5IHJlcXVpcmVkIGZvciB0aGUgQklF UiBmb3J3YXJkaW5nIGFzIHNwZWNpZmllZCBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvYyBzaG91bGQg YmUgc3VwcG9ydGVkIGJ5IGVhY2ggZW5jYXBzdWxhdGlvbiBzY2hlbWUuDQoNCkJlc3QgcmVnYXJk cywNClhpYW9odQ0KDQpGcm9tOiBBbGlhIEF0bGFzIFttYWlsdG86YWthdGxhc0BnbWFpbC5jb21d DQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDEzLCAyMDE1IDEwOjU4IEFNDQpUbzogWHV4aWFvaHUN CkNjOiBBbnRvbmkgUHJ6eWdpZW5kYTsgYmllckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtCaWVy XSBwcm9wb3NlZCBCSUVSIGNoYXJ0ZXINCg0KSGkgWGlhb2h1LA0KDQpUaGUgZGV0YWlscyBvZiB3 aGF0IGZpZWxkcyBhbmQgc2l6ZXMgbmVlZCB0byBiZSBpbiB0aGUgZW5jYXBzdWxhdGlvbiBzaG91 bGQgYmUgY2FwdHVyZWQgaW4gdGhlIGFyY2hpdGVjdHVyZSBkcmFmdC4NCkluIHRoZSBwcm9wb3Nl ZCBjaGFydGVyLCB0aGF0IGlzIHNwZWNpZmllZCBpbjoNCiIgICAxKSBCSUVSIGFyY2hpdGVjdHVy ZTogVGhlIFdHIHdpbGwgcHVibGlzaCBhbiBhcmNoaXRlY3R1cmUsIGJhc2VkDQogICB1cG9uIGRy YWZ0LXdpam5hbmRzLWJpZXItYXJjaGl0ZWN0dXJlLTA0LiAgSXQgd2lsbCBpbmNsdWRlIHRoZQ0K ICAgbm9ybWF0aXZlIGFsZ29yaXRobSBmb3IgaG93IEJJRVIgcGFja2V0IGZvcndhcmRpbmcgaXMg ZG9uZS4gIEl0DQogICB3aWxsIHNwZWNpZnkgdGhlIGluZm9ybWF0aW9uIHRoYXQgaXMgcmVxdWly ZWQgYnkgYSBCSUVSIGhlYWRlciB0bw0KICAgc3VwcG9ydCBCSUVSIGZvcndhcmRpbmcuIg0KDQpB cyB5b3UgY2FuIHByb2JhYmx5IHRlbGwgZnJvbSB0aGlzIGNoYXJ0ZXIsIEkgYW0gcmVhbGx5IHN0 ZWVyaW5nIGF3YXkgZnJvbSBwcm9jZXNzLXN0eWxlIGRvY3VtZW50cyBpbiBmYXZvcg0Kb2YgY29t YmluaW5nIHJlcXVpcmVtZW50cyB3aXRoIHRoZSBhc3NvY2lhdGVkIHNvbHV0aW9ucywgaW4gdGVy bXMgb2YgbWluaW1pemluZyB0aGUgbnVtYmVyIG9mIHVzZS1jYXNlIGRyYWZ0cywNCmFuZCBzbyBv bi4gIEF0IHRoZSBlbmQgb2YgdGhlIGRheSwgd2UgbmVlZCBSRkNzIHRoYXQgZGVzY3JpYmUgZnVu Y3Rpb25hbGl0eSB0aGF0IGNhbiBiZSBpbXBsZW1lbnRlZCwgZGVwbG95ZWQsDQphbmQgYmUgaW50 ZXJvcGVyYWJsZS4NCg0KUmVnYXJkcywNCkFsaWENCg0KDQpPbiBUaHUsIEZlYiAxMiwgMjAxNSBh dCA5OjQ2IFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVA aHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgQWxpYSwNCg0KSSBmdWxseSBhZ3JlZSB3aXRoIHlvdXIg cG9pbnQgdGhhdCByZXF1aXJlbWVudHMgYXJlIGVzc2VudGlhbCBmb3IgZGVzaWduaW5nIGFueSBu ZXcgZGF0YS1wbGFuZSBlbmNhcHN1bGF0aW9uLiBJIHdvbmRlciB3aGV0aGVyIHRoZSBCSUVSIFdH IHdvdWxkIHN0aWxsIHdvcmsgb3V0IGEgZGF0YS1wbGFuZSByZXF1aXJlbWVudCBkb2N1bWVudCBn aXZlbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGhhcyBhbHJlYWR5IGJlZW4gdGhlcmUuIElN SE8sIFRob3NlIGZpZWxkcy9lbGVtZW50cyBvbiB0aGUgZGF0YS1wbGFuZSB3aGljaCBhcmUgZXNz ZW50aWFsIGZvciB0aGUgQklFUiBmb3J3YXJkaW5nIGNvdWxkIGJlIHNwZWNpZmllZCBlaXRoZXIg aW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBvciBpbiB0aGUgZGF0YS1wbGFuZSByZXF1aXJl bWVudCBkb2N1bWVudC4gQXMgc3VjaCwgYm90aCB0aGUgZ2VuZXJpYyBCSUVSIGVuY2Fwc3VsYXRp b24gc2NoZW1lIGFuZCB0aGUgTVBMUy1kZXBlbmRhbnQgQklFUiBlbmNhcHN1bGF0aW9uIHNjaGVt ZSBzaG91bGQgcmVzcGVjdCB0aG9zZSBkYXRhLXBsYW5lIHJlcXVpcmVtZW50cy4gSW4gb3RoZXIg d29yZHMsIHRob3NlIG5lY2Vzc2FyeSBmaWVsZHMvZWxlbWVudHMgZm9yIEJJRVIgZm9yd2FyZGlu ZyBjb3VsZCBiZSBjb21wbGV0ZWx5IGNvbnRhaW5lZCBpbiBhIGdlbmVyaWMgQklFUiBoZWFkZXIg b3Igc3ByZWFkIG92ZXIgdGhlIE1QTFMgaGVhZGVyIGFuZCB0aGUgTVBMUy1kZXBlbmRhbnQgIEJJ RVIgaGVhZGVyLiBXaXRoIHRob3NlIGRhdGEtcGxhbmUgcmVxdWlyZW1lbnRzIHdoaWNoIGFyZSBp bmRlcGVuZGVudCBmcm9tIGFueSBzcGVjaWZpYyBlbmNhcHN1bGF0aW9uIHNjaGVtZSwgd2UgY291 bGQgZnVydGhlciBldmFsdWF0ZSB0aGUgcHJvcyBhbmQgY29ucyBvZiBlYWNoIHNjaGVtZS4NCg0K QmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCkZyb206IEFsaWEgQXRsYXMgW21haWx0bzpha2F0bGFz QGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5jb20+XQ0KU2VudDogVGh1cnNkYXksIEZl YnJ1YXJ5IDEyLCAyMDE1IDEwOjUxIFBNDQpUbzogWHV4aWFvaHUNCkNjOiBBbnRvbmkgUHJ6eWdp ZW5kYTsgYmllckBpZXRmLm9yZzxtYWlsdG86YmllckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb Qmllcl0gcHJvcG9zZWQgQklFUiBjaGFydGVyDQoNClhpYW9odSwNCg0KSSBjZXJ0YWlubHkgdW5k ZXJzdGFuZCB0aGF0IHlvdSBhcmUgdmVyeSBpbnRlcmVzdGVkIGluIHdvcmtpbmcgb24gYSBnZW5l cmljIGVuY2Fwc3VsYXRpb24gZm9yIEJJRVIuICBJIGRvIHRoaW5rIHRoaXMgbWF5IGJlIHVzZWZ1 bCB3b3JrLiAgVGhlIE1QTFMgZW5jYXBzdWxhdGlvbiB3b3JrIGlzIGZ1cnRoZXIgYWxvbmcgYW5k IGhhcyBzaWduaWZpY2FudCBiZW5lZml0cyBpbiB0ZXJtcyBvZiBub3QgbmVlZGluZyB0byByZXZp c2l0IGEgbnVtYmVyIG9mIGlzc3VlcyB0aGF0IE1QTFMgYWxyZWFkeSBoYW5kbGVzLg0KDQpZb3Vy IHByb3Bvc2VkIGNoYW5nZXMgYmFzaWNhbGx5IGVsaW1pbmF0ZSBhbnkgaW5kaWNhdGlvbiBvZiB3 aGF0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgaW4gdGhlIGdlbmVyaWMgZW5jYXBzdWxhdGlvbiwg d2l0aG91dCBhbnkgcmVhc29uaW5nLCBhbmQgcHVzaGVzIGZvciBpdCB0byBiZSBjb25zaWRlcmVk IGFzIGFuIGVxdWFsIGZvY3VzIHdpdGggdGhlIE1QTFMgZW5jYXBzdWxhdGlvbi4gIEkgYW0gYWxy ZWFkeSBjb25jZXJuZWQgdGhhdCB0aGVyZSdzIGEgbG90IG9mIHdvcmsgZm9yIGJpZXIgdG8gZ2V0 IHRocm91Z2guDQoNCkRvIHlvdSB0aGluayB0aGF0IHRoZSByZXF1aXJlbWVudHMgb24gdGhlIGdl bmVyaWMgZW5jYXBzdWxhdGlvbiBuZWVkIHJlZmluaW5nIGFuZCB3aHk/DQoNClJlZ2FyZHMsDQpB bGlhDQoNCg0KT24gVGh1LCBGZWIgMTIsIDIwMTUgYXQgNDoyOCBBTSwgWHV4aWFvaHUgPHh1eGlh b2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIFRv bnksDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXNwb25zZS4gSWYgdGhlIFdHIGlzIGludGVu ZGVkIHRvIHdvcmsgb24gYm90aCBNUExTLWJhc2VkIGFuZCBub24tTVBMUy1iYXNlZCBCSUVSIGVu Y2Fwc3VsYXRpb24gc2NoZW1lcyBjb25jdXJyZW50bHksIEkgd291bGQgc3VnZ2VzdCBtYWtpbmcg dGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gdGhlIEJJRVIgZW5jYXBzdWxhdGlvbiByZWxhdGVkIHRl eHQ6DQoNCk9MRDoNCiAgIDIpIEJJRVIgZW5jYXBzdWxhdGlvbjogVGhlIHdvcmtpbmcgZ3JvdXAg c2hvdWxkIGFzc3VtZSB0aGF0IHRoZQ0KICAgdGVjaG5vbG9neSB3aWxsIG5lZWQgdG8gYmUgZW1i ZWRkZWQgaW4gdGhlIGRhdGEgcGxhbmUgYW5kIG9wZXJhdGUNCiAgIGF0IHRoZSBoaWdoZXN0IHBh Y2tldCBsaW5lIHNwZWVkcy4gIFRoZSBXRyB3aWxsIHB1Ymxpc2ggYSBkb2N1bWVudA0KICAgZGVm aW5pbmcgYW4gTVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9uIGJhc2VkIHVwb24NCiAgIGRyYWZ0LXdp am5hbmRzLW1wbHMtYmllci1lbmNhcHN1bGF0aW9uLTAyLiBEdWUgdG8gdGhlIGNyaXRpY2FsIG5l ZWQNCiAgIHRvIGhhdmUgYSBoaWdoLXF1YWxpdHkgYW5kIHN0YWJsZSBSRkMgZm9yIGEgbmV3IGRh dGEtcGxhbmUNCiAgIGVuY2Fwc3VsYXRpb24sIHRoZSBNUExTLWJhc2VkIGVuY2Fwc3VsYXRpb24g ZHJhZnQgc2hhbGwgd2FpdCBhZnRlcg0KICAgV0dMQyBhbmQgbm90IHByb2dyZXNzIHRvIElFVEYg TGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d28NCiAgIGluZGVwZW5kZW50IGludGVyb3BlcmFi bGUgaW1wbGVtZW50YXRpb25zLg0KDQogICBBcyBhIHNlY29uZGFyeSBmb2N1cywgdGhlIFdHIG1h eSBhbHNvIHdvcmsgb24gb25lIG5vbi1NUExTDQogICBkYXRhLXBsYW5lIGVuY2Fwc3VsYXRpb24u ICBUaGlzIGRyYWZ0IGFsc28gc2hhbGwgd2FpdCBhZnRlciBXR0xDDQogICBhbmQgbm90IHByb2dy ZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJlIGFyZSB0d28gaW5kZXBlbmRlbnQNCiAg IGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLiAgVGhpcyBkcmFmdCBtdXN0IGZvY3VzIG9u IGFuZA0KICAgaW5jbHVkZSB0aGUgZm9sbG93aW5nIGRldGFpbHM6DQoNCiAgICAgICBhKSBXaGF0 IGlzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBlbmNhcHN1bGF0aW9uIGFuZCBmb3Igd2hpY2gN CiAgICAgICB1c2UtY2FzZXMgaXMgdGhpcyBlbmNhcHN1bGF0aW9uIHJlcXVpcmVkPw0KDQogICAg ICAgYikgRG9lcyB0aGlzIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24gaW1wbHkgYW55IGNoYW5nZXMg dG8gdGhlDQogICAgICAgTVBMUy1iYXNlZCBlbmNhcHN1bGF0aW9uPw0KDQogICAgICAgYykgV2hh dCBkZXNpZ24gY2hvaWNlcyBoYXZlIGJlZW4gbWFkZSBmb3IgdGhlIGVuY2Fwc3VsYXRpb24NCiAg ICAgICB0eXBlIGFuZCB0aGUgaW5jbHVkZWQgZmllbGRzLg0KDQogICAgICAgZCkgVGhlIHByb3Bv c2VkIGVuY2Fwc3VsYXRpb24gd2l0aCBjb25zaWRlcmF0aW9ucyBnaXZlbiB0byBhdA0KICAgICAg IGxlYXN0IE9BTSwgQ2xhc3Mgb2YgU2VydmljZSwgc2VjdXJpdHksIGZyYWdtZW50YXRpb24sIFRU TC4NCk5FVzoNCjIpIEJJRVIgZW5jYXBzdWxhdGlvbjogVGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxk IGFzc3VtZSB0aGF0IHRoZQ0KICAgdGVjaG5vbG9neSB3aWxsIG5lZWQgdG8gYmUgZW1iZWRkZWQg aW4gdGhlIGRhdGEgcGxhbmUgYW5kIG9wZXJhdGUNCiAgIGF0IHRoZSBoaWdoZXN0IHBhY2tldCBs aW5lIHNwZWVkcy4gIFRoZSBXRyB3aWxsIHdvcmsgb24gYm90aCBNUExTLWJhc2VkDQphbmQgbm9u LU1QTFMtYmFzZWQgQklFUiBlbmNhcHN1bGF0aW9uIHNjaGVtZXMgYW5kIHB1Ymxpc2ggdGhlIGNv cnJlc3BvbmRpbmcgZG9jdW1lbnRzLg0KRHVlIHRvIHRoZSBjcml0aWNhbCBuZWVkIHRvIGhhdmUg YSBoaWdoLXF1YWxpdHkgYW5kIHN0YWJsZSBSRkMgZm9yIGEgbmV3IGRhdGEtcGxhbmUNCiAgIGVu Y2Fwc3VsYXRpb24sIHRoZSBCSUVSIGVuY2Fwc3VsYXRpb24gZHJhZnQgc2hhbGwgd2FpdCBhZnRl cg0KICAgV0dMQyBhbmQgbm90IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJl IGFyZSB0d28NCiAgIGluZGVwZW5kZW50IGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLg0K DQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KDQoNCg0KRnJvbTogQW50b25pIFByenlnaWVuZGEg W21haWx0bzphbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb208bWFpbHRvOmFudG9uaS5wcnp5 Z2llbmRhQGVyaWNzc29uLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTIsIDIwMTUg MjoyNyBQTQ0KVG86IFh1eGlhb2h1OyBiaWVyQGlldGYub3JnPG1haWx0bzpiaWVyQGlldGYub3Jn Pg0KU3ViamVjdDogUkU6IFtCaWVyXSBwcm9wb3NlZCBCSUVSIGNoYXJ0ZXINCg0KPGhhdCB0eXBl PeKAnXdnIGNoYWly4oCdPg0KDQpJTUhPLCB0aGUgQklFUiBsYXllciBpcyBleGFjdGx5IGEgdG90 YWxseSBuZXcgTkVUV09SSyBMQVlFUg0KW1Rvbnkgc2FpZF0gWHV4aWFvaHUsIHRoYXQgYWxsIGRl cGVuZHMgaG93IElQIGNlbnRyaWMgb25lIHNlZXMgaXQuIEl0IGNhbiBiZSBjb25zaWRlcmVkIGxh eWVyIDIuNSBhcyB3ZWxsIGdpdmVuIGl0IGRvZXNu4oCZdCBldmVuIGhhdmUgdG8gY2FycnkgSVAg ZnJhbWVzLg0KYW5kIHRoZXJlZm9yZSB0aGUgQklFUiBoZWFkZXIgaXMgYmV0dGVyIHRvIGJlIGRl c2lnbmVkIGFzIGEgY29tcGxldGUgbmV0d29yayBsYXllciBoZWFkZXIgZnJvbSB0aGUgYmVnaW5u aW5nLCByYXRoZXIgdGhhbiBjb3VwbGluZyBpdCB3aXRoIGFuIE1QTFMgbGFiZWwgc28gYXMgdG8g YmUgY2FwYWJsZSBvZiBhY3RpbmcgYXMgYSBjb21wbGV0ZSBuZXR3b3JrIGxheWVyIGhlYWRlciwg d2hpY2ggaXMgc3BlY2lhbGx5IG1lYW5pbmdmdWwgaW4gdGhlIG5vbi1NUExTIG5ldHdvcmsgZW52 aXJvbm1lbnRzLiBUaGVyZWZvcmUsIGl0IHNlZW1zIG1vcmUgcmVhc29uYWJsZSB0byBhbGxvdyB0 aGUgV0cgdG8gd29yayBvbiB0aGUgTVBMUy1iYXNlZCBhbmQgbm9uLU1QTFMtYmFzZWQgZW5jYXBz dWxhdGlvbiBvcHRpb25zIGNvbmN1cnJlbnRseQ0KW1Rvbnkgc2FpZF0gSSBkbyBOT1Qgc2VlIGFu eXdoZXJlIGluIHRoZSBjaGFydGVyIHRoYXQgYm90aCBDQU5OT1QgYmUgd29ya2VkIG9uIGNvbmN1 cnJlbnRseS4gQWRkaXRpb25hbCB0aG91Z2h0IGhhcyBiZWVuIHB1dCBpbnRvIHNwZWNpZnlpbmcg V0hBVCBhIGdlbmVyaWMgZW5jb2RpbmcgZHJhZnQgbmVlZHMgdG8gcHJvdmlkZSBmb3IgaXQgdG8g YmUgaGlnaCBxdWFsaXR5IGFuZCBJIHRoaW5rIHRoZXJlIGlzIGVub3VnaCB3b3JrIHRvIGJlIGRv bmUgdGhlcmUuIE1QTFMgaXMgc2ltcGx5IHRoZSBtb3N0IHByYWdtYXRpYyBjaG9pY2Ugb2YgYSBs b25nIG1hdHVyZSBMMi41IHRlY2hub2xvZ3kgdGhhdCBwcm92YWJseSBzb2x2ZXMgbWFueSBsYXJn ZS1zY2FsZSBkZXBsb3ltZW50IHByb2JsZW1zLg0KDQo8L2hhdD4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJJRVIgbWFpbGluZyBsaXN0DQpCSUVS QGlldGYub3JnPG1haWx0bzpCSUVSQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9iaWVyDQoNCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830662BNKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsN Cglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnm s6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQWxpYSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBsaWtlIHlvdXIgYXBwcm9hY2ggb2Ygc3RlZXJpbmcg YXdheSBmcm9tIHByb2Nlc3Mtc3R5bGUgZG9jdW1lbnRzLiBJdOKAmXMgYW4gZWZmaWNpZW50IHdh eS4gSGVuY2UsIHRoZSBnZW5lcmljIEJJRVIgZW5jYXBzdWxhdGlvbiBkb2MgYW5kIHRoZSBNUExT LWRlcGVuZGFudA0KIEJJRVIgZW5jYXBzdWxhdGlvbiBkb2MgbmVlZCB0byBmb2xsb3cgdGhlIGFy Y2hpdGVjdHVyZSBkb2MuIFRoYXTigJlzIHRvIHNheSwgYW55IGZ1bmN0aW9uYWxpdHkgcmVxdWly ZWQgZm9yIHRoZSBCSUVSIGZvcndhcmRpbmcgYXMgc3BlY2lmaWVkIGluIHRoZSBhcmNoaXRlY3R1 cmUgZG9jIHNob3VsZCBiZSBzdXBwb3J0ZWQgYnkgZWFjaCBlbmNhcHN1bGF0aW9uIHNjaGVtZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WGlhb2h1PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IEFsaWEgQXRsYXMgW21haWx0bzpha2F0bGFzQGdtYWlsLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDEzLCAyMDE1IDEwOjU4IEFNPGJyPg0KPGI+ VG86PC9iPiBYdXhpYW9odTxicj4NCjxiPkNjOjwvYj4gQW50b25pIFByenlnaWVuZGE7IGJpZXJA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtCaWVyXSBwcm9wb3NlZCBCSUVSIGNo YXJ0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgWGlhb2h1 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBkZXRhaWxzIG9m IHdoYXQgZmllbGRzIGFuZCBzaXplcyBuZWVkIHRvIGJlIGluIHRoZSBlbmNhcHN1bGF0aW9uIHNo b3VsZCBiZSBjYXB0dXJlZCBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5JbiB0aGUgcHJvcG9zZWQgY2hhcnRlciwgdGhhdCBpcyBzcGVjaWZpZWQgaW46PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90OyAmbmJzcDsgMSkgQklFUiBhcmNoaXRlY3R1cmU6IFRo ZSBXRyB3aWxsIHB1Ymxpc2ggYW4gYXJjaGl0ZWN0dXJlLCBiYXNlZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsgJm5ic3A7dXBvbiBkcmFmdC13aWpuYW5kcy1iaWVyLWFyY2hpdGVjdHVyZS0w NC4mbmJzcDsgSXQgd2lsbCBpbmNsdWRlIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsg Jm5ic3A7bm9ybWF0aXZlIGFsZ29yaXRobSBmb3IgaG93IEJJRVIgcGFja2V0IGZvcndhcmRpbmcg aXMgZG9uZS4mbmJzcDsgSXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO3dpbGwg c3BlY2lmeSB0aGUgaW5mb3JtYXRpb24gdGhhdCBpcyByZXF1aXJlZCBieSBhIEJJRVIgaGVhZGVy IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtzdXBwb3J0IEJJRVIgZm9yd2Fy ZGluZy4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkFzIHlvdSBjYW4gcHJvYmFibHkgdGVsbCBmcm9tIHRoaXMgY2hhcnRlciwgSSBhbSByZWFs bHkgc3RlZXJpbmcgYXdheSBmcm9tIHByb2Nlc3Mtc3R5bGUgZG9jdW1lbnRzIGluIGZhdm9yPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPm9mIGNvbWJpbmluZyByZXF1aXJlbWVudHMgd2l0aCB0aGUgYXNz b2NpYXRlZCBzb2x1dGlvbnMsIGluIHRlcm1zIG9mIG1pbmltaXppbmcgdGhlIG51bWJlciBvZiB1 c2UtY2FzZSBkcmFmdHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFuZCBzbyBvbi4mbmJzcDsgQXQg dGhlIGVuZCBvZiB0aGUgZGF5LCB3ZSBuZWVkIFJGQ3MgdGhhdCBkZXNjcmliZSBmdW5jdGlvbmFs aXR5IHRoYXQgY2FuIGJlIGltcGxlbWVudGVkLCBkZXBsb3llZCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+YW5kIGJlIGludGVyb3BlcmFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbGlhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+T24gVGh1LCBGZWIgMTIsIDIwMTUgYXQgOTo0NiBQTSwgWHV4aWFvaHUg Jmx0OzxhIGhyZWY9Im1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEFsaWEsPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnQgdGhh dCByZXF1aXJlbWVudHMgYXJlIGVzc2VudGlhbCBmb3IgZGVzaWduaW5nIGFueSBuZXcNCiBkYXRh LXBsYW5lIGVuY2Fwc3VsYXRpb24uIEkgd29uZGVyIHdoZXRoZXIgdGhlIEJJRVIgV0cgd291bGQg c3RpbGwgd29yayBvdXQgYSBkYXRhLXBsYW5lIHJlcXVpcmVtZW50IGRvY3VtZW50IGdpdmVuIHRo ZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaGFzIGFscmVhZHkgYmVlbiB0aGVyZS4gSU1ITywgVGhv c2UgZmllbGRzL2VsZW1lbnRzIG9uIHRoZSBkYXRhLXBsYW5lIHdoaWNoIGFyZSBlc3NlbnRpYWwg Zm9yIHRoZSBCSUVSIGZvcndhcmRpbmcNCiBjb3VsZCBiZSBzcGVjaWZpZWQgZWl0aGVyIGluIHRo ZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgb3IgaW4gdGhlIGRhdGEtcGxhbmUgcmVxdWlyZW1lbnQg ZG9jdW1lbnQuIEFzIHN1Y2gsIGJvdGggdGhlIGdlbmVyaWMgQklFUiBlbmNhcHN1bGF0aW9uIHNj aGVtZSBhbmQgdGhlIE1QTFMtZGVwZW5kYW50IEJJRVIgZW5jYXBzdWxhdGlvbiBzY2hlbWUgc2hv dWxkIHJlc3BlY3QgdGhvc2UgZGF0YS1wbGFuZSByZXF1aXJlbWVudHMuIEluIG90aGVyIHdvcmRz LA0KIHRob3NlIG5lY2Vzc2FyeSBmaWVsZHMvZWxlbWVudHMgZm9yIEJJRVIgZm9yd2FyZGluZyBj b3VsZCBiZSBjb21wbGV0ZWx5IGNvbnRhaW5lZCBpbiBhIGdlbmVyaWMgQklFUiBoZWFkZXIgb3Ig c3ByZWFkIG92ZXIgdGhlIE1QTFMgaGVhZGVyIGFuZCB0aGUgTVBMUy1kZXBlbmRhbnQmbmJzcDsg QklFUiBoZWFkZXIuIFdpdGggdGhvc2UgZGF0YS1wbGFuZSByZXF1aXJlbWVudHMgd2hpY2ggYXJl IGluZGVwZW5kZW50IGZyb20gYW55IHNwZWNpZmljIGVuY2Fwc3VsYXRpb24NCiBzY2hlbWUsIHdl IGNvdWxkIGZ1cnRoZXIgZXZhbHVhdGUgdGhlIHByb3MgYW5kIGNvbnMgb2YgZWFjaCBzY2hlbWUu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlhpYW9odTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFsaWENCiBBdGxhcyBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFr YXRsYXNAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVh cnkgMTIsIDIwMTUgMTA6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IFh1eGlhb2h1PGJyPg0KPGI+Q2M6 PC9iPiBBbnRvbmkgUHJ6eWdpZW5kYTsgPGEgaHJlZj0ibWFpbHRvOmJpZXJAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5iaWVyQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0JpZXJdIHByb3Bvc2VkIEJJRVIgY2hhcnRlcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5YaWFvaHUsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBj ZXJ0YWlubHkgdW5kZXJzdGFuZCB0aGF0IHlvdSBhcmUgdmVyeSBpbnRlcmVzdGVkIGluIHdvcmtp bmcgb24gYSBnZW5lcmljIGVuY2Fwc3VsYXRpb24gZm9yIEJJRVIuJm5ic3A7IEkgZG8gdGhpbmsg dGhpcyBtYXkgYmUgdXNlZnVsIHdvcmsuJm5ic3A7IFRoZSBNUExTIGVuY2Fwc3VsYXRpb24NCiB3 b3JrIGlzIGZ1cnRoZXIgYWxvbmcgYW5kIGhhcyBzaWduaWZpY2FudCBiZW5lZml0cyBpbiB0ZXJt cyBvZiBub3QgbmVlZGluZyB0byByZXZpc2l0IGEgbnVtYmVyIG9mIGlzc3VlcyB0aGF0IE1QTFMg YWxyZWFkeSBoYW5kbGVzLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3VyIHByb3Bvc2VkIGNoYW5nZXMgYmFzaWNhbGx5IGVsaW1p bmF0ZSBhbnkgaW5kaWNhdGlvbiBvZiB3aGF0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgaW4gdGhl IGdlbmVyaWMgZW5jYXBzdWxhdGlvbiwgd2l0aG91dCBhbnkgcmVhc29uaW5nLCBhbmQgcHVzaGVz IGZvciBpdA0KIHRvIGJlIGNvbnNpZGVyZWQgYXMgYW4gZXF1YWwgZm9jdXMgd2l0aCB0aGUgTVBM UyBlbmNhcHN1bGF0aW9uLiZuYnNwOyBJIGFtIGFscmVhZHkgY29uY2VybmVkIHRoYXQgdGhlcmUn cyBhIGxvdCBvZiB3b3JrIGZvciBiaWVyIHRvIGdldCB0aHJvdWdoLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkRvIHlvdSB0aGluayB0aGF0IHRo ZSByZXF1aXJlbWVudHMgb24gdGhlIGdlbmVyaWMgZW5jYXBzdWxhdGlvbiBuZWVkIHJlZmluaW5n IGFuZCB3aHk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5BbGlhPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPk9uIFRodSwgRmViIDEyLCAyMDE1IGF0IDQ6MjggQU0sIFh1eGlhb2h1ICZsdDs8YSBocmVm PSJtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnh1eGlhb2h1QGh1 YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBUb255LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXNwb25zZS4gSWYgdGhlIFdHIGlz IGludGVuZGVkIHRvIHdvcmsgb24gYm90aCBNUExTLWJhc2VkIGFuZA0KIG5vbi1NUExTLWJhc2Vk IEJJRVIgZW5jYXBzdWxhdGlvbiBzY2hlbWVzIGNvbmN1cnJlbnRseSwgSSB3b3VsZCBzdWdnZXN0 IG1ha2luZyB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byB0aGUgQklFUiBlbmNhcHN1bGF0aW9uIHJl bGF0ZWQgdGV4dDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PTEQ6PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7MikgQklFUiBlbmNhcHN1 bGF0aW9uOiBUaGUgd29ya2luZyBncm91cCBzaG91bGQgYXNzdW1lIHRoYXQgdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7ICZuYnNwO3RlY2hub2xvZ3kgd2lsbCBuZWVkIHRvIGJlIGVtYmVkZGVkIGluIHRoZSBk YXRhIHBsYW5lIGFuZCBvcGVyYXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2F0IHRoZSBoaWdoZXN0 IHBhY2tldCBsaW5lIHNwZWVkcy4mbmJzcDsgVGhlIFdHIHdpbGwgcHVibGlzaCBhIGRvY3VtZW50 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2RlZmluaW5nIGFuIE1QTFMtYmFzZWQgZW5jYXBzdWxhdGlv biBiYXNlZCB1cG9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2RyYWZ0LXdpam5hbmRzLW1wbHMtYmll ci1lbmNhcHN1bGF0aW9uLTAyLiBEdWUgdG8gdGhlIGNyaXRpY2FsIG5lZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsgJm5ic3A7dG8gaGF2ZSBhIGhpZ2gtcXVhbGl0eSBhbmQgc3RhYmxlIFJGQyBmb3IgYSBuZXcg ZGF0YS1wbGFuZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtlbmNhcHN1bGF0aW9uLCB0aGUgTVBMUy1i YXNlZCBlbmNhcHN1bGF0aW9uIGRyYWZ0IHNoYWxsIHdhaXQgYWZ0ZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsg Jm5ic3A7V0dMQyBhbmQgbm90IHByb2dyZXNzIHRvIElFVEYgTGFzdCBDYWxsIHVudGlsIHRoZXJl IGFyZSB0d288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7aW5kZXBlbmRlbnQgaW50ZXJvcGVyYWJsZSBp bXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO0FzIGEg c2Vjb25kYXJ5IGZvY3VzLCB0aGUgV0cgbWF5IGFsc28gd29yayBvbiBvbmUgbm9uLU1QTFM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsgJm5ic3A7ZGF0YS1wbGFuZSBlbmNhcHN1bGF0aW9uLiZuYnNwOyBUaGlzIGRy YWZ0IGFsc28gc2hhbGwgd2FpdCBhZnRlciBXR0xDPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2FuZCBu b3QgcHJvZ3Jlc3MgdG8gSUVURiBMYXN0IENhbGwgdW50aWwgdGhlcmUgYXJlIHR3byBpbmRlcGVu ZGVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4m bmJzcDsgVGhpcyBkcmFmdCBtdXN0IGZvY3VzIG9uIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtp bmNsdWRlIHRoZSBmb2xsb3dpbmcgZGV0YWlsczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthKSBXaGF0IGlzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRo ZSBlbmNhcHN1bGF0aW9uIGFuZCBmb3Igd2hpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt1c2UtY2FzZXMgaXMgdGhpcyBlbmNhcHN1bGF0aW9uIHJlcXVpcmVkPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2IpIERvZXMgdGhpcyBw cm9wb3NlZCBlbmNhcHN1bGF0aW9uIGltcGx5IGFueSBjaGFuZ2VzIHRvIHRoZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01QTFMtYmFzZWQgZW5jYXBzdWxhdGlvbj88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjKSBXaGF0IGRlc2ln biBjaG9pY2VzIGhhdmUgYmVlbiBtYWRlIGZvciB0aGUgZW5jYXBzdWxhdGlvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgYW5kIHRoZSBpbmNsdWRlZCBmaWVsZHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZCkgVGhlIHBy b3Bvc2VkIGVuY2Fwc3VsYXRpb24gd2l0aCBjb25zaWRlcmF0aW9ucyBnaXZlbiB0byBhdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xlYXN0IE9BTSwgQ2xhc3Mgb2YgU2Vydmlj ZSwgc2VjdXJpdHksIGZyYWdtZW50YXRpb24sIFRUTC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+TkVXOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50OjI0LjBw dCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+MikgQklFUiBlbmNhcHN1bGF0aW9uOiBUaGUgd29ya2lu ZyBncm91cCBzaG91bGQgYXNzdW1lIHRoYXQgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO3RlY2hu b2xvZ3kgd2lsbCBuZWVkIHRvIGJlIGVtYmVkZGVkIGluIHRoZSBkYXRhIHBsYW5lIGFuZCBvcGVy YXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2F0IHRoZSBoaWdoZXN0IHBhY2tldCBsaW5lIHNwZWVk cy4mbmJzcDsgVGhlIFdHIHdpbGwgd29yayBvbiBib3RoIE1QTFMtYmFzZWQNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDozMC4wcHQiPg0K PHNwYW4gbGFuZz0iRU4tVVMiPmFuZCBub24tTVBMUy1iYXNlZCBCSUVSIGVuY2Fwc3VsYXRpb24g c2NoZW1lcyBhbmQgcHVibGlzaCB0aGUgY29ycmVzcG9uZGluZyBkb2N1bWVudHMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50OjI0LjBwdCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyI+RHVlIHRvIHRoZSBjcml0aWNhbCBuZWVkIHRvIGhhdmUgYSBo aWdoLXF1YWxpdHkgYW5kIHN0YWJsZSBSRkMgZm9yIGEgbmV3IGRhdGEtcGxhbmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsgJm5ic3A7ZW5jYXBzdWxhdGlvbiwgdGhlIEJJRVIgZW5jYXBzdWxhdGlvbiBkcmFmdCBz aGFsbCB3YWl0IGFmdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO1dHTEMgYW5kIG5vdCBwcm9ncmVz cyB0byBJRVRGIExhc3QgQ2FsbCB1bnRpbCB0aGVyZSBhcmUgdHdvPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZu YnNwO2luZGVwZW5kZW50IGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5YaWFvaHU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW50b25pDQogUHJ6eWdp ZW5kYSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5j b20iIHRhcmdldD0iX2JsYW5rIj5hbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb208L2E+XQ0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxMiwgMjAxNSAyOjI3IFBNPGJy Pg0KPGI+VG86PC9iPiBYdXhpYW9odTsgPGEgaHJlZj0ibWFpbHRvOmJpZXJAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5iaWVyQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog W0JpZXJdIHByb3Bvc2VkIEJJRVIgY2hhcnRlcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtoYXQgdHlwZT3igJ13ZyBjaGFpcuKA nSZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JTUhPLCB0aGUgQklFUiBs YXllciBpcyBleGFjdGx5IGEgdG90YWxseSBuZXcgTkVUV09SSyBMQVlFUg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W1Rvbnkgc2FpZF0NCjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WHV4aWFvaHUsDQo8L3NwYW4+PGI+ PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij50aGF0IGFsbCBkZXBlbmRzIGhvdyBJUCBjZW50cmljIG9uZSBzZWVzIGl0LiBJdCBjYW4gYmUg Y29uc2lkZXJlZCBsYXllciAyLjUgYXMgd2VsbCBnaXZlbiBpdCBkb2VzbuKAmXQgZXZlbiBoYXZl IHRvIGNhcnJ5IElQIGZyYW1lcy4NCjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YW5kIHRoZXJlZm9y ZSB0aGUgQklFUiBoZWFkZXIgaXMgYmV0dGVyIHRvIGJlIGRlc2lnbmVkIGFzIGEgY29tcGxldGUg bmV0d29yayBsYXllciBoZWFkZXINCiBmcm9tIHRoZSBiZWdpbm5pbmcsIHJhdGhlciB0aGFuIGNv dXBsaW5nIGl0IHdpdGggYW4gTVBMUyBsYWJlbCBzbyBhcyB0byBiZSBjYXBhYmxlIG9mIGFjdGlu ZyBhcyBhIGNvbXBsZXRlIG5ldHdvcmsgbGF5ZXIgaGVhZGVyLCB3aGljaCBpcyBzcGVjaWFsbHkg bWVhbmluZ2Z1bCBpbiB0aGUgbm9uLU1QTFMgbmV0d29yayBlbnZpcm9ubWVudHMuIFRoZXJlZm9y ZSwgaXQgc2VlbXMgbW9yZSByZWFzb25hYmxlIHRvIGFsbG93IHRoZSBXRyB0byB3b3JrDQogb24g dGhlIE1QTFMtYmFzZWQgYW5kIG5vbi1NUExTLWJhc2VkIGVuY2Fwc3VsYXRpb24gb3B0aW9ucyBj b25jdXJyZW50bHkgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1Rvbnkgc2FpZF0gSSBkbyBOT1Qgc2Vl IGFueXdoZXJlIGluIHRoZSBjaGFydGVyIHRoYXQgYm90aCBDQU5OT1QgYmUgd29ya2VkIG9uDQog Y29uY3VycmVudGx5LiBBZGRpdGlvbmFsIHRob3VnaHQgaGFzIGJlZW4gcHV0IGludG8gc3BlY2lm eWluZyBXSEFUIGEgZ2VuZXJpYyBlbmNvZGluZyBkcmFmdCBuZWVkcyB0byBwcm92aWRlIGZvciBp dCB0byBiZSBoaWdoIHF1YWxpdHkgYW5kIEkgdGhpbmsgdGhlcmUgaXMgZW5vdWdoIHdvcmsgdG8g YmUgZG9uZSB0aGVyZS4gTVBMUyBpcyBzaW1wbHkgdGhlIG1vc3QgcHJhZ21hdGljIGNob2ljZSBv ZiBhIGxvbmcgbWF0dXJlIEwyLjUgdGVjaG5vbG9neQ0KIHRoYXQgcHJvdmFibHkgc29sdmVzIG1h bnkgbGFyZ2Utc2NhbGUgZGVwbG95bWVudCBwcm9ibGVtcy4gPC9zcGFuPjwvaT48L2I+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbHQ7L2hhdCZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkJJ RVIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5CSUVSQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYmllciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmllcjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830662BNKGEML512MBSchi_-- From nobody Fri Feb 13 17:39:03 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A9A1A1A99; Fri, 13 Feb 2015 17:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3iSwhpo_wgm; Fri, 13 Feb 2015 17:38:31 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D581A1A86; Fri, 13 Feb 2015 17:38:30 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-57-54de53545654 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 96.B6.03307.4535ED45; Fri, 13 Feb 2015 20:41:09 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Fri, 13 Feb 2015 20:38:28 -0500 From: Antoni Przygienda To: "stbryant@cisco.com" , Alia Atlas , "bier@ietf.org" Thread-Topic: [Bier] proposed BIER charter Thread-Index: AQHQRjuQYyjkJ/or3U2D1i8/o65ffZztW3uAgAIBvMA= Date: Sat, 14 Feb 2015 01:38:27 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1824CFA5@eusaamb103.ericsson.se> References: <54DCAE4F.8050903@cisco.com> In-Reply-To: <54DCAE4F.8050903@cisco.com> 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_2E4BB27CAB87BF43B4207C0E55860F1824CFA5eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXRPiG5o8L0Qg7+HmSx+9Nxgtvj08BKz xd+fWxktls7Yw2Qx489EZotzT+cwOrB5TPm9kdVj56y77B5Llvxk8lixeSVjAEsUl01Kak5m WWqRvl0CV0bTTLeCW1OZK3791m5gbH7M1MXIwSEhYCKx96xIFyMnkCkmceHeerYuRi4OIYEj jBJvJuxjAUkICSxnlLh6RxzEZhOwkLj87SkziC0iUCDx5+QfdhCbWSBXYt6pa2C2sICmRO+l PWwQNVoSG++vZ4KwrSROHD8NVsMioCrxe187O8gNvALeEhtv1kOsypd41ruUEcTmBBqz68hr VhCbEei276fWMEGsEpe49WQ+E8TNAhJL9pxnhrBFJV4+/scKYStK7OufDnUa0Mx/N8Be4RUQ lDg58wnLBEbRWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FyFFanFqW m25ksIkRGI3HJNh0dzDueWl5iFGAg1GJh7fA4G6IEGtiWXFl7iFGaQ4WJXHeRQ8OhggJpCeW pGanphakFsUXleakFh9iZOLglGpg5CjmrJknuSbk1VFmbcsX3DbbJla9q9Bes5pDZsvSP8YF KwNuKsaePvpzq+nsjVcPRrOGT2CW8tCa3u77YFOUidiCD7rPBKSONBlPm7fu/M9/J/y3C0pd TWlsFfTPOiBTuTm9fznTXbegvyLBVytZ9qf3/69y5Mw1v7K2qPiqxWEzJk0pBa1UJZbijERD Leai4kQA8/hHgqcCAAA= Archived-At: Cc: Adrian Farrel , "iesg@ietf.org" , Alvaro Retana Subject: Re: [Bier] proposed BIER charter 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, 14 Feb 2015 01:38:39 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F1824CFA5eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, I concur with Alia that a new data plane concept like this one is = a thing seldom introduced and frail with surprising risks (IPv6 =3D ~15 yea= rs from idea to reasonable scale of deployment ? MPLS =3D ~ 10 years ? ;-) IMO, it is far less risky to give this thing a vibrant WG where people know= that they have to push for serious implementations (and prove them viable = before standards track with resulting huge investment in silicon by many co= mpanies will be taken) rather than rush it without adequate experience and = end up with a massive egg on our collective faces. The path to standards i= s fair (FYI, it was initially much stricter) and clearly spelled out me thi= nks. I'm waiting for people getting excited by the fame attached to a first= Linux kernel implementation going @ 1GB bitrate (I'm too smart to talk abo= ut packet size or bitstring lengths here ;-) Pen-ultimately, I would like to see precise use-cases for the low link-spee= ds and edge to consider this further. A 'may be useful' does not justify ma= jor surgery on charter IMO. Ultimately, early vendor support & strong customer response in the market p= lace is the best pressure point for IETF to move such work into Standards T= rack lest they end up looking like Johnie-come-laties. We ain't there yet. --- tony From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, February 12, 2015 5:45 AM To: Alia Atlas; bier@ietf.org Cc: Adrian Farrel; iesg@ietf.org; Alvaro Retana Subject: Re: [Bier] proposed BIER charter Alia I think that you are crossing far too many bridges before you get to them in terms of you expectation of where BIER will be deployed and how it will be implemented. The charter should not include such specific assumptions, particularly given the fast moving changes that are happening in our industry especially in the area of packet forwarding design. I have not seen such assumptions in other charters and I don't think that they have a place in this one. In terms of choice of document stream (experimental vs PS), that is a decision that can be taken at the time of publication when more information will be available in terms of potential market take-up, expected/actual deployment scenarios, breadth of implementation and implementation experience. Whilst this technology may be deployed in the Internet core, it my also be deployed at the edge where a much lower threshold is applicable. I fear that by introducing these caveats the IETF is entrenching the perception that it slows technology down rather than embracing and encouraging innovation. I would therefore suggest removing the text on implementation styles and document stream constraints. - Stewart On 11/02/2015 20:44, Alia Atlas wrote: I have been working on getting a charter together for BIER with the intent = of pushing for it to be chartered before the Dallas IETF. This has not yet= gone through IESG review and it may have some aspects updated. Please send comments here. The charter can be found at http://datatracker.ietf.org/doc/charter-ietf-bi= er/ and is included below as well. WG Chairs: Greg Shepherd > Tony Przygienda > In conventional IP multicast forwarding, the packets of a given multicast "flow" are forwarded along a tree that has been constructed for the specific purpose of carrying that flow. This requires transit nodes to maintain state on a per-flow basis, and requires the transit nodes to participate in multicast-specific tree building protocols. The flow to which a packet belongs is determined by its IP source and destination address fields. BIER (Bit Index Explicit Replication) is an alternative method of multicast forwarding. It does not require any multicast-specific trees, and hence does not require any multicast-specific tree building protocols. Within a given "BIER domain", an ingress node encapsulates a multicast data packet in a "BIER header". The BIER header identifies the packet's egress nodes in that domain. Each possible egress node is represented by a a single bit within a bitstring; to send a packet to a particular set of egress nodes, the ingress node sets the bits for each of those egress nodes, and clears the other bits in the bistring. Each packet can then be forwarded along the unicast shortest path tree from the ingress node to the egress nodes. Thus there are no per-flow forwarding entries. Due to the particular sensitivity of adding new significant functionality into the data-plane at high link speeds, the BIER work will progress as Experimental. As described in item (9) below, the work may become Standards Track once there is sufficient experience with the benefits and downsides of the technology. BIER is initially chartered to do experimental work on this new multicast forwarding mechanism as follows: 1) BIER architecture: The WG will publish an architecture, based upon draft-wijnands-bier-architecture-04. It will include the normative algorithm for how BIER packet forwarding is done. It will specify the information that is required by a BIER header to support BIER forwarding. 2) BIER encapsulation: The working group should assume that the technology will need to be embedded in the data plane and operate at the highest packet line speeds. The WG will publish a document defining an MPLS-based encapsulation based upon draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need to have a high-quality and stable RFC for a new data-plane encapsulation, the MPLS-based encapsulation draft shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. As a secondary focus, the WG may also work on one non-MPLS data-plane encapsulation. This draft also shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. This draft must focus on and include the following details: a) What is the applicability of the encapsulation and for which use-cases is this encapsulation required? b) Does this proposed encapsulation imply any changes to the MPLS-based encapsulation? c) What design choices have been made for the encapsulation type and the included fields. d) The proposed encapsulation with considerations given to at least OAM, Class of Service, security, fragmentation, TTL. 3) Transition Mechanisms: The WG will describe how BIER can be partially deployed and still provide useful functionality. A minimum of the necessary mechanisms to support incremental deployment and/or managing different BIER mask-length compatibility may be defined. Each such mechanism must include an applicability statement to differentiate its necessity from other proposed mechanisms. 4) Applicability Statements: The WG will work on a document describing how BIER can be applied to multicast L3VPN and to EVPN. This draft will describe what mechanism is used to communicate the group membership between the ingress router and the egress routers, what scalability considerations may arise, and any deployment considerations. 5) Use Case: The WG may produce one use-case document that clearly articulates the potential benefits of BIER for different use-cases. This would be based upon draft-kumar-bier-use-cases-01. 6) OAM: The WG will describe how OAM will work in a BIER domain and what simplifications BIER offers for managing the multicast traffic. A strong preference will be given to extensions to existing protocols. 7) Management models: The WG may work on YANG models and, if needed, MIB modules to support common manageability. 8) IGP extensions. When a BIER domain falls within a "link state IGP"" network, the information needed to set up the BIER forwarding tables (e.g., the mapping between a given bit position and a given egress router) may be carried in the link state advertisements of the IGP. The link state advertisments may also carry other information related to forwarding (e.g., the IGP may support multiple topologies, in which case it may be necessary to advertise which topologies are to be used for BIE= R forwarding). Any necessary extensions to the IGP will be specified by the WG, in cooperation with the ISIS and OSPF WGs. 9) Deployment Experience: Once there is deployment experience, the WG will produce a document describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms. Ideally, this should also contain an analysis of the impact and benefit of the new BIER data-plane to the overall Internet architecture. This document is intended to be used to evaluate whether to recharter BIER to produce Standards Track RFCs. The BIER working group will coordinate with several different working groups and must include the relevant other working groups during working group last call on the relevant drafts. BIER will coordinate with MPLS on the MPLS-based encapsulation and associated MPLS-based OAM mechanisms. BIER will coordinate with ISIS and OSPF on extensions to flood BIER-related information. BIER will coordinate with BESS and IDR on the applicability of existing BGP-based mechanisms for providing multicast group membership information. Regards, Alia _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_2E4BB27CAB87BF43B4207C0E55860F1824CFA5eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= <hat type=3D”wg-chair”>

=  

= Stewart, I concur with Alia that a new data plan= e concept like this one is a thing seldom introduced and frail with surprising risks (IPv6 =3D ~15 years from idea to reasonable scale of= deployment ? MPLS =3D ~ 10 years ? ;-)

=  

= IMO, it is far less risky to give this thing a v= ibrant WG where people know that they have to push for serious implementations (and prove them viable before standards track with resulti= ng huge investment in silicon by many companies will be taken) rather than = rush it without adequate experience and end up with a massive egg on our co= llective faces.  The path to standards is fair (FYI, it was initially much stricter) and clearly spelled out me t= hinks. I’m waiting for people getting excited by the fame attached to= a first Linux kernel implementation going @ 1GB bitrate (I’m too sma= rt to talk about packet size or bitstring lengths here ;-)

=  

= Pen-ultimately, I would like to see precise use-= cases for the low link-speeds and edge to consider this further. A ‘may be useful’ does not justify major surgery on charter IM= O.

=  

= Ultimately, early vendor support & strong cu= stomer response in the market place is the best pressure point for IETF to move such work into Standards Track lest they end up looking like = Johnie-come-laties. We ain’t there yet.

=  

= </hat>

=  

= --- tony

=  

= From: BIER [mailto:bier-bounces@ietf.org] On= Behalf Of Stewart Bryant
Sent: Thursday, February 12,= 2015 5:45 AM
To: Alia Atlas; bier@ietf.or= g
Cc: Adrian Farrel; iesg@ietf= .org; Alvaro Retana
Subject: Re: [Bier] proposed= BIER charter

 

Alia

I think that you are crossing far too many bridges before you get to them in terms of you expectation of where BIER will be deployed and how
it will be implemented.

The charter should not include such specific assumptions, particularly
given the fast moving changes that are happening in our industry
especially in the area of packet forwarding design.

I have not seen such assumptions in other charters and I don't think
that they have a place in this one.

In terms of choice of document stream (experimental vs PS),
that is a decision that can be taken at the time of publication
when more information will be available in terms of potential
market take-up, expected/actual deployment scenarios,
breadth of implementation and implementation experience.

Whilst this technology may be deployed in the Internet core,
it my also be deployed at the edge where a much lower threshold
is applicable.

I fear that by introducing these caveats the IETF is entrenching the
perception that it slows technology down rather than embracing
and encouraging innovation.

I would therefore suggest removing the text on implementation
styles and document stream constraints.

- Stewart

On 11/02/2015 20:44, Alia Atlas wrote:

I have been working on getting a cha= rter together for BIER with the intent of pushing for it to be chartered be= fore the Dallas IETF.  This has not yet gone through IESG review and it may have some aspects updated.

 

Please send comments here.

 

and is included below as well.<= /o:p>

 

 

WG Chairs:<= /p>

  Greg Shepherd  <gjshep@gmail.com>

  Tony Przygienda <tonysietf@gmail.com>

 

 

In conventional IP multicast forward= ing, the packets of a given

multicast "flow" are forwa= rded along a tree that has been constructed

for the specific purpose of carrying= that flow.  This requires transit

nodes to maintain state on a per-flo= w basis, and requires the transit

nodes to participate in multicast-sp= ecific tree building protocols.

The flow to which a packet belongs i= s determined by its IP source and

destination address fields.

 

BIER (Bit Index Explicit Replication= ) is an alternative method of

multicast forwarding.  It does = not require any multicast-specific

trees, and hence does not require an= y multicast-specific tree building

protocols.  Within a given &quo= t;BIER domain", an ingress node encapsulates<= /p>

a multicast data packet in a "B= IER header".  The BIER header

identifies the packet's egress nodes= in that domain.  Each possible

egress node is represented by a a si= ngle bit within a bitstring; to

send a packet to a particular set of= egress nodes, the ingress node

sets the bits for each of those egre= ss nodes, and clears the other

bits in the bistring.  Each pac= ket can then be forwarded along the

unicast shortest path tree from the = ingress node to the egress nodes.

Thus there are no per-flow forwardin= g entries.

 

Due to the particular sensitivity of= adding new significant

functionality into the data-plane at= high link speeds, the BIER work

will progress as Experimental. = As described in item (9) below, the

work may become Standards Track once= there is sufficient experience

with the benefits and downsides of t= he technology.

 

BIER is initially chartered to do ex= perimental work on this new

multicast forwarding mechanism as fo= llows:

 

   1) BIER architecture: T= he WG will publish an architecture, based

   upon draft-wijnands-bie= r-architecture-04.  It will include the

   normative algorithm for= how BIER packet forwarding is done.  It

   will specify the inform= ation that is required by a BIER header to

   support BIER forwarding= .

 

   2) BIER encapsulation: = The working group should assume that the

   technology will need to= be embedded in the data plane and operate

   at the highest packet l= ine speeds.  The WG will publish a document

   defining an MPLS-based = encapsulation based upon

   draft-wijnands-mpls-bie= r-encapsulation-02. Due to the critical need

   to have a high-quality = and stable RFC for a new data-plane

   encapsulation, the MPLS= -based encapsulation draft shall wait after

   WGLC and not progress t= o IETF Last Call until there are two

   independent interoperab= le implementations.

 

   As a secondary focus, t= he WG may also work on one non-MPLS

   data-plane encapsulatio= n.  This draft also shall wait after WGLC

   and not progress to IET= F Last Call until there are two independent

   interoperable implement= ations.  This draft must focus on and

   include the following d= etails:

 

       a) What i= s the applicability of the encapsulation and for which

       use-cases= is this encapsulation required?

 

       b) Does t= his proposed encapsulation imply any changes to the

       MPLS-base= d encapsulation?

 

       c) What d= esign choices have been made for the encapsulation=

       type and = the included fields.

 

       d) The pr= oposed encapsulation with considerations given to at

       least OAM= , Class of Service, security, fragmentation, TTL.<= /p>

 

   3) Transition Mechanism= s: The WG will describe how BIER can be

   partially deployed and = still provide useful functionality.  A

   minimum of the necessar= y mechanisms to support incremental

   deployment and/or manag= ing different BIER mask-length compatibility

   may be defined.  E= ach such mechanism must include an applicability

   statement to differenti= ate its necessity from other proposed

   mechanisms.<= /span>

 

   4) Applicability Statem= ents: The WG will work on a document

   describing how BIER can= be applied to multicast L3VPN and to EVPN.

   This draft will describ= e what mechanism is used to communicate the

   group membership betwee= n the ingress router and the egress routers,

   what scalability consid= erations may arise, and any deployment

   considerations. 

 

   5) Use Case: The WG may= produce one use-case document that clearly

   articulates the potenti= al benefits of BIER for different use-cases.

   This would be based upo= n draft-kumar-bier-use-cases-01.

 

   6) OAM: The WG will des= cribe how OAM will work in a BIER domain and

   what simplifications BI= ER offers for managing the multicast

   traffic.  A strong= preference will be given to extensions to

   existing protocols.

 

   7) Management models: T= he WG may work on YANG models and, if needed,

   MIB modules to support = common manageability.

 

   8) IGP extensions. = ; When a BIER domain falls within a "link state IGP""

   network, the informatio= n needed to set up the BIER forwarding tables

   (e.g., the mapping betw= een a given bit position and a given egress

   router) may be carried = in the link state advertisements of the IGP.  The

   link state advertisment= s may also carry other information related to

   forwarding (e.g., the I= GP may support multiple topologies, in which case<= /p>

   it may be necessary to = advertise which topologies are to be used for BIER=

   forwarding).  Any = necessary extensions to the IGP will be specified by

   the WG, in cooperation = with the ISIS and OSPF WGs.

 

   9) Deployment Experienc= e: Once there is deployment experience, the

   WG will produce a docum= ent describing the benefits, problems, and

   trade-offs for using BI= ER instead of traditional multicast

   forwarding mechanisms.&= nbsp; Ideally, this should also contain an

   analysis of the impact = and benefit of the new BIER data-plane to

   the overall Internet ar= chitecture.  This document is intended to be<= /p>

   used to evaluate whethe= r to recharter BIER to produce Standards

   Track RFCs.<= /span>

 

The BIER working group will coordina= te with several different working

groups and must include the relevant= other working groups during

working group last call on the relev= ant drafts.  BIER will coordinate

with MPLS on the MPLS-based encapsul= ation and associated MPLS-based

OAM mechanisms.  BIER will coor= dinate with ISIS and OSPF on extensions

to flood BIER-related information.&n= bsp; BIER will coordinate with BESS and

IDR on the applicability of existing= BGP-based mechanisms for

providing multicast group membership= information.

 

Regards,

Alia




_______________________________________________=

BIER mailing list
BIER@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/bier




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cr=
i/index.html
 
--_000_2E4BB27CAB87BF43B4207C0E55860F1824CFA5eusaamb103ericsso_-- From nobody Fri Feb 13 23:39:00 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E08F1A1AB1; Fri, 13 Feb 2015 23:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po6JcsRBHgQ9; Fri, 13 Feb 2015 23:38:54 -0800 (PST) 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 322291A1AB0; Fri, 13 Feb 2015 23:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=703; q=dns/txt; s=iport; t=1423899535; x=1425109135; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=neR1r+JmICnCkgACtFAkot+L3wnys2IN8GXqzdIVgOE=; b=MB+m9w/t3hD6VWwouqtZZca5SMd58LHjF8YB99inIhxFJfkzKyiOJDAI v8XchkD8kQfvp04meeJT6iLAaa2mzYjV22a38Gzr/zNdwcAnRrE8/aoAc HkKJ7HNq/hjE34sPUuGzXbT7xHqt2GU9OnEiH/nkm0mSUeWLrioMgCwLI g=; X-IronPort-AV: E=Sophos;i="5.09,575,1418083200"; d="scan'208";a="345007952" 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; 14 Feb 2015 07:38:53 +0000 Received: from ams-iwijnand-8817.cisco.com (ams-iwijnand-8817.cisco.com [10.60.202.88]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1E7coeQ014904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Feb 2015 07:38:51 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: IJsbrand Wijnands In-Reply-To: Date: Sat, 14 Feb 2015 08:38:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54DCAE4F.8050903@cisco.com> <4A496052E7B7E84A9324854763C616FA233CF4DA@C111GTUHMBX56.ERF.thomson.com> To: Alia Atlas X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "bier@ietf.org" , "iesg@ietf.org" , Adrian Farrel , Alvaro Retana , Arkadiy Gulko , stbryant Subject: Re: [Bier] proposed BIER charter 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, 14 Feb 2015 07:38:56 -0000 Hi Alia, > I'm delighted to hear of your interest and that of other operators. I = did, of course, speak with you before the BoF and know of your = involvement in the drafts. Unfortunately, I haven't heard such support = expressed in the IETF by operators; obviously vendors=E2=80=99 interest = can reflect such interest indirectly. I would just like to point out that we have 4 different operators in our = contributing author section of the BIER architecture draft = (https://tools.ietf.org/html/draft-wijnands-bier-architecture-04#section-1= 0) that indicated they want to help move this work forward, you don=E2=80=99= t consider that as =E2=80=98support=E2=80=99? Thx, Ice.= From nobody Sat Feb 14 06:33:18 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40FD1A1EF9; Sat, 14 Feb 2015 06:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5aTjBVKckCM; Sat, 14 Feb 2015 06:33:13 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D71B1A1EEF; Sat, 14 Feb 2015 06:33:13 -0800 (PST) Received: by mail-yh0-f41.google.com with SMTP id 29so10640188yhl.0; Sat, 14 Feb 2015 06:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j1JBzRMyyMjOlUr3ENnxGUw3gw1tSx24QjIwezvPgPg=; b=Z+SAqP57NPhAyzwLBaxd+g/YND0tdT34sJf66/MV18dQoVHj3bXxS6YIZnF2cDCOow 5+5D/AFv7t7TawnAZOvVqNLydzgHfhund1/X7n9Sj1A3+hPg29lSWVtjvSfRrKXl0pjm CkSFQMIR3VqdGNbJxe/QIvoozP7IwZ2EBn08Xw9lMnbrC3fnbuwsr8yPnWwqVirQZuCm hOfv9wVporC8K0G3V+mUBmlWe5SmYeJtO7Vz5fmZbl2dXnXLZH79/AyXf6s3YRP2R+hg G7IN8CU/9OuY/iaGrKHafXwpFylNMyi/ZcmwXx8+thv5YqZf1NU7H8mjytjeFS5gcMEE xCWA== MIME-Version: 1.0 X-Received: by 10.236.13.100 with SMTP id a64mr11554388yha.25.1423924392529; Sat, 14 Feb 2015 06:33:12 -0800 (PST) Received: by 10.170.133.197 with HTTP; Sat, 14 Feb 2015 06:33:12 -0800 (PST) In-Reply-To: References: <54DCAE4F.8050903@cisco.com> <4A496052E7B7E84A9324854763C616FA233CF4DA@C111GTUHMBX56.ERF.thomson.com> Date: Sat, 14 Feb 2015 09:33:12 -0500 Message-ID: From: Alia Atlas To: IJsbrand Wijnands Content-Type: multipart/alternative; boundary=001a11c24e609a95d7050f0d3ba7 Archived-At: Cc: "bier@ietf.org" , "iesg@ietf.org" , Adrian Farrel , Alvaro Retana , Arkadiy Gulko , stbryant Subject: Re: [Bier] proposed BIER charter 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, 14 Feb 2015 14:33:15 -0000 --001a11c24e609a95d7050f0d3ba7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ice, On Sat, Feb 14, 2015 at 2:38 AM, IJsbrand Wijnands wrote: > Hi Alia, > > > I'm delighted to hear of your interest and that of other operators. I > did, of course, speak with you before the BoF and know of your involvemen= t > in the drafts. Unfortunately, I haven't heard such support expressed in > the IETF by operators; obviously vendors=E2=80=99 interest can reflect su= ch > interest indirectly. > > I would just like to point out that we have 4 different operators in our > contributing author section of the BIER architecture draft ( > https://tools.ietf.org/html/draft-wijnands-bier-architecture-04#section-1= 0) > that indicated they want to help move this work forward, you don=E2=80=99= t consider > that as =E2=80=98support=E2=80=99? > Obviously, have active authors implies that they are interested in developing the technology because it has promise. Obviously, by being willing to charter a working group, I have heard and agree. Except for Arkadiy, they haven't participated on the mailing list or spoke up at the BoF at all - despite all being active IETFers. Regards, Alia > Thx, > > Ice. --001a11c24e609a95d7050f0d3ba7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ice,

On Sat, Feb 14, 2015 at 2:38 AM, I= Jsbrand Wijnands <ice@cisco.com> wrote:
Hi Al= ia,

> I'm delighted to hear of your interest and that of other operators= .=C2=A0 I did, of course, speak with you before the BoF and know of your in= volvement in the drafts.=C2=A0 Unfortunately, I haven't heard such supp= ort expressed in the IETF by operators; obviously vendors=E2=80=99 interest= can reflect such interest indirectly.

I would just like to point out that we have 4 different operators in= our contributing author section of the BIER architecture draft (https://tools.ietf.org/html/draft-wijnands-bier-archite= cture-04#section-10) that indicated they want to help move this work fo= rward, you don=E2=80=99t consider that as =E2=80=98support=E2=80=99?

Obviously, have active authors implies that t= hey are interested in developing the technology because it has promise.=C2= =A0 Obviously, by being willing to charter a working group, I have heard an= d agree. =C2=A0 Except for Arkadiy, they haven't participated on the ma= iling list or spoke up at the BoF at all - despite all being active IETFers= . =C2=A0

Regards,
Alia
=C2=A0<= /div>
Thx,

Ice.

--001a11c24e609a95d7050f0d3ba7-- From nobody Sat Feb 14 08:35:47 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C141A6F0E; Sat, 14 Feb 2015 08:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 VDYJcRtfOirI; Sat, 14 Feb 2015 08:35:38 -0800 (PST) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33231A6F0D; Sat, 14 Feb 2015 08:35:37 -0800 (PST) Received: by pdbfl12 with SMTP id fl12so25771810pdb.2; Sat, 14 Feb 2015 08:35:37 -0800 (PST) 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=waAMY6/1wZo0I/vSBCSmbIurAu1nGywiTPTzgr5jgCk=; b=kSJMuPcgzsVlF9Y8acpQ1aAHiyBroUU8MfK+hYgPtjwnb4OdpnsDv//U3jJAKroBp9 wRHi8/LKbG9Vld4PXz+S844Sy6DojCau60SMbzS3M1AE+wZWyUvoFxqqLGUUQTey2PNL lk56Vo9pYJa7qpXuTgfo5Buw3/Kp19OxJIwQN3uZxWHU4qQ+utYjOxyfJLjIEDWChAvm 8qXrqN2pyhsqFCMl+mxfINYulj5+EA4VPo61l8le9fDfAZyE1VnbQRsuEAyt1J8m9jXl dedNBVc7RP1icWuvqfJxnEloXqgBMhjmrz67MvwrGioxsp3dciy0vbKAVfO5jtqTHKxj fLCg== X-Received: by 10.66.119.103 with SMTP id kt7mr25026596pab.157.1423931737270; Sat, 14 Feb 2015 08:35:37 -0800 (PST) Received: from [10.81.114.230] (mobile-166-171-250-184.mycingular.net. [166.171.250.184]) by mx.google.com with ESMTPSA id rb3sm9986683pab.29.2015.02.14.08.35.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Feb 2015 08:35:36 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-EA4B2963-B123-455C-8BB2-0D7597EF4D0C Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Sat, 14 Feb 2015 08:35:34 -0800 Content-Transfer-Encoding: 7bit Message-Id: <5F3A0664-A9D2-46E8-B1F4-937B1661F5F8@gmail.com> References: <54DCAE4F.8050903@cisco.com> <4A496052E7B7E84A9324854763C616FA233CF4DA@C111GTUHMBX56.ERF.thomson.com> To: Alia Atlas Archived-At: Cc: "bier@ietf.org" , IJsbrand Wijnands , "iesg@ietf.org" , Alvaro Retana , Adrian Farrel , Arkadiy Gulko , stbryant Subject: Re: [Bier] proposed BIER charter 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, 14 Feb 2015 16:35:40 -0000 --Apple-Mail-EA4B2963-B123-455C-8BB2-0D7597EF4D0C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alia, Arkadiy is the user, operator, and requirement setter. He will use the= technology. And he has done more than speak up, he is a =E2=84=85-author an= d helping to build the technology to be useful and practical.=20 Dino > On Feb 14, 2015, at 6:33 AM, Alia Atlas wrote: >=20 > Ice, >=20 >> On Sat, Feb 14, 2015 at 2:38 AM, IJsbrand Wijnands wrote:= >=20 >> Hi Alia, >>=20 >> > I'm delighted to hear of your interest and that of other operators. I d= id, of course, speak with you before the BoF and know of your involvement in= the drafts. Unfortunately, I haven't heard such support expressed in the I= ETF by operators; obviously vendors=E2=80=99 interest can reflect such inter= est indirectly. >>=20 >> I would just like to point out that we have 4 different operators in our c= ontributing author section of the BIER architecture draft (https://tools.iet= f.org/html/draft-wijnands-bier-architecture-04#section-10) that indicated th= ey want to help move this work forward, you don=E2=80=99t consider that as =E2= =80=98support=E2=80=99? >=20 > Obviously, have active authors implies that they are interested in develop= ing the technology because it has promise. Obviously, by being willing to c= harter a working group, I have heard and agree. Except for Arkadiy, they h= aven't participated on the mailing list or spoke up at the BoF at all - desp= ite all being active IETFers. =20 >=20 > Regards, > Alia > =20 >> Thx, >>=20 >> Ice. >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier --Apple-Mail-EA4B2963-B123-455C-8BB2-0D7597EF4D0C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Alia, Arkadiy is the user, operator, a= nd requirement setter. He will use the technology. And he has done more than= speak up, he is a =E2=84=85-author and helping to build the technology to b= e useful and practical. 

Dino


On Feb 14, 2015, at 6:33 AM, Alia Atlas <akatlas@gmail.com> wrote:

Ice,

On Sat, Feb 14, 2015 at= 2:38 AM, IJsbrand Wijnands <ice@cisco.com> wrote:

> I'm delighted to hear of your interest and that of other operators.&nbs= p; I did, of course, speak with you before the BoF and know of your involvem= ent in the drafts.  Unfortunately, I haven't heard such support express= ed in the IETF by operators; obviously vendors=E2=80=99 interest can reflect= such interest indirectly.

I would just like to point out that we have 4 different operators in o= ur contributing author section of the BIER architecture draft (https://tools.ietf.org/html/draft-wijnands-bier-architecture= -04#section-10) that indicated they want to help move this work forward,= you don=E2=80=99t consider that as =E2=80=98support=E2=80=99?

Obviously, have active authors implies that they are i= nterested in developing the technology because it has promise.  Obvious= ly, by being willing to charter a working group, I have heard and agree. &nb= sp; Except for Arkadiy, they haven't participated on the mailing list or spo= ke up at the BoF at all - despite all being active IETFers.  

Regards,
Alia
 
Thx,

Ice.

____________________= ___________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman= /listinfo/bier
= --Apple-Mail-EA4B2963-B123-455C-8BB2-0D7597EF4D0C-- From nobody Sat Feb 14 12:13:47 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A331A000A; Sat, 14 Feb 2015 12:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2FG_3k2uiEP; Sat, 14 Feb 2015 12:13:42 -0800 (PST) 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 630831A0053; Sat, 14 Feb 2015 12:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=849; q=dns/txt; s=iport; t=1423944821; x=1425154421; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=pBvqsJx1JO7o9Xez50kIIf4TFFxCTaUT6Y2Lc5mw4qQ=; b=HNKcai76oRzavf0V4VUAeVVrTqk0d0lqym95zMIafIq9xTRMyt56y8Oj YSTa3Y7Ku9GQtMdPJgcsfM6MpSO3J3SuqiF88rYQfljkwOBduTsyc3kbQ 4/bhw3iFjaSpQrcp+ghEoQlq5I1sjmWhOH45gd8TkGu+mly7/BIOaVX07 A=; X-IronPort-AV: E=Sophos;i="5.09,577,1418083200"; d="scan'208";a="350324898" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 14 Feb 2015 20:13:39 +0000 Received: from [10.61.219.184] ([10.61.219.184]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1EKDdRo029834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Feb 2015 20:13:39 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: IJsbrand Wijnands In-Reply-To: Date: Sat, 14 Feb 2015 21:13:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54DCAE4F.8050903@cisco.com> <4A496052E7B7E84A9324854763C616FA233CF4DA@C111GTUHMBX56.ERF.thomson.com> To: Alia Atlas X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "bier@ietf.org" , "iesg@ietf.org" , Adrian Farrel , Alvaro Retana , Arkadiy Gulko , stbryant Subject: Re: [Bier] proposed BIER charter 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, 14 Feb 2015 20:13:43 -0000 Alia, > Obviously, have active authors implies that they are interested in = developing the technology because it has promise. Obviously, by being = willing to charter a working group, I have heard and agree. Except for = Arkadiy, they haven't participated on the mailing=20 You=E2=80=99re doing a very good job in hiding your excitement ;-)=20 > list or spoke up at the BoF at all - despite all being active IETFers.=20= First of all, at least 3 of the operators where not in Hawaii. Second, = you have your priorities reversed! You should put much more weight in = operators that are willing to associate their name with a draft and help = move the technology forward. Anybody can go to the mic at an IETF = meeting and make some comments. Its the people on the drafts that make = the difference and GSD. Thx, Ice. From nobody Sat Feb 14 12:37:25 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7499C1A0060; Sat, 14 Feb 2015 12:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 SA0Q1ehoTugv; Sat, 14 Feb 2015 12:37:21 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26C41A0056; Sat, 14 Feb 2015 12:37:21 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8EB0E880E2; Sat, 14 Feb 2015 12:37:21 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id CC61A71B0001; Sat, 14 Feb 2015 12:37:20 -0800 (PST) Message-ID: <54DFB200.8070604@innovationslab.net> Date: Sat, 14 Feb 2015 15:37:20 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stewart Bryant , Alia Atlas , "bier@ietf.org" References: <54DCAE4F.8050903@cisco.com> In-Reply-To: <54DCAE4F.8050903@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="B5f5mbts8gOHjpLLWUfWJ5TJot5mUrxLw" Archived-At: Cc: Adrian Farrel , "iesg@ietf.org" , Alvaro Retana Subject: Re: [Bier] proposed BIER charter 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, 14 Feb 2015 20:37:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B5f5mbts8gOHjpLLWUfWJ5TJot5mUrxLw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stewart, On 2/12/15 8:44 AM, Stewart Bryant wrote: > Alia >=20 > I think that you are crossing far too many bridges before you get to th= em > in terms of you expectation of where BIER will be deployed and how > it will be implemented. >=20 > The charter should not include such specific assumptions, particularly > given the fast moving changes that are happening in our industry > especially in the area of packet forwarding design. >=20 > I have not seen such assumptions in other charters and I don't think > that they have a place in this one. >=20 > In terms of choice of document stream (experimental vs PS), > that is a decision that can be taken at the time of publication > when more information will be available in terms of potential > market take-up, expected/actual deployment scenarios, > breadth of implementation and implementation experience. Given that we do not have a wealth of deployment experience with BIER, I think it is quite reasonable to start the process as an Experimental specification. Part of the reason for me holding this view is that there is still some areas of work needed to understand how BIER will fit in the overall multicast architecture. For example, in non-MPLS deployments, there is a need to specify how BIER-battered forwarding will interact with the group management protocols. >=20 > Whilst this technology may be deployed in the Internet core, > it my also be deployed at the edge where a much lower threshold > is applicable. I agree, but an Experimental specification does not preclude such cases. In fact, those deployments will help all of us understand what deficiencies or efficiencies are in BIER. >=20 > I fear that by introducing these caveats the IETF is entrenching the > perception that it slows technology down rather than embracing > and encouraging innovation. I disagree with the above view. The label placed on specifications rarely slows down technology if it is viable. Regards, Brian --B5f5mbts8gOHjpLLWUfWJ5TJot5mUrxLw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU37IFAAoJEBOZRqCi7goqu1UIAJTiMV7ogQD8UT3U70Y6LEKI FSEJmv8rnImgh0dpQMLhtnzXVpQtm2oPrx1waYIpfhTScN7jdeR0To6CIByGUt6r TiNt9GU0rWywe3pWEl5NpPxlwg0UxxkgnSUisOcq01xTZ6hWEQAumKfNkFF5UQh0 kA0Liu9OqdIJpGVaxQT4HEc27Jd57OfoIL6FxFhe+BJ+qwmV3McdPWruvf1OLj1I bDIFZEcG9TDpDeKsiog9J8Ezc8CPAzcyczceVtYUHPSd/XXf8pEBlT6wyGwb3gRp NcgbjuL5DV6lZAE/8sAKWtjsTFPPOsKHl0hUwpjRV5Xi/QblkMtMdNZh0Bvn6v4= =3Dca -----END PGP SIGNATURE----- --B5f5mbts8gOHjpLLWUfWJ5TJot5mUrxLw-- From nobody Sat Feb 14 16:19:51 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8FC1A0118; Sat, 14 Feb 2015 16:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4YRdhgSjiH2; Sat, 14 Feb 2015 16:19:46 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286B41A008A; Sat, 14 Feb 2015 16:19:45 -0800 (PST) Received: by mail-yk0-f171.google.com with SMTP id q200so8089249ykb.2; Sat, 14 Feb 2015 16:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WJK561tVZO1Fb71YMHxxD4HTXaugX/F/euFdpxC3Wzc=; b=G9KT6TRmL3pWQxC+SqYvKitYYxlC3eguCTtbDl/f1kTKBdPCDQdHM61q/DyyUfOdam CyQ5ouMQyz81syUGb6pu9IUyOsPbEl+fcdzIP6dlmWxHQ7rM8XgRZlZxgPYMrvN9ErzZ H7SL07k3QsSf9CjJh1GGGBuTEy7g1CXlITCodbdjgvFYiCGJ63kRQCkHLJC9D3FL7BME Ge3L6BhrUZWZJ2jLaWpwmHCqeVoS3kQo+fea9l3r8UFrhUw8OTPR5XsVXwY6FWXns/ZD Xt98nU16dh2NGIEXQmwtICmR5deDoFSqGEghwSOTybO4d+42DS8xupaW9tVSbBIyMIIE SVhQ== MIME-Version: 1.0 X-Received: by 10.170.198.215 with SMTP id p206mr14392176yke.72.1423959585210; Sat, 14 Feb 2015 16:19:45 -0800 (PST) Received: by 10.170.133.197 with HTTP; Sat, 14 Feb 2015 16:19:45 -0800 (PST) In-Reply-To: <20150214214725.9126.32255.idtracker@ietfa.amsl.com> References: <20150214214725.9126.32255.idtracker@ietfa.amsl.com> Date: Sat, 14 Feb 2015 19:19:45 -0500 Message-ID: From: Alia Atlas To: Joel Jaeggli Content-Type: multipart/alternative; boundary=001a1144f8e6404a2d050f156d52 Archived-At: Cc: Greg Shepherd , "bier@ietf.org" , The IESG , Tony Przygienda Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 15 Feb 2015 00:19:48 -0000 --001a1144f8e6404a2d050f156d52 Content-Type: text/plain; charset=UTF-8 Hi Joel, On Sat, Feb 14, 2015 at 4:47 PM, Joel Jaeggli wrote: > Joel Jaeggli has entered the following ballot position for > charter-ietf-bier-00-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-bier/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > So the size of the bier domain is bounded I suppose by the number of > egress points you're willing to include in your header. given the > inherent suitability of such a method for overlays it seems like it > distinctly bounds the size of such an overlay based on the header size/ > if you chain bier domains (no subdomain) how do you do loop detection (or > don't you). > The bier-ingress router can do a bit of ingress replication, if needed. Basically, only one "word" of the bitmap is in the packet and the bier-ingress replicates once for each different word that needs to be sent to. One of the questions, of course, is how many bits are in a word. At 1024 or 2048, that handles much larger networks but requires more bits in the header to be available for processing than at 256. I haven't yet seen any ideas describing chaining bier domains. I think between bier domains it would default up to the tree-building protocol. Possibly one of the bier proponents will have more ideas. Thanks for the early review! Alia --001a1144f8e6404a2d050f156d52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joel,

On Sat, Feb 14, 2015 at 4:47 PM, Joel Jaeggli <= ;joelja@bogus.com= > wrote:
Joel Jaeggli has enter= ed the following ballot position for
charter-ietf-bier-00-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-bier/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

So the size of the bier domain is bounded I suppose by the number of
egress points you're willing to include in your header. given the
inherent suitability of such a method for overlays it seems like it
distinctly bounds the size of such an overlay based on the header size/
if you chain bier domains (no subdomain) how do you do loop detection (or don't you).

The bier-ingress router= can do a bit of ingress replication, if needed.=C2=A0 Basically,
only one "word" of the bitmap is in the packet and the bier-ingr= ess replicates once
for each different word that needs to be sent= to.=C2=A0 One of the questions, of course,
is how many bits are = in a word.=C2=A0 At 1024 or 2048, that handles much larger networks
but requires more bits in the header to be available for processing than= at 256.

I haven't yet seen any ideas describi= ng chaining bier domains.=C2=A0 I think between
bier domains it w= ould default up to the tree-building protocol.=C2=A0 Possibly one of the
bier proponents will have more ideas.

Than= ks for the early review!
Alia

--001a1144f8e6404a2d050f156d52-- From nobody Sat Feb 14 17:00:38 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177B01A00F9; Sat, 14 Feb 2015 17:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fatVQqZFoJv; Sat, 14 Feb 2015 17:00:31 -0800 (PST) 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 393371A0130; Sat, 14 Feb 2015 17:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9529; q=dns/txt; s=iport; t=1423962031; x=1425171631; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=v5Y8+mIwZTVTPwdd7I7mhNOdFw9usFQDIZ+GABjTnng=; b=EZbgE656DGQ6F+VTylvDJy0E2zzUvvUvqOK4wcc2Lq73gV8lVf7JYXxe lB0BU0mDfuDYzpZfsFgwc4v8FQGRZY02d37GBRYZ4d5VpcowhNNhjfxU9 M1q8+9jXe3GaCg83Jc2MTeDymXR8cFmBTMzqAAWM5JSMEC7k9928T7ApL 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BgBQD17t9U/4cNJK1bgwZSWsIwAQmFcQKBDkMBAQEBAQF8hA0BAQQBAQFrCxACAQgSLQcnCxQDDgIEDgWILQ3TNAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiwyEFVQEB4MWgRQFjUyBbIk3kw0ig25vgQKBQQEBAQ X-IronPort-AV: E=Sophos;i="5.09,578,1418083200"; d="scan'208,217";a="396041811" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP; 15 Feb 2015 01:00:30 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1F10URA013471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Feb 2015 01:00:30 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Sat, 14 Feb 2015 19:00:29 -0600 From: "Rajiv Asati (rajiva)" To: Brian Haberman Thread-Topic: [Bier] proposed BIER charter Thread-Index: AQHQSJYHMrYFGWrOhUGuXJjtT6R8K5zw5GhZ Date: Sun, 15 Feb 2015 01:00:29 +0000 Message-ID: <60280EE7-6782-42DF-9CFF-5BD5F3C1D38B@cisco.com> References: <54DCAE4F.8050903@cisco.com>,<54DFB200.8070604@innovationslab.net> In-Reply-To: <54DFB200.8070604@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_60280EE7678242DF9CFF5BD5F3C1D38Bciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bier@ietf.org" , "iesg@ietf.org" , "Alvaro Retana \(aretana\)" , Adrian Farrel , "Stewart Bryant \(stbryant\)" Subject: Re: [Bier] proposed BIER charter 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, 15 Feb 2015 01:00:34 -0000 --_000_60280EE7678242DF9CFF5BD5F3C1D38Bciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Given that we do not have a wealth of deployment experience with BIER, I think it is quite reasonable to start the process as an Experimental specification. We may find the above a bit odd, if we relate to how RFC3031/3032 (MPLS arc= hitecture and encoding) were put on standards track right from the getgo, d= espite having limited deployment experience with MPLS. Experimental in many circles play a significant mind-barrier game. Part of the reason for me holding this view is that there is still some areas of work needed to understand how BIER will fit in the overall multicast architecture. Ummmm....we will certainly have work to do in not only understanding existi= ng areas, but also exploring new areas (such as 6lopan) for BIER. But that'= s cant/mustn't be the reason to classify any work as experimental. Cheers, Rajiv On Feb 14, 2015, at 3:37 PM, Brian Haberman > wrote: Hi Stewart, On 2/12/15 8:44 AM, Stewart Bryant wrote: Alia I think that you are crossing far too many bridges before you get to them in terms of you expectation of where BIER will be deployed and how it will be implemented. The charter should not include such specific assumptions, particularly given the fast moving changes that are happening in our industry especially in the area of packet forwarding design. I have not seen such assumptions in other charters and I don't think that they have a place in this one. In terms of choice of document stream (experimental vs PS), that is a decision that can be taken at the time of publication when more information will be available in terms of potential market take-up, expected/actual deployment scenarios, breadth of implementation and implementation experience. Given that we do not have a wealth of deployment experience with BIER, I think it is quite reasonable to start the process as an Experimental specification. Part of the reason for me holding this view is that there is still some areas of work needed to understand how BIER will fit in the overall multicast architecture. For example, in non-MPLS deployments, there is a need to specify how BIER-battered forwarding will interact with the group management protocols. Whilst this technology may be deployed in the Internet core, it my also be deployed at the edge where a much lower threshold is applicable. I agree, but an Experimental specification does not preclude such cases. In fact, those deployments will help all of us understand what deficiencies or efficiencies are in BIER. I fear that by introducing these caveats the IETF is entrenching the perception that it slows technology down rather than embracing and encouraging innovation. I disagree with the above view. The label placed on specifications rarely slows down technology if it is viable. Regards, Brian _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier --_000_60280EE7678242DF9CFF5BD5F3C1D38Bciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Given that we do not have a wealth of depl= oyment experience with BIER, I
think it is quite reasonable to start the process as an Experimental
specification.  

We may find the above a bit odd, if we relate to how RFC3031/3032 (MPL= S architecture and encoding) were put on standards track right from the get= go, despite having limited deployment experience with MPLS.  

Experimental in many circles play a significant mind-barrier game. &nb= sp;


Part of the reason for me holding this vie= w is that
there is still some areas of work needed to understand how BIER will fit in the overall multicast architecture.  

Ummmm....we will certainly have work to do in not only understanding e= xisting areas, but also exploring new areas (such as 6lopan) for BIER. But = that's cant/mustn't be the reason to classify any work as experimental. &nb= sp; 


Cheers,
Rajiv  




On Feb 14, 2015, at 3:37 PM, Brian Haberman <brian@innovationslab.net> wrote:

Hi Stewart,

On 2/12/15 8:44 AM, Stewart Bryant wrote:
Alia

I think that you are crossing far too many = bridges before you get to them
in terms of you expectation of where BIER w= ill be deployed and how
it will be implemented.

The charter should not include such specifi= c assumptions, particularly
given the fast moving changes that are happ= ening in our industry
especially in the area of packet forwarding= design.

I have not seen such assumptions in other c= harters and I don't think
that they have a place in this one.<= br>

In terms of choice of document stream (expe= rimental vs PS),
that is a decision that can be taken at the= time of publication
when more information will be available in = terms of potential
market take-up, expected/actual deployment = scenarios,
breadth of implementation and implementatio= n experience.

Given that we do not have a wealth of deployment experience with BIER= , I
think it is quite reasonable to start the process as an Experimental<= /span>
specification.  Part of the reason for me holding this view is t= hat
there is still some areas of work needed to understand how BIER will = fit
in the overall multicast architecture.  For example, in non-MPLS=
deployments, there is a need to specify how BIER-battered forwarding<= /span>
will interact with the group management protocols.


Whilst this technology may be deployed in t= he Internet core,
it my also be deployed at the edge where a = much lower threshold
is applicable.

I agree, but an Experimental specification does not preclude such cas= es.
In fact, those deployments will help all of us understand what=
deficiencies or efficiencies are in BIER.


I fear that by introducing these caveats th= e IETF is entrenching the
perception that it slows technology down ra= ther than embracing
and encouraging innovation.

I disagree with the above view.  The label placed on specificati= ons
rarely slows down technology if it is viable.

Regards,
Brian

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ie= tf.org/mailman/listinfo/bier
--_000_60280EE7678242DF9CFF5BD5F3C1D38Bciscocom_-- From nobody Sun Feb 15 01:50:12 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191891A1AA6; Sun, 15 Feb 2015 01:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ODTzsDPK4fb9; Sun, 15 Feb 2015 01:50:05 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34C41A1AA4; Sun, 15 Feb 2015 01:50:04 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t1F9nuLv029115; Sun, 15 Feb 2015 09:49:56 GMT Received: from 950129200 (xdsl-77-74-119-17.c.btirol.at [77.74.119.17] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t1F9nhv9029022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 15 Feb 2015 09:49:43 GMT From: "Adrian Farrel" To: "'Alia Atlas'" , "'Joel Jaeggli'" References: <20150214214725.9126.32255.idtracker@ietfa.amsl.com> In-Reply-To: Date: Sun, 15 Feb 2015 09:49:42 -0000 Message-ID: <011501d04904$bacd7bf0$306873d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0116_01D04904.C081C010" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLIDneLHdU3n9M/7CwfZhG/jgb7/gJQ5Ppymu7fqKA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21332.003 X-TM-AS-Result: No--12.826-10.0-31-10 X-imss-scan-details: No--12.826-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkBcCxXH25sMHYeAntdoMxBadAB35LoCrtTY+WMspgYx+jQb Y5MLDM8IXers26Xj0FAVLdL1nSIVCteV00rMo+W9Qz/LkQyz8mbX1njydWb1yLkiJ/BgvX6rP1G ENVD+bMxBmf3XoP3J5Eb5H/7zTJtBZCSBV6VCLjUWGNJh59eVbCseSAhqf1rRCNGeqofM1fdqeZ +AzBMmzcnHRSOAKlDBD7uVWbyyDVI/IVzSvtxQYVRe8joruKtpAHN/Ezu9EnFScXQMxepe+0Rml qEETmfEvW02iaVAiIQkC5AZv2h0wDpI0A0aNTmUTVa+L3Zgqc6bAFRopiFBCmglqTT0/D3BRpye xIPofKWt/TcqGAEA51dXJSQa3y+Tue4A1S8vO3raGKmW8Fvr+1F5adRR2Ej1isIL6qBciPIiXZj DiyK4lEbpePxXTTv5LC0ZKcJf5Djs8TWiNgS9oe9VsdrlGzy3Q6/DFZugyt0wODfUl7mJKf4ZAU sty2ENewo8j91GeTG6RgENsA/90MsesOAiftrl9iItFUn3XkM7r2Gtb9iBYU8dFP+NPq6+dXDbH Fxm2F+dv7RrSohAJCkm8kuls98/aEoHA+Yew8W7vYqkCS0dL7YidXoBo/qVlSFPfwjN9pHsoEFn ZAFTLE+J83GmsfZy66Wuu9SwKD+HFo7dvDc+MOOtrJejSjcwWq9ln3+CkiGPaLJ/Ca3ST2ji04E zOjY4PDcFKiUcob7XoUgqgJGOVTWBtSWZ+bE6b/5HBZ6dvRjRaXpm7mwQnLkY3WUw/B8Xu8iyJC yNt6l2+AZuxakJy3inb860CrQowPo8GP7TYNueAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLm0EqN7 mnB3kESKBlicakMpb7RdBjVJkrNtXQuD0xt7lf26wQO7oY06nHykmahZQBF0p9+vw8Dr4WtX47P GkKTPB3T8Yqz8MaMsabGc+mUFc/9za0y1DHl Archived-At: Cc: 'Greg Shepherd' , bier@ietf.org, 'The IESG' Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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: Sun, 15 Feb 2015 09:50:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0116_01D04904.C081C010 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While Alia may be right that no-one has discussed chaining BIER domains, = the charter wording gave me the impression that this was "perfectly = reasonable." Thus, a packet exiting one domain might then be injected = into a new domain. =20 Consider, for example, the work that has been done on P2MP RSVP-TE where = the ingress domain builds a tree to reach all of the egress nodes it = owns and also each of the downstream domains. But it doesn't know the = tree across the downstream domains. =20 And Joel's concern about looping is valid. Of course, a solution could be developed. =20 But how about this charter limit the work to a single domain? =20 Adrian =20 =20 From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Alia Atlas Sent: 15 February 2015 00:20 To: Joel Jaeggli Cc: Greg Shepherd; bier@ietf.org; The IESG; Tony Przygienda Subject: Re: [Bier] Joel Jaeggli's No Objection on = charter-ietf-bier-00-01: (with COMMENT) =20 Hi Joel, =20 On Sat, Feb 14, 2015 at 4:47 PM, Joel Jaeggli wrote: Joel Jaeggli has entered the following ballot position for charter-ietf-bier-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bier/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- So the size of the bier domain is bounded I suppose by the number of egress points you're willing to include in your header. given the inherent suitability of such a method for overlays it seems like it distinctly bounds the size of such an overlay based on the header size/ if you chain bier domains (no subdomain) how do you do loop detection = (or don't you). =20 The bier-ingress router can do a bit of ingress replication, if needed. = Basically, only one "word" of the bitmap is in the packet and the bier-ingress = replicates once for each different word that needs to be sent to. One of the questions, = of course, is how many bits are in a word. At 1024 or 2048, that handles much = larger networks but requires more bits in the header to be available for processing than = at 256. =20 I haven't yet seen any ideas describing chaining bier domains. I think = between bier domains it would default up to the tree-building protocol. = Possibly one of the bier proponents will have more ideas. =20 Thanks for the early review! Alia =20 ------=_NextPart_000_0116_01D04904.C081C010 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

While Alia may be right that = no-one has discussed chaining BIER domains, the charter wording gave me = the impression that this was "perfectly reasonable." Thus, a = packet exiting one domain might then be injected into a new = domain.

 

<gratuitous = analogy>

Consider, for example, the = work that has been done on P2MP RSVP-TE where the ingress domain builds = a tree to reach all of the egress nodes it owns and also each of the = downstream domains. But it doesn't know the tree across the downstream = domains.

</gratuitous = analogy>

 

And Joel's concern about = looping is valid.

Of course, a solution could be = developed.

 

But how about this charter = limit the work to a single domain?

 

Adrian

 

 

From: BIER = [mailto:bier-bounces@ietf.org] On Behalf Of Alia = Atlas
Sent: 15 February 2015 00:20
To: Joel = Jaeggli
Cc: Greg Shepherd; bier@ietf.org; The IESG; Tony = Przygienda
Subject: Re: [Bier] Joel Jaeggli's No Objection on = charter-ietf-bier-00-01: (with = COMMENT)

 

Hi = Joel,

 

On Sat, = Feb 14, 2015 at 4:47 PM, Joel Jaeggli <joelja@bogus.com> wrote:

Joel Jaeggli has entered the following ballot position = for
charter-ietf-bier-00-01: No Objection

When responding, = please keep the subject line intact and reply to all
email addresses = included in the To and CC lines. (Feel free to cut this
introductory = paragraph, however.)



The document, along with other = ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-bier/<= br>


----------------------------------------------------------= ------------
COMMENT:
---------------------------------------------= -------------------------

So the size of the bier domain is = bounded I suppose by the number of
egress points you're willing to = include in your header. given the
inherent suitability of such a = method for overlays it seems like it
distinctly bounds the size of = such an overlay based on the header size/
if you chain bier domains = (no subdomain) how do you do loop detection (or
don't = you).

 

The bier-ingress router can do a bit of ingress = replication, if needed.  Basically,

only one "word" of the bitmap is in the = packet and the bier-ingress replicates once

for each different word that needs to be sent = to.  One of the questions, of course,

is how many bits are in a word.  At 1024 or 2048, = that handles much larger networks

but requires more bits in the header to be available = for processing than at 256.

 

I = haven't yet seen any ideas describing chaining bier domains.  I = think between

bier domains = it would default up to the tree-building protocol.  Possibly one of = the

bier proponents will = have more ideas.

 

Thanks for the early = review!

Alia

 

------=_NextPart_000_0116_01D04904.C081C010-- From nobody Sun Feb 15 08:24:33 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACEF1A7034; Sun, 15 Feb 2015 08:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L-dsVjHjD_t; Sun, 15 Feb 2015 08:24:27 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC36D1A802F; Sun, 15 Feb 2015 08:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34037; q=dns/txt; s=iport; t=1424017467; x=1425227067; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=laI4mRh+YPG2rIHxcfzuyAGlEvu4XIuHZQh630SRqa8=; b=UIBJBQP9hEHWhjO47YA2ifZvC2RCEKK4s6UqzAoUKO/8LVqO8bRAFKXA wl6Id7YU59ZJDRCicYcQbSIRdIUGHeWMZsTF5eOPBp2oTjijjq9HKi/A0 WaJJy8J0Clelvgzkohm4ljHqxTw5LC5CTI16OCPI8eYIq6ZDrRmSQb8hZ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskNAEnH4FStJA2M/2dsb2JhbABbgkNDUlqvYQIBAQEBBQF1H4IJjQc8gUsZAQmFcQKBEEMBAQEBAQF8hAwBAQEEAQEBKkELEAIBCBEEAQEhAQYHJgELFAkIAgQOBAEbiBINzkIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhgSFCIQLCwYBTAQGAYMWgRQFhVqHcoFsg1eFYIEYOIJViyqDPiKCMoE8b4EDCBeBIQEBAQ X-IronPort-AV: E=Sophos;i="5.09,581,1418083200"; d="scan'208,217";a="396373721" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 15 Feb 2015 16:24:26 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1FGOQXI000626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Feb 2015 16:24:26 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.156]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Sun, 15 Feb 2015 10:24:25 -0600 From: "IJsbrand Wijnands (iwijnand)" To: "" Thread-Topic: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT) Thread-Index: AQHQSLUfxD/rUn4IdEaOiajtj1h48Zzx3JwAgAAJtBU= Date: Sun, 15 Feb 2015 16:24:25 +0000 Message-ID: References: <20150214214725.9126.32255.idtracker@ietfa.amsl.com> , <011501d04904$bacd7bf0$306873d0$@olddog.co.uk> In-Reply-To: <011501d04904$bacd7bf0$306873d0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DB75EA2363E246ABA28D4F792B4EB135ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Joel Jaeggli , Greg Shepherd , "bier@ietf.org" , The IESG Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 15 Feb 2015 16:24:30 -0000 --_000_DB75EA2363E246ABA28D4F792B4EB135ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, Procedures for stitching such 'domains' together are documented in rfc6514 = and called 'Segmented Inter-AS MVPN'. I think the exact same procedures can= be applied to BIER domains. These procedures where developed in the contex= t of L3VPN. If any updates are need I would think this work belongs in BESS= . So limiting the scope to single domain in the BIER charter is ok with me. Thx, Ice. Sent from my iPad On 15 Feb 2015, at 10:50, Adrian Farrel > wrote: While Alia may be right that no-one has discussed chaining BIER domains, th= e charter wording gave me the impression that this was "perfectly reasonabl= e." Thus, a packet exiting one domain might then be injected into a new dom= ain. Consider, for example, the work that has been done on P2MP RSVP-TE where th= e ingress domain builds a tree to reach all of the egress nodes it owns and= also each of the downstream domains. But it doesn't know the tree across t= he downstream domains. And Joel's concern about looping is valid. Of course, a solution could be developed. But how about this charter limit the work to a single domain? Adrian From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Alia Atlas Sent: 15 February 2015 00:20 To: Joel Jaeggli Cc: Greg Shepherd; bier@ietf.org; The IESG; Tony Przy= gienda Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01:= (with COMMENT) Hi Joel, On Sat, Feb 14, 2015 at 4:47 PM, Joel Jaeggli > wrote: Joel Jaeggli has entered the following ballot position for charter-ietf-bier-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bier/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- So the size of the bier domain is bounded I suppose by the number of egress points you're willing to include in your header. given the inherent suitability of such a method for overlays it seems like it distinctly bounds the size of such an overlay based on the header size/ if you chain bier domains (no subdomain) how do you do loop detection (or don't you). The bier-ingress router can do a bit of ingress replication, if needed. Ba= sically, only one "word" of the bitmap is in the packet and the bier-ingress replica= tes once for each different word that needs to be sent to. One of the questions, of= course, is how many bits are in a word. At 1024 or 2048, that handles much larger = networks but requires more bits in the header to be available for processing than at= 256. I haven't yet seen any ideas describing chaining bier domains. I think bet= ween bier domains it would default up to the tree-building protocol. Possibly o= ne of the bier proponents will have more ideas. Thanks for the early review! Alia _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier --_000_DB75EA2363E246ABA28D4F792B4EB135ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Folks,

Procedures for stitching such 'domains' together are documented in rfc= 6514 and called 'Segmented Inter-AS MVPN'. I think the exact same procedure= s can be applied to BIER domains. These procedures where developed in the c= ontext of L3VPN. If any updates are need I would think this work belongs in BESS. So limiting the scope to= single domain in the BIER charter is ok with me.

Thx,

Ice.

Sent from my iPad

On 15 Feb 2015, at 10:50, Adrian Farrel <adrian@olddog.co.uk> wrote:

While Alia may be right that no-one has discussed c= haining BIER domains, the charter wording gave me the impression that this was "perfectly reasonable." Thus, a packet exiting one doma= in might then be injected into a new domain.

 

<gratuitous analogy>

Consider, for example, the work that has been done = on P2MP RSVP-TE where the ingress domain builds a tree to reach all of the egress nodes it owns and also each of the downstream domains. But i= t doesn't know the tree across the downstream domains.

</gratuitous analogy>

 

And Joel's concern about looping is valid.

Of course, a solution could be developed.

 

But how about this charter limit the work to a sing= le domain?

 

Adrian

 

 

 

Hi Joel,

 

On Sat, Feb 14, 2015 at 4:47 PM, Joel Jaeggli <joelja@bogus.com>= ; wrote:

Joel Jaeggli has entered the following ballot positi= on for
charter-ietf-bier-00-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-bier/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

So the size of the bier domain is bounded I suppose by the number of
egress points you're willing to include in your header. given the
inherent suitability of such a method for overlays it seems like it
distinctly bounds the size of such an overlay based on the header size/
if you chain bier domains (no subdomain) how do you do loop detection (or don't you).

 

The bier-ingress router can do a bit of ingress repl= ication, if needed.  Basically,

only one "word" of the bitmap is in the pa= cket and the bier-ingress replicates once

for each different word that needs to be sent to.&nb= sp; One of the questions, of course,

is how many bits are in a word.  At 1024 or 204= 8, that handles much larger networks

but requires more bits in the header to be available= for processing than at 256.

 

I haven't yet seen any ideas describing chaining bie= r domains.  I think between

bier domains it would default up to the tree-buildin= g protocol.  Possibly one of the

bier proponents will have more ideas.

 

Thanks for the early review!

Alia

 

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ie= tf.org/mailman/listinfo/bier
--_000_DB75EA2363E246ABA28D4F792B4EB135ciscocom_-- From nobody Sun Feb 15 08:37:39 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13741A1BCA; Sun, 15 Feb 2015 08:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 5C80QAwYbd61; Sun, 15 Feb 2015 08:37:36 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9A01A1AA0; Sun, 15 Feb 2015 08:37:35 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C370E880F0; Sun, 15 Feb 2015 08:37:35 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E842F136820B; Sun, 15 Feb 2015 08:37:34 -0800 (PST) Message-ID: <54E0CB50.2000202@innovationslab.net> Date: Sun, 15 Feb 2015 11:37:36 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <54DCAE4F.8050903@cisco.com>, <54DFB200.8070604@innovationslab.net> <60280EE7-6782-42DF-9CFF-5BD5F3C1D38B@cisco.com> In-Reply-To: <60280EE7-6782-42DF-9CFF-5BD5F3C1D38B@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="D9SuP1sCKM8aBx4vFfgMNTmwiGpUh7pTw" Archived-At: Cc: "bier@ietf.org" , "iesg@ietf.org" , "Alvaro Retana \(aretana\)" , Adrian Farrel , "Stewart Bryant \(stbryant\)" Subject: Re: [Bier] proposed BIER charter 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, 15 Feb 2015 16:37:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D9SuP1sCKM8aBx4vFfgMNTmwiGpUh7pTw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rajiv, On 2/14/15 8:00 PM, Rajiv Asati (rajiva) wrote: > Given that we do not have a wealth of deployment experience with > BIER, I think it is quite reasonable to start the process as an > Experimental specification. >=20 > We may find the above a bit odd, if we relate to how RFC3031/3032 > (MPLS architecture and encoding) were put on standards track right > from the getgo, despite having limited deployment experience with > MPLS. I am speaking to this from the multicast perspective. >=20 > Experimental in many circles play a significant mind-barrier game. >=20 I am not aware of those situations, but I am not involved in MPLS circles. Can someone describe such a scenario? >=20 > Part of the reason for me holding this view is that there is still > some areas of work needed to understand how BIER will fit in the > overall multicast architecture. >=20 > Ummmm....we will certainly have work to do in not only understanding > existing areas, but also exploring new areas (such as 6lopan) for > BIER. But that's cant/mustn't be the reason to classify any work as > experimental. >=20 As I stated above, I am looking at this from the multicast (i.e., IP) perspective. It took quite a few years before the community felt comfortable moving PIM from Experimental to Standards Track. It is quite possible that the MPLS-centric components of BIER are viewed much differently than the IP-centric components. Regards, Brian --D9SuP1sCKM8aBx4vFfgMNTmwiGpUh7pTw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU4MtVAAoJEBOZRqCi7goqZTkH/0xdGY4zVT4EyPnvH750JSNX AmPVsJact7hEkqLnxAOBUEKUiX3apk7/eiT0KKYUx/W53FpuhyFq3rFwoQZHSYnt y+I1MeoJvFrcP96rSSrXgiA06w7hgZ2+GCh8QVskHZVZvKbF2xfgusYsrg7kv2LD zTjyYDVwbbtLkXgZ//RtoZQaMoOAXHPDK0UlaR8eC7PFhooAcW7dnCAJ/CARIprO lVQhfCNRM0HoRHWCGiLrSLktl3yyNPuT2fWrgD3InfjgM4/Qp23TJtoRb/A0m4gy J2Wi95UlSXWMjtRddtbyKV91iKYkx6HoAeLrknMBLR3fXiOWDGuaeVVVKRpdvuc= =7t2l -----END PGP SIGNATURE----- --D9SuP1sCKM8aBx4vFfgMNTmwiGpUh7pTw-- From nobody Sun Feb 15 09:42:30 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59C41A6EE9; Sun, 15 Feb 2015 09:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq_JhFWwMcKg; Sun, 15 Feb 2015 09:42:20 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B58A1A6EF3; Sun, 15 Feb 2015 09:42:18 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-5d-54e07a788d92 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7C.07.25146.87A70E45; Sun, 15 Feb 2015 11:52:40 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0210.002; Sun, 15 Feb 2015 12:42:16 -0500 From: Antoni Przygienda To: "IJsbrand Wijnands (iwijnand)" , "" Thread-Topic: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT) Thread-Index: AQHQSLUgfctwANhBEEKUODqERnb11Jzxy9gAgABuSYD//7zkwA== Date: Sun, 15 Feb 2015 17:42:16 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F18257772@eusaamb103.ericsson.se> References: <20150214214725.9126.32255.idtracker@ietfa.amsl.com> , <011501d04904$bacd7bf0$306873d0$@olddog.co.uk> 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_2E4BB27CAB87BF43B4207C0E55860F18257772eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyuXRPrG5F1YMQgwcN+hY/em4wWyydsYfJ YsucPItXc+4wW8z4M5HZ4tWpNYwObB5njyxg9JjyeyOrx85Zd9k9liz5yeSxYvNKxgDWKC6b lNSczLLUIn27BK6MZfdfsBf0v2as6L3+hrGBccl5xi5GTg4JAROJTVfPQdliEhfurWfrYuTi EBI4wijRsf8llLOcUaL3xW2wKjYBC4nL354yg9giAskSvxpWM4IUMQs0MUp8/7CeCSQhLBAj MfPECXaIoliJnaf3Q9lOErN/TQNrZhFQlXjzZBJYnFfAW+LN8UPsENveMErsOH0GaDUHB6eA rcSfRwkgNYxA530/tQZsPrOAuMStJ/OZIM4WkFiy5zwzhC0q8fLxP1YIW0ni4+/57CBjmAXy JWbsr4VYJShxcuYTlgmMorOQTJqFUDULSRVEiY7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ ipGjtDi1LDfdyHATIzA6j0mwOe5gXPDJ8hCjAAejEg/vBu4HIUKsiWXFlbmHGKU5WJTEecuu HAwREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFhfeY/1vaB3XOrm2Jtbi0S2/rQIVFPuD1ui ffIrazTvjq7kL/LaUp+9LCLUvkhsjntW+aLHhFk2eWEZ86Riz4g8Rq36RvlwreMx65ebiK+5 kaz3P8o+7Mipvuvrp+jMj72/78n0iuW+exfrvpzB+qnQmElylV2ZQX8r+6d/YR2nLYz8ujx+ KrEUZyQaajEXFScCAB9vFjOvAgAA Archived-At: Cc: Joel Jaeggli , Greg Shepherd , "bier@ietf.org" , The IESG Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 15 Feb 2015 17:42:26 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F18257772eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable are we talking a single AD ? or a single BIER domain ? Out the context I r= ead we're talking AD ? Then yes, I do think I agree with Ice here (as in th= is being basically inter-AS VPNs problem and with that probably BESS work). I sent some explanations about the size of a BIER domain to reflect on Joel= 's comments and the chaining _within_ an AD (assuming e.g. that a BIER doma= in could be an IGP area only or two IGPs interact). Didn't see it pass the = mailer. pasted below with minor editorials thanks --- tony Yes, ideas as to chaining & even translation between BIER domains are here,= some even written down but have been withheld to not overwhelm the communi= ty before the WG is established properly. Yes, it will amount to same thing= as OSPF area problem or a distance vector protocol if things get fancy (ma= ybe piggy-backed on BGP even which I do not foresee). As to size of a domain, it's pretty much arbitrary as far as practical prob= lem addressed goes. What Alia calls 'word size' and we call 'bitstring leng= th' only determines how many receivers can be marked up on a packet. It's o= nly a 'partitioning' scheme of a sub-domain where each 'bitstring length' r= epresents a subset of receivers. We have the limitation of a BFR-id being c= urrently 2 bytes which leaves us with 65'535 BFER (receivers) but given the= P-routers don't need one (BIER routers that do not have to act as receiver= s) we are talking much larger domain in terms of devices albeit surely not = enough for large scale multicast in the millions of receivers (which as a p= roblem, frankly, this technology should not be addressing currently) Additionally, I forgot to mention, BIER supports the concept of a subdomain= which, due to the fact that a BFR-id is subdomain-specifc can ultimately ;= support 255*65'535 receivers over the same domain albeit those are separate= d into the said sub-domains. Multiply that with the fact that a subdomain c= an run on a different multi-topology (if signalled via IGP) and I think we = have a very wide, albeit orthogonal 'addressing' scheme here that should su= pport very wide number of implementations (pure P-routers with a single top= ology, single-subdomain support, single bitstring length) all the way to ve= ry sizable deployments separating BIER traffic based on topology and subdom= ain membership and allowing for provisioning of rich service infrastructure= s for providers. Do I sound like a commercial, I probably do ;-) From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand Wijnands (i= wijnand) Sent: Sunday, February 15, 2015 8:24 AM To: Cc: Joel Jaeggli; Greg Shepherd; bier@ietf.org; The IESG Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01:= (with COMMENT) Hi Folks, Procedures for stitching such 'domains' together are documented in rfc6514 = and called 'Segmented Inter-AS MVPN'. I think the exact same procedures can= be applied to BIER domains. These procedures where developed in the contex= t of L3VPN. If any updates are need I would think this work belongs in BESS= . So limiting the scope to single domain in the BIER charter is ok with me. Thx, Ice. Sent from my iPad On 15 Feb 2015, at 10:50, Adrian Farrel > wrote: While Alia may be right that no-one has discussed chaining BIER domains, th= e charter wording gave me the impression that this was "perfectly reasonabl= e." Thus, a packet exiting one domain might then be injected into a new dom= ain. Consider, for example, the work that has been done on P2MP RSVP-TE where th= e ingress domain builds a tree to reach all of the egress nodes it owns and= also each of the downstream domains. But it doesn't know the tree across t= he downstream domains. And Joel's concern about looping is valid. Of course, a solution could be developed. But how about this charter limit the work to a single domain? Adrian From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Alia Atlas Sent: 15 February 2015 00:20 To: Joel Jaeggli Cc: Greg Shepherd; bier@ietf.org; The IESG; Tony Przy= gienda Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01:= (with COMMENT) Hi Joel, On Sat, Feb 14, 2015 at 4:47 PM, Joel Jaeggli > wrote: Joel Jaeggli has entered the following ballot position for charter-ietf-bier-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bier/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- So the size of the bier domain is bounded I suppose by the number of egress points you're willing to include in your header. given the inherent suitability of such a method for overlays it seems like it distinctly bounds the size of such an overlay based on the header size/ if you chain bier domains (no subdomain) how do you do loop detection (or don't you). The bier-ingress router can do a bit of ingress replication, if needed. Ba= sically, only one "word" of the bitmap is in the packet and the bier-ingress replica= tes once for each different word that needs to be sent to. One of the questions, of= course, is how many bits are in a word. At 1024 or 2048, that handles much larger = networks but requires more bits in the header to be available for processing than at= 256. I haven't yet seen any ideas describing chaining bier domains. I think bet= ween bier domains it would default up to the tree-building protocol. Possibly o= ne of the bier proponents will have more ideas. Thanks for the early review! Alia _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier --_000_2E4BB27CAB87BF43B4207C0E55860F18257772eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= <hat type=3D”individual cat of the herd= ”>

=  

= are we talking a single AD ? or a single BIER do= main ?  Out the context I read we’re talking AD ? Then yes, I do think I agree with Ice here (as in this being basically inter-AS VPNs p= roblem and with that probably BESS work).

=  

= I sent some explanations about the size of a BIE= R domain to reflect on Joel’s comments and the chaining _within_ an AD (assuming e.g. that a BIER domain could be an IGP area only or two I= GPs interact). Didn’t see it pass the mailer. pasted below with minor= editorials

=  

= </hat>

=  

= thanks

=  

= --- tony

=  

 

Yes, ideas as to chaining & even translation between BIER d= omains are here, some even written down but have been withheld to not overwhelm the community before the WG is established properly. Yes, it= will amount to same thing as OSPF area problem or a distance vector protoc= ol if things get fancy (maybe piggy-backed on BGP even which I do not fores= ee).

As to size of a domain, it's pretty much arbitrary as far as pr= actical problem addressed goes. What Alia calls 'word size' and we call 'bitstring length' only determines how many receivers can be m= arked up on a packet. It's only a 'partitioning' scheme of a sub-domain whe= re each 'bitstring length' represents a subset of receivers. We have the li= mitation of a BFR-id being currently 2 bytes which leaves us with 65'535 BFER (receivers) but given the P-route= rs don't need one (BIER routers that do not have to act as receivers) we ar= e talking much larger domain in terms of devices albeit surely not enough f= or large scale multicast in the millions of receivers (which as a problem, frankly, this technology should= not be addressing currently)

 

Additionally, I forgot to mention, BIER supports the concept of= a subdomain which, due to the fact that a BFR-id is subdomain-specifc can ultimately ;support 255*65'535 receivers over the same domain albeit t= hose are separated into the said sub-domains. Multiply that with the fact t= hat a subdomain can run on a different multi-topology (if signalled via IGP= ) and I think we have a very wide, albeit orthogonal 'addressing' scheme here that should support very wide n= umber of implementations (pure P-routers with a single topology, single-sub= domain support, single bitstring length) all the way to very sizable deploy= ments separating BIER traffic based on topology and subdomain membership and allowing for provisioning of rich= service infrastructures for providers.

Do I sound like a commercial, I probably do ;-)

=  

 

=  

=  

From: BIER [mailto:bier-bounces@ietf.org] On Beha= lf Of IJsbrand Wijnands (iwijnand)
Sent: Sunday, February 15, 2= 015 8:24 AM
To: <adrian@olddog.co.uk&= gt;
Cc: Joel Jaeggli; Greg Sheph= erd; bier@ietf.org; The IESG
Subject: Re: [Bier] Joel Jae= ggli's No Objection on charter-ietf-bier-00-01: (with COMMENT)

 

Hi Folks,

 

Procedures for stitching such 'domains' together are= documented in rfc6514 and called 'Segmented Inter-AS MVPN'. I think the ex= act same procedures can be applied to BIER domains. These procedures where developed in the context of L3VPN. If any = updates are need I would think this work belongs in BESS. So limiting the s= cope to single domain in the BIER charter is ok with me.<= /font>

 

Thx,

 

Ice.


Sent from my iPad


On 15 Feb 2015, at 10:50, Adrian Farrel <adrian@olddog.co.uk> wrote:

= While Alia may be right that no-one has discusse= d chaining BIER domains, the charter wording gave me the impression that this was "perfectly reasonable." Thus, a packet exiting one= domain might then be injected into a new domain.<= /p>

=  

= <gratuitous analogy>

= Consider, for example, the work that has been do= ne on P2MP RSVP-TE where the ingress domain builds a tree to reach all of the egress nodes it owns and also each of the downstream domains. B= ut it doesn't know the tree across the downstream domains.

= </gratuitous analogy>

=  

= And Joel's concern about looping is valid.

= Of course, a solution could be developed.=

=  

= But how about this charter limit the work to a s= ingle domain?

=  

= Adrian

=  

=  

From: BIER [mailto:bier-bounces@ietf.org= ] On Behalf Of Alia Atlas
Sent: 15 February 2015 00:20=
To: Joel Jaeggli
Cc: Greg Shepherd; bier@ietf.org; The IESG; Tony Przygienda
Subject: Re: [Bier] Joel Jae= ggli's No Objection on charter-ietf-bier-00-01: (with COMMENT)

 

Hi Joel,

 

On Sat, Feb 14, 2015 at 4:47 PM, Joel Jaeggli <joelja@bogus.com>= ; wrote:

Joel Jaeggli has entered the following ballot positi= on for
charter-ietf-bier-00-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-bier/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

So the size of the bier domain is bounded I suppose by the number of
egress points you're willing to include in your header. given the
inherent suitability of such a method for overlays it seems like it
distinctly bounds the size of such an overlay based on the header size/
if you chain bier domains (no subdomain) how do you do loop detection (or don't you).

 

The bier-ingress router can do a bit of ingress repl= ication, if needed.  Basically,

only one "word" of the bitmap is in the pa= cket and the bier-ingress replicates once

for each different word that needs to be sent to.&nb= sp; One of the questions, of course,

is how many bits are in a word.  At 1024 or 204= 8, that handles much larger networks

but requires more bits in the header to be available= for processing than at 256.

 

I haven't yet seen any ideas describing chaining bie= r domains.  I think between

bier domains it would default up to the tree-buildin= g protocol.  Possibly one of the

bier proponents will have more ideas.

 

Thanks for the early review!

Alia

 

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

--_000_2E4BB27CAB87BF43B4207C0E55860F18257772eusaamb103ericsso_-- From nobody Sun Feb 15 11:43:29 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844FB1A00E5; Sun, 15 Feb 2015 11:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 uLWQSG9idbTV; Sun, 15 Feb 2015 11:43:23 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8F51A00E7; Sun, 15 Feb 2015 11:43:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 457231C068A; Sun, 15 Feb 2015 11:43:23 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D71991C0331; Sun, 15 Feb 2015 11:43:21 -0800 (PST) Message-ID: <54E0F6B8.80305@joelhalpern.com> Date: Sun, 15 Feb 2015 14:42:48 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" , Brian Haberman References: <54DCAE4F.8050903@cisco.com>, <54DFB200.8070604@innovationslab.net> <60280EE7-6782-42DF-9CFF-5BD5F3C1D38B@cisco.com> In-Reply-To: <60280EE7-6782-42DF-9CFF-5BD5F3C1D38B@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Stewart Bryant \(stbryant\)" , "Alvaro Retana \(aretana\)" , "bier@ietf.org" , "iesg@ietf.org" , Adrian Farrel Subject: Re: [Bier] proposed BIER charter 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, 15 Feb 2015 19:43:24 -0000 Having been the routing AD who chartered the MPLS work in the first place, there was already significant deplopyment of something similar, and an understanding that the deployment might have to change. There were also many op[erators who were asking for the technology. And it was a natural evolution and replacement of an existing technology. Yours, Joel PS: We still made mistakes. The mess with CRLDP and RSVP-TE should have resulted, in my opinion, in the working group picking one or both ending up on experimental. Fortunately, that was pure control plane. And we did later pick one. On 2/14/15 8:00 PM, Rajiv Asati (rajiva) wrote: >> Given that we do not have a wealth of deployment experience with BIER, I >> think it is quite reasonable to start the process as an Experimental >> specification. > > We may find the above a bit odd, if we relate to how RFC3031/3032 (MPLS > architecture and encoding) were put on standards track right from the > getgo, despite having limited deployment experience with MPLS. > > Experimental in many circles play a significant mind-barrier game. ... From nobody Mon Feb 16 03:38:24 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3341A885E; Mon, 16 Feb 2015 03:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmi4HrWQw-r5; Mon, 16 Feb 2015 03:38:17 -0800 (PST) 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 090D81A8854; Mon, 16 Feb 2015 03:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1783; q=dns/txt; s=iport; t=1424086697; x=1425296297; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LA0D30xREjH5T5GKJvUlmM9EQTDUnPzdjck6eFfA7DU=; b=Hvjlj9dWz/n4fUcxYbKYVP3NyLIZ6pv8KDJYX36Eif4v3a/LQJEFeyw8 k2p0qOdV7WrOwAWHz5akLBEhftzEBnkIucMt5Qm4H2uMrklLjfwzMk2LN FwHQt/T5sgcqwB0ddje+7TqY7MRXuNFWWW/A4npjzUNMEXodpwHf5ktc8 s=; X-IronPort-AV: E=Sophos;i="5.09,587,1418083200"; d="scan'208";a="347148111" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 16 Feb 2015 11:38:15 +0000 Received: from [64.103.108.122] (dhcp-bdlk10-data-vlan301-64-103-108-122.cisco.com [64.103.108.122]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1GBcFdi021142; Mon, 16 Feb 2015 11:38:15 GMT Message-ID: <54E1D6A7.1040305@cisco.com> Date: Mon, 16 Feb 2015 11:38:15 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brian Haberman , "Rajiv Asati (rajiva)" References: <54DCAE4F.8050903@cisco.com>, <54DFB200.8070604@innovationslab.net> <60280EE7-6782-42DF-9CFF-5BD5F3C1D38B@cisco.com> <54E0CB50.2000202@innovationslab.net> In-Reply-To: <54E0CB50.2000202@innovationslab.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Alvaro Retana \(aretana\)" , "bier@ietf.org" , "iesg@ietf.org" , Adrian Farrel Subject: Re: [Bier] proposed BIER charter X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 11:38:19 -0000 On 15/02/2015 16:37, Brian Haberman wrote: > >> Experimental in many circles play a significant mind-barrier game. >> > I am not aware of those situations, but I am not involved in MPLS > circles. Can someone describe such a scenario? > Firstly experimental implies in most peoples mind "might not work". Secondly we tell everyone that experimental codepoints MUST NOT be deployed in production. There is a very real risk of the conflation of these two points into "this experimental RFC is on that may not work and must not be deployed in a production network". If you go back to my original point, I was saying that I thought that dictating the track at this stage was premature and that the decision should be made when documents were ready, and thus when more information was available. >> Part of the reason for me holding this view is that there is still >> some areas of work needed to understand how BIER will fit in the >> overall multicast architecture. >> >> Ummmm....we will certainly have work to do in not only understanding >> existing areas, but also exploring new areas (such as 6lopan) for >> BIER. But that's cant/mustn't be the reason to classify any work as >> experimental. >> > As I stated above, I am looking at this from the multicast (i.e., IP) > perspective. It took quite a few years before the community felt > comfortable moving PIM from Experimental to Standards Track. The key difference between this multicast technology and earlier such technologies is that classic m/c distributes client state through-out the network, which frankly does not scale, whereas this is a technology in which the client state is shared solely with the information distributor, which is intrinsically more scalable. - Stewart From nobody Mon Feb 16 05:57:44 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C5D1A1B51; Mon, 16 Feb 2015 05:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AD6pOjgAiiYT; Mon, 16 Feb 2015 05:57:35 -0800 (PST) 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 2757C1A1B4B; Mon, 16 Feb 2015 05:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46052; q=dns/txt; s=iport; t=1424095054; x=1425304654; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=GqGhR9jvsIXdIIuXvqmosMBKEmh0cJONkowtFCVDomo=; b=BTp9wGpPwMG6sE2Uw/fgnJ/spAlWjbl2dfFmn12mvS4xJwytGLSYqSg9 RbR7ASQeeOZDpA8PVMxDwBbk8qAi/i6e6VdlLX3YYyEDVYVd8xxRYSN9y 8iq8BHewiQ66vNkxo86FZ/f2pdwJzBLoT4VT/ySCS3HL1CriWE5B8gp+0 I=; X-IronPort-AV: E=Sophos;i="5.09,587,1418083200"; d="scan'208,217";a="351396089" 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; 16 Feb 2015 13:57:32 +0000 Received: from [10.147.62.73] (dhcp-bdlk10-vlan256-10-147-62-73.cisco.com [10.147.62.73]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1GDvWrT020924; Mon, 16 Feb 2015 13:57:32 GMT Message-ID: <54E1F74C.9090806@cisco.com> Date: Mon, 16 Feb 2015 13:57:32 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alia Atlas References: <54DCAE4F.8050903@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060608000706080802070603" Archived-At: Cc: Adrian Farrel , "bier@ietf.org" , "iesg@ietf.org" , Alvaro Retana Subject: Re: [Bier] proposed BIER charter X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 13:57:42 -0000 This is a multi-part message in MIME format. --------------060608000706080802070603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/02/2015 15:13, Alia Atlas wrote: > Stewart, > > I certainly appreciate your taking the time to provide feedback. I > understand that you > are excited by this technology and have urged that innovation needs > time and space > to be worked on before being evaluated by the harsh realities of the > marketplace and > interest in deployment. I think my three key points were: a) We should not prejudge the technology at this stage, but rather should take a contingency approach, i.e. make a decision when we need to make it and have more information, rather than make it now and risk either creating a self fulfilling prophecy, or needing to revisit this decision later with all the associated work. b) Listen to what David Ward was saying in his talk in Hawaii about the risk of the IETF becoming irrelevant in the face of the speed of open source. In this case we seem to be putting up barriers to speed of execution rather than breaking them down. c) Do not pre-judge how a technology of this type will be implemented given the re-balancing we are seeing between s/w and h/w, i.e. do not express a view on implementation technology in a charter. In the version of the charter I reviewed you explicitly called for a h/w implementation. > > On Thu, Feb 12, 2015 at 8:44 AM, Stewart Bryant > wrote: > > Alia > > I think that you are crossing far too many bridges before you get > to them > in terms of you expectation of where BIER will be deployed and how > it will be implemented. > > > I did read the use-cases and understand the primary motivation is for > MVPN > and EVPN which are deployed in the backbone of SP networks that operate at > high speeds. Even in data-centers, use of 10G links is common. > > The charter should not include such specific assumptions, particularly > given the fast moving changes that are happening in our industry > especially in the area of packet forwarding design. > > > What specifically are you objecting to? > > I have not seen such assumptions in other charters and I don't think > that they have a place in this one. > > > What specific assumption are you objecting to and what reasoning do > you have > beyond historical? > > In terms of choice of document stream (experimental vs PS), > that is a decision that can be taken at the time of publication > when more information will be available in terms of potential > market take-up, expected/actual deployment scenarios, > breadth of implementation and implementation experience. > > > At this time, a sufficiently compelling case has not been made to > convince that > PS is anywhere near appropriate for this change of adding a completely > new forwarding > algorithm and a fourth encapsulation to go with IPv4, IPv6, and MPLS > to the Internet > architecture for the next 15+ years. At this time we have no evidence either way, so why make a statement at all, why not gather the evidence as we do the engineering? In one of the cases (BEIR/MPLS) it is not clear that this is an extension beyond the norm. Certainly it seems nothing worse than VXLAN which is headed to be a de-facto standard. > > It is true that if that changes between now and when drafts are ready > to progress, that can > be revisited. > > There are WGs that have been chartered to do experimental work in the > past. I understand > that it is disappointing that there wasn't a strong case for more than > experimental at this time. > I have been extremely clear since the last IETF that I was only > considering Experimental for > the WG for the initial chartering. > > Whilst this technology may be deployed in the Internet core, > it my also be deployed at the edge where a much lower threshold > is applicable. > > > The technology needs to work in both locations - given the use-cases. > What specifically are > you objecting to? The edge case will surely be operating in an environment where s/w forwarding is in ascendency and thus may just be another NFV function. My concern is that you were asserting a h/w forwarding paradigm which is not the current industry trajectory for the edge. > > I fear that by introducing these caveats the IETF is entrenching the > perception that it slows technology down rather than embracing > and encouraging innovation. > > > By creating a WG for open collaboration and defining an ambitious new > forwarding technology, > the IETF is not embracing and encouraging innovation? I suppose it's > all in the eye of the > beholder - but to me it feels like "give an inch and get pushed for a > mile". I object to that statement which seems to me to be contra to the IETF ethos of community consensus. > > I would therefore suggest removing the text on implementation > styles and document stream constraints. > > > IF the encapsulations are specified in a way that two independent > interoperable implementations > are not available, it both increases the risk that we might end up > with two different versions - one > Experimental and another through bitter experience that is PS later - > and is a poor indication of > the lack of industry support and interest in the technology and its use. "IF the encapsulations are specified in a way that two independent interoperable implementations are not available, " Does not parse. The specification needs to be implementation agnostic and compatible with any reasonable implementations platform: h/w, f/w, s/w. Now you could perhaps assert that you need one of each style, but that was not what you proposed, you proposed h/w. - Stewart > Regards, > Alia > > > - Stewart > > > On 11/02/2015 20:44, Alia Atlas wrote: >> I have been working on getting a charter together for BIER with >> the intent of pushing for it to be chartered before the Dallas >> IETF. This has not yet gone through IESG review and it may have >> some aspects updated. >> >> Please send comments here. >> >> The charter can be found at >> http://datatracker.ietf.org/doc/charter-ietf-bier/ >> and is included below as well. >> >> >> WG Chairs: >> Greg Shepherd > >> Tony Przygienda > >> >> >> In conventional IP multicast forwarding, the packets of a given >> multicast "flow" are forwarded along a tree that has been constructed >> for the specific purpose of carrying that flow. This requires >> transit >> nodes to maintain state on a per-flow basis, and requires the transit >> nodes to participate in multicast-specific tree building protocols. >> The flow to which a packet belongs is determined by its IP source and >> destination address fields. >> >> BIER (Bit Index Explicit Replication) is an alternative method of >> multicast forwarding. It does not require any multicast-specific >> trees, and hence does not require any multicast-specific tree >> building >> protocols. Within a given "BIER domain", an ingress node >> encapsulates >> a multicast data packet in a "BIER header". The BIER header >> identifies the packet's egress nodes in that domain. Each possible >> egress node is represented by a a single bit within a bitstring; to >> send a packet to a particular set of egress nodes, the ingress node >> sets the bits for each of those egress nodes, and clears the other >> bits in the bistring. Each packet can then be forwarded along the >> unicast shortest path tree from the ingress node to the egress nodes. >> Thus there are no per-flow forwarding entries. >> >> Due to the particular sensitivity of adding new significant >> functionality into the data-plane at high link speeds, the BIER work >> will progress as Experimental. As described in item (9) below, the >> work may become Standards Track once there is sufficient experience >> with the benefits and downsides of the technology. >> >> BIER is initially chartered to do experimental work on this new >> multicast forwarding mechanism as follows: >> >> 1) BIER architecture: The WG will publish an architecture, based >> upon draft-wijnands-bier-architecture-04. It will include the >> normative algorithm for how BIER packet forwarding is done. It >> will specify the information that is required by a BIER header to >> support BIER forwarding. >> >> 2) BIER encapsulation: The working group should assume that the >> technology will need to be embedded in the data plane and operate >> at the highest packet line speeds. The WG will publish a document >> defining an MPLS-based encapsulation based upon >> draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need >> to have a high-quality and stable RFC for a new data-plane >> encapsulation, the MPLS-based encapsulation draft shall wait after >> WGLC and not progress to IETF Last Call until there are two >> independent interoperable implementations. >> >> As a secondary focus, the WG may also work on one non-MPLS >> data-plane encapsulation. This draft also shall wait after WGLC >> and not progress to IETF Last Call until there are two independent >> interoperable implementations. This draft must focus on and >> include the following details: >> >> a) What is the applicability of the encapsulation and for >> which >> use-cases is this encapsulation required? >> >> b) Does this proposed encapsulation imply any changes to the >> MPLS-based encapsulation? >> >> c) What design choices have been made for the encapsulation >> type and the included fields. >> >> d) The proposed encapsulation with considerations given to at >> least OAM, Class of Service, security, fragmentation, TTL. >> >> 3) Transition Mechanisms: The WG will describe how BIER can be >> partially deployed and still provide useful functionality. A >> minimum of the necessary mechanisms to support incremental >> deployment and/or managing different BIER mask-length >> compatibility >> may be defined. Each such mechanism must include an applicability >> statement to differentiate its necessity from other proposed >> mechanisms. >> >> 4) Applicability Statements: The WG will work on a document >> describing how BIER can be applied to multicast L3VPN and to EVPN. >> This draft will describe what mechanism is used to communicate the >> group membership between the ingress router and the egress >> routers, >> what scalability considerations may arise, and any deployment >> considerations. >> >> 5) Use Case: The WG may produce one use-case document that clearly >> articulates the potential benefits of BIER for different >> use-cases. >> This would be based upon draft-kumar-bier-use-cases-01. >> >> 6) OAM: The WG will describe how OAM will work in a BIER >> domain and >> what simplifications BIER offers for managing the multicast >> traffic. A strong preference will be given to extensions to >> existing protocols. >> >> 7) Management models: The WG may work on YANG models and, if >> needed, >> MIB modules to support common manageability. >> >> 8) IGP extensions. When a BIER domain falls within a "link >> state IGP"" >> network, the information needed to set up the BIER forwarding >> tables >> (e.g., the mapping between a given bit position and a given egress >> router) may be carried in the link state advertisements of the >> IGP. The >> link state advertisments may also carry other information >> related to >> forwarding (e.g., the IGP may support multiple topologies, in >> which case >> it may be necessary to advertise which topologies are to be >> used for BIER >> forwarding). Any necessary extensions to the IGP will be >> specified by >> the WG, in cooperation with the ISIS and OSPF WGs. >> >> 9) Deployment Experience: Once there is deployment experience, the >> WG will produce a document describing the benefits, problems, and >> trade-offs for using BIER instead of traditional multicast >> forwarding mechanisms. Ideally, this should also contain an >> analysis of the impact and benefit of the new BIER data-plane to >> the overall Internet architecture. This document is intended to be >> used to evaluate whether to recharter BIER to produce Standards >> Track RFCs. >> >> The BIER working group will coordinate with several different working >> groups and must include the relevant other working groups during >> working group last call on the relevant drafts. BIER will coordinate >> with MPLS on the MPLS-based encapsulation and associated MPLS-based >> OAM mechanisms. BIER will coordinate with ISIS and OSPF on >> extensions >> to flood BIER-related information. BIER will coordinate with BESS and >> IDR on the applicability of existing BGP-based mechanisms for >> providing multicast group membership information. >> >> Regards, >> Alia >> >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------060608000706080802070603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/02/2015 15:13, Alia Atlas wrote:
Stewart,

I certainly appreciate your taking the time to provide feedback.Ā  I understand that you
are excited by this technology and have urged that innovation needs time and space
to be worked on before being evaluated by the harsh realities of the marketplace andĀ 
interest in deployment.
I think my three key points were:

a) We should not prejudge the technology at this stage, but rather should
take a contingency approach, i.e. make a decision when we need to make
it and have more information, rather than make it now and risk either
creating a self fulfilling prophecy, or needing to revisit this decision
later with all the associated work.

b) Listen to what David Ward was saying in his talk in Hawaii about the
risk of the IETF becoming irrelevant in the face of the speed of open source.
In this case we seem to be putting up barriers to speed of execution
rather than breaking them down.

c) Do not pre-judge how a technology of this type will be implemented
given the re-balancing we are seeing between s/w and h/w, i.e. do not
express a view on implementation technology in a charter. In the version
of the charter I reviewed you explicitly called for a h/w implementation.



On Thu, Feb 12, 2015 at 8:44 AM, Stewart Bryant <stbryant@cisco.com> wrote:
Alia

I think that you are crossing far too many bridges before you get to them
in terms of you expectation of where BIER will be deployed and how
it will be implemented.

I did read the use-cases and understand the primary motivation is for MVPNĀ 
and EVPN which are deployed in the backbone of SP networks that operate at
high speeds.Ā  Even in data-centers, use of 10G links is common.
Ā 
The charter should not include such specific assumptions, particularly
given the fast moving changes that are happening in our industry
especially in the area of packet forwarding design.

What specifically are you objecting to?Ā 
Ā 
I have not seen such assumptions in other charters and I don't think
that they have a place in this one.

What specific assumption are you objecting to and what reasoning do you have
beyond historical?
Ā 
In terms of choice of document stream (experimental vs PS),
that is a decision that can be taken at the time of publication
when more information will be available in terms of potential
market take-up, expected/actual deployment scenarios,
breadth of implementation and implementation experience.

At this time, a sufficiently compelling case has not been made to convince that
PS is anywhere near appropriate for this change of adding a completely new forwardingĀ 
algorithm and a fourth Ā encapsulation to go with IPv4, IPv6, and MPLS to the InternetĀ 
architecture for the next 15+ years.
At this time we have no evidence either way, so why make
a statement at all, why not gather the evidence as we do the
engineering?

In one of the cases (BEIR/MPLS) it is not clear that this is an extension
beyond the norm. Certainly itĀ  seems nothing worse than VXLAN
which is headed to be a de-facto standard.


It is true that if that changes between now and when drafts are ready to progress, that can
be revisited.

There are WGs that have been chartered to do experimental work in the past.Ā  I understand
that it is disappointing that there wasn't a strong case for more than experimental at this time.
Ā 
I have been extremely clear since the last IETF that I was only considering Experimental forĀ 
the WG for the initial chartering.

Whilst this technology may be deployed in the Internet core,
it my also be deployed at the edge where a much lower threshold
is applicable.

The technology needs to work in both locations - given the use-cases.Ā  What specifically are
you objecting to?
The edge case will surely be operating in an environment where
s/w forwarding is in ascendency and thus may just be another
NFV function. My concern is that you were asserting a h/w forwarding
paradigm which is not the current industry trajectory for the edge.
Ā 
I fear that by introducing these caveats the IETF is entrenching the
perception that it slows technology down rather than embracing
and encouraging innovation.

By creating a WG for open collaboration and defining an ambitious new forwarding technology,
the IETF is not embracing and encouraging innovation?Ā  I suppose it's all in the eye of the

beholder - but to me it feels like "give an inch and get pushed for a mile".
I object to that statement which seems to me to be contra to the IETF
ethos of community consensus.

Ā 
I would therefore suggest removing the text on implementation
styles and document stream constraints.

IF the encapsulations are specified in a way that two independent interoperable implementations
are not available, it both increases the risk that we might end up with two different versions - one
Experimental and another through bitter experience that is PS later - and is a poor indication of
the lack of industry support and interest in the technology and its use.
"IF the encapsulations are specified in a way that two independent interoperable implementations
are not available, " Does not parse.

The specification needs to be implementation agnostic and compatible with any
reasonable implementations platform: h/w, f/w, s/w. Now you could perhaps
assert that you need one of each style, but that was not what you proposed, you
proposed h/w.

- Stewart

Ā 
Regards,
Alia


- Stewart


On 11/02/2015 20:44, Alia Atlas wrote:
I have been working on getting a charter together for BIER with the intent of pushing for it to be chartered before the Dallas IETF.Ā  This has not yet gone through IESG review and it may have some aspects updated.

Please send comments here.

and is included below as well.


WG Chairs:
Ā  Greg Shepherd Ā <gjshep@gmail.com>
Ā  Tony Przygienda <tonysietf@gmail.com>


In conventional IP multicast forwarding, the packets of a given
multicast "flow" are forwarded along a tree that has been constructed
for the specific purpose of carrying that flow.Ā  This requires transit
nodes to maintain state on a per-flow basis, and requires the transit
nodes to participate in multicast-specific tree building protocols.
The flow to which a packet belongs is determined by its IP source and
destination address fields.

BIER (Bit Index Explicit Replication) is an alternative method of
multicast forwarding.Ā  It does not require any multicast-specific
trees, and hence does not require any multicast-specific tree building
protocols.Ā  Within a given "BIER domain", an ingress node encapsulates
a multicast data packet in a "BIER header".Ā  The BIER header
identifies the packet's egress nodes in that domain.Ā  Each possible
egress node is represented by a a single bit within a bitstring; to
send a packet to a particular set of egress nodes, the ingress node
sets the bits for each of those egress nodes, and clears the other
bits in the bistring.Ā  Each packet can then be forwarded along the
unicast shortest path tree from the ingress node to the egress nodes.
Thus there are no per-flow forwarding entries.

Due to the particular sensitivity of adding new significant
functionality into the data-plane at high link speeds, the BIER work
will progress as Experimental.Ā  As described in item (9) below, the
work may become Standards Track once there is sufficient experience
with the benefits and downsides of the technology.

BIER is initially chartered to do experimental work on this new
multicast forwarding mechanism as follows:

Ā  Ā 1) BIER architecture: The WG will publish an architecture, based
Ā  Ā upon draft-wijnands-bier-architecture-04.Ā  It will include the
Ā  Ā normative algorithm for how BIER packet forwarding is done.Ā  It
Ā  Ā will specify the information that is required by a BIER header to
Ā  Ā support BIER forwarding.

Ā  Ā 2) BIER encapsulation: The working group should assume that the
Ā  Ā technology will need to be embedded in the data plane and operate
Ā  Ā at the highest packet line speeds.Ā  The WG will publish a document
Ā  Ā defining an MPLS-based encapsulation based upon
Ā  Ā draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need
Ā  Ā to have a high-quality and stable RFC for a new data-plane
Ā  Ā encapsulation, the MPLS-based encapsulation draft shall wait after
Ā  Ā WGLC and not progress to IETF Last Call until there are two
Ā  Ā independent interoperable implementations.

Ā  Ā As a secondary focus, the WG may also work on one non-MPLS
Ā  Ā data-plane encapsulation.Ā  This draft also shall wait after WGLC
Ā  Ā and not progress to IETF Last Call until there are two independent
Ā  Ā interoperable implementations.Ā  This draft must focus on and
Ā  Ā include the following details:

Ā  Ā  Ā  Ā a) What is the applicability of the encapsulation and for which
Ā  Ā  Ā  Ā use-cases is this encapsulation required?

Ā  Ā  Ā  Ā b) Does this proposed encapsulation imply any changes to the
Ā  Ā  Ā  Ā MPLS-based encapsulation?

Ā  Ā  Ā  Ā c) What design choices have been made for the encapsulation
Ā  Ā  Ā  Ā type and the included fields.

Ā  Ā  Ā  Ā d) The proposed encapsulation with considerations given to at
Ā  Ā  Ā  Ā least OAM, Class of Service, security, fragmentation, TTL.

Ā  Ā 3) Transition Mechanisms: The WG will describe how BIER can be
Ā  Ā partially deployed and still provide useful functionality. Ā A
Ā  Ā minimum of the necessary mechanisms to support incremental
Ā  Ā deployment and/or managing different BIER mask-length compatibility
Ā  Ā may be defined.Ā  Each such mechanism must include an applicability
Ā  Ā statement to differentiate its necessity from other proposed
Ā  Ā mechanisms.

Ā  Ā 4) Applicability Statements: The WG will work on a document
Ā  Ā describing how BIER can be applied to multicast L3VPN and to EVPN.
Ā  Ā This draft will describe what mechanism is used to communicate the
Ā  Ā group membership between the ingress router and the egress routers,
Ā  Ā what scalability considerations may arise, and any deployment
Ā  Ā considerations.Ā 

Ā  Ā 5) Use Case: The WG may produce one use-case document that clearly
Ā  Ā articulates the potential benefits of BIER for different use-cases.
Ā  Ā This would be based upon draft-kumar-bier-use-cases-01.

Ā  Ā 6) OAM: The WG will describe how OAM will work in a BIER domain and
Ā  Ā what simplifications BIER offers for managing the multicast
Ā  Ā traffic.Ā  A strong preference will be given to extensions to
Ā  Ā existing protocols.

Ā  Ā 7) Management models: The WG may work on YANG models and, if needed,
Ā  Ā MIB modules to support common manageability.

Ā  Ā 8) IGP extensions.Ā  When a BIER domain falls within a "link state IGP""
Ā  Ā network, the information needed to set up the BIER forwarding tables
Ā  Ā (e.g., the mapping between a given bit position and a given egress
Ā  Ā router) may be carried in the link state advertisements of the IGP.Ā  The
Ā  Ā link state advertisments may also carry other information related to
Ā  Ā forwarding (e.g., the IGP may support multiple topologies, in which case
Ā  Ā it may be necessary to advertise which topologies are to be used for BIER
Ā  Ā forwarding).Ā  Any necessary extensions to the IGP will be specified by
Ā  Ā the WG, in cooperation with the ISIS and OSPF WGs.

Ā  Ā 9) Deployment Experience: Once there is deployment experience, the
Ā  Ā WG will produce a document describing the benefits, problems, and
Ā  Ā trade-offs for using BIER instead of traditional multicast
Ā  Ā forwarding mechanisms.Ā  Ideally, this should also contain an
Ā  Ā analysis of the impact and benefit of the new BIER data-plane to
Ā  Ā the overall Internet architecture.Ā  This document is intended to be
Ā  Ā used to evaluate whether to recharter BIER to produce Standards
Ā  Ā Track RFCs.

The BIER working group will coordinate with several different working
groups and must include the relevant other working groups during
working group last call on the relevant drafts.Ā  BIER will coordinate
with MPLS on the MPLS-based encapsulation and associated MPLS-based
OAM mechanisms.Ā  BIER will coordinate with ISIS and OSPF on extensions
to flood BIER-related information.Ā  BIER will coordinate with BESS and
IDR on the applicability of existing BGP-based mechanisms for
providing multicast group membership information.

Regards,
Alia


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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html





-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------060608000706080802070603-- From nobody Mon Feb 16 17:30:58 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD0B1A01E7; Mon, 16 Feb 2015 17:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsnT3JO_8djY; Mon, 16 Feb 2015 17:30:55 -0800 (PST) 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 A8EB71A040C; Mon, 16 Feb 2015 17:30:54 -0800 (PST) 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 BSS19333; Tue, 17 Feb 2015 01:30:53 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Feb 2015 01:30:52 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Tue, 17 Feb 2015 09:30:47 +0800 From: Xuxiaohu To: "bier@ietf.org" , idr wg Thread-Topic: New Version Notification for draft-xu-idr-bier-extensions-00.txt Thread-Index: AQHQSlCq3k5gpZgciU2QvKfhI3xxk5z0Dcqg Date: Tue, 17 Feb 2015 01:30:47 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083097F5@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.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Bier] FW: New Version Notification for draft-xu-idr-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, 17 Feb 2015 01:30:56 -0000 SGkgYWxsLA0KDQpBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJkcywNClhp YW9odQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDog VHVlc2RheSwgRmVicnVhcnkgMTcsIDIwMTUgOToyNiBBTQ0KPiBUbzogTWFjaCBDaGVuOyBYdXhp YW9odTsgWHV4aWFvaHU7IElKc2JyYW5kIFdpam5hbmRzOyBLZXl1ciBQYXRlbDsgS2V5dXIgUGF0 ZWw7DQo+IElKc2JyYW5kIFdpam5hbmRzOyBNYWNoIENoZW4NCj4gU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1pZHItYmllci1leHRlbnNpb25zLTAwLnR4dA0K PiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14dS1pZHItYmllci1leHRlbnNp b25zLTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW9odSBY dSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQt eHUtaWRyLWJpZXItZXh0ZW5zaW9ucw0KPiBSZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlCR1AgRXh0 ZW5zaW9ucyBmb3IgQklFUg0KPiBEb2N1bWVudCBkYXRlOgkyMDE1LTAyLTE2DQo+IEdyb3VwOgkJ SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJNw0KPiBVUkw6DQo+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1LWlkci1iaWVyLWV4dGVuc2lvbnMtMDAu dHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC14dS1pZHItYmllci1leHRlbnNpb25zLw0KPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtaWRyLWJpZXItZXh0ZW5zaW9ucy0wMA0KPiANCj4g DQo+IEFic3RyYWN0Og0KPiAgICBCaXQgSW5kZXggRXhwbGljaXQgUmVwbGljYXRpb24gKEJJRVIp IGlzIGEgbmV3IG11bHRpY2FzdCBmb3J3YXJkaW5nDQo+ICAgIGFyY2hpdGVjdHVyZSB3aGljaCBk b2Vzbid0IHJlcXVpcmUgYW4gZXhwbGljaXQgdHJlZS1idWlsZGluZyBwcm90b2NvbA0KPiAgICBh bmQgZG9lc24ndCByZXF1aXJlIGludGVybWVkaWF0ZSByb3V0ZXJzIHRvIG1haW50YWluIGFueSBt dWx0aWNhc3QNCj4gICAgc3RhdGUuICBCSUVSIGlzIGFwcGxpY2FibGUgaW4gYSBtdWx0aS10ZW5h bnQgZGF0YSBjZW50ZXIgbmV0d29yaw0KPiAgICBlbnZpb3Jvbm1lbnQgZm9yIGVmZmljaWVudCBk ZWxpdmVyeSBvZiBCcm9hZGNhc3QsIFVua25vd24tdW5pY2FzdCBhbmQNCj4gICAgTXVsdGljYXN0 IChCVU0pIHRyYWZmaWMgd2hpbGUgZWxpbWluYXRpbmcgdGhlIG5lZWQgZm9yIG1haXRhaW5pbmcg YQ0KPiAgICBodWdlIGFtb3VudCBvZiBtdWx0aWNhc3Qgc3RhdGUgaW4gYW4gdW5kZXJsYXkuICBU aGlzIGRvY3VtZW50DQo+ICAgIGRlc2NyaWJlcyBCR1AgZXh0ZW5zaW9ucyBmb3IgYWR2ZXJ0aXNp bmcgdGhlIEJJRVItc3BlY2lmaWMNCj4gICAgaW5mb3JtYXRpb24uICBUaGVzZSBleHRlc25pb25z IGFyZSBhcHBsaWNhYmxlIGluIHRob3NlIG11bHRpLXRlbmFudA0KPiAgICBkYXRhIGNlbnRlcnMg d2hlcmUgQkdQIGluc3RlYWQgb2YgSUdQIGlzIGRlcGxveWVkIGFzIGFuIHVuZGVybGF5IGZvcg0K PiAgICBuZXR3b3JrIHJlYWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50LiAgVGhlc2UgZXh0ZW5zaW9u cyBtYXkgYWxzbyBiZQ0KPiAgICBhcHBsaWNhYmxlIGluIG90aGVyIHNjZW5hcmlvcy4NCj4gDQo+ IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Feb 16 18:06:49 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03CE1A6F5D; Mon, 16 Feb 2015 18:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEDxcUd9Lxor; Mon, 16 Feb 2015 18:06:44 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326C31A6F3C; Mon, 16 Feb 2015 18:06:44 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-c9-54e2421f72aa Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 61.1D.25146.F1242E45; Mon, 16 Feb 2015 20:16:48 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Mon, 16 Feb 2015 21:06:41 -0500 From: Antoni Przygienda To: Xuxiaohu , "bier@ietf.org" , idr wg Thread-Topic: [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-00.txt Thread-Index: AQHQSlCq3k5gpZgciU2QvKfhI3xxk5z0DcqggAADj/A= Date: Tue, 17 Feb 2015 02:06:41 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1825C17B@eusaamb103.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083097F5@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083097F5@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.10] Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F1825C17Beusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXSPt66C06MQg40fuSyWztjDZPHq9jMm i63nVzE6MHu0HHnL6rFkyU+mAKYoLpuU1JzMstQifbsEroyT22azFzR/Zqw4e2g1SwPjn+uM XYycHBICJhKbjz9lgrDFJC7cW8/WxcjFISRwhFFi6vRHrCAJIYHljBIHP1uC2GwCFhKXvz1l 7mLk4BARiJH4OJELJCwsECVx/PhPsJkiAtESq95uhrKtJJ72XGEGsVkEVCWOn3zJBmLzCnhL HF62gx1ifKjEvntdYCM5BcIkdn4NBwkzAp3z/dQasNOYBcQlbj2ZD3WmgMSSPeeZIWxRiZeP /7FC2EoSk5aeY4Woz5do+nmfGWKVoMTJmU9YJjCKzEIyahaSsllIyiDiOhILdn9ig7C1JZYt fM0MY5858JgJWXwBI/sqRo7S4tSy3HQjw02MwDg6JsHmuINxwSfLQ4wCHIxKPLwGdo9ChFgT y4orcw8xSnOwKInzll05GCIkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUfSqpk37tDd/98m9 2diezGC2b+f7u1e9/8TPTZg3r2El15PfF9zSGHrCH1/R5982WZj9/R2HwAS5tScZGPQFHm2f vadoK8uf83ZyGXyXHBqCA6eGna2d3NWlGPjjrObuR483v8oVXMfwPrP0UHIqc7StHEvqXSWx uTcMTjU6fDLaezXTv4/RXImlOCPRUIu5qDgRAJEpiz6EAgAA Archived-At: Subject: Re: [Bier] FW: New Version Notification for draft-xu-idr-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, 17 Feb 2015 02:06:47 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F1825C17Beusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Xuxiaohu, thanks for the work. multiple things: The BFR-ID TLV is encoded as follows: Type:TBD2 Length:5 Value: contains a two-octet BFR-ID. I am missing here the indication of subdomain-id since without that, the BF= R-ID will easily collide within the BIER domain advertising the BGP info @ = the edge. The BSL TLV is encoded as follows: Type:TBD3 Length:4 Value: contains a one-octet BSL which indicates the length of the Bitstring in 4-octets. Is this encoded equivalent to MPLS draft ? Indicate so and indicate WHICH b= its are used and which are reserved. If not, indicate how e.g. 33 as bitst= ring length should be treated if e.g. the ensuing encaps cannot deal with i= t ? The BIER MPLS Encapsualtion TLV is encoded as follows: Type:TBD4 Length:7 Value: contains a one-octet Label Range Size field indicating the size of the label range, and a 3-octect Label Rang Base field where the 20 rightmost bits represent the first label in the label range. indicate that the other bits are reserved/must be ignored/send 0 Generally, it is considered de rigeur to make nice pictures of those TLVs t= o make the documents more readable. I suggest doing so. Another question here is what happens when multiple eBPG edges of an AD adv= ertise this attribute. Is the preference driven by MED [or another attribut= e?] based e.g. on the IGP distance within AD to the BFR ? Is the expectation that each BGP router advertising this is BFR itself ? Or= has capabilities to unicast tunnel into the BIER domain ? Overall, this seems to imply somewhat that BIER domain is aligned with the = whole IGP domain (and not areas) and e.g. two OSPF areas cannot be two BIER= domains. This is an interesting architectural question that wasn't brough= t up yet ? thanks --- tony > -----Original Message----- > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Monday, February 16, 2015 5:31 PM > To: bier@ietf.org; idr wg > Subject: [Bier] FW: New Version Notification for draft-xu-idr-bier-extens= ions- > 00.txt > > Hi all, > > Any comments are welcome. > > Best regards, > Xiaohu > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto= :internet-drafts@ietf.org] > > Sent: Tuesday, February 17, 2015 9:26 AM > > To: Mach Chen; Xuxiaohu; Xuxiaohu; IJsbrand Wijnands; Keyur Patel; > > Keyur Patel; IJsbrand Wijnands; Mach Chen > > Subject: New Version Notification for > > draft-xu-idr-bier-extensions-00.txt > > > > > > A new version of I-D, draft-xu-idr-bier-extensions-00.txt > > has been successfully submitted by Xiaohu Xu and posted to the IETF > repository. > > > > Name: draft-xu-idr-bier-extensions > > Revision: 00 > > Title: BGP Extensions for BIER > > Document date: 2015-02-16 > > Group: Individual Submission > > Pages: 7 > > URL: > > http://www.ietf.org/internet-drafts/draft-xu-idr-bier-extensions-00.txt > > Status: https://datatracker.ietf.org/doc/draft-xu-idr-bier-exte= nsions/ > > Htmlized: http://tools.ietf.org/html/draft-xu-idr-bier-extensions= -00 > > > > > > Abstract: > > Bit Index Explicit Replication (BIER) is a new multicast forwarding > > architecture which doesn't require an explicit tree-building protoco= l > > and doesn't require intermediate routers to maintain any multicast > > state. BIER is applicable in a multi-tenant data center network > > envioronment for efficient delivery of Broadcast, Unknown-unicast an= d > > Multicast (BUM) traffic while eliminating the need for maitaining a > > huge amount of multicast state in an underlay. This document > > describes BGP extensions for advertising the BIER-specific > > information. These extesnions are applicable in those multi-tenant > > data centers where BGP instead of IGP is deployed as an underlay for > > network reachability advertisement. These extensions may also be > > applicable in other scenarios. > > > > > > > > > > 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. > > > > The IETF Secretariat > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier --_000_2E4BB27CAB87BF43B4207C0E55860F1825C17Beusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<hat type=3D”individual cat contributor”&g= t;

 

Xuxiaohu, thanks for the work.

 

multiple things:

 

  The BFR-ID TLV is encoded as follows:=

 

      Type:TBD2=

 

      Length:5<= /strong>

 

      Value: contains a two-octet BFR-ID.

 

I am missing here the indication of subdomain-id since wi= thout that, the BFR-ID will easily collide within the BIER domain advertisi= ng the BGP info @ the edge.

 

The BSL TLV is encoded as follows:

 

      Type:TBD3<= /b>

 

      Length:4

 

      Value: contains a one-octet BSL whi= ch indicates the length of the

      Bitstring in 4-octets.

 <= /o:p>

Is this encoded equivalent to MPLS draft ? Indicate so an= d indicate WHICH bits are used and which are reserved. If not, indicate how= e.g.  33 as bitstring length should be treated if e.g. the ensuing encaps cannot deal with it ?=

 

   The BIER MPLS Encapsualtion TLV is encoded as follows= :

 

      Type:TBD4<= /b>

 

      Length:7

 

      Value: contains a one-octet Label R= ange Size field indicating the

      size of the label range, and a 3-oc= tect Label Rang Base field

      where the 20 rightmost bits represe= nt the first label in the label

      range.=

 

indicate that the other bits are reserved/must be ignored= /send 0

 

Generally, it is considered de rigeur to make nice pictur= es of those TLVs to make the documents more readable. I suggest doing so.

 

Another question here is what happens when multiple eBPG = edges of an AD advertise this attribute. Is the preference driven by MED [o= r another attribute?] based e.g. on the IGP distance within AD to the BFR ?

 

Is the expectation that each BGP router advertising this = is BFR itself ? Or has capabilities to unicast tunnel into the BIER domain = ?

 

Overall, this seems to imply somewhat that BIER domain is= aligned with the whole IGP domain (and not areas) and e.g. two OSPF areas = cannot be two BIER domains.  This is an interesting architectural question that wasn’t brought up yet ?=

 

</hat>

 

thanks

 

--- tony

 

> -----Original Message-----

> From: BIER [mailto:bier-bounces@ietf.org] On Behalf = Of Xuxiaohu

> Sent: Monday, February 16, 2015 5:31 PM

> To: bier@ietf.org; idr wg

> Subject: [Bier] FW: New Version Notification for dra= ft-xu-idr-bier-extensions-

> 00.txt

>

> Hi all,

>

> Any comments are welcome.

>

> Best regards,

> Xiaohu

>

> > -----Original Message-----

> > From: internet-drafts@ietf.org [mailto:internet-= drafts@ietf.org]

> > Sent: Tuesday, February 17, 2015 9:26 AM=

> > To: Mach Chen; Xuxiaohu; Xuxiaohu; IJsbrand Wij= nands; Keyur Patel;

> > Keyur Patel; IJsbrand Wijnands; Mach Chen

> > Subject: New Version Notification for

> > draft-xu-idr-bier-extensions-00.txt

> >

> >

> > A new version of I-D, draft-xu-idr-bier-extensi= ons-00.txt

> > has been successfully submitted by Xiaohu Xu an= d posted to the IETF

> repository.

> >

> > Name:       =             &nb= sp;      draft-xu-idr-bier-extensions

> > Revision:       0= 0

> > Title:       = ;            &n= bsp;         BGP Extensions for BIE= R

> > Document date:     &nb= sp;   2015-02-16

> > Group:       = ;            &n= bsp;      Individual Submission

> > Pages:       = ;            &n= bsp;       7

> > URL:

> > http://www.ietf.org/internet-drafts/draft-xu-idr-bier-extensions-00.txt

> > Status:      &nbs= p;  = https://datatracker.ietf.org/doc/draft-xu-idr-bier-extensions/

> > Htmlized:       htt= p://tools.ietf.org/html/draft-xu-idr-bier-extensions-00

> >

> >

> > Abstract:

> >    Bit Index Explicit Replicatio= n (BIER) is a new multicast forwarding

> >    architecture which doesn't re= quire an explicit tree-building protocol

> >    and doesn't require intermedi= ate routers to maintain any multicast

> >    state.  BIER is applicab= le in a multi-tenant data center network

> >    envioronment for efficient de= livery of Broadcast, Unknown-unicast and

> >    Multicast (BUM) traffic while= eliminating the need for maitaining a

> >    huge amount of multicast stat= e in an underlay.  This document

> >    describes BGP extensions for = advertising the BIER-specific

> >    information.  These exte= snions are applicable in those multi-tenant

> >    data centers where BGP instea= d of IGP is deployed as an underlay for

> >    network reachability advertis= ement.  These extensions may also be

> >    applicable in other scenarios= .

> >

> >

> >

> >

> > Please note that it may take a couple of minute= s from the time of

> > submission until the htmlized version and diff = are available at tools.ietf.org.

> >

> > The IETF Secretariat

>

> _______________________________________________

> BIER mailing list

> BIER@ietf.org

> https://www.ietf.or= g/mailman/listinfo/bier

--_000_2E4BB27CAB87BF43B4207C0E55860F1825C17Beusaamb103ericsso_-- From nobody Mon Feb 16 18:46:45 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AAA1A86E9 for ; Mon, 16 Feb 2015 18:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQPcsZ20qSyV for ; Mon, 16 Feb 2015 18:46:42 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7113C1A86E2 for ; Mon, 16 Feb 2015 18:46:42 -0800 (PST) Received: by mail-qg0-f43.google.com with SMTP id i50so26227454qgf.2 for ; Mon, 16 Feb 2015 18:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=pj6724C+FeFsjhwyVKZbH2JuB36v8BDcSdBxfSmRHvI=; b=XTzwkBPo40ThEXXoYZOxlRCTjmnNObI/W0kxFrPKKisoUOHdWJkQbZUBuAPZNiM8O5 od+OzywST7ZtZrCslP7EQALc+7BU6xcO/LY2ck+ieUDWuIfkOq4viTFGkC51BQmctvZ1 OAeVQHmEiRNAMi9NNeUQdQ7Rg10gK15OBiOtM8opPsAZtruu6s0qCpDLNiLEME8a2evS O3Vl8Etdh/npWyPrKQXQz8YrspbqQ2h6iawVjG8arycUHI/jZ8kxiM/r3wIUHyzkU2Zy S+g9pHaKIJapUYBZ1L4yLSYnSa4xnFpX381ZAdXGKVnfppA6q1YZpDJmgzzmT5uVLtCt 4WOA== X-Received: by 10.140.22.8 with SMTP id 8mr696125qgm.72.1424141201685; Mon, 16 Feb 2015 18:46:41 -0800 (PST) Received: from [10.189.137.177] ([166.170.34.41]) by mx.google.com with ESMTPSA id n34sm3211249qge.27.2015.02.16.18.46.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Feb 2015 18:46:40 -0800 (PST) From: Greg Shepherd Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D167) Message-Id: Date: Mon, 16 Feb 2015 21:46:39 -0500 To: bier@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: Subject: [Bier] Call for Agenda Items 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, 17 Feb 2015 02:46:44 -0000 It's not yet clear whether we'll be a WG or a second BOF in Dallas, but this= won't change the majority of our work items. So please send your request fo= r an agenda slot w/ doc/title and required time, and we can get ready for BI= ER in Dallas! Thanks, Greg Sent from my iPhone= From nobody Mon Feb 16 19:09:00 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747421A8953; Mon, 16 Feb 2015 19:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ux67wckMjm5h; Mon, 16 Feb 2015 19:08:55 -0800 (PST) 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 E7E811A86DE; Mon, 16 Feb 2015 19:08:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSS24979; Tue, 17 Feb 2015 03:08:52 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Feb 2015 03:08:51 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 17 Feb 2015 11:08:44 +0800 From: Xuxiaohu To: Antoni Przygienda , "bier@ietf.org" , idr wg Thread-Topic: [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-00.txt Thread-Index: AQHQSlZlMR85vC1xX0KsHdMGHaa/oZz0Gozg Date: Tue, 17 Feb 2015 03:08:44 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083098C8@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083097F5@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F1825C17B@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1825C17B@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.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083098C8NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Bier] FW: New Version Notification for draft-xu-idr-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, 17 Feb 2015 03:08:58 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083098C8NKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tony, Thanks a lot for your valuable comments and suggestion. Please see my respo= nse inline. From: Antoni Przygienda [mailto:antoni.przygienda@ericsson.com] Sent: Tuesday, February 17, 2015 10:07 AM To: Xuxiaohu; bier@ietf.org; idr wg Subject: RE: [Bier] FW: New Version Notification for draft-xu-idr-bier-exte= nsions-00.txt Xuxiaohu, thanks for the work. multiple things: The BFR-ID TLV is encoded as follows: Type:TBD2 Length:5 Value: contains a two-octet BFR-ID. I am missing here the indication of subdomain-id since without that, the BF= R-ID will easily collide within the BIER domain advertising the BGP info @ = the edge. [Xiaohu] Thanks for point it out. Will fix it in the next version. The BSL TLV is encoded as follows: Type:TBD3 Length:4 Value: contains a one-octet BSL which indicates the length of the Bitstring in 4-octets. Is this encoded equivalent to MPLS draft ? Indicate so and indicate WHICH b= its are used and which are reserved. If not, indicate how e.g. 33 as bitst= ring length should be treated if e.g. the ensuing encaps cannot deal with i= t ? [Xiaohu] IMHO, it'd better to specify the legal BSL values in the BIER arch= draft which should be independent of specific BIER encapsulations. The BIER MPLS Encapsualtion TLV is encoded as follows: Type:TBD4 Length:7 Value: contains a one-octet Label Range Size field indicating the size of the label range, and a 3-octect Label Rang Base field where the 20 rightmost bits represent the first label in the label range. indicate that the other bits are reserved/must be ignored/send 0 Generally, it is considered de rigeur to make nice pictures of those TLVs t= o make the documents more readable. I suggest doing so. [Xiaohu] Thanks for the above suggestions. Will fix them in the next versio= n. Another question here is what happens when multiple eBPG edges of an AD adv= ertise this attribute. Is the preference driven by MED [or another attribut= e?] based e.g. on the IGP distance within AD to the BFR ? [Xiaohu] I think so. Is the expectation that each BGP router advertising this is BFR itself ? Or= has capabilities to unicast tunnel into the BIER domain ? [Xiaohu]Since the BIER attribute is an optional, transitive BGP path attrib= ute, it should support the scenario where a BGP speaker is allowed to tunne= l a BIER packet or the payload of a BIER packet to the BFER directly if the= BGP next-hop is a non-BFR. Furthermore, it should support as well the scen= ario where a BGP speaker is allowed to tunnel a BIER packet to the BGP next= -hop if these two BGP peers are not directly connected (e.g., multi-hop EBG= P) . Overall, this seems to imply somewhat that BIER domain is aligned with the = whole IGP domain (and not areas) and e.g. two OSPF areas cannot be two BIER= domains. This is an interesting architectural question that wasn't brough= t up yet ? [Xiaohu] In this doc, it's assumed that a BIER domain is aligned with the w= hole network consist of multiple ASes. Best regards, Xiaohu thanks --- tony > -----Original Message----- > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Monday, February 16, 2015 5:31 PM > To: bier@ietf.org; idr wg > Subject: [Bier] FW: New Version Notification for draft-xu-idr-bier-extens= ions- > 00.txt > > Hi all, > > Any comments are welcome. > > Best regards, > Xiaohu > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto= :internet-drafts@ietf.org] > > Sent: Tuesday, February 17, 2015 9:26 AM > > To: Mach Chen; Xuxiaohu; Xuxiaohu; IJsbrand Wijnands; Keyur Patel; > > Keyur Patel; IJsbrand Wijnands; Mach Chen > > Subject: New Version Notification for > > draft-xu-idr-bier-extensions-00.txt > > > > > > A new version of I-D, draft-xu-idr-bier-extensions-00.txt > > has been successfully submitted by Xiaohu Xu and posted to the IETF > repository. > > > > Name: draft-xu-idr-bier-extensions > > Revision: 00 > > Title: BGP Extensions for BIER > > Document date: 2015-02-16 > > Group: Individual Submission > > Pages: 7 > > URL: > > http://www.ietf.org/internet-drafts/draft-xu-idr-bier-extensions-00.txt > > Status: https://datatracker.ietf.org/doc/draft-xu-idr-bier-exte= nsions/ > > Htmlized: http://tools.ietf.org/html/draft-xu-idr-bier-extensions= -00 > > > > > > Abstract: > > Bit Index Explicit Replication (BIER) is a new multicast forwarding > > architecture which doesn't require an explicit tree-building protoco= l > > and doesn't require intermediate routers to maintain any multicast > > state. BIER is applicable in a multi-tenant data center network > > envioronment for efficient delivery of Broadcast, Unknown-unicast an= d > > Multicast (BUM) traffic while eliminating the need for maitaining a > > huge amount of multicast state in an underlay. This document > > describes BGP extensions for advertising the BIER-specific > > information. These extesnions are applicable in those multi-tenant > > data centers where BGP instead of IGP is deployed as an underlay for > > network reachability advertisement. These extensions may also be > > applicable in other scenarios. > > > > > > > > > > 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. > > > > The IETF Secretariat > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083098C8NKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tony,

 

Thanks a lot for your valuable comments and suggestion. Please se= e my response inline.

 

From: Antoni Przygienda [mailto:antoni.przygienda@ericsson.= com]
Sent: Tuesday, February 17, 2015 10:07 AM
To: Xuxiaohu; bier@ietf.org; idr wg
Subject: RE: [Bier] FW: New Version Notification for draft-xu-idr-bi= er-extensions-00.txt

 

<hat type=3D”indivi= dual cat contributor”>

<= o:p> 

Xuxiaohu, thanks for the wor= k.

<= o:p> 

multiple things:<= /span>

<= o:p> 

  The BFR-ID TLV is encoded = as follows:

 =

      Ty= pe:TBD2

 =

      Le= ngth:5

 =

      Va= lue: contains a two-octet BFR-ID.

<= o:p> 

I am missing here the indica= tion of subdomain-id since without that, the BFR-ID will easily collide wit= hin the BIER domain advertising the BGP info @ the edge.

 

[Xiaohu] Thanks for point it out. Will fix it in the next vers= ion.

 

<= o:p> 

The BSL TLV is encoded as foll= ows:

 

     = Type:TBD3

 

     = Length:4

 

     = Value: contains a one-octet BSL which indicates the length of the

     = Bitstring in 4-octets.

<= o:p> 

Is this encoded equivalent t= o MPLS draft ? Indicate so and indicate WHICH bits are used and which are r= eserved. If not, indicate how e.g.  33 as bitstring length should be t= reated if e.g. the ensuing encaps cannot deal with it ?

 

[Xiaohu] IMHO, it’d better to specify the legal BSL valu= es in the BIER arch draft which should be independent of specific BIER enca= psulations.

 

   The BIER MPLS Enc= apsualtion TLV is encoded as follows:

 

     = Type:TBD4

 

     = Length:7

 

     = Value: contains a one-octet Label Range Size field indicating the

     = size of the label range, and a 3-octect Label Rang Base field

     = where the 20 rightmost bits represent the first label in the label

     = range.

<= o:p> 

indicate that the other bits= are reserved/must be ignored/send 0

<= o:p> 

Generally, it is considered = de rigeur to make nice pictures of those TLVs to make the documents more re= adable. I suggest doing so.

 

[Xiaohu] Thanks for the above suggestions. Will fix them in th= e next version.

<= o:p> 

Another question here is wha= t happens when multiple eBPG edges of an AD advertise this attribute. Is th= e preference driven by MED [or another attribute?] based e.g. on the IGP di= stance within AD to the BFR ?

 

[Xiaohu] I think so.

<= o:p> 

Is the expectation that each= BGP router advertising this is BFR itself ? Or has capabilities to unicast= tunnel into the BIER domain ?

 

[Xiaohu]Since the BIER attribute is an optional, transitive BG= P path attribute, it should support the scenario where a BGP speaker is all= owed to tunnel a BIER packet or the payload of a BIER packet to the BFER directly if the BGP next-hop is a non-BFR. Fu= rthermore, it should support as well the scenario where a BGP speaker is al= lowed to tunnel a BIER packet to the BGP next-hop if these two BGP peers ar= e not directly connected (e.g., multi-hop EBGP) .

<= o:p> 

Overall, this seems to imply= somewhat that BIER domain is aligned with the whole IGP domain (and not ar= eas) and e.g. two OSPF areas cannot be two BIER domains.  This is an i= nteresting architectural question that wasn’t brought up yet ?

 

[Xiaohu] In this doc, it’s assumed that a BIER domain is= aligned with the whole network consist of multiple ASes.

Best regards,

Xiaohu

<= o:p> 

</hat>

<= o:p> 

thanks

<= o:p> 

--- tony <= /p>

<= o:p> 

> -----Original Message--= ---

> From: BIER [mailto:bier-bounces@ietf.org] On Behalf O= f Xuxiaohu

> Sent: Monday, February = 16, 2015 5:31 PM

> To: bier@ietf.org; idr wg

> Subject: [Bier] FW: New= Version Notification for draft-xu-idr-bier-extensions-

> 00.txt

>

> Hi all,

>

> Any comments are welcom= e.

>

> Best regards,

> Xiaohu

>

> > -----Original Mess= age-----

> > From: internet-drafts@ietf.= org [mailto:internet-drafts@ietf.org]

> > Sent: Tuesday, Feb= ruary 17, 2015 9:26 AM

> > To: Mach Chen; Xux= iaohu; Xuxiaohu; IJsbrand Wijnands; Keyur Patel;

> > Keyur Patel; IJsbr= and Wijnands; Mach Chen

> > Subject: New Versi= on Notification for

> > draft-xu-idr-bier-= extensions-00.txt

> ><= /p>

> ><= /p>

> > A new version of I= -D, draft-xu-idr-bier-extensions-00.txt

> > has been successfu= lly submitted by Xiaohu Xu and posted to the IETF

> repository.<= /span>

> ><= /p>

> > Name:  &= nbsp;           &nbs= p;           draft-xu-idr= -bier-extensions

> > Revision: &nb= sp;     00

> > Title:  =             &nb= sp;            =   BGP Extensions for BIER

> > Document date:&nbs= p;        2015-02-16

> > Group:  =             &nb= sp;           Individual = Submission

> > Pages:  =             &nb= sp;            7

> > URL:

> > http://www.ietf.org/i= nternet-drafts/draft-xu-idr-bier-extensions-00.txt

> > Status:  = ;       https://datatracker.i= etf.org/doc/draft-xu-idr-bier-extensions/

> > Htmlized: &nb= sp;     http://tools.ietf.org= /html/draft-xu-idr-bier-extensions-00

> ><= /p>

> ><= /p>

> > Abstract:

> >    = Bit Index Explicit Replication (BIER) is a new multicast forwarding

> >    = architecture which doesn't require an explicit tree-building protocol<= /o:p>

> >    = and doesn't require intermediate routers to maintain any multicast

> >    = state.  BIER is applicable in a multi-tenant data center network<= /o:p>

> >    = envioronment for efficient delivery of Broadcast, Unknown-unicast and<= /o:p>

> >    = Multicast (BUM) traffic while eliminating the need for maitaining a

> >    = huge amount of multicast state in an underlay.  This document

> >    = describes BGP extensions for advertising the BIER-specific

> >    = information.  These extesnions are applicable in those multi-tenant

> >    = data centers where BGP instead of IGP is deployed as an underlay for

> >    = network reachability advertisement.  These extensions may also be=

> >    = applicable in other scenarios.

> ><= /p>

> ><= /p>

> ><= /p>

> ><= /p>

> > Please note that i= t may take a couple of minutes from the time of

> > submission until t= he htmlized version and diff are available at tools.ietf.org.

> ><= /p>

> > The IETF Secretari= at

>

> _______________________= ________________________

> BIER mailing list<= /o:p>

> BIER@ietf.o= rg

> https://www.ietf.org/= mailman/listinfo/bier

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083098C8NKGEML512MBSchi_-- From nobody Mon Feb 16 19:24:42 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AC11A00FE; Mon, 16 Feb 2015 19:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfaPwSowm5ev; Mon, 16 Feb 2015 19:24:36 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CC21A0162; Mon, 16 Feb 2015 19:24:36 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-df-54e26089acb2 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7E.F0.03307.98062E45; Mon, 16 Feb 2015 22:26:34 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Mon, 16 Feb 2015 22:24:33 -0500 From: Antoni Przygienda To: Xuxiaohu , "bier@ietf.org" , idr wg Thread-Topic: [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-00.txt Thread-Index: AQHQSlCq3k5gpZgciU2QvKfhI3xxk5z0DcqggAADj/CAAGvqAP//ru+g Date: Tue, 17 Feb 2015 03:24:32 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1825C259@eusaamb103.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083097F5@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F1825C17B@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083098C8@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083098C8@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.10] Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F1825C259eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXSPn25XwqMQg+ULuS2WztjDZPHq9jMm i63nVzE6MHu0HHnL6rFkyU+mAKYoLpuU1JzMstQifbsErowjkz6wF0w4w1hxcLtPA+P7rYxd jBwcEgImErv2JXQxcgKZYhIX7q1n62Lk4hASOMIo8fhYFzOEs5xRYtnMrWwgVWwCFhKXvz1l BmkWEYiR+DiRCyQsLBAlcfz4T0YQW0QgWmLV281QtptEX/tudhCbRUBVYuW3drAxvALeEt++ 3mQBsYUEHjNKfJliDWJzCoRJLPjxhAnEZgQ66PupNWA2s4C4xK0n85kgDhWQWLLnPDOELSrx 8vE/VghbSWLS0nOsEPX5EhOX/2SF2CUocXLmE5YJjCKzkIyahaRsFpIyiLiOxILdn9ggbG2J ZQtfM8PYZw48ZkIWX8DIvoqRo7Q4tSw33chgEyMwjo5JsOnuYNzz0vIQowAHoxIPr4HdoxAh 1sSy4srcQ4zSHCxK4ryLHhwMERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4I0yjLs+jKWnB Stf6XSqxd/6bTT3a+Xld2y/3cy8OCSx8v89vy/OGu+fnLbR94uPKmq/+zUBsgp+y/9Y0nqRi K71G6dMXdDImfqn9Pl3AMcH2gSz3RItOn3f7dpq/Lt0bvNyGyXzb3dNSalUvT25P//9O5Umv XsC+WMemIlv1Z89Lfwkt7lusxFKckWioxVxUnAgA01GCXYQCAAA= Archived-At: Subject: Re: [Bier] FW: New Version Notification for draft-xu-idr-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, 17 Feb 2015 03:24:39 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F1825C259eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Length:5 Value: contains a two-octet BFR-ID. I am missing here the indication of subdomain-id since without that, the BF= R-ID will easily collide within the BIER domain advertising the BGP info @ = the edge. [Xiaohu] Thanks for point it out. Will fix it in the next version. [Tony said] ack The BSL TLV is encoded as follows: Type:TBD3 Length:4 Value: contains a one-octet BSL which indicates the length of the Bitstring in 4-octets. Is this encoded equivalent to MPLS draft ? Indicate so and indicate WHICH b= its are used and which are reserved. If not, indicate how e.g. 33 as bitst= ring length should be treated if e.g. the ensuing encaps cannot deal with i= t ? [Xiaohu] IMHO, it'd better to specify the legal BSL values in the BIER arch= draft which should be independent of specific BIER encapsulations. [Tony said] agreed, that's a heads-up for Ice to put it into the architect= ure draft me thinks. It's hanging in the MPLS draft right now. Given how wi= dely it's referenced, it should be moved up me thinks. The BIER MPLS Encapsualtion TLV is encoded as follows: Type:TBD4 Length:7 Value: contains a one-octet Label Range Size field indicating the size of the label range, and a 3-octect Label Rang Base field where the 20 rightmost bits represent the first label in the label range. indicate that the other bits are reserved/must be ignored/send 0 Generally, it is considered de rigeur to make nice pictures of those TLVs t= o make the documents more readable. I suggest doing so. [Xiaohu] Thanks for the above suggestions. Will fix them in the next versio= n. [Tony said] ack Another question here is what happens when multiple eBPG edges of an AD adv= ertise this attribute. Is the preference driven by MED [or another attribut= e?] based e.g. on the IGP distance within AD to the BFR ? [Xiaohu] I think so. [Tony said] ack, I suggest to put it into lead-in section (Special consider= ations, requireements, assumptions, something ?) Is the expectation that each BGP router advertising this is BFR itself ? Or= has capabilities to unicast tunnel into the BIER domain ? [Xiaohu]Since the BIER attribute is an optional, transitive BGP path attrib= ute, it should support the scenario where a BGP speaker is allowed to tunne= l a BIER packet or the payload of a BIER packet to the BFER directly if the= BGP next-hop is a non-BFR. Furthermore, it should support as well the scen= ario where a BGP speaker is allowed to tunnel a BIER packet to the BGP next= -hop if these two BGP peers are not directly connected (e.g., multi-hop EBG= P) . [Tony said] [Tony said] Yes, I suggest a small section stating this and exp= laining this. Overall, this seems to imply somewhat that BIER domain is aligned with the = whole IGP domain (and not areas) and e.g. two OSPF areas cannot be two BIER= domains. This is an interesting architectural question that wasn't brough= t up yet ? [Xiaohu] In this doc, it's assumed that a BIER domain is aligned with the w= hole network consist of multiple ASes. [Tony said] Let's spell it out and have a discussion @ next BOF/WG [whateve= r we become when we've grown up to have a charter ;-) ] I think it will be= a very relevant architectural decision at this point in time and possibly = influence all IGP drafts. What speaks against BIER domain aligned with AD i= s scalabilty, what speaks for it is simplicity. --- tony --_000_2E4BB27CAB87BF43B4207C0E55860F1825C259eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_2E4BB27CAB87BF43B4207C0E55860F1825C259eusaamb103ericsso_-- From nobody Tue Feb 17 03:08:36 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97951A6F21 for ; Tue, 17 Feb 2015 03:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KbTigftY7k7 for ; Tue, 17 Feb 2015 03:08:32 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A6C1A87E6 for ; Tue, 17 Feb 2015 03:08:31 -0800 (PST) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail21.telekom.de with ESMTP; 17 Feb 2015 12:08:29 +0100 X-IronPort-AV: E=Sophos;i="5.09,594,1418079600"; d="scan'208";a="765757984" Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 17 Feb 2015 12:08:29 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 17 Feb 2015 12:08:29 +0100 From: To: Date: Tue, 17 Feb 2015 12:08:28 +0100 Thread-Topic: [Bier] proposed BIER charter Thread-Index: AdBKog6keGZKs092Sp+26haHc03a1g== Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E7BBBA4CF1@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Martin.Horneffer@telekom.de, bier@ietf.org Subject: [Bier] proposed BIER charter 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, 17 Feb 2015 11:08:34 -0000 Hi Alia, I read the postings at bier@ietf.org with much interest and would like to s= ee it being progressed in IETF as a WG rather sooner than later. IMHO BIER = is at least very interesting for DT, and for some IP-Multicast setups it mi= ght be a better approach than "traditional" PIM setups. Cheers, Uwe Uwe Joorde, Deutsche Telekom Backbone Engineering From nobody Tue Feb 17 06:33:26 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CF81A1B28 for ; Tue, 17 Feb 2015 06:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYX86DRcsyVJ for ; Tue, 17 Feb 2015 06:33:23 -0800 (PST) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1BB1A88A4 for ; Tue, 17 Feb 2015 06:33:23 -0800 (PST) Received: by pdev10 with SMTP id v10so44044863pde.10 for ; Tue, 17 Feb 2015 06:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DK8nm3ZCmGZq7OFCodj5wmra4LQq9p4ujquhEnRfpGY=; b=XmU7vVyCAeTRXogrH6wILelIkD5d6Vfq+My08s0KAp555CsiLuqAMmeE7Ol8aolPvl zm1AOp/M+Ebl4BkRbBT07cxA3AaxnFOeRNWreqbNVyO6yYGKbNQTZKiOC2DWLWhJ5eiy QLdo3CIfV9b1KIRq0/rTnmA3WZLqbngXavSLB3+VyZLeTCMNI10234Wb7ajKfC+O1lwd zMcY6OsRKNRgitcUkCSaMxdvzxva+3loz15aHJcUuEQQlZCG3WSY/Tk5WXyPlRvJZXw6 K8oNRhKOuRjjdXbMx3nUxe6TZNITbmL3kN9Te5Xarknyz1s23IkjA6LvbgEkTJK7vxp9 EKig== MIME-Version: 1.0 X-Received: by 10.70.56.34 with SMTP id x2mr49123222pdp.127.1424183601720; Tue, 17 Feb 2015 06:33:21 -0800 (PST) Received: by 10.70.73.229 with HTTP; Tue, 17 Feb 2015 06:33:21 -0800 (PST) In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E7BBBA4CF1@HE113667.emea1.cds.t-internal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01E7BBBA4CF1@HE113667.emea1.cds.t-internal.com> Date: Tue, 17 Feb 2015 09:33:21 -0500 Message-ID: From: Alia Atlas To: Uwe.Joorde@telekom.de Content-Type: multipart/alternative; boundary=089e0160cc68acf539050f499544 Archived-At: Cc: Martin.Horneffer@telekom.de, "bier@ietf.org" Subject: Re: [Bier] proposed BIER charter 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, 17 Feb 2015 14:33:25 -0000 --089e0160cc68acf539050f499544 Content-Type: text/plain; charset=UTF-8 Hi Uwe, On Tue, Feb 17, 2015 at 6:08 AM, wrote: > Hi Alia, > > I read the postings at bier@ietf.org with much interest and would like to > see it being progressed in IETF as a WG rather sooner than later. IMHO BIER > is at least very interesting for DT, and for some IP-Multicast setups it > might be a better approach than "traditional" PIM setups. > Thanks very much for your feedback. It really helps to hear from additional people with different perspectives on the proposed technology! I am working on getting BIER chartered as a WG - hopefully before the Dallas IETF. Regards, Alia > Cheers, Uwe > > Uwe Joorde, Deutsche Telekom Backbone Engineering > --089e0160cc68acf539050f499544 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Uwe,


On Tue, Feb 17, 2015 at 6:08 AM, &= lt;Uwe.Joorde@te= lekom.de> wrote:
Hi Alia,=

I read the postings at bier@ietf.org w= ith much interest and would like to see it being progressed in IETF as a WG= rather sooner than later. IMHO BIER is at least very interesting for DT, a= nd for some IP-Multicast setups it might be a better approach than "tr= aditional" PIM setups.

Thanks very= much for your feedback.=C2=A0 It really helps to hear from additional peop= le with different perspectives on the proposed technology!=C2=A0 I am worki= ng on getting BIER chartered as a WG - hopefully before the Dallas IETF.

Regards,
Alia=C2=A0

=C2=A0
Cheers, Uwe

Uwe Joorde, Deutsche Telekom Backbone Engineering

--089e0160cc68acf539050f499544-- From nobody Tue Feb 17 07:10:45 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904161A89B9; Tue, 17 Feb 2015 07:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZEUh0u2WqV_D; Tue, 17 Feb 2015 07:10:35 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9145C1A89B4; Tue, 17 Feb 2015 07:10:35 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 47ED2880D1; Tue, 17 Feb 2015 07:10:35 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8BEBD1368244; Tue, 17 Feb 2015 07:10:34 -0800 (PST) Message-ID: <54E359F2.2080204@innovationslab.net> Date: Tue, 17 Feb 2015 10:10:42 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stewart Bryant , "Rajiv Asati (rajiva)" References: <54DCAE4F.8050903@cisco.com>, <54DFB200.8070604@innovationslab.net> <60280EE7-6782-42DF-9CFF-5BD5F3C1D38B@cisco.com> <54E0CB50.2000202@innovationslab.net> <54E1D6A7.1040305@cisco.com> In-Reply-To: <54E1D6A7.1040305@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uEd4vokms5g0wVjpXsb4qTGdgbovoFa4T" Archived-At: Cc: "Alvaro Retana \(aretana\)" , "bier@ietf.org" , "iesg@ietf.org" , Adrian Farrel Subject: Re: [Bier] proposed BIER charter 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, 17 Feb 2015 15:10:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uEd4vokms5g0wVjpXsb4qTGdgbovoFa4T Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stewart, On 2/16/15 6:38 AM, Stewart Bryant wrote: > On 15/02/2015 16:37, Brian Haberman wrote: >=20 >> >>> Experimental in many circles play a significant mind-barrier game. >>> >> I am not aware of those situations, but I am not involved in MPLS >> circles. Can someone describe such a scenario? >> > Firstly experimental implies in most peoples mind "might not work". > Secondly we tell everyone that experimental codepoints MUST NOT > be deployed in production. There is a very real risk of the conflation > of these two points into "this experimental RFC is on that may not > work and must not be deployed in a production network". Maybe your experience is radically different than mine, but most people I have interacted with about RFCs outside of the IETF have zero clue about the Experimental/Standards Track/Informational labels. I am more than willing to believe that there are people who pay attention to those.= The issue with code points is quite valid. However, depending on the registry in question, permanent allocations can be made for Experimental/Informational track documents. I will point out that PIM was labeled Experimental for quite some time and saw significant deployment in production networks. >=20 > If you go back to my original point, I was saying that I thought that > dictating the track at this stage was premature and that the > decision should be made when documents were ready, and thus > when more information was available. >=20 And I will just re-iterate that I am just speaking as an individual who has a history in the multicast (is it experimental or is it not) domain. It is up to the consensus of the community as to what goes into the charter. >>> Part of the reason for me holding this view is that there is still >>> some areas of work needed to understand how BIER will fit in the >>> overall multicast architecture. >>> >>> Ummmm....we will certainly have work to do in not only understanding >>> existing areas, but also exploring new areas (such as 6lopan) for >>> BIER. But that's cant/mustn't be the reason to classify any work as >>> experimental. >>> >> As I stated above, I am looking at this from the multicast (i.e., IP) >> perspective. It took quite a few years before the community felt >> comfortable moving PIM from Experimental to Standards Track. > The key difference between this multicast technology and earlier > such technologies is that classic m/c distributes client state > through-out the network, which frankly does not scale, whereas > this is a technology in which the client state is shared solely with > the information distributor, which is intrinsically more scalable. In some of the proposed scenarios, there will be significant work needed to get the client state to the distributor. But let me state this one more time, I am just an individual in this community. I have no problem with being ruled in the rough. Regards, Brian --uEd4vokms5g0wVjpXsb4qTGdgbovoFa4T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU41n3AAoJEBOZRqCi7goqyVoH/iqFbFIGGAb4S4qkuX3x1H8s M3NJMv7JFsrbHyt0pE2BToOEkPCnBqak8iMi/1CFrTR6VSeUFe6JVt3JUQuENoqp Nm6M3vSooaZBJC/uOzABohQ69ezHcQ1xRm9sFVNLK8dyaYtWm4F0kZrrpgsStgBG vUSQa9f1qpA4eu7q9nYTUIMZ0tFuHK463phynvWbDJfnT8IV6Wv/zDc9hP2ibiWK N3UYQ3Knnxth63UEfZgyZHaKE9QClvrxmp6Nb5asCHO/N8NmM8izP/30IRLgWj38 /+FjklSzu71Au0OINDjrdPpG5bY3fxmhdJS2zxCrsKpEKilwaCf8xceP4KQTqtI= =wcI/ -----END PGP SIGNATURE----- --uEd4vokms5g0wVjpXsb4qTGdgbovoFa4T-- From nobody Tue Feb 17 07:13:14 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AB51A89B4; Tue, 17 Feb 2015 07:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQTJgbteJWXh; Tue, 17 Feb 2015 07:13:11 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA35B1A873A; Tue, 17 Feb 2015 07:13:10 -0800 (PST) Received: from BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142) by BY1PR0501MB1143.namprd05.prod.outlook.com (25.160.103.153) with Microsoft SMTP Server (TLS) id 15.1.87.18; Tue, 17 Feb 2015 15:13:09 +0000 Received: from [172.29.33.103] (66.129.241.12) by BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142) with Microsoft SMTP Server (TLS) id 15.1.87.18; Tue, 17 Feb 2015 15:13:07 +0000 Message-ID: <54E35A7C.70605@juniper.net> Date: Tue, 17 Feb 2015 10:13:00 -0500 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: , 'Alia Atlas' , 'Joel Jaeggli' References: <20150214214725.9126.32255.idtracker@ietfa.amsl.com> <011501d04904$bacd7bf0$306873d0$@olddog.co.uk> In-Reply-To: <011501d04904$bacd7bf0$306873d0$@olddog.co.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN1PR07CA0060.namprd07.prod.outlook.com (10.255.193.35) To BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1096; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:BY1PR0501MB1096; X-Forefront-PRVS: 0490BBA1F0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(24454002)(377454003)(479174004)(77096005)(230783001)(65806001)(65956001)(66066001)(42186005)(77156002)(33656002)(76176999)(54356999)(36756003)(50986999)(2950100001)(65816999)(50466002)(92566002)(47776003)(83506001)(46102003)(122386002)(40100003)(86362001)(87976001)(23746002)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1096; H:[172.29.33.103]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1096; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2015 15:13:07.1242 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1096 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1143; X-OriginatorOrg: juniper.net Archived-At: Cc: 'Greg Shepherd' , bier@ietf.org, 'The IESG' , erosen@juniper.net Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 17 Feb 2015 15:13:12 -0000 On 2/15/2015 4:49 AM, Adrian Farrel wrote: > how about this charter limit the work to a single domain? I really don't see any reason for the charter to limit the work to a single domain. If you look at draft-rosen-l3vpn-mvpn-bier, for example, it does support multiple domains. One could argue whether that draft belongs in BIER or BESS, but of course the answer is "both". We don't want to get into a situation where BIER can't consider it because it is "out of charter", and then BESS can't consider it because it is about BIER but outside BIER's charter. This sort of issue can be left in the hands of the WG(s). Too many details and restrictions in the charter just leads to a lot of politics. (The real "poster child" for the dangers of an overly constraining charter is PPVPN. All kinds of nonsense was put in the charter to ensure that the work that came out would be significantly different than the work that went in. This delayed formal publication of the work for seven years, but in the end the work that came out was substantially the same as the work that went in, and market penetration was not at all delayed. But there was lots and lots of annoying politics.) One issue that the process wonks might want to think about is codepoint allocation. If there is not going to be a mechanism for the early allocation of codepoints, one can anticipate that there will be lots of codepoint squatting, with the usual set of hassles arriving later. From nobody Tue Feb 17 07:51:36 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0971A8AA0; Tue, 17 Feb 2015 07:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uJ9IjROD4TY; Tue, 17 Feb 2015 07:51:31 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAEB1A8A99; Tue, 17 Feb 2015 07:51:31 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-0c-54e30f93e172 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D5.83.03307.39F03E45; Tue, 17 Feb 2015 10:53:23 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0210.002; Tue, 17 Feb 2015 10:51:29 -0500 From: Antoni Przygienda To: Eric C Rosen , "adrian@olddog.co.uk" , 'Alia Atlas' , 'Joel Jaeggli' Thread-Topic: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT) Thread-Index: AQHQSLUgfctwANhBEEKUODqERnb11Jzxy9gAgAN+/gD//7YZwA== Date: Tue, 17 Feb 2015 15:51:29 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1825C5AC@eusaamb103.ericsson.se> References: <20150214214725.9126.32255.idtracker@ietfa.amsl.com> <011501d04904$bacd7bf0$306873d0$@olddog.co.uk> <54E35A7C.70605@juniper.net> In-Reply-To: <54E35A7C.70605@juniper.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLonQXcy/+MQg7u7RC1+9Nxgtvj08BKz xdIZe5gs1m34wGyxZU6exYw/E5ktXp1aw+jA7nH2yAJGj52z7rJ7LFnyk8njetNVdo8Vm1cy BrBGcdmkpOZklqUW6dslcGWsPfyJseA0Z8Wsg+eZGhgPsXcxcnJICJhI/Py/lgXCFpO4cG89 WxcjF4eQwBFGidPvTzBDOMsZJbasewdWxSZgIXH521OwhIjAbEaJ/7sXgo1iFkiXOLT6LliR sECMxMwTJ8DiIgKxEjtP74eynSTOXekFs1kEVCUatnxnBLF5Bbwldv09xAqx7SqjRNPJA2wg CU4BTYkXi56AFTEC3ff91BomiGXiEreezGeCuFtAYsme88wQtqjEy8f/WCFsJYk5r68xQ9Tr SCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFlFSNHaXFqWW66kcEm RmDkHZNg093BuOel5SFGAQ5GJR5eA7tHIUKsiWXFlbmHGKU5WJTEeRc9OBgiJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgZHjY8CDF/XlO43SnhoeVH/zx27aKV4fqRP7tlyW7Xj2vMLlG09B GXea0ISZk1WXbTmRvGqHv+fOwwfXCG9QOrS2/OmRa9xaWgu7FltcU+aa+ibtWZf2T2fe/2WW Jbtb2FbsklfekrBYNzb3UIjIvcxXStc/6lVMaRfZGy4+49iBpx/7v8VF3VmoxFKckWioxVxU nAgAka4xfJ0CAAA= Archived-At: Cc: 'Greg Shepherd' , "bier@ietf.org" , 'The IESG' Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 17 Feb 2015 15:51:33 -0000 > On 2/15/2015 4:49 AM, Adrian Farrel wrote: > > how about this charter limit the work to a single domain? >=20 > I really don't see any reason for the charter to limit the work to a sing= le domain. >=20 > If you look at draft-rosen-l3vpn-mvpn-bier, for example, it does support = multiple > domains. One could argue whether that draft belongs in BIER or BESS, but= of > course the answer is "both". We don't want to get into a situation where= BIER > can't consider it because it is "out of charter", and then BESS can't con= sider it > because it is about BIER but outside BIER's charter. [Tony said] hmmm, good point. BESS are in fact busy gophers and it's not = hypothetical.=20 > One issue that the process wonks might want to think about is codepoint > allocation. If there is not going to be a mechanism for the early alloca= tion of > codepoints, one can anticipate that there will be lots of codepoint squat= ting, > with the usual set of hassles arriving later. [Tony said] hmmm, good point again. Within BIER itself, we can keep an inf= ormational and update it (works quite well is my experience) but in IGPs [a= nd things like IMET/BESS] I fully agree.=20 --- tony=20 From nobody Tue Feb 17 07:59:08 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEA01A8AEB; Tue, 17 Feb 2015 07:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.599 X-Spam-Level: X-Spam-Status: No, score=-100.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bgs_31Vy2YoI; Tue, 17 Feb 2015 07:59:03 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3261A8AC0; Tue, 17 Feb 2015 07:56:42 -0800 (PST) Received: by mail-yk0-f181.google.com with SMTP id 200so16765388ykr.12; Tue, 17 Feb 2015 07:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+fxf2mMW3BMdsxvLKVA2yAJ1Yr3N7I6GFTfeD5YpVVk=; b=ysb65iUDYw0rsEqwVO6OSN+/UEskYy3Cz/8PHXUgVofePvRoG3I1J23GSf09ivrFkx jER7J6o5aFEx5vAZBODtVjchwCgQVVNyWb4mHQkmPlVxnuJ35flYrf8dcbxulcuqQnS4 xcvKUlWDV4BddcodMCuSmIRxz6YAzBlrhJx4cxFo4Dhit14KHGDu3lmBq4UcqvXP6qfe lvgEYYm42Rptk9HlZ2T4fm6cn90c2N6Edy2WDJEHtgYyGGxAdyz2fOpwdNfSkU9TY+bj A//Wy+HUVCliGw/SUQnIGzJaaxqLGe7K8qs66A190Mb69rTbYfc/7Lcb+E53Y+MAclhU WNoQ== MIME-Version: 1.0 X-Received: by 10.236.203.108 with SMTP id e72mr3411058yho.48.1424188601930; Tue, 17 Feb 2015 07:56:41 -0800 (PST) Received: by 10.170.133.197 with HTTP; Tue, 17 Feb 2015 07:56:41 -0800 (PST) In-Reply-To: References: <54DCAE4F.8050903@cisco.com> <4A496052E7B7E84A9324854763C616FA233CF4DA@C111GTUHMBX56.ERF.thomson.com> Date: Tue, 17 Feb 2015 10:56:41 -0500 Message-ID: From: Alia Atlas To: IJsbrand Wijnands Content-Type: multipart/alternative; boundary=089e0160b506b61dc4050f4abf66 Archived-At: Cc: "bier@ietf.org" , "iesg@ietf.org" , Adrian Farrel , Alvaro Retana , Arkadiy Gulko , stbryant Subject: Re: [Bier] proposed BIER charter 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, 17 Feb 2015 15:59:05 -0000 --089e0160b506b61dc4050f4abf66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ice, On Sat, Feb 14, 2015 at 3:13 PM, IJsbrand Wijnands wrote: > Alia, > > > Obviously, have active authors implies that they are interested in > developing the technology because it has promise. Obviously, by being > willing to charter a working group, I have heard and agree. Except for > Arkadiy, they haven't participated on the mailing > > You=E2=80=99re doing a very good job in hiding your excitement ;-) > Shall I bounce up and down and talk enthusiastically? This is the option that gets a WG created quickly and has a fast path for getting the work done. This is the option that says "hey, this is neat work and a really cool idea. Let's get it fleshed out and see if there's actual interest in deployment". It's a architecturally clever idea but I'm twitchy about the forwarding plane implications - particularly for the non-MPLS encapsulation= . > list or spoke up at the BoF at all - despite all being active IETFers. > > First of all, at least 3 of the operators where not in Hawaii. Second, yo= u > have your priorities reversed! You should put much more weight in operato= rs > that are willing to associate their name with a draft and help move the > technology forward. Anybody can go to the mic at an IETF meeting and make > some comments. Its the people on the drafts that make the difference and > GSD. > Without being inside a team of authors working on a draft - and when a draft has 5 authors/editors and 8 more contributing authors, it's quite hard to tell how much enthusiasm and work is being put in, much less the difference between "neat idea - let's explore it" and "this needs to be in my network ASAP". Regards, Alia > Thx, > > Ice. > > --089e0160b506b61dc4050f4abf66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ice,

On Sat, Feb 14, 2015 at 3:13 PM, IJsbrand Wijnands &l= t;ice@cisco.com><= /span> wrote:
Alia,

> Obviously, have active authors implies that they are interested in dev= eloping the technology because it has promise.=C2=A0 Obviously, by being wi= lling to charter a working group, I have heard and agree.=C2=A0 =C2=A0Excep= t for Arkadiy, they haven't participated on the mailing

You=E2=80=99re doing a very good job in hiding your excitement ;-)

Shall I bounce up and down and talk enth= usiastically?=C2=A0 This is the option that gets a WG created quickly and h= as a fast path for getting the work done.=C2=A0 This is the option that say= s "hey, this is neat work and a really cool idea.=C2=A0 Let's get = it fleshed out and see if there's actual interest in deployment". = =C2=A0 It's a architecturally clever idea but I'm twitchy about the= forwarding plane implications - particularly for the non-MPLS encapsulatio= n.

>= list or spoke up at the BoF at all - despite all being active IETFers.

First of all, at least 3 of the operators where not in Hawaii. Secon= d, you have your priorities reversed! You should put much more weight in op= erators that are willing to associate their name with a draft and help move= the technology forward. Anybody can go to the mic at an IETF meeting and m= ake some comments. Its the people on the drafts that make the difference an= d GSD.

Without being inside a team of a= uthors working on a draft - and when a draft has 5 authors/editors and 8 = =C2=A0more contributing authors, it's quite hard to tell how much enthu= siasm and work is being put in, much less the difference between "neat= idea - let's explore it" and "this needs to be in my network= ASAP".

Regards,
Alia
=C2=A0
Thx,

Ice.


--089e0160b506b61dc4050f4abf66-- From nobody Thu Feb 19 04:55:56 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD3A1A0406; Sat, 14 Feb 2015 13:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gTI7IX67-mMg; Sat, 14 Feb 2015 13:47:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F2E1A039D; Sat, 14 Feb 2015 13:47:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214214725.9126.32255.idtracker@ietfa.amsl.com> Date: Sat, 14 Feb 2015 13:47:25 -0800 Archived-At: X-Mailman-Approved-At: Thu, 19 Feb 2015 04:55:55 -0800 Cc: gjshep@gmail.com, bier@ietf.org Subject: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 21:47:26 -0000 Joel Jaeggli has entered the following ballot position for charter-ietf-bier-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bier/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- So the size of the bier domain is bounded I suppose by the number of egress points you're willing to include in your header. given the inherent suitability of such a method for overlays it seems like it distinctly bounds the size of such an overlay based on the header size/ if you chain bier domains (no subdomain) how do you do loop detection (or don't you). From nobody Thu Feb 19 04:55:58 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24BAD1A8770; Wed, 18 Feb 2015 20:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 cNG45ub3cnjs; Wed, 18 Feb 2015 20:27:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0601A8764; Wed, 18 Feb 2015 20:27:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219042729.29944.59145.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 20:27:29 -0800 Archived-At: X-Mailman-Approved-At: Thu, 19 Feb 2015 04:55:55 -0800 Cc: gjshep@gmail.com, bier@ietf.org Subject: [Bier] Spencer Dawkins' No Objection on charter-ietf-bier-00-01: (with COMMENT) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 04:27:31 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-bier-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bier/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One question. This text 9) Deployment Experience: Once there is deployment experience, the WG will produce a document describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms. Ideally, this should also contain an analysis of the impact and benefit of the new BIER data-plane to the overall Internet architecture. This document is intended to be used to evaluate whether to recharter BIER to produce Standards Track RFCs. seems like a lot of words to say "once there is deployment experience, BIER may be rechartered to produce Standards Track RFCs". Do you need to define the gates they must pass through now? (What if you think of something else later?) "produce a document" sounds like we're likely to be having the usual discussion about whether to publish a working paper as an RFC when that happens. If they sent the ADs an e-mail, would that be wrong? From nobody Thu Feb 19 04:57:07 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AED1A903E; Thu, 19 Feb 2015 04:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 HTWtwSfUIwr3; Thu, 19 Feb 2015 04:57:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 300D71A87A2; Thu, 19 Feb 2015 04:57:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219125702.17580.66715.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 04:57:02 -0800 Archived-At: Cc: gjshep@gmail.com, bier@ietf.org Subject: [Bier] Brian Haberman's No Objection on charter-ietf-bier-00-01: (with COMMENT) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 12:57:03 -0000 Brian Haberman has entered the following ballot position for charter-ietf-bier-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bier/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. The first work item says the WG "will specify the information that is required by a BIER header to support BIER forwarding." That doesn't parse right to me. Will the WG specify what information is needed by a router to support BIER forwarding? Will the WG specify what information is needed in a BIER header? A little clarification would be good. 2. Work item #2 (non-MPLS data plane) combined with the last paragraph of the charter seems to preclude the WG from looking at the BIER and PIM/IGMP/MLD interactions. Is that the intent? 3. Does the WG need to develop an Applicability Statement for the non-MPLS data plane, if they choose to move that direction? 4. Does the charter require the WG to publish the use cases document? From nobody Thu Feb 19 08:00:41 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF401A910A; Thu, 19 Feb 2015 08:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhcNr5oFCLIG; Thu, 19 Feb 2015 08:00:37 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BF51A9153; Thu, 19 Feb 2015 08:00:20 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so15831044obc.9; Thu, 19 Feb 2015 08:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j7Q+nRVBIuuxUmY4vrQ+0fcyZjhYYZ4AP3sLHMr7L9M=; b=mwjcVH8a3xoBqRPpqqxlHA1/0u0SB8ZihvI69hz2tqys9kR1pSmBRwgpDKNIvmocre OxrydCV26BPxb8NQ7ZUlMaOlVLIerZeRhmK3Gr8uwwtzXYG5ujJZMz5JQXaIg1BpQsQz xyDO8lp3uj4+ffnHkeeBnV+4emlcABqj4vQAHsw5tH9acgY8kGJ7kAdI6u++5uiMDG8n TB8nriffTEpekZQN183e5B1YmT6xJyoG/n4ANkxM0JlHYWj55LJxJVj2qWcY/0Qoo0S2 HOKmmx04/yl7/oc90Y2puuxXnmB2qyHbqudwc6JakbeyaKQHXUBHe2zkKMQ9TVBFsa0P oDFQ== MIME-Version: 1.0 X-Received: by 10.60.42.211 with SMTP id q19mr3406002oel.58.1424361619835; Thu, 19 Feb 2015 08:00:19 -0800 (PST) Received: by 10.60.94.20 with HTTP; Thu, 19 Feb 2015 08:00:19 -0800 (PST) In-Reply-To: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> References: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:00:19 -0500 Message-ID: From: Alia Atlas To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0111dcc261ce4c050f7308f8 Archived-At: Cc: Greg Shepherd , "bier@ietf.org" , The IESG Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 19 Feb 2015 16:00:39 -0000 --089e0111dcc261ce4c050f7308f8 Content-Type: text/plain; charset=UTF-8 Hi Stephen, On Thu, Feb 19, 2015 at 10:47 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > charter-ietf-bier-00-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-bier/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > I'm fine with this going for external review. > > I would like to see the security properties of Bier called out more > as something that the proposed WG will address, e.g. does the > work to date include any integrity mechanisms so that one could > check if a bit-flip is causing packets to be sent to the "wrong" > places? Is there some (usable) security mechanism in place > for establishing the bit-mask value to use at ingress? Etc. > I did talk with Greg and Tony about the possibility of having an integrity mechanism, though MPLS doesn't and has been working ok. It is something that should be discussed in the context of an encapsulation; I just don't see it as something that needs to be pulled out into a separate work-item in the charter. I'm happy to chat with you and get your thoughts on what additional security mechanisms might make sense to be concerned about. The integrity of the bitmap was the only one that I easily saw. Alia --089e0111dcc261ce4c050f7308f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

On Thu, Feb 19, 2015 at 10:47 AM, Stephen Farrell <step= hen.farrell@cs.tcd.ie> wrote:
Stephen Farrell has entered the following ballot position for
charter-ietf-bier-00-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-bier/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


I'm fine with this going for external review.

I would like to see the security properties of Bier called out more
as something that the proposed WG will address, e.g. does the
work to date include any integrity mechanisms so that one could
check if a bit-flip is causing packets to be sent to the "wrong"<= br> places? Is there some (usable) security mechanism in place
for establishing the bit-mask value to use at ingress? Etc.

I did talk with Greg and Tony about the possibility of= having an integrity mechanism,
though MPLS doesn't and has b= een working ok. =C2=A0 It is something that should be
discussed i= n the context of an encapsulation; I just don't see it as something tha= t
needs to be pulled out into a separate work-item in the charter= .

I'm happy to chat with you and get your thou= ghts on what additional
security mechanisms might make sense to b= e concerned about.=C2=A0 The integrity of
the bitmap was the only= one that I easily saw.

Alia=C2=A0

=
--089e0111dcc261ce4c050f7308f8-- From nobody Fri Feb 20 02:39:00 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9CE1A882B; Fri, 20 Feb 2015 02:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMBRojNKShx7; Fri, 20 Feb 2015 02:38:54 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED2E1A87F2; Fri, 20 Feb 2015 02:38:54 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id wp18so22199988obc.8; Fri, 20 Feb 2015 02:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wRdjO0DSCIsMTpy17PRvbi3BRgE5OEEwIsRt+ga4jjI=; b=LnIfOTBoSbrP/EJewqAFkSlcKoS8SIXMdwyKp0fLizzck1XK74hys3vX9z1mr21oR8 86IIjV0xG5lEsxhwG1kT3aeMv6L1dpJW4G6QiHkzIJ/PjGn2BkG+YfRKAZ2COroby5ul IvCGTzrKtwET1cFD4hlIumhZyHVK6E6W7GzsKXdvxDFpxnm0K7yx/ITXGKK0yPR/y6kZ z3KMTeeNRN/PsKibVm7JKbm647Z1bP8uTBaXNvR+7ZAL9q50iGYY5GzGnM6ooD1ImjI7 PGERRotMxfF8PJVjmODZ5IH5J69a2QVYewQArgs3JxcjZ4FFuPOP45TENK97dhJL/v8j 6E9w== MIME-Version: 1.0 X-Received: by 10.182.209.72 with SMTP id mk8mr5938705obc.54.1424428733750; Fri, 20 Feb 2015 02:38:53 -0800 (PST) Received: by 10.182.120.198 with HTTP; Fri, 20 Feb 2015 02:38:53 -0800 (PST) Received: by 10.182.120.198 with HTTP; Fri, 20 Feb 2015 02:38:53 -0800 (PST) In-Reply-To: References: <54DCAE4F.8050903@cisco.com> <4A496052E7B7E84A9324854763C616FA233CF4DA@C111GTUHMBX56.ERF.thomson.com> Date: Fri, 20 Feb 2015 04:38:53 -0600 Message-ID: From: Luay Jalil To: Alia Atlas Content-Type: multipart/alternative; boundary=e89a8ff25256aee233050f82a852 Archived-At: Cc: "bier@ietf.org" , IJsbrand Wijnands , "iesg@ietf.org" , Alvaro Retana , Adrian Farrel , Arkadiy Gulko , stbryant Subject: Re: [Bier] proposed BIER charter 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, 20 Feb 2015 10:38:56 -0000 --e89a8ff25256aee233050f82a852 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This technology is interesting and I'd like to see it progress Thanks, Luay On Feb 17, 2015 9:59 AM, "Alia Atlas" wrote: > Ice, > > On Sat, Feb 14, 2015 at 3:13 PM, IJsbrand Wijnands wrote: > >> Alia, >> >> > Obviously, have active authors implies that they are interested in >> developing the technology because it has promise. Obviously, by being >> willing to charter a working group, I have heard and agree. Except for >> Arkadiy, they haven't participated on the mailing >> >> You=E2=80=99re doing a very good job in hiding your excitement ;-) >> > > Shall I bounce up and down and talk enthusiastically? This is the option > that gets a WG created quickly and has a fast path for getting the work > done. This is the option that says "hey, this is neat work and a really > cool idea. Let's get it fleshed out and see if there's actual interest i= n > deployment". It's a architecturally clever idea but I'm twitchy about t= he > forwarding plane implications - particularly for the non-MPLS encapsulati= on. > > > list or spoke up at the BoF at all - despite all being active IETFers. >> >> First of all, at least 3 of the operators where not in Hawaii. Second, >> you have your priorities reversed! You should put much more weight in >> operators that are willing to associate their name with a draft and help >> move the technology forward. Anybody can go to the mic at an IETF meetin= g >> and make some comments. Its the people on the drafts that make the >> difference and GSD. >> > > Without being inside a team of authors working on a draft - and when a > draft has 5 authors/editors and 8 more contributing authors, it's quite > hard to tell how much enthusiasm and work is being put in, much less the > difference between "neat idea - let's explore it" and "this needs to be i= n > my network ASAP". > > Regards, > Alia > > > >> Thx, >> >> Ice. >> >> > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > --e89a8ff25256aee233050f82a852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This technology is interesting and I'd like to see it pr= ogress

Thanks,
Luay

On Feb 17, 2015 9:59 AM, "Alia Atlas" = <akatlas@gmail.com> wrote:
Ice,=

On Sat, Feb 14, 2= 015 at 3:13 PM, IJsbrand Wijnands <ice@cisco.com> wrote:
Alia,

> Obviously, have active authors implies that they are interested in dev= eloping the technology because it has promise.=C2=A0 Obviously, by being wi= lling to charter a working group, I have heard and agree.=C2=A0 =C2=A0Excep= t for Arkadiy, they haven't participated on the mailing

You=E2=80=99re doing a very good job in hiding your excitement ;-)

Shall I bounce up and down and talk enth= usiastically?=C2=A0 This is the option that gets a WG created quickly and h= as a fast path for getting the work done.=C2=A0 This is the option that say= s "hey, this is neat work and a really cool idea.=C2=A0 Let's get = it fleshed out and see if there's actual interest in deployment". = =C2=A0 It's a architecturally clever idea but I'm twitchy about the= forwarding plane implications - particularly for the non-MPLS encapsulatio= n.

> list or sp= oke up at the BoF at all - despite all being active IETFers.

First of all, at least 3 of the operators where not in Hawaii. Secon= d, you have your priorities reversed! You should put much more weight in op= erators that are willing to associate their name with a draft and help move= the technology forward. Anybody can go to the mic at an IETF meeting and m= ake some comments. Its the people on the drafts that make the difference an= d GSD.

Without being inside a team of a= uthors working on a draft - and when a draft has 5 authors/editors and 8 = =C2=A0more contributing authors, it's quite hard to tell how much enthu= siasm and work is being put in, much less the difference between "neat= idea - let's explore it" and "this needs to be in my network= ASAP".

Regards,
Alia
=C2=A0
Thx,

Ice.



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

--e89a8ff25256aee233050f82a852-- From nobody Fri Feb 20 10:48:51 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9F01A8894 for ; Fri, 20 Feb 2015 10:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 OGpqMvEQjkIe; Fri, 20 Feb 2015 10:48:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5061A899D; Fri, 20 Feb 2015 10:48:36 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220184836.27776.72078.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 10:48:36 -0800 From: IETF Secretariat Archived-At: Subject: [Bier] State changed: charter-ietf-bier-00-01 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 18:48:49 -0000 State changed to External review. URL: http://datatracker.ietf.org/doc/charter-ietf-bier/ From nobody Fri Feb 20 10:48:57 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DE61A8984; Fri, 20 Feb 2015 10:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 VyIaJ9tzngPG; Fri, 20 Feb 2015 10:48:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B8B1A8724; Fri, 20 Feb 2015 10:48:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220184842.25652.67405.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 10:48:42 -0800 From: IETF Secretariat Archived-At: Subject: [Bier] Telechat update notice: X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 18:48:56 -0000 Telechat date has been changed to 2015-03-05 from 2015-02-19 ID Tracker URL: http://datatracker.ietf.org/doc/charter-ietf-bier/ From nobody Fri Feb 20 12:22:46 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D131A00E4 for ; Fri, 20 Feb 2015 12:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lyRhoswUg6X for ; Fri, 20 Feb 2015 12:22:33 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02321A00CA for ; Fri, 20 Feb 2015 12:22:33 -0800 (PST) Received: by pdjy10 with SMTP id y10so9904771pdj.13 for ; Fri, 20 Feb 2015 12:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=r/VgPkveucO1sJCK5gmQtyp5+XEpWM3h1zQdVzV/AiE=; b=axeulK55oACvct2Mz443igjOKBsQ+NvtsHC64KOLan1tSrPDlRw6fwwDjWgwxPHvVD Z5hpgQ8F6DqsGd3xlYjDtXTNhWGIPeI/fNfUzHETCrlP0E+zMF02Fm8lwmsXyz4zWRY3 36+3E1ztXlGZugajGQVOE0d/1L24zGFGvpj/3RRMfiqUwqNKj+daX/e/S8+to7zJWCPD RBHDypc69cQxnPQXGtryK7djbmHQ2kx65Q4dZxFZcB4pAeWUvbhPUNNaa7k7tf/HnSa+ f+NrTNS/hNOFdIah6cDjNj38OH17RvXCRZ15c04OoYGNRoEhuoLHxtS2A6IWQM6vtdlE suSg== X-Received: by 10.70.43.12 with SMTP id s12mr8046868pdl.25.1424463752714; Fri, 20 Feb 2015 12:22:32 -0800 (PST) Received: from [10.66.18.90] ([166.170.40.1]) by mx.google.com with ESMTPSA id fx10sm19083189pac.35.2015.02.20.12.22.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Feb 2015 12:22:30 -0800 (PST) References: <20150220184836.27776.72078.idtracker@ietfa.amsl.com> From: Greg Shepherd Content-Type: multipart/alternative; boundary=Apple-Mail-58458FFC-BAB1-4DBE-BFF7-8B94D10B6D7D X-Mailer: iPhone Mail (11D167) Message-Id: Date: Fri, 20 Feb 2015 12:22:25 -0800 To: bier@ietf.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Archived-At: Subject: [Bier] Fwd: State changed: charter-ietf-bier-00-01 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, 20 Feb 2015 20:22:38 -0000 --Apple-Mail-58458FFC-BAB1-4DBE-BFF7-8B94D10B6D7D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sent from my iPhone Begin forwarded message: > From: IETF Secretariat > Date: February 20, 2015 at 10:48:36 PST > To: , , > Subject: State changed: charter-ietf-bier-00-01 > > State changed to External review. > > URL: http://datatracker.ietf.org/doc/charter-ietf-bier/ --Apple-Mail-58458FFC-BAB1-4DBE-BFF7-8B94D10B6D7D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


Sent from my iPhone

Begin forwarded message:

From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Date: February 20, 2015 at 10:48:36 PST
To: <bier@ietf.org>, <gjshep@gmail.com>, <tonysietf@gmail.com>
Subject: State changed: charter-ietf-bier-00-01

State changed to External review.

URL: http://datatracker.ietf.org/doc/charter-ietf-bier/
--Apple-Mail-58458FFC-BAB1-4DBE-BFF7-8B94D10B6D7D-- From nobody Fri Feb 20 13:26:13 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16F01A9119; Thu, 19 Feb 2015 07:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8yJjX_kWXQZh; Thu, 19 Feb 2015 07:50:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E7C1A90E0; Thu, 19 Feb 2015 07:47:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 07:47:58 -0800 Archived-At: X-Mailman-Approved-At: Fri, 20 Feb 2015 13:26:12 -0800 Cc: gjshep@gmail.com, bier@ietf.org Subject: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 15:50:27 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-bier-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bier/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm fine with this going for external review. I would like to see the security properties of Bier called out more as something that the proposed WG will address, e.g. does the work to date include any integrity mechanisms so that one could check if a bit-flip is causing packets to be sent to the "wrong" places? Is there some (usable) security mechanism in place for establishing the bit-mask value to use at ingress? Etc. From nobody Fri Feb 20 13:26:14 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8D81A8722; Thu, 19 Feb 2015 10:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvdItPWwRjaJ; Thu, 19 Feb 2015 10:35:39 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09A01A877F; Thu, 19 Feb 2015 10:35:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CBBBEBED6; Thu, 19 Feb 2015 18:35:36 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtoFsetKifKT; Thu, 19 Feb 2015 18:35:35 +0000 (GMT) Received: from [172.16.20.132] (unknown [216.127.117.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4D5CABEE6; Thu, 19 Feb 2015 18:35:34 +0000 (GMT) Message-ID: <54E62CF5.6010608@cs.tcd.ie> Date: Thu, 19 Feb 2015 18:35:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alia Atlas References: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 20 Feb 2015 13:26:12 -0800 Cc: Greg Shepherd , "bier@ietf.org" , The IESG Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 19 Feb 2015 18:35:42 -0000 Hiya, On 19/02/15 16:00, Alia Atlas wrote: > Hi Stephen, > > On Thu, Feb 19, 2015 at 10:47 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> charter-ietf-bier-00-01: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/charter-ietf-bier/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> I'm fine with this going for external review. >> >> I would like to see the security properties of Bier called out more >> as something that the proposed WG will address, e.g. does the >> work to date include any integrity mechanisms so that one could >> check if a bit-flip is causing packets to be sent to the "wrong" >> places? Is there some (usable) security mechanism in place >> for establishing the bit-mask value to use at ingress? Etc. >> > > I did talk with Greg and Tony about the possibility of having an integrity > mechanism, > though MPLS doesn't and has been working ok. It is something that should > be > discussed in the context of an encapsulation; I just don't see it as > something that > needs to be pulled out into a separate work-item in the charter. Well, folks do sometimes forget security things if they're not called out, but I can live with that:-) > > I'm happy to chat with you and get your thoughts on what additional > security mechanisms might make sense to be concerned about. The integrity > of > the bitmap was the only one that I easily saw. Yep. Well, protecting it's integrity in transit, but presumably also trying to ensure one starts out with the right bit-mask as well. I agree though that generic mpls things (like opportunistic security:-) oughtn't be intertwined here. Cheers, S. > > Alia > From nobody Fri Feb 20 13:26:16 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCFB1A8724; Fri, 20 Feb 2015 10:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.906 X-Spam-Level: X-Spam-Status: No, score=-100.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FS_REPLICA=0.994, USER_IN_WHITELIST=-100] 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 a8U5RAtbIUHH; Fri, 20 Feb 2015 10:47:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8751A00FD; Fri, 20 Feb 2015 10:47:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220184757.28048.63722.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 10:47:57 -0800 Archived-At: X-Mailman-Approved-At: Fri, 20 Feb 2015 13:26:12 -0800 Cc: bier WG Subject: [Bier] WG Review: Bit Indexed Explicit Replication (bier) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 18:47:59 -0000 A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-03-02. Bit Indexed Explicit Replication (bier) ------------------------------------------------ Current Status: Proposed WG Chairs: Greg Shepherd Tony Przygienda Assigned Area Director: Alia Atlas Mailing list Address: bier@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bier Archive: http://www.ietf.org/mail-archive/web/bier/current/maillist.html Charter: In conventional IP multicast forwarding, the packets of a given multicast "flow" are forwarded along a tree that has been constructed for the specific purpose of carrying that flow. This requires transit nodes to maintain state on a per-flow basis, and requires the transit nodes to participate in multicast-specific tree building protocols. The flow to which a packet belongs is determined by its IP source and destination address fields. BIER (Bit Index Explicit Replication) is an alternative method of multicast forwarding. It does not require any multicast-specific trees, and hence does not require any multicast-specific tree building protocols. Within a given "BIER domain", an ingress node encapsulates a multicast data packet in a "BIER header". The BIER header identifies the packet's egress nodes in that domain. Each possible egress node is represented by a a single bit within a bitstring; to send a packet to a particular set of egress nodes, the ingress node sets the bits for each of those egress nodes, and clears the other bits in the bistring. Each packet can then be forwarded along the unicast shortest path tree from the ingress node to the egress nodes. Thus there are no per-flow forwarding entries. Due to the particular sensitivity of adding new significant functionality into the data-plane at high link speeds, the BIER work will progress as Experimental. As described in item (9) below, the work may become Standards Track once there is sufficient experience with the benefits and downsides of the technology. BIER is initially chartered to do experimental work on this new multicast forwarding mechanism as follows: 1) BIER architecture: The WG will publish an architecture, based upon draft-wijnands-bier-architecture-04. It will include the normative algorithm for how BIER packet forwarding is done. It will specify the information that is required by a BIER header to support BIER forwarding. 2) BIER encapsulation: The working group should assume that the technology will need to be embedded in the data plane and operate at the highest packet line speeds. The WG will publish a document defining an MPLS-based encapsulation based upon draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need to have a high-quality and stable RFC for a new data-plane encapsulation, the MPLS-based encapsulation draft shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. As a secondary focus, the WG may also work on one non-MPLS data-plane encapsulation. This draft also shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. This draft must focus on and include the following details: a) What is the applicability of the encapsulation and for which use-cases is this encapsulation required? b) Does this proposed encapsulation imply any changes to the MPLS-based encapsulation? c) What design choices have been made for the encapsulation type and the included fields. d) The proposed encapsulation with considerations given to at least OAM, Class of Service, security, fragmentation, TTL. 3) Transition Mechanisms: The WG will describe how BIER can be partially deployed and still provide useful functionality. A minimum of the necessary mechanisms to support incremental deployment and/or managing different BIER mask-length compatibility may be defined. Each such mechanism must include an applicability statement to differentiate its necessity from other proposed mechanisms. 4) Applicability Statements: The WG will work on a document describing how BIER can be applied to multicast L3VPN and to EVPN. This draft will describe what mechanism is used to communicate the group membership between the ingress router and the egress routers, what scalability considerations may arise, and any deployment considerations. 5) Use Case: The WG may produce one use-case document that clearly articulates the potential benefits of BIER for different use-cases. This would be based upon draft-kumar-bier-use-cases-01. 6) OAM: The WG will describe how OAM will work in a BIER domain and what simplifications BIER offers for managing the multicast traffic. A strong preference will be given to extensions to existing protocols. 7) Management models: The WG may work on YANG models and, if needed, MIB modules to support common manageability. 8) IGP extensions. When a BIER domain falls within a "link state IGP"" network, the information needed to set up the BIER forwarding tables (e.g., the mapping between a given bit position and a given egress router) may be carried in the link state advertisements of the IGP. The link state advertisments may also carry other information related to forwarding (e.g., the IGP may support multiple topologies, in which case it may be necessary to advertise which topologies are to be used for BIER forwarding). Any necessary extensions to the IGP will be specified by the WG, in cooperation with the ISIS and OSPF WGs. 9) Deployment Experience: Once there is deployment experience, the WG will produce a document describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms. Ideally, this should also contain an analysis of the impact and benefit of the new BIER data-plane to the overall Internet architecture. This document is intended to be used to evaluate whether to recharter BIER to produce Standards Track RFCs. The BIER working group will coordinate with several different working groups and must include the relevant other working groups during working group last call on the relevant drafts. BIER will coordinate with MPLS on the MPLS-based encapsulation and associated MPLS-based OAM mechanisms. BIER will coordinate with ISIS and OSPF on extensions to flood BIER-related information. BIER will coordinate with BESS and IDR on the applicability of existing BGP-based mechanisms for providing multicast group membership information. Milestones: TBD From nobody Fri Feb 20 15:02:40 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8701E1A0276; Fri, 20 Feb 2015 15:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-d5OJGF4AfG; Fri, 20 Feb 2015 15:02:38 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D269C1A0194; Fri, 20 Feb 2015 15:02:37 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-0e-54e75cc7b8a4 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AD.10.25146.7CC57E45; Fri, 20 Feb 2015 17:11:51 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Fri, 20 Feb 2015 18:02:36 -0500 From: Antoni Przygienda To: Stephen Farrell , The IESG Thread-Topic: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) Thread-Index: AQHQTFtu/8rPFJ0i10WzKm2dXjUQ6pz6GBcA Date: Fri, 20 Feb 2015 23:02:35 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1825FBD1@eusaamb103.ericsson.se> References: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> In-Reply-To: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPiO7xmOchBnuumFosnbGHyWLLnDyL GX8mMltM33uN3YHFY233VTaPnbPusnssWfKTKYA5issmJTUnsyy1SN8ugStj24+JTAVrOCo+ rS9oYLzK1sXIySEhYCLRse8DC4QtJnHh3nqgOBeHkMARRomDExqZIZzljBL3jvwF62ATsJC4 /O0pM4gtIuAp8bDvFFg3s4CXxInVa9lBbGGBeIlN93rZIWoSJE5MamOEsI0kXq2/C1bPIqAq 8erSTCYQm1fAW+Lm6p1g9UICjhJrNm9lBbE5BZwktm68DraXEei676fWMEHsEpe49WQ+E8TV AhJL9pxnhrBFJV4+/scKYStJTFp6jhWiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPYLCRj ZyFpmYWkZRaSlgWMLKsYOUqLU8ty040MNzECI+iYBJvjDsYFnywPMQpwMCrx8H7IehYixJpY VlyZe4hRmoNFSZy37MrBECGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MolfNXYJPcItofEo9 a/5a/ANznOeeO648G8Linpn6LZI8f0MldA9/8tGTOwRvbtjUutef61fql3DXozo/73yrYnIS XfZy/coTetf3iLyuPfzGv7Et7UQRk82uwOI58w6WW8rfPJ/1vixhpvp3E8MAV/bKork9cywc G1ZMvzB7gaRqUPb+uXenKbEUZyQaajEXFScCAB0k3n+BAgAA Archived-At: Cc: "gjshep@gmail.com" , "bier@ietf.org" Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 20 Feb 2015 23:02:39 -0000 What I suggested off the bat is something like 2 bits=20 1 - indicates presence of ECC bit=20 2 - ECC bit=20 treatment is probably simply discarding frames with corrupt bitmask.=20 At least in MPLS encaps we have enough space in the back after the bitmask = flew through before BFR-id.=20 Optional because it may be additional burden on the hardware. again, just a first shot idea without any further deeper thought =20 --- tony=20 >=20 > I'm fine with this going for external review. >=20 > I would like to see the security properties of Bier called out more as so= mething > that the proposed WG will address, e.g. does the work to date include any > integrity mechanisms so that one could check if a bit-flip is causing pac= kets to be > sent to the "wrong" > places? Is there some (usable) security mechanism in place for establishi= ng the > bit-mask value to use at ingress? Etc. >=20 >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Fri Feb 20 15:21:23 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0407A1A0393; Fri, 20 Feb 2015 15:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfeFdL1oEMOn; Fri, 20 Feb 2015 15:21:20 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4981A0396; Fri, 20 Feb 2015 15:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1405; q=dns/txt; s=iport; t=1424474480; x=1425684080; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=P0CLCLJ8OVPbVPEK6h+2fVefXSoCMRXms9QlfX12yTk=; b=id+q5YtbmyTjBR24qJyDT27+NlaIwyJ8BsfgCSbsyKgVYocuo4d9o/95 lI8JSzOYdBCNj676tiaNxeTHLCU5bRIfLMrQ0cUGAue7XzPrj5UE/8eR6 ER3bLnXHhUqI0VhQuT2LUeFisToGYvtN7VqVVGaLTpgyiA+wYRyyDDDRT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APBQAWwedU/5BdJa1bgwZSXsJ+CoVxAoEZQwEBAQEBAXyEEAEBBAEBATc0CxACAQg2ECcLJQIEAQ0FiC8N03MBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsPhG4HhCsBBI9Pg12FZZMxIoIygTxvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,617,1418083200"; d="scan'208";a="397971641" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 20 Feb 2015 23:21:19 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1KNLJTV006008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Feb 2015 23:21:19 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 20 Feb 2015 17:21:19 -0600 From: "Acee Lindem (acee)" To: Antoni Przygienda , Stephen Farrell , The IESG Thread-Topic: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) Thread-Index: AQHQTFtuE4Hwh0JVyEGkAuxxO7cXSpz6jn+A//+xaIA= Date: Fri, 20 Feb 2015 23:21:18 +0000 Message-ID: References: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> <2E4BB27CAB87BF43B4207C0E55860F1825FBD1@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1825FBD1@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="us-ascii" Content-ID: <0FA3F20F66211045B00DEC45E7D0AA7C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "gjshep@gmail.com" , "bier@ietf.org" Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 20 Feb 2015 23:21:22 -0000 Hi Tony,=20 Maybe we can get away with one bit: https://tools.ietf.org/html/rfc3514 ;) Acee=20 On 2/20/15, 6:02 PM, "Antoni Przygienda" wrote: >What I suggested off the bat is something like 2 bits > >1 - indicates presence of ECC bit >2 - ECC bit=20 > >treatment is probably simply discarding frames with corrupt bitmask. > >At least in MPLS encaps we have enough space in the back after the >bitmask flew through before BFR-id. > >Optional because it may be additional burden on the hardware. > >again, just a first shot idea without any further deeper thought > >--- tony=20 > >>=20 >> I'm fine with this going for external review. >>=20 >> I would like to see the security properties of Bier called out more as >>something >> that the proposed WG will address, e.g. does the work to date include >>any >> integrity mechanisms so that one could check if a bit-flip is causing >>packets to be >> sent to the "wrong" >> places? Is there some (usable) security mechanism in place for >>establishing the >> bit-mask value to use at ingress? Etc. >>=20 >>=20 >> _______________________________________________ >> 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 Fri Feb 20 15:50:25 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906471A0097 for ; Fri, 20 Feb 2015 15:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM9o6JU8y-31 for ; Fri, 20 Feb 2015 15:50:23 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49CB1A01EA for ; Fri, 20 Feb 2015 15:49:56 -0800 (PST) Received: by labhs14 with SMTP id hs14so9284396lab.1 for ; Fri, 20 Feb 2015 15:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ey3e6D/trxI9CysSDfZw73eXaXOyF6cWD2FqvTkVUTw=; b=Gk8xpXuFLzdWE/vs0AeFr5DMwYq+5JW3Fgt9WQIkzj7rMkXoeRiVjIAq6zLKQ5InZo Mw88CfiAZ3trNmpdUUuc6waBpZSI7pd6+3vBxcS5/9VvsOpmH76AWp/UzPOSqiiKp4G5 vmwn8V6afezxaHSJ0h1NaYBL3EghQIXvuaed2z82PNNrYyvEYgLyPm2fSfaMLr105Iqv lVxNf6nmVlp5FInFzXLd536OHsGC5HAFehzMOomUkO/DB4WPcGSrDRZMaeseTrmCGBi9 8DqZMdlrmPoHIBq/aSbr1Nka6T1GWSmkgdpHVM7OpI6zftjxFvtMAYcMygd8OzsyT4ya 2nyQ== MIME-Version: 1.0 X-Received: by 10.112.126.130 with SMTP id my2mr134324lbb.55.1424476195375; Fri, 20 Feb 2015 15:49:55 -0800 (PST) Received: by 10.152.113.168 with HTTP; Fri, 20 Feb 2015 15:49:55 -0800 (PST) Date: Fri, 20 Feb 2015 18:49:55 -0500 Message-ID: From: Aldrin Isaac To: bier@ietf.org Content-Type: multipart/alternative; boundary=001a11c373fa9dcfeb050f8db55b Archived-At: Subject: [Bier] Multicast needs BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 23:50:24 -0000 --001a11c373fa9dcfeb050f8db55b Content-Type: text/plain; charset=UTF-8 Hi, As an operator who runs a network where multicast is required and used extensively, I can vouch for the fact that existing approaches to multicast make it a non-starter for mission critical use cases. This speaks poorly to the way multicast is done today. Today I have no option but to use an approach that does a poor job of meeting my business requirements and expectations. Multi-destination forwarding needs more than a facelift- it needs an overhaul. BIER currently represents a fresh new way of looking at the problem that I am in full support of. It finally puts multi-destination forwarding at the same level as unicast. Unless someone can come up with something better than more lipstick on a pig, we need to see progress on BIER. Cheers, Aldrin --001a11c373fa9dcfeb050f8db55b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

As an operator who runs a network w= here multicast is required and used extensively, I can vouch for the fact t= hat existing approaches to multicast make it a non-starter for mission crit= ical use cases.=C2=A0 This speaks poorly to the way multicast is done today= .=C2=A0 Today I have no option but to use an approach that does a poor job = of meeting my business requirements and expectations.=C2=A0 Multi-destinati= on forwarding needs more than a facelift- it needs an overhaul. =C2=A0

BIER currently represents a fresh new way of looking a= t the problem that I am in full support of.=C2=A0 It finally puts multi-des= tination forwarding at the same level as unicast.=C2=A0 Unless someone can = come up with something better than more lipstick on a pig, we need to see p= rogress on BIER.

Cheers,
Aldrin
--001a11c373fa9dcfeb050f8db55b-- From nobody Fri Feb 20 16:18:58 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F331A03A3 for ; Fri, 20 Feb 2015 16:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12oBVe9sGu3W for ; Fri, 20 Feb 2015 16:18:56 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03D81A0137 for ; Fri, 20 Feb 2015 16:18:55 -0800 (PST) Received: by pdbfp1 with SMTP id fp1so11115861pdb.5 for ; Fri, 20 Feb 2015 16:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=xg9aTIgzZt3hAaaa8vmpcTS6ioSgRgk+wC3XgJ0Ib6M=; b=zzaQN6EL5u7WcyiOdnBqA+4inSe2eCrwSPoFFmO6WwaKuVbxXoGUFbF5K5+r9YnbJw KuJ6RLnjiu/mMVsXiMk5hFdbpcJCvp5Jr5FxGWuzPP2JIASxrtT1FZdNB+asqr47Lggv syO2bOzhmZs8t2sKtZJzmDj1n7Vw72Do2YLUJ51IcI8XjkNag1GZ2UT15a8Z8iG332Cu wqOEi7bIdpU0NYwH1T8UNo9txAHQyMqRJsBL7a1yJo+9UnDKxx/9GyrnkAwDjYWFlb+y AQb0cEPEFPbUUPpSfHd5NRtthJGq3rU1+DcbFLx/A/q7oaSek53aLQM+XJ+u2x18Axon bnFA== X-Received: by 10.70.42.206 with SMTP id q14mr241862pdl.141.1424477935157; Fri, 20 Feb 2015 16:18:55 -0800 (PST) Received: from [10.200.82.203] ([166.170.37.188]) by mx.google.com with ESMTPSA id x4sm26238413pbt.71.2015.02.20.16.18.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Feb 2015 16:18:54 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6A5725F9-E164-4E24-A287-874ACBA6E4BF@gmail.com> X-Mailer: iPhone Mail (11D167) From: Greg Shepherd Date: Fri, 20 Feb 2015 16:18:52 -0800 To: Aldrin Isaac Archived-At: Cc: "bier@ietf.org" Subject: Re: [Bier] Multicast needs BIER X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 00:18:57 -0000 Thanks Aldrin! Operator input is critical as we flesh out the details of BIE= R. I look forward to more of your input as the work progresses. Greg Sent from my iPhone > On Feb 20, 2015, at 15:49, Aldrin Isaac wrote: >=20 > Hi, >=20 > As an operator who runs a network where multicast is required and used ext= ensively, I can vouch for the fact that existing approaches to multicast mak= e it a non-starter for mission critical use cases. This speaks poorly to th= e way multicast is done today. Today I have no option but to use an approac= h that does a poor job of meeting my business requirements and expectations.= Multi-destination forwarding needs more than a facelift- it needs an overh= aul. =20 >=20 > BIER currently represents a fresh new way of looking at the problem that I= am in full support of. It finally puts multi-destination forwarding at the= same level as unicast. Unless someone can come up with something better th= an more lipstick on a pig, we need to see progress on BIER. >=20 > Cheers, > Aldrin > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Fri Feb 20 16:21:19 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0B51A065C; Fri, 20 Feb 2015 16:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMEr886CBMkR; Fri, 20 Feb 2015 16:21:12 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94F71A0461; Fri, 20 Feb 2015 16:21:10 -0800 (PST) Received: by pdjz10 with SMTP id z10so11059704pdj.12; Fri, 20 Feb 2015 16:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=1fViwuNIlmp3LopgWUYIZI0ZCg3hDImAt3CQ0U9W8rg=; b=fHXihEJLDDebuZB5PhtRLD4atnbvJBtyD3O25FyF6+LRB5slWbhbDTrhbIRNDarEDl 7JGB9jzKUQ+7hIj58IBxUQv4cWJanG6lHnWDRaq3L4UreiZe27BFT3ftWXNmVwd2z78i hLJm2udlWwpRWeuA0SyUHkCR6zqbbTPWVt0KvtJwVs8ovLEMcCpfxqjlbKHKiP8zIYKy Es9xNPtY9gS6yEevuxRJj9V0JOfQlw3GnnMXEG+EcCOuSXPnP8B49Frsd8Yf1a5ONzD8 1U3s0JB8XU6BGWylT7oePEvRUzsEjRoeRRj7KYlN/DjCa7rKbDTxwI6ER2eIgkSKxrHk ZvBQ== X-Received: by 10.70.136.66 with SMTP id py2mr512298pdb.100.1424478069961; Fri, 20 Feb 2015 16:21:09 -0800 (PST) Received: from [10.200.82.203] ([166.170.37.188]) by mx.google.com with ESMTPSA id sg4sm28374314pac.11.2015.02.20.16.21.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Feb 2015 16:21:08 -0800 (PST) References: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> <2E4BB27CAB87BF43B4207C0E55860F1825FBD1@eusaamb103.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D167) From: Greg Shepherd Date: Fri, 20 Feb 2015 16:21:06 -0800 To: "Acee Lindem (acee)" Archived-At: Cc: "bier@ietf.org" , Antoni Przygienda , The IESG , Stephen Farrell Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 21 Feb 2015 00:21:14 -0000 I agree with higher level motivation, but particularly with MPLS encap why s= hould BIER be treated with any more concern than all other MPLS packets? Greg Sent from my iPhone > On Feb 20, 2015, at 15:21, "Acee Lindem (acee)" wrote: >=20 > Hi Tony,=20 > Maybe we can get away with one bit: https://tools.ietf.org/html/rfc3514 ;)= > Acee=20 >=20 >=20 > On 2/20/15, 6:02 PM, "Antoni Przygienda" > wrote: >=20 >> What I suggested off the bat is something like 2 bits >>=20 >> 1 - indicates presence of ECC bit >> 2 - ECC bit=20 >>=20 >> treatment is probably simply discarding frames with corrupt bitmask. >>=20 >> At least in MPLS encaps we have enough space in the back after the >> bitmask flew through before BFR-id. >>=20 >> Optional because it may be additional burden on the hardware. >>=20 >> again, just a first shot idea without any further deeper thought >>=20 >> --- tony=20 >>=20 >>>=20 >>> I'm fine with this going for external review. >>>=20 >>> I would like to see the security properties of Bier called out more as >>> something >>> that the proposed WG will address, e.g. does the work to date include >>> any >>> integrity mechanisms so that one could check if a bit-flip is causing >>> packets to be >>> sent to the "wrong" >>> places? Is there some (usable) security mechanism in place for >>> establishing the >>> bit-mask value to use at ingress? Etc. >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 From nobody Fri Feb 20 16:22:41 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3549E1A049A; Fri, 20 Feb 2015 16:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWXfVPsR0nS3; Fri, 20 Feb 2015 16:22:38 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D34E1A0461; Fri, 20 Feb 2015 16:22:38 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-13-54e77bb1ae21 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 8C.74.03307.1BB77E45; Fri, 20 Feb 2015 19:23:46 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Fri, 20 Feb 2015 19:22:36 -0500 From: Antoni Przygienda To: "Acee Lindem (acee)" , Stephen Farrell , The IESG Thread-Topic: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) Thread-Index: AQHQTFtu/8rPFJ0i10WzKm2dXjUQ6pz6GBcAgABq3wD//7wuQA== Date: Sat, 21 Feb 2015 00:22:36 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1825FC8F@eusaamb103.ericsson.se> References: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> <2E4BB27CAB87BF43B4207C0E55860F1825FBD1@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.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPoO6m6uchBl8WcFlMfjuP2WLpjD1M Flvm5FnM+DOR2WL63mvsDqweU35vZPVY232VzWPnrLvsHkuW/GQKYInisklJzcksSy3St0vg yuj43cNaME2oonP6RLYGxmN8XYycHBICJhLPv39lg7DFJC7cWw9kc3EICRxhlLjduIAFwlnO KPHv7lpmkCo2AQuJy9+egtkiAkUS/zu+sILYzAJeEidWr2UHsYUF4iU23etlh6hJkDgxqY2x i5EDyHaSuNTLBRJmEVCVeLexjwXE5hXwllj6vIcdYtcSRokt72+DJTgFtCU2bvoBZjMCXff9 1BomiF3iEreezGeCuFpAYsme88wQtqjEy8f/WCFsRYl9/dPZIep1JBbs/sQGYWtLLFv4mhli saDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiyipGjtDi1LDfdyGATIzCujkmw6e5g3PPS8hCj AAejEg/vh6xnIUKsiWXFlbmHGKU5WJTEeRc9OBgiJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gTF7h7FazPFJR/ectikXNXn557Ls3Nsq3OE3Vn7fteVP8xUWya1zuNYV/f5RES+2IfrJ0pBr 3r/1q0/ZmxvWfHVcrTc5Kja1ti6fT2Fhk6c1T9zvYr3zGmeevpV5uWCGQquT9CTvg8zRxl4Z G6US69e1pPw1a0juWph+rVbBm8/gTGim5cX1d5VYijMSDbWYi4oTAc3CR9iMAgAA Archived-At: Cc: "gjshep@gmail.com" , "bier@ietf.org" Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 21 Feb 2015 00:22:40 -0000 Honestly, after having been presented with the concern=20 I was holding it with mild attempt to go after an Apr 1st draft but then th= e discussion started to sound serious ;-)=20 BIER over Avian Carriers will have to do then (we'll need a new encapsulati= on type to pull it off, probably BIER-in-CANS or=20 BIER-in-Bottles drafts to make sure the transport can lift it. You voluntee= r? ;-)=20 OK, me back to writing code here again and you get back to squint @ the yan= g models=20 --- tony=20 > -----Original Message----- > From: Acee Lindem (acee) [mailto:acee@cisco.com] > Sent: Friday, February 20, 2015 3:21 PM > To: Antoni Przygienda; Stephen Farrell; The IESG > Cc: gjshep@gmail.com; bier@ietf.org > Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-0= 0-01: > (with COMMENT) >=20 > Hi Tony, > Maybe we can get away with one bit: https://tools.ietf.org/html/rfc3514 ;= ) Acee >=20 >=20 > On 2/20/15, 6:02 PM, "Antoni Przygienda" > wrote: >=20 > >What I suggested off the bat is something like 2 bits > > > >1 - indicates presence of ECC bit > >2 - ECC bit > > > >treatment is probably simply discarding frames with corrupt bitmask. > > > >At least in MPLS encaps we have enough space in the back after the > >bitmask flew through before BFR-id. > > > >Optional because it may be additional burden on the hardware. > > > >again, just a first shot idea without any further deeper thought > > > >--- tony > > > >> > >> I'm fine with this going for external review. > >> > >> I would like to see the security properties of Bier called out more as > >>something > >> that the proposed WG will address, e.g. does the work to date include > >>any > >> integrity mechanisms so that one could check if a bit-flip is causing > >>packets to be > >> sent to the "wrong" > >> places? Is there some (usable) security mechanism in place for > >>establishing the > >> bit-mask value to use at ingress? Etc. > >> > >> > >> _______________________________________________ > >> 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 Fri Feb 20 17:48:59 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07B01A0AF7; Fri, 20 Feb 2015 17:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Daah_qlebuAM; Fri, 20 Feb 2015 17:48:51 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B063D1A0673; Fri, 20 Feb 2015 17:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2930; q=dns/txt; s=iport; t=1424483333; x=1425692933; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mcL3StHbgPz4CObQRYBYNxPiitb5fWNL0QVcf22okME=; b=FdUcNkpMm6eTh0aFzeTit0a8DDe04sYy+wh+tNLpPucLbEFOjLkQLf51 Mbmv5YkwLY7WsFCPiJW4s1uvsZfLQDTlpaElQ/Bdz7PRTi3rx9BXOIzhc I7oxbKfKvhdD52tod+91Xo6LSZ+ppkfhpIhmW2Bp3T+h9lULDL95yAamf s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQDq4udU/5xdJa1bgwZSXsJ+CoVxAoEZQwEBAQEBAXyEDwEBAQQBAQFkBwsMBAIBCBEEAQEBJwchBgsUCQgCBAENBYgbAxENzioNhSwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsPgkSCKgcGhCUFihmFNoNdhB+BRo0qhgcigjKBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,618,1418083200"; d="scan'208";a="397999784" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 21 Feb 2015 01:48:51 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t1L1mn1J005679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 21 Feb 2015 01:48:50 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Fri, 20 Feb 2015 19:48:49 -0600 From: "Acee Lindem (acee)" To: Antoni Przygienda , Stephen Farrell , The IESG Thread-Topic: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) Thread-Index: AQHQTFtuE4Hwh0JVyEGkAuxxO7cXSpz6jn+A//+xaICAAGTzAP//xEOA Date: Sat, 21 Feb 2015 01:48:48 +0000 Message-ID: References: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> <2E4BB27CAB87BF43B4207C0E55860F1825FBD1@eusaamb103.ericsson.se> <2E4BB27CAB87BF43B4207C0E55860F1825FC8F@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1825FC8F@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "gjshep@gmail.com" , "bier@ietf.org" Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 21 Feb 2015 01:48:54 -0000 On 2/20/15, 7:22 PM, "Antoni Przygienda" wrote: >Honestly, after having been presented with the concern >I was holding it with mild attempt to go after an Apr 1st draft but then >the discussion started to sound serious ;-) > >BIER over Avian Carriers will have to do then (we'll need a new >encapsulation type to pull it off, probably BIER-in-CANS or >BIER-in-Bottles drafts to make sure the transport can lift it. You >volunteer? ;-) I have extensive experience in this area and would be open to reviewing some drafts in Dallas. I'd even review them without prior viewing (i.e., I=B9ll review these BIER drafts cold...). >=20 > >OK, me back to writing code here again and you get back to squint @ the >yang models Yeah - I do have to get back to those YANG models. But on a more serious note, I don=B9t believe we want to go down the path of encapsulation security (MPLS, BIER, or otherwise). We will always have authentication in the endpoints.=20 Acee=20 >=20 > >--- tony=20 > >> -----Original Message----- >> From: Acee Lindem (acee) [mailto:acee@cisco.com] >> Sent: Friday, February 20, 2015 3:21 PM >> To: Antoni Przygienda; Stephen Farrell; The IESG >> Cc: gjshep@gmail.com; bier@ietf.org >> Subject: Re: [Bier] Stephen Farrell's No Objection on >>charter-ietf-bier-00-01: >> (with COMMENT) >>=20 >> Hi Tony, >> Maybe we can get away with one bit: https://tools.ietf.org/html/rfc3514 >>;) Acee >>=20 >>=20 >> On 2/20/15, 6:02 PM, "Antoni Przygienda" >> >> wrote: >>=20 >> >What I suggested off the bat is something like 2 bits >> > >> >1 - indicates presence of ECC bit >> >2 - ECC bit >> > >> >treatment is probably simply discarding frames with corrupt bitmask. >> > >> >At least in MPLS encaps we have enough space in the back after the >> >bitmask flew through before BFR-id. >> > >> >Optional because it may be additional burden on the hardware. >> > >> >again, just a first shot idea without any further deeper thought >> > >> >--- tony >> > >> >> >> >> I'm fine with this going for external review. >> >> >> >> I would like to see the security properties of Bier called out more >>as >> >>something >> >> that the proposed WG will address, e.g. does the work to date include >> >>any >> >> integrity mechanisms so that one could check if a bit-flip is causing >> >>packets to be >> >> sent to the "wrong" >> >> places? Is there some (usable) security mechanism in place for >> >>establishing the >> >> bit-mask value to use at ingress? Etc. >> >> >> >> >> >> _______________________________________________ >> >> 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 Fri Feb 20 18:34:47 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A261A19E3; Fri, 20 Feb 2015 18:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7krAvYbvc2CH; Fri, 20 Feb 2015 18:34:43 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D8D1A005D; Fri, 20 Feb 2015 18:34:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C8CA3BEC4; Sat, 21 Feb 2015 02:34:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdOBHli2lcfi; Sat, 21 Feb 2015 02:34:39 +0000 (GMT) Received: from [10.1.2.38] (unknown [216.9.108.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C3C4ABEC3; Sat, 21 Feb 2015 02:34:38 +0000 (GMT) Message-ID: <54E7EEB7.5010109@cs.tcd.ie> Date: Sat, 21 Feb 2015 02:34:31 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Acee Lindem (acee)" , Antoni Przygienda , The IESG References: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> <2E4BB27CAB87BF43B4207C0E55860F1825FBD1@eusaamb103.ericsson.se> <2E4BB27CAB87BF43B4207C0E55860F1825FC8F@eusaamb103.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "gjshep@gmail.com" , "bier@ietf.org" Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 21 Feb 2015 02:34:45 -0000 Nothing to do with the bier charter's progression, but I'm curious... On 21/02/15 01:48, Acee Lindem (acee) wrote: > on a more serious > note, I donĀ¹t believe we want to go down the path of encapsulation > security (MPLS, BIER, or otherwise). We will always have authentication in > the endpoints. Can you translate that into something I understand I wonder? :-) When you say "authentication in the endpoints" who do you mean is authenticating what to whom? Ta, S. PS: I'm fine continuing this chat offlist or in a fine bar in Dallas (assuming an accessible one exists:-) From nobody Sat Feb 21 04:24:22 2015 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9581A6F7C; Sat, 21 Feb 2015 04:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvSPLyoBGiDL; Sat, 21 Feb 2015 04:24:19 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8F31A0077; Sat, 21 Feb 2015 04:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1668; q=dns/txt; s=iport; t=1424521460; x=1425731060; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sUJrcKZDnuwbsUiQCqBbJWjWq0d8GwJL3dGqs41VZ04=; b=MGgN6vKy8mirKprG/pWz2ftJtjfXOA2phM9jZPpF2bF54HeEmuTRl8Ra UzOotgiL3ZfE25GjeEhrigAoN5/aLbXl3l3wlS96LQzWlbrcsN+Wk7KJq mCB6hhuO9nKc+c9tV8XPp/+hhceVwU0LwEjhID5j/cEcnLW/tLm98mMYe 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CjBQAFeOhU/5RdJa1bgwaBLASDBMV5Ahx9QwEBAQEBAXyEEAEBBDRFEAIBCBgEKAICMCUCBAENBYgvnh+cZAaYNgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBG4l0hFMbB4JigUkBBI9OiUGTMCKCMoE8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,620,1418083200"; d="scan'208";a="125670397" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 21 Feb 2015 12:24:19 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1LCOIFl025364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 21 Feb 2015 12:24:18 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Sat, 21 Feb 2015 06:24:18 -0600 From: "Acee Lindem (acee)" To: Stephen Farrell , Antoni Przygienda , The IESG Thread-Topic: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) Thread-Index: AQHQTFtuE4Hwh0JVyEGkAuxxO7cXSpz6jn+A//+xaICAAGTzAP//xEOAgABgmICAAFD0gA== Date: Sat, 21 Feb 2015 12:24:17 +0000 Message-ID: References: <20150219154758.16857.55616.idtracker@ietfa.amsl.com> <2E4BB27CAB87BF43B4207C0E55860F1825FBD1@eusaamb103.ericsson.se> <2E4BB27CAB87BF43B4207C0E55860F1825FC8F@eusaamb103.ericsson.se> <54E7EEB7.5010109@cs.tcd.ie> In-Reply-To: <54E7EEB7.5010109@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="euc-kr" Content-ID: <7EEB45EBBF849B45B035986D21E1E5DB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "gjshep@gmail.com" , "bier@ietf.org" Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT) 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, 21 Feb 2015 12:24:21 -0000 DQoNCk9uIDIvMjAvMTUsIDk6MzQgUE0sICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllPiB3cm90ZToNCg0KPg0KPk5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgYmllciBj aGFydGVyJ3MgcHJvZ3Jlc3Npb24sIGJ1dCBJJ20gY3VyaW91cy4uLg0KPg0KPk9uIDIxLzAyLzE1 IDAxOjQ4LCBBY2VlIExpbmRlbSAoYWNlZSkgd3JvdGU6DQo+PiBvbiBhIG1vcmUgc2VyaW91cw0K Pj4gbm90ZSwgSSBkb26p9nQgYmVsaWV2ZSB3ZSB3YW50IHRvIGdvIGRvd24gdGhlIHBhdGggb2Yg ZW5jYXBzdWxhdGlvbg0KPj4gc2VjdXJpdHkgKE1QTFMsIEJJRVIsIG9yIG90aGVyd2lzZSkuIFdl IHdpbGwgYWx3YXlzIGhhdmUgYXV0aGVudGljYXRpb24NCj4+aW4NCj4+IHRoZSBlbmRwb2ludHMu IA0KPg0KPkNhbiB5b3UgdHJhbnNsYXRlIHRoYXQgaW50byBzb21ldGhpbmcgSSB1bmRlcnN0YW5k IEkgd29uZGVyPyA6LSkgV2hlbg0KPnlvdSBzYXkgImF1dGhlbnRpY2F0aW9uIGluIHRoZSBlbmRw b2ludHMiIHdobyBkbyB5b3UgbWVhbiBpcw0KPmF1dGhlbnRpY2F0aW5nIHdoYXQgdG8gd2hvbT8N Cg0KSSBtZWFudCB0aGF0IG11bHRpY2FzdCByZWNlaXZlcnMgY291bGQgYXV0aGVudGljYXRlIHJl Y2VpdmVkIG11bHRpY2FzdA0KcGFja2V0cy4gVXBvbiBmdXJ0aGVyIHJlZmxlY3Rpb24sIHRoaXMg cHJvYmFibHkgaXNuoa90IGFsbCB0aGF0IHJlbGV2YW50IG9yDQppbnRlcmVzdGluZy4gVGhlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBCSUVSIGFyZSBzaW1pbGFyIHRvDQpjb252ZW50aW9u YWwgbXVsdGljYXN0IGV4Y2VwdCB0aGF0IHRoZSBtdWx0aWNhc3QgY29yZSBkb2VzbqGvdCBoYXZl IGFsbCB0aGUNCihTLEcpIHN0YXRlLiBIZW5jZSwgSSBiZWxpZXZlIHdoYXQgcmVhbGx5IG5lZWRz IHRvIGJlIGRlZmluZWQgaXMgdGhlIGxldmVsDQpvZiB0cnVzdCByZXF1aXJlZCB3aXRoaW4gYSBC SUVSIGRvbWFpbiBhbmQgdGhlIHJvbGUgb2YgdGhlIEJJRVIgZG9tYWluDQpib3JkZXIgcm91dGVy cyBpbiBwcm90ZWN0aW5nIHRoYXQgZG9tYWluLg0KDQpUaGFua3MsDQpBY2VlIA0KDQoNCg0KDQo+ DQo+VGEsDQo+Uy4NCj4NCj5QUzogSSdtIGZpbmUgY29udGludWluZyB0aGlzIGNoYXQgb2ZmbGlz dCBvciBpbiBhIGZpbmUgYmFyIGluIERhbGxhcw0KPihhc3N1bWluZyBhbiBhY2Nlc3NpYmxlIG9u ZSBleGlzdHM6LSkNCj4NCj4NCg0K

      Length:5

 

      Value: cont= ains a two-octet BFR-ID.

 

I am missing here the indicati= on of subdomain-id since without that, the BFR-ID will easily collide withi= n the BIER domain advertising the BGP info @ the edge.

 

[Xiaohu] Thanks for point it out. Will fix it in the next version.

 <= /i>

[Tony said] ack=

 

The BSL TLV is encoded as follows:

 

      Type:TBD= 3

 

      Length:4=

 

      Value: c= ontains a one-octet BSL which indicates the length of the=

      Bitstrin= g in 4-octets.

 

Is this encoded equivalent to = MPLS draft ? Indicate so and indicate WHICH bits are used and which are res= erved. If not, indicate how e.g.  33 as bitstring length should be treated if e.g. the ensuing encaps cannot deal = with it ?

 

[Xiaohu] IMHO, it’d better to specify the legal BSL values in the B= IER arch draft which should be independent of specific BIER encapsulations.

 <= /i>

[Tony said]  agreed, that’s a= heads-up for Ice to put it into the architecture draft me thinks. It’s hanging in the MPLS draft right now. Given how widel= y it’s referenced, it should be moved up me thinks.

 

   The BIER MPLS Encapsualtio= n TLV is encoded as follows:

 

      Type:TBD= 4

 

      Length:7=

 

      Value: c= ontains a one-octet Label Range Size field indicating the=

      size of = the label range, and a 3-octect Label Rang Base field

      where th= e 20 rightmost bits represent the first label in the label

      range.

 

indicate that the other bits a= re reserved/must be ignored/send 0

 

Generally, it is considered de= rigeur to make nice pictures of those TLVs to make the documents more read= able. I suggest doing so.

 

[Xiaohu] Thanks for the above suggestions. Will fix them in the next vers= ion.

 <= /i>

[Tony said] ack=

 

Another question here is what = happens when multiple eBPG edges of an AD advertise this attribute. Is the = preference driven by MED [or another attribute?] based e.g. on the IGP distance within AD to the BFR ?

 

[Xiaohu] I think so.

 <= /i>

[Tony said] ack, I suggest to put it int= o lead-in section (Special considerations, requireements, assumptions, something ?)

 

Is the expectation that each B= GP router advertising this is BFR itself ? Or has capabilities to unicast t= unnel into the BIER domain ?

 

[Xiaohu]Since the BIER attribute is an optional, transitive BGP path attr= ibute, it should support the scenario where a BGP speaker is allowed to tunnel a BIER packet or the payload of a BIER = packet to the BFER directly if the BGP next-hop is a non-BFR. Furthermore, = it should support as well the scenario where a BGP speaker is allowed to tu= nnel a BIER packet to the BGP next-hop if these two BGP peers are not directly connected (e.g., multi-hop EBGP) .=

 

[Tony said] [Tony said] Ye= s, I suggest a small section stating this and explaining this.

 

Overall, this seems to imply s= omewhat that BIER domain is aligned with the whole IGP domain (and not area= s) and e.g. two OSPF areas cannot be two BIER domains.  This is an interesting architectural question that was= n’t brought up yet ?

 <= /i>

 

[Xiaohu] In this doc, it’s assumed t= hat a BIER domain is aligned with the whole network consist of multiple ASes.

[Tony s= aid] Let’s spell it out and have a discussion @ next BOF/WG [whatever we become when we’ve grown up to have a char= ter ;-) ]  I think it will be a very relevant architectural decision a= t this point in time and possibly influence all IGP drafts. What speaks aga= inst BIER domain aligned with AD is scalabilty, what speaks for it is simplicity.

--- tony