From nobody Thu Jan 4 11:03:23 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3511241FC for ; Thu, 4 Jan 2018 11:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 iDobaSx9z3wn for ; Thu, 4 Jan 2018 11:03:20 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DD1127978 for ; Thu, 4 Jan 2018 11:03:20 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id h2so2119235oti.5 for ; Thu, 04 Jan 2018 11:03:20 -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=kPCkwvCYNZ80blCYPsiiVwM5VsYjAi2+7UJS4VxUkIY=; b=RC2HcnmwihYI+ompqB4hwvhLOTyJRI9+EbmkX9gaWkLetnh0THbxCtiOooWWIQyiWP IMAyX1/exDjisG1de2NCaZDzkYY+xgA1lP6x645I1y071woCgzqTbIlDdLBiL0PJVYTr D1ZUBIGDSgBz3MR/UMlpOe/1/sRGnI3QrcsDkbmrJjVvfrrGBu3KaXpUp30nwo6/KQxy lK8MIGW/K0swsHsZoCtRmqQyawqbcwsfei3qP+ph5KJ3Wtx2YpHORV/6YH4NPno4YgUV S/bL4rNnyz5gjDdM89j+BMIRSt/mvkcw5Bs6VGK3EMk4YQTHWb8kr3oWke3zlYxI7yxV iRbQ== 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=kPCkwvCYNZ80blCYPsiiVwM5VsYjAi2+7UJS4VxUkIY=; b=rszPzRl7h7l1rLSqzjhWHNY2Vcx4nv+U7wtcUPyvVMxfqxHbicMlmZyPs+pf2Hijz6 FIbGEeii2rbjP2+7I1Z3xNS0suCh0bZApROkqIk54nnkJqBCA003r4cJkxr6GEZp1b3Z 7N2Eo4ApHR+hdDlnlKPKPAEjcebrX+uN1f9OPxaNt8nQeQjfXEhM/ZtVVLrL/mfElY0d bQthaHNv1li0BtFqcbQeHEUkmjNxNIpH0Nz6qEWqD9kehEb1kZ3nBjIdJXBofTkbJf7k 6ASlBENCt79+VzeD2Er8vQ9qGFwZzY8cv65icEp2rqTfQkioSlYa7aakjCWwvuW/BUjQ 1whw== X-Gm-Message-State: AKwxytfYkI1K6UqwYIIa0QcoQxTxhk6ynfeK66XIroEpZoKRcNNcXh1M K5+59S0VyH78FFiY8QH0k3Vs6RZof0k5woS4rYRG+M0d X-Google-Smtp-Source: ACJfBouquZQqS0WUQXtbEN3zfaxOL4r3DUzwWPdG6nkT32JSFbJYdr2CDQBtOcdsVO+8CW8znxl7ogiRu5fkQTyEtOM= X-Received: by 10.157.34.12 with SMTP id o12mr356951ota.309.1515092598941; Thu, 04 Jan 2018 11:03:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.4.54 with HTTP; Thu, 4 Jan 2018 11:03:18 -0800 (PST) From: Alia Atlas Date: Thu, 4 Jan 2018 14:03:18 -0500 Message-ID: To: rift@ietf.org Content-Type: multipart/alternative; boundary="001a11c0f238296d600561f7fc0f" Archived-At: Subject: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 19:03:22 -0000 --001a11c0f238296d600561f7fc0f Content-Type: text/plain; charset="UTF-8" Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG charters with Alvaro. Here is what we have so far. Comments and improvements would be most welcome. ================ Routing in Fat Trees (RIFT) Clos and Fat-Tree topologies have gained prominence in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services. The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'. RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale. The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will: - deal with automatic construction of fat-tree topologies based on detection of links, - minimize the amount of routing state held at each topology level, - automatically prune topology distribution exchanges to a sufficient subset of links, - support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing, - allow traffic steering and re-routing policies, - and provide mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence. It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration. The protocol must support IPv6 and should also support IPv4. The Working Group may establish additional requirements to constrain and inform their work. The RIFT Working Group is chartered for the following list of items: - A Standards Track specification based on draft-przygienda-rift. The document will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.). - A YANG module focused on configuration of protocol instances - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification. Milestones Feb 2018 Adopt a protocol specification document Feb 2019 Submit protocol specification to IESG for publication Feb 2019 Submit Threat Analysis to IESG for publication Apr 2019 Submit YANG module to IESG for publication Apr 2019 Submit Applicability Statement to IESG for publication ============ Thanks, Alia --001a11c0f238296d600561f7fc0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tony, Jeffrey Zhang, I, and others have been discussing po= ssible RIFT WG charters with Alvaro.=C2=A0 Here is what we have so far.=C2= =A0 Comments and improvements would be most welcome.

=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Routing in Fat Tree= s (RIFT)

Clos and Fat-Tree topologies have gained prominence in data= center networks as a result of a trend towards centralized data center net= work architectures that may deliver computation and storage services.
= =C2=A0
The Routing in Fat Trees (RIFT) protocol addresses the demands of= routing in Clos and Fat-Tree networks via a mixture of both link-state and= distance-vector techniques colloquially described as 'link-state towar= ds the spine and distance vector towards the leafs'.=C2=A0 RIFT uses th= is hybrid approach to focus on networks with regular topologies with a high= degree of connectivity, a defined directionality, and large scale.

= The RIFT Working Group will work on a standards track specification of a sp= ecialized, dynamic routing protocol for Clos and fat-tree network topologie= s. The protocol will:

- deal with automatic construction of fat-tree= topologies based on detection of links,
- minimize the amount of routin= g state held at each topology level,
- automatically prune topology dist= ribution exchanges to a sufficient=C2=A0subset of links,
- support autom= atic disaggregation of prefixes on link and node failures to prevent black-= holing and suboptimal routing,
- allow traffic steering and re-routing p= olicies,
- and provide mechanisms to synchronize a limited key-value dat= a-store that=C2=A0can be used after protocol convergence.

It is impo= rtant that nodes participating in the protocol should need only very light = configuration and should be able to join a network as leaf nodes simply by = connecting to the network using default configuration.

The protocol = must support IPv6 and should also support IPv4.

The Working Group ma= y establish additional requirements to constrain and inform their work.
=
The RIFT Working Group is chartered for the following list of items:
- A Standards Track specification based on draft-przygienda-rift. The = document will include:

=C2=A0 - an Implementation Status section as = described in RFC 7942
=C2=A0 - an Operational Considerations section to = explain how the protocol is configured, deployed, and diagnosed
=C2=A0 -= Security and Privacy Considerations, although this material may refer to a= separate Threat Analysis document (q.v.).
=C2=A0 - A YANG module focuse= d on configuration of protocol instances
=C2=A0 - An Applicability State= ment that describes how to deploy and configure the protocol in networks wi= th different topologies
=C2=A0 - A Security Threat Analysis document tha= t describes the attack vectors and mitigations that shall be sent for publi= cation at the same time as the protocol specification.

Milestones
=C2=A0 Feb 2018 Adopt a protocol specification document
=C2=A0 Feb = 2019 Submit protocol specification to IESG for publication
=C2=A0 Feb 20= 19 Submit Threat Analysis to IESG for publication
=C2=A0 Apr 2019 Submit= YANG module to IESG for publication
=C2=A0 Apr 2019 Submit Applicabilit= y Statement to IESG for publication

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks,

Alia

--001a11c0f238296d600561f7fc0f-- From nobody Thu Jan 4 11:25:02 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E393F12D7E6 for ; Thu, 4 Jan 2018 11:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 PDqej0Njp43q for ; Thu, 4 Jan 2018 11:24:58 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99702126CD8 for ; Thu, 4 Jan 2018 11:24:58 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id x15so2177404ote.0 for ; Thu, 04 Jan 2018 11:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mhRc+GPHazAajZJ23NZTrMN966zPWipEK9ClWzIZYjg=; b=mU1uhi4r/ORFp7pm9pj+kFZOA+mMz3zVix/Mfkicb8UXA62OyxkRhQleoGUgDLM37Q K5wFA+G0xYP3S9BFD8oBWZNLHMhxown2OWy8DlYkK9gbT/5XwARLHpTZEQI7VW/eGi7D E9Xx/9uGE3a2pOz2E4xk1CaWGMIffxuQDvaYwxXPTG/ekjcAjrHJlBhMDIpc8lh+fmbt J1vAmaxpcAo/pyE4ur8O9ASBBCVJ8YILXGn96iHWRi7NDP9SBUMSna7kcddyzkl+FGtn 2kv6BgYnSclMFgZiA6pALk00K3/BIHZh7vSLKSxW6FJOREP6Y0QzjCIRY91I8VZP81wG 60ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mhRc+GPHazAajZJ23NZTrMN966zPWipEK9ClWzIZYjg=; b=dhlUSRh/yxkvMKqd4jefoNZ7uoRQeQ+CHiNPTiSSO9jsunPMUdgjVI+Qie1/XDxkE7 S6WEzOEt4yiZNJaeV8oRWLJCG+PBzSdJN9nP9ATHUeY2xAnhj02isfrv+NNQbBkxXAyA LOhlC92cxANxGiW2rZV1AuJrV4Y+Sc+4d9WBWO0IHYwKw8G7iNS+D2/lQ9GxzTEIe/ZF z25CnClG3rfqadYilu/l/UnhYWcxWwjfr1b7Atjac02CbSJmH13jWMsVNHHC3Rst1gYR 3RmkaKiUMuAFA4Z/WkC6pd9Fz0TK3RmJqLXoxcUiLtdwMFt3S6kN5n/x+1/Hd02+RvlD yZzQ== X-Gm-Message-State: AKwxytfLcB1ZPhooT9IgL022slWQR4tjXduJOeFd7Rjo5grizabPoQo5 iruvPmD0Vc0uNRbujdM2IjEmuk0p X-Google-Smtp-Source: ACJfBouCmHcMCiYqUgcd9k37yXC2puAqZx7AcAiIX8sC/RxbXYnOP+RK01Kd1k7UDA1aqV1TzJICAA== X-Received: by 10.157.7.41 with SMTP id 38mr377464ote.315.1515093897985; Thu, 04 Jan 2018 11:24:57 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::100a? ([2600:8802:5600:f7a::100a]) by smtp.gmail.com with ESMTPSA id z51sm1834079otc.36.2018.01.04.11.24.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2018 11:24:57 -0800 (PST) From: Fred Baker Message-Id: <1CC03D9B-091B-4870-A66C-84D110BC09F7@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_50CE4E19-DF7C-4C42-9595-D403C5ECD903"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 4 Jan 2018 11:24:55 -0800 In-Reply-To: Cc: rift@ietf.org To: Alia Atlas References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 19:25:01 -0000 --Apple-Mail=_50CE4E19-DF7C-4C42-9595-D403C5ECD903 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Question: Do we have a simulation that can be exercised in virtual routing = environments? If I were a data center operator, I might want to compare = and contrast with my current routing approach, both to identify possible = issues and to qualify the protocol for use in my operation. > On Jan 4, 2018, at 11:03 AM, Alia Atlas wrote: >=20 > Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT = WG charters with Alvaro. Here is what we have so far. Comments and = improvements would be most welcome. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Routing in Fat Trees (RIFT) >=20 > Clos and Fat-Tree topologies have gained prominence in data center = networks as a result of a trend towards centralized data center network = architectures that may deliver computation and storage services. >=20 > The Routing in Fat Trees (RIFT) protocol addresses the demands of = routing in Clos and Fat-Tree networks via a mixture of both link-state = and distance-vector techniques colloquially described as 'link-state = towards the spine and distance vector towards the leafs'. RIFT uses = this hybrid approach to focus on networks with regular topologies with a = high degree of connectivity, a defined directionality, and large scale. >=20 > The RIFT Working Group will work on a standards track specification of = a specialized, dynamic routing protocol for Clos and fat-tree network = topologies. The protocol will: >=20 > - deal with automatic construction of fat-tree topologies based on = detection of links, > - minimize the amount of routing state held at each topology level, > - automatically prune topology distribution exchanges to a sufficient = subset of links, > - support automatic disaggregation of prefixes on link and node = failures to prevent black-holing and suboptimal routing, > - allow traffic steering and re-routing policies, > - and provide mechanisms to synchronize a limited key-value data-store = that can be used after protocol convergence. >=20 > It is important that nodes participating in the protocol should need = only very light configuration and should be able to join a network as = leaf nodes simply by connecting to the network using default = configuration. >=20 > The protocol must support IPv6 and should also support IPv4. >=20 > The Working Group may establish additional requirements to constrain = and inform their work. >=20 > The RIFT Working Group is chartered for the following list of items: >=20 > - A Standards Track specification based on draft-przygienda-rift. The = document will include: >=20 > - an Implementation Status section as described in RFC 7942 > - an Operational Considerations section to explain how the protocol = is configured, deployed, and diagnosed > - Security and Privacy Considerations, although this material may = refer to a separate Threat Analysis document (q.v.). > - A YANG module focused on configuration of protocol instances > - An Applicability Statement that describes how to deploy and = configure the protocol in networks with different topologies > - A Security Threat Analysis document that describes the attack = vectors and mitigations that shall be sent for publication at the same = time as the protocol specification. >=20 > Milestones >=20 > Feb 2018 Adopt a protocol specification document > Feb 2019 Submit protocol specification to IESG for publication > Feb 2019 Submit Threat Analysis to IESG for publication > Apr 2019 Submit YANG module to IESG for publication > Apr 2019 Submit Applicability Statement to IESG for publication > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Thanks, >=20 > Alia >=20 > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift --Apple-Mail=_50CE4E19-DF7C-4C42-9595-D403C5ECD903 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlpOf4cACgkQEhdRnd2G P+DPVBAAkuNzj9O8cLj1UwfZJ8GDkx0w1WPA67bi2DC9BX9LMcHS3g6m2CsOJMNr hVEzOLq1bqRmZ7gl6WlbTDcOQGjXHLWwQQGalBx8bclI72Yu5hqZHK7VLj6hivg6 T+TbbgJujD7wNF5EP0cgya0Oc45jxAjdSSCS6wduMG3ycCSJtV3wpfvAgQHJtz7U 1c36w/0LXq3BVN8kiVzbFaEW/Tje6iooX1L30aDk07Kk4a6jEwB7JeuN4A6UNHe7 kfN+JUQ44xhKcudFl6ocsu0T4NPv1vsoeJHgIjHx1jHDT+nCoCMRd9FqBaL48q0S LRaoPuReQQ9EwdN+3afLRUROKl/pqP13GsVTg8XIZJIMk9g6LUsN3mqvkq3bttQI 11e4gwAO4z+F9Ff60064Ptl8rAF74dZtJ8CDYLRWpUZbMo72Xjw/N8SAIALqCVRB 4PAdNQii4z0J1ktu/MsCPuk6jU9C+sPlLzo7ow/sLX7FkJySEoQLeRNPV0Bds4YL cTIqnbY443muxEIDwSyoXR9MGF0spQxIA1X0FPdKWi18hlkH+GSMmDxUMm5Dtrgw q5IBZoNp0DjR1TkqYrtaHdk2bpao7+YNyJOqatHHWu/pbBNXYTOUrMT5TD/TNiq/ 62JABSyqc7UgExDIYXIhGub+4lppeQlu+JlM4NbXEakh15tlGZM= =6xmx -----END PGP SIGNATURE----- --Apple-Mail=_50CE4E19-DF7C-4C42-9595-D403C5ECD903-- From nobody Thu Jan 4 12:03:17 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6305412D871 for ; Thu, 4 Jan 2018 12:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 wnjxaThRFgbp for ; Thu, 4 Jan 2018 12:03:12 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37E5126CD8 for ; Thu, 4 Jan 2018 12:03:11 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id b141so5574341wme.1 for ; Thu, 04 Jan 2018 12:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TdTLLp6xGm8CYRr680b/nNviyYACLRAWeBK6gEqxy5A=; b=GSPAM/+WevhhIBePw4IurC/IRNiF2JLmxOV+f0PMPBZqqF8VAxIcGa7AJrpnqYoTIZ k5fnn2LfgMonSfXYZBDAYjXfeGBPcAwfkodsi8mCjSD/cs1tOZY5M7P7W+Jxmr2o5Dxc CUATAJx4NcwP5wYBfOgJxKIJSP3JkVttweYki6A2bWdSRoELhZyI9SSEG1/jmJUvbRHU kRjeS5pG3ElqsjnH6+3GVE353haJBTCA9kFvTvFAB2jliZam3GZOVWfvsML9v8YEkH4M nb9Qwy5mITIKZfeWVBgjUKQe3uF/f0g1KmzsdWjaziGJcBr8fjNCT0dta/7AqcHbMVpn 7vUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TdTLLp6xGm8CYRr680b/nNviyYACLRAWeBK6gEqxy5A=; b=duDWAKnhvYWILqXDov6JJPsOJ6VBKOY0szAeteI7jjoHw5uIqNEdam2VvxSTGXyZkb oqQzGQYH8j1yV/O9sMOMEUX8q4wiCbKmJwbRArGNe6jKWpy4FzgFLkiYrYBs9JNNrkhk BWEmJywYRywYhsDpLgabOuSCTGfqy8LTwuOcmqOMDKwVhspo5Bj87PwY/xi80AH2wNR1 +Jx/P1jC4RdDvD5qJaN4FogJOXPlDp7PAk+j6XgRSlh1xignHOCRf10E0bFaVhWv+Yf2 riab7z/NU/iMnlJox2oLwwpdLCQsCpG2g5Hu8kJv4X6WnV0+DUf1wV9FzkR3cjxHXm1o eXgQ== X-Gm-Message-State: AKGB3mLB75gthsQnS3NNPlvjIR8ynoXlYRXdGcIFdheVhCJfMkgJozj2 r3xKGA6onTPtfxGtP4ogctmS0zaRm6fKczsu4se7xw== X-Google-Smtp-Source: ACJfBovY6LT2eL+h0LwMAEevDeaVLG5mqgZaICb2gkZ5i9ua1ZCCDbILL0Iw2y6ToOYRGh2ZEdqtmws8gUoVYSyPbH8= X-Received: by 10.80.180.234 with SMTP id x39mr919063edd.55.1515096190450; Thu, 04 Jan 2018 12:03:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 4 Jan 2018 12:02:30 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 4 Jan 2018 12:02:30 -0800 Message-ID: To: Alia Atlas Cc: rift@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0e46523b82df0561f8d2c0" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 20:03:13 -0000 --94eb2c0e46523b82df0561f8d2c0 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 4, 2018 at 11:03 AM, Alia Atlas wrote: > Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG > charters with Alvaro. Here is what we have so far. Comments and > improvements would be most welcome. > > ... RIFT uses this hybrid approach to focus on networks with regular > topologies with a high degree of connectivity, a defined directionality, > and large scale. > > it's not only working for big scale, it works fine for small while being able to go big ... --- tony --94eb2c0e46523b82df0561f8d2c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 4, 2018 at 11:03 AM, Alia Atlas <akatlas@gmail.com>= wrote:
Tony, Jef= frey Zhang, I, and others have been discussing possible RIFT WG charters wi= th Alvaro.=C2=A0 Here is what we have so far.=C2=A0 Comments and improvemen= ts would be most welcome.

...=C2=A0 RIFT uses this hybrid app= roach to focus on networks with regular topologies with a high degree of co= nnectivity, a defined directionality, and large scale.


it's not only wor= king for big scale, it works fine for small while being able to go big ...<= div>
--- tony
--94eb2c0e46523b82df0561f8d2c0-- From nobody Thu Jan 4 13:48:22 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5A0126E3A for ; Thu, 4 Jan 2018 13:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 3o5Q6ZNTRcOi for ; Thu, 4 Jan 2018 13:48:18 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDA9126B6E for ; Thu, 4 Jan 2018 13:48:18 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id b76so2767628wrd.3 for ; Thu, 04 Jan 2018 13:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TFSfZBPUDzdoDStBYMNhTMjcyI0vqJ+xG6LUW3VrfmI=; b=N2xaRCk+QCebFYgMIawba5Uxh2vQ3CuTZeLX5/pJ0vNhRlNgcjX3f75ix1Gb5Iadye zJek4qZlW+VEFQi0WEbcfu817QC1JXF3gWzv4GwhjyXNA7ke5owKEMK696o1ERz7mCJc Qwslcn6VByPRioLXdGdtpRBz+w1vKytCgPgKb+hQyuGBtVc0mejeHAxkmd4xt41xyPlw RHexrtHgF+cTvLOysD5EYeXQ65uEuYu3PlpeKWZpfvw7wVecJP/ClDSdqPeI+2dTYr1d 3Eye97XkXmO3HpyB/so7CXkkkbKi3RHER+sQ1qaGvXjN4KiDgs7XUrTsPY2mzY7Nc1na 4lOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TFSfZBPUDzdoDStBYMNhTMjcyI0vqJ+xG6LUW3VrfmI=; b=rZd11jprqPU0xRGSTMq1laqIy4l6LhuO2j4eDk1FulffnH6knawaH+cvzZWnhkHPCP d03dRWrnssstQHmdK5fZ9eOeWvfPiIctsDvSZAWf6Edqh4QuYfCOAMOW9ZhNqSQdzssL 3CAs3GtyJ3lHhnx8KOhGDPpUaH1jSaYmS77Vl4fhNGSLGBoTrZILT4NtBSlSvF8X0+zc UeN+afQrPeV9Wu9HJihqxXkxho2QTwkR926YHHJy1s49wJu1MX7cVOUlYKFGfgro/wIS hNOZBdbw/s/YYngOYGKWxRzC7LwVPs9pGB4DYTQAzQjPcvj1YJm11IguK78AqumF/ET4 oceA== X-Gm-Message-State: AKGB3mI+WZnc1xuW0ptkSGYdXGf3JBY0JOPUCjMl3UdnXwmvYl085wvD qb4sl37IKtaosGWVHmuir8oIN+CaQV0a/KsITP0= X-Google-Smtp-Source: ACJfBotM8pTpWuoh74mLaU+I0fR9Bjm96cx37JPMK460HMXZDV70UZoiYT1rvE8pKxSOyNrxbGCqovgCsLu9goNPAOI= X-Received: by 10.223.151.142 with SMTP id s14mr791878wrb.256.1515102496340; Thu, 04 Jan 2018 13:48:16 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Thu, 4 Jan 2018 13:48:15 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Thu, 4 Jan 2018 22:48:15 +0100 X-Google-Sender-Auth: q9xuobTOcKtQ526zeq0eEMzgGTI Message-ID: To: Alia Atlas Cc: rift@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1b562217be680561fa4a85" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 21:48:21 -0000 --94eb2c1b562217be680561fa4a85 Content-Type: text/plain; charset="UTF-8" Hi Alia, Do we really need yet one more new routing protocol vs relatively minor extension of existing link state protocols ? In the light of recent proposal of dynamic flooding I am completely not convinced there is need to discuss rift charter. REF: https://tools.ietf.org/html/draft-li-dynamic-flooding-00 Cheers, Robert On Thu, Jan 4, 2018 at 8:03 PM, Alia Atlas wrote: > Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG > charters with Alvaro. Here is what we have so far. Comments and > improvements would be most welcome. > > ================ > Routing in Fat Trees (RIFT) > > Clos and Fat-Tree topologies have gained prominence in data center > networks as a result of a trend towards centralized data center network > architectures that may deliver computation and storage services. > > The Routing in Fat Trees (RIFT) protocol addresses the demands of routing > in Clos and Fat-Tree networks via a mixture of both link-state and > distance-vector techniques colloquially described as 'link-state towards > the spine and distance vector towards the leafs'. RIFT uses this hybrid > approach to focus on networks with regular topologies with a high degree of > connectivity, a defined directionality, and large scale. > > The RIFT Working Group will work on a standards track specification of a > specialized, dynamic routing protocol for Clos and fat-tree network > topologies. The protocol will: > > - deal with automatic construction of fat-tree topologies based on > detection of links, > - minimize the amount of routing state held at each topology level, > - automatically prune topology distribution exchanges to a > sufficient subset of links, > - support automatic disaggregation of prefixes on link and node failures > to prevent black-holing and suboptimal routing, > - allow traffic steering and re-routing policies, > - and provide mechanisms to synchronize a limited key-value data-store > that can be used after protocol convergence. > > It is important that nodes participating in the protocol should need only > very light configuration and should be able to join a network as leaf nodes > simply by connecting to the network using default configuration. > > The protocol must support IPv6 and should also support IPv4. > > The Working Group may establish additional requirements to constrain and > inform their work. > > The RIFT Working Group is chartered for the following list of items: > > - A Standards Track specification based on draft-przygienda-rift. The > document will include: > > - an Implementation Status section as described in RFC 7942 > - an Operational Considerations section to explain how the protocol is > configured, deployed, and diagnosed > - Security and Privacy Considerations, although this material may refer > to a separate Threat Analysis document (q.v.). > - A YANG module focused on configuration of protocol instances > - An Applicability Statement that describes how to deploy and configure > the protocol in networks with different topologies > - A Security Threat Analysis document that describes the attack vectors > and mitigations that shall be sent for publication at the same time as the > protocol specification. > > Milestones > > Feb 2018 Adopt a protocol specification document > Feb 2019 Submit protocol specification to IESG for publication > Feb 2019 Submit Threat Analysis to IESG for publication > Apr 2019 Submit YANG module to IESG for publication > Apr 2019 Submit Applicability Statement to IESG for publication > > ============ > > Thanks, > > Alia > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift > > --94eb2c1b562217be680561fa4a85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alia,

Do we really need yet one more new routing protocol = vs relatively minor extension of existing link state protocols ?=C2=A0

In the light of recent pro= posal of dynamic flooding I am completely not convinced there is need to di= scuss rift charter.=C2=A0

REF: https://tools.ietf= .org/html/draft-li-dynamic-flooding-00

<= div class=3D"gmail_default">Che= ers,
Robert



On Thu, Jan 4, 2018 = at 8:03 PM, Alia Atlas <akatlas@gmail.com> wrote:
Tony, Jeffrey Zhang, I, and others= have been discussing possible RIFT WG charters with Alvaro.=C2=A0 Here is = what we have so far.=C2=A0 Comments and improvements would be most welcome.=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<= div>Routing in Fat Trees (RIFT)

Clos and Fat-Tree topologies have ga= ined prominence in data center networks as a result of a trend towards cent= ralized data center network architectures that may deliver computation and = storage services.
=C2=A0
The Routing in Fat Trees (RIFT) protocol add= resses the demands of routing in Clos and Fat-Tree networks via a mixture o= f both link-state and distance-vector techniques colloquially described as = 'link-state towards the spine and distance vector towards the leafs'= ;.=C2=A0 RIFT uses this hybrid approach to focus on networks with regular t= opologies with a high degree of connectivity, a defined directionality, and= large scale.

The RIFT Working Group will work on a standards track = specification of a specialized, dynamic routing protocol for Clos and fat-t= ree network topologies. The protocol will:

- deal with automatic con= struction of fat-tree topologies based on detection of links,
- minimize= the amount of routing state held at each topology level,
- automaticall= y prune topology distribution exchanges to a sufficient=C2=A0subset of link= s,
- support automatic disaggregation of prefixes on link and node failu= res to prevent black-holing and suboptimal routing,
- allow traffic stee= ring and re-routing policies,
- and provide mechanisms to synchronize a = limited key-value data-store that=C2=A0can be used after protocol convergen= ce.

It is important that nodes participating in the protocol should = need only very light configuration and should be able to join a network as = leaf nodes simply by connecting to the network using default configuration.=

The protocol must support IPv6 and should also support IPv4.
The Working Group may establish additional requirements to constrain and i= nform their work.

The RIFT Working Group is chartered for the follow= ing list of items:

- A Standards Track specification based on draft-= przygienda-rift. The document will include:

=C2=A0 - an Implementati= on Status section as described in RFC 7942
=C2=A0 - an Operational Consi= derations section to explain how the protocol is configured, deployed, and = diagnosed
=C2=A0 - Security and Privacy Considerations, although this ma= terial may refer to a separate Threat Analysis document (q.v.).
=C2=A0 -= A YANG module focused on configuration of protocol instances
=C2=A0 - A= n Applicability Statement that describes how to deploy and configure the pr= otocol in networks with different topologies
=C2=A0 - A Security Threat = Analysis document that describes the attack vectors and mitigations that sh= all be sent for publication at the same time as the protocol specification.=

Milestones

=C2=A0 Feb 2018 Adopt a protocol specification do= cument
=C2=A0 Feb 2019 Submit protocol specification to IESG for publica= tion
=C2=A0 Feb 2019 Submit Threat Analysis to IESG for publication
= =C2=A0 Apr 2019 Submit YANG module to IESG for publication
=C2=A0 Apr 20= 19 Submit Applicability Statement to IESG for publication

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks,

Alia


_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift


--94eb2c1b562217be680561fa4a85-- From nobody Thu Jan 4 15:02:54 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9C1126BF7; Thu, 4 Jan 2018 15:02:44 -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_PASS=-0.001, UNPARSEABLE_RELAY=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 L5uNiMSXIB4a; Thu, 4 Jan 2018 15:02:42 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA06B126B6E; Thu, 4 Jan 2018 15:02:41 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id 97so36270otj.13; Thu, 04 Jan 2018 15:02:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=/vharC6XqmhTbYQsojGFS3lPraWqh5fOutlWSGfXu90=; b=VhU+RU12PhnIrcFgBXB6i1fcAkAspPiCizdh2pZWTGCIbf+4ELbSMwTqnQC1Vj2hJN Iczz/xkk19qers1qylNEXaxTjZtjY2/yLoviOy/j5TX/7Yv5KygegvucprRfNYTDgc6c 2vSbdtxNFZHHJdSjrz5idVv8XxJpxVP/l7p4U2LklqmfXLRMv/wTX8EDWkR0St3qls31 PYkdVJ3yFhzeTHuNxCo5HFrWZ7XInxNSxQBQM1Hnftech7ob8hmC+Xxgx8zM6xKcgnC9 wZGynDFU1+Uua89KttprfCZ7hlmYiO3YUvUZrmZIUZBPEpAvPD1g1scXZ8mBs5+Jdfnw Em3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=/vharC6XqmhTbYQsojGFS3lPraWqh5fOutlWSGfXu90=; b=Ry/MGoQc1/rGKdOoM8xxXBPC/usP29tDa6B08RCX85sdozGfgU7OsxgoCc3KM+YFbS Xegf59WSNFg12pAF563stS1MYbUG25X/73N3MqORsWUglNPmJr7uzYIjzkUHNVhSNXKV iOaCYeqSz5cMZAM2XQFerrHBEz6avwRH6alPANrBNfFhhpHIm2hHVvMAGn+/aU0SC0ID 3jkN16gk1LHlxaSq2IcEJpax68rKIG5TTEjVv6lJA1OGCScL3h7MsbaSUcP2PnVMcAs/ YhcoBePzdzgvblIqzBMqgJQ5OWNKBg5kkVWgdvEKAYJgoHT2wuVyGJk3S8Nx0Fdo44TO L8Kg== X-Gm-Message-State: AKwxyteAm3hgXsTT4A7M9Ph3RXDexY56v4+mIkudQCff4A1tQwmyucP/ PfG9FXFfy3ElakuI9q2J5dgBZgO9fuKlaijAtmE= X-Google-Smtp-Source: ACJfBosGobI0+2nrcxLrPc2op9uNqoxPxrbinSB0vMMfyF1Ag61N0OXQf7QZJW6u+ZONVTAzzTbS+a2ub+LnQJzKRvM= X-Received: by 10.157.89.137 with SMTP id u9mr702509oth.164.1515106961235; Thu, 04 Jan 2018 15:02:41 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 4 Jan 2018 15:02:40 -0800 From: Alvaro Retana In-Reply-To: References: X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Thu, 4 Jan 2018 15:02:40 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, lsvr@ietf.org, "dcrouting@ietf.org" Content-Type: multipart/alternative; boundary="f40304353f6438a2010561fb5471" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:02:45 -0000 --f40304353f6438a2010561fb5471 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote: Robert: Hi! Happy New Year! Do we really need yet one more new routing protocol vs relatively minor extension of existing link state protocols ? That was pretty much the question asked during the dcrouting BOF in Singapore. Starting from the assumption that one size doesn=E2=80=99t fit = all, the room showed interest in working on solutions beyond the current work in isis/ospf (which was also quickly reviewed there). To be clear, the intent of chartering rift doesn=E2=80=99t mean that work i= n other WGs (including new proposals) should stop. Quite the contrary, if there is sustained interest in this effort, then we will go on with it =E2=80=94 if = there isn=E2=80=99t (for whatever reason), then it will be clear as well. Note t= hat I asked the proponents to constrain the proposed charter to work items that should be able to be delivered within a short timeframe (around a year) =E2= =80=94 so that we can reassess the interest, and re-charter if appropriate. The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2=80= =99m cc=E2=80=99ing that list here to avoid repeating the discussion there. Als= o, I noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80=99= ing that list as well. Thanks! Alvaro. --f40304353f6438a2010561fb5471 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On January 5, = 2018 at 5:48:23 AM, Robert Raszuk (rob= ert@raszuk.net) wrote:

=
Robert:

Hi!=C2=A0 Happy New Year!

<= /font>
Do we really need yet one more new routing= protocol vs relatively minor extension of existing link state protocols ?= =C2=A0

That was pretty much the question asked durin= g the dcrouting BOF in Singapore.=C2=A0 Starting from the assumption that o= ne size doesn=E2=80=99t fit all, the room showed interest in working on sol= utions beyond the current work in isis/ospf (which was also quickly reviewe= d there).

To be clear, the intent of chartering rift doesn=E2=80=99t mean that wor= k in other WGs (including new proposals) should stop.=C2=A0 Quite the contr= ary, if there is sustained interest in this effort, then we will go on with= it =E2=80=94 if there isn=E2=80=99t (for whatever reason), then it will be= clear as well.=C2=A0 Note that I asked the proponents to constrain the pro= posed charter to work items that should be able to be delivered within a sh= ort timeframe (around a year) =E2=80=94 so that we can reassess the interes= t, and re-charter if appropriate.

The above obviously applies to the lsvr (aka BGP= -SPF) proposal, so I=E2=80=99m cc=E2=80=99ing that list here to avoid repea= ting the discussion there.=C2=A0 Also, I noticed you forwarded your message= to dcrouting, so I=E2=80=99m cc=E2=80=99ing that list as well.

Thanks!

Alvaro.
--f40304353f6438a2010561fb5471-- From nobody Thu Jan 4 15:13:51 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE18126B71; Thu, 4 Jan 2018 15:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1QXHrMx-l9KQ; Thu, 4 Jan 2018 15:13:35 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F3312420B; Thu, 4 Jan 2018 15:13:35 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id b141so6301299wme.1; Thu, 04 Jan 2018 15:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TIMiJJbEceqbsi0eZInm8W7y2HyIhMaKM98cY+BhLcU=; b=kRf5dq60K+tBNbTQawUatyzXWSXgqMrdWoycmTQTL3U3J61B7rRuDCM3/21XPJgCri e/pjMKvyLfnLV9niM6rsj2+4BEiRFX36hpf+8dezh/SX5A1WSud8J1qOMgLGsMiGgej3 2LQdj2TTJCb62hX8D5fj8lRmRnf8RETmKqk2mpzTsv6bj8tDk+P0UR1IAA66sZyVoX8q POOQ57NQpPbFIc9fXNOFCyDWla712N0ADYuv2rOAu9KUGH+QDWrmCnSbpf1D4mKHbeHT jUzp3HxUQ2eTWAP+3NqoBSL37eK32OWNR3YiTncfje2NOnZHZukdZmakAj7QweFzLgs9 LfSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TIMiJJbEceqbsi0eZInm8W7y2HyIhMaKM98cY+BhLcU=; b=l2MUOvEvUV/N6V1W9z4u/qG8IvjQ/jDtSsR4ArcHV5O+o3BKoeCPC66XNmmigPlOly TAO0tjVPWp7phbbmIsZFFu3dKqvipc3a92Fm1HwhaQx/tfxxRLDeF6UuoQQX19gu/bAN jHwe1vCwB/zMN/3KgB+R5IswNLQkV5byNEARygFXx3TfUudm0snj0ZDocBeoDbCpFl5m blOMKMSnk2Bkm4/e3mhOQIyB2oc7yTvB6tlv06RmBjUThtrOvdzJWHiM5UOt62ZD6sQi sAH2tXCX53GSfMBjkVlmAIJiEo33S+vR1+h3muQJo9rvW7bwVSOS6p4taWgBFnZMUuLG TVYQ== X-Gm-Message-State: AKGB3mKwipnRxQ4rP1d5hn7w+EEy2gG0FyutAjhNlPxAZKdAxpYdasw6 rrzFKg19uvYwsXDtrB05v8vp1R1QqLG1e6hyDUQ= X-Google-Smtp-Source: ACJfBovw7K5lG+jBVjkzMaMIvWgYmFlDsceEPM9YEp8uCLvUFPCqtchb4xsdsQCfk8X8zoaTXwVUVsd7DhWqsF2nv7k= X-Received: by 10.28.232.148 with SMTP id f20mr731933wmi.147.1515107613520; Thu, 04 Jan 2018 15:13:33 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Thu, 4 Jan 2018 15:13:32 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Fri, 5 Jan 2018 00:13:32 +0100 X-Google-Sender-Auth: eNsIvzejQXL_7-qh-nHpEo9bl-0 Message-ID: To: Alvaro Retana Cc: rift@ietf.org, lsvr@ietf.org, "dcrouting@ietf.org" Content-Type: multipart/alternative; boundary="001a1147c49e19b7380561fb7bfa" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:13:38 -0000 --001a1147c49e19b7380561fb7bfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Happy New Year !!! > That was pretty much the question asked during the dcrouting BOF in Singapore. Well .. in Singapore and during most of list discussions dynamic flooding proposal was not on the table. Now it is. To me this is game changer and any conclusions reached previously IMHO should now be revisited. As far as outcome of the BOF - I am not sure how the conclusion was derived that we need new protocols - especially only those presented. In real practical cases a lot of DC clusters are build with at most few hundreds of L3 nodes which in all flavors of current link state implementations will work just fine as is. For MSDCs use of either eBGP or Open/R is deployed. Now dynamic flooding can extend link state to scale much larger. Personally IMHO this case is solved. Maybe time to move on to other areas ? :) Best, R. On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana wrote: > On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote= : > > Robert: > > Hi! Happy New Year! > > Do we really need yet one more new routing protocol vs relatively minor > extension of existing link state protocols ? > > > That was pretty much the question asked during the dcrouting BOF in > Singapore. Starting from the assumption that one size doesn=E2=80=99t fi= t all, the > room showed interest in working on solutions beyond the current work in > isis/ospf (which was also quickly reviewed there). > > To be clear, the intent of chartering rift doesn=E2=80=99t mean that work= in other > WGs (including new proposals) should stop. Quite the contrary, if there = is > sustained interest in this effort, then we will go on with it =E2=80=94 i= f there > isn=E2=80=99t (for whatever reason), then it will be clear as well. Note= that I > asked the proponents to constrain the proposed charter to work items that > should be able to be delivered within a short timeframe (around a year) = =E2=80=94 > so that we can reassess the interest, and re-charter if appropriate. > > The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2= =80=99m > cc=E2=80=99ing that list here to avoid repeating the discussion there. A= lso, I > noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80= =99ing that list as > well. > > Thanks! > > Alvaro. > --001a1147c49e19b7380561fb7bfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

=
Happy New Year !!!

> That was pretty much the question asked during the dcrouting = BOF in Singapore.=C2=A0

Well= .. in Singapore and during most of list discussions dynamic flooding propo= sal was not on the table. Now it is.=C2=A0
<= span style=3D"font-family:arial,sans-serif;font-size:12.8px">
To me this is game changer and any conclusions reached previously IMHO sho= uld now be revisited.=C2=A0

As far as ou= tcome of the BOF - I am not sure how the conclusion was derived that we nee= d new protocols - especially only those presented. In real practical cases = a lot of DC clusters are build with at most few hundreds of L3 nodes which = in all flavors=C2=A0of current link state implementations will work just fi= ne as is.=C2=A0

For MSDCs use of e= ither eBGP or Open/R is deployed.

Now dyna= mic flooding can extend link state to scale much larger.=C2=A0
=
Personally=C2=A0IMHO this case is solved. Maybe time to move o= n to other areas ? :)
<= span style=3D"font-size:12.8px">
Best,
R.


<= br>
On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retan= a <aretana.ietf@gmail.com> wrote:
On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote:

Robert:

Hi!= =C2=A0 Happy New Year!

D= o we really need yet one more new routing protocol vs relatively minor exte= nsion of existing link state protocols ?=C2=A0

That was pretty much t= he question asked during the dcrouting BOF in Singapore.=C2=A0 Starting fro= m the assumption that one size doesn=E2=80=99t fit all, the room showed int= erest in working on solutions beyond the current work in isis/ospf (which w= as also quickly reviewed there).

To be clear, the intent of chartering = rift doesn=E2=80=99t mean that work in other WGs (including new proposals) = should stop.=C2=A0 Quite the contrary, if there is sustained interest in th= is effort, then we will go on with it =E2=80=94 if there isn=E2=80=99t (for= whatever reason), then it will be clear as well.=C2=A0 Note that I asked t= he proponents to constrain the proposed charter to work items that should b= e able to be delivered within a short timeframe (around a year) =E2=80=94 s= o that we can reassess the interest, and re-charter if appropriate.

The a= bove obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2=80=99m c= c=E2=80=99ing that list here to avoid repeating the discussion there.=C2=A0= Also, I noticed you forwarded your message to dcrouting, so I=E2=80=99m cc= =E2=80=99ing that list as well.

Thanks!

Alvaro.

--001a1147c49e19b7380561fb7bfa-- From nobody Thu Jan 4 15:36:45 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E491127876; Thu, 4 Jan 2018 15:36:42 -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_PASS=-0.001, UNPARSEABLE_RELAY=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 h5t0_F0rhCvt; Thu, 4 Jan 2018 15:36:39 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91049127863; Thu, 4 Jan 2018 15:36:39 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id g59so2670093otg.11; Thu, 04 Jan 2018 15:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=VZyLhPQl9OMvHpsHmLbAogRpZEf6QtwXAYRe3BXYLvI=; b=KMTx4Zhj2V1HzM+z8zkOqPf02JN3ZhyemDTfQF2AokmSJ3D6rtgv0jDcmtd7ND3AQX ccU3IzQnK9kghRmaD+l246/mgzxtsJn2mTmL0wTY1YwkJnRVEYp26DBQLxG8YYILqmQU n07hY1oaZJ2lMTfoUdwKN6ti5jh8aXRvjLuuAgjSiEFY9lK2Zlg7B1s+vRoSUWfDTYsz 4bff/dh8MuIkTgILPPSDckgf6mObmUf8ZcMMJFtf1FOC4hi1GvospSYdwWDjlKiPaGJ7 F03Cb95m0qcCy27ubpB+mCcIDwLiN9OzVMFBPCf9wkREYWKgBOITIkQsVtQYQ7BlqhvI c2WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=VZyLhPQl9OMvHpsHmLbAogRpZEf6QtwXAYRe3BXYLvI=; b=dwzUhTCWW/Ue83n2dwgUVgrx2LoiyeVnmk3oFOoa1x+1oy/XUrjWH43W0bNpMhyFgd GAEUezK2z46FdRJx+kevAtlZAYcR/9fzKwj+h5dbEzW0b9WCJ5R9gFr2SZwQ/jDsA0Za ElfqfrX8mm5WSTcZD3hGhL+b1aBPgWzgszliGZ98MiSe8d5uk5n59n3Mhf1KQnJWpqRT UBS/sszQAE2M7DXbr8hW9h4gPpvlVjeqx1kWKb5MB53UvN4/qXIlVmd/DG6zPnzmKZBv Re2d6ZFc4r9U0dVTyKRdwTJWmWerT/i1/BndyGorAfhSENaZZ1+PWCFATmN2T5YObPDO CtDQ== X-Gm-Message-State: AKwxytdj/2MWtCCWiPkiJy3fTyNMxgPIQB0QkIhB+PCZNSrnMWfLvYxG 99o+jum2cQtT0+k72SEWLoRF5EvIgsbLvUirnQA= X-Google-Smtp-Source: ACJfBosT0rDxF7qpoheOgLy/B7Ib8gYYO0GNOD7UNTe1FNc4SXUUB8ehK74ndfwQ7rfQxcEL2ducUqf5ziBeiuLweIw= X-Received: by 10.157.63.136 with SMTP id r8mr855921otc.187.1515108998974; Thu, 04 Jan 2018 15:36:38 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 4 Jan 2018 15:36:38 -0800 From: Alvaro Retana In-Reply-To: References: X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Thu, 4 Jan 2018 15:36:38 -0800 Message-ID: To: Robert Raszuk Cc: "dcrouting@ietf.org" , lsvr@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="001a11c02924ae14570561fbcd63" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:36:42 -0000 --001a11c02924ae14570561fbcd63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert: As I said: if there=E2=80=99s no interest in a specific proposal it will th= en be clear from the list discussion and we=E2=80=99ll do the right thing. I really don=E2=80=99t want to make this a beauty contest =E2=80=94 there a= re multiple feasible solutions, some may be better than others. We can probably all argue in favor of our favorite solution/protocol/idea, but that won=E2=80= =99t move any of them forward. IOW, please focus on advancing what you think is worth advancing=E2=80=A6 Thanks! Alvaro. On January 5, 2018 at 7:13:34 AM, Robert Raszuk (robert@raszuk.net) wrote: Hi Alvaro, Happy New Year !!! > That was pretty much the question asked during the dcrouting BOF in Singapore. Well .. in Singapore and during most of list discussions dynamic flooding proposal was not on the table. Now it is. To me this is game changer and any conclusions reached previously IMHO should now be revisited. As far as outcome of the BOF - I am not sure how the conclusion was derived that we need new protocols - especially only those presented. In real practical cases a lot of DC clusters are build with at most few hundreds of L3 nodes which in all flavors of current link state implementations will work just fine as is. For MSDCs use of either eBGP or Open/R is deployed. Now dynamic flooding can extend link state to scale much larger. Personally IMHO this case is solved. Maybe time to move on to other areas ? :) Best, R. On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana wrote: > On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote= : > > Robert: > > Hi! Happy New Year! > > Do we really need yet one more new routing protocol vs relatively minor > extension of existing link state protocols ? > > > That was pretty much the question asked during the dcrouting BOF in > Singapore. Starting from the assumption that one size doesn=E2=80=99t fi= t all, the > room showed interest in working on solutions beyond the current work in > isis/ospf (which was also quickly reviewed there). > > To be clear, the intent of chartering rift doesn=E2=80=99t mean that work= in other > WGs (including new proposals) should stop. Quite the contrary, if there = is > sustained interest in this effort, then we will go on with it =E2=80=94 i= f there > isn=E2=80=99t (for whatever reason), then it will be clear as well. Note= that I > asked the proponents to constrain the proposed charter to work items that > should be able to be delivered within a short timeframe (around a year) = =E2=80=94 > so that we can reassess the interest, and re-charter if appropriate. > > The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2= =80=99m > cc=E2=80=99ing that list here to avoid repeating the discussion there. A= lso, I > noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80= =99ing that list as > well. > > Thanks! > > Alvaro. > --001a11c02924ae14570561fbcd63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Robert:

As I said: if there=E2=80=99s no interest in a specific prop= osal it will then be clear from the list discussion and we=E2=80=99ll do th= e right thing.
I real= ly don=E2=80=99t want to make this a beauty contest =E2=80=94 there are mul= tiple feasible solutions, some may be better than others.=C2=A0 We can prob= ably all argue in favor of our favorite solution/protocol/idea, but that wo= n=E2=80=99t move any of them forward.=C2=A0 IOW, please focus on advancing = what you think is worth advancing=E2=80=A6

Thanks!

Alvaro.

On January 5, 2018 at 7= :13:34 AM, Robert Raszuk (robert@raszu= k.net) wrote:

Hi Alvaro,

Happy New Year !!!

> That was pretty much the question asked during the dcrouting BOF in Singapore.=C2=A0
Well .. in Singapore and during most of list discussions dynamic flooding proposal was not on the table. Now it is.=C2=A0
To= me this is game changer and any conclusions reached previously IMHO should now be revisited.=C2=A0
As= far as outcome of the BOF - I am not sure how the conclusion was derived that we need new protocols - especially only those presented. In real practical cases a lot of DC clusters are build with at most few hundreds of L3 nodes which in all flavors=C2=A0of current link state implementations will work just fine as is.=C2=A0
For MSDCs use of either eBGP or Open/R is deployed.
No= w dynamic flooding can extend link state to scale much larger.=C2=A0
Pe= rsonally=C2=A0IMHO this case is solved. Maybe time to move on to other areas ? :)
Be= st,
R.=


On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana <aretana.ietf@gmail.com> wrote:
On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote:

Robert:

Hi!=C2=A0 Happy New Year!
Do we really need yet one more new routing protocol vs relatively minor extension of existing link state protocols ?=C2=A0

That was pretty much the question asked during the dcrouting BOF in Singapore.=C2=A0 Starting from the assumption that one size doesn=E2=80=99t fit all, the room showed interest in working on solutions beyond the current work in isis/ospf (which was also quickly reviewed there).

To be clear, the intent of chartering rift doesn=E2=80=99t mean that work in other WGs (including new proposals) should stop.=C2=A0 Quite the contrary, if there is sustained interest in this effort, then we will go on with it =E2=80=94 if there isn=E2=80=99t (for whatever reason), then it will be clear as well.=C2=A0 Note that I asked the proponents to constrain the proposed charter to work items that should be able to be delivered within a short timeframe (around a year) =E2=80=94 so that we can reassess the interest, and re-charter if appropriate.

The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2=80=99m cc=E2=80=99ing that list= here to avoid repeating the discussion there.=C2=A0 Also, I noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80=99ing that lis= t as well.

Thanks!

Alvaro.

--001a11c02924ae14570561fbcd63-- From nobody Thu Jan 4 15:43:55 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08975127863 for ; Thu, 4 Jan 2018 15:43:53 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.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 8BZwB-5P-taX for ; Thu, 4 Jan 2018 15:43:49 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4062E1275AB for ; Thu, 4 Jan 2018 15:43:49 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id q5so2689900oth.2 for ; Thu, 04 Jan 2018 15:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5uZqkmbAKtcxYzgCp7CqHjUEe+skkAFWcTPAUF8IsrU=; b=QHKjEJ7M1VtODJGMR1vf6iRi9YZFZYfxUt94dFoDDpu6tu7XH78u/GB+L/a69hXFpf ngFjbs8MUaQ+MdgtgNywxFQdByo67BY+KqzTAHbe1QXJ4HK8okGb92IAw4bb50pj4ZDi WKKNGu8ZSFMoM5U1sVa2+aMdjm9rgcMaHEn7fRWfjOYamjcx/xx/r09axevWHUZeg0Fv dx5GF4Ntmi0bm3lN4bFVt+iixIVotZnZQYaGsC5BwEqjSkXYcYdpQ2qPjI3x3yz906ir ca0A3I+HYengs+RASc+k3MUXJfy/Gj1+ilvtcFzdNNImLWFHmerhVj5OH87hiTKREdWt TJDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5uZqkmbAKtcxYzgCp7CqHjUEe+skkAFWcTPAUF8IsrU=; b=OzT9p0RoE4yKNNsygYJG6wJSQrnPKKoawwQQleMowIUoT0cQckpjVHFIoeaTWVlUd0 VzZ3vGsxnBlUhRFcQr5/r3rNQY0XZ+zQ8RkOR87KV09ULp6ZefGcCG3H0yI3LQbRNAWP ssAM1f2SVQv9YYGT8cWdMWDX+MrkNxrBlCslrVILTAtCF2KVO9QnhNlu7APBVE/Z6uaR tvjAsX0E4tC0U03nfVryDY0+m4A4idjvhePl0i4rwNqQFFB07Llc+nacr7jCQ3k/JhvP j/giUCee1LOChFhnSN83NP/QKOb7jmjyXHfBQqrkZIjISkk5WjGai77sodOkyoCLdczb 5GcA== X-Gm-Message-State: AKwxyteCHEMSp1xJGqUPD8CALOnGcJ0fb0CzVpAVP3CP+qEqtfVeDBPn FmsJccSTgv/Kn68RhG6UEin4ykR2govaBYhDgTQAQxJU X-Google-Smtp-Source: ACJfBos1Wc93420yZW2AQpRXu89Eukcj8oc6m26nhLywjWNG5CRrIPNdg8hLN8KcwXn5ItTz6Jh0VXkCi0pptLzj0no= X-Received: by 10.157.4.162 with SMTP id 31mr735044otm.98.1515109428393; Thu, 04 Jan 2018 15:43:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.60.173 with HTTP; Thu, 4 Jan 2018 15:43:47 -0800 (PST) In-Reply-To: References: From: Victor Kuarsingh Date: Thu, 4 Jan 2018 18:43:47 -0500 Message-ID: To: Robert Raszuk Cc: Alvaro Retana , "dcrouting@ietf.org" , lsvr@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="94eb2c09c31e468c780561fbe7e7" Archived-At: Subject: Re: [Rift] [Lsvr] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:43:53 -0000 --94eb2c09c31e468c780561fbe7e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert, On Thu, Jan 4, 2018 at 6:13 PM, Robert Raszuk wrote: > Hi Alvaro, > > > As far as outcome of the BOF - I am not sure how the conclusion was derived > that we need new protocols - especially only those presented. In real > practical cases a lot of DC clusters are build with at most few hundreds of > L3 nodes which in all flavors of current link state implementations will > work just fine as is. We attempted to structure the BoF to help understand a few things. This included audience input on whether there are new/augmented requirements within the DC and if there was agreement if that may drive us to new protocol work. Based on questions to the audience and feedback (show of of hands), it indicated that there was room for new protocol work (Notes/Minutes here - https://datatracker.ietf.org/doc/minutes-100-dcrouting/) As for BGPSPF (LSVR based solution) and RIFT, audience feedback also supported the notion that there are folks willing to work on such protocols= . > > For MSDCs use of either eBGP or Open/R is deployed. This may be generally true, and based largely on availability of options and protocols. If new options were available, it's hard to say this would still be the case. > > Now dynamic flooding can extend link state to scale much larger. > > Personally IMHO this case is solved. Maybe time to move on to other areas ? > :) I am not sure anything is ever finally solved. Continue refinement of designs and deployments are a norm in our industry as things change. We often make due with what we have and drive changes if possible and/or when needed. I would not want this to limit innovation. Recent example of a place where a new protocol is useful would be Babel. Once can argue that we should have solved similar cases with existing protocols, but that did not mean targeting the new uses cases with a new protocol did not make sense. Requirements continue to change, and we know things today we did not know years ago when we originally built OSPF, IS-IS, BGP etc. I think using empirical knowledge from real deployments to focus new work makes a lot of sense to me. There is likely room to continue iteration of existing protocols, and that may be just fine for many use cases. However, that should not limit us from developing new protocols which can solve new and emerging problems. regards, Victor K > > Best, > R. > > > > On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana > wrote: >> >> On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote: >> >> Robert: >> >> Hi! Happy New Year! >> >> Do we really need yet one more new routing protocol vs relatively minor >> extension of existing link state protocols ? >> >> >> That was pretty much the question asked during the dcrouting BOF in >> Singapore. Starting from the assumption that one size doesn=E2=80=99t f= it all, the >> room showed interest in working on solutions beyond the current work in >> isis/ospf (which was also quickly reviewed there). >> >> To be clear, the intent of chartering rift doesn=E2=80=99t mean that wor= k in other >> WGs (including new proposals) should stop. Quite the contrary, if there is >> sustained interest in this effort, then we will go on with it =E2=80=94 = if there >> isn=E2=80=99t (for whatever reason), then it will be clear as well. Not= e that I >> asked the proponents to constrain the proposed charter to work items tha= t >> should be able to be delivered within a short timeframe (around a year) =E2=80=94 so >> that we can reassess the interest, and re-charter if appropriate. >> >> The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2= =80=99m >> cc=E2=80=99ing that list here to avoid repeating the discussion there. = Also, I >> noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80= =99ing that list as >> well. >> >> Thanks! >> >> Alvaro. > > > > _______________________________________________ > Lsvr mailing list > Lsvr@ietf.org > https://www.ietf.org/mailman/listinfo/lsvr > --94eb2c09c31e468c780561fbe7e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Robert,

On Thu, Jan 4, 2018 at 6:13 PM, Robert Rasz= uk <robert@raszuk.net> wrote= :
> Hi Alvaro,
>
>
> As far as outcome of the BOF -= I am not sure how the conclusion was derived
> that we need new prot= ocols - especially only those presented. In real
> practical cases a = lot of DC clusters are build with at most few hundreds of
> L3 nodes = which in all flavors of current link state implementations will
> wor= k just fine as is.

We attempted to structure the BoF to help unders= tand a few things.=C2=A0 This included audience input on whether there are = new/augmented requirements within the DC and if there was agreement if that= may drive us to new protocol work.=C2=A0 Based on questions to the audienc= e and feedback (show of of hands), it indicated that there was room for new= protocol work (Notes/Minutes here - https://datatracker.ietf.org/doc/minutes-100-= dcrouting/)=C2=A0

As for BGPSPF (LSVR base= d solution) and RIFT, audience feedback also supported the notion that ther= e are folks willing to work on such protocols.

>
> For MSDC= s use of either eBGP or Open/R is deployed.

This m= ay be generally true, and based largely on availability of options and prot= ocols.=C2=A0 If new options were available, it's hard to say this would= still be the case.

>
> Now dynamic flooding can ext= end link state to scale much larger.
>
> Personally IMHO this c= ase is solved. Maybe time to move on to other areas ?
> :)
=
I am not sure anything is ever finally solved. Continue refi= nement of designs and deployments are a norm in our industry as things chan= ge.=C2=A0 We often make due with what we have and drive changes if possible= and/or when needed. I would not want this to limit innovation.=C2=A0 Recen= t example of a place where a new protocol is useful would be Babel.=C2=A0 O= nce can argue that we should have solved similar cases with existing protoc= ols, but that did not mean targeting the new uses cases with a new protocol= did not make sense.=C2=A0

Requirements continue t= o change, and we know things today we did not know years ago when we origin= ally built OSPF, IS-IS, BGP etc.=C2=A0 I think using empirical knowledge fr= om real deployments to focus new work makes a lot of sense to me.=C2=A0 The= re is likely room to continue iteration of existing protocols, and that may= be just fine for many use cases.=C2=A0 However, that should not limit us f= rom developing new protocols which can solve new and emerging problems.=C2= =A0

regards,

Victor K

>
> Best,
> R.
>
>
>
> On= Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana <aretana.ietf@gmail.com>
> wrote:
>>>> On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote:
>>
>>= Robert:
>>
>> Hi!=C2=A0 Happy New Year!
>>
&= gt;> Do we really need yet one more new routing protocol vs relatively m= inor
>> extension of existing link state protocols ?
>>>>
>> That was pretty much the question asked during the d= crouting BOF in
>> Singapore.=C2=A0 Starting from the assumption t= hat one size doesn=E2=80=99t fit all, the
>> room showed interest = in working on solutions beyond the current work in
>> isis/ospf (w= hich was also quickly reviewed there).
>>
>> To be clear,= the intent of chartering rift doesn=E2=80=99t mean that work in other
&= gt;> WGs (including new proposals) should stop.=C2=A0 Quite the contrary= , if there is
>> sustained interest in this effort, then we will g= o on with it =E2=80=94 if there
>> isn=E2=80=99t (for whatever rea= son), then it will be clear as well.=C2=A0 Note that I
>> asked th= e proponents to constrain the proposed charter to work items that
>&g= t; should be able to be delivered within a short timeframe (around a year) = =E2=80=94 so
>> that we can reassess the interest, and re-charter = if appropriate.
>>
>> The above obviously applies to the = lsvr (aka BGP-SPF) proposal, so I=E2=80=99m
>> cc=E2=80=99ing that= list here to avoid repeating the discussion there.=C2=A0 Also, I
>&g= t; noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80= =99ing that list as
>> well.
>>
>> Thanks!
&g= t;>
>> Alvaro.
>
>
>
> ________________= _______________________________
> Lsvr mailing list
> Lsvr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsvr<= /a>
>
--94eb2c09c31e468c780561fbe7e7-- From nobody Thu Jan 4 15:59:33 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC07B12741D; Thu, 4 Jan 2018 15:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xMPN4eD2aapr; Thu, 4 Jan 2018 15:59:26 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5EFF126CF9; Thu, 4 Jan 2018 15:59:25 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id t8so6372585wmc.3; Thu, 04 Jan 2018 15:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2RxeVdpq1Mpcl9/pHeL7AJFTqSpIw56qWobL6i3Vy0g=; b=Ca8Bs05L5XRi8ijbGHMhPHbVn2wb3OVYiyXa0arK+6mgadO1AKCkCKz7sjVAZL+5/V e+DfTeQLEx6IMSinsVkOWcGTQoSQhShI95JGM1Hqx/V1o/Cmk5yDR012iCE0kIqkjBxC UMpbrVUpQAk5iNxmMOdO89rY77l7AHRWNkWFG0/+7JSyzOOuKQIqpasr4HwShMi7mG71 eBQ2kWO4uAK927X5CCnFDxogrPJUTIOiY5XC3lYqImEMR2AKhXBByvngXJBQrEBGsLrH cKGlLQUOEJyeied1y4AsIoTgWT9OSH2c50q3Bwm8ckfmHJQCzI9oiz1RKL6+kMoyNv79 IYfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2RxeVdpq1Mpcl9/pHeL7AJFTqSpIw56qWobL6i3Vy0g=; b=VLguUpw1kW4uN3Z0UMnLgsJOZhUaH246AkKB/o1qxJV/rbxiYRmjFbCakRcxTSNicu Xa+Z7qwhTE2TOr4COjrwJkvOEFf/xNpGG9zh23wJ8LgOf2j4LJ5Gr+7WucvSKvU50/CU BAyzgl+aDt85rF21lGACFv8PZFlOoqsshHjVKR+jCMGwjiu0Kklq003uaXzhCCJoRGtI pH3QAcfOoo8Tox61Ou4F9gbvKURKXcaM1PLrDtndVCvarlBWP9P3D756oIKVhtisOzsR X63I/7G+G37CF7fslVogXmQ0Nvfc+zCGG8iXg57ccGdwQpcm4UZslkGNIytEruEt1fbu 4GgQ== X-Gm-Message-State: AKGB3mKoTBkPxoRp5Qvh/8bSyP1Rg0ZYMr/mgmZuHQQPOaEgQz3W+bJ6 93Q5PHj8AGIqYhYv38AYd3brvQUJWHWSN5xr2FQ= X-Google-Smtp-Source: ACJfBos0Y9zLAMN57BQ42U15PZUA8JkRvw9Sn8tqZ326Jth0e8t9pXLEb71LPNE1F4oUau5vCpouNsuL6Sgbp2n7iYY= X-Received: by 10.28.232.148 with SMTP id f20mr787488wmi.147.1515110364219; Thu, 04 Jan 2018 15:59:24 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Thu, 4 Jan 2018 15:59:23 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Fri, 5 Jan 2018 00:59:23 +0100 X-Google-Sender-Auth: PGues8NnjwmILipBvOv1dvuuoV4 Message-ID: To: Victor Kuarsingh Cc: Alvaro Retana , "dcrouting@ietf.org" , lsvr@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="001a1147c49e0e0d430561fc1f61" Archived-At: Subject: Re: [Rift] [Lsvr] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:59:28 -0000 --001a1147c49e0e0d430561fc1f61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Victor, =E2=80=8BWriting new draft is easy ... getting via IETF journey =E2=80=8Bwi= th it is a bit harder, but doable. And all of this is free of real cost. However to have multiple vendors putting development resources into multiple proposals, having army of ops folks to learn it, test it across vendors and to be able to deploy it is a huge industry cost. Sure we should and will continue to innovate - this is beyond any doubt. But the crux is to choose areas where we spend community time on. Rightly structured BOF should start with discussing the problems .. what is technically wrong with existing solutions ? - Is it redundant flooding in case of link state ? - Is it lack of auto-config in case of BGP ? Both have protocol solutions in the pipe. See when you allow multiple proposals to progress, each will be supported by given vendor. So likely you will get N solutions moving to IESG. Then what ? We will then have multiple new protocols for inter-domain routing ? And not so long ago folks complained that having two OSPF and ISIS is a bad thing ..... Best, R. On Fri, Jan 5, 2018 at 12:43 AM, Victor Kuarsingh wrote= : > Robert, > > On Thu, Jan 4, 2018 at 6:13 PM, Robert Raszuk wrote: > > Hi Alvaro, > > > > > > As far as outcome of the BOF - I am not sure how the conclusion was > derived > > that we need new protocols - especially only those presented. In real > > practical cases a lot of DC clusters are build with at most few hundred= s > of > > L3 nodes which in all flavors of current link state implementations wil= l > > work just fine as is. > > We attempted to structure the BoF to help understand a few things. This > included audience input on whether there are new/augmented requirements > within the DC and if there was agreement if that may drive us to new > protocol work. Based on questions to the audience and feedback (show of = of > hands), it indicated that there was room for new protocol work > (Notes/Minutes here - https://datatracker.ietf.org/ > doc/minutes-100-dcrouting/) > > As for BGPSPF (LSVR based solution) and RIFT, audience feedback also > supported the notion that there are folks willing to work on such protoco= ls. > > > > > For MSDCs use of either eBGP or Open/R is deployed. > > This may be generally true, and based largely on availability of options > and protocols. If new options were available, it's hard to say this woul= d > still be the case. > > > > > Now dynamic flooding can extend link state to scale much larger. > > > > Personally IMHO this case is solved. Maybe time to move on to other > areas ? > > :) > > I am not sure anything is ever finally solved. Continue refinement of > designs and deployments are a norm in our industry as things change. We > often make due with what we have and drive changes if possible and/or whe= n > needed. I would not want this to limit innovation. Recent example of a > place where a new protocol is useful would be Babel. Once can argue that > we should have solved similar cases with existing protocols, but that did > not mean targeting the new uses cases with a new protocol did not make > sense. > > Requirements continue to change, and we know things today we did not know > years ago when we originally built OSPF, IS-IS, BGP etc. I think using > empirical knowledge from real deployments to focus new work makes a lot o= f > sense to me. There is likely room to continue iteration of existing > protocols, and that may be just fine for many use cases. However, that > should not limit us from developing new protocols which can solve new and > emerging problems. > > regards, > > Victor K > > > > > Best, > > R. > > > > > > > > On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana > > wrote: > >> > >> On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) > wrote: > >> > >> Robert: > >> > >> Hi! Happy New Year! > >> > >> Do we really need yet one more new routing protocol vs relatively mino= r > >> extension of existing link state protocols ? > >> > >> > >> That was pretty much the question asked during the dcrouting BOF in > >> Singapore. Starting from the assumption that one size doesn=E2=80=99t= fit all, > the > >> room showed interest in working on solutions beyond the current work i= n > >> isis/ospf (which was also quickly reviewed there). > >> > >> To be clear, the intent of chartering rift doesn=E2=80=99t mean that w= ork in > other > >> WGs (including new proposals) should stop. Quite the contrary, if > there is > >> sustained interest in this effort, then we will go on with it =E2=80= =94 if there > >> isn=E2=80=99t (for whatever reason), then it will be clear as well. N= ote that I > >> asked the proponents to constrain the proposed charter to work items > that > >> should be able to be delivered within a short timeframe (around a year= ) > =E2=80=94 so > >> that we can reassess the interest, and re-charter if appropriate. > >> > >> The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I= =E2=80=99m > >> cc=E2=80=99ing that list here to avoid repeating the discussion there.= Also, I > >> noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2= =80=99ing that > list as > >> well. > >> > >> Thanks! > >> > >> Alvaro. > > > > > > > > _______________________________________________ > > Lsvr mailing list > > Lsvr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsvr > > > --001a1147c49e0e0d430561fc1f61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Victor,

=E2=80=8BWr= iting new draft is easy ... getting via IETF journey =E2=80=8Bwith it is a = bit harder, but doable. And all of this is free of real cost.=C2=A0

However to have multiple vend= ors putting development resources into multiple proposals, having army of o= ps folks to learn it, test it across vendors and to be able to deploy it is= a huge industry cost.=C2=A0

Sure we should and will continue to innovate - this is beyond any = doubt. But the crux is to choose areas where we spend community time on.=C2= =A0

Rightly structured= BOF should start with discussing the problems .. what is technically wrong= with existing solutions ?=C2=A0

- Is it redundant flooding in case of link state ?=C2=A0

- Is it lack of auto-config i= n case of BGP ?=C2=A0

= Both have protocol solutions in the pipe.=C2=A0

See when you allow multiple proposals to prog= ress, each will be supported by given vendor. So likely you will get N solu= tions moving to IESG. Then what ? We will then have multiple new protocols = for inter-domain routing ?=C2=A0

And not so long ago folks complained that having two OSPF and IS= IS is a bad thing .....=C2=A0

Best,
R.

<= /div>











On Fri, Jan 5, 2018 at = 12:43 AM, Victor Kuarsingh <victor@jvknet.com> wrote:
Robert,

On Thu, Jan 4, = 2018 at 6:13 PM, Robert Raszuk <robert@raszuk.net> wrote:
> Hi Alvaro,
>
>
> As far as outcome of the BOF - I am not su= re how the conclusion was derived
> that we need new protocols - espe= cially only those presented. In real
> practical cases a lot of DC cl= usters are build with at most few hundreds of
> L3 nodes which in all= flavors of current link state implementations will
> work just fine = as is.

We attempted to structure the BoF to help understand = a few things.=C2=A0 This included audience input on whether there are new/a= ugmented requirements within the DC and if there was agreement if that may = drive us to new protocol work.=C2=A0 Based on questions to the audience and= feedback (show of of hands), it indicated that there was room for new prot= ocol work (Notes/Minutes here - https://datatracker.ietf.org/doc/minutes-100-dcrouting/)=C2=A0

As for= BGPSPF (LSVR based solution) and RIFT, audience feedback also supported th= e notion that there are folks willing to work on such protocols.

>
> For MSDCs use of either eBGP or Open/R is deploy= ed.

This may be generally true, and based l= argely on availability of options and protocols.=C2=A0 If new options were = available, it's hard to say this would still be the case.

>
> Now dynamic flooding can extend link state t= o scale much larger.
>
> Personally IMHO this case is solved. M= aybe time to move on to other areas ?
> :)

I am not sure anything is ever finally solved. Continue refinement of= designs and deployments are a norm in our industry as things change.=C2=A0= We often make due with what we have and drive changes if possible and/or w= hen needed. I would not want this to limit innovation.=C2=A0 Recent example= of a place where a new protocol is useful would be Babel.=C2=A0 Once can a= rgue that we should have solved similar cases with existing protocols, but = that did not mean targeting the new uses cases with a new protocol did not = make sense.=C2=A0

Requirements continue to change,= and we know things today we did not know years ago when we originally buil= t OSPF, IS-IS, BGP etc.=C2=A0 I think using empirical knowledge from real d= eployments to focus new work makes a lot of sense to me.=C2=A0 There is lik= ely room to continue iteration of existing protocols, and that may be just = fine for many use cases.=C2=A0 However, that should not limit us from devel= oping new protocols which can solve new and emerging problems.=C2=A0
<= div>
regards,

Victor K

>
> Best,
> R.
>
>
&g= t;
> On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana <aretana.ietf@gmail.com&g= t;
> wrote:
>>
>> On January 5, 2018 at 5:48:23 AM,= Robert Raszuk (robe= rt@raszuk.net) wrote:
>>
>> Robert:
>>
&g= t;> Hi!=C2=A0 Happy New Year!
>>
>> Do we really need = yet one more new routing protocol vs relatively minor
>> extension= of existing link state protocols ?
>>
>>
>> Tha= t was pretty much the question asked during the dcrouting BOF in
>>= ; Singapore.=C2=A0 Starting from the assumption that one size doesn=E2=80= =99t fit all, the
>> room showed interest in working on solutions = beyond the current work in
>> isis/ospf (which was also quickly re= viewed there).
>>
>> To be clear, the intent of charterin= g rift doesn=E2=80=99t mean that work in other
>> WGs (including n= ew proposals) should stop.=C2=A0 Quite the contrary, if there is
>>= ; sustained interest in this effort, then we will go on with it =E2=80=94 i= f there
>> isn=E2=80=99t (for whatever reason), then it will be cl= ear as well.=C2=A0 Note that I
>> asked the proponents to constrai= n the proposed charter to work items that
>> should be able to be = delivered within a short timeframe (around a year) =E2=80=94 so
>>= that we can reassess the interest, and re-charter if appropriate.
>&= gt;
>> The above obviously applies to the lsvr (aka BGP-SPF) propo= sal, so I=E2=80=99m
>> cc=E2=80=99ing that list here to avoid repe= ating the discussion there.=C2=A0 Also, I
>> noticed you forwarded= your message to dcrouting, so I=E2=80=99m cc=E2=80=99ing that list as
&= gt;> well.
>>
>> Thanks!
>>
>> Alvar= o.
>
>
>
> ____________________________= ___________________
> Lsvr mailing list
> Lsvr@ietf.org
> https://www.ietf= .org/mailman/listinfo/lsvr
>

--001a1147c49e0e0d430561fc1f61-- From nobody Sat Jan 6 13:35:59 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D7312D574; Sat, 6 Jan 2018 13:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 NpG5EHTVq9xd; Sat, 6 Jan 2018 13:35:51 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8231201F2; Sat, 6 Jan 2018 13:35:51 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id m8so2421507lfc.6; Sat, 06 Jan 2018 13:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2NxtdpZBcGT6Xn6YYVE8gdQC13GgBaWJzEDAgsCmciw=; b=Ud/aErFP4S+z50hfFe6olc3SktwoeKc4pvoMfRlISaV45JtWfBlOaqPvO7/loLPWsJ jTrh6vZgxXa5SvA+2hPlj2kogtxuw9xhuxus3368eNHw6792rRC4Kl/rOM4C27tkmegT YPTKSgk9azaVcqZ5qcjeHIhuz5ALnyGPMjBFd8eFwHnQXxfw+5bjQ3VOqugKKDne7reT k9s2JTCvzcwfuszzw1VSJGl0OuVYwnpkJBrJ5YPZY4767nL9rITmESmD1dwTTWjpFWNh Wra0LqfQPzms5A5dTimekQmiF8Zv6XIlIqy5i+jmbgU4VFksEZfpiN0uo8jQeSG1CmfD SOxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2NxtdpZBcGT6Xn6YYVE8gdQC13GgBaWJzEDAgsCmciw=; b=JJPyUFW/kRcvfR49lGUAAvnoSkuTK1TwqhZOa2wRFYd0BOEICshVtMqq7+1nGsxt2P 9j/dbRAeZW7mfMb0usfEdTcYTBmKMBLwyrZbsI+zgogWZaCeSWnVrTk9P4aJut+/iQzz fM6+x20AFw2FeNOWoHTt4BsI42zx6pUJu2LHaF/eM3GFjPOXwTvf78YEpsZraSnppioo Js+NpzgNjtUn4iKKeAxZ6jg4xcsHLuHtnQmZpRjTtCD2NjCjyadY+GhgQo2pGYD3DIyS w31SdADXvdsn+Fhtpm3pnfBJdNbmIndAscglYr0F6TLFyVt0lrKXHZl3Iw1QBlvuThPC qOJw== X-Gm-Message-State: AKGB3mLvnQtdeP04SG+Y+L/6ZRT+lq1lVXkvh2iaMn/k2FtezrrdlBPg V4ndfyePC3F+d+chk4O+/3Y/SKobTFo4Z0vTTHU= X-Google-Smtp-Source: ACJfBovIU3xIVB4KiXKEJaj737KQwY6gTLG+66iDY64GiKOMjm1DXEfHM/9pjbD9AmAzmKx7OFxQLCbzXfokFKGGKJY= X-Received: by 10.46.87.12 with SMTP id l12mr3794356ljb.16.1515274549202; Sat, 06 Jan 2018 13:35:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.32.136 with HTTP; Sat, 6 Jan 2018 13:35:48 -0800 (PST) In-Reply-To: References: From: Greg Mirsky Date: Sat, 6 Jan 2018 13:35:48 -0800 Message-ID: To: Robert Raszuk , Petr Lapukhov Cc: Alvaro Retana , "dcrouting@ietf.org" , lsvr@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="f403045f8c563e153005622259d6" Archived-At: Subject: Re: [Rift] [Dcrouting] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 21:35:54 -0000 --f403045f8c563e153005622259d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Robert, I recall presentation by Petr Lapukhov on Open/R and Terragraph where the principle of optimized flooding was used. Of course, algorithms and mechanics of the Open/R in Terragraph may be different from those proposed in the draft An Architecture for Dynamic Flooding on Dense Graphs. I believe it will be very interesting and helpful to look at the proposed dynamic flooding from the point of experience of the Open/R and Terragraph. Regards, Greg On Thu, Jan 4, 2018 at 3:13 PM, Robert Raszuk wrote: > Hi Alvaro, > > Happy New Year !!! > > > That was pretty much the question asked during the dcrouting BOF in > Singapore. > > Well .. in Singapore and during most of list discussions dynamic flooding > proposal was not on the table. Now it is. > > To me this is game changer and any conclusions reached previously IMHO > should now be revisited. > > As far as outcome of the BOF - I am not sure how the conclusion was > derived that we need new protocols - especially only those presented. In > real practical cases a lot of DC clusters are build with at most few > hundreds of L3 nodes which in all flavors of current link state > implementations will work just fine as is. > > For MSDCs use of either eBGP or Open/R is deployed. > > Now dynamic flooding can extend link state to scale much larger. > > Personally IMHO this case is solved. Maybe time to move on to other areas > ? :) > > Best, > R. > > > > On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana > wrote: > >> On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) >> wrote: >> >> Robert: >> >> Hi! Happy New Year! >> >> Do we really need yet one more new routing protocol vs relatively minor >> extension of existing link state protocols ? >> >> >> That was pretty much the question asked during the dcrouting BOF in >> Singapore. Starting from the assumption that one size doesn=E2=80=99t f= it all, the >> room showed interest in working on solutions beyond the current work in >> isis/ospf (which was also quickly reviewed there). >> >> To be clear, the intent of chartering rift doesn=E2=80=99t mean that wor= k in >> other WGs (including new proposals) should stop. Quite the contrary, if >> there is sustained interest in this effort, then we will go on with it = =E2=80=94 if >> there isn=E2=80=99t (for whatever reason), then it will be clear as well= . Note >> that I asked the proponents to constrain the proposed charter to work it= ems >> that should be able to be delivered within a short timeframe (around a >> year) =E2=80=94 so that we can reassess the interest, and re-charter if = appropriate. >> >> The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2= =80=99m >> cc=E2=80=99ing that list here to avoid repeating the discussion there. = Also, I >> noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2=80= =99ing that list as >> well. >> >> Thanks! >> >> Alvaro. >> > > > _______________________________________________ > Dcrouting mailing list > Dcrouting@ietf.org > https://www.ietf.org/mailman/listinfo/dcrouting > > --f403045f8c563e153005622259d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Robert,
I recall presentation by Petr Lapukhov on O= pen/R and Terragraph where the principle of optimized flooding was used. Of= course, algorithms and mechanics of the Open/R in Terragraph may be differ= ent from those proposed in the= =C2=A0draft An Architecture for Dynamic Flooding on Dense Graphs. I believe= it will be very interesting and helpful to look at the proposed dynamic fl= ooding from the point of experience of the Open/R and Terragraph.

<= font face=3D"arial, helvetica, sans-serif">Regards,
Greg

On Thu, Jan 4, 2018 at 3:13 PM,= Robert Raszuk <robert@raszuk.net> wrote:
Hi Alvaro,

Happy New Year !!!

> That was pretty much the que= stion asked during the dcrouting BOF in Singapore.=C2=A0

Well .. in Singapore and during most of l= ist discussions dynamic flooding proposal was not on the table. Now it is.= =C2=A0

To me this is game changer and any conclusions= reached previously IMHO should now be revisited.=C2=A0
<= br>
As far as outcome of the BOF - I am not sure how the conclusion was deri= ved that we need new protocols - especially only those presented. In real p= ractical cases a lot of DC clusters are build with at most few hundreds of = L3 nodes which in all flavors=C2=A0of current link state implementations wi= ll work just fine as is.=C2=A0

F= or MSDCs use of either eBGP or Open/R is deployed.

=
= Now dynamic flooding can extend link state to scale much larger.=C2=A0

<= /span>
P= ersonally=C2=A0IMHO this case is solved. Maybe time to move on to other are= as ? :)

Best,
R.



On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana <aretana.= ietf@gmail.com> wrote:
On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote:<= /font>

=
Rob= ert:

Hi!=C2=A0 Happy New Year!

Do we really need yet one more new routi= ng protocol vs relatively minor extension of existing link state protocols = ?=C2=A0

That was = pretty much the question asked during the dcrouting BOF in Singapore.=C2=A0= Starting from the assumption that one size doesn=E2=80=99t fit all, the ro= om showed interest in working on solutions beyond the current work in isis/= ospf (which was also quickly reviewed there).

To be clear, the = intent of chartering rift doesn=E2=80=99t mean that work in other WGs (incl= uding new proposals) should stop.=C2=A0 Quite the contrary, if there is sus= tained interest in this effort, then we will go on with it =E2=80=94 if the= re isn=E2=80=99t (for whatever reason), then it will be clear as well.=C2= =A0 Note that I asked the proponents to constrain the proposed charter to w= ork items that should be able to be delivered within a short timeframe (aro= und a year) =E2=80=94 so that we can reassess the interest, and re-charter = if appropriate.

The above obviously applies to the lsvr (aka BGP= -SPF) proposal, so I=E2=80=99m cc=E2=80=99ing that list here to avoid repea= ting the discussion there.=C2=A0 Also, I noticed you forwarded your message= to dcrouting, so I=E2=80=99m cc=E2=80=99ing that list as well.

= Thanks!

Alvaro.


_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>


--f403045f8c563e153005622259d6-- From nobody Sat Jan 6 14:29:30 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7F3129C6D; Sat, 6 Jan 2018 14:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 skGzbyfPe8VH; Sat, 6 Jan 2018 14:29:26 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83461124BE8; Sat, 6 Jan 2018 14:29:25 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id w107so7336148wrb.9; Sat, 06 Jan 2018 14:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PeqwTLrXTtDdECnVY0MWKsEX7BLM7Y9VVc4WXbhGPcE=; b=KYKmgP8usk1yIkMcPxmUgmhHSSiC0VjKjMcKrVV/A+OlkOdAm6Hl1agzFhcpVUdYpY okSFnK+raGkooQ4dZR+ZTL6bUaWINNQ7y9jEuphyjCRpviEgFUAZ1rUpEw/4lkbqvFec 3NByEQjpvlqgZxJnarGmWSjQ/waCf5uC2Gxrl1gbSQ1gjeOE/RcfMuv2MNqvGlvjqQPL fslwnH27RCT/F0lJFfemJ9TeLL1ZVLLuCR56HSHzJSMLCRXM9IObSdc5As2dMerEjyOF Zi7XAQfkisxO2oR8fNcspTEgvMGjhP85RgHBaVRk5KCw/RlLevVRJERmYPfuoIX/uS5b ayqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PeqwTLrXTtDdECnVY0MWKsEX7BLM7Y9VVc4WXbhGPcE=; b=a9HlnhMq519f+KTMJEPrKsvyiNxxuQBPQqzzjcB5GtKIZtqC252Vd4s+m1vDrQRPT+ sqtUsfGYpOj+j6fNg6r1WCbpjl0iz5vUXKcRH+idrzNlm8dfPXTiYFxZPm+JendgScE3 6uMRhL77OhGhTtw/VKuseLWolbViufOP2dle+uCV+annxrTgRyR+5uybX6yuvAkqqU1J eSoHzNQVeX/xZeBBCK8/bP4Fk2sTKmulZdJ/PsP9UzOxBgxwEAz3+tREv8GEF03ZYDPs JumPKvRaLepxI6QbNv2r38+8d3WDQqjPGssl9KHPjj6CzgciLyCCZ/NOslJf0zV2Fq0q gJVQ== X-Gm-Message-State: AKGB3mKzdiuJ1jTMke6ozKDZWKfkgCAz53PM/tx34ct6qmIV0S2nWgV2 P4p55uAxkHxCASH4opJ8NSGBDrKT1xOMIJsJoBU= X-Google-Smtp-Source: ACJfBoss27ZAQdDWX75/qZ+h15LW8g0HWo9pbsOfKHYEuqMXRSs/TD7rcSpiI/SsxfLFs4D4WtfXVAIvWR9f+Q6B1TQ= X-Received: by 10.223.151.142 with SMTP id s14mr6035506wrb.256.1515277763660; Sat, 06 Jan 2018 14:29:23 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Sat, 6 Jan 2018 14:29:22 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Sat, 6 Jan 2018 23:29:22 +0100 X-Google-Sender-Auth: -DMn0K1U4vKtKrHfa4eYDTYFM_o Message-ID: To: Greg Mirsky Cc: Petr Lapukhov , Alvaro Retana , "dcrouting@ietf.org" , lsvr@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1b5622d6cfd405622318a7" Archived-At: Subject: Re: [Rift] [Dcrouting] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 22:29:29 -0000 --94eb2c1b5622d6cfd405622318a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, > I believe it will be very interesting and helpful to look at the proposed dynamic flooding from the point of experience of the Open/R and Terragraph. Honestly I don't think so. The reason is that what Tony Li proposed is an update to classic link state flooding. In fact he is reusing existing DR/DIS in his proposal. Open/R is using message bus for control plane transport which is a completely different paradigm. I am not making any judgement here which is better or worse scale or convergence wise. But at least to me there are apples and oranges and comparing or drawing any conclusion from the behavior of one to the other seems quite bizarre. Personally I like a lot Open/R real pub-sub model. We have been using BGP to propagate p2p messages within p2mp protocol for way too long now. That nonsense has to stop. RTC has been proposed for other reasons and is not the right way to filter BGP information to stretch it as p2p database distribution protocol. It would be very interesting to see proposals for BGP intra-domain transport using message bus. But for robust topology discovery, computing SPF, local protection with no constrains on network topology I guess I will still value link state for a while :). And as already stated for 95% of DCs where cluster size is up to 100 racks I think there is no issue to use currently shipping OSPF or ISIS. When you go beyond that (if you as an enterprise ever do) there is for more optimizations. But from my personal experience building huge flat DC clusters is only applicable to very few customers. Very frankly even issuing RFC describing use of BGP for DC fabric confused number of folks with 5-10 racks and made them to insist that only BGP will work and ISIS or OSPF is a very bad idea. Others for the very same reasons use BGP only deployments in campus networks. Let's be very careful what we consider as good IETF work items and what we define here as standard tracks documents as even if not intended they do have a ricochet effect. Best, Robert. On Sat, Jan 6, 2018 at 10:35 PM, Greg Mirsky wrote: > Hi Robert, > I recall presentation by Petr Lapukhov on Open/R and Terragraph where the > principle of optimized flooding was used. Of course, algorithms and > mechanics of the Open/R in Terragraph may be different from those propose= d > in the draft An Architecture for Dynamic Flooding on Dense Graphs. I > believe it will be very interesting and helpful to look at the proposed > dynamic flooding from the point of experience of the Open/R and Terragrap= h. > > Regards, > Greg > > On Thu, Jan 4, 2018 at 3:13 PM, Robert Raszuk wrote: > >> Hi Alvaro, >> >> Happy New Year !!! >> >> > That was pretty much the question asked during the dcrouting BOF in >> Singapore. >> >> Well .. in Singapore and during most of list discussions dynamic floodin= g >> proposal was not on the table. Now it is. >> >> To me this is game changer and any conclusions reached previously IMHO >> should now be revisited. >> >> As far as outcome of the BOF - I am not sure how the conclusion was >> derived that we need new protocols - especially only those presented. In >> real practical cases a lot of DC clusters are build with at most few >> hundreds of L3 nodes which in all flavors of current link state >> implementations will work just fine as is. >> >> For MSDCs use of either eBGP or Open/R is deployed. >> >> Now dynamic flooding can extend link state to scale much larger. >> >> Personally IMHO this case is solved. Maybe time to move on to other area= s >> ? :) >> >> Best, >> R. >> >> >> >> On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana >> wrote: >> >>> On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) >>> wrote: >>> >>> Robert: >>> >>> Hi! Happy New Year! >>> >>> Do we really need yet one more new routing protocol vs relatively minor >>> extension of existing link state protocols ? >>> >>> >>> That was pretty much the question asked during the dcrouting BOF in >>> Singapore. Starting from the assumption that one size doesn=E2=80=99t = fit all, the >>> room showed interest in working on solutions beyond the current work in >>> isis/ospf (which was also quickly reviewed there). >>> >>> To be clear, the intent of chartering rift doesn=E2=80=99t mean that wo= rk in >>> other WGs (including new proposals) should stop. Quite the contrary, i= f >>> there is sustained interest in this effort, then we will go on with it = =E2=80=94 if >>> there isn=E2=80=99t (for whatever reason), then it will be clear as wel= l. Note >>> that I asked the proponents to constrain the proposed charter to work i= tems >>> that should be able to be delivered within a short timeframe (around a >>> year) =E2=80=94 so that we can reassess the interest, and re-charter if= appropriate. >>> >>> The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I=E2= =80=99m >>> cc=E2=80=99ing that list here to avoid repeating the discussion there. = Also, I >>> noticed you forwarded your message to dcrouting, so I=E2=80=99m cc=E2= =80=99ing that list as >>> well. >>> >>> Thanks! >>> >>> Alvaro. >>> >> >> >> _______________________________________________ >> Dcrouting mailing list >> Dcrouting@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrouting >> >> > --94eb2c1b5622d6cfd405622318a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Greg,

> I believe it will = be very interesting and helpful to look at the proposed dynamic flooding fr= om the point of experience of the Open/R and Terragraph.

Honestly I don't think so.=C2=A0=

The reason is that wh= at Tony Li proposed is an update to classic link state flooding. In fact he= is reusing existing DR/DIS in his proposal.=C2=A0
=
Open/R is using message bus for control plane = transport which is a completely different paradigm.=C2=A0

I am not making any judgement here wh= ich is better or worse scale or convergence wise. But at least to me there = are apples and oranges and comparing or drawing any conclusion from the beh= avior of one to the other seems quite bizarre.=C2=A0

Personally I like a lot Open/R real pub-sub = model. We have been using BGP to propagate p2p messages within p2mp protoco= l for way too long now. That nonsense has to stop. RTC has been proposed fo= r other reasons and is not the right way to filter BGP information to stret= ch it as p2p database distribution protocol. It would be very interesting t= o see proposals for BGP intra-domain transport using message bus.=C2=A0

But for robust topology d= iscovery, computing SPF, local protection with no constrains on network top= ology I guess I will still value link state for a while :).=C2=A0=C2=A0

And as already stated for= 95% of DCs where cluster size is up to 100 racks I think there is no issue= to use currently shipping OSPF or ISIS. When you go beyond that (if you as= an enterprise ever do) there is for more optimizations. But from my person= al experience building huge flat DC clusters is only applicable to very few= customers.=C2=A0

Very= frankly even issuing RFC describing use of BGP for DC fabric confused numb= er of folks with 5-10 racks and made them to insist that only BGP will work= and ISIS or OSPF is a very bad idea. Others for the very same reasons use = BGP only deployments in campus networks.=C2=A0

=
Let's be very careful what we consider as good= IETF work items and what we define here as standard tracks documents as ev= en if not intended they do have a ricochet effect.=C2=A0

Best,
Robert= .


On Sat, Jan 6, 2018 at 10:35 PM= , Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Robert,
I= recall presentation by Petr Lapukhov on Open/R and Terragraph where the pr= inciple of optimized flooding was used. Of course, algorithms and mechanics= of the Open/R in Terragraph may be different from those proposed in the=C2=A0draft An Architecture for Dy= namic Flooding on Dense Graphs. I believe it will be very interesting and h= elpful to look at the proposed dynamic flooding from the point of experienc= e of the Open/R and Terragraph.

Regards,
Greg

On Thu, Jan 4, 2018 at 3:13 PM, Robe= rt Raszuk <robert@raszuk.net> wrote:
Hi Alvaro,

Happy New Year !!!

> That was pretty much the ques= tion asked during the dcrouting BOF in Singapore.=C2=A0

Well .. in Sing= apore and during most of list discussions dynamic flooding proposal was not= on the table. Now it is.=C2=A0

To me this is game changer and any conclusions reached previously IMH= O should now be revisited.=C2=A0

As far as outcome of the BOF - I am not sure how the conclusion was = derived that we need new protocols - especially only those presented. In re= al practical cases a lot of DC clusters are build with at most few hundreds= of L3 nodes which in all flavors=C2=A0of current link state implementation= s will work just fine as is.=C2=A0

For MSDCs use of either eBGP or Open/R is deplo= yed.
<= br>
Now dynamic flooding = can extend link state to scale much larger.=C2=A0

Personally=C2=A0IMHO this case is solved. Maybe time to move on to oth= er areas ? :)

=
Best,
R.


<= div class=3D"gmail-m_5204468319542514966h5">

=
On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana <= span dir=3D"ltr"><aretana.ietf@gmail.com> wrote:
On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net) wrote:

Robert:

Hi!=C2=A0 Happy New Year!
=
Do we really need yet one more new routing protocol v= s relatively minor extension of existing link state protocols ?=C2=A0

<= /div>
That was pr= etty much the question asked during the dcrouting BOF in Singapore.=C2=A0 S= tarting from the assumption that one size doesn=E2=80=99t fit all, the room= showed interest in working on solutions beyond the current work in isis/os= pf (which was also quickly reviewed there).

To be clear, the intent of chartering rift doesn=E2=80=99t mea= n that work in other WGs (including new proposals) should stop.=C2=A0 Quite= the contrary, if there is sustained interest in this effort, then we will = go on with it =E2=80=94 if there isn=E2=80=99t (for whatever reason), then = it will be clear as well.=C2=A0 Note that I asked the proponents to constra= in the proposed charter to work items that should be able to be delivered w= ithin a short timeframe (around a year) =E2=80=94 so that we can reassess t= he interest, and re-charter if appropriate.

The above obviously applies to the lsvr (aka BGP-SPF) proposal= , so I=E2=80=99m cc=E2=80=99ing that list here to avoid repeating the discu= ssion there.=C2=A0 Also, I noticed you forwarded your message to dcrouting,= so I=E2=80=99m cc=E2=80=99ing that list as well.

Thanks!

Alvaro.


________________________= _______________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>



--94eb2c1b5622d6cfd405622318a7-- From nobody Mon Jan 8 09:57:57 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069A3127909 for ; Mon, 8 Jan 2018 09:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 CAHulqIm27ak for ; Mon, 8 Jan 2018 09:57:53 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BEB712711D for ; Mon, 8 Jan 2018 09:57:52 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id t8so15715324wmc.3 for ; Mon, 08 Jan 2018 09:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ql6jhr1n6l/jEGqbWJ2/lp/PR4LZmv+3vuBeyI1JHiw=; b=N55dRXooXAJtx/nD4SQeznCg81sReEttOHf3NeSpTZcvRpInD4ZrCT2ZjXcBhpzJXs vfEF14lReBxvA5AKAkVhhuyvDolhN97AW4cCFtNZwwMBK3zax6QvhlwUHFfktDuWqw6d vpLN5Jgc3qKTcz82VX7lPK30QZMpaRGPznc4C3HkiDrtqZDddFQgRGdDMzTwksL4sXtj A9h5jGY1dnYqLbZwRVsDsn9QCPzPf0/rp7FC0AO8HDhE/Y43WI4MzNxOyNJHynokmXn/ vtpcbSrRTadwtYJKjvIlyfuY578ibfvDDG9Ai4qFDZbDdUZgC1CBNbKGUaqLgmGZC5X1 yU9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ql6jhr1n6l/jEGqbWJ2/lp/PR4LZmv+3vuBeyI1JHiw=; b=EkqY4atdNCWNG5TZQMJ0y/jAbN69PBXul94A8mWXH4h3lo+M0V+MYdHq4kpZPQdXNw HhLqP/HUZYfW32teQS50HmyDjCjw4qqD8Pi6tsEKJI/FUgbQGzzausWN1TxjqSkngmSG dtfZSnyzLX7m+/c6x8c1ZMaE6TCjc+sTJ1UPNfA9ZZz/7lZ8g3nM9JCLHrXAEzje14jb Nq863xXPbWYMU8nfyzryIaZI9L5MwKha/xvWfU2kOokNFL0265AehbuK2ioV3/y/5Zop uob/ZB6DJ0jvDKTj6wR68bxzg4aQ+cZ0L9cXX6XYtIV8COfSN7yg5VldmSisEyA8l6nO NKtA== X-Gm-Message-State: AKGB3mIaa4XMK6olWRZ9sLr65C6AYtJD1oNBM+OY4H24tV6H8vxBmsve XGaTk2nlMNpg1cXbQBA3L9cdfiiH20BYmgr5B4A= X-Google-Smtp-Source: ACJfBovmOtePUwPD2t65Zoj8wi3oTMkkCjEOFEbiIaQtfKt1YWhogFR8P5CoDmn7ojDUzaUOLtAPrHwwd2X7tGx0FNo= X-Received: by 10.80.206.67 with SMTP id k3mr17869612edj.153.1515434270990; Mon, 08 Jan 2018 09:57:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Mon, 8 Jan 2018 09:57:10 -0800 (PST) In-Reply-To: <1CC03D9B-091B-4870-A66C-84D110BC09F7@gmail.com> References: <1CC03D9B-091B-4870-A66C-84D110BC09F7@gmail.com> From: Tony Przygienda Date: Mon, 8 Jan 2018 09:57:10 -0800 Message-ID: To: Fred Baker Cc: Alia Atlas , rift@ietf.org Content-Type: multipart/alternative; boundary="f403045dbf00672a9e056247895a" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 17:57:56 -0000 --f403045dbf00672a9e056247895a Content-Type: text/plain; charset="UTF-8" Fred, RIFT running code is steadily evolving and has been played with. And it could be interop'ed ;-) Having said that, if there is interest from other parties in building an openly available simulation/code/environment I'm perfectly happy to give people cycles explaining/exchanging experiences and ideas. One of the reasons we held back in documenting the FSMs is that it would be great to have implementations inter'op'ing a bit and shaking out unclear/flaky pieces before concrete is poured. And having more people to pour concrete into the draft would be welcome of course from available cycles perspective as well. thanks --- tony On Thu, Jan 4, 2018 at 11:24 AM, Fred Baker wrote: > Question: > > Do we have a simulation that can be exercised in virtual routing > environments? If I were a data center operator, I might want to compare and > contrast with my current routing approach, both to identify possible issues > and to qualify the protocol for use in my operation. > > > On Jan 4, 2018, at 11:03 AM, Alia Atlas wrote: > > > > Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG > charters with Alvaro. Here is what we have so far. Comments and > improvements would be most welcome. > > > > ================ > > Routing in Fat Trees (RIFT) > > > > Clos and Fat-Tree topologies have gained prominence in data center > networks as a result of a trend towards centralized data center network > architectures that may deliver computation and storage services. > > > > The Routing in Fat Trees (RIFT) protocol addresses the demands of > routing in Clos and Fat-Tree networks via a mixture of both link-state and > distance-vector techniques colloquially described as 'link-state towards > the spine and distance vector towards the leafs'. RIFT uses this hybrid > approach to focus on networks with regular topologies with a high degree of > connectivity, a defined directionality, and large scale. > > > > The RIFT Working Group will work on a standards track specification of a > specialized, dynamic routing protocol for Clos and fat-tree network > topologies. The protocol will: > > > > - deal with automatic construction of fat-tree topologies based on > detection of links, > > - minimize the amount of routing state held at each topology level, > > - automatically prune topology distribution exchanges to a sufficient > subset of links, > > - support automatic disaggregation of prefixes on link and node failures > to prevent black-holing and suboptimal routing, > > - allow traffic steering and re-routing policies, > > - and provide mechanisms to synchronize a limited key-value data-store > that can be used after protocol convergence. > > > > It is important that nodes participating in the protocol should need > only very light configuration and should be able to join a network as leaf > nodes simply by connecting to the network using default configuration. > > > > The protocol must support IPv6 and should also support IPv4. > > > > The Working Group may establish additional requirements to constrain and > inform their work. > > > > The RIFT Working Group is chartered for the following list of items: > > > > - A Standards Track specification based on draft-przygienda-rift. The > document will include: > > > > - an Implementation Status section as described in RFC 7942 > > - an Operational Considerations section to explain how the protocol is > configured, deployed, and diagnosed > > - Security and Privacy Considerations, although this material may > refer to a separate Threat Analysis document (q.v.). > > - A YANG module focused on configuration of protocol instances > > - An Applicability Statement that describes how to deploy and > configure the protocol in networks with different topologies > > - A Security Threat Analysis document that describes the attack > vectors and mitigations that shall be sent for publication at the same time > as the protocol specification. > > > > Milestones > > > > Feb 2018 Adopt a protocol specification document > > Feb 2019 Submit protocol specification to IESG for publication > > Feb 2019 Submit Threat Analysis to IESG for publication > > Apr 2019 Submit YANG module to IESG for publication > > Apr 2019 Submit Applicability Statement to IESG for publication > > ============ > > > > Thanks, > > > > Alia > > > > _______________________________________________ > > Rift mailing list > > Rift@ietf.org > > https://www.ietf.org/mailman/listinfo/rift > > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift > > --f403045dbf00672a9e056247895a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fred, RIFT running code is steadily evolvin= g and has been played with. And it could be interop'ed ;-)

Having said that, if there is interest from other parties in building an = openly available simulation/code/environment I'm perfectly happy to giv= e people cycles explaining/exchanging experiences and ideas. One of the rea= sons we held back in documenting the FSMs is that it would be great to have= implementations inter'op'ing a bit and shaking out unclear/flaky p= ieces before concrete is poured.=C2=A0 And having more people to pour concr= ete into the draft would be welcome of course from available cycles perspec= tive as well.

thanks

--- tony
=C2=A0

On Thu, Jan 4,= 2018 at 11:24 AM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
Question:

Do we have a simulation that can be exercised in virtual routing environmen= ts? If I were a data center operator, I might want to compare and contrast = with my current routing approach, both to identify possible issues and to q= ualify the protocol for use in my operation.

> On Jan 4, 2018, at 11:03 AM, Alia Atlas <akatlas@gmail.com> wrote:
>
> Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT = WG charters with Alvaro.=C2=A0 Here is what we have so far.=C2=A0 Comments = and improvements would be most welcome.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Routing in Fat Trees (RIFT)
>
> Clos and Fat-Tree topologies have gained prominence in data center net= works as a result of a trend towards centralized data center network archit= ectures that may deliver computation and storage services.
>
> The Routing in Fat Trees (RIFT) protocol addresses the demands of rout= ing in Clos and Fat-Tree networks via a mixture of both link-state and dist= ance-vector techniques colloquially described as 'link-state towards th= e spine and distance vector towards the leafs'.=C2=A0 RIFT uses this hy= brid approach to focus on networks with regular topologies with a high degr= ee of connectivity, a defined directionality, and large scale.
>
> The RIFT Working Group will work on a standards track specification of= a specialized, dynamic routing protocol for Clos and fat-tree network topo= logies. The protocol will:
>
> - deal with automatic construction of fat-tree topologies based on det= ection of links,
> - minimize the amount of routing state held at each topology level, > - automatically prune topology distribution exchanges to a sufficient = subset of links,
> - support automatic disaggregation of prefixes on link and node failur= es to prevent black-holing and suboptimal routing,
> - allow traffic steering and re-routing policies,
> - and provide mechanisms to synchronize a limited key-value data-store= that can be used after protocol convergence.
>
> It is important that nodes participating in the protocol should need o= nly very light configuration and should be able to join a network as leaf n= odes simply by connecting to the network using default configuration.
>
> The protocol must support IPv6 and should also support IPv4.
>
> The Working Group may establish additional requirements to constrain a= nd inform their work.
>
> The RIFT Working Group is chartered for the following list of items: >
> - A Standards Track specification based on draft-przygienda-rift. The = document will include:
>
>=C2=A0 =C2=A0- an Implementation Status section as described in RFC 794= 2
>=C2=A0 =C2=A0- an Operational Considerations section to explain how the= protocol is configured, deployed, and diagnosed
>=C2=A0 =C2=A0- Security and Privacy Considerations, although this mater= ial may refer to a separate Threat Analysis document (q.v.).
>=C2=A0 =C2=A0- A YANG module focused on configuration of protocol insta= nces
>=C2=A0 =C2=A0- An Applicability Statement that describes how to deploy = and configure the protocol in networks with different topologies
>=C2=A0 =C2=A0- A Security Threat Analysis document that describes the a= ttack vectors and mitigations that shall be sent for publication at the sam= e time as the protocol specification.
>
> Milestones
>
>=C2=A0 =C2=A0Feb 2018 Adopt a protocol specification document
>=C2=A0 =C2=A0Feb 2019 Submit protocol specification to IESG for publica= tion
>=C2=A0 =C2=A0Feb 2019 Submit Threat Analysis to IESG for publication >=C2=A0 =C2=A0Apr 2019 Submit YANG module to IESG for publication
>=C2=A0 =C2=A0Apr 2019 Submit Applicability Statement to IESG for public= ation
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Thanks,
>
> Alia
>
> _______________________________________________
> Rift mailing list
> Rift@ietf.org
> https://www.ietf.org/mailman/listinfo/rift

_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift


--f403045dbf00672a9e056247895a-- From nobody Thu Jan 11 01:30:24 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD4512EAD2; Thu, 11 Jan 2018 01:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 lkVx0_wrXYd6; Thu, 11 Jan 2018 01:30:08 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B1912EAC4; Thu, 11 Jan 2018 01:30:02 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id f8so1559890wre.4; Thu, 11 Jan 2018 01:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=kh8T7brrv/cjhjR3OTaVmYAvcRZYJ+BCUuJ8lf9m7ps=; b=lzdbeFPNe0CGQSHrqbDeVhv7OV3PbN+iIYIzgMBBq0SZue6/+eWy/GACahvDIgFQu2 rAv2rKJGQp0l0PYAsy/SzRc0HO7nqpxQq7p1nEUBn2bTl+75fGbl4qpyIUpj9Natgdma sh1llgUskEJtelne6QdzqAd8O+arehmoB2wYZPm7gVNwUIumbFcaKDP665oW929sZ8eN Qc9bH0pSibr3Iuyf2S+ZSQAkXDT/S1vAqE7MfpP+fdbCe++Tir8hzO9oRVRvMQLKQE02 Y/IwyPuGXpxX7LeVUeK8h1YCsavehDvBpRWmLkW++S9dbBQg69nt2uc1ZJ57PmfjFEmH wSgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=kh8T7brrv/cjhjR3OTaVmYAvcRZYJ+BCUuJ8lf9m7ps=; b=igaBGZttTe1RW8hDBkQzQmwP48DgNHFVNKo4Udu2OKDQWbHHfeJbHGMRVW1fwftZCx HTQgZLPUZNL2ou71kq49pZMOGKR6+0bXp7GJp1qDqYcZY0WGB+I7lrqC5i/DBW/c63mt f37NZHqaKVOUg0Q29PPaVq5up2JVQH3+WyOLDMh9Ze1qRczgMAOTXOjxnkFCuIweXmgI gFcVQpkybSsGRxFCviaXi68VFFagp4wFzKcphvNDyhDo635mIk+i/HbUY+DyrJr4M67Q OviW9LqzmhKmiA/3InIHMdesc1cIAtxwJtpFKIa0x9dqBraeo3bHNBXXvN5aULwNzOvS zmbQ== X-Gm-Message-State: AKGB3mIS5vWi8b4EuljH9cFfSyn2yjgCbT4g+U3KW48Jzt7OZO20KE1S 9J0EffnjSoD5vttGpxd86sEXOWsM+YU0vseFhycBPA== X-Google-Smtp-Source: ACJfBouGfOqpROp74qVWV2bAPOh1k9+n/jJnzJbnwG8gHj3iTZTMXxEPccQQ3ct2PCtfRTj9wyF90HY7n4f5VyTHuew= X-Received: by 10.223.162.138 with SMTP id s10mr18444858wra.239.1515663000744; Thu, 11 Jan 2018 01:30:00 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Thu, 11 Jan 2018 01:30:00 -0800 (PST) From: Robert Raszuk Date: Thu, 11 Jan 2018 10:30:00 +0100 X-Google-Sender-Auth: J8FHB4iM-Aawfk291TNE-C289v0 Message-ID: To: rift@ietf.org Cc: spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045e97f8c2381405627cca15" Archived-At: Subject: [Rift] draft-przygienda-rift-03 X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 09:30:10 -0000 --f403045e97f8c2381405627cca15 Content-Type: text/plain; charset="UTF-8" Hi, I have one little question/doubt on scalability point of RIFT ... Assume that someone would like to signal IPv6 prefix SID for Segment Routing in the underlay within RIFT. Wouldn't it result in amount of protocol state in full analogy to massive deaggregation - which as of today is designed to be very careful and limited operation only at moments of failure(s) ? I sort of find it a bit surprising that RIFT draft does not provide encoding for SID distribution when it is positioned as an alternative to other protocols (IGPs or BGP) which already provide ability to carry all types of SIDs. Cheers, Robert. PS1: Horizontal links which were discussed could be installed to offload from fabric transit massive amount of data (ex: storage mirroring) directly between leafs or L3 TORs and not to be treated as "backup". PS2: Restricting any protocol to specific topologies seems like pretty slippery slope to me. In any case if protocol does that it should also contain self detection mechanism of "unsupported topology" and flash red light in any NOC. --f403045e97f8c2381405627cca15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">I have one little question/doubt on scalability point of = RIFT ...=C2=A0

Assume = that someone would like to signal IPv6 prefix SID for Segment Routing in th= e underlay within RIFT.=C2=A0

Wouldn't it result in amount of protocol state in full analogy= to massive deaggregation - which as of today is designed to be very carefu= l and limited operation only at moments of failure(s) ?=C2=A0

I sort of find it a bit surprising = that RIFT draft does not provide encoding for SID distribution when it is p= ositioned as an alternative to other protocols (IGPs or BGP) which already = provide ability to carry all types of SIDs.=C2=A0
<= br>
Cheers,
Robert.

=
PS1: Horizontal links which were discussed could b= e installed to offload from fabric transit massive amount of data (ex: stor= age mirroring) directly between leafs or L3 TORs and not to be treated as &= quot;backup".=C2=A0

PS2: Restricting any protocol to specific topologies seems like pretty s= lippery slope to me. In any case if protocol does that it should also conta= in self detection mechanism of "unsupported topology" and flash r= ed light in any NOC.=C2=A0


--f403045e97f8c2381405627cca15-- From nobody Thu Jan 11 09:40:52 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3117A12D87A; Thu, 11 Jan 2018 09:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Yy0zFXMceXHE; Thu, 11 Jan 2018 09:40:47 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 D54EB12AF6E; Thu, 11 Jan 2018 09:40:46 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id g75so7192334wme.0; Thu, 11 Jan 2018 09:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=28LzpsAOotuG0kTesPyhckSUU7GjJaKZZTZr25OZ7Tg=; b=Kw5diFxbvFji8IgBYw826CWHCjtbP96aYs8CbS1/JyvEmCwfmDFf9BQemp5mcS107L hr4N2V8/IKTvPT1QoudwpMDGdVWEIVaav9bwSDKpeb0mXhDPGBU6fXeFdgbfAGd+i4QD EfWutEW92RR0o9iXBqaqc0lW8MyfVP4BMinovVMXWJv6K2hiaemFz/OZAwcZFaOMAqRW +By8fDok4BfHJ90XKp3N4ymo3aaI9CU/rqi9Y+XvIvDXcFy/smNNInn+f+/LI4OiIGfx BcRNRsDGat45w0VQK1TrQLdrh19YUdmpM+Xclz/j8Q7f91Y8xyKjIrMz5elvORs9qWOZ 7Sgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=28LzpsAOotuG0kTesPyhckSUU7GjJaKZZTZr25OZ7Tg=; b=fNe7RfolSDlRAAMWmZBiBg2WklZ1J7DRnqzI7rQpjlwdYIaOvKnM3lt+Qv/SBsMYuJ OlfdjlUoT/fahGK/s9D8pF/kgx2CdXiMUEHTwJG43BEuBbrZiYYiVCpR+KAOiVF5QkR+ 14IgSpQSMaiXPNGXw/esj0WyB1CYNZjmDGwRWhW6Wn4fi/EmTcaOPjlEkqeG5f6Gael2 jsOZtLurYqBSqTVaZBahMTdxAUn22dXvrXlMzT7b6DpPfQNLh2E12CrRy0yANRKLJYPI Vn5+5WNOzLgRsygly59ntTxLytRgAOPWlLbtnGOnAqKimyLizeB8xJpZPLbd+2t3clMq +JNg== X-Gm-Message-State: AKwxytet5jgPEkXfMU4oX1ivB70D5TIStn+7L8BCkwPYddQGCJLsoBny lP1cuZF6GohgkUW+Y39mMsJLttDolmILwJiFYcJ1JxLg X-Google-Smtp-Source: ACJfBovE+dv/dnxi+8dmmt3c/ip9MbCW3y43Z8k3L5C2aLetXu8D6giGDE0CiOCwP5PW8PuvFn5TXMVgvoTQ6fOcVL8= X-Received: by 10.80.153.139 with SMTP id m11mr13471418edb.145.1515692445175; Thu, 11 Jan 2018 09:40:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 11 Jan 2018 09:40:04 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 11 Jan 2018 09:40:04 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0ec4fac89593056283a558" Archived-At: Subject: Re: [Rift] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 17:40:50 -0000 --94eb2c0ec4fac89593056283a558 Content-Type: text/plain; charset="UTF-8" Robert, productive points, thanks for raising them ... I go a bit in depth 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you run RIFT). The only one that comes up regularly is egress engineering and that IMO is equivalent to SID=leaf address (which could be a HV address of course once you have RIFT all way down to server) so really, what's the point to have a SID? It's probably much smarter to use IBGP & so on overlay to do this kind of synchronization if needed since labels/SIDs become very useful in overlay to distinguish lots stuff there like VPNs/services which you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 address. Having said that, discussion always to be had if you pay me dinner ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but again, no _real_ use case so far. And if your only concern is to "shape towards a prefix" we have PGP in the draft which doesn't need new silicon ;-P And then ultimately, yes, if you really, really want a SID per prefix everywhere then you'll carry SIDs to everywhere since unicast SIDs are really just a glorified way to say "I have this non-aggreagable 20 bit IP host address" which architecturally is a very interesting proposition in terms of scaling (but then again, no account for taste and RFC1925 clause 3 applies) ... Your LSDB will be still much smaller, your SPF will be still simple on leaf in RIFT but your FIB will blow up and anything changing on a leaf shakes all other leafs (unless you start to run pollicies to control distribution @ which point in time you start to baby-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you will observe that RIFT can do anycast without need for ECMP, i.e. true anycast in a sense and with that having anycast SID serves no real purpose in RIFT and is actually generally much harder to do since you need globally unique label blocks and so on ... 2. Horizontal links on CLOSes are not used that way normally all I saw since your blocking goes to hell unless you provision some kind of really massive parallel links between ToRs _and_ understand your load. We _could_ build RIFT that way but you give up balancing through the fabric and loop-free property in a sense (that's a longish discussion and scaling since now you have prefixes showing up all kind of crazy places instead of default). I see enough demand, we get there ... Otherwise RFC1925 clause 10 and 5. 3. PS1: Yes, lots of things "could" be done and then we "could" build a protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal links, unless provisioned correctly will pretty much just ruin your blocking/loss on the fabric is the experience (which the math supports). In a sense if you know your big flows you can build a specialized topology to do the optimal distribution (MPLS tunnels anyone ;-) but the point of fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a good analogy would be that you like to build special RAM chips for the type of data structures you are storing and we know how well that scales over time. We know now that within 3-4 years characteristics of DC flows flip upside down without a sweat when people go from server/client to microservices, from servers to containers and so on and so on. So if you can't predict your load all the time you need a _regular_ topology where _regular_ is more of a mathematical than a protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and just stick them in" applies here. So RIFT is done largely to serve a well-known structure called a "lattice" (with some restrictions) since we need an "up" and "down". Things like hypercubes, thoroidal meshes and so on and so on exist but CLOS won for a very good reason in history for that kind of problems (once you move to NUMA other things win ;-) And if you know your loads and your can heft the OPEX and you like to play with protocols generally and if you can support the scale in terms of leaf FIB sizes, flooding, slower convergence & so on & so on and you run flat IGP on some kind of stuff that you build that doesn't even have to be regular in any sense. We spent many years solving THAT problem obviously and doing something like RIFT to replace normal IGP is of limited interest IMO (albeit certain aspects having to do with modern implemenation techniques may get us there one day but it's much less of pressing problem than solving specialized DC routing well IMO again). 3. PS2: RIFT cannot build an "unsupported topology" no matter how you cable (that's the point of it) or rather we have miscabling detection and do not form adjacencies when you read the draft carefully. That's your "flash red light" and it comes included for free with my compliments ;-) ... Otherwise RFC1925 clause 10. Otherwise, if you have concrete charter points you'd like to add, be more specific in your asks and we see what the list thinks after ... thanks --- tony On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: > Hi, > > I have one little question/doubt on scalability point of RIFT ... > > Assume that someone would like to signal IPv6 prefix SID for Segment > Routing in the underlay within RIFT. > > Wouldn't it result in amount of protocol state in full analogy to massive > deaggregation - which as of today is designed to be very careful and > limited operation only at moments of failure(s) ? > > I sort of find it a bit surprising that RIFT draft does not provide > encoding for SID distribution when it is positioned as an alternative to > other protocols (IGPs or BGP) which already provide ability to carry all > types of SIDs. > > Cheers, > Robert. > > PS1: Horizontal links which were discussed could be installed to offload > from fabric transit massive amount of data (ex: storage mirroring) directly > between leafs or L3 TORs and not to be treated as "backup". > > PS2: Restricting any protocol to specific topologies seems like pretty > slippery slope to me. In any case if protocol does that it should also > contain self detection mechanism of "unsupported topology" and flash red > light in any NOC. > > > > _______________________________________________ > Dcrouting mailing list > Dcrouting@ietf.org > https://www.ietf.org/mailman/listinfo/dcrouting > > --94eb2c0ec4fac89593056283a558 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Robert, productive points, thanks for raisi= ng them ... I go a bit in depth

1. I saw no _r= eal_ use-cases for SID in DC so far to be frank (once you run RIFT). The on= ly one that comes up regularly is egress engineering and that IMO is equiva= lent to SID=3Dleaf address (which could be a HV address of course once you = have RIFT all way down to server) so really, what's the point to have a= SID? It's probably much smarter to use IBGP & so on overlay to do = this kind of synchronization if needed since labels/SIDs become very useful= in overlay to distinguish lots stuff there like VPNs/services which you= 9;d carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 addr= ess. Having said that, discussion always to be had if you pay me dinner ;--= ) and I know _how_ we can do SIDs in RIFT since I thought it through but ag= ain, no _real_ use case so far. And if your only concern is to "shape = towards a prefix" we have PGP in the draft which doesn't need new = silicon ;-P And then ultimately, yes, if you really, really want a SID per = prefix everywhere then you'll carry=C2=A0 SIDs to everywhere since unic= ast SIDs are really just a glorified way to say "I have this non-aggre= agable 20 bit IP host address" which architecturally is a very interes= ting proposition in terms of scaling (but then again, no account for taste = and RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be still much smalle= r, your SPF will be still simple on leaf in RIFT but your FIB will blow up = and anything changing on a leaf shakes all other leafs (unless you start to= run pollicies to control distribution @ which point in time you start to b= aby-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID w= ould be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you read= RIFT draft carefully you will observe that RIFT can do anycast without nee= d for ECMP, i.e. true anycast in a sense and with that having anycast SID s= erves no real purpose in RIFT and is actually generally much harder to do s= ince you need globally unique label blocks and so on ...=C2=A0

2. Horizontal links on CLOSes are not used that way normally all I saw si= nce your blocking goes to hell unless you provision some kind of really mas= sive parallel links between ToRs _and_ understand your load. We _could_ bui= ld RIFT that way but you give up balancing through the fabric and loop-free= property in a sense (that's a longish discussion=C2=A0 and scaling sin= ce now you have prefixes showing up all kind of crazy places instead of def= ault). I see enough demand, we get there ...=C2=A0 Otherwise RFC1925 clause= 10 and 5.=C2=A0

3. PS1: Yes, lots of things &quo= t;could" be done and then we "could" build a protocol to do = that and RFC1925 clause 7 and 8 applies. Such horizontal links, unless prov= isioned correctly will pretty much just ruin your blocking/loss on the fabr= ic is the experience (which the math supports). In a sense if you know your= big flows you can build a specialized topology to do the optimal distribut= ion (MPLS tunnels anyone ;-) but the point of fabric is that it's a fab= ric (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a g= ood analogy would be that you like to build special RAM chips for the type = of data structures you are storing and we know how well that scales over ti= me. We know now that within 3-4 years characteristics of DC flows flip upsi= de down without a sweat when people go from server/client to microservices,= from servers to containers and so on and so on. So if you can't predic= t your load all the time you need a _regular_ topology where _regular_ is m= ore of a mathematical than a protocol discussion. Fabric analogy of "b= uy more RAM chips in Fry's and just stick them in" applies here. S= o RIFT is done largely to serve a well-known structure called a "latti= ce" (with some restrictions) since we need an "up" and "= ;down". Things like hypercubes, thoroidal meshes and so on and so on e= xist but CLOS won for a very good reason in history for that kind of proble= ms (once you move to NUMA other things win ;-) And if you know your loads a= nd your can heft the OPEX and you like to play with protocols generally and= if you can support the scale in terms of leaf FIB sizes, flooding, slower = convergence & so on & so on and you run flat IGP on some kind of st= uff that you build that doesn't even have to be regular in any sense. W= e spent many years solving THAT problem obviously and doing something like = RIFT to replace normal IGP is of limited interest IMO (albeit certain aspec= ts having to do with modern implemenation techniques may get us there one d= ay but it's much less of pressing problem than solving specialized DC r= outing well IMO again).

3. PS2: RIFT cannot build = an "unsupported topology" no matter how you cable (that's the= point of it) or rather we have miscabling detection and do not form adjace= ncies when you read the draft carefully. That's your "flash red li= ght" and it comes included for free with my compliments=C2=A0 ;-) ... = Otherwise RFC1925 clause 10.

Otherwise, if you have concrete = charter points you'd like to add, be more specific in your asks and we = see what the list thinks after ...

thanks

--- tony


On Thu, Jan 11, 2018 at 1:30 AM, Robe= rt Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little question/doubt on scalabi= lity point of RIFT ...=C2=A0

Assume that someone would like to signal = IPv6 prefix SID for Segment Routing in the underlay within RIFT.=C2=A0

=
Wouldn't it result in amount of protocol state in full analogy to mass= ive deaggregation - which as of today is designed to be very careful and li= mited operation only at moments of failure(s) ?=C2=A0

I sort of find = it a bit surprising that RIFT draft does not provide encoding for SID distr= ibution when it is positioned as an alternative to other protocols (IGPs or= BGP) which already provide ability to carry all types of SIDs.=C2=A0
=

<= /div>
= Cheers,
Robert.

PS1: Horizontal links which were discussed could be= installed to offload from fabric transit massive amount of data (ex: stora= ge mirroring) directly between leafs or L3 TORs and not to be treated as &q= uot;backup".=C2=A0

PS2: Restricting any protocol to specific topo= logies seems like pretty slippery slope to me. In any case if protocol does= that it should also contain self detection mechanism of "unsupported = topology" and flash red light in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>


--94eb2c0ec4fac89593056283a558-- From nobody Thu Jan 11 10:14:31 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C25212EC15; Thu, 11 Jan 2018 10:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 YOjNLfWGTShX; Thu, 11 Jan 2018 10:14:20 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B0D12EC19; Thu, 11 Jan 2018 10:14:20 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id g75so7377242wme.0; Thu, 11 Jan 2018 10:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UOdvwV2owj7LKJBCFUvzKuKbXklYBo2Tzi7cUB4ECRc=; b=IqXKUsHqGuE4APKsrKWL75XfXOBM2HR0zMqlYPlkiEr6TWFHeobqKTlJjeAG3ccE34 +L8onjMjMPPBXMWMdaxTZm4VZT+Y5l+NtV6h+w7zAg5QRtyx9RWJGQ4/mNHg1ixdm6KG gg7XhbAFl7hxaoY37DYa0Ou0DoIlO8A7fSKPzH2w69SxYjG++QxtNas/BYvHtmfrECWq qQOKJQn8Zxf+RfssAYJdYm6BWpek1Ea0RHYMYbVpZ4sHr0zCG3O0yLW65Skh5H7sR5AJ 8alFYYqovEKgfe+Y3VVoeQz3ksiY99WNHoZaNlOtCt6pHQj0J96DA29X2rajM2Vp5s2i OO3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UOdvwV2owj7LKJBCFUvzKuKbXklYBo2Tzi7cUB4ECRc=; b=SfIWI/8q38NpgdJKtLcrC3K0dVC09fOOez7zoAvxri0QDKTQGtyfgwwyzMLu5ThE1d jb+ERAlzmRU6ND9//z6jBNOFIUjpMw7dNJmCzEVjKWvYqlWxXGGaKSBKXnDRxNayYXT2 WbZ/qnqL+VCxJ8ic0mMuMDkNe6hM2LZBOBdrHC3igFv8PFKMKlbI95xZmyYhIr8s76UV erxxj48EximU8nkuBDCTJU/NKSWmE5PQ4Kteq/v5XVXPNM77ELwga+DFQ7VGJfV5SWBu BhSAyd5XStXk+q1FPN8cM+m0i5rdMjDb5fHRlvp9SwFbZS85uWWaaRhn/joaG26iNaji eNJQ== X-Gm-Message-State: AKGB3mLVKL6wQHc0WI1ee5Wm5GLbgPzq6n5RmD2xCVhkh/a96rJCF8nS LPllMHMDJmMzZJKieNK6dVWiBrw3o+b94TzeT0M= X-Google-Smtp-Source: ACJfBotIWCTtPLGvxSlzSPCOI090iis+G8Mp0Q1o6YOCSclT1TkiPamjc1ZPveo8AKu14+yM/XDB+0zjSUjjrpzLsgM= X-Received: by 10.80.155.89 with SMTP id a25mr32109737edj.290.1515694459077; Thu, 11 Jan 2018 10:14:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 11 Jan 2018 10:13:38 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 11 Jan 2018 10:13:38 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1aec78d2475b0562841d15" Archived-At: Subject: Re: [Rift] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 18:14:24 -0000 --94eb2c1aec78d2475b0562841d15 Content-Type: text/plain; charset="UTF-8" Having said that there are interesting use cases we talk of "some binding per node" but that's more of a KV store corner where people think it's very useful to have the spines pushing stuff down to all nodes or (at cost of stability) having a node push some stuff up that gets pushed down to all other nodes. That's more of a "per leaf node" information case and pretty good unless leafs go crazy doing dynamic re-assignment (but we can dampen that in spines @ every level if needed) but it's not _per prefix_ which you seemed to ask about .... --- tony On Thu, Jan 11, 2018 at 9:40 AM, Tony Przygienda wrote: > Robert, productive points, thanks for raising them ... I go a bit in depth > > 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you > run RIFT). The only one that comes up regularly is egress engineering and > that IMO is equivalent to SID=leaf address (which could be a HV address of > course once you have RIFT all way down to server) so really, what's the > point to have a SID? It's probably much smarter to use IBGP & so on overlay > to do this kind of synchronization if needed since labels/SIDs become very > useful in overlay to distinguish lots stuff there like VPNs/services which > you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 > address. Having said that, discussion always to be had if you pay me dinner > ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but > again, no _real_ use case so far. And if your only concern is to "shape > towards a prefix" we have PGP in the draft which doesn't need new silicon > ;-P And then ultimately, yes, if you really, really want a SID per prefix > everywhere then you'll carry SIDs to everywhere since unicast SIDs are > really just a glorified way to say "I have this non-aggreagable 20 bit IP > host address" which architecturally is a very interesting proposition in > terms of scaling (but then again, no account for taste and RFC1925 clause 3 > applies) ... Your LSDB will be still much smaller, your SPF will be still > simple on leaf in RIFT but your FIB will blow up and anything changing on a > leaf shakes all other leafs (unless you start to run pollicies to control > distribution @ which point in time you start to baby-sit your fabric @ high > OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast > (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you > will observe that RIFT can do anycast without need for ECMP, i.e. true > anycast in a sense and with that having anycast SID serves no real purpose > in RIFT and is actually generally much harder to do since you need globally > unique label blocks and so on ... > > 2. Horizontal links on CLOSes are not used that way normally all I saw > since your blocking goes to hell unless you provision some kind of really > massive parallel links between ToRs _and_ understand your load. We _could_ > build RIFT that way but you give up balancing through the fabric and > loop-free property in a sense (that's a longish discussion and scaling > since now you have prefixes showing up all kind of crazy places instead of > default). I see enough demand, we get there ... Otherwise RFC1925 clause > 10 and 5. > > 3. PS1: Yes, lots of things "could" be done and then we "could" build a > protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal > links, unless provisioned correctly will pretty much just ruin your > blocking/loss on the fabric is the experience (which the math supports). In > a sense if you know your big flows you can build a specialized topology to > do the optimal distribution (MPLS tunnels anyone ;-) but the point of > fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily > scalable). Otherwise a good analogy would be that you like to build special > RAM chips for the type of data structures you are storing and we know how > well that scales over time. We know now that within 3-4 years > characteristics of DC flows flip upside down without a sweat when people go > from server/client to microservices, from servers to containers and so on > and so on. So if you can't predict your load all the time you need a > _regular_ topology where _regular_ is more of a mathematical than a > protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and > just stick them in" applies here. So RIFT is done largely to serve a > well-known structure called a "lattice" (with some restrictions) since we > need an "up" and "down". Things like hypercubes, thoroidal meshes and so on > and so on exist but CLOS won for a very good reason in history for that > kind of problems (once you move to NUMA other things win ;-) And if you > know your loads and your can heft the OPEX and you like to play with > protocols generally and if you can support the scale in terms of leaf FIB > sizes, flooding, slower convergence & so on & so on and you run flat IGP on > some kind of stuff that you build that doesn't even have to be regular in > any sense. We spent many years solving THAT problem obviously and doing > something like RIFT to replace normal IGP is of limited interest IMO > (albeit certain aspects having to do with modern implemenation techniques > may get us there one day but it's much less of pressing problem than > solving specialized DC routing well IMO again). > > 3. PS2: RIFT cannot build an "unsupported topology" no matter how you > cable (that's the point of it) or rather we have miscabling detection and > do not form adjacencies when you read the draft carefully. That's your > "flash red light" and it comes included for free with my compliments ;-) > ... Otherwise RFC1925 clause 10. > > Otherwise, if you have concrete charter points you'd like to add, be more > specific in your asks and we see what the list thinks after ... > > thanks > > --- tony > > > On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: > >> Hi, >> >> I have one little question/doubt on scalability point of RIFT ... >> >> Assume that someone would like to signal IPv6 prefix SID for Segment >> Routing in the underlay within RIFT. >> >> Wouldn't it result in amount of protocol state in full analogy to massive >> deaggregation - which as of today is designed to be very careful and >> limited operation only at moments of failure(s) ? >> >> I sort of find it a bit surprising that RIFT draft does not provide >> encoding for SID distribution when it is positioned as an alternative to >> other protocols (IGPs or BGP) which already provide ability to carry all >> types of SIDs. >> >> Cheers, >> Robert. >> >> PS1: Horizontal links which were discussed could be installed to offload >> from fabric transit massive amount of data (ex: storage mirroring) directly >> between leafs or L3 TORs and not to be treated as "backup". >> >> PS2: Restricting any protocol to specific topologies seems like pretty >> slippery slope to me. In any case if protocol does that it should also >> contain self detection mechanism of "unsupported topology" and flash red >> light in any NOC. >> >> >> >> _______________________________________________ >> Dcrouting mailing list >> Dcrouting@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrouting >> >> > --94eb2c1aec78d2475b0562841d15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Having said that there are interesting use cases we t= alk of "some binding per node" but that's more of a KV store = corner where people think it's very useful to have the spines pushing s= tuff down to all nodes or (at cost of stability) having a node push some st= uff up that gets pushed down to all other nodes. That's more of a "= ;per leaf node" information case and pretty good unless leafs go crazy= doing dynamic re-assignment (but we can dampen that in spines @ every leve= l if needed) but it's not _per prefix_ which you seemed to ask about ..= ..

--- tony

On Thu, Jan 11, 2018 at 9:40 AM, Tony Przygienda <ton= ysietf@gmail.com> wrote:
Robert, productive points, thanks for raising= them ... I go a bit in depth

1. I saw no _rea= l_ use-cases for SID in DC so far to be frank (once you run RIFT). The only= one that comes up regularly is egress engineering and that IMO is equivale= nt to SID=3Dleaf address (which could be a HV address of course once you ha= ve RIFT all way down to server) so really, what's the point to have a S= ID? It's probably much smarter to use IBGP & so on overlay to do th= is kind of synchronization if needed since labels/SIDs become very useful i= n overlay to distinguish lots stuff there like VPNs/services which you'= d carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 addres= s. Having said that, discussion always to be had if you pay me dinner ;--) = and I know _how_ we can do SIDs in RIFT since I thought it through but agai= n, no _real_ use case so far. And if your only concern is to "shape to= wards a prefix" we have PGP in the draft which doesn't need new si= licon ;-P And then ultimately, yes, if you really, really want a SID per pr= efix everywhere then you'll carry=C2=A0 SIDs to everywhere since unicas= t SIDs are really just a glorified way to say "I have this non-aggreag= able 20 bit IP host address" which architecturally is a very interesti= ng proposition in terms of scaling (but then again, no account for taste an= d RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be still much smaller,= your SPF will be still simple on leaf in RIFT but your FIB will blow up an= d anything changing on a leaf shakes all other leafs (unless you start to r= un pollicies to control distribution @ which point in time you start to bab= y-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID wou= ld be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you read R= IFT draft carefully you will observe that RIFT can do anycast without need = for ECMP, i.e. true anycast in a sense and with that having anycast SID ser= ves no real purpose in RIFT and is actually generally much harder to do sin= ce you need globally unique label blocks and so on ...=C2=A0

= 2. Horizontal links on CLOSes are not used that way normally all I saw sinc= e your blocking goes to hell unless you provision some kind of really massi= ve parallel links between ToRs _and_ understand your load. We _could_ build= RIFT that way but you give up balancing through the fabric and loop-free p= roperty in a sense (that's a longish discussion=C2=A0 and scaling since= now you have prefixes showing up all kind of crazy places instead of defau= lt). I see enough demand, we get there ...=C2=A0 Otherwise RFC1925 clause 1= 0 and 5.=C2=A0

3. PS1: Yes, lots of things "= could" be done and then we "could" build a protocol to do th= at and RFC1925 clause 7 and 8 applies. Such horizontal links, unless provis= ioned correctly will pretty much just ruin your blocking/loss on the fabric= is the experience (which the math supports). In a sense if you know your b= ig flows you can build a specialized topology to do the optimal distributio= n (MPLS tunnels anyone ;-) but the point of fabric is that it's a fabri= c (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a goo= d analogy would be that you like to build special RAM chips for the type of= data structures you are storing and we know how well that scales over time= . We know now that within 3-4 years characteristics of DC flows flip upside= down without a sweat when people go from server/client to microservices, f= rom servers to containers and so on and so on. So if you can't predict = your load all the time you need a _regular_ topology where _regular_ is mor= e of a mathematical than a protocol discussion. Fabric analogy of "buy= more RAM chips in Fry's and just stick them in" applies here. So = RIFT is done largely to serve a well-known structure called a "lattice= " (with some restrictions) since we need an "up" and "d= own". Things like hypercubes, thoroidal meshes and so on and so on exi= st but CLOS won for a very good reason in history for that kind of problems= (once you move to NUMA other things win ;-) And if you know your loads and= your can heft the OPEX and you like to play with protocols generally and i= f you can support the scale in terms of leaf FIB sizes, flooding, slower co= nvergence & so on & so on and you run flat IGP on some kind of stuf= f that you build that doesn't even have to be regular in any sense. We = spent many years solving THAT problem obviously and doing something like RI= FT to replace normal IGP is of limited interest IMO (albeit certain aspects= having to do with modern implemenation techniques may get us there one day= but it's much less of pressing problem than solving specialized DC rou= ting well IMO again).

3. PS2: RIFT cannot build an= "unsupported topology" no matter how you cable (that's the p= oint of it) or rather we have miscabling detection and do not form adjacenc= ies when you read the draft carefully. That's your "flash red ligh= t" and it comes included for free with my compliments=C2=A0 ;-) ... Ot= herwise RFC1925 clause 10.

Otherwise, if you have concrete ch= arter points you'd like to add, be more specific in your asks and we se= e what the list thinks after ...

thanks
<= div>
--- tony


On Thu, Jan 11, = 2018 at 1:30 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little question/doubt on scalability point of RIFT = ...=C2=A0

Assume that someone would like to signal IPv6 prefix SID for= Segment Routing in the underlay within RIFT.=C2=A0

Wouldn't it re= sult in amount of protocol state in full analogy to massive deaggregation -= which as of today is designed to be very careful and limited operation onl= y at moments of failure(s) ?=C2=A0

I sort of find it a bit surprising = that RIFT draft does not provide encoding for SID distribution when it is p= ositioned as an alternative to other protocols (IGPs or BGP) which already = provide ability to carry all types of SIDs.=C2=A0

Cheers,
Robert.
<= br>
PS1: Horizontal links which were discussed could be installed to offloa= d from fabric transit massive amount of data (ex: storage mirroring) direct= ly between leafs or L3 TORs and not to be treated as "backup".=C2= =A0

PS2: Restricting any protocol to specific topologies seems like pr= etty slippery slope to me. In any case if protocol does that it should also= contain self detection mechanism of "unsupported topology" and f= lash red light in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>



--94eb2c1aec78d2475b0562841d15-- From nobody Thu Jan 11 10:54:18 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C181512EC34; Thu, 11 Jan 2018 10:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 zX0ITynZDL13; Thu, 11 Jan 2018 10:54:11 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB0212EC28; Thu, 11 Jan 2018 10:54:10 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id w50so3140129wrc.11; Thu, 11 Jan 2018 10:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XBsVJdwaPGx2Oe8DF2MuJoBW8K3GxaHJzU3Al3NBB+U=; b=Nt7rkPYr7f6vk4HjRj7UDA2KSVB0pEVn7NTdeuqVeKDjktCYqjWWSx1Il38FJ+jwSO UyFwFFGTnaZ/ZPUlCkPJ9KK62oo/gPKcqlJIcLMFIe3C8BJkoTXKuY486u4DsvmDeT8P pOQzAA3HUmko8J+TEBFy7lJ3yGh1Y+ZtwOaCAm9iJgvJqDKyY3UfKV/ldMYNDjH/C/PK n90Wiy3e2T7xO1udpNfRKzQtb95xc17hoL7sOHvmipsb+c8K2DBPAvzB45ogguMix50L SmYqZ0+LHcYKV6PbPmn+AWLSLXdpWp4u1O5sUFB3pyy6ffxu+r6+eJMaV07Gp7u+i4wU xKaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XBsVJdwaPGx2Oe8DF2MuJoBW8K3GxaHJzU3Al3NBB+U=; b=QzhyCYOdXWzumINHBMmuCisWDebI7BUNP0oHE7vbCtDHXbUmMCzqxxFXOZ58ueTzmL pbzva8xkVq1qfuO1O7t3u5GiPHEM4ZUTZ/iQdMoSnG37olajd8CZEQ7S5eGHyrOghwkf NckhMlrEB2fFlZXH6kVsXYTfyeii8A9IPjwIsu+sEAShA1ZY4uMemaj9HQfjhLf20VyG xPxMmYEzYQcXUe88OFTlQIn3Jj1wbJzEuE1MUyO3XzyAvBw88G3kH7XUVJLWn4f1ONpd 9X9G1ti0rsExftbIdLM9O9Givc63L2/KncL1E5FaoGVPL4uLLpw1tIoIVHNZjp+SjS+B OMhA== X-Gm-Message-State: AKGB3mIEXzjbpAchfFgyScXzCZ68e1L07Wd747tLA7+nXXxTvlNKmlBy hKu5ArOOparWWwLNCkrgn437OG5mXok6UsW6hnY= X-Google-Smtp-Source: ACJfBotWZ+6WURyNM6XicTV2WRXclCfOF6oQ4Mr+UIAmsuvJYxRfW/bOXoLrErmMb+VVDL2OOubqjQL4N/y/JiVWcYE= X-Received: by 10.223.162.138 with SMTP id s10mr19970405wra.239.1515696848935; Thu, 11 Jan 2018 10:54:08 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Thu, 11 Jan 2018 10:54:07 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Thu, 11 Jan 2018 19:54:07 +0100 X-Google-Sender-Auth: 6e6RpwM60kiISNZLH8BBjo12tnQ Message-ID: To: Tony Przygienda Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045e97f844a0bc056284ac2a" Archived-At: Subject: Re: [Rift] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 18:54:14 -0000 --f403045e97f844a0bc056284ac2a Content-Type: text/plain; charset="UTF-8" Hi Tony, Thx for elaborating ... Two small comments: A) SID/SR use case in underlay could be as simple as gracefully taking a fabric node out of service. Not much OPEX needed if your NMS is decent. Otherwise in normal link state I can do overload bit, in BGP number of solutions from shutdown to MED to LP ... depending what is your BGP design. In RIFT how do you do that ? Note that overlay (if such exist) does not help here. B) For horizontal links imagine you have servers with 40 GB ports to TOR. Then you have Nx100 GB from TOR up. You are going to oversubscribe on TOR (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to interconnect TORs because I do know that servers behind those TORs need to talk to each other in a non blocking fashion _and_ I have spare 100 GB ports on TORs having routing protocol which does not allow me to do that seems pretty limited - wouldn't you agree ? Thx, R. On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda wrote: > Robert, productive points, thanks for raising them ... I go a bit in depth > > 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you > run RIFT). The only one that comes up regularly is egress engineering and > that IMO is equivalent to SID=leaf address (which could be a HV address of > course once you have RIFT all way down to server) so really, what's the > point to have a SID? It's probably much smarter to use IBGP & so on overlay > to do this kind of synchronization if needed since labels/SIDs become very > useful in overlay to distinguish lots stuff there like VPNs/services which > you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 > address. Having said that, discussion always to be had if you pay me dinner > ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but > again, no _real_ use case so far. And if your only concern is to "shape > towards a prefix" we have PGP in the draft which doesn't need new silicon > ;-P And then ultimately, yes, if you really, really want a SID per prefix > everywhere then you'll carry SIDs to everywhere since unicast SIDs are > really just a glorified way to say "I have this non-aggreagable 20 bit IP > host address" which architecturally is a very interesting proposition in > terms of scaling (but then again, no account for taste and RFC1925 clause 3 > applies) ... Your LSDB will be still much smaller, your SPF will be still > simple on leaf in RIFT but your FIB will blow up and anything changing on a > leaf shakes all other leafs (unless you start to run pollicies to control > distribution @ which point in time you start to baby-sit your fabric @ high > OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast > (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you > will observe that RIFT can do anycast without need for ECMP, i.e. true > anycast in a sense and with that having anycast SID serves no real purpose > in RIFT and is actually generally much harder to do since you need globally > unique label blocks and so on ... > > 2. Horizontal links on CLOSes are not used that way normally all I saw > since your blocking goes to hell unless you provision some kind of really > massive parallel links between ToRs _and_ understand your load. We _could_ > build RIFT that way but you give up balancing through the fabric and > loop-free property in a sense (that's a longish discussion and scaling > since now you have prefixes showing up all kind of crazy places instead of > default). I see enough demand, we get there ... Otherwise RFC1925 clause > 10 and 5. > > 3. PS1: Yes, lots of things "could" be done and then we "could" build a > protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal > links, unless provisioned correctly will pretty much just ruin your > blocking/loss on the fabric is the experience (which the math supports). In > a sense if you know your big flows you can build a specialized topology to > do the optimal distribution (MPLS tunnels anyone ;-) but the point of > fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily > scalable). Otherwise a good analogy would be that you like to build special > RAM chips for the type of data structures you are storing and we know how > well that scales over time. We know now that within 3-4 years > characteristics of DC flows flip upside down without a sweat when people go > from server/client to microservices, from servers to containers and so on > and so on. So if you can't predict your load all the time you need a > _regular_ topology where _regular_ is more of a mathematical than a > protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and > just stick them in" applies here. So RIFT is done largely to serve a > well-known structure called a "lattice" (with some restrictions) since we > need an "up" and "down". Things like hypercubes, thoroidal meshes and so on > and so on exist but CLOS won for a very good reason in history for that > kind of problems (once you move to NUMA other things win ;-) And if you > know your loads and your can heft the OPEX and you like to play with > protocols generally and if you can support the scale in terms of leaf FIB > sizes, flooding, slower convergence & so on & so on and you run flat IGP on > some kind of stuff that you build that doesn't even have to be regular in > any sense. We spent many years solving THAT problem obviously and doing > something like RIFT to replace normal IGP is of limited interest IMO > (albeit certain aspects having to do with modern implemenation techniques > may get us there one day but it's much less of pressing problem than > solving specialized DC routing well IMO again). > > 3. PS2: RIFT cannot build an "unsupported topology" no matter how you > cable (that's the point of it) or rather we have miscabling detection and > do not form adjacencies when you read the draft carefully. That's your > "flash red light" and it comes included for free with my compliments ;-) > ... Otherwise RFC1925 clause 10. > > Otherwise, if you have concrete charter points you'd like to add, be more > specific in your asks and we see what the list thinks after ... > > thanks > > --- tony > > > On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: > >> Hi, >> >> I have one little question/doubt on scalability point of RIFT ... >> >> Assume that someone would like to signal IPv6 prefix SID for Segment >> Routing in the underlay within RIFT. >> >> Wouldn't it result in amount of protocol state in full analogy to massive >> deaggregation - which as of today is designed to be very careful and >> limited operation only at moments of failure(s) ? >> >> I sort of find it a bit surprising that RIFT draft does not provide >> encoding for SID distribution when it is positioned as an alternative to >> other protocols (IGPs or BGP) which already provide ability to carry all >> types of SIDs. >> >> Cheers, >> Robert. >> >> PS1: Horizontal links which were discussed could be installed to offload >> from fabric transit massive amount of data (ex: storage mirroring) directly >> between leafs or L3 TORs and not to be treated as "backup". >> >> PS2: Restricting any protocol to specific topologies seems like pretty >> slippery slope to me. In any case if protocol does that it should also >> contain self detection mechanism of "unsupported topology" and flash red >> light in any NOC. >> >> >> >> _______________________________________________ >> Dcrouting mailing list >> Dcrouting@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrouting >> >> > --f403045e97f844a0bc056284ac2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tony,

Thx for elaborating ...

=
Two small comments:

A) SID/SR use case in underlay could be as simple as gracefully taking a = fabric node out of service. Not much OPEX needed if your NMS is decent. Oth= erwise in normal link state I can do overload bit, in BGP number of solutio= ns from shutdown to MED to LP ... depending what is your BGP design. In RIF= T how do you do that ? Note that overlay (if such exist) does not help here= .=C2=A0

B) For horizon= tal links imagine you have servers with 40 GB ports to TOR. Then you have N= x100 GB from TOR up. You are going to oversubscribe on TOR (servers to fabr= ic) most likely 2:1 .. 3:1 etc. So if I want to interconnect TORs because I= do know that servers behind those TORs need to talk to each other in a non= blocking fashion _and_ I have spare 100 GB ports on TORs having routing pr= otocol which does not allow me to do that seems pretty limited - wouldn'= ;t you agree ?=C2=A0

T= hx,
R.







On Thu, Jan 11, 2018 at 6:= 40 PM, Tony Przygienda <tonysietf@gmail.com> wrote:
Robert, product= ive points, thanks for raising them ... I go a bit in depth
<= br>
1. I saw no _real_ use-cases for SID in DC so far to be frank= (once you run RIFT). The only one that comes up regularly is egress engine= ering and that IMO is equivalent to SID=3Dleaf address (which could be a HV= address of course once you have RIFT all way down to server) so really, wh= at's the point to have a SID? It's probably much smarter to use IBG= P & so on overlay to do this kind of synchronization if needed since la= bels/SIDs become very useful in overlay to distinguish lots stuff there lik= e VPNs/services which you'd carry e.g. in MPLSoUDP. In underlay just us= e the destination v4/v6 address. Having said that, discussion always to be = had if you pay me dinner ;--) and I know _how_ we can do SIDs in RIFT since= I thought it through but again, no _real_ use case so far. And if your onl= y concern is to "shape towards a prefix" we have PGP in the draft= which doesn't need new silicon ;-P And then ultimately, yes, if you re= ally, really want a SID per prefix everywhere then you'll carry=C2=A0 S= IDs to everywhere since unicast SIDs are really just a glorified way to say= "I have this non-aggreagable 20 bit IP host address" which archi= tecturally is a very interesting proposition in terms of scaling (but then = again, no account for taste and RFC1925 clause 3 applies) ...=C2=A0 Your LS= DB will be still much smaller, your SPF will be still simple on leaf in RIF= T but your FIB will blow up and anything changing on a leaf shakes all othe= r leafs (unless you start to run pollicies to control distribution @ which = point in time you start to baby-sit your fabric @ high OPEX). One of the re= asons to do per-prefix SID would be non-ECMP anycast (where SIDs _are_ in f= act usefull) but if you read RIFT draft carefully you will observe that RIF= T can do anycast without need for ECMP, i.e. true anycast in a sense and wi= th that having anycast SID serves no real purpose in RIFT and is actually g= enerally much harder to do since you need globally unique label blocks and = so on ...=C2=A0

2. Horizontal links on CLOSes are not used th= at way normally all I saw since your blocking goes to hell unless you provi= sion some kind of really massive parallel links between ToRs _and_ understa= nd your load. We _could_ build RIFT that way but you give up balancing thro= ugh the fabric and loop-free property in a sense (that's a longish disc= ussion=C2=A0 and scaling since now you have prefixes showing up all kind of= crazy places instead of default). I see enough demand, we get there ...=C2= =A0 Otherwise RFC1925 clause 10 and 5.=C2=A0

3. P= S1: Yes, lots of things "could" be done and then we "could&q= uot; build a protocol to do that and RFC1925 clause 7 and 8 applies. Such h= orizontal links, unless provisioned correctly will pretty much just ruin yo= ur blocking/loss on the fabric is the experience (which the math supports).= In a sense if you know your big flows you can build a specialized topology= to do the optimal distribution (MPLS tunnels anyone ;-) but the point of f= abric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and eas= ily scalable). Otherwise a good analogy would be that you like to build spe= cial RAM chips for the type of data structures you are storing and we know = how well that scales over time. We know now that within 3-4 years character= istics of DC flows flip upside down without a sweat when people go from ser= ver/client to microservices, from servers to containers and so on and so on= . So if you can't predict your load all the time you need a _regular_ t= opology where _regular_ is more of a mathematical than a protocol discussio= n. Fabric analogy of "buy more RAM chips in Fry's and just stick t= hem in" applies here. So RIFT is done largely to serve a well-known st= ructure called a "lattice" (with some restrictions) since we need= an "up" and "down". Things like hypercubes, thoroidal = meshes and so on and so on exist but CLOS won for a very good reason in his= tory for that kind of problems (once you move to NUMA other things win ;-) = And if you know your loads and your can heft the OPEX and you like to play = with protocols generally and if you can support the scale in terms of leaf = FIB sizes, flooding, slower convergence & so on & so on and you run= flat IGP on some kind of stuff that you build that doesn't even have t= o be regular in any sense. We spent many years solving THAT problem obvious= ly and doing something like RIFT to replace normal IGP is of limited intere= st IMO (albeit certain aspects having to do with modern implemenation techn= iques may get us there one day but it's much less of pressing problem t= han solving specialized DC routing well IMO again).

3. PS2: RIFT cannot build an "unsupported topology" no matter h= ow you cable (that's the point of it) or rather we have miscabling dete= ction and do not form adjacencies when you read the draft carefully. That&#= 39;s your "flash red light" and it comes included for free with m= y compliments=C2=A0 ;-) ... Otherwise RFC1925 clause 10.

Othe= rwise, if you have concrete charter points you'd like to add, be more s= pecific in your asks and we see what the list thinks after ...
thanks

--- tony

On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk <robert@raszu= k.net> wrote:
<= div>
Hi,

I have one little question/doubt= on scalability point of RIFT ...=C2=A0

Assume that someone would like= to signal IPv6 prefix SID for Segment Routing in the underlay within RIFT.= =C2=A0

Wouldn't it result in amount of protocol state in full anal= ogy to massive deaggregation - which as of today is designed to be very car= eful and limited operation only at moments of failure(s) ?=C2=A0

=
I sor= t of find it a bit surprising that RIFT draft does not provide encoding for= SID distribution when it is positioned as an alternative to other protocol= s (IGPs or BGP) which already provide ability to carry all types of SIDs.= =C2=A0

Cheers,
Robert.

PS1: Horizontal links which were discus= sed could be installed to offload from fabric transit massive amount of dat= a (ex: storage mirroring) directly between leafs or L3 TORs and not to be t= reated as "backup".=C2=A0

PS2: Restricting any protocol to s= pecific topologies seems like pretty slippery slope to me. In any case if p= rotocol does that it should also contain self detection mechanism of "= unsupported topology" and flash red light in any NOC.=C2=A0

=

<= /div>

_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>



--f403045e97f844a0bc056284ac2a-- From nobody Thu Jan 11 13:20:08 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640F512DA47; Thu, 11 Jan 2018 13:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 aDSWk7t2ahDJ; Thu, 11 Jan 2018 13:20:03 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A6512EBEC; Thu, 11 Jan 2018 13:20:02 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id g75so8292981wme.0; Thu, 11 Jan 2018 13:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DQBG+dtO/SbWFKgey3PkCMYKx5eGzyyZTMSJYOrWMfM=; b=D1rlsc1hihilQE9BbfXvbsmZYe1oP+4sMkp2sn2plO6TUZnWDFZf7wt35GCbHUljyH CS+un3v+TcpgJep+Qsa0/uhzBuGQ5udaDvkQU/uN+oqPznJaaHZRMCW7rcmyPStnbQOF bAytvpDxImGs57nwBCl3Gnw6wHcpsNmg2aJTF9h7j+k6vAqE+/B6PH7OtCyNDqVx/JEn aCTZL659uRlgw3PxJLRVHP2YG2SwTiUYN/c9sc8tnYeaLcvrrs2JVAektj5kzGJ/YZTf 86BOx5XYQkNutvAAmYOGRo08/vmq8hs1LmCS1mDyGLzELzaikNkKRwCil2906iff4Ys1 +h0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DQBG+dtO/SbWFKgey3PkCMYKx5eGzyyZTMSJYOrWMfM=; b=nSb4RhHLesRidW85iCwfuNipkTJXM17HlHhCVoaCfkfKZ637xQ19jODk6SiuchVY33 6K/vaxvvmJLYI2Z8Qg6y5sRbvXJXqWg6YlfzT87a18o7dsNe8O1PDFv0p+NshWEy1Hfn UpKYOJXPlgRIcTXysfMn8Ee5DauuRHXUqx3t0Jd6xStbhAhTLH1tiKcToqk3dsupIY/r lUDJ9bWD7fUYwaK96zaJkSkcVHnpvQ4spqjFbMSPAKkdqCD1hLck0lpQjqczdlUcU7MM YLLQJ8ZPKEx+DDoHuzfjlAQwE2DBYyJnJfqdIO56na2kQrxQBO2CQtqvOQspJmZSuvjb lTOg== X-Gm-Message-State: AKGB3mLulbLZbBjDNq3xM3v7NKCLfbeboAauFL+OeD/XmClY+GqVKRJ0 RPdgBrvoueqlbjLE+j+bRu8uu7vP8rp+gT8IDnA= X-Google-Smtp-Source: ACJfBotzQdfSmgV6vxmSUH/XtR6ztc3QHiUuWfBZm0vAAPsLuvIaa8g+PrELdcO7WMpaMJmK2kUQefyTTPGhDuCkLvY= X-Received: by 10.80.205.203 with SMTP id h11mr32269245edj.159.1515705601209; Thu, 11 Jan 2018 13:20:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 11 Jan 2018 13:19:20 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 11 Jan 2018 13:19:20 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045dc2e0f1b7d0056286b55a" Archived-At: Subject: Re: [Rift] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 21:20:06 -0000 --f403045dc2e0f1b7d0056286b55a Content-Type: text/plain; charset="UTF-8" A. Reading the draft you'll find the overload bit on RIFT which IMO is the best out-of-production solution. B. Depends what your LEAF is. If LEAF is your TOR (most stuff today) then RIFT will do that just fine using LEAF2LEAF procedures in fact. If we start to run RIFT @ the server level then we'd need discuss but people do not do horizontal links in non-leaf-to-non-leaf as far I saw (except protection here and there) but then again, they mostly don't extend the fabric routing protocol into the server (which RIFT intends to do). So, for today you're good. Once you want RIFT on server I think having spine horizontals is not a good idea in general I hope that computes and I'd encourage you to read the draft again, maybe without the "it should work just like BGP or just like today's IGP" hat on ... ;-) Of course, paying me fancy dinners and asking questions, letting me ramble then is a valid substitute ;-) --- tony On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk wrote: > Hi Tony, > > Thx for elaborating ... > > Two small comments: > > A) SID/SR use case in underlay could be as simple as gracefully taking a > fabric node out of service. Not much OPEX needed if your NMS is decent. > Otherwise in normal link state I can do overload bit, in BGP number of > solutions from shutdown to MED to LP ... depending what is your BGP design. > In RIFT how do you do that ? Note that overlay (if such exist) does not > help here. > > B) For horizontal links imagine you have servers with 40 GB ports to TOR. > Then you have Nx100 GB from TOR up. You are going to oversubscribe on TOR > (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to > interconnect TORs because I do know that servers behind those TORs need to > talk to each other in a non blocking fashion _and_ I have spare 100 GB > ports on TORs having routing protocol which does not allow me to do that > seems pretty limited - wouldn't you agree ? > > Thx, > R. > > > > > > > > On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda > wrote: > >> Robert, productive points, thanks for raising them ... I go a bit in depth >> >> 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you >> run RIFT). The only one that comes up regularly is egress engineering and >> that IMO is equivalent to SID=leaf address (which could be a HV address of >> course once you have RIFT all way down to server) so really, what's the >> point to have a SID? It's probably much smarter to use IBGP & so on overlay >> to do this kind of synchronization if needed since labels/SIDs become very >> useful in overlay to distinguish lots stuff there like VPNs/services which >> you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 >> address. Having said that, discussion always to be had if you pay me dinner >> ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but >> again, no _real_ use case so far. And if your only concern is to "shape >> towards a prefix" we have PGP in the draft which doesn't need new silicon >> ;-P And then ultimately, yes, if you really, really want a SID per prefix >> everywhere then you'll carry SIDs to everywhere since unicast SIDs are >> really just a glorified way to say "I have this non-aggreagable 20 bit IP >> host address" which architecturally is a very interesting proposition in >> terms of scaling (but then again, no account for taste and RFC1925 clause 3 >> applies) ... Your LSDB will be still much smaller, your SPF will be still >> simple on leaf in RIFT but your FIB will blow up and anything changing on a >> leaf shakes all other leafs (unless you start to run pollicies to control >> distribution @ which point in time you start to baby-sit your fabric @ high >> OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast >> (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you >> will observe that RIFT can do anycast without need for ECMP, i.e. true >> anycast in a sense and with that having anycast SID serves no real purpose >> in RIFT and is actually generally much harder to do since you need globally >> unique label blocks and so on ... >> >> 2. Horizontal links on CLOSes are not used that way normally all I saw >> since your blocking goes to hell unless you provision some kind of really >> massive parallel links between ToRs _and_ understand your load. We _could_ >> build RIFT that way but you give up balancing through the fabric and >> loop-free property in a sense (that's a longish discussion and scaling >> since now you have prefixes showing up all kind of crazy places instead of >> default). I see enough demand, we get there ... Otherwise RFC1925 clause >> 10 and 5. >> >> 3. PS1: Yes, lots of things "could" be done and then we "could" build a >> protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal >> links, unless provisioned correctly will pretty much just ruin your >> blocking/loss on the fabric is the experience (which the math supports). In >> a sense if you know your big flows you can build a specialized topology to >> do the optimal distribution (MPLS tunnels anyone ;-) but the point of >> fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily >> scalable). Otherwise a good analogy would be that you like to build special >> RAM chips for the type of data structures you are storing and we know how >> well that scales over time. We know now that within 3-4 years >> characteristics of DC flows flip upside down without a sweat when people go >> from server/client to microservices, from servers to containers and so on >> and so on. So if you can't predict your load all the time you need a >> _regular_ topology where _regular_ is more of a mathematical than a >> protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and >> just stick them in" applies here. So RIFT is done largely to serve a >> well-known structure called a "lattice" (with some restrictions) since we >> need an "up" and "down". Things like hypercubes, thoroidal meshes and so on >> and so on exist but CLOS won for a very good reason in history for that >> kind of problems (once you move to NUMA other things win ;-) And if you >> know your loads and your can heft the OPEX and you like to play with >> protocols generally and if you can support the scale in terms of leaf FIB >> sizes, flooding, slower convergence & so on & so on and you run flat IGP on >> some kind of stuff that you build that doesn't even have to be regular in >> any sense. We spent many years solving THAT problem obviously and doing >> something like RIFT to replace normal IGP is of limited interest IMO >> (albeit certain aspects having to do with modern implemenation techniques >> may get us there one day but it's much less of pressing problem than >> solving specialized DC routing well IMO again). >> >> 3. PS2: RIFT cannot build an "unsupported topology" no matter how you >> cable (that's the point of it) or rather we have miscabling detection and >> do not form adjacencies when you read the draft carefully. That's your >> "flash red light" and it comes included for free with my compliments ;-) >> ... Otherwise RFC1925 clause 10. >> >> Otherwise, if you have concrete charter points you'd like to add, be more >> specific in your asks and we see what the list thinks after ... >> >> thanks >> >> --- tony >> >> >> On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: >> >>> Hi, >>> >>> I have one little question/doubt on scalability point of RIFT ... >>> >>> Assume that someone would like to signal IPv6 prefix SID for Segment >>> Routing in the underlay within RIFT. >>> >>> Wouldn't it result in amount of protocol state in full analogy to >>> massive deaggregation - which as of today is designed to be very careful >>> and limited operation only at moments of failure(s) ? >>> >>> I sort of find it a bit surprising that RIFT draft does not provide >>> encoding for SID distribution when it is positioned as an alternative to >>> other protocols (IGPs or BGP) which already provide ability to carry all >>> types of SIDs. >>> >>> Cheers, >>> Robert. >>> >>> PS1: Horizontal links which were discussed could be installed to offload >>> from fabric transit massive amount of data (ex: storage mirroring) directly >>> between leafs or L3 TORs and not to be treated as "backup". >>> >>> PS2: Restricting any protocol to specific topologies seems like pretty >>> slippery slope to me. In any case if protocol does that it should also >>> contain self detection mechanism of "unsupported topology" and flash red >>> light in any NOC. >>> >>> >>> >>> _______________________________________________ >>> Dcrouting mailing list >>> Dcrouting@ietf.org >>> https://www.ietf.org/mailman/listinfo/dcrouting >>> >>> >> > --f403045dc2e0f1b7d0056286b55a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A. Reading the draft you'll find the overloa= d bit on RIFT which IMO is the best out-of-production solution.
B.= Depends what your LEAF is. If LEAF is your TOR (most stuff today) then RIF= T will do that just fine using LEAF2LEAF procedures in fact. If we start to= run RIFT @ the server level then we'd need discuss but people do not d= o horizontal links in non-leaf-to-non-leaf as far I saw (except protection = here and there) but then again, they mostly don't extend the fabric rou= ting protocol into the server (which RIFT intends to do). So, for today you= 're good. Once you want RIFT on server I think having spine horizontals= is not a good idea in general

I hope that co= mputes and I'd encourage you to read the draft again, maybe without the= "it should work just like BGP or just like today's IGP" hat = on ...=C2=A0 ;-)=C2=A0 Of course, paying me fancy dinners and asking questi= ons, letting me ramble then is a valid substitute ;-)

--- tony

On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk <= ;robert@raszuk.net> wrote:
Hi Tony,

Thx for elaborating ...

Two small comments:

A) SID/SR use case= in underlay could be as simple as gracefully taking a fabric node out of s= ervice. Not much OPEX needed if your NMS is decent. Otherwise in normal lin= k state I can do overload bit, in BGP number of solutions from shutdown to = MED to LP ... depending what is your BGP design. In RIFT how do you do that= ? Note that overlay (if such exist) does not help here.=C2=A0

B) For horizontal links imagine yo= u have servers with 40 GB ports to TOR. Then you have Nx100 GB from TOR up.= You are going to oversubscribe on TOR (servers to fabric) most likely 2:1 = .. 3:1 etc. So if I want to interconnect TORs because I do know that server= s behind those TORs need to talk to each other in a non blocking fashion _a= nd_ I have spare 100 GB ports on TORs having routing protocol which does no= t allow me to do that seems pretty limited - wouldn't you agree ?=C2=A0=

Thx,
R.


=





On Th= u, Jan 11, 2018 at 6:40 PM, Tony Przygienda <tonysietf@gmail.com&g= t; wrote:
Robert, productive points, thanks for raising them ... I go a bit i= n depth

1. I saw no _real_ use-cases for SID i= n DC so far to be frank (once you run RIFT). The only one that comes up reg= ularly is egress engineering and that IMO is equivalent to SID=3Dleaf addre= ss (which could be a HV address of course once you have RIFT all way down t= o server) so really, what's the point to have a SID? It's probably = much smarter to use IBGP & so on overlay to do this kind of synchroniza= tion if needed since labels/SIDs become very useful in overlay to distingui= sh lots stuff there like VPNs/services which you'd carry e.g. in MPLSoU= DP. In underlay just use the destination v4/v6 address. Having said that, d= iscussion always to be had if you pay me dinner ;--) and I know _how_ we ca= n do SIDs in RIFT since I thought it through but again, no _real_ use case = so far. And if your only concern is to "shape towards a prefix" w= e have PGP in the draft which doesn't need new silicon ;-P And then ult= imately, yes, if you really, really want a SID per prefix everywhere then y= ou'll carry=C2=A0 SIDs to everywhere since unicast SIDs are really just= a glorified way to say "I have this non-aggreagable 20 bit IP host ad= dress" which architecturally is a very interesting proposition in term= s of scaling (but then again, no account for taste and RFC1925 clause 3 app= lies) ...=C2=A0 Your LSDB will be still much smaller, your SPF will be stil= l simple on leaf in RIFT but your FIB will blow up and anything changing on= a leaf shakes all other leafs (unless you start to run pollicies to contro= l distribution @ which point in time you start to baby-sit your fabric @ hi= gh OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast= (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully yo= u will observe that RIFT can do anycast without need for ECMP, i.e. true an= ycast in a sense and with that having anycast SID serves no real purpose in= RIFT and is actually generally much harder to do since you need globally u= nique label blocks and so on ...=C2=A0

2. Horizontal links on= CLOSes are not used that way normally all I saw since your blocking goes t= o hell unless you provision some kind of really massive parallel links betw= een ToRs _and_ understand your load. We _could_ build RIFT that way but you= give up balancing through the fabric and loop-free property in a sense (th= at's a longish discussion=C2=A0 and scaling since now you have prefixes= showing up all kind of crazy places instead of default). I see enough dema= nd, we get there ...=C2=A0 Otherwise RFC1925 clause 10 and 5.=C2=A0
<= div>
3. PS1: Yes, lots of things "could" be done an= d then we "could" build a protocol to do that and RFC1925 clause = 7 and 8 applies. Such horizontal links, unless provisioned correctly will p= retty much just ruin your blocking/loss on the fabric is the experience (wh= ich the math supports). In a sense if you know your big flows you can build= a specialized topology to do the optimal distribution (MPLS tunnels anyone= ;-) but the point of fabric is that it's a fabric (i.e. load agnostic,= cheap, no OPEX and easily scalable). Otherwise a good analogy would be tha= t you like to build special RAM chips for the type of data structures you a= re storing and we know how well that scales over time. We know now that wit= hin 3-4 years characteristics of DC flows flip upside down without a sweat = when people go from server/client to microservices, from servers to contain= ers and so on and so on. So if you can't predict your load all the time= you need a _regular_ topology where _regular_ is more of a mathematical th= an a protocol discussion. Fabric analogy of "buy more RAM chips in Fry= 's and just stick them in" applies here. So RIFT is done largely t= o serve a well-known structure called a "lattice" (with some rest= rictions) since we need an "up" and "down". Things like= hypercubes, thoroidal meshes and so on and so on exist but CLOS won for a = very good reason in history for that kind of problems (once you move to NUM= A other things win ;-) And if you know your loads and your can heft the OPE= X and you like to play with protocols generally and if you can support the = scale in terms of leaf FIB sizes, flooding, slower convergence & so on = & so on and you run flat IGP on some kind of stuff that you build that = doesn't even have to be regular in any sense. We spent many years solvi= ng THAT problem obviously and doing something like RIFT to replace normal I= GP is of limited interest IMO (albeit certain aspects having to do with mod= ern implemenation techniques may get us there one day but it's much les= s of pressing problem than solving specialized DC routing well IMO again). =

3. PS2: RIFT cannot build an "unsupported top= ology" no matter how you cable (that's the point of it) or rather = we have miscabling detection and do not form adjacencies when you read the = draft carefully. That's your "flash red light" and it comes i= ncluded for free with my compliments=C2=A0 ;-) ... Otherwise RFC1925 clause= 10.

Otherwise, if you have concrete charter points you'd= like to add, be more specific in your asks and we see what the list thinks= after ...

thanks

---= tony


On Thu, Jan 11, = 2018 at 1:30 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little question/doubt on scal= ability point of RIFT ...=C2=A0

Assume that someone would like to sign= al IPv6 prefix SID for Segment Routing in the underlay within RIFT.=C2=A0
<= br>
Wouldn't it result in amount of protocol state in full analogy to m= assive deaggregation - which as of today is designed to be very careful and= limited operation only at moments of failure(s) ?=C2=A0

I sort of fin= d it a bit surprising that RIFT draft does not provide encoding for SID dis= tribution when it is positioned as an alternative to other protocols (IGPs = or BGP) which already provide ability to carry all types of SIDs.=C2=A0
Cheers,
Robert.

PS1: Horizontal links which were discussed could = be installed to offload from fabric transit massive amount of data (ex: sto= rage mirroring) directly between leafs or L3 TORs and not to be treated as = "backup".=C2=A0

PS2: Restricting any protocol to specific to= pologies seems like pretty slippery slope to me. In any case if protocol do= es that it should also contain self detection mechanism of "unsupporte= d topology" and flash red light in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>




--f403045dc2e0f1b7d0056286b55a-- From nobody Thu Jan 11 14:23:58 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0B712E03C; Thu, 11 Jan 2018 14:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 4yLoD9119feS; Thu, 11 Jan 2018 14:23:55 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 D177F12D87D; Thu, 11 Jan 2018 14:23:54 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id b141so8557859wme.1; Thu, 11 Jan 2018 14:23:54 -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=ewaw4bpqvf595bIP+ZoHK9BBdTwyxgGdIq3hywK3TNQ=; b=VGtaKbyisKwE8yd6Aj9wxlTWNA/havSM+XlKhAq/+gWmEBKaGzXNyDSvymO1IBgASX InTzfLXP0vS0E2Nm5Xqd5hzqhSYHwjMqmuH+XtjSimBeDl8wYxq3QLZrl3u1OB8MQiXK xniNoDh7LqYfd4RKWb/6kzbOX1rlZlmohNdyUgq7AqrTpfRdjhTyMnhSMJOPiN/TCb4p y1ebZIP4T8kQdMXQE3mdD1Bj+R7ugZKPJg+wwO1UQbniVnQWz1X3QRmei9RIwYYliWr/ NTjRfCv8g2pVk2oGGMJgnjjH1NR6ed5PXOD7Ufi0SLgGMljYmtUC2aVJDNV6Z4+8wmTw znuA== 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=ewaw4bpqvf595bIP+ZoHK9BBdTwyxgGdIq3hywK3TNQ=; b=fHrHn+e0RUJ9hkGrbPhX9GWKqTpWF2jddo67nPs/7xG38k/5fT4qXFkxdQpw+FQ0Vq MzjwedPwM+XXiqCTU0YeLtcGt8qUbeMAsfLrd6tU8C874TvSk1Jf5u6VryTARYF44bmA zgraSMHph1REJgvvmNVtXXVLc2U0oiP/G63x61oFsCjvr2H2RofwwNUkZJRyLMgpuRHf f7CvJn05ycMPsHEN3pUCJA6ZyGcsPPfddIJznYfECHkfat1fC+CKgMgMdrvV/wDodHps +n3DACwr3rrj+0xdObxa0j8kxKVxSaITxsnJ1LV8T3eY3n9q5cOhFDxCwdMhjf1VGyAF QuYA== X-Gm-Message-State: AKGB3mLGuZRIUzpDE0sfwDkKDcKljdf3ka339IeKXNFqcrBfIFhaJLSJ 8SMdXqjNZ/M6o4Ntxx9NwBM4Bl0Q9onppE27hNoE5TMa X-Google-Smtp-Source: ACJfBovXLIWYEtrtZFHaO5wDGC9RQYVziaZO+R5olK5tXUau0BhQ9dkQ1+belTayQNTDXYbWV8USUVDt8eRvrlC2YS4= X-Received: by 10.80.206.67 with SMTP id k3mr33495447edj.153.1515709433324; Thu, 11 Jan 2018 14:23:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 11 Jan 2018 14:23:12 -0800 (PST) From: Tony Przygienda Date: Thu, 11 Jan 2018 14:23:12 -0800 Message-ID: To: rift@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045dbf005b28090562879a68" Archived-At: Subject: [Rift] FYI: New version of RIFT published (-04) X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 22:23:56 -0000 --f403045dbf005b28090562879a68 Content-Type: text/plain; charset="UTF-8" A new version of https://datatracker.ietf.org/doc/draft-przygienda-rift/ has been published. The update incorporates a full ZTP solution which can be optionally applied on a node-by-node basis or on a whole IP fabric. Comments obviously welcome thanks --- tony --f403045dbf005b28090562879a68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The upda= te incorporates a full ZTP solution which can be optionally applied on a no= de-by-node basis or on a whole IP fabric.

Com= ments obviously welcome

thanks

--- tony=


--f403045dbf005b28090562879a68-- From nobody Sat Jan 13 10:17:36 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AF012D946; Sat, 13 Jan 2018 10:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 L4pFTk_zgke9; Sat, 13 Jan 2018 10:17:31 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 B43C312D944; Sat, 13 Jan 2018 10:17:30 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id 141so17378599wme.3; Sat, 13 Jan 2018 10:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KEI6utxYxohvgPc2yEgIZxMMdheZ0eskVDfyStQqha0=; b=Sk8NH1HfG0PY0gyzDlj9w1Ij2nKT+98SXG0NPhOkXshs+aWwY58gVqOKPvQPTSWZCW ccfu1eLX44WV+QHreRnXJNINWWF4jQR7PYS0JH3JyQgWU7fr0Kig1rg8XJyfNXkJ9R3a et91NjkBNVi322Iq3OrNlOQSWo6qT4l9baKtkNCII6csDaFMItDsirYLZQ+gZiYrrY5x JxdOT/17AFlIcrrAy0MUl2V0IsiL10IkP+LCvXj7BUnXKxW2j6iR+RXQbX3pPyPI0/3p DeayJrLB+8ZvF14OTJqd5jfNHoK3SQAmV3BEoRlnN378xQfHYll+xyzXdST6USKxEBX3 zwrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KEI6utxYxohvgPc2yEgIZxMMdheZ0eskVDfyStQqha0=; b=OZWssFTHkupDt5YmMS64e/d5XrERTfAASSrZYZiGZtUvV+eJGv+HtQ+L7SBjGV8XSi +K2H4ymA45qnUmdGjc177ac7tM04ICRwd/VTPdul2kjNV1SeDYGPOpjcsjIiyGQAdCIc fT9rpyK5UO+3MIVH1RM4hLDdT9ufRwHQ8EEudYlHRz8Ce8Msz9lylsIqvQA4w4b1MQwU ySWNXJPboWwRC0rbcd9P0ohMTm6sRGtn4M5A6jDUXca13bTBaUzsP/yQYxt+0nDGOnmD qknYHHwFMZdM7c9tFUfcvI+MdRHIx/ubH18ktTtKhL301m2Fx3zNughRUyl+H9MiaJI7 E0Kg== X-Gm-Message-State: AKwxytfzAWz+55nDjzSWUzBZxi7Umip6ukUlV3FJm5YiTQ1PMDTPue6g DbOwD8gI+WeEghjJE9op0++SvE7/5lj82J9Vj0s/XXVy X-Google-Smtp-Source: ACJfBotiqIl9QK6CNqU+43tkCk2tmza3axvtrupMxh/Sl6VmZAajWCZM71A5Yj9RFgKEQnaSZQinwyfNAypcyKWIvd4= X-Received: by 10.80.155.90 with SMTP id a26mr3233443edj.290.1515867449013; Sat, 13 Jan 2018 10:17:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Sat, 13 Jan 2018 10:16:48 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Sat, 13 Jan 2018 10:16:48 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1af462d338da0562ac649d" Archived-At: Subject: Re: [Rift] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 18:17:34 -0000 --94eb2c1af462d338da0562ac649d Content-Type: text/plain; charset="UTF-8" So I thought over your horizontal link case to shortcut the spine levels for some kind of traffic again and I think the current draft actually covers that if you're willing to provision things correctly yourself via S-PGP. Let me see whether we agree on this picture first: . +--------+ +--------+ . | | | | ^ N . |Spine 21| |Spine 22| | .Level 2 ++-+--+-++ ++-+--+-++ <-*-> E/W . | | | | | | | | | . P111/2| |P121 | | | | S v . ^ ^ ^ ^ | | | | . | | | | | | | | . +--------------+ | +-----------+ | | | +---------------+ . | | | | | | | | . South +-----------------------------+ | | ^ . | | | | | | | All TIEs . 0/0 0/0 0/0 +-----------------------------+ | . v v v | | | | | . | | +-+ +<-0/0----------+ | | . | | | | | | | | .+-+----++ optional +-+----++ ++----+-+ ++-----++ .| | E/W link | +=====+ | | | .|Node111+----------+Node112| |Node121| |Node122| .+-+---+-+ ++----+-+ +-+---+-+ ++---+--+ . | | | South | | | | . | +---0/0--->-----+ 0/0 | +----------------+ | . 0/0 | | | | | | | . | +---<-0/0-----+ | v | +--------------+ | | . v | | | | | | | .+-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+ .| | (L2L) | | | | Level 0 | | .|Leaf111~~~~~~~~~~~~Leaf112| |Leaf121| |Leaf122| .+-+-----+ +-+---+-+ +--+--+-+ +-+-----+ . + + \ / + + . Prefix111 Prefix112 \ / Prefix121 Prefix122 . multi-homed . Prefix .+---------- Pod 1 ---------+ +---------- Pod 2 ---------+ I assume here that what you ask for is the following scenario: a) POD1 being a compute generating very heavy load towards storage in Prefix121. b) traffic from POD1 NOT being balanced through the spines but taking a horizontal link Node112 to Node121 to reach your storage in Prefix121 to save bandwidth? or delay? c) The key to riches is -04 section4.2.5.1 . Northbound SPF in the paragraph "Other south prefixes found when crossing E-W link MAY be used IIF". Now, we could make it a MUST (but it's really an implementation knob IMO) and what it says is that if you are willing to inject an "S-PGP" @ Node121 for Prefix121 it will get flooded to Node112 and Node112 will have a more specific match than the default in N-SPF. From 121 normal RIFT takes over since the normal N-Prefix for Leaf121 kicks in on Node121. I assume Node112 policy on the ingress is to not propagate the S-PGP south but use it for N-SPF only. Observe that a) you have to switch off miscabling detection for PoD# on those nodes since you are "crossing PoDs illegally" b) if you want whole Pod#1 to do that you either cable Node111 to Node121 as well (which will load balance whole Pod#1 towards storage without using Spine) OR you propagate S-PGPs south towards leafs (which will cost you leaf FIB of course but make sure ALL traffic to storage goes over Node112 only). c) Your forwarding on Node112 can actually even go haywire & load-balance some of the traffic to Prefix121 using this S-PGP over Node121 and some still using the default route towards spine(which here is a blatant violation of LPM of course) and RIFT will work just fine (unless you loop yourself to death with PGPs you install) but that of course is a deep rathole in itself. I just mention it to show why the "non-looping" design is so important and makes for the shortcomings for the SPF on a fabric, predicted by the non-directional mesh property that Dijkstra solved in his time. so? --- tony On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk wrote: > Hi Tony, > > Thx for elaborating ... > > Two small comments: > > A) SID/SR use case in underlay could be as simple as gracefully taking a > fabric node out of service. Not much OPEX needed if your NMS is decent. > Otherwise in normal link state I can do overload bit, in BGP number of > solutions from shutdown to MED to LP ... depending what is your BGP design. > In RIFT how do you do that ? Note that overlay (if such exist) does not > help here. > > B) For horizontal links imagine you have servers with 40 GB ports to TOR. > Then you have Nx100 GB from TOR up. You are going to oversubscribe on TOR > (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to > interconnect TORs because I do know that servers behind those TORs need to > talk to each other in a non blocking fashion _and_ I have spare 100 GB > ports on TORs having routing protocol which does not allow me to do that > seems pretty limited - wouldn't you agree ? > > Thx, > R. > > > > > > > > On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda > wrote: > >> Robert, productive points, thanks for raising them ... I go a bit in depth >> >> 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you >> run RIFT). The only one that comes up regularly is egress engineering and >> that IMO is equivalent to SID=leaf address (which could be a HV address of >> course once you have RIFT all way down to server) so really, what's the >> point to have a SID? It's probably much smarter to use IBGP & so on overlay >> to do this kind of synchronization if needed since labels/SIDs become very >> useful in overlay to distinguish lots stuff there like VPNs/services which >> you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 >> address. Having said that, discussion always to be had if you pay me dinner >> ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but >> again, no _real_ use case so far. And if your only concern is to "shape >> towards a prefix" we have PGP in the draft which doesn't need new silicon >> ;-P And then ultimately, yes, if you really, really want a SID per prefix >> everywhere then you'll carry SIDs to everywhere since unicast SIDs are >> really just a glorified way to say "I have this non-aggreagable 20 bit IP >> host address" which architecturally is a very interesting proposition in >> terms of scaling (but then again, no account for taste and RFC1925 clause 3 >> applies) ... Your LSDB will be still much smaller, your SPF will be still >> simple on leaf in RIFT but your FIB will blow up and anything changing on a >> leaf shakes all other leafs (unless you start to run pollicies to control >> distribution @ which point in time you start to baby-sit your fabric @ high >> OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast >> (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you >> will observe that RIFT can do anycast without need for ECMP, i.e. true >> anycast in a sense and with that having anycast SID serves no real purpose >> in RIFT and is actually generally much harder to do since you need globally >> unique label blocks and so on ... >> >> 2. Horizontal links on CLOSes are not used that way normally all I saw >> since your blocking goes to hell unless you provision some kind of really >> massive parallel links between ToRs _and_ understand your load. We _could_ >> build RIFT that way but you give up balancing through the fabric and >> loop-free property in a sense (that's a longish discussion and scaling >> since now you have prefixes showing up all kind of crazy places instead of >> default). I see enough demand, we get there ... Otherwise RFC1925 clause >> 10 and 5. >> >> 3. PS1: Yes, lots of things "could" be done and then we "could" build a >> protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal >> links, unless provisioned correctly will pretty much just ruin your >> blocking/loss on the fabric is the experience (which the math supports). In >> a sense if you know your big flows you can build a specialized topology to >> do the optimal distribution (MPLS tunnels anyone ;-) but the point of >> fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily >> scalable). Otherwise a good analogy would be that you like to build special >> RAM chips for the type of data structures you are storing and we know how >> well that scales over time. We know now that within 3-4 years >> characteristics of DC flows flip upside down without a sweat when people go >> from server/client to microservices, from servers to containers and so on >> and so on. So if you can't predict your load all the time you need a >> _regular_ topology where _regular_ is more of a mathematical than a >> protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and >> just stick them in" applies here. So RIFT is done largely to serve a >> well-known structure called a "lattice" (with some restrictions) since we >> need an "up" and "down". Things like hypercubes, thoroidal meshes and so on >> and so on exist but CLOS won for a very good reason in history for that >> kind of problems (once you move to NUMA other things win ;-) And if you >> know your loads and your can heft the OPEX and you like to play with >> protocols generally and if you can support the scale in terms of leaf FIB >> sizes, flooding, slower convergence & so on & so on and you run flat IGP on >> some kind of stuff that you build that doesn't even have to be regular in >> any sense. We spent many years solving THAT problem obviously and doing >> something like RIFT to replace normal IGP is of limited interest IMO >> (albeit certain aspects having to do with modern implemenation techniques >> may get us there one day but it's much less of pressing problem than >> solving specialized DC routing well IMO again). >> >> 3. PS2: RIFT cannot build an "unsupported topology" no matter how you >> cable (that's the point of it) or rather we have miscabling detection and >> do not form adjacencies when you read the draft carefully. That's your >> "flash red light" and it comes included for free with my compliments ;-) >> ... Otherwise RFC1925 clause 10. >> >> Otherwise, if you have concrete charter points you'd like to add, be more >> specific in your asks and we see what the list thinks after ... >> >> thanks >> >> --- tony >> >> >> On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: >> >>> Hi, >>> >>> I have one little question/doubt on scalability point of RIFT ... >>> >>> Assume that someone would like to signal IPv6 prefix SID for Segment >>> Routing in the underlay within RIFT. >>> >>> Wouldn't it result in amount of protocol state in full analogy to >>> massive deaggregation - which as of today is designed to be very careful >>> and limited operation only at moments of failure(s) ? >>> >>> I sort of find it a bit surprising that RIFT draft does not provide >>> encoding for SID distribution when it is positioned as an alternative to >>> other protocols (IGPs or BGP) which already provide ability to carry all >>> types of SIDs. >>> >>> Cheers, >>> Robert. >>> >>> PS1: Horizontal links which were discussed could be installed to offload >>> from fabric transit massive amount of data (ex: storage mirroring) directly >>> between leafs or L3 TORs and not to be treated as "backup". >>> >>> PS2: Restricting any protocol to specific topologies seems like pretty >>> slippery slope to me. In any case if protocol does that it should also >>> contain self detection mechanism of "unsupported topology" and flash red >>> light in any NOC. >>> >>> >>> >>> _______________________________________________ >>> Dcrouting mailing list >>> Dcrouting@ietf.org >>> https://www.ietf.org/mailman/listinfo/dcrouting >>> >>> >> > --94eb2c1af462d338da0562ac649d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So I thought over your horizontal link case= to shortcut the spine levels
for some kind of traffic a= gain and I think the current draft actually
covers that = if you're willing to provision things correctly yourself via S-PGP.
Let me see whether we agree on this picture first:

= .=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--------+
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ^ N
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |Spine 21|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |Spine 22|=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.Level 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ++-+--+-++=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ++-+--+-++=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-*-> E/W=
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 P111/2|=C2=A0 |P121=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 S v
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ ^=C2=A0 ^ ^=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 |= |
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |
.=C2=A0 +------------= --+ |=C2=A0 +-----------+=C2=A0 | |=C2=A0 | +---------------+
.=C2=A0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0 | |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
. South +------= -----------------------+ |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^
.=C2=A0 |=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 All TIEs
.=C2=A0 0/0=C2=A0 0/0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0/0=C2=A0=C2=A0 +---------------------= --------+=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0 v=C2=A0=C2=A0=C2=A0 v=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+=C2=A0=C2=A0=C2=A0 += <-0/0----------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0 |
.+-+----++ optional +-+----++=C2=A0=C2=A0= =C2=A0=C2=A0 ++----+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 ++-----++
.|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | E/W link |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=3D=3D=3D=3D=3D+ =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.|Node111+----------+Node112|=C2= =A0=C2=A0=C2=A0=C2=A0 |Node121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |Node122|
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ++----+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++---+--+
.=C2=A0 |= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0 South=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0 +---0/0--->-----+ 0/0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 +----------------+= |
. 0/0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | | |
.=C2=A0 |=C2=A0=C2=A0 += ---<-0/0-----+ |=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0 +--------------+ | |
.=C2=A0 v=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | |
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--+--+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +---+-+-+
.|=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0 (L2L)=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= Level 0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.|Leaf111~~~~~~~~~~~~Le= af112|=C2=A0=C2=A0=C2=A0=C2=A0 |Leaf121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |Leaf122|
.+-+-----+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0 +--+--+-+=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-----+
.=C2=A0 +=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 /=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +
.=C2=A0 Prefix111=C2=A0=C2=A0 Pre= fix112=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=C2=A0=C2=A0 Pref= ix121=C2=A0=C2=A0=C2=A0 Prefix122
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 multi-homed
.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefi= x
.+---------- Pod 1 ---------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------- Pod = 2 ---------+

I assume here that what you ask for is the fo= llowing scenario:
a) POD1 being a compute generating very hea= vy load towards storage in
=C2=A0=C2=A0 Prefix121.
<= /span>
b) traffic from POD1 NOT being balanced through the spines but tak= ing
=C2=A0=C2=A0 a horizontal link Node112 to Node= 121 to reach your storage in Prefix121
=C2=A0=C2=A0 to s= ave bandwidth? or delay?
<= font size=3D"2">c) The key = to riches is -04 section
4.2.5.1. Northbound SPF

=C2=A0 in the paragraph "Other south prefixes found when crossing E= -W link MAY be used IIF". Now, we could make it a MUST (but it's r= eally an implementation knob IMO) and what it says is that if you are willi= ng to inject an "S-PGP" @ Node121 for Prefix121 it will get flood= ed to Node112 and Node112 will have a more specific match than the default = in N-SPF. From 121 normal RIFT takes over since the normal N-Prefix for Lea= f121 kicks in on Node121. I assume Node112 policy on the ingress is to not = propagate the S-PGP south but use it for N-SPF only.

=


Observe that

a) you have to switch off mis= cabling detection for PoD# on those nodes since you are "crossing PoDs= illegally"

b) if you want whole Pod#1 to do that you either cable Node111 to No= de121 as well (which will load balance whole Pod#1 towards storage without = using Spine)=C2=A0 OR you propagate S-PGPs south towards leafs (which will = cost you leaf FIB of course but make sure ALL traffic to storage goes over = Node112 only).

c) Your forwarding on Node112 can actually even go haywire & load= -balance some of the traffic to Prefix121 using this S-PGP over Node121 and= some still using the default route towards spine(which here is a blatant v= iolation of LPM of course) and RIFT will work just fine (unless you loop yo= urself to death with PGPs you install) but that of course is a deep rathole= in itself. I just mention it to show why the "non-looping" desig= n is so important and makes for the shortcomings for the SPF on a fabric, p= redicted by the non-directional mesh property that Dijkstra solved in his t= ime.

so?<= br>

--- tony <= br>






On Thu, Jan 11, 2018 at 10:= 54 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Tony,
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
Thx for elaborating ...

Two small comments:
A) SID/SR use case in underlay could be as simple= as gracefully taking a fabric node out of service. Not much OPEX needed if= your NMS is decent. Otherwise in normal link state I can do overload bit, = in BGP number of solutions from shutdown to MED to LP ... depending what is= your BGP design. In RIFT how do you do that ? Note that overlay (if such e= xist) does not help here.=C2=A0

B) For horizontal links imagine you have servers with 40 GB ports= to TOR. Then you have Nx100 GB from TOR up. You are going to oversubscribe= on TOR (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to int= erconnect TORs because I do know that servers behind those TORs need to tal= k to each other in a non blocking fashion _and_ I have spare 100 GB ports o= n TORs having routing protocol which does not allow me to do that seems pre= tty limited - wouldn't you agree ?=C2=A0

Thx,
R.





<= br>

On Thu, Jan 11, 2018 at 6:40 PM, Tony= Przygienda <tonysietf@gmail.com> wrote:
Robert, productive points,= thanks for raising them ... I go a bit in depth

1. I saw no _real_ use-cases for SID in DC so far to be frank (once you = run RIFT). The only one that comes up regularly is egress engineering and t= hat IMO is equivalent to SID=3Dleaf address (which could be a HV address of= course once you have RIFT all way down to server) so really, what's th= e point to have a SID? It's probably much smarter to use IBGP & so = on overlay to do this kind of synchronization if needed since labels/SIDs b= ecome very useful in overlay to distinguish lots stuff there like VPNs/serv= ices which you'd carry e.g. in MPLSoUDP. In underlay just use the desti= nation v4/v6 address. Having said that, discussion always to be had if you = pay me dinner ;--) and I know _how_ we can do SIDs in RIFT since I thought = it through but again, no _real_ use case so far. And if your only concern i= s to "shape towards a prefix" we have PGP in the draft which does= n't need new silicon ;-P And then ultimately, yes, if you really, reall= y want a SID per prefix everywhere then you'll carry=C2=A0 SIDs to ever= ywhere since unicast SIDs are really just a glorified way to say "I ha= ve this non-aggreagable 20 bit IP host address" which architecturally = is a very interesting proposition in terms of scaling (but then again, no a= ccount for taste and RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be = still much smaller, your SPF will be still simple on leaf in RIFT but your = FIB will blow up and anything changing on a leaf shakes all other leafs (un= less you start to run pollicies to control distribution @ which point in ti= me you start to baby-sit your fabric @ high OPEX). One of the reasons to do= per-prefix SID would be non-ECMP anycast (where SIDs _are_ in fact usefull= ) but if you read RIFT draft carefully you will observe that RIFT can do an= ycast without need for ECMP, i.e. true anycast in a sense and with that hav= ing anycast SID serves no real purpose in RIFT and is actually generally mu= ch harder to do since you need globally unique label blocks and so on ...= =C2=A0

2. Horizontal links on CLOSes are not used that way no= rmally all I saw since your blocking goes to hell unless you provision some= kind of really massive parallel links between ToRs _and_ understand your l= oad. We _could_ build RIFT that way but you give up balancing through the f= abric and loop-free property in a sense (that's a longish discussion=C2= =A0 and scaling since now you have prefixes showing up all kind of crazy pl= aces instead of default). I see enough demand, we get there ...=C2=A0 Other= wise RFC1925 clause 10 and 5.=C2=A0

3. PS1: Yes, = lots of things "could" be done and then we "could" buil= d a protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal= links, unless provisioned correctly will pretty much just ruin your blocki= ng/loss on the fabric is the experience (which the math supports). In a sen= se if you know your big flows you can build a specialized topology to do th= e optimal distribution (MPLS tunnels anyone ;-) but the point of fabric is = that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily scala= ble). Otherwise a good analogy would be that you like to build special RAM = chips for the type of data structures you are storing and we know how well = that scales over time. We know now that within 3-4 years characteristics of= DC flows flip upside down without a sweat when people go from server/clien= t to microservices, from servers to containers and so on and so on. So if y= ou can't predict your load all the time you need a _regular_ topology w= here _regular_ is more of a mathematical than a protocol discussion. Fabric= analogy of "buy more RAM chips in Fry's and just stick them in&qu= ot; applies here. So RIFT is done largely to serve a well-known structure c= alled a "lattice" (with some restrictions) since we need an "= ;up" and "down". Things like hypercubes, thoroidal meshes an= d so on and so on exist but CLOS won for a very good reason in history for = that kind of problems (once you move to NUMA other things win ;-) And if yo= u know your loads and your can heft the OPEX and you like to play with prot= ocols generally and if you can support the scale in terms of leaf FIB sizes= , flooding, slower convergence & so on & so on and you run flat IGP= on some kind of stuff that you build that doesn't even have to be regu= lar in any sense. We spent many years solving THAT problem obviously and do= ing something like RIFT to replace normal IGP is of limited interest IMO (a= lbeit certain aspects having to do with modern implemenation techniques may= get us there one day but it's much less of pressing problem than solvi= ng specialized DC routing well IMO again).

3. PS2:= RIFT cannot build an "unsupported topology" no matter how you ca= ble (that's the point of it) or rather we have miscabling detection and= do not form adjacencies when you read the draft carefully. That's your= "flash red light" and it comes included for free with my complim= ents=C2=A0 ;-) ... Otherwise RFC1925 clause 10.

Otherwise, if= you have concrete charter points you'd like to add, be more specific i= n your asks and we see what the list thinks after ...

thanks

--- tony

<= div class=3D"gmail_extra">
On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk <= robert@raszuk.net> wrote:
Hi,

=
I have one little question/doubt on scalability point of RIFT ...=C2=A0
Assume that someone would like to signal IPv6 prefix SID for Segment Rou= ting in the underlay within RIFT.=C2=A0

Wouldn't it result in amou= nt of protocol state in full analogy to massive deaggregation - which as of= today is designed to be very careful and limited operation only at moments= of failure(s) ?=C2=A0

I sort of find it a bit surprising that RIFT dr= aft does not provide encoding for SID distribution when it is positioned as= an alternative to other protocols (IGPs or BGP) which already provide abil= ity to carry all types of SIDs.=C2=A0

Cheers,
Robert.

PS1: Hor= izontal links which were discussed could be installed to offload from fabri= c transit massive amount of data (ex: storage mirroring) directly between l= eafs or L3 TORs and not to be treated as "backup".=C2=A0

PS2= : Restricting any protocol to specific topologies seems like pretty slipper= y slope to me. In any case if protocol does that it should also contain sel= f detection mechanism of "unsupported topology" and flash red lig= ht in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>




--94eb2c1af462d338da0562ac649d-- From nobody Sat Jan 13 11:21:43 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394B812DA18; Sat, 13 Jan 2018 11:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 BnE0sAhOl5TL; Sat, 13 Jan 2018 11:21:37 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 671CC12D775; Sat, 13 Jan 2018 11:21:37 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id r78so17754724wme.0; Sat, 13 Jan 2018 11:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nDC5tEdZeKOJidfY4+fIen3tufn96hcV08bzyS97DBY=; b=uq7/lVnLKN9THamLL+QuLOXqHYDsQbuZmgE4q8ykpR1lRozFmggV8IzTQDG8PCcImA /aJ7cmwukbtYSxtEOiexfDuZ2Vyi556sG2+5ek4yp+GZqCHEYct/Yl/0rM3p3r2fxriW 1XEluU3FZUKoZQuzXQPfpTUJ4abh9LLs/hb1bINeR8VDY26EGrZKA46X6+7ZT68FIafV WD/E51+1Oiv41pF3X9ZinqqYH8S3eURgTNtmY0Yz0l5Z4jFdgNtGRjMCXGdNtmHrq+qM ZAdRenmZL/iQpfbNPLor0TAoJElIjxA0v/1mNf/Y2idRRA4LLxeOlspXvAbr6eViQEcY nWhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nDC5tEdZeKOJidfY4+fIen3tufn96hcV08bzyS97DBY=; b=EuvYl3OafrsaGw/KHmrXKIiypzqfIcPZOJUdh5CettTVMVN0PNN+/T9mXMlJg/UPiu ZpnOOwhqex4EBV898fFHIwoFDBoJ0jSniwqT0cJ62w35ni5NR0vGi3uMVjE/gXPM4UYm L1hFnQGyGoAFew/GitFZs28jIhvi3YbC8mKvxRtLlt1gWc6y6Pds5s2tOy80c3q7i/1T usAUx5W+mli4AN1vAwG/+b346nbsux+Xo4gGkfs8935YK9yjwssOD4/vzsmoXdGbJeqz I/9lkjLbVAMHh/4LGlRZVSLzbPCtduD/IWzLug34TWC+0Ng6etVJZsfjCZSpTtz/jjVn rptQ== X-Gm-Message-State: AKwxytc1Yd6CbN9nr/T92SEUTNq8RilyaAuFrs+ssDnaWsBqKchO6arV Y0Y/gW0DuF1Sy8QwsBm5Ti9ZPpyESYk3wifWdLe/ubjB X-Google-Smtp-Source: ACJfBovPpqxlmA8Hdn0xevvQ8aPWiVNMs3E4RVDtvAUmIrYUDwuXdxAel2FqRzKp13SlHk1Z/4fSUnIFmbsi8c2Klu4= X-Received: by 10.28.61.68 with SMTP id k65mr6530537wma.147.1515871295478; Sat, 13 Jan 2018 11:21:35 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Sat, 13 Jan 2018 11:21:34 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Sat, 13 Jan 2018 20:21:34 +0100 X-Google-Sender-Auth: 7dHHwjSzFZUKamPXnSNXUpgcBSE Message-ID: To: Tony Przygienda Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="001a114b2d02179ff90562ad4af1" Archived-At: Subject: Re: [Rift] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 19:21:41 -0000 --001a114b2d02179ff90562ad4af1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tony, > =E2=80=8B if you're willing to provision things correctly yourself via S-PGP. I am not willing to do that. I would like routing to do it for me auto-magically. But yes you got the question right. I was asking for shortcuts between last levels of fabric. Not so much between Node 111 & Node 112 - but you said it is optional so ok. Side note: PGP abbrev. for vast majority of people means completely different thing then what you defined it to mean locally in your draft. I highly recommended you rename it in -05 version to PGD (policy guided destination(s) or PGR (policy guided reachability/routing). Now requirement to switch off miscabling detection is not acceptable. You are stating that only rift knows how should I cable my fabric ? And if I cable it some other way it will detect it as miscabling ? I think in most cases of correct cables check you actually define the intent then network detects if such intent is met. > Node112 can actually even go haywire That may be not best property of a routing protocol :) Best, R. On Sat, Jan 13, 2018 at 7:16 PM, Tony Przygienda wrote: > So I thought over your horizontal link case to shortcut the spine levels > for some kind of traffic again and I think the current draft actually > covers that > =E2=80=8B=E2=80=8B > if you're willing to provision things correctly yourself via S-PGP. > Let me see whether we agree on this picture first: > > . +--------+ +--------+ > . | | | | ^ N > . |Spine 21| |Spine 22| | > .Level 2 ++-+--+-++ ++-+--+-++ <-*-> E/W > . | | | | | | | | | > . P111/2| |P121 | | | | S v > . ^ ^ ^ ^ | | | | > . | | | | | | | | > . +--------------+ | +-----------+ | | | +---------------+ > . | | | | | | | | > . South +-----------------------------+ | | ^ > . | | | | | | | All TIEs > . 0/0 0/0 0/0 +-----------------------------+ | > . v v v | | | | | > . | | +-+ +<-0/0----------+ | | > . | | | | | | | | > .+-+----++ optional +-+----++ ++----+-+ ++-----++ > .| | E/W link | +=3D=3D=3D=3D=3D+ | | | > .|Node111+----------+Node112| |Node121| |Node122| > .+-+---+-+ ++----+-+ +-+---+-+ ++---+--+ > . | | | South | | | | > . | +---0/0--->-----+ 0/0 | +----------------+ | > . 0/0 | | | | | | | > . | +---<-0/0-----+ | v | +--------------+ | | > . v | | | | | | | > .+-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+ > .| | (L2L) | | | | Level 0 | | > .|Leaf111~~~~~~~~~~~~Leaf112| |Leaf121| |Leaf122| > .+-+-----+ +-+---+-+ +--+--+-+ +-+-----+ > . + + \ / + + > . Prefix111 Prefix112 \ / Prefix121 Prefix122 > . multi-homed > . Prefix > .+---------- Pod 1 ---------+ +---------- Pod 2 ---------+ > > I assume here that what you ask for is the following scenario: > a) POD1 being a compute generating very heavy load towards storage in > Prefix121. > b) traffic from POD1 NOT being balanced through the spines but taking > a horizontal link Node112 to Node121 to reach your storage in > Prefix121 > to save bandwidth? or delay? > c) The key to riches is -04 section4.2.5.1 > . > Northbound SPF > > in the paragraph "Other south prefixes found when crossing E-W link MAY > be used IIF". Now, we could make it a MUST (but it's really an > implementation knob IMO) and what it says is that if you are willing to > inject an "S-PGP" @ Node121 for Prefix121 it will get flooded to Node112 > and Node112 will have a more specific match than the default in N-SPF. Fr= om > 121 normal RIFT takes over since the normal N-Prefix for Leaf121 kicks in > on Node121. I assume Node112 policy on the ingress is to not propagate th= e > S-PGP south but use it for N-SPF only. > > > Observe that > > a) you have to switch off miscabling detection for PoD# on those nodes > since you are "crossing PoDs illegally" > > b) if you want whole Pod#1 to do that you either cable Node111 to Node121 > as well (which will load balance whole Pod#1 towards storage without usin= g > Spine) OR you propagate S-PGPs south towards leafs (which will cost you > leaf FIB of course but make sure ALL traffic to storage goes over Node112 > only). > > c) Your forwarding on Node112 can actually even go haywire & load-balance > some of the traffic to Prefix121 using this S-PGP over Node121 and some > still using the default route towards spine(which here is a blatant > violation of LPM of course) and RIFT will work just fine (unless you loop > yourself to death with PGPs you install) but that of course is a deep > rathole in itself. I just mention it to show why the "non-looping" design > is so important and makes for the shortcomings for the SPF on a fabric, > predicted by the non-directional mesh property that Dijkstra solved in hi= s > time. > > so? > > --- tony > > > > > > > On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk wrote= : > >> Hi Tony, >> >> Thx for elaborating ... >> >> Two small comments: >> >> A) SID/SR use case in underlay could be as simple as gracefully taking a >> fabric node out of service. Not much OPEX needed if your NMS is decent. >> Otherwise in normal link state I can do overload bit, in BGP number of >> solutions from shutdown to MED to LP ... depending what is your BGP desi= gn. >> In RIFT how do you do that ? Note that overlay (if such exist) does not >> help here. >> >> B) For horizontal links imagine you have servers with 40 GB ports to TOR= . >> Then you have Nx100 GB from TOR up. You are going to oversubscribe on TO= R >> (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to >> interconnect TORs because I do know that servers behind those TORs need = to >> talk to each other in a non blocking fashion _and_ I have spare 100 GB >> ports on TORs having routing protocol which does not allow me to do that >> seems pretty limited - wouldn't you agree ? >> >> Thx, >> R. >> >> >> >> >> >> >> >> On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda >> wrote: >> >>> Robert, productive points, thanks for raising them ... I go a bit in >>> depth >>> >>> 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you >>> run RIFT). The only one that comes up regularly is egress engineering a= nd >>> that IMO is equivalent to SID=3Dleaf address (which could be a HV addre= ss of >>> course once you have RIFT all way down to server) so really, what's the >>> point to have a SID? It's probably much smarter to use IBGP & so on ove= rlay >>> to do this kind of synchronization if needed since labels/SIDs become v= ery >>> useful in overlay to distinguish lots stuff there like VPNs/services wh= ich >>> you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v= 6 >>> address. Having said that, discussion always to be had if you pay me di= nner >>> ;--) and I know _how_ we can do SIDs in RIFT since I thought it through= but >>> again, no _real_ use case so far. And if your only concern is to "shape >>> towards a prefix" we have PGP in the draft which doesn't need new silic= on >>> ;-P And then ultimately, yes, if you really, really want a SID per pref= ix >>> everywhere then you'll carry SIDs to everywhere since unicast SIDs are >>> really just a glorified way to say "I have this non-aggreagable 20 bit = IP >>> host address" which architecturally is a very interesting proposition i= n >>> terms of scaling (but then again, no account for taste and RFC1925 clau= se 3 >>> applies) ... Your LSDB will be still much smaller, your SPF will be st= ill >>> simple on leaf in RIFT but your FIB will blow up and anything changing = on a >>> leaf shakes all other leafs (unless you start to run pollicies to contr= ol >>> distribution @ which point in time you start to baby-sit your fabric @ = high >>> OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycas= t >>> (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully= you >>> will observe that RIFT can do anycast without need for ECMP, i.e. true >>> anycast in a sense and with that having anycast SID serves no real purp= ose >>> in RIFT and is actually generally much harder to do since you need glob= ally >>> unique label blocks and so on ... >>> >>> 2. Horizontal links on CLOSes are not used that way normally all I saw >>> since your blocking goes to hell unless you provision some kind of real= ly >>> massive parallel links between ToRs _and_ understand your load. We _cou= ld_ >>> build RIFT that way but you give up balancing through the fabric and >>> loop-free property in a sense (that's a longish discussion and scaling >>> since now you have prefixes showing up all kind of crazy places instead= of >>> default). I see enough demand, we get there ... Otherwise RFC1925 clau= se >>> 10 and 5. >>> >>> 3. PS1: Yes, lots of things "could" be done and then we "could" build a >>> protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal >>> links, unless provisioned correctly will pretty much just ruin your >>> blocking/loss on the fabric is the experience (which the math supports)= . In >>> a sense if you know your big flows you can build a specialized topology= to >>> do the optimal distribution (MPLS tunnels anyone ;-) but the point of >>> fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and ea= sily >>> scalable). Otherwise a good analogy would be that you like to build spe= cial >>> RAM chips for the type of data structures you are storing and we know h= ow >>> well that scales over time. We know now that within 3-4 years >>> characteristics of DC flows flip upside down without a sweat when peopl= e go >>> from server/client to microservices, from servers to containers and so = on >>> and so on. So if you can't predict your load all the time you need a >>> _regular_ topology where _regular_ is more of a mathematical than a >>> protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and >>> just stick them in" applies here. So RIFT is done largely to serve a >>> well-known structure called a "lattice" (with some restrictions) since = we >>> need an "up" and "down". Things like hypercubes, thoroidal meshes and s= o on >>> and so on exist but CLOS won for a very good reason in history for that >>> kind of problems (once you move to NUMA other things win ;-) And if you >>> know your loads and your can heft the OPEX and you like to play with >>> protocols generally and if you can support the scale in terms of leaf F= IB >>> sizes, flooding, slower convergence & so on & so on and you run flat IG= P on >>> some kind of stuff that you build that doesn't even have to be regular = in >>> any sense. We spent many years solving THAT problem obviously and doing >>> something like RIFT to replace normal IGP is of limited interest IMO >>> (albeit certain aspects having to do with modern implemenation techniqu= es >>> may get us there one day but it's much less of pressing problem than >>> solving specialized DC routing well IMO again). >>> >>> 3. PS2: RIFT cannot build an "unsupported topology" no matter how you >>> cable (that's the point of it) or rather we have miscabling detection a= nd >>> do not form adjacencies when you read the draft carefully. That's your >>> "flash red light" and it comes included for free with my compliments ;= -) >>> ... Otherwise RFC1925 clause 10. >>> >>> Otherwise, if you have concrete charter points you'd like to add, be >>> more specific in your asks and we see what the list thinks after ... >>> >>> thanks >>> >>> --- tony >>> >>> >>> On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk >>> wrote: >>> >>>> Hi, >>>> >>>> I have one little question/doubt on scalability point of RIFT ... >>>> >>>> Assume that someone would like to signal IPv6 prefix SID for Segment >>>> Routing in the underlay within RIFT. >>>> >>>> Wouldn't it result in amount of protocol state in full analogy to >>>> massive deaggregation - which as of today is designed to be very caref= ul >>>> and limited operation only at moments of failure(s) ? >>>> >>>> I sort of find it a bit surprising that RIFT draft does not provide >>>> encoding for SID distribution when it is positioned as an alternative = to >>>> other protocols (IGPs or BGP) which already provide ability to carry a= ll >>>> types of SIDs. >>>> >>>> Cheers, >>>> Robert. >>>> >>>> PS1: Horizontal links which were discussed could be installed to >>>> offload from fabric transit massive amount of data (ex: storage mirror= ing) >>>> directly between leafs or L3 TORs and not to be treated as "backup". >>>> >>>> PS2: Restricting any protocol to specific topologies seems like pretty >>>> slippery slope to me. In any case if protocol does that it should also >>>> contain self detection mechanism of "unsupported topology" and flash r= ed >>>> light in any NOC. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Dcrouting mailing list >>>> Dcrouting@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dcrouting >>>> >>>> >>> >> > --001a114b2d02179ff90562ad4af1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tony,

> =E2=80=8B
if yo= u're willing to provision things correctly yourself via S-PGP.=C2=A0

I am not willing to do that. I would like routing to do it f= or me auto-magically. But yes you got the question right. I was asking for = shortcuts between last levels of fabric. Not so much between Node 111 &= Node 112 - but you said it is optional so ok.=C2=A0

<= div class=3D"gmail_default" style=3D"font-size:small">Side note: PGP abbrev. for vast majority of people means com= pletely different thing then what you defined it to mean locally in your dr= aft. I highly recommended you rename it in -05 version to PGD (policy guide= d destination(s) or PGR (policy guided reachability/routing).=C2=A0<= /div>

Now requirement to sw= itch off miscabling detection is not acceptable. You are stating that only = rift knows how should I cable my fabric ? And if I cable it some other way = it will detect it as miscabling ? I think in most cases of correct cables c= heck you actually define the intent then network detects if such intent is = met.=C2=A0

> Node112 can actually even go haywire

<= /div>
That may be not best property of a routing= protocol :)=C2=A0

Best,
R.

On Sat, Ja= n 13, 2018 at 7:16 PM, Tony Przygienda <tonysietf@gmail.com> wrote:
So I thought over your horizontal link case to shortcut= the spine levels
for some kind of traffic again and I t= hink the current draft actually
covers that
=E2=80=8B=E2=80=8B
if you're willing to pr= ovision things correctly yourself via S-PGP.
<= font size=3D"2">Let me see = whether we agree on this picture first:

.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-------= -+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+
.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ N
.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |Spine 21|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |Spine 22|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |.Level 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++-+--+-++=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++-+--+-++=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 <-*-> E/W
.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |= =C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 P111/2|=C2=A0 |P121=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S v=
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ ^=C2=A0 ^ ^=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |
.=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | |=C2=A0 | |
.=C2=A0 +--------------+ |=C2=A0 +-----------+=C2= =A0 | |=C2=A0 | +---------------+
.=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 | |=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |
. South +-----------------------------+ |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 All TIEs
.=C2=A0 0/0=C2=A0 0/0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 0/0=C2=A0=C2=A0 +-----------------------------+=C2=A0=C2= =A0=C2=A0=C2=A0 |
.=C2=A0 v=C2=A0=C2=A0=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+=C2=A0=C2=A0=C2=A0 +<-0/0----------+= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0 |
.+-+----++ optional +-+----++=C2=A0=C2=A0=C2=A0=C2=A0 ++----= +-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++-----++.|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | E/W link |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 +=3D=3D=3D=3D=3D+ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |
.|Node111+----------+Node112|=C2=A0=C2=A0=C2=A0= =C2=A0 |Node121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |Node122|
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ++----+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++---+--+
.=C2=A0 |=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0 South=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0 +---0/0--->-----+ 0/0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 +----------------+ |
. 0/0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | | |
.=C2=A0 |=C2=A0=C2=A0 +---<-0/0-= ----+ |=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0 +--------------+ | |
.=C2=A0 v=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | |
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--+--+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +---+-+-+
.|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0 (L2L)=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Level 0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.|Leaf111~~~~~~~~~~~~Leaf112|=C2= =A0=C2=A0=C2=A0=C2=A0 |Leaf121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |Leaf122|
.+-+-----+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0 +--+--+-+=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-----+
.=C2=A0 +=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 /=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +
.=C2=A0 Prefix111=C2=A0=C2=A0 Prefix112= =C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=C2=A0=C2=A0 Prefix121= =C2=A0=C2=A0=C2=A0 Prefix122
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 multi-homed
.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefix
.= +---------- Pod 1 ---------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------- Pod 2 ----= -----+

I assume here that what you ask for is the followin= g scenario:
a) POD1 being a compute generating very heavy loa= d towards storage in
=C2=A0=C2=A0 Prefix121.
=
b) traffic from POD1 NOT being balanced through the spines but taking
=C2=A0=C2=A0 a horizontal <= span style=3D"font-family:monospace,monospace">link Node112 to Node121 to r= each your storage in Prefix121
=C2=A0=C2=A0 to save band= width? or delay?
c) The key to ric= hes is -04 section
4.2.5.1. Northbound= SPF

<= font size=3D"2">=C2=A0 in the paragraph "Other south prefixes found wh= en crossing E-W link MAY be used IIF". Now, we could make it a MUST (b= ut it's really an implementation knob IMO) and what it says is that if = you are willing to inject an "S-PGP" @ Node121 for Prefix121 it w= ill get flooded to Node112 and Node112 will have a more specific match than= the default in N-SPF. From 121 normal RIFT takes over since the normal N-P= refix for Leaf121 kicks in on Node121. I assume Node112 policy on the ingre= ss is to not propagate the S-PGP south but use it for N-SPF only.


=

Observe that

a) you have to s= witch off miscabling detection for PoD# on those nodes since you are "= crossing PoDs illegally"

b) if you want whole Pod#1 to do that you either cable = Node111 to Node121 as well (which will load balance whole Pod#1 towards sto= rage without using Spine)=C2=A0 OR you propagate S-PGPs south towards leafs= (which will cost you leaf FIB of course but make sure ALL traffic to stora= ge goes over Node112 only).

c) Your forwarding on Node112 can actually even go haywi= re & load-balance some of the traffic to Prefix121 using this S-PGP ove= r Node121 and some still using the default route towards spine(which here i= s a blatant violation of LPM of course) and RIFT will work just fine (unles= s you loop yourself to death with PGPs you install) but that of course is a= deep rathole in itself. I just mention it to show why the "non-loopin= g" design is so important and makes for the shortcomings for the SPF o= n a fabric, predicted by the non-directional mesh property that Dijkstra so= lved in his time.

so?

= --- tony

=




<= /span>
=

On Thu, Jan 11, 2018 at 10:= 54 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Tony,

Thx for = elaborating ...

Two small comments:

A) SID/SR use case in unde= rlay could be as simple as gracefully taking a fabric node out of service. = Not much OPEX needed if your NMS is decent. Otherwise in normal link state = I can do overload bit, in BGP number of solutions from shutdown to MED to L= P ... depending what is your BGP design. In RIFT how do you do that ? Note = that overlay (if such exist) does not help here.=C2=A0

B) For horizont= al links imagine you have servers with 40 GB ports to TOR. Then you have Nx= 100 GB from TOR up. You are going to oversubscribe on TOR (servers to fabri= c) most likely 2:1 .. 3:1 etc. So if I want to interconnect TORs because I = do know that servers behind those TORs need to talk to each other in a non = blocking fashion _and_ I have spare 100 GB ports on TORs having routing pro= tocol which does not allow me to do that seems pretty limited - wouldn'= t you agree ?=C2=A0

Thx,
R.







On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda <<= a href=3D"mailto:tonysietf@gmail.com" target=3D"_blank">tonysietf@gmail.com= > wrote:
Robert, productive points, thanks for rais= ing them ... I go a bit in depth

1. I saw no _= real_ use-cases for SID in DC so far to be frank (once you run RIFT). The o= nly one that comes up regularly is egress engineering and that IMO is equiv= alent to SID=3Dleaf address (which could be a HV address of course once you= have RIFT all way down to server) so really, what's the point to have = a SID? It's probably much smarter to use IBGP & so on overlay to do= this kind of synchronization if needed since labels/SIDs become very usefu= l in overlay to distinguish lots stuff there like VPNs/services which you&#= 39;d carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 add= ress. Having said that, discussion always to be had if you pay me dinner ;-= -) and I know _how_ we can do SIDs in RIFT since I thought it through but a= gain, no _real_ use case so far. And if your only concern is to "shape= towards a prefix" we have PGP in the draft which doesn't need new= silicon ;-P And then ultimately, yes, if you really, really want a SID per= prefix everywhere then you'll carry=C2=A0 SIDs to everywhere since uni= cast SIDs are really just a glorified way to say "I have this non-aggr= eagable 20 bit IP host address" which architecturally is a very intere= sting proposition in terms of scaling (but then again, no account for taste= and RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be still much small= er, your SPF will be still simple on leaf in RIFT but your FIB will blow up= and anything changing on a leaf shakes all other leafs (unless you start t= o run pollicies to control distribution @ which point in time you start to = baby-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID = would be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you rea= d RIFT draft carefully you will observe that RIFT can do anycast without ne= ed for ECMP, i.e. true anycast in a sense and with that having anycast SID = serves no real purpose in RIFT and is actually generally much harder to do = since you need globally unique label blocks and so on ...=C2=A0

2. Horizontal links on CLOSes are not used that way normally all I saw s= ince your blocking goes to hell unless you provision some kind of really ma= ssive parallel links between ToRs _and_ understand your load. We _could_ bu= ild RIFT that way but you give up balancing through the fabric and loop-fre= e property in a sense (that's a longish discussion=C2=A0 and scaling si= nce now you have prefixes showing up all kind of crazy places instead of de= fault). I see enough demand, we get there ...=C2=A0 Otherwise RFC1925 claus= e 10 and 5.=C2=A0

3. PS1: Yes, lots of things &qu= ot;could" be done and then we "could" build a protocol to do= that and RFC1925 clause 7 and 8 applies. Such horizontal links, unless pro= visioned correctly will pretty much just ruin your blocking/loss on the fab= ric is the experience (which the math supports). In a sense if you know you= r big flows you can build a specialized topology to do the optimal distribu= tion (MPLS tunnels anyone ;-) but the point of fabric is that it's a fa= bric (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a = good analogy would be that you like to build special RAM chips for the type= of data structures you are storing and we know how well that scales over t= ime. We know now that within 3-4 years characteristics of DC flows flip ups= ide down without a sweat when people go from server/client to microservices= , from servers to containers and so on and so on. So if you can't predi= ct your load all the time you need a _regular_ topology where _regular_ is = more of a mathematical than a protocol discussion. Fabric analogy of "= buy more RAM chips in Fry's and just stick them in" applies here. = So RIFT is done largely to serve a well-known structure called a "latt= ice" (with some restrictions) since we need an "up" and &quo= t;down". Things like hypercubes, thoroidal meshes and so on and so on = exist but CLOS won for a very good reason in history for that kind of probl= ems (once you move to NUMA other things win ;-) And if you know your loads = and your can heft the OPEX and you like to play with protocols generally an= d if you can support the scale in terms of leaf FIB sizes, flooding, slower= convergence & so on & so on and you run flat IGP on some kind of s= tuff that you build that doesn't even have to be regular in any sense. = We spent many years solving THAT problem obviously and doing something like= RIFT to replace normal IGP is of limited interest IMO (albeit certain aspe= cts having to do with modern implemenation techniques may get us there one = day but it's much less of pressing problem than solving specialized DC = routing well IMO again).

3. PS2: RIFT cannot build= an "unsupported topology" no matter how you cable (that's th= e point of it) or rather we have miscabling detection and do not form adjac= encies when you read the draft carefully. That's your "flash red l= ight" and it comes included for free with my compliments=C2=A0 ;-) ...= Otherwise RFC1925 clause 10.

Otherwise, if you have concrete= charter points you'd like to add, be more specific in your asks and we= see what the list thinks after ...

thanks

--- tony


On Thu, Jan 11, 2018 at 1:30 AM, Robert = Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little q= uestion/doubt on scalability point of RIFT ...=C2=A0

Assume that som= eone would like to signal IPv6 prefix SID for Segment Routing in the underl= ay within RIFT.=C2=A0

Wouldn't it result in amount of protocol sta= te in full analogy to massive deaggregation - which as of today is designed= to be very careful and limited operation only at moments of failure(s) ?= =C2=A0

I sort of find it a bit surprising that RIFT draft does not pro= vide encoding for SID distribution when it is positioned as an alternative = to other protocols (IGPs or BGP) which already provide ability to carry all= types of SIDs.=C2=A0

Cheers,
Robert.

PS1: Horizontal links wh= ich were discussed could be installed to offload from fabric transit massiv= e amount of data (ex: storage mirroring) directly between leafs or L3 TORs = and not to be treated as "backup".=C2=A0

PS2: Restricting an= y protocol to specific topologies seems like pretty slippery slope to me. I= n any case if protocol does that it should also contain self detection mech= anism of "unsupported topology" and flash red light in any NOC.= =C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>





--001a114b2d02179ff90562ad4af1-- From nobody Sat Jan 13 12:06:27 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E956612DA45; Sat, 13 Jan 2018 12:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 O0Czzf8z_CFd; Sat, 13 Jan 2018 12:06:24 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C75A12785F; Sat, 13 Jan 2018 12:06:24 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id 81so6974156wmb.1; Sat, 13 Jan 2018 12:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M6tStLQI2nMWJkmv3cYNWsAz2C4w7C4yQit3Yek2nxM=; b=bjp42liFBKDgjbXHjRbJCNG7zjVdX9c8coJHTMAVkU7vbTjhkLTF3BKnWg8cl9oB5E eNamGvU0SaND0A+lVuDYT9bAfi3BqAbLZhRzFkOQTu1CzB0SBQoWJFa31BdchOjkjlGe LP1yFBSlKaWfzAGub++6REcXkPPUqAAKuq/0SriEiRmU26+Yo0E8md8IgqnAHGGgknfm ZgxLnSuRATfi8YF65t675rNztSY/sJamESkt0bxIiH8wxUOzcZYRVpyFjjFwdP0OFIlK YG43dhb7GMgK6wkpifzfxVF4LodO4jYIIseEFhiOJTVjbBk7fdQTTczRKyZ6plgGiimk 76Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M6tStLQI2nMWJkmv3cYNWsAz2C4w7C4yQit3Yek2nxM=; b=hOtXTOuCPymc4VitxiS3RRJPv5m0ktu6agDNXcne62IcUnHq4MdavXYuUXAq31PAi4 VNiWTQAq+J7AoTFE0bkSagbd+ZfqiygpvaCtPlV3BBCqrZavMcVcB3wETADlDMM7bpHs xLsHMPaYMimdxLm0RCvyB4+ccp9jNDH/GBLmZkY582L20W71LRw9P64zLALlMLQPzQo5 CxcvV1lWJfRHPkA7eVZRJhxb/RkJrBlBbk+Ql5hI1MlGLB7CbxUJNfkK+79CaS3E7uax hw6EceSbkigjCrzGI0zwEEJog0d+s+iszVROzk/bGFrRp0J4Jx7M4XNhe947DnCXpGHR ny8Q== X-Gm-Message-State: AKwxyteHH3PH9cp1au6INBn/u3j4folZFC31DDZBhUP4tntN9vt9jf8j 1pqJ+x0HtcNgtBhuBqfpsh4AJVr+7iWUhhPkYaPsvw== X-Google-Smtp-Source: ACJfBosSCqJa79P15j3WrVpS9xs0vvhDNOAsuM56a+S7ar0hMu/L+t5hiMtcFIxzoJRDJ3HX1T2hArViavNSoSEef98= X-Received: by 10.80.148.217 with SMTP id t25mr3272264eda.121.1515873982606; Sat, 13 Jan 2018 12:06:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Sat, 13 Jan 2018 12:05:42 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Sat, 13 Jan 2018 12:05:42 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045c231641f1bf0562adea23" Archived-At: Subject: Re: [Rift] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 20:06:26 -0000 --f403045c231641f1bf0562adea23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 13, 2018 at 11:21 AM, Robert Raszuk wrote: > Hi Tony, > > > =E2=80=8B > if you're willing to provision things correctly yourself via S-PGP. > > I am not willing to do that. I would like routing to do it for me > auto-magically. > The price of that would be that you can run strict SPF only then and loose all the non-equal cost forwarding, including true anycast. Plus, once you think that through in general sense you basically end up with host addresses everywhere (since if you use aggregates you'll blackhole on link failures). If you want to avoid SPF and host routes while still asking for all the things you ask, then as a very experienced and highly regarded architect here puts it to end such discussions "your problem is overly constrained" and there is no protocol/algebra whatsoever that will give you that ... > But yes you got the question right. I was asking for shortcuts between > last levels of fabric. Not so much between Node 111 & Node 112 - but you > said it is optional so ok. > > Side note: PGP abbrev. for vast majority of people means completely > different thing then what you defined it to mean locally in your draft. I > highly recommended you rename it in -05 version to PGD (policy guided > destination(s) or PGR (policy guided reachability/routing). > Sigh, I warned when the acronym was picked. Come up with something that is a word, the funnier the better, easier to remember for our brains that way. Can be 4 letters ;-) and will get you an Ack mention l;-) > > Now requirement to switch off miscabling detection is not acceptable. You > are stating that only rift knows how should I cable my fabric ? > No, it doesn't. You asked in your previous email for "red lights" when topology is built incorrectly and you have it. Now you don't want it. Both states cannot be true @ the same time unless you are entangled ;-) > Node112 can actually even go haywire > > That may be not best property of a routing protocol :) > > "haywire" is the wrong word. Rather, I should have said "it will even allow that". Now, why would you want the same src/dst pair sometimes shortcut on the horizontal link and sometimes go up to spine I can't imagine but you ask for all kind of very non-obvious things you seem to like so I'm just pointing the space of possibilities out to you ... -- tony --f403045c231641f1bf0562adea23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jan 13, 2018 at 11:21 AM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:
Hi Tony,

> =E2=80=8B
if you're willing to provis= ion things correctly yourself via S-PGP.=C2=A0

I am not willing to do that. I would like routing = to do it for me auto-magically.

The price of that would be that you can run strict SPF only then a= nd loose all the non-equal cost forwarding, including true anycast. Plus, o= nce you think that through in general sense you basically end up with host = addresses everywhere (since if you use aggregates you'll blackhole on l= ink failures). If you want to avoid SPF and host routes while still asking = for all the things you ask, then as a very experienced and highly regarded = architect here puts it to end such discussions "your problem is overly= constrained" and there is no protocol/algebra whatsoever that will gi= ve you that ...
=C2=A0
<= div dir=3D"ltr">
But yes you got = the question right. I was asking for shortcuts between last levels of fabri= c. Not so much between Node 111 & Node 112 - but you said it is optiona= l so ok.=C2=A0

<= /span>
Side note: PGP abbrev. for vast majority of people means completely dif= ferent thing then what you defined it to mean locally in your draft. I high= ly recommended you rename it in -05 version to PGD (policy guided destinati= on(s) or PGR (policy guided reachability/routing).=C2=A0
=

Sigh, I warned when the acronym was picked= .=C2=A0 Come up with something that is a word, the funnier the better, easi= er to remember for our brains that way. Can be 4 letters ;-)=C2=A0 and will= get you an Ack mention l;-)
=C2=A0

Now requirement to switch off miscabling de= tection is not acceptable. You are stating that only rift knows how should = I cable my fabric ?

No,= it doesn't. You asked in your previous email for "red lights"= ; when topology is built incorrectly and you have it. Now you don't wan= t it. Both states cannot be true @ the same time unless you are entangled ;= -)=C2=A0

> Node112 can actually even go haywire

That may be not best property of a routing protocol :)=C2=A0


&quo= t;haywire" is the wrong word. Rather,=C2=A0 I should have said "i= t will even allow that". Now, why would you want the same src/dst pair= sometimes shortcut on the horizontal link and sometimes go up to spine I c= an't imagine but you ask for all kind of very non-obvious things you se= em to like so I'm just pointing the space of possibilities out to you .= ..


-- tony
--f403045c231641f1bf0562adea23-- From nobody Sat Jan 13 13:37:47 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBD512DB6D; Sat, 13 Jan 2018 13:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 uxFdkbiV-xJb; Sat, 13 Jan 2018 13:37:34 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F74012DA6B; Sat, 13 Jan 2018 13:37:33 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id g21so8215473wrb.13; Sat, 13 Jan 2018 13:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Bjm5Czc5xjrY6UBeaM1gFgjOnLr74zNjwlIqSs7533A=; b=dAUhUHQCxBFwpePgRTGBGM9QfC+nXZbI2eyenyikuZBnLs021RGkgaC3zbb0tPQ+yS tSwtgLRWD0RSxHes/0L+/2cj2JhMKOV8zSfbzRHmtaFX7cNU/vnZ4Bwjnh2QcDxSwRXq QxhXhYCVVI5RH3PVkmqW9ietUvWxKHreV0mWkOjqagR7Pc2IGxjeFnVs06nv9xORDD4M yI24pNZYqXOVe9wTRH+acfqWjbGFV8Ylj5hs4BB1O83KG9IW9aJSAyrrQv1x+1m7H9gv 7V8jqswROQIc/hSe0gqWYEY/LHcrYVakxE9rM9j/wJeHx/QMZLGLk/gv3PmmlS/iYqg2 Qk7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Bjm5Czc5xjrY6UBeaM1gFgjOnLr74zNjwlIqSs7533A=; b=WkIIDsMbreIiCSHc+hqbZnfsQXxnB1Corpxv2qT6CynZLQAKYEyzb1Cex8zzWg4jgZ L8iFOvdTFRyOye66lAxFzvGYY6kMTfIH+FrVX8ailxoSlC0SfBRLeWFIeCfKUSz0qJwb vUACIE73CMe8Sa7it/Pf0WuzWSqW3aZr4YxydQnpp9yQti4JssRhkVlAZfICCPkeBOrJ yWaIIGrp6zQ/WSHd26kSGfkdPO74FoAb45tEumaomRT8nBvsA0SqwEtvILuXczr1eO55 4ukS48gaUs6AySfa9yLXVZowegWBRp58tS4ko3LSWUZyUoIjmrN5kY8YHYGKd7HMMjkM 1P0A== X-Gm-Message-State: AKwxytejqIx55lAu/DKEHeJpd1S/HJmpD40jY+GDLD3PYsh6mAg9IFF5 ZtxREMIjv4TzS/BSh1IRcYc5gTs+PndD6JmQWbI= X-Google-Smtp-Source: ACJfBotV/qx9Bu4066HISmr0EA5JqSt8IG/Uz8OjTM2eN+xycprV5DDnQZQgZ2cZJxA1IuukhX3seih8G0wJxYPf6Rs= X-Received: by 10.223.138.133 with SMTP id y5mr6035043wry.224.1515879451701; Sat, 13 Jan 2018 13:37:31 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Sat, 13 Jan 2018 13:37:30 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Sat, 13 Jan 2018 22:37:30 +0100 X-Google-Sender-Auth: MvTUuWUvbGroOZvv_J7rPbzIbEc Message-ID: To: Tony Przygienda Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="001a113c2ca23db6000562af300b" Archived-At: Subject: Re: [Rift] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 21:37:36 -0000 --001a113c2ca23db6000562af300b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tony, > The price of that would be that you can run strict SPF only then and loose all the non-equal cost forwarding, including true anycast. 1. Did anyone really asked that we should refrain from running "strict SPF" in DCs ? Contrary I see group of folks keen on running it based on BGP-LS like feeds :) 2. Is non-ECMP fwd-ing a feature or a bug in DC fabric ? When I described to customers that with MPLS you can run non ECMP load balancing it was shock .. but in WAN there are some use cases for it. But in DC fabric - I doubt it. 3. True anycast is clearly possible with native link state and native distance vector. Why the new "hybrid" glue of both would not allow it ? Because it counts on massive aggregation - right ? > Plus, once you think that through in general sense you basically end up with host addresses everywhere (since if you use aggregates you'll blackhole on link failures). If you want to avoid SPF and host routes Host routes are just leaves so they hang off nodes and do not make SPF any harder. Besides I am not convinced that building flat underlays with 1M host routes is the right architecture - even if some folks ask you about it. Best, R. On Sat, Jan 13, 2018 at 9:05 PM, Tony Przygienda wrote: > > > On Sat, Jan 13, 2018 at 11:21 AM, Robert Raszuk wrote= : > >> Hi Tony, >> >> > =E2=80=8B >> if you're willing to provision things correctly yourself via S-PGP. >> >> I am not willing to do that. I would like routing to do it for me >> auto-magically. >> > > The price of that would be that you can run strict SPF only then and loos= e > all the non-equal cost forwarding, including true anycast. Plus, once you > think that through in general sense you basically end up with host > addresses everywhere (since if you use aggregates you'll blackhole on lin= k > failures). If you want to avoid SPF and host routes while still asking fo= r > all the things you ask, then as a very experienced and highly regarded > architect here puts it to end such discussions "your problem is overly > constrained" and there is no protocol/algebra whatsoever that will give y= ou > that ... > > >> But yes you got the question right. I was asking for shortcuts between >> last levels of fabric. Not so much between Node 111 & Node 112 - but you >> said it is optional so ok. >> >> Side note: PGP abbrev. for vast majority of people means completely >> different thing then what you defined it to mean locally in your draft. = I >> highly recommended you rename it in -05 version to PGD (policy guided >> destination(s) or PGR (policy guided reachability/routing). >> > > Sigh, I warned when the acronym was picked. Come up with something that > is a word, the funnier the better, easier to remember for our brains that > way. Can be 4 letters ;-) and will get you an Ack mention l;-) > > >> >> Now requirement to switch off miscabling detection is not acceptable. Yo= u >> are stating that only rift knows how should I cable my fabric ? >> > > No, it doesn't. You asked in your previous email for "red lights" when > topology is built incorrectly and you have it. Now you don't want it. Bot= h > states cannot be true @ the same time unless you are entangled ;-) > > > Node112 can actually even go haywire >> >> That may be not best property of a routing protocol :) >> >> > "haywire" is the wrong word. Rather, I should have said "it will even > allow that". Now, why would you want the same src/dst pair sometimes > shortcut on the horizontal link and sometimes go up to spine I can't > imagine but you ask for all kind of very non-obvious things you seem to > like so I'm just pointing the space of possibilities out to you ... > > > -- tony > --001a113c2ca23db6000562af300b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tony,

> The price of that would be that you can run strict SPF only the= n and loose all the non-equal cost forwarding, including true anycast.=C2= =A0

1. Did anyone really asked t= hat we should refrain from running "strict SPF" in DCs ? Contrary= I see group of folks keen on running it based on BGP-LS like feeds :)=C2= =A0

2. Is non-ECMP fwd-ing a fea= ture or a bug in DC fabric ? When I described to customers that with MPLS y= ou can run non ECMP load balancing it was shock .. but in WAN there are som= e use cases for it. But in DC fabric - I doubt it.=C2=A0
=
3. True anycast is clearly possible with native link= state and native distance vector. Why the new "hybrid" glue of b= oth would not allow it ? Because it counts on massive aggregation - right ?= =C2=A0

> Plus, once you think t= hat through in general sense you basically end up with host addresses every= where (since if you use aggregates you'll blackhole on link failures). = If you want to avoid SPF and host routes

<= /div>
Host routes are just leaves so they hang off nodes and do not make SPF a= ny harder. Besides I am not convinced that building flat underlays with 1M = host routes is the right architecture - even if some folks ask you about it= .=C2=A0

= Best,
R.

<= /div>



On Sat, Jan 13, 2018 at 9:05 PM, To= ny Przygienda <tonysietf@gmail.com> wrote:


On Sat, Jan 13, 2018 at 11:21 AM, R= obert Raszuk <robert@raszuk.net> wrote:
Hi Tony,

> =E2=80=8B
if you're willing to provision things correctly yours= elf via S-PGP.=C2=A0

I am not willing to do that. I would like routing to d= o it for me auto-magically.
The price of that would be that you can run strict SPF only the= n and loose all the non-equal cost forwarding, including true anycast. Plus= , once you think that through in general sense you basically end up with ho= st addresses everywhere (since if you use aggregates you'll blackhole o= n link failures). If you want to avoid SPF and host routes while still aski= ng for all the things you ask, then as a very experienced and highly regard= ed architect here puts it to end such discussions "your problem is ove= rly constrained" and there is no protocol/algebra whatsoever that will= give you that ...
=C2=A0
But yes you got the question right. I was asking for shortcuts between = last levels of fabric. Not so much between Node 111 & Node 112 - but yo= u said it is optional so ok.=C2=A0

Side note: PGP abbrev. for vast majority of peopl= e means completely different thing then what you defined it to mean locally= in your draft. I highly recommended you rename it in -05 version to PGD (p= olicy guided destination(s) or PGR (policy guided reachability/routing).=C2= =A0

Sigh, I warne= d when the acronym was picked.=C2=A0 Come up with something that is a word,= the funnier the better, easier to remember for our brains that way. Can be= 4 letters ;-)=C2=A0 and will get you an Ack mention l;-)
=C2=A0
=

Now requirement to switch off miscabling detection is not acceptable. You = are stating that only rift knows how should I cable my fabric ?

No, it doesn't. You ask= ed in your previous email for "red lights" when topology is built= incorrectly and you have it. Now you don't want it. Both states cannot= be true @ the same time unless you are entangled ;-)=C2=A0

=
> Node112 can actually even go haywire

That m= ay be not best property of a routing protocol :)=C2=A0


"haywire&qu= ot; is the wrong word. Rather,=C2=A0 I should have said "it will even = allow that". Now, why would you want the same src/dst pair sometimes s= hortcut on the horizontal link and sometimes go up to spine I can't ima= gine but you ask for all kind of very non-obvious things you seem to like s= o I'm just pointing the space of possibilities out to you ...
=

-- tony

--001a113c2ca23db6000562af300b-- From nobody Mon Jan 15 15:07:47 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7767812ECB8 for ; Mon, 15 Jan 2018 15:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 bw8yxOiub4i4 for ; Mon, 15 Jan 2018 15:07:41 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F350812EC9D for ; Mon, 15 Jan 2018 15:07:40 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0FN7cu9019427 for ; Mon, 15 Jan 2018 23:07:38 GMT Received: from 950129200 ([193.56.243.15]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id w0FN7bhQ019404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Jan 2018 23:07:38 GMT Reply-To: From: "Adrian Farrel" To: References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> In-Reply-To: <002601d38727$57b4b010$071e1030$@olddog.co.uk> Date: Mon, 15 Jan 2018 23:07:34 -0000 Message-ID: <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_029A_01D38E55.A1A780F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMzL2uhu7Viq2qc1OoXva7zQ+HgrgHGkmxToKgVmqA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23598.003 X-TM-AS-Result: No--24.119-10.0-31-10 X-imss-scan-details: No--24.119-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtFT7QvMcPWmSE4Et37YzhXUju+GX08gELBq4coTktrGX3w9 3dJCnn/PzIQR4qph2OiZ5rXmZbU9pTK42JVSvu3AA9lly13c/gEZbpN+hw0Kex9c+XdX53q+4MZ EpBAfSmL2iwPL/DVlBZSbvtxRhVumIU3qZgE1HXCxo9yzdPhMvaxwr8rYOW+OrY9uF6odMlz6Hz UbYzyTZRrOPS5/AuSaZCn+RolpoONGpu6xOWqZa68+ihL49RBy1Vt6Fa0LhuKtbmIBTxgsvjd5d t2gRgt4gbxuI02Hw4TO/WH+Jlz/QG1yv+64My/e9Ib/6w+1lWT6mRiZWXNny1LBqp/yXWJk+fSz 7TNMjtrNwwTsLpfty4UpDvxb+6yuxQrmDctU7afFlCgYxEaGE+imxgRHwEwm2m/9xxi5QYlDys8 dPtlQ3QkwKl1h7YFKX7i1MCO9Yls36KWWVzEGOMFWmsryu9ZfI5K4Cd+0ao+rhzX/yPmkeokyW8 Z13Bv2kD1Vp0N3nHWNanw0XyVihU8Aw2tCWJUVthSuSdSoQvtezmeoa8MJ8wQLUvnBZL2Kmec3x nR/JN/ATcK7E+4iY5yk89+C3M7xsn/vLFz1kV8uLk8NfSpYeh3fOSCz34UdydovWuL+KVd07+2Q NMSDJBFbcWj6Erewls1+C1BQP6RHW+94FA8JF8G0UNgaZpYqtF9GMNu1bqLkOOZ1bT6psa7BVPF MOQQusrZgdv+SJ0/88SAvS2rKrnRue7aQeqLEVF7yOiu4q2kgVvZV3BB2QNE6Er5EVajmW2E6A0 VjBlqQ0Ir9EHtCMQJIccaMDcUCF/JN69C1+RCeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyL3PDiXO /tFSYVH0dq7wY7u6x90gjcID+omAPTRnPo++N3YNOWu+ZMaylwdRr2ED9amXGPQGvk3DA== Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 23:07:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_029A_01D38E55.A1A780F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 I joined this list a little late to have a neat head of thread to = respond to, but here's a response to Alvaro's copy to = routing-discussion. =20 The charter text looks water-tight to me and I'd like to see this WG = formed so that the whole community can work on RIFT. =20 Maybe s/prominence/popularity/=20 =20 There is a problem with the indentation in the deliverables... OLD - A Standards Track specification based on draft-przygienda-rift. The = document will include: =20 - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is = configured, deployed, and diagnosed - Security and Privacy Considerations, although this material may = refer to a separate Threat Analysis document (q.v.). - A YANG module focused on configuration of protocol instances - An Applicability Statement that describes how to deploy and = configure the protocol in networks with different topologies - A Security Threat Analysis document that describes the attack = vectors and mitigations that shall be sent for publication at the same = time as the protocol specification. NEW - A Standards Track specification based on draft-przygienda-rift. The = document will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the = protocol is configured, deployed, and diagnosed - Security and Privacy Considerations, although this material may = refer to a separate Threat Analysis document (q.v.). - A YANG module focused on configuration of protocol instances - An Applicability Statement that describes how to deploy and = configure the protocol in networks with different topologies - A Security Threat Analysis document that describes the attack = vectors and mitigations that shall be sent for publication at the same = time as the protocol specification. END =20 Cheers, Adrian =20 =20 From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro Retana Sent: 06 January 2018 03:25 To: routing-discussion@ietf.org; rtgwg@ietf.org Subject: Fwd: [Rift] kicking off the charter discussion =20 FYI.. =20 If you are interested in this topic, please make comments and send = feedback on the rift@ietf.org list. =20 Thanks! =20 Alvaro. =20 On January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com) wrote: Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG = charters with Alvaro. Here is what we have so far. Comments and = improvements would be most welcome.=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Routing in Fat Trees (RIFT) Clos and Fat-Tree topologies have gained prominence in data center = networks as a result of a trend towards centralized data center network = architectures that may deliver computation and storage services. =20 The Routing in Fat Trees (RIFT) protocol addresses the demands of = routing in Clos and Fat-Tree networks via a mixture of both link-state = and distance-vector techniques colloquially described as 'link-state = towards the spine and distance vector towards the leafs'. RIFT uses = this hybrid approach to focus on networks with regular topologies with a = high degree of connectivity, a defined directionality, and large scale. The RIFT Working Group will work on a standards track specification of a = specialized, dynamic routing protocol for Clos and fat-tree network = topologies. The protocol will: - deal with automatic construction of fat-tree topologies based on = detection of links, - minimize the amount of routing state held at each topology level, - automatically prune topology distribution exchanges to a sufficient = subset of links, - support automatic disaggregation of prefixes on link and node failures = to prevent black-holing and suboptimal routing, - allow traffic steering and re-routing policies, - and provide mechanisms to synchronize a limited key-value data-store = that can be used after protocol convergence. It is important that nodes participating in the protocol should need = only very light configuration and should be able to join a network as = leaf nodes simply by connecting to the network using default = configuration. The protocol must support IPv6 and should also support IPv4. The Working Group may establish additional requirements to constrain and = inform their work. The RIFT Working Group is chartered for the following list of items: - A Standards Track specification based on draft-przygienda-rift. The = document will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is = configured, deployed, and diagnosed - Security and Privacy Considerations, although this material may = refer to a separate Threat Analysis document (q.v.). - A YANG module focused on configuration of protocol instances - An Applicability Statement that describes how to deploy and = configure the protocol in networks with different topologies - A Security Threat Analysis document that describes the attack = vectors and mitigations that shall be sent for publication at the same = time as the protocol specification. Milestones Feb 2018 Adopt a protocol specification document Feb 2019 Submit protocol specification to IESG for publication Feb 2019 Submit Threat Analysis to IESG for publication Apr 2019 Submit YANG module to IESG for publication Apr 2019 Submit Applicability Statement to IESG for publication=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks, Alia _______________________________________________=20 Rift mailing list=20 Rift@ietf.org=20 https://www.ietf.org/mailman/listinfo/rift=20 ------=_NextPart_000_029A_01D38E55.A1A780F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I joined this list a little late to have a neat = head of thread to respond to, but here's a response to Alvaro's copy to = routing-discussion.

 

The charter text looks water-tight to me and I'd = like to see this WG formed so that the whole community can work on = RIFT.

 

Maybe s/prominence/popularity/ =

 

There is a problem with the indentation in the = deliverables...

OLD

- A Standards Track specification based on = draft-przygienda-rift. The document will = include:

 

=C2=A0 - = an Implementation Status section as described in RFC = 7942

=C2=A0 - = an Operational Considerations section to explain how the protocol is = configured, deployed, and diagnosed

=C2=A0 - = Security and Privacy Considerations, although this material may refer to = a separate Threat Analysis document (q.v.).

=C2=A0 - A = YANG module focused on configuration of protocol = instances

=C2=A0 - = An Applicability Statement that describes how to deploy and configure = the protocol in networks with different = topologies

=C2=A0 - A = Security Threat Analysis document that describes the attack vectors and = mitigations that shall be sent for publication at the same time as the = protocol specification.

NEW

- A Standards Track specification based on = draft-przygienda-rift. The document will = include:

=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0- an Implementation Status = section as described in RFC 7942

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0- an Operational = Considerations section to explain how the protocol is configured, = deployed, and diagnosed

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0- Security and Privacy = Considerations, although this material may refer to a separate Threat = Analysis document (q.v.).

=C2=A0 - A = YANG module focused on configuration of protocol = instances

=C2=A0 - = An Applicability Statement that describes how to deploy and configure = the protocol in networks with different = topologies

=C2=A0 - A = Security Threat Analysis document that describes the attack vectors and = mitigations that shall be sent for publication at the same time as the = protocol specification.

END

 

Cheers,

Adrian

 

 

From: rtgwg = [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro = Retana
Sent: 06 January 2018 03:25
To: = routing-discussion@ietf.org; rtgwg@ietf.org
Subject: Fwd: = [Rift] kicking off the charter = discussion

 

FYI..

 

If you are interested in this topic, = please make comments and send feedback on the rift@ietf.org list.

 

Thanks!

 

Alvaro.

 

On = January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com) = wrote:

Tony, Jeffrey Zhang, I, and others have = been discussing possible RIFT WG charters with Alvaro.  Here is = what we have so far.  Comments and improvements would be most = welcome.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Routing in Fat Trees (RIFT)

Clos = and Fat-Tree topologies have gained prominence in data center networks = as a result of a trend towards centralized data center network = architectures that may deliver computation and storage = services.
 
The Routing in Fat Trees (RIFT) protocol = addresses the demands of routing in Clos and Fat-Tree networks via a = mixture of both link-state and distance-vector techniques colloquially = described as 'link-state towards the spine and distance vector towards = the leafs'.  RIFT uses this hybrid approach to focus on networks = with regular topologies with a high degree of connectivity, a defined = directionality, and large scale.

The RIFT Working Group will work = on a standards track specification of a specialized, dynamic routing = protocol for Clos and fat-tree network topologies. The protocol = will:

- deal with automatic construction of fat-tree topologies = based on detection of links,
- minimize the amount of routing state = held at each topology level,
- automatically prune topology = distribution exchanges to a sufficient subset of links,
- = support automatic disaggregation of prefixes on link and node failures = to prevent black-holing and suboptimal routing,
- allow traffic = steering and re-routing policies,
- and provide mechanisms to = synchronize a limited key-value data-store that can be used after = protocol convergence.

It is important that nodes participating in = the protocol should need only very light configuration and should be = able to join a network as leaf nodes simply by connecting to the network = using default configuration.

The protocol must support IPv6 and = should also support IPv4.

The Working Group may establish = additional requirements to constrain and inform their work.

The = RIFT Working Group is chartered for the following list of = items:

- A Standards Track specification based on = draft-przygienda-rift. The document will include:

  - an = Implementation Status section as described in RFC 7942
  - an = Operational Considerations section to explain how the protocol is = configured, deployed, and diagnosed
  - Security and Privacy = Considerations, although this material may refer to a separate Threat = Analysis document (q.v.).
  - A YANG module focused on = configuration of protocol instances
  - An Applicability = Statement that describes how to deploy and configure the protocol in = networks with different topologies
  - A Security Threat = Analysis document that describes the attack vectors and mitigations that = shall be sent for publication at the same time as the protocol = specification.

Milestones

  Feb 2018 Adopt a protocol = specification document
  Feb 2019 Submit protocol specification = to IESG for publication
  Feb 2019 Submit Threat Analysis to = IESG for publication
  Apr 2019 Submit YANG module to IESG for = publication
  Apr 2019 Submit Applicability Statement to IESG = for publication

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks,

Alia=

_______________________________________________
Rift mailing = list
Rift@ietf.org
https://www.ietf.org/= mailman/listinfo/rift =

<= /html> ------=_NextPart_000_029A_01D38E55.A1A780F0-- From nobody Mon Jan 15 15:23:54 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922DF12ECB7 for ; Mon, 15 Jan 2018 15:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 h_IHiG1aRBqD for ; Mon, 15 Jan 2018 15:23:50 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 E378D12D88D for ; Mon, 15 Jan 2018 15:23:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CC29B4A20B5 for ; Mon, 15 Jan 2018 15:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1516058629; bh=KoKtWM3jGx05nvuw/KLF/xMujhMkbxPnka6yi5i92LA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=cLj9xrvj0V834Oj+iDZ+ISHpKIkVKIvhTwThtoGs/f2vsharl3djgHWwFcn78YwWT KFS5GvRT0EhmqkanySHSp6BTrG7J9OBDMrzuWD1rdTcBppJdzQYb7vPq4PmEKzFjJQ aPcdtH+3FY01rDEmGM5sGcpX5DY+iUcGhdByUlHs= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6BEE84A20A9 for ; Mon, 15 Jan 2018 15:23:49 -0800 (PST) To: rift@ietf.org References: From: "Joel M. Halpern" Message-ID: <64ca4f21-a7b8-6414-eb38-1a7cdb2f6fa6@joelhalpern.com> Date: Mon, 15 Jan 2018 18:23:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rift] Fwd: kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 23:23:52 -0000 I haven't commented because this seemed clear. Sure, folks can argue that we don't need this. We can just fine-tune existing things. And we will. Even so, this seems potentially very useful. And explorse a part of the space we do not ahve a lot of experience engineering. In a bounded fashion. Seems like it is worth doing to me. Yours, Joel On 1/5/18 10:24 PM, Alvaro Retana wrote: > FYI.. > > If you are interested in this topic, please make comments and send > feedback on the rift@ietf.org  list. > > Thanks! > > Alvaro. > > On January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com > ) wrote: > >> Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT >> WG charters with Alvaro.  Here is what we have so far.  Comments and >> improvements would be most welcome. >> >> ================ >> Routing in Fat Trees (RIFT) >> >> Clos and Fat-Tree topologies have gained prominence in data center >> networks as a result of a trend towards centralized data center >> network architectures that may deliver computation and storage services. >> >> The Routing in Fat Trees (RIFT) protocol addresses the demands of >> routing in Clos and Fat-Tree networks via a mixture of both link-state >> and distance-vector techniques colloquially described as 'link-state >> towards the spine and distance vector towards the leafs'.  RIFT uses >> this hybrid approach to focus on networks with regular topologies with >> a high degree of connectivity, a defined directionality, and large scale. >> >> The RIFT Working Group will work on a standards track specification of >> a specialized, dynamic routing protocol for Clos and fat-tree network >> topologies. The protocol will: >> >> - deal with automatic construction of fat-tree topologies based on >> detection of links, >> - minimize the amount of routing state held at each topology level, >> - automatically prune topology distribution exchanges to a >> sufficient subset of links, >> - support automatic disaggregation of prefixes on link and node >> failures to prevent black-holing and suboptimal routing, >> - allow traffic steering and re-routing policies, >> - and provide mechanisms to synchronize a limited key-value data-store >> that can be used after protocol convergence. >> >> It is important that nodes participating in the protocol should need >> only very light configuration and should be able to join a network as >> leaf nodes simply by connecting to the network using default >> configuration. >> >> The protocol must support IPv6 and should also support IPv4. >> >> The Working Group may establish additional requirements to constrain >> and inform their work. >> >> The RIFT Working Group is chartered for the following list of items: >> >> - A Standards Track specification based on draft-przygienda-rift. The >> document will include: >> >>   - an Implementation Status section as described in RFC 7942 >>   - an Operational Considerations section to explain how the protocol >> is configured, deployed, and diagnosed >>   - Security and Privacy Considerations, although this material may >> refer to a separate Threat Analysis document (q.v.). >>   - A YANG module focused on configuration of protocol instances >>   - An Applicability Statement that describes how to deploy and >> configure the protocol in networks with different topologies >>   - A Security Threat Analysis document that describes the attack >> vectors and mitigations that shall be sent for publication at the same >> time as the protocol specification. >> >> Milestones >> >>   Feb 2018 Adopt a protocol specification document >>   Feb 2019 Submit protocol specification to IESG for publication >>   Feb 2019 Submit Threat Analysis to IESG for publication >>   Apr 2019 Submit YANG module to IESG for publication >>   Apr 2019 Submit Applicability Statement to IESG for publication >> >> ============ >> >> Thanks, >> >> Alia >> >> _______________________________________________ >> Rift mailing list >> Rift@ietf.org >> https://www.ietf.org/mailman/listinfo/rift > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > From nobody Mon Jan 15 16:44:50 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9D5120047; Mon, 15 Jan 2018 16:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 l9OEhOIMOb1z; Mon, 15 Jan 2018 16:44:47 -0800 (PST) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C47C12D883; Mon, 15 Jan 2018 16:44:47 -0800 (PST) Received: by mail-pl0-x22b.google.com with SMTP id d21so4848350pll.1; Mon, 15 Jan 2018 16:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=/aXVc0bxAxusyFW/ZqZCQAfCfRKeVAIHVoIi3VG/CrQ=; b=B+AruA10WwG02Z5dv3pbAeFqwNJ+ywd0Z/K++WMubSR/GgcofrQ9dgzlJqPTHMu7He /uQc3ElNNvxYIOid4SOYwETXv4C6Msp+iQbkVQLhAUfuoVZkMPVapcSBMJ1p2LZYjfKD 0tLOWwrrYlVqU13C9RX6QU/uUDN/DXlPLpyHGjlgjZEx03psBJyHvIn+TNYDt6pHX45N i6zdYi9iFW7WFW6l3AdgIBqmvMJ27J75QUVnqKrqEf2TLeL3zNdFeO9VGD0N4+fESt/F VCTD4XBKs7ioOCbR5tgDn6g1bV/ttoloHJIJX9ZkICvR40lgytJ+kNsRUAD0hzncdSuS VrqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=/aXVc0bxAxusyFW/ZqZCQAfCfRKeVAIHVoIi3VG/CrQ=; b=EWUJVrA7J0/RJRSjnPv/U8VrEmK1ovoJGI9EJYG9/WVn36nE3PgRvVu1tWB0WWFGFX 6WkIk8sJtH3cItXF804Vg+bx77nR6mKvk9iaKLGKBvKr1BFyG53h7RZqc7EQSslx3BWU aqCajqZJMgiDN95NC3zZ4MIyAYa+rIjJKpUqMum6ox8aAEPHxZtOwgk7emlrSmZtFa3k gDu4H04h2fohYVU6u3KGKtkCt5fQtAQOLeHhuDL7134KlyvvJx/Ru6b3cGSj0zfK+JI8 eLGdm7o6S3lBZLpcHn5Vjnu+JM1G8YBoPWj1eNJmQrTVr54b63MDTpuln+1RjU0+blaq zLvw== X-Gm-Message-State: AKGB3mLyaHWuUDPmWa+0YdJEDfMGVrZZGizlzKnwfky8Argvf7eEwbRi pfE806xh0CYZak7cnEvqH8F4Bg== X-Google-Smtp-Source: ACJfBoubQit0Af/YDnbLZgLwmsx6Fnabk4mUJtqGJgzNQAi0d/VXeTF2xHJRwtZRJj9X1077RMJrjg== X-Received: by 10.84.241.194 with SMTP id t2mr37692878plm.318.1516063486445; Mon, 15 Jan 2018 16:44:46 -0800 (PST) Received: from [192.168.1.25] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id e12sm753271pgu.48.2018.01.15.16.44.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jan 2018 16:44:45 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Mon, 15 Jan 2018 16:44:44 -0800 From: Jeff Tantsura To: , routing-discussion Message-ID: <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> Thread-Topic: [Rift] kicking off the charter discussion References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> In-Reply-To: <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3598879485_2083440032" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 00:44:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3598879485_2083440032 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi, =20 I find Adrian=E2=80=99s changes perfect and support the charter as per below. Due to changes in my working situation I didn=E2=80=99t quite participate in init= ial discussion, starting now. =20 I have got some ideas of using THRIFT/gRPC alike encoding schema=E2=80=99s for mo= re, than RIFT currently defines, for later thought. =20 Cheers, Jeff =20 From: Rift on behalf of Adrian Farrel Reply-To: Date: Monday, January 15, 2018 at 15:07 To: Subject: Re: [Rift] kicking off the charter discussion =20 Hi, =20 I joined this list a little late to have a neat head of thread to respond t= o, but here's a response to Alvaro's copy to routing-discussion. =20 The charter text looks water-tight to me and I'd like to see this WG formed= so that the whole community can work on RIFT. =20 Maybe s/prominence/popularity/=20 =20 There is a problem with the indentation in the deliverables... OLD - A Standards Track specification based on draft-przygienda-rift. The docum= ent will include: =20 =C2=A0 - an Implementation Status section as described in RFC 7942 =C2=A0 - an Operational Considerations section to explain how the protocol is c= onfigured, deployed, and diagnosed =C2=A0 - Security and Privacy Considerations, although this material may refer = to a separate Threat Analysis document (q.v.). =C2=A0 - A YANG module focused on configuration of protocol instances =C2=A0 - An Applicability Statement that describes how to deploy and configure = the protocol in networks with different topologies =C2=A0 - A Security Threat Analysis document that describes the attack vectors = and mitigations that shall be sent for publication at the same time as the p= rotocol specification. NEW - A Standards Track specification based on draft-przygienda-rift. The docum= ent will include: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - an Implementation Status section as described in RFC 7942 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - an Operational Considerations section to explain how the proto= col is configured, deployed, and diagnosed =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Security and Privacy Considerations, although this material = may refer to a separate Threat Analysis document (q.v.). =C2=A0 - A YANG module focused on configuration of protocol instances =C2=A0 - An Applicability Statement that describes how to deploy and configure = the protocol in networks with different topologies =C2=A0 - A Security Threat Analysis document that describes the attack vectors = and mitigations that shall be sent for publication at the same time as the p= rotocol specification. END =20 Cheers, Adrian =20 =20 From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro Retana Sent: 06 January 2018 03:25 To: routing-discussion@ietf.org; rtgwg@ietf.org Subject: Fwd: [Rift] kicking off the charter discussion =20 FYI.. =20 If you are interested in this topic, please make comments and send feedback= on the rift@ietf.org list. =20 Thanks! =20 Alvaro. =20 On January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com) wrote: Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG ch= arters with Alvaro. Here is what we have so far. Comments and improvements= would be most welcome.=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Routing in Fat Trees (RIFT) Clos and Fat-Tree topologies have gained prominence in data center networks= as a result of a trend towards centralized data center network architecture= s that may deliver computation and storage services. =20 The Routing in Fat Trees (RIFT) protocol addresses the demands of routing i= n Clos and Fat-Tree networks via a mixture of both link-state and distance-v= ector techniques colloquially described as 'link-state towards the spine and= distance vector towards the leafs'. RIFT uses this hybrid approach to focu= s on networks with regular topologies with a high degree of connectivity, a = defined directionality, and large scale. The RIFT Working Group will work on a standards track specification of a sp= ecialized, dynamic routing protocol for Clos and fat-tree network topologies= . The protocol will: - deal with automatic construction of fat-tree topologies based on detectio= n of links, - minimize the amount of routing state held at each topology level, - automatically prune topology distribution exchanges to a sufficient subse= t of links, - support automatic disaggregation of prefixes on link and node failures to= prevent black-holing and suboptimal routing, - allow traffic steering and re-routing policies, - and provide mechanisms to synchronize a limited key-value data-store that= can be used after protocol convergence. It is important that nodes participating in the protocol should need only v= ery light configuration and should be able to join a network as leaf nodes s= imply by connecting to the network using default configuration. The protocol must support IPv6 and should also support IPv4. The Working Group may establish additional requirements to constrain and in= form their work. The RIFT Working Group is chartered for the following list of items: - A Standards Track specification based on draft-przygienda-rift. The docum= ent will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is co= nfigured, deployed, and diagnosed - Security and Privacy Considerations, although this material may refer t= o a separate Threat Analysis document (q.v.). - A YANG module focused on configuration of protocol instances - An Applicability Statement that describes how to deploy and configure t= he protocol in networks with different topologies - A Security Threat Analysis document that describes the attack vectors a= nd mitigations that shall be sent for publication at the same time as the pr= otocol specification. Milestones Feb 2018 Adopt a protocol specification document Feb 2019 Submit protocol specification to IESG for publication Feb 2019 Submit Threat Analysis to IESG for publication Apr 2019 Submit YANG module to IESG for publication Apr 2019 Submit Applicability Statement to IESG for publication=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks, Alia _______________________________________________=20 Rift mailing list=20 Rift@ietf.org=20 https://www.ietf.org/mailman/listinfo/rift=20 _______________________________________________ Rift mailing list Rift@ietf= .org https://www.ietf.org/mailman/listinfo/rift=20 --B_3598879485_2083440032 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi,

 

I find Adrian=E2=80=99s changes perfect and support the charter= as per below.

Due to changes in my working situ= ation I didn=E2=80=99t quite participate in initial discussion, starting now.=

 

I have got some i= deas of using THRIFT/gRPC alike encoding schema=E2=80=99s for more, than RIFT curr= ently defines, for later thought.

 

Cheers,

Jeff

 

From: Rift <rift-bounces@ietf.org> on behalf of Adrian Farr= el <adrian@olddog.co.uk>
Reply-To: <adrian@olddog.co.uk&g= t;
Date: Monday, January 15, 2018 at 15:07
To: <rift@= ietf.org>
Subject: Re: [Rift] kicking off the charter discussio= n

 

Hi,

 

I joined this list a little late to have a neat head of thread to resp= ond to, but here's a response to Alvaro's copy to routing-discussion.=

 

The charter text looks water-tight to me and I'd like to see this W= G formed so that the whole community can work on RIFT.

=

 

Maybe = s/prominence/popularity/

 

There is a problem with the indenta= tion in the deliverables...

OLD

- A Standards Track specification ba= sed on draft-przygienda-rift. The document will include:

 

=C2=A0 -= an Implementation Status section as described in RFC 7942=

=C2=A0 - an Operational Considerations section to expla= in how the protocol is configured, deployed, and diagnosed=

=C2=A0 - Security and Privacy Considerations, although = this material may refer to a separate Threat Analysis document (q.v.).

=C2=A0 - A YANG module focused on configura= tion of protocol instances

=C2=A0 - An= Applicability Statement that describes how to deploy and configure the prot= ocol in networks with different topologies

=C2=A0 - A Security Threat Analysis document that describes the attack = vectors and mitigations that shall be sent for publication at the same time = as the protocol specification.

NEW=

- A Standards Track specification= based on draft-przygienda-rift. The document will include:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - an Implementation Status section as d= escribed in RFC 7942

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - = an Operational Considerations section to explain how the protocol is configu= red, deployed, and diagnosed

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - Security and Privacy Considerations, although this material may re= fer to a separate Threat Analysis document (q.v.).

=C2=A0 - A YANG module focused on configuration of protocol ins= tances

=C2=A0 - An Applicability State= ment that describes how to deploy and configure the protocol in networks wit= h different topologies

=C2=A0 - A Secu= rity Threat Analysis document that describes the attack vectors and mitigati= ons that shall be sent for publication at the same time as the protocol spec= ification.

END

 

Chee= rs,

Adrian

 

 

From: rtgwg [mailto:rtgwg-boun= ces@ietf.org] On Behalf Of Alvaro Retana
Sent: 06 January 2= 018 03:25
To: routing-discussion@ietf.org; rtgwg@ietf.org
Su= bject: Fwd: [Rift] kicking off the charter discussion<= /p>

 

FYI..

<= p class=3DMsoNormal> 

If you are interested in this topic, please make comments and send feedbac= k on the rift@ietf.org list.<= o:p>

 

Thanks!<= /p>

 

Alvaro.

 

On January 5, 2018 at 3:03:25 AM= , Alia Atlas (akatlas@gmail.com) wrot= e:

Tony, Jeffrey Zhang, I, and others have been di= scussing possible RIFT WG charters with Alvaro.  Here is what we have s= o far.  Comments and improvements would be most welcome.

 

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Routing in Fat Trees (RI= FT)

Clos and Fat-Tree topologies have gained prominence in data cente= r networks as a result of a trend towards centralized data center network ar= chitectures that may deliver computation and storage services.
 
= The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in= Clos and Fat-Tree networks via a mixture of both link-state and distance-ve= ctor techniques colloquially described as 'link-state towards the spine and = distance vector towards the leafs'.  RIFT uses this hybrid approach to = focus on networks with regular topologies with a high degree of connectivity= , a defined directionality, and large scale.

The RIFT Working Group w= ill work on a standards track specification of a specialized, dynamic routin= g protocol for Clos and fat-tree network topologies. The protocol will:
<= br>- deal with automatic construction of fat-tree topologies based on detect= ion of links,
- minimize the amount of routing state held at each topolog= y level,
- automatically prune topology distribution exchanges to a suffi= cient subset of links,
- support automatic disaggregation of prefixe= s on link and node failures to prevent black-holing and suboptimal routing,<= br>- allow traffic steering and re-routing policies,
- and provide mechan= isms to synchronize a limited key-value data-store that can be used aft= er protocol convergence.

It is important that nodes participating in = the protocol should need only very light configuration and should be able to= join a network as leaf nodes simply by connecting to the network using defa= ult configuration.

The protocol must support IPv6 and should also sup= port IPv4.

The Working Group may establish additional requirements to= constrain and inform their work.

The RIFT Working Group is chartered= for the following list of items:

- A Standards Track specification b= ased on draft-przygienda-rift. The document will include:

  - an= Implementation Status section as described in RFC 7942
  - an Opera= tional Considerations section to explain how the protocol is configured, dep= loyed, and diagnosed
  - Security and Privacy Considerations, althou= gh this material may refer to a separate Threat Analysis document (q.v.).  - A YANG module focused on configuration of protocol instances
&n= bsp; - An Applicability Statement that describes how to deploy and configure= the protocol in networks with different topologies
  - A Security T= hreat Analysis document that describes the attack vectors and mitigations th= at shall be sent for publication at the same time as the protocol specificat= ion.

Milestones

  Feb 2018 Adopt a protocol specification= document
  Feb 2019 Submit protocol specification to IESG for publi= cation
  Feb 2019 Submit Threat Analysis to IESG for publication
=   Apr 2019 Submit YANG module to IESG for publication
  Apr 201= 9 Submit Applicability Statement to IESG for publication <= /p>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks,

Alia

_______________________________________________
Rift mailing list =
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift=

_____= __________________________________________ Rift mailing list Rift@ietf.org h= ttps://www.ietf.org/mailman/listinfo/rift

--B_3598879485_2083440032-- From nobody Tue Jan 16 02:04:46 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C27112D950 for ; Tue, 16 Jan 2018 02:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 bVECHI60v8Bq for ; Tue, 16 Jan 2018 02:04:43 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB1512D955 for ; Tue, 16 Jan 2018 02:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32994; q=dns/txt; s=iport; t=1516097082; x=1517306682; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=gfQ0FKl9TT2zw1aaC8AMF6bOuWSuQed76ohtkeWrPY8=; b=lVSEScnJl4yxwQj6SgB0IBbgUBox0TbOBYdydDnndfl2Cp+x973DNqOs SoH9Y4GU0YNcNGwngvwIppCCab4lELJjrYoMn5+KmyQaWdHQtf4iCYDjv ofMORopYmlulB0EEtH8E6TM1RJSt6RL32VHce1FbwMRB6YCeCnIymebfj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAQAEzl1a/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKR4EWdCeEE4sYj0YniQaOJoITAwoYAQqFGAKFFxcBAQEBAQE?= =?us-ascii?q?BAQFrKIUjAQEBAQMBASFJAhsJAhEDAQEBASABBgMCAiEGHwkIBgEMBgIBARCKB?= =?us-ascii?q?wMVEIh1nXCCJyaHEg2CBAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhDiDcIFpKQy?= =?us-ascii?q?Ba4EOgmtEAQECgUgTNBaCYYJlBZlyiTU9iSyCDIURhQKCGYYdg2+Ha41+gR6IC?= =?us-ascii?q?YE8IQM0JYErMhoIGxU9giqEV0E3inkBJoIkAQEB?= X-IronPort-AV: E=Sophos;i="5.46,367,1511827200"; d="scan'208,217";a="1424121" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 10:04:24 +0000 Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0GA4ON9016953; Tue, 16 Jan 2018 10:04:24 GMT To: Jeff Tantsura , rift@ietf.org References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> From: Robert Wilton Message-ID: <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> Date: Tue, 16 Jan 2018 10:04:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> Content-Type: multipart/alternative; boundary="------------1D34EDCF1E42457671EAB853" Content-Language: en-US Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 10:04:46 -0000 This is a multi-part message in MIME format. --------------1D34EDCF1E42457671EAB853 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I was actually wondering whether it wouldn't be better for RIFT to use CBOR encoding rather than Thrift or protobuf (that the draft suggests as a possible alternative). Are there reasons why Thrift is a better choice that CBOR (given that CBOR is IETF specified)? Thanks, Rob On 16/01/2018 00:44, Jeff Tantsura wrote: > > Hi, > > I find Adrian’s changes perfect and support the charter as per below. > > Due to changes in my working situation I didn’t quite participate in > initial discussion, starting now. > > I have got some ideas of using THRIFT/gRPC alike encoding schema’s for > more, than RIFT currently defines, for later thought. > > Cheers, > > Jeff > > *From: *Rift on behalf of Adrian Farrel > > *Reply-To: * > *Date: *Monday, January 15, 2018 at 15:07 > *To: * > *Subject: *Re: [Rift] kicking off the charter discussion > > Hi, > > I joined this list a little late to have a neat head of thread to > respond to, but here's a response to Alvaro's copy to routing-discussion. > > The charter text looks water-tight to me and I'd like to see this WG > formed so that the whole community can work on RIFT. > > Maybe s/prominence/popularity/ > > There is a problem with the indentation in the deliverables... > > OLD > > - A Standards Track specification based on draft-przygienda-rift. The > document will include: > > - an Implementation Status section as described in RFC 7942 > > - an Operational Considerations section to explain how the protocol is > configured, deployed, and diagnosed > > - Security and Privacy Considerations, although this material may > refer to a separate Threat Analysis document (q.v.). > > - A YANG module focused on configuration of protocol instances > > - An Applicability Statement that describes how to deploy and > configure the protocol in networks with different topologies > > - A Security Threat Analysis document that describes the attack > vectors and mitigations that shall be sent for publication at the same > time as the protocol specification. > > NEW > > - A Standards Track specification based on draft-przygienda-rift. The > document will include: > > - an Implementation Status section as described in RFC 7942 > > - an Operational Considerations section to explain how the protocol is > configured, deployed, and diagnosed > > - Security and Privacy Considerations, although this material may > refer to a separate Threat Analysis document (q.v.). > > - A YANG module focused on configuration of protocol instances > > - An Applicability Statement that describes how to deploy and > configure the protocol in networks with different topologies > > - A Security Threat Analysis document that describes the attack > vectors and mitigations that shall be sent for publication at the same > time as the protocol specification. > > END > > Cheers, > > Adrian > > *From:*rtgwg [mailto:rtgwg-bounces@ietf.org] *On Behalf Of *Alvaro Retana > *Sent:* 06 January 2018 03:25 > *To:* routing-discussion@ietf.org; rtgwg@ietf.org > *Subject:* Fwd: [Rift] kicking off the charter discussion > > FYI.. > > If you are interested in this topic, please make comments and send > feedback on the rift@ietf.org  list. > > Thanks! > > Alvaro. > > On January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com > ) wrote: > > Tony, Jeffrey Zhang, I, and others have been discussing possible > RIFT WG charters with Alvaro.  Here is what we have so far.  > Comments and improvements would be most welcome. > > ================ > > Routing in Fat Trees (RIFT) > > Clos and Fat-Tree topologies have gained prominence in data center > networks as a result of a trend towards centralized data center > network architectures that may deliver computation and storage > services. > > The Routing in Fat Trees (RIFT) protocol addresses the demands of > routing in Clos and Fat-Tree networks via a mixture of both > link-state and distance-vector techniques colloquially described > as 'link-state towards the spine and distance vector towards the > leafs'.  RIFT uses this hybrid approach to focus on networks with > regular topologies with a high degree of connectivity, a defined > directionality, and large scale. > > The RIFT Working Group will work on a standards track > specification of a specialized, dynamic routing protocol for Clos > and fat-tree network topologies. The protocol will: > > - deal with automatic construction of fat-tree topologies based on > detection of links, > - minimize the amount of routing state held at each topology level, > - automatically prune topology distribution exchanges to a > sufficient subset of links, > - support automatic disaggregation of prefixes on link and node > failures to prevent black-holing and suboptimal routing, > - allow traffic steering and re-routing policies, > - and provide mechanisms to synchronize a limited key-value > data-store that can be used after protocol convergence. > > It is important that nodes participating in the protocol should > need only very light configuration and should be able to join a > network as leaf nodes simply by connecting to the network using > default configuration. > > The protocol must support IPv6 and should also support IPv4. > > The Working Group may establish additional requirements to > constrain and inform their work. > > The RIFT Working Group is chartered for the following list of items: > > - A Standards Track specification based on draft-przygienda-rift. > The document will include: > >   - an Implementation Status section as described in RFC 7942 >   - an Operational Considerations section to explain how the > protocol is configured, deployed, and diagnosed >   - Security and Privacy Considerations, although this material > may refer to a separate Threat Analysis document (q.v.). >   - A YANG module focused on configuration of protocol instances >   - An Applicability Statement that describes how to deploy and > configure the protocol in networks with different topologies >   - A Security Threat Analysis document that describes the attack > vectors and mitigations that shall be sent for publication at the > same time as the protocol specification. > > Milestones > >   Feb 2018 Adopt a protocol specification document >   Feb 2019 Submit protocol specification to IESG for publication >   Feb 2019 Submit Threat Analysis to IESG for publication >   Apr 2019 Submit YANG module to IESG for publication >   Apr 2019 Submit Applicability Statement to IESG for publication > > ============ > > Thanks, > > Alia > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift > > _______________________________________________ Rift mailing list > Rift@ietf.org https://www.ietf.org/mailman/listinfo/rift > > > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift --------------1D34EDCF1E42457671EAB853 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I was actually wondering whether it wouldn't be better for RIFT to use CBOR encoding rather than Thrift or protobuf (that the draft suggests as a possible alternative).

Are there reasons why Thrift is a better choice that CBOR (given that CBOR is IETF specified)?

Thanks,
Rob


On 16/01/2018 00:44, Jeff Tantsura wrote:

Hi,

 

I find Adrian’s changes perfect and support the charter as per below.

Due to changes in my working situation I didn’t quite participate in initial discussion, starting now.

 

I have got some ideas of using THRIFT/gRPC alike encoding schema’s for more, than RIFT currently defines, for later thought.

 

Cheers,

Jeff

 

From: Rift <rift-bounces@ietf.org> on behalf of Adrian Farrel <adrian@olddog.co.uk>
Reply-To: <adrian@olddog.co.uk>
Date: Monday, January 15, 2018 at 15:07
To: <rift@ietf.org>
Subject: Re: [Rift] kicking off the charter discussion

 

Hi,

 

I joined this list a little late to have a neat head of thread to respond to, but here's a response to Alvaro's copy to routing-discussion.

 

The charter text looks water-tight to me and I'd like to see this WG formed so that the whole community can work on RIFT.

 

Maybe s/prominence/popularity/

 

There is a problem with the indentation in the deliverables...

OLD

- A Standards Track specification based on draft-przygienda-rift. The document will include:

 

  - an Implementation Status section as described in RFC 7942

  - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed

  - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).

  - A YANG module focused on configuration of protocol instances

  - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies

  - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

NEW

- A Standards Track specification based on draft-przygienda-rift. The document will include:

      - an Implementation Status section as described in RFC 7942

      - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed

       - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).

  - A YANG module focused on configuration of protocol instances

  - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies

  - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

END

 

Cheers,

Adrian

 

 

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro Retana
Sent: 06 January 2018 03:25
To: routing-discussion@ietf.org; rtgwg@ietf.org
Subject: Fwd: [Rift] kicking off the charter discussion

 

FYI..

 

If you are interested in this topic, please make comments and send feedback on the rift@ietf.org list.

 

Thanks!

 

Alvaro.

 

On January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com) wrote:

Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG charters with Alvaro.  Here is what we have so far.  Comments and improvements would be most welcome.

 

================

Routing in Fat Trees (RIFT)

Clos and Fat-Tree topologies have gained prominence in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services.
 
The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'.  RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale.

The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will:

- deal with automatic construction of fat-tree topologies based on detection of links,
- minimize the amount of routing state held at each topology level,
- automatically prune topology distribution exchanges to a sufficient subset of links,
- support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing,
- allow traffic steering and re-routing policies,
- and provide mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence.

It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration.

The protocol must support IPv6 and should also support IPv4.

The Working Group may establish additional requirements to constrain and inform their work.

The RIFT Working Group is chartered for the following list of items:

- A Standards Track specification based on draft-przygienda-rift. The document will include:

  - an Implementation Status section as described in RFC 7942
  - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed
  - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).
  - A YANG module focused on configuration of protocol instances
  - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies
  - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

Milestones

  Feb 2018 Adopt a protocol specification document
  Feb 2019 Submit protocol specification to IESG for publication
  Feb 2019 Submit Threat Analysis to IESG for publication
  Apr 2019 Submit YANG module to IESG for publication
  Apr 2019 Submit Applicability Statement to IESG for publication

============

Thanks,

Alia

_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift

_______________________________________________ Rift mailing list Rift@ietf.org https://www.ietf.org/mailman/listinfo/rift 



_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift

--------------1D34EDCF1E42457671EAB853-- From nobody Tue Jan 16 09:09:51 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9066912E88E for ; Tue, 16 Jan 2018 09:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 DX6UzZ3-kQ5g for ; Tue, 16 Jan 2018 09:09:43 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 2387912E88D for ; Tue, 16 Jan 2018 09:09:43 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id i11so10042439wmf.4 for ; Tue, 16 Jan 2018 09:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o99yawSk7v/ylhUHzkTXPveISrYs05DIBXxCbUNALnk=; b=SceGB9+puHh1uNFGrjNzb7PMDy08OM5+HREXinDC0W/HFhU4xbFZfYe0W/weEYbhkj 2jHbe2ILiNj243GE/z663WuzbQmjZ8vXrzHQBAohRC5YSmrkhx7XuHGNvUrNFgS+FSXL E7pJFh2nYqTzJm4GiO6QPsU5nwOaj6TNa+HNZ9NVHwbzVMGF4BXXyqgV9MszwjYVcP+S bLJUcSE5xgslAlLp6L81EYc2384hm0+6abkTt4VbiCGMWsDwu2N1qA/qXRa8bQbn6PaI B38Re+k74qzX0TWpWy6O8hZrgj3ZJUBCIuMDyG+Dr2IOLNieHr5W1KNBy6CYk+LYOUkv mIMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o99yawSk7v/ylhUHzkTXPveISrYs05DIBXxCbUNALnk=; b=Vfp3rtRVzDOA58BXM3vR2kYFWVnzS5rUiuTOhMBM2sJv9+1fllMnedxZAMSrRJcVog 02bVOH9oaEfHoN6r4xuZfu5pDwh0j7ziqNxVDhLKScPKy/dnQYYHlkki1cSPpU6Q6n/O aymr5lX5MkLjHUmfhArTHe0CwZ/1aZIeB/GvTJVuBERpL5irjJM2pTNTRtT+U/8GnHlU eLH9nstjKF6Nusbk2f6h2UYI0OhUZoE4ZQuXzeZGDBcso0wP3Z/rit8gEEasr32QYZ1x zP/tbvOFdAobKlYk5DUMBdzPbYqBHPzCV9xMrsCseY+yR6D0N9HenT1XcEYDqvP5SYUI Tc2Q== X-Gm-Message-State: AKwxytd2VK3twp4hILjxdYobKpT+q39DHMcWKICu5UnDI2lSVNexVO5L XsHeIgp80qb2t3F12Ss1W87ODcUmfXIxbKxECfnzFQ== X-Google-Smtp-Source: ACJfBos0kI4nc+/DwI7EIu8eSJFegLdh5AWVPN7m2a4I4XjGKkK/bWdgxbsgzeAEy4eSH/wwbvyXArSRg89YtpcvX+I= X-Received: by 10.80.148.217 with SMTP id t25mr16430508eda.121.1516122581554; Tue, 16 Jan 2018 09:09:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Tue, 16 Jan 2018 09:09:00 -0800 (PST) In-Reply-To: <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> From: Tony Przygienda Date: Tue, 16 Jan 2018 09:09:00 -0800 Message-ID: To: Robert Wilton Cc: Jeff Tantsura , rift@ietf.org Content-Type: multipart/alternative; boundary="f403045c2316e8d9900562e7cb2d" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 17:09:49 -0000 --f403045c2316e8d9900562e7cb2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert, the newest draft version says that protobuf is a fine alternative to work with (but discussion thrift/protobuf is very comparable IMO @ capabilities/conceptual span level and _someone_ would have to do the work to be more than a boilerplate ;-). And AFAIR CBOR is basically message pack which would suffer from the JSON problem of having no type checking or schema definition which makes it a fine proposition if you just "writing some internal code where the code is the schema" but how would you standardize interoperable, backwards compatible formats/protocols that way and ensure minor/major versioning and so on? Having said that, serialization is now a huge fertile ground with all kind of ideas and endless packages roaming the field so the discussion would really have to be "what are the properties of a serialization approach that is useful to support solutions to the problem of type X". Having suffered decades from subtle encoding problems on routing protocols in terms of bugs and inter-operability issues I would not be particularly leaning towards adopting anything that doesn't have strong schema and type checking for that purpose. Of course the hand-written ser/de-sers in routing protocols had a purpose beyond keeping programmers employed ;-), the packages were not available and even if they were the available cycles and memory footprints would not have had supported them until recently ... And then of course there's proof in the pudding of defining schema, compiling it, making it run, seeing what really holds up @ scale ... And if you have something real for RIFT I'm always interested in having a more detailed discussion, voice some more qualified opinions ;-) thanks ---- tony On Tue, Jan 16, 2018 at 2:04 AM, Robert Wilton wrote: > I was actually wondering whether it wouldn't be better for RIFT to use > CBOR encoding rather than Thrift or protobuf (that the draft suggests as = a > possible alternative). > > Are there reasons why Thrift is a better choice that CBOR (given that CBO= R > is IETF specified)? > Thanks, > Rob > > > > On 16/01/2018 00:44, Jeff Tantsura wrote: > > Hi, > > > > I find Adrian=E2=80=99s changes perfect and support the charter as per be= low. > > Due to changes in my working situation I didn=E2=80=99t quite participate= in > initial discussion, starting now. > > > > I have got some ideas of using THRIFT/gRPC alike encoding schema=E2=80=99= s for > more, than RIFT currently defines, for later thought. > > > > Cheers, > > Jeff > > > > *From: *Rift on behalf of > Adrian Farrel > *Reply-To: * > *Date: *Monday, January 15, 2018 at 15:07 > *To: * > *Subject: *Re: [Rift] kicking off the charter discussion > > > > Hi, > > > > I joined this list a little late to have a neat head of thread to respond > to, but here's a response to Alvaro's copy to routing-discussion. > > > > The charter text looks water-tight to me and I'd like to see this WG > formed so that the whole community can work on RIFT. > > > > Maybe s/prominence/popularity/ > > > > There is a problem with the indentation in the deliverables... > > OLD > > - A Standards Track specification based on draft-przygienda-rift. The > document will include: > > > > - an Implementation Status section as described in RFC 7942 > > - an Operational Considerations section to explain how the protocol is > configured, deployed, and diagnosed > > - Security and Privacy Considerations, although this material may refer > to a separate Threat Analysis document (q.v.). > > - A YANG module focused on configuration of protocol instances > > - An Applicability Statement that describes how to deploy and configure > the protocol in networks with different topologies > > - A Security Threat Analysis document that describes the attack vectors > and mitigations that shall be sent for publication at the same time as th= e > protocol specification. > > NEW > > - A Standards Track specification based on draft-przygienda-rift. The > document will include: > > - an Implementation Status section as described in RFC 7942 > > - an Operational Considerations section to explain how the protocol > is configured, deployed, and diagnosed > > - Security and Privacy Considerations, although this material may > refer to a separate Threat Analysis document (q.v.). > > - A YANG module focused on configuration of protocol instances > > - An Applicability Statement that describes how to deploy and configure > the protocol in networks with different topologies > > - A Security Threat Analysis document that describes the attack vectors > and mitigations that shall be sent for publication at the same time as th= e > protocol specification. > > END > > > > Cheers, > > Adrian > > > > > > *From:* rtgwg [mailto:rtgwg-bounces@ietf.org ] *O= n > Behalf Of *Alvaro Retana > *Sent:* 06 January 2018 03:25 > *To:* routing-discussion@ietf.org; rtgwg@ietf.org > *Subject:* Fwd: [Rift] kicking off the charter discussion > > > > FYI.. > > > > If you are interested in this topic, please make comments and send > feedback on the rift@ietf.org list. > > > > Thanks! > > > > Alvaro. > > > > On January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com) wrote: > > Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG > charters with Alvaro. Here is what we have so far. Comments and > improvements would be most welcome. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Routing in Fat Trees (RIFT) > > Clos and Fat-Tree topologies have gained prominence in data center > networks as a result of a trend towards centralized data center network > architectures that may deliver computation and storage services. > > The Routing in Fat Trees (RIFT) protocol addresses the demands of routing > in Clos and Fat-Tree networks via a mixture of both link-state and > distance-vector techniques colloquially described as 'link-state towards > the spine and distance vector towards the leafs'. RIFT uses this hybrid > approach to focus on networks with regular topologies with a high degree = of > connectivity, a defined directionality, and large scale. > > The RIFT Working Group will work on a standards track specification of a > specialized, dynamic routing protocol for Clos and fat-tree network > topologies. The protocol will: > > - deal with automatic construction of fat-tree topologies based on > detection of links, > - minimize the amount of routing state held at each topology level, > - automatically prune topology distribution exchanges to a > sufficient subset of links, > - support automatic disaggregation of prefixes on link and node failures > to prevent black-holing and suboptimal routing, > - allow traffic steering and re-routing policies, > - and provide mechanisms to synchronize a limited key-value data-store > that can be used after protocol convergence. > > It is important that nodes participating in the protocol should need only > very light configuration and should be able to join a network as leaf nod= es > simply by connecting to the network using default configuration. > > The protocol must support IPv6 and should also support IPv4. > > The Working Group may establish additional requirements to constrain and > inform their work. > > The RIFT Working Group is chartered for the following list of items: > > - A Standards Track specification based on draft-przygienda-rift. The > document will include: > > - an Implementation Status section as described in RFC 7942 > - an Operational Considerations section to explain how the protocol is > configured, deployed, and diagnosed > - Security and Privacy Considerations, although this material may refer > to a separate Threat Analysis document (q.v.). > - A YANG module focused on configuration of protocol instances > - An Applicability Statement that describes how to deploy and configure > the protocol in networks with different topologies > - A Security Threat Analysis document that describes the attack vectors > and mitigations that shall be sent for publication at the same time as th= e > protocol specification. > > Milestones > > Feb 2018 Adopt a protocol specification document > Feb 2019 Submit protocol specification to IESG for publication > Feb 2019 Submit Threat Analysis to IESG for publication > Apr 2019 Submit YANG module to IESG for publication > Apr 2019 Submit Applicability Statement to IESG for publication > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Thanks, > > Alia > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift > > _______________________________________________ Rift mailing list > Rift@ietf.org https://www.ietf.org/mailman/listinfo/rift > > > _______________________________________________ > Rift mailing listRift@ietf.orghttps://www.ietf.org/mailman/listinfo/rift > > > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift > > --f403045c2316e8d9900562e7cb2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Robert, the newest draft version says that protobuf i= s a fine alternative to work with (but discussion thrift/protobuf is very c= omparable IMO @ capabilities/conceptual span level and _someone_ would have= to do the work to be more than a boilerplate ;-).=C2=A0 And AFAIR CBOR is = basically message pack which=C2=A0 would suffer from the JSON problem of ha= ving no type checking or schema definition which makes it a fine propositio= n if you just "writing some internal code where the code is the schema= " but how would you standardize interoperable, backwards compatible fo= rmats/protocols that way and ensure minor/major versioning and so on?
<= /div>

Having said that, serialization is now a huge fert= ile ground with all kind of ideas and endless packages roaming the field so= the discussion would really have to be "what are the properties of a = serialization approach that is useful to support solutions to the problem o= f type X". Having suffered decades from subtle encoding problems on ro= uting protocols in terms of bugs and inter-operability issues I would not b= e particularly leaning towards adopting anything that doesn't have stro= ng schema and type checking for that purpose. Of course the hand-written se= r/de-sers in routing protocols had a purpose beyond keeping programmers emp= loyed ;-), the packages were not available and even if they were the availa= ble cycles and memory footprints would not have had supported them until re= cently ...

And then of course there's pro= of in the pudding of defining schema, compiling it, making it run, seeing w= hat really holds up @ scale ... And if you have something real for RIFT I&#= 39;m always interested in having a more detailed discussion, voice some mor= e qualified opinions ;-)

thanks

---- tony



On Tue, Jan 16, 2018 at 2:04 AM, Robert W= ilton <rwilton@cisco.com> wrote:
=20 =20 =20

I was actually wondering whether it wouldn't be better for RIFT to use CBOR encoding rather than Thrift or protobuf (that the draft suggests as a possible alternative).

Are there reasons why Thrift is a better choice that CBOR (given that CBOR is IETF specified)?

Thanks,
Rob



On 16/01/2018 00:4= 4, Jeff Tantsura wrote:
=20 =20 =20 =20 =20

Hi,

=C2=A0

I find Adrian=E2=80=99s changes perfect and support the charter a= s per below.

Due to changes in my working situation I didn=E2=80=99t quite participate in initial discussion, starting now.<= /span>

=C2=A0

I have got some ideas of using THRIFT/gRPC alike encoding schema=E2=80=99s for more, than RIFT currently defines, for lat= er thought.

=C2=A0

Cheers,<= /p>

Jeff

=C2=A0

From: Rift <rift-bounces@ietf.org> on behalf of Adrian Farrel &= lt;adrian@olddog.co.uk>
Reply-To: <adri= an@olddog.co.uk>
Date: Monday, January 15, 2018 at 15:07
To: <rift@ietf.org>= ;
Subject: Re: [Rift] kicking off the charter discussion

= =C2=A0

Hi,

=C2=A0

I joined this list a little late to have a neat head of thread to respond to, but here's a response to Alvaro's copy t= o routing-discussion.

=C2=A0

The charter text looks water-tight to me and I'd like to see this WG formed so that the whole community can work on RIFT.

=C2=A0

Maybe s/prominence/popularity/

=C2=A0

There is a problem with the indentation in the deliverables...=

OLD

- A Standards Track specification based on draft-przygienda-rift. The document will include:=

=C2=A0

=C2=A0 - an Implementation Status section as described in RFC 7942

=C2=A0 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed

=C2=A0 - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).

=C2=A0 - A YANG module focused on configuration of protocol instances

=C2=A0 - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies

=C2=A0 - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

NEW

- A Standards Track specification based on draft-przygienda-rift. The document will include:=

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 - an Implementation Status section as described in RFC 7942

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).

=C2=A0 - A YANG module focused on configuration of protocol instances

=C2=A0 - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies

=C2=A0 - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

END

=C2=A0

Cheers,<= /p>

Adrian

=C2=A0

=C2=A0

From: rtgwg [mailto:rt= gwg-bounces@ietf.org] On Behalf Of Alvaro Retana
Sent: 06 January 2018 03:25
To: routing-discussion@ietf.org; rtgwg@ietf.org Subject: Fwd: [Rift] kicking off the charter discussion

=C2=A0

FYI..

=C2=A0

If you are interested in this topic, please make comments and send feedback on the rift@ietf.org=C2=A0list.

=C2=A0

Thanks!

=C2=A0

Alvaro.

=C2=A0

On January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com) wrote:

Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG charters with Alvaro.=C2=A0 Here is what we have so far.=C2=A0 Co= mments and improvements would be most welcome. <= /u>

=C2=A0=

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

Routing in Fat Trees (RIFT)

Clos and Fat-Tree topologies have gained prominence in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services.
=C2=A0
The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'.=C2=A0 RIFT uses this hybrid approach = to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale.

The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will:

- deal with automatic construction of fat-tree topologies based on detection of links,
- minimize the amount of routing state held at each topology level,
- automatically prune topology distribution exchanges to a sufficient=C2=A0subset of links, - support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing,
- allow traffic steering and re-routing policies,
- and provide mechanisms to synchronize a limited key-value data-store that=C2=A0can be use= d after protocol convergence.

It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration.

The protocol must support IPv6 and should also support IPv4.

The Working Group may establish additional requirements to constrain and inform their work.

The RIFT Working Group is chartered for the following list of items:

- A Standards Track specification based on draft-przygienda-rift. The document will include:

=C2=A0 - an Implementation Status section as described in RFC 7942
=C2=A0 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed
=C2=A0 - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).
=C2=A0 - A YANG module focused on configuration o= f protocol instances
=C2=A0 - An Applicability Statement that describe= s how to deploy and configure the protocol in networks with different topologies
=C2=A0 - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

Milestones

=C2=A0 Feb 2018 Adopt a protocol specification document
=C2=A0 Feb 2019 Submit protocol specification to IESG for publication
=C2=A0 Feb 2019 Submit Threat Analysis to IESG fo= r publication
=C2=A0 Apr 2019 Submit YANG module to IESG for publication
=C2=A0 Apr 2019 Submit Applicability Statement to IESG for publication

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks,

Alia

______________________________<= wbr>_________________
Rift mailing list
Ri= ft@ietf.org
https://www.ietf.org/mailman/listinfo/rift

______________________________________= _________ Rift mailing list Rift@ietf.or= g https://w= ww.ietf.org/mailman/listinfo/rift 



_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/rift


_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift


--f403045c2316e8d9900562e7cb2d-- From nobody Tue Jan 16 09:16:30 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63FA12DDD2 for ; Tue, 16 Jan 2018 09:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Qf5U3VpLz1k5 for ; Tue, 16 Jan 2018 09:16:26 -0800 (PST) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765FE12D7EB for ; Tue, 16 Jan 2018 09:16:19 -0800 (PST) Received: by mail-pl0-x22c.google.com with SMTP id g18so1041799plo.7 for ; Tue, 16 Jan 2018 09:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2GhRCeVqo7/dZlmITZD32DYODKG39lfuKaKt3uSWeDQ=; b=fOYR5fNIshgw/OufyDVl4YOeqO+J37NALrtk/H6JMPsvmqkcaLoHy4qWEZrYktpXHQ EurTXoz3DA+Rcq7GHAxGsmRBbkAnQk6BBxzE44gwTGjWvQ/Emk9ZD+DRX7NKGdcNDmfk 0Ro2N9I03e30ztvvHmALpkmcJvXrJlub8/Ffk/xlTIh6wNQY0chaTGuIhOZP727jtksf 4vtrAPNi3930rptbIKr4Zc3vdcH3hHCHDEWH1cCNXQQG9JyNlxaQr3Y428kCDBsLVtbe BOaJB/qFrXFyGTm20cuwrgbvac+/jBIeK4exZaMXCJA2xnHgQyuULHvTM3vZ9hZHaPyX RKDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2GhRCeVqo7/dZlmITZD32DYODKG39lfuKaKt3uSWeDQ=; b=nFTG1G++dC8M2b1Ezsar7N+Od5IMNWSne7M0HjNqYmuiMIHpDtc+xZnsnTXr3hsd67 B7z4UsLIl3mRgEK8QgN1/75ILKp8tMiBGZpTJJ1HJoRhS7UU4QaPrsDbAdudefBrhTN9 3jqTMKLzfChg/fG2ejwD9zaEM/oiIIxf6pasKDfRi49WDfSHsBkLKHUMOUzmWwzc2tAI /EIM2BcylDneOI6Xn1p71st8582XWYICQ6k7vOBkD4hrkcnSG3RcVdBSzHnHzgXgQxV8 wfgs2kgUgcnWXXG6FYZGtGYu52rfUl3AHihpAPCBp3xLBBXBmP9MpH9AzQFeobvzhTdv MAXg== X-Gm-Message-State: AKwxytfWk+ErKs7Zkp3gB1ANhKuUFuwaFu4UVTYj321GNZZU2lOHupQp JY9Gm/6/7cZsXkPT2uluPxw= X-Google-Smtp-Source: ACJfBos5NDK9inxoYkNOVdlIgGj8Oq5DY2uzZ0PPeciZHvq+SI6IBcH2amPZ5QslCG3+byxZ7HwDWw== X-Received: by 10.84.143.131 with SMTP id 3mr19451149plz.385.1516122979005; Tue, 16 Jan 2018 09:16:19 -0800 (PST) Received: from [172.22.228.216] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id o123sm4440898pfb.91.2018.01.16.09.16.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jan 2018 09:16:18 -0800 (PST) From: Tony Li Message-Id: <3381E659-7DAE-44A4-97A2-5FA7D966189C@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D66B6F94-6D42-4E72-88EC-D1E7A6B9A5DA" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 16 Jan 2018 09:16:17 -0800 In-Reply-To: Cc: Robert Wilton , Jeff Tantsura , rift@ietf.org To: Tony Przygienda References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 17:16:29 -0000 --Apple-Mail=_D66B6F94-6D42-4E72-88EC-D1E7A6B9A5DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 16, 2018, at 9:09 AM, Tony Przygienda = wrote: >=20 > And then of course there's proof in the pudding of defining schema, = compiling it, making it run, seeing what really holds up @ scale ... And = if you have something real for RIFT I'm always interested in having a = more detailed discussion, voice some more qualified opinions ;-)=20 Luddite here. =20 Do we have any worked examples of anyone using one of these packages = long term in a standard and demonstrating ongoing interoperability? It = would seem to me that unless folks are willing to mandate the schema = file and the version of the translator to use the odds of actual = cross-implementation cross-version interoperability are slim to none. Consider this one vote for traditional TLVs. Tony --Apple-Mail=_D66B6F94-6D42-4E72-88EC-D1E7A6B9A5DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
--94eb2c1942de783dff0563a58279-- From nobody Fri Jan 26 11:08:17 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243E9124D37; Fri, 26 Jan 2018 11:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 mCtziUUoIniR; Fri, 26 Jan 2018 11:08:14 -0800 (PST) Received: from mail-yb0-x244.google.com (mail-yb0-x244.google.com [IPv6:2607:f8b0:4002:c09::244]) (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 5B065124BE8; Fri, 26 Jan 2018 11:08:14 -0800 (PST) Received: by mail-yb0-x244.google.com with SMTP id i12so559924ybj.7; Fri, 26 Jan 2018 11:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zzi6nrnuUqm0JRHA7rcUtenUTvKiqAaZQR1k37WnDSU=; b=rWnVt3mdp/QqArkW7hSod91DxGU9Qr3hndfIJ3NHGkhheWytjXb9w4Zsbahw8jAJkK p6CH/7bxi2lBSTPDSpFnZ2xQWumaijqrz/8GKq9GATSIyLaODDcpBSg7L91+zyfVnORK cVzG4AXs50OrxYcP5Dqknyq7MK1qSIyBzCCWpyxNVth4moJzuJdM2Kh3mkgoIXaS5uYz tS4Zl0aKBCpYpRiS9O+S0hh9P6LPDS8pSXakNae+fHsHvHEzU3x+PeQETKZW2wpHN6iy yy+9DB5fBcK8Bt9n1SCocbXkXt05HRTNO+fHI7+Oc6cAwrZGXWWkGWd6i7qAwLgXOVe/ +dsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zzi6nrnuUqm0JRHA7rcUtenUTvKiqAaZQR1k37WnDSU=; b=kPqRoMBkGMbQt0ZrE068pGjuZrRIBZCNzjbRQGcXTPJbxbkF+I+0jEW+7M2lc4xgwn GNJlGWLd8+erTxmxrLROr10/oT/xHRSl5awWOxdeD4fXIsiInb7xZYjDwNOjIcY6lJ1S 1XnFz/wbApPxwR0ug5GD22UDlgAdr8Es1SpCXNlWwGJfIZWBFafQzzD53yg+onJM9GJW EmsjVuybAAYJYJCLwiYdI6Q7EYs0WmueEDQewded5mHnB7voxeJ7hEM0okrFTHNQVenJ f0WwvUhapAqxMGdeF0QkK+nIz12RLQ8q843Fy+fIPD8XuzGN/SnoYb+eLhx8SjCc7XSG 8bxg== X-Gm-Message-State: AKwxytcj+IumZk/9hVKWU65E8pGiusAzC/BAYk0vqElg/qNlTXSY7Bf6 GneuOlEY7H+N58pURLwxAoUh2fHoeunjJeByyj0= X-Google-Smtp-Source: AH8x226Ci6/6nCOH12VwSdZ8btDQVPBuCVY4Cc9o+W8jwHFLD8R3ax6XJq0SCqYFZGl+Okm9j+sEBjHm6ndqE+AVHj8= X-Received: by 10.37.3.194 with SMTP id 185mr11821164ybd.379.1516993693325; Fri, 26 Jan 2018 11:08:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.20.4 with HTTP; Fri, 26 Jan 2018 11:08:12 -0800 (PST) Received: by 10.37.20.4 with HTTP; Fri, 26 Jan 2018 11:08:12 -0800 (PST) In-Reply-To: References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 26 Jan 2018 13:08:12 -0600 Message-ID: To: "Alvaro Retana (aretana)" Cc: Tony Przygienda , rift-chairs@ietf.org, IESG , rift@ietf.org Content-Type: multipart/alternative; boundary="001a11c01102379e0d0563b29efc" Archived-At: Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT) X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 19:08:16 -0000 --001a11c01102379e0d0563b29efc Content-Type: text/plain; charset="UTF-8" Hi, Alvaro, On Jan 25, 2018 11:57, "Alvaro Retana" wrote: On January 25, 2018 at 9:44:45 AM, Alvaro Retana (aretana.ietf@gmail.com) wrote: I think that we can come up with a general introductory paragraph (just a few sentences) that provides some specific background for the DC-related routing work. I will borrow from the references that Tony pointed to and bounce something by thing list before the end of the day. I put together a couple of sentences as a brief introduction and submitted it as -05 [1]. Please take a look. I plan on asking the IESG Secretariat to move the charter on to External Review before the end of the day today. My apologies for only noticing this now. The diff looks good - the opening paragraph was what I was hoping for. If you're still open for suggestions, I'd also suggested "A standards track *routing protocol* specification that will include" to make it a bit more obvious that this specification was the same work described earlier in the charter, but that wasn't as important. Do the right thing :-) Spencer Thanks! Alvaro. [1] https://datatracker.ietf.org/doc/charter-ietf-rift/00-05/ Diffs: https://www.ietf.org/rfcdiff?url1=https%3A%2F% 2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-rift%2Fwithmilestones-00-04.txt& url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-rift% 2Fwithmilestones-00-05.txt --001a11c01102379e0d0563b29efc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Alvaro,

On Jan 25, 2018 11:57, "Alvaro Retana" <<= a href=3D"mailto:aretana.ietf@gmail.com">aretana.ietf@gmail.com> wro= te:
On January 25, 2018 at 9:44:45 AM, Alvaro Retana (aretana.ietf@gmail.com) wrote:

I think that we can come up with a general in= troductory paragraph (just a few sentences) that provides some specific bac= kground for the DC-related routing work.=C2=A0 I will borrow from the refer= ences that Tony pointed to and bounce something by thing list before the en= d of the day.

I put= together a couple of sentences as a brief introduction and submitted it as= -05 [1].=C2=A0 Please take a look.

I plan on asking the IESG Secretariat to move the ch= arter on to External Review before the end of the day today.

My apologies for only noticing this now.=C2=A0

The diff looks good - the opening paragraph wa= s what I was hoping for.

If you're still open for suggestions, I'd also suggested

"A standards track *routing = protocol* specification that will include"=C2=A0

to make it a bit more obvious that this speci= fication was the same work described earlier in the charter, but that wasn&= #39;t as important.=C2=A0

Do the right thing :-)

Spencer

 --001a11c01102379e0d0563b29efc-- From nobody Fri Jan 26 13:05:11 2018 Return-Path: X-Original-To: rift@ietf.org Delivered-To: rift@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62261126BFD; Fri, 26 Jan 2018 13:05:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rift@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151700070939.4399.14467194442688675416.idtracker@ietfa.amsl.com> Date: Fri, 26 Jan 2018 13:05:09 -0800 Archived-At: Subject: [Rift] WG Review: Routing In Fat Trees (rift) X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 21:05:09 -0000 A new IETF WG has been proposed in the Routing Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2018-02-05. Routing In Fat Trees (rift) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Zhaohui Zhang Assigned Area Director: Alvaro Retana Routing Area Directors: Alia Atlas Alvaro Retana Deborah Brungard Mailing list: Address: rift@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/rift Archive: https://mailarchive.ietf.org/arch/search/?email_list=rift Group page: https://datatracker.ietf.org/group/rift/ Charter: https://datatracker.ietf.org/doc/charter-ietf-rift/ Data Centers have been steadily growing to commonly host tens of thousands of end points, or more, in a single network. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and for low human intervention, data center networks have a unique set of requirements that is resulting in the design of routing solutions specific to them. Clos and Fat-Tree topologies have gained popularity in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services. The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'. RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale. The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will: - deal with automatic construction of fat-tree topologies based on detection of links, - minimize the amount of routing state held at each topology level, - automatically prune topology distribution exchanges to a sufficient subset of links, - support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing, - allow traffic steering and re-routing policies, - and provide mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence. It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration. The protocol must support IPv6 and should also support IPv4. The Working Group may establish additional requirements to constrain and inform their work. The RIFT Working Group is chartered for the following list of items: - A Standards Track specification that will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.) - A YANG module focused on configuration and monitoring of protocol instances - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification Milestones Mar 2018 Adopt a protocol specification document Feb 2019 Submit protocol specification to IESG for publication Feb 2019 Submit Threat Analysis to IESG for publication Apr 2019 Submit YANG module to IESG for publication Apr 2019 Submit Applicability Statement to IESG for publication

On Jan 16, 2018, at 9:09 AM, Tony Przygienda <tonysietf@gmail.com>= wrote:

And then of course there's proof = in the pudding of defining schema, compiling it, making it run, seeing = what really holds up @ scale ... And if you have something real for RIFT = I'm always interested in having a more detailed discussion, voice some = more qualified opinions ;-) 


Luddite here.  

Do we have any worked examples of = anyone using one of these packages long term in a standard and = demonstrating ongoing interoperability? It would seem to me that unless = folks are willing to mandate the schema file and the version of the = translator to use the odds of actual cross-implementation cross-version = interoperability are slim to none.

Consider this one vote for traditional = TLVs.

Tony

= --Apple-Mail=_D66B6F94-6D42-4E72-88EC-D1E7A6B9A5DA-- From nobody Tue Jan 16 09:39:05 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749F712D82D for ; Tue, 16 Jan 2018 09:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 jYsnzgpLdRMU for ; Tue, 16 Jan 2018 09:39:01 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64DE112E869 for ; Tue, 16 Jan 2018 09:38:58 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id 141so10230964wme.3 for ; Tue, 16 Jan 2018 09:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b+YiVQCvC80vgRBbPl7XJ5Cqd8NIPGTIR+47ZWdcOd8=; b=sptHGcp9smKJelEgRgR4lQqiRV14L1SD8QccyCBoS4C5Ag4fyHzXrjMaHrPY12JpKJ qGEwOg5p8+mC0CEK/GrHb0dhSzHEe96pOc2256r/zwR6ViK5tXIl5R/W9ewFIl4psizI 0iPcOZ/7tf+oSBpu4/bTx6bvymW1GuPEUABDnfVQjxjivezPB25t6hzxgWXVDbOuAr+h BpuNzLC7ExMPugSj5t3bTM9K/RU1jLyFRK7tmjk030nfrixPc7X3FwqsW/+sPiKA1FzM fmH4IfUOUoAuN21j6O1K9uEQ1CHQk/HwZWWjAp1ZfcxXOrd6Qh2uihmg+hPRt4Fe5pc1 C2RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b+YiVQCvC80vgRBbPl7XJ5Cqd8NIPGTIR+47ZWdcOd8=; b=btcpTUbMPBvR0iKiEPT4ZN0adsNIrfcv+5XECis4Fd4+lv1hRoHtgpo33jLcIA6YSH ZYcEfKxupPKp9ekLeEzGc3wNL9mtig4qHNJPlMBIsoGH3e7Py3Bt6HHg2Z2rrl/4hPB2 ca0+83VFg7W3OiDQEBNf3orWw820Jxqrz2XP07eXlUuzuLQLm9dG8ZIcD2WX4CQAwi+R FNcwKUO5yBNlfHfpW65sop6McttsQY78QoWM6jO+vnwqv15iFG5soQDWtwBVM0Pq5Dy6 87K+CZGmspyeYjaL/8ue7vQdShJlqywGc487hBx4+F78IINIlzWlTNTqmHEQdtUuBJFP ixug== X-Gm-Message-State: AKGB3mIna9uEbvWpp5xmIo8ID9xU7+5zS0M5tcYQRnGNTHQHRu0+EjXU Uh4vnFY+poLWJf0k18mtQrnwDaR35xVEzjn43ewaCuyS X-Google-Smtp-Source: ACJfBou9OlYa4XsLhCtGA8Dz06zIVmW/iFqkECkOOgIqf0WmBS3wlAAg0Q8wMcz14580IfYkNQ6LSEAQqWEHlwzbV4o= X-Received: by 10.80.183.34 with SMTP id g31mr53830992ede.191.1516124336884; Tue, 16 Jan 2018 09:38:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Tue, 16 Jan 2018 09:38:16 -0800 (PST) In-Reply-To: <3381E659-7DAE-44A4-97A2-5FA7D966189C@gmail.com> References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> <3381E659-7DAE-44A4-97A2-5FA7D966189C@gmail.com> From: Tony Przygienda Date: Tue, 16 Jan 2018 09:38:16 -0800 Message-ID: To: Tony Li Cc: Robert Wilton , Jeff Tantsura , rift@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19507e8910650562e834c2" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 17:39:03 -0000 --94eb2c19507e8910650562e834c2 Content-Type: text/plain; charset="UTF-8" Tony, unfortunately you are asking here for someone 2 years out of school with 20 years job experience ;-) Those packages are too recent, first "something" that was consumption ready is really just 2008-10 (Thrift) and the CPU juice & languages are here since only about 4 years to do that kind of stuff @ scale/speed we need in protocols IME ... Service deployment folks have tons of experience with service migration and experience there has been quite good as far I talk to them. And within the big shops service inter-operability, inter-dependency, forward rolling is keeping busy a lot of people from what I saw. But yes, they are not "routing protocols" per se which is a mildly specialized problem we all made careers of ;-) ... As to mandate: just like "TLVs" are part of the standard so can a schema be (and YANGs are standard, aren't they, albeit serving different corner obviously) and I would argue syntactically a much "cleaner, maintainable, easier to advance" one when it comes to syntactic correctness of what can leave the box. [Footnote: semantically, no matter how beautifully you encode, if you make a mess of inter-dependent, badly described flags with partitions across multiple instances of things and fail to describe all boundary/error conditions that can happen, anything can be bad. The limit here is the capability of the protocol designers to create orthogonal, clean algebras or object/relationship model] ... And the "each-their-own-TLV-parser-interoperability" is based on the tactic understanding that no'one tries to break the other guys' parser too hard with crazy stuff being sent, unless of course a bug happens and "who could have known" and "oh, will never happen again". And to fix things in specs after the fact is not fun and sometimes not even possible. Having done RFC7606 this does not make for maintainable code that inspires a lot of confidence ... And frankly, while you were gone quite a discussion was raging whether RFC7606 is a bug or a feature, IMO it's both since it expresses "well meaning intentions" which sometimes can just make this paved road so much more slippery ... I fully acknowledge that TLVs saved the Internet's bacon for years to come and there was no practical alternative for those years but routing protocols aren't a "dead language" yet and we allegedly made a bit of a pig's ear of using the technologies in HW and SW given to us over last decade+ or so [except IDR, this one is willing to burn any memory/CPU you give it before it's soldered on] ;-) Ultimately, schemas are just "serialization" and very, very useful stuff we put into TLVs like "transitive" and "optional" properties can only be partially encoded that way and may be added (think optional being "optional" in thrift and mandatory being more of "required" but something like "transitory" cannot be expressed in those schemas since it really is specific for "diffused computation"). So TLVs lessons-learned will be moved forward and surely not forgotten ... Further continuation of this is rather a bar BoF than mailing list fodder IMO ... thanks --- tony On Tue, Jan 16, 2018 at 9:16 AM, Tony Li wrote: > > > On Jan 16, 2018, at 9:09 AM, Tony Przygienda wrote: > > And then of course there's proof in the pudding of defining schema, > compiling it, making it run, seeing what really holds up @ scale ... And if > you have something real for RIFT I'm always interested in having a more > detailed discussion, voice some more qualified opinions ;-) > > > > Luddite here. > > Do we have any worked examples of anyone using one of these packages long > term in a standard and demonstrating ongoing interoperability? It would > seem to me that unless folks are willing to mandate the schema file and the > version of the translator to use the odds of actual cross-implementation > cross-version interoperability are slim to none. > > Consider this one vote for traditional TLVs. > > Tony > > --94eb2c19507e8910650562e834c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tony, unfortunately you are asking here for= someone 2 years out of school with 20 years job experience ;-)=C2=A0 Those= packages are too recent, first "something" that was consumption = ready is really just 2008-10 (Thrift) and the CPU juice & languages are= here since only about 4 years to do that kind of stuff @ scale/speed we ne= ed in protocols IME ... Service deployment folks have tons of experience wi= th service migration and experience there has been quite good as far I talk= to them. And within the big shops service inter-operability, inter-depende= ncy, forward rolling is keeping busy a lot of people from what I saw. But y= es, they are not "routing protocols" per se which is a mildly spe= cialized problem we all made careers of ;-)=C2=A0 ...

As to m= andate: just like "TLVs" are part of the standard so can a schema= be (and YANGs are standard, aren't they, albeit serving different corn= er obviously) and I would argue syntactically a much "cleaner, maintai= nable, easier to advance" one when it comes to syntactic correctness o= f what can leave the box. [Footnote: semantically, no matter how beautifull= y you encode, if you make a mess of inter-dependent, badly described flags = with partitions across multiple instances of things and fail to describe al= l boundary/error conditions that can happen, anything can be bad. The limit= here is the capability of the protocol designers to create orthogonal, cle= an algebras or object/relationship model] ... And the "each-their-own-= TLV-parser-interoperability" is based on the tactic understanding that= no'one tries to break the other guys' parser too hard with crazy s= tuff being sent, unless of course a bug happens and "who could have kn= own" and "oh, will never happen again". And to fix things in= specs after the fact is not fun and sometimes not even possible. Having do= ne RFC7606 this does not make for maintainable code that inspires a lot of = confidence ...=C2=A0 And frankly, while you were gone quite a discussion wa= s raging whether RFC7606 is a bug or a feature, IMO it's both since it = expresses "well meaning intentions" which sometimes can just make= this paved road so much more slippery ...

I = fully acknowledge that TLVs saved the Internet's bacon for years to com= e and there was no practical alternative for those years but routing protoc= ols aren't a "dead language" yet and we allegedly made a bit = of a pig's ear of using the technologies in HW and SW given to us over = last decade+ or so [except IDR, this one is willing to burn any memory/CPU = you give it before it's soldered on] ;-)

= Ultimately, schemas are just "serialization" and very, very usefu= l stuff we put into TLVs like "transitive" and "optional&quo= t; properties can only be partially encoded that way and may be added (thin= k=C2=A0 optional being "optional" in thrift and mandatory being m= ore of "required" but something like "transitory" canno= t be expressed in those schemas since it really is specific for "diffu= sed computation"). So TLVs lessons-learned will be moved forward and s= urely not forgotten ...

Further continuation = of this is rather a bar BoF than mailing list fodder IMO ...

thanks

--- tony

On Tue, J= an 16, 2018 at 9:16 AM, Tony Li <tony1athome@gmail.com> = wrote:


On Jan 16, 2018, at 9:09 AM, Tony Przygienda <tonysietf@gmail.com&g= t; wrote:

And then of course there's = proof in the pudding of defining schema, compiling it, making it run, seein= g what really holds up @ scale ... And if you have something real for RIFT = I'm always interested in having a more detailed discussion, voice some = more qualified opinions ;-)=C2=A0


Luddite here. =C2=A0

Do we have any w= orked examples of anyone using one of these packages long term in a standar= d and demonstrating ongoing interoperability? It would seem to me that unle= ss folks are willing to mandate the schema file and the version of the tran= slator to use the odds of actual cross-implementation cross-version interop= erability are slim to none.

Consider this one vote= for traditional TLVs.
=

Tony


--94eb2c19507e8910650562e834c2-- From nobody Tue Jan 16 09:56:34 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2582126BFD for ; Tue, 16 Jan 2018 09:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ZuMxHuv8PxTM for ; Tue, 16 Jan 2018 09:56:29 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2189D12D85E for ; Tue, 16 Jan 2018 09:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48119; q=dns/txt; s=iport; t=1516125388; x=1517334988; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=dRdrsqZB0zUMJbUXrb+NHhvs6BLFBTMh5HbpI7lRd1I=; b=E0RtDeK7oOTj25+CAHCvf0EyG5VBjERmeXviAmRkyYS5mUMc+Fb3dO5u NzmFMolfqCwFLDf72uKz8Z0DhQkDqlnTyjwYQJrsortCquP27sn7RpqTr YkDGTfd4hRtoLgcInjfakIpzWPqYtxUBb8DFazxDsB3uaH/Hj4jFdJrNC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQCBO15a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKR4EWdCeEE4sYjzwyiQaOJoITAwoYAQqFGAKFHBcBAQEBAQE?= =?us-ascii?q?BAQFrKIUjAQEBBAEBIUkCCxAJAhEDAQEBASABBgMCAiEGHwkIBg0GAgEBEAeKA?= =?us-ascii?q?AMVEIcknXCCJyaHFA2CBAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhDiDcIFpKYF?= =?us-ascii?q?3gQ6Ca0QBAQIBAYFGEzQWgmGCZQWZcok1PYgMgSCCDIURhQKCGYYdg2+Ha40+Q?= =?us-ascii?q?IEeiAmBPCEDNCWBKzIaCBsVPYIqghs5HIFnQTeKBQEBJQeCHQEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,369,1511827200"; d="scan'208,217";a="1485235" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 17:56:24 +0000 Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0GHuN5i005127; Tue, 16 Jan 2018 17:56:23 GMT To: Tony Przygienda Cc: Jeff Tantsura , rift@ietf.org References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> From: Robert Wilton Message-ID: Date: Tue, 16 Jan 2018 17:56:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D4B852376B7C2AEBA2D622C4" Content-Language: en-US Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 17:56:33 -0000 This is a multi-part message in MIME format. --------------D4B852376B7C2AEBA2D622C4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tony, I don't know of the relative benefits of protobuf vs thrift, but I was more thinking of the "eat your own dog food", and I thought that one of the aims for CBOR was to act as a robust encoding for protocol messages, i.e. to replace the buggy TLV parsing. When I looked at CBOR it seemed to compare favorably (size and performance wise) to other binary serialization protocols.  I.e. if a new IETF protocol is going to use a binary serialization protocol other than the IETF specified one then at least it should warrant some proper discussion. ;-) Regarding specifying the format/schema definition (and validation of messages), there is a CBOR WG draft for that: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl Thanks, Rob On 16/01/2018 17:09, Tony Przygienda wrote: > Robert, the newest draft version says that protobuf is a fine > alternative to work with (but discussion thrift/protobuf is very > comparable IMO @ capabilities/conceptual span level and _someone_ > would have to do the work to be more than a boilerplate ;-).  And > AFAIR CBOR is basically message pack which  would suffer from the JSON > problem of having no type checking or schema definition which makes it > a fine proposition if you just "writing some internal code where the > code is the schema" but how would you standardize interoperable, > backwards compatible formats/protocols that way and ensure minor/major > versioning and so on? > > Having said that, serialization is now a huge fertile ground with all > kind of ideas and endless packages roaming the field so the discussion > would really have to be "what are the properties of a serialization > approach that is useful to support solutions to the problem of type > X". Having suffered decades from subtle encoding problems on routing > protocols in terms of bugs and inter-operability issues I would not be > particularly leaning towards adopting anything that doesn't have > strong schema and type checking for that purpose. Of course the > hand-written ser/de-sers in routing protocols had a purpose beyond > keeping programmers employed ;-), the packages were not available and > even if they were the available cycles and memory footprints would not > have had supported them until recently ... > > And then of course there's proof in the pudding of defining schema, > compiling it, making it run, seeing what really holds up @ scale ... > And if you have something real for RIFT I'm always interested in > having a more detailed discussion, voice some more qualified opinions ;-) > > thanks > > ---- tony > > > > On Tue, Jan 16, 2018 at 2:04 AM, Robert Wilton > wrote: > > I was actually wondering whether it wouldn't be better for RIFT to > use CBOR encoding rather than Thrift or protobuf (that the draft > suggests as a possible alternative). > > Are there reasons why Thrift is a better choice that CBOR (given > that CBOR is IETF specified)? > > Thanks, > Rob > > > > On 16/01/2018 00:44, Jeff Tantsura wrote: >> >> Hi, >> >> I find Adrian’s changes perfect and support the charter as per below. >> >> Due to changes in my working situation I didn’t quite participate >> in initial discussion, starting now. >> >> I have got some ideas of using THRIFT/gRPC alike encoding >> schema’s for more, than RIFT currently defines, for later thought. >> >> Cheers, >> >> Jeff >> >> *From: *Rift >> on behalf of Adrian Farrel >> >> *Reply-To: * >> *Date: *Monday, January 15, 2018 at 15:07 >> *To: * >> *Subject: *Re: [Rift] kicking off the charter discussion >> >> Hi, >> >> I joined this list a little late to have a neat head of thread to >> respond to, but here's a response to Alvaro's copy to >> routing-discussion. >> >> The charter text looks water-tight to me and I'd like to see this >> WG formed so that the whole community can work on RIFT. >> >> Maybe s/prominence/popularity/ >> >> There is a problem with the indentation in the deliverables... >> >> OLD >> >> - A Standards Track specification based on draft-przygienda-rift. >> The document will include: >> >> - an Implementation Status section as described in RFC 7942 >> >> - an Operational Considerations section to explain how the >> protocol is configured, deployed, and diagnosed >> >> - Security and Privacy Considerations, although this material may >> refer to a separate Threat Analysis document (q.v.). >> >> - A YANG module focused on configuration of protocol instances >> >> - An Applicability Statement that describes how to deploy and >> configure the protocol in networks with different topologies >> >> - A Security Threat Analysis document that describes the attack >> vectors and mitigations that shall be sent for publication at the >> same time as the protocol specification. >> >> NEW >> >> - A Standards Track specification based on draft-przygienda-rift. >> The document will include: >> >> - an Implementation Status section as described in RFC 7942 >> >> - an Operational Considerations section to explain how the >> protocol is configured, deployed, and diagnosed >> >> - Security and Privacy Considerations, although this material may >> refer to a separate Threat Analysis document (q.v.). >> >> - A YANG module focused on configuration of protocol instances >> >> - An Applicability Statement that describes how to deploy and >> configure the protocol in networks with different topologies >> >> - A Security Threat Analysis document that describes the attack >> vectors and mitigations that shall be sent for publication at the >> same time as the protocol specification. >> >> END >> >> Cheers, >> >> Adrian >> >> *From:*rtgwg [mailto:rtgwg-bounces@ietf.org] *On Behalf Of >> *Alvaro Retana >> *Sent:* 06 January 2018 03:25 >> *To:* routing-discussion@ietf.org >> ; rtgwg@ietf.org >> >> *Subject:* Fwd: [Rift] kicking off the charter discussion >> >> FYI.. >> >> If you are interested in this topic, please make comments and >> send feedback on the rift@ietf.org  list. >> >> Thanks! >> >> Alvaro. >> >> On January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com >> ) wrote: >> >> Tony, Jeffrey Zhang, I, and others have been discussing >> possible RIFT WG charters with Alvaro.  Here is what we have >> so far.  Comments and improvements would be most welcome. >> >> ================ >> >> Routing in Fat Trees (RIFT) >> >> Clos and Fat-Tree topologies have gained prominence in data >> center networks as a result of a trend towards centralized >> data center network architectures that may deliver >> computation and storage services. >> >> The Routing in Fat Trees (RIFT) protocol addresses the >> demands of routing in Clos and Fat-Tree networks via a >> mixture of both link-state and distance-vector techniques >> colloquially described as 'link-state towards the spine and >> distance vector towards the leafs'.  RIFT uses this hybrid >> approach to focus on networks with regular topologies with a >> high degree of connectivity, a defined directionality, and >> large scale. >> >> The RIFT Working Group will work on a standards track >> specification of a specialized, dynamic routing protocol for >> Clos and fat-tree network topologies. The protocol will: >> >> - deal with automatic construction of fat-tree topologies >> based on detection of links, >> - minimize the amount of routing state held at each topology >> level, >> - automatically prune topology distribution exchanges to a >> sufficient subset of links, >> - support automatic disaggregation of prefixes on link and >> node failures to prevent black-holing and suboptimal routing, >> - allow traffic steering and re-routing policies, >> - and provide mechanisms to synchronize a limited key-value >> data-store that can be used after protocol convergence. >> >> It is important that nodes participating in the protocol >> should need only very light configuration and should be able >> to join a network as leaf nodes simply by connecting to the >> network using default configuration. >> >> The protocol must support IPv6 and should also support IPv4. >> >> The Working Group may establish additional requirements to >> constrain and inform their work. >> >> The RIFT Working Group is chartered for the following list of >> items: >> >> - A Standards Track specification based on >> draft-przygienda-rift. The document will include: >> >>   - an Implementation Status section as described in RFC 7942 >>   - an Operational Considerations section to explain how the >> protocol is configured, deployed, and diagnosed >>   - Security and Privacy Considerations, although this >> material may refer to a separate Threat Analysis document (q.v.). >>   - A YANG module focused on configuration of protocol instances >>   - An Applicability Statement that describes how to deploy >> and configure the protocol in networks with different topologies >>   - A Security Threat Analysis document that describes the >> attack vectors and mitigations that shall be sent for >> publication at the same time as the protocol specification. >> >> Milestones >> >>   Feb 2018 Adopt a protocol specification document >>   Feb 2019 Submit protocol specification to IESG for publication >>   Feb 2019 Submit Threat Analysis to IESG for publication >>   Apr 2019 Submit YANG module to IESG for publication >>   Apr 2019 Submit Applicability Statement to IESG for >> publication >> >> ============ >> >> Thanks, >> >> Alia >> >> _______________________________________________ >> Rift mailing list >> Rift@ietf.org >> https://www.ietf.org/mailman/listinfo/rift >> >> >> _______________________________________________ Rift mailing list >> Rift@ietf.org >> https://www.ietf.org/mailman/listinfo/rift >> >> >> >> >> _______________________________________________ >> Rift mailing list >> Rift@ietf.org >> https://www.ietf.org/mailman/listinfo/rift >> > > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift > > > --------------D4B852376B7C2AEBA2D622C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Tony,

I don't know of the relative benefits of protobuf vs thrift, but I was more thinking of the "eat your own dog food", and I thought that one of the aims for CBOR was to act as a robust encoding for protocol messages, i.e. to replace the buggy TLV parsing. 

When I looked at CBOR it seemed to compare favorably (size and performance wise) to other binary serialization protocols.  I.e. if a new IETF protocol is going to use a binary serialization protocol other than the IETF specified one then at least it should warrant some proper discussion. ;-)

Regarding specifying the format/schema definition (and validation of messages), there is a CBOR WG draft for that: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl

Thanks,
Rob



On 16/01/2018 17:09, Tony Przygienda wrote:
Robert, the newest draft version says that protobuf is a fine alternative to work with (but discussion thrift/protobuf is very comparable IMO @ capabilities/conceptual span level and _someone_ would have to do the work to be more than a boilerplate ;-).  And AFAIR CBOR is basically message pack which  would suffer from the JSON problem of having no type checking or schema definition which makes it a fine proposition if you just "writing some internal code where the code is the schema" but how would you standardize interoperable, backwards compatible formats/protocols that way and ensure minor/major versioning and so on?

Having said that, serialization is now a huge fertile ground with all kind of ideas and endless packages roaming the field so the discussion would really have to be "what are the properties of a serialization approach that is useful to support solutions to the problem of type X". Having suffered decades from subtle encoding problems on routing protocols in terms of bugs and inter-operability issues I would not be particularly leaning towards adopting anything that doesn't have strong schema and type checking for that purpose. Of course the hand-written ser/de-sers in routing protocols had a purpose beyond keeping programmers employed ;-), the packages were not available and even if they were the available cycles and memory footprints would not have had supported them until recently ...

And then of course there's proof in the pudding of defining schema, compiling it, making it run, seeing what really holds up @ scale ... And if you have something real for RIFT I'm always interested in having a more detailed discussion, voice some more qualified opinions ;-)

thanks

---- tony



On Tue, Jan 16, 2018 at 2:04 AM, Robert Wilton <rwilton@cisco.com> wrote:

I was actually wondering whether it wouldn't be better for RIFT to use CBOR encoding rather than Thrift or protobuf (that the draft suggests as a possible alternative).

Are there reasons why Thrift is a better choice that CBOR (given that CBOR is IETF specified)?

Thanks,
Rob



On 16/01/2018 00:44, Jeff Tantsura wrote:

Hi,

 

I find Adrian’s changes perfect and support the charter as per below.

Due to changes in my working situation I didn’t quite participate in initial discussion, starting now.

 

I have got some ideas of using THRIFT/gRPC alike encoding schema’s for more, than RIFT currently defines, for later thought.

 

Cheers,

Jeff

 

From: Rift <rift-bounces@ietf.org> on behalf of Adrian Farrel <adrian@olddog.co.uk>
Reply-To: <adrian@olddog.co.uk>
Date: Monday, January 15, 2018 at 15:07
To: <rift@ietf.org>
Subject: Re: [Rift] kicking off the charter discussion

 

Hi,

 

I joined this list a little late to have a neat head of thread to respond to, but here's a response to Alvaro's copy to routing-discussion.

 

The charter text looks water-tight to me and I'd like to see this WG formed so that the whole community can work on RIFT.

 

Maybe s/prominence/popularity/

 

There is a problem with the indentation in the deliverables...

OLD

- A Standards Track specification based on draft-przygienda-rift. The document will include:

 

  - an Implementation Status section as described in RFC 7942

  - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed

  - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).

  - A YANG module focused on configuration of protocol instances

  - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies

  - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

NEW

- A Standards Track specification based on draft-przygienda-rift. The document will include:

      - an Implementation Status section as described in RFC 7942

      - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed

       - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).

  - A YANG module focused on configuration of protocol instances

  - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies

  - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

END

 

Cheers,

Adrian

 

 

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro Retana
Sent: 06 January 2018 03:25
To: routing-discussion@ietf.org; rtgwg@ietf.org
Subject: Fwd: [Rift] kicking off the charter discussion

 

FYI..

 

If you are interested in this topic, please make comments and send feedback on the rift@ietf.org list.

 

Thanks!

 

Alvaro.

 

On January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com) wrote:

Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG charters with Alvaro.  Here is what we have so far.  Comments and improvements would be most welcome.

 

================

Routing in Fat Trees (RIFT)

Clos and Fat-Tree topologies have gained prominence in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services.
 
The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'.  RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale.

The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will:

- deal with automatic construction of fat-tree topologies based on detection of links,
- minimize the amount of routing state held at each topology level,
- automatically prune topology distribution exchanges to a sufficient subset of links,
- support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing,
- allow traffic steering and re-routing policies,
- and provide mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence.

It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration.

The protocol must support IPv6 and should also support IPv4.

The Working Group may establish additional requirements to constrain and inform their work.

The RIFT Working Group is chartered for the following list of items:

- A Standards Track specification based on draft-przygienda-rift. The document will include:

  - an Implementation Status section as described in RFC 7942
  - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed
  - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).
  - A YANG module focused on configuration of protocol instances
  - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies
  - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

Milestones

  Feb 2018 Adopt a protocol specification document
  Feb 2019 Submit protocol specification to IESG for publication
  Feb 2019 Submit Threat Analysis to IESG for publication
  Apr 2019 Submit YANG module to IESG for publication
  Apr 2019 Submit Applicability Statement to IESG for publication

============

Thanks,

Alia

_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift

_______________________________________________ Rift mailing list Rift@ietf.org https://www.ietf.org/mailman/listinfo/rift 



_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift


_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift



--------------D4B852376B7C2AEBA2D622C4-- From nobody Tue Jan 16 10:58:49 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA06812E874 for ; Tue, 16 Jan 2018 10:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 SMrq2dZjsY_5 for ; Tue, 16 Jan 2018 10:58:44 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BE41242F5 for ; Tue, 16 Jan 2018 10:58:44 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id t74so10501675wme.3 for ; Tue, 16 Jan 2018 10:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d3m7ijqe8vZJcFwZKTVCfWiRU+1Sbjt17fjrsTZlbZk=; b=N0NxyPjqWBZdS5HTiBv5e9QuXOJNXtDfGkdcqrkTLO3LeVPjiKbVziOuLLlYi94a0T Av6FKFHWgSzNxgxPUr+JNXR7YLNjK36zwtG67JnkzZRp0e4ka/5NMi1qS4u7Y361efHn 0IKjzVNi+EmmZrI1bmENL42/N3mDx316xFer3os3zvda5bsOSfYrT0OoslQSwGDNuC+2 KvEsAtABPfX+L7/6scfOghar7QtXdVffIxIx0qqlZKo6wl96bAQzbWF1hbegETJW8/ZT /ARjQY6TCqR1gqtxEaa921b0RagZB7EajjKrZNCrIVbzvbAOQGjUQBpswfK0EpOIPiYY xB4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d3m7ijqe8vZJcFwZKTVCfWiRU+1Sbjt17fjrsTZlbZk=; b=Zrcb+8W0jLDbv0yjT0tLLtg5dhR2yhTIuZI2DeKy/OvCikHT7ImE7Y9XetgS3Ak0Nu MB5N43DOukhA6Wlv8oZliesfnrkYkCZEJbMI4RBUiFZgksFKdjIkGmqZ3JWsFNEWLgZG 9xNfBCLVd6WfWqF6X0MWLFK0T0XXij+mCqI5IcvcJI+LEfWNqVPK5GJU9RZTkdUVtJdD bhEq5N+Ad+NQ1NuDqWbTrThZvcR0Ix/M/J5oTVbSGddQ20pFbn1ZNqmuzo7CttfuImU4 /eQRlgY11MpZ9lIuoKRxzgIxO0iO0VSn5IAnonXGkvvLLOYiNkv9+2iT5RuKdtw1X06H 39KA== X-Gm-Message-State: AKwxytfsG5Q/RSlCT0H3wbu7Ul05Ui+mojkPr0Uz1Y0neJRNumVVZCTZ JNGJIbdbRcOv90sEz3L0/wTXREnvI3Zp2fM/NmE= X-Google-Smtp-Source: ACJfBouT2FD1tq5bj0n1DMiv0Eon/hlRtV5qc2Q5EINj/jRnHVQyhQvqtx0Zfuqdg7YjkPYKU7veTosUDDFHb3MaqXI= X-Received: by 10.80.155.90 with SMTP id a26mr17098129edj.290.1516129122726; Tue, 16 Jan 2018 10:58:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Tue, 16 Jan 2018 10:58:02 -0800 (PST) In-Reply-To: References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> From: Tony Przygienda Date: Tue, 16 Jan 2018 10:58:02 -0800 Message-ID: To: Robert Wilton Cc: Jeff Tantsura , rift@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1af462cb39690562e9515b" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 18:58:49 -0000 --94eb2c1af462cb39690562e9515b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert, sure, thanks for the pointers, it looks interesting, let's see how it progresses and whether they produce a standard/implementation given it's right now a draft couple months old ... If someone has the drive and will do work on it I personally think that it's a viable discussion point whether something like this should be part of RIFT charter ... --- tony On Tue, Jan 16, 2018 at 9:56 AM, Robert Wilton wrote: > Hi Tony, > > I don't know of the relative benefits of protobuf vs thrift, but I was > more thinking of the "eat your own dog food", and I thought that one of t= he > aims for CBOR was to act as a robust encoding for protocol messages, i.e. > to replace the buggy TLV parsing. > > When I looked at CBOR it seemed to compare favorably (size and performanc= e > wise) to other binary serialization protocols. I.e. if a new IETF protoc= ol > is going to use a binary serialization protocol other than the IETF > specified one then at least it should warrant some proper discussion. ;-) > > Regarding specifying the format/schema definition (and validation of > messages), there is a CBOR WG draft for that: > https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl > > Thanks, > Rob > > > On 16/01/2018 17:09, Tony Przygienda wrote: > > Robert, the newest draft version says that protobuf is a fine alternative > to work with (but discussion thrift/protobuf is very comparable IMO @ > capabilities/conceptual span level and _someone_ would have to do the wor= k > to be more than a boilerplate ;-). And AFAIR CBOR is basically message > pack which would suffer from the JSON problem of having no type checking > or schema definition which makes it a fine proposition if you just "writi= ng > some internal code where the code is the schema" but how would you > standardize interoperable, backwards compatible formats/protocols that wa= y > and ensure minor/major versioning and so on? > > > Having said that, serialization is now a huge fertile ground with all kin= d > of ideas and endless packages roaming the field so the discussion would > really have to be "what are the properties of a serialization approach th= at > is useful to support solutions to the problem of type X". Having suffered > decades from subtle encoding problems on routing protocols in terms of bu= gs > and inter-operability issues I would not be particularly leaning towards > adopting anything that doesn't have strong schema and type checking for > that purpose. Of course the hand-written ser/de-sers in routing protocols > had a purpose beyond keeping programmers employed ;-), the packages were > not available and even if they were the available cycles and memory > footprints would not have had supported them until recently ... > > And then of course there's proof in the pudding of defining schema, > compiling it, making it run, seeing what really holds up @ scale ... And = if > you have something real for RIFT I'm always interested in having a more > detailed discussion, voice some more qualified opinions ;-) > > thanks > > ---- tony > > > > On Tue, Jan 16, 2018 at 2:04 AM, Robert Wilton wrote: > >> I was actually wondering whether it wouldn't be better for RIFT to use >> CBOR encoding rather than Thrift or protobuf (that the draft suggests as= a >> possible alternative). >> >> Are there reasons why Thrift is a better choice that CBOR (given that >> CBOR is IETF specified)? >> Thanks, >> Rob >> >> >> >> On 16/01/2018 00:44, Jeff Tantsura wrote: >> >> Hi, >> >> >> >> I find Adrian=E2=80=99s changes perfect and support the charter as per b= elow. >> >> Due to changes in my working situation I didn=E2=80=99t quite participat= e in >> initial discussion, starting now. >> >> >> >> I have got some ideas of using THRIFT/gRPC alike encoding schema=E2=80= =99s for >> more, than RIFT currently defines, for later thought. >> >> >> >> Cheers, >> >> Jeff >> >> >> >> *From: *Rift on behalf >> of Adrian Farrel >> *Reply-To: * >> *Date: *Monday, January 15, 2018 at 15:07 >> *To: * >> *Subject: *Re: [Rift] kicking off the charter discussion >> >> >> >> Hi, >> >> >> >> I joined this list a little late to have a neat head of thread to respon= d >> to, but here's a response to Alvaro's copy to routing-discussion. >> >> >> >> The charter text looks water-tight to me and I'd like to see this WG >> formed so that the whole community can work on RIFT. >> >> >> >> Maybe s/prominence/popularity/ >> >> >> >> There is a problem with the indentation in the deliverables... >> >> OLD >> >> - A Standards Track specification based on draft-przygienda-rift. The >> document will include: >> >> >> >> - an Implementation Status section as described in RFC 7942 >> >> - an Operational Considerations section to explain how the protocol is >> configured, deployed, and diagnosed >> >> - Security and Privacy Considerations, although this material may refe= r >> to a separate Threat Analysis document (q.v.). >> >> - A YANG module focused on configuration of protocol instances >> >> - An Applicability Statement that describes how to deploy and configur= e >> the protocol in networks with different topologies >> >> - A Security Threat Analysis document that describes the attack vector= s >> and mitigations that shall be sent for publication at the same time as t= he >> protocol specification. >> >> NEW >> >> - A Standards Track specification based on draft-przygienda-rift. The >> document will include: >> >> - an Implementation Status section as described in RFC 7942 >> >> - an Operational Considerations section to explain how the protoco= l >> is configured, deployed, and diagnosed >> >> - Security and Privacy Considerations, although this material may >> refer to a separate Threat Analysis document (q.v.). >> >> - A YANG module focused on configuration of protocol instances >> >> - An Applicability Statement that describes how to deploy and configur= e >> the protocol in networks with different topologies >> >> - A Security Threat Analysis document that describes the attack vector= s >> and mitigations that shall be sent for publication at the same time as t= he >> protocol specification. >> >> END >> >> >> >> Cheers, >> >> Adrian >> >> >> >> >> >> *From:* rtgwg [mailto:rtgwg-bounces@ietf.org ] *= On >> Behalf Of *Alvaro Retana >> *Sent:* 06 January 2018 03:25 >> *To:* routing-discussion@ietf.org; rtgwg@ietf.org >> *Subject:* Fwd: [Rift] kicking off the charter discussion >> >> >> >> FYI.. >> >> >> >> If you are interested in this topic, please make comments and send >> feedback on the rift@ietf.org list. >> >> >> >> Thanks! >> >> >> >> Alvaro. >> >> >> >> On January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com) wrote: >> >> Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG >> charters with Alvaro. Here is what we have so far. Comments and >> improvements would be most welcome. >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Routing in Fat Trees (RIFT) >> >> Clos and Fat-Tree topologies have gained prominence in data center >> networks as a result of a trend towards centralized data center network >> architectures that may deliver computation and storage services. >> >> The Routing in Fat Trees (RIFT) protocol addresses the demands of routin= g >> in Clos and Fat-Tree networks via a mixture of both link-state and >> distance-vector techniques colloquially described as 'link-state towards >> the spine and distance vector towards the leafs'. RIFT uses this hybrid >> approach to focus on networks with regular topologies with a high degree= of >> connectivity, a defined directionality, and large scale. >> >> The RIFT Working Group will work on a standards track specification of a >> specialized, dynamic routing protocol for Clos and fat-tree network >> topologies. The protocol will: >> >> - deal with automatic construction of fat-tree topologies based on >> detection of links, >> - minimize the amount of routing state held at each topology level, >> - automatically prune topology distribution exchanges to a >> sufficient subset of links, >> - support automatic disaggregation of prefixes on link and node failures >> to prevent black-holing and suboptimal routing, >> - allow traffic steering and re-routing policies, >> - and provide mechanisms to synchronize a limited key-value data-store >> that can be used after protocol convergence. >> >> It is important that nodes participating in the protocol should need onl= y >> very light configuration and should be able to join a network as leaf no= des >> simply by connecting to the network using default configuration. >> >> The protocol must support IPv6 and should also support IPv4. >> >> The Working Group may establish additional requirements to constrain and >> inform their work. >> >> The RIFT Working Group is chartered for the following list of items: >> >> - A Standards Track specification based on draft-przygienda-rift. The >> document will include: >> >> - an Implementation Status section as described in RFC 7942 >> - an Operational Considerations section to explain how the protocol is >> configured, deployed, and diagnosed >> - Security and Privacy Considerations, although this material may refe= r >> to a separate Threat Analysis document (q.v.). >> - A YANG module focused on configuration of protocol instances >> - An Applicability Statement that describes how to deploy and configur= e >> the protocol in networks with different topologies >> - A Security Threat Analysis document that describes the attack vector= s >> and mitigations that shall be sent for publication at the same time as t= he >> protocol specification. >> >> Milestones >> >> Feb 2018 Adopt a protocol specification document >> Feb 2019 Submit protocol specification to IESG for publication >> Feb 2019 Submit Threat Analysis to IESG for publication >> Apr 2019 Submit YANG module to IESG for publication >> Apr 2019 Submit Applicability Statement to IESG for publication >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Thanks, >> >> Alia >> >> _______________________________________________ >> Rift mailing list >> Rift@ietf.org >> https://www.ietf.org/mailman/listinfo/rift >> >> _______________________________________________ Rift mailing list >> Rift@ietf.org https://www.ietf.org/mailman/listinfo/rift >> >> >> _______________________________________________ >> Rift mailing listRift@ietf.orghttps://www.ietf.org/mailman/listinfo/rift >> >> >> >> _______________________________________________ >> Rift mailing list >> Rift@ietf.org >> https://www.ietf.org/mailman/listinfo/rift >> >> > > --94eb2c1af462cb39690562e9515b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Robert, sure, thanks for the pointers, it looks inter= esting, let's see how it progresses and whether they produce a standard= /implementation given it's right now a draft couple months old ... If s= omeone has the drive and will do work on it I personally think that it'= s a viable discussion point whether something like this should be part of R= IFT charter ...

--- tony

On Tue, Jan 16, 2018 at 9:56 AM, Robert Wil= ton <rwilton@cisco.com> wrote:
=20 =20 =20

Hi Tony,

I don't know of the relative benefits of protobuf vs thrift, but I was more thinking of the "eat your own dog food", and I t= hought that one of the aims for CBOR was to act as a robust encoding for protocol messages, i.e. to replace the buggy TLV parsing.=C2=A0

When I looked at CBOR it seemed to compare favorably (size and performance wise) to other binary serialization protocols.=C2=A0 I.e. if a new IETF protocol is going to use a binary serialization protocol other than the IETF specified one then at least it should warrant some proper discussion. ;-)

Regarding specifying the format/schema definition (and validation of messages), there is a CBOR WG draft for that: https:/= /datatracker.ietf.org/doc/draft-ietf-cbor-cddl

Thanks,
Rob



On 16/01/2018 17:09= , Tony Przygienda wrote:
=20
Robert, the newest draft version says that protobuf is a fine alternative to work with (but discussion thrift/protobuf is very comparable IMO @ capabilities/conceptual span level and _someone_ would have to do the work to be more than a boilerplate ;-).=C2=A0 And AFAIR CBOR is basically message pack which=C2=A0 would suffer from the JSON problem of having no type checking or schema definition which makes it a fine proposition if you just "writing some internal code where th= e code is the schema" but how would you standardize interoperable, backwards compatible formats/protocols that way and ensure minor/major versioning and so on?

Having said that, serialization is now a huge fertile ground with all kind of ideas and endless packages roaming the field so the discussion would really have to be "what are th= e properties of a serialization approach that is useful to support solutions to the problem of type X". Having suffered decades from subtle encoding problems on routing protocols in terms of bugs and inter-operability issues I would not be particularly leaning towards adopting anything that doesn't have strong schema and type checking for that purpose. Of course the hand-written ser/de-sers in routing protocols had a purpose beyond keeping programmers employed ;-), the packages were not available and even if they were the available cycles and memory footprints would not have had supported them until recently ...

And then of course there's proof in the pudding of definin= g schema, compiling it, making it run, seeing what really holds up @ scale ... And if you have something real for RIFT I'm always interested in having a more detailed discussion, voice some more qualified opinions ;-)

thanks

---- tony



On Tue, Jan 16, 2018 at 2:04 AM, Robert Wilton <rwilton@cisco.com> wrote:

I was actually wondering whether it wouldn't be better for RIFT to use CBOR encoding rather than Thrift or protobuf (that the draft suggests as a possible alternative).

Are there reasons why Thrift is a better choice that CBOR (given that CBOR is IETF specified)?

Thanks,
Rob



On 16/01/2018 00:44, Jeff Tantsura wrote:

Hi,

=C2=A0

I find Adrian=E2=80=99s changes perfect and support= the charter as per below.

Due to changes in my working situation I didn=E2=80= =99t quite participate in initial discussion, starting now.

=C2=A0

I have got some ideas of using THRIFT/gRPC alike encoding schema=E2=80=99s for more, than RIFT currently defines, for later thought.

=C2=A0

Cheers,<= /p>

Jeff

=C2=A0

From: Rift <rift-bounces@ietf.org> on behalf of Adrian Farrel <adrian@olddog.co.uk>
Reply-To: <adrian@olddog.co.uk>
Date: Monday, January 15, 2018 at 15:07
To: <rift@ietf.org>
Subject: Re: [Rift] kicking off the charter discussion

=C2=A0

Hi,

=C2=A0

I joined this list a little late to have a neat head of thread to respond to, but here's a response to Alvaro's copy to routing-discussion.

=C2=A0

The charter text looks water-tight to me and I'd like to see this WG formed so that the whole community can work on RIFT.

=C2=A0

Maybe s/prominence/popularity/

=C2=A0

There is a problem with the indentation in the deliverables...

OLD

- A Standards Track specification based on draft-przygienda-rift. The document will include:

=C2=A0

=C2=A0 - an Implementation Status section as described in RFC 7942

=C2=A0 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed

=C2=A0 - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).

=C2=A0 - A YANG module focused on configuration of protocol instances

=C2=A0 - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies

=C2=A0 - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

NEW

- A Standards Track specification based on draft-przygienda-rift. The document will include:

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 - an Implementation Status section as described in RFC 7942

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).

=C2=A0 - A YANG module focused on configuration of protocol instances

=C2=A0 - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies

=C2=A0 - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

END

=C2=A0

Cheers,<= /p>

Adrian

=C2=A0

=C2=A0

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alvaro Retana
Sent: 06 January 2018 03:25
To: routing-discussion@ietf.org; rtgwg@ietf.org
Subject: Fwd: [Rift] kicking off the charter discussion

=C2=A0

FYI..

=C2=A0

If you are interested in this topic, please make comments and send feedback on the rift@ietf.org=C2=A0list.=

=C2=A0

Thanks!

=C2=A0

Alvaro.

=C2=A0

On January 5, 2018 at 3:03:25 AM, Alia Atlas (akatlas@gmail.com) wrote:

Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG charters with Alvaro.=C2=A0 Here is what we have so far.=C2=A0 Comments a= nd improvements would be most welcome.

=C2=A0=

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Routing in Fat Trees (RIFT)

Clos and Fat-Tree topologies have gained prominence in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services.
=C2=A0
The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state toward= s the spine and distance vector towards the leafs'.=C2=A0 RIFT = uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale.
The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will:

- deal with automatic construction of fat-tree topologies based on detection of links,
- minimize the amount of routing state held at each topology level,
- automatically prune topology distribution exchanges to a sufficient=C2=A0subset of links, - support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing,
- allow traffic steering and re-routing policies,
- and provide mechanisms to synchronize a limited key-value data-store that=C2=A0can be used after protocol convergence.

It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration.

The protocol must support IPv6 and should also support IPv4.

The Working Group may establish additional requirements to constrain and inform their work.
The RIFT Working Group is chartered for the following list of items:

- A Standards Track specification based on draft-przygienda-rift. The document will include:

=C2=A0 - an Implementation Status section as described in RFC 7942 =C2=A0 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed
=C2=A0 - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.). =C2=A0 - A YANG module focused on configuration of protocol instances
=C2=A0 - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies
=C2=A0 - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

Milestones

=C2=A0 Feb 2018 Adopt a protocol specification document
=C2=A0 Feb 2019 Submit protocol specification to IESG for publication
=C2=A0 Feb 2019 Submit Threat Analysis to IESG for publication =C2=A0 Apr 2019 Submit YANG module = to IESG for publication
=C2=A0 Apr 2019 Submit Applicabilit= y Statement to IESG for publication

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks,

Alia

_________________= ______________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinf= o/rift

_____________________________= __________________ Rift mailing list Rift@ietf.org https://www.ietf.org/mailman/li= stinfo/rift 



_____________________________________________=
__
Rift mailing list
Rift@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/rift


_______________________________________________
Rift mailing list
Rift@ietf.or= g
https://www.ietf.org/mailman/listinfo/rif= t




--94eb2c1af462cb39690562e9515b-- From nobody Tue Jan 16 11:45:01 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A192D12EAAF for ; Tue, 16 Jan 2018 11:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tx3--3bfsnpc for ; Tue, 16 Jan 2018 11:44:57 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1D012420B for ; Tue, 16 Jan 2018 11:44:57 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id t20so5343948ote.11 for ; Tue, 16 Jan 2018 11:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JqhcdaMEQcywkKFI2roY7XC2C35IRScL4KAqxIZ5HSA=; b=h3cgiO97WhGk9b5YD1pJDrcibb8Hfdga8TOIll21tyaK1k2IwBTrJZ7/kzjpXepVJY CMg1rHMR+lNsM2SpLWeKoer2fzpzoKFTX23ZyALEQE1ZxWL8K7xqlSiHQl9Q1vMgUr3b Z4PwXOOrG4I5mIqGNyf7nzC8e/1qY6duf00L/jvgVG/qcCebCpKKFvoB1ZnFtPH2sau7 t/4mr+g6og5wsDSQAG0cP/6goBzYrRz+xGem/yaEuAOGPRlYGTwSRjPhYrZBL1l0h3F2 jqPTi3Ao7ZuCPAVz65RKkER4OKR7TT/gS22yLs8GrAlCBeynqoyWZnjBl+jqQZcmeIDf VKmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JqhcdaMEQcywkKFI2roY7XC2C35IRScL4KAqxIZ5HSA=; b=e5cmZbKaKZxVvtcdupWRaikoLUme1uzTxgM9r+/YDTDr/W94Rkoy6xjzPfV388sPcp 9wjtL6tj+6MH7Qbs9aMxfCIV0VgyZbeR9sXfPE1nQD+cUOQ5oYc3Okn1PEMgxYJUyw52 2Ygwb7lT/SgBeGlAdsWS2ji8HiFMf/aouvCfAI3BnAN/NMFW0gT9ibh/J0vlgkcVYkUs VQyXL34/JGACDA9D7m/A1sYxbPnDLcBXLPC7fw3fWuhMpJWVc8jqpfXqqF6qEbZdVsXk MMwIUf87Xtc6Cpr9qD3ExV4z/r/FqQDWaNz3Huynxf46me0QP5TGa4xhkvXWCyfAWI0c L7/A== X-Gm-Message-State: AKwxytcjPpsFqC5L2svpU1CEwa2yuWSkupa7CsBrEb0Xb/TtP7uYfFEy h0rrj4PMvCrVsln6XEYERQDV95JCLvcj36tk32k= X-Google-Smtp-Source: ACJfBouT8A+43UPSTVmYN9UWOBndslzS9Q9sN1TT4Snlwoq+A317jOxHHtY7jgp+Gac4ND5dN+S6Mu6YwAn1Y4gRhG8= X-Received: by 10.157.17.98 with SMTP id p31mr7764337otp.362.1516131896832; Tue, 16 Jan 2018 11:44:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.67.47 with HTTP; Tue, 16 Jan 2018 11:44:56 -0800 (PST) In-Reply-To: <3381E659-7DAE-44A4-97A2-5FA7D966189C@gmail.com> References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> <3381E659-7DAE-44A4-97A2-5FA7D966189C@gmail.com> From: Alia Atlas Date: Tue, 16 Jan 2018 14:44:56 -0500 Message-ID: To: Tony Li Cc: Tony Przygienda , Robert Wilton , Jeff Tantsura , rift@ietf.org Content-Type: multipart/alternative; boundary="001a113e15d624b8570562e9f796" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 19:45:00 -0000 --001a113e15d624b8570562e9f796 Content-Type: text/plain; charset="UTF-8" Tony, Thrift is used all over Apache and there are large ecosystems built on it. I had experience with protobuf when I worked at Google; that was over 10 years ago and while there has been evolution, it hasn't been radical. Again, there are large systems using this. Personally, I'd prefer to avoid the not-invented-here problems; there's a large amount of really excellent and solid open-source work. Specific technical concerns are, of course, important but also part of the meat of the planned WG. IMHO, it'd be a shame to believe that there are no better ways to do serialization/de-serialization than what the IETF did over 25 years ago. Regards, Alia On Tue, Jan 16, 2018 at 12:16 PM, Tony Li wrote: > > > On Jan 16, 2018, at 9:09 AM, Tony Przygienda wrote: > > And then of course there's proof in the pudding of defining schema, > compiling it, making it run, seeing what really holds up @ scale ... And if > you have something real for RIFT I'm always interested in having a more > detailed discussion, voice some more qualified opinions ;-) > > > > Luddite here. > > Do we have any worked examples of anyone using one of these packages long > term in a standard and demonstrating ongoing interoperability? It would > seem to me that unless folks are willing to mandate the schema file and the > version of the translator to use the odds of actual cross-implementation > cross-version interoperability are slim to none. > > Consider this one vote for traditional TLVs. > > Tony > > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift > > --001a113e15d624b8570562e9f796 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tony,

Thrift is used all over Apache an= d there are large ecosystems built on it.
I had experience with p= rotobuf when I worked at Google; that was over 10 years ago and while there=
has been evolution, it hasn't been radical.=C2=A0 Again, the= re are large systems using this.

Personally, I'= ;d prefer to avoid the not-invented-here problems; there's a large amou= nt of really
excellent and solid open-source work.=C2=A0 Specific= technical concerns are, of course, important but also
part of th= e meat of the planned WG.=C2=A0 IMHO, it'd be a shame to believe that t= here are no better ways to
do serialization/de-serialization than= what the IETF did over 25 years ago.

Regards,
Alia

On Tue, Jan 16, 2018 at 12:16 PM, Tony Li <tony1athome@gmail.com= > wrote:

On Jan 16, 2018, at 9:09 AM, Tony Przygien= da <tonysietf@g= mail.com> wrote:

And then of course= there's proof in the pudding of defining schema, compiling it, making = it run, seeing what really holds up @ scale ... And if you have something r= eal for RIFT I'm always interested in having a more detailed discussion= , voice some more qualified opinions ;-)=C2=A0


Luddite here. =C2=A0

Do w= e have any worked examples of anyone using one of these packages long term = in a standard and demonstrating ongoing interoperability? It would seem to = me that unless folks are willing to mandate the schema file and the version= of the translator to use the odds of actual cross-implementation cross-ver= sion interoperability are slim to none.

Consider t= his one vote for traditional TLVs.

Tony


_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift


--001a113e15d624b8570562e9f796-- From nobody Tue Jan 16 12:32:58 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144BC12EB00 for ; Tue, 16 Jan 2018 12:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 v5S-_ffnjJ7p for ; Tue, 16 Jan 2018 12:32:54 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 72DD9126C19 for ; Tue, 16 Jan 2018 12:32:54 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-04v.sys.comcast.net with ESMTP id bXttelEyqAAfabXugeO07h; Tue, 16 Jan 2018 20:32:54 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-12v.sys.comcast.net with SMTP id bXsTeTzSkXO7AbXsVehc5c; Tue, 16 Jan 2018 20:30:52 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tony Li In-Reply-To: Date: Tue, 16 Jan 2018 12:30:36 -0800 Cc: Tony Przygienda , Robert Wilton , Jeff Tantsura , rift@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0171B705-3058-45E2-BAF7-4EEA2FC203BC@tony.li> References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> <3381E659-7DAE-44A4-97A2-5FA7D966189C@gmail.com> To: Alia Atlas X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfMAts5DPumxh2JKNbyjPTt4sCf8slEHJDYAYeTVwdBEhkC8JdQzESwA2GNgyqwEoDhjUhQLY1lKizyM5xta6AmsQYSFNRHIl6RnF3Y8qHy+u1Ls8Wnlr fL5n94AeH6crnNtxUh2+MD1QnWPztcEgJTKQrO/cMQWQ19chY9UG7LJYSEiR4wEOI59dZsEYQ1Ei4n6+HAZSvdxQ738ihM6BkJe8xK0V/yfFgsYCeTEISRCU VOKthKWV61ElohZ0MJGJSrzl7XyUKTnQtvvURX/pR0VEEdh7QGe18+tCT511v4Pf Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 20:32:56 -0000 Alia, > Thrift is used all over Apache and there are large ecosystems built on = it. > I had experience with protobuf when I worked at Google; that was over = 10 years ago and while there > has been evolution, it hasn't been radical. Again, there are large = systems using this. >=20 > Personally, I'd prefer to avoid the not-invented-here problems; = there's a large amount of really > excellent and solid open-source work. Specific technical concerns = are, of course, important but also > part of the meat of the planned WG. IMHO, it'd be a shame to believe = that there are no better ways to > do serialization/de-serialization than what the IETF did over 25 years = ago. Thank you. Perhaps I should also point out that I=E2=80=99ve used = protobufs in a product or three already. I do understand the = capabilities and benefits and I like them. However, there are = limitations and I hope that folks recognize them before we go mandating = things. The IETF has had a long tradition of mandating the protocol but not the = implementation. This is moving the line. Big time. Please think very hard before doing this. Tony From nobody Tue Jan 16 12:34:41 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C9F12EB09 for ; Tue, 16 Jan 2018 12:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q8E3cimstbeb for ; Tue, 16 Jan 2018 12:34:34 -0800 (PST) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC3D12EB02 for ; Tue, 16 Jan 2018 12:34:33 -0800 (PST) Received: by mail-pl0-x231.google.com with SMTP id q2so7040165pll.3 for ; Tue, 16 Jan 2018 12:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I7XRlp69Irz4an41xolVGBHMC9lek9FUd/SWVawPSCk=; b=LB09nNJaDdAIVTv3uFooOzBYvwZmPIRa4hlPzsO/9WgjPdqnI9D2RPFok7PO8x8oEf umabJQg1mFSK69xtfk7QyL6xh6Lf97niSdaQUqYsb6GtiK9J4M3jNWqAmAzd5gWeTdm8 7qby7VO4kO1aAMOwWW2usR7mMoZfw9STNuYSZWWb/5zqaR5c9N99RBcMotuD/lgGv5cI MLc3QdOYZGRpfArCZPcs5hlyp6/FQnVbCmWEbsJxpgwafgQrrQmKalyL7l8DYE06bbvx fS39Q8jnsFxSXaXHRE2od6wS+jM8zC0EAbnjVWI+U/vCKVKSCQaqpBxJmWpl5jW6ebyl DSrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I7XRlp69Irz4an41xolVGBHMC9lek9FUd/SWVawPSCk=; b=ni+JuRYg5hQLslN/tvrUm0RgiSHcyJuREWS7HnP2nT/z1QIJ6C98Qdb7r+dtyWQhXN 827Hmkh20VDkUuxTSDugtLGXk6BG2IopHx1fwt4kAM7OBNo8C7QmnubUujMuPOj7wPSt ZoVm2rtUCPZ2l88Ck2Eh3vJQTQN9HA/lOhKJP/kgcoqf3fUmj1oq7ms0UNPjJvJwVI14 Nw0cP611e08pB5CBrphv79ZISrZG8lX0BQ/t3IOfMMvWnODHL8WPsBB/4ao5QNfor4Y1 kIZ9Kov416VDEnDerVJOro7s5UWC+qQy8egw/KcOKY02SyJg3mtWcTZ6Yo7kqb3tLKyW j35A== X-Gm-Message-State: AKwxytdhxm9PFiVhqlxaVaojmgSXsYGTDey8Om9jgo8/zNRphBcyjFf0 biTj73Z0NbjpDkGNYcg3RWk= X-Google-Smtp-Source: ACJfBouQMmUDtDhr4B0GEk7pn8LNX+2ipOG0LiBpWRBO6vS0RWOnicQHhoRGIOfO99PksRqSOv9h2A== X-Received: by 10.84.212.151 with SMTP id e23mr818942pli.194.1516134873001; Tue, 16 Jan 2018 12:34:33 -0800 (PST) Received: from [172.22.228.216] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id r9sm3954608pgp.78.2018.01.16.12.34.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jan 2018 12:34:32 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tony Li In-Reply-To: Date: Tue, 16 Jan 2018 12:34:31 -0800 Cc: Tony Przygienda , Robert Wilton , Jeff Tantsura , rift@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8E79B970-71CF-4763-B541-D8088336100B@gmail.com> References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> <3381E659-7DAE-44A4-97A2-5FA7D966189C@gmail.com> To: Alia Atlas X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 20:34:40 -0000 Alia, > Thrift is used all over Apache and there are large ecosystems built on = it. > I had experience with protobuf when I worked at Google; that was over = 10 years ago and while there > has been evolution, it hasn't been radical. Again, there are large = systems using this. >=20 > Personally, I'd prefer to avoid the not-invented-here problems; = there's a large amount of really > excellent and solid open-source work. Specific technical concerns = are, of course, important but also > part of the meat of the planned WG. IMHO, it'd be a shame to believe = that there are no better ways to > do serialization/de-serialization than what the IETF did over 25 years = ago. Thank you. Perhaps I should also point out that I=E2=80=99ve used = protobufs in a product or three already. I do understand the = capabilities and benefits and I like them. However, there are = limitations and I hope that folks recognize them before we go mandating = things. The IETF has had a long tradition of mandating the protocol but not the = implementation. This is moving the line. Big time. Please think very hard before doing this. Tony From nobody Tue Jan 16 12:45:03 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6DA12EB14 for ; Tue, 16 Jan 2018 12:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 lkFLwHceNo-D for ; Tue, 16 Jan 2018 12:45:00 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31AD312EB09 for ; Tue, 16 Jan 2018 12:44:59 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id y141so11598470oia.0 for ; Tue, 16 Jan 2018 12:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0E7swTwds/1St2vUJSEbOXMdFj9GWwpuPMGV2bA1E50=; b=c64o5rL4iwE3xpbOanr7sSlm2G8ZrzIB14JOToflQWAcOWllFE85Sp9qGsXpr5KiSI chNdL13pH7Dur/T23ggTApcDyWPwGQbSOJRi7GUwMkB0LxhhuuxVB4PlNqY5dJFxgwiw ecoLopXaRUwLp28IlKGTfCW035YHacupoSav2tWPkv7hn9/DCMuecdlqYvvo/8e6iyC3 ZiXmla0GAj9+4IHJELiYEXFnP5IOvTyBH+pMgmpg5kW9Pb/mUKOlSTPczVp0m6YZJeng pDAAux7wsyQoLTxQhDBIYDB4ePThkosznD+U+0jt2Hvxbz4+B9mxuT9mCZT47eMbwlKF kZjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0E7swTwds/1St2vUJSEbOXMdFj9GWwpuPMGV2bA1E50=; b=Ee90ie4vp3a+AGVMsTrU9FCFk/m6isielNEv0S5b3F3mZuFxu3o7kmfoaCZSmzMS5/ fjSoAnx35AZKZcvk0oUGeWAns4ihEUWPwIGFRbriKqUpQ+ogRf9wnACaCi3GfLkAFvyl g9HKwkUcPpZaEO6MjfA9vimMphdGY+un8RrnXyCER8ArpWto53PaQ0XoriQuOQiEVgQo kKH9VmtShE7Que5gGKNuCOXVNsgcjX4OPsmRk4Xgis+A0TUDF8FdrvRDvKeNT+53VIwE byp/ZCYt1xvOcuPEXlibpj5CHdP1aYr5L907JLrjaOpKcAVLpSpkgYf7ZemibYOSF+Kz MQCA== X-Gm-Message-State: AKwxytel/EzDqkvzhQXgZOgrW7oT3dG3sthksoE+QjjlE4nerI3isIRN Ob8/auG741B4sviFL3eI4jF22duNvBpW/wQ530s= X-Google-Smtp-Source: ACJfBosYYKtykMbbz6k8xHob/crUklfIQHQu7T75BL1qvE1X9lIQK3qFir/xpldJX7ldkiw3YGxWG+jet5dD7BOzOXU= X-Received: by 10.202.215.6 with SMTP id o6mr1695834oig.108.1516135498228; Tue, 16 Jan 2018 12:44:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.67.47 with HTTP; Tue, 16 Jan 2018 12:44:57 -0800 (PST) In-Reply-To: <0171B705-3058-45E2-BAF7-4EEA2FC203BC@tony.li> References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> <3381E659-7DAE-44A4-97A2-5FA7D966189C@gmail.com> <0171B705-3058-45E2-BAF7-4EEA2FC203BC@tony.li> From: Alia Atlas Date: Tue, 16 Jan 2018 15:44:57 -0500 Message-ID: To: Tony Li Cc: Tony Przygienda , Robert Wilton , Jeff Tantsura , rift@ietf.org Content-Type: multipart/alternative; boundary="001a113d38aecda8d90562eacdd4" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 20:45:02 -0000 --001a113d38aecda8d90562eacdd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tony, On Tue, Jan 16, 2018 at 3:30 PM, Tony Li wrote: > > Alia, > > > Thrift is used all over Apache and there are large ecosystems built on > it. > > I had experience with protobuf when I worked at Google; that was over 1= 0 > years ago and while there > > has been evolution, it hasn't been radical. Again, there are large > systems using this. > > > > Personally, I'd prefer to avoid the not-invented-here problems; there's > a large amount of really > > excellent and solid open-source work. Specific technical concerns are, > of course, important but also > > part of the meat of the planned WG. IMHO, it'd be a shame to believe > that there are no better ways to > > do serialization/de-serialization than what the IETF did over 25 years > ago. > > > Thank you. Perhaps I should also point out that I=E2=80=99ve used protob= ufs in a > product or three already. I do understand the capabilities and benefits a= nd > I like them. However, there are limitations and I hope that folks recogni= ze > them before we go mandating things. > Absolutely! I'm not surprised that you have familiarity with them - and discussing the benefits and limitations would be very useful. > The IETF has had a long tradition of mandating the protocol but not the > implementation. This is moving the line. Big time. > I think the intent would be to reference a suitable document for Thrift or protobufs - not to mandate a particular implementation be used. Separately from the RIFT work, but addressing this type of issue, I co-authored draft-atlas-external-normref-00 which is trying to clarify and describe under what circumstances a reference to an external specification is acceptable and how to handle that. Please think very hard before doing this. Many of us are familiar with the problems of a pervasive single implementation - with the associated bugs and fragility. My personal hope is re-use and improvement, so that we can describe in data models and get out of a requirement for hand-written special-cased code. Regards, Alia > Tony > > > --001a113d38aecda8d90562eacdd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tony,

On Tue, Jan 16, 2018 at 3:30 PM, Tony Li <tony.li@tony.li> wrote:

Alia,

> Thrift is used all over Apache and there are large ecosystems built on= it.
> I had experience with protobuf when I worked at Google; that was over = 10 years ago and while there
> has been evolution, it hasn't been radical.=C2=A0 Again, there are= large systems using this.
>
> Personally, I'd prefer to avoid the not-invented-here problems; th= ere's a large amount of really
> excellent and solid open-source work.=C2=A0 Specific technical concern= s are, of course, important but also
> part of the meat of the planned WG.=C2=A0 IMHO, it'd be a shame to= believe that there are no better ways to
> do serialization/de-serialization than what the IETF did over 25 years= ago.


Thank you.=C2=A0 Perhaps I should also point out that I=E2=80=99ve u= sed protobufs in a product or three already. I do understand the capabiliti= es and benefits and I like them. However, there are limitations and I hope = that folks recognize them before we go mandating things.

Absolutely!=C2=A0 I'm not surprised that you have fam= iliarity with them - and discussing the benefits and limitations would be v= ery useful.
=C2=A0
The IETF has had a long tradition of mandating the protocol but not the imp= lementation. This is moving the line. Big time.

I think the intent would be to reference a suitable document for T= hrift or protobufs - not to mandate a particular implementation be used.
Separately from the RIFT work, but addressing this type of issue,= =C2=A0 I co-authored draft-atlas-external-normref-00 which is trying to cla= rify
and describe under what circumstances a reference to an exte= rnal specification is acceptable and how to handle that.

Please think very hard before doing this.

M= any of us are familiar with the problems of a pervasive single implementati= on - with the associated bugs and fragility.=C2=A0
My persona= l hope is re-use and improvement, so that we can describe in data models an= d get out of a requirement for hand-written
special-cased code.

Regards,
Alia

= =C2=A0
Tony



--001a113d38aecda8d90562eacdd4-- From nobody Tue Jan 16 12:45:53 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE7812EB10 for ; Tue, 16 Jan 2018 12:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 h_Cg5F5Gd1fx for ; Tue, 16 Jan 2018 12:45:51 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C4C12EB09 for ; Tue, 16 Jan 2018 12:45:50 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id v71so11337927wmv.2 for ; Tue, 16 Jan 2018 12:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DKbpujIPV+Fq/+1+ZX8MtIs+eDAES64LnQdavborQNY=; b=Zuv+Gqz2pUy76A6Ql/O0xD+Lxt/SJ5EAVDKuwRIFYhY29AJ4bdoerulRfrF2flqUsL vx9TWGOK+wwVE2cDN8tvcPhf2+o1o9jwjG81d/Iu7P0lcUFJldhUKXivqJ0/kQcg1DQj J57WB1k+Cp8INe5LzQ3MXEwdyTWQHLZfrjgUqwuwJi9tu0T0ldPANJVxAGH23gS1Glv4 g605F99/jcgrcDqnOn2Lh/dSCy3i5m9WdrdrY4YcUleFgSL51BCLmVb47HvYKpXfMXPi q1PraRrI2VM7oV5jKwvI307CQYHwt5jDzzsnP3YcSyeamgM3s2QzMafQmHEtcP/5wSJP fNeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DKbpujIPV+Fq/+1+ZX8MtIs+eDAES64LnQdavborQNY=; b=hSBVJoCk1TYJ+scXLrh9C/ef2EzPqIrCIyhXEXjiQaEiTAHLgpkvoSK5AG5HcO+Hg6 gIuX2VdvR6nH727YDCv2rZF6zPsEVZy7S9Ya2YJi5HN8OzCX28Dl28v6Q/cVXZ1524ge 5aLwHDMTOh4WFfGEJnuK5L11efoDKP8UXq1+FLTbOQgZfAq212lRerF7wB4lnH9WNg3h XxqvZ53bDxCiWXhazI6gBOD4g6f2Q9UaFnagCeHDxl7Eiuc13bG6QBNEu+knh1t+8Uc5 yz0Lb1/QAPwfGfm386nKLd68WybkLuBoDmAuaVFX2abNj3KZoksHlnKwrvY0VFDe/Jzv PBKw== X-Gm-Message-State: AKwxytcAN56g0Zbx96DAIoLRuGbccZkaWpoiqri2zKMVjmxlNi74pD96 Hex08b03TIxGPWjaeB+WJidwXgi2WpoVhGWCj5Y= X-Google-Smtp-Source: ACJfBosODRu/i91IOed4PsGS+qz+2qKIqtHQMlvs/7Ec/qbBxkpwOBWK2REOTYsrrUgeDUEcn0WZJB59NEDOCgQADWQ= X-Received: by 10.80.206.88 with SMTP id k24mr14086565edj.153.1516135549268; Tue, 16 Jan 2018 12:45:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Tue, 16 Jan 2018 12:45:08 -0800 (PST) In-Reply-To: <8E79B970-71CF-4763-B541-D8088336100B@gmail.com> References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> <3381E659-7DAE-44A4-97A2-5FA7D966189C@gmail.com> <8E79B970-71CF-4763-B541-D8088336100B@gmail.com> From: Tony Przygienda Date: Tue, 16 Jan 2018 12:45:08 -0800 Message-ID: To: Tony Li Cc: Alia Atlas , Robert Wilton , Jeff Tantsura , rift@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1b26d4d874d50562ead0e9" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 20:45:52 -0000 --94eb2c1b26d4d874d50562ead0e9 Content-Type: text/plain; charset="UTF-8" > The IETF has had a long tradition of mandating the protocol but not the > implementation. This is moving the line. Big time. > Here I'm somehow missing the point utterly. How is providing a schema mandating the implementation? Is Yang mandating implementations and we should stop it today? And providing TLV is also "mandating implementation" and saying I would argue "it has to run on TCP" even more so ... no'one says anywhere "you must use compiler X or language Y or processor Z or anything like that". We just use _a practical_ schema language to get off the cycle of hand-knit parsers and non-orthogonal encodings everywhere to increase the maintainability and delivery cycles of code. NIY is another topic and orthogonal ... --- tony --94eb2c1b26d4d874d50562ead0e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=
The IETF has had a long tradition of mandating the protocol but not the imp= lementation. This is moving the line. Big time.

Here I'm somehow missing the point utterly. How is= providing a schema mandating the implementation? Is Yang mandating impleme= ntations and we should stop it today? And providing TLV is also "manda= ting implementation" and saying I would argue "it has to=C2=A0 ru= n on TCP" even more so ... no'one says anywhere "you must use= compiler X or language Y or processor Z or anything like that". We ju= st use _a practical_ schema language to get off the cycle of hand-knit pars= ers and non-orthogonal encodings everywhere to increase the maintainability= and delivery cycles of code.

NIY is another = topic and orthogonal ...

--- tony
<= /div>
--94eb2c1b26d4d874d50562ead0e9-- From nobody Tue Jan 16 12:47:56 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2565712D7F7 for ; Tue, 16 Jan 2018 12:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 YfQ0kBJFtt1d for ; Tue, 16 Jan 2018 12:47:54 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC1C12EB15 for ; Tue, 16 Jan 2018 12:47:53 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id r78so11363143wme.0 for ; Tue, 16 Jan 2018 12:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=odFcSTgV07+JQb8SUfD5oFMcFV7mI5KGstqsVx0Z9Y0=; b=pVeBZQRZrejRvvrpvGuYSOeEd3BKFgRJsewl92o1+yIdy0hwwUEVMauU3/6ML5+NfC dYqDFhfDjwTCFa6mEW/a9q+/bFx+oXcHL0ZLkGblsOJMotUiowX9V5U2HRRZzpMa7hxs KA6bocPSOgXht8dQw5n/pE/zpjFctjmghSxnOXsxrzw/bwonI64umrrsMJz6YpOBAeF1 fZbW9mFxWy4tk2G4zxdxwZH7O39+QdD68UZ15rLDR5tTYMmWb/BEapkTq+Y2E2risIV5 DsatJ4+n/XCWXDMN6qUvRcBrMxlC5/2Wcnzsyi16a9Lpzv+tI1ux8elgVC2+BLThj8fO AUMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=odFcSTgV07+JQb8SUfD5oFMcFV7mI5KGstqsVx0Z9Y0=; b=KC9FTahjOcv/i+DOmrCm0/ifgTArVy8q0wnTA3Nn/pOGlTMHW1kWuRtJV+t9+le3nr Xd1q14BQao6hvwczsLg+8CO6ksC41DdOnbfOb5LAGAEfqiYiLGY+rSHqG/NqrWWBGQKz 4Cwgy0dnx9y4XX2QCO/k799UmJoLUSOXH8w6YJBWxWAJzSHI6KVrZWYUC48yeL2OVs3X E0bK2/lMZa3oS7pGata1LnANfJ6e0vdcpyoR0kV7bNIUCiZvpEVAfoImpvdxpu+p+HjI Jr21PyazdYaAkxmfKULjHlQwAzrs0ZiBusGQ1XcaNlZIF9ddawr7mBSZKoq6yQ7HI+jY hcuw== X-Gm-Message-State: AKwxyteKoXbUjJFLVwIcy+aXQcee4yZNzduBppMVvpJ85LEyu5VheitL j0l1ttBe4iYDXNON5Aruiu3KMmn9NHS4q7Kwp1E= X-Google-Smtp-Source: ACJfBosd0CbEWsZJrzKPIn/1hWdXVw0DQFLiCKUkbvPUqym9sXwcjgSAPNwxluso+gAjQNUxSHC18p4mjt3uRf+H2CI= X-Received: by 10.80.217.6 with SMTP id t6mr112082edj.171.1516135672324; Tue, 16 Jan 2018 12:47:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Tue, 16 Jan 2018 12:47:11 -0800 (PST) In-Reply-To: References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> <3381E659-7DAE-44A4-97A2-5FA7D966189C@gmail.com> <8E79B970-71CF-4763-B541-D8088336100B@gmail.com> From: Tony Przygienda Date: Tue, 16 Jan 2018 12:47:11 -0800 Message-ID: To: Tony Li Cc: Alia Atlas , Robert Wilton , Jeff Tantsura , rift@ietf.org Content-Type: multipart/alternative; boundary="089e082216482e27e20562ead8e0" Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 20:47:55 -0000 --089e082216482e27e20562ead8e0 Content-Type: text/plain; charset="UTF-8" > > NIY is another topic and orthogonal ... > > Sorry, NIH of course (as in IBM and DEC times where only hand-brewed-at-home was worthy enough) ... --- tony --089e082216482e27e20562ead8e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0

NIY is another topic a= nd orthogonal ...


Sorry, NIH of course (as in IBM and DEC times where only hand-brewe= d-at-home was worthy enough) ...

--- tony

--089e082216482e27e20562ead8e0-- From nobody Tue Jan 16 13:01:31 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26A712EB1B for ; Tue, 16 Jan 2018 13:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 IPlCfnQh5w5L for ; Tue, 16 Jan 2018 13:01:28 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (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 90B9312D778 for ; Tue, 16 Jan 2018 13:01:28 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-11v.sys.comcast.net with ESMTP id bYLNeDlc8b6ygbYMKeLB4j; Tue, 16 Jan 2018 21:01:28 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-02v.sys.comcast.net with SMTP id bYK6e8iL7e2qebYK9eKskk; Tue, 16 Jan 2018 20:59:26 +0000 From: Tony Li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_76FC2453-D3FD-43A3-B2D9-AB97D370EB35" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 16 Jan 2018 12:59:10 -0800 In-Reply-To: Cc: Alia Atlas , Robert Wilton , Jeff Tantsura , rift@ietf.org To: Tony Przygienda References: <002601d38727$57b4b010$071e1030$@olddog.co.uk> <029901d38e55$a1a473b0$e4ed5b10$@olddog.co.uk> <06E31BAE-90B8-4D68-A362-FA69D9ACCCB5@gmail.com> <3a574ec6-5969-7676-99c8-f18369af866c@cisco.com> <3381E659-7DAE-44A4-97A2-5FA7D966189C@gmail.com> <8E79B970-71CF-4763-B541-D8088336100B@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfIo9JEq7X/tgkO/xy6MzuQVeDRG1l18ETbGpSVbX5VSYrmIukKnqwSPABJT8QBoskamBAQnm8bnx4yTRXdWx4uJDz41tiMkpXJ7FUl5/bP/PxFmc732O ODhNHjkW609f090DX0Th5oRaw4oaWhdnFlsJdW/0To8/DjgbTCRPmLvbu5PQbobmbnoKFcCp4e5MOKHsTxwcAZJ1YlUqRBl6zyEGEOl/F2nY1+MDluOlvuOV GSFDzMtr9TfDBTWmxn8Mam1AaI0uxm4PYC+XERTYLZa1LCRGnp3xcs22yvHOVSPS Archived-At: Subject: Re: [Rift] kicking off the charter discussion X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 21:01:30 -0000 --Apple-Mail=_76FC2453-D3FD-43A3-B2D9-AB97D370EB35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > The IETF has had a long tradition of mandating the protocol but not = the implementation. This is moving the line. Big time. >=20 > Here I'm somehow missing the point utterly. How is providing a schema = mandating the implementation? Is Yang mandating implementations and we = should stop it today? And providing TLV is also "mandating = implementation" and saying I would argue "it has to run on TCP" even = more so ... no'one says anywhere "you must use compiler X or language Y = or processor Z or anything like that". We just use _a practical_ schema = language to get off the cycle of hand-knit parsers and non-orthogonal = encodings everywhere to increase the maintainability and delivery cycles = of code.=20 If we select Thrift/protobuf/CDDL and publish a schema, then we are = putting a stake in the ground. =46rom that point, implementors are = pretty restricted. Just how many processors do you expect to exist given = a particular DDL and target language? The pragmatic answer is one. = Further more, there will be N versions of that one, each with its own = quirks and not necessarily backward compatible. Tony --Apple-Mail=_76FC2453-D3FD-43A3-B2D9-AB97D370EB35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The IETF has had a long tradition of = mandating the protocol but not the implementation. This is moving the = line. Big time.
Here I'm somehow missing the point = utterly. How is providing a schema mandating the implementation? Is Yang = mandating implementations and we should stop it today? And providing TLV = is also "mandating implementation" and saying I would argue "it has = to  run on TCP" even more so ... no'one says anywhere "you must use = compiler X or language Y or processor Z or anything like that". We just = use _a practical_ schema language to get off the cycle of hand-knit = parsers and non-orthogonal encodings everywhere to increase the = maintainability and delivery cycles of code.


If we select = Thrift/protobuf/CDDL and publish a schema, then we are putting a stake = in the ground. =46rom that point, implementors are pretty restricted. = Just how many processors do you expect to exist given a particular DDL = and target language? The pragmatic answer is one. Further more, there = will be N versions of that one, each with its own quirks and not = necessarily backward compatible.

Tony

= --Apple-Mail=_76FC2453-D3FD-43A3-B2D9-AB97D370EB35-- From nobody Wed Jan 17 15:48:03 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B2712EAC9 for ; Wed, 17 Jan 2018 15:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 RRUQpJTwbmuZ for ; Wed, 17 Jan 2018 15:48:00 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78CC12EA97 for ; Wed, 17 Jan 2018 15:47:59 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id b11so1692622oif.2 for ; Wed, 17 Jan 2018 15:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=+cy4SY9HeKIKsnKnPttgWGmHtizlCRecM/qF3djiN1U=; b=ogH50aURR2mDzHzsyX9YOTA+rHuD3UC3uYbmmVArIuUcaHjceJlWXyZmQxA/qOttCE BFAopsIvqhwn/exuUVRhkacizdJS0DtzBXhd5EpsfIKHj4LGsm6sOa6PhW6W4bPKzsni 9dhLRXvU+AO5TbBKJ48KAllNRsHs6oj0YJf9p/O9z1FYA1kxl9IZp7dqjc0zM7aypbxt xfx2oYha7jpvSTvY20DcutAYN/uZ5NiVv1I46s90i9Afi3GVMtnF8M2DN/m3c5tiEyBb FvuLKo0lzMY13zqn3jCoYVVvW0EFjr97Z5HQP1bzusm/nVjkXcLQSYh0gGalWNW5S/SY K6Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=+cy4SY9HeKIKsnKnPttgWGmHtizlCRecM/qF3djiN1U=; b=C8sOJZHj8T1N1Ips/THgYwNnprf8pY21Q9h2KiadVl48+Gv64+wc54o2tfOPLccCOC NST6AdOyoNyIRO4KZD6FDy3oebIQafRu/RbF/mZGydPj4X5iayNDKXnAosBSHyR3W+12 PApJRzJ81lTLfIvpw3GSlQMmkx51QIAXJpAfYJ+8/9dStM6+SXx8UY7rFrtv8NvPEIMg P0ZE1kAhOD4ixPGryoA3gmvwdpjqN9M/ZiH8p0GRgkc6itrQAVdMVk97GMMgxBOinwZi lzT2DTKK5fdozJm0Ye0nQ8DRSxIAkeKw6wISF9//rr6FyX+cCCxV+Kjv8D6ptNJ6NeQ3 k4BA== X-Gm-Message-State: AKwxytdV/STKJiF5kBuJiYLmIR5RhGUhJYzhRrkU7J+O3d8btxzYXyw/ mSEQddLI463NPEmZCyfm4uYmor7n9mjpwitpT8M= X-Google-Smtp-Source: ACJfBospzQVeAGtRs9zkBJ2iBA5sjI2VKLI8XducPnLi3sQFFNHD8J6UFO8nBaQrdeP/tHz4AWiwRdWwsAX0N0ccpL4= X-Received: by 10.202.72.69 with SMTP id v66mr1935527oia.214.1516232879074; Wed, 17 Jan 2018 15:47:59 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 17 Jan 2018 15:47:58 -0800 From: Alvaro Retana X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Wed, 17 Jan 2018 15:47:58 -0800 Message-ID: To: rift@ietf.org Content-Type: multipart/alternative; boundary="001a1134fe582774050563017a42" Archived-At: Subject: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2018 23:48:01 -0000 --001a1134fe582774050563017a42 Content-Type: text/plain; charset="UTF-8" Hi! It looks like the discussion has now moved to topics that should be dealt with in the WG itself, so I have started the formal review process. The intent is to have a WG formed by IETF 101. You can follow along here: https://datatracker.ietf.org/doc/charter-ietf-rift/ Thanks! Alvaro. --001a1134fe582774050563017a42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi!

It looks like the discussion has now moved to topics that should b= e dealt with in the WG itself, so I have started the formal review process.= =C2=A0 The intent is to have a WG formed by IETF 101.

You can follow along here:=C2=A0https://datatracker.i= etf.org/doc/charter-ietf-rift/=C2=A0

Thanks!

Alvaro.

--001a1134fe582774050563017a42-- From nobody Thu Jan 18 00:33:43 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC0B12EB1D for ; Thu, 18 Jan 2018 00:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 A6yFba4KQHZL for ; Thu, 18 Jan 2018 00:33:26 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B783112EB21 for ; Thu, 18 Jan 2018 00:33:26 -0800 (PST) Received: from [192.168.1.10] (unknown [119.94.164.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9CE7918013B2; Thu, 18 Jan 2018 09:33:23 +0100 (CET) To: Alvaro Retana , rift@ietf.org References: From: Loa Andersson Message-ID: <29fe7962-cfbb-6ce3-b4aa-b31a75f6c03b@pi.nu> Date: Thu, 18 Jan 2018 16:33:17 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 08:33:32 -0000 Alvaro, Tnx, yes I think that is the case. One thing before we go ther. To my understanding "fat tree" and "clos" are not (exactly) the same thing, if we name the working group "Routing In Fat Trees", there is a risk (very small) that we leave "Clos" at the road side. Could we keep the abbreviation (rift) but change the name to Routing in Fat Tree and Clos". /Loa On 2018-01-18 07:47, Alvaro Retana wrote: > Hi! > > It looks like the discussion has now moved to topics that should be > dealt with in the WG itself, so I have started the formal review > process.  The intent is to have a WG formed by IETF 101. > > You can follow along here: > https://datatracker.ietf.org/doc/charter-ietf-rift/ > > Thanks! > > Alvaro. > > > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jan 18 06:15:07 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D662120726 for ; Thu, 18 Jan 2018 06:15:06 -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_PASS=-0.001, UNPARSEABLE_RELAY=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 KJ8rf1SFra0T for ; Thu, 18 Jan 2018 06:15:04 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32211205D3 for ; Thu, 18 Jan 2018 06:15:04 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id r4so16344632oti.12 for ; Thu, 18 Jan 2018 06:15:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=oXNSRTM25iVEPtkPBxYAQAoPN5hiQ5yykjMSis8y1/0=; b=t+P4o6dtFAaR7eKYuppKMZ1jNoQAJCEvCzV5mdxQGUa/nPXWEANW1V1yIHEIUA5hY1 vnl+CE40Kz9EYqTJljqytOb7khZeQqdRI4firTz8AAWug1JQnFDld+L+kz4N43IuH5WO VzAWIsK7VX6woWoJQZAeyzZ2/x3mOo5tSk5J1eiMzsZQfAPYwi9l43ue94L2wbAKLYNz 7SvcWJ3G6/MPNUCTd8Rfrcto6amYv9dLe9SneVmGHbCLDqOca4HFX/Rl+jTrtscRlQpi wQmKdbvJphDjGjwPei09dkiW08Vr9oh/Uo7/2qRowNcI8bLJ7CC9cSqNOXnvidHsPMEZ 9sJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=oXNSRTM25iVEPtkPBxYAQAoPN5hiQ5yykjMSis8y1/0=; b=HzFjT4xWLdD4MNToH2EwP/kybijrItf+qE3Kh71/u8pdKMPa8BhczwYkqFFGNiDv3w dV5RVx4dF3wwfPyCO6aUPZ2QKNHAyl2mfTDTjtDHKN5tuzoMTwZEOGG7w0BzbvJKOM7r WUJm5S3f6Cjxyo+p+5xHPoTcMDSXutk3y68hLcdk+nZX81dP/LXvRx64iL4A3otEzjIl No6psBYIjdqpOT37hCm9CoPIBrywCx3oeh0P9+LQ1WLigRqJbM6PaLiiaSDIqIHk0iHD Jq9YOT1Wrk5KU9spRnmfOyPE7WEBnb0186z4M4+o88qwL6N3fRG39nvvixVouqUMxegv lX2g== X-Gm-Message-State: AKwxytdS8oLO4cO9xUOYvi6BjR+FdmoDsU0A/Ow2KhjGpfFUYfTTDgpb 4gWsLAYPAbmGIeABvd6X00XSGDY4Ix5HP7UWkek= X-Google-Smtp-Source: ACJfBotX/kYtLFRMdt+6C8+e1F2A72Vdy19HJZwBvug3hV9LZdWGGB7XUg3KvD+vXvgeH11G85a2Q7J9e9LNWKKTF+c= X-Received: by 10.157.22.220 with SMTP id s28mr3181958ots.317.1516284904187; Thu, 18 Jan 2018 06:15:04 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 18 Jan 2018 06:15:03 -0800 From: Alvaro Retana In-Reply-To: <29fe7962-cfbb-6ce3-b4aa-b31a75f6c03b@pi.nu> References: <29fe7962-cfbb-6ce3-b4aa-b31a75f6c03b@pi.nu> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Thu, 18 Jan 2018 06:15:03 -0800 Message-ID: To: Loa Andersson , rift@ietf.org Content-Type: multipart/alternative; boundary="001a113e4d2a17b01c05630d97eb" Archived-At: Subject: Re: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 14:15:06 -0000 --001a113e4d2a17b01c05630d97eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On January 18, 2018 at 3:33:25 AM, Loa Andersson (loa@pi.nu) wrote: Loa: Hi! To my understanding "fat tree" and "clos" are not (exactly) the same thing, if we name the working group "Routing In Fat Trees", there is a risk (very small) that we leave "Clos" at the road side. Could we keep the abbreviation (rift) but change the name to Routing in Fat Tree and Clos". I don=E2=80=99t think that=E2=80=99s necessary as long as the charter is sp= ecific about what the WG will be doing. IOW, I think the name is not as important as the charter. Do we need to update the charter to make sure your point is captured? Thanks! Alvaro. --001a113e4d2a17b01c05630d97eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On January 18,= 2018 at 3:33:25 AM, Loa Andersson (loa@pi.nu<= /a>) wrote:



To my under= standing "fat tree" and "clos" are not (exactly) the sa= me=C2=A0
thing, if we name the working group "Routing In Fat Tr= ees", there is a=C2=A0
risk (very small) that we leave "Cl= os" at the road side. Could we keep=C2=A0
the abbreviation (rif= t) but change the name to Routing in Fat Tree and=C2=A0
Clos".<= span class=3D"Apple-converted-space">=C2=A0
<= /font>

I = don=E2=80=99t think that=E2=80=99s necessary as long as the charter is spec= ific about what the WG will be doing.=C2=A0 IOW, I think the name is not as= important as the charter.

Do we need to update the charter to make sure your point is captur= ed?

Thanks!=

Alvaro.
--001a113e4d2a17b01c05630d97eb-- From nobody Thu Jan 18 06:23:15 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62CA12700F for ; Thu, 18 Jan 2018 06:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.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 0NGM2sbifnBb for ; Thu, 18 Jan 2018 06:23:11 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 3D9011205D3 for ; Thu, 18 Jan 2018 06:23:11 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0IEM0rZ004534; Thu, 18 Jan 2018 06:23:08 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=hUN1SXHEWDZwe/hs9VmGEB4oGxZzbrnpC/IXBw7MH1s=; b=up49p4IdqKztBTxcAsiiy5LawLCaGl6vPH4DJRDyBFdJ+VsJljHu591OT6TNJG1Qi77G 8P00MA9d1/Om/cPKc3p+LXoB7JY91CF/1LmhzsSo5M1s3F17CvIrN1dC11iVJtr/KBe8 lAc+sQ8eq0UVKn7I3mh8uRZVwD6/6SkLFBnWwCLRlrbX0dE8HITZ85ERv+yoF0ggi0T+ qeLAF/0/VSf2DeHL6f70ACH0o1cZWQamjRs5Q0kVcN3f7RM7ZuzsPuejAVc+Sb/+Hekx PqIsB3+/SI61utg5w+qUSrj/sFv7olI6e6nXjmi1j1UsdQB7P/QWPra931i1/h+tXl/K 4Q== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0183.outbound.protection.outlook.com [216.32.181.183]) by mx0a-00273201.pphosted.com with ESMTP id 2fjw99802t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Jan 2018 06:23:07 -0800 Received: from CY1PR0501MB1340.namprd05.prod.outlook.com (10.160.226.145) by CY1PR0501MB2059.namprd05.prod.outlook.com (10.164.3.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Thu, 18 Jan 2018 14:23:06 +0000 Received: from CY1PR0501MB1340.namprd05.prod.outlook.com ([10.160.226.145]) by CY1PR0501MB1340.namprd05.prod.outlook.com ([10.160.226.145]) with mapi id 15.20.0428.014; Thu, 18 Jan 2018 14:23:05 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Alvaro Retana , Loa Andersson , "rift@ietf.org" Thread-Topic: [Rift] Internal Review of the rift Charter Thread-Index: AQHTj+2f2u7Oze5tMU6oEwCD4tM+4qN5Th6AgABffYCAAAHXwA== Date: Thu, 18 Jan 2018 14:23:05 +0000 Message-ID: References: <29fe7962-cfbb-6ce3-b4aa-b31a75f6c03b@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.76.172.253] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0501MB2059; 7:g6xyhB7/CSMwlmwOdzXOr7o9mLeawFFzYNcdUS0HDqMW5VyFL20hiqx+fST08YgJEHTiNWWJmFDSasC/NeP81MicvrqGJ9XiwY1gjl5QbOXfKsDcw1QPqaOEKkmfbXU8R9Ptsg2muUr8MzOg3gvGLY1dSOhlFAB6EkwwXJyKK8O0qm7Aw7nEcVTk6+kVsleDmPiWhRg5mYjYN8LaDeGIDaUr0gzmwbUbe8cd881zRc5sVQpNa7W+qEOUerSl4Tpt x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 10f68c3f-bcd5-4619-9626-08d55e7efdce x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060)(7193020); SRVR:CY1PR0501MB2059; x-ms-traffictypediagnostic: CY1PR0501MB2059: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231023)(944501161)(6055026)(6041268)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY1PR0501MB2059; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY1PR0501MB2059; x-forefront-prvs: 05568D1FF7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(39860400002)(346002)(39380400002)(57704003)(199004)(189003)(2900100001)(8676002)(97736004)(9686003)(74316002)(2950100002)(54896002)(6306002)(55016002)(5660300001)(316002)(110136005)(2501003)(8936002)(66066001)(7736002)(81166006)(81156014)(99286004)(3660700001)(14454004)(102836004)(33656002)(478600001)(3846002)(6116002)(790700001)(6436002)(39060400002)(2906002)(86362001)(68736007)(6246003)(3280700002)(77096007)(26005)(53946003)(106356001)(236005)(6506007)(53936002)(53546011)(229853002)(7696005)(105586002)(76176011)(25786009)(59450400001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2059; H:CY1PR0501MB1340.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: eig5uS3Txh2z9Q9rgvkvpuiEkU1EzlHRZzkm7N7M8GiL9TDh8l7Aq43VoNFDFTc0oYnMwc4NxiXod9kZUanlEA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB1340C57DA7AF622C3C29D00DD4E80CY1PR0501MB1340_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 10f68c3f-bcd5-4619-9626-08d55e7efdce X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2018 14:23:05.9232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2059 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801180194 Archived-At: Subject: Re: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 14:23:14 -0000 --_000_CY1PR0501MB1340C57DA7AF622C3C29D00DD4E80CY1PR0501MB1340_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByb3Bvc2VkIGNoYXJ0ZXIgZG9lcyBzcGVjaWZpY2FsbHkgY292ZXIgYm90aCBDTE9TIGFu ZCBGYXQtdHJlZSB0b3BvbG9naWVzOg0KDQo+IFRoZSBSSUZUIFdvcmtpbmcgR3JvdXAgd2lsbCB3 b3JrIG9uIGEgc3RhbmRhcmRzIHRyYWNrIHNwZWNpZmljYXRpb24gb2YgYSBzcGVjaWFsaXplZCwg ZHluYW1pYyByb3V0aW5nIHByb3RvY29sIGZvciBDbG9zIGFuZCBmYXQtdHJlZSBuZXR3b3JrIHRv cG9sb2dpZXMg4oCmDQoNCkplZmZyZXkNCg0KRnJvbTogUmlmdCBbbWFpbHRvOnJpZnQtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsdmFybyBSZXRhbmENClNlbnQ6IFRodXJzZGF5LCBK YW51YXJ5IDE4LCAyMDE4IDk6MTUgQU0NClRvOiBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+OyBy aWZ0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1JpZnRdIEludGVybmFsIFJldmlldyBvZiB0aGUg cmlmdCBDaGFydGVyDQoNCk9uIEphbnVhcnkgMTgsIDIwMTggYXQgMzozMzoyNSBBTSwgTG9hIEFu ZGVyc3NvbiAobG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+KSB3cm90ZToNCg0KTG9hOg0KDQpI aSENCg0KVG8gbXkgdW5kZXJzdGFuZGluZyAiZmF0IHRyZWUiIGFuZCAiY2xvcyIgYXJlIG5vdCAo ZXhhY3RseSkgdGhlIHNhbWUNCnRoaW5nLCBpZiB3ZSBuYW1lIHRoZSB3b3JraW5nIGdyb3VwICJS b3V0aW5nIEluIEZhdCBUcmVlcyIsIHRoZXJlIGlzIGENCnJpc2sgKHZlcnkgc21hbGwpIHRoYXQg d2UgbGVhdmUgIkNsb3MiIGF0IHRoZSByb2FkIHNpZGUuIENvdWxkIHdlIGtlZXANCnRoZSBhYmJy ZXZpYXRpb24gKHJpZnQpIGJ1dCBjaGFuZ2UgdGhlIG5hbWUgdG8gUm91dGluZyBpbiBGYXQgVHJl ZSBhbmQNCkNsb3MiLg0KDQpJIGRvbuKAmXQgdGhpbmsgdGhhdOKAmXMgbmVjZXNzYXJ5IGFzIGxv bmcgYXMgdGhlIGNoYXJ0ZXIgaXMgc3BlY2lmaWMgYWJvdXQgd2hhdCB0aGUgV0cgd2lsbCBiZSBk b2luZy4gIElPVywgSSB0aGluayB0aGUgbmFtZSBpcyBub3QgYXMgaW1wb3J0YW50IGFzIHRoZSBj aGFydGVyLg0KDQpEbyB3ZSBuZWVkIHRvIHVwZGF0ZSB0aGUgY2hhcnRlciB0byBtYWtlIHN1cmUg eW91ciBwb2ludCBpcyBjYXB0dXJlZD8NCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQo= --_000_CY1PR0501MB1340C57DA7AF622C3C29D00DD4E80CY1PR0501MB1340_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDM5MDNELkYxMTM4NzMwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6Wm9vbT4xMjA8L3c6Wm9vbT4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xl YW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5n Lz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2 ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRD b250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhv bGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJv bW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3Okxp ZFRoZW1lQXNpYW4+WkgtQ048L3c6TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNj cmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4N Cjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3 OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQo8 L3c6Q29tcGF0aWJpbGl0eT4NCjxtOm1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlh IE1hdGgiLz4NCjxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9 IiYjNDU7LSIvPg0KPG06c21hbGxGcmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06 bE1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2 YWw9ImNlbnRlckdyb3VwIi8+DQo8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRM aW0gbTp2YWw9InN1YlN1cCIvPg0KPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0 aFByPjwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgRGVmU2VtaUhpZGRlbj0iZmFsc2UiIERlZlFGb3JtYXQ9ImZhbHNl IiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjM3MSI+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1h bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFG b3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcg OCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVh ZGluZyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iaW5kZXggMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9ImluZGV4IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggNSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4 IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggOCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJpbmRleCA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2Mg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJ0b2MgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InRvYyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCBJbmRlbnQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iZm9vdG5vdGUgdGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0 aW9uIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaGVhZGVyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9ImZvb3RlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCBoZWFkaW5nIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM1IiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0YWJsZSBvZiBmaWd1cmVzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9ImVudmVsb3BlIGFkZHJlc3MiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW52ZWxvcGUg cmV0dXJuIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3Rub3RlIHJlZmVyZW5jZSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJsaW5lIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJwYWdlIG51bWJlciIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJlbmRub3RlIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idGFibGUgb2YgYXV0aG9y aXRpZXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0ibWFjcm8iLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0idG9hIGhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJl ciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i TGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJMaXN0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxp c3QgQnVsbGV0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxp c3QgTnVtYmVyIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJDbG9zaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNpZ25hdHVy ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGgg Rm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iQm9keSBUZXh0IEluZGVudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRp bnVlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBD b250aW51ZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJNZXNzYWdlIEhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iU2FsdXRhdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJE YXRlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEZpcnN0IEluZGVudCAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ik5vdGUgSGVhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJCb2R5IFRleHQgSW5kZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0 IEluZGVudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJsb2NrIFRleHQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkZvbGxvd2VkSHlw ZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIyIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IkRvY3VtZW50IE1hcCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJQbGFp biBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkUtbWFpbCBTaWduYXR1cmUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iSFRNTCBUb3Agb2YgRm9ybSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJI VE1MIEJvdHRvbSBvZiBGb3JtIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCAoV2ViKSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEFjcm9ueW0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iSFRNTCBBZGRyZXNzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQ2l0ZSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJIVE1MIENvZGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBE ZWZpbml0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgS2V5Ym9hcmQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iSFRNTCBQcmVmb3JtYXR0ZWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i SFRNTCBTYW1wbGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBUeXBld3JpdGVyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IkhUTUwgVmFyaWFibGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i Tm9ybWFsIFRhYmxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImFubm90YXRpb24gc3ViamVjdCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJObyBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91 dGxpbmUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIFNpbXBsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIENsYXNzaWMgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2lj IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBD b2xvcmZ1bCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSBDb2x1bW5zIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBDb2x1bW5zIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29s dW1ucyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3Jp ZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBHcmlkIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBHcmlkIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSBMaXN0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBMaXN0IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA3Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJs ZSAzRCBlZmZlY3RzIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJUYWJsZSBDb250ZW1wb3JhcnkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi bGUgRWxlZ2FudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBQcm9mZXNzaW9uYWwiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iVGFibGUgU3VidGxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgV2ViIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmFsbG9vbiBUZXh0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJUYWJsZSBHcmlk Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFRoZW1lIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJObyBTcGFjaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0g U2hhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0 IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3Jp ZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1l PSJNZWRpdW0gR3JpZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVs IExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5h bWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9Ikxp Z2h0IEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUi IE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlz dCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3Rl Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJN ZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBO YW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRp bmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0 IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYi IE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBH cmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3Jm dWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFt ZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFt ZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVt IExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0i TWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1l PSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBH cmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBH cmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1l PSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAx IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4 IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExp c3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNv bG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9 IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1 bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9 IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIg TmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlz dCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFt ZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQg MyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUg RW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEi IFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRs ZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzIiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJC b29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3 IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmlibGlvZ3Jh cGh5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i VE9DIEhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDEiIE5hbWU9IlBsYWluIFRhYmxlIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDIiIE5hbWU9IlBsYWluIFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDMiIE5hbWU9IlBsYWluIFRhYmxlIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDQiIE5hbWU9IlBsYWluIFRhYmxl IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDUiIE5hbWU9 IlBsYWluIFRhYmxlIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDAiIE5hbWU9IkdyaWQgVGFibGUgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJH cmlkIFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDkiIE5hbWU9IkdyaWQgVGFibGUgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1 bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0i R3JpZCBUYWJsZSA3IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUg MiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFi bGUgNSBEYXJrIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUg NyBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgi IE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxl IDUgRGFyayBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcg Q29sb3JmdWwgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBO YW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1 IERhcmsgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENv bG9yZnVsIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFt ZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBE YXJrIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xv cmZ1bCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9 IkdyaWQgVGFibGUgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFy ayBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1 MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3Jm dWwgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJH cmlkIFRhYmxlIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsg QWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEi IE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVs IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2 IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxl IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9 Ikxpc3QgVGFibGUgNSBEYXJrIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1 bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0i TGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUg MyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlz dCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxp c3QgVGFibGUgMSBMaWdodCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDki IE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3Qg VGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0 IFRhYmxlIDEgTGlnaHQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBO YW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRh YmxlIDYgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBU YWJsZSAxIExpZ2h0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFt ZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJs ZSA2IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFi bGUgMSBMaWdodCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9 Ikxpc3QgVGFibGUgNCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUg NiBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxl IDEgTGlnaHQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJM aXN0IFRhYmxlIDQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYg Q29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPC93Okxh dGVudFN0eWxlcz4NCjwveG1sPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmlu aXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2Ut MToyIDExIDYgNCAyIDIgMiAyIDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVy aWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZv bnQtc2lnbmF0dXJlOjMgMCAwIDAgMSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNh bWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsNCgltc28tZm9udC1h bHQ6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWZvbnQtY2hhcnNldDoxOw0KCW1zby1nZW5lcmlj LWZvbnQtZmFtaWx5OnJvbWFuOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250 LXNpZ25hdHVyZTotNTM2ODcwMTQ1IDExMDczMDU3MjcgMCAwIDQxNSAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTsN Cgltc28tZm9udC1hbHQ6fD8/wqjCrD8/P8Khwqc/Pz/CocKnPz8/Ow0KCW1zby1mb250LWNoYXJz ZXQ6MTM0Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5Om1vZGVybjsNCgltc28tZm9udC1waXRj aDpmaXhlZDsNCgltc28tZm9udC1zaWduYXR1cmU6MSAxMzUxMzUyMzIgMTYgMCAyNjIxNDQgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtYWx0OiJDZW50dXJ5IEdvdGhpYyI7DQoJbXNvLWZvbnQt Y2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBp dGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODU5OTA1IC0xMDczNzMyNDg1 IDkgMCA1MTEgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWFsdDoiXEBEZW5nWGlhbiI7 DQoJbXNvLWZvbnQtY2hhcnNldDoxMzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6bW9kZXJu Ow0KCW1zby1mb250LXBpdGNoOmZpeGVkOw0KCW1zby1mb250LXNpZ25hdHVyZToxIDEzNTEzNTIz MiAxNiAwIDI2MjE0NCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNv LXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6RGVuZ1hpYW47fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJs aW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkRlbmdYaWFuO30NCnNwYW4uYXBwbGUtY29udmVydGVk LXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTsNCgltc28tc3R5 bGUtdW5oaWRlOm5vO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS11bmhpZGU6bm87 DQoJbXNvLWFuc2ktZm9udC1zaXplOjExLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCW1zby1o YW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCglt c28tZm9vdGVyLW1hcmdpbjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxl DQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1z aXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93Onll czsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28t cGFkZGluZy1hbHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0K CW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1v cnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRhYi1pbnRlcnZhbDouNWluIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRoZSBwcm9wb3NlZCBjaGFydGVyIGRvZXMgc3BlY2lmaWNhbGx5IGNvdmVyIGJvdGgg Q0xPUyBhbmQgRmF0LXRyZWUgdG9wb2xvZ2llczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgVGhlIFJJRlQgV29ya2luZyBH cm91cCB3aWxsIHdvcmsgb24gYSBzdGFuZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbiBvZiBhIHNw ZWNpYWxpemVkLCBkeW5hbWljIHJvdXRpbmcgcHJvdG9jb2wgZm9yIENsb3MgYW5kIGZhdC10cmVl IG5ldHdvcmsgdG9wb2xvZ2llcyDigKY8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3Rlcjps aW5lLWJyZWFrIj4NCjwhW2lmICFzdXBwb3J0TGluZUJyZWFrTmV3TGluZV0+PGJyIHN0eWxlPSJt c28tc3BlY2lhbC1jaGFyYWN0ZXI6bGluZS1icmVhayI+DQo8IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkplZmZyZXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4gUmlmdA0KIFtt YWlsdG86cmlmdC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkFsdmFybyBS ZXRhbmE8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMTgsIDIwMTggOToxNSBB TTxicj4NCjxiPlRvOjwvYj4gTG9hIEFuZGVyc3NvbiAmbHQ7bG9hQHBpLm51Jmd0OzsgcmlmdEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1JpZnRdIEludGVybmFsIFJldmlldyBv ZiB0aGUgcmlmdCBDaGFydGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxv b3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtt c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6 YmxhY2siPk9uIEphbnVhcnkgMTgsIDIwMTggYXQgMzozMzoyNSBBTSwgTG9hIEFuZGVyc3NvbiAo PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSI+bG9hQHBpLm51PC9hPikgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjpibGFjayI+TG9hOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6YmxhY2siPkhpITxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPlRvIG15IHVuZGVyc3RhbmRpbmcgJnF1 b3Q7ZmF0IHRyZWUmcXVvdDsgYW5kICZxdW90O2Nsb3MmcXVvdDsgYXJlIG5vdCAoZXhhY3RseSkg dGhlIHNhbWU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPnRoaW5nLCBpZiB3ZSBuYW1lIHRoZSB3b3JraW5nIGdyb3VwICZxdW90O1Jv dXRpbmcgSW4gRmF0IFRyZWVzJnF1b3Q7LCB0aGVyZSBpcyBhPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+cmlzayAodmVyeSBzbWFsbCkgdGhhdCB3ZSBsZWF2ZSAmcXVvdDtDbG9z JnF1b3Q7IGF0IHRoZSByb2FkIHNpZGUuIENvdWxkIHdlIGtlZXA8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj50aGUgYWJicmV2aWF0aW9uIChyaWZ0KSBidXQgY2hhbmdlIHRoZSBu YW1lIHRvIFJvdXRpbmcgaW4gRmF0IFRyZWUgYW5kPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+Q2xvcyZxdW90Oy48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBpZD0iYmxvb3Bfc2lnbl8xNTE2Mjg0 ODIxNzA5MjkzODI0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO21z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9zaWduXzE1MTYy ODQ4MjE3MDkyOTM4MjQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5JIGRv buKAmXQgdGhpbmsgdGhhdOKAmXMgbmVjZXNzYXJ5IGFzIGxvbmcgYXMgdGhlIGNoYXJ0ZXIgaXMg c3BlY2lmaWMgYWJvdXQgd2hhdCB0aGUgV0cgd2lsbCBiZSBkb2luZy4mbmJzcDsgSU9XLCBJIHRo aW5rIHRoZSBuYW1lIGlzIG5vdA0KIGFzIGltcG9ydGFudCBhcyB0aGUgY2hhcnRlci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUxNjI4NDgyMTcw OTI5MzgyNCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjttc28tZmFy ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3Bfc2lnbl8xNTE2Mjg0ODIx NzA5MjkzODI0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+RG8gd2UgbmVl ZCB0byB1cGRhdGUgdGhlIGNoYXJ0ZXIgdG8gbWFrZSBzdXJlIHlvdXIgcG9pbnQgaXMgY2FwdHVy ZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9zaWduXzE1 MTYyODQ4MjE3MDkyOTM4MjQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX3NpZ25f MTUxNjI4NDgyMTcwOTI5MzgyNCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX3Np Z25fMTUxNjI4NDgyMTcwOTI5MzgyNCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3Bf c2lnbl8xNTE2Mjg0ODIxNzA5MjkzODI0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+QWx2YXJvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR0501MB1340C57DA7AF622C3C29D00DD4E80CY1PR0501MB1340_-- From nobody Thu Jan 18 13:09:22 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D0A12D7E3 for ; Thu, 18 Jan 2018 13:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gxVI8sQ0TwpC for ; Thu, 18 Jan 2018 13:09:20 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 625F0127275 for ; Thu, 18 Jan 2018 13:09:20 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id v71so25728059wmv.2 for ; Thu, 18 Jan 2018 13:09:20 -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=abseEv5CMJPv2qgXSMyA0dK9H3zBP6wlrgBT1XZqneE=; b=XRzbEsKNBTbuY4lXwQ7rzMAjwdSv/S2cn8s4cUt6zcNj2CaX0luqAVYTQ04MdtwMjX M9kqzG4igYI+brXZanbeAswrRCBIBK0kySQip+ETNJxTtTXJ5FLUodP2mvA1mRRb2ZWF 0CmfJVMqR2xIPm6rb2UYK9x6ENtETYwEhBDiTmej9GtiGBZHjIvgz5eq7IjrDGTwrrNT xI6iJgMx0vBSKWIJmPlijnbTC8dyfKvnAUJXe8yUF+pAhfMEmwOVLVNwZR+jvkjTDSoD 8+2Loo3XbpQIUqYaCk1UAe5ejIG7H7Peh1QZG3orKzToYGTKZr7T353dMTVe+ZfypIRa SpEA== 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=abseEv5CMJPv2qgXSMyA0dK9H3zBP6wlrgBT1XZqneE=; b=KxgXa7mGkKmENFRQ61gCfQB5C1t4sC5m+l3qdefqg4pImuwPcOz66sIFr4XrPQmYIo R3gaDb0vRdW+Kvc8B7u0Yajl5n/K1eOJvQEymqKr6Frv8UNH1SxCAzJvCWXPngDT+2Xh /omdI3IpD2KxlxFimnofbTCyP+4x6gjsuPYRTfzuB/ryqYbKxbCF8zkkBU/0eARkd8/Q 9hhPCjtLu6W9M9z7FLqUqT+wqGhTN6PeJCFbgPu6Gz1dQ9lfQlWhuUq9qonhgIpXHtTE tCKgkCZDgGQKLQHiSfSWokCy9RI/nvM6bFCg87vBl0RszRcnk2CFvEKVkaTOXY1Dy9Hc elWA== X-Gm-Message-State: AKwxytc0iimNPSnGXF0JMYJjggdgSlM1/TKM9AY+XcVwEbgh3xjWFWzE HtRvdyLpATmr5BlKxUA24Yajs9RCAexOObrR4V4Dzwab X-Google-Smtp-Source: ACJfBosQVBx39gi53ufkgmJkl7vQPdYcyaTcST90YFJ+BrgPoKX5Umcbhv4JcfRofLXnLKLbCr4hGc/iv66tyOGaiVw= X-Received: by 10.80.132.170 with SMTP id 39mr9426429edq.231.1516309758640; Thu, 18 Jan 2018 13:09:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.178.225 with HTTP; Thu, 18 Jan 2018 13:09:18 -0800 (PST) From: A S Date: Thu, 18 Jan 2018 16:09:18 -0500 Message-ID: To: rift@ietf.org Content-Type: multipart/alternative; boundary="f403045c91d48886bf0563136053" Archived-At: Subject: Re: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 21:09:21 -0000 --f403045c91d48886bf0563136053 Content-Type: text/plain; charset="UTF-8" Thanks Tony for answering and justifying the previous comments. While there would be need for enhancements and changes as it evolves but that is purpose of this group. L/S architectures being widely deployed, there is value in building something optimized for it and taking advantage of regularity in the topology. Charter seems to capture everything reasonable I can think of. Comments on calling fat tree or clos, those are very specific topologies, RIFT covers most of leaf-spine variants. Thanks, Alankar Comcast --f403045c91d48886bf0563136053 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Tony for answering and justifying th= e previous comments. While there would be need for enhancements and changes= as it evolves but that is purpose of this group.
L/S architectures bein= g widely deployed, there is value in building something optimized for it an= d taking advantage of regularity in the topology.

Charter see= ms to capture everything reasonable I can think of.
Comments on calling = fat tree or clos, those are very specific topologies, RIFT covers most of l= eaf-spine variants.

Thanks,
Alankar
Comcast<= br>
--f403045c91d48886bf0563136053-- From nobody Thu Jan 18 14:09:02 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE2612D7F0 for ; Thu, 18 Jan 2018 14:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ckDYGhQOTn-N for ; Thu, 18 Jan 2018 14:08:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 427E212D7F7 for ; Thu, 18 Jan 2018 14:08:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ecIMi-0002V8-Cm; Thu, 18 Jan 2018 22:08:56 +0000 Date: Thu, 18 Jan 2018 14:08:55 -0800 Message-ID: From: Randy Bush To: Loa Andersson Cc: Alvaro Retana , rift@ietf.org In-Reply-To: <29fe7962-cfbb-6ce3-b4aa-b31a75f6c03b@pi.nu> References: <29fe7962-cfbb-6ce3-b4aa-b31a75f6c03b@pi.nu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 22:09:00 -0000 Clos and Routing Under Fat Trees From nobody Thu Jan 18 14:24:23 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843F812025C for ; Thu, 18 Jan 2018 14:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 TDZXD6hJaa-V for ; Thu, 18 Jan 2018 14:24:20 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7767E126C19 for ; Thu, 18 Jan 2018 14:24:20 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id t79so13281765lfe.3 for ; Thu, 18 Jan 2018 14:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3mm/ky/gLpg7PwfEcbEOo+gGjM56P6ix/ACFXKHpsaM=; b=Xd7BYXTeTrgUQtFI2xnGE7J/LCdd7tTNBJr1Z/1WvtItDcyI1wiOeMWzAv0HW/lMZZ adSzrl9C8m7n7Jsyz2+4m15kpLTepE9JWBVYv6nS5fa1AXpUcdvT2gn/P8J9Kk3eZU62 8Kzyq4AONCvFO/XFoMXhAkj4THkJ4rMppfrGRk1LJdex+1BrpeacSaG7R3XebLSSeEz6 ZhO1aaHg829kpKWca8w8ik7CtHv7aUEzYAiyZWxsOXbV4QH/jS2hlGnEXkRqRbCvMp2R HXRco9NAwsSAbp+M6fQExIBrnikZqL6gewE9PHhUUxC0pmgkvsNfqGXBuAAk6AkBxqmq RSvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3mm/ky/gLpg7PwfEcbEOo+gGjM56P6ix/ACFXKHpsaM=; b=jabyWtnBGnLtfB20NYtKMP/+stjyig3/eVpxEQhbwLOIbkmQ886TWGf3DAj+rIy+Wm 3VdKee1sSl57t7m8OTtVXgP1qH//gtuBqwOM0pZFH/+1xg1YMUm8tvkFjxy1hburapa7 AaW8h3AFKfNiFeOEkXQxbcZcUbxGrJreBpR8jjBCdI0cV3ndP9v4nFbT4beAOpmjx/f0 4POSNaxgWFPjDMN7zoQcURmeIHhSRMmX5d/SjM4z2RGAx6fBQzfla2ESxjvaLn7sZj6q SLLlanMsaH0kTDBuZ+Zi6uvYmn5zxwISvF8Xe/lLe+mrrkIzAcVS03yeCN4dic6FmabJ eq7g== X-Gm-Message-State: AKwxyte9N4Lz2a32eBczbQaahoeAqdNgYn/0TqF6WaWOT2SPPG3NzNcs J52at9OGJgPFuFBsq7R2I/DVJC2Ez171ELhV9cQ= X-Google-Smtp-Source: ACJfBot5KK5he9xbkVI06L6qionHoRHJofyggD7Ql7tvQUWszc+vJwNuO05eskdUyef1maO50VEEICBlIcpFDrRZx80= X-Received: by 10.25.40.130 with SMTP id o124mr13109741lfo.3.1516314258556; Thu, 18 Jan 2018 14:24:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.32.234 with HTTP; Thu, 18 Jan 2018 14:24:17 -0800 (PST) In-Reply-To: References: <29fe7962-cfbb-6ce3-b4aa-b31a75f6c03b@pi.nu> From: Greg Mirsky Date: Thu, 18 Jan 2018 14:24:17 -0800 Message-ID: To: Randy Bush Cc: Loa Andersson , rift@ietf.org, Alvaro Retana Content-Type: multipart/alternative; boundary="001a114082d2bfccd90563146c84" Archived-At: Subject: Re: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 22:24:22 -0000 --001a114082d2bfccd90563146c84 Content-Type: text/plain; charset="UTF-8" RIFT -> LIFT (Lost in Fat Trees) On Thu, Jan 18, 2018 at 2:08 PM, Randy Bush wrote: > Clos and Routing Under Fat Trees > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift > --001a114082d2bfccd90563146c84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
RIFT -> LIFT (Lost in Fat Trees)
 --001a114082d2bfccd90563146c84-- From nobody Thu Jan 18 14:25:50 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FB0126CBF for ; Thu, 18 Jan 2018 14:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EN47KAS5m62W for ; Thu, 18 Jan 2018 14:25:47 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C68112025C for ; Thu, 18 Jan 2018 14:25:47 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id w50so24165598wrc.11 for ; Thu, 18 Jan 2018 14:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nQlvP2gMdu/BlPzoI8o7BSqepEWeznoTEbCU/XTS0Ac=; b=iaJAcixMgeXkLUoaKZ1oTjQGAOlRPpW9GOhw2t/ICnW3YXzNBRaNUsxoRK6P3LuCad H+YpO4a3MhjDIRuatI8lblnBoPo4PQeCjHBLdgolKx5P54CrJh+LSwlKSUOCmrTXxcbh jBPF2sf5D22EDVbu6OUDV7FWyq7js8r/S4AXzFRrC1elHIrton76m89NUVHJEa/bvj2L CZdCnYmvd47UtFkSg6veSwOTNWyx8Be3Yk+SBKE09c8IzpHXCHMifW5XDiJ/yydoRvft Y/TpinbVd/eRs6P7tHd0Urknio+Pk4AhAG8EYFRpou+d//nvpi+mRSu4rbaIJf1DgAop RnDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nQlvP2gMdu/BlPzoI8o7BSqepEWeznoTEbCU/XTS0Ac=; b=cShGRSlzkGWPwtCaj9Wa69tZxutMdmTjjlZm0lEp0ngWKDJSZ6fC7BNXjg9hYfSk/v 0JjIaOc5qHlF0+I3TjtJ0UrVRMUlX+TicnfLTxO9SIXcNC+PlDVzNTB9lLiYKv9FtNki r9Bzb4M4EaL6ynD2i1w1fArp0pv8ehY7vXGRTQF6kmIOgJthjEbviG3QyCR6mCkN2aVp ZRcn482t/hmFofvC5ATwej/rg45+fWmgKiZW60Y+iEN7z0KgnxkdBLzFgylVIFSY3aEK EboVX4VITzhTvoPRtYrM3RVyWYV1FBy2sXetaWesYMWWOt2QU0sICiqxQyzqqiKLYBsA GyMg== X-Gm-Message-State: AKwxytdDidG/08/dR9JvVtnX6WpWBmlXp1Wkl0Xqk2NR0BSy3SyxVWAU 3bXUFa8kUMKq8ew0Gb7B77Y= X-Google-Smtp-Source: ACJfBosd1FFXvTnH9lkhLSGGHbWgKCCvumB7f/S72sivFv+FBI1L2WPTzPirOYGmZkiyid5KaAHacg== X-Received: by 10.223.135.115 with SMTP id 48mr7472488wrz.122.1516314345633; Thu, 18 Jan 2018 14:25:45 -0800 (PST) Received: from 194.66.20.149.in-addr.arpa (194.66.20.149.in-addr.arpa. [149.20.66.194]) by smtp.gmail.com with ESMTPSA id l142sm10379693wmb.43.2018.01.18.14.25.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jan 2018 14:25:44 -0800 (PST) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8B4236E2-90A2-4B49-94DD-11F0CEE076DD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 18 Jan 2018 14:25:41 -0800 In-Reply-To: Cc: Loa Andersson , rift@ietf.org, Alvaro Retana To: Randy Bush References: <29fe7962-cfbb-6ce3-b4aa-b31a75f6c03b@pi.nu> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 22:25:49 -0000 --Apple-Mail=_8B4236E2-90A2-4B49-94DD-11F0CEE076DD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Jan 18, 2018, at 2:08 PM, Randy Bush wrote: > > Clos and Routing Under Fat Trees CRUFT? > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift --Apple-Mail=_8B4236E2-90A2-4B49-94DD-11F0CEE076DD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlphHuUACgkQEhdRnd2G P+CKpw//ZJHrQB/HiZWm/RE7MJWm5qcIgpKQ8HJlwq+YqDwOMIzzX4Vp6xAmEwUm gcmPOkP02JMZddKq3e30f3Hui4IcL1I3/zrhkH/VwFYmdBWasaYWcEbqAz77scyz zt6AGqc1N79Jhvz8u9PHP/aycB/eyxPMbKHbBa1qUtA+chOnGG1/vjdzI9p8e6Yr u8lxPxEN45YWDD89svc0YCrqXbb9JzoNPxCIW75tEQ4dQXPZmqXK2iKC3X2lzODz aa8DYqOTw3iTXV4kt2BlPKTKSBJQl0B7NA45gT/CMyQo1m82KDE4gfASBK7dbUTP DjT8TgIMgwn9B4bz/dkvs9jm7xC0eEVT6gSihXvlW1adN86FE50kuZEaqcmEvntK UKtpwDsP7eV5BwHnkqCpFYYohhSNI9JjHAp+NQfEl/QmJV0s2RqHaFWvK4FEChcb 8AE95nGOrvGOif7FAw65Qu8yoezG1LxRRDnoQ3bL6OLoQYTjrPx4fyjpy0ARak0e ezrdxX92wnLg2TEiuZEecViesHj20OhAFvDcxvMB2Sq3DE4k8yJUmFmEHr0QESTK fiapccyNwymbovL3zT2ROXC+/wjCJdnEGAlKjIIPeuXfojassGZ5/XGq585UEVXm M7+faCtIOPlBlB86ISGEGFzVDK7fysqNuUVvS/WIWL0rX5grYWY= =eC+g -----END PGP SIGNATURE----- --Apple-Mail=_8B4236E2-90A2-4B49-94DD-11F0CEE076DD-- From nobody Thu Jan 18 17:45:08 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441A4129BBF for ; Thu, 18 Jan 2018 17:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 p0dQcEMQoIYR for ; Thu, 18 Jan 2018 17:45:04 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDD5126CBF for ; Thu, 18 Jan 2018 17:45:04 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id v71so532359wmv.2 for ; Thu, 18 Jan 2018 17:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=+nMEr9gB4xDqTvO+kHrw4vJWgFkvotqTnmlxzlMCaxo=; b=Tr6u6s+g8ZLKeAuEbNJTAUhDZNGBVFxQ2pv/6xd7UqCwt8dK5JlvB3x53lqxpAagx5 yr+2VlexN/FNkd/fNOTk7SAG/oLlIOTWuSz1AH/IkvlNw/sQ6uGckQXJvK8KwAQkG/wM xg9eOTNJANP+9TAjzmmsx0vvDe48Nxx2/PckWDdQZ+f/BtLUty3LORA/GmjRroia8DKw /70fhQ97AtR7oeUTMYS2dZfwfpycw21DXNWW8WnAP+aO0RMNc/yUNMLILOJLGA+f7QDp /4UhKe0OL8OoC30yqqEx89H8CjsCdAEedk0FDd4zEM8BAh4+2lI/MGLNmKq9+myKz7bW ixBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=+nMEr9gB4xDqTvO+kHrw4vJWgFkvotqTnmlxzlMCaxo=; b=NJWH2HkeuZDKYrlslNUZs6W46749/fbyHdwJSVq/D/3wH23CeXFAkgJcgF7bkOd+TR fGfpC53vK5q/7gdaF5P6o0T5hrEnt+XAX6IWTFu9ztZu3c/bgPB9tveXPh5X6CLdWiUc T2lZSlG1+KpbA4paFz5Usr3aCm3eBwioLJoKr3T1ryIqpBr7OL2puCxhBOH2HtQAKlmU Qqy3ODCOPjaqlTmJXGDs75HrklrA0n9CbUOyh1LStKRm2+JyhZBcHRBqgaBiXHxtQeM0 SM5Ic+RFu3UZ0b1M9tkbNdv/1InzKIBOkX9o9gH7T2oR08gn235miia6q8bAUcma1J7f GGBw== X-Gm-Message-State: AKwxytc6b0BwLj6Es8PnO6zzXI97TWXI03Q8ZZVbehSSNn1PuiursjLd mPTztqSj9aFpgGlvsWnlQjNT0ScTkBJQpEhZGbcDjg== X-Google-Smtp-Source: ACJfBou4NwfVyqHoEsoS4q1mDXLHTkhqrL+XqGWBOEca5zvCZGA0JNU4rB/qJJcoqCi4K6owwuctPmLznI0qUD/XOQI= X-Received: by 10.80.165.97 with SMTP id z30mr10643835edb.66.1516326302928; Thu, 18 Jan 2018 17:45:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.178.225 with HTTP; Thu, 18 Jan 2018 17:45:02 -0800 (PST) In-Reply-To: References: From: A S Date: Thu, 18 Jan 2018 20:45:02 -0500 Message-ID: To: rift@ietf.org Content-Type: multipart/alternative; boundary="f403045c11cea654460563173a03" Archived-At: Subject: Re: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 01:45:06 -0000 --f403045c11cea654460563173a03 Content-Type: text/plain; charset="UTF-8" Got a unicast that Tony here is multicast address. To clarify, I meant Tony P. On Thu, Jan 18, 2018 at 4:09 PM, A S wrote: > Thanks Tony for answering and justifying the previous comments. While > there would be need for enhancements and changes as it evolves but that is > purpose of this group. > L/S architectures being widely deployed, there is value in building > something optimized for it and taking advantage of regularity in the > topology. > > Charter seems to capture everything reasonable I can think of. > Comments on calling fat tree or clos, those are very specific topologies, > RIFT covers most of leaf-spine variants. > > Thanks, > Alankar > Comcast > --f403045c11cea654460563173a03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got a unicast that Tony here is multicast address. To clar= ify, I meant Tony P.

On Thu, Jan 18, 2018 at 4:09 PM, A S <= ;as3957@gmail.com= > wrote:
=
Thanks Tony for answering and justifying the previous comments. W= hile there would be need for enhancements and changes as it evolves but tha= t is purpose of this group.
L/S architectures being widely deployed, the= re is value in building something optimized for it and taking advantage of = regularity in the topology.

Charter seems to capture everythi= ng reasonable I can think of.
Comments on calling fat tree or clos, thos= e are very specific topologies, RIFT covers most of leaf-spine variants.
Thanks,
Alankar
Comcast

--f403045c11cea654460563173a03-- From nobody Thu Jan 18 18:31:00 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3F712711D for ; Thu, 18 Jan 2018 18:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 aprFhhOdigk1 for ; Thu, 18 Jan 2018 18:30:56 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81251126E01 for ; Thu, 18 Jan 2018 18:30:56 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id g1so617958wmg.2 for ; Thu, 18 Jan 2018 18:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uE8AzC4RovSexV8jVDaovvtHuMpvd4N2XiF/ChvOo/4=; b=okmjpArWbf3+xNlnKdw7EiHg0xYMBtDVFX5878aNc+8k94RPTE4VZkWQvAdYhEhRwh C/0E+UHlrQQseNK33Be2Ig8uKA2n4PtnGscfwNurKJJt0zOgaxxUk8CUz6HjOytRZFri YyjarH89xR+2+HCE50d7/Cs21PFze6rnNy16dIPLHK7KLz2ql2XfxKDOSTWN1KojhC1S nz4Tlm68oVJMz738IUadRV3Mng7sSLj/Nz5iyMeZpDYoesDU0dM9wgsz+pjv9PsdLTZK Bk40inGCWWJZEcQGKlHbIaHHsqIKrZ4wpmzY3Sjut0go8trvBX5vRg8BvCjUJuW+Gw2y witA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uE8AzC4RovSexV8jVDaovvtHuMpvd4N2XiF/ChvOo/4=; b=CIWs113ScTycc/qehzUbWHJwIPb8rZu3N2ZxwbqpLjeJd7C3JAg5AmO5Uf4mimyV/r yIECH2w2aQM0mvK4qkk/gWwJeSGDRiMelSbhJXbhtLcffmLvDzfWwqMwlyIuFjedPogh 3mJOFCe0xFYpwvSO0PvKlicCC8fG3fzKCMw1ExoOG5uR3e6y+D7tSTfXIalVYBH4oI4Q pu6y2SBKlQI+VdjvXjUswBguYzntKJZ3vAwUc51fBLK4OQruHlgihhKqHKJqzgvEr5cl LCdfO3exUpVHhQu6+g8fwj9Ak2HSTVhwRIg14SHi8bko1milxgh9LioAIftjzeK8HQt9 6iQQ== X-Gm-Message-State: AKwxytftcP/tC46qnUxGhc7wmOI7JF4ipL27fR+nqcxjN/WAoG3AMf6P EXaZ65YeTYxj/x1pP/Pc/xol3ev76wjiG6+bWZU= X-Google-Smtp-Source: ACJfBovMmUUFoVJ9zDzpF7zXVpvcehMHeJyGR2w67w5MyHoqQ33FA4FmdRKTNPXnEMV1BftfVL2vSS372U6lWcsKvPs= X-Received: by 10.80.183.34 with SMTP id g31mr10552750ede.191.1516329055103; Thu, 18 Jan 2018 18:30:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Thu, 18 Jan 2018 18:30:14 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 18 Jan 2018 18:30:14 -0800 Message-ID: To: A S Cc: rift@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19507eb12de9056317de87" Archived-At: Subject: Re: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 02:30:58 -0000 --94eb2c19507eb12de9056317de87 Content-Type: text/plain; charset="UTF-8" funny one ;-) If that persists, I may to have to change my name to Zaphod or something ;-) BTW, talking about first possible WG meet @ 101 (no, it's NOT the highway in SV in case we have FUD in this case as well ;-), what would people like from me if I get a preso slot? Some more in-detail walk-through of some section/concept in the RIFT draft? List of what I think people can grab on the main draft to contribute/flesh out? Otherwise charter has things enough to camp on ... Before 101 I see another version rev'ed with some subtle ZTP updates due to feedback I got. And there's another one larg'ish addition being thought through but that's being chewed right now by the core folks and not ready for wider look yet. Most likely after 101 ... thanks --- tony On Thu, Jan 18, 2018 at 5:45 PM, A S wrote: > Got a unicast that Tony here is multicast address. To clarify, I meant > Tony P. > > > > --94eb2c19507eb12de9056317de87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
funny one ;-)=C2=A0=C2=A0 If that persists, I ma= y to have to change my name to Zaphod or something ;-)

BTW, t= alking about first possible WG meet @ 101 (no, it's NOT the highway in = SV in case we have FUD in this case as well ;-), what would people like fro= m me if I get a preso slot? Some more in-detail walk-through of some sectio= n/concept in the RIFT draft? List of what I think people can grab on the ma= in draft to contribute/flesh out? Otherwise charter has things enough to ca= mp on ...

Before 101 I see another version re= v'ed with some subtle ZTP updates due to feedback I got. And there'= s another one larg'ish addition being thought through but that's be= ing chewed right now by the core folks and not ready for wider look yet. Mo= st likely after 101 ...

thanks
=
--- tony=C2=A0

On Thu, Jan 18, 2018 at 5:45 PM, A S <as3957@gmail.com><= /span> wrote:
Got a unic= ast that Tony here is multicast address. To clarify, I meant Tony P.




--94eb2c19507eb12de9056317de87-- From nobody Thu Jan 18 21:33:30 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F72C127342 for ; Thu, 18 Jan 2018 21:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no 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 pU5cQayUCm5O for ; Thu, 18 Jan 2018 21:33:28 -0800 (PST) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (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 DA866124E15 for ; Thu, 18 Jan 2018 21:33:27 -0800 (PST) Received: by mail-it0-f44.google.com with SMTP id b5so834221itc.3 for ; Thu, 18 Jan 2018 21:33:27 -0800 (PST) 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:cc; bh=GepjEdvQquQ7ze8PWv57DulXlWmeCzg3xuQErYhtEW8=; b=l6z5IuuTCLhaPFWFgYUZMgL5lR1A5CGIpctRTEpr0R/Sin6m2CCT1IPsyj9c5/LLfh CwLWIoFN5zw6p2xCNLYnnlQS0aaP3R/H2aYVEnsa+FFpsKr9jLC09XlAhBnkzd35MuKD zdcNCIEqC7DxDbr5lEiGvrgC6TDhA/Phgf5Dw+uQA6vT+TqzPTluOyf4A53OF+ggcIMX wEaqVhpUkO5rkm0o0Ri63KzI3qmSort46ezFO+k9Cu+6mxetzOMqaMNr3pQDpoZRUBQp gDbFqwzrjkWYySJOwawZg5Afp5W6xVb5ENlmurf3EQISl9WZV5Kipy6ZMGWvuRdcj1Ln /Wrg== X-Gm-Message-State: AKwxytdK2vtsIpQIHwxqNr0eql0XUKw3kOaVyuRrvyabOeW310vK1HUq gRcNQu8MNaaS84Yeap4lL+6r9EZ87wwZ2CtNsUU= X-Google-Smtp-Source: ACJfBovyTgr4LhIs3bXSklswFCq4jbnfECMwt+FJ8lZuglAprpt6xtH9iwrUzF9iXmVYP3cOvCE3jrTO9hzjNXYp1gI= X-Received: by 10.36.137.67 with SMTP id s64mr28396026itd.90.1516340007100; Thu, 18 Jan 2018 21:33:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tony Li Date: Fri, 19 Jan 2018 05:33:16 +0000 Message-ID: To: A S Cc: rift@ietf.org Content-Type: multipart/alternative; boundary="94eb2c05eee67b67e805631a6b85" Archived-At: Subject: Re: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 05:33:29 -0000 --94eb2c05eee67b67e805631a6b85 Content-Type: text/plain; charset="UTF-8" > > Got a unicast that Tony here is multicast address. To clarify, I meant > Tony P. > Unqualified makes it anycast. ;-) T --94eb2c05eee67b67e805631a6b85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Got a unicast that Tony here is multicast address. To clarify, I meant Ton= y P.

Unqual= ified makes it anycast. =C2=A0;-)

T

--94eb2c05eee67b67e805631a6b85-- From nobody Fri Jan 19 09:34:41 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF01127369 for ; Fri, 19 Jan 2018 09:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.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 AjTV-FgPQNw9 for ; Fri, 19 Jan 2018 09:34:37 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 48A62126CF6 for ; Fri, 19 Jan 2018 09:34:37 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0JHTiM6003345; Fri, 19 Jan 2018 09:34:35 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=a/gTCupwzABwflgFmrvzzI65jZtclsEFKx23CIcteeo=; b=kdE2x5UBAF7ukatNV/nQjDqBXavs29AIIFO93HArFmUexwXBry48i2gK5T9gutxZ6D47 FZKZMkCUg4QN/XWpT4bGn/3LW1hH6lP8rcBc1+ky3r5hjVed4SPELIaNDRsFYPTh065c 2fJ89WHD/3gmOvP5zlTyedtWbmFyikjEQ57Bj7PL3tEGQ7p2H29v/uPujx6ZTNDUMeja DbRwMkQ2QNqgd8PQuMbW1+XTDHEYXVhEKblBDDlYKC2FsHGYjg6UpnEdcGD0BdsQqh7T mjmamtcgD/hmYx7kGppOEJBYN7GgqHNvXj3ZVSwmFmGS4TKn6gSytbpj5yLw5JRv3tay /w== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0054.outbound.protection.outlook.com [216.32.180.54]) by mx0a-00273201.pphosted.com with ESMTP id 2fkn0500qg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 19 Jan 2018 09:34:35 -0800 Received: from CY1PR0501MB1340.namprd05.prod.outlook.com (10.160.226.145) by CY1PR0501MB1691.namprd05.prod.outlook.com (10.163.140.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Fri, 19 Jan 2018 17:34:32 +0000 Received: from CY1PR0501MB1340.namprd05.prod.outlook.com ([10.160.226.145]) by CY1PR0501MB1340.namprd05.prod.outlook.com ([10.160.226.145]) with mapi id 15.20.0428.014; Fri, 19 Jan 2018 17:34:32 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Tony Przygienda , A S CC: "rift@ietf.org" Thread-Topic: [Rift] Internal Review of the rift Charter Thread-Index: AQHTkKCa2u7Oze5tMU6oEwCD4tM+4qN6bP0AgAAMoQCAAPxpUA== Date: Fri, 19 Jan 2018 17:34:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1691; 7:WvHZw1OmoU0mPy6yuZywh/ALSciRzyAZtN+1Y9yJP2vKxDIu460zWtiUdEXuZYe3CslT31bJPNMBGCo0fWULXy0t+/ZmM+5XiGxo5xStE8j4nzD2m0+72VKOtFL0KttJNvRyGebszVKhBjfG1Dfu549E6UMku7tBAM2TwSQaIZAwARjiYjkWw7s1ILSLJYXXJBlIip1YkUrOMK0G2hPQ8meFxbtVHpNOEKX4AqqgNMVAEzhptji2ggk9T552wTJo x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 447a237f-d8e6-4c92-5fe3-08d55f62e68a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY1PR0501MB1691; x-ms-traffictypediagnostic: CY1PR0501MB1691: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231023)(2400080)(944501161)(6055026)(6041268)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:CY1PR0501MB1691; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY1PR0501MB1691; x-forefront-prvs: 0557CBAD84 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(39860400002)(346002)(376002)(396003)(189003)(199004)(39060400002)(8936002)(229853002)(77096007)(6246003)(316002)(6436002)(7696005)(5660300001)(102836004)(55016002)(33656002)(105586002)(3846002)(790700001)(81166006)(6116002)(8676002)(76176011)(26005)(66066001)(99286004)(2900100001)(110136005)(106356001)(14454004)(25786009)(6306002)(4326008)(3280700002)(97736004)(6506007)(2950100002)(236005)(53546011)(9686003)(74316002)(478600001)(53936002)(86362001)(53946003)(54896002)(3660700001)(68736007)(81156014)(2906002)(7736002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1691; H:CY1PR0501MB1340.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: qoaoUtajYghEFSGOidfKhPe9HO2BiXo7HPxShgw4P2yTd1x8noxY9/+R9RSgKS2bgsrs46/wqK0B/a+mrE/+5A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB1340117544E37F133EF0BD75D4EF0CY1PR0501MB1340_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 447a237f-d8e6-4c92-5fe3-08d55f62e68a X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2018 17:34:32.1574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1691 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-19_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801190227 Archived-At: Subject: Re: [Rift] Internal Review of the rift Charter X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 17:34:40 -0000 --_000_CY1PR0501MB1340117544E37F133EF0BD75D4EF0CY1PR0501MB1340_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFNvbWUgbW9yZSBpbi1kZXRhaWwgd2Fsay10aHJvdWdoIG9mIHNvbWUgc2VjdGlvbi9jb25j ZXB0IGluIHRoZSBSSUZUIGRyYWZ0PyBMaXN0IG9mIHdoYXQgSSB0aGluayBwZW9wbGUgY2FuIGdy YWIgb24gdGhlIG1haW4gZHJhZnQgdG8gY29udHJpYnV0ZS9mbGVzaCBvdXQNCg0KVGhhdCB3aWxs IGRlZmluaXRlbHkgaGVscC4NCg0KSmVmZnJleQ0KDQpGcm9tOiBSaWZ0IFttYWlsdG86cmlmdC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9ueSBQcnp5Z2llbmRhDQpTZW50OiBUaHVy c2RheSwgSmFudWFyeSAxOCwgMjAxOCA5OjMwIFBNDQpUbzogQSBTIDxhczM5NTdAZ21haWwuY29t Pg0KQ2M6IHJpZnRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUmlmdF0gSW50ZXJuYWwgUmV2aWV3 IG9mIHRoZSByaWZ0IENoYXJ0ZXINCg0KZnVubnkgb25lIDstKSAgIElmIHRoYXQgcGVyc2lzdHMs IEkgbWF5IHRvIGhhdmUgdG8gY2hhbmdlIG15IG5hbWUgdG8gWmFwaG9kIG9yIHNvbWV0aGluZyA7 LSkNCkJUVywgdGFsa2luZyBhYm91dCBmaXJzdCBwb3NzaWJsZSBXRyBtZWV0IEAgMTAxIChubywg aXQncyBOT1QgdGhlIGhpZ2h3YXkgaW4gU1YgaW4gY2FzZSB3ZSBoYXZlIEZVRCBpbiB0aGlzIGNh c2UgYXMgd2VsbCA7LSksIHdoYXQgd291bGQgcGVvcGxlIGxpa2UgZnJvbSBtZSBpZiBJIGdldCBh IHByZXNvIHNsb3Q/IFNvbWUgbW9yZSBpbi1kZXRhaWwgd2Fsay10aHJvdWdoIG9mIHNvbWUgc2Vj dGlvbi9jb25jZXB0IGluIHRoZSBSSUZUIGRyYWZ0PyBMaXN0IG9mIHdoYXQgSSB0aGluayBwZW9w bGUgY2FuIGdyYWIgb24gdGhlIG1haW4gZHJhZnQgdG8gY29udHJpYnV0ZS9mbGVzaCBvdXQ/IE90 aGVyd2lzZSBjaGFydGVyIGhhcyB0aGluZ3MgZW5vdWdoIHRvIGNhbXAgb24gLi4uDQoNCkJlZm9y ZSAxMDEgSSBzZWUgYW5vdGhlciB2ZXJzaW9uIHJldidlZCB3aXRoIHNvbWUgc3VidGxlIFpUUCB1 cGRhdGVzIGR1ZSB0byBmZWVkYmFjayBJIGdvdC4gQW5kIHRoZXJlJ3MgYW5vdGhlciBvbmUgbGFy Zydpc2ggYWRkaXRpb24gYmVpbmcgdGhvdWdodCB0aHJvdWdoIGJ1dCB0aGF0J3MgYmVpbmcgY2hl d2VkIHJpZ2h0IG5vdyBieSB0aGUgY29yZSBmb2xrcyBhbmQgbm90IHJlYWR5IGZvciB3aWRlciBs b29rIHlldC4gTW9zdCBsaWtlbHkgYWZ0ZXIgMTAxIC4uLg0KDQp0aGFua3MNCg0KLS0tIHRvbnkN Cg0KT24gVGh1LCBKYW4gMTgsIDIwMTggYXQgNTo0NSBQTSwgQSBTIDxhczM5NTdAZ21haWwuY29t PG1haWx0bzphczM5NTdAZ21haWwuY29tPj4gd3JvdGU6DQpHb3QgYSB1bmljYXN0IHRoYXQgVG9u eSBoZXJlIGlzIG11bHRpY2FzdCBhZGRyZXNzLiBUbyBjbGFyaWZ5LCBJIG1lYW50IFRvbnkgUC4N Cg0KDQoNCg0K --_000_CY1PR0501MB1340117544E37F133EF0BD75D4EF0CY1PR0501MB1340_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDM5MTIxLkRBMjY3Q0EwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6Wm9vbT4xMjA8L3c6Wm9vbT4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xl YW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5n Lz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2 ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRD b250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhv bGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJv bW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3Okxp ZFRoZW1lQXNpYW4+WkgtQ048L3c6TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNj cmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4N Cjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3 OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQo8 dzpVc2VGRUxheW91dC8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjxtOm1hdGhQcj4NCjxtOm1hdGhG b250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCjxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQo8 bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KPG06c21hbGxGcmFjIG06dmFsPSJvZmYiLz4N CjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ck1hcmdpbiBtOnZhbD0i MCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQo8bTp3cmFwSW5kZW50IG06dmFs PSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0KPG06bmFyeUxpbSBtOnZhbD0i dW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0 ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgRGVmU2VtaUhpZGRlbj0iZmFsc2Ui IERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjM3 MSI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFFGb3JtYXQ9 InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp bmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i aGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijki IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRy dWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJp bmRleCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iaW5kZXggNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9ImluZGV4IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggOCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2Mg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDciLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCBJ bmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZm9vdG5vdGUgdGV4dCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaGVhZGVy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3RlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJp bmRleCBoZWFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM1IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0YWJsZSBvZiBmaWd1cmVz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIGFkZHJlc3MiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iZW52ZWxvcGUgcmV0dXJuIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3Rub3Rl IHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHJlZmVyZW5jZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJsaW5lIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJwYWdlIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHJlZmVyZW5jZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0idGFibGUgb2YgYXV0aG9yaXRpZXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0ibWFjcm8iLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9hIGhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i TGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJMaXN0IE51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlz dCBCdWxsZXQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlz dCBCdWxsZXQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlz dCBOdW1iZXIgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJDbG9zaW5nIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlNpZ25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i RGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJMaXN0IENvbnRpbnVlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGlu dWUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3Qg Q29udGludWUgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZXNzYWdlIEhlYWRlciIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iU2FsdXRhdGlvbiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJEYXRlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBG aXJzdCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEZpcnN0IEluZGVu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vdGUgSGVhZGluZyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJCb2R5IFRleHQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJsb2Nr IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IkZvbGxvd2VkSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjIyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9 IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkRvY3VtZW50IE1hcCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJQbGFpbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkUtbWFpbCBT aWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBUb3Agb2YgRm9ybSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Ik5vcm1hbCAoV2ViKSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEFjcm9ueW0iLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBBZGRyZXNzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IkhUTUwgQ2l0ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIENvZGUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iSFRNTCBEZWZpbml0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwg S2V5Ym9hcmQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBQcmVmb3JtYXR0ZWQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBTYW1wbGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRN TCBUeXBld3JpdGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgVmFyaWFibGUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iTm9ybWFsIFRhYmxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImFu bm90YXRpb24gc3ViamVjdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJObyBMaXN0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91 dGxpbmUgTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIFNpbXBsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBDbGFzc2ljIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3Np YyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl IENvbG9yZnVsIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iVGFibGUgQ29sdW1ucyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdy aWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iVGFibGUgR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iVGFibGUgR3JpZCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iVGFibGUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgTGlzdCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi bGUgTGlzdCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgOCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgM0QgZWZmZWN0cyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVj dHMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb250ZW1wb3JhcnkiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iVGFibGUgRWxlZ2FudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJs ZSBQcm9mZXNzaW9uYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iVGFibGUgV2ViIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmFs bG9vbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBOYW1lPSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFRoZW1lIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgTmFtZT0i UGxhY2Vob2xkZXIgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5nIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBM aXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1l PSJMaWdodCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRp dW0gTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3 IiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9y ZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzIiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9Ikxp Z2h0IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBOYW1lPSJSZXZpc2lv biIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2Vu dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1l PSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5h bWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVs IEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0 IEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5h bWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlk IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsg TGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0i Q29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFt ZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRp bmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVk aXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFt ZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0 IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcz IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBM aXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRp dW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFj Y2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBO YW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3Jp ZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9y ZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9 IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNj ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBM aXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1l ZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFt ZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGlu ZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRp bmcgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0i TWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBB Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIg TmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFk aW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFFGb3JtYXQ9 InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzIiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJl bmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM3IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iQmlibGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDEiIE5hbWU9IlBsYWluIFRhYmxlIDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDIiIE5hbWU9IlBsYWluIFRhYmxlIDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDMiIE5hbWU9IlBsYWlu IFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDQi IE5hbWU9IlBsYWluIFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDUiIE5hbWU9IlBsYWluIFRhYmxlIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDAiIE5hbWU9IkdyaWQgVGFibGUgTGlnaHQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUg MSBMaWdodCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIg TmFtZT0iR3JpZCBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikdy aWQgVGFibGUgNiBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDci IE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxl IDQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIi IE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFj Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO YW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0 IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUw IiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFj Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBO YW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt ZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIg TmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFt ZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50 IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9 IkdyaWQgVGFibGUgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h bWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50 IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9 IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJH cmlkIFRhYmxlIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2Vu dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1l PSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJH cmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3Jp ZCBUYWJsZSAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i R3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3Jp ZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlz dCBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5 IiBOYW1lPSJMaXN0IFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxp c3QgVGFibGUgNyBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgi IE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxl IDUgRGFyayBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcg Q29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFj Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBO YW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1 IERhcmsgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENv bG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFt ZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBE YXJrIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xv cmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50 IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9 Ikxpc3QgVGFibGUgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFy ayBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1 MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3Jm dWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJM aXN0IFRhYmxlIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEi IE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVs IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2 IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlz dCBUYWJsZSAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBO YW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBB Y2NlbnQgNiIvPg0KPC93OkxhdGVudFN0eWxlcz4NCjwveG1sPjwhW2VuZGlmXS0tPjxzdHlsZT48 IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oldp bmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwOw0KCW1zby1mb250LWFsdDpX aW5nZGluZ3M7DQoJbXNvLWZvbnQtY2hhcnNldDoyOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5 OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjAg MjY4NDM1NDU2IDAgMCAtMjE0NzQ4MzY0OCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsNCgltc28tZm9u dC1hbHQ6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5l cmljLWZvbnQtZmFtaWx5OnJvbWFuOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1m b250LXNpZ25hdHVyZTotNTM2ODcwMTQ1IDExMDczMDU3MjcgMCAwIDQxNSAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTsNCgltc28tZm9udC1hbHQ6U2ltU3VuOw0KCW1zby1mb250LWNoYXJzZXQ6MTM0Ow0KCW1zby1n ZW5lcmljLWZvbnQtZmFtaWx5Om1vZGVybjsNCgltc28tZm9udC1waXRjaDpmaXhlZDsNCgltc28t Zm9udC1zaWduYXR1cmU6MSAxMzUxMzUyMzIgMTYgMCAyNjIxNDQgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJ bXNvLWZvbnQtYWx0OiJDZW50dXJ5IEdvdGhpYyI7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1z by1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0K CW1zby1mb250LXNpZ25hdHVyZTotNTM2ODU5OTA1IC0xMDczNzMyNDg1IDkgMCA1MTEgMDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAw IDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWNoYXJzZXQ6MTM0Ow0KCW1zby1nZW5lcmljLWZvbnQt ZmFtaWx5Om1vZGVybjsNCgltc28tZm9udC1waXRjaDpmaXhlZDsNCgltc28tZm9udC1zaWduYXR1 cmU6MSAxMzUxMzUyMzIgMTYgMCAyNjIxNDQgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtdW5o aWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndp ZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkRlbmdYaWFuO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsN Cgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVy bGluZTpzaW5nbGU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLXN0eWxl LXVuaGlkZTpubzsNCgltc28tc3R5bGUtcWZvcm1hdDp5ZXM7DQoJbWFyZ2luLXRvcDowaW47DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp ZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpEZW5nWGlhbjt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkRlbmdYaWFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS11bmhpZGU6 bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjExLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCW1z by1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCW1zby1oYW5zaS1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCgltc28tZm9vdGVy LW1hcmdpbjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjExNDA3MjkzODE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjk2MTU0NDYyMCAxNDY5NzE1NjQ2IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDou MjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6RGVuZ1hp YW47DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi43NWluOw0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoxLjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MS43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyLjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjIuNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozLjI1aW47DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjMuNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NC4y NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gMTBdPjxzdHlsZT4vKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K dGFibGUuTXNvTm9ybWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6IlRhYmxlIE5vcm1hbCI7DQoJ bXNvLXRzdHlsZS1yb3diYW5kLXNpemU6MDsNCgltc28tdHN0eWxlLWNvbGJhbmQtc2l6ZTowOw0K CW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5nLWFsdDowaW4gNS40cHQgMGluIDUuNHB0Ow0KCW1z by1wYXJhLW1hcmdpbjowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1z by1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0idGFiLWludGVydmFsOi41aW4i Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tYmlk aS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5nczttc28tZmFyZWFzdC1mb250 LWZhbWlseTpXaW5nZGluZ3M7bXNvLWJpZGktZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+U29tZSBtb3JlIGluLWRldGFpbCB3YWxrLXRocm91Z2ggb2Ygc29tZSBzZWN0aW9uL2NvbmNl cHQgaW4gdGhlIFJJRlQgZHJhZnQ/IExpc3Qgb2Ygd2hhdCBJIHRoaW5rIHBlb3BsZSBjYW4gZ3Jh YiBvbiB0aGUgbWFpbiBkcmFmdCB0byBjb250cmlidXRlL2ZsZXNoIG91dDxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYXQgd2lsbCBkZWZpbml0ZWx5 IGhlbHAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkplZmZyZXk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4gUmlmdA0KIFttYWlsdG86cmlmdC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2Yg PC9iPlRvbnkgUHJ6eWdpZW5kYTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAx OCwgMjAxOCA5OjMwIFBNPGJyPg0KPGI+VG86PC9iPiBBIFMgJmx0O2FzMzk1N0BnbWFpbC5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiByaWZ0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbUmlmdF0gSW50ZXJuYWwgUmV2aWV3IG9mIHRoZSByaWZ0IENoYXJ0ZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPmZ1bm55IG9uZSA7LSkmbmJzcDsmbmJzcDsgSWYg dGhhdCBwZXJzaXN0cywgSSBtYXkgdG8gaGF2ZSB0byBjaGFuZ2UgbXkgbmFtZSB0byBaYXBob2Qg b3Igc29tZXRoaW5nIDstKQ0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJUVywgdGFsa2luZyBhYm91dCBmaXJzdCBwb3NzaWJsZSBXRyBtZWV0IEAgMTAxIChu bywgaXQncyBOT1QgdGhlIGhpZ2h3YXkgaW4gU1YgaW4gY2FzZSB3ZSBoYXZlIEZVRCBpbiB0aGlz IGNhc2UgYXMgd2VsbCA7LSksIHdoYXQgd291bGQgcGVvcGxlIGxpa2UgZnJvbSBtZSBpZiBJIGdl dCBhIHByZXNvIHNsb3Q/IFNvbWUgbW9yZSBpbi1kZXRhaWwgd2Fsay10aHJvdWdoIG9mIHNvbWUg c2VjdGlvbi9jb25jZXB0DQogaW4gdGhlIFJJRlQgZHJhZnQ/IExpc3Qgb2Ygd2hhdCBJIHRoaW5r IHBlb3BsZSBjYW4gZ3JhYiBvbiB0aGUgbWFpbiBkcmFmdCB0byBjb250cmlidXRlL2ZsZXNoIG91 dD8gT3RoZXJ3aXNlIGNoYXJ0ZXIgaGFzIHRoaW5ncyBlbm91Z2ggdG8gY2FtcCBvbiAuLi4NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWZv cmUgMTAxIEkgc2VlIGFub3RoZXIgdmVyc2lvbiByZXYnZWQgd2l0aCBzb21lIHN1YnRsZSBaVFAg dXBkYXRlcyBkdWUgdG8gZmVlZGJhY2sgSSBnb3QuIEFuZCB0aGVyZSdzIGFub3RoZXIgb25lIGxh cmcnaXNoIGFkZGl0aW9uIGJlaW5nIHRob3VnaHQgdGhyb3VnaCBidXQgdGhhdCdzIGJlaW5nIGNo ZXdlZCByaWdodCBub3cgYnkgdGhlIGNvcmUgZm9sa3MgYW5kIG5vdCByZWFkeSBmb3Igd2lkZXIg bG9vaw0KIHlldC4gTW9zdCBsaWtlbHkgYWZ0ZXIgMTAxIC4uLiA8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmtzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tIHRvbnkmbmJzcDsgPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gMTgsIDIwMTggYXQgNTo0 NSBQTSwgQSBTICZsdDs8YSBocmVmPSJtYWlsdG86YXMzOTU3QGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmFzMzk1N0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O21zby1ib3JkZXItbGVmdC1hbHQ6c29saWQgI0NDQ0NDQyAuNzVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdvdCBhIHVuaWNhc3QgdGhhdCBUb255IGhlcmUgaXMgbXVs dGljYXN0IGFkZHJlc3MuIFRvIGNsYXJpZnksIEkgbWVhbnQgVG9ueSBQLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0501MB1340117544E37F133EF0BD75D4EF0CY1PR0501MB1340_-- From nobody Fri Jan 19 21:10:58 2018 Return-Path: X-Original-To: rift@ietf.org Delivered-To: rift@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE3712783A; Fri, 19 Jan 2018 21:10:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: aretana.ietf@gmail.com, rift-chairs@ietf.org, rift@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com> Date: Fri, 19 Jan 2018 21:10:52 -0800 Archived-At: Subject: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT) X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2018 05:10:53 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-rift-00-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-rift/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I THINK I'm happy to see this work go forward, but I am almost sufficiently confused by the current charter to say "not ready for external review yet". Should be easy to fix, though, so not Blocking. (Could you spell out "Clos" on first use? I had to google that) It seemed to me that at least some of the discussion in DCROUTING BOF described some of the reasons why "routing in data centers is different". It would be helpful to me, if there was a mention of at least one or two differences that make new protocol work necessary or desirable. I mean, like, one sentence. It's possible to reverse-engineer that out of the bulleted list a bit further down, but that's kind of new-participant-hostile. The description of the protocol that the working group would deliver is tied to the deliverable based on draft-przygienda-rift, is that right? I had to look at the table of contents for draft-przygienda-rift to figure that out - and even then, I'm not sure. Perhaps - A Standards Track **routing protocol** specification based on draft-przygienda-rift. The document will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.) ? From nobody Sun Jan 21 14:18:24 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AF61243F3; Sun, 21 Jan 2018 14:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uppXBf1OWXyh; Sun, 21 Jan 2018 14:18:17 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2728D1200F1; Sun, 21 Jan 2018 14:18:14 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1edNwK-0001IN-UF; Sun, 21 Jan 2018 22:18:13 +0000 Date: Sun, 21 Jan 2018 14:18:12 -0800 Message-ID: From: Randy Bush To: Spencer Dawkins Cc: "The IESG" , rift-chairs@ietf.org, rift@ietf.org, aretana.ietf@gmail.com In-Reply-To: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com> References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT) X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 22:18:18 -0000 > (Could you spell out "Clos" on first use? I had to google that) uh, his first name was charles, as i remember. randy From nobody Sun Jan 21 14:45:57 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C581B127201; Sun, 21 Jan 2018 14:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 H8xhUboMGIUR; Sun, 21 Jan 2018 14:45:48 -0800 (PST) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 CA48B1200F1; Sun, 21 Jan 2018 14:45:48 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id y26so5630161pfi.10; Sun, 21 Jan 2018 14:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mSBT4Y/zk9oMtnGI0LgZJ9m8nnbDXZDdB975tO+p1GU=; b=VCAgVj5Z4zAbY4MdWKgg27kiZg+uqCHLECLmnjQ42QUimB4rp0bPF551z2wok3sQbQ 10pk/Tdzu1cDSSeIVCd/T3fkXIX7PTg5nhUSSJi/mKghk/ZH7+vkm+HUVUaI33Ik0xJs RtR7Qz64kRKDA8neWGfKaf6+A953NZNUoSyFPns3KQjwVodbsANsrvCCmilc9FywAgdP Y/LwnTRnXPS7sN68lg4F4q/phXHz924wocJs1SNayS+z/BqO8DYZldywrThWqAYYzYI3 xZ8cQfA8eqXr1sjJ164e+XtdwGG+Cd4QU0EfLwiXpvU4yzRywjp1gctAl9gGk21g9AYl AYJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mSBT4Y/zk9oMtnGI0LgZJ9m8nnbDXZDdB975tO+p1GU=; b=JUss88aDTLjYpKbvhCd3MJq/DknQ+yzZCDEKp46teMX9A6R7M1qc2rhzFVFLKYUPbz PeaGdlPPz9zTctSy2jNgbHpbnuzmN6Vr/VOjrFYKCmriKIzhs8a42YsobFfq6i1hyRAv 8GdvW/b8o31MLVTsIPGmFK1DMBEkvwPv5JX55fZ5R+MdxCL4aahanOQOYDFxEcf4PAzI iTEFCaIqdNur6bHvJSRLGT2nXF6VtmTYbTIYYwrj5CyuDmhnV+AuHKOsUJKMcCBWCoyR 076ZFkgW8Gl2n0zPMPgvifDjpQ+VF8cOIuPjKrhUoHi5XF0f2+Z06SOKDjaRD1wdel/7 7EoQ== X-Gm-Message-State: AKwxytf+AvdcnCLWdiDL9Szz5TA0EOa//wcTHESoC0QajsKDb//AHedA Qiwk4lTWVkZl1L5YrVWFqj99KJxr X-Google-Smtp-Source: AH8x224u8Tf7O4b7rW33XS+hQ7nyNp0eeuh44E2xXYMgpC8BsiejzmWsTK174NLRbEqpkz8aGPmqaQ== X-Received: by 2002:a17:902:6d09:: with SMTP id s9-v6mr2490937plk.176.1516574748421; Sun, 21 Jan 2018 14:45:48 -0800 (PST) Received: from [192.168.1.7] (ip184-189-218-77.sb.sd.cox.net. [184.189.218.77]) by smtp.gmail.com with ESMTPSA id l188sm1209630pgl.72.2018.01.21.14.45.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jan 2018 14:45:47 -0800 (PST) From: Fred Baker Message-Id: <7983DAAF-E9A8-4FB5-870B-179E130C2EA4@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_07BB659C-C994-4CBB-BA18-113FEAAE921B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 21 Jan 2018 14:45:43 -0800 In-Reply-To: Cc: Spencer Dawkins , rift-chairs@ietf.org, The IESG , rift@ietf.org, aretana.ietf@gmail.com To: Randy Bush References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT) X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 22:45:51 -0000 --Apple-Mail=_07BB659C-C994-4CBB-BA18-113FEAAE921B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 21, 2018, at 2:18 PM, Randy Bush wrote: >=20 >> (Could you spell out "Clos" on first use? I had to google that) >=20 > uh, his first name was charles, as i remember. Yes. https://en.wikipedia.org/wiki/Clos_network There is no wikipedia entry for the guy himself, but the first reference = in the article is to his May 1953 Bell Systems Technical Journal = article, listing Charles Clos as the author. I made the mistake of pronouncing the name "close". It rhymes with = "loss". > randy >=20 > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift --Apple-Mail=_07BB659C-C994-4CBB-BA18-113FEAAE921B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlplGBcACgkQEhdRnd2G P+BNzQ/8DOBrQ/AwjRABuh+gdZGuig+LK4Zu0fp4MRvXA2GO2yH+HKhEq7olshJF 4Udp7sDcCGuUwBQwownyOP0J0fT6VfoxgZXkE9XNjISK/KH8h74lQjqcU2rnMlhC r0eP78DBjn3oos19Wjt9HgI4Y7Aaq7fna4ubf7FmQWYwJaEUbklcRz4rE/sc48Wd j55h0+SjK/xs7OiCFvTVo3IQbxBQ/TF8f6QtAC3Wz6kEsVThKtMHSgcWrSBtqmsF vrRvMQFEl/nMtI9KMXLx6suGyj3JlPFwt0n8A0GA6rlQRD0JHLL5TyYf5jGdg7ID 88+h2NFIDJa7imGyqcyjTXq5umgq06idjF8u+3H2Z0Ib+/ZkXHQBbCRAokjB9AIY NzegEjkfBIJtEk6o0ZdhaArqZs3HVHvEy+tVbFeVoS+JnpZSk1J59ovJsudSzspg SyxlTsxCvvFtzlDKnShBVRZzAT00ut5IfcVA5F11sC3qRn5esYn/TgRCsODkHbrQ XxF8zXdYtnZR9VETDvK34UQeziolIQTPtIRW63vMdQHylF+1Kyihsnjyri2C984Z YRHzAWNBjC99qUUnye8L+i2xiP+CscDKgD9b2g+fchQdg7pKi2YHQr0iwQX0JvVg ZHkW7u/mOUGoJeKBdhvY1+FD9Agrw8ptI4aVreQRCIcu2/xgMbE= =OOdi -----END PGP SIGNATURE----- --Apple-Mail=_07BB659C-C994-4CBB-BA18-113FEAAE921B-- From nobody Sun Jan 21 15:37:50 2018 Return-Path: X-Original-To: rift@ietfa.amsl.com Delivered-To: rift@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D4A12421A; Sun, 21 Jan 2018 15:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YJOkWIaZJntp; Sun, 21 Jan 2018 15:37:43 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 2A6291200F1; Sun, 21 Jan 2018 15:37:43 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id g16so5692940pgn.7; Sun, 21 Jan 2018 15:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=JO8QJF9L/w+ASI2R1tY5kSJXtwtERb0/hpxmfHhDQpA=; b=YYoUaup7OTDNLclsu4W99ZqwfJ0q2x2I5iEpf+7rIEOCBxJOkR/Lep0OpJHt2oD68G C93KZUZo6NWkkO36NG8Ei8XKPleXHkN+ZbEOoFMRzvIL1J13JgepWnt8Q2pHmbraTQak /fAZml9Oa+M8X8zIy3Y8DjSMveW+3JvdTx2KLp11mjlTNSAnkeGluJLFTts+9+V8QoLC 7X6Kzy8pXygNNLGmcKLyKVPLefzuKkpMslpTIrcZn4NQYIiLx0Zwfr++uk5jm3Yc6Roj wjYeQErc8XS+JDGkO107h17bawDxeVrRArtYNupY0pKcu7uDwDWcWT+/8z6jzQd/35ZH J24Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=JO8QJF9L/w+ASI2R1tY5kSJXtwtERb0/hpxmfHhDQpA=; b=ZgP+8krB3f76tACTL4N+oln69cou2JxPk3YARricY9hxTMd4o3MiY7mMyl22BK9hAt azk/AkXCU6rIbZ23UD/vvujEXHyzzQRG77oIC2SF195gXG390Y5jj/U7YLqdVl33dkam o4vunu3npdFsDjCIig0PZ+VBK7GNsiAaethbIr31Nb/o/ceSr7m8lkjLxAv+LOrRgLNn xwz0rAAaOqKr355K0vrub/gsBQn9MbaxeLxpbxJBbV6jdj9VTGLlqrAc43vwRrS1jSNi eqC7Z8q95Bn5xqJtlj9wCO7yFLUaf9CkaDa0ji7b5k9syYb0Dzqzvg9tqB1Win8iaj88 qQGg== X-Gm-Message-State: AKwxytf8loqlfxzh2Wi5i5MgBOZ1ZZPLLwL6kkKZ90WXycr6xxbRatW4 jXCG6BrNfTJJfbWoKrbiI+WkT7k3dpM= X-Google-Smtp-Source: AH8x227H71IwVqeusY7MZILhOvm0rp9TOQsdLD5YupOyuNO7ntXJBO7nLKjAwSvG4BqiNJkF9aQcNw== X-Received: by 10.99.123.74 with SMTP id k10mr5501290pgn.165.1516577862328; Sun, 21 Jan 2018 15:37:42 -0800 (PST) Received: from iconic.local (173-8-183-214-SFBA.hfc.comcastbusiness.net. [173.8.183.214]) by smtp.gmail.com with ESMTPSA id v20sm27335886pfe.176.2018.01.21.15.37.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jan 2018 15:37:41 -0800 (PST) To: Fred Baker , Randy Bush Cc: aretana.ietf@gmail.com, rift-chairs@ietf.org, Spencer Dawkins , rift@ietf.org, The IESG References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com> <7983DAAF-E9A8-4FB5-870B-179E130C2EA4@gmail.com> From: Scott Whyte Message-ID: <1eab6277-f427-e555-9bf7-1b3075df5de0@gmail.com> Date: Sun, 21 Jan 2018 15:37:39 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <7983DAAF-E9A8-4FB5-870B-179E130C2EA4@gmail.com> Content-Type: multipart/alternative; boundary="------------523F63B4D79E1A0EA4653E4F" Content-Language: en-US Archived-At: Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT) X-BeenThere: rift@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of Routing in Fat Trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 23:37:45 -0000 This is a multi-part message in MIME format. --------------523F63B4D79E1A0EA4653E4F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/21/18 2:45 PM, Fred Baker wrote: > >> On Jan 21, 2018, at 2:18 PM, Randy Bush wrote: >> >>> (Could you spell out "Clos" on first use? I had to google that) >> uh, his first name was charles, as i remember. > Yes. > https://en.wikipedia.org/wiki/Clos_network > > There is no wikipedia entry for the guy himself, but the first reference in the article is to his May 1953 Bell Systems Technical Journal article, listing Charles Clos as the author. > > I made the mistake of pronouncing the name "close". It rhymes with "loss". Surely he was French? https://www.youtube.com/watch?v=XBjnEaYl0Ho > >> randy >> >> _______________________________________________ >> Rift mailing list >> Rift@ietf.org >> https://www.ietf.org/mailman/listinfo/rift > > > _______________________________________________ > Rift mailing list > Rift@ietf.org > https://www.ietf.org/mailman/listinfo/rift --------------523F63B4D79E1A0EA4653E4F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 1/21/18 2:45 PM, Fred Baker wrote:


On Jan 21, 2018, at 2:18 PM, Randy Bush <randy@psg.com> wrote:


(Could you spell out "Clos" on first use? I had to google that)

uh, his first name was charles, as i remember.

Yes.
https://en.wikipedia.org/wiki/Clos_network

There is no wikipedia entry for the guy himself, but the first reference in the article is to his May 1953 Bell Systems Technical Journal article, listing Charles Clos as the author.

I made the mistake of pronouncing the name "close". It rhymes with "loss".

Surely he was French?
https://www.youtube.com/watch?v=XBjnEaYl0Ho



randy

_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift


      

      

      

      
_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift


    

    

  


--------------523F63B4D79E1A0EA4653E4F--


From nobody Mon Jan 22 06:02:02 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228151252BA; Mon, 22 Jan 2018 06:01:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.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 lr6euO4z5-MG; Mon, 22 Jan 2018 06:01:56 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 676191200E5; Mon, 22 Jan 2018 06:01:56 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0MDxgZw020086; Mon, 22 Jan 2018 06:00:10 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=VMppSUCWACi6zlt7CGKsPV6KH3Hkyre7Zzka5TY33nw=; b=Xjp1hyz9x0yp+cnqL96GCnmJ1/BUiTJVLyuoTnXgnKZUOsAwy3krrX8DCtRYUKHwIR/k JGBTI8IBh5I1CG6z+7teZPME74XZ8ZMB2lfp1n1zzmQIy+YrTv4qLJynLgNbgb7ehNS2 pMnRoB0ipwQHkg8QouL65ay5al0gJszF/s2xY+5rl3zbiF761dRNZRU4S1ODcP7Pi12g kUTizBO29de5d3WiiEA7QA3BfH4BlzaExn02B32/2U1O+OjDgCoOSoInuQV2M4T48Uxf BJiHoZ9aATsGEfa9JtsQht3EEZSefFSYQELQjF4fPprZzrQz9jqERlyktYpAV7fHMwDO gA== 
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0178.outbound.protection.outlook.com [216.32.180.178]) by mx0a-00273201.pphosted.com with ESMTP id 2fnbh9rkew-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 22 Jan 2018 06:00:10 -0800
Received: from DM5PR0501MB3831.namprd05.prod.outlook.com (10.167.108.17) by DM5PR0501MB3814.namprd05.prod.outlook.com (10.167.108.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Mon, 22 Jan 2018 14:00:08 +0000
Received: from DM5PR0501MB3831.namprd05.prod.outlook.com ([fe80::64ad:5405:c8ee:e21]) by DM5PR0501MB3831.namprd05.prod.outlook.com ([fe80::64ad:5405:c8ee:e21%13]) with mapi id 15.20.0444.012; Mon, 22 Jan 2018 14:00:08 +0000
From: John E Drake 
To: Fred Baker , EXT - randy 
CC: "aretana.ietf@gmail.com" , "rift-chairs@ietf.org" , Spencer Dawkins , "rift@ietf.org" , The IESG 
Thread-Topic: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)
Thread-Index: AQHTka0OIFTy8ffpWkSLYzaeu6HIt6N+6BgAgAAHsYCAAP8PEA==
Date: Mon, 22 Jan 2018 14:00:08 +0000
Message-ID: 
References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com>  <7983DAAF-E9A8-4FB5-870B-179E130C2EA4@gmail.com>
In-Reply-To: <7983DAAF-E9A8-4FB5-870B-179E130C2EA4@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR0501MB3814; 7:hDmgvwPwX+RBKbe9pKmIumvmv9vcn5j8SV56jDSK8YT/fs2dsXZ3xeC208xA5W7EY+DCqm6KrdHyI37GuupeaoCYhssWUmkOuAqXfm4rt9Lpq8MQ3QFWMUr5oo7k/O47X1uFJaZM+r2y+6+lwVkr6+jG3HoGOGTg5yIPnVMwJCQ55vNvmaiIXVOPYHQq6sY3sA0d2Y47VlynW30wWdjEzhHPQxiTpq54bTRQmKfBGMap+skGa8CiKP8Xh9hYW2+F
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: e965caff-115e-43f7-1519-08d561a07268
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR0501MB3814; 
x-ms-traffictypediagnostic: DM5PR0501MB3814:
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231046)(2400081)(944501161)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041288)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR0501MB3814; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:DM5PR0501MB3814; 
x-forefront-prvs: 0560A2214D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(346002)(366004)(39860400002)(376002)(13464003)(199004)(189003)(74316002)(305945005)(3660700001)(66066001)(7736002)(76176011)(33656002)(7696005)(6246003)(5250100002)(105586002)(59450400001)(6436002)(2950100002)(55016002)(6506007)(99286004)(106356001)(6306002)(9686003)(229853002)(53546011)(110136005)(230783001)(54906003)(3280700002)(53936002)(26005)(478600001)(5660300001)(2900100001)(102836004)(8936002)(25786009)(966005)(14454004)(6116002)(68736007)(6346003)(3846002)(86362001)(2906002)(97736004)(316002)(4326008)(8676002)(81156014)(39060400002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0501MB3814; H:DM5PR0501MB3831.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: lgz18bbGCTEzuFWHjsg2b14zAgBCUQwqPMZMcvlLfzhUAgX7u6H1D5wCv20dZCeiiXizKzLNTVC+12vqLCyD1g==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: e965caff-115e-43f7-1519-08d561a07268
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2018 14:00:08.4253 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0501MB3814
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-22_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801220200
Archived-At: 
Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 14:01:58 -0000

Hi,

Apparently the 's' is silent:  https://en.wikipedia.org/wiki/Nonblocking_mi=
nimal_spanning_switch

Yours Irrespectively,

John

> -----Original Message-----
> From: Rift [mailto:rift-bounces@ietf.org] On Behalf Of Fred Baker
> Sent: Sunday, January 21, 2018 5:46 PM
> To: EXT - randy 
> Cc: aretana.ietf@gmail.com; rift-chairs@ietf.org; Spencer Dawkins
> ; rift@ietf.org; The IESG 
> Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00=
-04:
> (with COMMENT)
>=20
>=20
>=20
> > On Jan 21, 2018, at 2:18 PM, Randy Bush  wrote:
> >
> >> (Could you spell out "Clos" on first use? I had to google that)
> >
> > uh, his first name was charles, as i remember.
>=20
> Yes.
> https://en.wikipedia.org/wiki/Clos_network
>=20
> There is no wikipedia entry for the guy himself, but the first reference =
in the
> article is to his May 1953 Bell Systems Technical Journal article, listin=
g
> Charles Clos as the author.
>=20
> I made the mistake of pronouncing the name "close". It rhymes with "loss"=
.
>=20
> > randy
> >
> > _______________________________________________
> > Rift mailing list
> > Rift@ietf.org
> > https://www.ietf.org/mailman/listinfo/rift


From nobody Mon Jan 22 06:28:59 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0A1124207; Mon, 22 Jan 2018 06:28:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level: 
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 pOzPDetBjRYP; Mon, 22 Jan 2018 06:28:51 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4FC1200E5; Mon, 22 Jan 2018 06:28:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2518; q=dns/txt; s=iport; t=1516631330; x=1517840930; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mP+hNFLe4re4ywwjC8Untnd4dwZdBCrsbj6BTL20Uqw=; b=mcE5sF34vOsIWlALOolO3OBgJmoCjoqjNaFI/KbxRFqCbzzowHL8vSAY W3iOXMblwplHREZZ8I6+V7LOHkjbo90aiUhbm8h6iTrEMjPkF3fervvOE NM/1cfV39B4Yo4Fsr3gS8udi7pR+3NWbj24hkapx/yi2jqm6gzGLu88Ul w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAgBW9GVa/5hdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNCZnQnB4NWmQeCAokPkEYKGAuFGAIahFZDFAEBAQEBAQEBAWs?= =?us-ascii?q?ohSMBAQEEAQEhEToLDAQCAQgRBAEBAQICIwMCAgIfBgsUAQgIAgQBDQWKGwMVE?= =?us-ascii?q?LYNgieFPoF6DYJoAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4M6ghWDPymDBYJ?= =?us-ascii?q?rRAEBAgGFBTGCNAEEkjGRDD0CiBGIRIUEDZQSjVFDiQYCERkBgTsBNiIygRgGb?= =?us-ascii?q?xU9KgGBf4MJgU54iVOBFwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,396,1511827200"; d="scan'208";a="344423991"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2018 14:28:49 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0MESnSZ006468 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Jan 2018 14:28:49 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 22 Jan 2018 09:28:48 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Mon, 22 Jan 2018 09:28:48 -0500
From: "Acee Lindem (acee)" 
To: John E Drake , Fred Baker ,  EXT - randy 
CC: The IESG , "rift-chairs@ietf.org" , Spencer Dawkins , "rift@ietf.org" , "aretana.ietf@gmail.com" 
Thread-Topic: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)
Thread-Index: AQHTka0PtZpjdHzq1EiDXT+ootfc/KN/O+oAgAAHsICAAP98AP//tC8A
Date: Mon, 22 Jan 2018 14:28:48 +0000
Message-ID: 
References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com>  <7983DAAF-E9A8-4FB5-870B-179E130C2EA4@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <2CD49B65ECB7D2449F7C536C3A8CDCAF@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 14:28:53 -0000

QnV0IGl0IGlzIG9uZSBvZiB0aG9zZSBGcmVuY2ggbmFtZXMgdGhhdCBoYXMgYmVlbiBhbmdsaWNp
emVk4oCmIEF0IGxlYXN0IEnigJl2ZSBuZXZlciBoZWFyZCB0aGVtIGNhbGxlZCBDbG8gbmV0d29y
a3MuIA0KDQpBY2VlIA0KDQpPbiAxLzIyLzE4LCA5OjAyIEFNLCAiUmlmdCBvbiBiZWhhbGYgb2Yg
Sm9obiBFIERyYWtlIiA8cmlmdC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqZHJha2VA
anVuaXBlci5uZXQ+IHdyb3RlOg0KDQogICAgSGksDQogICAgDQogICAgQXBwYXJlbnRseSB0aGUg
J3MnIGlzIHNpbGVudDogIGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL05vbmJsb2NraW5n
X21pbmltYWxfc3Bhbm5pbmdfc3dpdGNoDQogICAgDQogICAgWW91cnMgSXJyZXNwZWN0aXZlbHks
DQogICAgDQogICAgSm9obg0KICAgIA0KICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
CiAgICA+IEZyb206IFJpZnQgW21haWx0bzpyaWZ0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBGcmVkIEJha2VyDQogICAgPiBTZW50OiBTdW5kYXksIEphbnVhcnkgMjEsIDIwMTggNTo0
NiBQTQ0KICAgID4gVG86IEVYVCAtIHJhbmR5IDxyYW5keUBwc2cuY29tPg0KICAgID4gQ2M6IGFy
ZXRhbmEuaWV0ZkBnbWFpbC5jb207IHJpZnQtY2hhaXJzQGlldGYub3JnOyBTcGVuY2VyIERhd2tp
bnMNCiAgICA+IDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT47IHJpZnRAaWV0Zi5vcmc7
IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KICAgID4gU3ViamVjdDogUmU6IFtSaWZ0XSBTcGVu
Y2VyIERhd2tpbnMnIE5vIE9iamVjdGlvbiBvbiBjaGFydGVyLWlldGYtcmlmdC0wMC0wNDoNCiAg
ICA+ICh3aXRoIENPTU1FTlQpDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiA+IE9uIEph
biAyMSwgMjAxOCwgYXQgMjoxOCBQTSwgUmFuZHkgQnVzaCA8cmFuZHlAcHNnLmNvbT4gd3JvdGU6
DQogICAgPiA+DQogICAgPiA+PiAoQ291bGQgeW91IHNwZWxsIG91dCAiQ2xvcyIgb24gZmlyc3Qg
dXNlPyBJIGhhZCB0byBnb29nbGUgdGhhdCkNCiAgICA+ID4NCiAgICA+ID4gdWgsIGhpcyBmaXJz
dCBuYW1lIHdhcyBjaGFybGVzLCBhcyBpIHJlbWVtYmVyLg0KICAgID4gDQogICAgPiBZZXMuDQog
ICAgPiBodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9DbG9zX25ldHdvcmsNCiAgICA+IA0K
ICAgID4gVGhlcmUgaXMgbm8gd2lraXBlZGlhIGVudHJ5IGZvciB0aGUgZ3V5IGhpbXNlbGYsIGJ1
dCB0aGUgZmlyc3QgcmVmZXJlbmNlIGluIHRoZQ0KICAgID4gYXJ0aWNsZSBpcyB0byBoaXMgTWF5
IDE5NTMgQmVsbCBTeXN0ZW1zIFRlY2huaWNhbCBKb3VybmFsIGFydGljbGUsIGxpc3RpbmcNCiAg
ICA+IENoYXJsZXMgQ2xvcyBhcyB0aGUgYXV0aG9yLg0KICAgID4gDQogICAgPiBJIG1hZGUgdGhl
IG1pc3Rha2Ugb2YgcHJvbm91bmNpbmcgdGhlIG5hbWUgImNsb3NlIi4gSXQgcmh5bWVzIHdpdGgg
Imxvc3MiLg0KICAgID4gDQogICAgPiA+IHJhbmR5DQogICAgPiA+DQogICAgPiA+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiA+IFJpZnQgbWFp
bGluZyBsaXN0DQogICAgPiA+IFJpZnRAaWV0Zi5vcmcNCiAgICA+ID4gaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yaWZ0DQogICAgDQogICAgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBSaWZ0IG1haWxpbmcgbGlzdA0KICAg
IFJpZnRAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3JpZnQNCiAgICANCg0K


From nobody Mon Jan 22 07:48:25 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E34A124207; Mon, 22 Jan 2018 07:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 7Il-DYC-t8bh; Mon, 22 Jan 2018 07:48:11 -0800 (PST)
Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 BD165127275; Mon, 22 Jan 2018 07:47:58 -0800 (PST)
Received: by mail-pg0-x243.google.com with SMTP id q67so7373370pga.9; Mon, 22 Jan 2018 07:47:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=FcPcsx6PLIGYguQpWTmUswqVPgpuUH6cgOWFI4597pc=; b=uTTd3hJHR3n8rJ6QytxoLXAshH60kJAfUTS/0XTFE0dSFkukzd0C9RzAPCZruQ/Whc qCnqo2TGKUV4IdVn5xwejDeuyABSlfIzN0QMv/sFBnZxjcntMAqZkhOkeDI04LF2hsB7 +fTK9KZEPwmf1sgP2p+z76BAtXhaXjEJljnrniyEF7tcFZA3yJOTa8hSVznc0baJhb6g +14RQepUVeM5nZ4hKgkfoLdT4hu3fO4hdIRPVVkreFDgq27lFvRJANVs4GjzymGBl54F JWRj6EmnswPGIQnsYkEW0mmrTB8xVo7qKOzWM/5T6gdy0BeOX2SogE8s8N5oBhDRkimB PHsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FcPcsx6PLIGYguQpWTmUswqVPgpuUH6cgOWFI4597pc=; b=Mx6be7mBSLXuAVeWAJ+6FZpi5Pjtkzsm6U9ktrNLGuONmAmp0YXxu6Yp6ntsHFu86w 2ThtqU13MIJC4iwstOcK+6ddH6T0zolDMYxy81D7HEAWQT+sf2zSVjcw7tfr8EaN8J2f CtxNmEuW6UuwTp6zkgtkQiLK4Kcv52QNN0zR2buyobMLqclL/ubj8Qucfmt+FwgY/pfn TixsQpAIfPNA7u1voJ8ZfIXwsTkGGvD5ZiWt/FLFJVi6gSWPEsOJn98V6EP4UjPG6Hdd m8UwP24S7/UTFUQKqWLxpA8wDQY57Y8fsqFlGxygUkCquRBUlK7Y6q+puzpbUKRI5hq2 lKiA==
X-Gm-Message-State: AKwxytcWviU0lnaO53xHgIwwRq3hqdiFra1w6Teh64thQGXEPZ/8Jgm8 IUMhu1RUu+fdfXxS3GTOjZM=
X-Google-Smtp-Source: AH8x227ai9C2t7N59uSSdpufBgjMWXLEyK9b4uItVK8u5/hocXJyvR0zzvwO7KIqQN4BZayM1q9Hug==
X-Received: by 10.99.62.10 with SMTP id l10mr7213704pga.288.1516636078325; Mon, 22 Jan 2018 07:47:58 -0800 (PST)
Received: from iconic.local (173-8-183-214-SFBA.hfc.comcastbusiness.net. [173.8.183.214]) by smtp.gmail.com with ESMTPSA id q24sm16453406pgn.15.2018.01.22.07.47.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 07:47:57 -0800 (PST)
To: "Acee Lindem (acee)" , John E Drake ,  Fred Baker , EXT - randy 
Cc: "aretana.ietf@gmail.com" , "rift-chairs@ietf.org" , The IESG , "rift@ietf.org" , Spencer Dawkins 
References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com>  <7983DAAF-E9A8-4FB5-870B-179E130C2EA4@gmail.com>  
From: Scott Whyte 
Message-ID: <6c468290-3327-f50e-def9-81bc3daab95c@gmail.com>
Date: Mon, 22 Jan 2018 07:47:55 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 15:48:14 -0000

We called them Clo networks within Google netops for at least 10 years

On 1/22/18 6:28 AM, Acee Lindem (acee) wrote:
> But it is one of those French names that has been anglicized… At least I’ve never heard them called Clo networks.
>
> Acee
>
> On 1/22/18, 9:02 AM, "Rift on behalf of John E Drake"  wrote:
>
>      Hi,
>      
>      Apparently the 's' is silent:  https://en.wikipedia.org/wiki/Nonblocking_minimal_spanning_switch
>      
>      Yours Irrespectively,
>      
>      John
>      
>      > -----Original Message-----
>      > From: Rift [mailto:rift-bounces@ietf.org] On Behalf Of Fred Baker
>      > Sent: Sunday, January 21, 2018 5:46 PM
>      > To: EXT - randy 
>      > Cc: aretana.ietf@gmail.com; rift-chairs@ietf.org; Spencer Dawkins
>      > ; rift@ietf.org; The IESG 
>      > Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04:
>      > (with COMMENT)
>      >
>      >
>      >
>      > > On Jan 21, 2018, at 2:18 PM, Randy Bush  wrote:
>      > >
>      > >> (Could you spell out "Clos" on first use? I had to google that)
>      > >
>      > > uh, his first name was charles, as i remember.
>      >
>      > Yes.
>      > https://en.wikipedia.org/wiki/Clos_network
>      >
>      > There is no wikipedia entry for the guy himself, but the first reference in the
>      > article is to his May 1953 Bell Systems Technical Journal article, listing
>      > Charles Clos as the author.
>      >
>      > I made the mistake of pronouncing the name "close". It rhymes with "loss".
>      >
>      > > randy
>      > >
>      > > _______________________________________________
>      > > Rift mailing list
>      > > Rift@ietf.org
>      > > https://www.ietf.org/mailman/listinfo/rift
>      
>      _______________________________________________
>      Rift mailing list
>      Rift@ietf.org
>      https://www.ietf.org/mailman/listinfo/rift
>      
>
> _______________________________________________
> Rift mailing list
> Rift@ietf.org
> https://www.ietf.org/mailman/listinfo/rift


From nobody Mon Jan 22 15:00:12 2018
Return-Path: 
X-Original-To: rift@ietf.org
Delivered-To: rift@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 382F912D848; Mon, 22 Jan 2018 15:00:10 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari 
To: "The IESG" 
Cc: aretana.ietf@gmail.com, rift-chairs@ietf.org, rift@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151666201022.29433.15272334803494567901.idtracker@ietfa.amsl.com>
Date: Mon, 22 Jan 2018 15:00:10 -0800
Archived-At: 
Subject: [Rift] Warren Kumari's No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Jan 2018 23:00:11 -0000

Warren Kumari has entered the following ballot position for
charter-ietf-rift-00-04: No Objection

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



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



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

I'm always concerned when a charter is specifically based on a document:
"The RIFT Working Group is chartered for the following list of items:

 - A Standards Track specification based on draft-przygienda-rift. The document
 will include:"

What happens if, after chartering, the WG discovers a major issue, and/or
decides to rewrite draft-przygienda-rift from scratch? Perhaps it should
instead be something like: "A Standards Track specification addressing the
requirements in draft-przygienda-rift"? Or moving the document itself into
milestones?

Note that this is just a comment; I won't be offended if you choose to ignore
it :-)



From nobody Tue Jan 23 16:18:16 2018
Return-Path: 
X-Original-To: rift@ietf.org
Delivered-To: rift@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6012D12D7F6; Tue, 23 Jan 2018 16:18:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell 
To: "The IESG" 
Cc: aretana.ietf@gmail.com, rift-chairs@ietf.org, rift@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151675309134.24213.4112256117444062434.idtracker@ietfa.amsl.com>
Date: Tue, 23 Jan 2018 16:18:11 -0800
Archived-At: 
Subject: [Rift] Ben Campbell's No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 00:18:11 -0000

Ben Campbell has entered the following ballot position for
charter-ietf-rift-00-04: No Objection

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



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



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

I agree with the comments about basing charter deliverables on specific
documents. Perhaps the proper term should be "consider as input".



From nobody Tue Jan 23 22:23:38 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE19212D871; Tue, 23 Jan 2018 22:23:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ULnwe8qBwO3B; Tue, 23 Jan 2018 22:23:35 -0800 (PST)
Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6E41275C5; Tue, 23 Jan 2018 22:23:34 -0800 (PST)
Received: by mail-yb0-x22f.google.com with SMTP id 65so1145282ybz.6; Tue, 23 Jan 2018 22:23:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FgenasEchLYVUsPXiH59eo1T15Q/Ox+5x4/SU9dy/3s=; b=JNo9UQnUxEBQv8Sxu6oe5NoCnVc/wZ9v3Vls/rHoJxPvrlASvAa+NHlTO6S/TJLTB4 cryksHbVqzPAqVHTd0MMVsIiG+y0JA5LoOU0S7kDEBZ3wXH945+xd1PyryTsna1aUD9X lgNz6UA1CAdW454A/e09X2yb3301/0GAaomgZ6B6gnTWABdiJmNCBjr4/HQ5xJUmOrmP 09eXQiKRiDlc2/gsJR9KbWZ2XLiHWKE85aCbJ9TrC2YLodGTeOdzbR0QH9r2WNXyDFaa Kj5GNhDEzr0ZPwqqUsu7MfLbDpI2Vz+aWq/N6C7IzaX0JQpAKt8IZbIfjXsRHvTfHMUz JU8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FgenasEchLYVUsPXiH59eo1T15Q/Ox+5x4/SU9dy/3s=; b=YjziyQ+BWx7GkDf4m04Ba/uV1qjFzwEq5JpibFWDLeibIJLT1PlH2l9ek97Zx92hTH Y7ieMPOBFcAz8WDivovBWxz+IEY4CMpHVUCEjHSyC7zPLZGQXiJsLlgQE91smnDyGVME cCBu7DEbPNoKJaCt5DNik2pUq+OzJe3rzFDP2arFdfoF8pBb5ms7bDpymWAjwb4sQgQu 9XTdCVXq3XXRJaPaLVdCDEVjbF4UaWQ3SbUTtAeS7xA4r331G8VREk7FtYjixNLDGUNt TWkyJ8kJVD1A1Urxqet69iPmadRLP9Pbck4jM2SfnmP1TSmb6/ojAuI8E53RR/fvFBEt vStw==
X-Gm-Message-State: AKwxytcuUUcqME7Hoy0grK8OjrmSfIbIMq0VnIPoaok8UymvHtJZ/kNk J6zTZFu+1D7SaeGcfnkK07CiPoSsKOxD3rhTBHs=
X-Google-Smtp-Source: AH8x227kim49WZdDiXXsErEgaAEpLaYqm4zYqtcDi3GYBE8t1nipJj1omD0nQawHa90TwRD8hlxOWy0MUh0ZE6iBWAQ=
X-Received: by 10.37.50.194 with SMTP id y185mr4476350yby.417.1516775013781; Tue, 23 Jan 2018 22:23:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.20.4 with HTTP; Tue, 23 Jan 2018 22:23:33 -0800 (PST)
Received: by 10.37.20.4 with HTTP; Tue, 23 Jan 2018 22:23:33 -0800 (PST)
In-Reply-To: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com>
References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com>
From: Spencer Dawkins at IETF 
Date: Wed, 24 Jan 2018 00:23:33 -0600
Message-ID: 
To: IESG 
Cc: rift-chairs@ietf.org, rift@ietf.org, aretana.ietf@gmail.com
Content-Type: multipart/alternative; boundary="001a1146cb44e695ce05637fb3e8"
Archived-At: 
Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 06:23:37 -0000

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

My apologies for getting the addressees wrong on my first follow-up - this
is a resend.

But just following up ...


On Jan 19, 2018 23:10, "Spencer Dawkins" 
wrote:

Spencer Dawkins has entered the following ballot position for
charter-ietf-rift-00-04: No Objection

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



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



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

I THINK I'm happy to see this work go forward, but I am almost sufficiently
confused by the current charter to say "not ready for external review yet".
Should be easy to fix, though, so not Blocking.

(Could you spell out "Clos" on first use? I had to google that)


Thanks for catching me up on Charles Clos. Beyond that ...


It seemed to me that at least some of the discussion in DCROUTING BOF
described
some of the reasons why "routing in data centers is different". It would be
helpful to me, if there was a mention of at least one or two differences
that
make new protocol work necessary or desirable. I mean, like, one sentence.
It's
possible to reverse-engineer that out of the bulleted list a bit further
down,
but that's kind of new-participant-hostile.


Did that make sense? It seemed useful to me, to help new participants
understand why this work is necessary.

I'll plead guilty to reading "data centers are special" and no details, and
hearing the echos of 20 years of "wireless is special" and no details in
various TSV working groups and BOFs, but ...

The description of the protocol that the working group would deliver is
tied to
the deliverable based on draft-przygienda-rift, is that right? I had to
look at
the table of contents for draft-przygienda-rift to figure that out - and
even
then, I'm not sure.


I'd really like to see this laced together more tightly. It didn't seem
reasonable to me, to send someone off to the data tracker, to read the
table of contents in draft-przygienda-rift and figure out that it is the
basis for the proposed working group's major deliverable, when making that
clear in the charter looked like a two-word addition.

Any thoughts about that?

Spencer

Perhaps

 - A Standards Track **routing protocol** specification based on
 draft-przygienda-rift. The document will include:
   - an Implementation Status section as described in RFC 7942
   - an Operational Considerations section to explain how the protocol is
   configured, deployed, and diagnosed - Security and Privacy
Considerations,
   although this material may refer to a separate Threat Analysis document
   (q.v.)

?

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


My apologies for getting the addressees wrong on my =
first follow-up - this is a resend.

But just following up ...


On Jan 19, 2018 23:10, "Spencer Dawki=
ns" <spencerdawkins.ietf@gmail.com<=
/a>> wrote:
Spencer Dawkins has ente=
red the following ballot position for
charter-ietf-rift-00-04: No Object=
ion

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



The document, alo=
ng with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-iet=
f-rift/



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

I THINK I'=
m happy to see this work go forward, but I am almost sufficiently
confus=
ed by the current charter to say "not ready for external review yet&qu=
ot;.
Should be easy to fix, though, so not Blocking.

(Could you s=
pell out "Clos" on first use? I had to google that)

Thanks for catching me up on Charles Clos. Beyond th=
at ...


It seemed to me that a=
t least some of the discussion in DCROUTING BOF described
some of the re=
asons why "routing in data centers is different". It would be
=
helpful to me, if there was a mention of at least one or two differences th=
at
make new protocol work necessary or desirable. I mean, like, one sent=
ence. It's
possible to reverse-engineer that out of the bulleted lis=
t a bit further down,
but that's kind of new-participant-hostile.

Did that make s=
ense? It seemed useful to me, to help new participants understand why this =
work is necessary.

I'll plead guilty to reading "data centers are=
 special" and no details, and hearing the echos of 20 years of "w=
ireless is special" and no details in various TSV working groups and B=
OFs, but ...

=

The description of t=
he protocol that the working group would deliver is tied to
the delivera=
ble based on draft-przygienda-rift, is that right? I had to look at
the =
table of contents for draft-przygienda-rift to figure that out - and eventhen, I'm not sure.

I'd really like to see this laced together more tightly. It=
 didn't seem reasonable to me, to send someone off to the data tracker,=
 to read the table of contents in=C2=A0draft-przygienda-rift and figure out=
 that it is the basis for the proposed working group's major deliverabl=
e, when making that clear in the charter looked like a two-word addition.
=
Any thoughts about that?

=
Spencer

Perhaps

=C2=
=A0- A Standards Track **routing protocol** specification based on
=C2=
=A0draft-przygienda-rift. The document will include:
=C2=A0 =C2=A0- an I=
mplementation Status section as described in RFC 7942
=C2=A0 =C2=A0- an =
Operational Considerations section to explain how the protocol is
=C2=A0=
 =C2=A0configured, deployed, and diagnosed - Security and Privacy Considera=
tions,
=C2=A0 =C2=A0although this material may refer to a separate Threa=
t Analysis document
=C2=A0 =C2=A0(q.v.)

?



--001a1146cb44e695ce05637fb3e8--


From nobody Tue Jan 23 23:12:48 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F53B12D961; Tue, 23 Jan 2018 23:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 hc8z_aastZ4J; Tue, 23 Jan 2018 23:12:38 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4952212D847; Tue, 23 Jan 2018 23:12:38 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id t74so6379767wme.3; Tue, 23 Jan 2018 23:12:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fo7rvVvNRrbvCMUIzB9OVupgL9whM/st20xLd2V9NY8=; b=bIpSQR5Jvtx3Z2x2iGlAK3Wyy4Eoah+CkgI4Ry7dvfkaWhJDehHKip3G6xU4Y9R+4F QsLT8gXo9+4Gbh/3JhmuOWeOCycnXeYaxVbiMVJQXB61nP7z65J/MMlvNAJHS9HrPII1 b1+ZiMhoZaTiKAzAA/FATXwcT8q/2wsjyqoyjLpXdlOXa/mTBv0hERvzrer5oMhw+sw8 auBFsnqDKPyUzRDnbv0q5yKoAmYy22Ne2vqbybJtRBjLudLWSxMScBvXiX0jYk5d68k6 Y7JJKDF6LqcfmayP0WeBbXt67Stp8PJ1XbohQfooT3KZI0jZB/7khzkcE/eSVOK8fDog wU/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fo7rvVvNRrbvCMUIzB9OVupgL9whM/st20xLd2V9NY8=; b=VTsatT8QnG1EZFggzI9lGRdaEANtleY7TN7S0sHNEgkkXWhs1sRiGpRE/E7XkH/KID LClq1l9IYHF7E3TB/LXRnTPnE+OAEMwvBo1PLBvO9SGkwTBOr4bbkQ/oQcHEWdnpI1nG hZGO3jq5eD5bQjt4eMC7rf5jkIoixMaabea43mRN4AKLPomdssyYsBZvO7ww3sdv70XD OUNO8M7sKoHLku2l8MhhVhIl3zye4Bg5MgDwiEEFpJhGCV7VM2urlH4p9kZQBCMEfhpf K1QmzMJSkbyVNvew5h75698mKlk8xsX+YLKAzeoYlBSZN5IGLzz33jCoqU5y3m7JWcao TYhg==
X-Gm-Message-State: AKwxytfkzETE7HwSgsKNYojF3fWd0FafDJPofeCzr6aHiP93iobsfYLH f0VTtjYIwIzk9WPl/vqrM5QWC0jIaqRH0If6wCg=
X-Google-Smtp-Source: AH8x225wjrV65WpCHxONJnytAyA3mUhPeiHjbWZ/18t8EsZs+H/Y04GKGMwdsf5clyPmi+70huWrRuOkKyJLO16Yr1Y=
X-Received: by 10.80.148.217 with SMTP id t25mr23210396eda.121.1516777956716;  Tue, 23 Jan 2018 23:12:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.182.239 with HTTP; Tue, 23 Jan 2018 23:11:56 -0800 (PST)
In-Reply-To: 
References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com> 
From: Tony Przygienda 
Date: Tue, 23 Jan 2018 23:11:56 -0800
Message-ID: 
To: Spencer Dawkins at IETF 
Cc: IESG , rift-chairs@ietf.org, rift@ietf.org,  Alvaro Retana 
Content-Type: multipart/alternative; boundary="f403045c23165036ff0563806318"
Archived-At: 
Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 07:12:42 -0000

--f403045c23165036ff0563806318
Content-Type: text/plain; charset="UTF-8"

Spencer, thanks for comments.

>From my side as  input: I think the RIFT draft REQ section is written very
tightly and has been  summarized in the charter  (in a somewhat overly
terse form possibly). Providing a full explanation of Clos and what
happened in DC routing is probably outside the scope here on the other hand
... Moreover, I do obviously think that IP Clos fabrics are special (and
given the scale/pervasiveness of those now we reached a point where a
solution that allows their operation at as close to 0 OPEX as possible is
desirable to many organizations). I consider RIFT as strawman (albeit there
is significantly more than straw there ;-) proposal for such a solution
while I look forward to the group welcoming further discussions on the
topic. And yes, we can and do extend some existing protocols to meet few of
the suggested goals (and that work is obviously going on) but to achieve
for IP clos (optionally and ideally extending all the way to the servers)
what traditional routing achieved for generic networks the thinking leads
to new paradigms.

And is wireless special? Having looked @ BABEL and its behavior and having
spent lots time with the creator I do think so (in terms of routing
perspective). As is industrial automation RPL is targeting. We can consider
ourselves as a body offering every car as long it's a Ford T with one of
the extensions but we can also think of IETF in 21st century (in routing
perspective) as opening towards different verticals needing specialized
solutions. An analogy would be the database industry where not every
solution is a SQL server or storage where we are not forced to put
everything on harddisks ... Random musings a bit ...

Do please suggest otherwise the 2-3 words you think would improve the
charter's readability

thanks again

--- tony

On Tue, Jan 23, 2018 at 10:23 PM, Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> My apologies for getting the addressees wrong on my first follow-up - this
> is a resend.
>
> But just following up ...
>
>
> On Jan 19, 2018 23:10, "Spencer Dawkins" 
> wrote:
>
> Spencer Dawkins has entered the following ballot position for
> charter-ietf-rift-00-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-rift/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I THINK I'm happy to see this work go forward, but I am almost sufficiently
> confused by the current charter to say "not ready for external review yet".
> Should be easy to fix, though, so not Blocking.
>
> (Could you spell out "Clos" on first use? I had to google that)
>
>
> Thanks for catching me up on Charles Clos. Beyond that ...
>
>
> It seemed to me that at least some of the discussion in DCROUTING BOF
> described
> some of the reasons why "routing in data centers is different". It would be
> helpful to me, if there was a mention of at least one or two differences
> that
> make new protocol work necessary or desirable. I mean, like, one sentence.
> It's
> possible to reverse-engineer that out of the bulleted list a bit further
> down,
> but that's kind of new-participant-hostile.
>
>
> Did that make sense? It seemed useful to me, to help new participants
> understand why this work is necessary.
>
> I'll plead guilty to reading "data centers are special" and no details,
> and hearing the echos of 20 years of "wireless is special" and no details
> in various TSV working groups and BOFs, but ...
>
> The description of the protocol that the working group would deliver is
> tied to
> the deliverable based on draft-przygienda-rift, is that right? I had to
> look at
> the table of contents for draft-przygienda-rift to figure that out - and
> even
> then, I'm not sure.
>
>
> I'd really like to see this laced together more tightly. It didn't seem
> reasonable to me, to send someone off to the data tracker, to read the
> table of contents in draft-przygienda-rift and figure out that it is the
> basis for the proposed working group's major deliverable, when making that
> clear in the charter looked like a two-word addition.
>
> Any thoughts about that?
>
> Spencer
>
> Perhaps
>
>  - A Standards Track **routing protocol** specification based on
>  draft-przygienda-rift. The document will include:
>    - an Implementation Status section as described in RFC 7942
>    - an Operational Considerations section to explain how the protocol is
>    configured, deployed, and diagnosed - Security and Privacy
> Considerations,
>    although this material may refer to a separate Threat Analysis document
>    (q.v.)
>
> ?
>
>
> _______________________________________________
> Rift mailing list
> Rift@ietf.org
> https://www.ietf.org/mailman/listinfo/rift
>
>

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


Spencer, thanks for comments. 

From=
 my side as=C2=A0 input: I think the RIFT draft REQ section is written very=
 tightly and has been=C2=A0 summarized in the charter=C2=A0 (in a somewhat =
overly terse form possibly). Providing a full explanation of Clos and what =
happened in DC routing is probably outside the scope here on the other hand=
 ... Moreover, I do obviously think that IP Clos fabrics are special (and g=
iven the scale/pervasiveness of those now we reached a point where a soluti=
on that allows their operation at as close to 0 OPEX as possible is desirab=
le to many organizations). I consider RIFT as strawman (albeit there is sig=
nificantly more than straw there ;-) proposal for such a solution while I l=
ook forward to the group welcoming further discussions on the topic. And ye=
s, we can and do extend some existing protocols to meet few of the suggeste=
d goals (and that work is obviously going on) but to achieve for IP clos (o=
ptionally and ideally extending all the way to the servers) what traditiona=
l routing achieved for generic networks the thinking leads to new paradigms=
. 

And is wireless special? Having looked @ BA=
BEL and its behavior and having spent lots time with the creator I do think=
 so (in terms of routing perspective). As is industrial automation RPL is t=
argeting. We can consider ourselves as a body offering every car as long it=
's a Ford T with one of the extensions but we can also think of IETF in=
 21st century (in routing perspective) as opening towards different vertica=
ls needing specialized solutions. An analogy would be the database industry=
 where not every solution is a SQL server or storage where we are not force=
d to put everything on harddisks ... Random musings a bit ... 

Do please suggest otherwise the 2-3 words you think would =
improve the charter's readability 

thanks =
again

--- tony 

On Thu, Jan 18, 2018 at 2:08 PM, R=
andy Bush <randy@psg.com> wrote:
Clos and Routing Under Fat Trees




_______________________________________________

Rift mailing list

Rift@ietf.org

https://www.ietf.org/mailman/listinfo/rift



On Tue, Jan 23, 2018 at 10:23 PM, Spencer Dawki=
ns at IETF <spencerdawkins.ietf@gmail.com> wrote=
:
My apologies for=
 getting the addressees wrong on my first follow-up - this is a resend.
=


But just following up ..=
.


On Jan 19, 2018 23:10, "Spencer Dawkin=
s" <spencerdawkin=
s.ietf@gmail.com> wrote:
Spencer=
 Dawkins has entered the following ballot position for
charter-ietf-rift=
-00-04: No Objection

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



=
The document, along with other ballot positions, can be found here:
https://datatr=
acker.ietf.org/doc/charter-ietf-rift/



-------------=
---------------------------------------------------------
COMM=
ENT:
----------------------------------------------------------------------

I THINK I'm happy to see this work go forward, but=
 I am almost sufficiently
confused by the current charter to say "n=
ot ready for external review yet".
Should be easy to fix, though, s=
o not Blocking.

(Could you spell out "Clos" on first use? =
I had to google that)

Thanks for=
 catching me up on Charles Clos. Beyond that ...


It seemed to me t=
hat at least some of the discussion in DCROUTING BOF described
some of t=
he reasons why "routing in data centers is different". It would b=
e
helpful to me, if there was a mention of at least one or two differenc=
es that
make new protocol work necessary or desirable. I mean, like, one=
 sentence. It's
possible to reverse-engineer that out of the bullete=
d list a bit further down,
but that's kind of new-participant-hostil=
e.

Did =
that make sense? It seemed useful to me, to help new participants understan=
d why this work is necessary.

I'll plead guilty to reading "data =
centers are special" and no details, and hearing the echos of 20 years=
 of "wireless is special" and no details in various TSV working g=
roups and BOFs, but ...

<=
/div>
The description of the protocol that the worki=
ng group would deliver is tied to
the deliverable based on draft-przygie=
nda-rift, is that right? I had to look at
the table of contents for draf=
t-przygienda-rift to figure that out - and even
then, I'm not sure.<=
br>

=

I'd=
 really like to see this laced together more tightly. It didn't seem re=
asonable to me, to send someone off to the data tracker, to read the table =
of contents in=C2=A0draft-przygienda-rift and figure out that it is the bas=
is for the proposed working group's major deliverable, when making that=
 clear in the charter looked like a two-word addition.

Any thoughts about =
that?
=

Spencer

Perhaps
=C2=A0- A Standards Track **routing protocol** specification based on=

=C2=A0draft-przygienda-rift. The document will include:
=C2=A0 =C2=
=A0- an Implementation Status section as described in RFC 7942
=C2=A0 =
=C2=A0- an Operational Considerations section to explain how the protocol i=
s
=C2=A0 =C2=A0configured, deployed, and diagnosed - Security and Privac=
y Considerations,
=C2=A0 =C2=A0although this material may refer to a sep=
arate Threat Analysis document
=C2=A0 =C2=A0(q.v.)

?



_______________________________________________

Rift mailing list

Rift@ietf.org

https://www.ietf.org/mailman/listinfo/rift





--f403045c23165036ff0563806318--


From nobody Wed Jan 24 02:30:56 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3259612D96D for ; Wed, 24 Jan 2018 02:30:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4HiaLOQcX2Bb for ; Wed, 24 Jan 2018 02:30:53 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7F612DA0D for ; Wed, 24 Jan 2018 02:30:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5265; q=dns/txt; s=iport; t=1516789852; x=1517999452; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=wXfavD2iiMMe53xnks59OheEZRdOS/RPYgrZ3FK64BY=; b=U9I7NI1TnjsNs0z3etfwRSr43Z2YOH+sxkE3ZAhmr5EFC/NMc4StqwpS effUeQ8dcPCCG3VRmejc58qNPIz+CJZXM/XYvJhDT7ey8KQr+YzAB2ClD aGWbrE69n8aI/Z3tCshkZMdRguWhBIjO/o4K76SaatgrJvtiE0AbJiUuN c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQDjX2ha/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodCeDXYsYj3aJD4hbh2sKGAEKhRgChVMUAQEBAQEBAQECayi?= =?us-ascii?q?FIwEBAQMBAQEhSwsQCxgnAwICIQYfEQYBDAYCAQGKGQMNCBCzMIInJoccDYMFA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWES4NsgWgpgwWCa0QBAQKFBoJlBZI3kRI?= =?us-ascii?q?9kFuFBowrh3mOHoEliBOBPDYigVAzGggbFT2CKoRXQTeOIAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,406,1511827200"; d="scan'208,217";a="1623133"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 10:30:50 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0OAUoYl003680; Wed, 24 Jan 2018 10:30:50 GMT
To: Tony Przygienda , A S 
Cc: rift@ietf.org
References:   
From: Robert Wilton 
Message-ID: <3b2b6dce-cebc-243e-63ea-3a561a1585ea@cisco.com>
Date: Wed, 24 Jan 2018 10:30:50 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------7AB4C33DAB2E463F330B7A83"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rift] Internal Review of the rift Charter
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 10:30:55 -0000

This is a multi-part message in MIME format.
--------------7AB4C33DAB2E463F330B7A83
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Tony,

On 19/01/2018 02:30, Tony Przygienda wrote:
> funny one ;-)   If that persists, I may to have to change my name to 
> Zaphod or something ;-)
>
> BTW, talking about first possible WG meet @ 101 (no, it's NOT the 
> highway in SV in case we have FUD in this case as well ;-), what would 
> people like from me if I get a preso slot? Some more in-detail 
> walk-through of some section/concept in the RIFT draft? List of what I 
> think people can grab on the main draft to contribute/flesh out? 
> Otherwise charter has things enough to camp on ...
I would suggest a list of things that you think are effectively done 
(from your POV), and a separate list of areas that you still think need 
further discussion/work.

Thanks,
Rob

>
> Before 101 I see another version rev'ed with some subtle ZTP updates 
> due to feedback I got. And there's another one larg'ish addition being 
> thought through but that's being chewed right now by the core folks 
> and not ready for wider look yet. Most likely after 101 ...
>
> thanks
>
> --- tony
>
> On Thu, Jan 18, 2018 at 5:45 PM, A S  > wrote:
>
>     Got a unicast that Tony here is multicast address. To clarify, I
>     meant Tony P.
>
>
>
>
>
>
> _______________________________________________
> Rift mailing list
> Rift@ietf.org
> https://www.ietf.org/mailman/listinfo/rift


--------------7AB4C33DAB2E463F330B7A83
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Tony,

    

    
On 19/01/2018 02:30, Tony Przygienda
      wrote:

    

    

      
      

        

          
funny one ;-)   If that persists, I may to have to change
            my name to Zaphod or something ;-) 

            

          

          BTW, talking about first possible WG meet @ 101 (no, it's NOT
          the highway in SV in case we have FUD in this case as well
          ;-), what would people like from me if I get a preso slot?
          Some more in-detail walk-through of some section/concept in
          the RIFT draft? List of what I think people can grab on the
          main draft to contribute/flesh out? Otherwise charter has
          things enough to camp on ... 

        

      

    

    I would suggest a list of things that you think are effectively done
    (from your POV), and a separate list of areas that you still think
    need further discussion/work.

    

    Thanks,

    Rob

    

    

      

        


        

        
Before 101 I see another version rev'ed with some subtle
          ZTP updates due to feedback I got. And there's another one
          larg'ish addition being thought through but that's being
          chewed right now by the core folks and not ready for wider
          look yet. Most likely after 101 ... 

        

        


        

        
thanks

        

        


        

        --- tony  

        


          
On Thu, Jan 18, 2018 at 5:45 PM, A S
            <as3957@gmail.com>
            wrote:

            

              
Got a unicast that Tony here is multicast
                address. To clarify, I meant Tony P.
                

                  


                    

                      

                        


                        

                      

                    

                  

                

              

              

            

          

          

        

      

      

      

      

      
_______________________________________________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift


    

    

  


--------------7AB4C33DAB2E463F330B7A83--


From nobody Wed Jan 24 06:28:01 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D842A124C27; Wed, 24 Jan 2018 06:28:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 JI1UjrjvjyzU; Wed, 24 Jan 2018 06:27:58 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3EA312422F; Wed, 24 Jan 2018 06:27:57 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id m19so1533937ywh.12; Wed, 24 Jan 2018 06:27:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OxAmwsqHWl32xAJCLVqPEjzXwHgvgrM9MfEJAe/CHA0=; b=gMmQdKB0ZuaoC5nwXpVOvLyfzBZGbAV1w1o4Nndj2Ue1KGVvbvL/VmAFtmbT+hFDxO IIAoF7io7D+LmDRurZPP/AIp3xlTT221F/y1/YA2OcCL9nRAFFLexLPNYYceDk+h3cO1 F2NGh1bwx2R7pBU58G3aFn/bF5XXYkNMc1QDZfk/WGmwBObs4uMO0/mHNkydETfyjZ/H Wg7u2POJ7XDgi/rt2V+JImy6rq1PjWzlR0EuEIsCJvCL921WnKIsCDWNemjRn/YBHoEw 9mzwnb/+087IHt6YMqgyzs25kAMaJhr5AchhP6J4CRk/3kh9MSfbqlb24j8XWOi3QpZy nWDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OxAmwsqHWl32xAJCLVqPEjzXwHgvgrM9MfEJAe/CHA0=; b=qJbruZTusEcO1ppGbbMTnDeKx1AhiKgfw21U2ZIg2aIl0prYxDUhwHcvLqkMykgvFR RkgFERP5PEnGLCV6Lx+sFkYKxU2vzfuYyjvF9upUI7wrbtdM2jUsrhH6DmKUGz7v4cFJ yhoVAzlgJg0CO5h7ri8g6l/Qt7Rv6XcnP5L2Wdp9pGaiIfXg17bciq5TUmtmwWqFomid KHldvdWSCfQBaYpR/GLkSDfp2VX70kYmwqcdNeACEs+sNZvvkEFXisECEp3mqr3AWu9F u3LqIktVvwQhxUTpnAwk9YuYP6O26vH/1yLA9fvXEXeYPwrY86JJPufRe0dNuOmFJ6rA dgMA==
X-Gm-Message-State: AKwxytfMx6uCMn0CZFdVEOvsdBbvnNYCUCBXC9zmjO4UvK3m7BhHYUSI HtIPDXo27h0ssHiLp+QogbvtOewZKNk2KE3PkKM=
X-Google-Smtp-Source: AH8x2241pYZLx9hTzb7AABbgKqmoNYhlVXKg3R0uyeZsRUL1tY6m6GWgpBfCbNdkFz+AlQBAsvq3mhOMv2zOPsndPqw=
X-Received: by 10.129.78.14 with SMTP id c14mr5396808ywb.109.1516804076569; Wed, 24 Jan 2018 06:27:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.20.4 with HTTP; Wed, 24 Jan 2018 06:27:56 -0800 (PST)
In-Reply-To: 
References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com>  
From: Spencer Dawkins at IETF 
Date: Wed, 24 Jan 2018 08:27:56 -0600
Message-ID: 
To: Tony Przygienda 
Cc: IESG , rift-chairs@ietf.org, rift@ietf.org,  Alvaro Retana 
Content-Type: multipart/alternative; boundary="001a114d7d3e2d8b0a05638678ad"
Archived-At: 
Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 14:28:01 -0000

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

Hi, Tony,

On Wed, Jan 24, 2018 at 1:11 AM, Tony Przygienda 
wrote:

> Spencer, thanks for comments.
>
> From my side as  input: I think the RIFT draft REQ section is written very
> tightly and has been  summarized in the charter  (in a somewhat overly
> terse form possibly). Providing a full explanation of Clos and what
> happened in DC routing is probably outside the scope here
>

Right. Agreed. I needed a pointer, and I got one.


> on the other hand ... Moreover, I do obviously think that IP Clos fabrics
> are special
>

Right. What I'm asking, is WHY. And, specifically, what is at least one
problem with using unmodified existing routing protocols in data centers,
that RIFT will fix?

Sorry if that wasn't clear.


> (and given the scale/pervasiveness of those now we reached a point where a
> solution that allows their operation at as close to 0 OPEX as possible is
> desirable to many organizations). I consider RIFT as strawman (albeit there
> is significantly more than straw there ;-) proposal for such a solution
> while I look forward to the group welcoming further discussions on the
> topic. And yes, we can and do extend some existing protocols to meet few of
> the suggested goals (and that work is obviously going on) but to achieve
> for IP clos (optionally and ideally extending all the way to the servers)
> what traditional routing achieved for generic networks the thinking leads
> to new paradigms.
>
> And is wireless special?
>

Sure. As above, there are things we did in transport protocols to
accommodate wireless, but we were working on specific problems ("high error
rate" got you UDP-lite, that only did checksum coverage of the UDP header,
for example). We had plenty of proposals based on hand-waving about
"wireless is special" that we didn't move forward, because that wasn't
engineering.


> Having looked @ BABEL and its behavior and having spent lots time with the
> creator I do think so (in terms of routing perspective). As is industrial
> automation RPL is targeting. We can consider ourselves as a body offering
> every car as long it's a Ford T with one of the extensions but we can also
> think of IETF in 21st century (in routing perspective) as opening towards
> different verticals needing specialized solutions. An analogy would be the
> database industry where not every solution is a SQL server or storage where
> we are not forced to put everything on harddisks ... Random musings a bit
> ...
>
> Do please suggest otherwise the 2-3 words you think would improve the
> charter's readability
>
> thanks again
>
> --- tony
>
> On Tue, Jan 23, 2018 at 10:23 PM, Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> wrote:
>
>> My apologies for getting the addressees wrong on my first follow-up -
>> this is a resend.
>>
>> But just following up ...
>>
>>
>> On Jan 19, 2018 23:10, "Spencer Dawkins" 
>> wrote:
>>
>> Spencer Dawkins has entered the following ballot position for
>> charter-ietf-rift-00-04: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/charter-ietf-rift/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I THINK I'm happy to see this work go forward, but I am almost
>> sufficiently
>> confused by the current charter to say "not ready for external review
>> yet".
>> Should be easy to fix, though, so not Blocking.
>>
>> (Could you spell out "Clos" on first use? I had to google that)
>>
>>
>> Thanks for catching me up on Charles Clos. Beyond that ...
>>
>>
>> It seemed to me that at least some of the discussion in DCROUTING BOF
>> described
>> some of the reasons why "routing in data centers is different". It would
>> be
>> helpful to me, if there was a mention of at least one or two differences
>> that
>> make new protocol work necessary or desirable. I mean, like, one
>> sentence. It's
>> possible to reverse-engineer that out of the bulleted list a bit further
>> down,
>> but that's kind of new-participant-hostile.
>>
>>
>> Did that make sense? It seemed useful to me, to help new participants
>> understand why this work is necessary.
>>
>> I'll plead guilty to reading "data centers are special" and no details,
>> and hearing the echos of 20 years of "wireless is special" and no details
>> in various TSV working groups and BOFs, but ...
>>
>> The description of the protocol that the working group would deliver is
>> tied to
>> the deliverable based on draft-przygienda-rift, is that right? I had to
>> look at
>> the table of contents for draft-przygienda-rift to figure that out - and
>> even
>> then, I'm not sure.
>>
>>
>> I'd really like to see this laced together more tightly. It didn't seem
>> reasonable to me, to send someone off to the data tracker, to read the
>> table of contents in draft-przygienda-rift and figure out that it is the
>> basis for the proposed working group's major deliverable, when making that
>> clear in the charter looked like a two-word addition.
>>
>> Any thoughts about that?
>>
>> Spencer
>>
>> Perhaps
>>
>>  - A Standards Track **routing protocol** specification based on
>>  draft-przygienda-rift. The document will include:
>>    - an Implementation Status section as described in RFC 7942
>>    - an Operational Considerations section to explain how the protocol is
>>    configured, deployed, and diagnosed - Security and Privacy
>> Considerations,
>>    although this material may refer to a separate Threat Analysis document
>>    (q.v.)
>>
>> ?
>>
>>
>> _______________________________________________
>> Rift mailing list
>> Rift@ietf.org
>> https://www.ietf.org/mailman/listinfo/rift
>>
>>
>

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


Hi, Tony,

On Wed, Jan 24, 2018 at 1:11 AM, Tony Przygienda <tonysietf@gma=
il.com> wrote:
Spencer, thanks for comments. 

From my side as=
=C2=A0 input: I think the RIFT draft REQ section is written very tightly an=
d has been=C2=A0 summarized in the charter=C2=A0 (in a somewhat overly ters=
e form possibly). Providing a full explanation of Clos and what happened in=
 DC routing is probably outside the scope here 

Right. Agreed. I needed a pointer, and I got one.
=C2=A0
on the o=
ther hand ... Moreover, I do obviously think that IP Clos fabrics are speci=
al 

Right. What I'm asking,=
 is WHY. And, specifically, what is at least one problem with using unmodif=
ied existing routing protocols in data centers, that RIFT will fix?=C2=A0

Sorry if that wasn't clear.
=C2=A0
(and given the scal=
e/pervasiveness of those now we reached a point where a solution that allow=
s their operation at as close to 0 OPEX as possible is desirable to many or=
ganizations). I consider RIFT as strawman (albeit there is significantly mo=
re than straw there ;-) proposal for such a solution while I look forward t=
o the group welcoming further discussions on the topic. And yes, we can and=
 do extend some existing protocols to meet few of the suggested goals (and =
that work is obviously going on) but to achieve for IP clos (optionally and=
 ideally extending all the way to the servers) what traditional routing ach=
ieved for generic networks the thinking leads to new paradigms. 
<=
div>
And is wireless special? 
<=
br>
Sure. As above, there are things we did in transport protocol=
s to accommodate wireless, but we were working on specific problems ("=
high error rate" got you UDP-lite, that only did checksum coverage of =
the UDP header, for example). We had plenty of proposals based on hand-wavi=
ng about "wireless is special" that we didn't move forward, b=
ecause that wasn't engineering.=C2=A0
=C2=A0
Having looked @ BABEL and its beh=
avior and having spent lots time with the creator I do think so (in terms o=
f routing perspective). As is industrial automation RPL is targeting. We ca=
n consider ourselves as a body offering every car as long it's a Ford T=
 with one of the extensions but we can also think of IETF in 21st century (=
in routing perspective) as opening towards different verticals needing spec=
ialized solutions. An analogy would be the database industry where not ever=
y solution is a SQL server or storage where we are not forced to put everyt=
hing on harddisks ... Random musings a bit ... 

Do please suggest otherwise the 2-3 words you think would improve the cha=
rter's readability 

thanks again

--- tony 

<=
div>
On Tue, Jan 23, 2018 at 10:23 PM, Spencer Dawkins at =
IETF <spencerdawkins.ietf@gmail.com> wrote:=

My apologies for getting the addressees wrong on my first=
 follow-up - this is a resend.

But just following up ...


On Jan 19, 2018 23:10, "Spencer Dawkins" <spencerdawkins.ietf@gmail.com> =
wrote:
Spencer Dawkins has entered the follo=
wing ballot position for
charter-ietf-rift-00-04: No Objection

Wh=
en responding, please keep the subject line intact and reply to all
emai=
l addresses included in the To and CC lines. (Feel free to cut this
intr=
oductory paragraph, however.)



The document, along with other=
 ballot positions, can be found here:
https://datatracker.ietf.org/doc/charte=
r-ietf-rift/



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

I THINK I=
'm happy to see this work go forward, but I am almost sufficiently
c=
onfused by the current charter to say "not ready for external review y=
et".
Should be easy to fix, though, so not Blocking.

(Could =
you spell out "Clos" on first use? I had to google that)

Thanks for catching me up on Charles Clo=
s. Beyond that ...


It seemed to me that at least some o=
f the discussion in DCROUTING BOF described
some of the reasons why &quo=
t;routing in data centers is different". It would be
helpful to me,=
 if there was a mention of at least one or two differences that
make new=
 protocol work necessary or desirable. I mean, like, one sentence. It's=

possible to reverse-engineer that out of the bulleted list a bit furthe=
r down,
but that's kind of new-participant-hostile.
=


Did that make sense? It=
 seemed useful to me, to help new participants understand why this work is =
necessary.

I'll plead guilty to reading "data centers are special=
" and no details, and hearing the echos of 20 years of "wireless =
is special" and no details in various TSV working groups and BOFs, but=
 ...

The description of the protocol that the working group=
 would deliver is tied to
the deliverable based on draft-przygienda-rift=
, is that right? I had to look at
the table of contents for draft-przygi=
enda-rift to figure that out - and even
then, I'm not sure.

I'd really =
like to see this laced together more tightly. It didn't seem reasonable=
 to me, to send someone off to the data tracker, to read the table of conte=
nts in=C2=A0draft-przygienda-rift and figure out that it is the basis for t=
he proposed working group's major deliverable, when making that clear i=
n the charter looked like a two-word addition.

Any thoughts about that?
Spencer

Perhaps

=C2=A0- A Standards Track **routing protocol** =
specification based on
=C2=A0draft-przygienda-rift. The document will in=
clude:
=C2=A0 =C2=A0- an Implementation Status section as described in R=
FC 7942
=C2=A0 =C2=A0- an Operational Considerations section to explain =
how the protocol is
=C2=A0 =C2=A0configured, deployed, and diagnosed - S=
ecurity and Privacy Considerations,
=C2=A0 =C2=A0although this material =
may refer to a separate Threat Analysis document
=C2=A0 =C2=A0(q.v.)
=

?

=



_____________________________________=
__________

Rift mailing list

Rift@ietf.org

https://www.ietf.org/mailman/listinfo/rift








--001a114d7d3e2d8b0a05638678ad--


From nobody Wed Jan 24 08:43:45 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CBF126CC7; Wed, 24 Jan 2018 08:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 nuXfgRfZuDmQ; Wed, 24 Jan 2018 08:43:39 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 B68B11205D3; Wed, 24 Jan 2018 08:43:38 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id v123so9822528wmd.5; Wed, 24 Jan 2018 08:43:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gymV9Y8/qSABU92uW+GU+y2FmH3tdnA3Xrct5nRBJmQ=; b=XL6uCSad5dcKz7/bJfOUL0ePnFl6QBPD9kSxiZfsV2G983hAfH8PvbyME/F3oqPHUY 9Fs+fw0R464O3PRS6lKt6vnyLlhQH2rpVmWF5faD/0nKZuqwy/+ZfRkdCEi7OFYZHPpe 4JDbWw1koekTq9oMk09b21O7fdXOZrOkPcfRF6W6Q19xXM+DhZp2o8Ep+KO4LPmuVgm1 ZtyMrk7TvTcJ3Q3Eb9kxERyBzkma+SkiUh9RmifJqfp6D/ilnURahw2m7wktS/6Qg1gC mS5K/lvelnqF6/vRwXqpIY11uSVJH4e+IvMcw3A0b4KTwMyLodlgeWmXx3DpeECI8MVD o1+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gymV9Y8/qSABU92uW+GU+y2FmH3tdnA3Xrct5nRBJmQ=; b=aoan1WaIQREtOlbjHVGZRiNRcJUgOi4iDSm1oFbXQOrr/xuYqnTPoIZ7KqmS/YINUL VmE52eHC6vfEpmUkI+7eZ/9+HluqNBNpfr1UcDLdHi792MJFM6ZufrFwymTEtPEO+ECN 25sI1rYtnwfVAsOtEswffe7EPc6WVN6F0mN7skVs/xOhDD9O6uiR3nDQRjZagPtoysuy Bs3wg3lO4urt686Hcz0ku1qKj1oGoTQsbp4wWV9lHhPOih3cxPv6oZ9+HHoLSN1wTAmJ Xb/JRBejv1C27fyw25VS9S45TGXa7i+8OBiyJLVOjRht/GqDU0Rq3FLmAkp3wkPelGZP /YFg==
X-Gm-Message-State: AKwxyteOiuYxhY2mrRRm/AczE3wu7uTdh4gRQ8gAOLxOvpNmP+xr8iba kOoINHQky0T0mF2/dTgKKZ5HPbdjWobr1ZjzysseQuIQ
X-Google-Smtp-Source: AH8x224db3fvLIBrx2lWjXe7vxNzEBdsJbP8q0WGM2gDEEpbaafZIfwE8YWAGX7fHk9BcT1zYJBADm2WdVS+UbM5pPQ=
X-Received: by 10.80.148.217 with SMTP id t25mr25602186eda.121.1516812217243;  Wed, 24 Jan 2018 08:43:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.182.239 with HTTP; Wed, 24 Jan 2018 08:42:56 -0800 (PST)
In-Reply-To: 
References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com>   
From: Tony Przygienda 
Date: Wed, 24 Jan 2018 08:42:56 -0800
Message-ID: 
To: Spencer Dawkins at IETF 
Cc: IESG , rift-chairs@ietf.org, rift@ietf.org,  Alvaro Retana 
Content-Type: multipart/alternative; boundary="f403045c2316665e130563885d54"
Archived-At: 
Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 16:43:41 -0000

--f403045c2316665e130563885d54
Content-Type: text/plain; charset="UTF-8"

>
> Right. What I'm asking, is WHY. And, specifically, what is at least one
> problem with using unmodified existing routing protocols in data centers,
> that RIFT will fix?
>
> Sorry if that wasn't clear.
>
>

Spencer, and here I have to fwd' you to the REQ section of current RIFT
draft (or the published DC requirements draft which lots of people with
vendor/opex experience in this space co-authored & discussed) which
explains the problems (and then there is good amount which has to do with
novel implementation techniques, the way software is delivered in DC and so
on which really is not something that is part of a protocol spec or this
discussion). I spent long days over years twiddling with traditional
protocols thinking how to do all the things required well and @ certain
point in time I cut my losses realizing that the problem presented is
fundamentally different one from generic SPF on a generic graph we solved
by now. To mention one fundamental problem I would say the "how do I keep
blast radius minimal" is a hard one since it inevitably leads to
"sumarization of information" which must be handled somehow once you incur
reconfiguration/failures to prevent blackholes. Solving both problems @
same time with generic algorithms on generic graphs does not seem feasible
to me today (and never was IMO, the discussion was really had during PNNI
complex node times in depth that used barrels of ink without any practical
or even theoretically feasible result and to go deeper, it has to do with
some epistemological principles some very smart people talked to me about).
So  you either summarize & pay blackholes (you may declare you network
reconfiguration or failure-free to which I drily observe that doing
anything but static routing is overcomplicating your solution then or you
may have to treat your IP fabric like a faulty RAM chip and throw the whole
lot away on a link failure) or you don't summarize and your blast radius is
everything on every change which presents (a.k.a host routes flat IGP)
inherent scaling/stability problems (to which one can of course declare
that amount of memory is infinite today, software is bug free and speed of
light is a temporary anomaly only of course).

Now, REQ can be discussed of course (REQ depend of course again on
customers, which markets you're addressing and so on so e'one has one piece
of the elephant especially in still nascent market like DC) and there's a
school of thought that " we can do what we can do and rest is irrelevant"
which is Ford-T and my add-on catalogue analogy I applied. Nothing wrong
with that of course and it will be done but this is often done under
assumptions of OPEX being free for everyone (i.e. humans can solve any
complicated problem that occurs, are abundantly available and they should
be royally paid for twiddling endless amount of non-orthogonal knobs and
damn' if  computers could solve that with good algorithms, not an economic
school of thought that carried lots of success over longer time horizons).
Reality is that network IT is being hard squeezed there for many orgs and
humans are slow & fallible (again, all depends on customer classes and so
on)  ... We are still thinking that "networking is special" and "bandwith
is not a commodity" and unfortunately, I dispute that strongly as far IP
fabrics go and I think our success as IETF will depend on being able on
deliver a technology that gives people "network as a RAM chip", i.e.
bandwith is a component needing zero OPEX to "buy-and-deploy-more-off" ...

So, I digressed a bit here and all this would  probably blow the format of
a charter by at least an order of dimension. Some of the stuff was talked
in the BoF format and then it needs bar discussions and involvement in the
group I'd say ...

--- tony

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



=

=


Righ=
t. What I'm asking, is WHY. And, specifically, what is at least one pro=
blem with using unmodified existing routing protocols in data centers, that=
 RIFT will fix?=C2=A0

Sorry if that wasn't cle=
ar.
=C2=A0

Spencer, and here I have to fwd' you to the R=
EQ section of current RIFT draft (or the published DC requirements draft wh=
ich lots of people with vendor/opex experience in this space co-authored &a=
mp; discussed) which explains the problems (and then there is good amount w=
hich has to do with novel implementation techniques, the way software is de=
livered in DC and so on which really is not something that is part of a pro=
tocol spec or this discussion). I spent long days over years twiddling with=
 traditional protocols thinking how to do all the things required well and =
@ certain point in time I cut my losses realizing that the problem presente=
d is fundamentally different one from generic SPF on a generic graph we sol=
ved by now. To mention one fundamental problem I would say the "how do=
 I keep blast radius minimal" is a hard one since it inevitably leads =
to "sumarization of information" which must be handled somehow on=
ce you incur reconfiguration/failures to prevent blackholes. Solving both p=
roblems @ same time with generic algorithms on generic graphs does not seem=
 feasible to me today (and never was IMO, the discussion was really had dur=
ing PNNI complex node times in depth that used barrels of ink without any p=
ractical or even theoretically feasible result and to go deeper, it has to =
do with some epistemological principles some very smart people talked to me=
 about). So=C2=A0 you either summarize & pay blackholes (you may declar=
e you network reconfiguration or failure-free to which I drily observe that=
 doing anything but static routing is overcomplicating your solution then o=
r you may have to treat your IP fabric like a faulty RAM chip and throw the=
 whole lot away on a link failure) or you don't summarize and your blas=
t radius is everything on every change which presents (a.k.a host routes fl=
at IGP)=C2=A0 inherent scaling/stability problems (to which one can of cour=
se declare that amount of memory is infinite today, software is bug free an=
d speed of light is a temporary anomaly only of course). 
Now, REQ can be discussed of course (REQ depend of course again=
 on customers, which markets you're addressing and so on so e'one h=
as one piece of the elephant especially in still nascent market like DC) an=
d there's a school of thought that " we can do what we can do and =
rest is irrelevant" which is Ford-T and my add-on catalogue analogy I =
applied. Nothing wrong with that of course and it will be done but this is =
often done under assumptions of OPEX being free for everyone (i.e. humans c=
an solve any complicated problem that occurs, are abundantly available and =
they should be royally paid for twiddling endless amount of non-orthogonal =
knobs and damn' if=C2=A0 computers could solve that with good algorithm=
s, not an economic school of thought that carried lots of success over long=
er time horizons). Reality is that network IT is being hard squeezed there =
for many orgs and humans are slow & fallible (again, all depends on cus=
tomer classes and so on)=C2=A0 ... We are still thinking that "network=
ing is special" and "bandwith is not a commodity" and unfort=
unately, I dispute that strongly as far IP fabrics go and I think our succe=
ss as IETF will depend on being able on deliver a technology that gives peo=
ple "network as a RAM chip", i.e. bandwith is a component needing=
 zero OPEX to "buy-and-deploy-more-off" ... 

So, I digressed a bit here and all this would=C2=A0 probably blow =
the format of a charter by at least an order of dimension. Some of the stuf=
f was talked in the BoF format and then it needs bar discussions and involv=
ement in the group I'd say ... 

--- tony <=
br>
=C2=A0



--f403045c2316665e130563885d54--


From nobody Wed Jan 24 09:09:18 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45674127077 for ; Wed, 24 Jan 2018 09:09:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 1TQpDRopra36 for ; Wed, 24 Jan 2018 09:09:15 -0800 (PST)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254D0127058 for ; Wed, 24 Jan 2018 09:09:09 -0800 (PST)
Received: by mail-wm0-x232.google.com with SMTP id i186so9750319wmi.4 for ; Wed, 24 Jan 2018 09:09:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CNKu3VSZ0uCnNLMsX83ng2ma0YMV02kSy7kVsAC5VEQ=; b=V04zl8wsuffYmjTpM5KJtgkoE8Ml+BkIUZO/mmw2PO1kw8nd248kAbp72gdwlu7uiq E5McmMVOGsKdCT6GSgcmaeDzPsjfkCbR04inyfpZfZyhwUeNRNxayCsIimqWo8IDpPud xvWuXtgHXBtNRjYODAmYH+XSOZzn3EWN0jH/xNxIPkEb+Ki4HetXFcm/KK0r607IG+fL GFRvN2yZJj52RxlCn/6rDF3wifE5qIKiZWAnNGSsKEjWInerJXT5aLGB3+iWcqm7OZGu Q1TdgKjuSerAHHq8DBlt1s+EFED5LXeXS3CZtPl+wQOzCWchS+kQm7ZF6dmsSknwktIg XExA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CNKu3VSZ0uCnNLMsX83ng2ma0YMV02kSy7kVsAC5VEQ=; b=DpEBrpq/kc2FvWp3YFr9ZAaEzcIi7xbQa+/Hvvi4Do10Uw4ukf0Xt/+gCWyEmk7d6X kabSTzSrahTuLp7KYixEibdY7ryAdVO21C9OZuL81ohxPpO8MlhkzeKTYsWT0IenxsH1 FFXxtjLAWBNapp2/nIqh5Yu+D2qkWc9kMwP1r5nWrxgaosBFmSFQb/vPFo291/wP+X09 X72PoQegD1mswRtLVTEhY6L59PqXjdniW7htEnMZsju6/oIi77oMjyZMSPT4X6ZhfFz5 I9wrnu2tz472YXmMYJH5MVSWBDFhqVoaLUv3FqPnXnYEwp2yGgOB7zMT0kXieQ63RDXO ifvQ==
X-Gm-Message-State: AKwxytfhzTFh4qPMwY3bF0jTVLwo2EWZ3TlcZWWPgEOpSNLITAiuICEk sww737NgYNL4Dk5Xs3vZ9X2AV+atFlaa/Vwx0FE=
X-Google-Smtp-Source: AH8x224nXVaTp8jIN19IAIWhBQbCjmyPzFdSGKzXaHZsBpZ50fQwAvy/9/pTIvL4ZxpMd+SB5GYrWkzSTEl6zo281NQ=
X-Received: by 10.80.183.97 with SMTP id g88mr23689875ede.191.1516813747114; Wed, 24 Jan 2018 09:09:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.182.239 with HTTP; Wed, 24 Jan 2018 09:08:26 -0800 (PST)
In-Reply-To: <3b2b6dce-cebc-243e-63ea-3a561a1585ea@cisco.com>
References:    <3b2b6dce-cebc-243e-63ea-3a561a1585ea@cisco.com>
From: Tony Przygienda 
Date: Wed, 24 Jan 2018 09:08:26 -0800
Message-ID: 
To: Robert Wilton 
Cc: A S , rift@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c19506896572b056388b8ba"
Archived-At: 
Subject: Re: [Rift] Internal Review of the rift Charter
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 17:09:17 -0000

--94eb2c19506896572b056388b8ba
Content-Type: text/plain; charset="UTF-8"

ok, good suggestion. I'll think of including something on buckets of

* I think that's easy to do, done, needs firming up
* that's open to attack, not hard
* that's hard and open

thanks

--- tony



On Wed, Jan 24, 2018 at 2:30 AM, Robert Wilton  wrote:

> Hi Tony,
> On 19/01/2018 02:30, Tony Przygienda wrote:
>
> funny one ;-)   If that persists, I may to have to change my name to
> Zaphod or something ;-)
>
> BTW, talking about first possible WG meet @ 101 (no, it's NOT the highway
> in SV in case we have FUD in this case as well ;-), what would people like
> from me if I get a preso slot? Some more in-detail walk-through of some
> section/concept in the RIFT draft? List of what I think people can grab on
> the main draft to contribute/flesh out? Otherwise charter has things enough
> to camp on ...
>
> I would suggest a list of things that you think are effectively done (from
> your POV), and a separate list of areas that you still think need further
> discussion/work.
>
> Thanks,
> Rob
>
>
> Before 101 I see another version rev'ed with some subtle ZTP updates due
> to feedback I got. And there's another one larg'ish addition being thought
> through but that's being chewed right now by the core folks and not ready
> for wider look yet. Most likely after 101 ...
>
> thanks
>
> --- tony
>
> On Thu, Jan 18, 2018 at 5:45 PM, A S  wrote:
>
>> Got a unicast that Tony here is multicast address. To clarify, I meant
>> Tony P.
>>
>>
>>
>>
>
>
> _______________________________________________
> Rift mailing listRift@ietf.orghttps://www.ietf.org/mailman/listinfo/rift
>
>
>

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


ok, good suggestion. I'll think of=
 including something on buckets of=C2=A0 

* I think that's=
 easy to do, done, needs firming up 
* that's open to attack, =
not hard
* that's hard and open 

=
thanks 

--- tony 



On Wed, Jan 24, 2018 a=
t 2:30 AM, Robert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    
Hi Tony,

    

    
On 19/01/2018 02:3=
0, Tony Przygienda
      wrote:

    

    

     =20
      

        

          
funny one ;-)=C2=A0=C2=A0 If that persists, I may to have to=
 change
            my name to Zaphod or something ;-) 

            

          

          BTW, talking about first possible WG meet @ 101 (no, it's NOT
          the highway in SV in case we have FUD in this case as well
          ;-), what would people like from me if I get a preso slot?
          Some more in-detail walk-through of some section/concept in
          the RIFT draft? List of what I think people can grab on the
          main draft to contribute/flesh out? Otherwise charter has
          things enough to camp on ... 

        

      

    

    I would suggest a list of things that you think are effectively done
    (from your POV), and a separate list of areas that you still think
    need further discussion/work.

    

    Thanks,

    Rob

    

    

      

        


        

        
Before 101 I see another version rev'ed with some subtle
          ZTP updates due to feedback I got. And there's another one
          larg'ish addition being thought through but that's being
          chewed right now by the core folks and not ready for wider
          look yet. Most likely after 101 ... 

        

        


        

        
thanks

        

        


        

        --- tony=C2=A0 

        


          
On Thu, Jan 18, 2018 at 5:45 PM, A S
            <as3957@gmail.com>
            wrote:

            

              
Got a unicast that Tony here is multicast
                address. To clarify, I meant Tony P.
                

                  


                    

                      

                        


                        

                      

                    

                  

                

              

              

            

          

          

        

      

      

      

      

      
___________________________________=
____________
Rift mailing list
Rift@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/rift


    

    

  






--94eb2c19506896572b056388b8ba--


From nobody Wed Jan 24 11:37:20 2018
Return-Path: 
X-Original-To: rift@ietf.org
Delivered-To: rift@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3751277BB; Wed, 24 Jan 2018 11:37:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov 
To: "The IESG" 
Cc: aretana.ietf@gmail.com, rift-chairs@ietf.org, rift@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151682263313.22681.14816918518556701596.idtracker@ietfa.amsl.com>
Date: Wed, 24 Jan 2018 11:37:13 -0800
Archived-At: 
Subject: [Rift] Alexey Melnikov's No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jan 2018 19:37:13 -0000

Alexey Melnikov has entered the following ballot position for
charter-ietf-rift-00-04: No Objection

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



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



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

The charter is hard to understand for a non specialist. Expanding acronyms on
first use/adding references would help.



From nobody Thu Jan 25 05:33:14 2018
Return-Path: 
X-Original-To: rift@ietf.org
Delivered-To: rift@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6E71200E5; Thu, 25 Jan 2018 05:33:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise 
To: "The IESG" 
Cc: aretana.ietf@gmail.com, rift-chairs@ietf.org, rift@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151688718885.31342.12143691556447545209.idtracker@ietfa.amsl.com>
Date: Thu, 25 Jan 2018 05:33:08 -0800
Archived-At: 
Subject: [Rift] Benoit Claise's No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 13:33:09 -0000

Benoit Claise has entered the following ballot position for
charter-ietf-rift-00-04: No Objection

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



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



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

 - A YANG module focused on configuration of protocol instances
I hope that this work item is
 - A YANG module focused on configuration and monitoring of protocol instances

Editorial
 - A Standards Track specification based on draft-przygienda-rift. The document
 will include:
   - an Implementation Status section as described in RFC 7942
   - an Operational Considerations section to explain how the protocol is
   configured, deployed, and diagnosed - Security and Privacy Considerations,
   although this material may refer to a separate Threat Analysis document
   (q.v.)

The sentence starting with "- Security and Privacy Considerations, ..." should have a new line.



From nobody Thu Jan 25 06:44:49 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B17D1241F8; Thu, 25 Jan 2018 06:44:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 AU_CUOXANsNP; Thu, 25 Jan 2018 06:44:46 -0800 (PST)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 8BC3B120726; Thu, 25 Jan 2018 06:44:46 -0800 (PST)
Received: by mail-oi0-x22d.google.com with SMTP id k15so5379316oib.1; Thu, 25 Jan 2018 06:44:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ZhW1cCLCKBBx9HUOt02ynudWgtr2tZgn01O7HZDnL7o=; b=KTfoms9aP5AoQ/xFpHQzlbKQfyCxk0vNsLua+1CESw+Qp7rFCoF/p/4qbMhUukeFmo PhHIsgytXQWcKVp8QwzSzmDYQJxpHPvUTLH5suDkvAJWXKYKj7X5Tw3Dc65P55ahfAMY KG5WuCZqQIkSPxJRiuzKO1ygDd6MhmGwbmhBmvSvba8WzFZ2lga+RW1mOxYdnqDxT0U3 clajWhOyW7zLvDcSIm1Omo8StBr4n+vy6RKRbo/V0oRBAE5eKJNHst96A38/tDxWTe6K 0lLPF3SLposDK96kZSrlGEfp9zlHvpqbnUuWDe6xUbUmUvTYI1zfibzS/Uabw9tate8/ aIgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ZhW1cCLCKBBx9HUOt02ynudWgtr2tZgn01O7HZDnL7o=; b=r4zd5F/eMKRJ0XXXqN3iIZUkiFiWaSlWr9OHs+v9RTT8TawWdeWv281Wc+lXarJkcK +92KwnAfGopfN2agAtwABv0eXGlvx6rDgbo9BiCk/we/51dZRjmlsr+MgCXRcnQWYtRi 73b7rTGnNl+186RrPQV6mR6UpiC0sKXXqG6SZTIV+LmOcMYwdEv6iapTkaXmMjg0NNqL uaDmVDBhd+HDjmcD7/zUGy7F5C+cnuS9AsKKMZUu/puXT7PWlBElxIWB0vZCfSM4tmX6 37gCtQ5puNyr91eCPNo6Ig09R3d+fD6VBntwDgaRbpkrarsZywnfeCiT9Nm4SKOOQEgq A9YA==
X-Gm-Message-State: AKwxytck/vMDT/Q/GfV6UoSP7JeTUrvd4TwUGlDnvKfN1+o1peX2bTDV mbkhvHgMqZe5YWeDg9zDnqE6jpvnXodS66F0DH4=
X-Google-Smtp-Source: AH8x226vzmSXmlzGSNMBEjgevJWBvCQPO/ZwIDR4DLj2Uu+uQh3jOWK8cbG6b9DhuGKcb68XCtgfyfUTVOf9H6jEFJ0=
X-Received: by 10.202.195.71 with SMTP id t68mr11514637oif.216.1516891485897;  Thu, 25 Jan 2018 06:44:45 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jan 2018 09:44:45 -0500
From: Alvaro Retana 
In-Reply-To: 
References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com>    
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Thu, 25 Jan 2018 09:44:45 -0500
Message-ID: 
To: Spencer Dawkins at IETF , Tony Przygienda 
Cc: rift@ietf.org, IESG , rift-chairs@ietf.org
Content-Type: multipart/alternative; boundary="001a113e24062e0b2305639ad297"
Archived-At: 
Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 14:44:48 -0000

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

On January 24, 2018 at 11:43:37 AM, Tony Przygienda (tonysietf@gmail.com)
wrote:

Hi!

I digressed a bit here and all this would  probably blow the format of a
charter by at least an order of dimension. Some of the stuff was talked in
the BoF format and then it needs bar discussions and involvement in the
group I'd say ...


Yes, I believe that the reasons for doing the work are well known to the
participants and whoever paid attention at the dcrouting BOF.  However, to
Spencer=E2=80=99s point, the charter is written not just for the benefit of=
 the
proponents (and others who understand and support the reasoning), but for
the benefit of potential new participants and other interested parties =E2=
=80=94
including future IESGs which will have the task of evaluating the output
and even rechartering the WG.

I think that we can come up with a general introductory paragraph (just a
few sentences) that provides some specific background for the DC-related
routing work.  I will borrow from the references that Tony pointed to and
bounce something by thing list before the end of the day.

Thanks!

Alvaro.

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

=

On January 24,=
 2018 at 11:43:37 AM, Tony Przygienda (tonysietf@gmail.com) wrote:

=

Hi!

=
 
I digressed a bit here and all this would=C2=A0 probab=
ly blow the format of a charter by at least an order of dimension. Some of =
the stuff was talked in the BoF format and then it needs bar discussions an=
d involvement in the group I'd say ...
 

Yes, I believe that the rea=
sons for doing the work are well known to the participants and whoever paid=
 attention at the dcrouting BOF.=C2=A0 However, to Spencer=E2=80=99s point,=
 the charter is written not just for the benefit of the proponents (and oth=
ers who understand and support the reasoning), but for the benefit of poten=
tial new participants and other interested parties =E2=80=94 including futu=
re IESGs which will have the task of evaluating the output and even rechart=
ering the WG.

I t=
hink that we can come up with a general introductory paragraph (just a few =
sentences) that provides some specific background for the DC-related routin=
g work.=C2=A0 I will borrow from the references that Tony pointed to and bo=
unce something by thing list before the end of the day.

Thanks!
Alvaro.


--001a113e24062e0b2305639ad297--


From nobody Thu Jan 25 07:26:26 2018
Return-Path: 
X-Original-To: rift@ietf.org
Delivered-To: rift@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C89BE126C25; Thu, 25 Jan 2018 07:26:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind?= 
To: "The IESG" 
Cc: aretana.ietf@gmail.com, rift-chairs@ietf.org, rift@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151689398477.20369.1775461157192923628.idtracker@ietfa.amsl.com>
Date: Thu, 25 Jan 2018 07:26:24 -0800
Archived-At: 
Subject: [Rift] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charter?= =?utf-8?q?-ietf-rift-00-04=3A_=28with_COMMENT=29?=
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 15:26:25 -0000

Mirja Kühlewind has entered the following ballot position for
charter-ietf-rift-00-04: No Objection

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



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



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

Not sure if the Threat Analysis and Applicability Statement need to be separate
documents or published in an RFC at all.



From nobody Thu Jan 25 09:07:11 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C581270AC; Thu, 25 Jan 2018 09:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 GzIcuZDloIRP; Thu, 25 Jan 2018 09:07:03 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5ECB126DC2; Thu, 25 Jan 2018 09:07:02 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id x4so31968830wmc.0; Thu, 25 Jan 2018 09:07:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wqJsd73oFHqvN7td8mKc5OtcBpDLMo0RW9pmc9gX8Og=; b=UD/snGA15BbHnhfSvljVuTnzGBNwnyRJghxxHGIp7vaVx4jF4lCDkZGi0XjDzeDsuf 0V09m4EKEGuFyT1eU5pztqjxsWF/6J8O+xDPEpoAc1xVh+bkYJptZiAZNME4vNXjNrVP 4qicma2+k07GNrhpHo9q4C+J7lK7XW4F/FYNoUYcusdWB1D92qCNhCA04uAwG+ezaAgY gdoGcavkOvQJpyHS6c8r2AJAO/27UEKDWDkqDmdos5dyZ7WSaegZo9PLRLQgDMMMN5db TS1W4QMA8rqEfbDE1OvYAOwuhi8VHgxPkYkfczTb6HhfD0KxplPn9bB2bXw67oNhnX+n DfXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wqJsd73oFHqvN7td8mKc5OtcBpDLMo0RW9pmc9gX8Og=; b=jf1osUG1ZGGcmuqkH1jhY4QtEfEs4U2kT3bk/3dMHuxIgxukcIFmhrfcEKV18RNCOh NpZ3miKJGSGFmU4v7zHZiGb81JJp7ZwbCsb+ULZvE6g0kSwCSB27MO8csdzYUOv9NEUQ GBGs/BbtMkilCVQxrC7vC1toeqBe5dRFBkT1lh15T4vhi+q7SvkE1uJ6opSmYbZMB7ZF G/dUSiPkuV7nLza+k47mia+Z/jUgOnSfRHVHp+3hYxGXIo1iKCfH9nKAKlEI/krwBjTI eqRGDiSv/SDTu/ReK6x4+5+auRjBi4kvRJRJdZj+ehlxAtmL6kQIOQn7D2JMbJhDqlPa Wmxg==
X-Gm-Message-State: AKwxytfVovDWmJXoV5j//9g+EP4AMJvQm7IKbIIG4X1AbFlwwlwIakmk o16D1tKyxCcFHHIGy4tmG2t34SM53Fb9MQxLzqY=
X-Google-Smtp-Source: AH8x224CJ1QlBJKkEQe7hRcqMXYi3dtmXEQ3LzWi8np88/HElIgu88ECfsVynHiIPdNa/6XQ+DeOYZ3BLMEvOcguAg4=
X-Received: by 10.80.183.97 with SMTP id g88mr28412949ede.191.1516900021322; Thu, 25 Jan 2018 09:07:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.182.239 with HTTP; Thu, 25 Jan 2018 09:06:21 -0800 (PST)
In-Reply-To: <151688718885.31342.12143691556447545209.idtracker@ietfa.amsl.com>
References: <151688718885.31342.12143691556447545209.idtracker@ietfa.amsl.com>
From: Tony Przygienda 
Date: Thu, 25 Jan 2018 09:06:21 -0800
Message-ID: 
To: Benoit Claise 
Cc: The IESG , rift-chairs@ietf.org, rift@ietf.org,  Alvaro Retana 
Content-Type: multipart/alternative; boundary="94eb2c195068ee49db05639cce9d"
Archived-At: 
Subject: Re: [Rift] Benoit Claise's No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 17:07:06 -0000

--94eb2c195068ee49db05639cce9d
Content-Type: text/plain; charset="UTF-8"

Benoit, thanks for review. Agree with your comments. Further comments

1. I personally think implementation status is kept more handy as a
separate document from spec ...
2. I think that monitoring YANG discussion is best kept as separate
model/topic from configuration Yang. Yang is _great_ for configuration but
monitoring has its own challenges (based on practical experience ;-).
Worthy discussion in the group and possibly a template of things to come in
other protocols, i.e. how do we provide good telemetry into a protocol
without starting with Yang or any other modelling/transport preconception
...  In fact, I would argue that to do really good monitoring @ certain
point in time you fall back on packet encodings themselves, i.e. you read
thrift/protobuf packets from something like a streaming medium [which puts
you close to e.g. flooding albeit you are willing to "miss things" being on
a slower, reliable medium like TCP while still achieving consistency] ...

thanks

--- tony

On Thu, Jan 25, 2018 at 5:33 AM, Benoit Claise  wrote:

> Benoit Claise has entered the following ballot position for
> charter-ietf-rift-00-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-rift/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>  - A YANG module focused on configuration of protocol instances
> I hope that this work item is
>  - A YANG module focused on configuration and monitoring of protocol
> instances
>
> Editorial
>  - A Standards Track specification based on draft-przygienda-rift. The
> document
>  will include:
>    - an Implementation Status section as described in RFC 7942
>    - an Operational Considerations section to explain how the protocol is
>    configured, deployed, and diagnosed - Security and Privacy
> Considerations,
>    although this material may refer to a separate Threat Analysis document
>    (q.v.)
>
> The sentence starting with "- Security and Privacy Considerations, ..."
> should have a new line.
>
>
> _______________________________________________
> Rift mailing list
> Rift@ietf.org
> https://www.ietf.org/mailman/listinfo/rift
>

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


Benoit, thanks for review. Agree with =
your comments. Further comments

1. I personally think implemen=
tation status is kept more handy as a separate document from spec ... 
<=
/div>2. I think that monitoring YANG discussion is best kept as separate mo=
del/topic from configuration Yang. Yang is _great_ for configuration but mo=
nitoring has its own challenges (based on practical experience ;-). Worthy =
discussion in the group and possibly a template of things to come in other =
protocols, i.e. how do we provide good telemetry into a protocol without st=
arting with Yang or any other modelling/transport preconception ...=C2=A0 I=
n fact, I would argue that to do really good monitoring @ certain point in =
time you fall back on packet encodings themselves, i.e. you read thrift/pro=
tobuf packets from something like a streaming medium [which puts you close =
to e.g. flooding albeit you are willing to "miss things" being on=
 a slower, reliable medium like TCP while still achieving consistency] ... =


thanks 

--- tony 

On Thu, Jan 25, 2018 at 5:33 AM, Benoi=
t Claise <bclaise@cisco.com> wrote:
Benoit Claise has entered the following ballot position for

charter-ietf-rift-00-04: No Objection



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)







The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/charter-iet=
f-rift/







-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



=C2=A0- A YANG module focused on configuration of protocol instances

I hope that this work item is

=C2=A0- A YANG module focused on configuration and monitoring of protocol i=
nstances



Editorial

=C2=A0- A Standards Track specification based on draft-przygienda-rift. The=
 document

=C2=A0will include:

=C2=A0 =C2=A0- an Implementation Status section as described in RFC 7942
=C2=A0 =C2=A0- an Operational Considerations section to explain how the pro=
tocol is

=C2=A0 =C2=A0configured, deployed, and diagnosed - Security and Privacy Con=
siderations,

=C2=A0 =C2=A0although this material may refer to a separate Threat Analysis=
 document

=C2=A0 =C2=A0(q.v.)



The sentence starting with "- Security and Privacy Considerations, ...=
" should have a new line.





_______________________________________________

Rift mailing list

Rift@ietf.org

https://www.ietf.org/mailman/listinfo/rift





--94eb2c195068ee49db05639cce9d--


From nobody Thu Jan 25 09:57:41 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA63A1270A7; Thu, 25 Jan 2018 09:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level: 
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 M6ylXxXvaz96; Thu, 25 Jan 2018 09:57:37 -0800 (PST)
Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (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 A87B1126E3A; Thu, 25 Jan 2018 09:57:37 -0800 (PST)
Received: by mail-oi0-x242.google.com with SMTP id m83so5798501oik.8; Thu, 25 Jan 2018 09:57:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ybL0xl9Q1tEnXv7HOsVT8O6pLVjJ1G8v2aKcnqm10AQ=; b=VJmLE/j+XokKRZH3iiM9DtzVCCQYuEd/TdaUa9HzWirLZopiIlDbSJ2FvHaDOdcbHr 8ULybvf3DjNRJjQjs4KDiYa32JvySXWWdIpyQp9HMksFGLo/khJB6tERmKfHPZTd6eBd p2+Cpy9+8OFDdbraz3Ds8RxUX9IFrA42hMGQ+dyVfk7gDrF0WVloFpSwF9Q34K/EeQLh Hqe6JdKwXV3UBEevVh+QMEUhWhIT3gP0oG+pLHCKny8BzUu/ab4xy5152GRZYUjWZXDh 9XKodZHzL5kOAoIi719sUmIspUJSL1BInz7MEHXMuJmKu82pSCmLzHTIxVb10rVoAtgd 0GEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ybL0xl9Q1tEnXv7HOsVT8O6pLVjJ1G8v2aKcnqm10AQ=; b=m9xBc5DUdIjDyOJBAj4XFoQUoPbSUqdeUo+1Hv/F1SQW2Sr4tODg6eXmEMFuEsyOWB 4etVHQTrkWbYENryg+Cy+XZDf1t+CW+h7xljlbcyieIGlMomb2ub0s4fN3ALAlCRYexN ZvyqpVqp21IxoRdNeCZyN6K9pFZ7Qttwl5DifyQOC50Fwa/HbJ7Muq2aRuQvWxCbgy/d B0K29zIom/75i2jatKqIYOO9zHob7FUgVPrbpXXFU/Yx849QJdsD180/2ANeCyQZGBae V0r4G4Zxm1b5O5eC4kuqvbJW9X8/iDtE2fT5doUlIdzoM3+3MPibRgXGDXh1/fKY0KMz V2YQ==
X-Gm-Message-State: AKwxyteG7gdJ4FKQ9pSnyzl2Dee/P+kySGRdq/Urnlddc0owgVBUw994 RLvg+9M5aDiZVZwXbzlbD9k9nQbIfnXwI2oq/Kg=
X-Google-Smtp-Source: AH8x226NBAF9299wJTxfabQudKmISrXi+EAn5BjsAEFygm6lQYlpK7JhMg5792pwO6nmQQUg/+uBTvj68JWBgscwym4=
X-Received: by 10.202.45.7 with SMTP id t7mr11424730oit.356.1516903056990; Thu, 25 Jan 2018 09:57:36 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jan 2018 12:57:36 -0500
From: Alvaro Retana 
In-Reply-To: 
References: <151642505281.3249.6131609585029677271.idtracker@ietfa.amsl.com>     
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Thu, 25 Jan 2018 12:57:36 -0500
Message-ID: 
To: Spencer Dawkins at IETF , Tony Przygienda 
Cc: rift-chairs@ietf.org, IESG , rift@ietf.org
Content-Type: multipart/alternative; boundary="001a1137bebadee74405639d8339"
Archived-At: 
Subject: Re: [Rift] Spencer Dawkins' No Objection on charter-ietf-rift-00-04: (with COMMENT)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jan 2018 17:57:40 -0000

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

On January 25, 2018 at 9:44:45 AM, Alvaro Retana (aretana.ietf@gmail.com)
wrote:

I think that we can come up with a general introductory paragraph (just a
few sentences) that provides some specific background for the DC-related
routing work.  I will borrow from the references that Tony pointed to and
bounce something by thing list before the end of the day.


I put together a couple of sentences as a brief introduction and submitted
it as -05 [1].  Please take a look.

I plan on asking the IESG Secretariat to move the charter on to External
Review before the end of the day today.

Thanks!

Alvaro.

[1] https://datatracker.ietf.org/doc/charter-ietf-rift/00-05/

Diffs:
https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-rift%2Fwithmilestones-00-04.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-rift%2Fwithmilestones-00-05.txt

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

=

On January 25,=
 2018 at 9:44:45 AM, Alvaro Retana (aretana.ietf@gmail.com) wrote:

 
I think that we can come up with a general in=
troductory paragraph (just a few sentences) that provides some specific bac=
kground for the DC-related routing work.=C2=A0 I will borrow from the refer=
ences that Tony pointed to and bounce something by thing list before the en=
d of the day.
 

<=
/div>
I put together a couple of sentences as a brief introduc=
tion and submitted it as -05 [1].=C2=A0 Please take a look.

I plan on asking the IESG Secreta=
riat to move the charter on to External Review before the end of the day to=
day.

Thanks!

Alvaro.





--001a1137bebadee74405639d8339--


From nobody Thu Jan 25 19:29:59 2018
Return-Path: 
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA69A12D851 for ; Thu, 25 Jan 2018 19:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 OgheCsS5MVi8 for ; Thu, 25 Jan 2018 19:29:55 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C46112E043 for ; Thu, 25 Jan 2018 19:29:55 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id w27so11235023lfd.6 for ; Thu, 25 Jan 2018 19:29:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sAnK67EIhMEoRiTIoBRdbYdWh32T/FQG+uS5Dzn3ack=; b=ZZiocysyoXD2N6+9YmXCZtr7qITKEZIWgQoR+uvx+BhbT1vdncNaKm+Hpn8U/M8J5/ tg9hNooN680VB8c1WoO1EwOVYoI7K29ZiZ5ZMKxUMmLAE5RFP2BCVwjG8v5mQvqme6K9 HRPIs4iSczcR0EJ6cKJAbpJzc4dfv2K7GBkQ56CzUURSmO6JXnBsp9H+UbgtjB5o2QAV G/n+u53lrRosrU0UAo7MjMEto/wGElO7LAqSLit96DYUNp1v6L7Wb8IWTGd9rcN3y8aX m4hN3sLGKYlBpNOnYbRPkDYWgCN2a0RV56I+STUG2XpKRK9W+2TjAXiWEOw+t7TKRy/o EvOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sAnK67EIhMEoRiTIoBRdbYdWh32T/FQG+uS5Dzn3ack=; b=IQ9/Y3BAqOap80wJzdE5s3+r8oL5Y4U39jSx2FbxKvOM1jCGGlhiE7XuIGCCcDazOu ngaK0PHB+T6WfW2Gx/zG08fZwVSRFXJc2W0QSWHtf5cPsGG73wD1LaKT7seM2Ifwb1G9 KeDO7xFqxj4ekR8O6H+ZDbR3RRkUkQCkM+JPeWjksKN4iDq5g/EFk4rBPP4Ra5y2P0CX f6idNmlcnoBUQwByZds+hwXJmXdPyNtl1LixOU8uAsUg58iyBADEybo4BSg52u6C35V3 74uDB6ZH2GKiiTkwnYL8vyeWv8+JhUGMRZdb6yHbmpft1A0gKCdYJl2DNM4LzFbsgtVc PVrg==
X-Gm-Message-State: AKwxytdWjt2aAk4Ii0me1e+awrUWirETVvhkZOO/vQ7nbRmZfZlSgffT Op9n8qXeLkuyZ+XaIP80R6/e2UMARstFEYVUOvo=
X-Google-Smtp-Source: AH8x224BU3ZgqXAbuThFJa+C4VfUvxr5vd7g8gfp4lkmMB1UkRXr99ivWUGbYAOyquvUaTTV9iUtfXQenjP2hT6Rokc=
X-Received: by 10.46.68.11 with SMTP id r11mr6911588lja.13.1516937393223; Thu, 25 Jan 2018 19:29:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.21.94 with HTTP; Thu, 25 Jan 2018 19:29:52 -0800 (PST)
In-Reply-To: 
References:    <3b2b6dce-cebc-243e-63ea-3a561a1585ea@cisco.com> 
From: Greg Mirsky 
Date: Thu, 25 Jan 2018 19:29:52 -0800
Message-ID: 
To: Tony Przygienda 
Cc: Robert Wilton , rift@ietf.org, A S 
Content-Type: multipart/alternative; boundary="94eb2c1942de783dff0563a58279"
Archived-At: 
Subject: Re: [Rift] Internal Review of the rift Charter
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of Routing in Fat Trees 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Jan 2018 03:29:58 -0000

--94eb2c1942de783dff0563a58279
Content-Type: text/plain; charset="UTF-8"

Hi,
not related to any of previous messages but since this is the only thread
at the moment.
Glad to see very pragmatic WG charter with crystal clear objective - do
that and close it.
Any plans to update the charter to reflect discussion on this list as well
as comments from ADs?
Personally, very interested in monitoring topic, monitoring control plane
protocol and information and/or data model.

Regards,
Greg

On Wed, Jan 24, 2018 at 9:08 AM, Tony Przygienda 
wrote:

> ok, good suggestion. I'll think of including something on buckets of
>
> * I think that's easy to do, done, needs firming up
> * that's open to attack, not hard
> * that's hard and open
>
> thanks
>
> --- tony
>
>
>
> On Wed, Jan 24, 2018 at 2:30 AM, Robert Wilton  wrote:
>
>> Hi Tony,
>> On 19/01/2018 02:30, Tony Przygienda wrote:
>>
>> funny one ;-)   If that persists, I may to have to change my name to
>> Zaphod or something ;-)
>>
>> BTW, talking about first possible WG meet @ 101 (no, it's NOT the highway
>> in SV in case we have FUD in this case as well ;-), what would people like
>> from me if I get a preso slot? Some more in-detail walk-through of some
>> section/concept in the RIFT draft? List of what I think people can grab on
>> the main draft to contribute/flesh out? Otherwise charter has things enough
>> to camp on ...
>>
>> I would suggest a list of things that you think are effectively done
>> (from your POV), and a separate list of areas that you still think need
>> further discussion/work.
>>
>> Thanks,
>> Rob
>>
>>
>> Before 101 I see another version rev'ed with some subtle ZTP updates due
>> to feedback I got. And there's another one larg'ish addition being thought
>> through but that's being chewed right now by the core folks and not ready
>> for wider look yet. Most likely after 101 ...
>>
>> thanks
>>
>> --- tony
>>
>> On Thu, Jan 18, 2018 at 5:45 PM, A S  wrote:
>>
>>> Got a unicast that Tony here is multicast address. To clarify, I meant
>>> Tony P.
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Rift mailing listRift@ietf.orghttps://www.ietf.org/mailman/listinfo/rift
>>
>>
>>
>
> _______________________________________________
> Rift mailing list
> Rift@ietf.org
> https://www.ietf.org/mailman/listinfo/rift
>
>

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


Hi,
not related to any of previous messages but since =
this is the only thread at the moment.
Glad to see very pragmatic=
 WG charter with crystal clear objective - do that and close it.
=
Any plans to update the charter to reflect discussion on this list as well =
as comments from ADs?
Personally, very interested in monitoring t=
opic, monitoring control plane protocol and information and/or data model.<=
/div>

Regards,
Greg

On Wed, Jan 24, 2018 at 9:08 AM, Tony Pr=
zygienda <tonysietf@gmail.com> wrote:
ok, g=
ood suggestion. I'll think of including something on buckets of=C2=A0 <=
br>
* I think that's easy to do, done, needs firming up 
* that's open to attack, not hard
* that's hard and op=
en 

thanks 

--- tony 


=


On Wed, Jan 24, 2018=
 at 2:30 AM, Robert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    
Hi Tony,

    

    
On 19/01/2018 02:30, Tony Przygienda
      wrote:

    

    

     =20
      

        

          
funny one ;-)=C2=A0=C2=A0 If that persists, I may to have to=
 change
            my name to Zaphod or something ;-) 

            

          

          BTW, talking about first possible WG meet @ 101 (no, it's NOT
          the highway in SV in case we have FUD in this case as well
          ;-), what would people like from me if I get a preso slot?
          Some more in-detail walk-through of some section/concept in
          the RIFT draft? List of what I think people can grab on the
          main draft to contribute/flesh out? Otherwise charter has
          things enough to camp on ... 

        

      

    

    I would suggest a list of things that you think are effectively done
    (from your POV), and a separate list of areas that you still think
    need further discussion/work.

    

    Thanks,

    Rob

    

    

      

        


        

        
Before 101 I see another version rev'ed with some subtle
          ZTP updates due to feedback I got. And there's another one
          larg'ish addition being thought through but that's being
          chewed right now by the core folks and not ready for wider
          look yet. Most likely after 101 ... 

        

        


        

        
thanks

        

        


        

        --- tony=C2=A0 

        


          
On Thu, Jan 18, 2018 at 5:45 PM, A S
            <as3957@gmail.com>
            wrote:

            

              
Got a unicast that Tony here is multicast
                address. To clarify, I meant Tony P.
                

                  


                    

                      

                        


                        

                      

                    

                  

                

              

              

            

          

          

        

      

      

      

      

      
______________________________________________=
_
Rift mailing list
Rift@ietf.org
https://www.ietf.org/mailman/listinfo/rift


    

    

  







_______________________________________________

Rift mailing list

Rift@ietf.org

https://www.ietf.org/mailman/listinfo/rift