From nobody Tue Feb 4 05:07:14 2020 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358481200E9 for ; Tue, 4 Feb 2020 05:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 n7w2IvJ0QRgg for ; Tue, 4 Feb 2020 05:07:10 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 851481200EB for ; Tue, 4 Feb 2020 05:07:10 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id q8so9439726pfh.7 for ; Tue, 04 Feb 2020 05:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=lp26A0iLzw9zWqap/vIftmQfMbfvpqzrnLAtdcSXD7g=; b=mVDc/xpw/5JpENqG4ie58lk9Adp4T4koqZVwFL21wgmRyrTPlYQNDG+zt4PQDXMg1O +wGDqS9tlMjed/9CAsV1U925UzD1oH7FHGp3MxtFM6LpwyMkpykNiUedaYzOHV0Wve3D 2HpyutrSlP0gkESXD2O6MI8dyN5VZe6rPD7TtBBrrJlGSgOB1PTi0BIwc3hrZH8GyqkN Mz002FNteBzF6DqUzClvCnvnFuWNDKbJJcLPNxhZlnbpF1E5RJUT3dyEynf98UDA7Mwh T0H/lFf0sGCW7N03ZYLmVhZR61bTB3sy2vvOPdbPr4Ml1YAaYAtS/qQFwCsgu97Qq0Sp 6wvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=lp26A0iLzw9zWqap/vIftmQfMbfvpqzrnLAtdcSXD7g=; b=CsdfoD5iqbt47VnWvugI8Y+bNCRqpitCWUNCH+miMmZjN1x2Acz4vg+dnSXKQ2qWOB OX/ZgYZrltuLgLyTmj4ZCB1bvvsw215K+7GUiOfyiCzryKZ3eC5kbV6D9IGnSPL74yc5 kqXeBdXwT5wzmB6pZh9WlZ2ji8o4Xyguh9LP699DNC9hNUuGkpJ4+eB7JmNcdnFGXXnB X7jW3yjwS9DZqdCh02eVfvtDSGAyFIdOQo8xKS/zxVSnL1qF9s4AA6kNKrzE3lQM3BqG nqf6DSgrCtPE3oyFpLXvE54lK6OLq1RnJODIQ3xpVp6Q7K+KTUR856RH3CWKauaq4sXy 6otg== X-Gm-Message-State: APjAAAUb7IT8kyvRJ+Lqiyogh2stPGuHKA0k6n3IJbYymw5C+dCbUpiS pzC7FYl4GFICMJW/4uoM4Slh3feLXEd93QZlW8z+4cze6bCeLQ== X-Google-Smtp-Source: APXvYqxDJkGHjLQqhKEOK+qtL2FjEBux2uAC8ua839uU6e/IBEH4VeD/KBoan7FTZXeu3w182PSFZkHl+G8RmOi+WNU= X-Received: by 2002:a63:fb05:: with SMTP id o5mr32041649pgh.355.1580821629541; Tue, 04 Feb 2020 05:07:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vishnu Pavan Beeram Date: Tue, 4 Feb 2020 07:06:58 -0600 Message-ID: To: TEAS WG Content-Type: multipart/alternative; boundary="000000000000aea081059dbfb761" Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-te-metric-recording-09 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 13:07:12 -0000 --000000000000aea081059dbfb761 Content-Type: text/plain; charset="UTF-8" WG, The LC for this draft closed on Jan 13th. Since there wasn't any support for the draft during the last call, we have decided to NOT progress this draft to the publication stage. The WG can revisit this draft (which is currently expired) at a later point in time if there is sufficient amount of interest in implementing the procedures defined in the draft. Regards, -Pavan and Lou On Mon, Jan 6, 2020 at 5:09 AM Vishnu Pavan Beeram wrote: > All, > > We haven't seen any responses at all for this on the list (blame it on the > holiday season). We'll extend the last call by one more week and see how it > goes -- the last call now ends on Jan 13th. > > Regards, > Pavan and Lou > > On Mon, Dec 16, 2019 at 8:48 PM Vishnu Pavan Beeram > wrote: > >> >> All, >> This starts a *three-week* working group last call on >> draft-ietf-teas-te-metric-recording-09 >> >> The working group last call ends on Jan 6th (extra week to account for >> the holidays). Please send your comments to the teas mailing list. >> >> Positive comments, e.g., "I've reviewed this document and believe it is >> ready for publication", are welcome! This is useful and important, even >> from authors. >> >> NOTE: IPR has been disclosed on this document >> >> Thank you, >> TEAS Chairs >> > --000000000000aea081059dbfb761 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

WG,

The LC for this = draft closed on Jan 13th.

<= span style=3D"font-size:11pt">=C2=A0

<= span style=3D"font-size:11pt">Since there wasn't any support for the dr= aft during the last call, we have decided to NOT progress this draft to the= publication stage. The WG can revisit this draft (which is currently expir= ed) at a later point in time if there is sufficient amount of interest in i= mplementing the procedures defined in the draft.

=C2=A0

Regards,

<= p class=3D"MsoNormal" style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-= family:Calibri,sans-serif;color:rgb(0,0,0);font-style:normal;font-variant-c= aps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-i= ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-deco= ration:none">-Pavan and Lou

=
On Mon= , Jan 6, 2020 at 5:09 AM Vishnu Pavan Beeram <vishnupavan@gmail.com> wrote:
All,

We haven't seen any responses at all for this on the = list (blame it on the holiday season). We'll extend the last call by on= e more week and see how it goes -- the last call now ends on Jan 13th.

Regards,
Pavan and Lou

On Mon, Dec 16, 20= 19 at 8:48 PM Vishnu Pavan Beeram <vishnupavan@gmail.com> wrote:

All,
This starts a *three-week* working group last call on draft-ietf-teas-te-metric-recording-09
The working group last call<= /span> ends on Jan 6th (extra week to account for the holidays). Please sen= d your comments to the teas mailing list.

Positive comments, e.g., "I've reviewed this document and believe = it is ready for publication", are welcome! This is useful and importan= t, even from authors.

NOTE: IPR has been disclosed on this document

Thank you,
TEAS Chairs
--000000000000aea081059dbfb761-- From nobody Mon Feb 10 09:22:50 2020 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6974812080C; Mon, 10 Feb 2020 09:22:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: "Vishnu Pavan Beeram" , "Lou Berger" Cc: GSMALiaisons@gsma.com, Deborah Brungard , Vishnu Beeram , ZSMSupport@etsi.org, 3GPPliaison@etsi.org, Martin Vigoureux , Alvaro Retana , Lou Berger , Traffic Engineering Architecture and Signaling Discussion List X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158135536833.4044.13200557926696328153.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2020 09:22:48 -0800 Archived-At: Subject: [Teas] New Liaison Statement, "Liaison from ISG ZSM to IETF for TN coordination" X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 17:22:49 -0000 Title: Liaison from ISG ZSM to IETF for TN coordination Submission Date: 2020-02-10 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1671/ From: Ishan Vaishnavi To: Vishnu Pavan Beeram , Lou Berger Cc: Deborah Brungard ,Vishnu Beeram ,Martin Vigoureux ,Alvaro Retana ,Lou Berger ,Traffic Engineering Architecture and Signaling Discussion List ,3GPPliaison@etsi.org,GSMALiaisons@gsma.com Response Contacts: ZSMSupport@etsi.org Technical Contacts: Purpose: For information Body: Attachments: ZSM(19)000648r4_ZSM003_Liaison_to_IETF_for_TN_coordination https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-02-10-etsi-isg-zsm-teas-liaison-from-isg-zsm-to-ietf-for-tn-coordination-attachment-1.docx From nobody Tue Feb 18 07:02:38 2020 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C29120170; Tue, 18 Feb 2020 07:02:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: teas@ietf.org Message-ID: <158203815089.14097.3360680124342315520@ietfa.amsl.com> Date: Tue, 18 Feb 2020 07:02:31 -0800 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-enhanced-vpn-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 15:02:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : A Framework for Enhanced Virtual Private Networks (VPN+) Services Authors : Jie Dong Stewart Bryant Zhenqiang Li Takuya Miyasaka Young Lee Filename : draft-ietf-teas-enhanced-vpn-05.txt Pages : 40 Date : 2020-02-18 Abstract: This document describes the framework for Enhanced Virtual Private Network (VPN+) service. The purpose is to support the needs of new applications, particularly applications that are associated with 5G services, by utilizing an approach that is based on existing VPN and TE technologies and adds features that specific services require over and above traditional VPNs. Typically, VPN+ will be used to form the underpinning of network slicing, but could also be of use in its own right providing enhanced connectivity services between customer sites. It is envisaged that enhanced VPNs will be delivered using a combination of existing, modified, and new networking technologies. This document provides an overview of relevant technologies and identifies some areas for potential new work. It is not envisaged that quite large numbers of VPN+ services will be deployed in a network and, in particular, it is not intended that all VPNs supported by a network will use VPN+ related techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-05 https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-enhanced-vpn-05 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/ From nobody Wed Feb 19 05:44:55 2020 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 783E612002F; Wed, 19 Feb 2020 05:44:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: teas@ietf.org Message-ID: <158211988117.17549.12144184579461512880@ietfa.amsl.com> Date: Wed, 19 Feb 2020 05:44:41 -0800 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-actn-yang-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 13:44:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks Authors : Young Lee Haomian Zheng Daniele Ceccarelli Bin Yeong Yoon Oscar Gonzalez de Dios Jong Yoon Shin Sergio Belotti Filename : draft-ietf-teas-actn-yang-05.txt Pages : 19 Date : 2020-02-19 Abstract: Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network operations needed to orchestrate, control and manage large-scale multi-domain TE networks, so as to facilitate network programmability, automation, efficient resource sharing, and end-to- end virtual service aware connectivity and network function virtualization services. This document explains how the different types of YANG models defined in the Operations and Management Area and in the Routing Area are applicable to the ACTN framework. This document also shows how the ACTN architecture can be satisfied using classes of data model that have already been defined, and discusses the applicability of specific data models that are under development. It also highlights where new data models may need to be developed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-actn-yang-05 https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-yang-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-yang-05 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/ From nobody Wed Feb 19 10:14:44 2020 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FF2120111; Wed, 19 Feb 2020 10:14:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: "Dhruv Dhody" , "Julien Meuric" , "Stewart Bryant" , "Fatai Zhang" , "Daniele Ceccarelli" , "Andrew Malis" , "Loa Andersson" , "Lou Berger" , "Vishnu Pavan Beeram" , "Tarek Saad" , "Nicolai Leymann" Cc: Deborah Brungard , Julien Meuric , Multiprotocol Label Switching Discussion List , Dhruv Dhody , Pseudowire And LDP-enabled Services Discussion List , Andrew Malis , Common Control and Measurement Plane Discussion List , Traffic Engineering Architecture and Signaling Discussion List , Martin Vigoureux , Scott Mansfield , sshew@ciena.com, Fatai Zhang , Nicolai Leymann , John Drake , Loa Andersson , Daniele Ceccarelli , Vishnu Beeram , Stewart Bryant , Path Computation Element Discussion List , Lou Berger , Tarek Saad , itu-t-liaison@iab.org, Alvaro Retana X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158213607762.17596.1750884122514290928.idtracker@ietfa.amsl.com> Date: Wed, 19 Feb 2020 10:14:37 -0800 Archived-At: Subject: [Teas] New Liaison Statement, "LS on OTNT Standardization Work Plan Issue 27" X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 18:14:38 -0000 Title: LS on OTNT Standardization Work Plan Issue 27 Submission Date: 2020-02-19 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1673/ Please reply by 2020-08-20 From: Hiroshi Ota To: Vishnu Pavan Beeram , Lou Berger ,Andrew Malis ,Stewart Bryant ,Loa Andersson ,Nicolai Leymann ,Tarek Saad ,Julien Meuric ,Dhruv Dhody ,Daniele Ceccarelli ,Fatai Zhang Cc: Deborah Brungard ,Julien Meuric ,Multiprotocol Label Switching Discussion List ,Dhruv Dhody ,Pseudowire And LDP-enabled Services Discussion List ,Andrew Malis ,Common Control and Measurement Plane Discussion List ,Traffic Engineering Architecture and Signaling Discussion List ,John Drake ,Scott Mansfield ,Fatai Zhang ,Nicolai Leymann ,Martin Vigoureux ,Loa Andersson ,Daniele Ceccarelli ,Vishnu Beeram ,Stewart Bryant ,Path Computation Element Discussion List ,Lou Berger ,Tarek Saad ,itu-t-liaison@iab.org,Alvaro Retana Response Contacts: sshew@ciena.com Technical Contacts: Purpose: For action Body: Attached is Issue 27 of the OTNT SWP, the latest version updated by the SG15 during a plenary meeting in February 2020. We would appreciate updates to the material relevant to your SDO. Attachment: Optical Transport Networks & Technologies Standardization Work Plan Issue 27, February 2020 Attachments: SG15-LS245 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-02-19-itu-t-sg-15-mpls-ccamp-pce-pals-teas-ls-on-otnt-standardization-work-plan-issue-27-attachment-1.pdf SG15-LS245-Att-OTN-issue27 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-02-19-itu-t-sg-15-mpls-ccamp-pce-pals-teas-ls-on-otnt-standardization-work-plan-issue-27-attachment-2.pdf From nobody Wed Feb 19 15:43:05 2020 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4141208CA for ; Wed, 19 Feb 2020 15:43:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 GG6M9rM7u5VB for ; Wed, 19 Feb 2020 15:42:55 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 36B3612082A for ; Wed, 19 Feb 2020 15:42:55 -0800 (PST) Received: from CMGW (unknown [10.9.0.13]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 32EC7215FF6 for ; Wed, 19 Feb 2020 16:41:15 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 4YxujfsHVfYE44YxujlxWj; Wed, 19 Feb 2020 16:41:15 -0700 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.2 cv=GJF4KqFK c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=l697ptgUJYAA:10 a=Vy_oeq2dmq0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=uherdBYGAAAA:8 a=bt8Zh30PAAAA:8 a=AUd_NHdVAAAA:8 a=CSO2qyI7bvr0v1_EvZ0A:9 a=6nr61LhBIYs0Ebk_:21 a=uJwmFCyPhUBEBMcX:21 a=7tK4qQerbkCMhLv0:21 a=QEXdDO2ut3YA:10 a=Y8UcbigLlIYA:10 a=dabfb9kwXn6cJaoZwxsA:9 a=9BybeBe_fWqFCivL:21 a=P52fktDv3FPoDL2V:21 a=QgMxFhycZdd_iLEp:21 a=_W_S_7VecoQA:10 a=c3Crxy7vjRUxnh_TEpKa:22 a=w1C3t2QeGrPiZgrLijVG:22 a=Ef4yma5cpRUEJWN9UqBm:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:To: References:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=anmsHCGDPmeDi/xmuNQldRjAAVvAx+1GdlnYIqE0GNw=; b=kM70eCFpHTr1YtHv+8xpBJoOv9 vaV+LcQzSfBAGltzB5fMFDC0cmzi+dg+Y+UTIqMTyZ8NX1W3VvylLNFM5JhT2T4ewubSbCIjmBsM5 yehWeVbwlcnEHDlIBSssqSC25; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:60472 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j4Yxt-0000PQ-Tt for teas@ietf.org; Wed, 19 Feb 2020 16:41:14 -0700 References: To: teas@ietf.org From: Lou Berger X-Forwarded-Message-Id: Message-ID: Date: Wed, 19 Feb 2020 18:41:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B43183003256DEC17CFA1947" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1j4Yxt-0000PQ-Tt X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net (fs2.dc.labn.net) [72.66.11.201]:60472 X-Source-Auth: lberger@labn.net X-Email-Count: 10 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [Teas] Fwd: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 23:43:02 -0000 This is a multi-part message in MIME format. --------------B43183003256DEC17CFA1947 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit FYI - this may be of interest to some. https://mailarchive.ietf.org/arch/browse/bier/ -------- Forwarded Message -------- Subject: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK Date: Tue, 18 Feb 2020 12:45:54 -0800 From: Greg Shepherd Reply-To: gjshep@gmail.com To: Jeffrey (Zhaohui) Zhang CC: Toerless Eckert , bier@ietf.org Thanks Toerless and Jeffrey https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ One more week of WGLC. Please read the latest rev and respond to this thread w/wo support. Chairs (Shep) On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang > wrote: Hi Toerless, Thanks! I support moving this to the next stage. Jeffrey On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > Thanks Jeff > > I have now pushed out -05 with the answers and hopefully resolution to > your points in email below.  Biggest addition was a section about > reuse of BPs (without DNR) which came out of the confusion i think the > reuse in the ECMP example raised. I was afraid so far to explan that > as it may not be easy to absorb and ultimately is stuff only > controller developers need to understand, but hopefully useful. > And then of course the summary of BP optimizatins you asked for > > Diff from last version i sent you: > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > **Araw.githubusercontent.com *toerless*bier-te-arch*master*draft-ietf-b > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org *id*draft-ietf-bier-te > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > full -04 -> 05 diff: > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* > *Atools.ietf.org *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. > ietf.org *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ > > Comments inline below. > > Cheers >     toerless > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang wrote: > > I Thought u-turn is the most simple comparison leaf vs. non-leaf BFR. > > > > Zzh> The text in the email is seriously misaligned. Looking at the picture in the diff link, while you gave a U-turn example, though even if BFER2 is not connected to BFR2  but only connected to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I suppose. That's why I said the first sentence of the above paragraph is enough to define Leaf BFER while the example itself is actually not needed. > > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> right-hand: > > Consider how redundant disjoint traffic can reach BFER1/BFER2 in above > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right hand > side, one traffic copy would be forwarded to BFER1 from BFR1, but the > other one could only reach BFER1 via BFER2, which makes BFER2 a > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding > traffic to BFER2 > > > Zzh> Additionally, in left part of the picture you added, if some failure leads to BFR2 to be only reachable via BFER1, then BFER1 is no longer a leaf BFER. > > Added sentence: > > Note that the BFER in the left hand picture are only guaranteed to > be leaf-BFR by fitting routing configuration that prohibits transit > traffic to pass through a PE, which is commonly applied in these > topologies. > > > I assume you don't reassign BPs when links go up and down. > > I didn't want to discuss that option in this document. Its obviously > perfectly feasible, but be yet a big amount of text (especially the > considerations how to do this make-before-break. Future doc. > > > > but subsequent polarization example confuses me. It seems that BP 0:6 is assigned to the routed adjacency BFR10 (which is actually talked about in Section 4.8). > > > > Section 4.7 does not mention "routed" at all, so there are no routed adjacencies at all used in 4.7. So i am not sure what you are confused about. > > > > Zzh> "The BIFT of each BFR are only populated with BPs that are adjacent to the BFR in the BIER-TE topology". > > Correct text from the introduction. Ok. > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I suppose in BFR4~BFR9 as well even though not drawn), I assumed it's for the "MP2P" routed adjacency to R10; though I then ruled that out - but I don't know what 0:6 represent now on BFR1, BFR2, and BFR3. > > Ah. Ok. I thought i could strip down the example to show only the > adjacencies relevant to the following discusion, but seemingly this > can introduce the confusion you have. > > So i completed the example with the BP assignment acoss all nodes, but > added text pointing to a new section further down to discuss the > re-use of BP for which thi picture is also an example. > > (check out the diff, new reuse text to long to copy inline). > > > The whole purpose of the ECMP BPs is of course to save bits, otherwise we'd give each link a separate BP, which would be 6 BP to reach to BFR4...BFR7 from BFR1. > > > > Zzh> The trouble I am having is that the same 0:6 is assigned to different things and it's present on all BFR1/BFR2/BFR3. It is perhaps an intentional smart design but I have not wrapped my mind around it. It's apparently different from the link bundle case, so better separate it out and elaborate it (including the DNR flag that might be needed here - If the packet arrives on BFR1 with 0:6, would the BP reset when it is sent to BFR2/3)? > > Yes, there was the bug of reusing BP 0:6 across sequential BFR along > the path, but now the example correctly reuses separate BP at > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on BFR2/BFR3) and so on. > > Thanks! > > > > 4.8.  Routed adjacencies > > > > > > If I understand it correctly, there is a BP assigned to L1/L2/L3 > > > respectively (p2p link), and then there are BPs assigned to MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 interface addresses and loopback addresses on BFR2/3. > > > > Ok that wasn't quite the read i expected. Let me clarify the text/picture: > > > >                    ............... > >          ...BFR1--...           ...--L1-- BFR2... > >                   ... .Routers. ...--L2--/ > >          ...BFR4--...           ...------ BFR3... > >                    ...............         | > >                                           LO > >                     Network Area 1 > > > > Assume the requirement in the above picture is to explicitly steer traffic flows that have arrived at BFR1 or BFR4 via a shortest path in the routing underlay "network area 1" to one of the following three next segments: (1) BFR2 via link L1, (2) BFR2 via link L2, (3) via BFR3. > > > > To achieve this, both BFR1 and BFR4 are set up with a forward_routed adjacency BitPosition towards an address of BFR2 on link L1, another forward_routed BitPosition towards an address of BFR2 on link L2 and a third forward_routed Bitposition towards a node address LO of BFR3. > > > > Does this clear ip the confusion ? > > > > Zzh> The picture is badly misaligned. I'll wait till 4.7 questions are cleared. > > Ok. > > > > If BFR2/3 are also BFERs, then they additionally will have BFER BPs. > > > On BFR1/4, the BIFT entries for the MP2P BPs for the L1/L2/L3/loopback interface addresses of BFR2/3 will use forward_routed(interface/loopback address). For a packet to be decapsulated on a BFER, there is a need for both the BFER BP and another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the former is for decapsulation and the latter is for getting it there). > > > > This is not discussed in this section, but you are right - unless > > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage the one shared "leaf-BFR" BP, so they do not need a per-BFER BP for local_decap(). > > > > Zzh> Right - shared leaf-BFR BP but still need that BP (the key is that we need a BP to get packet to a BFER and then a BP for decapsulation). > > You got it. > > > > If that???s the case, it???s worth point the above out. > > > > Hmm... The logic of BFER BPs is totally independent of the logic of forward_routed adjacency, so i would worry that repeating the explanation of BFER BPs would conflate the forward_routed explanation. > > > > Zzh> It's just that this is a place where all kinds of BPs are used so it's good to have a summary (could be a subsection 4.9). > > Yes, added such a summary. Pls. check. > > > > Actually, the reason that I thought this is MP2P is that 0:6 is present on R1, R2, and R3 (and more I assume) in Figure 12, but now I think it can???t be MP2P (so it is not correct to have 0:6 present on those routers ??? only the p2p tunnel head/tail should have the BP present in the BIFT). The reason is that if it were MP2P, any router getting a copy will send it to the endpoint of the routed adjacency, causing lots of duplicates. > > > > > > Am I getting this correct? > > > > I think you are still explaining from the misunderstsanding that the ECMP explanations where about routed adjacencies. > > > > I have now expanded the somewhat terse text in the BIFT table pictures, to make it clear that the ECMP is across multipe forward_connected adjacencies in the examples. For example, first BIFT picture: > > > >   BIFT entry in BFR1: > >  ------------------------------------------------------------------ > >   | Index |  Adjacencies                  | > >  ================================================================== > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | > >   |       |        forward_connected(L2, BFR2),                 | > >   |       |        forward_connected(L3, BFR2)}, seed)             | > >  ------------------------------------------------------------------ > > > > Of course, an ECMP adjacency can be across any type of adjacencies, but all the text/explanations used forward_connected, and now the pictures show that explicitly. > > > > Zzh> I can understand the multi-link case, but the multi-hop ECMP case (from BFR1 towards BFR10) is confusing me. It would help to give an example how it can be used, WITHOUT worrying about polarization. > > Please check -05 text that has the full set of BIFT listed now: > > There is  really nothing nothing unique in multi-hop ECMP for BIER-TE > that we do not also have in any other ECMP, except the conclusion that > we want to support fast HW hash mechanisms AND allow the controller to > set up non-polarized multi-hop ECMP AND be able to precalculate paths. > Hence the specification of ECMP adjacencies to have a controller > configurable seed. > > Btw: The picture is maybe unnecessarily large because i've used it for > 20 years to explain the same polarization issue for unicast vs > multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of > the PIM/mLDP joins), whereas for unicast/BIER only > BFR1...BFR7 are relevant. But being symmetric, the picture makes it > clear its the same problem. > > > >    To inhibit looping in the face of such physical misconfiguration, > > >    only forward_connected adjacencies are permitted to have DNR set, and > > >    the link layer destination address of the adjacency (e.g.  MAC > > >    address) protects against closing the loop.  Link layers without port > > >    unique link layer addresses should not be used with the DNR flag set. > > > > > > It???s not clear how link layer address helps? > > > > I have expanded this to > > "link layer port unique unicast destination address" > > > > Aka: MPLS or ethernet have unique link layer destination destination addresses (label or destination MAC). If you think about incorrectly plugged HDLC links (such as old T1/T3/... links), they only have 2 generic addresses, if i remember 1 or 3 in the HDLC frame. So when you misplug one of those p2p cables wrong, the packets would be incrrectly received by the wrong receiver node and then DNR could cause persistent loops only solved by TTL. > > > > Zzh> "Consider in the ring picture that link L4 from BFR3 is plugged into the L1 interface of BFRa" - still not sure how label/mac helps here. I suppose the ring topology is discovered/verified by the control plane and when the miscalling happens then the ring will not include the BFR1/BFR2 part and BFR3 will not have the DNR set? If ring discovery/varication is not done then perhaps we should point out that RPF based on link layer address is needed - the key is RPF (which needs unique link layer address)? > > Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF > is just a problem for receiver originated joins like in PIM/mLDP, but > not unicast/bier(-te)/RSVP-TE. > > Forward_connected is just like a unicast subnet adjacency to a direct > neighbor: Interface and L2 addresss of the destination. > > The controller (could be a human) "assumes" a particular physicial > topology, from telemetry/knowledge/whatever. It then calculates the > desired BIER-TE topology and pushes it down. This topology is meant to > be loop free of course wrt to the configured adjacencies. > In this BIER-TE topology, BFR3 will have a BP with the > forward_connected(L4, MAC-of-BFR2) adjacency. > > If the cable connecting to L4 is miswired, then BFR3 would still send > the packets to the MAC address of BFR2, but given how the cable > connects to some other node, these packets will be discarded by that > node. because they're just L2 unicast packets. > > I think this is equally true when we have normal BIER/MPLS enacp. > Those packets too are addressed to the unicast MAC address of the > neighbor. > > Now, if/when he controller recognizes that the physical topology has > changed, thats a completely different story and not addressed here. > Given how we assumed this was a cabling mistake, the controller would > probably only complain about the miswiring to operations but be happy > that the forwarding plane just makes packets fail instead of loop. If > this was a planned change process, then it will be similarily > convoluted as it would today be with rewiring cables in an > SR-MPLS/SRv6 topology and updating SIDs. > > > > Because the forwarding is different from BIER forwarding (because of [1] above), we might as well introduce an optimization here ??? for each BIFT, calculate the F-BM of the BIFT itself (the logical ???or??? of all the BPs presented in this BIFT) and then use (packet->bitstring & BIFT.F-BM) as the input to GetFirst/NextBitPosition(). That should skip many bits. > > > > Right. But i explicitly removed those optimizations (i had them in older draft versions) because the whole idea of this picture is solely the comparison with figure 4 of RFC8279. > > > > Zzh> I think it's worth point that optimization out; you can mark it optional if you want to emphasize the similarity to BIER forwarding, but since BIER forwarding does do the maskoff step, it is very efficient while BIER-TE forwarding does not it the maskoff step so this optimization is important. > > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM > rules [1] and [2] and added following paragraph: > > In BIER, the order of BPs impacts the result of forwarding because of [1]. > In BIER-TE, forwarding is not impacted by the order of BPs. It is > therefore possible to further optimize forwarding than in BIER. For > example parallelizing forwarding across multiple FPE cores or > distributed linecards does only need to examine an arbitrary subset of > BP and not evaluate the dependency between BPs. > > > >    The following pseudocode is comprehensive: > > > > > > The above sentence reads a bit strange (or lacks some segue). > > > > I hope not, but maybe best left to a native english speaker (RFC-editor). > > > > The first (RFC8279) pseudocode was simplified. The second one is comprehensive. If not comprehensive, whats a good opposite of simplified ? > > > > Zzh> Perhaps "The above simplified pseudocode is elaborated further as following"? > > Zzh> Jeffrey > > Done. > > Thanks a lot. > > > > > > > ________________________________________ > > > From: BIER [bier-bounces@ietf.org >] > > > on behalf of Toerless Eckert [tte@cs.fau.de >] > > > Sent: Tuesday, July 09, 2019 23:38 > > > To: Mike McBride > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > Thanks, Mike > > > > > > The authors also reviewed the document and concluded that it was > > > really hard to get into the document context because of too many > > > forward dependencies. We tried to fix this by adding two hopefully > > > good & basic examples into the Introduction section and using them > > > to also add a better definition of the term "BIER-TE Topology" in the Introduction. > > > Hopefully this makes readin the rest of te document smoother. > > > > > > Also improved text of Abstract and refined text compariing BIER-TE with SR. > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > **Atools.ietf.org *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > tool > > > s.ietf.org *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > jC81 > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > $ > > > > > **Atools.ietf.org *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > tool > > > s.ietf.org *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > jC81 > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > $> > > > > > > Cheers > > >     Toerless > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > How about three? I support. > > > > mike > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd >> wrote: > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > Please, read and respond. If you don't support, then please vote as much publicly right here. > > > > > > > > > > Thanks, > > > > > Greg > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) >> wrote: > > > > >> > > > > >> Support: > > > > >> > > > > >> I see great value in deterministic networks as well as IOT (with RPL). > > > > >> > > > > >> All the best, > > > > >> > > > > >> Pascal > > > > >> > > > > >> > -----Original Message----- > > > > >> > From: BIER > > > > >> > >> On > > > > >> > Behalf Of Toerless Eckert > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > >> > To: Greg Shepherd > > > > >> > >> > > > > >> > Cc: BIER WG >> > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > >> > > > > > >> > +1 > > > > >> > Obviously support as co-author. > > > > >> > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg Shepherd wrote: > > > > >> > > Please read and respond to this thread w/ or w/o support. > > > > >> > > > > > > >> > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > >> > > /doc > > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > >> > > > > > >> > > doc/ > > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > >> > > > > > > >> > > Vote ends 5 June 2019. > > > > >> > > > > > > >> > > Thanks, > > > > >> > > Shep > > > > >> > > (chairs) > > > > >> > > > > > >> > > _______________________________________________ > > > > >> > > BIER mailing list > > > > >> > > BIER@ietf.org > > > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > >> > > list > > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > >> > > > > > >> > > list > > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > >> > > > > > >> > _______________________________________________ > > > > >> > BIER mailing list > > > > >> > BIER@ietf.org > > > > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > >> > stin > > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > >> > l_qd > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > >> > > > > >> > stin > > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > >> > 4nrq > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > _______________________________________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > nfo/ > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > F0Kw > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > nfo/ > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > 8UCL > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > -- > > > --- > > > tte@cs.fau.de > > > > > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > bier > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > cJLD > > > FFNT2WVXWX$ > > > > > bier > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > Xc8Y > > > _6sKn2KoAT$> > > > > -- > > --- > > tte@cs.fau.de > > -- > --- > tte@cs.fau.de > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > 1_jWV3YUA6D$ -- --- tte@cs.fau.de _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier --------------B43183003256DEC17CFA1947 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

FYI - this may be of interest to some.  https://mailarchive.ietf.org/arch/browse/bier/


-------- Forwarded Message --------
Subject: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK
Date: Tue, 18 Feb 2020 12:45:54 -0800
From: Greg Shepherd <gjshep@gmail.com>
Reply-To: gjshep@gmail.com
To: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>
CC: Toerless Eckert <tte@cs.fau.de>, bier@ietf.org <bier@ietf.org>


Thanks Toerless and Jeffrey


One more week of WGLC. Please read the latest rev and respond to this thread w/wo support.

Chairs
(Shep)


On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org> wrote:
Hi Toerless,

Thanks!
I support moving this to the next stage.

Jeffrey

On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote:
> Thanks Jeff
>
> I have now pushed out -05 with the answers and hopefully resolution to
> your points in email below.  Biggest addition was a section about
> reuse of BPs (without DNR) which came out of the confusion i think the
> reuse in the ECMP example raised. I was afraid so far to explan that
> as it may not be easy to absorb and ultimately is stuff only
> controller developers need to understand, but hopefully useful.
> And then of course the summary of BP optimizatins you asked for
>
> Diff from last version i sent you:
>
> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https:
> **Araw.githubusercontent.com*toerless*bier-te-arch*master*draft-ietf-b
> ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org*id*draft-ietf-bier-te
> -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH
> OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$
>
> full -04 -> 05 diff:
>
> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:*
> *Atools.ietf.org*id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools.
> ietf.org*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk
> !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$
>
> Comments inline below.
>
> Cheers
>     toerless
>
> On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> > I Thought u-turn is the most simple comparison leaf vs. non-leaf BFR.
> >
> > Zzh> The text in the email is seriously misaligned. Looking at the picture in the diff link, while you gave a U-turn example, though even if BFER2 is not connected to BFR2  but only connected to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I suppose. That's why I said the first sentence of the above paragraph is enough to define Leaf BFER while the example itself is actually not needed.
>
> Argh... ok, had to fix two words, BFIR->BFER and left-hand -> right-hand:
>
> Consider how redundant disjoint traffic can reach BFER1/BFER2 in above
> picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right hand
> side, one traffic copy would be forwarded to BFER1 from BFR1, but the
> other one could only reach BFER1 via BFER2, which makes BFER2 a
> non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding
> traffic to BFER2
>
> > Zzh> Additionally, in left part of the picture you added, if some failure leads to BFR2 to be only reachable via BFER1, then BFER1 is no longer a leaf BFER.
>
> Added sentence:
>
> <t>Note that the BFER in the left hand picture are only guaranteed to
> be leaf-BFR by fitting routing configuration that prohibits transit
> traffic to pass through a PE, which is commonly applied in these
> topologies.</t>
>
> > I assume you don't reassign BPs when links go up and down.
>
> I didn't want to discuss that option in this document. Its obviously
> perfectly feasible, but be yet a big amount of text (especially the
> considerations how to do this make-before-break. Future doc.
>
> > > but subsequent polarization example confuses me. It seems that BP 0:6 is assigned to the routed adjacency BFR10 (which is actually talked about in Section 4.8).
> >
> > Section 4.7 does not mention "routed" at all, so there are no routed adjacencies at all used in 4.7. So i am not sure what you are confused about.
> >
> > Zzh> "The BIFT of each BFR are only populated with BPs that are adjacent to the BFR in the BIER-TE topology".
>
> Correct text from the introduction. Ok.
>
> > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I suppose in BFR4~BFR9 as well even though not drawn), I assumed it's for the "MP2P" routed adjacency to R10; though I then ruled that out - but I don't know what 0:6 represent now on BFR1, BFR2, and BFR3.
>
> Ah. Ok. I thought i could strip down the example to show only the
> adjacencies relevant to the following discusion, but seemingly this
> can introduce the confusion you have.
>
> So i completed the example with the BP assignment acoss all nodes, but
> added text pointing to a new section further down to discuss the
> re-use of BP for which thi picture is also an example.
>
> (check out the diff, new reuse text to long to copy inline).
>
> > The whole purpose of the ECMP BPs is of course to save bits, otherwise we'd give each link a separate BP, which would be 6 BP to reach to BFR4...BFR7 from BFR1.
> >
> > Zzh> The trouble I am having is that the same 0:6 is assigned to different things and it's present on all BFR1/BFR2/BFR3. It is perhaps an intentional smart design but I have not wrapped my mind around it. It's apparently different from the link bundle case, so better separate it out and elaborate it (including the DNR flag that might be needed here - If the packet arrives on BFR1 with 0:6, would the BP reset when it is sent to BFR2/3)?
>
> Yes, there was the bug of reusing BP 0:6 across sequential BFR along
> the path, but now the example correctly reuses separate BP at
> different stages of the paths (BP 0:6 on BFR1, BP 0:7 on BFR2/BFR3) and so on.
>
> Thanks!
>
> > > 4.8.  Routed adjacencies
> > >
> > > If I understand it correctly, there is a BP assigned to L1/L2/L3
> > > respectively (p2p link), and then there are BPs assigned to MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 interface addresses and loopback addresses on BFR2/3.
> >
> > Ok that wasn't quite the read i expected. Let me clarify the text/picture:
> >
> >                    ...............     
> >          ...BFR1--...           ...--L1-- BFR2...
> >                   ... .Routers. ...--L2--/ 
> >          ...BFR4--...           ...------ BFR3...
> >                    ...............         |
> >                                           LO
> >                     Network Area 1
> >
> > Assume the requirement in the above picture is to explicitly steer traffic flows that have arrived at BFR1 or BFR4 via a shortest path in the routing underlay "network area 1" to one of the following three next segments: (1) BFR2 via link L1, (2) BFR2 via link L2, (3) via BFR3.
> >
> > To achieve this, both BFR1 and BFR4 are set up with a forward_routed adjacency BitPosition towards an address of BFR2 on link L1, another forward_routed BitPosition towards an address of BFR2 on link L2 and a third forward_routed Bitposition towards a node address LO of BFR3.
> >
> > Does this clear ip the confusion ?
> >
> > Zzh> The picture is badly misaligned. I'll wait till 4.7 questions are cleared.
>
> Ok.
>
> > > If BFR2/3 are also BFERs, then they additionally will have BFER BPs.
> > > On BFR1/4, the BIFT entries for the MP2P BPs for the L1/L2/L3/loopback interface addresses of BFR2/3 will use forward_routed(interface/loopback address). For a packet to be decapsulated on a BFER, there is a need for both the BFER BP and another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the former is for decapsulation and the latter is for getting it there).
> >
> > This is not discussed in this section, but you are right - unless
> > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage the one shared "leaf-BFR" BP, so they do not need a per-BFER BP for local_decap().
> >
> > Zzh> Right - shared leaf-BFR BP but still need that BP (the key is that we need a BP to get packet to a BFER and then a BP for decapsulation).
>
> You got it.
>
> > > If that???s the case, it???s worth point the above out.
> >
> > Hmm... The logic of BFER BPs is totally independent of the logic of forward_routed adjacency, so i would worry that repeating the explanation of BFER BPs would conflate the forward_routed explanation.
> >
> > Zzh> It's just that this is a place where all kinds of BPs are used so it's good to have a summary (could be a subsection 4.9).
>
> Yes, added such a summary. Pls. check.
>
> > > Actually, the reason that I thought this is MP2P is that 0:6 is present on R1, R2, and R3 (and more I assume) in Figure 12, but now I think it can???t be MP2P (so it is not correct to have 0:6 present on those routers ??? only the p2p tunnel head/tail should have the BP present in the BIFT). The reason is that if it were MP2P, any router getting a copy will send it to the endpoint of the routed adjacency, causing lots of duplicates.
> > >
> > > Am I getting this correct?
> >
> > I think you are still explaining from the misunderstsanding that the ECMP explanations where about routed adjacencies.
> >
> > I have now expanded the somewhat terse text in the BIFT table pictures, to make it clear that the ECMP is across multipe forward_connected adjacencies in the examples. For example, first BIFT picture:
> >
> >   BIFT entry in BFR1:
> >   ------------------------------------------------------------------
> >   | Index |  Adjacencies                                           |
> >   ==================================================================
> >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                    |
> >   |       |        forward_connected(L2, BFR2),                    |
> >   |       |        forward_connected(L3, BFR2)}, seed)             |
> >   ------------------------------------------------------------------
> >
> > Of course, an ECMP adjacency can be across any type of adjacencies, but all the text/explanations used forward_connected, and now the pictures show that explicitly.
> >
> > Zzh> I can understand the multi-link case, but the multi-hop ECMP case (from BFR1 towards BFR10) is confusing me. It would help to give an example how it can be used, WITHOUT worrying about polarization.
>
> Please check -05 text that has the full set of BIFT listed now:
>
> There is  really nothing nothing unique in multi-hop ECMP for BIER-TE
> that we do not also have in any other ECMP, except the conclusion that
> we want to support fast HW hash mechanisms AND allow the controller to
> set up non-polarized multi-hop ECMP AND be able to precalculate paths.
> Hence the specification of ECMP adjacencies to have a controller
> configurable seed.
>
> Btw: The picture is maybe unnecessarily large because i've used it for
> 20 years to explain the same polarization issue for unicast vs
> multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of
> the PIM/mLDP joins), whereas for unicast/BIER only
> BFR1...BFR7 are relevant. But being symmetric, the picture makes it
> clear its the same problem.
>
> > >    To inhibit looping in the face of such physical misconfiguration,
> > >    only forward_connected adjacencies are permitted to have DNR set, and
> > >    the link layer destination address of the adjacency (e.g.  MAC
> > >    address) protects against closing the loop.  Link layers without port
> > >    unique link layer addresses should not be used with the DNR flag set.
> > >
> > > It???s not clear how link layer address helps?
> >
> > I have expanded this to
> > "link layer port unique unicast destination address"
> >
> > Aka: MPLS or ethernet have unique link layer destination destination addresses (label or destination MAC). If you think about incorrectly plugged HDLC links (such as old T1/T3/... links), they only have 2 generic addresses, if i remember 1 or 3 in the HDLC frame. So when you misplug one of those p2p cables wrong, the packets would be incrrectly received by the wrong receiver node and then DNR could cause persistent loops only solved by TTL.
> >
> > Zzh> "Consider in the ring picture that link L4 from BFR3 is plugged into the L1 interface of BFRa" - still not sure how label/mac helps here. I suppose the ring topology is discovered/verified by the control plane and when the miscalling happens then the ring will not include the BFR1/BFR2 part and BFR3 will not have the DNR set? If ring discovery/varication is not done then perhaps we should point out that RPF based on link layer address is needed - the key is RPF (which needs unique link layer address)?
>
> Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF
> is just a problem for receiver originated joins like in PIM/mLDP, but
> not unicast/bier(-te)/RSVP-TE.
>
> Forward_connected is just like a unicast subnet adjacency to a direct
> neighbor: Interface and L2 addresss of the destination.
>
> The controller (could be a human) "assumes" a particular physicial
> topology, from telemetry/knowledge/whatever. It then calculates the
> desired BIER-TE topology and pushes it down. This topology is meant to
> be loop free of course wrt to the configured adjacencies.
> In this BIER-TE topology, BFR3 will have a BP with the
> forward_connected(L4, MAC-of-BFR2) adjacency.
>
> If the cable connecting to L4 is miswired, then BFR3 would still send
> the packets to the MAC address of BFR2, but given how the cable
> connects to some other node, these packets will be discarded by that
> node. because they're just L2 unicast packets.
>
> I think this is equally true when we have normal BIER/MPLS enacp.
> Those packets too are addressed to the unicast MAC address of the
> neighbor.
>
> Now, if/when he controller recognizes that the physical topology has
> changed, thats a completely different story and not addressed here.
> Given how we assumed this was a cabling mistake, the controller would
> probably only complain about the miswiring to operations but be happy
> that the forwarding plane just makes packets fail instead of loop. If
> this was a planned change process, then it will be similarily
> convoluted as it would today be with rewiring cables in an
> SR-MPLS/SRv6 topology and updating SIDs.
>
> > > Because the forwarding is different from BIER forwarding (because of [1] above), we might as well introduce an optimization here ??? for each BIFT, calculate the F-BM of the BIFT itself (the logical ???or??? of all the BPs presented in this BIFT) and then use (packet->bitstring & BIFT.F-BM) as the input to GetFirst/NextBitPosition(). That should skip many bits.
> >
> > Right. But i explicitly removed those optimizations (i had them in older draft versions) because the whole idea of this picture is solely the comparison with figure 4 of RFC8279.
> >
> > Zzh> I think it's worth point that optimization out; you can mark it optional if you want to emphasize the similarity to BIER forwarding, but since BIER forwarding does do the maskoff step, it is very efficient while BIER-TE forwarding does not it the maskoff step so this optimization is important.
>
> Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM
> rules [1] and [2] and added following paragraph:
>
> <t>In BIER, the order of BPs impacts the result of forwarding because of [1].
> In BIER-TE, forwarding is not impacted by the order of BPs. It is
> therefore possible to further optimize forwarding than in BIER. For
> example parallelizing forwarding across multiple FPE cores or
> distributed linecards does only need to examine an arbitrary subset of
> BP and not evaluate the dependency between BPs.</t>
>
> > >    The following pseudocode is comprehensive:
> > >
> > > The above sentence reads a bit strange (or lacks some segue).
> >
> > I hope not, but maybe best left to a native english speaker (RFC-editor).
> >
> > The first (RFC8279) pseudocode was simplified. The second one is comprehensive. If not comprehensive, whats a good opposite of simplified ?
> >
> > Zzh> Perhaps "The above simplified pseudocode is elaborated further as following"?
> > Zzh> Jeffrey
>
> Done.
>
> Thanks a lot.
>
>
> >   
> > > ________________________________________
> > > From: BIER [bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>]
> > > on behalf of Toerless Eckert [tte@cs.fau.de<mailto:tte@cs.fau.de>]
> > > Sent: Tuesday, July 09, 2019 23:38
> > > To: Mike McBride
> > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert)
> > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch
> > >
> > > Thanks, Mike
> > >
> > > The authors also reviewed the document and concluded that it was
> > > really hard to get into the document context because of too many
> > > forward dependencies. We tried to fix this by adding two hopefully
> > > good & basic examples into the Introduction section and using them
> > > to also add a better definition of the term "BIER-TE Topology" in the Introduction.
> > > Hopefully this makes readin the rest of te document smoother.
> > >
> > > Also improved text of Abstract and refined text compariing BIER-TE with SR.
> > >
> > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https:
> > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
> > > tool
> > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R
> > > jC81
> > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh
> > > $
> > > <https://urldefense.com/v3/__http:/tools.ietf.org/*rfcdiff?url1=https:
> > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
> > > tool
> > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R
> > > jC81
> > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX
> > > $>
> > >
> > > Cheers
> > >     Toerless
> > >
> > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote:
> > > > How about three? I support.
> > > > mike
> > > >
> > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd <gjshep@gmail.com<mailto:gjshep@gmail.com>> wrote:
> > > > >
> > > > > We cannot take two 'yes' votes and WG consensus.
> > > > > Please, read and respond. If you don't support, then please vote as much publicly right here.
> > > > >
> > > > > Thanks,
> > > > > Greg
> > > > >
> > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:
> > > > >>
> > > > >> Support:
> > > > >>
> > > > >> I see great value in deterministic networks as well as IOT (with RPL).
> > > > >>
> > > > >> All the best,
> > > > >>
> > > > >> Pascal
> > > > >>
> > > > >> > -----Original Message-----
> > > > >> > From: BIER
> > > > >> > <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On
> > > > >> > Behalf Of Toerless Eckert
> > > > >> > Sent: mardi 4 juin 2019 02:03
> > > > >> > To: Greg Shepherd
> > > > >> > <gjshep@gmail.com<mailto:gjshep@gmail.com>>
> > > > >> > Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
> > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch
> > > > >> >
> > > > >> > +1
> > > > >> > Obviously support as co-author.
> > > > >> >
> > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg Shepherd wrote:
> > > > >> > > Please read and respond to this thread w/ or w/o support.
> > > > >> > >
> > > > >> > > https://urldefense.com/v3/__https://datatracker..ietf.org
> > > > >> > > /doc
> > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s
> > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$
> > > > >> > > <https://urldefense.com/v3/__https:/datatracker.ietf.org/
> > > > >> > > doc/
> > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx
> > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$>
> > > > >> > >
> > > > >> > > Vote ends 5 June 2019.
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > Shep
> > > > >> > > (chairs)
> > > > >> >
> > > > >> > > _______________________________________________
> > > > >> > > BIER mailing list
> > > > >> > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/
> > > > >> > > list
> > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE
> > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$
> > > > >> > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/
> > > > >> > > list
> > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b
> > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$>
> > > > >> >
> > > > >> > _______________________________________________
> > > > >> > BIER mailing list
> > > > >> > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/li
> > > > >> > stin
> > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4
> > > > >> > l_qd
> > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$
> > > > >> > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/li
> > > > >> > stin
> > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW
> > > > >> > 4nrq
> > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$>
> > > > >
> > > > > _______________________________________________
> > > > > BIER mailing list
> > > > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi
> > > > > nfo/
> > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX
> > > > > F0Kw
> > > > > ZD82cJLDFFNT2WVXWX$
> > > > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listi
> > > > > nfo/
> > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju
> > > > > 8UCL
> > > > > OgiuXc8Y_6sKn2KoAT$>
> > >
> > > --
> > > ---
> > > tte@cs.fau.de<mailto:tte@cs.fau.de>
> > >
> > > _______________________________________________
> > > BIER mailing list
> > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> > > bier
> > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82
> > > cJLD
> > > FFNT2WVXWX$
> > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/
> > > bier
> > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu
> > > Xc8Y
> > > _6sKn2KoAT$>
> >
> > --
> > ---
> > tte@cs.fau.de
>
> --
> ---
> tte@cs.fau.de
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
> __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4
> 1_jWV3YUA6D$

--
---
tte@cs.fau.de

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier
--------------B43183003256DEC17CFA1947-- From nobody Wed Feb 19 20:05:37 2020 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4091E12022E for ; Wed, 19 Feb 2020 20:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 eOBnXyhr4PRQ for ; Wed, 19 Feb 2020 20:05:26 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BDB612006E for ; Wed, 19 Feb 2020 20:05:26 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 20AF9548048; Thu, 20 Feb 2020 05:05:20 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 19CB0440040; Thu, 20 Feb 2020 05:05:20 +0100 (CET) Date: Thu, 20 Feb 2020 05:05:20 +0100 From: Toerless Eckert To: Lou Berger Cc: teas@ietf.org Message-ID: <20200220040520.GZ14549@faui48f.informatik.uni-erlangen.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Teas] Fwd: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 04:05:36 -0000 Thanks Lou For various non-technical issues [1], this document took unfortunately quite long to get to this stage. At IETF101 i presented about BIER-TE in TEAS: https://datatracker.ietf.org/meeting/101/materials/slides-101-teas-framework-for-traffic-engineering-with-bier-te-forwarding This was related to the framework draft targeted for TEAS how to manage the traffic engineering of BIER-TE. That draft is currently expired because of [1], and after a BIER-TE RFC is out, we'll revisit how to best continue with that work. Because of Lous feedback on the BIER mailing list and the non-existance of an up-to-date TE framework doc for BIER-TE, i also pushed an update -06 of the BIER-TE spec with a short summary of what the framework was expected to include. The big building block for a complete statelesss multicast TE solution that was missing from the framework document is btw the stateless (hop-by-hop) latency management (cyclic queuing), which we only posted later (draft-qiang-detnet-large-scale-detnet). Cheers Toerless [1] too long to explain here ;-) On Wed, Feb 19, 2020 at 06:41:12PM -0500, Lou Berger wrote: > FYI - this may be of interest to some. > https://mailarchive.ietf.org/arch/browse/bier/ > > > -------- Forwarded Message -------- > Subject: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK > Date: Tue, 18 Feb 2020 12:45:54 -0800 > From: Greg Shepherd > Reply-To: gjshep@gmail.com > To: Jeffrey (Zhaohui) Zhang > CC: Toerless Eckert , bier@ietf.org > > > > Thanks Toerless and Jeffrey > > https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ > > One more week of WGLC. Please read the latest rev and respond to this thread > w/wo support. > > Chairs > (Shep) > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang > > > wrote: > > Hi Toerless, > > Thanks! > I support moving this to the next stage. > > Jeffrey > > On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > > Thanks Jeff > > > > I have now pushed out -05 with the answers and hopefully > resolution to > > your points in email below.  Biggest addition was a section about > > reuse of BPs (without DNR) which came out of the confusion i > think the > > reuse in the ECMP example raised. I was afraid so far to explan that > > as it may not be easy to absorb and ultimately is stuff only > > controller developers need to understand, but hopefully useful. > > And then of course the summary of BP optimizatins you asked for > > > > Diff from last version i sent you: > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > **Araw.githubusercontent.com > *toerless*bier-te-arch*master*draft-ietf-b > > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org > *id*draft-ietf-bier-te > > > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > > > full -04 -> 05 diff: > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* > > *Atools.ietf.org > *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. > > ietf.org > *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ > > > > Comments inline below. > > > > Cheers > >     toerless > > > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang > wrote: > > > I Thought u-turn is the most simple comparison leaf vs. > non-leaf BFR. > > > > > > Zzh> The text in the email is seriously misaligned. Looking at > the picture in the diff link, while you gave a U-turn example, > though even if BFER2 is not connected to BFR2  but only connected to > BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I > suppose. That's why I said the first sentence of the above paragraph > is enough to define Leaf BFER while the example itself is actually > not needed. > > > > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> > right-hand: > > > > Consider how redundant disjoint traffic can reach BFER1/BFER2 in > above > > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right > hand > > side, one traffic copy would be forwarded to BFER1 from BFR1, but > the > > other one could only reach BFER1 via BFER2, which makes BFER2 a > > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding > > traffic to BFER2 > > > > > Zzh> Additionally, in left part of the picture you added, if > some failure leads to BFR2 to be only reachable via BFER1, then > BFER1 is no longer a leaf BFER. > > > > Added sentence: > > > > Note that the BFER in the left hand picture are only > guaranteed to > > be leaf-BFR by fitting routing configuration that prohibits transit > > traffic to pass through a PE, which is commonly applied in these > > topologies. > > > > > I assume you don't reassign BPs when links go up and down. > > > > I didn't want to discuss that option in this document. Its obviously > > perfectly feasible, but be yet a big amount of text (especially the > > considerations how to do this make-before-break. Future doc. > > > > > > but subsequent polarization example confuses me. It seems > that BP 0:6 is assigned to the routed adjacency BFR10 (which is > actually talked about in Section 4.8). > > > > > > Section 4.7 does not mention "routed" at all, so there are no > routed adjacencies at all used in 4.7. So i am not sure what you are > confused about. > > > > > > Zzh> "The BIFT of each BFR are only populated with BPs that are > adjacent to the BFR in the BIER-TE topology". > > > > Correct text from the introduction. Ok. > > > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I > suppose in BFR4~BFR9 as well even though not drawn), I assumed it's > for the "MP2P" routed adjacency to R10; though I then ruled that out > - but I don't know what 0:6 represent now on BFR1, BFR2, and BFR3. > > > > Ah. Ok. I thought i could strip down the example to show only the > > adjacencies relevant to the following discusion, but seemingly this > > can introduce the confusion you have. > > > > So i completed the example with the BP assignment acoss all > nodes, but > > added text pointing to a new section further down to discuss the > > re-use of BP for which thi picture is also an example. > > > > (check out the diff, new reuse text to long to copy inline). > > > > > The whole purpose of the ECMP BPs is of course to save bits, > otherwise we'd give each link a separate BP, which would be 6 BP to > reach to BFR4...BFR7 from BFR1. > > > > > > Zzh> The trouble I am having is that the same 0:6 is assigned > to different things and it's present on all BFR1/BFR2/BFR3. It is > perhaps an intentional smart design but I have not wrapped my mind > around it. It's apparently different from the link bundle case, so > better separate it out and elaborate it (including the DNR flag that > might be needed here - If the packet arrives on BFR1 with 0:6, would > the BP reset when it is sent to BFR2/3)? > > > > Yes, there was the bug of reusing BP 0:6 across sequential BFR along > > the path, but now the example correctly reuses separate BP at > > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on > BFR2/BFR3) and so on. > > > > Thanks! > > > > > > 4.8.  Routed adjacencies > > > > > > > > If I understand it correctly, there is a BP assigned to L1/L2/L3 > > > > respectively (p2p link), and then there are BPs assigned to > MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 > interface addresses and loopback addresses on BFR2/3. > > > > > > Ok that wasn't quite the read i expected. Let me clarify the > text/picture: > > > > > >                    ............... > > >          ...BFR1--...           ...--L1-- BFR2... > > >                   ... .Routers. ...--L2--/ > > >          ...BFR4--...           ...------ BFR3... > > >                    ...............         | > > >                                           LO > > >                     Network Area 1 > > > > > > Assume the requirement in the above picture is to explicitly > steer traffic flows that have arrived at BFR1 or BFR4 via a shortest > path in the routing underlay "network area 1" to one of the > following three next segments: (1) BFR2 via link L1, (2) BFR2 via > link L2, (3) via BFR3. > > > > > > To achieve this, both BFR1 and BFR4 are set up with a > forward_routed adjacency BitPosition towards an address of BFR2 on > link L1, another forward_routed BitPosition towards an address of > BFR2 on link L2 and a third forward_routed Bitposition towards a > node address LO of BFR3. > > > > > > Does this clear ip the confusion ? > > > > > > Zzh> The picture is badly misaligned. I'll wait till 4.7 > questions are cleared. > > > > Ok. > > > > > > If BFR2/3 are also BFERs, then they additionally will have > BFER BPs. > > > > On BFR1/4, the BIFT entries for the MP2P BPs for the > L1/L2/L3/loopback interface addresses of BFR2/3 will use > forward_routed(interface/loopback address). For a packet to be > decapsulated on a BFER, there is a need for both the BFER BP and > another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the > former is for decapsulation and the latter is for getting it there). > > > > > > This is not discussed in this section, but you are right - unless > > > BFR2 or BFR3 is a leaf BFR. In that case, it would just > leverage the one shared "leaf-BFR" BP, so they do not need a > per-BFER BP for local_decap(). > > > > > > Zzh> Right - shared leaf-BFR BP but still need that BP (the key > is that we need a BP to get packet to a BFER and then a BP for > decapsulation). > > > > You got it. > > > > > > If that???s the case, it???s worth point the above out. > > > > > > Hmm... The logic of BFER BPs is totally independent of the > logic of forward_routed adjacency, so i would worry that repeating > the explanation of BFER BPs would conflate the forward_routed > explanation. > > > > > > Zzh> It's just that this is a place where all kinds of BPs are > used so it's good to have a summary (could be a subsection 4.9). > > > > Yes, added such a summary. Pls. check. > > > > > > Actually, the reason that I thought this is MP2P is that 0:6 > is present on R1, R2, and R3 (and more I assume) in Figure 12, but > now I think it can???t be MP2P (so it is not correct to have 0:6 > present on those routers ??? only the p2p tunnel head/tail should > have the BP present in the BIFT). The reason is that if it were > MP2P, any router getting a copy will send it to the endpoint of the > routed adjacency, causing lots of duplicates. > > > > > > > > Am I getting this correct? > > > > > > I think you are still explaining from the misunderstsanding > that the ECMP explanations where about routed adjacencies. > > > > > > I have now expanded the somewhat terse text in the BIFT table > pictures, to make it clear that the ECMP is across multipe > forward_connected adjacencies in the examples. For example, first > BIFT picture: > > > > > >   BIFT entry in BFR1: > > >  ------------------------------------------------------------------ > > >   | Index |  Adjacencies                  | > > >  ================================================================== > > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | > > >   |       |        forward_connected(L2, BFR2),                 | > > >   |       |        forward_connected(L3, BFR2)}, seed)          >    | > > >  ------------------------------------------------------------------ > > > > > > Of course, an ECMP adjacency can be across any type of > adjacencies, but all the text/explanations used forward_connected, > and now the pictures show that explicitly. > > > > > > Zzh> I can understand the multi-link case, but the multi-hop > ECMP case (from BFR1 towards BFR10) is confusing me. It would help > to give an example how it can be used, WITHOUT worrying about > polarization. > > > > Please check -05 text that has the full set of BIFT listed now: > > > > There is  really nothing nothing unique in multi-hop ECMP for > BIER-TE > > that we do not also have in any other ECMP, except the conclusion > that > > we want to support fast HW hash mechanisms AND allow the > controller to > > set up non-polarized multi-hop ECMP AND be able to precalculate > paths. > > Hence the specification of ECMP adjacencies to have a controller > > configurable seed. > > > > Btw: The picture is maybe unnecessarily large because i've used > it for > > 20 years to explain the same polarization issue for unicast vs > > multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of > > the PIM/mLDP joins), whereas for unicast/BIER only > > BFR1...BFR7 are relevant. But being symmetric, the picture makes it > > clear its the same problem. > > > > > >    To inhibit looping in the face of such physical > misconfiguration, > > > >    only forward_connected adjacencies are permitted to have > DNR set, and > > > >    the link layer destination address of the adjacency (e.g.  MAC > > > >    address) protects against closing the loop.  Link layers > without port > > > >    unique link layer addresses should not be used with the > DNR flag set. > > > > > > > > It???s not clear how link layer address helps? > > > > > > I have expanded this to > > > "link layer port unique unicast destination address" > > > > > > Aka: MPLS or ethernet have unique link layer destination > destination addresses (label or destination MAC). If you think about > incorrectly plugged HDLC links (such as old T1/T3/... links), they > only have 2 generic addresses, if i remember 1 or 3 in the HDLC > frame. So when you misplug one of those p2p cables wrong, the > packets would be incrrectly received by the wrong receiver node and > then DNR could cause persistent loops only solved by TTL. > > > > > > Zzh> "Consider in the ring picture that link L4 from BFR3 is > plugged into the L1 interface of BFRa" - still not sure how > label/mac helps here. I suppose the ring topology is > discovered/verified by the control plane and when the miscalling > happens then the ring will not include the BFR1/BFR2 part and BFR3 > will not have the DNR set? If ring discovery/varication is not done > then perhaps we should point out that RPF based on link layer > address is needed - the key is RPF (which needs unique link layer > address)? > > > > Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. > RPF > > is just a problem for receiver originated joins like in PIM/mLDP, > but > > not unicast/bier(-te)/RSVP-TE. > > > > Forward_connected is just like a unicast subnet adjacency to a > direct > > neighbor: Interface and L2 addresss of the destination. > > > > The controller (could be a human) "assumes" a particular physicial > > topology, from telemetry/knowledge/whatever. It then calculates the > > desired BIER-TE topology and pushes it down. This topology is > meant to > > be loop free of course wrt to the configured adjacencies. > > In this BIER-TE topology, BFR3 will have a BP with the > > forward_connected(L4, MAC-of-BFR2) adjacency. > > > > If the cable connecting to L4 is miswired, then BFR3 would still > send > > the packets to the MAC address of BFR2, but given how the cable > > connects to some other node, these packets will be discarded by that > > node. because they're just L2 unicast packets. > > > > I think this is equally true when we have normal BIER/MPLS enacp. > > Those packets too are addressed to the unicast MAC address of the > > neighbor. > > > > Now, if/when he controller recognizes that the physical topology has > > changed, thats a completely different story and not addressed here. > > Given how we assumed this was a cabling mistake, the controller > would > > probably only complain about the miswiring to operations but be > happy > > that the forwarding plane just makes packets fail instead of > loop. If > > this was a planned change process, then it will be similarily > > convoluted as it would today be with rewiring cables in an > > SR-MPLS/SRv6 topology and updating SIDs. > > > > > > Because the forwarding is different from BIER forwarding > (because of [1] above), we might as well introduce an optimization > here ??? for each BIFT, calculate the F-BM of the BIFT itself (the > logical ???or??? of all the BPs presented in this BIFT) and then use > (packet->bitstring & BIFT.F-BM) as the input to > GetFirst/NextBitPosition(). That should skip many bits. > > > > > > Right. But i explicitly removed those optimizations (i had them > in older draft versions) because the whole idea of this picture is > solely the comparison with figure 4 of RFC8279. > > > > > > Zzh> I think it's worth point that optimization out; you can > mark it optional if you want to emphasize the similarity to BIER > forwarding, but since BIER forwarding does do the maskoff step, it > is very efficient while BIER-TE forwarding does not it the maskoff > step so this optimization is important. > > > > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM > > rules [1] and [2] and added following paragraph: > > > > In BIER, the order of BPs impacts the result of forwarding > because of [1]. > > In BIER-TE, forwarding is not impacted by the order of BPs. It is > > therefore possible to further optimize forwarding than in BIER. For > > example parallelizing forwarding across multiple FPE cores or > > distributed linecards does only need to examine an arbitrary > subset of > > BP and not evaluate the dependency between BPs. > > > > > >    The following pseudocode is comprehensive: > > > > > > > > The above sentence reads a bit strange (or lacks some segue). > > > > > > I hope not, but maybe best left to a native english speaker > (RFC-editor). > > > > > > The first (RFC8279) pseudocode was simplified. The second one > is comprehensive. If not comprehensive, whats a good opposite of > simplified ? > > > > > > Zzh> Perhaps "The above simplified pseudocode is elaborated > further as following"? > > > Zzh> Jeffrey > > > > Done. > > > > Thanks a lot. > > > > > > > > > > > ________________________________________ > > > > From: BIER [bier-bounces@ietf.org > >] > > > > on behalf of Toerless Eckert [tte@cs.fau.de > >] > > > > Sent: Tuesday, July 09, 2019 23:38 > > > > To: Mike McBride > > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > Thanks, Mike > > > > > > > > The authors also reviewed the document and concluded that it was > > > > really hard to get into the document context because of too many > > > > forward dependencies. We tried to fix this by adding two > hopefully > > > > good & basic examples into the Introduction section and using > them > > > > to also add a better definition of the term "BIER-TE > Topology" in the Introduction. > > > > Hopefully this makes readin the rest of te document smoother. > > > > > > > > Also improved text of Abstract and refined text compariing > BIER-TE with SR. > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > **Atools.ietf.org > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > tool > > > > s.ietf.org > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > jC81 > > > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > > $ > > > > > > > > **Atools.ietf.org > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > tool > > > > s.ietf.org > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > jC81 > > > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > > $> > > > > > > > > Cheers > > > >     Toerless > > > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > > How about three? I support. > > > > > mike > > > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > >> wrote: > > > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > > Please, read and respond. If you don't support, then > please vote as much publicly right here. > > > > > > > > > > > > Thanks, > > > > > > Greg > > > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) > >> wrote: > > > > > >> > > > > > >> Support: > > > > > >> > > > > > >> I see great value in deterministic networks as well as > IOT (with RPL). > > > > > >> > > > > > >> All the best, > > > > > >> > > > > > >> Pascal > > > > > >> > > > > > >> > -----Original Message----- > > > > > >> > From: BIER > > > > > >> > >> On > > > > > >> > Behalf Of Toerless Eckert > > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > > >> > To: Greg Shepherd > > > > > >> > >> > > > > > >> > Cc: BIER WG >> > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > >> > > > > > > >> > +1 > > > > > >> > Obviously support as co-author. > > > > > >> > > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg > Shepherd wrote: > > > > > >> > > Please read and respond to this thread w/ or w/o > support. > > > > > >> > > > > > > > >> > > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > > >> > > /doc > > > > > >> > > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > > >> > > > > > > > >> > > doc/ > > > > > >> > > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > > >> > > > > > > > >> > > Vote ends 5 June 2019. > > > > > >> > > > > > > > >> > > Thanks, > > > > > >> > > Shep > > > > > >> > > (chairs) > > > > > >> > > > > > > >> > > _______________________________________________ > > > > > >> > > BIER mailing list > > > > > >> > > BIER@ietf.org > > > > > > > >> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > > >> > > list > > > > > >> > > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > > >> > > > > > > > >> > > list > > > > > >> > > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > >> > > > > > > >> > _______________________________________________ > > > > > >> > BIER mailing list > > > > > >> > BIER@ietf.org > > > > > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > > >> > stin > > > > > >> > > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > > >> > l_qd > > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > > >> > > > > > > >> > stin > > > > > >> > > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > > >> > 4nrq > > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > _______________________________________________ > > > > > > BIER mailing list > > > > > > BIER@ietf.org > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > > nfo/ > > > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > > F0Kw > > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > > nfo/ > > > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > > 8UCL > > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > > > > > > _______________________________________________ > > > > BIER mailing list > > > > BIER@ietf.org > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > > bier > > > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > > cJLD > > > > FFNT2WVXWX$ > > > > > > > > bier > > > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > > Xc8Y > > > > _6sKn2KoAT$> > > > > > > -- > > > --- > > > tte@cs.fau.de > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > > > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > > 1_jWV3YUA6D$ > > -- > --- > tte@cs.fau.de > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas -- --- tte@cs.fau.de From nobody Fri Feb 28 01:56:14 2020 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531DE3A14D2; Fri, 28 Feb 2020 01:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 tjQDLozM2-pz; Fri, 28 Feb 2020 01:56:10 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 05EFD3A14D3; Fri, 28 Feb 2020 01:56:10 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E38A573B4804FF2E3D35; Fri, 28 Feb 2020 09:56:06 +0000 (GMT) Received: from lhreml735-chm.china.huawei.com (10.201.108.86) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 28 Feb 2020 09:56:06 +0000 Received: from lhreml735-chm.china.huawei.com (10.201.108.86) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 28 Feb 2020 09:56:06 +0000 Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Fri, 28 Feb 2020 09:56:05 +0000 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.89]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0439.000; Fri, 28 Feb 2020 17:55:59 +0800 From: Zhenghaomian To: "draft-ietf-teas-yang-path-computation@ietf.org" CC: "teas@ietf.org" Thread-Topic: Comments about draft-ietf-teas-yang-path-computation Thread-Index: AdXuF+hyFD0FlG+2Tqi+KCgsK/fEGA== Date: Fri, 28 Feb 2020 09:55:59 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.178.77] Content-Type: multipart/related; boundary="_004_E0C26CAA2504C84093A49B2CAC3261A43F7B4F37dggeml511mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Teas] Comments about draft-ietf-teas-yang-path-computation X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 09:56:13 -0000 --_004_E0C26CAA2504C84093A49B2CAC3261A43F7B4F37dggeml511mbxchi_ Content-Type: multipart/alternative; boundary="_000_E0C26CAA2504C84093A49B2CAC3261A43F7B4F37dggeml511mbxchi_" --_000_E0C26CAA2504C84093A49B2CAC3261A43F7B4F37dggeml511mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Authors, WG, We have been reviewing the document (-08), and would like to share with you= about the following comments: 1. The concept of path computation data model and the PCE should be o= rthogonal, i.e., we should avoid misleading that the path computation data = model must be achieved via PCEP, especially among controllers; please help = clarify if this understanding is correct; 2. Section 3.3 mentions the 'stateless' and 'stateful' path computati= on respectively, but the term is slightly confusing because it reminds peop= le to use stateful/stateless PCEP to do the path computation work, which is= actually just a sub-case in the path computation model. I think the motiva= tion to have 'stateful/stateless' here is 'to plan the network with or with= out actually occupying any resources', so probably some alternative termino= logies can be used. I don't have perfect term in my mind, but something lik= e 'compute-reserve' and 'compute-only' may be helpful; 3. Section 3.2 provides really detailed path computation policies, I = know we have hard experience to achieve here. The content is clear but seem= s an overkill. Shall we leave some path computation principles here, and mo= ve the details as an example to some appendix? Since there is also github about this work, the issues were listed as https= ://github.com/rvilalta/ietf-te-path-computation/issues/68 for your informat= ion as well. Thank you. Haomian Zheng PhD, Principle Standard Delegate for Transport & Access Software, Huawei Technologies Co., Ltd. Tel : +86 13066975206 Email : zhenghaomian@huawei.com [cid:image001.png@01D55296.0E369D90] This e-mail and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, b= ut not limited to, total or partial disclosure, reproduction, or disseminat= ion) by persons other than the intended recipient(s) is prohibited. If you = receive this e-mail in error, please notify the sender by phone or email im= mediately and delete it! --_000_E0C26CAA2504C84093A49B2CAC3261A43F7B4F37dggeml511mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Authors, WG,

 

We have been reviewing the docu= ment (-08), and would like to share with you about the following comments:

1= .   &= nbsp;   The concept of path com= putation data model and the PCE should be orthogonal, i.e., we should avoid= misleading that the path computation data model must be achieved via PCEP,= especially among controllers; please help clarify if this understanding is correct;

2= .   &= nbsp;   Section 3.3 mentions th= e ‘stateless’ and ‘stateful’ path computation respe= ctively, but the term is slightly confusing because it reminds people to us= e stateful/stateless PCEP to do the path computation work, which is actually just a sub-case in the path computation model. I think t= he motivation to have ‘stateful/stateless’ here is ‘to pl= an the network with or without actually occupying any resources’, so = probably some alternative terminologies can be used. I don’t have perfect term in my mind, but something like ‘compute-reserve= 217; and ‘compute-only’ may be helpful;

3= .   &= nbsp;   Section 3.2 provides re= ally detailed path computation policies, I know we have hard experience to = achieve here. The content is clear but seems an overkill. Shall we leave so= me path computation principles here, and move the details as an example to some appendix?

 

Since there is also github abou= t this work, the issues were listed as = https://github.com/rvilalta/ietf-te-path-computation/issues/68 for your= information as well. Thank you.

 

Haomian Zheng

PhD,

Principle Standard Delegate for Transport &am= p; Access Software,

Huawei Technologies Co., Ltd.<= /span>

Tel : +86 13066975206<= /o:p>

Email : zhenghaomian@huawei.com

3D"cid:image001.png@01D55296.0E=<= /o:p>

 

--_000_E0C26CAA2504C84093A49B2CAC3261A43F7B4F37dggeml511mbxchi_-- --_004_E0C26CAA2504C84093A49B2CAC3261A43F7B4F37dggeml511mbxchi_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=28158; creation-date="Fri, 28 Feb 2020 09:55:59 GMT"; modification-date="Fri, 28 Feb 2020 09:55:59 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAATgAAAD1CAYAAADEfum0AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAW JQAAFiUBSVIk8AAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAG1+SURBVHhe 7Z0HgFxF/cdn93p6oxk6qCBdBEGKQRBUEEIRAkQITTpEKRL5w7K0CAgcEClGIIGASA29KiBVaoBQ pYTeArn0a7v7/37ezmzevdvd27vcccfdTPK79/a9qb+Z+c7v95vyypPJpPHOc8BzwHOgN3KgvDcW ypfJc8BzwHMADniA8+3Ac8BzoNdywANcr61aXzDPAc8BD3C+DXgOeA70Wg54gOu1VesL5jngOeAB zrcBzwHPgV7LAQ9wvbZqfcE8BzwHPMD5NuA54DnQazngAa7XVq0vmOeA54AHON8GPAc8B3otBzzA 9dqq9QXzHPAc8ADn24DngOdAr+WAB7heW7W+YJ4DngMe4Hwb8BzwHOi1HPAA12ur1hfMc8BzwAOc bwOeA54DvZYDHuB6bdX6gnkOeA54gPNtwHPAc6DXcsADXK+tWl8wzwHPAQ9wvg14DngO9FoOeIDr tVXrC+Y54DngAc63Ac8Bz4FeywEPcL22an3BPAc8BzzA+TbgOeA50Gs54AGu11atL5jngOeABzjf BjwHPAd6LQc8wPXaqvUF8xzwHOjxADf2gakrLTtwwMim8uZZl2yy12elVtmpQ75aZUFT8wrzFzS/ Mzk28stSw3l/ngOeA72HAz0O4NZOJMq2XHOlrSr7VWyWHhgfZKorRvXrV7baQlP+zCHP3nHw5E12 bhOsDk+/vdrissFT+g3u/z1T3fDK8ZXznqosK587v7754WFHnj8jmUxmek8V+pJ4DngOFOJAjwG4 MYlE5dB+y21ftuzIIzIms3H/ytiypqLMpCrLTHMmY8oryn5tKmI7qCDTilXnqWuvHZ/36ceja2qq tk5n4mbAwAHLm/Kyn6cFaTVlZR8tvvrkJ0x60aRzP+r3uG8WngOeA72bAz0C4MYmJi43JD7i9Ip4 bP+KilhVQ3mZWWAEc/wTMGWa02ZE/7LYgLL4nmM/fuzmaSO3qi9ULXNee2iZmuX67W3KKszCxrSJ qYRxEzOxsrip7le1Yiwe3yvV3LTj8as0XvDZZ19eMK1h5NzeXcW+dJ4DfZcD3Q5wYxPnfX+o6Xdh TSz2y8VlxiyIZUwMiqtSYgImkfDJNAjpysriP6xZ3LSx3jxRqMqah8Y3Ka+o+H5TRoHKVbzyCpMu K1N8cbOwmSjTprq8YkBNTdmpK6yw7JqH1H11wuS64Z/03SbgS+450Hs50K0ANzaRGDjUDD93gIn9 sk6A1iwKgK1M4AQFIKf/ul+QSptlKspHmsrYFsUArqay6pflVZWDFjQJJAVusYoKxaViAnJElk6b xamUoombmgH99omlM/VjzFOH31C3eWPvrWZfMs+BvsmBbgO4nySmVg8wwxLVJrZznXjfDJA5cJO0 ZeL2ge4DYJIk1ySVVZLZZmNnPjZo2rpbzYtW2dFVXy1bHq9cN6MwMr8JGAG2coFcpa4COqRBAVws 1WQaG4Vnjc2mqrpy3Kpm4xmnHpuYdLqffOibvcCXutdyoNsAbnUzZ9O4iR/VAGgF2mhWFQ0c14Aw wIkCsIuZ+uaMSVfGtxm6QvPKejuzVa3UNG8aj1dt3iDgipVXCeAktcmeZ8orA2nOAJyS3hSpiZen BHLNmseIx1Pp1EnNVxx3v/nMvNVra9oXzHOgD3KgWwDuVC0F+cIMO7qfiVXNFdg4XMsBW7gici8l fOl5PB4fkE6Xr5QX4Ex8WGV5ecVCK/FlgTFrf4thj4uXCy8lucUFehIXAdXFjU2mX1Xld+Y3NR2s OE/sg23AF9lzoNdyoFsA7jVTPXiEiW0EYLEgLYdh/CiyQi0laa46ZsqbYrHt5fPecK2cuulTlfPe XlPLQdICMUlqSH5BApqJRS0VmYxkRb0P3tmUU9yiGmfS25xY9fGwcxtGft1ra9sXzHOgj3GgWwBu sOm/q+SnkfVh6S0Mbrl7QR+zoRb0MgKmKkljjZnMBtF6+vS/Kw8eMCyzBWDGmrc4gBaQVFLZ3BDc UHMzABy/Q+8bm1NGCuwPmmvKtzIN5vY+1gZ8cT0Hei0HOhXgtk1MHLalqZ/T1k4BgcnGg4ypbiUq AWSgE6AUSGGIYEhkSGA8Z12cACwd63/0x48NuGTkVguW1MzitEmVxwPgwnSHrS0uiU1LQwKA5DkA x5V3gFxKL0WywZnqsni/xlR6ubZqesxT11XObx5Yc/dWO/v1c20xy7/3HOhmDnQawI1N1G6o9WwX fW1qbrjEmMuKlUsyWROm/hYO8JK+qGVqWdUS3dGCWvCb96JGhdSi3RXNwNgP9PQZF0e1aV5DgDUg 3QyiscREYIbqyRxsEDfTqtlZVAA0o2UnplliXQByAlGT0oWwxd3QmoEnLG9SWx/w1C1HXL357u+0 5d+/9xzwHOg+DnQKwB2SmDi0zPRPDjVlW882qe8J7J6Ylhz/cpFitba05cCsJbBhLstKb1mVs1mA VF5WtXzD4vTaZtASgNPi3t2q45nhDQ0NwdKQDJMICG9B2OykQs4FAIcU16xdEiLALpYyZc14LuwO nXnXtpXl5vhBsfiQxkX1F+kggAOnbb//F91XfT5lzwHPgWIcWGqA2zSR0CKM4X/Uklrtgk+ZGhNb XuLTWXskJu5/c3JCIYM985stXaBGirQUJFgUh4jngI2JAlFMlNa2rYE1sXhTc3xYOAJJYMtVaFnJ YifBxVg1x0oTJD/UVVReGyKwwwFwIvwDeEpcW7haZculcfjbD6zZv7JsYllzZsicBY2mfya2o1aY HKT3E30T8xzwHOiZHFhqgFvPDP2dVpyNl9wk+3xgMTODTWynjOl3jk4GOeb1ZHJxtOjgWCsH+KAh AmxIVE1sbdBDp6py5XeFgE7AJKBrAUaZJgXSZAF+AqkveBuS3gA455hpBdwAviatmdPvxlSTwqeD FSZRN3bmHYNilWUX1sTjm8yubwpAVtKeqUmZ8UfectVbI15+/9a27I49s/p9rjwHejcHlgrgtI/0 e2Wm8o+CiarFdkaURbuLdK/9A/tvaYY+8rox10VZ2Gya7p9vKsZq+e1QFvrmnEAjIyEqJmKDfSwA OD0TEMXS2p3ADKl+pwVkAqWWEwJNSrlJqqmAMJgpJV4t9M1ozVuwiDgnwWWnaAO1NJhhTclclzEN DfVfVGRS7+UDuKH9qg+qTqd2nLu4McgXkx+LGjXz2phZNtOQOf+dFVZ4XkeczOrdTcWXznPg28eB DgOcFuvGPjZDT9Zi3ZXnhZZ7ICchsg3UBql+Jn7aIYlJb0xOHvV8mDUNpuxRbZ76XLOpQzkWJCc0 oZJqD2mGTfG6Gp0Gok2jksp0LcuqlRltWE1J6lKSax398R0DLxm58/xNhzxVbj6uHJKxAJe112UB DmDLOIALhDoLqLnJBu1LLY+b+qbU6198PucFM7JlJR7y3j2/qjJlEwRssQakPUAxAN+0mbc4ZQY1 ZlbR4/EKBXnnOeA50IM40GGAe98M+oUksD0AKI41CvaLWsfdQj0bamJr1pvURE067KFJh9ze0Waz jPTB2XOCGc4wMwI1FZATQDUImCoEJABcOTOiktosUCFFyddKWrw2WCHmb/Bm8/dTlbF1mrQtC+Et JjDMlAmI2KqlY5ICfTU3yYDaSqbt8pNAQoyZdFPTZ9FjmA75+I4VqtIVEytNZpmv6xsDUAvAFlW4 UaVukFYrqmrIjD3gjNrrrz5lfG5WtwfVsc+K50Cf5UCHAE6HU1bEzLADJL31Q3qLYlQweyninfxs K2g4Vj/PcP5uSO7bcFCidpqgYnPJWIHZLecAkEbFIHAzqKq6jwngjAArIzUV9TQt9VC7rgYtaC6v IVy8uXlNSWGrNAmEAmkNlJPfQJJzy0PC+8GCXQ4AG6p0xiysx37XfK9mSHJuzFfXVVQsHnZKv3hs /XmaVADYMgAvBLghXep+ka6Dm8zw+nR8P0m1L2jDfttrTfpsc/MF9xz4ZjnQIYCTZvljwce22M+C mUoLaFH7PPY4qaLxGpP54wGJ2ueuTo7Pba8SPMxoEFRJxqpsAXBIVwIQU2knGgASwamRGmkkxeEy ktTKM/EBpqGsKgA4k+lXlk5XNmOHs7sVYuw3Zf0bmQokuFDughlbbGnadI/9rbH5C5Nq/E+Y9QO/ Gr5vTdwc1qRJhSBepLZg1hWAsyQ1mrmJRlFN2ox+1wy4WHH4DfvfbBv2qXkOFORAhwBOp4BsJrVt WFsHqAEpi0SDTby/lmGccnRi4vOXJCcE68YG6DSQJhO7r7+Wl0juaplB7G9S/YxO/DCIeMHZcCz1 yO7cYmmHtqSWl6czvOXYI+myUjxjsTgSXCwtuQz/qKgO3HIAp7j5b5ePVAssU6nmuwe+9cGnZvNs Ng5/4571q+Pm+PJUJjZXAMey5AwAx/LkBt3X61qPGp2lJqnVytayFaZiEw9wvrd5DvQcDrQb4LQd a2iFqd4hLuTREtnsPvWsXJWzqDm4cpIdx4/rUMvN55uapNTb8Tckkw2XyCYnNfVfjaZsJ877YCVa ziF5ASACNg67zAQAh5qalcIyZcEkg6Qwqw1KgsrElBukN4gJCU4QYRY1DHBBEjYdvvOgXw3NzQ1a 7Hvv6ZvvG+D10TPvqCmvKE8MNJl1vlio3bKopE5qU54y2hHmwI08xiTNEXCIJlWU2520LvCfz3g1 tee0cJ+TPs2BdgNctanpL1PVCAdeTkUtxMVA4BJJWjP9Tdm+mnq4Qz8DVVWyz93aP3BstTGrL4xG wGSDpCNktOzx5SJ7zSDZYUdjQTCOwyvlMcP2LCQ41FNNLgRSXHBkEv8tFNsMpwWiAyriLPd45qOG hY+45MtMfB+tIt6pTmppRra+7IQCEpuT3HSv2dMAgJHg0HRzWYtJMA0S8s5zwHOgB3Cg3QAncAtk J/LOjevc7nfUDsdzN6sqKWdgpYmfOzYx6e1pyaP+96pZ8P7GpupOLRQ+1gFmC55gi4szLWpjzXnS DdY3u7Mq3SAwcqt7rQTHGXCBegs6BpKdjdkuE9HOC0xqadnP7r55zZ2/4u3hM29ZL56KJ5VkZf1i qcHY3LC3AW4CNbMIcLNSHJIcIGwdDNGb+Oq6+qnUHtCyfRY8B8SBdgMcXKMzCzICBoYnGNyUQz6Q wy+zqsNMbN1mkz5QPyegyq2TOO+6MlO9t44uX5YFwi3CAmD12UUo2TMsOe6IGyQnXd30RGNz9lM1 ehS8DlRTARulc8tD7Mb7LCrr2CVNWmhHwtuNC+tvJ29H31FbE1txpRP0iZqR8xZL3kQtDWxuChCA m1VNkdwAN1TXkCPfJP+ub1aeA54DPYYD7QY4LeIFXlACc6Kc0yALAVsYCLHHSfg68tBE7ZNXJMff KSnuxU1N9e0CuEPYDdHKgSMY9UGP7J/slZ0IjVYbRMri4HN77HmmTJ5QVVMBKloYbnkpT8czC5qb blth75ffMq/vbhYtM3KfwY2psQsFbGkdZR4AmFVDA+nN2t6CCQbSi2TV66U9pk37jHgO5DjQboAb asxcmd4/0sTAhlkpLvt3SX/PPgtLdmF+s18VVbXBxCfoFJKnJyeTX66VqL1eNrLfaM3cEBYItwJK 8AuACfTA7CxosL6tjNjkGlinJqmNCQkArVzG/+C4JAs7oe89EHSg7HMLGxo/rK9PX3v668n04U9d t0a8KXYCYmBTvcBNAJZBPcbGBsgFkwt25hTgywNu2Bml1M7WGpGWop1vbJ4DngPdxoF2A5x2JMzf M1F7r6QwzX6ySHcJyOXMXJEZ1ShgIcUNMvHN60y/YxTFKW+YOU9trMmHAaZsP7Z55ZHjssCGLcwu 0DUpZh8s3+YIgGr0nrVydlkJEw5MNAR+Asp6LtM1Lkql0tdP3mrvV9ly9uWWa/5pYCz2/TriB9SC dW6KjysTHQHIIdW1rifyKhuiEeg3LjLxm+v8DGq3NWafsOdAlAPtBjgiEGw8qg79fj9jVmGd2xJg y38fTRSc4DCjKhM/+JBE7T2S4p5aJ1F7leY9d9ZxS0OwxeV1PMYmxiJdRCZ2O+BQG9n1oN8ZlSjY nhXsfkCZDmVQtzoRxCxMZz6Za9JTCfrp+quM7rcwvediNvG7BbwW4HJSHL9brEZekjvKrllgtqa9 njLNL/gm5jngOdBzONAhgLshOf7V3yQumDbQlJ0sUMqpqC3V0qxkh1tyly04T5HihuvsuLSJnzQ2 MXUv7XJ49ODERdOlpo4rKMU5vrEQGBucM3zNzy4n4cMKUIZN9laSyy0xCSQ3Vo1o3Vpj81XT9jz4 jUOmXj6iqqLi+OpM84A5SG5uHywqKr9JJ1hqVwBw9UY7NQKnxcpXSLr9pOdUrc+J54DnQIcADrZV mYZL55rq7Yea+CbMjmI5ywcDhSYe8Es47WTYLmPmjtXPvyuGi+aZ9M7V+vxf3gmHcH0Fp4FkEa55 vuCFDflSUbMSHOqqXmCTs+vg8Kd9pWZ+ShOdDQuDI9X7N8R/V9mY/vG8YKeCBTNmToPFvUVxLUiX 1AXIHA91c9wsvsE3J88Bz4GexYGiAMem+vuUX9mVWlmfpiUnfLJH4rxjF5mKfwwysVXmyR8KY2jO Miipk94c+DnA48oOAKm5/bSx6iipqvdPTo6fcXji4smSiv6YPaWkRCd9Oca55vEssAU7GQIVlVnU bKawvaWZWTWZv04+avwnh9RO2kA7vQ5vTGXKmtjphQrKoZrBdwRLcyo34PbqItPwp6uTE+bkC7Vj orbfxmZOvTbh+8mH0tjqfXkOdBoHigLcW6Zyl3VMfKfyxMQrH01OeCya6s3JE57aM3HeUdILL9F+ 01Xnh9TVrN+WxyhFw4M9hNGEwwY6J5cJhxO0Ru6v9Sa+q7Z2fS98zlybJQ5mVq2tjIid5KZ71sb1 F7jpuN4XUg3zriGusnmpP1bHYivOCQ7TbDP2Fh7QfgdKflto0m9rHvfYq5Mn/C8aA5MXH5rhu+pM vLGfmuGkOb19qXjfngOeA0vLgYIAt3wiUV1uKnYfZsyYRdpjuV3iz9c3mabLH02e8lo40RuTJ9wl SW62/F4qkNsIUAIvsrvggbisROROfova4xCcWOyhE4APkBR3i6S4p49MXHyxwtfqvLlyNuIXUnML Fj4Au2y6/GUSQE4LPdLnTE5OmK09sDtWmPjOiwrNHBSImLiwuQl8JbmlHtNEyXFXJsc/G/Wucujj O8MPlfq6+3ATr/rKpLDNTV/ayvLhPQc8B9rHgYIAJ32rehWTXmZBYFuLDx9g4kfHTdWuOybOm1xv mqf8KznhA5eUJLmnRyfO22cZUzl5mIlviVTGUUrBTikLMlmQa+14xqypDsccrrVxJ0jy2WOOGXpT k/aECiB+0taJJW0VFzuZZma1jCM9/SXz9e1HJ2r7Lzbx4/Ss/5zSleDAJ/Y2SBMkN9SZRb+Xmv5Z OP0xidqNBGj6EE1sH8U/lBlmAJpt/23l07/3HPAc6HwOFAS4oTKpcQqaVEeBlY4JV9oDjVlReziT laZ8l90S51z6mUnf9qT9ctb05AlvSJI7UAeAn6V1Yb+WRFbtJgqiwJZvVhUwUNw7fmqGjpYUd9sh iYsv1Dlym0r6Km9xrLnlgeKIsauiLZZoEgNb35dzTGOttoY1rJe4+FBJYNtgM2yPw94mt+Brk7lW 0tsEgdtcF14S20o6Qmo/SYW/k9S5sg74NHOtJGvlz9INe+3JlPfrOeA5UJQDRW1wjQK3coGb7GLB urX5umeP+xBT9kMturhsBWP2HJM477J3zYJ7BB6NkuT+95NE7UFrm5j2lprT9HWtFdiZYI+pDKSg 7LznkhlXh1BIOvJfpbN6j9UnBx/9xNTcs7KJXSMb1oGk7cxkbhKDuc7sUR82wjxg5yTIxSY9ZXWz 4NkDEud9t9JUHUkeOOqpTXSUPxgEuCmxNxea1Ok3mmVuqkvuG0y68D3YctN/Z/HiGIH6D8lj+IRj yuuRzfdAz4Hu40BRgMtuP8oEAKetWcE/1r19rd/9TbxCgLR9synbYjUz+J7vJGonvWnmPP5kMjn/ SWP+pi9uvVFlKk/SHtNf0smR5rgCAuF9m2FpDj/yv9VA03/3m5PHTNYpwBcICneUWrgcam8YkLQs VycsNdm9Whx+RNSogktsb9klHOlXlPJFhP3MVBzI5EU0rij7HRDrwzkAe1rS5T9l1DtHe2dfwu+Y xHVVA81XsuP1P1LL7raW5FlOnPDL5dEBmytz91WxT9lzoO9yoJgNLjY0+HRL0MkDexrgxtYsAEor MwLwE9D1F/1G77Zd1wy9cYNE7SVaCPzatOQJ/9HHZmaoyx+rRI6QFLQ8aqiTxqLLSagC0ErHMcW1 dORwhb1Xi39f1YTAuZWm7HzW8IY/dqAFwotqTEUAcDoX5PN6E5sn9XA4vwEVJE0Bs05yaz59cvK4 j99JTNqwxqT3dZ9eLVTl2UmJmLXbZd6Velv7TzP7MrcFS6C7ufIzXmntpDT6IaGyaDlcnjxSWynC Yt9thb7kngNdxIFiEhzffF8AqKGPZdU9wE3QEkhywRnhwQQBqqxAbphsdIcpzPZjEudfOd/0n6yV /V8q2BkCqwckXp0iu9wvZXyPAwpZlXPJpnxXPnv67/p6z+LfP2sB7dWLTc1OOixzGyd5ZScuMgtk gwsATt9Z/aDcVH6owgQA5xbgzjfmxsVm3l36AHV8iBk2TmfRrYRtLJ/jKczAZifwTs036Rs1UXKm QDaYNZZ6u3qNqTxCJxn/VsC2LHbBOhtXGL2isUvSpKwFNnp1Ua36aD0HPAcCDhQEuJM0uXm1MQ8I LHYSnJQDckw1lOkfoJdVWLOgR+/VmjABXYwlFKtXm7Kzqk3Dr/ZJ1F72tplz87Rk8r87JhJ7fscM P1BhjpLq9333geglC0iyNcJzxaclumUHHJ6YdONlyQnvCiCTSpMJB82AZtVAgcanmggRhhnztFnw wU/NsLcFwhvym2UcAqf39VGbPyvt+kMS520sW+KezMiS13ziFOooz/X+WYHXpFfM19dzXp2OaB/2 PdN/n7jATXa2tZEAAcnoRAnphsHNLSkRYC8SYD7t25vngOfAN8+BggCXTCYzjYnES1IX5wg4lkG1 RGorsxJcFtzclEEWplBZmZ1EnZRKuoVAaLN1zbDRaybOv+L6ZPIhPZ6kD0E/0Gyaj9ZG+72GmJiW oSwRb5yah4QnwPmeZivH6fWpz8u29zMz/BLZuk5UPoJEBSCz9F2H4KTz15PJ1NaJi+cRnrR1rZdo dwEqrpadlH1tRvxO4LTCV4HM2dLhH0BUvB8psimSt67Q2raPEpL6PklcvFul6S+pLbYtNkiky+CL rHlAMgxuSKdAIKeMCPQ/VnlaLZL+5qvap+g50Pc40NZe1Fck9fxHdrHdkX5YMgLIOSACabQ8wtrG 3EatrBRWJ7/q4GUCyD0k9W2zX+LC6wQvf9cSkFf0+mhJZTdJpT1Bse3YX5jUEABkTjoL7hX/WB1v fp2ksDc3Tky8UJMP22piYxO+qSWg+TRcXSwb4bfeA0QPLDSD/8bvL83QH+mkuL2i58wBbNn1cRxz lL6lwTReMDl5wnOEEQhvcagZcaTyvrPAvT8g3Oq04SzItnDZWdPsU7fwTZLkI5ptDr4k5p3ngOfA N8uBogD3mWZEV9ZXoiSF0NErsgCEJJclYGbJ7lO3LSurvOEPOxVgJ7vWcNExmmT49f6abR1k5lx2 STL5H6mtzy1vho5ZrHdSPzfgu8uIZKiRzKhqO9RqUjP3188/ad3ZF/slLj5b9q+p+rLLIAFriw8s S3rM1ChXOgbp/TkmPXFacv96tkt9bEYcJUlxsDbxB7kF2GQvZAFuRmr145pEuehx8/VtkgLTWgS8 rJTwI1TWQwV+ywOKTKZEJ0TyWfHC4ObUU4X/Wulcc1VyPJq1d54DngPfMAfakuDM8sbc/qWJXdfP ZMYhyYAq2e1T2QUf2akGHLKc/X6CtVAhxaDSES47QxpbTdB3fqMZuq3sc1dKbb1Vj6/Surd7Bpua 32oS4hCpi98lRtRBO7mxzwGJSVddnTzq7WuSx0w/PFE7dZCpOFqpg1U5x7Yufiww6Us1uRHYvD40 Q7fQYuEdSZs8It0BPgLNZ/RsSrX5eurlyeQiTUKUaWHxAVLADxOAbgrAIoHms9flk9pIy0luzjbH R21UhinKy+PfcJ365DwHPAcsB9oEOBbwjkgkzhdY7SApbAXAKmuPywJb+HsMQBzOSTxZ4MuunUOt BLRAJQHNrwQ82+r8t+slIV0k6Yz1Zedp7dwdWko8RnEfKD8rAzBay7aKZjTH6PZMYqs3TRd+LpuY IKXFZxAkwVXPNs0PN5jFV+FPJ6FUlmvmVLa8oajX2mWAjfA15f1vzWbhTdqTGpzdJqlti2Yz/Pcq 3+4A8pIZ3paTEW0BWxbksiSJEVvkixmz6CLf0jwHPAe6jwNtAhxZm51MzhyYSBwhwJkse9kI1EhA w6mr2VNDsrTEBJ+9C//OTkQY81XWAF+liYgDFMvW2ur01zlm8TUCujf1Wh+Hrr19GWP2kd+xy5j4 CgLBQ+Rniux3H+nkjvcEhOMElC3OAJGqeeUXpnHWzdpMT7o1ZsBG2gUxRpIduwveq5CqON/UX6vw 7/Be8X1HgHyErGUHCgRXQIVFLS625MNVk1PMXWldOXmuPbXw5i1NRxyq8uT263ZfFfuUPQf6LgdK AjjY814yOX01zSwKMC7X5MAySDpsqA9/PjDb0bNQ5+S4JapbVpLLvgmM+4EkKHBZA7V1mOn/630S 511wvU4n0ULhGfI2Q8b+G78w6QNkn9tbEhHHKZ1IGlpE3OoEj6uTxzzgqlFfly8vN8OP0Mkf87/W zG29SV1zmV3Phh8tHh4ne53exzZBfWV21amW+VfJLZlQCKuizq/bnaFPIqKKv63jng5Uflrlse82 M19yz4Hu4UDJAGdB7laBnL5Uas6WPW0DpDFAzi2ecNJadroBOMtu8XISDtfs+rmsD4CBNWUCmtgg Y7bpZyo23j9x0ZWa0Zx0Q/KEdycnj2JW87kDEhdLdU0NYdJAB0cWwqAcB1fPfi76odkmNVlLRXI2 MNnyNio3qcO1U2F/2fsq3Yb4bL6WuJbr2Vom5365K3oyi4Mpk0D/SUmBx01LHuPXvXVPe/apeg60 4EC7AM6C3D1DEolXJa2cyPILGeWHZwEr+30tHXMUABfgVh6smltyPhzvsdy5XRFumgKQnC0SUAyS Cvz7uKnYVstILrjLzLmOLVKShu5vT73dILuh/F/rwuhU3ZrldYyRJLrjtCNiVZZ8hJeNtLavFcZQ AC343EMA4dl7qeyfyr43dZFZfKFUZL8kpD2V5f16DnQhB9oNcORFoPN+nT7evEoicXOjiY/WkePb aT71O9rTMFizrTHtZAgOhpTdK/tpBAtqkppy4LBkLV0WKMJr62R3W1+gN2VPM+xXixK1Z2omkrVz HXKytWkmNZ7QZMXPyQvgRt6wzbWU2qI2w9Y7E/ARnGxuMk0CtnkCyXckvz4YN023XZM84fkOZdAH 8hzwHOgyDnQI4Fxu3k8mH9b9wysmEt+XBPMdRbZhk4lt3GxSg7RToUxAIptdmQW57Eb9rOQTQEta 95oKze6QEFBkBT85ZmoVVt9hjmuVivmhqMMAp6XJmxGt9o3eqmUnwWdqOHakxRRsiL1u5sLKcMFP 3WeUdzLIb32FNf68VtX9Tyr6+zcnx/uJhC5rnj5iz4Gl48BSAZxL+iPtNNA99DBryl62a9S0cDfQ SrWSP72niO1f7cmuJguqfmyGFsKikqLqZ9KXDTVzLlTaLWZdSwpsPbFZX7ex3+iPbIB+43x7mOf9 eg50Iwc6BeDC+WdfqH6nZKerYHP8d4IPZ5X3u9OU969OTOxfbsornGroEtf3HFBT9TgVfNlUtrsK 3QyqNMPjc8xC9rB+3FEeafnJsrPM8J9mEhcv1vFJCzXJoE9ElzVJmssLtkhp5aZpUbOpWCgJbXG1 qV6oTf2LoFImODqaTx/Oc8BzoPM50GGA02zq2tJAj1SWKu0C13KBAx/q09dJMbXF+uvckcFaDjJY 9q6BVSYzQKrowHKTrnRqatZYD+kc3+z8KqojM6rB7GyTSV00x9Q8uDTFblZ2FP9OOoV4D5RhfUCH 6KQeZx2/QjOjUosz+jZXhYDQzFdeFqRMw7zZZshcnfs0f6/EBfVST9NSqPmKaoqvqVJeqedzK0zZ RV5dXZqa8mE9BzqfAx0GOG2urJP6t+kIrSVj4W90+QRZZf40u4AipX/cZzdzceASIMekA3qjOzFY C3M58FILc1OvCYB0mu+8a+/Ozoh22LHcRDOyB2mP6rPaPnWMdhmM1Llycbd9awnAuSOQYnxCerDy Ntjpxu7UlCWnBWdX/zF3rH2x5iOTvlXSqpbceec54DnQkzjQYYDTRvxPNblw4FfG3KMJgZWiu8mX 6H/ZE4AD3VNwxtXNrAJwSG78HizSaSULhWa3fm0Wn/6f5ClvdxajNAvLKU7n6vsRj2qz2KkCtR0k VZaxdazlmrcsLGfBa8muBvd7ycLe7Bl4SJof6cPP803j0dOTE5gb8c5zwHOgB3GgwwBHGTS5MFOn jZwmaexSgVyV/UBCq+IhpbFB362JAxwANyCEI4t00i47AF6RzeuMj8yCu2TH65LTNyTN/VcHWI4d aSr3rTDlx2lj/6pszyJvgJeT5qzKnSsH+XbPsktFMkG+tRPja23cP02fUAz2tXrnOeA50LM4sFQA R1G0MFcLXDMjtTvgNL6nUAiZsouAAQd2N2SYebAHQpbJzpWZMtekal9JnhLsE+1KJzCao/gnjU5M eqq/aTxOKvRuWiNXBdCRP7caLgxy2QXK7pj1bN71ex67Fu5NnnBzV+bXx+054DnQcQ4sNcAxa6pl FGfJeL+40mROEuDpA85ZMIuenuukJBYA64w5fXc1/aA23Z8/I3nKUk0kdKT405NHPa+Z3v23M4Pu kE1QuycMR6IHG+6DbwJGpDYADvWaj9nIz+c6lfj4+5MTpnUkbR/Gc8Bz4JvhwFIDHNnksEhd/iKb 3Is61eM0RbolkwXuGwgAGwmxg0Dgl5JK+JzUu8uxt32WPAX7WLc47chokvh1w476Dqs2lu2rSY5x AuV1BNICsewnE3HkHVCWpJpR/u/XSXFnSRLM7XHtlsz7RD0HPAfa5ECnAJxLRTa5f1XpOw7afrC3 5LdtJAltLFBbjvd8XV5w8ZzOhbtnjsncLnDpMXs2705O4Pjzv8g+d6PW6Y2RpLat8rlJlUn3Z72c JiM+0TKXZzkK/StTc/PryfFz2+Ss9+A54DnQ7RzoVICjNA3J5Oz3jblE6t8VWkKxvlS/VXkuoHhf R4PMGJ48LasB9kAnqYxtV+f+RF8DqzENm2kyZIT22jY3mYb/vWiaZ7pvo/bArPsseQ54DuThQKcD nEtDYNBYJ4lNv4MPueCCj5Z+C9yTyfF8jvAbtwt+C1jjs+g58K3iQJcB3LeKCz6zngOeA72SAx7g emW1+kJ5DngOwAEPcL4deA54DvRaDniA67VV6wvmOeA54AHOtwHPAc+BXsuBogCX0JluKjl7yjld aL4OjWy1E0t+iAM/XBfJT27Tud6x3pcDN4Lvy+hdi6/Rw1Xrh7W1bHzAT97TQ+SPPAwjLvnRHv+W Tu/1sS/DZoRmvWc7VisnP+SFnVaa5G2dznXXXVf11ltv4Ydya8VLco4tn8tfoQM7yTtlXKgwwYGY CkcY0iLMAj2vz5cn/8xzwHOg6zhQFODKq6s3STU0nJfJZACW80V/j2alWn4aGhr+LD8s6L1OdEbI z36653N/i0QHilodPV5eXn54c3Ozvo8aAOQfRPfmK248Hj88nU5z/lyjwOISAUg0Lyfr3WjhJGBy jt7fFI7njDPO+G4sFrtI+Vxdcd1XW1v7f+PHj29xAsi77757tPwcKD+x8nj8CoWvVf5+mkqlztEz e9p53sqoULgv5OdwvQ1OQVG4PzQ3p/aJ6UyBsrKyS/Tosq6rRh+z54DnQD4OFAU4AYoOsjX6pkFw 4tHK+SKwfn6sd2zTXCPihzA/sM+QsFo5AQNh1tVVx13G9L3n1m7ixIkrCzwAv9V4q/sjBFA3C6Dq nG+B1gLl5ftZgSn2K/1pAXB6t6bCbafnFfKx8vz586/UfQ5wkSSV/jbyo4M8Bcjx+IvErXB8F2Lj 4s3HfTKnjFOfApeJxb4rmXQt7pW3VYqH9289BzwHuoIDRQFOqNYsfQvpC7Wt0GlIqJ34AeCi6qX7 nT1IJL8Lq255dzk0NjbuJOAJwC0Aj0xmnbkLF/5Ctze4Z+l05ZRYrOEoK0luKIltzVNOyZ4pN3Nm oiwWq9gpFstU6L0+b5Oukj65hV7lAE4S10YCsy15L4nr2eaBA1+ycefyJAD8RGDFB50pc/gsAanP 8bkVFWWzQ0UMl6sQ77qiTn2cngOeA5YD7ZlkyGt/Uofv8MdcSqkFSVbY1fbFrwCGtFICocpMU9Ne idra25Pjx1u7YP1nsXjZfzKp1G/0fj2B1UbyGwDcnXeaYel080aAl3Vx3e+GmuvsgvL/QxG2RACU eOui+VNZn1hllVX2ExiSj+D4OKnX8Tlz3hWllHSTt7OVUqnej+fAN8SB9gBc3s6rDo701mUgJ1BB etsUcNL9ZKU1XDaxPXT9uZkzH9X4EXgFUIlu1y0AVya/2wjAbsXo39gY31JYtKEFSb3OAE5rCqjW 1XVGIvFUucBzN/t+tsLmtpdF6qF5//339yD2DTVOn4znwNJyoBSAC8QeAcDuZ5111giBA6pooJ7p GSrod/WMGcNOd7KzDdJnaMZK+gKAZldUVFze2JheXYLczqQZj2fGCcQedZ8jlAT2jPy9jh1N96OU IWyIs5HOdMXGtjheXn5bqqlpV4lpq+k5NrkZ5eUPfTeVSq9jC/CUQPu/+Qoj/z9Wen/VO1RUZnXh xT1K/7ZOL7yP0HPAc2CpOVAywAnlftLU1PSTpU6xHRHMX7x4w3Q6tT1BBFr31tfXYzN7S0DFBMCP 9SnmbSSFbQBI4UdA879EMvmkPDNRMBK72tSpUx+TRLaLwAkJ8N8VZWVXppubt1V8NULpTU499dRY 8owzdlL5RpBMLFb2xGmnnRK1JQYzF8zA6npEniJ4gGtHvXqvngPfFAdKAbhsXjKZBerldVZycQZ2 VFPWujF7WOwDzdlPGeRx1q6Wt7zpxsYxAJGwpa6ysuKWk08+mTgWaQJhqqQs1NaVdd1JUtVLTopT Jh5QpsbI3yCB2jaffPLJF7p+j1la+X9s5ZVXfuLtt995JJNJ7aXfm0kqXEtTpWvpZZylHsLBuwox HwlQBZmtwjsbHKD30TdVWT4dzwHPgfZxoBSAc8B1taKeImIRrHMpSUUAzdmi3BKJ0PusbU5iUXlZ WSs1dubMmah5SE6Bk8SVA8kzEom1FHjbbPBYk+jnZ5999jb62aQ0V9Bva0uL7Sr0JW/Bx6EFZk/q 3QeoqfK3tQCQZSpVevZlZWXlc/vuu2+DAPIJmeH2ElgN1PPf6/3PCCv/Tw0a1MyZcFEXALrePyr/ f1KcAC3PyD+HZXrnOeA50AM5UArAuWzPkpT0QrQMWqNWpYW+rXYoWEAAcJD+yvR3Zz17NBz+zjvv HCJ1ERXT2fNyOxDS8fhvFPi7vJMquozSOFJCmHWBNBbc69kGstPtrtuL7cvPBUIPWjvc5roGoKnr y1Jxg8kDLU5+YMHChR/o4UrNqdRBWjaC9Iafe8aPT3IWXCH3tZaeBOvjvPMc8Bzo+RxoD8ChirZy AjAks0Lq6RsCjgYmJrSGYk8B5BPyfxfbpKRWDpHEdrzWfATGfUlUz0tCep77xMSJq0k+Q80E0uYI xVjuUS5IcxCnE8Vj+kxCZh3FrU0H8V9rQuIaFv4q7ibR4/J6mN7xGYggeq1te1DgFBw1vmDBAtnx yl7S101XFri5OGcpnifbqLL28Kvn177PoedAL+dAl3ZYgdk9AriHRDsKbFYUL6eIHhS4sSB2Dal6 TgVNy88/JkyY8Dn8Lm9u3r45k1mTe4HOTVItT7Mg6sAIFbFGkx6TtWTkZ0pni4ULF7Jw927CaNHv 49JqX5SdjWUkSIdfKa0nXF1irxP9U0LgjjZeXj0vAJxZoL6DSQals5nyfq3uST8K6lrMW35RMlkw jl7elHzxPAd6HgeKb9XK7g91tjMnDUVLEfbDsomcE4gsFCCcJGlpWcHOJgI5tmsF682cE/g0C8Su GjRo4FSeyf8ISVu/1W2l3s0RuF0l4Mtr51L8V8vPz5iIENgdZJeMaC/qhE9PP/3059IpzbQqIr1/ ZujQoS3Ua7vW7XOB1goWBFlDl89hcwyAlUkNXcbm84SKq+Urd+idA0kWKDvXgi89rxn4HHkO9E4O FN+qlU7P076lFwQCbNX6LB8L9G6eVtW+mM5khkjcmhX1IxCaKeAZE4+X7y9b2mjBRA4oBTJMBkwd NGjQdKmXLBhmomE9XQbL/2sCjf/KbtbK7ufSEPg91NSUuklxrCd8GZlKNTNhEWygV9jrY/H45kIm TvSQbS0bv3PbbbfdO//+978nS7LbCwlPkmDebzAoP1+rjK9iSizilJRZVF5uvnR+FOc78bKy1yXm ETLfxEXvbFG+VJ4DPYgDRQFOnf8ZGeQ1S2nK62tqwvssc0WQn2flByN/pcCoLl/ZBHLv6rlMa4nL da2qr9eO+OrqWKqmpi66JUrxvaj4dpG/pvr6Gh3RNL7gV7gk2X0m8DxY/ocpTvlrzgGM4nlKz3+t eCpq8uR98803b77vvvvOlZ8pCqvtXqlc2HAZtA/2EfnZAcwU5d2upufBSSMq/5L0GxtrFY7ZXZ7n 5UsPagc+K54DvZIDRQFOwMQm8Q+Lldz6CZZotOUmTEi2uaRC8QEGJQOC/PPh6FYfj7br4j5pI+8L 9f69Nvyw17Wk8oXjUfpMaASTGt55DngOdA8HunSSoXuK5FP1HPAc8BzIcsADnG8JngOeA72WAx7g em3V+oJ5DngOeIDzbcBzwHOg13LAA1yvrVpfMM8BzwEPcL4NeA54DvRaDniA67VV6wvmOeA54AHO twHPAc+BXssBD3C9tmp9wTwHPAc8wPk24DngOdBrOeABrtdWrS+Y54DngAc43wY8BzwHei0HPMD1 2qr1BfMc8BzwAOfbgOeA50Cv5YAHuF5btb5gngOeAx7gfBvwHPAc6LUc8ADXa6vWF8xzwHPAA5xv A54DngO9lgMe4Hpt1fqCeQ54DniA823Ac8BzoNdywANcr61aXzDPAc8BD3C+DXgOeA70Wg54gOu1 VesL5jngOeABzrcBzwHPgV7LAQ9wvbZqfcE8BzwHPMD5NuA54DnQazngAa7XVq0vmOeA54AHON8G PAc8B3otBzzA9dqq9QXzHPAcKAngEolEmVgFNSWTyUyYbXpHHKno846y1sZnFF9zR+NYmnBKP67w lKlFWe3zmPKVWpr4e0pYlSdm6zStMqWj+WpPvbr2oXgaO6t8irOCuBRnk4vT5jlos+Hn7U3T5pc4 WtSlfZ7Jx4/2puH99wwOlARwyupvRMeIDhG9GmpwO+j+KNHJopc7qUiXAjBqbEeoodV3UpztiWYn eT5UdIroBQIqLyN0OVv0juic9kTW1X6Vt7WVxo6i28Qv8kd+qdcTbX5vLDD4rKH3fxXdJ7ownE+F H2qfParr1cXKYIHoYvn52raDpS6y4lxfkVwmmiKaHIpwWd2TVkp+DlO55tnyAob99HtuNHH5669n vJ8HcOn3IN3Txpp0f5KefW7jWMGW+Q09/3O07Vmerik/y4gqI+k02N9VkeeA83zRm4pv0VIzxkfQ bg6UCnArKubNRQMjKYyzz10FF8yAGggdCuCgcSAxEGa26FkRQFlNIxXtJUK6oBHX2Qg/1HWKa9A8 07tddNlaFJYoaVD8pkETRzH3iV5OVpw0QOIbRpqi5UQ/EfHbOfI+WlQSuCmuLeX3QBuYchIvjR8p uC1Hvikr4EK+9tBlOxvIdSDixN/tInh4mmgL+R2rcAt1v5XoDNFU0U2iFlK3jet7um4vuidPhsg/ 9fC/tjJr83aQru9bEKAOqEckYcrwnGisaLjIlR/pnMFruvL7fDgNxQGIXSFaRfSJfo/U9VMrVdFG fiyi/AFg6P0oXY4Qvav7CXnA/GC920x0pAgQJo5f2/Bn6RoAnBxte08ReT4vnCd7P1hXwPXnovDA G25vSLDUC8+4ktbbol1FM/PE6R91MQdKBbgFygeNMjcK2VEWkEGiW0e/v2sr1VUw/t9Wg3OdhAZC x6OT0hBoqEgc74o2EiE10CkID20oWixiNKdBXxfhBY32WJsnGhRhB1g/hCNMIUABAJHOiHO+8k7Y P4reEH0porwAhXNIdeQP0AVsCA9oufjpOC+E1KYh+r2eff8DXSkzIP2ZzWco6ha3Tm28M/QUoP2d COD4rw1P2Snjf5XmPcoTwHuSCMC/VzRB9LoISSSnfsof8a8mAkQAJdxsPXd5/Z8FSMpL56yz9Uw5 KTP1/5ZTRfXuZ/oNGM0SfSRCmgfcqFd4yHOkKqTfOfY5aZIHAA9wyQGc4mPw+7N9v7ON4xZdAfKJ IuqUeqHd7iL/SK6AFZLcvQUk1XX1jjpzbR0+Ug74l1N/7T1x8zyfGQLeIb2hqbjBi7LQ9v5m4xyv a3hg5TllbWuwJR7vuoADBQFOjYdGvboI0ECCoZI20nMkHjrrYaIaEQ2VDgZI4OhQdAaeXyL6k30+ Q9dt7Xs6F6D2F9GTIkCScADBFBsX8X8lAsT2ES2vtBudxKXfk0Q0fMCSBkmHvEiEGsGoDbBGVQab lQCY6IAAE45OSd54RqOnLKSHOgMwjxbBq9NdBLoSByDuwPJXNixeAJmHRfAMFWuMiM7/UCh8vlsH 7mEJASlsNxHPMBWQ7nQR5bteeVxeV0CAsIv0e5yuAA8q9hz9HiKe1dnECAsQIqlQLtyVhBNRp/vI PwCPZIcDbJw0Qvwz8CP6wL5fWVckk0OVxocKe4NN+1f6/RZ+9OyXulC3Z4out+GoH+oqbF9DRTxa tLvoBBEgiVTFoHOW4gHEbhWR1x+JqH/ycb7on6LF8lOldKPaBHyjXh3QUx5HYeAJP7fZbHHhPXHQ /slT2AHigOObIjfA8x5Qh0f5JOh8afhnncyBYhIcwIaozujnpBUaKGB0jYhOh6TxfyI6OQBD5dLp HbjlVForSdABUX1qRdh2UJ/oYNiRACo64Kq2jNN0pXF+RzRChCp1jcKfhnFY9LF+Q4Gzoz95oKE9 p/dIFKU60qXDjxcxgiPhYJ96UYSKsZIIEEdi/UKEWo26TRlQ3QHCnKRE/siHlZgYBGaJnu6gHQYQ ID7qijTgMfd0ePJF58bOVCcCmDYUUR4GhnGiu5QPbE0OuCkbZX1MxACC1LSOjYt6xFywqugJEQMA 70kflZbOGrY/vafftIEfKQ0k8g1EDA4/02/uAU3yQr4XufLrXT57FOCN5Ikj73+w6cI/ygzYukEU 4AAMH1ecnym+VXQP+BH+USLQM0B8UxFSLVLwmXpGeZDEKT+D2gQ9Iy4c0hntB15cqOev6Xp5SCrH T50I9R3p3znAi3rgijru8sj7VUWYQrzrJg4UAzhGQqQHGjqNiQZxrohOgT0D6ehEUaCmhW0pahw0 FoAm1+nxo+c0Nkbea0WM+hk9A+SIm04EqI63cSL5AFJIDEhXhKFTtogzxDcnbXVktKQTAcz3i+jA vxA9IAI4jhFdKgLItxH9W3SVaFcRQE9+GATy5QugB5zpUHSaqOrjJAh4DbDe7GxvoXIFkplNA0mN dDYRPSWqEwGyABNlQDKikyJpUk/co6qGpReiBqQPFyFlET9SNhIz0u+popdEe4s+FTmAos6PD+WL 2y1E1Cl5p6xr2XRRcWlbj9u44G247PlUQCRe1ND3bZ6cHwY+2hpqIfHTVj4Un24O5QUzAAMNQOYc dXKI/UGbgDdOGqVM3KNJuPYCH3gOWMILzAF/F4XVWPIBYNE2nTmFsmEDhAcM1rQfNxBhWqAOvOsm DhQEODUgpKfb1CmpdEZDVKE7ADI9YyRnZogZJwBqbV131G8aJ45OjfSWAxu9x1iMREiF03i21TNU h7tFNFwaBSBFQyFN1AAkBMR/AOA8xc99IUcDJQ462sGKG+N7WNogL3QaOu3tzo5kI6MzkC6q0WYi pJEL7RUpAFsKnYjRH+ltiIgGTj7hIXHnAzgk0+9aP+vpChBF1SI6CMACX94VBRJIyLmOh8SGVMFv 8sSsIerkJc6vyvxD3dPJa/XOSSaR6IKf5LXBSScK5wBoYz0H/C5F5bQBecfglC+ei0mLvNir69iU E6CEV6iolI1JECfNbGUjy7U/pfeKrTOkIcI7flJn8Jq6QWJfQ7SD/GIzBbwpL8BL3KiIzpFhpO4z RD8VjbHhace3i2jfABw8J/7VREiBz4t+L4K3UXWXcr6nvGJaWZJQIvFz/WCWljYTfj5KP6gr77qJ A8UkOJclbCIAEI3uCjWsP6gig5Fc9z/RZRcRAID47xyNMzpKMzLSuLBhnC2iYWKrYtQ7U0TjweGH Tow6TOcCpF6x11ASBW+RlpA4nUqGRwAIMAL8ZoruEyEZOEeneh21V2UiHzR40p0ielHPX9Lz820Y JA2kAeJHSnKqYz6AW1XvUQmRBFC58BsFODoRHQaJCt7kc0iSTCggacF31KhqXYmLfFI+JDiAhLwv o3fE5dLDdhmuj7CdiCgJTxoMNmeJ9lX43ygMg5dzbgInnD/yvroIQBgtOk0EQNDRrxAhSTKgIBEC Aqi/OHg1S1QXjkz3SOvwAsmd/JIvyrCc6Crl5zDan+4vEtEGeU95AeWj9J4BIHC6J1145YDqJT2b p9+f6TF1R95n6lkAunqOxkGaDKLUebQ+3YC2sfzSZnEunvUJq+e1ulIH9BX8I1XiSulnLuv+2okc KMp4VRiNHtsIYICEg6Rxo54fbRs/6tsHIjrGtXqOzQLwACSgsLpII99ZROcChFC3Phf9S4SqRF7o rJfZxnGsrk5io7MWk0hgCY0TqfFVEeoU/h2YkA+kL1QLJ+kRxjkA2tlOiMdJVUhJj6pcjO4AOWvN MGaP1j3lQWJFbSkkwbk4P1a4QuBF50KSxdFR8zn4v7L8oToTJ9Iw5UQSOi4UAAmODoZKjcQH6MFD 7FczrD/KBy+OU3xIROSdeCkzUt0CwE33dGRmTCknLlyXLknURlR3eEA+/g6QKhxtAgmKgZH2gAZA XnAOXEkvap9icAOARoucnW6I7qmfkXbwIbwzlQBC8AbpCVDM5xzY0B7hCW2aOOBjeBIKvvGcdkhe AbywQ+KjzW4gYtDiPQPNuiLygcZAm8Vmiy2O9DBnwOO22m6BrPvHS8uBggBnpYNfKQGMqqhNiNpI WjTWwXq/ja50BFQH7EF/FR2u5w/ZygVswlLDd/SbCYaL1Rhn2BETlYLRGXWDvNDokKZoaIAno6wb Oe/R/dVFCryC3tF47wOUov6UHu9p0Iy6LUZn+f9K7ynT9215UbEniTBgo7IioaA+/02/V9T1e6Lr bGd2Nqp8diXiIb1nyI/COsBz2WPVPMAB4ANyTi0MZ5/3dCbUaKeOwqPpIni3kfVM3Eio8JFyOKm1 TvfUhXPkk4FktIhOiyMcgFJl6516vk00Sb/3VR4BrHxtBVABwJCS6Oj/kH/AgbLAL2x0PxIBQg4g SfMxxXlVKE/ulvomHUCEARUHb6hXwAl+AnaLFR5+wNPAPqcrGgFtq+BAEkmPNkCczhEuH4gH7228 SKSkCXihvaCJMCidLHqH9G1k/9SVMiLhe9eNHCgmwdGosFEgXTGKbyvCpnKDiNGO0WymCKmN2VHs HXRA7Dg0lLD9iyLSyTC6oiYg4tNw6fx0ODoAIzrx4gA4ntPgARCc64z2Z6vL/npCwwvbYcKeACY6 ARJNi4as/GAnQspB3UIVIz+U+VoRozIS4Z9Uzv/JL40ZYEG9zjkLVLnf8gdv17P5/61+IwEiTYQd K+vpaHRW+IxEGHXwgrp4UYRahoPPQ0S3ixhciIPf14sAh8NEL9j0nHTh4iUPmBPGiZA2iB+Vfj9R 3JbjEeULlRz71UmiI1zg8FV+kdzvll9U5wmih0VILNQZ0jlxu/qD54AwExArKswNtJtIvPB9iGis KLD9ydEmkOxoK87MwC4EpEMA9FDRJjbtabq2BXDkCR4Q57GKx0nNSMW0UdJwkn8kewG4MbCPE6GN PC3CZPM4HvVujC4TRdTDf/T7OvJVRLpsFb9/0LkcKAZwNCxG42tEgAudjOUZLP5EumEEQyxn1KZR MGLTcLCR0Pm5d42UXL8swoi7mwhVl8aNbY1Rjs5B42aERjoiX0kREgIjdKDWKJ0KpU9Db+H0HAkE kECSAITzOeIh3ny2MsA2kNBElJnGO14EWDBqo0ZfqHRW0ZXO/oToMZtIoVEfsIWHGLHhVT5eOymL zgbAIflEHUAPf1Fzn+Sl8oGkF0g2rvPo2aq2DHjZ2oJPnugCXsJrFmGTN+Kjk0elS0wF8DWQPuUY HAqVFZ5RL2cozoeppzwJ0xZ4jmQIL/LFBc9QWxlYaR/4IQ8ABWnwGx59V3SXaGUR6uA40Z1KO2wH zpOF4BH8fEPEYHaU9eTMFtjtZolatBGVh/qh3Qaqu80H7QXJlgEmcEr/Vfl9ULc/EwHA9J139Ox/ ujLxc3+hTPnnXcOBYgCH9ETnpgHtY5N3ozGNkEpDAuAZnQNwQWr4oQjgwuVGU1Vusyr6cj1DKqIB 3yRClbxTtLaIDkB+sG/gUH145uwlpHWAKJ+UwyiOqvZX1F8bPnohLhpuvhGaTvegVVVpxL8W0RmR 1IhvvN41Kv+n6h5V+xD9dp2ATpnP0REBwyhwRP0uowdIxUgPLfwqPcoOSJLWMP3+ha50TGhr8mel BgagE0VIT0gTY/X8GjpcgbzxONyJW4G+Va9QzQFAeMbgg798wOTA62z5RXLL165cGuT7kQL5os0B pIeInCkBviB9h8sCzxkwASjKC2itq7QXKt/Ekc85qWyOXjKAOdtc2C95RDV26rF7h6SIOgqAnisC XG8W/Vg0RBRWRbHLzRJRVwy640T0CaedFMief9wVHCgIcNbmgOTi7Bzcug7IDBnqEUbonESlBoZt CAmMkRXXojPI7wvyM13PfyBiVESNpcFgH8MvUiLqDo3xLyLUSafm0HFa2TQUH40POyCg62wg+XhF JyD/DuhyfmyncB3DqSnk5QLRP/WeVfqoqQeKUK8fILCeIUUhTbRSaSwAtilRKA4kFfLF6SVRNZz6 OU60lQjVeTPLA0AAvyxoZkHx4bpHBcaWiXqE1MWM9156D+iFHXyms61n80/eqbd8kq0LRxjnJ58/ x1faC7aoQioe/laz5Y1kK/jpJFoGFspH20JSCkt8SOKAHbO81Cn1sKEu00WoiE6yDsePv3k8KLVe IpljsMUE8rLCv6f0aK+APgM6bTTq4FGd/E6RX+pjDdF7efz5R13MgWISXDjpKFABNC3ABmkDINBz wGCyroShsQdOz2jcjGh7iJAKMYQjxdF4CPcfhf9S/tbXPfliLVZYxW3BCivdMPGBWkljQ6pCzXNp BWqtDYR9BWmKjo20hIrWlsMehY3sCxFq959FzxO9lUaDNEVIjozmgZNfgIgyAgit1OlIonQEJDg6 wHCF/T9deQZY3yiikwNQ/xBRFlQi1H/AHwn6zwpDHs4ToTZfq7x9aiVN6uA63VPuN0ISJ3kaIkKa RlKBT+TBqYROYiOrpAlhd4LXqLT5eBcANHlWOkhWBZ3ys71eMjDkc05FPQbgxoP8o6IyIAJ0pEPb oB776x0aAvlHokWyxm/UAW5DRaPlHzBqS6ImPGmgrrI0h+OkyAsDutsxc7JuMVew/zXaRp2tESBe gOSv6+t5S+sfdjkHSgU4GoVTRVtkykptF9LIdI8URAdfV4RtAvXBOYzLzC6hvu4tAgCwvSEZ0RjY 9E4nQxWi0T6t3zROJ8Gh8v2fGowboZnNpRPTKY7Uc2ZZnQN0UCmQdIgDgEPNAXA5waKQLYnwrhM5 SQVgGy+iPIDFjlZiIl8biAD62lDalH83ETwoJhURxHUGAI34xtkrEyV3K5/w42qlNwXPLt/6DZjQ 6U4TnSTC7ngQ4GbzcbWuSNGniFCnfisCAHFIpqRLnSFVUN79RKhUzna2g+6pGyRs+IeKxf2los9s POEL8QX2WuUNU0U+EHFlReJ+KE8cPKI9sp8UqZQ6PFM0RAS4XiKC1y+J9hL9RwRAk9Z6Imc2iUZN uwXgphVIs9Bj8rijKAfoyhPayVkiBjDsgoEkH3G0ZXhRSIptZza896XhQKkAR+MsJE3R2VDF6AD4 oUM8KpoaUY9o+EhP5+o5QIPx9WldAaE1RVvaK+UhPTe5wG8aCx26LlRYfr8mQtK7JsIE0sKQzKgO yGC/CyQh+S00y+qicGV1nRSAALg5Wok8k1fiJl4kOmYDHXgQB2n/zua/GJC6cuHHATlpUlbSy6m3 YUBW+gCUA30kkgdFLHINpFec7lmLltDtRyIkYqemkmcGGOqM+iGvSCVIQkjR+McFkrgISYsw2Enp 8H8rMjhQ9zNF1K0DSpclrsRD+eAfZc4HAJSHpTn4c/UAyDOQYaSfq3fn6H62CFuti4P6xZSQz+YI CNGWHI/Decp3T5zkn7oNVOCQQ5KlnV4kUnJ5d9bMsnkrqH20lQH/vvM4UCrA3aokabytRG1VMiM6 Hbqokz8koNyME571DBWMkRdiRG6PQ2J7UnG0snPpGarcse2JLOQXFRD1L5goUVzYlaDA6TfqaE4l jaYBuOhZPimng9lpFQyeYacElJDALlSaSLctnAUi1Pecs8CHREoHnhMqE2YCyJWRsruJpVLyPVWe GNTY/F7IyB/EI4DCJsVgmM/flXp+C/4UD2slkZRius9JUbp/Uc+YXCjJyf90eYQ6wyEF0uaCtlHA MfsMP6gf77qZAyUBnAUMQKPHOOUJiaBNI357M6x4HeC2N+g34t8CKMZt51qBW7GMKHxdZ2dUcQYS eSnxyi8DZV6nd0iQTopcqmPJS8lLe/0of2gNxcCNPAdSsXc9gwMlAVzPyKrPheeA54DnQPs44AGu ffzyvj0HPAe+RRzwAPctqiyfVc8Bz4H2ccADXPv45X17DngOfIs44AHuW1RZPqueA54D7eNAmwCn qXoW0rJ4NbymK9gl0JkzRkqHpQNDRCwf4HyvID09J4+sxwp/cKZoKe06KreGKxwX66FcGnNdGu1j Wc/xrXJSDwNFLCwttKiYha58DyHYqtQRp3TgJfGw/SiXjp6TNrsK4GUpu0M6kjxtgDVvONbHkYfo lrYOxesDlc4BW9f0H/pTl9V16TkqzWebAKdoDhaxEp7O5Ba/cs9iUtaHsW7sCRW6rW1JbeVolDyw iJO1duytZNEnjtXjF4seF53WViT2PVt22IrEyv4TRSwWxf1KlBSxGp51cp2+zKTE/HWWN4ANnowS FVo8y5q3B1VXfDO06Bq1fJmyAwy7HtjOxXpHt1sC76eKtrY8Zh1cpzqlzXa+A0XssnC7aThdmUXX /+7UxHxkbXGAfvQzEfu+n2zLc095XwrAsc/vRzbDdBC3ypxHG4tYdHkVK+fV6JYGMJAG2HLD6Iy0 4BzPNxOx2b5UhzRInt+3+XXh2LJDGizCLKXspabXXf6oC7aEsa2JBcb5VusDcOy86OjWIbcViq1u jOBht5Z+sI2K3Sid6tSc2CYFsHKYgVsQjiYxRrSL3v9R7Y3tW33a2cXQtAF29HzRhcxA0PiJiD70 rXGldHK35QQEZ3M8UgMOiY3Gh9QFyM0Ss9lOE93eUioz2Aq0iQjwcdIbYUkfCcxJYaXERx6Ih44R Vq2n6/cMEera0oBxKXn4JvxQtuDkChH7SZF+o9ukGCzYtdBu6c0WgDTgJQuKo2owC1/h9dJK7y14 pXbE3lekdgbXC0TsyHA7A5AiJokulD++eF9wV8k3UQHdmYY1HdD/UOE5nKErAY66Zu9vp9Z1V/Ov FIBzI/87akyzIhl6W0ym4bPN5zARG5A7tE1JcQNqbMMp5IpKIKhSisOBMZXQyr+VMEsCNsUXSJGl ALa1+ZF+YJvQ76102ZNGp2fucICidakwwX7JUBlKrXvKSXlfszsKSg3XHn+kkY//HZUKC6YtPgDQ qMKA2/miE8N2P/2eJj90NICN70o8ms8WbFVrToRpl72I9NtjbqHeSlX9bTshTyXtU7W8aC5iK2bQ xwbKgN2mjVXxVbaHH+31354G9U35LQXgXF5gZD6H1MD2FNSHQHqw4IA4yyke/w6LznqHOjNKhLE4 Z0fR8xF6BjB8puct9qwWY4bCraH324u21D2V/LBohqiVIVrvOXJnW9FHSoMTOAKn56jBPxc9R75E 7IEkjxyNDXj/K5/6rXds5sc+xAZsju95RFcaHbapISKk0qJOYeATJ2yghjfoN/YNvivBBvJSHWok k0FtOsWPOrO2CLsp29JyTu8wOaCKcnRVbq9qm5G2jAMpHNX1qXxlUBqotEj+HOXdIn0bzZq67iqi /Khd+SZP7if/IoC9RbtU/OQf9Za2xDcmGGAeUDyo6eGy0l6RBhmg/yui/qnLgTYMRyFh4giHcbxj 3zQTL+RzE/l/lzREj+QDL73n/Dja6E9DeXqoUB3LPwck0E7hFR8Bwr5Jfr4iM/pN3rcRrUx8Igaa ffQcMw71Rj5ygKfnSMTbEZ/uOXgBezbxtdrmZ0EV/pFXjpbHL30gqg2FONNzb9sDcK2YYYs1SleA jA35bh8eTMcYSaXCrNxmdd3TuP8uek0UNhTTKa6yfgGYNp2YDyigytAgkABp8LuLkAQBzKjdjsY/ RXSDKAdwul9edIUIFXyIiMbAKAvwYeS+UmkdqwaBmB44/aYjcsoFtj4aHv4JB4A/LaLxFzwHTOHh PWrlRBENtM5ef6nr/nrP+XYzXHptXAGBXN7a8MtRQ8eJuEYB5iA9Gy3aWQTYd8SRfw4DuEBlODXc 4fV7JT2Hz7QPeJTPUW+oXOy3zQeAhGEQ2V8EsOcmPRQ/tkjUVzo0HRz1mvzwucE/6npXSBqizpEQ AchnRJtb/wwU2Pn+betgViiTtEviuVu0ioj2RN3tJDpEdJLCBF8Wc2H0ewPdYyskb07NdnniiKvn Q/G77zr8Wc/gA32O+Jnku1dx8TW7j3TPJBr9i740xPoZryttkPzStwKAUxjCosZil3Y2dPJ6l95x Ck1OrdVv/JwtOsaGxz+D78EiJGF+h00+4az3yPtSAM6NoNuLATQGGhVMpxIZmf4g4lSLv4hZTmqC CTArapSGCbzDjheeSHDPib8ktUd5AXyoOCSGM0VTbCVQIeeK6EwvR7juZhqjdirKQuUxe8tJIuNE r4qQDrEB0UgYxQJ7j9Im/xNEgNtJottFNK4fizhNAj7wgeBi9grX8BlxObkDCQNeI0lcmU0msVsR 9cQVjTDkh9EZAzD14xw8plyor84G5/hfSOUsJKmHoi16+w+9PVo0VnS1CH46h0SyoSg4eqpALGEb brSNBEGsVNcivMoOKF4qgq9I0NNFdModRBeJauGDyIWDD8QPSPUXHS9iwGWAopMTjkGANuYcvIY/ DKL/FNFeAAgkP9LGFn2HKABd5Qkpj3QpN8DIO9oJvwHiS+Vndwta+AcESY/6ZGBlEKYPAUj0M77+ Bvh8JoLH9L+pIsrB8w9FlBkQJD4GXAQAno8X0caQ/n4vOkyE5En7xS/tgWcMfmgetG+kPfhzloh2 WSfKJ1ETRY90pQCcsxccqRJA+RwjS1giwo8LF0V8ftPx3XsXX6HnhRiHdIh6d62Ij504W8sNqqzl 9KxWlA9ESTs6EeLyyIiJpHavTfR9xUU8dFRG+ADg5NYWAXqow5eF1Kjb5R/VgoZO/m4plHn7HPWJ M+pQeZzjIz5IEEghlIPGXMxRbhotklHU9kj9zhIheTigoezwPl9DdRMGHR6lVRa+PHan4kfC2tCl a6WDX+s3Ugwg2JYjj9E2UizMLnqJRM+3KM4LeeRTj8voN4PgvqLT7TtXRvjAQapoDzgmy07Rlfpe X/dlIYnMtRukS77T4eqGNCgr8WM7dFIlbWCU6Gz5BWSd49RrNAAkNfy4tAFO1E7aIJMGgZNfABuV G/5xPBaDL8tlACwGU9r5s3qeU6n1jkEciXyIaLTeoea6+ABDBu/95A+JE3MAbe13IuybpM9ggOOE aOKhjWKSKUkAcWl197UUgHMgMUWZxT6EZOZGP0RkxO0TxAQq+5YSJI7OKjM2AvKPvSFqSL6HPIny SgAFMsBISQOJqmZOKg1XLI0HosFHwQD/+GUULuboJKixMfGORk2DQ9UnzzQ24h0iagvgkNgAAlQ+ 1JJwPuEPo3mp6msbWS75NdLNONFvVDZOUAZ4kTYA/zdFlL2zHfzDMWhEnRtAkHLDkwi05c9Fd0UC vGWfk2fqkYEP56RjPgAerZcZeo9Eh8TjHKCL5AwYAbJoHdQrz14RUV+YVwAxpG+kRtqgG0iDeJQW JxwjXJCfsNqO5El9k6+o5E189E+0Kz5Wjkbj+jvmnFkipLKtRQAcKvHyIlRmfuec0geQEWAoT68E OCoF+0UriUQFh0mI3oi0SDRfhZmT554Rs8MSQig+19jyjfKI3ti/wupasWxRaVQ+jdapcs6/iyOc Z0ZOVNYNRagBD+JZvFhXFxYT00ix6xR0DATyj31yTxsPDRI3W0QnAZhK4ROdFDWXY9tbNMxi6Xfx OwYJ1D3MBfDkRcsngPsi5ZMOVsi5DsQA0p4BirgBjKfyRIzNDsmEASncQbmnvqNtyAFBIf5TR1HX whyD5CcPq4p4jtpJ+s40Qj5oV4NESHw47Gr4hzetZn7zaEiF+OeeA1aoyPAFLYeyurIz4KxmPQJs OFRz7I9MCuabeUaiA4BL7VNt5e8beV+KBEdGYEw+exrv/iVCZ8f+xAjTFsDBRDplV+rypQBDlMGU EemrTbWIDqoGfKH8MtL+U/d/1ZUGjN0ESeI4+UEKKOgUZm+9vNymOV1XQADgBByJG/teqaMlja5Q /eQrJ/zJx/82y16sTO6dyo6tCDUViY12QdnoHAAN7aWYc3UHGOQtv1W/sI9R7luVHhIW5XHSTL4y hzt4+D1xRDut81uoHRUDXhcmfJ2pNJC8wrZfQAbB4OVQZqJhS2F3IT/ERbm+FgH61G24nNQDQIbk j3OCR3sGlaXJ3zcStlSAcwzIlykY6VS16OiI/6ihnY6IOB21gxUqsIsz2iFdZ4xOGBAPovkPRDSs Up1rEG2CijoYZdhIhHoDWO8nIjy/MdreXixRhcdmBhgygu+vDjo97N92YBpje4C61JGVOClji7iV JuoTPMuXrvPfnvww6NGpUVOpB2xIj5ZQJxjEUd9Q3TYQYRaJOlR5BgcGU+IE4DD2U4YtbfhwGNRM p8K1pwx5ki7tEXZZayOjnbAAvgWw2zYUFggAItRJJK9W5g35RxKjvbDEicG0LQfv4Q9hjleYFlKn bYNIbW4WtU73xLud3p0p/84049JZx/KwKwWTtsrU7vftAbhCozuGz21EMAhVCYdfB2xR2wDGW1yp AIdfOl2UsajD2DyokOsiFbKLnmMQndFujpQWYGN5S4pQPbjSIMkjm9pLKRegTGeET3TmnFNZ4Cdq 7yxRtJGVlrvivuhEONRHN5nifo/SDR0tDAJhaSaqvrv2E31OfJgJsIUiqVJPzHLebO1xBXNo7T3X yQMGeGy7LKUgT4HTb9rTH0TYn24QuQ7qJGYmni6LJIAkiWNtXrGZ7YL56uCL6QqHgX6MKCq5HqBn THwcK6L9fq2yUR8JETzLTZToOe2LSQe0AyRhJhlw1I2zBUfbSp3eMbCQzi9E01wZ7AD6d/1eSzRa NEv0pQhQ3NCm49JwS6KY+cXl+qHiYXAfJcKGjPbB2spvZABxZWnrWgrAOYlmXxVoVUXoAAtRFkkJ 5qF2niYKGhuNSH4ZwQGaU3WPKMxospPoeMukqCgMQMCwaJ6wi6HasEyFtPjYMaMR8WNQpvEw03Ol rqTzU9ERtuD5VI98aVDGfM+JxsURzi+Nab7olyI61qc2fL3ygUH/E+WRKfZCDomDBoT6dozCII3Q 8WhwSIDkZajoR3r3seIqpjrCL/y3KXnazGDgBzDGK25ACAkJO9l4EWV0Ep7LO/mivKuK9lAYVELq BEedEoZBhvKy2yUAO6QMPUOFp7OiTmIf/I+LtI0rwEVbGS0aafmDmoXd6DARgwADA19oc9IM6t4j ot3lH/srv8k7dXSyiHr6RyhdBw75VFf3LtoWXRvIp8a5Z+E2R36Q5vdXnpBMp9s8racr4DZXNCOU J/g1VjTB8pO6QltAQ2AyAFva+yH/tAvsjtjxfq4w2H3pi2/TR/R7si3/+bonGO+d9kCdkF7QTuX/ c/m5VLcMDpN0f4qu2IEBr7PtlXYbLh+DzF9ElOcmEepup5g5QmVcqttSAA7QoNMymYBk4RyNgAKy /OBUGBNBb0acUaLRottEzsiKfQmxfbCYGAuFoWMBGlEGUQH3iRiJGNmpqUkKx8wSM6WTRADab0U0 aEY0GsIPbVxRkKMDRkc70uY5FAUK3gGwYcPrS/pNY6Dc2N/INw2c9LligzpNeaTcrZwdAM7VCxrm ISJAwKn5d+n+Rfv8DF1JC3DI5wKpUVSKyuLC0/mRPIn7EhGdjHbABNKbolGiHM+oH5Xlbj1D9ZtI nvXbbZ8CiBjE4D9S/D6RvD6v3wAT7QbAocO06ZQmy3N+J49MXNHh4TFtECBH8mVSh8MdcnZO3cPz o/ScDgqg/V5E3SH9IMmwOX9WJHHAoZBER1uAt+H2Qx2Rj3xSCv4BgJxTeuxCOE4PaJO0VfKH4zcS E0tNcpKS7mfKPwIA0ivlcJIxoERbYjlLOA3aHQADIfGRN8qD+YOdIk8pPuqG9/QT2j3lod8CvH+I SLRIdSuJyAP15frDLN1PFY0SRcHdtb1STSSU/xtzpQDcFOXmccsYOr+rXHfPItJWHVDP+CI8zGXU RH+HuS/o+UN6jsQwJAKIzNLQmKn4nLMdDCB5QDRChNQWOL17UXHRqX4m+pGIyn/C+v2eroxmNFLn GEXxj8QVdkgkgAwqdhQsHrHvwmXEdoL0db/oapFrOIjv5JHGfLny9oHySCdv5fT8Tb0HtMk7cdE4 kaZQU6iXZ0V0qM/zhbfPKBtANUTkVM8i3nPfTK2VJ6SDTUSDRS/bdMk79cWgFXZ0NsCE0fxV5d2p KY/o929ESPJIhU6yC8JaKYJ8MTiwnKcU9d2Ffd2C3DV6wIBIm6H+nhPxeUKk+BYOsFAY6hGebiaC j/+1aSOthh1t4FAR7blFm9NvQB9JkbYQbj8A+gwR0mPUUW9IV7zPOeWJb+kigTEAkCcAlwGM7XA5 gHYB9Gy6/AN6+N9QRNuiDGztQmIOx42db4oe0DZ/IKK8CAS5/DHIyg8DFwMUdk3KRttithSAD8fX zMCsB7TDzUXL2LxSNvoWQgMDrnMA7HgRbRBJs8eBXJsAJyagW0PtdoCcAiEZQGFGMqK2cPILuAAY rZze0XEQp/O9o1EBMlDY0WmjaVBJAGX0OY24UNo0mKi6idpDA9hZeXs0Gp8aCaMoIx5gmhfgCGMl iqt0C0Ud4Ys6CxioHe1yFqAeUSAo7GiwrYDSjvJI0S2cjQe1M6/qKT6soneADR3u4XZlMssfOvdD kOIKL7gtGJXCUFdI8NdGNIRo3qnzqF0s8KM4AORW+dVzgD8K/i7MLN1ArZwFJtpv3jach68F08nj l7ZGXgvyV+kjPEBtOlvXSOxQ1CE555z8AoiAJbyEepR6SkbbBLg2OdI3PaAywDsknnzOPc8Zx/sK m9TgUb+QCpGM9hWtITpZnSEsCbWbHe2R/lzkCpNPlWx32j5Afg4wgOgN6vTaooNDkn2PYZkHuI5V BRIL0gV7CZldQt3hN8CHGnewCCk1KlV2LLVvV6jllV1se9gXMT4jweaTUL9dpfK5zccB7HHYdDlt p5Um0xNY5gGuY7Uww4IYNsbDRRi+nftEN4j3zPBx39ccQI9tB3vb9aKJ1sTQ1/jQ68uLiqpCsnqh xzoPcB2oGqsuYbzFJsEECpMEGI8xAj8iYjFmdKa2Ayl9K4Ng/Af0q0ULxAc3E/itLIzP9LebAx7g lqL+1HmZtGCGC/JOHLB2L2aEIe88B7qVAx7gupX9PnHPAc+BruRAmwBn16wNUybYQbBUM2GdVRDl 6eeKizVcV4XtO3q+oZ79QnStXS4QJKnnrAH6lej+nmoMLZU3duZqY/lnjdLTKg/La3JO70fqx5oi 1ie2WN+ld4RhLdOHdulAqcmW5E/xo6pvK5oa5n+hwPJP+2NF/VBbZ6zR8s5zoNM40CbAKSUWrbLo cDtRq4WJpeZEjRmbDA2ZD8curfoCWI0XsaYtvLiUBaGni5jlDK9d20G/WRVPeXvcbI8FLZaWsFL/ C7sWKS9rUQHln61KfxSxHi+6/okdACeJjhb9LRLJ9vo9zb4vaV1UqfVr/bGd6Cybp+jawXxRUd5x ItbLsbLeA1w7Ge69F+dAKQDHWiJWKC/tmqKtFAf729jX1mrRaDsripX0zOBEN+CTx3zPsZH9U8Re uZ7o2HExScQSCwCKlefFHCDNSvvvhD0J+IhnAxHA8Uv9vkGAGF6tzvo07IZ5F+Z2AmNcfUTrpVjU zLZSZ0vbvjoh+z6K3saBUgCOxlryFpsiDGIpBVtVWAi6tI7OUKgTtXquTn6X/EMlO4ED67gAEI6C 7uqZQLYEsZ4OgCtlNTj+2U+4t/LJpwndfsoN9QwVFFMC6uJyogDg5A/Qg/9s/SpFuiqZVyGPrl5K BSu3/7Y9gNiRfPkwfZQDpQBcK9ZY2wnqIMcDsf9vC92zH5EtLm/qWW57kt6heiFV0IEBCo6NpoOy d+0V+f0gnIDejdJvVBZWSbOX899LWzeKc0XFwV7G1xUfW7tyzq68x24EuNDR2CbDfa2IpR5sycoB nPyz5w8QgXeAB5uao3YwgJG9sEhKQ0So96jobIViD2Kwp1BxIRn/SLSayG3W31bPsaHhh727+To/ IMU2OHYJMGA4gCNN0mFhLYuNqSO3tWi4zQfg1mK/rc3HKD1nkTKOOqFcLYBK/ni/lgjb3zxr28Q+ yzE5LfZJ2nhaXOSf/MA/8kw9sOcR3lLX3nkOdDoHOgRwygVrvs4RNarRshaMzfAAFsSxK3wuztl/ aNTsRUWCo8OcKMKuh182Owf+rAE8oduDQqWM6/nl+s1WH1SrjrrRCsjqemxT5DtwihsJB5WZTe9u 3Zq7skKbExqCdK0EhFrI6RAAppOiHtc7jgsP731lEuRcGx57IQMAvAbQ7pB/PuoxS/fw4HwRkyAO TC7SPSCFGr+7qNXEjsK+qzjYAD1KRF0ssjZOJlgA3RtFgPYe9p4iIMENEbGZPreFzILWaXrGQQdh QLtC705XWuFN7TvKz5mipN6xPee3IiRJbIIFJWT5BcCOEcF/Bg9ssIAyC4H57QCafHrnOdBpHOgo wDlVBMkEVahWxAZnOjb356hRP28lOSYmADQkoT1to0bCo2M+RUnkl47OiQQA3oWiy0RILn8Q0TGQ Dpg86KhzajHAETilicREvg4U0WmniHj2fyI6LpLW9FCC7KsEfDjNYm8RkxsAE3nlu6m7yH9458Ky eo7BHeADbOjUgOnOIqSq40VIvLWie0THihgELhAhnSFpFev48IQZU/hP+CEiJGUmXp4QvShaR/ni 1JY63SN9UW8z9TswOVjJjbJT3iki8kubYIICqrBgTD6dw47HIAHwsWMDsGwhhYf8ulvKXCuiLRwi YoJjlAheryrqqbbRPEXxj75NHOgowFFGOh+AcLE6DJIX7m2rXgFMqEuAHKoI0gCdlpGeryxFR3tm 35Ci+IQZYQOnMON1QQU6TvecevpOB5nr1LywLZH8jRM9IuKI5kANVTqkv75oLd0HX2DSdQX9BmgB nb2QoGw+kKSYGa4V7Sr6q33u7Ghv6PceTi2WX9RGJgh+pvsRVjq6xUpfSFDwk8/e5T2xIlJ2loAA Ng7gWDaD3ZDjsTlGZ6budxONEk23+WMSIjyDzQCFlMcMJh8BDt4pLGUFEMkTAxeqJA7+kUdU8n3l v83JCls2wBuQPFxhnMkB3iEFs18XydY7z4FO58DSABwSGJ2M2cmwe0Q/kMToCGGHikRD5ppzVn1h uQPPkQhyzoILnWiMiI6YUy87gRNDFAd2qToHbsQJ6ChPACnASp4A8pVE2MnuDIGbywIAwBIUTt+N Ay62nLzniOyczU/3H8sP9jOAiLSd+ocEC29a8adIORkkkIAAOdxPbHxOGuI9KjV2Ohw20o9EM0Jx AorUIza0HPAh4SmflIt6YYmQAzjqFPBmUGsT3Gw6bmb3Mf2O7vigvskvvPDOc6DTObA0AEfn/1A0 K5IrNzMWzawzJOczKCMF4c5Wx/q9rs4PcSFp4Vbt5NJjY7tfhKS2njrsK8Sve9QpbE0At7N/AQJ0 bCYAkMBc/twSGmx5TCwAVEgl7n2LyQebf3genTgI86RUgztg9aloZaRBXTcUofq5JSa8w364s96j RqOmv6FyhtcyOpUd0I06JkQANCYVnCNvAD7plOrgDW0F1TgsPRIeXtWJlik1Mu/Pc6A9HFgagCMd Omq0s9IpSu2k0bzS2LFtOemPeDjwEMM5105z2KXU8S9WhLeJbtU9kx0AFIZwgAFV0Rnd3RXAQ9XG hUGYsNgTo8tpCi1/IL5Sl1IUKjPpzxVtJMLGt6GInR1ukgQbHRMVTDyMEjEpgP0w7FweitVXvjK0 p9248IXS6GhbKcQX/9xzIMeB9jTUfGyjcZZqP8EvHaqF4RwQsWob8XO0zp3RhKydC5BzLgwu+fLV 5ro9xcnZbSxdQRohTxjV4QegcL7yEUyAWAew8e5JPd8vT/5QExv0LmyMx1t7O6+bvCmliZJnVDzs n9uLALaHXUDL1xf0m5lYysakRxTg3PIXpKyoY3YUPmJHjLq2wCrMfwYE+LK+eN4/IsUhQcK7QgNB KXzwfjwHCnJgaQGuPayl0SMhOZtROCz2Igzb+6sT3IftjZfWPler25+KdhW9ZwMBqoBBoY5WymJZ jPN/Ep0swtCNCofk+LlLP5TBWboHCH+hPG2o9zPcO/3eR/csCWE2kiUtHXGUw9koS1oyYQEMg/1p ImZ1ASLyGXbkE1UTKQ6giU7uMJtNeluoHDWKE5XRzTAD5PxGJS/VufoID3rEgfrPLPqPIvGRL56T T+88BzqdA6UAHJ0+qnbSkAmbLzzv8B+V7Ohg2LKOUmei03GPTYjlDM+IUPOYbbtM76/SlVGdiQWA j46JTck5bH+A5Ynye6WuGPORskgbyYPnf9eVpR50YJeXcJ6QCFGHWbqCkRv7ECDDmjI6JIuQ3ydB O/FQq9tpIs76Z1IBu9U6ogtFdOKwxJcvPZd3x7cwOCN9vS1CEjtU8d+rKwMBxv989jEXl5OU4CUf YiGOnNNvFmHDXxY549ep184PaxhR0eHBhfI71b5gUocZb3hIeOcoVzETBPHj54+2DskTC4LP17Ob bBpInJQJ215S5Cad2ivthovq7z0H8nKgFIBDUso3cQAAFbIj5Xs3Q/4BMWZYbxXRoAG0F1Ht1Alo 7MR3lGgve8+6MBat8sk3Z1uiIHeIkDCQXJAKkARYuoFEQjp00PVE2KboTC6fYVUIde164rZ+ATzy hNoESL6iPB0WUlUBgiNFp4i4B6SHip61+XuJjFkXtd2FXgV5acE3JCcLmix6PU40XsQkCMs8igEc 7/D3Q5GbXAinxb1b0sIAEeYhwM1s6fF6jsR7kAhpFAcPLhXJS4uvqDsVulC9oyIzK4pajGTGhA1L he5UOgxUE0XUPTZOgJCJHPLuJjuiefe/PQeWigOlANyflcIVImbtnENaOsI2UmfHce9YUsDyghYd zhr16bzXibB/ATavukB6P0edgDVoN4iYkURlpAM/E+lk9DrW26GyrinCvoMkxvOX9RxQYEmEm6Hj 1c02rfAMIlINwDhFxCwjZXJLNXh3Ds8V3yjybiXByfrN8gikD5Y/zBHN0Lsg/ZDDjge4zoo85ycA j/SJFJpziuMFxT1aD8g7UlJd1E80LoX5RGFYqwa/wgAb9jpJP8gzvAzbMQM/iuNDxXGgbuEBAAvY IYmxBzeqLk/Xc6TbfHY5FxfSIPwhnpxEqbj+pnQAvzVElP8TEQuS+c1AEZUuo8X1vz0H2s2BNgFO DbNVY2bkV0oYsFs51Dk9zLtGSu9QAx8rlEu9RzKIrpXK611+scc5m1zOT77negY4hwEa/1uK6NAX AoyRRGaoM66iZ0iVqK917r38AtyFpKXAm/wAJnklL71DymxXmQr5t2khwUGF4qQ+3OLaQn4YpB4v lo5Ni4XOUEEHYOplC/AO8Q4+R3kdHnTayoJ/7znQLg60CXDtiu3b5Rl1DTvXDgIzDgjISaL6zewq ajKgOPfbVSyfW88BzwHHgb4McP8SEx4RYfT+uUANSdXZ4HbSPZIbKjPrybzzHPAc+BZyoM8CnCS2 DwRqv1WdHS5i5wKTFThADhUbIzuzmIUM6t/C6vZZ9hzoWxzoswBHNVt74RkCuvP0s8XaLQ9sfasj +NL2Tg70aYBzVSowa7F8ondWtS+V50Df44AHuL5X577EngN9hgMe4PpMVfuCeg70PQ54gOt7de5L 7DnQZzjgAa7PVLUvqOdA3+OAB7i+V+e+xJ4DfYYDHuD6TFX7gnoO9D0OeIDre3XuS+w50Gc44AGu z1S1L6jnQN/jgAe4vlfnvsSeA32GAx7g+kxV+4J6DvQ9DhQEuFMTCTadDxNx2mqbH3Hpe6xrs8Rx 7f9qzzHcGTHanTjMgZeLTtchoG2m4j14DngOFORAMQmOY7vP1VEao3TloMr2dFbPcp3Kq2Nr28Oz tHidJoCu/XTl62LjPSM9BzwHOs6BYgAXHN+tjoZU4T4M0vGUfMi2OOA+7gMqpsR0PiTjneeA58BS cKAYwPFRld+L6Gj+u5VLweQOBI1pdAk+4eed54DnQMc5UBDgZP/hoMc6Sx1PwYf0HPAc8BzoJg74 WdRuYrxP1nPAc6DrOeABrut57FPwHPAc6CYOeIDrJsb7ZD0HPAe6ngMe4Lqexz4FzwHPgW7igAe4 bmK8T9ZzwHOg6zngAa7reexT8BzwHOgmDniA6ybG+2Q9BzwHup4DHuC6nsc+Bc8Bz4Fu4oAHuG5i vE/Wc8BzoOs54AGu63nsU/Ac8BzoJg54gOsmxvtkPQc8B7qeAx7gup7HPgXPAc+BbuKAB7huYrxP 1nPAc6DrOeABrut57FPwHPAc6CYOeIDrJsb7ZD0HPAe6ngP/D4zOznkFiApuAAAAAElFTkSuQmCC --_004_E0C26CAA2504C84093A49B2CAC3261A43F7B4F37dggeml511mbxchi_-- From nobody Fri Feb 28 11:53:18 2020 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB65F3A1CF6 for ; Fri, 28 Feb 2020 11:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KerApETPajbv for ; Fri, 28 Feb 2020 11:53:14 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 152CC3A1CF3 for ; Fri, 28 Feb 2020 11:53:14 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id p9so4527134wmc.2 for ; Fri, 28 Feb 2020 11:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nKZFRHXeN0qJpL691FAQ4+XKQnR0/q+3jTdmWyn19gU=; b=Eysn0NPhMqQFJTskm6NfunkB3eovu5aU8VQP6SQp7sDfLqpoIm7l7tobh2wtx4ISBE bxBA4iXiyvVoz1Yhu2+tWEb65KOtHNXuzTPfoVPLw9r9nqtJAoItOEyKg39elF6NAf5z hcYLwqY0hJjCIsYOKATy3p6s/CX/pXyaPAjDpYSI2EPMhE2KHbcOaGj4vm7PfjWEsSSr +qkdHUgl7xPj4mZ5LjygzHArK8crrowY8Sl9o4Z0KCAlM3jlD9/V816UnZhe+fWD0W4G pJ7QL/0ArxEh0jhWji0PeP3ZVNXF1MPSsWG98Oj0gmJv8L9HU/A74VaF2JdPBOEa3Lfc JWeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nKZFRHXeN0qJpL691FAQ4+XKQnR0/q+3jTdmWyn19gU=; b=TkeD4DNn7f13naqWLVHO5an/ACin3+z9oKbLB4C5FI3Z39PMMMG0FoWbM9ucebcZt5 Jx/xzeP7MEhEtMp7Dqz94Te7bffy8g6RgrubGhKXk0jbiaxc/WDY0yanhiXuBHGbwcM4 eu6anyFVBwWa3kNz1v2ZggACbxbHx5lsD6EcEEhEPfxyKDVHHK1Fx3VYtmWQgyMHcr0f zGQEq76ZpbxCE7egJhKUq22aYEsG+B+zicbG+Y5lKzPyLoTJ9KQEMxoiXTklkAAMOnyY NHM/XR/Rddw++ZKfNYmzXRWhvbIK6DFqc9Hd2rLPijFWoqeXCFmkaLi+fJ+iM3hsjFil LUCQ== X-Gm-Message-State: APjAAAXQopLsJOElAjOx7FnfK1wiR9I/5W1iB/BBustMDKoDsml9wgHC bW0ikCTaAy9gbxevObEFuFZcriajU5mHfDoI74E8c5/no5lMhS+Q X-Google-Smtp-Source: APXvYqx+T9Ig4FFqspH6V3wWcmCob0ZeDHliPqJ5oa4V/Rs9AAEdBwzv9bfzUJM09zuVoNaM6K7vZoPhE0jiXHARIvc= X-Received: by 2002:a1c:e908:: with SMTP id q8mr1878861wmc.77.1582919592320; Fri, 28 Feb 2020 11:53:12 -0800 (PST) MIME-Version: 1.0 From: Matt Hartley Date: Fri, 28 Feb 2020 14:53:01 -0500 Message-ID: To: TEAS WG Content-Type: multipart/alternative; boundary="000000000000022315059fa830e1" Archived-At: Subject: [Teas] Agenda for Vancouver X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 19:53:16 -0000 --000000000000022315059fa830e1 Content-Type: text/plain; charset="UTF-8" All, It's that time, again. The agenda for Montreal is at https://datatracker.ietf.org/meeting/107/agenda. We have two sessions: 13:30 - 15:00 on Wednesday, March 25th and 17:40 - 18:40 on Thursday, March 26th. If you have a draft that you'd like to present, please send a slot request to me and the Chairs by the end of the day on Monday, March 9th (that's just over a week from now). Please note that this is also the cutoff for draft submissions. We'll need to know which draft(s) you plan to present, who will be presenting, and how long you need. If you have a WG draft that won't be presented, please plan to send an update on it to the list. Cheers Matt/Lou/Pavan - *2020-02-28 (Friday):* Final agenda to be published. - *2020-03-09 (Monday):* Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59. Upload using the ID Submission Tool . - *2020-03-09 (Monday):* Standard rate registration and payment cut-off at UTC 23:59.. - *2020-03-11 (Wednesday):* Draft Working Group agendas due by UTC 23:59. Upload using the Meeting Materials Management Tool . - *2020-03-16 (Monday):* Registration cancellation cut-off at UTC 23:59. - *2020-03-16 (Monday):* Revised Working Group agendas due by UTC 23:59. Upload using the Meeting Materials Management Tool . - *2020-04-17 (Friday):* Proceedings submission cutoff date by UTC 23:59. Upload using the Meeting Materials Management Tool . - *2020-05-11 (Monday):* Proceedings submission corrections cutoff date by UTC 23:59. --000000000000022315059fa830e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

It's that time, aga= in. The agenda for Montreal is at https://datatracker.ietf.org/meeting/107/agenda. We = have two sessions: 13:30 - 15:00 on Wednesday, March 25th and 17:40 - 18:40= on Thursday, March 26th.

If you have a draft that= you'd like to present, please send a slot request to me and the Chairs= by the end of the day on Monday, March 9th (that's just over a week fr= om now). Please note that this is also the cutoff for draft submissions. We= 'll need to know which draft(s) you plan to present, who will be presen= ting, and how long you need. If you have a WG draft that won't be prese= nted, please plan to send an update on it to the list.

Cheers

Matt/Lou/Pavan

  • 2020-02-28 (Friday): Final agenda to be publish= ed.=20 =20 =20 =20 =20 =20 =20
    • =20
  • 2020-03-09 (Monday): Internet Draft submission = cut-off (for all drafts, including -00) by UTC 23:59.=20 =20 =20 =20 =20 =20 Upload using the ID Submi= ssion Tool. =20 =20 =20
    • =20
  • 2020-03-09 (Monday): Standard rate registration= and payment cut-off at UTC 23:59..=20 =20 =20 =20 =20 =20 =20
    • =20
  • 2020-03-11 (Wednesday): Draft Working Group age= ndas due by UTC 23:59.=20 =20 =20 =20 =20 =20 =20 Upload using the Meeting Materials Management Tool. =20 =20
    • =20
  • 2020-03-16 (Monday): Registration cancellation = cut-off at UTC 23:59.=20 =20 =20 =20 =20 =20 =20
    • =20
  • 2020-03-16 (Monday): Revised Working Group agen= das due by UTC 23:59.=20 =20 =20 =20 =20 =20 =20 Upload using the Meeting Materials Management Tool. =20 =20
    • =20
  • 2020-04-17 (Friday): Proceedings submission cut= off date by UTC 23:59.=20 =20 =20 =20 =20 =20 =20 Upload using the Meeting Materials Management Tool. =20 =20
    • =20
  • 2020-05-11 (Monday): Proceedings submission cor= rections cutoff date by UTC 23:59.=20 =20 =20 =20 =20 =20 =20
    • --000000000000022315059fa830e1-- From nobody Fri Feb 28 14:40:44 2020 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FE03A1F3E; Fri, 28 Feb 2020 14:35:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: teas@ietf.org, db3546@att.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292933074.19931.17425519514376851649@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:30 -0800 Archived-At: Subject: [Teas] teas - Requested sessions have been scheduled for IETF 107 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:39 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. teas Session 1 (1:30 requested) Wednesday, 25 March 2020, Afternoon Session I 1330-1500 Room Name: Plaza B/C size: 300 --------------------------------------------- teas Session 2 (1:00 requested) Thursday, 26 March 2020, Afternoon Session III 1740-1840 Room Name: Regency C size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/teas.ics Request Information: --------------------------------------------------------- Working Group Name: Traffic Engineering Architecture and Signaling Area Name: Routing Area Session Requester: Lou Berger Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1 Hour Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: ccamp mpls pce netmod detnet Technology Overlap: idr i2rs spring lsr Key Participant Conflict: pals bess nvo3 People who must be present: Lou Berger Deborah Brungard Vishnu Pavan Beeram Resources Requested: Special Requests: One 2.5 hour session please... Other Conflicts: IRTF RRG, RTG BOFs --------------------------------------------------------- From nobody Fri Feb 28 16:12:06 2020 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C42A3A07BD; Fri, 28 Feb 2020 16:11: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 tfdUqNriI50Y; Fri, 28 Feb 2020 16:11:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A39D3A07DA; Fri, 28 Feb 2020 16:11:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C5838F4072C; Fri, 28 Feb 2020 16:11:30 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, teas@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200229001130.C5838F4072C@rfc-editor.org> Date: Fri, 28 Feb 2020 16:11:30 -0800 (PST) Archived-At: Subject: [Teas] =?utf-8?q?RFC_8735_on_Scenarios_and_Simulation_Results_of?= =?utf-8?q?_PCE_in_a_Native_IP_Network?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 00:11:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8735 Title: Scenarios and Simulation Results of PCE in a Native IP Network Author: A. Wang, X. Huang, C. Kou, Z. Li, P. Mi Status: Informational Stream: IETF Date: February 2020 Mailbox: wangaj3@chinatelecom.cn, huangxh@bupt.edu.cn, koucx@lsec.cc.ac.cn, li_zhenqiang@hotmail.com, mipenghui@huawei.com Pages: 16 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-teas-native-ip-scenarios-12.txt URL: https://www.rfc-editor.org/info/rfc8735 DOI: 10.17487/RFC8735 Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios. One feasible E2E traffic-engineering solution is the addition of central control in a native IP network. This document describes various complex scenarios and simulation results when applying the Path Computation Element (PCE) in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology, providing traffic engineering for native IP networks in a manner that applies equally to intra- and inter-domain scenarios. This document is a product of the Traffic Engineering Architecture and Signaling Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC