From nobody Thu Apr 4 14:19:34 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FE01201AC; Thu, 4 Apr 2019 14:19:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <155441277196.30979.10716601102648982774@ietfa.amsl.com> Date: Thu, 04 Apr 2019 14:19:32 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-vendor-lcaf-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 21:19:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : Vendor Specific LISP Canonical Address Format (LCAF) Authors : Alberto Rodriguez-Natal Vina Ermagan Anton Smirnov Vrushali Ashtaputre Dino Farinacci Filename : draft-ietf-lisp-vendor-lcaf-04.txt Pages : 5 Date : 2019-04-04 Abstract: This document describes a new LISP Canonical Address Format (LCAF), the Vendor Specific LCAF. This LCAF enables organizations to have internal encodings for LCAF addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-vendor-lcaf/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-vendor-lcaf-04 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-vendor-lcaf-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-vendor-lcaf-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 11 08:52:44 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF91203B4; Thu, 11 Apr 2019 08:52:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <155499795515.26218.5415135810813132252@ietfa.amsl.com> Date: Thu, 11 Apr 2019 08:52:35 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-eid-anonymity-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 15:52:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : LISP EID Anonymity Authors : Dino Farinacci Padma Pillay-Esnault Wassim Haddad Filename : draft-ietf-lisp-eid-anonymity-06.txt Pages : 10 Date : 2019-04-11 Abstract: This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-anonymity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-eid-anonymity-06 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-anonymity-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-eid-anonymity-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 11 11:09:44 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E7112030F; Thu, 11 Apr 2019 11:09:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <155500617686.13837.11456966919261734391@ietfa.amsl.com> Date: Thu, 11 Apr 2019 11:09:36 -0700 Archived-At: Subject: [lisp] I-D Action: draft-farinacci-lisp-geo-07.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 18:09:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : LISP Geo-Coordinate Use-Cases Author : Dino Farinacci Filename : draft-farinacci-lisp-geo-07.txt Pages : 10 Date : 2019-04-11 Abstract: This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-farinacci-lisp-geo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-farinacci-lisp-geo-07 https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-geo-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-geo-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 11 11:17:07 2019 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7305D1203DA; Thu, 11 Apr 2019 11:17:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <155500662537.14212.68268042338218973@ietfa.amsl.com> Date: Thu, 11 Apr 2019 11:17:05 -0700 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-te-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 18:17:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : LISP Traffic Engineering Use-Cases Authors : Dino Farinacci Michael Kowal Parantap Lahiri Filename : draft-ietf-lisp-te-04.txt Pages : 17 Date : 2019-04-11 Abstract: This document describes how LISP reencapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-te/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-te-04 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-te-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-te-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 11 20:00:04 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED6E120640; Thu, 11 Apr 2019 19:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=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 CbGknGdAPtrG; Thu, 11 Apr 2019 19:59:55 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 1330512046B; Thu, 11 Apr 2019 19:59:55 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id t8so7125837otp.7; Thu, 11 Apr 2019 19:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yLqVC9ybTnFy9AMLCaS7V6RsOL6N2R3wh0X76uKjaBI=; b=cb6zUzf7k+1DDTLPGcmcgEzlIaNtob5GMQLgcRkE/QmFX51TNLem6+6J18Ss/u4u/y nl8JGIvVMgDise6xHZQcZD6v0CfFAF/rSwquxQC89dY5/syGZTvVJPchwXeOqjJKOI0a mlqBLU4AMpX4RdgQNBmFL2cjiDUXQ5uMG7Bore1mN9rbjkIPKjbHNeEuiXvYd7wFPulN tanlL2Rk5paMjfQe3mogwS0SOv+0utOR+/U5yyvxjJRd2LVCxTyBv8OoERycIsBk0F01 s9x1m8dT0jckGB533T05nJrBvHtvYg5jm4zCNApjVRxmS1hc2cv3Okt05GHDkCPvdI0L P+2Q== 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=yLqVC9ybTnFy9AMLCaS7V6RsOL6N2R3wh0X76uKjaBI=; b=JxudCw2Dtwj1OnfD83Me2K08MVAIXc3MozLPG+4RY1VXCgXf9+rjvHkxoSA07nNelO AkB42Di8rywvotEwycWhhFZx8dS8dm6Se9eahBy+V8asAxvlvo7ugtL0gBahNaNsUYP3 HWRnGkhy6mx6Xt9421/qT+Kn7azHNjUzREGVJU8DM9iK+i2arSyVVUjV75gtdkIqkMsN 90IQIoEOhQnzt9GyOcm83AldIEAN9JbB8I9oklWmPHM6/+yAzFSa8n3atlWrWSNY42TE vtU+nZEHXoSstgfMvrpwwkwIlBUvnrhAWxDEWeOaVhOdI2ojBvpSKvOV2X5TrvrtCC1q p5iw== X-Gm-Message-State: APjAAAUcugDa4Rs/ZS1gsUfhRdfLMPFdeVh8+/6hlf65gYRe54smf4qA BRoYbLZBxpOWVby6jYfV/ZxxmQxBzADsO0slSg0= X-Google-Smtp-Source: APXvYqztB4mv33TB1xZcTVZwuS7eILsbHkVZ2I2dTQckI9S1+n8J4Gln12bxhB2D0NRlQoFWoEnl4M9T7FbI3CUWU9E= X-Received: by 2002:a9d:7ad9:: with SMTP id m25mr35808552otn.75.1555037994337; Thu, 11 Apr 2019 19:59:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Fri, 12 Apr 2019 12:59:27 +1000 Message-ID: To: Robert Raszuk Cc: Robert Raszuk , SPRING WG , "ipv6@ietf.org" , Dino Farinacci , lisp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 02:59:56 -0000 Hi Robert, Sorry not to get back to you sooner. On Mon, 1 Apr 2019 at 01:40, Robert Raszuk wrote: > > Hi Mark, > > > Since you correctly observed that now SID can be 32 bit and that is similar to the size of IPv4 my fundamental question is why not use something which already exists instead of defining some sort of new from scratch ? > > It will be perfectly fine to have full proper SRv6 with SRH and LISP or Vector Routing as an alternative options. I really do not see a room or need for yet one more mapping plane. What problem does it solve which would not be already solved elsewhere ? > Well, there seems to be or have been concerns about the overhead of using 128 bit SIDs in IPv6. That seemed to be the motivation for EH insertion. I sympathise with the overhead concern, although I'd be quite happy to put up with the overhead and bandwidth costs of full IPv6-in-IPv6 tunnelling in comparison to non-commodity operations like inserting the SRH EH into existing IPv6 packets to avoid that overhead. Bandwidth is always getting cheaper. I think the value in using IPv6 as the transport for SR is that IPv6 is becoming and will be the future the commodity layer 3 protocol. MPLS may be fairly commodity, however IPv6 will be more so, and I think the reason is that it is an end-to-end protocol that hosts use (I think this is also why Ethernet has become the dominant link-layer protocol, even for WAN links). So if SR wants to benefit from and leverage IPv6's commodification, then it needs to be limited to commodity IPv6 operations. If it deviates, then it isn't commodity IPv6 any more. So my motivation for suggesting 32 bit SIDs in IPv6, and I'm guessing Ron's too for his smaller variable SIDs proposal including 32 bits, is to try to reduce the overhead of SR over IPv6, while also retaining commodity IPv6 operation. Regards, Mark. From nobody Thu Apr 11 20:21:13 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBF812003F; Thu, 11 Apr 2019 20:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wLsLDXEacglM; Thu, 11 Apr 2019 20:21:10 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 1050412000F; Thu, 11 Apr 2019 20:21:10 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id p6so4470542pgh.9; Thu, 11 Apr 2019 20:21:10 -0700 (PDT) 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=sbx2F0+va19UWW1Udn3ZsqZB6LXf4tM8iBHSMhfY1a4=; b=odLsiNoZu7BUPuqNflTx7X2kyhCzOpbbKhPRUSIQkiw7vyKftc0nkFHTHisA+8PbZv A93cIl000XL/2ejdvCasdSkSMv4dy+ts/JQQYfWlQncdS5qAWgDq24rTa6SZvDamMbwx XJEvpbGX6z6T+lOfhPmSypVNZ33zKBly9/BTqtgt6dT9JyGobz4ExI7zFPoTyqZhjf3U kmVQd5vFsJhxDWCFtqZ4NgqSO+MRqrL7XmkRpUt8ZLQclULfsQB8qPK4mRK/Begp+0m7 yhrCkQjd9Ld485V9ZVRTX9WvA1DjIjwZedbXrnuWYe/lP/adYpljJBDv4kz4o8Oe5L7y Mopw== 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=sbx2F0+va19UWW1Udn3ZsqZB6LXf4tM8iBHSMhfY1a4=; b=amdETb5qRgt9H08VOJCpTKRW+GdkMShb2w2cX6SlpfHy7ZcXV+X37sWeTACGSH+f1h bKyjrKeAvEDuPn0S7bGPiXlR2oqm47RlopoDvrRUJCaSuxaWl8zs+dDnKNYma9kia+VU Bcz/KWsHhCJtKp4jq7u14B9awTMd3m9NU4RtQY7JMRKa1eT+hYutheVdlpUQY1axG0s8 Jr2aAvpY6f8dmVYsRVcNlsZW9BEWFMu+R4w12iOqzO31a85O2ZY/tVqkllTCZ4G/Atjx 9gkYdb9Y6puZbodbfGDZa5fVdS9p46PVmWc21/5cMfZHSXgvSBHEHGpNqNxsI8DqomFD 1YPw== X-Gm-Message-State: APjAAAVHZ4wz3ay3/jsMOxO/dl2AeJM7VhXVITrKHrJYBtJkcoM2IQPS HcHyf6MniyJtXTihNzdCYmaAzb+Z X-Google-Smtp-Source: APXvYqwBAXBvuRX2hMF3QFD2VJxgi+pQ7TGkAQqJHN0/viveFZtGz+QMWMdt38SVUpSMJP7oLOODag== X-Received: by 2002:aa7:8c84:: with SMTP id p4mr54610982pfd.164.1555039269195; Thu, 11 Apr 2019 20:21:09 -0700 (PDT) Received: from ?IPv6:2601:646:9600:e494:d8a:730f:c589:c301? ([2601:646:9600:e494:d8a:730f:c589:c301]) by smtp.gmail.com with ESMTPSA id g4sm10009758pfc.75.2019.04.11.20.21.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 20:21:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Thu, 11 Apr 2019 20:21:06 -0700 Cc: Robert Raszuk , Robert Raszuk , SPRING WG , "ipv6@ietf.org" , lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <95D431A8-12BF-4025-9A50-5A5580EAD0F7@gmail.com> References: To: Mark Smith Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 03:21:12 -0000 So it looks like SR is either turning out to be like LISP or BIER, or both. S= o where is the unique value? The next step is you=E2=80=99ll need a control plane (where discussions have= begun) where it makes SR even more like LISP and support for multicast (whe= re discussions have begun) where it makes SR even more like BIER.=20 Dino > On Apr 11, 2019, at 7:59 PM, Mark Smith wrote: >=20 > Hi Robert, >=20 > Sorry not to get back to you sooner. >=20 >> On Mon, 1 Apr 2019 at 01:40, Robert Raszuk wrote: >>=20 >> Hi Mark, >>=20 > >>=20 >> Since you correctly observed that now SID can be 32 bit and that is simil= ar to the size of IPv4 my fundamental question is why not use something whic= h already exists instead of defining some sort of new from scratch ? >>=20 >> It will be perfectly fine to have full proper SRv6 with SRH and LISP or V= ector Routing as an alternative options. I really do not see a room or need f= or yet one more mapping plane. What problem does it solve which would not be= already solved elsewhere ? >>=20 >=20 > Well, there seems to be or have been concerns about the overhead of > using 128 bit SIDs in IPv6. That seemed to be the motivation for EH > insertion. >=20 > I sympathise with the overhead concern, although I'd be quite happy to > put up with the overhead and bandwidth costs of full IPv6-in-IPv6 > tunnelling in comparison to non-commodity operations like inserting > the SRH EH into existing IPv6 packets to avoid that overhead. > Bandwidth is always getting cheaper. >=20 > I think the value in using IPv6 as the transport for SR is that IPv6 > is becoming and will be the future the commodity layer 3 protocol. > MPLS may be fairly commodity, however IPv6 will be more so, and I > think the reason is that it is an end-to-end protocol that hosts use > (I think this is also why Ethernet has become the dominant link-layer > protocol, even for WAN links). >=20 > So if SR wants to benefit from and leverage IPv6's commodification, > then it needs to be limited to commodity IPv6 operations. If it > deviates, then it isn't commodity IPv6 any more. >=20 > So my motivation for suggesting 32 bit SIDs in IPv6, and I'm guessing > Ron's too for his smaller variable SIDs proposal including 32 bits, is > to try to reduce the overhead of SR over IPv6, while also retaining > commodity IPv6 operation. >=20 > Regards, > Mark. From nobody Fri Apr 12 07:26:18 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3091203BE for ; Fri, 12 Apr 2019 07:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 94DGmqt-_Z-0 for ; Fri, 12 Apr 2019 07:26:05 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 771D0120757 for ; Fri, 12 Apr 2019 07:26:02 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id v20so11364944qtv.12 for ; Fri, 12 Apr 2019 07:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MBfSWMwrVEodV4RF7TPkS8BzUOKnYeniZin9hoE0rU8=; b=Wki8kckKxH6sHRDLGiuWLbaIwurhrqKYvCkvJQuGqgMQcoyXwAPBu6REXeMXDG0OyI sGeJqW/fMZ1PSejI5zQ4HFkr0idc24l4z0ZvywiZLBT4CdHj/IA8b+HyPfLHnjthzdYI 8r9PbDp+F9+Fgh5qDvBHgvXrAS3FFogCdoziH7cnYP/CrxygLHD4NzndWhM5mY/cnKH3 /1O4BFrBzJO8hdobLg9lGZfvlVePWMFzAWvVYEcsL8LP2tb9FoZEiYmc+nBkz0wtuSO1 LwJPaVdG9YND1aV8conLkqsWeDxdnP/9GmLCMHIngF+CMzTZrevBdT9vYXUR4xCcZDqL rIGQ== 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:content-transfer-encoding; bh=MBfSWMwrVEodV4RF7TPkS8BzUOKnYeniZin9hoE0rU8=; b=ZCehmjuQ7pTTAsJdQBAhEs5qU7nUzfyWvndBBEdqStSM8zwz+VjJGzKP2kjp7WCKiP kcx2P0WKRDvxob5U5sP+lG+MmonTjO8L2qNOFOd6xpWZYowQFZaOOXNGYgtyVbq8PkIB h1aLQ54RhCilWIU1ip1Ebk0xperMMh1LFclBcxBI7HmWupneQ4XR7KjRXnTncZtOU1en 4/vieT12x7rz5mLNjQd2+Ga8adtcnGEfP7sR8y6tBPifhCoWo7GtUv97cJk2ZAl6sPo2 8i0xHJRCn6T7/ZQ86DdFHdJ7JQ2+hnVXUMZWNnardkGsJDMj9/LTTfNENh6e2yqYUiGu EYGw== X-Gm-Message-State: APjAAAUaxS571AQSIhkfw52VzQtrdQGSP7u6W34d5dGlsPvD6uMwB0xB lUMThGp7B47PaTTcjsuLCXX6vtgGM6AMjaWL2PEwSQ== X-Google-Smtp-Source: APXvYqxV6TC30d4p143iSYqogn+xMTxWjoFcN69ynzxQBrGW/QhAkUOlOEiqB1YaLWDjnmgitgW4eGuiVR3MTAfWBkQ= X-Received: by 2002:a0c:963c:: with SMTP id 57mr47185938qvx.166.1555079161263; Fri, 12 Apr 2019 07:26:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Fri, 12 Apr 2019 07:25:50 -0700 Message-ID: To: Robert Raszuk Cc: Mark Smith , "ipv6@ietf.org" , SPRING WG , "lisp@ietf.org list" , Dino Farinacci Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 14:26:07 -0000 On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wrote: > > Hi Mark, > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and = a 32 bit alignment, > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 networ= k. > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may also = create some opportunities to > > leverage IPv4 support in existing protocols to suite carrying and proce= ssing 32 bit SIDs with some, possibly > > slight, modification. For example, perhaps IPv4 Address Family support = in OSPFv3 (RFC 5838) could be > > somehow leveraged to suit SR. > > > Thank you for describing your understanding of fundamentals of SR. > > I think SR while indeed started with the story of "less control plane is = good for you" now clearly has evolved into not only reduction of control pl= ane but what can be even more important to some users ability to request sp= ecific behavior via programmed functions of network elements on a per flow = basis without actually per flow or per path signalling or state. > > Yes for some it may be very useful feature and I am sure some will call i= t overload of data plane or . There is no one size fits all. > > With that let's observe that till today SR did not require any new mappin= g plane to be distributed in control plane and to be inserted into data pla= ne. This is clearly a precedent. > > Furthermore as we see in companion documents all additional network funct= ionality is being taken away from SRH and is being shifted to Destination O= ptions . > > As far as mapping plane I already pointed out in my Vector Routing propos= al that we have one already it is called BGP. One needs to also observe tha= t we as industry worked number of years of protocol suite called LISP allow= ing not only very good mapping plane, but also data plane integration. CC-i= ng lisp authors for their comments. Note also work for integrating SRv6 wit= h LISP which is already is published. > > Since you correctly observed that now SID can be 32 bit and that is simil= ar to the size of IPv4 my fundamental question is why not use something whi= ch already exists instead of defining some sort of new from scratch ? > Robert, I don't see in the SRH draft where 32 bit SIDs are defined. Can you please provide a reference? As for trying to use something that already exists, why does SR used a fixed size format for SIDs instead of a variable length format like that described in RFC6554? Similarly, why does SR define it's own TLV format instead of using Hop-by-Hop and Destination Options defined in RFC8200? Tom > It will be perfectly fine to have full proper SRv6 with SRH and LISP or V= ector Routing as an alternative options. I really do not see a room or need= for yet one more mapping plane. What problem does it solve which would not= be already solved elsewhere ? > > Kind regards, > Robert > > >>> 2) Is there an agreement that solutions which require additional per SR= path state in both control plane and now in data plane are really somethin= g we should be endorsing here ? >> >> >> I think so. >> >> My understanding of what SR is fundamentally about is to reduce control = plane state and processing. The trade-off for reduced control plane state a= nd processing is to instead carry and encode most or all of that informatio= n or its semantics as per-packet overhead. >> >> If the per-packet overhead becomes too large and expensive, then pushing= some of that information and processing back into the control plane should= be ok, as long as there is still a beneficial overall reduction in control= plane state and processing. >> >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and a= 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform SR in= an IPv6 network. >> >> As 32 bit SIDs are also the same size as IPv4 addresses, that may also c= reate some opportunities to leverage IPv4 support in existing protocols to = suite carrying and processing 32 bit SIDs with some, possibly slight, modif= ication. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 58= 38) could be somehow leveraged to suit SR. >> >> Regards, >> Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Apr 12 07:38:51 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F9E12030C; Fri, 12 Apr 2019 07:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, 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=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 UEusvZy516Qh; Fri, 12 Apr 2019 07:38:41 -0700 (PDT) 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 C7A0912027B; Fri, 12 Apr 2019 07:38:38 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3CEYIQs006133; Fri, 12 Apr 2019 07:38:37 -0700 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=a9OSjYtzj+5QBnvuGQ5MK6NOMcOP7U5Rxb3p/UeyIdw=; b=SP3vQ7HnsBBBk7uDl0oaYh5pT515nJgdh5kBOBc9AkERrV2QMe1o6tnZWoAzPWorKvWI TNjsojjJCrgWS/GAF1gf0tIpcrc1wv4mmX/CGi+04DGuEIHop/kH2hZTKHIp4k04PuAq fKkKvQNheX6nHCNk9yQMr7h1FSJCmC1GXeCVdzC/9wjh0+KlVRBvtsRcOdcQ1gyb2f5R UtrNGrByvCtDED8qsWdEdOJo3TZDU3NLk+Ht9OtQh07kTFgL3F2i16RfFMVZpykQ7D4T w/0iJcO3RIcSHj4a1eKWQcvbFFHgiKKjz+4nymg210A51HYziA3+KsQFr3r8n11euBzu 9A== Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp2055.outbound.protection.outlook.com [104.47.33.55]) by mx0a-00273201.pphosted.com with ESMTP id 2rtqjfrj2a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 12 Apr 2019 07:38:36 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB5079.namprd05.prod.outlook.com (20.177.230.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.9; Fri, 12 Apr 2019 14:38:33 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::30f9:29cf:6d50:edd4]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::30f9:29cf:6d50:edd4%4]) with mapi id 15.20.1792.009; Fri, 12 Apr 2019 14:38:33 +0000 From: Ron Bonica To: Dino Farinacci , Mark Smith CC: "ipv6@ietf.org" , SPRING WG , "lisp@ietf.org" , Robert Raszuk Thread-Topic: [spring] IPv6-compressed-routing-header-crh Thread-Index: AQHU5XwSQNUFwLkE10qv/uSLYFT0BKYiu67wgAFwpgCAAB1KAIAABz6AgAC56gCAAMlxgIASGEyAgAAGDACAALzFcA== Content-Class: Date: Fri, 12 Apr 2019 14:38:33 +0000 Message-ID: References: <95D431A8-12BF-4025-9A50-5A5580EAD0F7@gmail.com> In-Reply-To: <95D431A8-12BF-4025-9A50-5A5580EAD0F7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-04-12T14:38:31.5643727Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1eccd3cf-1a99-4a57-7aa1-08d6bf548a15 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB5079; x-ms-traffictypediagnostic: BYAPR05MB5079: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(366004)(346002)(376002)(39860400002)(199004)(189003)(13464003)(7696005)(97736004)(110136005)(76176011)(66066001)(446003)(229853002)(81166006)(81156014)(316002)(53546011)(99286004)(6506007)(478600001)(102836004)(71190400001)(6436002)(71200400001)(2906002)(26005)(186003)(93886005)(68736007)(11346002)(305945005)(966005)(486006)(14454004)(33656002)(3846002)(6116002)(476003)(25786009)(52536014)(86362001)(6246003)(4326008)(561944003)(8676002)(55016002)(105586002)(256004)(5660300002)(106356001)(7736002)(9686003)(8936002)(53936002)(74316002)(54906003)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5079; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: L9kZUFSejiynVVAHa1yMLlywAlOy+/Xnm2g2TPJdWFUpzssRcGaQ4ECC7mxJLxvVuOBihBFdeSewF18KhSe3OM7c4yiHGSA2Dlv3wfq3Cb636lbPRtvN8CPgqph3ETvp/rFKKoyZXPVKxk52Dzq7fOheYQuGY5zjjGOiCNuCzmsA2aQCYNxaaAV+ypgHNz+C0pcnVuhzKf6l74USJe+Y+r4Zy8kjsjM6arlPrniNL0ahMkgeY+DuD2N/EXHvSDcr46bDpbI0uHkrlxaXHWMGKU2Aa7eiDopmTlnvyCOVfhJ5Fa2lOknrmLXl2xo3JSGMT1Dm7GZymYEhG1tF8ezf2gI1GWCew2k6kup5YPJtPVRCtwgrEGLh7fF9n/21ywKTudxBsv5/8m6ZUW5x4OnZGQb+kGzfeAdEy5R3PQg/eB4= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 1eccd3cf-1a99-4a57-7aa1-08d6bf548a15 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 14:38:33.2964 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5079 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-12_09:, , 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-1810050000 definitions=main-1904120096 Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 14:38:43 -0000 RGlubywNCg0KUGxlYXNlIHN0YW5kIGJ5IGZvciBJU0lTIEV4dGVuc2lvbnMgVG8gU3VwcG9ydCB0 aGUgQ1JILiBBdCB0aGUgbW9tZW50LCBpdCBpcyB0ZW4gcGFnZXMgbG9uZywgaW5jbHVkaW5nIHR3 byBwYWdlcyBvZiBib2lsZXJwbGF0ZSBhbmQgdHdvIHBhZ2VzIG9mIHJlZmVyZW5jZXMuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBSb24NCg0KDQoNCkp1bmlwZXIgSW50ZXJuYWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBpcHY2IDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBP ZiBEaW5vIEZhcmluYWNjaQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTEsIDIwMTkgMTE6MjEg UE0NCj4gVG86IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb20+DQo+IENjOiBpcHY2 QGlldGYub3JnOyBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz47IGxpc3BAaWV0Zi5vcmc7IFJv YmVydA0KPiBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0Pg0KPiBTdWJqZWN0OiBSZTogW3Nwcmlu Z10gSVB2Ni1jb21wcmVzc2VkLXJvdXRpbmctaGVhZGVyLWNyaA0KPiANCj4gU28gaXQgbG9va3Mg bGlrZSBTUiBpcyBlaXRoZXIgdHVybmluZyBvdXQgdG8gYmUgbGlrZSBMSVNQIG9yIEJJRVIsIG9y IGJvdGguIFNvDQo+IHdoZXJlIGlzIHRoZSB1bmlxdWUgdmFsdWU/DQo+IA0KPiBUaGUgbmV4dCBz dGVwIGlzIHlvdeKAmWxsIG5lZWQgYSBjb250cm9sIHBsYW5lICh3aGVyZSBkaXNjdXNzaW9ucyBo YXZlIGJlZ3VuKQ0KPiB3aGVyZSBpdCBtYWtlcyBTUiBldmVuIG1vcmUgbGlrZSBMSVNQIGFuZCBz dXBwb3J0IGZvciBtdWx0aWNhc3QgKHdoZXJlDQo+IGRpc2N1c3Npb25zIGhhdmUgYmVndW4pIHdo ZXJlIGl0IG1ha2VzIFNSIGV2ZW4gbW9yZSBsaWtlIEJJRVIuDQo+IA0KPiBEaW5vDQo+IA0KPiA+ IE9uIEFwciAxMSwgMjAxOSwgYXQgNzo1OSBQTSwgTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQGdt YWlsLmNvbT4NCj4gd3JvdGU6DQo+ID4NCj4gPiBIaSBSb2JlcnQsDQo+ID4NCj4gPiBTb3JyeSBu b3QgdG8gZ2V0IGJhY2sgdG8geW91IHNvb25lci4NCj4gPg0KPiA+PiBPbiBNb24sIDEgQXByIDIw MTkgYXQgMDE6NDAsIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PiB3cm90ZToNCj4g Pj4NCj4gPj4gSGkgTWFyaywNCj4gPj4NCj4gPiA8c25pcD4NCj4gPj4NCj4gPj4gU2luY2UgeW91 IGNvcnJlY3RseSBvYnNlcnZlZCB0aGF0IG5vdyBTSUQgY2FuIGJlIDMyIGJpdCBhbmQgdGhhdCBp cyBzaW1pbGFyDQo+IHRvIHRoZSBzaXplIG9mIElQdjQgbXkgZnVuZGFtZW50YWwgcXVlc3Rpb24g aXMgd2h5IG5vdCB1c2Ugc29tZXRoaW5nIHdoaWNoDQo+IGFscmVhZHkgZXhpc3RzIGluc3RlYWQg b2YgZGVmaW5pbmcgc29tZSBzb3J0IG9mIG5ldyAgZnJvbSBzY3JhdGNoID8NCj4gPj4NCj4gPj4g SXQgd2lsbCBiZSBwZXJmZWN0bHkgZmluZSB0byBoYXZlIGZ1bGwgcHJvcGVyIFNSdjYgd2l0aCBT UkggYW5kIExJU1Agb3INCj4gVmVjdG9yIFJvdXRpbmcgYXMgYW4gYWx0ZXJuYXRpdmUgb3B0aW9u cy4gSSByZWFsbHkgZG8gbm90IHNlZSBhIHJvb20gb3IgbmVlZCBmb3INCj4geWV0IG9uZSBtb3Jl IG1hcHBpbmcgcGxhbmUuIFdoYXQgcHJvYmxlbSBkb2VzIGl0IHNvbHZlIHdoaWNoIHdvdWxkIG5v dCBiZQ0KPiBhbHJlYWR5IHNvbHZlZCBlbHNld2hlcmUgPw0KPiA+Pg0KPiA+DQo+ID4gV2VsbCwg dGhlcmUgc2VlbXMgdG8gYmUgb3IgaGF2ZSBiZWVuIGNvbmNlcm5zIGFib3V0IHRoZSBvdmVyaGVh ZCBvZg0KPiA+IHVzaW5nIDEyOCBiaXQgU0lEcyBpbiBJUHY2LiBUaGF0IHNlZW1lZCB0byBiZSB0 aGUgbW90aXZhdGlvbiBmb3IgRUgNCj4gPiBpbnNlcnRpb24uDQo+ID4NCj4gPiBJIHN5bXBhdGhp c2Ugd2l0aCB0aGUgb3ZlcmhlYWQgY29uY2VybiwgYWx0aG91Z2ggSSdkIGJlIHF1aXRlIGhhcHB5 IHRvDQo+ID4gcHV0IHVwIHdpdGggdGhlIG92ZXJoZWFkIGFuZCBiYW5kd2lkdGggY29zdHMgb2Yg ZnVsbCBJUHY2LWluLUlQdjYNCj4gPiB0dW5uZWxsaW5nIGluIGNvbXBhcmlzb24gdG8gbm9uLWNv bW1vZGl0eSBvcGVyYXRpb25zIGxpa2UgaW5zZXJ0aW5nDQo+ID4gdGhlIFNSSCBFSCBpbnRvIGV4 aXN0aW5nIElQdjYgcGFja2V0cyB0byBhdm9pZCB0aGF0IG92ZXJoZWFkLg0KPiA+IEJhbmR3aWR0 aCBpcyBhbHdheXMgZ2V0dGluZyBjaGVhcGVyLg0KPiA+DQo+ID4gSSB0aGluayB0aGUgdmFsdWUg aW4gdXNpbmcgSVB2NiBhcyB0aGUgdHJhbnNwb3J0IGZvciBTUiBpcyB0aGF0IElQdjYNCj4gPiBp cyBiZWNvbWluZyBhbmQgd2lsbCBiZSB0aGUgZnV0dXJlIHRoZSBjb21tb2RpdHkgbGF5ZXIgMyBw cm90b2NvbC4NCj4gPiBNUExTIG1heSBiZSBmYWlybHkgY29tbW9kaXR5LCBob3dldmVyIElQdjYg d2lsbCBiZSBtb3JlIHNvLCBhbmQgSQ0KPiA+IHRoaW5rIHRoZSByZWFzb24gaXMgdGhhdCBpdCBp cyBhbiBlbmQtdG8tZW5kIHByb3RvY29sIHRoYXQgaG9zdHMgdXNlDQo+ID4gKEkgdGhpbmsgdGhp cyBpcyBhbHNvIHdoeSBFdGhlcm5ldCBoYXMgYmVjb21lIHRoZSBkb21pbmFudCBsaW5rLWxheWVy DQo+ID4gcHJvdG9jb2wsIGV2ZW4gZm9yIFdBTiBsaW5rcykuDQo+ID4NCj4gPiBTbyBpZiBTUiB3 YW50cyB0byBiZW5lZml0IGZyb20gYW5kIGxldmVyYWdlIElQdjYncyBjb21tb2RpZmljYXRpb24s DQo+ID4gdGhlbiBpdCBuZWVkcyB0byBiZSBsaW1pdGVkIHRvIGNvbW1vZGl0eSBJUHY2IG9wZXJh dGlvbnMuIElmIGl0DQo+ID4gZGV2aWF0ZXMsIHRoZW4gaXQgaXNuJ3QgY29tbW9kaXR5IElQdjYg YW55IG1vcmUuDQo+ID4NCj4gPiBTbyBteSBtb3RpdmF0aW9uIGZvciBzdWdnZXN0aW5nIDMyIGJp dCBTSURzIGluIElQdjYsIGFuZCBJJ20gZ3Vlc3NpbmcNCj4gPiBSb24ncyB0b28gZm9yIGhpcyBz bWFsbGVyIHZhcmlhYmxlIFNJRHMgcHJvcG9zYWwgaW5jbHVkaW5nIDMyIGJpdHMsIGlzDQo+ID4g dG8gdHJ5IHRvIHJlZHVjZSB0aGUgb3ZlcmhlYWQgb2YgU1Igb3ZlciBJUHY2LCB3aGlsZSBhbHNv IHJldGFpbmluZw0KPiA+IGNvbW1vZGl0eSBJUHY2IG9wZXJhdGlvbi4NCj4gPg0KPiA+IFJlZ2Fy ZHMsDQo+ID4gTWFyay4NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdy b3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVl c3RzOiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+ IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pcHY2JmQ9RHdJR2FRJmM9SEFrWXVo NjNyc3VocjZTDQo+IGNiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj1GY2g5RlE4MnNpci1C b0x4ODRoS3VLd2wtDQo+IEFXRjJFZnBIY0F3ckRUaEtQOCZtPWRueEo0WnpZR3ZaOHVLRnl0cjhQ TU1IaTV1RDM1ejVBQ0F4NjcNCj4gV0VuZ1hjJnM9ODNxMVQ4Tk9iYU5TMW9tUW9KUktzUS1iM2Et eC1fdkliRV9MWm12aVBKNCZlPQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From nobody Fri Apr 12 09:40:04 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E871202FC; Fri, 12 Apr 2019 09:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KN3wLHOmlj7Q; Fri, 12 Apr 2019 09:40:00 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 39940120371; Fri, 12 Apr 2019 09:39:57 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id a96so5387026pla.6; Fri, 12 Apr 2019 09:39:57 -0700 (PDT) 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=gp4KxVwJxFgpGp+mQhao7iOpBPKzPbVPUwujZuIKvZI=; b=kedC5BnJYGcI/KaXV4JVfvqf1dC7REE/WQg6ME+dLfG2m66QFCXAg2qrWpQjeauOD0 zlxU/MJMoAb0TabVJ07VsXkAOItXxqnhPJTvH6DzNo230mgLR/LADPbp+kE6JYPCYoiw 7gZYrttmrWntbupzefBpMsqC4rBLI+TLHkJ/i8L/01wAekxzPwLZhEVbvB/LYD2rIVbz 1gG+6PFmeMOIClsXzN/fDBc6MuqTuVk6OZZmSIlHxROGWUsZEHR4E9txv5q2HPUsweOt qNIE7MeEUHbdC4NdUmaaQYCz6J38rvLkJe7c8XUZGN3XO8e1kJv9luItfVdHG1P90BXY IbRw== 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=gp4KxVwJxFgpGp+mQhao7iOpBPKzPbVPUwujZuIKvZI=; b=rwU9Wyd7/q9YN1J0SHckeAi0VAwUyIfNoB5XG8IqqaegCp1QqU3aafbTY8BT3yHOxg b9yiFOuvwJl1wEs5CwLxqldH5NXz2rpyGK2fnhMMU/ESmkZtNkZefT/u9ElS8L/qCuP+ IP+3KlmGKPgsmqZ67EWJNG+Cpeqw3b4ae5EPKQ9QZUQaeqVnhJel1Kpp7uwXIYrzgd91 6XV7ndL7z9kXnmER1o+E+Ah6eyxV5XQZ/oA0WXeqiOGSGFy5imw3WKmtMKbJouZKHz+X eISQ+bMsmoeuG7jMnbJWvQRk0INZuP9z3QpP/bbt4UeIdtGqUN37rxDfRrEnLqgcqPeO Pt9w== X-Gm-Message-State: APjAAAWvUh7X661tJyj9K1kzBVRpNlFeNJNpKYCqZikAWFMv5kbelIU5 LOofdVeqAar3Myv9VfPpK2Y= X-Google-Smtp-Source: APXvYqwhoqT4X8wzdSMIxrUTdsVODBvsbo9tTungI/PAuY8Y/yaZEj/mkc4OFvrKXvzWZfvSmuppTg== X-Received: by 2002:a17:902:585:: with SMTP id f5mr27396243plf.116.1555087196282; Fri, 12 Apr 2019 09:39:56 -0700 (PDT) Received: from [10.97.50.55] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id 17sm58696167pgz.52.2019.04.12.09.39.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Apr 2019 09:39:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Fri, 12 Apr 2019 09:39:54 -0700 Cc: Mark Smith , "ipv6@ietf.org" , SPRING WG , "lisp@ietf.org" , Robert Raszuk Content-Transfer-Encoding: quoted-printable Message-Id: <40F707BF-6BF0-4907-8E27-118CD5FE3005@gmail.com> References: <95D431A8-12BF-4025-9A50-5A5580EAD0F7@gmail.com> To: Ron Bonica X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:40:03 -0000 Sounds good for a intra-AS solution. Dino > On Apr 12, 2019, at 7:38 AM, Ron Bonica wrote: >=20 > Dino, >=20 > Please stand by for ISIS Extensions To Support the CRH. At the moment, = it is ten pages long, including two pages of boilerplate and two pages = of references. >=20 > = Ron >=20 >=20 >=20 > Juniper Internal >=20 >> -----Original Message----- >> From: ipv6 On Behalf Of Dino Farinacci >> Sent: Thursday, April 11, 2019 11:21 PM >> To: Mark Smith >> Cc: ipv6@ietf.org; SPRING WG ; lisp@ietf.org; Robert >> Raszuk >> Subject: Re: [spring] IPv6-compressed-routing-header-crh >>=20 >> So it looks like SR is either turning out to be like LISP or BIER, or = both. So >> where is the unique value? >>=20 >> The next step is you=E2=80=99ll need a control plane (where = discussions have begun) >> where it makes SR even more like LISP and support for multicast = (where >> discussions have begun) where it makes SR even more like BIER. >>=20 >> Dino >>=20 >>> On Apr 11, 2019, at 7:59 PM, Mark Smith >> wrote: >>>=20 >>> Hi Robert, >>>=20 >>> Sorry not to get back to you sooner. >>>=20 >>>> On Mon, 1 Apr 2019 at 01:40, Robert Raszuk = wrote: >>>>=20 >>>> Hi Mark, >>>>=20 >>> >>>>=20 >>>> Since you correctly observed that now SID can be 32 bit and that is = similar >> to the size of IPv4 my fundamental question is why not use something = which >> already exists instead of defining some sort of new from scratch ? >>>>=20 >>>> It will be perfectly fine to have full proper SRv6 with SRH and = LISP or >> Vector Routing as an alternative options. I really do not see a room = or need for >> yet one more mapping plane. What problem does it solve which would = not be >> already solved elsewhere ? >>>>=20 >>>=20 >>> Well, there seems to be or have been concerns about the overhead of >>> using 128 bit SIDs in IPv6. That seemed to be the motivation for EH >>> insertion. >>>=20 >>> I sympathise with the overhead concern, although I'd be quite happy = to >>> put up with the overhead and bandwidth costs of full IPv6-in-IPv6 >>> tunnelling in comparison to non-commodity operations like inserting >>> the SRH EH into existing IPv6 packets to avoid that overhead. >>> Bandwidth is always getting cheaper. >>>=20 >>> I think the value in using IPv6 as the transport for SR is that IPv6 >>> is becoming and will be the future the commodity layer 3 protocol. >>> MPLS may be fairly commodity, however IPv6 will be more so, and I >>> think the reason is that it is an end-to-end protocol that hosts use >>> (I think this is also why Ethernet has become the dominant = link-layer >>> protocol, even for WAN links). >>>=20 >>> So if SR wants to benefit from and leverage IPv6's commodification, >>> then it needs to be limited to commodity IPv6 operations. If it >>> deviates, then it isn't commodity IPv6 any more. >>>=20 >>> So my motivation for suggesting 32 bit SIDs in IPv6, and I'm = guessing >>> Ron's too for his smaller variable SIDs proposal including 32 bits, = is >>> to try to reduce the overhead of SR over IPv6, while also retaining >>> commodity IPv6 operation. >>>=20 >>> Regards, >>> Mark. >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_ipv6&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6S >> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3DFch9FQ82sir-BoLx84hKuKwl- >> AWF2EfpHcAwrDThKP8&m=3DdnxJ4ZzYGvZ8uKFytr8PMMHi5uD35z5ACAx67 >> WEngXc&s=3D83q1T8NObaNS1omQoJRKsQ-b3a-x-_vIbE_LZmviPJ4&e=3D >> -------------------------------------------------------------------- From nobody Fri Apr 12 13:49:07 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E63B120615; Fri, 12 Apr 2019 13:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=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 v4_nk2x93UGr; Fri, 12 Apr 2019 13:48:57 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 C9FE1120059; Fri, 12 Apr 2019 13:48:57 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id o74so9575719ota.3; Fri, 12 Apr 2019 13:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=W03jy2TD9zvOCvHF4aS1E01RQNW36Kj59LVnKVj6x8M=; b=m8s8wyq6OiHnb2wSkxy7/30URuC4oyZD31O0VgzHWiNCceFEtCDByjjkISiFdurBHJ mMzNe7tNn5SFy3iXFRMhNQFcsZc5aHfOWx4aGoOxUuk8djeX1wm2SqRh7xRH2GjWNOAE KCfUEclSv7hV2VqDs4bVzr61oVte0Q07caoWci3C4v9eioQ3124SIHjC6vRPAF2lBsPt C3i4olm+D8THseyjBDO4/WK5avYATrTfQT1XVDOq4lH5c8LmgXocu3usUWc8i1lR5aCI 21uI8y67XWtrJaUWVZFNcyNxd/x/n/HRy0mdO5/buOzpQWyUSqFTb10ZZZrddsgKlxR0 kQmA== 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:content-transfer-encoding; bh=W03jy2TD9zvOCvHF4aS1E01RQNW36Kj59LVnKVj6x8M=; b=ohnVR2c8Bu5J8fgxObEnKra0w02i0IkoPYoAM24BPsbOveehHqS8BOkuSFG8Q26du3 FYZO/EXLOV4CUtCKYaduHjpDrOyZgeRObljv+CFnrC/UL0mTa35iAockWiRumA/akQl0 TJz7Vok+rZ4kZJa8WUDX0V4LDfQscf0C5CR9AW1rFhfAKDqDa/WSYKji70HcnIaS6Rn5 M/+9vaF5A15hs3W21EVHHYY7owr0qYuJa5DGb1EazoDKp/ClQU4WxbiWGDLntFzE+aWm lupXXiSifskkxcZtjMjguGvtdOodp89b9G6/IG61DGTn4xaAVvxu6tgYKeF7umV8cA8I PASQ== X-Gm-Message-State: APjAAAVmyM7C5iKIzxYJDYvykddHpWs5dQ7aKDoNn1jJef6A13j1LNo1 Rjcw/K1I60T/gozSq8ZtCrjQ2KJErzKPK4S0Fvs= X-Google-Smtp-Source: APXvYqyQnD3LNbg9t1b/iHYXtf6XXQtXJ05am0BwGjW0m2vq5ngase1Dj5THavUagdmXqvGXICOeSlvQmmwePyZt2TE= X-Received: by 2002:a9d:62c8:: with SMTP id z8mr39239234otk.144.1555102137057; Fri, 12 Apr 2019 13:48:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Sat, 13 Apr 2019 06:48:30 +1000 Message-ID: To: Tom Herbert Cc: Robert Raszuk , Mark Smith , "ipv6@ietf.org" , SPRING WG , "lisp@ietf.org list" , Dino Farinacci Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 20:49:00 -0000 Hi Tom, On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wrote: > > > > Hi Mark, > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary an= d a 32 bit alignment, > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 netw= ork. > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may als= o create some opportunities to > > > leverage IPv4 support in existing protocols to suite carrying and pro= cessing 32 bit SIDs with some, possibly > > > slight, modification. For example, perhaps IPv4 Address Family suppor= t in OSPFv3 (RFC 5838) could be > > > somehow leveraged to suit SR. > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > I think SR while indeed started with the story of "less control plane i= s good for you" now clearly has evolved into not only reduction of control = plane but what can be even more important to some users ability to request = specific behavior via programmed functions of network elements on a per flo= w basis without actually per flow or per path signalling or state. > > > > Yes for some it may be very useful feature and I am sure some will call= it overload of data plane or . There is no one size fits all. > > > > With that let's observe that till today SR did not require any new mapp= ing plane to be distributed in control plane and to be inserted into data p= lane. This is clearly a precedent. > > > > Furthermore as we see in companion documents all additional network fun= ctionality is being taken away from SRH and is being shifted to Destination= Options . > > > > As far as mapping plane I already pointed out in my Vector Routing prop= osal that we have one already it is called BGP. One needs to also observe t= hat we as industry worked number of years of protocol suite called LISP all= owing not only very good mapping plane, but also data plane integration. CC= -ing lisp authors for their comments. Note also work for integrating SRv6 w= ith LISP which is already is published. > > > > Since you correctly observed that now SID can be 32 bit and that is sim= ilar to the size of IPv4 my fundamental question is why not use something w= hich already exists instead of defining some sort of new from scratch ? > > > Robert, > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > please provide a reference? > To clarify, I've been thinking about the idea of a smaller SID size for IPv6 for a while now (since inserting EHs came up), and thought about what would be a generic single size that might suit SR that wasn't the same size as an IPv6 address. 32 bits seemed suitable to me, although if people wanted bigger, I'd be suggesting 64 bits (not entirely coincidentally the common IID size.) Ron and others have written this draft, which supports SIDS of various sizes - 8, 16 or 32 bits - that triggered this discussion. "The IPv6 Compressed Routing Header (CRH)" https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 Regards, Mark. > As for trying to use something that already exists, why does SR used a > fixed size format for SIDs instead of a variable length format like > that described in RFC6554? Similarly, why does SR define it's own TLV > format instead of using Hop-by-Hop and Destination Options defined in > RFC8200? > > Tom > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP or= Vector Routing as an alternative options. I really do not see a room or ne= ed for yet one more mapping plane. What problem does it solve which would n= ot be already solved elsewhere ? > > > > Kind regards, > > Robert > > > > > >>> 2) Is there an agreement that solutions which require additional per = SR path state in both control plane and now in data plane are really someth= ing we should be endorsing here ? > >> > >> > >> I think so. > >> > >> My understanding of what SR is fundamentally about is to reduce contro= l plane state and processing. The trade-off for reduced control plane state= and processing is to instead carry and encode most or all of that informat= ion or its semantics as per-packet overhead. > >> > >> If the per-packet overhead becomes too large and expensive, then pushi= ng some of that information and processing back into the control plane shou= ld be ok, as long as there is still a beneficial overall reduction in contr= ol plane state and processing. > >> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and= a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform SR = in an IPv6 network. > >> > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may also= create some opportunities to leverage IPv4 support in existing protocols t= o suite carrying and processing 32 bit SIDs with some, possibly slight, mod= ification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC = 5838) could be somehow leveraged to suit SR. > >> > >> Regards, > >> Mark. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- From nobody Fri Apr 12 15:09:37 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B4A120316 for ; Fri, 12 Apr 2019 15:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 zPBD-fMqbNqb for ; Fri, 12 Apr 2019 15:09:32 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 D1963120153 for ; Fri, 12 Apr 2019 15:09:31 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id v20so13002509qtv.12 for ; Fri, 12 Apr 2019 15:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6VMG5ROx8h3XR0PB0SaEKDaaR9EzFF6kKsLkMqb5EZg=; b=vNdw0q1XATjueoxlN0D3Mg+xvp1xmnX8LNtmKVLJsIaKqt2ahNinNR0NJhypIVLBLz Je3C4vqrRyYwLDDSqaBRqfHPJ53MjcfELrq7JS/v6KJlr7EqP1DTRdHU45c/e5j+ufw0 ffb9oPWz9w96wPNO/94Vv1HqZLcqjAT1S332KdHWLYT3mV/NuJb2dEvFiJo/dBWCmzO0 na0uyMH8tlNOls/XtJGEo/fbjtgLHv5YwxC6g6OI71S5/qvVtq9LWfnmxNuij2OezvXj 13/jH4m9qNYBgqXj9SOeTac9Xc/P1kGNqFKg1HA2Qg992fn7yGuUL24n5leIAQBbgaSM yAnw== 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:content-transfer-encoding; bh=6VMG5ROx8h3XR0PB0SaEKDaaR9EzFF6kKsLkMqb5EZg=; b=rMPEY+D0C3SOwibR+dZdyNqPXPcPh7IeZ6zfn3U4nMfWuolO3/uClmc7W6rhLcP8zg 12Ddw5ibds3+kZm3XEpr706PHe75HYa7xHCfPHijcaJrDKITOLi9HyW0XpAOLS1HkaXl c8SoOAZF22tE9C9pB5zTiImoQf/hTNDZn0EpUv5OVSVk1XnQ4HOK9UWlklJFiZB/fM8d uUMeT88phHqzvd0R6/1YYPy6JhnPFm7hVawA3/1cTU26H602zztvSpDhLFoxDSxwrj0f m8HHxlY3dhoA+/Koo0qd1WzTw6baf5tprp2XQAUAn4GP9kQmvGcJOiT1F2QsT+AdXFLs KHUQ== X-Gm-Message-State: APjAAAX1OKk+8sFEQ8EuHZO+R2+cgQN97yi+XyZLhhCprBe5HiPXne6H y+OXrmNF72daHoSdlOQdNBDW/Ua1FM8l0bjBCQz/1A== X-Google-Smtp-Source: APXvYqygkqTelTlRQafxcfxO+j+F4vmiId2Q5Nq4FVY/w069HDMDFZDJEJr+YPrWIlLbHtn61B+iQ8GKEgrdAXRV/oQ= X-Received: by 2002:ac8:1833:: with SMTP id q48mr49382100qtj.133.1555106970736; Fri, 12 Apr 2019 15:09:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Fri, 12 Apr 2019 15:09:18 -0700 Message-ID: To: Mark Smith Cc: Robert Raszuk , "ipv6@ietf.org" , SPRING WG , "lisp@ietf.org list" , Dino Farinacci Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 22:09:34 -0000 On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrote: > > Hi Tom, > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wrote= : > > > > > > Hi Mark, > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary = and a 32 bit alignment, > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 ne= twork. > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may a= lso create some opportunities to > > > > leverage IPv4 support in existing protocols to suite carrying and p= rocessing 32 bit SIDs with some, possibly > > > > slight, modification. For example, perhaps IPv4 Address Family supp= ort in OSPFv3 (RFC 5838) could be > > > > somehow leveraged to suit SR. > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > I think SR while indeed started with the story of "less control plane= is good for you" now clearly has evolved into not only reduction of contro= l plane but what can be even more important to some users ability to reques= t specific behavior via programmed functions of network elements on a per f= low basis without actually per flow or per path signalling or state. > > > > > > Yes for some it may be very useful feature and I am sure some will ca= ll it overload of data plane or . There is no one size fits all. > > > > > > With that let's observe that till today SR did not require any new ma= pping plane to be distributed in control plane and to be inserted into data= plane. This is clearly a precedent. > > > > > > Furthermore as we see in companion documents all additional network f= unctionality is being taken away from SRH and is being shifted to Destinati= on Options . > > > > > > As far as mapping plane I already pointed out in my Vector Routing pr= oposal that we have one already it is called BGP. One needs to also observe= that we as industry worked number of years of protocol suite called LISP a= llowing not only very good mapping plane, but also data plane integration. = CC-ing lisp authors for their comments. Note also work for integrating SRv6= with LISP which is already is published. > > > > > > Since you correctly observed that now SID can be 32 bit and that is s= imilar to the size of IPv4 my fundamental question is why not use something= which already exists instead of defining some sort of new from scratch ? > > > > > Robert, > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > please provide a reference? > > > > To clarify, I've been thinking about the idea of a smaller SID size > for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.) > > Ron and others have written this draft, which supports SIDS of various > sizes - 8, 16 or 32 bits - that triggered this discussion. > Mark, Why not just put a SID length field in the header (like RFC6554 but more generic). That would allow lengths of 1-16 bytes. Additional flags could be used to indicate the semantics of the entries. For instance, they might be actual addresses (128 bits for IPv6, 32 bits for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) where the rest of the address can be inferred, indices into a table, labels, etc. Tom > "The IPv6 Compressed Routing Header (CRH)" > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > Regards, > Mark. > > > > As for trying to use something that already exists, why does SR used a > > fixed size format for SIDs instead of a variable length format like > > that described in RFC6554? Similarly, why does SR define it's own TLV > > format instead of using Hop-by-Hop and Destination Options defined in > > RFC8200? > > > > Tom > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP = or Vector Routing as an alternative options. I really do not see a room or = need for yet one more mapping plane. What problem does it solve which would= not be already solved elsewhere ? > > > > > > Kind regards, > > > Robert > > > > > > > > >>> 2) Is there an agreement that solutions which require additional pe= r SR path state in both control plane and now in data plane are really some= thing we should be endorsing here ? > > >> > > >> > > >> I think so. > > >> > > >> My understanding of what SR is fundamentally about is to reduce cont= rol plane state and processing. The trade-off for reduced control plane sta= te and processing is to instead carry and encode most or all of that inform= ation or its semantics as per-packet overhead. > > >> > > >> If the per-packet overhead becomes too large and expensive, then pus= hing some of that information and processing back into the control plane sh= ould be ok, as long as there is still a beneficial overall reduction in con= trol plane state and processing. > > >> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary a= nd a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform S= R in an IPv6 network. > > >> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may al= so create some opportunities to leverage IPv4 support in existing protocols= to suite carrying and processing 32 bit SIDs with some, possibly slight, m= odification. For example, perhaps IPv4 Address Family support in OSPFv3 (RF= C 5838) could be somehow leveraged to suit SR. > > >> > > >> Regards, > > >> Mark. > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- From nobody Fri Apr 12 15:13:25 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C09120222 for ; Fri, 12 Apr 2019 15:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 L15JrhfXIwAz for ; Fri, 12 Apr 2019 15:13:15 -0700 (PDT) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 020E1120153 for ; Fri, 12 Apr 2019 15:13:14 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id p20so13026472qtc.9 for ; Fri, 12 Apr 2019 15:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2fS0ON8kaiWudWg7vve7pxDdwWA26K2xrSxjKNGWg9w=; b=QABvau4fNK2d0vEqzZ54DL5zz8ryWJ6OORefhk7ernYpBrkuzkjRbUQvubSNZBQ8tx domTomFPCNO1EGnc9BUKYrdCAzRuXye0yj5JneQOaSBbiF8x5MdRmcS2e+Pqu1avkgaK fFU9FvdonlQYFjLJCEhW+4rbW+WcxWgQ32vkUD1mz6rEz2LmjInGq079Y41c5EJde1DO k+SPRGe/zmodVq385rI2rU8qpx4JaoHE0En5+fxRuEYWjj1yD56GkS6PUBnyzu8vQqfl 3iVYVJnzqi7lO/HrusETD14dxCgImfwm9OXqxu0Oy2LajpoOjPscoNDFQqJ7kSuny3Yj 5xdQ== 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=2fS0ON8kaiWudWg7vve7pxDdwWA26K2xrSxjKNGWg9w=; b=JBHTc4WVnyUtgevPzTGBDvawu0B3GDgq/LJ1gUO6pfhlW6beO88xHrX77SrXpgpRzZ VFItROOhw03B/TUh+obyA0QS71f6aF6pPceUbnEPytnzdoEsyhenw8/vM6ZK0uz6Ae2b tmhUzU8dShu3Hgt+11q832+DETKwvDXGtVhCmLJ87s5neIfgbVwwb1YMdX0eTwMgaXRE CNEPm7rUFDNuAz+/CqRfjn1CfV829tGkG82FsWk2O5xuOuDL3cVDZqIDwJxmg3gXE4Ol CpUk85XPMAgCrxQfwCPD3gY89KdG0KoZOM+X1m8oZDTLP3gs4XoLIJXZmbLbKPgDrHl1 L1CQ== X-Gm-Message-State: APjAAAX7ZQlj7Hg7HF1AJ0w9quypJELJrnvYMmIjiOqiOxDreTa+PIg1 0x1BXjUlLcSu4m0GPMHFJl2pnuEUmCQ8W3wKrxTE3A== X-Google-Smtp-Source: APXvYqzq0RMAqky4X0q0VmY+CyT894sOqVBjsEDAEJCtGxQwtKItqhsWYrXwW/FqTP+WUvJucHC+LkCjg1kgdTnCbJ8= X-Received: by 2002:a0c:b095:: with SMTP id o21mr47372292qvc.162.1555107193998; Fri, 12 Apr 2019 15:13:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Sat, 13 Apr 2019 00:13:03 +0200 Message-ID: To: Tom Herbert Cc: Mark Smith , "ipv6@ietf.org" , SPRING WG , "lisp@ietf.org list" , Dino Farinacci Content-Type: multipart/alternative; boundary="000000000000e2e32a05865c9b21" Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 22:13:18 -0000 --000000000000e2e32a05865c9b21 Content-Type: text/plain; charset="UTF-8" Hi Tom, I already suggested this on March 30th ... *"PS. But if you choose to go ahead with CRH I would highly advise to make your CRH SID a variable length. "* No feedback/response was received from authors. Thx, R. On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert wrote: > On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrote: > > > > Hi Tom, > > > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: > > > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk > wrote: > > > > > > > > Hi Mark, > > > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary > and a 32 bit alignment, > > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 > network. > > > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may > also create some opportunities to > > > > > leverage IPv4 support in existing protocols to suite carrying and > processing 32 bit SIDs with some, possibly > > > > > slight, modification. For example, perhaps IPv4 Address Family > support in OSPFv3 (RFC 5838) could be > > > > > somehow leveraged to suit SR. > > > > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > > > I think SR while indeed started with the story of "less control > plane is good for you" now clearly has evolved into not only reduction of > control plane but what can be even more important to some users ability to > request specific behavior via programmed functions of network elements on a > per flow basis without actually per flow or per path signalling or state. > > > > > > > > Yes for some it may be very useful feature and I am sure some will > call it overload of data plane or . There is no one size fits all. > > > > > > > > With that let's observe that till today SR did not require any new > mapping plane to be distributed in control plane and to be inserted into > data plane. This is clearly a precedent. > > > > > > > > Furthermore as we see in companion documents all additional network > functionality is being taken away from SRH and is being shifted to > Destination Options . > > > > > > > > As far as mapping plane I already pointed out in my Vector Routing > proposal that we have one already it is called BGP. One needs to also > observe that we as industry worked number of years of protocol suite called > LISP allowing not only very good mapping plane, but also data plane > integration. CC-ing lisp authors for their comments. Note also work for > integrating SRv6 with LISP which is already is published. > > > > > > > > Since you correctly observed that now SID can be 32 bit and that is > similar to the size of IPv4 my fundamental question is why not use > something which already exists instead of defining some sort of new from > scratch ? > > > > > > > Robert, > > > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > > please provide a reference? > > > > > > > To clarify, I've been thinking about the idea of a smaller SID size > > for IPv6 for a while now (since inserting EHs came up), and thought > > about what would be a generic single size that might suit SR that > > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > > me, although if people wanted bigger, I'd be suggesting 64 bits (not > > entirely coincidentally the common IID size.) > > > > Ron and others have written this draft, which supports SIDS of various > > sizes - 8, 16 or 32 bits - that triggered this discussion. > > > Mark, > > Why not just put a SID length field in the header (like RFC6554 but > more generic). That would allow lengths of 1-16 bytes. Additional > flags could be used to indicate the semantics of the entries. For > instance, they might be actual addresses (128 bits for IPv6, 32 bits > for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) > where the rest of the address can be inferred, indices into a table, > labels, etc. > > Tom > > > "The IPv6 Compressed Routing Header (CRH)" > > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > > > Regards, > > Mark. > > > > > > > As for trying to use something that already exists, why does SR used a > > > fixed size format for SIDs instead of a variable length format like > > > that described in RFC6554? Similarly, why does SR define it's own TLV > > > format instead of using Hop-by-Hop and Destination Options defined in > > > RFC8200? > > > > > > Tom > > > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP > or Vector Routing as an alternative options. I really do not see a room or > need for yet one more mapping plane. What problem does it solve which would > not be already solved elsewhere ? > > > > > > > > Kind regards, > > > > Robert > > > > > > > > > > > >>> 2) Is there an agreement that solutions which require additional > per SR path state in both control plane and now in data plane are really > something we should be endorsing here ? > > > >> > > > >> > > > >> I think so. > > > >> > > > >> My understanding of what SR is fundamentally about is to reduce > control plane state and processing. The trade-off for reduced control plane > state and processing is to instead carry and encode most or all of that > information or its semantics as per-packet overhead. > > > >> > > > >> If the per-packet overhead becomes too large and expensive, then > pushing some of that information and processing back into the control plane > should be ok, as long as there is still a beneficial overall reduction in > control plane state and processing. > > > >> > > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary > and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform > SR in an IPv6 network. > > > >> > > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may > also create some opportunities to leverage IPv4 support in existing > protocols to suite carrying and processing 32 bit SIDs with some, possibly > slight, modification. For example, perhaps IPv4 Address Family support in > OSPFv3 (RFC 5838) could be somehow leveraged to suit SR. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------- > --000000000000e2e32a05865c9b21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

I already suggested this on Mar= ch 30th ...=C2=A0

"PS. But if you choose to go ahead with CRH = I would highly advise to make your CRH SID a variable length. "=

<= /span>
No = feedback/response was received from authors.=C2=A0

Thx,
R.

On= Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:
On Fri, Apr 12, 2019 at 1:48 PM Mark Smith &l= t;markzzzsmith@= gmail.com> wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote: > > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform = SR in an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network = elements on a per flow basis without actually per flow or per path signalli= ng or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not requi= re any new mapping plane to be distributed in control plane and to be inser= ted into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane inte= gration. CC-ing lisp authors for their comments. Note also work for integra= ting SRv6 with LISP which is already is published.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new=C2=A0 f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. C= an you
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID siz= e
> for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable t= o
> me, although if people wanted bigger, I'd be suggesting 64 bits (n= ot
> entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-= bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's= own TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequ= ate to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support i= n OSPFv3 (RFC 5838) could be somehow leveraged to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf= .org
> > > Administrative Requests: https://www.ietf.o= rg/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------
--000000000000e2e32a05865c9b21-- From nobody Sat Apr 13 16:22:28 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70780120286; Sat, 13 Apr 2019 16:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=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 9DsbmBajGec6; Sat, 13 Apr 2019 16:22:24 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 474D81203D6; Sat, 13 Apr 2019 16:22:24 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id u15so11463709otq.10; Sat, 13 Apr 2019 16:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BpliNzDOXEXeGrQIP95L58hfgxkKCr/0TzZOSU+vC4M=; b=WjOXS3CGVr98ukKprhXA37O6/WGw1IW6o0Y5i8SFaeGW56t4FADfrFT2V2tTTg/CrW 4hGJX0jnQqOZR3/pSv9luMhPoH5kxxlKQRN2TdS02+eFX8dQfcjTHjut+D16v34b990X ZSs3hGew9DvIIl5ldznoZ8R2AFJeQzOoX9uJKQRWzGFdTUS81ZMO++dCdxl9iUATPoyC YcUBASHL0xFJHfvSgb+rKMY9rO2uW1qcLx0sf+V+KhoirSrDdxk3tDRrnIXt8/e6BNiH koYjCHG9zHyJSQi1uVA4WbY1QqIAbWhdojLvBgdNY4aab8xUiOkps9hXoB9/dsY/WFIe qUqw== 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:content-transfer-encoding; bh=BpliNzDOXEXeGrQIP95L58hfgxkKCr/0TzZOSU+vC4M=; b=n436M5z1MbF+YJFjycpcWjOeTwGZNJJP1J3i5+EelAUTYBBBjtHE0pNDtl2xR1p1GZ zEBJ77hN4xrJRMB8wlHsJIEj5LvCMEIYUzrWUV0UV+5eiD8IFHUOK8kgfd/lSBLXJCkn trLEpu1h33ducj2skSMaF8mbYi4Fv2mNKdxm4asL6FY/EAAnMfAlijO8V3X/RsFUSI1S 5jOZaYtuu2nceUnMLwWoJctdWsAvbrxyHTnn8JWQHjbo48QfuV7CUkrEF6KBuCJzJx5j rFCCnFt9iDoy8iDEUQqo6/2gxuOXBFpu67os2plBcF37UT8EUmN+mMTphWUJXR1Q2HtJ l1qA== X-Gm-Message-State: APjAAAVMUMp1SWHmx9ZtQfLFfSyG7a83r3wCcPZNIf2aBvyDAmpQkYy7 o46kYH0+WMit2uOyqmAKLw1tU1QNXopPxtOVghA= X-Google-Smtp-Source: APXvYqzl6L/9E+5zqe/rw5sE5olIRoWiIibtmQZMdGkGkuaTpAW1wYPq8LWBmEVKDlZh+X4S1VY2zwSS6A2h3hJ/kyg= X-Received: by 2002:a9d:7ad9:: with SMTP id m25mr42761638otn.75.1555197743504; Sat, 13 Apr 2019 16:22:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Sun, 14 Apr 2019 09:21:56 +1000 Message-ID: To: Tom Herbert Cc: Robert Raszuk , "ipv6@ietf.org" , SPRING WG , "lisp@ietf.org list" , Dino Farinacci Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 23:22:27 -0000 Hi Tom, On Sat, 13 Apr 2019 at 08:09, Tom Herbert wrote: > > > To clarify, I've been thinking about the idea of a smaller SID size > > for IPv6 for a while now (since inserting EHs came up), and thought > > about what would be a generic single size that might suit SR that > > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > > me, although if people wanted bigger, I'd be suggesting 64 bits (not > > entirely coincidentally the common IID size.) > > > > Ron and others have written this draft, which supports SIDS of various > > sizes - 8, 16 or 32 bits - that triggered this discussion. > > > Mark, > > Why not just put a SID length field in the header (like RFC6554 but > more generic). That would allow lengths of 1-16 bytes. More generally, I think it is better to have a single size field that is a "one-size-fits-all" for all foreseeable use cases, and some reasonable overhead to try to cater for future unforeseeable use cases. It is simpler in design, implementation and operation. A major operational issue is created if you happen to underestimate the size you need, and have to go through your network increasing it. For a production network, that sort of project is a bit like what replacing an air plane engine would be like while the plane is flying. The simplest and safest way to avoid a future size upgrade is to pick a single size that far exceeds all likely use cases. Apparently that was the practice with CLNS variable length addresses, where people commonly picked 20 octet addresses regardless, with that practice used to then decide against variable length IPv6 addresses. So people preferred and tended to "one-size-fits-all" addressing anyway when they had a variable length addressing choice. It has been common in RFC1918 addressed networks to universally or near universally use /24s for the same reasons. I think RFC6554's complexity is justified because the links it is operating over are very bandwidth and MTU constrained. More general scenarios don't have those sorts of constraints, and constant technology evolution is also constantly reducing or eliminating them. >Additional > flags could be used to indicate the semantics of the entries. For > instance, they might be actual addresses (128 bits for IPv6, 32 bits > for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) > where the rest of the address can be inferred, indices into a table, > labels, etc. While not addressing the parts of addresses case, the other choice is to encode semantics in the addresses indicating what they're representing and how they should be processed. We already do that in many cases - unicast address scopes and types (Link-Local scope vs global ULA/GUA), and functions such as 6to4 or discard (i.e. 100::/64), and multicast address scopes and multicast forwarding via replication at network junctions itself. Regards, Mark. > > Tom > > > "The IPv6 Compressed Routing Header (CRH)" > > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > > > Regards, > > Mark. > > > > > > > As for trying to use something that already exists, why does SR used = a > > > fixed size format for SIDs instead of a variable length format like > > > that described in RFC6554? Similarly, why does SR define it's own TLV > > > format instead of using Hop-by-Hop and Destination Options defined in > > > RFC8200? > > > > > > Tom > > > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LIS= P or Vector Routing as an alternative options. I really do not see a room o= r need for yet one more mapping plane. What problem does it solve which wou= ld not be already solved elsewhere ? > > > > > > > > Kind regards, > > > > Robert > > > > > > > > > > > >>> 2) Is there an agreement that solutions which require additional = per SR path state in both control plane and now in data plane are really so= mething we should be endorsing here ? > > > >> > > > >> > > > >> I think so. > > > >> > > > >> My understanding of what SR is fundamentally about is to reduce co= ntrol plane state and processing. The trade-off for reduced control plane s= tate and processing is to instead carry and encode most or all of that info= rmation or its semantics as per-packet overhead. > > > >> > > > >> If the per-packet overhead becomes too large and expensive, then p= ushing some of that information and processing back into the control plane = should be ok, as long as there is still a beneficial overall reduction in c= ontrol plane state and processing. > > > >> > > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary= and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform= SR in an IPv6 network. > > > >> > > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may = also create some opportunities to leverage IPv4 support in existing protoco= ls to suite carrying and processing 32 bit SIDs with some, possibly slight,= modification. For example, perhaps IPv4 Address Family support in OSPFv3 (= RFC 5838) could be somehow leveraged to suit SR. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > -------------------------------------------------------------------= - > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------= - From nobody Sun Apr 14 16:55:20 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7AF1200EF; Sun, 14 Apr 2019 16:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, 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=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 VU5xtmAbiIK7; Sun, 14 Apr 2019 16:55:07 -0700 (PDT) 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 05E621200A2; Sun, 14 Apr 2019 16:55:06 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3ENstcZ001255; Sun, 14 Apr 2019 16:55:01 -0700 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=/ASgUu6ofrZndLBR57juRM2yEse2omOLK5//KU2OT0s=; b=hVCLmNdurvNdtIdkZq6IxwBUaiCcpRQX9c8rVPrKwuaVIM6uhEKuFjoM9tQVBEs92G5k t+DZJFqYF6ELRH32IhFgrT12lr8RiEUhOGv1ILbGwnKKBFJEnOZcYQYtPYFluaOgKsOJ j9r4NvESi31R1mHJJn/xDhU+5lBzNlpS+X1RfFmWKpmPWRgS8mtDbB2kqrxkNVz46+yW Ii1Rd3NL1/v36lgC5ZBw36Y47avShT8xjDQ49NgOOUwv0eicSs7cN/GgxTEmmYBv/PeF f7G9m8//GNi+22V+Z6M6vq6cd8eUbzAkH2TPQLuuoCdgZqqJPfunUrpLso0UOKXVyk6w Gg== Received: from nam05-by2-obe.outbound.protection.outlook.com (mail-by2nam05lp2055.outbound.protection.outlook.com [104.47.50.55]) by mx0a-00273201.pphosted.com with ESMTP id 2ruf1k1whr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 14 Apr 2019 16:55:01 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB4182.namprd05.prod.outlook.com (52.135.200.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Sun, 14 Apr 2019 23:54:58 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::30f9:29cf:6d50:edd4]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::30f9:29cf:6d50:edd4%4]) with mapi id 15.20.1813.009; Sun, 14 Apr 2019 23:54:58 +0000 From: Ron Bonica To: Robert Raszuk , Tom Herbert CC: SPRING WG , "ipv6@ietf.org" , Mark Smith , Dino Farinacci , "lisp@ietf.org list" Thread-Topic: [spring] IPv6-compressed-routing-header-crh Thread-Index: AQHU5XwSQNUFwLkE10qv/uSLYFT0BKYiu67wgAFwpgCAAB1KAIAABz6AgAC56gCAAMlxgIAS2BIAgABq6gCAABaTAIAAAQyAgAM/fDA= Content-Class: Date: Sun, 14 Apr 2019 23:54:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-04-14T23:54:56.8382267Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 134a5581-4193-4705-891e-08d6c1349a26 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB4182; x-ms-traffictypediagnostic: BYAPR05MB4182: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 00073DB75F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(346002)(376002)(136003)(189003)(199004)(6246003)(9326002)(7696005)(316002)(7736002)(99286004)(53546011)(5660300002)(446003)(11346002)(790700001)(74316002)(6116002)(3846002)(476003)(486006)(76176011)(71200400001)(66066001)(71190400001)(2906002)(6506007)(102836004)(606006)(256004)(14444005)(86362001)(55016002)(6306002)(54896002)(4326008)(561944003)(6436002)(53936002)(105586002)(229853002)(81166006)(81156014)(33656002)(25786009)(68736007)(478600001)(9686003)(52536014)(26005)(93886005)(8936002)(186003)(110136005)(54906003)(97736004)(106356001)(966005)(8676002)(236005)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4182; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: akYvkfbpwjOxwoeHtsYHcJ26NLMmoDXpa+ygKNzRICG+cUyh85OwcavAlOBBQyrV8K6Pu2LzlcQT4Q2hjkndEdrCLwFd3NO9vql7UC/UE5L+BjJychdIfNC7oqAYbayOuw8ZMjQ5hrZ5pg6c7hx8rZnrKFVHn5DLxY/fJN0wUGU8gFmzJ3lxcAZckQnu/6kRLNiWYcihvPn5Q1UD8hpnzscUFWxABk+t0bhbygmBVEPOFKxHTaHamaDlNDknz88ImMzfiy4FxPn81CIaPNCcZ7+P05pr6MMqlWe/uYGjavZsPDIAYwHqxtlngsnNSsy5oiNJ+JDFDwyrtnJJ43CCIe+5y0wrNg7n/kjRoLaGT7FF8wE2vve53xNahFHExvL1JtH9aNKz25H/vF8wMiB50UXcNwKDJkD7983JsOqqLIc= Content-Type: multipart/alternative; boundary="_000_BYAPR05MB4245D2964D8F90A3A76356C0AE2A0BYAPR05MB4245namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 134a5581-4193-4705-891e-08d6c1349a26 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2019 23:54:58.6339 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4182 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-14_08:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904140179 Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2019 23:55:10 -0000 --_000_BYAPR05MB4245D2964D8F90A3A76356C0AE2A0BYAPR05MB4245namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, In order to make the CRH ASIC-friendly, we have the following constraints: * Support only a small handful of SID lengths * If at all possible, make them align on word boundaries Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should= support a length greater than 32? Is there some length less than 32 that w= ould be beneficial? Ron Juniper Internal From: spring On Behalf Of Robert Raszuk Sent: Friday, April 12, 2019 6:13 PM To: Tom Herbert Cc: SPRING WG ; ipv6@ietf.org; Mark Smith ; Dino Farinacci ; lisp@ietf.org list Subject: Re: [spring] IPv6-compressed-routing-header-crh Hi Tom, I already suggested this on March 30th ... "PS. But if you choose to go ahead with CRH I would highly advise to make y= our CRH SID a variable length. " No feedback/response was received from authors. Thx, R. On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert > wrote: On Fri, Apr 12, 2019 at 1:48 PM Mark Smith > wrote: > > Hi Tom, > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert > wrote: > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk > wrote: > > > > > > Hi Mark, > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary = and a 32 bit alignment, > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 ne= twork. > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may a= lso create some opportunities to > > > > leverage IPv4 support in existing protocols to suite carrying and p= rocessing 32 bit SIDs with some, possibly > > > > slight, modification. For example, perhaps IPv4 Address Family supp= ort in OSPFv3 (RFC 5838) could be > > > > somehow leveraged to suit SR. > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > I think SR while indeed started with the story of "less control plane= is good for you" now clearly has evolved into not only reduction of contro= l plane but what can be even more important to some users ability to reques= t specific behavior via programmed functions of network elements on a per f= low basis without actually per flow or per path signalling or state. > > > > > > Yes for some it may be very useful feature and I am sure some will ca= ll it overload of data plane or . There is no one size fits all. > > > > > > With that let's observe that till today SR did not require any new ma= pping plane to be distributed in control plane and to be inserted into data= plane. This is clearly a precedent. > > > > > > Furthermore as we see in companion documents all additional network f= unctionality is being taken away from SRH and is being shifted to Destinati= on Options . > > > > > > As far as mapping plane I already pointed out in my Vector Routing pr= oposal that we have one already it is called BGP. One needs to also observe= that we as industry worked number of years of protocol suite called LISP a= llowing not only very good mapping plane, but also data plane integration. = CC-ing lisp authors for their comments. Note also work for integrating SRv6= with LISP which is already is published. > > > > > > Since you correctly observed that now SID can be 32 bit and that is s= imilar to the size of IPv4 my fundamental question is why not use something= which already exists instead of defining some sort of new from scratch ? > > > > > Robert, > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > please provide a reference? > > > > To clarify, I've been thinking about the idea of a smaller SID size > for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.) > > Ron and others have written this draft, which supports SIDS of various > sizes - 8, 16 or 32 bits - that triggered this discussion. > Mark, Why not just put a SID length field in the header (like RFC6554 but more generic). That would allow lengths of 1-16 bytes. Additional flags could be used to indicate the semantics of the entries. For instance, they might be actual addresses (128 bits for IPv6, 32 bits for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) where the rest of the address can be inferred, indices into a table, labels, etc. Tom > "The IPv6 Compressed Routing Header (CRH)" > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > Regards, > Mark. > > > > As for trying to use something that already exists, why does SR used a > > fixed size format for SIDs instead of a variable length format like > > that described in RFC6554? Similarly, why does SR define it's own TLV > > format instead of using Hop-by-Hop and Destination Options defined in > > RFC8200? > > > > Tom > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP = or Vector Routing as an alternative options. I really do not see a room or = need for yet one more mapping plane. What problem does it solve which would= not be already solved elsewhere ? > > > > > > Kind regards, > > > Robert > > > > > > > > >>> 2) Is there an agreement that solutions which require additional pe= r SR path state in both control plane and now in data plane are really some= thing we should be endorsing here ? > > >> > > >> > > >> I think so. > > >> > > >> My understanding of what SR is fundamentally about is to reduce cont= rol plane state and processing. The trade-off for reduced control plane sta= te and processing is to instead carry and encode most or all of that inform= ation or its semantics as per-packet overhead. > > >> > > >> If the per-packet overhead becomes too large and expensive, then pus= hing some of that information and processing back into the control plane sh= ould be ok, as long as there is still a beneficial overall reduction in con= trol plane state and processing. > > >> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary a= nd a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform S= R in an IPv6 network. > > >> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may al= so create some opportunities to leverage IPv4 support in existing protocols= to suite carrying and processing 32 bit SIDs with some, possibly slight, m= odification. For example, perhaps IPv4 Address Family support in OSPFv3 (RF= C 5838) could be somehow leveraged to suit SR. > > >> > > >> Regards, > > >> Mark. > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf..org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- --_000_BYAPR05MB4245D2964D8F90A3A76356C0AE2A0BYAPR05MB4245namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ro= bert,

=  

In or= der to make the CRH ASIC-friendly, we have the following constraints:<= /o:p>

=  

  • Support only a small handful of SID length= s
  • If at all possible, make them align on wor= d boundaries

=  

Curre= ntly, we support 8, 16 and 32 bytes. Do you see a reason why we should supp= ort a length greater than 32? Is there some length less than 32 that would = be beneficial?

=  

 = ;            &n= bsp;            = ;            &n= bsp;            = ;  Ron

=  

=  

 

Juniper Internal=

From: spring <spring-bounces@ietf.org> = On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <tom@herbertland.com>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Mark Smith <= ;markzzzsmith@gmail.com>; Dino Farinacci <farinacci@gmail.com>; li= sp@ietf.org list <lisp@ietf.org>
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

Hi Tom,

 

I already suggested this on March 30th ... 

 

"PS. But if you choose to go ahead with CRH I would hig= hly advise to make your CRH SID a variable length. "

 

No feedback/response was received from authors. 

 

Thx,
R.

 

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:=

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.c= om> wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote: > > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform SR i= n an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network elements on a per flow basis without actually per flo= w or per path signalling or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not require a= ny new mapping plane to be distributed in control plane and to be inserted = into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comm= ents. Note also work for integrating SRv6 with LISP which is already is pub= lished.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new  f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. Can y= ou
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID size > for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable to > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's own= TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequate = to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leverage= d to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf= ..org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------

--_000_BYAPR05MB4245D2964D8F90A3A76356C0AE2A0BYAPR05MB4245namp_-- From nobody Wed Apr 17 19:00:09 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDC0120288; Wed, 17 Apr 2019 19:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 BBr25t2RPHWV; Wed, 17 Apr 2019 19:00:03 -0700 (PDT) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (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 092DF12029D; Wed, 17 Apr 2019 19:00:02 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id s83so304444qke.3; Wed, 17 Apr 2019 19:00:01 -0700 (PDT) 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=apwRvFbJHIZmrPFtFzS2YG0EWBSQhmsdKCjkxOf8djI=; b=IM6ciqWKeg3VLbWhA7mX2qewIIkN7EDSmDvl31RzsucmD7GlnMWkuO5woDE7Qkxt0m TOZOMiBWyFOU29L0k670t0coRA/gb5G0rP5TNrcPsRxEr5EwqL/aR0QmNFwCA5LDgRkn XMpegBM5UrEQ/vtrW/RqKl8cDRWgeYiugHSg5Ezb3bPpkR6dqY3hkRaTn60magvWR+D9 fPavUr18uV5SPRDl0EHztT265CrT3T14FuBJZTbm1l5Lnq3/mpHkxchmJCctz5/3LOn2 JRaIyXZvzTOZOb50UK4sEDUlyuWj45ZOf9iy9O0fnWly54yhC8vVgjOiK5MQ0wsnC+d+ XUYA== 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=apwRvFbJHIZmrPFtFzS2YG0EWBSQhmsdKCjkxOf8djI=; b=D5lhLKAwGbxz63J/2zDLEIyufw6hK8nWhJJej7vSvb/iALCx4K/sYg6qJQ3gD6Wql6 FD88mkvQlBOjT33nMU03VMkYqhcKv3p2elEDZK3i1eJ2WeIwzG5aOw9TsmabS0cna+J5 BhgQDvGSb572iFhS89Dr8h1HgIkj4Ox2j8uKvpuJW12dTP7BkeuY2x2Wvi3RNNZcLstX J/Y1VpDzAavUpfCROThJ0au+PizCIISjO8MvNu3y+VzvMwDVQmfU934n669Qd8Ac1K9T 2y7vDJQIAaRKSfUzyLKumx+JmyqTDO2hw6At42BfwzlwDZD5Ie2mRhIN66gqw5kdMc2y kv9A== X-Gm-Message-State: APjAAAXi+0VcpABmLf8UgKIE+yLeUNBJ3dyMeVOojoAzKwt4uZOS0ffm +rjYMsWMY5tzAaHQYHMdHMdikV1W X-Google-Smtp-Source: APXvYqyYAhLH3j/rI1PLH2UbYUUinZAbUJs3gtDVQfTKdmYnw4v+Z8ydq7ikabfqCfUgsy4ZS7ND8g== X-Received: by 2002:a37:553:: with SMTP id 80mr71586921qkf.243.1555552800769; Wed, 17 Apr 2019 19:00:00 -0700 (PDT) Received: from ?IPv6:2600:1003:b027:ef02:f445:be7e:a3e0:6382? ([2600:1003:b027:ef02:f445:be7e:a3e0:6382]) by smtp.gmail.com with ESMTPSA id t30sm286299qkj.56.2019.04.17.18.59.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 18:59:59 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A86F88CE-54D6-4935-B390-06C2222A1DFB Mime-Version: 1.0 (1.0) From: Gyan Mishra X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Wed, 17 Apr 2019 21:59:58 -0400 Cc: Robert Raszuk , Tom Herbert , SPRING WG , "ipv6@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Transfer-Encoding: 7bit Message-Id: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> References: To: Ron Bonica Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 02:00:07 -0000 --Apple-Mail-A86F88CE-54D6-4935-B390-06C2222A1DFB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree to make the SID align on word boundaries but I am thinking the softw= are should have hardware independence if at all possible. I think 32 bit is a reasonable size. Gyan S. Mishra IT Network Engineering & Technology Consultant Routing & Switching / Service Provider MPLS & IPv6 Expert www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT Mobile =E2=80=93 202-734-1000 Sent from my iPhone > On Apr 14, 2019, at 7:54 PM, Ron Bonica wrote: >=20 > Hi Robert, > =20 > In order to make the CRH ASIC-friendly, we have the following constraints:= > =20 > Support only a small handful of SID lengths > If at all possible, make them align on word boundaries > =20 > Currently, we support 8, 16 and 32 bytes. Do you see a reason why we shoul= d support a length greater than 32? Is there some length less than 32 that w= ould be beneficial? > =20 > Ron > =20 > =20 > =20 > Juniper Internal > From: spring On Behalf Of Robert Raszuk > Sent: Friday, April 12, 2019 6:13 PM > To: Tom Herbert > Cc: SPRING WG ; ipv6@ietf.org; Mark Smith ; Dino Farinacci ; lisp@ietf.org list > Subject: Re: [spring] IPv6-compressed-routing-header-crh > =20 > Hi Tom, > =20 > I already suggested this on March 30th ...=20 > =20 > "PS. But if you choose to go ahead with CRH I would highly advise to make y= our CRH SID a variable length. " > =20 > No feedback/response was received from authors.=20 > =20 > Thx, > R. > =20 > On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert wrote: > On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrote:= > > > > Hi Tom, > > > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: > > > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wrot= e: > > > > > > > > Hi Mark, > > > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary= and a 32 bit alignment, > > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 n= etwork. > > > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may a= lso create some opportunities to > > > > > leverage IPv4 support in existing protocols to suite carrying and p= rocessing 32 bit SIDs with some, possibly > > > > > slight, modification. For example, perhaps IPv4 Address Family sup= port in OSPFv3 (RFC 5838) could be > > > > > somehow leveraged to suit SR. > > > > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > > > I think SR while indeed started with the story of "less control plan= e is good for you" now clearly has evolved into not only reduction of contro= l plane but what can be even more important to some users ability to request= specific behavior via programmed functions of network elements on a per flo= w basis without actually per flow or per path signalling or state. > > > > > > > > Yes for some it may be very useful feature and I am sure some will c= all it overload of data plane or . There is no one size fits all. > > > > > > > > With that let's observe that till today SR did not require any new m= apping plane to be distributed in control plane and to be inserted into data= plane. This is clearly a precedent. > > > > > > > > Furthermore as we see in companion documents all additional network f= unctionality is being taken away from SRH and is being shifted to Destinatio= n Options . > > > > > > > > As far as mapping plane I already pointed out in my Vector Routing p= roposal that we have one already it is called BGP. One needs to also observe= that we as industry worked number of years of protocol suite called LISP al= lowing not only very good mapping plane, but also data plane integration. CC= -ing lisp authors for their comments. Note also work for integrating SRv6 wi= th LISP which is already is published. > > > > > > > > Since you correctly observed that now SID can be 32 bit and that is s= imilar to the size of IPv4 my fundamental question is why not use something w= hich already exists instead of defining some sort of new from scratch ? > > > > > > > Robert, > > > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > > please provide a reference? > > > > > > > To clarify, I've been thinking about the idea of a smaller SID size > > for IPv6 for a while now (since inserting EHs came up), and thought > > about what would be a generic single size that might suit SR that > > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > > me, although if people wanted bigger, I'd be suggesting 64 bits (not > > entirely coincidentally the common IID size.) > > > > Ron and others have written this draft, which supports SIDS of various > > sizes - 8, 16 or 32 bits - that triggered this discussion. > > > Mark, >=20 > Why not just put a SID length field in the header (like RFC6554 but > more generic). That would allow lengths of 1-16 bytes. Additional > flags could be used to indicate the semantics of the entries. For > instance, they might be actual addresses (128 bits for IPv6, 32 bits > for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) > where the rest of the address can be inferred, indices into a table, > labels, etc. >=20 > Tom >=20 > > "The IPv6 Compressed Routing Header (CRH)" > > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > > > Regards, > > Mark. > > > > > > > As for trying to use something that already exists, why does SR used a= > > > fixed size format for SIDs instead of a variable length format like > > > that described in RFC6554? Similarly, why does SR define it's own TLV > > > format instead of using Hop-by-Hop and Destination Options defined in > > > RFC8200? > > > > > > Tom > > > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP= or Vector Routing as an alternative options. I really do not see a room or n= eed for yet one more mapping plane. What problem does it solve which would n= ot be already solved elsewhere ? > > > > > > > > Kind regards, > > > > Robert > > > > > > > > > > > >>> 2) Is there an agreement that solutions which require additional p= er SR path state in both control plane and now in data plane are really some= thing we should be endorsing here ? > > > >> > > > >> > > > >> I think so. > > > >> > > > >> My understanding of what SR is fundamentally about is to reduce con= trol plane state and processing. The trade-off for reduced control plane sta= te and processing is to instead carry and encode most or all of that informa= tion or its semantics as per-packet overhead. > > > >> > > > >> If the per-packet overhead becomes too large and expensive, then pu= shing some of that information and processing back into the control plane sh= ould be ok, as long as there is still a beneficial overall reduction in cont= rol plane state and processing. > > > >> > > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary a= nd a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform SR= in an IPv6 network. > > > >> > > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may a= lso create some opportunities to leverage IPv4 support in existing protocols= to suite carrying and processing 32 bit SIDs with some, possibly slight, mo= dification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5= 838) could be somehow leveraged to suit SR. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > --------------------------------------------------------------------= > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf...org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > --------------------------------------------------------------------= > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-A86F88CE-54D6-4935-B390-06C2222A1DFB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I agree to make the SID= align on word boundaries but I am thinking the software should have hardwar= e independence if at all possible.

I think 32 bit i= s a reasonable size.


Gyan S. Mishra
<= div>IT Network Eng= ineering & Technology Consultant
Routing & Switching / Service Provid= er MPLS & IPv6 Expert


Sent from my iPhone

On Apr 14, 2= 019, at 7:54 PM, Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:

<= /div>
=

Hi Rob= ert,

&= nbsp;

In ord= er to make the CRH ASIC-friendly, we have the following constraints:

&= nbsp;

  • Support only a small handful of SID lengths=
  • If at all possible, make them align on word= boundaries

&= nbsp;

Curren= tly, we support 8, 16 and 32 bytes. Do you see a reason why we should suppor= t a length greater than 32? Is there some length less than 32 that would be b= eneficial?

&= nbsp;

 =             &nbs= p;            &n= bsp;            =             &nbs= p; Ron

&= nbsp;

&= nbsp;

 

Juniper Internal<= /o:p>

From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <tom@herber= tland.com>
Cc: SPRING WG <spring@ietf.org<= /a>>; ipv6@ietf.org; Mark Smith <= markzzzsmith@gmail.com>; Di= no Farinacci <farinacci@gmail.com<= /a>>; lisp@ietf.org list <lisp@ietf.org>
Subject: Re: [spring] IPv6-compressed-routing-header-crh

 

Hi Tom,

 

I already suggested this on March 30th ... =

 

"PS. But if you choose to go ahead with CRH I would highly adv= ise to make your CRH SID a variable length. "

 

No feedback/response was received from authors. <= /p>

 

Thx,
R.

 

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.com= > wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote:
> > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform SR in= an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite car= rying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address = Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals o= f SR.
> > >
> > > I think SR while indeed started with the story of "less contr= ol plane is good for you" now clearly has evolved into not only reduction of= control plane but what can be even more important to some users ability to r= equest specific behavior via programmed functions of network elements on a per flow basis without actually per flow= or per path signalling or state.
> > >
> > > Yes for some it may be very useful feature and I am sure some= will call it overload of data plane or . There is no one size fits all.
= > > >
> > > With that let's observe that till today SR did not require an= y new mapping plane to be distributed in control plane and to be inserted in= to data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional n= etwork functionality is being taken away from SRH and is being shifted to De= stination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector Ro= uting proposal that we have one already it is called BGP. One needs to also o= bserve that we as industry worked number of years of protocol suite called L= ISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comme= nts. Note also work for integrating SRv6 with LISP which is already is publi= shed.
> > >
> > > Since you correctly observed that now SID can be 32 bit and t= hat is similar to the size of IPv4 my fundamental question is why not use so= mething which already exists instead of defining some sort of new  from= scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. Can yo= u
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID size
= > for IPv6 for a while now (since inserting EHs came up), and thought
= > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable to
= > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various<= br> > sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR us= ed a
> > fixed size format for SIDs instead of a variable length format lik= e
> > that described in RFC6554? Similarly, why does SR define it's own T= LV
> > format instead of using Hop-by-Hop and Destination Options defined= in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH a= nd LISP or Vector Routing as an alternative options. I really do not see a r= oom or need for yet one more mapping plane. What problem does it solve which= would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which require= additional per SR path state in both control plane and now in data plane ar= e really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to r= educe control plane state and processing. The trade-off for reduced control p= lane state and processing is to instead carry and encode most or all of that= information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensiv= e, then pushing some of that information and processing back into the contro= l plane should be ok, as long as there is still a beneficial overall reducti= on in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet= boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to= perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses, t= hat may also create some opportunities to leverage IPv4 support in existing p= rotocols to suite carrying and processing 32 bit SIDs with some, possibly sl= ight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leveraged= to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > -------------------------------------------------------------= -------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.= ..org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > -------------------------------------------------------------= -------

--------= ------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailma= n/listinfo/ipv6
----------------------------------------= ----------------------------
= --Apple-Mail-A86F88CE-54D6-4935-B390-06C2222A1DFB-- From nobody Wed Apr 17 20:03:06 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27061201B0 for ; Wed, 17 Apr 2019 20:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 ulQhYaPjT4r7 for ; Wed, 17 Apr 2019 20:02:55 -0700 (PDT) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 64D25120291 for ; Wed, 17 Apr 2019 20:02:55 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id s15so699414qtn.3 for ; Wed, 17 Apr 2019 20:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sBBBVQ8Cy8NV1N8lgyAqBey9Yo3TzSBOTPM4Tv9h4po=; b=e1vHfxMkzW6ZmQfx93lsgbwkwPi1dZSIF6aHIt/fMDKiqO4mNwaK5sDb/WbZAvH/0I 0fnwnxE9/JHuwKuqVJhZhQHDRVsveZQp+TGQLaV2ap13pE3hN3HZDQYihpFmhUtBIPrl mZT7N9eYUEyoMeFivkLGH1a5LnITOq0mkP4Xa9sQdLcCrYng5TQhFG+p0s7QNXZslbWg /XCxGcPYsbIPiMJ5CXdZNZfVNI8L0HIIpetrkHWx675FTwb6bKoJ6Q8LOodTd6sZYgdk NZaL/z7KbaSPqjd6WSeCn/GgpEEekFg6PaUpw6ssIkR0HR8GVbiBdT0BEtWdDZy18bMD iqjQ== 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:content-transfer-encoding; bh=sBBBVQ8Cy8NV1N8lgyAqBey9Yo3TzSBOTPM4Tv9h4po=; b=CisxVJuTCGjcB8CXAE2BOyz8yG3yuBEYY8dK4Uz4xQ+zfwJoHDb0xsXu8F8Bp2Idak sgerGh+jIcswMxzBVqJqWFsP92v3XpeRS8ZTvAetkRmYQDXJpayl1jg+cPNpoRprRfSw H2Lrw5xXrZ+RyNqGVr8RzfhmLz4Yro9wOeCWo2zK4HGs+dIpVQIXUDuL1EDz56yW/LfD bdGp1KYUTfGxugAZP9wM2FOgsAhgOkm3a3rnqukVEQO7UktnOiGoPzjMsyuvLjXpoHiG +OxGlQDdKESks7HI+4fd9e3QebHiKIz40pkSk1Al4fQAEpGf2EOyXVQV/8GBc5ubtBZo udyA== X-Gm-Message-State: APjAAAVc8kTPmzEGxuH+9GD1pfTLwdRFsRAqnQWYlq0U2e+havhNEUuq KsNIAuIwhMDPoJM0kkp2m6tsetJQVOfWsFSyutCTpQ== X-Google-Smtp-Source: APXvYqwx8tR0r+0u47Jpmb20I344E+KzbCRSXr4q9BJooJSU5FXRlNynbck3lNqP0Bk0U3U26QpnEXpBmmJWIkuRtH8= X-Received: by 2002:aed:2196:: with SMTP id l22mr71120413qtc.226.1555556574195; Wed, 17 Apr 2019 20:02:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Wed, 17 Apr 2019 20:02:42 -0700 Message-ID: To: Ron Bonica Cc: Robert Raszuk , SPRING WG , "ipv6@ietf.org" , Mark Smith , Dino Farinacci , "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 03:02:59 -0000 On Sun, Apr 14, 2019 at 4:55 PM Ron Bonica wrote: > > Hi Robert, > > > > In order to make the CRH ASIC-friendly, we have the following constraints= : > > > > Support only a small handful of SID lengths > If at all possible, make them align on word boundaries > > > > Currently, we support 8, 16 and 32 bytes. Do you see a reason why we shou= ld support a length greater than 32? Is there some length less than 32 that= would be beneficial? > Ron, I think the term "Compressed Routing Header" is a bit of a misnomer. It's really a "Mapped Routing Header" where the SIDs are presumably smaller that the addresses that they map to. But, mapping requires configuration and state in the network in order for it to work. For instance, if I just want to send a packet to a list of nodes by IPv6 address, it seems like I'd need to use something else besides CRH (or set up a possibly complex control plane that might be overkill for this scenario). We can do that in segment routing since it carries 128 bit addresses, but then that creates giant headers which is what we're trying to avoid in the first place. A compressed format would remove redundant information that can be reconstructed at the hops without additional state beyond what is in the packet. For instance, compressing a list of IPv6 addresses is possible if they all share a common prefix that can be compressed-- which is probably very likely in the closed domains that it seems like source routing is targeted to. Tom > > > Ron > > > > > > > > Juniper Internal > > From: spring On Behalf Of Robert Raszuk > Sent: Friday, April 12, 2019 6:13 PM > To: Tom Herbert > Cc: SPRING WG ; ipv6@ietf.org; Mark Smith ; Dino Farinacci ; lisp@ietf.org list > Subject: Re: [spring] IPv6-compressed-routing-header-crh > > > > Hi Tom, > > > > I already suggested this on March 30th ... > > > > "PS. But if you choose to go ahead with CRH I would highly advise to make= your CRH SID a variable length. " > > > > No feedback/response was received from authors. > > > > Thx, > R. > > > > On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert wrote: > > On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrote= : > > > > Hi Tom, > > > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: > > > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wro= te: > > > > > > > > Hi Mark, > > > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundar= y and a 32 bit alignment, > > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 = network. > > > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may= also create some opportunities to > > > > > leverage IPv4 support in existing protocols to suite carrying and= processing 32 bit SIDs with some, possibly > > > > > slight, modification. For example, perhaps IPv4 Address Family su= pport in OSPFv3 (RFC 5838) could be > > > > > somehow leveraged to suit SR. > > > > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > > > I think SR while indeed started with the story of "less control pla= ne is good for you" now clearly has evolved into not only reduction of cont= rol plane but what can be even more important to some users ability to requ= est specific behavior via programmed functions of network elements on a per= flow basis without actually per flow or per path signalling or state. > > > > > > > > Yes for some it may be very useful feature and I am sure some will = call it overload of data plane or . There is no one size fits all. > > > > > > > > With that let's observe that till today SR did not require any new = mapping plane to be distributed in control plane and to be inserted into da= ta plane. This is clearly a precedent. > > > > > > > > Furthermore as we see in companion documents all additional network= functionality is being taken away from SRH and is being shifted to Destina= tion Options . > > > > > > > > As far as mapping plane I already pointed out in my Vector Routing = proposal that we have one already it is called BGP. One needs to also obser= ve that we as industry worked number of years of protocol suite called LISP= allowing not only very good mapping plane, but also data plane integration= . CC-ing lisp authors for their comments. Note also work for integrating SR= v6 with LISP which is already is published. > > > > > > > > Since you correctly observed that now SID can be 32 bit and that is= similar to the size of IPv4 my fundamental question is why not use somethi= ng which already exists instead of defining some sort of new from scratch = ? > > > > > > > Robert, > > > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > > please provide a reference? > > > > > > > To clarify, I've been thinking about the idea of a smaller SID size > > for IPv6 for a while now (since inserting EHs came up), and thought > > about what would be a generic single size that might suit SR that > > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > > me, although if people wanted bigger, I'd be suggesting 64 bits (not > > entirely coincidentally the common IID size.) > > > > Ron and others have written this draft, which supports SIDS of various > > sizes - 8, 16 or 32 bits - that triggered this discussion. > > > Mark, > > Why not just put a SID length field in the header (like RFC6554 but > more generic). That would allow lengths of 1-16 bytes. Additional > flags could be used to indicate the semantics of the entries. For > instance, they might be actual addresses (128 bits for IPv6, 32 bits > for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) > where the rest of the address can be inferred, indices into a table, > labels, etc. > > Tom > > > "The IPv6 Compressed Routing Header (CRH)" > > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > > > Regards, > > Mark. > > > > > > > As for trying to use something that already exists, why does SR used = a > > > fixed size format for SIDs instead of a variable length format like > > > that described in RFC6554? Similarly, why does SR define it's own TLV > > > format instead of using Hop-by-Hop and Destination Options defined in > > > RFC8200? > > > > > > Tom > > > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LIS= P or Vector Routing as an alternative options. I really do not see a room o= r need for yet one more mapping plane. What problem does it solve which wou= ld not be already solved elsewhere ? > > > > > > > > Kind regards, > > > > Robert > > > > > > > > > > > >>> 2) Is there an agreement that solutions which require additional = per SR path state in both control plane and now in data plane are really so= mething we should be endorsing here ? > > > >> > > > >> > > > >> I think so. > > > >> > > > >> My understanding of what SR is fundamentally about is to reduce co= ntrol plane state and processing. The trade-off for reduced control plane s= tate and processing is to instead carry and encode most or all of that info= rmation or its semantics as per-packet overhead. > > > >> > > > >> If the per-packet overhead becomes too large and expensive, then p= ushing some of that information and processing back into the control plane = should be ok, as long as there is still a beneficial overall reduction in c= ontrol plane state and processing. > > > >> > > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary= and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform= SR in an IPv6 network. > > > >> > > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may = also create some opportunities to leverage IPv4 support in existing protoco= ls to suite carrying and processing 32 bit SIDs with some, possibly slight,= modification. For example, perhaps IPv4 Address Family support in OSPFv3 (= RFC 5838) could be somehow leveraged to suit SR. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > -------------------------------------------------------------------= - > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf..org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------= - From nobody Thu Apr 18 07:02:21 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D0312033E; Thu, 18 Apr 2019 07:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 iI_pBOP8gJR2; Thu, 18 Apr 2019 07:02:06 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 1EAA012014A; Thu, 18 Apr 2019 07:02:06 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3IDxsdO004469; Thu, 18 Apr 2019 07:02:01 -0700 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=nBl1GeFBDeiJ3+mIz/sGS6Vbc5b/zOQHxTZlNa9Q02Q=; b=pIDuuT1KUnJkCxI/Osu2BV2aZN1vJ4uODw3rC9/JMmR52F6AGVHqjfNn7mKyLKiSgOMg NB5K7XQYMd1PkSkMjMx/iAKkuRCX5WA59sR7CINoYtZv2PfbRIwAff7pxlfD0X5wkwbA Vihl1FuFdVHzC6/ji1jSGPLe/vw8+U+OzeHiX4GqYxOREDw7MbngrkpWF890j+nvsD3C FAV5tPifsodGOOAc1DtnJXvFe521mAgWK5DKGQefE6DvE8h+DH0f1ZZZfYfNfccmRlq/ 8n3UxpI0iW7j0ImZFtxd32W0jt3q3v++IIGEC63sNmCMW33TKu18Qs2GIXRghb3FqFH6 MQ== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2054.outbound.protection.outlook.com [104.47.45.54]) by mx0b-00273201.pphosted.com with ESMTP id 2rxp8kggng-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Apr 2019 07:01:58 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB6262.namprd05.prod.outlook.com (20.178.196.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Thu, 18 Apr 2019 14:01:54 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::30f9:29cf:6d50:edd4]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::30f9:29cf:6d50:edd4%4]) with mapi id 15.20.1813.009; Thu, 18 Apr 2019 14:01:54 +0000 From: Ron Bonica To: Gyan Mishra CC: Robert Raszuk , Tom Herbert , SPRING WG , "ipv6@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Thread-Topic: [spring] IPv6-compressed-routing-header-crh Thread-Index: AQHU5XwSQNUFwLkE10qv/uSLYFT0BKYiu67wgAFwpgCAAB1KAIAABz6AgAC56gCAAMlxgIAS2BIAgABq6gCAABaTAIAAAQyAgAM/fDCABNuTAIAAxd4g Content-Class: Date: Thu, 18 Apr 2019 14:01:54 +0000 Message-ID: References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> In-Reply-To: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-04-18T14:01:52.2350133Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: be635910-6c00-4f80-cea4-08d6c40669ee x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR05MB6262; x-ms-traffictypediagnostic: BYAPR05MB6262: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(396003)(136003)(39860400002)(189003)(199004)(186003)(7736002)(316002)(9686003)(54896002)(6306002)(54906003)(14454004)(55016002)(97736004)(966005)(66574012)(236005)(66066001)(76176011)(561944003)(68736007)(7696005)(81156014)(81166006)(8936002)(6116002)(3846002)(790700001)(8676002)(86362001)(446003)(102836004)(53546011)(26005)(2906002)(6506007)(74316002)(476003)(486006)(99286004)(11346002)(71190400001)(33656002)(45080400002)(256004)(6246003)(229853002)(52536014)(14444005)(478600001)(6916009)(93886005)(71200400001)(53936002)(606006)(4326008)(1411001)(6436002)(5660300002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB6262; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: b6LOk2ybIQxj0LHMsyCk34qNY6jSgrs/JCmiI2AnhE+ccvAw8lg8qGbuvh3xhF+eVDciLeQI7MrzyyEFK/HGpECiNQrdAhVem5NijsaDa8F2aor16JJb3pmhlyz8NdBxZ0Gw8YyukYSgpcM5Yhv3bFjYkVFAa65Tbv8n3Y8b6LPyAwYIO8GBqyiuGPAQoaXJtfk2yWo8RkYRqJRxv9zZZeB1Abm+mR8jh6p0HOXLDIyiEIGCP69S6Uuj1nyklFAx/ZtALtd4UUn2jJN6ioLD1S5ZNJ2RSB2Xf3AxLt0oXepFA+ANLtrTEROrWxrXbKzJhFveIFhJBdK3j6SsNNpqhUEnqLdYaZxt8WTYqlCnclSsvBgg5U3l/gq4EX+t+/3jhLhko5mEYTt+HFmMukXgHuQejIZ9HKJfqOF5nl+Xp1Y= Content-Type: multipart/alternative; boundary="_000_BYAPR05MB4245A7C3E215FF0028FE9B06AE260BYAPR05MB4245namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: be635910-6c00-4f80-cea4-08d6c40669ee X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 14:01:54.3868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6262 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-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-1810050000 definitions=main-1904180097 Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 14:02:11 -0000 --_000_BYAPR05MB4245A7C3E215FF0028FE9B06AE260BYAPR05MB4245namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gyan, Let's think about how a network operator might choose a SID size.... Assume that an MAN includes 100 routers. These routers are connected to one= another by infrastructure links. Each router has 20 or fewer infrastructur= e links. The network operator might assign one loosely routes SID to each router. Th= ese loosely routed SIDs have network-wide significance (i.e., the cannot be= reused). The network operator might also assign one strictly routed SID to each link= . The strictly routed SIDs have node-local significance only. They can be r= eused from one node to another. So, in this case, the network operator only needs 120 SIDs. This fits in ei= ght bits with plenty of room for growth. Now consider another network that includes 30,000 routers. Each router is c= onnected to its peers by 200 infrastructure links or fewer. This network w= ould need 30,200 SIDs. This would fit in 16 bits. A *really big* network might require more than 32,000 SIDs. So, we support = a 32-bit SID. = Ron Juniper Internal From: Gyan Mishra Sent: Wednesday, April 17, 2019 10:00 PM To: Ron Bonica Cc: Robert Raszuk ; Tom Herbert ; S= PRING WG ; ipv6@ietf.org; Dino Farinacci ; lisp@ietf.org list Subject: Re: [spring] IPv6-compressed-routing-header-crh I agree to make the SID align on word boundaries but I am thinking the soft= ware should have hardware independence if at all possible. I think 32 bit is a reasonable size. Gyan S. Mishra IT Network Engineering & Technology Consultant Routing & Switching / Service Provider MPLS & IPv6 Expert www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT Mobile - 202-734-1000 Sent from my iPhone On Apr 14, 2019, at 7:54 PM, Ron Bonica > wrote: Hi Robert, In order to make the CRH ASIC-friendly, we have the following constraints: * Support only a small handful of SID lengths * If at all possible, make them align on word boundaries Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should= support a length greater than 32? Is there some length less than 32 that w= ould be beneficial? Ron Juniper Internal From: spring > On B= ehalf Of Robert Raszuk Sent: Friday, April 12, 2019 6:13 PM To: Tom Herbert > Cc: SPRING WG >; ipv6@ietf.org; Mark Smith >; Dino Farinacci = >; lisp@ietf.org list > Subject: Re: [spring] IPv6-compressed-routing-header-crh Hi Tom, I already suggested this on March 30th ... "PS. But if you choose to go ahead with CRH I would highly advise to make y= our CRH SID a variable length. " No feedback/response was received from authors. Thx, R. On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert > wrote: On Fri, Apr 12, 2019 at 1:48 PM Mark Smith > wrote: > > Hi Tom, > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert > wrote: > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk > wrote: > > > > > > Hi Mark, > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary = and a 32 bit alignment, > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 ne= twork. > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may a= lso create some opportunities to > > > > leverage IPv4 support in existing protocols to suite carrying and p= rocessing 32 bit SIDs with some, possibly > > > > slight, modification. For example, perhaps IPv4 Address Family supp= ort in OSPFv3 (RFC 5838) could be > > > > somehow leveraged to suit SR. > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > I think SR while indeed started with the story of "less control plane= is good for you" now clearly has evolved into not only reduction of contro= l plane but what can be even more important to some users ability to reques= t specific behavior via programmed functions of network elements on a per f= low basis without actually per flow or per path signalling or state. > > > > > > Yes for some it may be very useful feature and I am sure some will ca= ll it overload of data plane or . There is no one size fits all. > > > > > > With that let's observe that till today SR did not require any new ma= pping plane to be distributed in control plane and to be inserted into data= plane. This is clearly a precedent. > > > > > > Furthermore as we see in companion documents all additional network f= unctionality is being taken away from SRH and is being shifted to Destinati= on Options . > > > > > > As far as mapping plane I already pointed out in my Vector Routing pr= oposal that we have one already it is called BGP. One needs to also observe= that we as industry worked number of years of protocol suite called LISP a= llowing not only very good mapping plane, but also data plane integration. = CC-ing lisp authors for their comments. Note also work for integrating SRv6= with LISP which is already is published. > > > > > > Since you correctly observed that now SID can be 32 bit and that is s= imilar to the size of IPv4 my fundamental question is why not use something= which already exists instead of defining some sort of new from scratch ? > > > > > Robert, > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > please provide a reference? > > > > To clarify, I've been thinking about the idea of a smaller SID size > for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.) > > Ron and others have written this draft, which supports SIDS of various > sizes - 8, 16 or 32 bits - that triggered this discussion. > Mark, Why not just put a SID length field in the header (like RFC6554 but more generic). That would allow lengths of 1-16 bytes. Additional flags could be used to indicate the semantics of the entries. For instance, they might be actual addresses (128 bits for IPv6, 32 bits for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) where the rest of the address can be inferred, indices into a table, labels, etc. Tom > "The IPv6 Compressed Routing Header (CRH)" > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > Regards, > Mark. > > > > As for trying to use something that already exists, why does SR used a > > fixed size format for SIDs instead of a variable length format like > > that described in RFC6554? Similarly, why does SR define it's own TLV > > format instead of using Hop-by-Hop and Destination Options defined in > > RFC8200? > > > > Tom > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP = or Vector Routing as an alternative options. I really do not see a room or = need for yet one more mapping plane. What problem does it solve which would= not be already solved elsewhere ? > > > > > > Kind regards, > > > Robert > > > > > > > > >>> 2) Is there an agreement that solutions which require additional pe= r SR path state in both control plane and now in data plane are really some= thing we should be endorsing here ? > > >> > > >> > > >> I think so. > > >> > > >> My understanding of what SR is fundamentally about is to reduce cont= rol plane state and processing. The trade-off for reduced control plane sta= te and processing is to instead carry and encode most or all of that inform= ation or its semantics as per-packet overhead. > > >> > > >> If the per-packet overhead becomes too large and expensive, then pus= hing some of that information and processing back into the control plane sh= ould be ok, as long as there is still a beneficial overall reduction in con= trol plane state and processing. > > >> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary a= nd a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform S= R in an IPv6 network. > > >> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may al= so create some opportunities to leverage IPv4 support in existing protocols= to suite carrying and processing 32 bit SIDs with some, possibly slight, m= odification. For example, perhaps IPv4 Address Family support in OSPFv3 (RF= C 5838) could be somehow leveraged to suit SR. > > >> > > >> Regards, > > >> Mark. > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf....org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_BYAPR05MB4245A7C3E215FF0028FE9B06AE260BYAPR05MB4245namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gyan,=

=  

Let&#= 8217;s think about how a network operator might choose a SID size….

=  

Assum= e that an MAN includes 100 routers. These routers are connected to one anot= her by infrastructure links. Each router has 20 or fewer infrastructure lin= ks.

=  

The n= etwork operator might assign one loosely routes SID to each router. These l= oosely routed SIDs have network-wide significance (i.e., the cannot be reus= ed).

=  

The n= etwork operator might also assign one strictly routed SID to each link. The= strictly routed SIDs have node-local significance only. They can be reused= from one node to another.

=  

So, i= n this case, the network operator only needs 120 SIDs. This fits in eight b= its with plenty of room for growth.

=  

Now c= onsider another network that includes 30,000 routers. Each router is connec= ted to its peers by 200 infrastructure links or fewer.  This network w= ould need 30,200 SIDs. This would fit in 16 bits.

=  

A *really big* network might require more than 32,000 SIDs. So, we suppor= t a 32-bit SID.

=  

 = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            Ron<= o:p>

=  

=  

=  

 

Juniper Internal=

From: Gyan Mishra <hayabusagsm@gmail.com&g= t;
Sent: Wednesday, April 17, 2019 10:00 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>; Tom Herbert <tom@her= bertland.com>; SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Fa= rinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org&g= t;
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

 

I agree to make the SID align on word boundaries but= I am thinking the software should have hardware independence if at all pos= sible.

 

I think 32 bit is a reasonable size.

 

 

Gyan S. Mishra

IT Network Engineering & Technology Consultant

Routing & Switching / Service Provider MPLS &= ; IPv6 Expert

Mobile – 202= -734-1000

 

Sent from my iPhone


On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> w= rote:

Hi Ro= bert,

 = ;

In or= der to make the CRH ASIC-friendly, we have the following constraints:

 = ;

  • Support only a small handful of SID length= s
  • If at all possible, make them align on wor= d boundaries

 = ;

Curre= ntly, we support 8, 16 and 32 bytes. Do you see a reason why we should supp= ort a length greater than 32? Is there some length less than 32 that would = be beneficial?

 = ;

 = ;            &n= bsp;            = ;            &n= bsp;            = ;  Ron

 = ;

 = ;

 

Juniper Internal=

From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <tom@herbe= rtland.com>
Cc: SPRING WG <spring@ietf.org= >; ipv6@ietf.org; Mark Smith <markzzzsmith@gmail.com>; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

Hi Tom,

 

I already suggested this on March 30th ... 

 

"PS. But if you choose to go ahead with CRH I would hig= hly advise to make your CRH SID a variable length. "

 

No feedback/response was received from authors. 

 

Thx,
R.

 

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:=

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.c= om> wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote: > > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform SR i= n an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network elements on a per flow basis without actually per flo= w or per path signalling or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not require a= ny new mapping plane to be distributed in control plane and to be inserted = into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comm= ents. Note also work for integrating SRv6 with LISP which is already is pub= lished.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new  f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. Can y= ou
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID size > for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable to > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's own= TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequate = to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leverage= d to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf= ....org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------

----------------------------------------------------= ----------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--_000_BYAPR05MB4245A7C3E215FF0028FE9B06AE260BYAPR05MB4245namp_-- From nobody Thu Apr 18 07:30:57 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0482C1200DF for ; Thu, 18 Apr 2019 07:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 Ty_z4W2xCW1P for ; Thu, 18 Apr 2019 07:30:44 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 36CD6120418 for ; Thu, 18 Apr 2019 07:30:44 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id f13so2004442qto.6 for ; Thu, 18 Apr 2019 07:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NTSQaZFa2Mf31wBt3okiQ/Q27njdUVfwUFFuDeOp8Js=; b=YffNL6byhw1UIwM90hlY5FNY4hKD9bN37u7VCRGJD87LePRrg8QqllJ1on+QlBwrQi Pm+1jI8CCUa7ZqA3rFlTh0C5jh6GhbdNoqxcghK44ysLrih9h9sFBtKQlUIoP5Ky2Qu5 B+GElSi8UebgqMYp5/zE4WmKDVgemR9aVyMRh1guxrCB3PY8ZEswEHJOVAw3jvLazx/q RXvMKIaefUk2JTpxD8zZWKiv+ectxJaKLKwXT373w2VR4uwsSXg8s8UIkhQjpEpBJXhd uS+OFJ+RzAb7mIpDkvMl8g00e4nWtRfBQavVbEM94llPZseqMyjQE900bntQj1S7EtoI ZHCw== 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=NTSQaZFa2Mf31wBt3okiQ/Q27njdUVfwUFFuDeOp8Js=; b=eamk5p2VK3S3jatYv1UmE7Pi/3LkVQ4I1WLDQqJNYA/7Dpvln81YhdXkYtS+vwW5Gp ZkxKWdz7Z2b2fEGrOVDg+8gTTAGFYaV7SK69LSEd/PJl3e0hZA6YhhAbhyaLpl+Lc3Y1 VQO9Nb6TnI2+CmQQV9j10mtGQcFqXa3BRnSjp2K4IWosu1x57GzW8VElFqnpiKjavgCc SB5szMs9Xof0kxh5fR5mpJradfGmG6wy0vPzOrP/mEm1BL3u2JsUoQvlfI3NgVrsIuPl UYrWwCRnNI6VdQo9PDHezR9QuXfO8bLLYA4/Uf0zahmGnuLDiaGp27gEVXM1CLeAknZE ss8A== X-Gm-Message-State: APjAAAV1moxQDPoSTCt4rXAmZTQX6kWXGnMHt9ZYlCtQmiE+EspTt/Q/ 6JK6iZIvU6o2IbKA8h0DMjw6hEvkoeZ7YZGITjQF0Q== X-Google-Smtp-Source: APXvYqw4yTNZAXSfGFwSnSEXTxn5z8vhlMYOQMKgEFwKosdGnMrqBeRVRu3J7jaO/S3sEh58UHRupHO1kbxNV1dpHVA= X-Received: by 2002:a0c:d1a6:: with SMTP id e35mr75379267qvh.174.1555597843154; Thu, 18 Apr 2019 07:30:43 -0700 (PDT) MIME-Version: 1.0 References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> In-Reply-To: From: Robert Raszuk Date: Thu, 18 Apr 2019 16:30:29 +0200 Message-ID: To: Ron Bonica Cc: Gyan Mishra , Tom Herbert , SPRING WG , "ipv6@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000dae3dc0586ced8de" Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 14:30:50 -0000 --000000000000dae3dc0586ced8de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ron, I must observe that your analysis is incorrect. SIDs are not only used for TE or traffic steering purposes but what is even more interesting for various functions - for example NFV. So you need as much SIDs as possible imagination of your value add network functions - which will be different from those functions at the encap dst which as you indicate in other draft can be carried in destination options. That debate is still I think open. Thx, R. On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica wrote: > Gyan, > > > > Let=E2=80=99s think about how a network operator might choose a SID size= =E2=80=A6. > > > > Assume that an MAN includes 100 routers. These routers are connected to > one another by infrastructure links. Each router has 20 or fewer > infrastructure links. > > > > The network operator might assign one loosely routes SID to each router. > These loosely routed SIDs have network-wide significance (i.e., the canno= t > be reused). > > > > The network operator might also assign one strictly routed SID to each > link. The strictly routed SIDs have node-local significance only. They ca= n > be reused from one node to another. > > > > So, in this case, the network operator only needs 120 SIDs. This fits in > eight bits with plenty of room for growth. > > > > Now consider another network that includes 30,000 routers. Each router is > connected to its peers by 200 infrastructure links or fewer. This networ= k > would need 30,200 SIDs. This would fit in 16 bits. > > > > A **really big** network might require more than 32,000 SIDs. So, we > support a 32-bit SID. > > > > > Ron > > > > > > > > > > Juniper Internal > > *From:* Gyan Mishra > *Sent:* Wednesday, April 17, 2019 10:00 PM > *To:* Ron Bonica > *Cc:* Robert Raszuk ; Tom Herbert ; > SPRING WG ; ipv6@ietf.org; Dino Farinacci < > farinacci@gmail.com>; lisp@ietf.org list > *Subject:* Re: [spring] IPv6-compressed-routing-header-crh > > > > > > I agree to make the SID align on word boundaries but I am thinking the > software should have hardware independence if at all possible. > > > > I think 32 bit is a reasonable size. > > > > > > Gyan S. Mishra > > IT Network Engineering & Technology Consultant > > Routing & Switching / Service Provider MPLS & IPv6 Expert > > www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT > > > Mobile =E2=80=93 202-734-1000 > > > > Sent from my iPhone > > > On Apr 14, 2019, at 7:54 PM, Ron Bonica < > rbonica=3D40juniper.net@dmarc.ietf.org> wrote: > > Hi Robert, > > > > In order to make the CRH ASIC-friendly, we have the following constraints= : > > > > - Support only a small handful of SID lengths > - If at all possible, make them align on word boundaries > > > > Currently, we support 8, 16 and 32 bytes. Do you see a reason why we > should support a length greater than 32? Is there some length less than 3= 2 > that would be beneficial? > > > > Ron > > > > > > > > Juniper Internal > > *From:* spring *On Behalf Of *Robert Raszuk > *Sent:* Friday, April 12, 2019 6:13 PM > *To:* Tom Herbert > *Cc:* SPRING WG ; ipv6@ietf.org; Mark Smith < > markzzzsmith@gmail.com>; Dino Farinacci ; > lisp@ietf.org list > *Subject:* Re: [spring] IPv6-compressed-routing-header-crh > > > > Hi Tom, > > > > I already suggested this on March 30th ... > > > > *"**PS. But if you choose to go ahead with CRH I would highly advise to > make your CRH SID a variable length. "* > > > > No feedback/response was received from authors. > > > > Thx, > R. > > > > On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert wrote: > > On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrote= : > > > > Hi Tom, > > > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: > > > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk > wrote: > > > > > > > > Hi Mark, > > > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundar= y > and a 32 bit alignment, > > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 > network. > > > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may > also create some opportunities to > > > > > leverage IPv4 support in existing protocols to suite carrying and > processing 32 bit SIDs with some, possibly > > > > > slight, modification. For example, perhaps IPv4 Address Family > support in OSPFv3 (RFC 5838) could be > > > > > somehow leveraged to suit SR. > > > > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > > > I think SR while indeed started with the story of "less control > plane is good for you" now clearly has evolved into not only reduction of > control plane but what can be even more important to some users ability t= o > request specific behavior via programmed functions of network elements on= a > per flow basis without actually per flow or per path signalling or state. > > > > > > > > Yes for some it may be very useful feature and I am sure some will > call it overload of data plane or . There is no one size fits all. > > > > > > > > With that let's observe that till today SR did not require any new > mapping plane to be distributed in control plane and to be inserted into > data plane. This is clearly a precedent. > > > > > > > > Furthermore as we see in companion documents all additional network > functionality is being taken away from SRH and is being shifted to > Destination Options . > > > > > > > > As far as mapping plane I already pointed out in my Vector Routing > proposal that we have one already it is called BGP. One needs to also > observe that we as industry worked number of years of protocol suite call= ed > LISP allowing not only very good mapping plane, but also data plane > integration. CC-ing lisp authors for their comments. Note also work for > integrating SRv6 with LISP which is already is published. > > > > > > > > Since you correctly observed that now SID can be 32 bit and that is > similar to the size of IPv4 my fundamental question is why not use > something which already exists instead of defining some sort of new from > scratch ? > > > > > > > Robert, > > > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > > please provide a reference? > > > > > > > To clarify, I've been thinking about the idea of a smaller SID size > > for IPv6 for a while now (since inserting EHs came up), and thought > > about what would be a generic single size that might suit SR that > > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > > me, although if people wanted bigger, I'd be suggesting 64 bits (not > > entirely coincidentally the common IID size.) > > > > Ron and others have written this draft, which supports SIDS of various > > sizes - 8, 16 or 32 bits - that triggered this discussion. > > > Mark, > > Why not just put a SID length field in the header (like RFC6554 but > more generic). That would allow lengths of 1-16 bytes. Additional > flags could be used to indicate the semantics of the entries. For > instance, they might be actual addresses (128 bits for IPv6, 32 bits > for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) > where the rest of the address can be inferred, indices into a table, > labels, etc. > > Tom > > > "The IPv6 Compressed Routing Header (CRH)" > > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > > > > Regards, > > Mark. > > > > > > > As for trying to use something that already exists, why does SR used = a > > > fixed size format for SIDs instead of a variable length format like > > > that described in RFC6554? Similarly, why does SR define it's own TLV > > > format instead of using Hop-by-Hop and Destination Options defined in > > > RFC8200? > > > > > > Tom > > > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LIS= P > or Vector Routing as an alternative options. I really do not see a room o= r > need for yet one more mapping plane. What problem does it solve which wou= ld > not be already solved elsewhere ? > > > > > > > > Kind regards, > > > > Robert > > > > > > > > > > > >>> 2) Is there an agreement that solutions which require additional > per SR path state in both control plane and now in data plane are really > something we should be endorsing here ? > > > >> > > > >> > > > >> I think so. > > > >> > > > >> My understanding of what SR is fundamentally about is to reduce > control plane state and processing. The trade-off for reduced control pla= ne > state and processing is to instead carry and encode most or all of that > information or its semantics as per-packet overhead. > > > >> > > > >> If the per-packet overhead becomes too large and expensive, then > pushing some of that information and processing back into the control pla= ne > should be ok, as long as there is still a beneficial overall reduction in > control plane state and processing. > > > >> > > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary > and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perfor= m > SR in an IPv6 network. > > > >> > > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may > also create some opportunities to leverage IPv4 support in existing > protocols to suite carrying and processing 32 bit SIDs with some, possibl= y > slight, modification. For example, perhaps IPv4 Address Family support in > OSPFv3 (RFC 5838) could be somehow leveraged to suit SR. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > -------------------------------------------------------------------= - > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf....org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > -------------------------------------------------------------------= - > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > --000000000000dae3dc0586ced8de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ron,

I must observe that your analys= is is incorrect.=C2=A0

SIDs are not only used for = TE or traffic steering purposes but what is even more interesting for vario= us functions - for example NFV.=C2=A0

So you need = as much SIDs as possible imagination of your value add network functions - = which will be different from those functions at the encap dst which as you = indicate in other draft can be carried in destination options.=C2=A0
<= div>
That debate is still I think open.=C2=A0

<= /div>
Thx,
R.


On Thu, Apr 18, 2019 at 4:0= 2 PM Ron Bonica <rbonica@juniper.= net> wrote:

= Gyan,

= =C2=A0

= Let=E2=80=99s think about how a network operator might choose a SID size=E2= =80=A6.

= =C2=A0

= Assume that an MAN includes 100 routers. These routers are connected to one= another by infrastructure links. Each router has 20 or fewer infrastructur= e links.

= =C2=A0

= The network operator might assign one loosely routes SID to each router. Th= ese loosely routed SIDs have network-wide significance (i.e., the cannot be= reused).

= =C2=A0

= The network operator might also assign one strictly routed SID to each link= . The strictly routed SIDs have node-local significance only. They can be r= eused from one node to another.

= =C2=A0

= So, in this case, the network operator only needs 120 SIDs. This fits in ei= ght bits with plenty of room for growth.

= =C2=A0

= Now consider another network that includes 30,000 routers. Each router is c= onnected to its peers by 200 infrastructure links or fewer.=C2=A0 This netw= ork would need 30,200 SIDs. This would fit in 16 bits.

= =C2=A0

= A *really big* network might require more than 32,000 SIDs. So, we s= upport a 32-bit SID.

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Ron

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0

Juniper Internal

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Wednesday, April 17, 2019 10:00 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>; Tom Herbert <tom@herbertland.com>; SPRING WG &l= t;spring@ietf.org&= gt;; ipv6@ietf.org; = Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>
Subject: Re: [spring] IPv6-compressed-routing-header-crh

=C2=A0

=C2=A0

I agree to make the SID align on word boundaries but= I am thinking the software should have hardware independence if at all pos= sible.

=C2=A0

I think 32 bit is a reasonable size.

=C2=A0

=C2=A0

Gyan S. Mishra

IT Network Engineering & Technology Consultant

Routing & Switching / Service Provider MPLS &= ; IPv6 Expert

Mobile =E2=80=93=C2=A0202-734-1000

=C2=A0

Sent from my iPhone


On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=3D40juniper.net@dmarc.= ietf.org> wrote:

= Hi Robert,

= =C2=A0

= In order to make the CRH ASIC-friendly, we have the following constraints:<= /span>

= =C2=A0

  • Support only a small handful of SID lengths<= /span>
  • If at all possible, make them align on word = boundaries

= =C2=A0

= Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should= support a length greater than 32? Is there some length less than 32 that w= ould be beneficial?

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Ron

= =C2=A0

= =C2=A0

=C2=A0

Juniper Internal

From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <tom@herbertland.com>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Mark Smith <markzzzsmith@gmail.com>; Dino Farinacci <farinacci@gmail.com= >; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh

=C2=A0

Hi Tom,

=C2=A0

I already suggested this on March 30th ...=C2=A0<= /u>

=C2=A0

"PS. But if you choose to go ahead with CRH I would highly advise t= o make your CRH SID a variable length. "

=C2=A0

No feed= back/response was received from authors.=C2=A0

=C2=A0

Thx, R.

=C2=A0

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.c= om> wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote: > > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform = SR in an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network elements on a per flow basis without actually per flo= w or per path signalling or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not requi= re any new mapping plane to be distributed in control plane and to be inser= ted into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comm= ents. Note also work for integrating SRv6 with LISP which is already is pub= lished.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new=C2=A0 f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. C= an you
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID siz= e
> for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable t= o
> me, although if people wanted bigger, I'd be suggesting 64 bits (n= ot
> entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's= own TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequ= ate to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leverage= d to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf= ....org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------

----------------------------------------------------= ----------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------=

--000000000000dae3dc0586ced8de-- From nobody Thu Apr 18 13:30:06 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2AB12034B; Thu, 18 Apr 2019 13:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 2foenc657NSk; Thu, 18 Apr 2019 13:29:54 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 A1A17120188; Thu, 18 Apr 2019 13:29:53 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3IKJOpC023459; Thu, 18 Apr 2019 13:29:47 -0700 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=mKaRn4aqoXiHjiYDMOTC8PEKYSHyPlsa1v8VrLJFIS8=; b=mmN3C4tZGp1XYtXIJjrd5U8c6f9dHQyNPl/xuAYComFBOLQ6pQZdD/hnme6s94L+Nj1t q2Y/vTqHjKKzkvu2GYxwH1GKGJv7LnMfVKDdA14PYSVZ+w3l9SyFOIKqN8NdSbRqpF1k iBmjNypnR6lttfTa5flRqQvn/lcN4J4RpHszBvnmuCVuCE86UXpM9ZWt9PoScLGcodkV 6p4xeYx4XbqxaKGTDydd5ZS58Rp8etBwKWFhOtNG+LB1mGxb5wgje46nDH9qX3LU5bBh xMnCSfNw4YfwnUvWdT+3M5nfvQxRLETjecpcm7EtJCrlSN/lqMUppwxIfHhL4rhgNVau iA== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp2051.outbound.protection.outlook.com [104.47.41.51]) by mx0b-00273201.pphosted.com with ESMTP id 2rxwkfrb6h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Apr 2019 13:29:46 -0700 Received: from BN7PR05MB4243.namprd05.prod.outlook.com (52.133.222.152) by BN7PR05MB5890.namprd05.prod.outlook.com (20.176.30.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Thu, 18 Apr 2019 20:29:43 +0000 Received: from BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::8906:7b1e:6bd0:28f2]) by BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::8906:7b1e:6bd0:28f2%7]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 20:29:43 +0000 From: Ron Bonica To: Robert Raszuk CC: Gyan Mishra , Tom Herbert , SPRING WG , "ipv6@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Thread-Topic: [spring] IPv6-compressed-routing-header-crh Thread-Index: AQHU5XwSQNUFwLkE10qv/uSLYFT0BKYiu67wgAFwpgCAAB1KAIAABz6AgAC56gCAAMlxgIAS2BIAgABq6gCAABaTAIAAAQyAgAM/fDCABNuTAIAAxd4ggAAL04CAAF6GQA== Content-Class: Date: Thu, 18 Apr 2019 20:29:43 +0000 Message-ID: References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-04-18T20:29:40.0853040Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d9d85b72-3dbd-4ed2-b6ee-08d6c43c973d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BN7PR05MB5890; x-ms-traffictypediagnostic: BN7PR05MB5890: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(136003)(39860400002)(346002)(376002)(199004)(189003)(5660300002)(6246003)(66066001)(25786009)(55016002)(7736002)(74316002)(476003)(7696005)(53546011)(102836004)(316002)(64756008)(966005)(486006)(66946007)(446003)(606006)(66446008)(186003)(26005)(11346002)(99286004)(4326008)(52536014)(478600001)(68736007)(6506007)(76176011)(517774005)(45080400002)(6436002)(93886005)(81166006)(81156014)(8676002)(30864003)(2906002)(54906003)(86362001)(53936002)(97736004)(8936002)(33656002)(53946003)(66574012)(14454004)(256004)(14444005)(6916009)(6306002)(54896002)(236005)(9686003)(71190400001)(71200400001)(6116002)(3846002)(561944003)(790700001)(5070765005)(229853002)(66476007)(66556008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB5890; H:BN7PR05MB4243.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: KTAGS3ZmtbOtonugef7tBPmbcHKdEYvZJjz0pxC+v3G19gG4txjeN3JktwFO17JAtjhBs+YnMiSkbWFnzpDWyjsjH4mDCzCL6r/LWK1xJmcVE2rfAq6wloO2XQPCI+4bdnQczRyPzPyMkqNtLdNBwckrFqMSjr0z9Gz1QhAkHoT7YlbmmK7C8OuFY82K5CRDvKwByy/iUibup4yYd6E1ZNi9XQgJwJhXtoGLZpI8oKhJkyc2baJkS19m2cBm6ANL7mQRdh5/uzFRwJJiTNmT02Qi33k8+0xWLmGe8cF8VsLaOvV6qVHCQLxjZUFxiraHmNiHLpAyBrAPAOqcT2rBFxaarKA5y+KVln46xCD+gKfq6fcZJChyv6rl9io7w+jkYuhKkMBDFkuNGoqn4FqgD1r+NTNXgk82RI7c3aSik7Q= Content-Type: multipart/alternative; boundary="_000_BN7PR05MB424378EE1287B03467E2B4CAAE260BN7PR05MB4243namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: d9d85b72-3dbd-4ed2-b6ee-08d6c43c973d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 20:29:43.2160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB5890 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-18_10:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904180123 Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 20:29:57 -0000 --_000_BN7PR05MB424378EE1287B03467E2B4CAAE260BN7PR05MB4243namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, The Compressed Routing Header (CRH) has exactly one function. That is to ro= ute a packet for segment to segment along an SR path. Therefore, SIDs conta= ined by the CRH have only one function. That is to steer packets to the nex= t segment. Granted, we may want to program a service behavior at a segment endpoint. I= Pv6 includes a Destination Options header that can be used to convey inform= ation segment endpoints and destination options can contain service SIDs. T= hese service SIDs can be as long or short as they need to be. See draft-bon= ica-6man-vpn-dest-opt for an example. = Ron Juniper Internal From: Robert Raszuk Sent: Thursday, April 18, 2019 10:30 AM To: Ron Bonica Cc: Gyan Mishra ; Tom Herbert ;= SPRING WG ; ipv6@ietf.org; Dino Farinacci ; lisp@ietf.org list Subject: Re: [spring] IPv6-compressed-routing-header-crh Hi Ron, I must observe that your analysis is incorrect. SIDs are not only used for TE or traffic steering purposes but what is even= more interesting for various functions - for example NFV. So you need as much SIDs as possible imagination of your value add network = functions - which will be different from those functions at the encap dst w= hich as you indicate in other draft can be carried in destination options. That debate is still I think open. Thx, R. On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica > wrote: Gyan, Let's think about how a network operator might choose a SID size.... Assume that an MAN includes 100 routers. These routers are connected to one= another by infrastructure links. Each router has 20 or fewer infrastructur= e links. The network operator might assign one loosely routes SID to each router. Th= ese loosely routed SIDs have network-wide significance (i.e., the cannot be= reused). The network operator might also assign one strictly routed SID to each link= . The strictly routed SIDs have node-local significance only. They can be r= eused from one node to another. So, in this case, the network operator only needs 120 SIDs. This fits in ei= ght bits with plenty of room for growth. Now consider another network that includes 30,000 routers. Each router is c= onnected to its peers by 200 infrastructure links or fewer. This network w= ould need 30,200 SIDs. This would fit in 16 bits. A *really big* network might require more than 32,000 SIDs. So, we support = a 32-bit SID. = Ron Juniper Internal From: Gyan Mishra > Sent: Wednesday, April 17, 2019 10:00 PM To: Ron Bonica > Cc: Robert Raszuk >; Tom Herber= t >; SPRING WG >; ipv6@ietf.org; Dino Fa= rinacci >; lisp@ietf.org list > Subject: Re: [spring] IPv6-compressed-routing-header-crh I agree to make the SID align on word boundaries but I am thinking the soft= ware should have hardware independence if at all possible. I think 32 bit is a reasonable size. Gyan S. Mishra IT Network Engineering & Technology Consultant Routing & Switching / Service Provider MPLS & IPv6 Expert www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT Mobile - 202-734-1000 Sent from my iPhone On Apr 14, 2019, at 7:54 PM, Ron Bonica > wrote: Hi Robert, In order to make the CRH ASIC-friendly, we have the following constraints: * Support only a small handful of SID lengths * If at all possible, make them align on word boundaries Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should= support a length greater than 32? Is there some length less than 32 that w= ould be beneficial? Ron Juniper Internal From: spring > On B= ehalf Of Robert Raszuk Sent: Friday, April 12, 2019 6:13 PM To: Tom Herbert > Cc: SPRING WG >; ipv6@ietf.org; Mark Smith >; Dino Farinacci = >; lisp@ietf.org list > Subject: Re: [spring] IPv6-compressed-routing-header-crh Hi Tom, I already suggested this on March 30th ... "PS. But if you choose to go ahead with CRH I would highly advise to make y= our CRH SID a variable length. " No feedback/response was received from authors. Thx, R. On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert > wrote: On Fri, Apr 12, 2019 at 1:48 PM Mark Smith > wrote: > > Hi Tom, > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert > wrote: > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk > wrote: > > > > > > Hi Mark, > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary = and a 32 bit alignment, > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 ne= twork. > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may a= lso create some opportunities to > > > > leverage IPv4 support in existing protocols to suite carrying and p= rocessing 32 bit SIDs with some, possibly > > > > slight, modification. For example, perhaps IPv4 Address Family supp= ort in OSPFv3 (RFC 5838) could be > > > > somehow leveraged to suit SR. > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > I think SR while indeed started with the story of "less control plane= is good for you" now clearly has evolved into not only reduction of contro= l plane but what can be even more important to some users ability to reques= t specific behavior via programmed functions of network elements on a per f= low basis without actually per flow or per path signalling or state. > > > > > > Yes for some it may be very useful feature and I am sure some will ca= ll it overload of data plane or . There is no one size fits all. > > > > > > With that let's observe that till today SR did not require any new ma= pping plane to be distributed in control plane and to be inserted into data= plane. This is clearly a precedent. > > > > > > Furthermore as we see in companion documents all additional network f= unctionality is being taken away from SRH and is being shifted to Destinati= on Options . > > > > > > As far as mapping plane I already pointed out in my Vector Routing pr= oposal that we have one already it is called BGP. One needs to also observe= that we as industry worked number of years of protocol suite called LISP a= llowing not only very good mapping plane, but also data plane integration. = CC-ing lisp authors for their comments. Note also work for integrating SRv6= with LISP which is already is published. > > > > > > Since you correctly observed that now SID can be 32 bit and that is s= imilar to the size of IPv4 my fundamental question is why not use something= which already exists instead of defining some sort of new from scratch ? > > > > > Robert, > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > please provide a reference? > > > > To clarify, I've been thinking about the idea of a smaller SID size > for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.) > > Ron and others have written this draft, which supports SIDS of various > sizes - 8, 16 or 32 bits - that triggered this discussion. > Mark, Why not just put a SID length field in the header (like RFC6554 but more generic). That would allow lengths of 1-16 bytes. Additional flags could be used to indicate the semantics of the entries. For instance, they might be actual addresses (128 bits for IPv6, 32 bits for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) where the rest of the address can be inferred, indices into a table, labels, etc. Tom > "The IPv6 Compressed Routing Header (CRH)" > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > Regards, > Mark. > > > > As for trying to use something that already exists, why does SR used a > > fixed size format for SIDs instead of a variable length format like > > that described in RFC6554? Similarly, why does SR define it's own TLV > > format instead of using Hop-by-Hop and Destination Options defined in > > RFC8200? > > > > Tom > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP = or Vector Routing as an alternative options. I really do not see a room or = need for yet one more mapping plane. What problem does it solve which would= not be already solved elsewhere ? > > > > > > Kind regards, > > > Robert > > > > > > > > >>> 2) Is there an agreement that solutions which require additional pe= r SR path state in both control plane and now in data plane are really some= thing we should be endorsing here ? > > >> > > >> > > >> I think so. > > >> > > >> My understanding of what SR is fundamentally about is to reduce cont= rol plane state and processing. The trade-off for reduced control plane sta= te and processing is to instead carry and encode most or all of that inform= ation or its semantics as per-packet overhead. > > >> > > >> If the per-packet overhead becomes too large and expensive, then pus= hing some of that information and processing back into the control plane sh= ould be ok, as long as there is still a beneficial overall reduction in con= trol plane state and processing. > > >> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary a= nd a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform S= R in an IPv6 network. > > >> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may al= so create some opportunities to leverage IPv4 support in existing protocols= to suite carrying and processing 32 bit SIDs with some, possibly slight, m= odification. For example, perhaps IPv4 Address Family support in OSPFv3 (RF= C 5838) could be somehow leveraged to suit SR. > > >> > > >> Regards, > > >> Mark. > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf....org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_BN7PR05MB424378EE1287B03467E2B4CAAE260BN7PR05MB4243namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rober= t,

=  

The C= ompressed Routing Header (CRH) has exactly one function. That is to route a= packet for segment to segment along an SR path. Therefore, SIDs contained = by the CRH have only one function. That is to steer packets to the next segment.

=  

Grant= ed, we may want to program a service behavior at a segment endpoint. IPv6 i= ncludes a Destination Options header that can be used to convey information= segment endpoints and destination options can contain service SIDs. These service SIDs can be as long or short as th= ey need to be. See draft-bonica-6man-vpn-dest-opt for an example.

=  

 = ;            &n= bsp;            = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p; Ron

=  

 

Juniper Internal=

From: Robert Raszuk <robert@raszuk.net>=
Sent: Thursday, April 18, 2019 10:30 AM
To: Ron Bonica <rbonica@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Tom Herbert <tom@h= erbertland.com>; SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino = Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org= >
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

Hi Ron,

 

I must observe that your analysis is incorrect. = ;

 

SIDs are not only used for TE or traffic steering pu= rposes but what is even more interesting for various functions - for exampl= e NFV. 

 

So you need as much SIDs as possible imagination of = your value add network functions - which will be different from those funct= ions at the encap dst which as you indicate in other draft can be carried i= n destination options. 

 

That debate is still I think open. <= /p>

 

Thx,

R.

 

 

On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica <rbonica@juniper.net> wrote:

Gyan,

 <= /o:p>

Let’s think a= bout how a network operator might choose a SID size….

 <= /o:p>

Assume that an MAN = includes 100 routers. These routers are connected to one another by infrast= ructure links. Each router has 20 or fewer infrastructure links.

 <= /o:p>

The network operato= r might assign one loosely routes SID to each router. These loosely routed = SIDs have network-wide significance (i.e., the cannot be reused).

 <= /o:p>

The network operato= r might also assign one strictly routed SID to each link. The strictly rout= ed SIDs have node-local significance only. They can be reused from one node to another.

 <= /o:p>

So, in this case, t= he network operator only needs 120 SIDs. This fits in eight bits with plent= y of room for growth.

 <= /o:p>

Now consider anothe= r network that includes 30,000 routers. Each router is connected to its pee= rs by 200 infrastructure links or fewer.  This network would need 30,200 SIDs. This would fit in 16 bits.

 <= /o:p>

A *really big* network might require more than 32,000 SIDs. So, we support a 32-bit SID= .

 <= /o:p>

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Ron

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

Juniper Internal=

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Wednesday, April 17, 2019 10:00 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>; Tom Herbert <tom@herbertland.com>; SPRING WG &l= t;spring@ietf.org&= gt;; ipv6@ietf.org; Dino = Farinacci <fari= nacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

 

I agree to make the SID align on word boundaries but I am thinking= the software should have hardware independence if at all possible.

 

I think 32 bit is a reasonable size.

 

 

Gyan S. Mishra

IT Network Engineering & Technology Consultant

Routing & Switching / Service Provider MPLS & IPv6 Expert<= o:p>

Mobile – 202-734-1000

 

Sent from my iPhone


On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=3D40juniper.net@dmarc.= ietf.org> wrote:

Hi Robert,

 <= /o:p>

In order to make th= e CRH ASIC-friendly, we have the following constraints:

 <= /o:p>

  • Support only a small handful of SID length= s
  • If at all possible, make them align on wor= d boundaries

 <= /o:p>

Currently, we suppo= rt 8, 16 and 32 bytes. Do you see a reason why we should support a length g= reater than 32? Is there some length less than 32 that would be beneficial?

 <= /o:p>

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            Ron

 <= /o:p>

 <= /o:p>

 

Juniper Internal=

From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <tom@herbertland.com>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Mark = Smith <markz= zzsmith@gmail.com>; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

Hi Tom,

 

I already suggested this on March 30th ... 

 

"PS. But if you choose to go ahead with CRH I would highly advise to = make your CRH SID a variable length. "

 

No feedba= ck/response was received from authors. 

 

Thx,
R.

 

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:<= o:p>

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.com> wro= te:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote: > > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform SR i= n an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network elements on a per flow basis without actually per flo= w or per path signalling or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not require a= ny new mapping plane to be distributed in control plane and to be inserted = into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comm= ents. Note also work for integrating SRv6 with LISP which is already is pub= lished.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new  f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. Can y= ou
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID size > for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable to > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's own= TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequate = to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leverage= d to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf= ....org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------

------------------------------------------------------------------= --
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--_000_BN7PR05MB424378EE1287B03467E2B4CAAE260BN7PR05MB4243namp_-- From nobody Thu Apr 18 13:56:32 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CF1120397 for ; Thu, 18 Apr 2019 13:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 ZVephDHoUGVk for ; Thu, 18 Apr 2019 13:56:20 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 55AD5120387 for ; Thu, 18 Apr 2019 13:56:20 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id i14so3655700qtr.10 for ; Thu, 18 Apr 2019 13:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+bQlh236jkz61VajplMDZsGP7gkDTbu7TZ/dBqK/RE4=; b=a61XWSAGTX9uXu72EVI2e1D7s7QAyw20rQ0UwCtRKSEuLleVdrYQ6oySJItsl7G+rc mzsYT6WdaHnvqqAEYV2sMI+529t/LYLRCmuBXncHLxNTySv+wSh04jRiOp1ojHE82r+E L/Y7wyYpAatqzGLt1t8+kPw/3xW1nPHDLIcCe17xrZk+Y3eIGTzrsTH6I3pbsmzYtIAu O1dt/BmO42nRH4HCUUO3ul1YI3NIOJ6upk8tkezlf0U5qdSrHcVFa+I54YdwYF2ZfaKr PAp9f8ujF186Or3Z7s5NGZjVy805AHK8X5X5Lksh28/fQA+RB48Kvq2MA86FnIFzWDUw wm3Q== 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=+bQlh236jkz61VajplMDZsGP7gkDTbu7TZ/dBqK/RE4=; b=nYwp/gwbLcDDaAku3y39o0J6Q29EVobP3++B3M2uPo3TRHhcLjFZUznPjfi60ktHLt yUR+UgOSwYXG3XTlZc5q5zaZ/SHyZX4+CJbAxN9F7lvIZzpciV6l8qXdIOjprlR6dxeS zlW9SwLH7WYl5rdGEQ4iwhnEPUE/wep3VUmYaWF7d2nxMviB9X/6/65mXRhbYchM2TyX e+oQL2UsBNhPBwLfTlfoRGkSxnFJVE5VQ8cz3MUUkP7H8Lj75hR1pJPgmjJ1fgHN3Zxo Sn+jpyd+bbHMF7MobTcCljLZjdYOAW6gdfvXTouWoIet2VGDSoW9a0k3b1n1fuqb2mUG jwHQ== X-Gm-Message-State: APjAAAU3fwg6FSpOJA0b+I/w9vPHd9CyTUzVG/J8vUt8RtB2Mt+J4950 +CsO738UPGqKrr4d4slhbI5/Gz80uq+Oj2VnE/wrsw== X-Google-Smtp-Source: APXvYqwT12DZasf1UXORzAD7WOqX3w4pUwtE5oEOsTmepWyog3fHfp0DIiZ/yP0F6y3vBMDU83P+aoBXDSoOIflskUQ= X-Received: by 2002:a0c:a8d5:: with SMTP id h21mr231322qvc.124.1555620979137; Thu, 18 Apr 2019 13:56:19 -0700 (PDT) MIME-Version: 1.0 References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> In-Reply-To: From: Robert Raszuk Date: Thu, 18 Apr 2019 22:56:09 +0200 Message-ID: To: Ron Bonica Cc: Gyan Mishra , Tom Herbert , SPRING WG , "ipv6@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="000000000000ddfd8f0586d43b87" Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 20:56:26 -0000 --000000000000ddfd8f0586d43b87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ron, > The Compressed Routing Header (CRH) has exactly one function. That is to route a packet for > segment to segment along an SR path. Therefore, SIDs contained by the CRH have only one > function. That is to steer packets to the next segment. Indeed and that is precisely where the fundamental problem resides with your proposal. Let's take a look at RFC8402 - Segment Routing Architecture. In body of the above RFC we clearly see definition of SID to be either a topological instruction (your draft meets that requirement) or service instruction (your draft fails to meet those requirements) To illustrate along with just a basic example from RFC8402 of service instruction - different per hop behavior treatment for traversing packets to be embedded into SID. So if you are only to associate SID with topological instructions you have no way to express transit service instructions so it seems pretty obvious that your proposal does not meet basic SR network programming requirements. That means that all you can provide is subset of SR Architecture requirements so perhaps to avoid industry confusion your solution should avoid use of SID or SR references. Perhaps as Tom already also observed we should call it MRH Mapped Routing Header instead. Kind regards, Robert. On Thu, Apr 18, 2019 at 10:29 PM Ron Bonica wrote: > Robert, > > > > The Compressed Routing Header (CRH) has exactly one function. That is to > route a packet for segment to segment along an SR path. Therefore, SIDs > contained by the CRH have only one function. That is to steer packets to > the next segment. > > > > Granted, we may want to program a service behavior at a segment endpoint. > IPv6 includes a Destination Options header that can be used to convey > information segment endpoints and destination options can contain service > SIDs. These service SIDs can be as long or short as they need to be. See > draft-bonica-6man-vpn-dest-opt for an example. > > > > > Ron > > > > > > Juniper Internal > > *From:* Robert Raszuk > *Sent:* Thursday, April 18, 2019 10:30 AM > *To:* Ron Bonica > *Cc:* Gyan Mishra ; Tom Herbert < > tom@herbertland.com>; SPRING WG ; ipv6@ietf.org; Dino > Farinacci ; lisp@ietf.org list > *Subject:* Re: [spring] IPv6-compressed-routing-header-crh > > > > Hi Ron, > > > > I must observe that your analysis is incorrect. > > > > SIDs are not only used for TE or traffic steering purposes but what is > even more interesting for various functions - for example NFV. > > > > So you need as much SIDs as possible imagination of your value add networ= k > functions - which will be different from those functions at the encap dst > which as you indicate in other draft can be carried in destination option= s. > > > > That debate is still I think open. > > > > Thx, > > R. > > > > > > On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica wrote: > > Gyan, > > > > Let=E2=80=99s think about how a network operator might choose a SID size= =E2=80=A6. > > > > Assume that an MAN includes 100 routers. These routers are connected to > one another by infrastructure links. Each router has 20 or fewer > infrastructure links. > > > > The network operator might assign one loosely routes SID to each router. > These loosely routed SIDs have network-wide significance (i.e., the canno= t > be reused). > > > > The network operator might also assign one strictly routed SID to each > link. The strictly routed SIDs have node-local significance only. They ca= n > be reused from one node to another. > > > > So, in this case, the network operator only needs 120 SIDs. This fits in > eight bits with plenty of room for growth. > > > > Now consider another network that includes 30,000 routers. Each router is > connected to its peers by 200 infrastructure links or fewer. This networ= k > would need 30,200 SIDs. This would fit in 16 bits. > > > > A **really big** network might require more than 32,000 SIDs. So, we > support a 32-bit SID. > > > > > Ron > > > > > > > > > > Juniper Internal > > *From:* Gyan Mishra > *Sent:* Wednesday, April 17, 2019 10:00 PM > *To:* Ron Bonica > *Cc:* Robert Raszuk ; Tom Herbert ; > SPRING WG ; ipv6@ietf.org; Dino Farinacci < > farinacci@gmail.com>; lisp@ietf.org list > *Subject:* Re: [spring] IPv6-compressed-routing-header-crh > > > > > > I agree to make the SID align on word boundaries but I am thinking the > software should have hardware independence if at all possible. > > > > I think 32 bit is a reasonable size. > > > > > > Gyan S. Mishra > > IT Network Engineering & Technology Consultant > > Routing & Switching / Service Provider MPLS & IPv6 Expert > > www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT > > > Mobile =E2=80=93 202-734-1000 > > > > Sent from my iPhone > > > On Apr 14, 2019, at 7:54 PM, Ron Bonica < > rbonica=3D40juniper.net@dmarc.ietf.org> wrote: > > Hi Robert, > > > > In order to make the CRH ASIC-friendly, we have the following constraints= : > > > > - Support only a small handful of SID lengths > - If at all possible, make them align on word boundaries > > > > Currently, we support 8, 16 and 32 bytes. Do you see a reason why we > should support a length greater than 32? Is there some length less than 3= 2 > that would be beneficial? > > > > Ron > > > > > > > > Juniper Internal > > *From:* spring *On Behalf Of *Robert Raszuk > *Sent:* Friday, April 12, 2019 6:13 PM > *To:* Tom Herbert > *Cc:* SPRING WG ; ipv6@ietf.org; Mark Smith < > markzzzsmith@gmail.com>; Dino Farinacci ; > lisp@ietf.org list > *Subject:* Re: [spring] IPv6-compressed-routing-header-crh > > > > Hi Tom, > > > > I already suggested this on March 30th ... > > > > *"**PS. But if you choose to go ahead with CRH I would highly advise to > make your CRH SID a variable length. "* > > > > No feedback/response was received from authors. > > > > Thx, > R. > > > > On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert wrote: > > On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrote= : > > > > Hi Tom, > > > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: > > > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk > wrote: > > > > > > > > Hi Mark, > > > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundar= y > and a 32 bit alignment, > > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 > network. > > > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may > also create some opportunities to > > > > > leverage IPv4 support in existing protocols to suite carrying and > processing 32 bit SIDs with some, possibly > > > > > slight, modification. For example, perhaps IPv4 Address Family > support in OSPFv3 (RFC 5838) could be > > > > > somehow leveraged to suit SR. > > > > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > > > I think SR while indeed started with the story of "less control > plane is good for you" now clearly has evolved into not only reduction of > control plane but what can be even more important to some users ability t= o > request specific behavior via programmed functions of network elements on= a > per flow basis without actually per flow or per path signalling or state. > > > > > > > > Yes for some it may be very useful feature and I am sure some will > call it overload of data plane or . There is no one size fits all. > > > > > > > > With that let's observe that till today SR did not require any new > mapping plane to be distributed in control plane and to be inserted into > data plane. This is clearly a precedent. > > > > > > > > Furthermore as we see in companion documents all additional network > functionality is being taken away from SRH and is being shifted to > Destination Options . > > > > > > > > As far as mapping plane I already pointed out in my Vector Routing > proposal that we have one already it is called BGP. One needs to also > observe that we as industry worked number of years of protocol suite call= ed > LISP allowing not only very good mapping plane, but also data plane > integration. CC-ing lisp authors for their comments. Note also work for > integrating SRv6 with LISP which is already is published. > > > > > > > > Since you correctly observed that now SID can be 32 bit and that is > similar to the size of IPv4 my fundamental question is why not use > something which already exists instead of defining some sort of new from > scratch ? > > > > > > > Robert, > > > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > > please provide a reference? > > > > > > > To clarify, I've been thinking about the idea of a smaller SID size > > for IPv6 for a while now (since inserting EHs came up), and thought > > about what would be a generic single size that might suit SR that > > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > > me, although if people wanted bigger, I'd be suggesting 64 bits (not > > entirely coincidentally the common IID size.) > > > > Ron and others have written this draft, which supports SIDS of various > > sizes - 8, 16 or 32 bits - that triggered this discussion. > > > Mark, > > Why not just put a SID length field in the header (like RFC6554 but > more generic). That would allow lengths of 1-16 bytes. Additional > flags could be used to indicate the semantics of the entries. For > instance, they might be actual addresses (128 bits for IPv6, 32 bits > for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) > where the rest of the address can be inferred, indices into a table, > labels, etc. > > Tom > > > "The IPv6 Compressed Routing Header (CRH)" > > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > > > > Regards, > > Mark. > > > > > > > As for trying to use something that already exists, why does SR used = a > > > fixed size format for SIDs instead of a variable length format like > > > that described in RFC6554? Similarly, why does SR define it's own TLV > > > format instead of using Hop-by-Hop and Destination Options defined in > > > RFC8200? > > > > > > Tom > > > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LIS= P > or Vector Routing as an alternative options. I really do not see a room o= r > need for yet one more mapping plane. What problem does it solve which wou= ld > not be already solved elsewhere ? > > > > > > > > Kind regards, > > > > Robert > > > > > > > > > > > >>> 2) Is there an agreement that solutions which require additional > per SR path state in both control plane and now in data plane are really > something we should be endorsing here ? > > > >> > > > >> > > > >> I think so. > > > >> > > > >> My understanding of what SR is fundamentally about is to reduce > control plane state and processing. The trade-off for reduced control pla= ne > state and processing is to instead carry and encode most or all of that > information or its semantics as per-packet overhead. > > > >> > > > >> If the per-packet overhead becomes too large and expensive, then > pushing some of that information and processing back into the control pla= ne > should be ok, as long as there is still a beneficial overall reduction in > control plane state and processing. > > > >> > > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary > and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perfor= m > SR in an IPv6 network. > > > >> > > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may > also create some opportunities to leverage IPv4 support in existing > protocols to suite carrying and processing 32 bit SIDs with some, possibl= y > slight, modification. For example, perhaps IPv4 Address Family support in > OSPFv3 (RFC 5838) could be somehow leveraged to suit SR. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > -------------------------------------------------------------------= - > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf....org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > -------------------------------------------------------------------= - > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > --000000000000ddfd8f0586d43b87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ron,

> The Compressed Routing Header (CRH) has exactly one function. That = is to route a packet for=C2=A0
> segment to segment along an S= R path. Therefore, SIDs contained by the CRH have only one=C2=A0
= > function. That is to steer packets to the next segment.
=
Indeed and that is precisely where the fundamental problem r= esides with your proposal.=C2=A0

Let's take a = look at RFC8402 -=C2=A0Segment Routing Architecture.=C2=A0

In body of the above RFC we clearly see definition of SID to be ei= ther a topological instruction (your draft meets that requirement) or servi= ce instruction (your draft fails to meet those requirements)=C2=A0

To illustrate along with just a basic example from RFC8402= of service instruction - different per hop behavior treatment for traversi= ng packets to be embedded into SID.=C2=A0

So if yo= u are only to associate SID with topological instructions you have no way t= o express transit service instructions so it seems pretty obvious that your= proposal does not meet basic SR network programming requirements.=C2=A0

That means that all you can provide is subset of SR = Architecture requirements so perhaps to avoid industry confusion your solut= ion should avoid use of SID or SR references. Perhaps as Tom already also o= bserved we should call it MRH Mapped Routing Header instead.=C2=A0

Kind=C2=A0regards,
Robert.

On T= hu, Apr 18, 2019 at 10:29 PM Ron Bonica <rbonica@juniper.net> wrote:

= Robert,

= =C2=A0

= The Compressed Routing Header (CRH) has exactly one function. That is to ro= ute a packet for segment to segment along an SR path. Therefore, SIDs conta= ined by the CRH have only one function. That is to steer packets to the next segment.

= =C2=A0

= Granted, we may want to program a service behavior at a segment endpoint. I= Pv6 includes a Destination Options header that can be used to convey inform= ation segment endpoints and destination options can contain service SIDs. These service SIDs can be as long or short as th= ey need to be. See draft-bonica-6man-vpn-dest-opt for an example.=

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Ron

= =C2=A0

=C2=A0

Juniper Internal

From: Robert Raszuk <robert@raszuk.net>
Sent: Thursday, April 18, 2019 10:30 AM
To: Ron Bonica <rbonica@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Tom Herbert <tom@herbertland.com>; SPRIN= G WG <spring@ietf.o= rg>; ipv6@ietf.or= g; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>
Subject: Re: [spring] IPv6-compressed-routing-header-crh

=C2=A0

Hi Ron,

=C2=A0

I must observe that your analysis is incorrect.=C2= =A0

=C2=A0

SIDs are not only used for TE or traffic steering pu= rposes but what is even more interesting for various functions - for exampl= e NFV.=C2=A0

=C2=A0

So you need as much SIDs as possible imagination of = your value add network functions - which will be different from those funct= ions at the encap dst which as you indicate in other draft can be carried i= n destination options.=C2=A0

=C2=A0

That debate is still I think open.=C2=A0

=C2=A0

Thx,

R.

=C2=A0

=C2=A0

On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica <rbonica@juniper.net= > wrote:

= Gyan,

= =C2=A0

= Let=E2=80=99s think about how a network operator might choose a SID size=E2= =80=A6.

= =C2=A0

= Assume that an MAN includes 100 routers. These routers are connected to one= another by infrastructure links. Each router has 20 or fewer infrastructure links.

= =C2=A0

= The network operator might assign one loosely routes SID to each router. Th= ese loosely routed SIDs have network-wide significance (i.e., the cannot be reused).

= =C2=A0

= The network operator might also assign one strictly routed SID to each link= . The strictly routed SIDs have node-local significance only. They can be reused from one node to another.

= =C2=A0

= So, in this case, the network operator only needs 120 SIDs. This fits in ei= ght bits with plenty of room for growth.

= =C2=A0

= Now consider another network that includes 30,000 routers. Each router is c= onnected to its peers by 200 infrastructure links or fewer.=C2=A0 This network would need 30,200 SIDs. This would fit in 16 bits.<= /u>

= =C2=A0

= A *really big* network might require more than 32,000 SIDs. So, we s= upport a 32-bit SID.

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Ron

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0

Juniper Internal

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Wednesday, April 17, 2019 10:00 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>; Tom Herbert <tom@herbertland.com>; SPRING WG &l= t;spring@ietf.org&= gt;; ipv6@ietf.org; Dino = Farinacci <fari= nacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh

=C2=A0

=C2=A0

I agree to make the SID align on word boundaries but= I am thinking the software should have hardware independence if at all pos= sible.

=C2=A0

I think 32 bit is a reasonable size.

=C2=A0

=C2=A0

Gyan S. Mishra

IT Network Engineering & Technology Consultant

Routing & Switching / Service Provider MPLS &= ; IPv6 Expert

Mobile =E2=80=93=C2=A0202-734-1000

=C2=A0

Sent from my iPhone


On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=3D40juniper.net@dmarc.= ietf.org> wrote:

= Hi Robert,

= =C2=A0

= In order to make the CRH ASIC-friendly, we have the following constraints:<= /span>

= =C2=A0

  • Support only a small handful of SID lengths<= /span>
  • If at all possible, make them align on word = boundaries

= =C2=A0

= Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should= support a length greater than 32? Is there some length less than 32 that would be beneficial?

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Ron

= =C2=A0

= =C2=A0

=C2=A0

Juniper Internal

From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <tom@herbertland.com>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Mark = Smith <markz= zzsmith@gmail.com>; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh

=C2=A0

Hi Tom,

=C2=A0

I already suggested this on March 30th ...=C2=A0<= /u>

=C2=A0

"PS. But if you choose to go ahead with CRH I would highly advise t= o make your CRH SID a variable length. "

=C2=A0

No feed= back/response was received from authors.=C2=A0

=C2=A0

Thx, R.

=C2=A0

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.c= om> wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote: > > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform = SR in an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network elements on a per flow basis without actually per flo= w or per path signalling or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not requi= re any new mapping plane to be distributed in control plane and to be inser= ted into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comm= ents. Note also work for integrating SRv6 with LISP which is already is pub= lished.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new=C2=A0 f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. C= an you
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID siz= e
> for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable t= o
> me, although if people wanted bigger, I'd be suggesting 64 bits (n= ot
> entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's= own TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequ= ate to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leverage= d to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf= ....org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------

----------------------------------------------------= ----------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------=

--000000000000ddfd8f0586d43b87-- From nobody Thu Apr 18 14:30:29 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3565712017E for ; Thu, 18 Apr 2019 14:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 3caFz70Gx-AD for ; Thu, 18 Apr 2019 14:30:15 -0700 (PDT) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (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 AC131120163 for ; Thu, 18 Apr 2019 14:30:13 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id g1so2014761qki.5 for ; Thu, 18 Apr 2019 14:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dB53xf/7m+ClKvNYDoernxO9Ha+p4vW4Tk9X2hjMlfA=; b=SBvcTkiBanJpjN+Qigcn8AjIcXh2ISTet2XA7vHv0Ak5Fyt+VFqnGh8DdyPC5kM1vL IUlbqTzWB/uzlXqoRqsCZBe9bCSmXz8TKxXoI/C0XB9tAED6jkbvdleRxlnOmDVkyMSd V00xHKjxE0Ni7O3CaLWmdcsn6vvRG92cx0jZJ95jxcIt0pqFxQGTkFHf7hvEtd7xIMiS ZltqJ7YWqXq1GZARHvgUc5IMBNHqNIlf8863P1oSFchVH4SrTz5iJIpWWzVCxZp6zQzo NCMQ60L4BFefCk3vVGzMAC3fit0vYu3KMkAitvNjFbDhZH56NNMwVzCvN1P03EEqGu5k dfYw== 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:content-transfer-encoding; bh=dB53xf/7m+ClKvNYDoernxO9Ha+p4vW4Tk9X2hjMlfA=; b=OHl1cwa2XhVA6RYSiRHdETopthejj5gFwXD2YydVpkQJKGBYvIak+fskoR3RG4O2yx AfMADxtloilfDgYFq/iAmFiYbTH+li2QINFeGDLAhrQiTE8DuZlYFXzkuBI5Vkjpv5nk 8bvRZWRydWPwzzIeA3FiIgQ6xyWpmelVo9qxUFbu5FWfWwuM6//fD3bDaxmTDk8+1apt 3llZcMe5YxAauf9rgoxa8+4cZU6OxIHhCWD2B222TnvgGhnRr9MYXVRyJh11uT3BAgg+ 5CttrDxEKrdJtjeAVqc86KPi3BjU7kjqatzy2HEP91c3TIK+weKktbvgtuIo7PljRWTq yTAA== X-Gm-Message-State: APjAAAXlZ+7OGpG8AekRXWR4Ox1pW6x/+IR4EBywYlSv6oi/I1CV36a4 XzlEhRlYMKrEWKkUGpHLSj9f+sBHQ73CX+F9nlY7Ww== X-Google-Smtp-Source: APXvYqxr6VmksluDv+4BOC/rValaM39qIQ+MCYZeXA4IhUe8YgUT0CiVjpvP1IQbLwdMqyBHvDaZZfkjDMDdLmb5zuo= X-Received: by 2002:a37:a34a:: with SMTP id m71mr214331qke.323.1555623012476; Thu, 18 Apr 2019 14:30:12 -0700 (PDT) MIME-Version: 1.0 References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> In-Reply-To: From: Tom Herbert Date: Thu, 18 Apr 2019 14:30:00 -0700 Message-ID: To: Robert Raszuk Cc: Ron Bonica , Gyan Mishra , SPRING WG , "ipv6@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 21:30:20 -0000 On Thu, Apr 18, 2019 at 1:56 PM Robert Raszuk wrote: > > Hi Ron, > > > The Compressed Routing Header (CRH) has exactly one function. That is t= o route a packet for > > segment to segment along an SR path. Therefore, SIDs contained by the C= RH have only one > > function. That is to steer packets to the next segment. > > Indeed and that is precisely where the fundamental problem resides with y= our proposal. > > Let's take a look at RFC8402 - Segment Routing Architecture. > > In body of the above RFC we clearly see definition of SID to be either a = topological instruction (your draft meets that requirement) or service inst= ruction (your draft fails to meet those requirements) > > To illustrate along with just a basic example from RFC8402 of service ins= truction - different per hop behavior treatment for traversing packets to b= e embedded into SID. > > So if you are only to associate SID with topological instructions you hav= e no way to express transit service instructions so it seems pretty obvious= that your proposal does not meet basic SR network programming requirements= . > > That means that all you can provide is subset of SR Architecture requirem= ents so perhaps to avoid industry confusion your solution should avoid use = of SID or SR references. Perhaps as Tom already also observed we should cal= l it MRH Mapped Routing Header instead. Robert, I think I was actually making the opposite argument. The routing entries in CRH are not addresses and not in themselves topological, they're values that need to be mapped at each hop. They require interpretation in the context of a shared state and network wide configuration, so effectively all CRH entries _are_ instructions. The fact that entries in CRH are defined only to map to addresses seems to be a deliberate design choice as opposed to a limitation in the design. But, assuming that one did want to allow SIDs to represent arbitrary instructions, I still don't understand why you'd need 128 bit numbers for that-- it seems like 32 or 16 bits would be enough. Tom > > Kind regards, > Robert. > > On Thu, Apr 18, 2019 at 10:29 PM Ron Bonica wrote: >> >> Robert, >> >> >> >> The Compressed Routing Header (CRH) has exactly one function. That is to= route a packet for segment to segment along an SR path. Therefore, SIDs co= ntained by the CRH have only one function. That is to steer packets to the = next segment. >> >> >> >> Granted, we may want to program a service behavior at a segment endpoint= . IPv6 includes a Destination Options header that can be used to convey inf= ormation segment endpoints and destination options can contain service SIDs= . These service SIDs can be as long or short as they need to be. See draft-= bonica-6man-vpn-dest-opt for an example. >> >> >> >> = Ron >> >> >> >> >> >> Juniper Internal >> >> From: Robert Raszuk >> Sent: Thursday, April 18, 2019 10:30 AM >> To: Ron Bonica >> Cc: Gyan Mishra ; Tom Herbert ; SPRING WG ; ipv6@ietf.org; Dino Farinacci ; lisp@ietf.org list >> Subject: Re: [spring] IPv6-compressed-routing-header-crh >> >> >> >> Hi Ron, >> >> >> >> I must observe that your analysis is incorrect. >> >> >> >> SIDs are not only used for TE or traffic steering purposes but what is e= ven more interesting for various functions - for example NFV. >> >> >> >> So you need as much SIDs as possible imagination of your value add netwo= rk functions - which will be different from those functions at the encap ds= t which as you indicate in other draft can be carried in destination option= s. >> >> >> >> That debate is still I think open. >> >> >> >> Thx, >> >> R. >> >> >> >> >> >> On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica wrote: >> >> Gyan, >> >> >> >> Let=E2=80=99s think about how a network operator might choose a SID size= =E2=80=A6. >> >> >> >> Assume that an MAN includes 100 routers. These routers are connected to = one another by infrastructure links. Each router has 20 or fewer infrastruc= ture links. >> >> >> >> The network operator might assign one loosely routes SID to each router.= These loosely routed SIDs have network-wide significance (i.e., the cannot= be reused). >> >> >> >> The network operator might also assign one strictly routed SID to each l= ink. The strictly routed SIDs have node-local significance only. They can b= e reused from one node to another. >> >> >> >> So, in this case, the network operator only needs 120 SIDs. This fits in= eight bits with plenty of room for growth. >> >> >> >> Now consider another network that includes 30,000 routers. Each router i= s connected to its peers by 200 infrastructure links or fewer. This networ= k would need 30,200 SIDs. This would fit in 16 bits. >> >> >> >> A *really big* network might require more than 32,000 SIDs. So, we suppo= rt a 32-bit SID. >> >> >> >> = Ron >> >> >> >> >> >> >> >> >> >> Juniper Internal >> >> From: Gyan Mishra >> Sent: Wednesday, April 17, 2019 10:00 PM >> To: Ron Bonica >> Cc: Robert Raszuk ; Tom Herbert = ; SPRING WG ; ipv6@ietf.org; Dino Farinacci ; lisp@ietf.org list >> Subject: Re: [spring] IPv6-compressed-routing-header-crh >> >> >> >> >> >> I agree to make the SID align on word boundaries but I am thinking the s= oftware should have hardware independence if at all possible. >> >> >> >> I think 32 bit is a reasonable size. >> >> >> >> >> >> Gyan S. Mishra >> >> IT Network Engineering & Technology Consultant >> >> Routing & Switching / Service Provider MPLS & IPv6 Expert >> >> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT >> >> Mobile =E2=80=93 202-734-1000 >> >> >> >> Sent from my iPhone >> >> >> On Apr 14, 2019, at 7:54 PM, Ron Bonica wrote: >> >> Hi Robert, >> >> >> >> In order to make the CRH ASIC-friendly, we have the following constraint= s: >> >> >> >> Support only a small handful of SID lengths >> If at all possible, make them align on word boundaries >> >> >> >> Currently, we support 8, 16 and 32 bytes. Do you see a reason why we sho= uld support a length greater than 32? Is there some length less than 32 tha= t would be beneficial? >> >> >> >> Ron >> >> >> >> >> >> >> >> Juniper Internal >> >> From: spring On Behalf Of Robert Raszuk >> Sent: Friday, April 12, 2019 6:13 PM >> To: Tom Herbert >> Cc: SPRING WG ; ipv6@ietf.org; Mark Smith ; Dino Farinacci ; lisp@ietf.org list >> Subject: Re: [spring] IPv6-compressed-routing-header-crh >> >> >> >> Hi Tom, >> >> >> >> I already suggested this on March 30th ... >> >> >> >> "PS. But if you choose to go ahead with CRH I would highly advise to mak= e your CRH SID a variable length. " >> >> >> >> No feedback/response was received from authors. >> >> >> >> Thx, >> R. >> >> >> >> On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert wrote= : >> >> On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrot= e: >> > >> > Hi Tom, >> > >> > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: >> > > >> > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wr= ote: >> > > > >> > > > Hi Mark, >> > > > >> > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet bounda= ry and a 32 bit alignment, >> > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6= network. >> > > > > >> > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that ma= y also create some opportunities to >> > > > > leverage IPv4 support in existing protocols to suite carrying an= d processing 32 bit SIDs with some, possibly >> > > > > slight, modification. For example, perhaps IPv4 Address Family s= upport in OSPFv3 (RFC 5838) could be >> > > > > somehow leveraged to suit SR. >> > > > >> > > > >> > > > Thank you for describing your understanding of fundamentals of SR. >> > > > >> > > > I think SR while indeed started with the story of "less control pl= ane is good for you" now clearly has evolved into not only reduction of con= trol plane but what can be even more important to some users ability to req= uest specific behavior via programmed functions of network elements on a pe= r flow basis without actually per flow or per path signalling or state. >> > > > >> > > > Yes for some it may be very useful feature and I am sure some will= call it overload of data plane or . There is no one size fits all. >> > > > >> > > > With that let's observe that till today SR did not require any new= mapping plane to be distributed in control plane and to be inserted into d= ata plane. This is clearly a precedent. >> > > > >> > > > Furthermore as we see in companion documents all additional networ= k functionality is being taken away from SRH and is being shifted to Destin= ation Options . >> > > > >> > > > As far as mapping plane I already pointed out in my Vector Routing= proposal that we have one already it is called BGP. One needs to also obse= rve that we as industry worked number of years of protocol suite called LIS= P allowing not only very good mapping plane, but also data plane integratio= n. CC-ing lisp authors for their comments. Note also work for integrating S= Rv6 with LISP which is already is published. >> > > > >> > > > Since you correctly observed that now SID can be 32 bit and that i= s similar to the size of IPv4 my fundamental question is why not use someth= ing which already exists instead of defining some sort of new from scratch= ? >> > > > >> > > Robert, >> > > >> > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you >> > > please provide a reference? >> > > >> > >> > To clarify, I've been thinking about the idea of a smaller SID size >> > for IPv6 for a while now (since inserting EHs came up), and thought >> > about what would be a generic single size that might suit SR that >> > wasn't the same size as an IPv6 address. 32 bits seemed suitable to >> > me, although if people wanted bigger, I'd be suggesting 64 bits (not >> > entirely coincidentally the common IID size.) >> > >> > Ron and others have written this draft, which supports SIDS of various >> > sizes - 8, 16 or 32 bits - that triggered this discussion. >> > >> Mark, >> >> Why not just put a SID length field in the header (like RFC6554 but >> more generic). That would allow lengths of 1-16 bytes. Additional >> flags could be used to indicate the semantics of the entries. For >> instance, they might be actual addresses (128 bits for IPv6, 32 bits >> for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) >> where the rest of the address can be inferred, indices into a table, >> labels, etc. >> >> Tom >> >> > "The IPv6 Compressed Routing Header (CRH)" >> > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 >> > >> > Regards, >> > Mark. >> > >> > >> > > As for trying to use something that already exists, why does SR used= a >> > > fixed size format for SIDs instead of a variable length format like >> > > that described in RFC6554? Similarly, why does SR define it's own TL= V >> > > format instead of using Hop-by-Hop and Destination Options defined i= n >> > > RFC8200? >> > > >> > > Tom >> > > >> > > > It will be perfectly fine to have full proper SRv6 with SRH and LI= SP or Vector Routing as an alternative options. I really do not see a room = or need for yet one more mapping plane. What problem does it solve which wo= uld not be already solved elsewhere ? >> > > > >> > > > Kind regards, >> > > > Robert >> > > > >> > > > >> > > >>> 2) Is there an agreement that solutions which require additional= per SR path state in both control plane and now in data plane are really s= omething we should be endorsing here ? >> > > >> >> > > >> >> > > >> I think so. >> > > >> >> > > >> My understanding of what SR is fundamentally about is to reduce c= ontrol plane state and processing. The trade-off for reduced control plane = state and processing is to instead carry and encode most or all of that inf= ormation or its semantics as per-packet overhead. >> > > >> >> > > >> If the per-packet overhead becomes too large and expensive, then = pushing some of that information and processing back into the control plane= should be ok, as long as there is still a beneficial overall reduction in = control plane state and processing. >> > > >> >> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundar= y and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perfor= m SR in an IPv6 network. >> > > >> >> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may= also create some opportunities to leverage IPv4 support in existing protoc= ols to suite carrying and processing 32 bit SIDs with some, possibly slight= , modification. For example, perhaps IPv4 Address Family support in OSPFv3 = (RFC 5838) could be somehow leveraged to suit SR. >> > > >> >> > > >> Regards, >> > > >> Mark. >> > > > >> > > > ------------------------------------------------------------------= -- >> > > > IETF IPv6 working group mailing list >> > > > ipv6@ietf....org >> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6 >> > > > ------------------------------------------------------------------= -- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Thu Apr 18 14:43:04 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52B11203FA for ; Thu, 18 Apr 2019 14:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 SVSiPpU5N8eY for ; Thu, 18 Apr 2019 14:42:51 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 8C1E112037E for ; Thu, 18 Apr 2019 14:42:51 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id z17so3755666qts.13 for ; Thu, 18 Apr 2019 14:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F4nVACGHNR4ExvK82YgqAizIKZW1ff+aQLDis4BxqJQ=; b=bkC9BdXpBeTtV67+NOe/ep+NUbht8N3y6/h77ECbYSRz/w7giTBu2xcJf4UJ9DXGcD ggadUBCFzQf5dQqv+eB57tiI3LM538rwih++NQsmq5PMKQXNaqGgviXAvzbjeSi61L4/ geZeDVekGG/vNdVfow92sE9gmnRRyLYpQa24wp33I4R9Twd4gCYFOb2hbS2KOerhYkfL ip4ifFuNdSXy+PwazkzRMaV321Ppbty74F5F5+pe1nVk6JnrkThCZ21rmZxZNIX53ZdX Sfe4iL5/q9Go3/rhx9jyWckVV7g2qcZchbWfu4Qg46xsKfxjssq6vyseinj3YWun3fN9 yJ/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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F4nVACGHNR4ExvK82YgqAizIKZW1ff+aQLDis4BxqJQ=; b=af+NZddVcfl4gojHZpcdMi3a70ygpeqyjmwLOgKz8GcBbrbQFz36EKcDN0atZJf59d M7+zraELuSCH0r2O7zr6AMf5m8jmzunwUkK7n/vvTHFqe455zDx2kn8yqR0wyjCExMpB B773b2BmQsmv1PzfFHfMx43gcgzw+cbwatzs3dt9w9BECcHKcycQPl3lpyDh3qP0TeS6 kC8IN0ts1vY0iQRNkq6NVP2q07FPGuDW08kNWlqCuffRLEwyaLlspE3btRt2eb0xVGzK AJPBApER6LQDqqJbihq+G07ndbBm214tRZfzobYStD63goxavpZBTcwuV3LUtbI8ZzJr l75A== X-Gm-Message-State: APjAAAVmuYZMpL/AlyD0qJ4cM2tacel6RjCQ+Y6T/1hfyNTDzgey3/XA 6D9VbMGTyMFT9bpFYmDZCogZ0eSfzUoVqlS9qo1FmQ== X-Google-Smtp-Source: APXvYqxcCQVezfx+XDHfZdat47n/pdp+0bNnF6vFxEUKjYohAflbdazN9SgW6GEjJ+VnNqTz5RyD/Vlolpq3N+zhGco= X-Received: by 2002:ac8:2899:: with SMTP id i25mr285479qti.361.1555623770570; Thu, 18 Apr 2019 14:42:50 -0700 (PDT) MIME-Version: 1.0 References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> In-Reply-To: From: Robert Raszuk Date: Thu, 18 Apr 2019 23:42:24 +0200 Message-ID: To: Tom Herbert Cc: Ron Bonica , Gyan Mishra , SPRING WG , "ipv6@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="0000000000003fd4da0586d4e2cb" Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 21:42:55 -0000 --0000000000003fd4da0586d4e2cb Content-Type: text/plain; charset="UTF-8" Hi Tom, > The fact that entries in CRH are defined only to map to addresses seems to > be a deliberate design choice as opposed to a limitation in the design. Yes this is true - any mapping can be used to express much more then topological information. See LISP as example :) My comment was not focused on the choice of solution based on mapping (modulo embedded question do we really new one more mapping system), but to the design choice made to *only* bind it to topological instructions. With that I do think it no longer meets SR Architecture primitives. Many thx, Robert. On Thu, Apr 18, 2019 at 11:30 PM Tom Herbert wrote: > On Thu, Apr 18, 2019 at 1:56 PM Robert Raszuk wrote: > > > > Hi Ron, > > > > > The Compressed Routing Header (CRH) has exactly one function. That is > to route a packet for > > > segment to segment along an SR path. Therefore, SIDs contained by the > CRH have only one > > > function. That is to steer packets to the next segment. > > > > Indeed and that is precisely where the fundamental problem resides with > your proposal. > > > > Let's take a look at RFC8402 - Segment Routing Architecture. > > > > In body of the above RFC we clearly see definition of SID to be either a > topological instruction (your draft meets that requirement) or service > instruction (your draft fails to meet those requirements) > > > > To illustrate along with just a basic example from RFC8402 of service > instruction - different per hop behavior treatment for traversing packets > to be embedded into SID. > > > > So if you are only to associate SID with topological instructions you > have no way to express transit service instructions so it seems pretty > obvious that your proposal does not meet basic SR network programming > requirements. > > > > That means that all you can provide is subset of SR Architecture > requirements so perhaps to avoid industry confusion your solution should > avoid use of SID or SR references. Perhaps as Tom already also observed we > should call it MRH Mapped Routing Header instead. > > Robert, > > I think I was actually making the opposite argument. The routing > entries in CRH are not addresses and not in themselves topological, > they're values that need to be mapped at each hop. They require > interpretation in the context of a shared state and network wide > configuration, so effectively all CRH entries _are_ instructions. The > fact that entries in CRH are defined only to map to addresses seems to > be a deliberate design choice as opposed to a limitation in the > design. But, assuming that one did want to allow SIDs to represent > arbitrary instructions, I still don't understand why you'd need 128 > bit numbers for that-- it seems like 32 or 16 bits would be enough. > > Tom > > > > > Kind regards, > > Robert. > > > > On Thu, Apr 18, 2019 at 10:29 PM Ron Bonica wrote: > >> > >> Robert, > >> > >> > >> > >> The Compressed Routing Header (CRH) has exactly one function. That is > to route a packet for segment to segment along an SR path. Therefore, SIDs > contained by the CRH have only one function. That is to steer packets to > the next segment. > >> > >> > >> > >> Granted, we may want to program a service behavior at a segment > endpoint. IPv6 includes a Destination Options header that can be used to > convey information segment endpoints and destination options can contain > service SIDs. These service SIDs can be as long or short as they need to > be. See draft-bonica-6man-vpn-dest-opt for an example. > >> > >> > >> > >> > Ron > >> > > --0000000000003fd4da0586d4e2cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,
> The=C2=A0fact that entries in CRH are defined only to map= to addresses seems to
> be a deliberate design choice as opposed to = a limitation in the=C2=A0design.=C2=A0=C2=A0

Y= es this is true - any mapping can be used to express much more then topolog= ical information. See LISP as example :)=C2=A0

My = comment was not focused on the choice of solution based on mapping (modulo = embedded question do we really new one more mapping system), but to the des= ign choice made to *only* bind it to topological instructions. With that I = do think it no longer meets SR Architecture primitives.=C2=A0
Many thx,
Robert.


On Thu, Apr 18,= 2019 at 11:30 PM Tom Herbert <to= m@herbertland.com> wrote:
On Thu, Apr 18, 2019 at 1:56 PM Robert Raszuk <robert@raszuk.net> w= rote:
>
> Hi Ron,
>
> > The Compressed Routing Header (CRH) has exactly one function. Tha= t is to route a packet for
> > segment to segment along an SR path. Therefore, SIDs contained by= the CRH have only one
> > function. That is to steer packets to the next segment.
>
> Indeed and that is precisely where the fundamental problem resides wit= h your proposal.
>
> Let's take a look at RFC8402 - Segment Routing Architecture.
>
> In body of the above RFC we clearly see definition of SID to be either= a topological instruction (your draft meets that requirement) or service i= nstruction (your draft fails to meet those requirements)
>
> To illustrate along with just a basic example from RFC8402 of service = instruction - different per hop behavior treatment for traversing packets t= o be embedded into SID.
>
> So if you are only to associate SID with topological instructions you = have no way to express transit service instructions so it seems pretty obvi= ous that your proposal does not meet basic SR network programming requireme= nts.
>
> That means that all you can provide is subset of SR Architecture requi= rements so perhaps to avoid industry confusion your solution should avoid u= se of SID or SR references. Perhaps as Tom already also observed we should = call it MRH Mapped Routing Header instead.

Robert,

I think I was actually making the opposite argument. The routing
entries in CRH are not addresses and not in themselves topological,
they're values that need to be mapped at each hop. They require
interpretation in the context of a shared state and network wide
configuration, so effectively all CRH entries _are_ instructions. The
fact that entries in CRH are defined only to map to addresses seems to
be a deliberate design choice as opposed to a limitation in the
design. But, assuming that one did want to allow SIDs to represent
arbitrary instructions, I still don't understand why you'd need 128=
bit numbers for that-- it seems like 32 or 16 bits would be enough.

Tom

>
> Kind regards,
> Robert.
>
> On Thu, Apr 18, 2019 at 10:29 PM Ron Bonica <rbonica@juniper.net> wrote:
>>
>> Robert,
>>
>>
>>
>> The Compressed Routing Header (CRH) has exactly one function. That= is to route a packet for segment to segment along an SR path. Therefore, S= IDs contained by the CRH have only one function. That is to steer packets t= o the next segment.
>>
>>
>>
>> Granted, we may want to program a service behavior at a segment en= dpoint. IPv6 includes a Destination Options header that can be used to conv= ey information segment endpoints and destination options can contain servic= e SIDs. These service SIDs can be as long or short as they need to be. See = draft-bonica-6man-vpn-dest-opt for an example.
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ron
>>

--0000000000003fd4da0586d4e2cb-- From nobody Thu Apr 18 14:57:45 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7827E120475; Thu, 18 Apr 2019 14:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 6yGqldJ-hbP5; Thu, 18 Apr 2019 14:57:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795D1120418; Thu, 18 Apr 2019 14:57:31 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 34C7F59AED34F913A471; Thu, 18 Apr 2019 22:57:29 +0100 (IST) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 18 Apr 2019 22:57:28 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.117]) by SJCEML702-CHM.china.huawei.com ([169.254.4.74]) with mapi id 14.03.0439.000; Thu, 18 Apr 2019 14:57:16 -0700 From: James N Guichard To: Ron Bonica , Robert Raszuk CC: SPRING WG , "ipv6@ietf.org" , "Dino Farinacci" , "lisp@ietf.org list" , James N Guichard Thread-Topic: [spring] IPv6-compressed-routing-header-crh Thread-Index: AQHU5XwSQNUFwLkE10qv/uSLYFT0BKYiu67wgAHl/gCAAB1LAIAABz2AgAC56wCAAMlxgIAS2BEAgABq6wCAABaTAIAAAQyAgANBIwCABNnsAIAAybQAgAAH/YCAAGRegP//n5KQ Date: Thu, 18 Apr 2019 21:57:15 +0000 Message-ID: References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.16] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA31364F26Asjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 21:57:42 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA31364F26Asjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, I am wondering about how do you plan to handle service SIDs (or any SID wit= h embedded functions) at intermediate nodes; draft-bonica-6man-vpn-dest-opt= seems to only handle the case where the endpoint will process the destinat= ion option: Section 4 says: "It MUST NOT appear in a Hop-by-hop Options header and SHOU= LD NOT appear in a Destination Options header that precedes a Routing heade= r". If you relax the latter and encode the SID in a destination option precedin= g the CRH (or SRH) then wouldn't every node in the segment-list have to pro= cess the SID and figure out whether it is a local SID or not? That would se= em to be overly complex given you could just encode the SID in the CRH (or = SRH) and only the node where said SID is exposed would process it. Thanks! Jim From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, April 18, 2019 4:30 PM To: Robert Raszuk Cc: SPRING WG ; ipv6@ietf.org; Dino Farinacci ; lisp@ietf.org list Subject: RE: [spring] IPv6-compressed-routing-header-crh Robert, The Compressed Routing Header (CRH) has exactly one function. That is to ro= ute a packet for segment to segment along an SR path. Therefore, SIDs conta= ined by the CRH have only one function. That is to steer packets to the nex= t segment. Granted, we may want to program a service behavior at a segment endpoint. I= Pv6 includes a Destination Options header that can be used to convey inform= ation segment endpoints and destination options can contain service SIDs. T= hese service SIDs can be as long or short as they need to be. See draft-bon= ica-6man-vpn-dest-opt for an example. = Ron Juniper Internal From: Robert Raszuk > Sent: Thursday, April 18, 2019 10:30 AM To: Ron Bonica > Cc: Gyan Mishra >; Tom = Herbert >; SPRING WG >; ipv6@ietf.org; D= ino Farinacci >; lisp@ietf.= org list > Subject: Re: [spring] IPv6-compressed-routing-header-crh Hi Ron, I must observe that your analysis is incorrect. SIDs are not only used for TE or traffic steering purposes but what is even= more interesting for various functions - for example NFV. So you need as much SIDs as possible imagination of your value add network = functions - which will be different from those functions at the encap dst w= hich as you indicate in other draft can be carried in destination options. That debate is still I think open. Thx, R. On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica > wrote: Gyan, Let's think about how a network operator might choose a SID size.... Assume that an MAN includes 100 routers. These routers are connected to one= another by infrastructure links. Each router has 20 or fewer infrastructur= e links. The network operator might assign one loosely routes SID to each router. Th= ese loosely routed SIDs have network-wide significance (i.e., the cannot be= reused). The network operator might also assign one strictly routed SID to each link= . The strictly routed SIDs have node-local significance only. They can be r= eused from one node to another. So, in this case, the network operator only needs 120 SIDs. This fits in ei= ght bits with plenty of room for growth. Now consider another network that includes 30,000 routers. Each router is c= onnected to its peers by 200 infrastructure links or fewer. This network w= ould need 30,200 SIDs. This would fit in 16 bits. A *really big* network might require more than 32,000 SIDs. So, we support = a 32-bit SID.. = Ron Juniper Internal From: Gyan Mishra > Sent: Wednesday, April 17, 2019 10:00 PM To: Ron Bonica > Cc: Robert Raszuk >; Tom Herber= t >; SPRING WG >; ipv6@ietf.org; Dino Fa= rinacci >; lisp@ietf.org list > Subject: Re: [spring] IPv6-compressed-routing-header-crh I agree to make the SID align on word boundaries but I am thinking the soft= ware should have hardware independence if at all possible. I think 32 bit is a reasonable size. Gyan S. Mishra IT Network Engineering & Technology Consultant Routing & Switching / Service Provider MPLS & IPv6 Expert www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT Mobile - 202-734-1000 Sent from my iPhone On Apr 14, 2019, at 7:54 PM, Ron Bonica > wrote: Hi Robert, In order to make the CRH ASIC-friendly, we have the following constraints: * Support only a small handful of SID lengths * If at all possible, make them align on word boundaries Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should= support a length greater than 32? Is there some length less than 32 that w= ould be beneficial? Ron Juniper Internal From: spring > On B= ehalf Of Robert Raszuk Sent: Friday, April 12, 2019 6:13 PM To: Tom Herbert > Cc: SPRING WG >; ipv6@ietf.org; Mark Smith >; Dino Farinacci = >; lisp@ietf.org list > Subject: Re: [spring] IPv6-compressed-routing-header-crh Hi Tom, I already suggested this on March 30th ... "PS. But if you choose to go ahead with CRH I would highly advise to make y= our CRH SID a variable length. " No feedback/response was received from authors. Thx, R. On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert > wrote: On Fri, Apr 12, 2019 at 1:48 PM Mark Smith > wrote: > > Hi Tom, > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert > wrote: > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk > wrote: > > > > > > Hi Mark, > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary = and a 32 bit alignment, > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 ne= twork. > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may a= lso create some opportunities to > > > > leverage IPv4 support in existing protocols to suite carrying and p= rocessing 32 bit SIDs with some, possibly > > > > slight, modification. For example, perhaps IPv4 Address Family supp= ort in OSPFv3 (RFC 5838) could be > > > > somehow leveraged to suit SR. > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > I think SR while indeed started with the story of "less control plane= is good for you" now clearly has evolved into not only reduction of contro= l plane but what can be even more important to some users ability to reques= t specific behavior via programmed functions of network elements on a per f= low basis without actually per flow or per path signalling or state. > > > > > > Yes for some it may be very useful feature and I am sure some will ca= ll it overload of data plane or . There is no one size fits all. > > > > > > With that let's observe that till today SR did not require any new ma= pping plane to be distributed in control plane and to be inserted into data= plane. This is clearly a precedent. > > > > > > Furthermore as we see in companion documents all additional network f= unctionality is being taken away from SRH and is being shifted to Destinati= on Options . > > > > > > As far as mapping plane I already pointed out in my Vector Routing pr= oposal that we have one already it is called BGP. One needs to also observe= that we as industry worked number of years of protocol suite called LISP a= llowing not only very good mapping plane, but also data plane integration. = CC-ing lisp authors for their comments. Note also work for integrating SRv6= with LISP which is already is published. > > > > > > Since you correctly observed that now SID can be 32 bit and that is s= imilar to the size of IPv4 my fundamental question is why not use something= which already exists instead of defining some sort of new from scratch ? > > > > > Robert, > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > please provide a reference? > > > > To clarify, I've been thinking about the idea of a smaller SID size > for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.) > > Ron and others have written this draft, which supports SIDS of various > sizes - 8, 16 or 32 bits - that triggered this discussion. > Mark, Why not just put a SID length field in the header (like RFC6554 but more generic). That would allow lengths of 1-16 bytes. Additional flags could be used to indicate the semantics of the entries. For instance, they might be actual addresses (128 bits for IPv6, 32 bits for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) where the rest of the address can be inferred, indices into a table, labels, etc. Tom > "The IPv6 Compressed Routing Header (CRH)" > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > Regards, > Mark. > > > > As for trying to use something that already exists, why does SR used a > > fixed size format for SIDs instead of a variable length format like > > that described in RFC6554? Similarly, why does SR define it's own TLV > > format instead of using Hop-by-Hop and Destination Options defined in > > RFC8200? > > > > Tom > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP = or Vector Routing as an alternative options. I really do not see a room or = need for yet one more mapping plane. What problem does it solve which would= not be already solved elsewhere ? > > > > > > Kind regards, > > > Robert > > > > > > > > >>> 2) Is there an agreement that solutions which require additional pe= r SR path state in both control plane and now in data plane are really some= thing we should be endorsing here ? > > >> > > >> > > >> I think so. > > >> > > >> My understanding of what SR is fundamentally about is to reduce cont= rol plane state and processing. The trade-off for reduced control plane sta= te and processing is to instead carry and encode most or all of that inform= ation or its semantics as per-packet overhead. > > >> > > >> If the per-packet overhead becomes too large and expensive, then pus= hing some of that information and processing back into the control plane sh= ould be ok, as long as there is still a beneficial overall reduction in con= trol plane state and processing. > > >> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary a= nd a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform S= R in an IPv6 network. > > >> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may al= so create some opportunities to leverage IPv4 support in existing protocols= to suite carrying and processing 32 bit SIDs with some, possibly slight, m= odification. For example, perhaps IPv4 Address Family support in OSPFv3 (RF= C 5838) could be somehow leveraged to suit SR. > > >> > > >> Regards, > > >> Mark. > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.....org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA31364F26Asjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ron,

 

I am wondering about h= ow do you plan to handle service SIDs (or any SID with embedded functions) = at intermediate nodes; draft-bonica-6man-vpn-dest-opt seems to only handle = the case where the endpoint will process the destination option:

 

Section 4 says: “It MUST NOT appear in a Hop-by-ho= p Options header and SHOULD NOT appear in a Destination Options header that= precedes a Routing header”.

 

If you rel= ax the latter and encode the SID in a destination option preceding the CRH = (or SRH) then wouldn’t every node in the segment-list have to process= the SID and figure out whether it is a local SID or not? That would seem to be overly complex given you could just enco= de the SID in the CRH (or SRH) and only the node where said SID is exposed = would process it.

 = ;

Thanks!

 = ;

Jim

 

From: ipv6 [mailto:ipv6-bounces@ietf.org] = On Behalf Of Ron Bonica
Sent: Thursday, April 18, 2019 4:30 PM
To: Robert Raszuk <robert@raszuk.net>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci= <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>
Subject: RE: [spring] IPv6-compressed-routing-header-crh<= /p>

 

Rober= t,

=  

The C= ompressed Routing Header (CRH) has exactly one function. That is to route a= packet for segment to segment along an SR path. Therefore, SIDs contained = by the CRH have only one function. That is to steer packets to the next segment.

=  

Grant= ed, we may want to program a service behavior at a segment endpoint. IPv6 i= ncludes a Destination Options header that can be used to convey information= segment endpoints and destination options can contain service SIDs. These service SIDs can be as long or short as th= ey need to be. See draft-bonica-6man-vpn-dest-opt for an example.

=  

 = ;            &n= bsp;            = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p; Ron

=  

 

Juniper Internal=

From: Robert Raszuk <robert@raszuk.net>
Sent: Thursday, April 18, 2019 10:30 AM
To: Ron Bonica <rbonica@ju= niper.net>
Cc: Gyan Mishra <hayabus= agsm@gmail.com>; Tom Herbert <tom@herbertland.com>; SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

Hi Ron,

 

I must observe that your analysis is incorrect. = ;

 

SIDs are not only used for TE or traffic steering pu= rposes but what is even more interesting for various functions - for exampl= e NFV. 

 

So you need as much SIDs as possible imagination of = your value add network functions - which will be different from those funct= ions at the encap dst which as you indicate in other draft can be carried i= n destination options. 

 

That debate is still I think open. <= /p>

 

Thx,

R.

 

 

On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica <rbonica@juniper.net> wrote:

Gyan,

 <= /o:p>

Let’s think a= bout how a network operator might choose a SID size….

 <= /o:p>

Assume that an MAN = includes 100 routers. These routers are connected to one another by infrast= ructure links. Each router has 20 or fewer infrastructure links.

 <= /o:p>

The network operato= r might assign one loosely routes SID to each router. These loosely routed = SIDs have network-wide significance (i.e., the cannot be reused).

 <= /o:p>

The network operato= r might also assign one strictly routed SID to each link. The strictly rout= ed SIDs have node-local significance only. They can be reused from one node to another.

 <= /o:p>

So, in this case, t= he network operator only needs 120 SIDs. This fits in eight bits with plent= y of room for growth.

 <= /o:p>

Now consider anothe= r network that includes 30,000 routers. Each router is connected to its pee= rs by 200 infrastructure links or fewer.  This network would need 30,200 SIDs. This would fit in 16 bits.

 <= /o:p>

A *really big* network might require more than 32,000 SIDs. So, we support a 32-bit SID= ..

 <= /o:p>

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Ron

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

Juniper Internal=

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Wednesday, April 17, 2019 10:00 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>; Tom Herbert <tom@herbertland.com>; SPRING WG &l= t;spring@ietf.org&= gt;; ipv6@ietf.org; Dino = Farinacci <fari= nacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

 

I agree to make the SID align on word boundaries but I am thinking= the software should have hardware independence if at all possible.

 

I think 32 bit is a reasonable size.

 

 

Gyan S. Mishra

IT Network Engineering & Technology Consultant

Routing & Switching / Service Provider MPLS & IPv6 Expert<= o:p>

Mobile – 202-734-1000

 

Sent from my iPhone


On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=3D40juniper.net@dmarc.= ietf.org> wrote:

Hi Robert,

 <= /o:p>

In order to make th= e CRH ASIC-friendly, we have the following constraints:

 <= /o:p>

·       &= nbsp; Support only a small handful of SID lengths

·       &= nbsp; If at all possible, make them align on word boundaries

 <= /o:p>

Currently, we suppo= rt 8, 16 and 32 bytes. Do you see a reason why we should support a length g= reater than 32? Is there some length less than 32 that would be beneficial?

 <= /o:p>

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            Ron

 <= /o:p>

 <= /o:p>

 

Juniper Internal=

From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <tom@herbertland.com>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Mark = Smith <markz= zzsmith@gmail.com>; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

Hi Tom,

 

I already suggested this on March 30th ... 

 

"PS. But if you choose to go ahead with CRH I would highly advise to = make your CRH SID a variable length. "

 

No feedba= ck/response was received from authors. 

 

Thx,
R.

 

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:<= o:p>

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.com> wro= te:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote: > > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform SR i= n an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network elements on a per flow basis without actually per flo= w or per path signalling or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not require a= ny new mapping plane to be distributed in control plane and to be inserted = into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comm= ents. Note also work for integrating SRv6 with LISP which is already is pub= lished.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new  f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. Can y= ou
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID size > for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable to > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's own= TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequate = to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leverage= d to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf= .....org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------

------------------------------------------------------------------= --
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA31364F26Asjceml521mbxchi_-- From nobody Thu Apr 18 15:05:09 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2067E1203E1; Thu, 18 Apr 2019 15:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 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_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_06=0.001, 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 2AzPl6j8H96r; Thu, 18 Apr 2019 15:04:59 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 4AEA91203CD; Thu, 18 Apr 2019 15:04:59 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id o74so2980489ota.3; Thu, 18 Apr 2019 15:04:59 -0700 (PDT) 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=auDnx5WsaM6HQ5DxX70RMyjBF1c9f177iERrw+bfPbM=; b=jPAtfhNQwJQ7cooUtL2NUfp4tW9F3neYRlDnnd2HZN5SXGX/sAUEVW9oJ3kadggXRd qttbCv0A85EsfiKmDbwiiZrvIk9ZN7rFfKsMlJaKrl5y3LR1bsVWOQavz9xx8bNw2VtS v2s6v6QnQoq02aEWKZhHZFlVmWjcuBCa4T6PJuBkvS3t/4YAudTkLxkEimzR7+xud1Ej 6QfDwN2VRoPDJh8jeu6otN3TZO477CePbWLXKHF2BHJx8sSdtJlMmG3CnxHogWYAq+PM hW0O0V2kfp48/LOnZxszcqueMVvgD2MxAhikrYeEEYhJYgfktk5Oq4C2MtWn3z2+p69j 14mg== 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=auDnx5WsaM6HQ5DxX70RMyjBF1c9f177iERrw+bfPbM=; b=ono81K2jPzGOt9+Jl6L3HyUyRiclyqxPqWjF+s2shW1aLClcpt5FAdSJ8YaSaYMN0j gdU/QF0UlZ5uvpbCd4btYIA7jAMO7fZsNRxw/29/C2vKF7N7CSwr/bQHrwglscqLMv/p 9QngqHlsNwz0aho6VtoKfyCfWOeEiQTRaFc7Q7t3ed5jzg79YBG9iChexzt0YPehJgmU pwaUhvNUFaMNMBYJr3n+EiSoctOeHC3I9HGWMccMzpttvd73lzwcnL0Q4JYba0pskk9m zXXQ2TgV/7VpFYKgN9Oy7mPOBC1iSmVPRKeHrDC+SlvSJ9FXh8xdfpyOSjY5A9sRAFgA Hocw== X-Gm-Message-State: APjAAAX1mTGMSNem0aWLc5JnjmyAkjfkQJhYSn0iWwYIE9Zku8A/9TW0 FgUKJp9rgDyn9MOOV0GCWtA= X-Google-Smtp-Source: APXvYqyq0k7ipPb7MUDQQwroFTz27J9wYmQNynWIhrb6gKbrX5ERWcDGwl9TRjIMYKhfqL+V++tYdQ== X-Received: by 2002:a9d:5b7:: with SMTP id 52mr100558otd.279.1555625098554; Thu, 18 Apr 2019 15:04:58 -0700 (PDT) Received: from dino-macbook.attlocal.net (adsl-108-94-1-135.dsl.pltn13.sbcglobal.net. [108.94.1.135]) by smtp.gmail.com with ESMTPSA id l49sm1206288otc.19.2019.04.18.15.04.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Apr 2019 15:04:57 -0700 (PDT) From: Dino Farinacci Message-Id: <1A4DFA66-D01C-4704-B81E-B1F02FC1A146@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5684746F-2B66-4DD5-B766-141F89F3E8DA" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 18 Apr 2019 15:04:26 -0700 In-Reply-To: Cc: Tom Herbert , Ron Bonica , Gyan Mishra , SPRING WG , "ipv6@ietf.org" , "lisp@ietf.org list" To: Robert Raszuk References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 22:05:01 -0000 --Apple-Mail=_5684746F-2B66-4DD5-B766-141F89F3E8DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Yes this is true - any mapping can be used to express much more then = topological information. See LISP as example :)=20 With respect to the data-plane, the ELP (Explicit Locator Path, defined = in RFC8060 and use-cases in draft-ietf-lisp-te) RLOC-record: The L-bit, when set, means that Reencap Hop is routable by the underlay = (an RLOC). When 0, a mapping system lookup can be performed to get the = RLOC. Hence, doing what Tom commented on. Note this format above is in the *control-plane* and each node along the = segment-route(LOL)/reencapsulation path has the ELP stored apriori. My demo of SR using the LISP mapping system, these ELP formatted records = are used and registered in the mapping system. They are registered with = L-bit set to 1 and the AFI=3D2 (an IPv6 RLOC). But note, if you used this in the control-plane, there would be no = packet overhead because the destination address used to find these ELP = paths. The authors of SR already know this. FYI, Dino --Apple-Mail=_5684746F-2B66-4DD5-B766-141F89F3E8DA Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_700F2C60-ADFC-4BA9-8D06-1210BF6DFFCF" --Apple-Mail=_700F2C60-ADFC-4BA9-8D06-1210BF6DFFCF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Yes = this is true - any mapping can be used to express much more then = topological information. See LISP as example :) 

With = respect to the data-plane, the ELP (Explicit Locator Path, defined in = RFC8060 and use-cases in draft-ietf-lisp-te) RLOC-record:


The L-bit, when set, means that Reencap Hop is routable by = the underlay (an RLOC). When 0, a mapping system lookup can be performed = to get the RLOC. Hence, doing what Tom commented on.

Note this format above = is in the *control-plane* and each node along the = segment-route(LOL)/reencapsulation path has the ELP stored = apriori.

My = demo of SR using the LISP mapping system, these ELP formatted records = are used and registered in the mapping system. They are registered with = L-bit set to 1 and the AFI=3D2 (an IPv6 RLOC).

But note, if you used this in the = control-plane, there would be no packet overhead because the destination = address used to find these ELP paths. The authors of SR already know = this.

FYI,
Dino


= --Apple-Mail=_700F2C60-ADFC-4BA9-8D06-1210BF6DFFCF Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Screen Shot 2019-04-18 at 2.59.07 PM.png" Content-Type: image/png; x-unix-mode=0644; name="Screen Shot 2019-04-18 at 2.59.07 PM.png" Content-Id: <29C5B268-48D6-4A90-831F-8C1D5FD0AE98@attlocal.net> iVBORw0KGgoAAAANSUhEUgAABHYAAAIwCAYAAADj4OzLAAAMKmlDQ1BJQ0MgUHJvZmlsZQAASImV VwdYU8kWnluSkJDQAqFICb0JUqRLDS1SpYONkAQSSowJQcWOigquBRURrMiqiKJrAWSxYS+LYu8P RVSUdXEVGypvkgC6+r33vne+b+7975kz5/zn3Jn5ZgBQj+WIxbmoBgB5onxJXFgQMyU1jUnqBBjQ AjTgAAw4XKk4MDY2EkAZev9T3t0EiPx9zUHu6+f+/yqaPL6UCwASC3EGT8rNg/ggALg7VyzJB4DQ A/Xm0/LFEBMhS6AtgQQhtpDjLCX2lOMMJY5U2CTEsSBOB0CFyuFIsgBQk/NiFnCzoB+1ZRA7iXhC EcQtEPtxBRwexJ8hHpmXNwVidRuIbTK+85P1D58Zwz45nKxhrMxFISrBQqk4lzPj/yzH/5a8XNlQ DHPYqAJJeJw8Z3ndcqZEyDEV4nOijOgYiLUgvi7kKezl+KlAFp44aP+BK2XBmgEGACiVxwmOgNgQ YjNRbnTkoN4vUxjKhhjWHk0Q5rMTlGNRnmRK3KB/dDpfGhI/hDkSRSy5TYksJzFw0OcmAZ895LO5 UJCQrOSJXikQJkVDrAbxfWlOfMSgzYtCASt6yEYii5Nzhv8cA5mS0DilDWaRJx3KC/MWCNnRgzgy X5AQrhyLTeJyFNz0IM7mS1Mih3jy+MEhyrywIr4ocZA/VibOD4obtK8R58YO2mMt/Nwwud4M4jZp QfzQ2N58ONmU+eJAnB+boOSGa2dzxsYqOeB2IBKwQDBgAhlsGWAKyAbCtp7GHvil7AkFHCABWYAP V5xSMzQiWdEjgs94UAj+hIgPpMPjghS9fFAA9V+GtcqnA8hU9BYoRuSApxDngQiQC79lilGi4WhJ 4AnUCH+KzoVcc2GT9/2kY6oP6YghxGBiODGUaIsb4H64Dx4JnwGwueCeuNcQr2/2hKeEdsJjwg1C B+HOZGGR5AfmTBAFOiDH0MHsMr7PDreCXt3wINwX+oe+cQZuABzw0TBSIO4PY7tB7fdcZcMZf6vl oC+yExkl65IDyDY/MlCzU3Mb9iKv1Pe1UPLKGK4Wa7jnxzxY39WPB98RP1piS7AD2FnsBHYea8Ea ARM7hjVhl7Ajcjw8N54o5sZQtDgFnxzoR/hTPM5gTHnVpE51Tt1Onwf7QD5/er58sbCmiGdIhFmC fGYg3K35TLaI6ziS6eLk7AWAfO9Xbi1vGIo9HWFc+KYreguAL29gYKDlmy4SrsmDiwCgPP2msz4K l7MuAOdKuTJJgVKHyx8EQAHqcKXoA2O4d9nAjFyAO/ABASAEjAUxIAGkgkmwzgI4TyVgGpgF5oNi UApWgrWgEmwG28BOsAfsB42gBZwAZ8BFcAXcAPfgXOkCL0EveAf6EQQhITSEjugjJoglYo+4IJ6I HxKCRCJxSCqSjmQhIkSGzEIWIKVIGVKJbEVqkd+Qw8gJ5DzSjtxBHiHdyN/IJxRDqag2aoRaoaNQ TzQQjUAT0IloFjoVLUQXosvRCrQa3Y02oCfQi+gNtAN9ifZhAFPFGJgp5oB5YiwsBkvDMjEJNgcr wcqxaqwea4Z/+hrWgfVgH3EiTseZuAOcr+F4Is7Fp+Jz8GV4Jb4Tb8BP4dfwR3gv/pVAIxgS7Ane BDYhhZBFmEYoJpQTthMOEU7DtdNFeEckEhlEa6IHXHupxGziTOIy4kbiXuJxYjuxk9hHIpH0SfYk X1IMiUPKJxWT1pN2k46RrpK6SB9UVFVMVFxUQlXSVEQqRSrlKrtUjqpcVXmm0k/WIFuSvckxZB55 BnkFuYbcTL5M7iL3UzQp1hRfSgIlmzKfUkGpp5ym3Ke8UVVVNVP1Uh2nKlSdp1qhuk/1nOoj1Y9U LaodlUWdQJVRl1N3UI9T71Df0Gg0K1oALY2WT1tOq6WdpD2kfVCjqzmqsdV4anPVqtQa1K6qvVIn q1uqB6pPUi9UL1c/oH5ZvUeDrGGlwdLgaMzRqNI4rHFLo0+TrumsGaOZp7lMc5fmec3nWiQtK60Q LZ7WQq1tWie1OukY3ZzOonPpC+g19NP0Lm2itrU2Wztbu1R7j3abdq+Ols5onSSd6TpVOkd0OhgY w4rBZuQyVjD2M24yPuka6Qbq8nWX6tbrXtV9rzdCL0CPr1eit1fvht4nfaZ+iH6O/ir9Rv0HBriB ncE4g2kGmwxOG/SM0B7hM4I7omTE/hF3DVFDO8M4w5mG2wwvGfYZGRuFGYmN1hudNOoxZhgHGGcb rzE+atxtQjfxMxGarDE5ZvKCqcMMZOYyK5inmL2mhqbhpjLTraZtpv1m1maJZkVme80emFPMPc0z zdeYt5r3WphYRFnMsqizuGtJtvS0FFiuszxr+d7K2irZarFVo9Vzaz1rtnWhdZ31fRuajb/NVJtq m+u2RFtP2xzbjbZX7FA7NzuBXZXdZXvU3t1eaL/Rvn0kYaTXSNHI6pG3HKgOgQ4FDnUOjxwZjpGO RY6Njq9GWYxKG7Vq1NlRX53cnHKdapzuOWs5j3Uucm52/tvFzoXrUuVy3ZXmGuo617XJ9fVo+9H8 0ZtG33aju0W5LXZrdfvi7uEuca937/aw8Ej32OBxy1PbM9Zzmec5L4JXkNdcrxavj97u3vne+73/ 8nHwyfHZ5fN8jPUY/piaMZ2+Zr4c362+HX5Mv3S/LX4d/qb+HP9q/8cB5gG8gO0BzwJtA7MDdwe+ CnIKkgQdCnrP8mbNZh0PxoLDgkuC20K0QhJDKkMehpqFZoXWhfaGuYXNDDseTgiPCF8VfottxOay a9m9Yz3Gzh57KoIaER9RGfE40i5SEtkchUaNjVoddT/aMloU3RgDYtgxq2MexFrHTo39fRxxXOy4 qnFP45zjZsWdjafHT47fFf8uIShhRcK9RJtEWWJrknrShKTapPfJwcllyR0po1Jmp1xMNUgVpjal kdKS0ran9Y0PGb92fNcEtwnFE25OtJ44feL5SQaTcicdmaw+mTP5QDohPTl9V/pnTgynmtOXwc7Y kNHLZXHXcV/yAnhreN18X34Z/1mmb2ZZ5vMs36zVWd0Cf0G5oEfIElYKX2eHZ2/Ofp8Tk7MjZyA3 OXdvnkpeet5hkZYoR3RqivGU6VPaxfbiYnHHVO+pa6f2SiIk26WIdKK0KV8bHrIvyWxki2SPCvwK qgo+TEuadmC65nTR9Esz7GYsnfGsMLTw15n4TO7M1lmms+bPejQ7cPbWOcicjDmtc83nLpzbNS9s 3s75lPk58/8ocioqK3q7IHlB80KjhfMWdi4KW1RXrFYsKb612Gfx5iX4EuGStqWuS9cv/VrCK7lQ 6lRaXvp5GXfZhV+cf6n4ZWB55vK2Fe4rNq0krhStvLnKf9XOMs2ywrLO1VGrG9Yw15Ssebt28trz 5aPLN6+jrJOt66iIrGhab7F+5frPlYLKG1VBVXs3GG5YuuH9Rt7Gq5sCNtVvNtpcuvnTFuGW21vD tjZUW1WXbyNuK9j2tCap5uyvnr/WbjfYXrr9yw7Rjo6dcTtP1XrU1u4y3LWiDq2T1XXvnrD7yp7g PU31DvVb9zL2lu4D+2T7XvyW/tvN/RH7Ww94Hqg/aHlwwyH6oZIGpGFGQ2+joLGjKbWp/fDYw63N Ps2Hfnf8fUeLaUvVEZ0jK45Sji48OnCs8FjfcfHxnhNZJzpbJ7feO5ly8vqpcafaTkecPncm9MzJ s4Fnj53zPddy3vv84QueFxovul9suOR26dAfbn8canNva7jscbnpiteV5vYx7Uev+l89cS342pnr 7OsXb0TfaL+ZePP2rQm3Om7zbj+/k3vn9d2Cu/335t0n3C95oPGg/KHhw+p/2f5rb4d7x5FHwY8u PY5/fK+T2/nyifTJ566FT2lPy5+ZPKt97vK8pTu0+8qL8S+6Xopf9vcU/6n554ZXNq8O/hXw16Xe lN6u15LXA38ve6P/Zsfb0W9b+2L7Hr7Le9f/vuSD/oedHz0/nv2U/OlZ/7TPpM8VX2y/NH+N+Hp/ IG9gQMyRcBRHAQw2NDMTgL93AEBLBYB+BZ4fxivvZgpBlPdJBQL/CSvvbwpxB6AevuTHcNZxAPbB ZjUP+g4AQH4ETwgAqKvrcBsUaaari9IXFd5YCB8GBt4YAUBqBuCLZGCgf+PAwJcaSPYOAMenKu+E cpHfQbcEyNENPd488IP8Gyn4cVpVUYNWAAAACXBIWXMAABYlAAAWJQFJUiTwAAABnmlUWHRYTUw6 Y29tLmFkb2JlLnhtcAAAAAAAPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4 bXB0az0iWE1QIENvcmUgNS40LjAiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cu dzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9u IHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpleGlmPSJodHRwOi8vbnMuYWRvYmUuY29t L2V4aWYvMS4wLyI+CiAgICAgICAgIDxleGlmOlBpeGVsWERpbWVuc2lvbj4xMTQyPC9leGlmOlBp eGVsWERpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxZRGltZW5zaW9uPjU2MDwvZXhpZjpQ aXhlbFlEaW1lbnNpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+Cjwv eDp4bXBtZXRhPgqbDxM9AAAAHGlET1QAAAACAAAAAAAAARgAAAAoAAABGAAAARgAAJcj2m8+CQAA QABJREFUeAHsvW+IHMmZ//kIZqEFY2jBGNRmFizjgenh52VTrA88y77wGP+ga9jjXEObs4T3OErt ezHehd4a/16ovftCW144bc8uaNt3IPfcgky1jzXVPrS0DNqrnhdLtw/tUg2aH1UDGroXNFQLNFAN ElSBBHFPZFVkPJmVWX8zs6u6voValZmVGX8+EfFExJNPPHFO8YfwAQEQAAEQAAEQAAEQAAEQAAEQ AAEQAAEQmDoC56DYmboyQ4JBAARAAARAAARAAARAAARAAARAAARAwCUAxQ4qAgiAAAiAAAiAAAiA AAiAAAiAAAiAAAhMKQEodqa04JBsEAABEAABEAABEAABEAABEAABEAABEIBiB3UABEAABEAABEAA BEAABEAABEAABEAABKaUABQ7U1pwSDYIgAAIgAAIgAAIgAAIgAAIgAAIgAAIQLGDOgACIAACIAAC IAACIAACIAACIAACIAACU0oAip0pLTgkGwRAAARAAARAAARAAARAAARAAARAAASg2EEdAAEQAAEQ AAEQAAEQAAEQAAEQAAEQAIEpJQDFzpQWHJINAiAAAiAAAiAAAiAAAiAAAiAAAiAAAlDsoA6AAAiA AAiAAAiAAAiAAAiAAAiAAAiAwJQSgGJnSgsOyQYBEAABEAABEAABEAABEAABEAABEAABKHZQB0AA BEAABEAABEAABEAABEAABEAABEBgSglAsTOlBYdkgwAIgAAIgAAIgAAIgAAIgAAIgAAIgAAUO6gD IAACIAACIAACIAACIAACIAACIAACIDClBKDYmdKCQ7JBAARAAARAAARAAARAAARAAARAAARAAIod 1AEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQmFICUOxMacEh2SAAAiAAAiAAAiAAAiAAAiAAAiAAAiAA xQ7qAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAhMKQEodqa04JBsEAABEAABEAABEAABEAABEAABEAAB EIBiB3UABEAABEAABEAABEAABEAABEAABEAABKaUABQ7U1pwSDYIgAAIgAAIgAAIgAAIgAAIgAAI gAAIQLGDOgACIAACIAACIAACIAACIAACIAACIAACU0oAip0pLTgkGwRAAARAAARAAARAAARAAARA AARAAASg2EEdAAEQAAEQAAEQAAEQAAEQAAEQAAEQAIEpJQDFzpQW3EDJfn5Mu787IHplgS7/iUPz rwz0VHw3nXb88eUEIYEACIAACMwQgdbnB7R/cEz0+iK941yaoZwjqyAAAiAAAiAAAtNIAIqdSSq1 5zXa+tU+NYNpmrtE7/3gnaEVM7VfvEtv/eieG9pGpUnvO3PBkBM9P+34E80cAgeBSSEQkBvnv/o2 Xfnu4qSkDukAgSkk0KKPLp+na/xehChDleYOpdx9Ds2s9ekuFf/1iCjQzU+7PGh9tk/Fj2uCx3l6 e/kKLc6LSz0Ox32+R9D4CQRAAARAAAQmigAUOxNUHFIR4k/WaAPL3b+5TN/5a3dkStk7VSr9MN3J 3qjxt54c0dHzObr09YXgGNWPBWeJEAD/RLAOHOiw/Fuf/JzO/8GPbfjOJjUruclpOy+PaZ8nZgvf eocuvWqTeWaPXEvFI1r8k7dpITDJTi3Pz0+o9uiIGi+JznOkcxcu0qWvsjxlq82TJyc099q8e5xa eqYuohZtff88Xf11O+HFh0268o3TKsxB4ElFVOD+SZMHgeT1O639I7+g+ov2Cypz7zAvqsZ93sSJ bxBIg8DxZzVqzS3QpdcH1FymkSjEAQIgMD0E1Bn4HG7nFRMf8q+gDl9MWOYfl1V+OatyKzn3L7vk dPKUVdXm8Gndu2GeJ8UDoeEDGPOJkeJ/UVWZTlluPEwnzZVb2b51J3u7MiaNKXn8FPifOpnHpb7l T+SozHJebd6tqEaScmMU/sd7am0lqzJORwYuFVU6LWeAkuP8rHXac7EWnqrSqpVTg8px5/pOJ/KG 2ljqL/s3HzQiE1u/u9a//B1HZVcLaufBYWQ45ofmw41OeGvp9zEv6qp0I9c/P8slk1x8hxJoqk3T nrjtV56F3jRRF+u7myonxg+pygOudwWPV7A95lQluvn1ZVjfL3K+eEy0nPHq9eYQY4Nxn++bwBm/ oX6/4JXLoPKbreBU+emMgwvJfrO22WGZUacwZA9JES6BAAhMGwGatgSHpbd623b4g3cs2ckXnI+K HSE/mmJHPa2q8v0y/yU8GQ0rFH1tlPh5IpjrTASHGbxFJaH/9aYqDjAxpEmaLPfP1Oh3pM5/9KTG 9WTzoRlMBSckUecZtfMoXEkxdprG4H+41ZnQT1BdLa0ahhm1Fzq5kxNoc+8A3yaPzCs7gFI/c7sa WTRD9x8OvxToVfyNPU85TSul9JRsx+VuFqyQcsL4GH6RVPBDo1bhvnNHlfer6ZVhjNhTlQfNiq3z or45HWVP5lYML0bGkI0u1nGfj7FszlJQQ8vPVMd300W6WRtzzD9d2UVqQQAEEiBwJhQ76lldVR7w IGxLvHm9UVKVSsW9rn8zf/aeEZUlCRRCVJAzKeRPY/DVaNcfXV+K142SMKOKu+16s7dfUfXQSWlU yU3x9dPgf9q4XjRV1ZUVZbXmKfmybJ1h5EZZFW8XAhPk/EhWdH2zOgb/6p3JUuw09te9N7nOzb3I rDePq66stm2P1NrdPU9mG9nta59CMdF4zM+7ZSXKz1lTZa/8qr2trDr9R2W3aCenS+u2/9gvq82g FUwfhY20VlzfT0F4NPwTa2d1U1WfWu1T4xGzkRYVyxNk1RVZM/DDOATSlgeNR1W1p9vc/YCi3K13 +fGt15pjvvQZ9/lxCuMsP9tstPtPKT8jxt9Sxqbz4m66wMsxPyx2pqvskFoQmBQCZ8vHzmdbdO6N q2y0Q1R8pOjK191D/3/ePVmqNku06C6bb1HtX7dp/z/ZH4FYRj//5rcp880FopcntP8v96j2vO2v wA2w1aS5P8xQln/Xu2ds/7bCjgzYmwFfv/gnV+mdN+fo+NMDOjio0fHzJrVaRAtvXqZ39O5UIg5/ 4vxnrU+36Pyizo9Mq/+e4NnR77Zp97+3fPngFA3lfPn4k13a/r+36B7nifcEoYWLC7TgvEPZ/ylD l6hG2/9Pheb/6Cq9/71unz1jx/+yRtd+7y36iOPljp9yKfs1OPrVNfraFR07M3/B9WOEncROPt2n 0q+36d7veK10p4DmeGeVzFKW3lt6u2/5j8OfWlxX//Ueffz/7VKFd3Q5eqJLkD8XL1Nu5X3Kfc/p 7XslBv4j5b/jANhtQzq93I7muX2121+LDn67TaV/KdHBfxxxneRd3phl/ie5gR1o6iAH+Wx9/1zb r8ZykdQ/X/E/wr5iPrryFbrW8bsR6ufhFPnXfnmN3vozrrsrJWr+H9+i3X/6v+ij3+y368DFS3T1 hz+l93/Qp/z9OR7j7IQ+vHyBPnBdfDlUPq7QOxd7B2fbXo7b3mZo2/PuWSpS896Vrrrcs/x6R89y 3sqeUJ9kX+zTe1/+Y9p2w+nj9+zJPTq38G47RmedGpU8JekxYfcvz9F3/qEdXebmHu385O3u3H6x S5e//B1yi2SJ/TDd6/bD1PqiRru/3aX9f9ulg89bdNyRHwt/lHHlh+7vuj6tY7r364/pRP+g+8X/ wn3FNy9w/fs5/VzUv/d+8D7lf/hOV5n5w+O++Hf3aPvX92j/047s4hsW3nybMstZynxrsfv52OJv 0f5vtv39vN7KYJ6dkf9pd1/nT7c54/R/vE3FX5XoHssq/Vngtud8+z1673vfJvqE5dh/nNDl//l9 yn6ju0aMxN9EHfj25EFEWwncHttp6+AjOn/5GoeXobXrC/Szv9X9KRErOCn/re48uz+K/0543LT7 7zz24Ao1x2OlC1+9TN/6lsP+qo54bPC1vmODUZ53HU//2xNv3NTkjvvyn14hR8ss7TPrN1u09S/c p37GdZLLM/O99+mD/zV8Qws9Btr6pyKXc7v8dYNbWH6Hrq5cpex3e8vf1hMeX/HYofTbjtzmvu7S H/GubOyv68JJhYr/dI8yH+7Q+98OaYec1HGfF8Uw/KGQn8Uaj7/fDAlC3BM+vhuh/et8a8fhI5Qf fbZLJfEcvcrj9t9+RMX/cEe+dPWv1im/NE9bf/dXtP6bCo/nDyizskHrf/8+LYb4ixu7/fKY/5wZ 8484/vSos5+1Ez0AnZun+ZC0evfhAARA4GwRmBQNUxzpsNpuUvJtgF5jvXZ9Q1X1Onlh6uhpxNmM ONRcndiqR/vT8HwmBJcIbLgm2tVbAR8RS2uqsBK4JsyT1+9GLwuQHGx+BrUuil7WMJC/Gl4nXxzU 34WzGWKePmL8/LZ5jdfPZ5b0n+TGfk3ca+Y3/nYyqrA9GD/JctBj7y2nLnv7wnuwx5uHarNHubPk YAsGR23sRvjpGJf/03JEPRb11llX9aCPmLj4j5H/UHNutipoPK14S/Pa/EReVo2flcGKp/9dvCxv uRO+sAiRz8llWzz5lz/x0sPT5W/rrmAk5I7Lb2lTpWA/opoPjUk5p2VA6xCbfrlMtqn27hTU2s2d tqy93fGHxfnobp79y89fYIEzYS2VjVi6VTXxM1d2qBsIQJ6KtPC9sj+Sd8Vy7Kt3BVXvEaip39lb 3RZUjV1rYdXV1jr1yLlR7grd+hTqUe9MPQyTP50Qm2xVZJbhRsVPlFPlwDLIuOJXkeOAAf1dsK+r vLSKMnkO+Q5bmjQq/64C6Vzw2lOELIt6btzrpZVOPdDtXrSpvnLgWVWtG/kbwqxwy1pNhrankZ8P H7do+V6vCDkWSFP+bqClcV/ls4oL3N+u01x/H4fLDa+8Qp+zbStqWem4z49b7kqUtSyfxsOSWltl C0jtU4fvMUtng34fR23/insC6w/Lcupffkehz0XLHhs2EcvZwDhq1Pbb4DqWNeNcXjrrxc9j3e7x b1aVevY77VIs3/L7WcvNio/IsSsxAgCB6SdwNpZidcrBKkJ40F2zhWN8qLjKjReHqsDKA2dlwwpm PaG+nrPORzsda8ZM3NwJtxTqxI5Us8ooaBoPiirPzkvDlUOkHCmsO2FnB1hzbvMzuJKhcntNZTvO l3PLtpOQHa0lI4/qaj04KF3KqcKtDVVYDXEuHDFYHCX+ZsU4G/Uz9jq4roFOW6EmUx/XsR0cDc7c jZvrVT6QzvzNIvtn2FPlu1w/vCU+7Tzmt4PKnfH5Byc4OVZmltjH0s6ddV/dDCokYuE/bv7Zcfha p95GtSNayvIASNQRnjjE+xGT8Yj6LRU7wQH2qfJnELbuGkYOK0Q21UZgGdHa/cCEJF6Ibmhl4bi9 awIUEZ9Nf66tUNf3eRMBnlzrgfSjHZVlOZW71a1g0AN8o7gYySeWmJhEKnZumaWa/ZU19ftiafBq WHojQAx52XLTS9h6l22zM1HNeM6nbWRVkTetgF67xfJrl5ch3vRPErqcYPOEtrDa3X/qMPK67+AJ ipTlua2AQlQn4VHQgXlGrd/ZUXssP7X8Mg71TTglqdyJI36dhs44wPSfup614xugL/Ap19rPZVbW 1Pqtdd4QwfbDJv1h9Wtk/jrtIR+vXkTIspBHxr8k/EuZurh305S/o8rHEVE8FX6pAv2oYSa/u8Yz Yz7vOp52+5+QsU4nPXrMJ+thdkv04YGlkNo5sK6/evlo+e6mp8xo5yHEcbCv/mRdJ/2Hj+u8xGlP bV73pyms7vhfKozwfESxDHVZyE85/q7eaae//XKxwS8PM8pZyvsdao/T/jmRo5bfIS8blE653fJZ 5nYbYK6vZ29wWxbjj6AcHLX9dr0Y7lP/nX5zB/a1JtuKOd6JantDFTJuBgEQmHQCZ1axo3ewWbu+ xn95rzPuGgwES4cHdnKHlSy/nWy/W2mq8g0zONGDZ9GhizC8SUVHMBe2KvzGqnMDr0MOatGDHYMI yj0cRbHjC8Nzvtx/EuINAt20s3+ZSmCCoN+GiU5toInToPG/aKi9uztq5y4rIbY3PCVETk8s2Hnl jvtb53ubB0sRb7x8eR/xxHIYYDAv4rCDVx7Us3+PsF1AqttioseTHrkrhI1XTwpG5M8cy1tFVuaE OMt+VrGDy6C1Qwz8x82/QGkn594AJ6d2atbOpP6QJ5tbJVW1l+TjYxwLxUCElUlFWGysB3daOkX+ OtO+OrS8aRXX/NsoFjQjgxQDfD25l/W8V5gy/dlVLbv5z1MqSyueqFBE+Y0ymRXpDp08sa3TpmdR EOUMWqQtMFkb2gJQBNXrUHLr28f1Coid3Rdvs8wN2fmrWbF+U4IKTROk56xXt1v2USQdTDdZIecp bIPyh7nKlwrO9VK3TyRuW6XrQkGiLX9MxJ3v0eMPBNQVXr++QNQ7nXd2rl059ltlNGs73jjEnSSG WYSNyT+YC69ejNIWgoENeG53KOX2anYSE7sOhlkq+RSynboj+TWPWXEoxx58j7+eB/hr/1iCf//n ReaEDDATYlpma29vByf2x7a7o4rbZVFHm8qzUuK0ZW7siN9M2DyGvCkUNCt+H1dSPrMbga5P40Hv 9jfu810RjnJBsLPj7zWV65Sdv8xkBPG0fzdEkYaBy08+I8plT4z588ZKnK36jMVR18u5Uduv3mSk M/4t3TI7/LJl9xY7bpdjXz4ucb07NO1KIpTHj3dCFTtBCyn5CI5BAATODoEzq9jxhLoeKHT+ojsW WaB1MXhna5vVDbXhOdQl5Ql4+Yh77B9cRDnMrMqt2ftYHIyr2LHPBwdCgcTLjo1ZlUIGFu0sWueF 1DU4D4TJpwPHLx8VaZFvfeQtSR57g+FhlmJxmk1nr5Uy4bv/tFMtt1b3Jkgiz7qujs2fnQHXH/Kb Qn7brv+08+fD40OrMIlQWrgpFGkZmP+4+fcVqL8duRNEoxz13ZfEiYib67e7rbmOm3k2HrNj7Rti YM5LQiIn6mnz76CwdZe3F/bPK907vMlH0hM9ViJ6b7aXNgZe+mXTb2W2kd3s8yqat1cVZPn5J07e Lb0ORN13LSrdsucHmro9lVXBU+pw+nq1IS8OOWERE13v93gO7M5jMcWhnaE+YEtDV35oJ9a8JIXr v5Fx4UovqVhki4QQpatnxRVk5y2P1kqRXvXFv7V9sD+39WfI+COKwYbXp+6JFxhE7FQ9Ql7J/tCT /WFxj8g/GJSX/qTbuxcxl4+xcrouLdREu2Q+h0E+kl+Iwq4dvN+i1Vf24z7vpZ8PhINlLXsy3ss9 eVPguCGW4HL6Q6p+54G6WuuMRbU8kzJaKmYKeql+kJFOGi9pyvGSnY39oEpT/2aXjI3yfCBHo50K +WnltpXlvjKTMcTU/t0gRyk/8Yy0Zq7fNS/ixJiO7+0nB9U47dery8JqVbIa5Fj2v159c3qOSwcJ FveAAAhMB4Ezq9hZ29pT1YdV/tvz3vZEdixdZcXmomaduCcYWakTZkLuPSsGLz2VHmKw33MQy521 1+H1GVh6afAf2Of7KHaENYfjG5D5w9Nn7npgXlqWD/HRELx74Pjlg2JwMHh5yQDGO/YGw70mkk1t Ii12yvI6Yx4I9jOTFW98vMlhXPyfsfImsOwmbIDV09pqFP7j5t9XZKId0Vr3JMB3b9wnMm47IA1j GGq1d1r8Oxi8uhucOAd/T3iiJ5ereXV8gKLy0q8t1niLaVd+8zLXtpJoEBkoyq9HHptPD3mJRMhO WaLuh5W5veaonccDZEguDeN+JCl5ZhU7nK4xzO2bj/bUel8fYbwkIczahHF45RfBPur3wy3zlppU v7fKsm4Fl3RFhW9Kqt/v5j7z7d3fqy/gm6U1U79ljhXeudPhpWkbuyGT8zH5m3Sbby/9EeVh7ovt W/QD2TtsNdpoqPrTuvu9d9NaWwVfeklLq+BvMm2NB9YHlGxL4z4v45B+YmhAH26yTmoZsXaTfYLd KKiC/LteUOuBvrkolxOGWFk4vPQ4p5eHrbL1OS8DKvJOgfUoa41xn/dBGPFEyE9v/F2rqlLH8kWW mYwhrvbvhinSMGj5yTL3ybbQ8bdVXvru5cjHlZ86/XbMPEh/5+Y49L/2OL0zhnGy3J92y5vQB3ER BEBg6gmcWcWOtDYodd60eoNGfqMe9kbEX5qHAUeOuR5vYvSTdlIhtf7+MP33Bd/aBO8dV8jb53tP KuTApHfagynsfT5o/L5QRMccNRDw3R/ziTcY7jGY9xz9dgbMMp/OjUrvFLESx1uS0Bk4xsI/xMeN 9m2hB4Vda8h7DfRH4D9u/v3AbDsaRingD2PUMxG3UOjKCb32m2TN8kU8p8jfpMKruxHl2+93E864 37I+DFOGXvp02zNvrJlr+w2pcGDLFjThH1F+EQy0nDaONj0faiYwUfdtmQsFHw+Q17fkEgzzYNS3 SE+Cip3qlvWBM7LMjJgY5tl3Ttbn0H4Axc6QikVb7qQKweWNAbRNMbkPTqy8cIaMPxCFd+qF16Mv 0Df7HGrXouqmF2z4QQz8gwF76Y9sC8EnxjuveL50RJsJk6OB8vHSyff2XLYpljbKej7u875cCxkw 6FjIJ+/C8htxLbgU379UO5phlNX4uM/7OIxyItjJ8bcZL3nj70DYsvzGaf9usCINg5ZflGLHlqtU sliZ7pM/MbXf8DgDwHAKAiAAAj0InFnFjuz4VaPuvqF1/d14zv16mzr61kObjnm1l3m/FfjOje4d R2wZ2PsmRbGj2NmaUTb4Oiub6JGObCfVW7HkC1x0zMGBj+++hE7sIEN25v7IvHs6A2ZpBt13MCHy 51nOxMC/fte+9XZ9AggfAyb13jKwXgN9kb5B+Y+df5NA91u0j17p9D0T14mIW1sLPWuyVXXDfePc 4ONen9Pkb9IVrJfmuvnu97u5b9xv2e77WrCJyLz0BSbSjcdVVam13zg2HnQcrQtfCDYIUX6Rdcfe 0yXrRN3Xb3ubegmeLv+nDb0aa6RPRTgk9vVJI4UW/pDlNoDFYHgQamfVTiSzvANZl2UA+7jZ7PjK 6OLWCdNLRwT7qN+HUox4b9E5rwHLoajwTZb7/W7uM9/e/YH6aH433/XdwpDLvc2T9jsO/ja09pGX /ojyCN4/1rlsO2a8FPntd6JsnOtqZWrkMmSdOGERJNvSuM/78i3yEVXPfffziZR3tLzOPgFL7Asl +q/IfvB2dqsd/42B0BqHauc2O+llS51s6E6h7XYa6YR63OcDyRnqVLCT5aOetcff7tLmkADjav9u 0CINg5ZfHIqduNqvrUu95ychGMMvmRck4b/iKgiAwBkkMBuKHVFw1jrCv8ZZ3KKkI9gsv6HflE4b eUIRvobaThh6KmzEW6d+fmqskI9WMsh0B4/t830UK9wZmnXDxBPa4DaOwXDrbF5bf9p/pjNw/DIC 0TEPupuOfHzcY28w3GMw791jBsxyTXMfnyLexJQHsZmbHeueGPiXvToavXzJ83Fh0h0GaxT+4+bf lw7Rjnql0/dMXCci7sBb5X4xnCr/TuK66mUg0f1+D9w+8qls9/1knIzES1+vtmecV4fWDVF+ob/r 2Ow9XQN/Uff7KmhlwiOPOS7h9NU32Yl8ZoQffLugCH8QUUGxwspz6q/v4U0DCmYSHrn8xN7Txa0T j1d+EeyjfvfJxD5LWT3lNKc36Lw8KnyDod/v5j7z7d3foz7qe331PZJfJ1RWkOklhg3ZfcbE36Tb fHvpjygPc18c3419u0zKeyGgJ5Xmjw/lCwCp8LUOl9kazOxEGpIoWfayLY37vC8qKQMCikPffeJE lr/Ml7il/yHvCqmXnOaj8q8d8wvnyzL/buDjPt8/hf3vEOy60tfj6bjavxuFSEOUnOpKSsQztlzl +Duk/4ix/do4Wck50HLfrty4Fw53N62fO17avBmy9DP8SVwFARCYdgJnSrEj3+hIU1BfIXlvfaSw tnfs3bIOUrXjvPaHdz0QDpT18oJu5Y4V+K4Zf2BXGjcc3lmqYJwLcife27KHn/DSOqL23nvev/17 J1PiK7irg9kNTNyiDxucfjNRcTbD3zjJRwaOXzwknNOF8uFJyeED3hXpTtG384UIYaxDu14/mrl3 jzdgFn6TuFxztyOWY/GWqDn+3SzzsP4ExuUv6154uqt37VtlXX8jPyPxHzf//tR4u8v1Sqf/kdjO Rov7tPm3s+/Vywhu/X6PDaJo98MsxfLSpyfSEW8avXu8tudP9SDlZ+7pGvjLAX7UBMsfXZ8zWS9Y Bj+Us/k+jw75s3xjrHflq0b44qjeNRNwISdEvkNlA08qd8QOMVGTb69shq1/nhVtWzZuhm0pyDy0 3wgjO8Oc1I8cfwRrLzztKD2iPrqPMr+8kOuF++G7ZjbY+a1xKu7cElu+x8Q/mA0v/RHlEbx/nHPr mL3XuICXQZrxg3SifOzfxacYUv5yVyhdB3yKg3GflxkXZZEbVAYEyt9TbMlwO8eNR+yE/5b2wcNj SFGnpNKr9ChCTghrNV/+Oexxnw9J6vCXBLvI8XdYqDG1fzdokYZhys+My6TfLqtkke3fynTvXhHn OPJTp9++eOZlqfvdswzX+mm3xONftqqMqCaKeRoLfCsv4Tw5rOrhGgicRQJnQ7GjvdCzM9syOyY0 gmyNfSFU+Frlgfjz3SMVO7zrSa2idm5ZXwU6HN/44umeF7YbB2+BWXkkBa8V+CYNevC5zgJ4b58V Ebds2tq/d1sM6U7fS68vrSzk71bcPHq/Pww6Q2OFh8xv4HmHzes1I+953ulEDiz0ciybbh5gL62p cuWw7QDxETvAux1If9fEasz4vdbFSgIxSF7f7jhh5PIp3S74OizHWLx4z454oJfq6XrCfIpCgbcW ZK7veSjuEQzsIKA9OXFWN3lbdr2Eg9+OP2uoyn27jXu7/gSW9Y3JX5qj03LBLbs674RVuV9UeW8w 3VEq8cSvzHmt+uqvYTca/3Hz3+DybZcB7z7kpTejdkSdrfOymMPQNJu0j/jNysKqW/4i7g4j0166 lqYEojpV/lrZKeulm3a2qjOT++DvvAX5DjsPrkvxFcjPWKdyoDuABWDbmbFoV9p58q6UVZ1jmUfR 9tylWsHyYxmi82jKz/uu2DL2FDt6qYB+ft84amZruuusOOb42s/xsgkxCRucjbVy6WnFOXiA0XcG Jkd6m/mNbXa2ysvI6o8P1d7dosqJlwq6b7K78vj7rqzO+6O6qrPcL29teMoI0z84LpuqOvSsNtv9 54a3a1igfoXVP73TlqmfnCvPuqQj+/O3ylw/WXZq+cnyuextA9yWYX7l0vjx651svDoSlPOcpvX7 XBeELKoE+t/6faE45/vd+sMM9VK+Q97AYVP0K5qjfxnZuPx1tQj0v7KtdNq7zF+47I+uXpG/6L5z tyj6Zd5qnOOuct8nP91tXFun8NbNnSXDPsUk88my4qPy8LAt13y7EbbLf4Odq8u+YLznBTshA4h3 uJIyoMF5NemVedPH0mpIl+8a5821aua632AH0t39sCPaH5eeUNro5/W4p26W/7LsadTKvpdCQSfp 4z4fzM9Q56btCHa+8XegrYSFPW7798a+Ig0DlZ8em3H9NQpXooIr+9w0ijLRY8G2lZ1sq4VOPZfX uO4OLT8FEWnRzy84ShUtQ3izDn6ZuXndPz9ZtwJcBMCHIf5+dJ2K8nHkfxhnIAAC007gTCh2jHM2 LbwG/7OKFakl9z1vrFJ4omKXKsk4ZOfsF+6+cLrSlVXlRwF1O++WZDsXGUfUsYzbr+nvHbcNLyjo G7wDzWDP5v1KL24FkQy78h4dv2lMwUFyVJo2+zjaNOH1/uZy8xQJNm1RcfquB3Y/q983b8P7hLO0 rg4Dxa/TOA5/xYrH7rc0fdLBA/6wscGo/EfO/1B1X05Ie5fsoL8OVHeFIiE03FPkH5V+51bbcqzf 76H5GediwJF0b5Ny68zY17Z6yA33PlMeLJuHk5u2TZjJ9SD9h1+RMCCcRyUhT0O2eR4wmIFv4+UY 4f2UzbNhvBnYJUUupTH39P3u9I/96lfU756PMTeDTd9Sk15xB7egjgq/X/2X8Q9SB/xp6padldv+ iZf/flsGDvvq871U4fyPw1/ji2IQlQYyYxuX/aj/cd/pUxbaPHYpDiPv22hb/rLMkNbMken2yQVR BmM8PxS7SG5cf4VVW7/0O9dLfqtvaeXoy6Nk2jkOW+437vOjVgF+rn/bEeUUGU/87T+0DALlZzZW Cd67UeOEBpgaKztj8dl+pp23cduvxGKXdYeUvVc3cl1jcC8MVg4F86PPg8pA734cgAAInCkCZ0Kx c7gdsCbxhF8PwegUrC8Z1nCHTYrlUqziqt2u0xOaPEG3/misYkebaDZ52VLxRl5l5ICGdykq8Juc 4KDOrVF6na68t28e8n7z8M4aay9tfZ932FFhmHahqjZXM6EdAzk5tclvLkOe4rcE7TXiY8ffaV7V u91vinXYznJebeo30aGJGK1tVozfjr7M/PUpeyvESfbTitqI4sdvyTf4zU/PpHO9GYk/Z735qKzy YXVoKaeKD9jCizt83yRYtoEAupH5j5L/Yeo+v0W1bS6Q6FFPI9q/rMvZqOV1Is5T488KhDD5ld/u LAnp97vIQ1yHsk15JusRge+EydY+bdG5bpbJslNfz1LE3z5l+YUdb3RM3et3+/cfoyiR5Vtoo0SK QBDfZW5LpZvRCob8zZLPUkZGrP0yhNWjzApbLrBlRX3Xr7jOmDKIaD9e/Yv4PWzJaqOyE7AwFP3u Up6tsIKWqpyDiPCHiX9QZbatR7zcLcSKS1tWrEW8KMisaEvKkPR3CmFk/vp5tvj0yfY+7YdWS737 oU6a+n3JpeuWDbdD9jUn5fROwGLJ3OvIdOglfwGraXOftuA65KVsvvrJ/dehLINRnx+CnR0ThpOp PygFLOOkTMqotVtsifS4ewQgLW6cpYjxF7+I0ZY83U9z3y+sS0Z5Pjw3g10NygVTZvY7MFbtEexI 7X+M8pMy2qY3o1zn1I+lYp6tsO62265f8WJ9Go7Vfn1MuB3cFJthiLacXS2oElurhdUBGURVrF7Q +crdDhmrygdwDAIgcGYInNM54YaPz9gEWrT1/fN09ddsdH+7SqWVRRviy87hK/bSxB89P6HjzxtE Fy8QPW/S+fkLNP/qXOrJbp2cUKvDb25+nuamhWFL8zsmeu0SnX9+TI1XLtCli/OD8xuD/8mTYzo+ aTGrObrwGpfb/OjlNjL/cfM/OKmJu3Mi+J82lSe7dG7hO+1UOOvUqORpiNp/2qmPIf4T+vnlC/Tj g3ZQ/LaUMhdjCHbQILj9Hf3nMZ28INKtf+7CAi2w/OkrP1+26JjlB4sPmpvT8mOBxhAfg6a2677W CcuwJy268NUFanI+6CKn/zQS0pWywS6000904fXz1DxpuhwZZ//PhPDvn9AE73D7Dh5zvMbseOxx gcu+b72VyRn3eRnWiMetL47p6AuihU75DzJ+OtHjhXlub69ypDzmOeGxT7PVJGpxY3z1gtt+eyVn 3Od7hZ32b1Pb/uNsv7oO8DhQ1wXisZw7/h5m/Mv15oT/5uZY7g8ie9IuZMQHAiCQCAEodmLDKhQ7 d1ix80Oh2IktDgQEAiAAAtNBYPtH5+i9X7TTyo6D6co3Zmd02fp0i84vXm1nfrlIzX++4ipYpqPk kEoQAAEQAAEQAAEQAIFpIwDFTkwl1vqiRh9++S36KYfn3CjT7p9fpqbWtPPfhdcGeFMaUzoQDAiA AAhMBIHP79G533+3nZSVEqnb7AFmJj4t2v7ReU+ptfOYrXVen4mMI5MgAAIgAAIgAAIgAAKnRACK nRjA1351jd668lF0SCs7PKnhFfD4gAAIgMAMEaj9kmXjn7VlIztRpuwsKDg+32aF1ntuKbPTZVhv zlB9R1ZBAARAAARAAARA4LQIQLETA/naL9/jyct2dEirrNj5eyh2ogHhFxAAgbNJoEX31t6md//2 gHgXPnrfmYHlWJ9t0bk3rpJzfYf2f5bBEqyzWbGRKxAAARAAARAAARCYKAJQ7MRUHK6T2Yiw5l9l t6HDOD2LCAeXQQAEQGAaCbS+YCeQ0+T8fBzI7ECT/Z7S/GszoMQahxOeBQEQAAEQAAEQAAEQiI0A FDuxoURAIAACIAACIAACIAACIAACIAACIAACIJAuASh20uWN2EAABEAABEAABEAABEAABEAABEAA BEAgNgJQ7MSGEgGBAAiAAAiAAAiAAAiAAAiAAAiAAAiAQLoEoNhJlzdiAwEQAAEQAAEQAAEQAAEQ AAEQAAEQAIHYCECxExtKBAQCIAACIAACIAACIAACIAACIAACIAAC6RKAYidd3ogNBEAABEAABEAA BEAABEAABEAABEAABGIjAMVObCgREAiAAAiAAAiAAAiAAAiAAAiAAAiAAAikSwCKnXR5IzYQAAEQ AAEQAAEQAAEQAAEQAAEQAAEQiI0AFDuxoURAIAACIAACIAACIAACIAACIAACIAACIJAuASh20uWN 2EAABEAABEAABEAABEAABEAABEAABEAgNgJQ7MSGEgGBAAiAAAiAAAiAAAiAAAiAAAiAAAiAQLoE oNhJlzdiAwEQAAEQAAEQAAEQAAEQAAEQAAEQAIHYCECxExtKBAQCIAACIAACIAACIAACIAACIAAC IAAC6RKAYidd3ogNBEAABEAABEAABEAABEAABEAABEAABGIjAMVObCgREAiAAAiAAAiAAAiAAAiA AAiAAAiAAAikSwCKnXR5IzYQAAEQAAEQAAEQAAEQAAEQAAEQAAEQiI0AFDuxoURAIAACIAACIAAC IAACIAACIAACIAACIJAuASh20uWN2EAABEAABEAABEAABEAABEAABEAABEAgNgJQ7MSGEgGBAAiA AAiAAAiAAAiAAAiAAAiAAAiAQLoEoNhJlzdiAwEQAAEQAAEQAAEQAAEQAAEQAAEQAIHYCECxExtK BAQCIAACIAACIAACIAACIAACIAACIAAC6RKAYidd3ogNBEAABEAABEAABEAABEAABEAABEAABGIj AMVObCgREAiAAAiAAAiAAAiAAAiAAAiAAAiAAAikSwCKnXR5IzYQAAEQAAEQAAEQAAEQAAEQAAEQ AAEQiI0AFDuxoURAIAACIAACIAACIAACIAACIAACIAACIJAuASh20uWN2EAABEAABEAABEAABEAA BEAABEAABEAgNgJQ7MSGEgGBAAiAAAiAAAiAAAiAAAiAAAiAAAiAQLoEoNhJlzdiAwEQAAEQAAEQ AAEQAAEQAAEQAAEQAIHYCECxExtKBAQCIAACIAACIAACIAACIAACIAACIAAC6RKAYidd3ogNBEAA BEAABEAABEAABEAABEAABEAABGIjAMVObCgREAiAAAiAAAiAAAiAAAiAAAiAAAiAAAikSwCKnXR5 IzYQAAEQAAEQAAEQAAEQAAEQAAEQAAEQiI0AFDuxoURAIAACIAACIAACIAACIAACIAACIAACIJAu ASh20uWN2EAABEAABEAABEAABEAABEAABEAABEAgNgJQ7MSGEgGBAAiAAAiAAAiAAAiAAAiAAAiA AAiAQLoEoNhJlzdiAwEQAAEQAAEQAAEQAAEQAAEQAAEQAIHYCECxE4myRUcHNTp+yTfw38Ibi3Tp tbnIu/EDCIAACJw1AidPjuj4ZI4W31w4a1lDfkAABEAglICWe0fHLbq4MEdP+PvSNxZp/pXQW3ER BEAABM4UgdYXx3T0+Am19Pz3lTm6xPPf+VfPVBbPdGag2Akr3i8O6IMvX6YPA7/lbldoc8UJXMUp CIAACJwRAs9P6ODf92n//92lj/72Qzpws5WhSnOHHOi1z0ghIxsgAAJhBI4+3qIP3rlK2yE/Frar tPa9xZBfcAkEQAAEpp/AySf3qPC/vEsftgd+vgzlb5epsPIOYRjowzKRJ1DsBIvl+QFd+9Jl+ih4 vXOevVOh0g+h3InAg8sgAALTSuBljd77vbdCJjVZqjZLtIgefVpLFukGARDoQ+DgH9+jy38RptKx D2ZuVWjnzzH+s0RwBAIgcBYItD75iM7/wbWeWXFulKnyV+/0vAc/nj4BKHYCZXDvL8/Ru//Qvpi9 WabiT7gSP9mlqwvf8SY8pceKsq8HHsQpCIAACEwzAVbsXGPFjlZqZ1YK5Hz+U/rZb3WGoNiZ5mJF 2kEABPoQaLFS+7xVaq9tVeiDZcddfnX8u4/oK2/bCc/OsaLMxT7h4WcQAAEQmCICR796j752pa3Y Lmzt0fvfe5vm+WXe8e+26N23r3ast4lKj3j++/UpytgMJhWKHVnoz/fp3S/9Md3T15Y2qXkv55md SW2mc7NClZ/grY1Eh2MQAIEzQECvqdYf7U/i82069/vv8QEUOxoJPiAAAmeVwDH97NxX6KecvdxW lTZ/4F9ydfwvP6Wv/I8/czOfvVNlq23/72eVCvIFAiAwIwResl/Zz47owlfZn07AOvv4Nx/QV7Jt 5ySbD5uU+0bghhlBNC3ZhGJHlNTxxz+jr7yju3ai9QcNyn9zXvx6Qj/PXKAfu2+wC1RXawR3ogIP DkEABM4UgdanW3R+8SrnCYqdM1WwyAwIgEAXgZNPD6j6bJ7e/ualrt+IZeE5VxayNLzNip0VKHa6 IeEKCIDAmSTwGcu/N/RYkAiKnckvYSh2RBnVfvEevfUjbYrGzkKfsbPQgBdwuwY7y85ES3AmKtjh EARA4GwRgGLnbJUncgMCIDAagZOPP6QL73zgPhxm0TNaqHgKBEAABCafQO0X13hu3PY8W6w16cqb sNiZ5FKDYscrnRZtff88Xf01X3A2qFF5n6S9jr7t5N9/Thf+hx+7T0Br6WLAfyAAAmeUABQ7Z7Rg kS0QAIEhCJzQR2ytfc211ibaYR+LGfhYHIIfbgUBEJg6ArxD6vGTY/rdb35K7/23bdLORw6cdao/ yNOCXqqPz8QSgGLHKxqh2FkuUvOfr3j+dcwtdqIDczTDBN8gAAJnk4CVd1iKdTZLGLkCARDoR2D/ 796lP/5vrudF9r3IY8N73WPDfmHgdxAAARCYGgJP7tG5hXcDyc2zC5J1uCAJUJnEUyh2vFIRip2I zttOdKDY8bDhAARA4EwSsPIOip0zWcDIFAiAQE8CR+w09Gsdp6Ha11jlGS/BDyzR7xkAfgQBEACB aSPwxS5d/vJ3vJ2wTPJzt/Zo88/fNqf4nlACUOx4BSMUO7DY8ajgAARAYDYJQLEzm+WOXIMACPA2 v+xX5ysdvzqaR5F3g7mC3WBQNUAABGaBQKtFJ88bdHRwj3L/9Zqn5Fm7W6fCn2LroEmuAlDseKUj FDvwseNRwQEIgMBsEoBiZzbLHbkGgVkncPyvrNT5r21nyZpFYbdOa9/GZGbW6wXyDwIzSeDze3T5 999tK3ciVrTMJJcJzTQUO6JgsCuWgIFDEACBmSYAxc5MFz8yDwIzSaDGzkLfyv7My3vhPit1vgul jgcEByAAAjNGQBg+UJ4OX6zTJThQntg6AMWOKJrjj3/Gprc/da+sP2hQ/ptyX6wW74xwvrMzQoGd SK3BiZRgh0MQAIGzRQCKnbNVnsgNCIBAbwIHvK3v5c62vvrOjf0Gvf8tOQ7s/Tx+BQEQAIGzR8Cv 2KmyYmcRip2JLWYodmTRPN+nd7/0x+Tuf7C0ybsf5LydsVqfbNH5P7jq3u3crFDlJ3rzN3xAAARA 4IwS+GyLzr2hZV6Oqi820ZGf0WJGtkAABIhqv7pGb135qIMiQ6VaibJvznloWp9s04//5h6985N1 uuJ76efdggMQAAEQmD4CL0+odnBErS9dJOfNbutEOf/FzoCTX7xQ7ATK6N5fnqN3/6F9McsewIvs AXzuyT69t/DHtN25d+exoszrgQdxCgIgAAJTTaBFx5/U6EmLM8FvYxqflug7V9pLEgp3K5Rlmdd6 STS3sEiLr9sJz1RnGYkHARAAAfYhcY59SNhPjopb71DzedO7VPvNNfrwt3y6UiJ1O+tdxwEIgAAI TDOB1icfseHCtXYWHJZ9//v79G3nEl14pUm1j7foctb6G8vfPaT1P700zdk982mHYidYxM8P6NqX LpN5bxP8OXunSqUfLgYv4xwEQAAEppqAr3PvmRPe/vxFCRY8PRnhRxAAgWkhUPvFu/TWj1xb7b5J zt7mMeAKxoB9QeEGEACB6SDwZJfOLXynf1pXitS8fcVbydL/AdxxGgSg2Amj/sUBffDly/Rh4Lfc 7QptrmAJVgALTkEABM4CAbnzQa/8LG9S459zBM8TvSDhNxAAgWkhENzavFe6sd1vLzr4DQRAYBoJ tD7fpw//8sf0018fhCa/sFWh/A8cKHVC6UzWRSh2IsujxWsOa0Tn56jVaNH8G4t06TUsP4jEhR9A AARAAARAAARAAARAAARAAASmj8DzEzo6OqITvSRff+bmaXHxEs3BWXKbxxT8D8XOFBQSkggCIAAC IAACIAACIAACIAACIAACIAACYQSg2AmjgmsgAAIgAAIgAAIgAAIgAAIgAAIgAAIgMAUEoNiZgkJC EkEABEAABEAABEAABEAABEAABEAABEAgjAAUO2FUcA0EQAAEQAAEQAAEQAAEQAAEQAAEQAAEpoAA FDtTUEhIIgiAAAiAAAiAAAiAAAiAAAiAAAiAAAiEEYBiJ4wKroEACIAACIAACIAACIAACIAACIAA CIDAFBCAYmcKCglJBAEQAAEQAAEQAAEQAAEQAAEQAAEQAIEwAlDshFHBNRAAARAAARAAARAAARAA ARAAARAAARCYAgJQ7ExBISGJIAACIAACIAACIAACIAACIAACIAACIBBGAIqdMCq4BgIgAAIgAAIg AAIgAAIgAAIgAAIgAAJTQACKnSkoJCQRBEAABEAABEAABEAABEAABEAABEAABMIIQLETRsW91qKj gxodv+QT/lt4Y5EuvTYXeXdSP7ROjunoSYsWvn6J5l9JKpbucN14j57Q3MJFaj1+QvOc/4X5FPP/ /IRqR0fUarXTNn/pdPjr2I8ODqh1/iItfHWB0kTQXSqnc+Xk8xodPW5Q85XzdJ6TMLdwiRZfnz+d xKQVa4vrX43rn27//Ek7z60vjrj+n7Qjpzm69I3FdOse5//gkyrHf56a/P9b33DSjb+T85MnR3R8 MkeLby50rqTzpeM9Om7RxYU5esLfLv805e8XLPdZ7rr17xUuf5a/86+mk3dfLC+5Hhwcuf3ApYsL NJciA186TuvkZYuOP2P512jSeZZ/xPm/+PvcF57CWCBNBC2ufzXu/9ufObr4xqVU+/8Tl7nu/Fn6 zHF/8w2ue6kCgPyD/OMKB/kH+ceSB/JvtsZ/aXY1icSl8Okm8LSi8kSKgfv+crcr3ffGfeVFUx1W yqp4q6Cyjo1/o9KMO6bQ8JqPymptycYrGWRvlFTjRehj8V1k9hsrGR93kwZndVMdpoPBy09jtyDS klPVJPN/XFaZQJ0zebffeVVNiUH9QdFXB20aMiqJ6li/uyZYh9fBdhqYQWLl0FTl2/nwdCytqfLj pOE31M6NbGj8G/cPvXqZ5EGDy92WtS2HzQeNJKNth/2soSq7O2rjel45XltIpr6FZeZwl+u8F6/N u+ZR2K6GPRLrtcbDHZUXcl+WQ/52WSVd+4KZKd9wbF1YLgV/jvW8vrtu44ooA2e1lBKDpqpsFUQd tHUhcyuZccDOqmAdkX+3PqwUk2PQPFSbq+H9b2a1qOpJV8BnVbUeOv7IqfKjpCNvV2fIP1vXpfyB /IP80/UB8i/Wbs8fGOTfqY7//IUxvWc0vUlPKOXPKirXY1CVvZPMoK6dm6YqLod3qpsPkx/UNB5s 9B1Y09KmSmx6x+yjJlV2gLGu6gkVfVewL6oBBV82EYWGibf5MHxCbfPerhvFWtJ1gZUbN7sH947j qMxSRuVu7CQwsWiq0kp43Q/mnyipcuA0rPrT4CxluyZ3pcQmGNHt3zDIbyWrXOhXB4tJaPRMA+D2 Ft7+s6koMyu3whVqhr3+TmpQqxE0H272lb/OjbKhlfz3o4A8WkpQocC5qd7pz1+3/eSUuh2krNwI Uy44TsaVf+t3E2iDXX2NXw7JOqj74ER6gJA0ZJaD/UCCSvVmtefYSzMoJjwOgvzrUe8g/5Jpdx2x A/nXu+55MhDyL7G+f5blX2JQTyFgKHYC0HfExC57s/2GtMmWFHLCUXoceCi2U57YdSa3zlJOFa7b QVXyih2OW7wpy1wvqfqzdsaaj/d8Co61uwmpVsREInujqKpP28PXYPz57XQsF7oneslOMJs1M5Fy VOF2URXvBP82VfFuJdHBBU8v1c51+ebYUZu7VdVMzELGNJ6m2jT1b2VD7dzfUTt37V+Zz9eMwtXZ SES56JtYO2uq0ql/mkllS1gTJRW/T7Gq31C3VaiNSslnybWTlPx5Ufe18/Xddjuv70uFb14dJlUX eGJplOqZlYKwHEy23bk1kCeVUsavbVU868T6vl/hsnNs6my834dbVrFR2NpTjc7svb5f9CkXS4/i jTc8tIZtj6bdJa7YybUVW05ObXbJPpaFLBN3Kgn1PQbCi0MrZ3S+WQ6Ua4m9yjCxsoipeG08d6uo tLzzyb+7m14dyNxM5uVS9batf851ts4x7ZzlQlH0CUnFX7llxzu0zNa5evzBFsyVbWk1u2bTZenF cwT55ymWIf8g/1xFCuQfyyDIP0+pRmd0/BdPDzIxoUCxI4vi2Z43uAq+FZOTPiehgZWXFDOgUofe RCd5xY5S5RsdjflKiMnp45LX6dNycm9uG4+qqu5NqD0iSon4s7cTeGMqonIPWZnXXgriqLWba53j ZCeYVrGT8JKvYF7FeWNfLofIqUoKcxoTfZUnL/nV9Yg4m2qjo/jJ3kmm/O3ExlFhk/eyN7lJxmJI WiwVA5N3n/y5sWeQxfotLfaygWWnlg2p9SSXZGnZZ+Sf1+aTbXdtiHVV6CgwciFWUXKZYFL1T09i D2tVT6EjC7e+bZcHptEX1O+byXRWrZulgWkpdrh/Oa3Pnlx6xkue0hN/DVXm5ddr/EIjNE62ZjXL dJOxWpEvdgohVrG2fQTHRrGUlc9aqNsqSMqfwn4oobGTAfnXHv9B/ikF+cd1AfJPyBTIP6PcOZvj P1HUZ+AQih1RiHXhT6W78ja8iSVR2MBHBBTXoXiDncZgXjUO1d6ufVPty4ZICyU8wPfFa05E/Mkr dqzlFK3uqMYjo9RKdoJpFTvJxmOQdn831Lrn3yOjyk+77zi1K8KaKymLleqdjsUAT/DLIXOHwy3z exLlw3XOLMMMNTWW8icZxZ/1p8I+bTrWel55i4mlcz2d5UBpt4dGraL2HkRYA3rWdKSSlz8edXsg 6n/ifYGQtfm7h+rQKJUSlvte+0s4Hgs1cNTY86xiyFkPV7AEHknr1MqepCxWhPzht7Ih4s8ulU2i fKTF3PUQxbWQP0m9WIL8g/xz2zPkH1sqQv4FZbv34g3yL4gmkfO0x3+JZOKUAoViR4C3b4VCJjZ8 n12ak8wbe5GU9qHoYBIfzHdFHrjw1FiwaE1+Wg4sbRqaFbNMiVTYGyV75/hH8s2da7nhTaqSmNDb 9EpBVuF1GM3juqo+rKoK/4VaMdlHYzlqVuySE+dGMub+oyZ0z/j8SXDA4U0siS12QpY7WeemSdQD MbEKtYhrqnWzJEb7GYndyQbHb5bCOWF+tMRSuVDF06glG/2cbA/x5zc63rBfGsKxb9LyJyz+6m2j VGQ/Iwn72LJLYliJwIk5NArPJAa0IrNe++N4Gmy9VH986Mo/LQMbQUWjeC6uw4pYirS+H3sDGyOZ VuHu3AxReowRsn1UyB9a615uKZeohconG9JIR2KsQ2F9Dy9V85ypJxE/L7eF/IsuOcg/HvdC/kVX kER/gfzTS3Uh/xKtZGcqcCh2vOIUA5sIHxpywp+KosUPaZgAAEAASURBVEUMdlKJz2PRfWCVWqTy SfnYCUbbGdzvbbeXBzmuNYmTrCUJr6c1vlyczpKXtCaYNp62SbQxfTTfDvueqSY4wZHO+wpbZVW6 mVcZdpjsOk1eXlOlBwn7twiWvzkX7SBJawk//7za83bAYj8Pd+xSmGQGeGJioZ1DB8uZGdid+hKw puLwjY+ZTMTksWKUa4kolkxh229bHkkosmw8/Y/8/hbClH79wxjhDt4hrP6oyu2w7fvEHdixYtPz fTJCkH0fOd7xltwWdtt2G1LhkqS6w4vHU2D65WDuVpK7gvnbX3G3rDZW2XF6R/5lVzdUxZMHfSnG e4P3YoFUkuMAKf8duQNWk31MiB27MkkshZYWO2GKY89qlutEEsp9yL8edRbyzx2DpaXYgfzz10XI P6Ug//x1Amc9CUCx4+ERip2IN0J2opHsAMtLEg82jDPRJAd0XnwRB/JtTXI7EgUiFwoWo9jQ30kv D7KTC2u1Zcs92Qmmjcc/oZH5d/mH2ckH8I1yat/UR8ef4V15kpzchaW78cD6/UnOcXk75qp0ksz1 zeFdwLw3JXrA5eQjfACFpXy4a9ZikOO97t95LLhLWezyQMiaKB8ytm0k2w4MNdse0onPxBv89qzF dPknPLj34hYKFtv+8yG+T7wnYjgQfSBPro2Y8co94bx78WjOUX/cN5t0xZBhEURnqaO3FDU8Dev3 01duW4VqiCWNyMH4hw3eFVA6zudd4Jb851rhkwx/qVgjtcZLAL0PjwX8u5QlYDEN+efhDh5A/nWs JSH/FOQf5J+7M2UKk4BJGf8F5eE0nEOx45WSHNSGOwe2FW12FDtNqSnmwfZmat50hbMyMch3VjaT e2PNPhaMg0o5ubXlnuwE08aTUZv32ddRR3g2HpVVXk44Vna8WhvfgX9g3Z5YOWpd705z0y4D0dfT 2pXM5M1b25zEm1oTifnmAX7kpFLXw1sJLlFjc1tjNeOmYWlNFbeLqmB873jtIOGJTcQbeTvxTrYd mKKw7SGd+Ey88tvzL+OyD7GkkjfHeSyXvnrlzstQbyW1FEcp6ThdLvfyyj3xiU1nVyau92Xe/crd iU87lN717wqWiPyRFiOGNytxdftbX/ErN5JWLvuqES+BMpZ6xoLU93vMJ82Hcge8buXWeiW5Eb10 EK/lX+b6hiptbfploi6bJOqhVOxA/nm1CvJPKcg/yD8zJoT8031COuOxSRj/eYJwyg6g2PEKTCh2 YLHTpsI7QxlFhxZsuYR2I/KKIHjAg/pmo6EOKwHFxmoSzlub/LayM5DVyx1kWjxT0GSc1sqodH5D PzzwNAN8Yh8w8VsuifrvTmzYMkUsB2oIH0eU5JaHwcwLp5lJLsNyo+W42hZynYGMVqzwluvFW2IZ FrPJ3klOudN86J/EmgGF/zthxU5EO/cGuDPSsdeFXx3NP5ndiIIVXpw3m6rxtK4q9+1W1zoda0ks hRXyRVvlyY/nuDeiX5T3jnXMu6E1jDY7GJBwXp3UUhxjHeu2tcCOMBXjZ0jLxkQU68EMt8/TXP6t ZY+b985LhAwvPyvdLfGStM425J3rxQRf7gQtJt30aObmT6chacUO5J9b+SD/2m0Q8o/9i0L+sbV2 Ww5B/kGxE95bT85VKHa8shATW/jY4e3F/UodJzDY97CldcDm2IWOYHU1xmZL5Lji91lL5N0BbXGL rVW2S2rzemdgSxnejlsfd2/HGlcyeoXj2/I49jenov7zINr415DpsbuGJKFYkjHZY5nnpN+USx8T we2+1dM98eaYO7a465/NslLPqmwlJfwbrRTUzu6OsNrKdzs3lc+PcswTe2MtBB87ertbu/xPTyoL uz5V7yiEx3vm8Y5dEpjAxNZnLbG6qXbYUkXLvxJ/r3lOtXMqr63H2Hn+aXx2Vs0EPwHFps9iJ8yH leh/gor/BGHYPCfQ5n3p9sv/zQf+FwyNB9axfiKKFZEWbaG67vk3yqjc9U1VlsrNJOof5J8oAcg/ yD9fdeATyD9PuZxA/ytpQ/61acBiR9aK4Y6h2BG8rI8L619F/Dwzu2I1ayU7ieBJTfANrmSS5rEt H1KlRzGbhIuBnSfAzVvCru8EJhaDgPQsh5JZCugteeL85juOU2WyJP/N2BVLMiZzLLb4TmEZlmex xbvChE3j6/fXvDfHxbjrn8ly1Pfjkhd3MhYDPLHzJvDWv4pNzuzsilXdtuXsKnVOwa+K5W6O5MQ7 /km+HUQZ5UmP74QHtibHwW/vzXkSFmNiyZMu87Jfr8FJEe2D409F/AlrxcSXYcn8R1gkla+bJRnp v9iQCv78dph0DtaWYc9F+c74roCQfz1knx4LQv5B/iX5Yi9EdEH+hUDBpUgCUOwINPXdgjd5Wg+8 sdIDu00z8aFC6MRPBBXPISsbjHl47M5SI1LoezPHnVg2QZ8OEUmIvGyXgiSw5S+ztkud+nTsp7Dd u4Yi17snUR8k37Dw5e/SB0dkgY37A1spGCVblwXNuGF3PS8G9rQe7iBaKtZSmdmZRIplgtwmw8rG 3DnOt7XIClFsy0nmdf9SnXHi7PWsVTakY/qr01IR24rrurex3zXD75XkBH/zK3ZitxgL+FIz7S7s O79VTTCf0UFbxXMSihXJNyx8+TsvyY35vUJYrut3rYIxcUW6tFi6Hu7HSSrWUhV/vr45OVkA+Qf5 Fybvgtcg/yD/IP/Ceqx4r53G+C/eHJxeaFDsSPbPrPNcCmy56a0/58G+czM5HxsyOUoodoo13y+J nNiG1FZsrG0HBvC8RKSwklVrCfkYqVcqqlKpqkaYNpwHnkbJlZbzLg+y598hYR87Yfk2ifD8v+iy CZl4m/vG+ZaTu9Wgg2ZhPZPSG+vK7Y4zVW5zpUfjZGywZ+0baV5qdtz9zN4NsySPVGpbXnMyyiLe oFzqTuXoV6Q/j6AiTSr1upXeo8fZ80lPkZZwu+skorolnYRnVKnmn703H5ZUbjmnil1K/565GOzH Fw1VfcDyrxZujSD7n7TfGHtlzz52Ev30kH++/LNFhb9k4kmVVJzng36MfGOD8M0V4kmFCUW+SIrf QsvE4n3rpc4sZ91JrBP24qqh1r2l0GzR2KOsvDDjOGBLIhsvWw/fTm7sBfkH+RdWZSH/mArkn5BD kH9h7ST2aymP/2JP/ykGCMVOAL5d0962VnEHkMfSv0ayk7rG46qq6AG+/tsves6LnZs7qqoVHz0G /4GsDHfKA6g1M7DrfG+wj4XN25ve37pxopiE81z2cWMdNTuqcKesqo8bqvmMnSc/KHn+P9yBZ5fS YbisDnq3WxbMvCy2wF67W1GHxwlMK9iHSzv/GVW4XVLVR5x3PXjWu8IE8p+cvyM5mdD1v9xWsjXr quT5GeLBf9JOVHUB+ba7D5toDFqKg9/XEBZ72o9SmcvA/XAZ7N2RDpTT6dgbjytq3bcjFvv+CFE4 DZ7DPncyc2m1ttHxK1PfF/419DK1xCZ1TVV/2JFxgXZX4HZn5F/1cQLtT1iHtd/QsgInIP/yxmIz AR8fPh83DsfNu+LVn7IMaLDz5G2/v5+83Aq6T5GO87NbFlwORdH2d1jxXhdO1ccJXz7b2O/sxrSU U5vbe+qQ8650PWs2OP/WklaXTWL+jnx9EFtr3W+/2GgeV9Sap9TQztMDLzxkRuI6FtvdJyfv/Ynd u2GWWrGM590nD42x2rNDVZTboKdhsccyt17ZES9zOE3at1FisodZQP55FrJEkH+Qf5B/roSE/BNy 4YyO//xd4dSfQbETLEKfZUTnDZZQeCQ6qGMLHavc6I67PeFoX98MvE0OZmPYc9/EQuRXxukdJ7HG 2DeR75X3nG+3pmHzOfj9rOQQg3kv7y6bBN4YSx8qPfkX4necK6HwNsu966CTirVKs2KVCZkktxiX edd+NHyKFK6HjpjsdMplM6FdYRqsyM0uZVQmJE490N5LUqnT4eCzjAiph0nuDDW4DIrfeXX1trXG 8rf1blmUyO5svANhv3jd33m3pgTUWr5W4J4ElBwybU4C7bG+La0Fupmb+J3rQUvC7qSPc6W+71ei mXjtNyuZk1QudBIvrRU30rL75zK3VrGdMuiSRbxMLQHFns525faayrD8c7ri5LSwoikN7pB/0W3P tAHIv/itxiD//FIb8i/QDiH/xPgo/vGfv/ZN/xkUO2Fl+LTie3NtOrRcgmbAbjLYasbu/BRo2L5J Fis3zNu0sPSPco0nFmZXHJPfqG8nqTd2WjN+I3qAn71RVPVUZjUaoPZr0j2p10yc1VIik6vD3c2e ZZC7tRO+TG2U8u71DNd/+Yba1oOcKidhLRGSFjnRLj4KuSGxSw1VDmxv7uWfLSl2anE3PJuR6q3w +pY3llP21kSPGg862x77ZI6jgjvlxJ4IufOTL+6ALFwOc+48XmqCW/t6ZR6SjkS2G+fkNx/vqcJy eB3Q6SlsVRKRO6HkfH5N/Pzz24ehj4x3sanKPLF3Qni3y8JRG3dTsJThTDQq1lJW1gNHW7Gk0v/I lwrpLEP0yo6XW2+shNdBZ2VDVRMTf5zn0LLPeJZTXhoTPoD887d32Qb0MeQf5F+yTRDyz7Y5yD/L oiOXEhj/JVuf0w/9nI6SweHTRaBFtYMa0fk5ajVaNP/GIl16ba7rLlxIgMDLFh3/5xE9Ye7u55U5 usT8519NIK4JDLL1xTEdHT+hVif7pPO/yPlPufodf3pARw1uAq8wpC9dJOfNhfRocR04OdEA5mj+ NNrd8xOqPTqi1st2lucuXKLFr88nm//nxxwnlzvH2XzZpPOvLnC5X6J5zT/tT+uEDj45orkvETW4 DrzlOKnXv7SzPDHxcd07Ojoit/rrRM3N0yLXg7nTqAdpQ+G6f8Ly71jLv07b07Jn8esL6eaf5U/t kxrpLkjLv7kFbv+vJ9z+JWuuA23xN38q/Z7ug2pHT7wUzV9KfvzTenJEtccnHGeT5d95uvDli3RJ l7uXihQPIP9ShB2ICvIP8g/yD/IvIBZwOjgBKHYGZ4U7QQAEQAAEQAAEQAAEQAAEQAAEQAAEQGCi CECxM1HFgcSAAAiAAAiAAAiAAAiAAAiAAAiAAAiAwOAEoNgZnBXuBAEQAAEQAAEQAAEQAAEQAAEQ AAEQAIGJIgDFzkQVBxIDAiAAAiAAAiAAAiAAAiAAAiAAAiAAAoMTgGJncFa4EwRAAARAAARAAARA AARAAARAAARAAAQmigAUOxNVHEgMCIAACIAACIAACIAACIAACIAACIAACAxOAIqdwVnhThAAARAA ARAAARAAARAAARAAARAAARCYKAJQ7ExUcSAxIAACIAACIAACIAACIAACIAACIAACIDA4ASh2BmeF O0EABEAABEAABEAABEAABEAABEAABEBgoghAsTNRxYHEgAAIgAAIgAAIgAAIgAAIgAAIgAAIgMDg BKDYGZwV7gQBEAABEAABEAABEAABEAABEAABEACBiSIAxc5EFQcSAwIgAAIgAAIgAAIgAAIgAAIg AAIgAAKDE4BiZ3BWuBMEQAAEQAAEQAAEQAAEQAAEQAAEQAAEJorA2VbsPK/R1v+5Tc0/zFLuu4vp g0f84I/6h/Z3SvKn9eku/fzXB+Qsv0/vvDmXuvxD/OCP+of2B/kD+Yv+B/1v2gMQjD8w/jjN8Ufa 9d0XnzrDn+pWTnFm+S+nDl+kn1HED/6of2h/pyN/mqq4rNnz30opfeGnED/4o/6h/UH+QP6i/0m/ A0b/i/4X/e/p9b/pt3gZI8mTs3ZcvWMUC1lVaaafO8QP/m3FDuof2l/a8kcM7JaKrGZJ+4P4vYEl +KP+pd38pGIV9Q/1D/UvZQLo/9D/dRQrkL8zKH9TFjeB6GZGsVNNf2ajpGIH8QdqXgqn4G8Va6h/ KVS4QBSnW/8wsMTAEgNLV7GOgfUMDqwh/yD/IP8g/7gOQP5D/gfG5mf9dGYUO7AYSL8qy4kt+IN/ 2gRmu/5hYoOJDSY2mNhgYoOJHSw203+vi/4X/S/639ntf9Oe7fjjO9OKnUPhY6d6Cj52EL+xGMkp 8Pc3vDTOUP9mu/55A6vlYhrVrSsOxN8Z2IF/V91I4wLqH+qfO7FA+0ujuXXFgfaH9of2x3UA8qdL NqRx4bTlTxp5jIrjjOyKdULbf7dO+8ctmjtvvc8/OfgZffRbFi36s5yntTfsb61miy7/8Kd0xZlv /z7W/4gf/FH/0P5OSf6c1OjDGx/RMc2x/DOCrEUHf/sh3eucZq+vkbcvIMu+Fi3Q1b/OUzziD/GD P+of2h/kD+Qv+p82AfS/GH9g/DUT408j8ibpO0rjM1XXa8XO7lcdDbm7E5Y4dpzw3+Nae4n4w/ma cgD/cD6of/Gs/Z3x9le9kw2vX5325zhCFpo2yd/ZO9VYxDziB38e00TWQdS/cDZof5A/cQhgyF/I X8jfcBmruaD/CWeD/iee/icOGR53GGfDYuclW8z8A1tMnBC/s7Yfn8XO0hoVHKKm+ZkP3vrhB57F zsm/b9HV/61Ic1+XIZibg9/8xvv1q1T8+yvk2vsgfvBH/UP7Oy35c3LAFjtFaghrRWKbHPnGLHO9 QI6VftRqXqCr19li57W2bDv4xQf0098c0dyrQVkXcv68RZe+V6D1FRao+oP4wR/1D+0P8qctD93/ IX/R/1iLDfS/GH9g/OXNvidu/CkE99k4jFtTNEnhDeNjpHq7t9afSzvwRjLTdwt1xD+4jxPwR/3r bmPBNifP0f76OSQffI0xO3pckmwHOF7a7Gtthfg7HPuusQd/1L8B2pwcg6D9Qf70GWxD/kL+umMq 9D99Wgr639nuf/tUjyn8+Uw7Tx5mVxyrhBl0gNXfITDiN4qd7BBKMPAfTMGB+tfPIfdst7/hduUo LQ/a7oYYLJswB1hyiPjBfzC5h/o38GQN7a/9Mg7yp68SDPIX8hfyd4g6MIiyDPJ3auTvFOpueib5 bCzFYokU9qn98hq99Wcf8U9ZqjZLtNhnldXJFyfUfNmk8694HkjDgm3f8+oCzfdZtoD4wR/1D+3v dORPi7a+f56u/ppF2FKRmveu+Japdgm2ly06OWmwbDvP8q/rV98FLSMvvLZAcz3vQ/zgj/qH9gf5 A/mL/gf9L8YfPaefGH+d7vjTN8I9Ayc91T5T/uMwb+yTyCriH9xiB/zjJ4D6N8v1bziLnfhrH+L3 lkIMYDEA/nETQP1D/eu8gUf762uxE3frUxwj6h/qH0+RFSs2Uf/ib2B9QkT7O13506d4Ev75TC/F ssurcurwRcIkQ4JH/GZiDf6ofyENJOFLs93+RMe+UkqYdFjwiN8bWIB/WAVJ+BrqH+pfZ2KN9pdw WwsLHu0P7Q/tz1VsQf6ECYiEr522/Ek4e32CP9NLsah1RFv/uEXNP8xS7ruL6dtXIX7wR/1D+zsl +dP6bJd+/qsDcpbfp3fe7GkInIhsRPzgj/qH9gf5A/mL/gf9byKDjB6BYvyB8cdpjj96VM3Efzrb ip3E8SECEAABEAABEAABEAABEAABEAABEAABEDg9AlDsnB57xAwCIAACIAACIAACIAACIAACIAAC IAACYxGAYmcsfHgYBEAABEAABEAABEAABEAABEAABEAABE6PABQ7p8ceMYMACIAACIAACIAACIAA CIAACIAACIDAWASg2BkLHx4GARAAARAAARAAARAAARAAARAAARAAgdMjAMXO6bFHzCAAAiAAAiAA AiAAAiAAAiAAAiAAAiAwFgEodsbCh4dBAARAAARAAARAAARAAARAAARAAARA4PQIQLFzeuwRMwiA AAiAAAiAAAiAAAiAAAiAAAiAAAiMRQCKnbHw4WEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQOD0CZ1ux 87JFJ89bNP/qPNErpwcZMYMACIAACIAACKRIoMX9f4tofn4uxUgRFQiAwEQQQPufiGJAIkDgVAjM cPs/04qd1icf0fk/uEa0ukPq7zOnUrcQKQiAAAiAAAiAQLoEar94l9760T3Kbx/S+vcupRs5YgMB EDhVAmj/p4ofkYPAqRKY5fZ/thU7n27R+cWrREtFat67Qnhvd6rtDJGDAAiAAAiAQCoEar+8Rm/9 2UeUvV2l0spiKnEiEhAAgckggPY/GeWAVIDAaRCY5fYPxc5p1DjECQIgAAIgAAIgkBiBWR7YJQYV AYPAlBBA+5+SgkIyQSABArPc/qHYSaBCIUgQAAEQ0ARaJ8d09KRFC1+/RPMj+vk6+bxGR48b1Hzl PJ3nMOcWLtHi6+w3rMen9QXH+/gJtV7yTa/M0aU3FtnXWI8HAj/p52tHTzpX5+jiG5doAb5KApRw OskEZnlgN8nlMm1pa322T8WPayLZ5+nt5Su02FsEu/efPDmi45M5WnxzQTyPwzQIoP2nQTm+OFqf 7lLxX494gOMP8/xX36Yr34XFpZ8KzvoRmOn2r87wp1krKi58xUuxVPMM5xNZAwEQmBACL5rqsFJW xVsFlXVY9mj5w38bleElUP1B0ReGCYsoo6KCazzcUXkRr32GVP52ub8cbB6qzdWMl275fGa1qOo9 srGz6oQ+J8Nwj1cgjyektp7pZFTv5Nz6yEuxznQ+kblkCVRvdcvDSHn+rKEquztq43peOR3Z30te J5vy2Q4d7X+ayr+pNiPGLeRs9h+3TFNWkdZUCMxy+6dUCJ9SJFDsnBJ4RHsqBMo3ugegZlK98aAR nabjshiEWmWEeTbqe323LsKsq42lIZ7d75EeEep0HTZVcTmcwebDHhqRrkw2Vflmd1k6jqMySxmV u7ETOtBpPtzsq1hxbpS7YvMuvKiqvDcZaecjsxxMR15VX3hP2IOQZ6PqDS1hoGbB4SgpArM8sEuK aXe4DbUZIfNk+3eWsip/o6gqx8PIwe7YTuNKfb+ocss5/rOyMFSeswzMBuRnm0FWVacv26eBOtY4 0f5jxRkZWP1+oe+4Q8qC9nFGlZ/6g6zvbnIby6rcCrc1/ssYRQ9ezPtB4WwgArPc/qHYGaiK4CYQ mHQCEW88WBngdqQ9JtODKAS6O2ZSGfkmnAe1vO/cwB2879lJRztw+lixs9Jm4CzlVOF6n4lAaLhN tXNdWr44anO3qpphypTA84dbWY9/YWtPNTqTCT0xsW+PSZUeBR7snFZv2+ed62ydY+J8UVdFkabM zUp3AM2KV/65W0VVvr+jdu7av/LdTS8Noc93h4grIDAWgVke2I0FbpiHXxx2KYPD+gp5rTiUknuY xCR8L/dxuU4fF6XYMb9nVgpqzXvRAcVOwiUTGjzafyiW2C9Wb9txjmzn/Y5D25BI3eFW2+ISKy4E FBwOTGCW2z8UOwNXE9wIApNNoPn0UFX2K6ryoNwebJs3Hp3BaOlxVPp5+dDD9nN2MFpQlYq+Fvwr ewPW4BKHxuOqvZ+fLQrFxtr2Xue3PbX3oKoaRmkQlaRpvu7l7bD3RCAkj439dU85Q5RTlWEMm/Qy sBqzDXk7XN/Oe+GGD6hYKeVNRApK2mK1k1lXBaO4C1USNlSZl5+t8Vv50CQ/s4qfqZ3YhZQXLk0u gVke2KVaKo2Gqh/XrZXh0rqqPq6r+qND96+6v6MKy1JZHWH1l2qiR4is2Uexo4PUst/I/8eljsyF YmcE2mM/gvY/NsLBAmg2VFWPFXeL3ssdulEKHz+Ke8LHITZKU35Q7FgmOBqcgKk/wXnK4CFM751w nsxqZXxA4EwRaB3Qe+cv0zZnKnd9jY7/9md0j4+dm3tU+cnbPbO69f1zdPXX/NydKm3+MNxhnbmn 3zbCR7+6Rl+78pFOBVVfbNLiiM6DeyZ4kn98WaNrv/cWaQI8iKHcNwJeAbvSfkIfXr5AHxzoHzJU frpD77zWddNoFz7bonNvXHWfDU9Li7a+f94te6I8NdQ6BX2Dbv/oHL33Cw5iqUjNe1eCPg57psvW hTWqvyjQwqzVhZ508GMSBGbaeWISQPuEaXjTMsuHf+6WD7t/8y595691TxQtD1tParT9620q/Xaf nc4f850LdOmPFumdP3mbLpxUqPhP9yjz4Q69/23jjLhF+7/apho7ideO5b3Pq1+l7PfedmWUdn68 /fF/BpyyNtmp/CJlf9C+x3uOD04+PaDdf6+w02N+hEX2ha9epm99y6GFuSOW518bWJ63Pt2i84ta 5map2izRYj/xLxOB47EJmPrYb5wydkQIoE1AjHeKNUVX3gwBI+4JH4fYZ0z5DTPeaH1Ro93f7tL+ v+3SwectOnZlCEuRP8pQbuV9yn7TyA0bT/BIy6D9jw+o9kWD2/8F3vhikd7m9j9PNdr65T4LBZY0 rSbNc5gZxx/e8PIrGDvO4yJg6s9Mtv/p1Un1Tzl87PRnhDvOHoFDzzojx/5Qmqrk+UDQ573ya33E +LTcjYraWF1TRddPj7XsyNwKWZIjgjcacx7YJutjgJcDFHhtdnbJUdoPzUB/bH2ydvdQpDaBw36m +4EomxXrI8e50Ztt4NG+p9XbHbNmznexFmLSw157rH+gNXUYrCfMeM1Y7CwP6/yY1UQd6zFWLvZN K24AgTgIGPnjk2VxBIwwQgkY3pFv2B91NrNgORL2tt573siZiG/fMl6zQUbIvcVHbTlXvSWtheRy YcfvhP5ZVa17faW8r31cYItEs6Q1LP1BKN74M+n+Lxgxzl0Cpj6h/adUISLGO42HJbW2uq4q2qcO 32P8UEU6IO8k15RfpDwJZKuxK62du9svKwxUTx+DPAYq37TL0fX99i/jpdte2/D5OvTS63tOhtE+ 9smvQB5wGh8BUx6z2P6xFCu+eoSQQGACCDTUhlmCtdp2lCuX96zd715kYxNtJ/fZO2Inmc7gOXOr fa1yW+/4kekoeuzTwSMjWBNX7Aj/LrbT7e5Qg785fRRTwfwMfR4x0IkKp3rHDioKW2VVuplnB4Jt RVVmeU2VHvQqu5BQeYeW+qMqh9MO152UOOvWd07gERm/I3fAarKPnVU7ORp6YNJnQhdIBk5BIBYC Rv7M4sAuFoBDBmJ4R03EDrfXvIlSl2LkqXTgn1WbdyvqkJdzVSt7avO6lYtahvvK0/X/lfMULq6M d9jBvPAR1uDdBfOrcpcq7htcJ/S8bNQosJ/u2WUkfSZmOo6u9IewgmInBEqKl0x99NWXFOOfuajE eIctdryPGVdsuL61GjyWyChnKd93mbkpvyh54kXQOfDvXueoNe3rb5d3KL1pX2rpthv5YqvjH9GV IX1kQIadqW/cFWPkUeVXMBM4j42AqT+z2P6h2ImtGiEgEJgAAo/Mun6xxbZ0cBnqH8Wk2yp2iHcx Wbu+5v7lV9rO8YYVkEawJq7Y4fcmlbslVdwuqdKAf8Ut3qHlcZjlimERw7cY6AwyEaiEbKsbHGRk eFergVJ9vONNomwY+RDfOTKfDVUSChz9XIatoOzz/MaLFT6hPnRkMIHjirfDV4glUOBenIJAXASM /BlWbsUV/6yFY3h3TcTYB0dlW75Nd7p2xGk+tNY8xUfd5BoPrDVjmGJZvryIeiu/58mhjKo8k3GI fk9P6NhHkNy9q3lcUQXP/1j7hcEg8hyKHck4/WNTH9H+U2IvxjuZ5bw3fsx12s4gbUam1JRflzyR N8njp1VVvM3KnAfdltjSGjpMftR35c5eObXz0I5ymhzuhs+Sjy3QjUK4E/+48ktmA8fxEDD1Zxbb PxQ78dQhhAICE0FATqKlfYfc8aiXE2W7HKfb4mVYAWkEa/KKnYlA350IMdDpP6jhyUVg8sBekdT6 nWLXG6f8dvfApSty3xskW5a5W72XQjUfbvgUOVKpo4/XKwOplWxyhFLRudE7bvsQjkBgfAJG/gwr t8aPeTZDMLyDMiN4ntsSb7o7qOTEqKDfhAcmTvq2Ji/pyLGlzca+7NkMa+Hcna1J/Yobvqex51n1 dCl+hEUhaYtGE6Tvu+4tJ9X56S/POb3eMrGElyL70okTQ8DUR7R/QyThbzHeCbb5QduMTKEpv4EV O+Zh7cz5wZ5rrVPe1Zt2VFX9ccVbStVdH6Rit3sb9nawwhKel1YGh0Hjyy+TeHzHRcDUn+7yjiuG yQ0Hip3JLRukDASGI8Ada16/cdR/7AelzktxGsf895SX5IjdlqL9nNgOLsOm7FXeYan6sKr2tttv M4YVkEawJq/YYYudbVaAsBXOwH+sMNnr+GAYDvIQd4uBTv+JgGXfHhSxqbJ4q9yo2Dfa7Ny42wdO WLKaTS77uqrct1uN67DX7oZPXbzBSWcpX2Z1Q5XYEmqDTafdNHWuF4fYqqvxwCqK+jMIywSugcBo BIz8GVZujRYbnjK82/LLKpPtuV6+Gy571ONuC0OHrUZzKzmV42VUazfWVfHuHvdp0Zzrd+3Of7mA 8rty2y7n2jn2h+Ftq8yycX3fvqn338W6oQfW6mgQWQbFTpBguuemPqL9p8RdjHfWtvbcsaMeQ5Zu tMcPg7QZmVJTfoMqdpqP9tT6it/C2MoeK4+66gMv5zQ7fvbyG2mtfkIUtTHIL5l3HI9PwNSfrvIe P+iJDwGKnYkvIiQQBAYjIM3Rwzo0ey3KibJVLvh97LTN4If1SWMEa+KKnTPhY8ey1+VU2O2eYJRv mEFL91KGvjWEBx7G8Wf4QMkf/6brKNuGKpdChD9v75VHO6tmQDWgMko+jGMQGIOAkT+zOLAbA9vI jxreWvFccbc7r/h8cxEVIqxh2lFWhQ8e21cZ+WG/89vdFj9uCGJiSbRul4zK6yulrvzZdFPXEjHf zcIKcpBJKhQ7Pnqpn5hyRftPCb1oZz4fO7fbip1+zpKDqTTlN9B4I0Kxkl/NuZtqSHnSVR94/Ggc OvvGvcEE9bHAG1t+BePD+VgETP3pKu+xQp2Oh6HYmY5yQipBoA8B3v1qCOdv4U6U7eTeJwx5Z61q paLq3bqGnmkygjVxxY7eFYutSQbaDcvsmuVargywpKlnDvv8KAY6g0wEZPnlQxQ7cjndZtAWuE9S eGGA2PUqRMkilkzRyk5oaOXrRrGU71pjHvrAs4rnkBTLsEIJ4WKCBIz88cmyBOOb9aANb20tahds stwR/VLXMqggtMah2rm9rvJsqZNdzrCPL/1n5I5V7pQDVjcmGGmZY2SutOQpug5czd3tb+PcVU/+ SiH+fby7xZItE7b3W8gBFDshUFK8ZOoj2n9K0KPGO8/YarhStY7KB0yOKb9BFDv2BRI7V7+5023Z 96KhNjtL3bvrg11m6VxvbzgSlsSG54cnxGLHPDCm/DLB4Ht8Aqb+dJf3+GFPeghQ7Ex6CSF9IDAI AeFDwPNhoP0UyD/ezjXHg1f37UWoE2U7+Y9DGBrBmrhiZxA+p3FP1EAnIi2WV7gPB/l7+M4OEQG7 l23Z6jfqQed/qmm3IaXr4b5w7JKF7jXmYTHX74pdcIZWRIWFiGsgMDgB017ikGWDxzq7dxreXRMx VvCaN+K67wlVSj8uu0rgvNyNUaLkiZncijhSscL9YMb0ce6ukA1vmQVxnxf2buJw2y7h6vXGvnLL LueKjF+kGYodAeMUDk19RPtPCf6Q451+qTLl1yVPgg+KpVS0Gv5SSrGtoFlu1V0f5NiId80KG6vI sTP72KlazXU7NXHJr2DecD4yAVN/ust75CCn5kEodqamqJBQEIgmMOikW1p9hDlRNs6Tew1wo1Ph /0WmqUuR4L/1bJ6JgY40TY7MrNjRrHuAws77POfKIYoVnvhUH1RUpRbuw8Lzn6MnPUvyjXonNXJw 5IQtmWgI56FrkVum27w1vTdkA/sEsg/jCATGJjDLA7ux4Y0QgCfv2WIn+LFvu/WLhe7d8aR8KkX5 PvOWQoQrvk2c1rIwxzslWr84hSj/OYEdBMN8iPmWomrlVIjlj4nf+/YsfKKWPnt34iABAmj/CUDt FeSw451eYfFvveSJ71ERr7YW7Prw2Gin4+dHK5bDxrbSF6C+Z+2O9ufF2hv2U1jdL1plsR4/hSh2 4pRfXenHhZEIzHL7h2JnpCqDh0BgQgjoCX2lrNY6jm11p1Rms9fKw8AEX+8UwMupylvWisJhB8mV R/q+pjrk3yocjtnWVTtPrjzka1pZMKAZbeMxx6vv13/8bPF6x+ku71JS3O1cHyK8CSE8VDJ8DMSA wGHzYM3fZROhfNHlYMyF3QHIrXLbfLlZVyWPJQ8sfEsd2slrPrTbAZPDE5r7vHSOnWY3G2wGLSY3 Otz83fAlaHueDx+OY2VTHZrX288O/b4yepgre7DEZKnv8gvvIRyAQHwEZnlgFx/F/iE1tdxn2Wbl fZb7oIqqPjICRIfhXyqcuaH7F7s8w1q36IkTOzHeZvmlJ1b6w1anjVrZWpvy70EHyO0bO/8/LrWt Uvk+HRa5fWOYsto+JZdyuLLXTd+hOtT92A1rqeOGx2Fu7FfVoS9/Oqymqnt9pr+vLdxlHh35X30c fN1v04Gj+Aig/cfHsmdIPLZ0xzVivLO2VXZlQnssGBiLhgbWGYOGjh8dtaPHtOY3/g7KFvNC0m27 nXFt/VGVx7sbAaUML9l3x7bcfp/626FVCHfkhpEfXd/dFjuxyq9QPrg4LIFZbv9Q7AxbW3A/CEwQ gWrHMZ0ZcMrvDfFWMfo+R/3uP4RSoKsTa3dyfR3f8VsTzwQ+IgyZtsztCAeYE8R26KQMwWCz5h9U eHGxg87eHHmQ89i72x4cl/2TmagyWAmx1jGhsBNBb6meeZ59Esly02+r5G5d5tHgt/R10bfuBB/G OQjEQGCWB3Yx4BssCJZ5cpmVX1Y4/m2Bhc8tc58nGzzrln6TKv49crmFSbLfr4+OKx/YJcvc6X13 /LSZdA327c+fT7lu5GfoN08M9RJpfBIlgPafKF4v8OixpWnL/nbiPSgOBm87nTCdTVaj2s/gG4eY NPF3IAwdWmWrvQNsV/t31lTxjnkp2q3YUbHKL5svHI1OYJbbPxQ7o9cbPAkCp06gsW+3k/Z3RvzW VDiYPBT+Tvz3ralqZ32w/7roAHlwGmke7xGQS4X8z4aFuxFlFu+FN4UHA08OcqrnjuFPKz4LLMsv p8o93vY2H++pwnJQEWPLorBV8Q2GQgnzWvKNiC1DnZUNVZUv4UMD0BfZ8sizIMMyhEhM+CFRArM8 sEsUrC/wbiWKJ694SedhQIHRqBTt7nzkeP2KfOPtsMNkLwyfYsRxLXnkhM6XFHHinygOKIP0ko1b udC482w9efiwJNKuJ4aB/MmdB33ptjLYzddyuK8fkXwcxkAA7T8GiAMEUd+1yx3D222IT79guPxi qvcLrUAbWi11jWUOdzf97bPTBjMr66pyzNZ0gXRmoiyPtXX7gz1V3i2r8j5v2+5atbOXHs8XV7di J275FcSD8+EJzHL7P6dxcWM8k5/Wp1t0fvEqsU8Jat67QnNnMpfIFAiAwFkkcPzpAR01iM6/wrn7 0kVy3lwYLJvPT+jo6IhOWp3b5+ZpcfESzelwBvy0vjim2tET7+75S4t06bUhJCinwY2f455/1QsG ByCQGoHaL6/RW3/2EbHzRCqtLKYWLyIajcDJ58dE8wttefGS6OTkhJqtJlGLBdmrF2jh4vxQAR9/ ckC1L5q08I3LtDiM7Gqd0PHnTTr/2nlqPm/ShYsLQ8nOoRKJmxMjgPafGNrJDfhli46fHLtjj7m5 ObrwGsuTIYYtvTJ28I/v0eW/2OZbslRplsgJhBu3/OqVFvzWn8Ast38odvrXD9wBAiAAAiAAAiAw RQRmeWA3RcWEpIJAIgTQ/hPBOpuBnhzQtQuX6SOde2edGpU8Dadmnk1sp5nrWW7/UOycZs1D3CAA AiAAAiAAArETmOWBXewwESAITBkBtP8pK7CJSG6LDv5lmyonxBaCF6n1vEXzrRp9cOUDOuikz7lZ ocpPnIlILRIRTWCW2z8UO9H1Ar+AAAiAAAiAAAhMIYFZHthNYXEhySAQKwG0/1hxzkRgrU8/Yvcd 16Lz6hTo8MEaXRpiWXt0YPglSQKz3P6h2EmyZiFsEAABEAABEACB1AnM8sAuddiIEAQmjADa/4QV yDQkR1vnnH+LPgym1cnS+k/ylFt+m+ah1AnSmcjzWW7/Z1ux8wlrX/+Ata/OJjUrOThPnsjmh0SB AAiAAAiAQLwEar94l9760T3K3KrSzp/DeXK8dBEaCEw2AbT/yS6fSU6dXoLVYkfMxLNG7YSZ/+Ez ZQRmuf2facUOfXFAW7+t8U4Li3TlT7EmcsraJZILAiAAAiAAAiMRODnYpXv//Qld/C8ZeseBq8uR IOIhEJhSAmj/U1pwSDYIxEBgltv/2VbsxFA5EAQIgAAIgAAIgAAIgAAIgAAIgAAIgAAITCoBKHYm tWSQLhAAARAAARAAARAAARAAARAAARAAARDoQwCKnT6A8DMIgAAIgAAIgAAIgAAIgAAIgAAIgAAI TCoBKHYmtWSQLhAAgf+fvbMLjePK8vgJZEACP0jgAStkIR4SiMxkSInJQAzzMF7yoA67kA4KRCJ5 aSvzkJkBI88+SCYP3s48eOQMeOQdcOQNKLQCa1oBD1Ig0PLDrjXgLK3FWboNHqQFB8lgQzfYUAU2 3D1V3bfq1ld/uLuru6v+DS11fd2PX5177qlT954LAiAAAiAAAiAAAiAAAiAAAiAAAk0IwLHTBBAO gwAIgAAIgAAIgAAIgAAIgAAIgAAIgMCgEoBjZ1DvDMoFAiAAAiAAAiAAAiAAAiAAAiAAAiAAAk0I wLHTBBAOgwAIgAAIgAAIgAAIgAAIgAAIgAAIgMCgEoi3Y+dxmdb/skH662nKvDUZ/T1A/uAP+UP7 65P+Me5s0+Vru6TNfEynXh2JXP8hf/CH/KH9Qf9A/6L/Qf8btQEC+wP2Rz/tj6jl3ZWfiPGntJ4R XFn+ZsTek+grivzBH/KH9tcf/aOL3IzJnr/z+eiVn0D+4A/5Q/uD/oH+Rf8TfQeM/hf9L/rf/vW/ 0bd4NUdSN+L2u7QmHQtpUdSjrx3yB/+aYwfyh/YXtf5RDLvpHLtZov4gf9uwBH/IX9TNT3WsQv4g f5C/iAmg/0P/V3esQP8mUP9GrG482SXGsVOK/slGqI4d5O+RvAg2wd9xrEH+IhA4Txb9lT8YljAs YVhajnUY1gk0rKH/oP+g/6D/WAag/6H/PbZ53DcT49jBiIHoRVl9sAV/8I+aQLLlDw82eLDBgw0e bPBggwc7jNiM/r0u+l/0v+h/k9v/Rv20484v1o6dPSXGTqkPMXaQvxwxkhHg7254UWxB/pItf7Zh NZOLQtx8eSD/umEH/j7ZiGIH5A/yZz1YoP1F0dx8eaD9of2h/bEMQP/4dEMUO/qtf6KoY1geMVkV q0obf1ymnUODRkad6PP3dz+lq9+wajE/Mwu09IpzzNANmvrgHM1qY7XjHf1F/uAP+UP765P+qZbp 4vmrdEgjrP+kIjNo9w8Xaau+mV5cIntdQNZ9Bk3Q3CcL1B31h/zBH/KH9gf9A/2L/qdGAP0v7A/Y X4mwP6XKG6T/YR6fodpfztVXv6p7yK2VsJTfmhZ8vFtzL5F/MF95H8A/mA/krztzfxPe/kpr6WD5 qrc/TVN0oWyT/D+9VuqKmkf+4M82TagMQv6C2aD9Qf90QwFD/0L/Qv8G61iTC/qfYDbof7rT/3RD h3c7jXiM2HnKI2b+xCMmqsTvrJ2Pa8TO9BJlNSJdHuYfJz44a4/YqX63TnO/ztHIy2oK8mTvf37j /eIc5T6bJWu8D/IHf8gf2l+/9E91l0fs5KiijFYkHpOjvjFLLWZJc7QfGfo4zS3yiJ2jNd22+/lZ Ovf1Po0c8eq6gO3HBh1/J0vL86xQzQ/yB3/IH9of9E9NH1p/oX/R/zgjNtD/wv6A/WU/fQ+c/ako 7nj87LanaJDSayfGSOlKY68/323PG8lU0yXUkX/rMU7AH/Lnb2PeNqduo/01C0je+hxjDvQ4rbJt 4ff0atPRVsi/zrHpHHvwh/y10OZUGwTtD/qnibEN/Qv9a9lU6H+atBT0v8nuf5uIxxAejnXw5HZW xXGcMK0aWM0DAiN/6dhJt+EEA//WHByQv2YBuZPd/tpblSM/02q7a8NYlmm2MOUQ+YN/a3oP8tfy wxraX+1lHPRPUycY9C/0L/RvGzLQirMM+ndo9O8Q+m4aFjkeU7FYIwV9yl+ephMfXuVDaSrpeZps Msuq+rBK+lOdRp+3I5AGJVs758gEjTWZtoD8wR/yh/bXH/1j0Pp7ozR3jVXYdI70rVnXNFWfYntq ULVaYd02yvrPd9S1w9SR40cnaKThecgf/CF/aH/QP9C/6H/Q/8L+aPj4Cfurv/any8KNwUZDt8+Q H2znjX0vqor8Wx+xA/7dJwD5S7L8tTdip/vSh/ztqRAtjBgA/24TgPxB/upv4NH+mo7Y6XbrE5wj 5A/yx4/Igh2bkL/uN7AmKaL99Vf/NLk9PT4c66lYzvSqjNh70mOSAckjf/lgDf6Qv4AG0uNdyW5/ Ssc+n+8x6aDkkb9tWIB/kID0eB/kD/JXf7BG++txWwtKHu0P7Q/tz3JsQf8EKYge7+u3/ulx9Zok H+upWGTs0/qf10l/PU2ZtyajH1+F/MEf8of21yf9Y/x9my5/tUvazMd06tWGA4F7ohuRP/hD/tD+ oH+gf9H/oP/tiZHRIFHYH7A/+ml/NBDNnh+Kt2On5/iQAQiAAAiAAAiAAAiAAAiAAAiAAAiAAAj0 jwAcO/1jj5xBAARAAARAAARAAARAAARAAARAAARAoCMCcOx0hA8XgwAIgAAIgAAIgAAIgAAIgAAI gAAIgED/CMCx0z/2yBkEQAAEQAAEQAAEQAAEQAAEQAAEQAAEOiIAx05H+HAxCIAACIAACIAACIAA CIAACIAACIAACPSPABw7/WOPnEEABEAABEAABEAABEAABEAABEAABECgIwJw7HSEDxeDAAiAAAiA AAiAAAiAAAiAAAiAAAiAQP8IwLHTP/bIGQRAAARAAARAAARAAARAAARAAARAAAQ6IgDHTkf4cDEI gAAIgAAIgAAIgAAIgAAIgAAIgAAI9I9AvB07Tw2qPjZo7MgY0fP9g4ycQQAE+kAA7b8P0JElCAwI AYP7f4NobGxkQAqEYoAACIAACIAACPScQIL7/1g7dozvr9Loz04Tndkk8Vmq53KEDEAABAaHANr/ 4NwLlAQEoiZQ/vxtOvHRFi1s7NHyO8ejzh75gQAIgAAIgAAI9IFAkvv/eDt27qzT6OQc0XSO9K1Z wnu7PrQuZAkCfSJgoP33iTyyBYH+Eyh/eZpOfHiV0ldKlJ+f7H+BUAIQAAEQAAEQAIGeE0hy/w/H Ts/FCxmAAAj0gwAcO/2gjjxBYDAIJNmwG4w7gFKAAAiAAAiAQPQEktz/w7ETvbwhRxBomYBRPaT9 +wZNvHycxtqKE2XQ/m6ZDp9yVvydeGWSjh9N1pg1OHZaFjOc2ICA8fcdyt0oK2eM0smZWZrk0G1h n+r9fdo/NOjYxAjd5//HX5tss/2GpYz9rRJIsmHXKiOcBwIg0CGBx2Va/2qH9Hoyoy+dpNm3MEKw Q6q4HAQ6IpDk/h+OnY5EBxeDQJcJcMDf/e936G//9TfKf3GONnZr6a8UdfpYa9Ex83CXzv54ii56 ipa5UqTVec2zN76bcOzE995GWbPynzlWy++2XFmGtcf9G+t09tQcbbjOrm1kN0q09A4M/gA0PdmV ZMOuJ0CRKAgkgMDh38tkjEzQ8RcbeO4VDsb3lzmW52+cPdoq6cUMQj84RPALBCInkOj+X8T4o5dz gqVJcIwdoce4nuLJnlgw69nmd2G9FGcqQ1g3XeRmgu/j6u0WJfhRUWQayEF6rTiEXJ6tyIlp/8+G p0tXVcRqiMyq+kibTouF8zlRPGxRjrtUum4kc7CTE5mZDH9Tto4Nao/FS2n7uFp39XfqUnLaXzfY d5JGaS1j3Q+OsdNJMrgWBGJMoCJWpoNtDlVvrd6qxJiBUzW9vFrX4SlRbLWrOrwplubTIqXVOcb9 ecPBhV8gMLAEktz/08DelS4ULDEPdk9KDR/m1Q5a/Q2DtwtC1tUk2LEzXzMOtOmMyC42fpAMynrz jGOkpS8ULIemflgQacXZk78XdGX89iWm/ffz1j2DUznXqpOyn/UKylvRsz7Hjl5ytbGl9aKoPKkl crAjHxZqbXPzMChx7Os2gSQbdt1mifRiSoB1mmobqPah+juVEOeobTNQWpRadezURWNvveZIjv2L 5Jg2BVQrXgSS3P/DsRMHWa7cFLyYu/WmYWmtIIq3iqJYLIqc4hhY2rhZ23+rIJbqbxbg2BnQm19/ IBRiz3bY+R4kg4r+yJEDml51jVLTbzsPl9qFZIwasI00vEELkpbu7atUxMHhgShcqDsip5dF6d6B OLi7Z31LO5siO6Mpo1kWRMmW8e4Vo+cpsfNGjobzt8cDka3r4EzASMiD60t2/dNrGEHS83vFGSTZ sIuCL/KIB4HKvZJjG8rRO9qSKJh2pPUt2U7qeNQ4vBa2zcCOnZZH7NSTk/oGjp1wvjgCAlERkO0x ic+5iLHDryWG/WN8f5Xn+J62qpG7K2j25VqN9r86TT+ZvcobGSo9WaXJevDdjY+eo3c/5931ZeCN O9uU/8/7NKqGcDGIjv0yRaderc0zPvxui7b+p6qcw6Hinp+k1PsnaeSHXdr4pkg0Mkpk6HzdHF83 Qod3dmnXDOD7WCeD05t4dYpO/VKjMTWfWlFdf6scrDT/1QZtfL1Nh/LIsSmae3+WZmdOEccjTcbn aZlO/+gEmXeQHyQp81rjih/e+JReOHXOYrN8q0ILb6hzxKt0OTVOv/nGPJylA7FEE9aZ8f2DGDvR 3ls5p5lmcqT/x6wvxsD2v75N//hJLVZNmDwb98u0cW2D8t/scNBws/VzrIOfT7LeOEnj1SLlvtii 1MVN+vhXUnoN2mFdUeYA4ax9nM+Rlyj9Dusm3mMGP9648X+sn5zDZIa6ZP2VNvWXupt/V1lvbX9X pMMqX8IHx1+aojff1Fjv7HN7/EloezSvKz0ao5NvHPekyJt31um5yTlrPxsaWH7bT6jre6Q8gnfX 0SLBmBJYf+85mrvGlWMdLliHP8tn/28btP5FjvL/vV+7nOMETrDdNjc/R+m3NJ++JeOQtq7dIFa3 lv048tNTlH5jnLa/uEyXv673A8eO07vvf0wLH5zyX+8ppNmH7NzYpfLDCuvvcV54YpJOsv4eIw5y /OWObaeO/TxFKU32I/VEbD2dZps5b9vMniwCN6W+ofk86f/2Jpf/3+mqUv65D87Rx+8H1D8wNewE ARDohIBsj4ns/6PynvUjH9v7HvM39nY9PcNHpceSwvZbXHSxKucGK9N1uEEJskd26GLFe8za1qy3 GqVL6tt4vm56SWTnPfuU65evh7yxflJxjTKyyqBcJ7dXtw+6K048nSQ7kxbpaU1oWotfLtfS9b3u lsObWqOpH95zebt0Rcb44Pnhj/wnODFA2n8b5U9t8PfY7SLm7X9Q7oStb8J4363HPOO24x/x4oyw kO087L9rWoCMoxagJ3J3a2PpffrJPremv2x+j0piuUG8oOylrODQ49bIm6Dy2+kE/KhsL9sjdoJG 9ARcgl0dEpDymMQ3dh2iw+WJJKDE+AvT4Y24PCjao8HDdDe/ZBSFe+45TvrtFVs3hl9X07ukLYuD 0NGeOo8alTZQ/Xxb16cCppytWKOaK8Uc234pkTK/bP/ZZdDq++Qx63ha5EOmEkt9Y19v562UhUdS JyNaUSNBwTEQ6D0B2R6T2P9jKlbv5avnOdgPsGEOnJD92uKmVbaD7VXLqeHqkGYWRL7odEGljRWx IB965FSuxZzVyVZu5cQCB4+TDz2udLhzM50l3n1pXxBRfxC/hQu52nDg7Tw7XpTOkdNc3nHK1jFg vWhPZfOWs9G25qs9p765AAAW10lEQVRDxyVxJ9CWY0cxyrSVQOOhcssxoNp9MHUXbDi27HbxLEbq cFRxoEopO9Kwoeh7G850JJ/8PSgo+iMtVq8XxR5P5yoVb4rVRbex7uqonxywMzijXMt6gg3yTF03 mYAs/XRmwX0OG+kZDuYs4+CIB8o0xiCD3LPPV/6Gd4IDTMspDpzOZkJiXDVEEsFBKY8ueYkgX2QB AsNJQLEh2u0zK14bKiWW1zatkACF62xfuvRnShQeKITYIZQ9k3GCD9vnamLhDOt+1ueqHRbsGHfi E6rnhv1OcTD8lfoLxnDHv9vmlGmF2X1S38jziDSxdGFVrJyvx96p12vp2y6/mFRQ4icIgECNgGyP Sez/4diJQSuwH2DJHclfCrZvxM6Vekd5pqDUviKW7ZE7mggM8HnbeeOeWfePVvGu6JTlAKK6fLui V0ThkruDy5WdNzd7GwtO5z2dFaWAESd73zpvvc03P+0Gt1Mq6/mpi+L1vMht5EW+xW9unVf48bx5 8iTa+eazOnZmgleBc+QkeMRE5wUerBTs+rZrpA5WNYamNLa+8fLmtl/cUNuu5jbsuYa6olt4Oqnv U7nlxIhyjdipn1nZcdLXzqt6zUnqpowBZOpJl35RHmhM45tjBKmrd+mH/OChOGZMw70dx46Tr5l2 cNt0Solf3SIg5TGJhl23GCKdJBFQ9GBbekoX+fqiD6ZuTJ3fdBzmNj7PaJp5vx60gw/XdfCeYx4K /e6m45j3xA80szjYzjr2I9uGm7edF3/6g5JYcb0Y5MDI0i41L+bjheubYvN6QeQvSTtUEyvrm/X9 5rHaN79REHuuvsNMoPaR+sZy7MysukYWqf0bT3NzxT+U1+M/CIBA9wjI9pjE/h+One7JUV9Tqtwt 8RtupzMzCyMF2+vYEfygtVcuiQNPB1W55Twc0XxtNI9TKXVEzYLYUztG6yTFKOCOOWxETUl14HAH V/uoTiV+m+OuhlME/rV5xhn9087DlSuRYdl4VsdOiFFmOzrafDAdFlzectr1DeHhPR/bnRFw9E3w m075JjPojatq+GbNN6k+/WI6f/IiwyNtVnaC3ng6wYvJ57jhenGAeTmi0Of4UaaIWUP9AzEcKI7v 1h07Loc1j5x0O5QCM8LOLhGQ8phEw65LCJFMoggoNlw7fWZFGW3JU6XCzTczsp/sG/zTwWV7NfV3 kA1YOF+3/XyOEaXc5rXqaCD7/rH9ar+49Odtn2b3BfziMKAPss8L+OGUPxMYeNl2frXDNiAf7AIB EGhOQLbHJPb/CJ7MTxtx/cjgUezYoZLOgeC8UUJ9FecAu1McYJeD3ZkfXhab0i/WfhvfXabRX/zG 2ljY2KPld7wBQg1af2+0FnhvepX0rUxIkLsqXeQ8zpp5aCtUKX5MY0aZ3h09QRu1rCh9PktTHGzZ lwCX/9y/1IIDm6fyqCFafd9bjnoibf0zaPdrDsBq5tnqh4O1vvRmmk6+3BRqqyn6z2sreLLCPyR4 rR1MmHNip1jTYMz+Ag3XHru+9SDhPbxTwwWmR6V19E1YBinK3Vql2Tc8ASvN03/Youf+4W3Xhdp0 mqZeHCc6MkbHxifoxOtv0q9+dZImjrhOszcO/3qWXvjni9Z2hnXUqqKjdj9/l6Y+qmkYHo1IqWP2 ZeQEmSdihzQtvKkGHXfOq353kcZ/cdba0Ur7ObxxkYOZ1843L+Jl3mm2SQB0Jzf86pSAlEc27BCs ulOYuD4BBBQbokGfaTzcp/I9g46/NkljvCCHuniHCWnpQpZ3eoLZ8/YIB58/+4m5FETtwzHQeKEP p1eW7VUu6uEcqZ0fevzpIX36oxfItAxTl4q0+Vt24Qd8jF1eZGTqNB8Jt4dtm6HBOQFJW7vs8oXY X/bxBmzD0sZ+EACB9gjI9pbI/r+532t4z0j6G3vpsfSN2GlwS3UlDgudkaN2mo3WMRN03po0Xs7X Oc8sl7WkpDIyhZuuMqS28e/G+TSopPcQYux4icRiO+ntP+qb6OibBZ6maC53XhQ5ZYQdr8Ymgsba yHKWlBg8jfTAwkZY8HVnOXJ20ThvjlX9Mp+X2dn/nXJTyNve+qlKHKBmowUPXNNGSWS7HfDdLj1+ hBGQ9zWJb+zCmGA/CIQTUGyz0FElzmIbqbWaHrb72TZsN1O/q1PxzTLJ9ho2Vck+7i0b228yhk9D m9AOtM9TsZRpXioPpy7h56jnq79Dy1c/qdlxNS38BgEQ6IyAbG9J7P8xFasz2Rnoq6Vgt+PY4TkL 7kCf5rDWohN0d2Ej7NHMMQq08zcbcHHOC3bsZESO5zM3jHXD8W3y12+65jA3yLD5IXNVLB6m2/KK WBwM2pzWgVWxmqPt5xm2keY1BPtZqBjnbesb11B5bu9K/AXfNCgvj8qe2LyyzMHYMyI9I1clcaZf SodP4dB7YW27aK8M50yXOrgu4ybww0TAiialNSc4c/5ucLrWXnuYvpN20NleB1UWwTKDMPV8n5TH JBp2PYeLDGJIQLHNQvtM5xzZrux+1nTszCxzPJrGsQrN+ISb2yVfnBnZXsPikIUfd6bJaovB8dXM m1Wx4/CEO22cunQwFSuEXXj5YyhKqBII9JmAbG9ST/W5OJFmD8dOpLijzUwKdnuOHR57U3QClWpn lpUVqZYaOFOcDt922ARVV3nrTTIInl6y37jQdG0JyqBLE7dPGWnQbISAyUYNILh8yzvTnd+02QFg G4+ciAtn20gLMbTiUs9BqYetb7y8HzlvVE3HzKo1TM9T6nsFa2W6hfpbYM9RjrnDwdeVpWxD2wPH 0kmZDxjm1woOXxE8MaC2HbLUrBoHp9Eb3+IlxwEUln/xijtA/Eo3V+/zQcGORgSkPCbRsGvEBcdA IJiAYsN5dbh9gXOObFd2P8t6lqdC2We2+0O21/YdO06ZrJFAQf3LI3U0ZyuOHRIciqCtz7OXv61s cDIIgEALBGR7lHqqhUticwocO7G5lf6KOKsMcEfWViA41QlQfyjiTnvhethoHTNvd+dKnlUBrNJx 52qOjJFv3dWRPXZgOTOfsKkWZi4P9kRhjZdeZ4dTMTBInpVTPP4ojp1cuYUqPVIeaqXTrH6ZGpxW u/DsxlcLpRiYU2yDM9RIHZiixqIgtr6xg6I71XLelprtf8kXfF2Vz/zdkHHy9lD6xiNmCotyhA+P /lNW48qGOVkON22dVHsw8DpFzSXTHWe3eU6QY6e0rjp1UiKvrPpnkrCCP/Myuzmf09XhhF/dI5Bk w657FJFSkgjYK5sG6HDJQZ5jPzCxnbLAOlHadd4pVvI683/FnJ57KSuWzud8K2c16j/Maxsdr6gh BLgsS2s8ovsR9yO6Lko7OcfZb5WzgWPntqPnA/uLRweiuM0rqPJS7geebqpR+ZqV3zyODwiAQPcI JLn/h2One3I0EClVykVRvMXf29yBLtaXNeeVAnLbvK98ICqHe74OKajgutLB1TrsRqN1zBQ8jh2r A02JZe4Ab+4UuDNfsjv+WnqelQnu5l3HU4vmcuIVa7l0vVIRpVsFsXJG1qdmRCwHvZkJqswQ7avc K9Xun3kPFYNEu7ApSsX6veX7GPbZPOMYWOlLN2vDnQ9vOiOi+L5stvkmKiyvQd8Px040d0g3ZZZl 09E3aVHg7dJd1UHiXRKX2/ftkm3c2/fK0hu8qt5GsWaYm1Vgp3SlXBCZ+jFTf3AA5PDPPbcuIcuZ 3HiUmtpuzPTT/OBRvL0n9kw9et4ZqVPTXcQrc/EqhGr97rmdQxzaXZhTDlavrNrfBTliLiDOT3hl cORZCSTZsHtWZrgueQRsm6NYEFmpo0wdW1RsEdMeMb/KObZjh5Gpox5NHbm0VhAHD9jz8UQXlQfs DPk2J2z9x8d55Qxl5ShdHLDd6ixJrll5H8jug9Ow9LBtz/LxW/5VXR2HvmMDSX3t/h/u2BHqiHKO AZkvss1cObDsz9VF1XHPfZS0P73l05a4/1PK5z3OdTfZ2vVLnsihxiDQcwJJ7v/h2Om5eEWYQYtB gLWWhsuyo0aJjbHUcLSOWccgx05YB8sPfnc9rzs4hb3rWZdzx90Ze9LizrPkWa49QtK9yYrffNnT SCzjx1NnZd+qZzSAXSCe9qI+AHsZNppqYqcRkx+2swAjdnp3R1lmZeBKr6y5jXcuAsumV75XpHGs xK/xp+NpB3ZQ97BquXWXmR6v5Bd2cm1/Pc5W07yVNqjWr3TF7XRulI76QNS4UDjaCYEkG3adcMO1 CSLQhs3h1WmpK2oQe10UzreuA7XFvB3c3v8SsabvpZ0adjxoylZxPcSGZHsxtyZfLjZw7PCtb81B xEua1x1PYeVrVn55PEHShqqCQGQEktz/w7ETmZhFkNGTA9dUJ29HLLdbC+bJK2HZ06aajdYx6+Y4 djLrHBivUuI33QsiZafBnbWWEll+k1NpMC1Mv1cUy/NyKoXngY4fqjKLK6JwO3zESgSUe5dFyw+X jlERWJgHRdfQaHnfM1eSMQVLMoFjR5Lo5X+/E0XKG2lZ35SrSjFnBR6vnaMJOe3KvlfcxrXpsAcE zRrJ43cJ++vnNrZbDITJcXw2L7nfysq6LFwq8FvjvFJ2U5859TvYXm7ZKd3cSe6vD/a0TyDJhl37 tHBFMgnwYhkzfjtL6r1G/4Pihx3cyouMavO5HOEpsXTJHInt0eA82tFcjMKbl+2MDzkeas/o5gjv m6KwXRCFnZs8crRmLx5syCD6jR07PD5UbF6Q57rLlT6TFXkeremqAY82b1j+ZseTKXioNQj0lECS +//nTLKsUGP5Me6s0+jkHLFnn/StWRqJZS17U6nqjU9p/NQ5K/Glbw8o+9ZEk4wMWn9vlOaucejk KyXKz0865z+t/3ze2dX01+Mq7f9wSCPHON/HOtGRcZo4wnewnTSaZhLnEwwq75aJRkfIqBg09sok HT+arBaA9j9c8l3l9k5jEzR2hMvNOqNarZJucNs3jFr7PzbWVoUOv9+l8kOdJl6bosl2ZN+o0uEP Oo0eHSWddc8466AR6J222A/CyeUvT9OJD6/6+6NBKBzKAAIxJmA8PKT9h0QTL7IOrbIuHRtnvd5f +2P3z+/S1O82mHqainqetGbFMfsgtkPNvoieH6mVH/1AjKUWVYsTgST3/3DsxEmSu1aXQ/r0uRfo nJmetkwHxQVq5tbhpy/HsbPGjp0PFMdO18qFhECgdQJw7LTOCmeCQNwIJNmwi9u9RH1AoCMC1V06 PT5FV81E2KatsE3b3muCjnLHxSAAAhETSHL/D8dOxMI2qNlV+Q2Lzm8mRkdGaf/GMk2lP60V9cJN 0s+cbPrG2nhYpos/PmE5g7TzBdr+7ZSVnvm2Y/zoWNPrB5ULyjW8BODYGd57h5KDQKcEkmzYdcoO 14PAcBIwaPevG1TkgTYTx46R8ZhHKxtlOjt7lnbrFeJVQan4e548hQ8IgEBsCSS5/4djJ7Zi3XrF 7Afg0Es0Kjwo0qmjwSeUv+Ih77PWu5DgE+Y3SVzhsKn4gECEBGy5xlTMCKkjKxAYDAJJNuwG4w6g FCAQLQHjzlUOv3A6PFMtS3u3lug4plSFM8IREIgBgST3/3DsxECAO62C/QAcmlATx86X73IsA3Pu csjnDDt2PoNjJ4QOdveIgC3XcOz0iDCSBYHBJZBkw25w7wpKBgI9JGCOzhk9QRe9WWhpWv79AmVm TtIYnDpeOtgGgdgRSHL/H2/Hzvfsvf8Ze++1VdKLGQRPbtB0DQ4SZ5hB4gI+IyM8lapJoDmDA51y iNPAz9gRns2MzjSQDXb2joCB9t87uEgZBAacQPnzt+nER1uUulSizd8i5tuA3y4UDwS6RsCcgmU8 NS3SEbZdzW/XkkZCIAACQ0Agyf1/rB079HCX1r/hlYHGJmn2nzCndgjaIooIAt0jgPbfPZZICQSG jEB1d5u2/vc+Hftpik5pCJU6ZLcPxQUBEAABEACBZyKQ5P4/3o6dZxIHXAQCIAACIAACIAACIAAC IAACIAACIAACw0EAjp3huE8oJQiAAAiAAAiAAAiAAAiAAAiAAAiAAAj4CMCx40OCHSAAAiAAAiAA AiAAAiAAAiAAAiAAAiAwHATg2BmO+4RSggAIgAAIgAAIgAAIgAAIgAAIgAAIgICPABw7PiTYAQIg AAIgAAIgAAIgAAIgAAIgAAIgAALDQQCOneG4TyglCIAACIAACIAACIAACIAACIAACIAACPgIwLHj Q4IdIAACIAACIAACIAACIAACIAACIAACIDAcBOLt2HlcpvW/bJD+epoyb01Gf0eQP/hD/tD++qR/ jDvbdPnaLmkzH9OpV0ci13/IH/whf2h/0D/Qv+h/0P9GbYDA/oD90U/7I2p5d+UnYvwprWcEV5a/ GbH3JPqKIn/wh/yh/fVH/+giN2Oy5+98PnrlJ5A/+EP+0P6gf6B/0f9E3wGj/0X/i/63f/1v9C1e zZHUjbj9Lq1Jx0JaFPXoa4f8wb/m2IH8of1FrX8Uw246x26WqD/I3zYswR/yF3XzUx2rkD/IH+Qv YgLo/9D/1R0r0L8J1L8RqxtPdolx7JSif7IRqmMH+XskL4JN8Hcca5C/CATOk0V/5Q+GJQxLGJaW Yx2GdQINa+g/6D/oP+g/lgHof+h/j20e983EOHYwYiB6UVYfbMEf/KMmkGz5w4MNHmzwYIMHGzzY 4MEOIzajf6+L/hf9L/rf5Pa/UT/tuPOLtWNnT4mxU+pDjB3kL0eMZAT4uxteFFuQv2TLn21YzeSi EDdfHsi/btiBv082otgB+YP8WQ8WaH9RNDdfHmh/aH9ofywD0D8+3RDFjn7rnyjqGJZHTFbFqtLG H5dp59CgkVEn+vz93U/p6jesWszPzAItveIcM3SDpj44R7PaWO14R3+RP/hD/tD++qR/qmW6eP4q HdII6z+pyAza/cNF2qpvpheXyF4XkHWfQRM098kCdUf9IX/wh/yh/UH/QP+i/6kRQP8L+wP2VyLs T6nyBul/mMdnqPaXc/XVr+oecmslLOW3pgUf79bcS+QfzFfeB/AP5gP5687c34S3v9JaOli+6u1P 0xRdKNsk/0+vlbqi5pE/+LNNEyqDkL9gNmh/0D/dUMDQv9C/0L/BOtbkgv4nmA36n+70P93Q4d1O Ix4jdp7yiJk/8YiJKvE7a+fjGrEzvURZjUiXh/nHiQ/O2iN2qt+t09yvczTyspqCPNn7n994vzhH uc9myRrvg/zBH/KH9tcv/VPd5RE7OaoooxWJx+Sob8xSi1nSHO1Hhj5Oc4s8YudoTbftfn6Wzn29 TyNHvLouYPuxQcffydLyPCtU84P8wR/yh/YH/VPTh9Zf6F/0P86IDfS/sD9gf9lP3wNnfyqKOx4/ u+0pGqT02okxUrrS2OvPd9vzRjLVdAl15N96jBPwh/z525i3zanbaH/NApK3PseYAz1Oq2xb+D29 2nS0FfKvc2w6xx78IX8ttDnVBkH7g/5pYmxD/0L/WjYV+p8mLQX9b7L73ybiMYSHYx08uZ1VcRwn TKsGVvOAwMhfOnbSbTjBwL81Bwfkr1lA7mS3v/ZW5cjPtNru2jCWZZotTDlE/uDfmt6D/LX8sIb2 V3sZB/3T1AkG/Qv9C/3bhgy04iyD/h0a/TuEvpuGRY7HVCzWSEGf8pen6cSHV/lQmkp6niabzLKq PqyS/lSn0eftCKRBydbOOTJBY02mLSB/8If8of31R/8YtP7eKM1dYxU2nSN9a9Y1TdWn2J4aVK1W WLeNsv7zHXXtMHXk+NEJGml4HvIHf8gf2h/0D/Qv+h/0v7A/Gj5+wv7qr/3psnCHf+P/AQAA//8g KQqDAABAAElEQVTsvW9oJNe5oP8abJDACxpwwLoksHNJwBqSkDI3C3FYWE/wgtpkwW1kNhqcLz3y ZXGyMCvf+2E0mw+zsj9M5AQmGi471vwCMi3DnZUMXqTA3J+UDxcpMFlay/jSbRgjXZggDYyhGzxQ DTNw9lR3V9Wp6up/UndXd/VTIHX9Pe85zznnPafeOuc9ohK85VczSkT0X1rl7P4nFPnwp/xR/+LR P7bKzjjs9d90VvVf/SEf/pQ/6h/6B/1L+0P72+/3L/of9D/i7H/0u7wH5UnwMFlHB2uuYSGjDp70 P23Ih3/VsEP5o/71W/8YHZu59X4L1/KQ73Ws4E/56zsB6h/1r/Zig/7pe+2j/UP/oH9GWf/EoHIM kc84+/rlM5lb+VDWfrcm9g/Sknltqv9pRD78KX/Uv5j0T/nLHbnxyb5YM+/K+ZfG+q7/kA9/yh/1 D/2D/qX9of3tdweE/gf9jzj7H/0u76a8ZBt2zJSyDwEIQAACEIAABCAAAQhAAAIQgAAEEkYAw07C MpTkQAACEIAABCAAAQhAAAIQgAAEIDA6BDDsjE5ek1IIQAACEIAABCAAAQhAAAIQgAAEEkYAw07C MpTkQAACEIAABCAAAQhAAAIQgAAEIDA6BDDsjE5ek1IIQAACEIAABCAAAQhAAAIQgAAEEkYAw07C MpTkQAACEIAABCAAAQhAAAIQgAAEIDA6BDDsjE5ek1IIQAACEIAABCAAAQhAAAIQgAAEEkYAw07C MpTkQAACEIAABCAAAQhAAAIQgAAEIDA6BDDsjE5ek1IIQAACEIAABCAAAQhAAAIQgAAEEkYg2Yad p2UpPS7LxPMTIs8mLOdIDgQgAAEIDC6Bsm5/yiITE2PxxBH58fKPJ9eRCgEIQAACEBhtAnH3f2Kk n2jDTvnzWzL+/YsilzZF/SYVI2ZEQwACEIDAKBEofPS6nHtnS+Y3DmTpjbN9Tzry4+Xf9wxHIAQg AAEIQAACEnf/J84sSLZh54s1GZ+6IDKdFXtrVmL6bhpn/iIbAhCAAARiIFD4+KKc+/ktSd/My/rc VN9jgPx4+fc9wxEIAQhAAAIQgIDE3f+JMwsw7MRJH9kQgAAEIJBIAnF3LJCPYSeRFYtEQQACEIAA BJoQiLv/0yRqPb+EYafniBEAAQicisDjQ9n4ZEeKbiDab8nZ//CmnP+e9p3VaHtcksLhoehptpVt 4uyUnH2BMXuNcHG++wTi7lggH8NO90s1IUIAAhCAAAQGm0Dc/Z846WDYiZM+siEAgZYEyp/f0L6y fhG4L3U9J5u/tALnKgdf7cuNy1fkFx9t1V2zLq3I+gcZOYt9p44NJ7pPIO6OxTDLL/2lIPn7x+LY Zc9MTMqL3zorkxNlKRSOZewbZ+Xsi60rcdzp736JIkQIQAACEIAABFoRGOn2XyV4swtZpTNfaR87 yk5wOknaaBPI3UxXy7lT1hv8WVZKZS4tqu3c0fDBOt5VC3MZlZlLK23KqaRR+y2pT8fXOZVukH6f y5IaQgL1aeXMwBPIr2Yal1Uv9kW1PN243rrlduVu0Xui3Z325Ct19NlCQ73hyhfLUmmtPzbvHrQr XrUr3wyweG9TZaxWPObV0RPzqej9k8iPDomzEBhwAk+O1GLDepNRuSbq4+jOYuv6X9euptT2I4PJ o22llydpM5zQs0Yw7EIAAhDoBoFRbv+lGwAHNQwMO4OaM8SrmwTW59rtUFXvy6xGGEW6GaEehpWd qaYh0rBzv2bI1R3M9NWsyj+qmnPtB7tq3uh06lWKehhDgoZAlUBbHYsn+TaMkaJSUYbMFqDbkq/D yN9MtflCVtMz1qI6aONLSbvy3WQcbMyH4mGp1HRU3NIq1wP5bjz4hcDQEbBzkYYVq2bs0SNcGyap 4/pfa0tX7vmV0C6shOpu8z6J+WzDiHEBAhCAwAkJdNr/OKGYgXwMw85AZguRgkAHBJ4U1dGDI5W/ s1TrXKXU5r0jfe6g8pe/t6tWrgZH9WTv+52yDiTFfKutmhp2dOyK9/PqqGbQCUT2wbrX8Yw0CgVu 5gACpyfQbsei+CCvcndz+m9bLbijd6wFtV0555zPq2IbI1TCMW5Xvvr6qCp/J+u/HE4vqVzOka3/ 9ra1/qiOPvJG8MyttxwF27Z8J+LawJXxjK+Wyu4ZxtcntspvmKMK0irfhvrqSH4YHscQGDICTtu3 69TXOyEjS8W4M68OGukQu6jyTl036//Vdb/+e3ooeE/YOHN0L6d29/Q9lfsNXabr9bobxt6uyum+ CRsEIACBXhIY5fYfHzu6p8oGgUQQ+GJNnpm6oJOSlvyTdZl6Npiq4396X/7qP16pnNQjAGQzagnm x8ey8783ZOvTLdn58ljfOymT356UV/79eZl6oShbH98SmV6WlV++4gV++McNfW9Zxg23F7aMyStv pGXqeX2b4/z40z9V/GV4D+mdwD3GhfJXBdn7530p/KUoY2NjMv7CWbF+9IpMab8aa289Ixdu6xR2 uoT004JcfO6c6Nh3/qwRN3Yh0C6Bk8zxdsu3zGRF/eNsu6Ii7+tYvllHVvUS7W+Hlmj/ak/e/MaP ZaMiLSU5e1Mso86HI9GJ/NKfb8iZf1f1o7W4U5SFV+sdo+//7nV5+b86vrPSWvZ6U9lOXDqRH447 xxAYVgLl/Vsy/vJFHf2ULFyelPc/cFo9kaW9osz/qL5eVS46/4z6ny0omX3Ju+LvGPdow45kvtdY AXRTl/kRGMC9p7rPdPuPcvhUZNyI3tSrabG+qflE9H9s7Tzs5enadeMZdiEAge4QGOn2v5cWs7jD ZipW3DmA/H4S8Mq7NPiibXwVjxq1Yt/zpzJp1eqNcKnbn17xv9brMBv5tUmvVad82feWG4a1FJhT UVSb14Iji0zZ6atLar42tDwq/s1Y2zk/bZlavJrdzzUInJZA51+M/BFp3fAL17H8FvrB4ZE3/Hll jakYUaw6ke+Hm1K5r6NC0+c8H1oLjUcfGI92It94jF0IDDUBb2r2jPYtadRpbSz22+2oFBr3mqNx ivfW1cIlPYLP8aljtPfLgbY7HGB3dVk49MDxg02Vnk6rlPYDZrX5p41eavNBIJQTHzTs32jfns6W v25F93+uNZ4ed+LI8CAEIFAhMMrtP1OxqAQQSAiBload+/50pHqfHdr5omHMWbi5qfJ6etdBIac2 b4acq4acke/q66mA48aUSs8tVjuCDttHObV4aT7kFLV2j+fUsT0nsq6hpy3Djp7C4UxH292oTlGr +huwgk4fE5L3JGPwCHTesejuy1DH8o0Xu0b1K3/d93ljvvxF0e9Evp3zjb+pq9vNX0CjhEWc60R+ xOOcgsDwESjuetMpFz6rTnnavebWWd32HTdJklH/9Ygdb8uvVj+2LFcMuUWVvZRS1vR8U4fMStdg d9p0N4zUXmQidux7oalnRj/G7S9E/TY3TEUIanSqsriDv7CDKyt7r9q5sY9zAR9/ItoR/cy82iy0 MZ+0kUzOQwACTQmMcvuPYadp0eAiBIaHgGnYCXxM0waOg7vrgZE1erpDMGG2P/Ims2b4t3DverTr +8AwR+y413WH0l2xSmRRhUKv3FXcc30AiVoKrfLjdh6rnaK0WjdX77KP1HrIR1CjF083OkqvErIQ 0cELrOTh3cwOBLpPoPOORXdfhjqWb7zYRdevolqpOS93vnjvRlVyA2NH8vWqOr7+cEYLptTizaza vLOtfXJov1nHRT36wAi8jd2O5LcRHrdAYNAJ+A7ItYNxd+Sb4V+umRNl089VShseFi4vVP4yNb9f rQy5QTbd1WXBsENHun+wuZZV6xvrbf9l1zbVgcsnFNyJD4+3A32spc9q/agnB2rR9Z2mjTqbQ+nf 8MRUeBACsRAY5fYfw04sRQ6hEOg+Ad+w02QalWPsmIsYkm0YdlJXN6OdtX6dV0tzKTV/fTcy8tuX /SHHyyHDjXZrrJa8UT1LQcOP8ULpvNA1Mr74Xx71qlctVwkKjkByv6JZcyttLZUcmUBOQqADAp13 LLr7MtSxfKMepp1VdBxDivNn65Fv97bVomfU0Tqk1bQO/Vin8o885++N9dfCze1o3RSRL53KjwiC UxAYIgJ61Kvbxl7eNuJt6BVp4kTZqP9ue2n+Dqxhx0hp7Lv6A5g5NX3+elYtuHmi+17rjNKJPYuI wGgQGOX2H+fJuuVig0ASCJS18+TxivPkxqlZXMvJ/M8s7do4tGkHgFee+yt53zxtpST9N5NyRibk xW+ckbPftapOlB2HgFHbXzbkmW+9Wb0yty7qpu7i1DbfoaOIHiIuiz+ddC+JfKmdPn/HcfqsBylf 25Xc3/mOmf2b9N7jPXn93/xYKu5T23Ge/LQs5cdlOT7MyY3MT+TD/Vpol7ZF/eZ8IGgOINBtAp07 7ytr5+DjFefgevqC2Fuz9fVUR7L81aEUHpTl7PemZCLkIN1MQ8fyDceoZjj1+5ZsPshJ6pv1V8wz Hct3HtaO09d+n5XsJ+/LlltfzUCdfWtJju7Oy2STtDu3nUi+8yAbBIaRgNGOpldzcuunZ8V+asv4 s+OS/+i8/PjvqxWqoRNlo/4vrO3Khe+eEXlO16Pb78mbv9oSbdhp6iw5iKw9XRZ85oRH5UO92MOf pNTR4xPyo5+m5KyzuEO3t9K+XDzzcmWhBj9oS7L39mS2ibNp/172IACB0xIY6fY/ybY7bwRDyCdI ktNM2kaXgFfe9ZehrJ7K5PiX2V41/eM0n2NvF3wfPFqpRjv80+etS42WOja/DJq+bMzz9V8MzXgv 3Gm2FOqRN+qn9YidUDnQU7MWvS9n2rl0h9M6QqFxCIGWBDr/YmTUk4Ztlq1WauU4tVp1Tt4oIh3L b/HFXqy0Wlrr44gZPVKoeHxUWYp5PeTna36jmZ6oEuk4/Y1Ach4CQ0Ag5/nSadx2V9r1RqPtjPof 8LFzs+qjpzOfNO3osu5Ajd3HTlQyjOlvVebmCKqoBzgHAQh0k8Aot/9MxepmSSIsCMRIwDeQZAKG i/zavGGkWVRNX4meFFXuMz18+FJGO/jTK01MayfH+i/o/0JUIwOMnfMdGXrGF6OTk454GfXjLSqz EeHfx2VqdDy9sN1rbfz6K+/oIdHMc2+DGLechkDnHYt2Xob8e1rVgY7lG/VLLm1qnzbasFIsquIj 7d/mBH4+O5GfW1tSmTntULRZvdTO3109ZAWmmkTnUifyo0PgLASGhIBZd5t8lKl+sGnwgccIIzDt 6usjlcvl254CWSXm66leO09WelWslPPBqc0VsZz7urkqVl0J0R+RljyfOr6RbZ7VOOtQcQICvSIw yu0/hp1elSrChUCfCfgGkvBy5/orv9HRSN+MWGaz1hmxovzv1NJxYPjAqF9Vy02sMc9fFiq+dHav ur53GixlbKzW1cx3R6TRyBXbxq+r6J3ObZa57m0Q45bTEHDLWysDjC+jnZch/55W4XYs33ixizLA +vFsb699+TpNrn5qOFLJkWn46Ypy4B6KVvvyQw9yCIEhI2AuTOC1ba6PrNroVPte1vvAE+lE2aj/ AcPOiVj4eqrnhp0Txa9HD+l+1LKry3Q/Y0k7dTZ97GRWI/pePYoKwUJglAmMcvuPYWeUSz5pTxaB +27HLThip5LI0Koz6w9CSTecJ883GjWjO36uY8DGhh39+rWz6HUglzay3mpa1tVop8tKjyEyV7Ca X4vo/Ogl0zPGl8iol9qjXK7xl0WdPv/5sOErxIJDCHSBwEk6Ft4SwXq6RKPNvSeqDpjPdCzfeLHr u2HHcMzsvZiaiXH2DR2WuhahI0L3d5z+0PMcQmBYCKzP1UaGNDV4mh946qdEm6timVOxTsrA1VPO x5rR2EJGHXdaue57BIw7UR/WRgMQqYRA3wiMcvuPYadvxQxBEOgRgaIeKn03p7bXfH86y3dyKn/v ILBEsL8Uqu4ETi+qbT28+shdstgw7DgjWjLX1lX+WM+/cL/2Pcqr5Tl35E3jqViVFOrlPecdI4zn 08bpdDYY/l1DcvSZH/fqnHQdv7t5dXA/r/0E+Yai6lByZ1WsbX3tyE+fnasMx65et9Ti6rbKP9BT SL4u1i317kwzYYNArwm027EoPshX6m8up1eeMr72bur66dTrwJ9xT9cMO85UC0fOXtarQ6nLWb3M uCs779ezDqC1m3697JbyXgIrxtu0Wr9r1G0t01mVyzfMimpnREH78jtIFLdCYJAIOG3/Ttaboiiy VKm3TttnbvajA/3RI6eyl6v+cpx2cl63kQdOG2/r6deh+r+gfWk591fO32s6edsTc+TpC/2coafE WtB9DVeX6N82w/MCHvQdzS+f29X9o5pxraLDVgIrf5ojqhz26et6ufVHJ5jfOugsiB8EBoTAKLf/ GHYGpBASDQicjIAxjaHSoTA7F6KCDg+LgSlZTgfDcpY1djb9tb5ijIkIo2osMcNdaLlkeH4t443a qTw/18qYYqtNY7n0epm+fNfPhnOPlz49BNoc9dP4+YzKfV1NMv8h0EsCbXUsdL1z/EM0Lq+NrzUb Neekqy35zn0156jN4nCSETztyq8YdgyDlhkPx8eXWd8r1xo5fw1lZvvyQw9yCIGhIKDb/sDHE1NX 6GnPnt2g2X3Lar9l/beMsKLB2AXft55Zfxvtt2OYjZY0eGcb6U+vb+WNpDbzx9lf1iZtNghAoBcE Rrn9x7DTixJFmBDoIwFXgdV3olJqMzzlqpgLGHC8aVf6BdOdZiVWxMtU7eXTGclz1E5vJDQCqOH0 ihCn/GfL9S9yWnbq0ooegZMLDGl2RgEF0vf1gcpeDRmUjJfm9NVse3EPxYlDCJyEgFsvm4+s0cZW YxpSfR0Ovwz4x8t7wa/y4Ti2J1+PhgmPljPqjBuflbvNZYVlO8ftynfu9f1w6fQ1fFm11NJGru2X oU7kO3Fgg8CwEdi9no42Ck8vBz6+bBojddw67fw6K1we7ixFh+HpgfnAYgyRjB7t+v0H7zlfV5ky RdJq91FkKEN5spH+XHSnYn0d/dEsdZWVsoYyw4n0UBAY5fb/GSeHtNJN5Fb+Yk3Gpy6Idt4m9tas jCUylSQKAt0hUH54LMVnz8jkC9WaUi6VpPjY1oGX9d+YnHlxUsaebV9W+WFBcoVjGZ98WayXJtp/ 8GlZjv/1WGTijBZty/gLkzLRSeWtPH8oD4tOvPX27Jic/c6UTDxfPeQ/BPpBoPDxRTn381uiDTuy PjfVD5EBGUMl/+G+rP1TQSZeelVSP5yU0sNDOXxQEvupXdE+Z86clalvd6Z/4k5/IDM4gAAEIAAB CECgLwRGuf3HsNOXIoYQCEAAAhAYJQJxdyyQH69hbZTKOmmFAAQgAAEIDAqBuPs/cXLAsBMnfWRD AAIQgEAiCcTdsUA+hp1EViwSBQEIQAACEGhCIO7+T5Oo9fwShp2eI0YABCAAAQiMGoG4OxbIx7Az anWO9EIAAhCAAATi7v/EmQMYduKkj2wIQAACEEgkgbg7FsjHsJPIikWiIAABCEAAAk0IxN3/aRK1 nl9KtmHn81sy/v2LevGcFbFzGZwn97w4IQACEIAABBwChY9el3PvbEnqel42fxmD82Tkx8qfWgAB CEAAAhCAQP8JxN3/6n+KfYmJNuzIV3qljT8U9Oo6UzL7U8tPNXsQgAAEIACBHhIo7e/I1r88lBe/ m5LzVgerwnUpTsiPl3+XspFgIAABCEAAAhDogEDc/Z8Ootr1W5Nt2Ok6LgKEAAQgAAEIQAACEIAA BCAAAQhAAAKDQwDDzuDkBTGBAAQgAAEIQAACEIAABCAAAQhAAAIdEcCw0xEuboYABCAAAQhAAAIQ gAAEIAABCEAAAoNDAMPO4OQFMYEABCAAAQhAAAIQgAAEIAABCEAAAh0RwLDTES5uhgAEIAABCEAA AhCAAAQgAAEIQAACg0MAw87g5AUxgQAEIAABCEAAAhCAAAQgAAEIQAACHRHAsNMRLm6GAAQgAAEI QAACEIAABCAAAQhAAAKDQyDZhp3HBVn7hw2xf5CWzGtT/aeOfPhT/qh/Memf8hc7cuP2vlgz78r5 l8b6rv+QD3/KH/UP/YP+pf2h/e13B4T+B/2POPsf/S7vAXkqwVt+LaN0YvVfRh086X9CkQ9/yh/1 Lx79Y6vsjMNe/82t91/5KeTDn/JH/UP/oH9pf/rfANP+0v7S/sbX/va/xpsSxTxI2n5+1TUspFXO 7n/qkA//qmGH8kf967f+MTp201ltZun3hnyvYwl/yl+/q59pWKX8Uf4of30mQPtH+1czrKB/R1D/ 9lndhMSNjGEn3/83G2UadpAfKnl9OIS/b1ij/PWhwIVExFv+6FjSsaRjWTGs07EewY41+g/9h/5D /+kygP5H/4f65kk/HBnDDiMG+l+UzRdb+MO/3wRGu/zxYsOLDS82vNjwYsOLHSM2+/9dl/aX9pf2 d3Tb336/7QTlJdqwc2D42MnH4GMH+e6IkYyCf7Di9eOI8jfa5c/rWM1k+1Hc6mQgv9axg39d2ejH Ccof5a/yYkH960d1q5NB/aP+Uf90GUD/1OmGfpyIW//0I42NZCRkVaySbPx6SfaOyzI27nuff7j/ vtz6g1YtzjYzLwvf8a+V7bK8/PYVmbUmqtdP9R/58Kf8Uf9i0j+lgnx49ZYcy5jWf64iK8v+Bx/K Vu0wfXlBvHUBte4ry6Rc+NW8dEf9IR/+lD/qH/oH/Uv7UyVA+0v/g/7XSPQ/XZU3SL+NLD5Ddb6Q ra1+VbOQV1bCMvYtK/p6t+ZeIj+ar5sP8I/mQ/nrztzfEa9/+dV0dPmq1T/LMnShWyf1b3o13xU1 j3z46z5NwzJI+YtmQ/1D/3RDAaN/0b/o32gd63Ch/YlmQ/vTnfanGzq822EkY8TOUz1i5rd6xERJ 9DdrfwuM2JlekEVLxHYv651zb7/njdgp/XlNLvxtVsa+bYbg3hz+1V+8v3lBsr+Zlcp4H+TDn/JH /YtL/5T29YidrBSN0Yqix+SYX8xSlxfF8rWflO0zcuGyHrHzQlW37X/0nlz59FDGng/ruojjx2U5 +8aiLM1phepsyIc/5Y/6h/6p6sPKf/Qv7Y8/YoP2l/4H/S/v7Xvg+p+G4k7GbrctRYMUXic+RvI3 m1v9dW6HvkimWi6hjvz2fZzAn/JXX8fCdc48pv61ckje/hxj7ehx2mTbxv70SsvRVsivcWw5xx7+ lL826pzZB6H+oX9adLbRv+jfSp+K9qdFTaH9He32t0XxGMLLiXae3MmqOL4Rpt0OVmuHwMh3DTvp Doxg8G/PwEH5a+WQe7TrX2ercqzPtFvvOugsu2G2MeUQ+fBvT+9R/tp+WaP+VT/GoX9aGsHQv+hf 9G8HZaAdYxn6d2j07xDabppGORlTsbRGitoKH1+Ucz+/pS+lJW+vy1SLWValr0piP7Vl/FnPA2lU sNV7np+UiRbTFpAPf8of9S8e/VOWtbfG5cJtrcKms2JvzQamqdYptqdlKZWKWreNa/1XdzVwwtGR Z16YlLGm9yEf/pQ/6h/6B/1L+0P7S/+j6esn/a94+5+BHm4CDpqafYb8Yidf7HuRVOS3P2IH/t0n QPkb5fLX2Yid7pc+5HtTIdoYMQD/bhOg/FH+al/gqX8tR+x0u/YpLZHyR/nTr8hKGzYpf92vYC1C pP7Fq39aZE+PLyd6KpY/vSqjDp70mGRE8Mh3X6zhT/mLqCA9PjXa9c9o2OfWe0w6Knjkex0L+EcV kB6fo/xR/mov1tS/Hte1qOCpf9Q/6l/FsIX+iVIQPT4Xt/7pcfJaBJ/oqVhSPpS1362J/YO0ZF6b 6v/4KuTDn/JH/YtJ/5S/3JEbn+yLNfOunH+p6UDgnuhG5MOf8kf9Q/+gf2l/aH970sloEij9D/of cfY/mhTNnl9KtmGn5/gQAAEIQAACEIAABCAAAQhAAAIQgAAE4iOAYSc+9kiGAAQgAAEIQAACEIAA BCAAAQhAAAKnIoBh51T4eBgCEIAABCAAAQhAAAIQgAAEIAABCMRHAMNOfOyRDAEIQAACEIAABCAA AQhAAAIQgAAETkUAw86p8PEwBCAAAQhAAAIQgAAEIAABCEAAAhCIjwCGnfjYIxkCEIAABCAAAQhA AAIQgAAEIAABCJyKAIadU+HjYQhAAAIQgAAEIAABCEAAAhCAAAQgEB8BDDvxsUcyBCAAAQhAAAIQ gAAEIAABCEAAAhA4FQEMO6fCx8MQgAAEIAABCEAAAhCAAAQgAAEIQCA+Ask27DwtS+lxWSaenxB5 Nj7ISIYABCAAAQhAAAIQgAAEIAABCECghwTK+v2/LDIxMdZDIYMZdKINO+XPb8n49y+KXNoU9ZvU YOYAsYIABCAAAQhAAAIQgAAEIAABCEDgVAQKH70u597ZkvmNA1l64+ypwhq2h5Nt2PliTcanLohM Z8XempXRs9sNW3EkvhCAAAQgAAEIQAACEIAABCAAgc4JFD6+KOd+fkvSN/OyPjfVeQBD/ASGnSHO PKIOAQhAAAIQgAAEIAABCEAAAhCAgAiGnYSWgjIjdhKasyQLAhCAAAQgAIFBJlB6eCjHpTGZemly kKNJ3CAAAQhAIEEEMOwkKDPNpGDYMWmwDwEIQAACEIAABHpE4HFJ9v+8J3v//47c+uBD2a+ISUnO 3hSLufA9gk6wEIAABCBgEsCwY9JI0D6GnQRlJkmBAAQgMHAESnLrrTNy8XbziFnTaTn/ozflwlxa rBd5w21Oa7iulve1L7+XtS+/8HZpXS/akJadhZflJx9UTRzmLdl7tsx+L0Fl4WlB3nzunGyYiazs pyVvr8tUgpJal0ROQAACEIDAwBDAsDMwWdHdiGDY6S5PQoMABCAAAYPA00N577m/lg+NU612E/dC 3yrBCb9++OlF+ev0rfpUWiuichm59fIzcrHeriPptQNZ/1mCVuvQhp2L2rDjkEjNLYr1lyvy/h8c LBh26gsHZyAAAQhAoFcEMOz0imzM4WLYiTkDEA8BCEAg6QRKJTku2xVnfT/5+y29CuOS5G/OykS5 XEl56VFBNn57Ra7cdt/u5yX/ZEmmnk06mBFJ39OyFD7fk2zmJ/J+JYsXZTeXkslvTcnZF8akrP3M FI5LUvhfV+TCB7p8WAuy/T8vyCvWlIwlrQw8reW5k66/bMgz33pT72DYGZGaQDIhAAEIDAQBDDsD kQ3djwSGne4zJUQIQAACEKgn4HYkZCYr9j/OSnjmyc7/eF1+8iv9Yq+3FT0NJ9NgGs7hnzZk7fdZ Wf8/h1Uh2lgwOXNeT+O6IOnXrLpwqzf5/zt+vnwsW7f/KCUnCG2gGvvueUn/8Izs/P6G3Ph0Tw4f Hou8eFbe/Nm7Mv/2+RbytZHjjxuS/WRdtmrxn9TPWq++KW++8arI5xs6XSV5+T+/K+nvTfiRru2V vyrIzh92ZO+fd2T/L2U5dmTrbfJvUpKZ08/8sN4J7/Gft2Tr/5ZkXAO3tS3tlZ/NytTzOh7a18v+ F4f6nGNgOyNnf2DJKz/UxpRKiN3/t/bWM3JBT8nLrOZl5e365VUPP9Eje2b1eBZdPpQuH9Gbjvef tmTj9pbsfVFNu3Pf5EuvSGomLakf1cd/UNIfTo/X/8KwE0bDMQQgAAEI9JCA2x8bxeXORSV4swtZ pcuNkumsshOcTpIGAQhAAALxEsivZpq3N/dr7ZFuk7Rhpz6yj3JqwdLtldNmNfzLqO0HEc86oZ3w efvechN5obhYS+roSX3UK2eOd9V8y/hXw0tdz9UFUtxZahkP6+p26DlbrYRkpq4uqUxDfmm1WWjA LxRyZ4e2ys5U06Y7kpGPtiof9v3tJvF280Hn/30z/oOS/voke/0vSau8GeX6WzkDAQhAAAIQ6BoB t71t1B53TdAABoRhZwAzhShBAAIQgMBwEXA7Eo0+JBxsLHiGizrDTjGnUgFjREotrW6qXC6ntj9b UenQte1HITaneV4bhBYvZVQqZCDRc4bU/KW0EivlxdsxOGXWIgwXj7aVFYijqNTcglq6vqTmZ6zA 804YUZ2t/HVTjqUWrmfV9s62yl6rGcxq4WdDhpnc6qLKzJjPukaQ6q9Vly5Ry3eLIYCnPTQMO6sR fHTwB2tNDH/310OMqvm/u7erNleXQmVD1Lph3BmM9Nfzw7BTz4QzEIAABCDQewJufyyqr9F76fFK wLATL3+kQwACEIBAAgi4HYk6w45dVLkNczSKpYKGGVutz/nGiNTVTVWsGxVjq+1r2sjiGk/mzFGo p32+Ct8zPDgyppfUgTHKwr6/6RtupldCI2B9o0Ylftaiyh0bD+vg7cJmwDgR2dl6lFfZm9qYc/eg rjTYuRUv7amoETFP8qHRLimVvXvkhWPrsJfnTANTRuXrGHu3n2DHZ2DNLKrsalat3Fzx/pzjRdfA VTeCuKiWDOOTdXm9Pv+fFNX6ZSP+zsgpM5axp9+MTHUfw049E85AAAIQgEDvCbj9sci+Ru/FxyoB w06s+BEOAQhAAAJJIOB2JDzji2uECf3WjXgpGqNd9At747EkR2rBCyutcq7t5LTP1+D78U+p7YhI bF+tGRZmTKOSftiYYiYy39Bg4r/o69E8UcYZtxBoQ1j+7m5ltM72zq7K3c2rowc5b9RSZEfNNg07 KbUbHtFUCVsbwC75BrS6fHDln+jXN+y0yv86w587ZdzJW2u5Sf4X1fK0H//AqK/Y018Pzc9vpmLV 0+EMBCAAAQj0ioDbn4nsL/RK6ICE+4wTD90RSeTmOe+b1s4st+qdWSYy0SQKAhCAAAT6TsB11tdY cEqyd1dkNuQAuPz5LRn//kXvsYVri9qJsci4d0bv6OOxMb20+q/8ZbWz922Z/bZedemUz7tivPg3 aC8bXS/v6/i/XI3/wp0jWXyt3sGxK2P/kyuS+fW+ZD5ckXdfDd5X/nJPblz7hbz3kbt6mPtU8Fd3 1GR9LuSc2FhqO30zp6/riWFRW2lPXj/zY3FcWKeu7crm370SddcJzpVl7a3xivNkHbIsXNXyHZ/N xvZw/3255Sz/HeJ7+Ml72qnyh5U7l3O2vGs1du9s5rU2TMnKz2ocYk+/kdDartf/wnlyPRzOQAAC EIBAzwi4/ZXI/kLPpA5IwANiYOpJNLwvRnVDn3sijkAhAAEIQGBECbhfiJxRK7kHR+rofk5lLxnT Z2QxOH2mxslrp7zROP6oDN1N8KYghfddXzOnfd7NLi/+4RE5tRu866H2NH/TnyLmxskNs+3fB5t1 6bSm09rHT0alp02G0f55lDEVqWkcjPukbkpZ27GNuNEfsZPu0MeOx1Xn9WIL3z/2XX9KX+BLpJGu eNJfj8Qvl4zYqafDGQhAAAIQ6BUBt10NtJO9EjZg4TJiZ0AMbEQDAhCAAASGl4D7hSi43LkeyfGO HsnxUTVdelUnyf3384FE+iMb9OmZJdl8+6yUnwZuCRyU9fLdEy9acv7V6tLXp33eDdyLf2hESavr x398X/7q/JXKbc2WcXfDifrd+m/PyOu/rV5JX9uU5f+SksnnjTufluTWfzojF/WIl8gvcMaIlcWd oiy8Wr+UeiU0477wyBlD2gl2/RE7kfHTITbiW/joTTn3zkZFpjbKyOxLjUfsyBdr8szUhcq9ejqb bLojl4x0xZP+emR+uUxL3l6XqSbJqn+aMxCAAAQgAIGTEXDb20bt8clCHZKnBszQ1NXoeF+MQl8Y uyqEwCAAAQhAYOQJuF+I6nyofO37h9HdArXiOcepIvPaKX0tahnwVmBP+7wbfsP4125odN2UL5c2 3eCif7UT4Py9vCq6/oGcu54cKT35rDpip+Hz/j2RX+CMESt1/I2YFHcWvZFBJ2FtBBXaNUbsNPAf 1Ihf8a6/3HyrOOWu+6OjlszRPbGnP4RDH/rlYvhG7BzsrBjOvlNqZSfgqro+saEzcT8fig6HEIAA BEaKgNveRvYXEk4C58kJz2CSBwEIQAACvSfgrSqlpzKFN9OgILKgDswVmfRL+bxr2NC/zabSFJ3p XdcX1cLVrL9y0mmfr0W2WfydWxpeD8lfvFO/qpXzfPHeuveybF03lgQ3jRIR7JQ2Bm1e9Zczj5zq ZIahGaav7zoiA1ux4Mt3DGxLOxEeogNPdHaQnakapyLjp4NqyK+463GpGv6i41XMZT2jlPbjo3bN 2wYg/XW0PKfa3V6BrE5Sd0/o/NAekgzWzr4V5N1MYtzPN4sb1yAAAQiMAAEMOwnNZO+LESN2EprD JAsCEIBAvATsB3mVy2mDy2XX+JBW2/o4f9988w4vSZ5VOWfkSs3Ac7AxH3iRXFjdVkeP9LCWJ7Yq PjpSuTtZNW+siOS8aJoDf073vK2OCjm1XDNMOGFv5vRKVG70dRwO7pnp09edlaq+9rkf3fFHwjjG idRlnb77R6pYLOpnd9WKx6b6whxcFcsf7eI8m649e3Q/r7bXlgNGD+e65VzX7A4cPu4WMmw494k1 r7KfbavdnW21fNkf6VK51s0+geaTz22rBTd/ZpZ1/HT+15Z8tx8dhMqHw/dA2YZxz+2EVuKm4z5/ Xee/HtZk2/qveKS2rwfLR53xKM70u3mgdDnS6c7d1X+6/G+vLXhlevEzzUOfc67lHxj55j07QDsR /p6cfNGOrduLZNzPtxdL7oIABCCQWAJum8qInYRlMYadhGUoyYEABCAwSAT0C3XaMSJE/gWNL0pP yUqF7vNfFm21bYxKiQ7Pl2NdXg8ti33y5+17K5Hxt67nKqQbXQ9PecrdzESGE06LdckYbVTLy+Ke 7xQ4fH/DY2tFmxJqW5RhI8TaC2d6SR14D7oBnPw3vxoyGnlyVyqBZi0/37w46HsyG+bIJp1/1xqF E3w+dXXbT7cb7RjT70ahYTnxeLjp0FOzDKOW+/zA/D7ajizHm8dtxjDu59uMJrdBAAIQSCoBDDsJ zVkMOwnNWJIFAQhAYCAI6NEmc+4La+jXWgxOudLxdabT+NM8LLV+P2hhOLq7rjINDAHO9JuF63q0 SpMRDyd6Xo8w8OPkp2HeNTw0uJ65WTX8mNlQLBgjV0Iv9Km5RT2SqbGvEscvSVQ8UnNLKqdHvxzt BI0/qcvbvmjDsOFMZSve21ZLl9KB8KzpjMreMaaA+U+fas++Z06R8vlZl6v+hjZDo5Vc4072XjDv nUgUc5t1I7Pc+2V6Xo/0acAvxvR78BqUEy/+bnmYWQkZJb0QBmYnb4w2cuKfuVk/ta9ZZON+vlnc uAYBCEAg6QRG2bDDqli61WaDAAQgAAEIDAqB8lfHcviVyOQ3x8Uu2TI+cUYmnm9/WaHTPn9aDuXS sRw/FDlTi/+ZFyZlrJ3oPy3r546lVBZ9/5g4z0209VxBLj53Tm7piNetzOWuMPbsaVPVv+er/Mpy 5t9Oiv2vxyIvTspkMxDGqlhJSH//SDeRpFefK+m/sbGJ9spuOKi4nw/Hh2MIQAACI0JglFfFwrAz IoWcZEIAAhCAAAQSScAwbLRcMjyJAEY9/UnMU9IEAQhAAAInIoBh50TYBv+h8hdrMj51QbQvALG3 ZqWdD3+DnypiCAEIQAACEIBAhYAekVP6ckvOT70u+/rE4p28vPtDPdLlqS3ydFwmX5xINqhRT3+y c5fUQQACEIBAhwQw7HQIbFhux7AzLDlFPCEAAQhAAAKdEijL2lvjcuF24+e0ryBZeuNs4xuG+sqo p3+oM4/IQwACEIBADwhg2OkB1EEIEsPOIOQCcYAABCAAAQj0gsCoGzZGPf29KFOECQEIQAACw0wA w84w516TuJc/vyXj378oYq2IncswFasJKy5BAAIQgAAEho6Adrhceqy9LUduYzLRzOlw5DNDdnLU 0z9k2UV0IQABCECgtwQKH70u597ZktT1vGz+cqq3wgYs9EQ7T5av9mXtDwWRiSmZ/aleSJUNAhCA AAQgAAEIQAACEIAABCAAgcQRKO3vyNa/PJQXv5uS81bC/eyFci/Zhp1QYjmEAAQgAAEIQAACEIAA BCAAAQhAAAJJIoBhJ0m5SVogAAEIQAACEIAABCAAAQhAAAIQGCkCGHZGKrtJLAQgAAEIQAACEIAA BCAAAQhAAAJJIoBhJ0m5SVogAAEIQAACEIAABCAAAQhAAAIQGCkCGHZGKrtJLAQgAAEIQAACEIAA BCAAAQhAAAJJIoBhJ0m5SVogAAEIQAACEIAABCAAAQhAAAIQGCkCGHZGKrtJLAQgAAEIQAACEIAA BCAAAQhAAAJJIpBsw87jgqz9w4bYP0hL5rWp/ucb8uFP+aP+xaR/yl/syI3b+2LNvCvnXxrru/5D Pvwpf9Q/9A/6l/aH9rffHRD6H/Q/4ux/9Lu8B+SpBG/5tYzSidV/GXXwpP8JRT78KX/Uv3j0j62y Mw57/Te33n/lp5APf8of9Q/9g/6l/el/A0z7S/tL+xtf+9v/Gm9KFPMgafv5VdewkFY5u/+pQz78 q4Ydyh/1r9/6x+jYTWe1maXfG/K9jiX8KX/9rn6mYZXyR/mj/PWZAO0f7V/NsIL+HUH922d1ExI3 MoadfP/fbJRp2EF+qOT14RD+vmGN8teHAhcSEW/5o2NJx5KOZcWwTsd6BDvW6D/0H/oP/afLAPof /R/qmyf9cGQMO4wY6H9RNl9s4Q//fhMY7fLHiw0vNrzY8GLDiw0vdozY7P93Xdpf2l/a39Ftf/v9 thOUl2jDzoHhYycfg48d5LsjRjIK/sGK148jyt9olz+vYzWT7Udxq5OB/FrHDv51ZaMfJyh/lL/K iwX1rx/VrU4G9Y/6R/3TZQD9U6cb+nEibv3TjzQ2kpGQVbFKsvHrJdk7LsvYuO99/uH++3LrD1q1 ONvMvCx8x79Wtsvy8ttXZNaaqF4/1X/kw5/yR/2LSf+UCvLh1VtyLGNa/7mKrCz7H3woW7XD9OUF 8dYF1LqvLJNy4Vfz0h31h3z4U/6of+gf9C/tT5UA7S/9D/pfI9H/dFXeIP02svgM1flCtrb6Vc1C XlkJy9i3rOjr3Zp7ifxovm4+wD+aD+WvO3N/R7z+5VfT0eWrVv8sy9CFbp3Uv+nVfFfUPPLhr/s0 Dcsg5S+aDfUP/dMNBYz+Rf+if6N1rMOF9ieaDe1Pd9qfbujwboeRjBE7T/WImd/qERMl0d+s/S0w Ymd6QRYtEdu9rHfOvf2eN2Kn9Oc1ufC3WRn7thmCe3P4V3/x/uYFyf5mVirjfZAPf8of9S8u/VPa 1yN2slI0RiuKHpNjfjFLXV4Uy9d+UrbPyIXLesTOC1Xdtv/Re3Ll00MZez6s6yKOH5fl7BuLsjSn FaqzIR/+lD/qH/qnqg8r/9G/tD/+iA3aX/of9L+8t++B638aijsZu922FA1SeJ34GMnfbG7117kd +iKZarmEOvLb93ECf8pffR0L1znzmPrXyiF5+3OMtaPHaZNtG/vTKy1HWyG/xrHlHHv4U/7aqHNm H4T6h/5p0dlG/6J/K30q2p8WNYX2d7Tb3xbFYwgvJ9p5cier4vhGmHY7WK0dAiPfNeykOzCCwb89 Awflr5VD7tGuf52tyrE+026966Cz7IbZxpRD5MO/Pb1H+Wv7ZY36V/0Yh/5paQRD/6J/0b8dlIF2 jGXo36HRv0Nou2ka5WRMxdIaKWorfHxRzv38lr6Ulry9LlMtZlmVviqJ/dSW8Wc9D6RRwVbveX5S JlpMW0A+/Cl/1L949E9Z1t4alwu3tQqbzoq9NRuYplqn2J6WpVQqat02rvVf3dXACUdHnnlhUsaa 3od8+FP+qH/oH/Qv7Q/tL/2Ppq+f9L/i7X8GergJOGhq9hnyi518se9FUpHf/ogd+HefAOVvlMtf ZyN2ul/6kO9NhWhjxAD8u02A8kf5q32Bp/61HLHT7dqntETKH+VPvyIrbdik/HW/grUIkfoXr/5p kT09vpzoqVj+9KqMOnjSY5IRwSPffbGGP+UvooL0+NRo1z+jYZ9b7zHpqOCR73Us4B9VQHp8jvJH +au9WFP/elzXooKn/lH/qH8Vwxb6J0pB9Phc3Pqnx8lrEXyip2JJ+VDWfrcm9g/Sknltqv/jq5AP f8of9S8m/VP+ckdufLIv1sy7cv6lpgOBe6IbkQ9/yh/1D/2D/qX9of3tSSejSaD0P+h/xNn/aFI0 e34p2YadnuNDAAQgAAEIQAACEIAABCAAAQhAAAIQiI8Ahp342CMZAhCAAAQgAAEIQAACEIAABCAA AQicigCGnVPh42EIQAACEIAABCAAAQhAAAIQgAAEIBAfAQw78bFHMgQgAAEIQAACEIAABCAAAQhA AAIQOBUBDDunwsfDEIAABCAAAQhAAAIQgAAEIAABCEAgPgIYduJjj2QIQAACEIAABCAAAQhAAAIQ gAAEIHAqAhh2ToWPhyEAAQhAAAIQgAAEIAABCEAAAhCAQHwEMOzExx7JEIAABCAAAQhAAAIQgAAE IAABCEDgVAQw7JwKHw9DAAIQgAAEIAABCEAAAhCAAAQgAIH4CCTbsPO0LKXHZZl4fkLk2fggIxkC EIAABEaMQFm3P2WRiYmxeBKO/Hj5x5PrSIUABCAAAQiMNoG4+z8x0k+0Yaf8+S0Z//5FkUubon6T ihEzoiEAAQhAYJQIFD56Xc69syXzGwey9MbZvicd+fHy73uGIxACEIAABCAAAYm7/xNnFiTbsPPF moxPXRCZzoq9NSsxfTeNM3+RDQEIQAACMRAofHxRzv38lqRv5mV9bqrvMUB+vPz7nuEIhAAEIAAB CEBA4u7/xJkFGHbipI9sCEAAAhBIJIG4OxbIx7CTyIpFoiAAAQhAAAJNCMTd/2kStZ5fwrDTc8QI gAAETkXg8aFsfLIjRTcQ7bfk7H94U85/T/vOarQ9Lknh8FD0NNvKNnF2Ss6+wJi9Rrg4330CcXcs kI9hp/ulmhAhAAEIQAACg00g7v5PnHQw7MRJH9kQgEBLAuXPb2hfWb8I3Je6npPNX1qBc5WDr/bl xuUr8ouPtuquWZdWZP2DjJzFvlPHhhPdJxB3x2KY5Zf+UpD8/WNx7LJnJiblxW+dlcmJshQKxzL2 jbNy9sXWlTju9He/RBEiBCAAAQhAAAKtCIx0+68SvNmFrNKZr7SPHWUnOJ0kbbQJ5G6mq+XcKesN /iwrpTKXFtV27mj4YB3vqoW5jMrMpZU25VTSqP2W1Kfj65xKN0i/z2VJDSGB+rRyZuAJ5Fczjcuq F/uiWp5uXG/dcrtyt+g90e5Oe/KVOvpsoaHecOWLZam01h+bdw/aFa/alW8GWLy3qTJWKx7z6uiJ +VT0/knkR4fEWQgMOIEnR2qxYb3JqFwT9XF0Z7F1/a9rV1Nq+5HB5NG20suTtBlO6FkjGHYhAAEI dIPAKLf/0g2AgxoGhp1BzRni1U0C63Ptdqiq92VWI4wi3YxQD8PKzlTTEGnYuV8z5OoOZvpqVuUf Vc259oNdNW90OvUqRT2MIUFDoEqgrY7Fk3wbxkhRqShDZgvQbcnXYeRvptp8IavpGWtRHbTxpaRd +W4yDjbmQ/GwVGo6Km5pleuBfDce/EJg6AjYuUjDilUz9ugRrg2T1HH9r7WlK/f8SmgXVkJ1t3mf xHy2YcS4AAEIQOCEBDrtf5xQzEA+hmFnILOFSEGgAwJPiurowZHK31mqda5SavPekT53UPnL39tV K1eDo3qy9/1OWQeSYr7VVk0NOzp2xft5dVQz6AQi+2Dd63hGGoUCN3MAgdMTaLdjUXyQV7m7Of23 rRbc0TvWgtqunHPO51WxjREq4Ri3K199fVSVv5P1Xw6nl1Qu58jWf3vbWn9URx95I3jm1luOgm1b vhNxbeDKeMZXS2X3DOPrE1vlN8xRBWmVb0N9dSQ/DI9jCAwZAaft23Xq652QkaVi3JlXB410iF1U eaeum/X/6rpf/z09FLwnbJw5updTu3v6nsr9hi7T9XrdDWNvV+V034QNAhCAQC8JjHL7j48d3VNl g0AiCHyxJs9MXdBJSUv+ybpMPRtM1fE/vS9/9R+vVE7qEQCyGbUE8+Nj2fnfG7L16ZbsfHms752U yW9Pyiv//rxMvVCUrY9viUwvy8ovX/ECP/zjhr63LOOG2wtbxuSVN9Iy9by+zXF+/OmfKv4yvIf0 TuAe40L5q4Ls/fO+FP5SlLGxMRl/4axYP3pFprRfjbW3npELt3UKO11C+mlBLj53TnTsO3/WiBu7 EGiXwEnmeLvlW2ayov5xtl1Rkfd1LN+sI6t6ifa3Q0u0f7Unb37jx7JRkZaSnL0pllHnw5HoRH7p zzfkzL+r+tFa3CnKwqv1jtH3f/e6vPxfHd9ZaS17valsJy6dyA/HnWMIDCuB8v4tGX/5oo5+ShYu T8r7HzitnsjSXlHmf1RfryoXnX9G/c8WlMy+5F3xd4x7tGFHMt9rrAC6qcv8CAzg3lPdZ7r9Rzl8 KjJuRG/q1bRY39R8Ivo/tnYe9vJ07brxDLsQgEB3CIx0+99Li1ncYTMVK+4cQH4/CXjlXRp80Ta+ ikeNWrHv+VOZtGr1RrjU7U+v+F/rdZiN/Nqk16pTvux7yw3DWgrMqSiqzWvBkUWm7PTVJTVfG1oe Ff9mrO2cn7ZMLV7N7ucaBE5LoPMvRv6ItG74hetYfgv94PDIG/68ssZUjChWncj3w02p3NdRoelz ng+thcajD4xHO5FvPMYuBIaagDc1e0b7ljTqtDYW++12VAqNe83ROMV762rhkh7B5/jUMdr75UDb HQ6wu7osHHrg+MGmSk+nVUr7AbPa/NNGL7X5IBDKiQ8a9m+0b09ny1+3ovs/1xpPjztxZHgQAhCo EBjl9p+pWFQCCCSEQEvDzn1/OlK9zw7tfNEw5izc3FR5Pb3roJBTmzdDzlVDzsh39fVUwHFjSqXn FqsdQYfto5xavDQfcopau8dz6tieE1nX0NOWYUdP4XCmo+1uVKeoVf0NWEGnjwnJe5IxeAQ671h0 92WoY/nGi12j+pW/7vu8MV/+ouh3It/O+cbf1NXt5i+gUcIiznUiP+JxTkFg+AgUd73plAufVac8 7V5z66xu+46bJMmo/3rEjrflV6sfW5Yrhtyiyl5KKWt6vqlDZqVrsDttuhtGai8yETv2vdDUM6Mf 4/YXon6bG6YiBDU6VVncwV/YwZWVvVft3NjHuYCPPxHtiH5mXm0W2phP2kgm5yEAgaYERrn9x7DT tGhwEQLDQ8A07AQ+pmkDx8Hd9cDIGj3dIZgw2x95k1kz/Fu4dz3a9X1gmCN23Ou6Q+muWCWyqEKh V+4q7rk+gEQthVb5cTuP1U5RWq2bq3fZR2o95COo0YunGx2lVwlZiOjgBVby8G5mBwLdJ9B5x6K7 L0Mdyzde7KLrV1Gt1JyXO1+8d6MquYGxI/l6VR1ffzijBVNq8WZWbd7Z1j45tN+s46IefWAE3sZu R/LbCI9bIDDoBHwH5NrBuDvyzfAv18yJsunnKqUNDwuXFyp/mZrfr1aG3CCb7uqyYNihI90/2FzL qvWN9bb/smub6sDlEwruxIfH24E+1tJntX7UkwO16PpO00adzaH0b3hiKjwIgVgIjHL7j2EnliKH UAh0n4Bv2GkyjcoxdsxFDMk2DDupq5vRzlq/zquluZSav74bGfnty/6Q4+WQ4Ua7NVZL3qiepaDh x3ihdF7oGhlf/C+PetWrlqsEBUcguV/RrLmVtpZKjkwgJyHQAYHOOxbdfRnqWL5RD9POKjqOIcX5 s/XIt3vbatEz6mgd0mpah36sU/lHnvP3xvpr4eZ2tG6KyJdO5UcEwSkIDBEBPerVbWMvbxvxNvSK NHGibNR/t700fwfWsGOkNPZd/QHMnJo+fz2rFtw80X2vdUbpxJ5FRGA0CIxy+4/zZN1ysUEgCQTK 2nnyeMV5cuPULK7lZP5nlnZtHNq0A8Arz/2VvG+etlKS/ptJEKrx7gAALFdJREFUOSMT8uI3zsjZ 71pVJ8qOQ8Co7S8b8sy33qxemVsXdVN3cWqb79BRRA8Rl8WfTrqXRL7UTp+/4zh91oOUr+1K7u98 x8z+TXrv8Z68/m9+LBX3qe04T35alvLjshwf5uRG5ify4X4ttEvbon5zPhA0BxDoNoHOnfeVtXPw 8YpzcD19Qeyt2fp6qiNZ/upQCg/KcvZ7UzIRcpBupqFj+YZjVDOc+n1LNh/kJPXN+ivmmY7lOw9r x+lrv89K9pP3Zcutr2agzr61JEd352WySdqd204k33mQDQLDSMBoR9OrObn107NiP7Vl/NlxyX90 Xn7899UK1dCJslH/F9Z25cJ3z4g8p+vR7ffkzV9tiTbsNHWWHETWni4LPnPCo/KhXuzhT1Lq6PEJ +dFPU3LWWdyh21tpXy6eebmyUIMftCXZe3sy28TZtH8vexCAwGkJjHT7n2TbnTeCIeQTJMlpJm2j S8Ar7/rLUFZPZXL8y2yvmv5xms+xtwu+Dx6tVKMd/unz1qVGSx2bXwZNXzbm+fovhma8F+40Wwr1 yBv103rETqgc6KlZi96XM+1cusNpHaHQOIRASwKdfzEy6knDNstWK7VynFqtOidvFJGO5bf4Yi9W Wi2t9XHEjB4pVDw+qizFvB7y8zW/0UxPVIl0nP5GIDkPgSEgkPN86TRuuyvteqPRdkb9D/jYuVn1 0dOZT5p2dFl3oMbuYycqGcb0typzcwRV1AOcgwAEuklglNt/pmJ1syQRFgRiJOAbSDIBw0V+bd4w 0iyqpq9ET4oq95kePnwpox386ZUmprWTY/0X9H8hqpEBxs75jgw944vRyUlHvIz68RaV2Yjw7+My NTqeXtjutTZ+/ZV39JBo5rm3QYxbTkOg845FOy9D/j2t6kDH8o36JZc2tU8bbVgpFlXxkfZvcwI/ n53Iz60tqcycdijarF5q5++uHrICU02ic6kT+dEhcBYCQ0LArLtNPspUP9g0+MBjhBGYdvX1kcrl 8m1PgawS8/VUr50nK70qVsr54NTmiljOfd1cFauuhOiPSEueTx3fyDbPapx1qDgBgV4RGOX2H8NO r0oV4UKgzwR8A0l4uXP9ld/oaKRvRiyzWeuMWFH+d2rpODB8YNSvquUm1pjnLwsVXzq7V13fOw2W MjZW62rmuyPSaOSKbePXVfRO5zbLXPc2iHHLaQi45a2VAcaX0c7LkH9Pq3A7lm+82EUZYP14trfX vnydJlc/NRyp5Mg0/HRFOXAPRat9+aEHOYTAkBEwFybw2jbXR1ZtdKp9L+t94Il0omzU/4Bh50Qs fD3Vc8POieLXo4d0P2rZ1WW6n7GknTqbPnYyqxF9rx5FhWAhMMoERrn9x7AzyiWftCeLwH234xYc sVNJZGjVmfUHoaQbzpPnG42a0R0/1zFgY8OOfv3aWfQ6kEsbWW81LetqtNNlpccQmStYza9FdH70 kukZ40tk1EvtUS7X+MuiTp//fNjwFWLBIQS6QOAkHQtviWA9XaLR5t4TVQfMZzqWb7zY9d2wYzhm 9l5MzcQ4+4YOS12L0BGh+ztOf+h5DiEwLATW52ojQ5oaPM0PPPVTos1VscypWCdl4Oop52PNaGwh o447rVz3PQLGnagPa6MBiFRCoG8ERrn9x7DTt2KGIAj0iEBRD5W+m1Pba74/neU7OZW/dxBYIthf ClV3AqcX1bYeXn3kLllsGHacES2Za+sqf6znX7hf+x7l1fKcO/Km8VSsSgr18p7zjhHG82njdDob DP+uITn6zI97dU66jt/dvDq4n9d+gnxDUXUoubMq1ra+duSnz85VhmNXr1tqcXVb5R/oKSRfF+uW enemmbBBoNcE2u1YFB/kK/U3l9MrTxlfezd1/XTqdeDPuKdrhh1nqoUjZy/r1aHU5axeZtyVnffr WQfQ2k2/XnZLeS+BFeNtWq3fNeq2lumsyuUbZkW1M6KgffkdJIpbITBIBJy2fyfrTVEUWarUW6ft Mzf70YH+6JFT2ctVfzlOOzmv28gDp4239fTrUP1f0L60nPsr5+81nbztiTny9IV+ztBTYi3ovoar S/Rvm+F5AQ/6juaXz+3q/lHNuFbRYSuBlT/NEVUO+/R1vdz6oxPMbx10FsQPAgNCYJTbfww7A1II iQYETkbAmMZQ6VCYnQtRQYeHxcCULKeDYTnLGjub/lpfMcZEhFE1lpjhLrRcMjy/lvFG7VSen2tl TLHVprFcer1MX77rZ8O5x0ufHgJtjvpp/HxG5b6uJpn/EOglgbY6FrreOf4hGpfXxteajZpz0tWW fOe+mnPUZnE4yQieduVXDDuGQcuMh+Pjy6zvlWuNnL+GMrN9+aEHOYTAUBDQbX/g44mpK/S0Z89u 0Oy+ZbXfsv5bRljRYOyC71vPrL+N9tsxzEZLGryzjfSn17fyRlKb+ePsL2uTNhsEINALAqPc/mPY 6UWJIkwI9JGAq8DqO1EptRmeclXMBQw43rQr/YLpTrMSK+Jlqvby6YzkOWqnNxIaAdRwekWIU/6z 5foXOS07dWlFj8DJBYY0O6OAAun7+kBlr4YMSsZLc/pqtr24h+LEIQROQsCtl81H1mhjqzENqb4O h18G/OPlveBX+XAc25OvR8OER8sZdcaNz8rd5rLCsp3jduU79/p+uHT6Gr6sWmppI9f2y1An8p04 sEFg2AjsXk9HG4WnlwMfXzaNkTpunXZ+nRUuD3eWosPw9MB8YDGGSEaPdv3+g/ecr6tMmSJptfso MpShPNlIfy66U7G+jv5olrrKSllDmeFEeigIjHL7/4yTQ1rpJnIrf7Em41MXRDtvE3trVsYSmUoS BYHuECg/PJbis2dk8oVqTSmXSlJ8bOvAy/pvTM68OCljz7Yvq/ywILnCsYxPvizWSxPtP/i0LMf/ eiwycUaLtmX8hUmZ6KTyVp4/lIdFJ956e3ZMzn5nSiaerx7yHwL9IFD4+KKc+/kt0YYdWZ+b6ofI gIyhkv9wX9b+qSATL70qqR9OSunhoRw+KIn91K5onzNnzsrUtzvTP3GnP5AZHEAAAhCAAAQg0BcC o9z+Y9jpSxFDCAQgAAEIjBKBuDsWyI/XsDZKZZ20QgACEIAABAaFQNz9nzg5YNiJkz6yIQABCEAg kQTi7lggH8NOIisWiYIABCAAAQg0IRB3/6dJ1Hp+CcNOzxEjAAIQgAAERo1A3B0L5GPYGbU6R3oh AAEIQAACcfd/4swBDDtx0kc2BCAAAQgkkkDcHQvkY9hJZMUiURCAAAQgAIEmBOLu/zSJWs8vJduw 8/ktGf/+Rb14zorYuQzOk3tenBAAAQhAAAIOgcJHr8u5d7YkdT0vm7+MwXky8mPlTy2AAAQgAAEI QKD/BOLuf/U/xb7ERBt25Cu90sYfCnp1nSmZ/anlp5o9CEAAAhCAQA8JlPZ3ZOtfHsqL303JeauD VeG6FCfkx8u/S9lIMBCAAAQgAAEIdEAg7v5PB1Ht+q3JNux0HRcBQgACEIAABCAAAQhAAAIQgAAE IACBwSGAYWdw8oKYQAACEIAABCAAAQhAAAIQgAAEIACBjghg2OkIFzdDAAIQgAAEIAABCEAAAhCA AAQgAIHBIYBhZ3DygphAAAIQgAAEIAABCEAAAhCAAAQgAIGOCGDY6QgXN0MAAhCAAAQgAAEIQAAC EIAABCAAgcEhgGFncPKCmEAAAhCAAAQgAAEIQAACEIAABCAAgY4IYNjpCBc3QwACEIAABCAAAQhA AAIQgAAEIACBwSGQbMPO44Ks/cOG2D9IS+a1qf5TRz78KX/Uv5j0T/mLHblxe1+smXfl/Etjfdd/ yIc/5Y/6h/5B/9L+0P72uwNC/4P+R5z9j36X94A8leAtv5ZROrH6L6MOnvQ/ociHP+WP+heP/rFV dsZhr//m1vuv/BTy4U/5o/6hf9C/tD/9b4Bpf2l/aX/ja3/7X+NNiWIeJG0/v+oaFtIqZ/c/dciH f9WwQ/mj/vVb/xgdu+msNrP0e0O+17GEP+Wv39XPNKxS/ih/lL8+E6D9o/2rGVbQvyOof/usbkLi Rsawk+//m40yDTvID5W8PhzC3zesUf76UOBCIuItf3Qs6VjSsawY1ulYj2DHGv2H/kP/of90GUD/ o/9DffOkH46MYYcRA/0vyuaLLfzh328Co13+eLHhxYYXG15seLHhxY4Rm/3/rkv7S/tL+zu67W+/ 33aC8hJt2DkwfOzkY/Cxg3x3xEhGwT9Y8fpxRPkb7fLndaxmsv0obnUykF/r2MG/rmz04wTlj/JX ebGg/vWjutXJoP5R/6h/ugygf+p0Qz9OxK1/+pHGRjISsipWSTZ+vSR7x2UZG/e9zz/cf19u/UGr FmebmZeF7/jXynZZXn77isxaE9Xrp/qPfPhT/qh/MemfUkE+vHpLjmVM6z9XkZVl/4MPZat2mL68 IN66gFr3lWVSLvxqXrqj/pAPf8of9Q/9g/6l/akSoP2l/0H/ayT6n67KG6TfRhafoTpfyNZWv6pZ yCsrYRn7lhV9vVtzL5EfzdfNB/hH86H8dWfu74jXv/xqOrp81eqfZRm60K2T+je9mu+Kmkc+/HWf pmEZpPxFs6H+oX+6oYDRv+hf9G+0jnW40P5Es6H96U770w0d3u0wkjFi56keMfNbPWKiJPqbtb8F RuxML8iiJWK7l/XOubff80bslP68Jhf+Nitj3zZDcG8O/+ov3t+8INnfzEplvA/y4U/5o/7FpX9K +3rETlaKxmhF0WNyzC9mqcuLYvnaT8r2GblwWY/YeaGq2/Y/ek+ufHooY8+HdV3E8eOynH1jUZbm tEJ1NuTDn/JH/UP/VPVh5T/6l/bHH7FB+0v/g/6X9/Y9cP1PQ3EnY7fblqJBCq8THyP5m82t/jq3 Q18kUy2XUEd++z5O4E/5q69j4TpnHlP/Wjkkb3+OsXb0OG2ybWN/eqXlaCvk1zi2nGMPf8pfG3XO 7INQ/9A/LTrb6F/0b6VPRfvToqbQ/o52+9uieAzh5UQ7T+5kVRzfCNNuB6u1Q2Dku4addAdGMPi3 Z+Cg/LVyyD3a9a+zVTnWZ9qtdx10lt0w25hyiHz4t6f3KH9tv6xR/6of49A/LY1g6F/0L/q3gzLQ jrEM/Ts0+ncIbTdNo5yMqVhaI0VthY8vyrmf39KX0pK312WqxSyr0lclsZ/aMv6s54E0KtjqPc9P ykSLaQvIhz/lj/oXj/4py9pb43LhtlZh01mxt2YD01TrFNvTspRKRa3bxrX+q7saOOHoyDMvTMpY 0/uQD3/KH/UP/YP+pf2h/aX/0fT1k/5XvP3PQA83AQdNzT5DfrGTL/a9SCry2x+xA//uE6D8jXL5 62zETvdLH/K9qRBtjBiAf7cJUP4of7Uv8NS/liN2ul37lJZI+aP86VdkpQ2blL/uV7AWIVL/4tU/ LbKnx5cTPRXLn16VUQdPekwyInjkuy/W8Kf8RVSQHp8a7fpnNOxz6z0mHRU88r2OBfyjCkiPz1H+ KH+1F2vqX4/rWlTw1D/qH/WvYthC/0QpiB6fi1v/9Dh5LYJP9FQsKR/K2u/WxP5BWjKvTfV/fBXy 4U/5o/7FpH/KX+7IjU/2xZp5V86/1HQgcE90I/LhT/mj/qF/0L+0P7S/PelkNAmU/gf9jzj7H02K Zs8vJduw03N8CIAABCAAAQhAAAIQgAAEIAABCEAAAvERwLATH3skQwACEIAABCAAAQhAAAIQgAAE IACBUxHAsHMqfDwMAQhAAAIQgAAEIAABCEAAAhCAAATiI4BhJz72SIYABCAAAQhAAAIQgAAEIAAB CEAAAqcigGHnVPh4GAIQgAAEIAABCEAAAhCAAAQgAAEIxEcAw0587JEMAQhAAAIQgAAEIAABCEAA AhCAAARORQDDzqnw8TAEIAABCEAAAhCAAAQgAAEIQAACEIiPAIad+NgjGQIQgAAEIAABCEAAAhCA AAQgAAEInIoAhp1T4eNhCEAAAhCAAAQgAAEIQAACEIAABCAQH4FkG3aelqX0uCwTz0+IPBsfZCRD AAIQgAAEIAABCEAAAhCAAAQg0EMCZf3+XxaZmBjroZDBDDrRhp3y57dk/PsXRS5tivpNajBzgFhB AAIQgAAEIAABCEAAAhCAAAQgcCoChY9el3PvbMn8xoEsvXH2VGEN28PJNux8sSbjUxdEprNib83K 6Nnthq04El8IQAACEIAABCAAAQhAAAIQgEDnBAofX5RzP78l6Zt5WZ+b6jyAIX4Cw84QZx5RhwAE IAABCEAAAhCAAAQgAAEIQEAEw05CS0GZETsJzVmSBQEIQAACEIBA7ATKh7Lx8Y4UvYiMyyszszKl XRuyQQACEIAABPpNAMNOv4n3SR6GnT6BRgwEIAABCEAAAiNHoPz5De3L8BeBdC/nbHnXYvJ7AAoH EIAABCDQFwIYdvqCuf9CMOz0nzkSIQABCIwOgZLceuuMXLzdPMXWdFrO/+hNuTCXFutFXnib0xqu q+V97cvvZe3LL7xdWteLNqRlZ+Fl+ckH++Grkr1ny+z3ElAWvtqTK5f/P3lYOpZbt7cq6VzRacsk IW11ucYJCEAAAhAYdAIYdgY9h04YPww7JwTHYxCAAAQg0JrA00N577m/lg9b3+ndkZgXei9Fo71z +OlF+ev0rXoI1oqoXEZuvfyMXKy360h67UDWf5ag1TqeFuTic+fEIYFhp744cAYCEIAABPpDAMNO fzj3XQqGnb4jRyAEIACB0SJQKslx2a446/vJ3+sRC9NLkr85KxPlcoVD6VFBNn57Ra7cdt/u5yX/ ZEmmnh0tTIlN7dOyFD7fk2zmJ/J+JYsXZTeXkslvTcnZF8ak/PBQCsclKfyvK3LhA10+rAXZ/p8X 5BVrSsaSVAbK2rAzjmEnseWchEEAAhAYEgIYdoYkozqNJoadTolxPwQgAAEInISA25GQmazY/zgr 4Uk2O//jdfnJr1pPVTn804as/T4r6//nsBoNbSyYnDmvp3FdkPRrVl244bh2/Hz5WLZu/1FKTkDa QDX23fOS/uEZ2fn9Dbnx6Z4cPjwWefGsvPmzd2X+7fMt5Gsjxx83JPvJumzV4j+pn7VefVPefONV kc83dLpK8vJ/flfS36v3rlv+qiA7f9iRvX/ekf2/lOXYka23yb9JSWZOP/PDycqx+e/4z1uy9X9L Mq6B29qW9srPtOPe53U8/rwn+18c6nOOge2MnP2BJa/8UBtTzIe7uL/21jNyQU/Jy6zmZeXt+uVV Dz/RI3tm9XgWXT6ULh/Rm473n7ZkQ09p2vuimnbnvsmXXpHUTFpSP6qP/6CkXyJH7JRl79MNKTwW GXcTrMuYfPu8zL6aoNFKbtr4hQAEIACB2Am4/bFRXO5cVII3u5BVunQpmc4qO8HpJGkQgAAEIBAv gfxqpnl7c7/WHuk2SU9VqY/so5xasHR75bRZDf8yavtBxLNOaCd83r633EReKC7Wkjp6Uh/1ypnj XTXfMv7V8FLXc3WBFHeWWsbDurodes5WKyGZqatLKtOQX1ptFhrwC4Xc2aGtsjPVtOmOZOSjrcqH fX+7SbzdfND5f9+M/6CkXyf5Sd6Lv1e+7ZxKReZFWuUblaNIepyEAAQgAAEItEfAbW8btcfthTKc d2HYGc58I9YQgAAEIDBABNyORKMPCQcbC57hwnvxdeNfDL8Ap9TS6qbK5XJq+7MVlQ68HKfU9iP3 wdrvaZ7XBqHFSxmVChlI9JwhNX8prcRKefF2DE6ZtQjDxaNtZQXiKCo1t6CWri+p+Rkr8LwTRlRn K3/dlGOphetZtb2zrbLXagazWvjZkGEmt7qoMjPms64RpPpr1aVL1PLdYgjgaQ8Nw85qBB8d/MFa E8Pf/fUQo2r+7+7tqs3VpTrjyLph3BmM9OsERhl29LmwkTI9N6+WN6IZnTYXeB4CEIAABCDg9sei +hpJp4NhJ+k5TPogAAEIQKDnBNyORJ1hxy6q3IY5GsUKGWZstT7nGyNSVzdVsW40g622r2kji2s8 mTNHoZ72+Soaz/DgyJheUgfGwBD7/qZvuJleCY2A9Y0alfhZiyp3bDysg7cLmwHjRGRn61FeZW9q Y87dg7q8snMrXtpTUSNiDKNClVFKZe8eeeHYOuzlOdPAlOnyiBGfgTWzqLKrWbVyc8X7c44XXQNX 3QjioloyjE/W5fX6/H9SVOuXjfg7I6e81Omd2NMfjEP2vj6284ERaOlr2/XpMtPAPgQgAAEIQKAL BNz+WGRfowvhD3IQGHYGOXeIGwQgAAEIDAUBtyPhGV9cI0zot27ES9EY7aJf2BuPJTlSC15YaZVz bSenfb5G14+/HhEUEYntqzXDwoxpVNIPG1PMROYbGky8qdE6DZHGGTeXtSEsf3e3Mlpne2dX5e7m 1dGDnDdqKbKjpo0I/vSrlNoNj2iqhK0NYJd8A1pdPrjyT/TrG3Za5X+d4c+dMu7krbXcJP+Lanna j39g1Ffs6dfQDOPSvDZq+fkhaulOvbHuRJh5CAIQgAAEINCCgNufiewvtHh22C8/4yRAd0QSueE8 OZHZSqIgAAEIDBwB11lf44ilJHt3RWZDDoDLn9+S8e9f9B5buLaonRgbzmadK/p4bEwvrf4rf1nt 7H1bZr+tV1065fOuYC/+09r581a98+dG18v7Ov4vV+O/cOdIFl+rd3Dsytj/5Ipkfr0vmQ9X5N1X g/eVv9yTG9d+Ie995K4e5j4V/NUdNVmfCzknNhz3pm/m9HU9MSxqK+3J62d+LI4L69S1Xdn8u1ei 7jrBubKsvTVecZ6sQ5aFq1q+47PZ2B7uvy+3/qBPhPgefvKedqr8YeXO5Zwt71qN3Tubea0NU7Ly sxqH2NOvo2/EwUi2ZPSy7itJWtbdTBz7EIAABCAwcATc/kpkf2HgYtvlCA27ZapZ/L0vhHVDn5s9 xTUIQAACEIBAZwTcL0TOqJXcgyN1dD+nspeM6TOyGJw+Uwvea6e80Tj+qAzd3HtTkML7rq+Z0z7v ptKLf3hETu0G73qoPc3f9KeIuXFyw2z798FmXTqt6bT28ZNR6WmTYbR/HnO0SNM4GKNKpG5KWdux jbjRH7GT7tDHjsdV5/ViC98/9l1/Sl/gS6SRrnjSr5EYcQiW1XSDEVQRGDkFAQhAAAIQOCUBt10N tJOnDHNYHmfETpcNZQQHAQhAAAKjR8D9QhRc7lyP5HhHj+T4qMpDr+okuf9+PgDHG1nqnJ1Zks23 z0r5aeCWwEFZL9898aIl51+tLn192ufdwL34h0aUtLp+/Mf35a/OX6ncpqcHSeZ7jUecuGGFf7f+ 2zPy+m+rZ9PXNmX5v6Rk8nnjrqclufWfzshFPeIl8gucMVpkcacoC6/WL6VeCc24LzxyxpB2gl1/ xE5k/HSIjfgWPnpTzr2zUZGpjTIy+1ITfl+syTNTFyr36ulssumOXDLSFU/6dZSMOFhzy7L4akle n62WC70IvOS+XhHLzNNKKvgHAQhAAAIQ6C4Bt71t1B53V9qAhTYsFqiTxNP7khn6wniSsHgGAhCA AAQg0IiA+4WozofK175/GN38qxXPOU41JK+d0teilgFvJM89f9rn3XAaxr92Q6Prpny5tOkGF/2r nQDn7+VV0fUP5Nz15EjpyWfVETsNn/fvifwCZ44WadLeF3cWvZFBJ2EdnSjnrDFiJ8q5s76jEb/i XX+5+VZxyl33R0ctmaN7Yk+/TqARh2zBYaLTvDHv8RZZUAd1TsGr9w3a/4OdFcPZd0qt7ARcVbeM btzPt4wgN0AAAhBIMAG3vY3sLyQ43U7ScJ6c8AwmeRCAAAQg0HsC3qpSeipTeDMNCnUvuPqFeN41 bOjfZlNpis70ruuLauFq1l9h6LTP1yLbLP7OLQ2vh+QvNnCUW7y37r0sW9eN5a4Ng4Ae7RRGpw0G RbV51V/OPHKqkxmGZpi+vlsXTrHgy3cMbEs7ER6i655q/0R2pmqcioyfDqYhv+Kux6Vq+IuOVzGX NYwk2kG0edsApN807JiOnXM3jeXqp5cjpyO2T7kPd+r80B6SDNbOvhXk3SwacT/fLG5cgwAEIDAC BDDsJDSTvS+JTb7gJTTpJAsCEIAABPpAwH6QV7mcNrhcdo0PabWtj/P3zTfv8JLkWZVzRq7URjAc BEY2iFpY3VZHj/Swlie2Kj46Urk7WTVvrIjkvGiaA39O97ytjgo5tVwzTDhhb+b0SlRu9HUcDu6Z 6dPXnZWqvvbhHt3xR8I4xonUZZ2++0eqWCzqZ3fVisem+sIcXBXLH+3iPJuuPXt0P6+215YDRg/n uuVc1+wOHD7uFjJsOPeJNa+yn22r3Z1ttXzZH+lSudbNPoHmk89tqwU3f2aWdfx0/teWfLcfHYTK h8P3QNnG6BW3E1qJm477/HWd/3pYk23rv+KR2r5ujnzRjMJ+fOJMv86DI53e3E7WyyvTsONkUdZl 4+TLzIo6cMqFLh8DuUX4e3LyRTu2bi+6cT/fXiy5CwIQgEBiCbhtKiN2EpbFGHYSlqEkBwIQgMAg EdAv1GnnZTXyL2h8UXpKVip0n/+yaKttY1RKdHi+HOvyemhZ7JM/b99biYy/dT1XId3oenjKWWBk RiidZnqsS8Zoo1peFvd8p8DmvU33rRU9Aaq2RRk2GsVhekkdeA+6AZz8N78aMhp5clcqgWYtP9/M 9GQ2zCXAdf5daxRO8PnU1W0/3W60Y0x/VPkIGHYa1pFQ/XDTEvfvo+3I+rB53GbE4n6+zWhyGwQg AIGkEsCwk9CcxbCT0IwlWRCAAAQGgoAebTIXfPH2Xt6txTqfIs50Gn+ah6XW7wctDEd311WmgSFA L6OtFq7r0SoPgs+YGE70vB5h4MfJT8u8a3hocD1zs2r4MeUXC8bIFc/AUQ0zNbeoRzI1HqXh+CWJ ikdqbknl9OiXo52g8Sd1edsXbRg2nKlsxXvbaulSOhCeNZ1R2TvGFDD/6VPt2ffMKVI+P+ty1d/Q Zmi0kls+svfq87GY26wbmeXeL9PzeqRPA34xpl8db4cMlrpcPzCQPjlQC1FlWhvYjoxRS8YTse/m 1xYCxp3Mzfqpfc0iGffzzeLGNQhAAAJJJzDKhh1WxdK9JjYIQAACEIDAoBAof3Ush1+JTH5zXOyS LeMTZ2Ti+SarJYUiftrnQ8F1fFguHcvxQ5EztfifeWFSxtqJ/tOyfu5YSmXR94+J89xEW88V5OJz 5+SWjmndylzuCmPPdpyM2B6o8ivLmX87Kfa/Hou8OCmTzUAYK1IlIf2xgTcF69XnSvpvbGyivbJr Puvsx/18OD4cQwACEBgRAqO8KhaGnREp5CQTAhCAAAQgkEgChmGj5ZLhSQQw6ulPYp6SJghAAAIQ OBEBDDsnwjb4D5W/WJPxqQuifQGIvTUr7Xz4G/xUEUMIQAACEIAABCoE9Iic0pdbcn7qddnXJxbv 5OXdH+qRLk9tkafjMvniRLJBjXr6k527pA4CEIAABDokgGGnQ2DDcjuGnWHJKeIJAQhAAAIQ6JRA WdbeGpcLtxs/p30FydIbZxvfMNRXRj39Q515RB4CEIAABHpAAMNOD6AOQpAYdgYhF4gDBCAAAQhA oBcERt2wMerp70WZIkwIQAACEBhmAhh2hjn3msS9/PktGf/+RRFrRexchqlYTVhxCQIQgAAEIDB0 BLTD5dJj7W05chuTiWZOhyOfGbKTo57+IcsuogsBCEAAAr0lUPjodTn3zpakrudl85dTvRU2YKEn 2nmyfLUva38oiExMyexP9UKqbBCAAAQgAAEIQAACEIAABCAAAQgkjkBpf0e2/uWhvPjdlJy3Eu5n L5R7yTbshBLLIQQgAAEIQAACEIAABCAAAQhAAAIQSBIBDDtJyk3SAgEIQAACEIAABCAAAQhAAAIQ gMBIEcCwM1LZTWIhAAEIQAACEIAABCAAAQhAAAIQSBIBDDtJyk3SAgEIQAACEIAABCAAAQhAAAIQ gMBIEcCwM1LZTWIhAAEIQAACEIAABCAAAQhAAAIQSBIBDDtJyk3SAgEIQAACEIAABCAAAQhAAAIQ gMBIEcCwM1LZTWIhAAEIQAACEIAABCAAAQhAAAIQSBKBZBt2Hhdk7R82xP5BWjKvTfU/35APf8of 9S8m/VP+Ykdu3N4Xa+ZdOf/SWN/1H/LhT/mj/qF/0L+0P7S//e6A0P+g/xFn/6Pf5T0gTyV4y69l lE6s/suogyf9Tyjy4U/5o/7Fo39slZ1x2Ou/ufX+Kz+FfPhT/qh/6B/0L+1P/xtg2l/aX9rf+Nrf /td4U6KYB0nbz6+6hoW0ytn9Tx3y4V817FD+qH/91j9Gx246q80s/d6Q73Us4U/563f1Mw2rlD/K H+WvzwRo/2j/aoYV9O8I6t8+q5uQuJEx7OT7/2ajTMMO8kMlrw+H8PcNa5S/PhS4kIh4yx8dSzqW dCwrhnU61iPYsUb/of/Qf+g/XQbQ/+j/UN886YcjY9hhxED/i7L5Ygt/+PebwGiXP15seLHhxYYX G15seLFjxGb/v+vS/tL+0v6Obvvb77edoLxEG3YODB87+Rh87CDfHTGSUfAPVrx+HFH+Rrv8eR2r mWw/iludDOTXOnbwrysb/ThB+aP8VV4sqH/9qG51Mqh/1D/qny4D6J863dCPE3Hrn36ksZGMhKyK VZKNXy/J3nFZxsZ97/MP99+XW3/QqsXZZuZl4Tv+tbJdlpffviKz1kT1+qn+Ix/+lD/qX0z6p1SQ D6/ekmMZ0/rPVWRl2f/gQ9mqHaYvL4i3LqDWfWWZlAu/mpfuqD/kw5/yR/1D/6B/aX+qBGh/6X/Q /xqJ/qer8gbpt5HFZ6jOF7K11a9qFvLKSljGvmVFX+/W3EvkR/N18wH+0Xwof92Z+zvi9S+/mo4u X7X6Z1mGLnTrpP5Nr+a7ouaRD3/dp2lYBil/0Wyof+ifbihg9C/6F/0brWMdLrQ/0Wxof7rT/nRD h3c7jGSM2HmqR8z8Vo+YKIn+Zu1vgRE70wuyaInY7mW9c+7t97wRO6U/r8mFv83K2LfNENybw7/6 i/c3L0j2N7NSGe+DfPhT/qh/cemf0r4esZOVojFaUfSYHPOLWeryoli+9pOyfUYuXNYjdl6o6rb9 j96TK58eytjzYV0Xcfy4LGffWJSlOa1QnQ358Kf8Uf/QP1V9WPmP/qX98Uds0P7S/6D/5b19D1z/ 01DcydjttqVokMLrxMdI/mZzq7/O7dAXyVTLJdSR376PE/hT/urrWLjOmcfUv1YOydufY6wdPU6b bNvYn15pOdoK+TWOLefYw5/y10adM/sg1D/0T4vONvoX/VvpU9H+tKgptL+j3f62KB5DeDnRzpM7 WRXHN8K028Fq7RAY+a5hJ92BEQz+7Rk4KH+tHHKPdv3rbFWO9Zl2610HnWU3zDamHCIf/u3pPcpf 2y9r1L/qxzj0T0sjGPoX/Yv+7aAMtGMsQ/8Ojf4dQttN0ygnYyqW1khRW+Hji3Lu57f0pbTk7XWZ ajHLqvRVSeyntow/63kgjQq2es/zkzLRYtoC8uFP+aP+xaN/yrL21rhcuK1V2HRW7K3ZwDTVOsX2 tCylUlHrtnGt/+quBk44OvLMC5My1vQ+5MOf8kf9Q/+gf2l/aH/pfzR9/aT/FW//M9DDTcBBU7PP kF/s5It9L5KK/PZH7MC/+wQof6Nc/jobsdP90od8bypEGyMG4N9tApQ/yl/tCzz1r+WInW7XPqUl Uv4of/oVWWnDJuWv+xWsRYjUv3j1T4vs6fHlRE/F8qdXZdTBkx6TjAge+e6LNfwpfxEVpMenRrv+ GQ373HqPSUcFj3yvYwH/qALS43OUP8pf7cWa+tfjuhYVPPWP+kf9qxi20D9RCqLH5+LWPz1OXovg Ez0VS8qHsva7NbF/kJbMa1P9H1+FfPhT/qh/Memf8pc7cuOTfbFm3pXzLzUdCNwT3Yh8+FP+qH/o H/Qv7Q/tb086GU0Cpf9B/yPO/keTotnzS8k27PQcHwIg8P/asWMaAAAAhGH+XSOCY08FEJKeI0CA AAECBAgQIECAAAECBDoBYaez90yAAAECBAgQIECAAAECBAgQuASEnYvPmAABAgQIECBAgAABAgQI ECDQCQg7nb1nAgQIECBAgAABAgQIECBAgMAlIOxcfMYECBAgQIAAAQIECBAgQIAAgU5A2OnsPRMg QIAAAQIECBAgQIAAAQIELgFh5+IzJkCAAAECBAgQIECAAAECBAh0AsJOZ++ZAAECBAgQIECAAAEC BAgQIHAJCDsXnzEBAgQIECBAgAABAgQIECBAoBMQdjp7zwQIECBAgAABAgQIECBAgACBS0DYufiM CRAgQIAAAQIECBAgQIAAAQKdgLDT2XsmQIAAAQIECBAgQIAAAQIECFwCws7FZ0yAAAECBAgQIECA AAECBAgQ6ASEnc7eMwECBAgQIECAAAECBAgQIEDgEhB2Lj5jAgQIECBAgAABAgQIECBAgEAnIOx0 9p4JECBAgAABAgQIECBAgAABApeAsHPxGRMgQIAAAQIECBAgQIAAAQIEOgFhp7P3TIAAAQIECBAg QIAAAQIECBC4BISdi8+YAAECBAgQIECAAAECBAgQINAJCDudvWcCBAgQIECAAAECBAgQIECAwCUg 7Fx8xgQIECBAgAABAgQIECBAgACBTkDY6ew9EyBAgAABAgQIECBAgAABAgQuAWHn4jMmQIAAAQIE CBAgQIAAAQIECHQCwk5n75kAAQIECBAgQIAAAQIECBAgcAkIOxefMQECBAgQIECAAAECBAgQIECg ExB2OnvPBAgQIECAAAECBAgQIECAAIFLQNi5+IwJECBAgAABAgQIECBAgAABAp2AsNPZeyZAgAAB AgQIECBAgAABAgQIXALCzsVnTIAAAQIECBAgQIAAAQIECBDoBISdzt4zAQIECBAgQIAAAQIECBAg QOASEHYuPmMCBAgQIECAAAECBAgQIECAQCcg7HT2ngkQIECAAAECBAgQIECAAAECl4Cwc/EZEyBA gAABAgQIECBAgAABAgQ6AWGns/dMgAABAgQIECBAgAABAgQIELgEhJ2Lz5gAAQIECBAgQIAAAQIE CBAg0AkIO529ZwIECBAgQIAAAQIECBAgQIDAJSDsXHzGBAgQIECAAAECBAgQIECAAIFOYNYb4vB3 l0/zAAAAAElFTkSuQmCC --Apple-Mail=_700F2C60-ADFC-4BA9-8D06-1210BF6DFFCF-- --Apple-Mail=_5684746F-2B66-4DD5-B766-141F89F3E8DA-- From nobody Thu Apr 18 19:53:51 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282481200B3; Thu, 18 Apr 2019 19:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, 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=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 NDFwwxOoiwWo; Thu, 18 Apr 2019 19:53:38 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 53767120043; Thu, 18 Apr 2019 19:53:38 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3J2iDs9030525; Thu, 18 Apr 2019 19:53:28 -0700 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=6foWoHpvHs1+DM42Ua7WMXrN1EnCUpVL0nUTYav2AXU=; b=BL6nGvhZODGSQFfPIGdQPdLGcH/byPUteyBl3PUPBA7U8rLeFxigYivuSt8K+rfOD7Ka k7qVxcycpUOIvKc7WByzfALswxjFZYd+zMJUUs2r2JSOrY8wfXt9/gZxMz/A6m7Z54P9 IK5n0PbsptLiPigBGeg10qE/fAQ4SMeB003oKiwZbJ5f+mLPFVWphxxYKd/oJ+Ynq9wC c6UJAD4StnJ2w8b8Pz74qsXyu/gPXPJzv5QV7ykH1cR5Cg3jL+emkbE/7h08ODnSVdwA PE8Hu+OdvgGwWldrZErpN8eALCNZTjpaPtCDtJMsRtmZ6PLv9jBzsw3vDjV4tCAY3ViK NQ== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp2050.outbound.protection.outlook.com [104.47.34.50]) by mx0b-00273201.pphosted.com with ESMTP id 2ry2gbgb80-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Apr 2019 19:53:27 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB5157.namprd05.prod.outlook.com (20.177.231.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.10; Fri, 19 Apr 2019 02:53:24 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::30f9:29cf:6d50:edd4]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::30f9:29cf:6d50:edd4%4]) with mapi id 15.20.1813.009; Fri, 19 Apr 2019 02:53:24 +0000 From: Ron Bonica To: James N Guichard , Robert Raszuk CC: SPRING WG , "ipv6@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Thread-Topic: [spring] IPv6-compressed-routing-header-crh Thread-Index: AQHU5XwSQNUFwLkE10qv/uSLYFT0BKYiu67wgAFwpgCAAB1KAIAABz6AgAC56gCAAMlxgIAS2BIAgABq6gCAABaTAIAAAQyAgAM/fDCABNuTAIAAxd4ggAAL04CAAF6GQIAAHk2AgABFHsA= Content-Class: Date: Fri, 19 Apr 2019 02:53:24 +0000 Message-ID: References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-04-19T02:53:21.6815447Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef1de91f-9e35-4a8b-7bc1-08d6c4723113 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB5157; x-ms-traffictypediagnostic: BYAPR05MB5157: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-forefront-prvs: 0012E6D357 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(366004)(136003)(346002)(189003)(199004)(6436002)(561944003)(4326008)(110136005)(14454004)(229853002)(446003)(966005)(76176011)(186003)(6246003)(54906003)(7696005)(236005)(5070765005)(97736004)(52536014)(66556008)(76116006)(102836004)(68736007)(66476007)(26005)(25786009)(256004)(99286004)(14444005)(2906002)(478600001)(8936002)(6306002)(33656002)(86362001)(5660300002)(81166006)(6506007)(8676002)(53546011)(517774005)(7736002)(74316002)(606006)(81156014)(476003)(93886005)(71200400001)(9326002)(11346002)(316002)(66574012)(66066001)(53936002)(6116002)(3846002)(486006)(53946003)(45080400002)(55016002)(54896002)(71190400001)(66446008)(9686003)(66946007)(64756008)(30864003)(790700001)(73956011)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5157; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ipmSbc5tvJ4e1DnLK+w7AH0l54omqb5ugkh3W5d+HMhsDdBhfL90a5YncgCW31Hy70JJ5MfTJETMyjviTAgEbPUi9xW1XHNJsMdaa1I9LdbUr/jzroPH03W3hteZjOAXRIfe1y7YRUOIhIcV5tY8STCJPT4pLDlBojQvQ83Et420Bj0uOie61bvoV7K3AxHKvnv44owkvDzCpnq8wisXvuiejM2xrrn2HQyFrg8eD2fGPcxghMpKLnoeHNePKkeR6qeToMfKIzZ/ngbchZcKYuLsWPwkVhm3B/RHjaiD8HMILoHFYp+hesu1/Z5MHs7mUMoBN6LxZK+qPY3ENY2A7ODlQcS+D8JRiG0edFVYwFcxFqXbFGJxB+TdC1Quo/wGFc4oBpUpZjmUk9tkCX3DMEuRAHtLxpccEw/kf3+ixJA= Content-Type: multipart/alternative; boundary="_000_BYAPR05MB424592955BF0177DBFFC87F8AE270BYAPR05MB4245namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: ef1de91f-9e35-4a8b-7bc1-08d6c4723113 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2019 02:53:24.6198 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5157 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-19_01:, , 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-1810050000 definitions=main-1904190019 Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 02:53:42 -0000 --_000_BYAPR05MB424592955BF0177DBFFC87F8AE270BYAPR05MB4245namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Thanks for asking this insightful question. The answer depends on the SID t= ype. Some service SIDs (e.g., END.DX4, END.DX6, END.DT4, END.DT6) are processed = only in the following conditions: * When there is no SRH * When there is an SRH and Segments Left is equal to 0 Such SIDs should be encoded in the Destination Options header that immediat= ely precedes the upper-layer header. This is because the Destination Option= s header that immediately precedes the upper-layer header is only processed= when: * When there is no SRH * When there is an SRH and Segments Left is equal to 0 Moreover, Destination options are of variable length. So, each SID can be a= s long or short as it needs to be. One SID type can be long while another i= s short and neither needs to be the same length as SIDs that are encoded in= the IPv6 Routing header. The VPN Context Information Option [draft-bonica-6man-vpn-dest-opt] is an e= xample of such an encoding. It serves the same purpose as many of the SID d= efined in draft-filsfils-spring-srv6-network-programming (e.g., END.DX4, EN= D.DX6, END.DT4, END.DT6). As more service SIDs of this type are identified,= more destination options will be defined. Other Service SIDs can be processed when an SRH is present and Segments Lef= t is greater than zero. Ideally, these SIDs should be encoded in the Destin= ation Options Header that immediately precedes the Routing header. This is = because the Destination Options Header that immediately precedes the Routin= g header is processed by every segment endpoint. Draft-bonica-6man-seg-end-= opt offers one such encoding scheme, but it is not the only one. Another possibility is to encode these SIDs the Destination Options header = that immediately precedes the upper-layer header and required Service Funct= ion Instances that support these SIDs to look ahead. = Ron Juniper Internal From: James N Guichard Sent: Thursday, April 18, 2019 5:57 PM To: Ron Bonica ; Robert Raszuk Cc: SPRING WG ; ipv6@ietf.org; Dino Farinacci ; lisp@ietf.org list ; James N Guichard Subject: RE: [spring] IPv6-compressed-routing-header-crh Hi Ron, I am wondering about how do you plan to handle service SIDs (or any SID wit= h embedded functions) at intermediate nodes; draft-bonica-6man-vpn-dest-opt= seems to only handle the case where the endpoint will process the destinat= ion option: Section 4 says: "It MUST NOT appear in a Hop-by-hop Options header and SHOU= LD NOT appear in a Destination Options header that precedes a Routing heade= r". If you relax the latter and encode the SID in a destination option precedin= g the CRH (or SRH) then wouldn't every node in the segment-list have to pro= cess the SID and figure out whether it is a local SID or not? That would se= em to be overly complex given you could just encode the SID in the CRH (or = SRH) and only the node where said SID is exposed would process it. Thanks! Jim From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, April 18, 2019 4:30 PM To: Robert Raszuk > Cc: SPRING WG >; ipv6@ietf.org; Dino Farinacci >; lisp@ietf.org list > Subject: RE: [spring] IPv6-compressed-routing-header-crh Robert, The Compressed Routing Header (CRH) has exactly one function. That is to ro= ute a packet for segment to segment along an SR path. Therefore, SIDs conta= ined by the CRH have only one function. That is to steer packets to the nex= t segment. Granted, we may want to program a service behavior at a segment endpoint. I= Pv6 includes a Destination Options header that can be used to convey inform= ation segment endpoints and destination options can contain service SIDs. T= hese service SIDs can be as long or short as they need to be. See draft-bon= ica-6man-vpn-dest-opt for an example. = Ron Juniper Internal From: Robert Raszuk > Sent: Thursday, April 18, 2019 10:30 AM To: Ron Bonica > Cc: Gyan Mishra >; Tom = Herbert >; SPRING WG >; ipv6@ietf.org; D= ino Farinacci >; lisp@ietf.= org list > Subject: Re: [spring] IPv6-compressed-routing-header-crh Hi Ron, I must observe that your analysis is incorrect. SIDs are not only used for TE or traffic steering purposes but what is even= more interesting for various functions - for example NFV. So you need as much SIDs as possible imagination of your value add network = functions - which will be different from those functions at the encap dst w= hich as you indicate in other draft can be carried in destination options. That debate is still I think open. Thx, R. On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica > wrote: Gyan, Let's think about how a network operator might choose a SID size.... Assume that an MAN includes 100 routers. These routers are connected to one= another by infrastructure links. Each router has 20 or fewer infrastructur= e links. The network operator might assign one loosely routes SID to each router. Th= ese loosely routed SIDs have network-wide significance (i.e., the cannot be= reused). The network operator might also assign one strictly routed SID to each link= . The strictly routed SIDs have node-local significance only. They can be r= eused from one node to another. So, in this case, the network operator only needs 120 SIDs. This fits in ei= ght bits with plenty of room for growth. Now consider another network that includes 30,000 routers. Each router is c= onnected to its peers by 200 infrastructure links or fewer. This network w= ould need 30,200 SIDs. This would fit in 16 bits. A *really big* network might require more than 32,000 SIDs. So, we support = a 32-bit SID... = Ron Juniper Internal From: Gyan Mishra > Sent: Wednesday, April 17, 2019 10:00 PM To: Ron Bonica > Cc: Robert Raszuk >; Tom Herber= t >; SPRING WG >; ipv6@ietf.org; Dino Fa= rinacci >; lisp@ietf.org list > Subject: Re: [spring] IPv6-compressed-routing-header-crh I agree to make the SID align on word boundaries but I am thinking the soft= ware should have hardware independence if at all possible. I think 32 bit is a reasonable size. Gyan S. Mishra IT Network Engineering & Technology Consultant Routing & Switching / Service Provider MPLS & IPv6 Expert www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT Mobile - 202-734-1000 Sent from my iPhone On Apr 14, 2019, at 7:54 PM, Ron Bonica > wrote: Hi Robert, In order to make the CRH ASIC-friendly, we have the following constraints: * Support only a small handful of SID lengths * If at all possible, make them align on word boundaries Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should= support a length greater than 32? Is there some length less than 32 that w= ould be beneficial? Ron Juniper Internal From: spring > On B= ehalf Of Robert Raszuk Sent: Friday, April 12, 2019 6:13 PM To: Tom Herbert > Cc: SPRING WG >; ipv6@ietf.org; Mark Smith >; Dino Farinacci = >; lisp@ietf.org list > Subject: Re: [spring] IPv6-compressed-routing-header-crh Hi Tom, I already suggested this on March 30th ... "PS. But if you choose to go ahead with CRH I would highly advise to make y= our CRH SID a variable length. " No feedback/response was received from authors. Thx, R. On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert > wrote: On Fri, Apr 12, 2019 at 1:48 PM Mark Smith > wrote: > > Hi Tom, > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert > wrote: > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk > wrote: > > > > > > Hi Mark, > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary = and a 32 bit alignment, > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 ne= twork. > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may a= lso create some opportunities to > > > > leverage IPv4 support in existing protocols to suite carrying and p= rocessing 32 bit SIDs with some, possibly > > > > slight, modification. For example, perhaps IPv4 Address Family supp= ort in OSPFv3 (RFC 5838) could be > > > > somehow leveraged to suit SR. > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > I think SR while indeed started with the story of "less control plane= is good for you" now clearly has evolved into not only reduction of contro= l plane but what can be even more important to some users ability to reques= t specific behavior via programmed functions of network elements on a per f= low basis without actually per flow or per path signalling or state. > > > > > > Yes for some it may be very useful feature and I am sure some will ca= ll it overload of data plane or . There is no one size fits all. > > > > > > With that let's observe that till today SR did not require any new ma= pping plane to be distributed in control plane and to be inserted into data= plane. This is clearly a precedent. > > > > > > Furthermore as we see in companion documents all additional network f= unctionality is being taken away from SRH and is being shifted to Destinati= on Options . > > > > > > As far as mapping plane I already pointed out in my Vector Routing pr= oposal that we have one already it is called BGP. One needs to also observe= that we as industry worked number of years of protocol suite called LISP a= llowing not only very good mapping plane, but also data plane integration. = CC-ing lisp authors for their comments. Note also work for integrating SRv6= with LISP which is already is published. > > > > > > Since you correctly observed that now SID can be 32 bit and that is s= imilar to the size of IPv4 my fundamental question is why not use something= which already exists instead of defining some sort of new from scratch ? > > > > > Robert, > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > please provide a reference? > > > > To clarify, I've been thinking about the idea of a smaller SID size > for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.) > > Ron and others have written this draft, which supports SIDS of various > sizes - 8, 16 or 32 bits - that triggered this discussion. > Mark, Why not just put a SID length field in the header (like RFC6554 but more generic). That would allow lengths of 1-16 bytes. Additional flags could be used to indicate the semantics of the entries. For instance, they might be actual addresses (128 bits for IPv6, 32 bits for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) where the rest of the address can be inferred, indices into a table, labels, etc. Tom > "The IPv6 Compressed Routing Header (CRH)" > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > Regards, > Mark. > > > > As for trying to use something that already exists, why does SR used a > > fixed size format for SIDs instead of a variable length format like > > that described in RFC6554? Similarly, why does SR define it's own TLV > > format instead of using Hop-by-Hop and Destination Options defined in > > RFC8200? > > > > Tom > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP = or Vector Routing as an alternative options. I really do not see a room or = need for yet one more mapping plane. What problem does it solve which would= not be already solved elsewhere ? > > > > > > Kind regards, > > > Robert > > > > > > > > >>> 2) Is there an agreement that solutions which require additional pe= r SR path state in both control plane and now in data plane are really some= thing we should be endorsing here ? > > >> > > >> > > >> I think so. > > >> > > >> My understanding of what SR is fundamentally about is to reduce cont= rol plane state and processing. The trade-off for reduced control plane sta= te and processing is to instead carry and encode most or all of that inform= ation or its semantics as per-packet overhead. > > >> > > >> If the per-packet overhead becomes too large and expensive, then pus= hing some of that information and processing back into the control plane sh= ould be ok, as long as there is still a beneficial overall reduction in con= trol plane state and processing. > > >> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary a= nd a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform S= R in an IPv6 network. > > >> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may al= so create some opportunities to leverage IPv4 support in existing protocols= to suite carrying and processing 32 bit SIDs with some, possibly slight, m= odification. For example, perhaps IPv4 Address Family support in OSPFv3 (RF= C 5838) could be somehow leveraged to suit SR. > > >> > > >> Regards, > > >> Mark. > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf......org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_BYAPR05MB424592955BF0177DBFFC87F8AE270BYAPR05MB4245namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ji= m,

=  

Thank= s for asking this insightful question. The answer depends on the SID type.<= o:p>

=  

Some = service SIDs (e.g., END.DX4, END.DX6, END.DT4, END.DT6) are processed only = in the following conditions:

=  

  • When there is no SRH
  • When there is an SRH and Segments Left is = equal to 0

=  

Such = SIDs should be encoded in the Destination Options header that immediately p= recedes the upper-layer header. This is because the Destination Options hea= der that immediately precedes the upper-layer header is only processed when:

=  

  • When there is no SRH
  • When there is an SRH and Segments Left is = equal to 0

=  

Moreo= ver, Destination options are of variable length. So, each SID can be as lon= g or short as it needs to be. One SID type can be long while another is sho= rt and neither needs to be the same length as SIDs that are encoded in the IPv6 Routing header.

=  

The V= PN Context Information Option [draft-bonica-6man-vpn-dest-opt] is an exampl= e of such an encoding. It serves the same purpose as many of the SID define= d in draft-filsfils-spring-srv6-network-programming (e.g., END.DX4, END.DX6, END.DT4, END.DT6). As more service SIDs of this t= ype are identified, more destination options will be defined.

=  

Other= Service SIDs can be processed when an SRH is present and Segments Left is = greater than zero. Ideally, these SIDs should be encoded in the Destination= Options Header that immediately precedes the Routing header. This is because the Destination Options Header that im= mediately precedes the Routing header is processed by every segment endpoin= t. Draft-bonica-6man-seg-end-opt offers one such encoding scheme, but it is= not the only one.

=  

Anoth= er possibility is to encode these SIDs the Destination Options header that = immediately precedes the upper-layer header and required Service Function I= nstances that support these SIDs to look ahead.

=  

=  

 = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   Ron

=  

=  

 

Juniper Internal=

From: James N Guichard <james.n.guichard@h= uawei.com>
Sent: Thursday, April 18, 2019 5:57 PM
To: Ron Bonica <rbonica@juniper.net>; Robert Raszuk <robert= @raszuk.net>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci= <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>; Jam= es N Guichard <james.n.guichard@huawei.com>
Subject: RE: [spring] IPv6-compressed-routing-header-crh<= /p>

 

Hi Ron,

 

I am wondering about h= ow do you plan to handle service SIDs (or any SID with embedded functions) = at intermediate nodes; draft-bonica-6man-vpn-dest-opt seems to only handle = the case where the endpoint will process the destination option:

 

Section 4 says: “It MUST NOT appear in a Hop-by-ho= p Options header and SHOULD NOT appear in a Destination Options header that= precedes a Routing header”.

 

If you rel= ax the latter and encode the SID in a destination option preceding the CRH = (or SRH) then wouldn’t every node in the segment-list have to process= the SID and figure out whether it is a local SID or not? That would seem to be overly complex given you could just enco= de the SID in the CRH (or SRH) and only the node where said SID is exposed = would process it.

 = ;

Thanks!

 = ;

Jim

 

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica
Sent: Thursday, April 18, 2019 4:30 PM
To: Robert Raszuk <robert@ra= szuk.net>
Cc: SPRING WG <spring@ietf.org= >; ipv6@ietf.org; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>
Subject: RE: [spring] IPv6-compressed-routing-header-crh<= /p>

 

Rober= t,

=  

The C= ompressed Routing Header (CRH) has exactly one function. That is to route a= packet for segment to segment along an SR path. Therefore, SIDs contained = by the CRH have only one function. That is to steer packets to the next segment.

=  

Grant= ed, we may want to program a service behavior at a segment endpoint. IPv6 i= ncludes a Destination Options header that can be used to convey information= segment endpoints and destination options can contain service SIDs. These service SIDs can be as long or short as th= ey need to be. See draft-bonica-6man-vpn-dest-opt for an example.

=  

 = ;            &n= bsp;            = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p; Ron

=  

 

Juniper Internal=

From: Robert Raszuk <robert@raszuk.net>
Sent: Thursday, April 18, 2019 10:30 AM
To: Ron Bonica <rbonica@ju= niper.net>
Cc: Gyan Mishra <hayabus= agsm@gmail.com>; Tom Herbert <tom@herbertland.com>; SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

Hi Ron,

 

I must observe that your analysis is incorrect. = ;

 

SIDs are not only used for TE or traffic steering pu= rposes but what is even more interesting for various functions - for exampl= e NFV. 

 

So you need as much SIDs as possible imagination of = your value add network functions - which will be different from those funct= ions at the encap dst which as you indicate in other draft can be carried i= n destination options. 

 

That debate is still I think open. <= /p>

 

Thx,

R.

 

 

On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica <rbonica@juniper.net> wrote:

Gyan,

 <= /o:p>

Let’s think a= bout how a network operator might choose a SID size….

 <= /o:p>

Assume that an MAN = includes 100 routers. These routers are connected to one another by infrast= ructure links. Each router has 20 or fewer infrastructure links.

 <= /o:p>

The network operato= r might assign one loosely routes SID to each router. These loosely routed = SIDs have network-wide significance (i.e., the cannot be reused).

 <= /o:p>

The network operato= r might also assign one strictly routed SID to each link. The strictly rout= ed SIDs have node-local significance only. They can be reused from one node to another.

 <= /o:p>

So, in this case, t= he network operator only needs 120 SIDs. This fits in eight bits with plent= y of room for growth.

 <= /o:p>

Now consider anothe= r network that includes 30,000 routers. Each router is connected to its pee= rs by 200 infrastructure links or fewer.  This network would need 30,200 SIDs. This would fit in 16 bits.

 <= /o:p>

A *really big* network might require more than 32,000 SIDs. So, we support a 32-bit SID= ...

 <= /o:p>

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Ron

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

Juniper Internal=

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Wednesday, April 17, 2019 10:00 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>; Tom Herbert <tom@herbertland.com>; SPRING WG &l= t;spring@ietf.org&= gt;; ipv6@ietf.org; Dino = Farinacci <fari= nacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

 

I agree to make the SID align on word boundaries but I am thinking= the software should have hardware independence if at all possible.

 

I think 32 bit is a reasonable size.

 

 

Gyan S. Mishra

IT Network Engineering & Technology Consultant

Routing & Switching / Service Provider MPLS & IPv6 Expert<= o:p>

Mobile – 202-734-1000

 

Sent from my iPhone


On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=3D40juniper.net@dmarc.= ietf.org> wrote:

Hi Robert,

 <= /o:p>

In order to make th= e CRH ASIC-friendly, we have the following constraints:

 <= /o:p>

  • Support only a small handful of SID length= s
  • If at all possible, make them align on wor= d boundaries

 <= /o:p>

Currently, we suppo= rt 8, 16 and 32 bytes. Do you see a reason why we should support a length g= reater than 32? Is there some length less than 32 that would be beneficial?

 <= /o:p>

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            Ron

 <= /o:p>

 <= /o:p>

 

Juniper Internal=

From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <tom@herbertland.com>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Mark = Smith <markz= zzsmith@gmail.com>; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh<= /p>

 

Hi Tom,

 

I already suggested this on March 30th ... 

 

"PS. But if you choose to go ahead with CRH I would highly advise to = make your CRH SID a variable length. "

 

No feedba= ck/response was received from authors. 

 

Thx,
R.

 

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:<= o:p>

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.com> wro= te:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote: > > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform SR i= n an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network elements on a per flow basis without actually per flo= w or per path signalling or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not require a= ny new mapping plane to be distributed in control plane and to be inserted = into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comm= ents. Note also work for integrating SRv6 with LISP which is already is pub= lished.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new  f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. Can y= ou
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID size > for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable to > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's own= TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequate = to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leverage= d to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf= ......org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------

------------------------------------------------------------------= --
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--_000_BYAPR05MB424592955BF0177DBFFC87F8AE270BYAPR05MB4245namp_-- From nobody Fri Apr 19 00:31:37 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C26C1203EC for ; Fri, 19 Apr 2019 00:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 RtUbc8sV2P1X for ; Fri, 19 Apr 2019 00:31:12 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 9698B1200E3 for ; Fri, 19 Apr 2019 00:31:07 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id w5so4771259qtb.11 for ; Fri, 19 Apr 2019 00:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=odSC6jtuYzqadV5kIKzbbeg2FT5UpszIc2cipPe3fls=; b=IiQu23EqSg5K90hRl6UXQmv7Xux9x1N1NQM1EthObAqQar3ICTukbqmIt78k/OfwGw 5fR6hFn1jOfIPHg3Jzc82jhnS/LugCavQEnzTGKpDcBp2MduJOlerW05F09zNh2nT5Yt 8QmhSFtrRFZ6EVppmt/TOUu3hpr7gJPCYLDaUvfkG11CybjCdb4q+BV6nlIsoBazrqRX mf2dQSssY5Xhc2NhAxF/LAZ9NGdw43fDjOuZj+UII+/0HhAVS7RDgJ5mqN/ocVo57aw8 pYCX8kpAzYqtrwp83iUDQi7YNUpTloBoehnRwv21fx7nub2yEAaQtGd69V3f2MaJs34p uwBQ== 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=odSC6jtuYzqadV5kIKzbbeg2FT5UpszIc2cipPe3fls=; b=rZH0ZlT5g1v/fbgctvM1miOEjUKKiyMAKy/Mtc4U5x01Xnfbn3SShPdi694Qkl/OYh dkkFw14ZoPLROi9cDMjn26dLq+5FU2pHEF8tV0h5lBma7/510btdNiGB06nRrMLxiR/j zQMoIOtVXzIVggGLQffZihprc9ol5Cp8ZOZ394eCb5VLHwZ1Lpudel5SjCgjA01ZQufx dbKr5KPJ4r+o/WLwfCgfAXasDXBJUyTDObiGiI5y57OOQ9cfS164ePkIYwuHCVCuSAtg OXnW6VCOv78jeNvoXrTdId/gvKiJVYgTZs0FSZj4QNbXWRO1PFYCr1WeSOVIiQjEOjvn hDQA== X-Gm-Message-State: APjAAAVn6+vhY8IhDmbnusHYu69bWb/bxkM4jkIRQk4LTB3qktnYjHCi 9VafC/Urmra/AyvurNsOPb975FquKitSino8iU/yjw== X-Google-Smtp-Source: APXvYqzMSkUJfUkU4a5+KwNXvlVheB2WwpUVo7849dQvf52Qs+sg/TYlbL89D+idYL3U7T4kiXbeV4HJyIY6s4wSjiI= X-Received: by 2002:ac8:fb0:: with SMTP id b45mr2160270qtk.293.1555659066432; Fri, 19 Apr 2019 00:31:06 -0700 (PDT) MIME-Version: 1.0 References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> In-Reply-To: From: Robert Raszuk Date: Fri, 19 Apr 2019 09:30:56 +0200 Message-ID: To: Ron Bonica Cc: James N Guichard , SPRING WG , "ipv6@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="0000000000000bf5fd0586dd1a12" Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 07:31:23 -0000 --0000000000000bf5fd0586dd1a12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And what happens - - When there is an SRH and Segments Left is *not* equal to 0 ? On Fri, Apr 19, 2019 at 4:53 AM Ron Bonica wrote: > Hi Jim, > > > > Thanks for asking this insightful question. The answer depends on the SID > type. > > > > Some service SIDs (e.g., END.DX4, END.DX6, END.DT4, END.DT6) are processe= d > only in the following conditions: > > > > - When there is no SRH > - When there is an SRH and Segments Left is equal to 0 > > > > Such SIDs should be encoded in the Destination Options header that > immediately precedes the upper-layer header. This is because the > Destination Options header that immediately precedes the upper-layer head= er > is only processed when: > > > > - When there is no SRH > - When there is an SRH and Segments Left is equal to 0 > > > > Moreover, Destination options are of variable length. So, each SID can be > as long or short as it needs to be. One SID type can be long while anothe= r > is short and neither needs to be the same length as SIDs that are encoded > in the IPv6 Routing header. > > > > The VPN Context Information Option [draft-bonica-6man-vpn-dest-opt] is an > example of such an encoding. It serves the same purpose as many of the SI= D > defined in draft-filsfils-spring-srv6-network-programming (e.g., END.DX4, > END.DX6, END.DT4, END.DT6). As more service SIDs of this type are > identified, more destination options will be defined. > > > > Other Service SIDs can be processed when an SRH is present and Segments > Left is greater than zero. Ideally, these SIDs should be encoded in the > Destination Options Header that immediately precedes the Routing header. > This is because the Destination Options Header that immediately precedes > the Routing header is processed by every segment endpoint. > Draft-bonica-6man-seg-end-opt offers one such encoding scheme, but it is > not the only one. > > > > Another possibility is to encode these SIDs the Destination Options heade= r > that immediately precedes the upper-layer header and required Service > Function Instances that support these SIDs to look ahead. > > > > > > > Ron > > > > > > > > Juniper Internal > > *From:* James N Guichard > *Sent:* Thursday, April 18, 2019 5:57 PM > *To:* Ron Bonica ; Robert Raszuk > *Cc:* SPRING WG ; ipv6@ietf.org; Dino Farinacci < > farinacci@gmail.com>; lisp@ietf.org list ; James N > Guichard > *Subject:* RE: [spring] IPv6-compressed-routing-header-crh > > > > Hi Ron, > > > > I am wondering about how do you plan to handle service SIDs (or any SID > with embedded functions) at intermediate nodes; > draft-bonica-6man-vpn-dest-opt seems to only handle the case where the > endpoint will process the destination option: > > > > Section 4 says: =E2=80=9CIt MUST NOT appear in a Hop-by-hop Options heade= r and > SHOULD NOT appear in a Destination Options header that precedes a Routing > header=E2=80=9D. > > > > If you relax the latter and encode the SID in a destination option > preceding the CRH (or SRH) then wouldn=E2=80=99t every node in the segmen= t-list > have to process the SID and figure out whether it is a local SID or not? > That would seem to be overly complex given you could just encode the SID = in > the CRH (or SRH) and only the node where said SID is exposed would proces= s > it. > > > > Thanks! > > > > Jim > > > > *From:* ipv6 [mailto:ipv6-bounces@ietf.org ] *On > Behalf Of *Ron Bonica > *Sent:* Thursday, April 18, 2019 4:30 PM > *To:* Robert Raszuk > *Cc:* SPRING WG ; ipv6@ietf.org; Dino Farinacci < > farinacci@gmail.com>; lisp@ietf.org list > *Subject:* RE: [spring] IPv6-compressed-routing-header-crh > > > > Robert, > > > > The Compressed Routing Header (CRH) has exactly one function. That is to > route a packet for segment to segment along an SR path. Therefore, SIDs > contained by the CRH have only one function. That is to steer packets to > the next segment. > > > > Granted, we may want to program a service behavior at a segment endpoint. > IPv6 includes a Destination Options header that can be used to convey > information segment endpoints and destination options can contain service > SIDs. These service SIDs can be as long or short as they need to be. See > draft-bonica-6man-vpn-dest-opt for an example. > > > > > Ron > > > > > > Juniper Internal > > *From:* Robert Raszuk > *Sent:* Thursday, April 18, 2019 10:30 AM > *To:* Ron Bonica > *Cc:* Gyan Mishra ; Tom Herbert < > tom@herbertland.com>; SPRING WG ; ipv6@ietf.org; Dino > Farinacci ; lisp@ietf.org list > *Subject:* Re: [spring] IPv6-compressed-routing-header-crh > > > > Hi Ron, > > > > I must observe that your analysis is incorrect. > > > > SIDs are not only used for TE or traffic steering purposes but what is > even more interesting for various functions - for example NFV. > > > > So you need as much SIDs as possible imagination of your value add networ= k > functions - which will be different from those functions at the encap dst > which as you indicate in other draft can be carried in destination option= s. > > > > That debate is still I think open. > > > > Thx, > > R. > > > > > > On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica wrote: > > Gyan, > > > > Let=E2=80=99s think about how a network operator might choose a SID size= =E2=80=A6. > > > > Assume that an MAN includes 100 routers. These routers are connected to > one another by infrastructure links. Each router has 20 or fewer > infrastructure links. > > > > The network operator might assign one loosely routes SID to each router. > These loosely routed SIDs have network-wide significance (i.e., the canno= t > be reused). > > > > The network operator might also assign one strictly routed SID to each > link. The strictly routed SIDs have node-local significance only. They ca= n > be reused from one node to another. > > > > So, in this case, the network operator only needs 120 SIDs. This fits in > eight bits with plenty of room for growth. > > > > Now consider another network that includes 30,000 routers. Each router is > connected to its peers by 200 infrastructure links or fewer. This networ= k > would need 30,200 SIDs. This would fit in 16 bits. > > > > A **really big** network might require more than 32,000 SIDs. So, we > support a 32-bit SID... > > > > > Ron > > > > > > > > > > Juniper Internal > > *From:* Gyan Mishra > *Sent:* Wednesday, April 17, 2019 10:00 PM > *To:* Ron Bonica > *Cc:* Robert Raszuk ; Tom Herbert ; > SPRING WG ; ipv6@ietf.org; Dino Farinacci < > farinacci@gmail.com>; lisp@ietf.org list > *Subject:* Re: [spring] IPv6-compressed-routing-header-crh > > > > > > I agree to make the SID align on word boundaries but I am thinking the > software should have hardware independence if at all possible. > > > > I think 32 bit is a reasonable size. > > > > > > Gyan S. Mishra > > IT Network Engineering & Technology Consultant > > Routing & Switching / Service Provider MPLS & IPv6 Expert > > www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT > > > Mobile =E2=80=93 202-734-1000 > > > > Sent from my iPhone > > > On Apr 14, 2019, at 7:54 PM, Ron Bonica < > rbonica=3D40juniper.net@dmarc.ietf.org> wrote: > > Hi Robert, > > > > In order to make the CRH ASIC-friendly, we have the following constraints= : > > > > - Support only a small handful of SID lengths > - If at all possible, make them align on word boundaries > > > > Currently, we support 8, 16 and 32 bytes. Do you see a reason why we > should support a length greater than 32? Is there some length less than 3= 2 > that would be beneficial? > > > > Ron > > > > > > > > Juniper Internal > > *From:* spring *On Behalf Of *Robert Raszuk > *Sent:* Friday, April 12, 2019 6:13 PM > *To:* Tom Herbert > *Cc:* SPRING WG ; ipv6@ietf.org; Mark Smith < > markzzzsmith@gmail.com>; Dino Farinacci ; > lisp@ietf.org list > *Subject:* Re: [spring] IPv6-compressed-routing-header-crh > > > > Hi Tom, > > > > I already suggested this on March 30th ... > > > > *"**PS. But if you choose to go ahead with CRH I would highly advise to > make your CRH SID a variable length. "* > > > > No feedback/response was received from authors. > > > > Thx, > R. > > > > On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert wrote: > > On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrote= : > > > > Hi Tom, > > > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: > > > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk > wrote: > > > > > > > > Hi Mark, > > > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundar= y > and a 32 bit alignment, > > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 > network. > > > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may > also create some opportunities to > > > > > leverage IPv4 support in existing protocols to suite carrying and > processing 32 bit SIDs with some, possibly > > > > > slight, modification. For example, perhaps IPv4 Address Family > support in OSPFv3 (RFC 5838) could be > > > > > somehow leveraged to suit SR. > > > > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > > > I think SR while indeed started with the story of "less control > plane is good for you" now clearly has evolved into not only reduction of > control plane but what can be even more important to some users ability t= o > request specific behavior via programmed functions of network elements on= a > per flow basis without actually per flow or per path signalling or state. > > > > > > > > Yes for some it may be very useful feature and I am sure some will > call it overload of data plane or . There is no one size fits all. > > > > > > > > With that let's observe that till today SR did not require any new > mapping plane to be distributed in control plane and to be inserted into > data plane. This is clearly a precedent. > > > > > > > > Furthermore as we see in companion documents all additional network > functionality is being taken away from SRH and is being shifted to > Destination Options . > > > > > > > > As far as mapping plane I already pointed out in my Vector Routing > proposal that we have one already it is called BGP. One needs to also > observe that we as industry worked number of years of protocol suite call= ed > LISP allowing not only very good mapping plane, but also data plane > integration. CC-ing lisp authors for their comments. Note also work for > integrating SRv6 with LISP which is already is published. > > > > > > > > Since you correctly observed that now SID can be 32 bit and that is > similar to the size of IPv4 my fundamental question is why not use > something which already exists instead of defining some sort of new from > scratch ? > > > > > > > Robert, > > > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > > please provide a reference? > > > > > > > To clarify, I've been thinking about the idea of a smaller SID size > > for IPv6 for a while now (since inserting EHs came up), and thought > > about what would be a generic single size that might suit SR that > > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > > me, although if people wanted bigger, I'd be suggesting 64 bits (not > > entirely coincidentally the common IID size.) > > > > Ron and others have written this draft, which supports SIDS of various > > sizes - 8, 16 or 32 bits - that triggered this discussion. > > > Mark, > > Why not just put a SID length field in the header (like RFC6554 but > more generic). That would allow lengths of 1-16 bytes. Additional > flags could be used to indicate the semantics of the entries. For > instance, they might be actual addresses (128 bits for IPv6, 32 bits > for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) > where the rest of the address can be inferred, indices into a table, > labels, etc. > > Tom > > > "The IPv6 Compressed Routing Header (CRH)" > > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > > > > Regards, > > Mark. > > > > > > > As for trying to use something that already exists, why does SR used = a > > > fixed size format for SIDs instead of a variable length format like > > > that described in RFC6554? Similarly, why does SR define it's own TLV > > > format instead of using Hop-by-Hop and Destination Options defined in > > > RFC8200? > > > > > > Tom > > > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LIS= P > or Vector Routing as an alternative options. I really do not see a room o= r > need for yet one more mapping plane. What problem does it solve which wou= ld > not be already solved elsewhere ? > > > > > > > > Kind regards, > > > > Robert > > > > > > > > > > > >>> 2) Is there an agreement that solutions which require additional > per SR path state in both control plane and now in data plane are really > something we should be endorsing here ? > > > >> > > > >> > > > >> I think so. > > > >> > > > >> My understanding of what SR is fundamentally about is to reduce > control plane state and processing. The trade-off for reduced control pla= ne > state and processing is to instead carry and encode most or all of that > information or its semantics as per-packet overhead. > > > >> > > > >> If the per-packet overhead becomes too large and expensive, then > pushing some of that information and processing back into the control pla= ne > should be ok, as long as there is still a beneficial overall reduction in > control plane state and processing. > > > >> > > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary > and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perfor= m > SR in an IPv6 network. > > > >> > > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may > also create some opportunities to leverage IPv4 support in existing > protocols to suite carrying and processing 32 bit SIDs with some, possibl= y > slight, modification. For example, perhaps IPv4 Address Family support in > OSPFv3 (RFC 5838) could be somehow leveraged to suit SR. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > -------------------------------------------------------------------= - > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf......org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > -------------------------------------------------------------------= - > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > --0000000000000bf5fd0586dd1a12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000003643be05870f99ae--

And what happens -=C2=A0

  • When there is an SRH and Segments Left is not eq= ual to 0 ?=C2=A0


On Fri, Apr 19, 2019 at 4:53 AM Ron Bonica <rbonica@juniper.net> wrote:

= Hi Jim,

= =C2=A0

= Thanks for asking this insightful question. The answer depends on the SID t= ype.

= =C2=A0

= Some service SIDs (e.g., END.DX4, END.DX6, END.DT4, END.DT6) are processed = only in the following conditions:

= =C2=A0

  • When there is no SRH
  • When there is an SRH and Segments Left is eq= ual to 0

= =C2=A0

= Such SIDs should be encoded in the Destination Options header that immediat= ely precedes the upper-layer header. This is because the Destination Option= s header that immediately precedes the upper-layer header is only processed when:

= =C2=A0

  • When there is no SRH
  • When there is an SRH and Segments Left is eq= ual to 0

= =C2=A0

= Moreover, Destination options are of variable length. So, each SID can be a= s long or short as it needs to be. One SID type can be long while another i= s short and neither needs to be the same length as SIDs that are encoded in the IPv6 Routing header.<= /span>

= =C2=A0

= The VPN Context Information Option [draft-bonica-6man-vpn-dest-opt] is an e= xample of such an encoding. It serves the same purpose as many of the SID d= efined in draft-filsfils-spring-srv6-network-programming (e.g., END.DX4, END.DX6, END.DT4, END.DT6). As more service SIDs of this t= ype are identified, more destination options will be defined.=

= =C2=A0

= Other Service SIDs can be processed when an SRH is present and Segments Lef= t is greater than zero. Ideally, these SIDs should be encoded in the Destin= ation Options Header that immediately precedes the Routing header. This is because the Destination Options Header that im= mediately precedes the Routing header is processed by every segment endpoin= t. Draft-bonica-6man-seg-end-opt offers one such encoding scheme, but it is= not the only one.

= =C2=A0

= Another possibility is to encode these SIDs the Destination Options header = that immediately precedes the upper-layer header and required Service Funct= ion Instances that support these SIDs to look ahead.

= =C2=A0

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Ron

= =C2=A0

= =C2=A0

=C2=A0

Juniper Internal

From: James N Guichard <james.n.guichard@huawei.com<= /a>>
Sent: Thursday, April 18, 2019 5:57 PM
To: Ron Bonica <rbonica@juniper.net>; Robert Raszuk <robert@raszuk.net>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>; James N Guichard <= ;james.n.g= uichard@huawei.com>
Subject: RE: [spring] IPv6-compressed-routing-header-crh

=C2=A0

Hi Ron,<= u>

=C2=A0

I am wondering = about how do you plan to handle service SIDs (or any SID with embedded func= tions) at intermediate nodes; draft-bonica-6man-vpn-dest-opt seems to only = handle the case where the endpoint will process the destination option:

=C2=A0

Section 4 says: =E2=80=9CIt MUST NOT appear in a = Hop-by-hop Options header and SHOULD NOT appear in a Destination Options he= ader that precedes a Routing header=E2=80=9D.

=C2=A0

If = you relax the latter and encode the SID in a destination option preceding t= he CRH (or SRH) then wouldn=E2=80=99t every node in the segment-list have t= o process the SID and figure out whether it is a local SID or not? That would seem to be overly complex given you could just enco= de the SID in the CRH (or SRH) and only the node where said SID is exposed = would process it.

= =C2=A0

Tha= nks!

= =C2=A0

Jim=

=C2=A0

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica
Sent: Thursday, April 18, 2019 4:30 PM
To: Robert Raszuk <robert@raszuk.net>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: RE: [spring] IPv6-compressed-routing-header-crh

=C2=A0

= Robert,

= =C2=A0

= The Compressed Routing Header (CRH) has exactly one function. That is to ro= ute a packet for segment to segment along an SR path. Therefore, SIDs conta= ined by the CRH have only one function. That is to steer packets to the next segment.

= =C2=A0

= Granted, we may want to program a service behavior at a segment endpoint. I= Pv6 includes a Destination Options header that can be used to convey inform= ation segment endpoints and destination options can contain service SIDs. These service SIDs can be as long or short as th= ey need to be. See draft-bonica-6man-vpn-dest-opt for an example.=

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Ron

= =C2=A0

=C2=A0

Juniper Internal

From: Robert Raszuk <robert@raszuk.net>
Sent: Thursday, April 18, 2019 10:30 AM
To: Ron Bonica <rbonica@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Tom Herbert <tom@herbertland.com>; SPRIN= G WG <spring@ietf.o= rg>; ipv6@ietf.org; Dino = Farinacci <fari= nacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh

=C2=A0

Hi Ron,

=C2=A0

I must observe that your analysis is incorrect.=C2= =A0

=C2=A0

SIDs are not only used for TE or traffic steering pu= rposes but what is even more interesting for various functions - for exampl= e NFV.=C2=A0

=C2=A0

So you need as much SIDs as possible imagination of = your value add network functions - which will be different from those funct= ions at the encap dst which as you indicate in other draft can be carried i= n destination options.=C2=A0

=C2=A0

That debate is still I think open.=C2=A0

=C2=A0

Thx,

R.

=C2=A0

=C2=A0

On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica <rbonica@juniper.net= > wrote:

= Gyan,

= =C2=A0

= Let=E2=80=99s think about how a network operator might choose a SID size=E2= =80=A6.

= =C2=A0

= Assume that an MAN includes 100 routers. These routers are connected to one= another by infrastructure links. Each router has 20 or fewer infrastructure links.

= =C2=A0

= The network operator might assign one loosely routes SID to each router. Th= ese loosely routed SIDs have network-wide significance (i.e., the cannot be reused).

= =C2=A0

= The network operator might also assign one strictly routed SID to each link= . The strictly routed SIDs have node-local significance only. They can be reused from one node to another.

= =C2=A0

= So, in this case, the network operator only needs 120 SIDs. This fits in ei= ght bits with plenty of room for growth.

= =C2=A0

= Now consider another network that includes 30,000 routers. Each router is c= onnected to its peers by 200 infrastructure links or fewer.=C2=A0 This network would need 30,200 SIDs. This would fit in 16 bits.<= /u>

= =C2=A0

= A *really big* network might require more than 32,000 SIDs. So, we s= upport a 32-bit SID...

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Ron

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0

Juniper Internal

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Wednesday, April 17, 2019 10:00 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>; Tom Herbert <tom@herbertland.com>; SPRING WG &l= t;spring@ietf.org&= gt;; ipv6@ietf.org; Dino = Farinacci <fari= nacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh

=C2=A0

=C2=A0

I agree to make the SID align on word boundaries but= I am thinking the software should have hardware independence if at all pos= sible.

=C2=A0

I think 32 bit is a reasonable size.

=C2=A0

=C2=A0

Gyan S. Mishra

IT Network Engineering & Technology Consultant

Routing & Switching / Service Provider MPLS &= ; IPv6 Expert

Mobile =E2=80=93=C2=A0202-734-1000

=C2=A0

Sent from my iPhone


On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=3D40juniper.net@dmarc.= ietf.org> wrote:

= Hi Robert,

= =C2=A0

= In order to make the CRH ASIC-friendly, we have the following constraints:<= /span>

= =C2=A0

  • Support only a small handful of SID lengths<= /span>
  • If at all possible, make them align on word = boundaries

= =C2=A0

= Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should= support a length greater than 32? Is there some length less than 32 that would be beneficial?

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Ron

= =C2=A0

= =C2=A0

=C2=A0

Juniper Internal

From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <tom@herbertland.com>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Mark = Smith <markz= zzsmith@gmail.com>; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh

=C2=A0

Hi Tom,

=C2=A0

I already suggested this on March 30th ...=C2=A0<= /u>

=C2=A0

"PS. But if you choose to go ahead with CRH I would highly advise t= o make your CRH SID a variable length. "

=C2=A0

No feed= back/response was received from authors.=C2=A0

=C2=A0

Thx, R.

=C2=A0

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.c= om> wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote: > > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform = SR in an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network elements on a per flow basis without actually per flo= w or per path signalling or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not requi= re any new mapping plane to be distributed in control plane and to be inser= ted into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comm= ents. Note also work for integrating SRv6 with LISP which is already is pub= lished.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new=C2=A0 f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. C= an you
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID siz= e
> for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable t= o
> me, although if people wanted bigger, I'd be suggesting 64 bits (n= ot
> entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's= own TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequ= ate to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leverage= d to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf= ......org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------

----------------------------------------------------= ----------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------=

--0000000000000bf5fd0586dd1a12-- From nobody Fri Apr 19 03:44:03 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3D8120133 for ; Fri, 19 Apr 2019 03:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, 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=raszuk.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 tf0R2hChaqy6 for ; Fri, 19 Apr 2019 03:43:57 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 B1949120130 for ; Fri, 19 Apr 2019 03:43:56 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id v20so5125739qtv.12 for ; Fri, 19 Apr 2019 03:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YP3moLOYu8YJg/+V7AUNrKaeBTJf9MPBIMPU9upUwIo=; b=fUvpXscN7b7OcGImr61HM5PdSAYd39wCXu60AzeoXgJGqUriluuxYSa664BJI/pE5n cdUQtXvEqnzgQKKIMIJS40qmNtl1AosWGt9YELUxeKigsoPrtw8+UwEDx6pmnCqUYJzi HOpT9kcFh7fzQa9yyneQcb5a7Ufqz6y8i6OLbgelkiz2gZqB5G8EL3Hje+zyL+PRBd9R GWi71+xNoTgDbPE9/e5DzZLFpvTAKUTt0pgkEQKwW1bdfOZIq9LtWaRg0+RakqUir281 auePKFECIv+rY7+6mu8kxjXjYUpnQZqutX8XUj3TVV6HGRYX9YFxIqtvTQ90TsMqUXLA dkzA== 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=YP3moLOYu8YJg/+V7AUNrKaeBTJf9MPBIMPU9upUwIo=; b=A6f1j/su86fgMTWnZ11RjThmhUpChQQz93mGWYyCXWBIJaD9N62KmNBhyPRM969VNo faYTf4cJgj8PaYKNvv5CgicgWibXRmypds4wxWZKqolmqGXj+1nHIEtGB3aV3M7Zei3h O5N8pdZ9EcKpyJCilluljUrp+FnX1AcSkSPQnPrAsppq4bwkJPfDAoDTinY6twQ1w18t jAflvRpW7YxXUI76pEYCXoIKeEZ8TzmPr0KrIf+Xs2m0OOP7j6oZXznD7wpebmd4OWE8 mO11tE9Z/YsONFoc7f4LZk9Viag3DxSOQnhNjbQmLxaKhbB8ZEe4xalxW+8AgbXJkMIq 9dtA== X-Gm-Message-State: APjAAAVA8+ir6OfHn3zTxtSprILY/P7X/+SJ64Qoi1Ra71aBz8IsrrkJ +kgqvpP+wuUgHgOA/TCmpyZRRCvpXh7Jbm0oSvVOEw== X-Google-Smtp-Source: APXvYqwGqVO206RaoHYt6vGUy06ZKbkqPV3q1b8ygsRRrcLyZ8u5Ohsb+3i/biR01xhmEh7zP1c2UhyIhbpwqzSkjcg= X-Received: by 2002:a0c:949c:: with SMTP id j28mr2854048qvj.18.1555670635586; Fri, 19 Apr 2019 03:43:55 -0700 (PDT) MIME-Version: 1.0 References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> In-Reply-To: From: Robert Raszuk Date: Fri, 19 Apr 2019 12:43:41 +0200 Message-ID: To: Ron Bonica Cc: James N Guichard , SPRING WG , "ipv6@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Type: multipart/alternative; boundary="0000000000009f3e650586dfcbd4" Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 10:44:02 -0000 --0000000000009f3e650586dfcbd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Specifically how do you associate different service functions encoded in Dest. Options with specific segments for selective execution ? Hint: Execution of all encoded and carried from src or edge of the network service instructions in destinations options at each SR node is not an option. Do you now duplicate each SID into Dest Options to be able to choose which service is executed in which of the entire path's mid point ? Many thx, Robert. On Fri, Apr 19, 2019 at 9:30 AM Robert Raszuk wrote: > > And what happens - > > > - When there is an SRH and Segments Left is *not* equal to 0 ? > > > > On Fri, Apr 19, 2019 at 4:53 AM Ron Bonica wrote: > >> Hi Jim, >> >> >> >> Thanks for asking this insightful question. The answer depends on the SI= D >> type. >> >> >> >> Some service SIDs (e.g., END.DX4, END.DX6, END.DT4, END.DT6) are >> processed only in the following conditions: >> >> >> >> - When there is no SRH >> - When there is an SRH and Segments Left is equal to 0 >> >> >> >> Such SIDs should be encoded in the Destination Options header that >> immediately precedes the upper-layer header. This is because the >> Destination Options header that immediately precedes the upper-layer hea= der >> is only processed when: >> >> >> >> - When there is no SRH >> - When there is an SRH and Segments Left is equal to 0 >> >> >> >> Moreover, Destination options are of variable length. So, each SID can b= e >> as long or short as it needs to be. One SID type can be long while anoth= er >> is short and neither needs to be the same length as SIDs that are encode= d >> in the IPv6 Routing header. >> >> >> >> The VPN Context Information Option [draft-bonica-6man-vpn-dest-opt] is a= n >> example of such an encoding. It serves the same purpose as many of the S= ID >> defined in draft-filsfils-spring-srv6-network-programming (e.g., END.DX4= , >> END.DX6, END.DT4, END.DT6). As more service SIDs of this type are >> identified, more destination options will be defined. >> >> >> >> Other Service SIDs can be processed when an SRH is present and Segments >> Left is greater than zero. Ideally, these SIDs should be encoded in the >> Destination Options Header that immediately precedes the Routing header. >> This is because the Destination Options Header that immediately precedes >> the Routing header is processed by every segment endpoint. >> Draft-bonica-6man-seg-end-opt offers one such encoding scheme, but it is >> not the only one. >> >> >> >> Another possibility is to encode these SIDs the Destination Options >> header that immediately precedes the upper-layer header and required >> Service Function Instances that support these SIDs to look ahead. >> >> >> >> >> >> >> Ron >> >> >> >> >> >> >> >> Juniper Internal >> >> *From:* James N Guichard >> *Sent:* Thursday, April 18, 2019 5:57 PM >> *To:* Ron Bonica ; Robert Raszuk >> *Cc:* SPRING WG ; ipv6@ietf.org; Dino Farinacci < >> farinacci@gmail.com>; lisp@ietf.org list ; James N >> Guichard >> *Subject:* RE: [spring] IPv6-compressed-routing-header-crh >> >> >> >> Hi Ron, >> >> >> >> I am wondering about how do you plan to handle service SIDs (or any SID >> with embedded functions) at intermediate nodes; >> draft-bonica-6man-vpn-dest-opt seems to only handle the case where the >> endpoint will process the destination option: >> >> >> >> Section 4 says: =E2=80=9CIt MUST NOT appear in a Hop-by-hop Options head= er and >> SHOULD NOT appear in a Destination Options header that precedes a Routin= g >> header=E2=80=9D. >> >> >> >> If you relax the latter and encode the SID in a destination option >> preceding the CRH (or SRH) then wouldn=E2=80=99t every node in the segme= nt-list >> have to process the SID and figure out whether it is a local SID or not? >> That would seem to be overly complex given you could just encode the SID= in >> the CRH (or SRH) and only the node where said SID is exposed would proce= ss >> it. >> >> >> >> Thanks! >> >> >> >> Jim >> >> >> >> *From:* ipv6 [mailto:ipv6-bounces@ietf.org ] *On >> Behalf Of *Ron Bonica >> *Sent:* Thursday, April 18, 2019 4:30 PM >> *To:* Robert Raszuk >> *Cc:* SPRING WG ; ipv6@ietf.org; Dino Farinacci < >> farinacci@gmail.com>; lisp@ietf.org list >> *Subject:* RE: [spring] IPv6-compressed-routing-header-crh >> >> >> >> Robert, >> >> >> >> The Compressed Routing Header (CRH) has exactly one function. That is to >> route a packet for segment to segment along an SR path. Therefore, SIDs >> contained by the CRH have only one function. That is to steer packets to >> the next segment. >> >> >> >> Granted, we may want to program a service behavior at a segment endpoint= . >> IPv6 includes a Destination Options header that can be used to convey >> information segment endpoints and destination options can contain servic= e >> SIDs. These service SIDs can be as long or short as they need to be. See >> draft-bonica-6man-vpn-dest-opt for an example. >> >> >> >> >> Ron >> >> >> >> >> >> Juniper Internal >> >> *From:* Robert Raszuk >> *Sent:* Thursday, April 18, 2019 10:30 AM >> *To:* Ron Bonica >> *Cc:* Gyan Mishra ; Tom Herbert < >> tom@herbertland.com>; SPRING WG ; ipv6@ietf.org; Dino >> Farinacci ; lisp@ietf.org list >> *Subject:* Re: [spring] IPv6-compressed-routing-header-crh >> >> >> >> Hi Ron, >> >> >> >> I must observe that your analysis is incorrect. >> >> >> >> SIDs are not only used for TE or traffic steering purposes but what is >> even more interesting for various functions - for example NFV. >> >> >> >> So you need as much SIDs as possible imagination of your value add >> network functions - which will be different from those functions at the >> encap dst which as you indicate in other draft can be carried in >> destination options. >> >> >> >> That debate is still I think open. >> >> >> >> Thx, >> >> R. >> >> >> >> >> >> On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica wrote: >> >> Gyan, >> >> >> >> Let=E2=80=99s think about how a network operator might choose a SID size= =E2=80=A6. >> >> >> >> Assume that an MAN includes 100 routers. These routers are connected to >> one another by infrastructure links. Each router has 20 or fewer >> infrastructure links. >> >> >> >> The network operator might assign one loosely routes SID to each router. >> These loosely routed SIDs have network-wide significance (i.e., the cann= ot >> be reused). >> >> >> >> The network operator might also assign one strictly routed SID to each >> link. The strictly routed SIDs have node-local significance only. They c= an >> be reused from one node to another. >> >> >> >> So, in this case, the network operator only needs 120 SIDs. This fits in >> eight bits with plenty of room for growth. >> >> >> >> Now consider another network that includes 30,000 routers. Each router i= s >> connected to its peers by 200 infrastructure links or fewer. This netwo= rk >> would need 30,200 SIDs. This would fit in 16 bits. >> >> >> >> A **really big** network might require more than 32,000 SIDs. So, we >> support a 32-bit SID... >> >> >> >> >> Ron >> >> >> >> >> >> >> >> >> >> Juniper Internal >> >> *From:* Gyan Mishra >> *Sent:* Wednesday, April 17, 2019 10:00 PM >> *To:* Ron Bonica >> *Cc:* Robert Raszuk ; Tom Herbert ; >> SPRING WG ; ipv6@ietf.org; Dino Farinacci < >> farinacci@gmail.com>; lisp@ietf.org list >> *Subject:* Re: [spring] IPv6-compressed-routing-header-crh >> >> >> >> >> >> I agree to make the SID align on word boundaries but I am thinking the >> software should have hardware independence if at all possible. >> >> >> >> I think 32 bit is a reasonable size. >> >> >> >> >> >> Gyan S. Mishra >> >> IT Network Engineering & Technology Consultant >> >> Routing & Switching / Service Provider MPLS & IPv6 Expert >> >> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT >> >> >> Mobile =E2=80=93 202-734-1000 >> >> >> >> Sent from my iPhone >> >> >> On Apr 14, 2019, at 7:54 PM, Ron Bonica < >> rbonica=3D40juniper.net@dmarc.ietf.org> wrote: >> >> Hi Robert, >> >> >> >> In order to make the CRH ASIC-friendly, we have the following constraint= s: >> >> >> >> - Support only a small handful of SID lengths >> - If at all possible, make them align on word boundaries >> >> >> >> Currently, we support 8, 16 and 32 bytes. Do you see a reason why we >> should support a length greater than 32? Is there some length less than = 32 >> that would be beneficial? >> >> >> >> Ron >> >> >> >> >> >> >> >> Juniper Internal >> >> *From:* spring *On Behalf Of *Robert Raszuk >> *Sent:* Friday, April 12, 2019 6:13 PM >> *To:* Tom Herbert >> *Cc:* SPRING WG ; ipv6@ietf.org; Mark Smith < >> markzzzsmith@gmail.com>; Dino Farinacci ; >> lisp@ietf.org list >> *Subject:* Re: [spring] IPv6-compressed-routing-header-crh >> >> >> >> Hi Tom, >> >> >> >> I already suggested this on March 30th ... >> >> >> >> *"**PS. But if you choose to go ahead with CRH I would highly advise to >> make your CRH SID a variable length. "* >> >> >> >> No feedback/response was received from authors. >> >> >> >> Thx, >> R. >> >> >> >> On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert wrote= : >> >> On Fri, Apr 12, 2019 at 1:48 PM Mark Smith >> wrote: >> > >> > Hi Tom, >> > >> > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: >> > > >> > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk >> wrote: >> > > > >> > > > Hi Mark, >> > > > >> > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet >> boundary and a 32 bit alignment, >> > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 >> network. >> > > > > >> > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that ma= y >> also create some opportunities to >> > > > > leverage IPv4 support in existing protocols to suite carrying an= d >> processing 32 bit SIDs with some, possibly >> > > > > slight, modification. For example, perhaps IPv4 Address Family >> support in OSPFv3 (RFC 5838) could be >> > > > > somehow leveraged to suit SR. >> > > > >> > > > >> > > > Thank you for describing your understanding of fundamentals of SR. >> > > > >> > > > I think SR while indeed started with the story of "less control >> plane is good for you" now clearly has evolved into not only reduction o= f >> control plane but what can be even more important to some users ability = to >> request specific behavior via programmed functions of network elements o= n a >> per flow basis without actually per flow or per path signalling or state= . >> > > > >> > > > Yes for some it may be very useful feature and I am sure some will >> call it overload of data plane or . There is no one size fits all. >> > > > >> > > > With that let's observe that till today SR did not require any new >> mapping plane to be distributed in control plane and to be inserted into >> data plane. This is clearly a precedent. >> > > > >> > > > Furthermore as we see in companion documents all additional networ= k >> functionality is being taken away from SRH and is being shifted to >> Destination Options . >> > > > >> > > > As far as mapping plane I already pointed out in my Vector Routing >> proposal that we have one already it is called BGP. One needs to also >> observe that we as industry worked number of years of protocol suite cal= led >> LISP allowing not only very good mapping plane, but also data plane >> integration. CC-ing lisp authors for their comments. Note also work for >> integrating SRv6 with LISP which is already is published. >> > > > >> > > > Since you correctly observed that now SID can be 32 bit and that i= s >> similar to the size of IPv4 my fundamental question is why not use >> something which already exists instead of defining some sort of new fro= m >> scratch ? >> > > > >> > > Robert, >> > > >> > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you >> > > please provide a reference? >> > > >> > >> > To clarify, I've been thinking about the idea of a smaller SID size >> > for IPv6 for a while now (since inserting EHs came up), and thought >> > about what would be a generic single size that might suit SR that >> > wasn't the same size as an IPv6 address. 32 bits seemed suitable to >> > me, although if people wanted bigger, I'd be suggesting 64 bits (not >> > entirely coincidentally the common IID size.) >> > >> > Ron and others have written this draft, which supports SIDS of various >> > sizes - 8, 16 or 32 bits - that triggered this discussion. >> > >> Mark, >> >> Why not just put a SID length field in the header (like RFC6554 but >> more generic). That would allow lengths of 1-16 bytes. Additional >> flags could be used to indicate the semantics of the entries. For >> instance, they might be actual addresses (128 bits for IPv6, 32 bits >> for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) >> where the rest of the address can be inferred, indices into a table, >> labels, etc. >> >> Tom >> >> > "The IPv6 Compressed Routing Header (CRH)" >> > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 >> >> > >> > Regards, >> > Mark. >> > >> > >> > > As for trying to use something that already exists, why does SR used= a >> > > fixed size format for SIDs instead of a variable length format like >> > > that described in RFC6554? Similarly, why does SR define it's own TL= V >> > > format instead of using Hop-by-Hop and Destination Options defined i= n >> > > RFC8200? >> > > >> > > Tom >> > > >> > > > It will be perfectly fine to have full proper SRv6 with SRH and >> LISP or Vector Routing as an alternative options. I really do not see a >> room or need for yet one more mapping plane. What problem does it solve >> which would not be already solved elsewhere ? >> > > > >> > > > Kind regards, >> > > > Robert >> > > > >> > > > >> > > >>> 2) Is there an agreement that solutions which require additional >> per SR path state in both control plane and now in data plane are really >> something we should be endorsing here ? >> > > >> >> > > >> >> > > >> I think so. >> > > >> >> > > >> My understanding of what SR is fundamentally about is to reduce >> control plane state and processing. The trade-off for reduced control pl= ane >> state and processing is to instead carry and encode most or all of that >> information or its semantics as per-packet overhead. >> > > >> >> > > >> If the per-packet overhead becomes too large and expensive, then >> pushing some of that information and processing back into the control pl= ane >> should be ok, as long as there is still a beneficial overall reduction i= n >> control plane state and processing. >> > > >> >> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundar= y >> and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perfo= rm >> SR in an IPv6 network. >> > > >> >> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may >> also create some opportunities to leverage IPv4 support in existing >> protocols to suite carrying and processing 32 bit SIDs with some, possib= ly >> slight, modification. For example, perhaps IPv4 Address Family support i= n >> OSPFv3 (RFC 5838) could be somehow leveraged to suit SR. >> > > >> >> > > >> Regards, >> > > >> Mark. >> > > > >> > > > ------------------------------------------------------------------= -- >> > > > IETF IPv6 working group mailing list >> > > > ipv6@ietf......org >> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6 >> >> > > > ------------------------------------------------------------------= -- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> >> -------------------------------------------------------------------- >> >> --0000000000009f3e650586dfcbd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Specifically how do you as= sociate different service functions encoded in Dest. Options with specific = segments for selective execution ?=C2=A0

Hint: Execution= of all encoded and carried from src or edge of the network service instruc= tions in destinations options=C2=A0 at each SR node is not an option. Do you now duplicate each SID into Dest O= ptions=C2=A0 to be able to choose which service is executed in which of the= entire path's mid point ?=C2=A0

Many thx= ,
Robert.

On Fri, Apr 19, 2019 at 9:30 AM Robert Raszu= k <robert@raszuk.net> wrote:=

And what happens -=C2=A0

  • = When there is an SRH and Segments Left is not equal to 0 ?=C2=A0

<= /font>

On Fri, Apr 19, 2019 at 4:53 AM Ron Bonica <rbonica@juniper.net> = wrote:

= Hi Jim,

= =C2=A0

= Thanks for asking this insightful question. The answer depends on the SID t= ype.

= =C2=A0

= Some service SIDs (e.g., END.DX4, END.DX6, END.DT4, END.DT6) are processed = only in the following conditions:

= =C2=A0

  • When there is no SRH
  • When there is an SRH and Segments Left is eq= ual to 0

= =C2=A0

= Such SIDs should be encoded in the Destination Options header that immediat= ely precedes the upper-layer header. This is because the Destination Option= s header that immediately precedes the upper-layer header is only processed when:

= =C2=A0

  • When there is no SRH
  • When there is an SRH and Segments Left is eq= ual to 0

= =C2=A0

= Moreover, Destination options are of variable length. So, each SID can be a= s long or short as it needs to be. One SID type can be long while another i= s short and neither needs to be the same length as SIDs that are encoded in the IPv6 Routing header.<= /span>

= =C2=A0

= The VPN Context Information Option [draft-bonica-6man-vpn-dest-opt] is an e= xample of such an encoding. It serves the same purpose as many of the SID d= efined in draft-filsfils-spring-srv6-network-programming (e.g., END.DX4, END.DX6, END.DT4, END.DT6). As more service SIDs of this t= ype are identified, more destination options will be defined.=

= =C2=A0

= Other Service SIDs can be processed when an SRH is present and Segments Lef= t is greater than zero. Ideally, these SIDs should be encoded in the Destin= ation Options Header that immediately precedes the Routing header. This is because the Destination Options Header that im= mediately precedes the Routing header is processed by every segment endpoin= t. Draft-bonica-6man-seg-end-opt offers one such encoding scheme, but it is= not the only one.

= =C2=A0

= Another possibility is to encode these SIDs the Destination Options header = that immediately precedes the upper-layer header and required Service Funct= ion Instances that support these SIDs to look ahead.

= =C2=A0

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Ron

= =C2=A0

= =C2=A0

=C2=A0

Juniper Internal

From: James N Guichard <james.n.guichard@huawei.com<= /a>>
Sent: Thursday, April 18, 2019 5:57 PM
To: Ron Bonica <rbonica@juniper.net>; Robert Raszuk <robert@raszuk.net>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>; James N Guichard <= ;james.n.g= uichard@huawei.com>
Subject: RE: [spring] IPv6-compressed-routing-header-crh

=C2=A0

Hi Ron,<= u>

=C2=A0

I am wondering = about how do you plan to handle service SIDs (or any SID with embedded func= tions) at intermediate nodes; draft-bonica-6man-vpn-dest-opt seems to only = handle the case where the endpoint will process the destination option:

=C2=A0

Section 4 says: =E2=80=9CIt MUST NOT appear in a = Hop-by-hop Options header and SHOULD NOT appear in a Destination Options he= ader that precedes a Routing header=E2=80=9D.

=C2=A0

If = you relax the latter and encode the SID in a destination option preceding t= he CRH (or SRH) then wouldn=E2=80=99t every node in the segment-list have t= o process the SID and figure out whether it is a local SID or not? That would seem to be overly complex given you could just enco= de the SID in the CRH (or SRH) and only the node where said SID is exposed = would process it.

= =C2=A0

Tha= nks!

= =C2=A0

Jim=

=C2=A0

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica
Sent: Thursday, April 18, 2019 4:30 PM
To: Robert Raszuk <robert@raszuk.net>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: RE: [spring] IPv6-compressed-routing-header-crh

=C2=A0

= Robert,

= =C2=A0

= The Compressed Routing Header (CRH) has exactly one function. That is to ro= ute a packet for segment to segment along an SR path. Therefore, SIDs conta= ined by the CRH have only one function. That is to steer packets to the next segment.

= =C2=A0

= Granted, we may want to program a service behavior at a segment endpoint. I= Pv6 includes a Destination Options header that can be used to convey inform= ation segment endpoints and destination options can contain service SIDs. These service SIDs can be as long or short as th= ey need to be. See draft-bonica-6man-vpn-dest-opt for an example.=

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Ron

= =C2=A0

=C2=A0

Juniper Internal

From: Robert Raszuk <robert@raszuk.net>
Sent: Thursday, April 18, 2019 10:30 AM
To: Ron Bonica <rbonica@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Tom Herbert <tom@herbertland.com>; SPRIN= G WG <spring@ietf.o= rg>; ipv6@ietf.org; Dino = Farinacci <fari= nacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh

=C2=A0

Hi Ron,

=C2=A0

I must observe that your analysis is incorrect.=C2= =A0

=C2=A0

SIDs are not only used for TE or traffic steering pu= rposes but what is even more interesting for various functions - for exampl= e NFV.=C2=A0

=C2=A0

So you need as much SIDs as possible imagination of = your value add network functions - which will be different from those funct= ions at the encap dst which as you indicate in other draft can be carried i= n destination options.=C2=A0

=C2=A0

That debate is still I think open.=C2=A0

=C2=A0

Thx,

R.

=C2=A0

=C2=A0

On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica <rbonica@juniper.net= > wrote:

= Gyan,

= =C2=A0

= Let=E2=80=99s think about how a network operator might choose a SID size=E2= =80=A6.

= =C2=A0

= Assume that an MAN includes 100 routers. These routers are connected to one= another by infrastructure links. Each router has 20 or fewer infrastructure links.

= =C2=A0

= The network operator might assign one loosely routes SID to each router. Th= ese loosely routed SIDs have network-wide significance (i.e., the cannot be reused).

= =C2=A0

= The network operator might also assign one strictly routed SID to each link= . The strictly routed SIDs have node-local significance only. They can be reused from one node to another.

= =C2=A0

= So, in this case, the network operator only needs 120 SIDs. This fits in ei= ght bits with plenty of room for growth.

= =C2=A0

= Now consider another network that includes 30,000 routers. Each router is c= onnected to its peers by 200 infrastructure links or fewer.=C2=A0 This network would need 30,200 SIDs. This would fit in 16 bits.<= /u>

= =C2=A0

= A *really big* network might require more than 32,000 SIDs. So, we s= upport a 32-bit SID...

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Ron

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0

Juniper Internal

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Wednesday, April 17, 2019 10:00 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>; Tom Herbert <tom@herbertland.com>; SPRING WG &l= t;spring@ietf.org&= gt;; ipv6@ietf.org; Dino = Farinacci <fari= nacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh

=C2=A0

=C2=A0

I agree to make the SID align on word boundaries but= I am thinking the software should have hardware independence if at all pos= sible.

=C2=A0

I think 32 bit is a reasonable size.

=C2=A0

=C2=A0

Gyan S. Mishra

IT Network Engineering & Technology Consultant

Routing & Switching / Service Provider MPLS &= ; IPv6 Expert

Mobile =E2=80=93=C2=A0202-734-1000

=C2=A0

Sent from my iPhone


On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=3D40juniper.net@dmarc.= ietf.org> wrote:

= Hi Robert,

= =C2=A0

= In order to make the CRH ASIC-friendly, we have the following constraints:<= /span>

= =C2=A0

  • Support only a small handful of SID lengths<= /span>
  • If at all possible, make them align on word = boundaries

= =C2=A0

= Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should= support a length greater than 32? Is there some length less than 32 that would be beneficial?

= =C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Ron

= =C2=A0

= =C2=A0

=C2=A0

Juniper Internal

From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <tom@herbertland.com>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Mark = Smith <markz= zzsmith@gmail.com>; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list &= lt;lisp@ietf.org>=
Subject: Re: [spring] IPv6-compressed-routing-header-crh

=C2=A0

Hi Tom,

=C2=A0

I already suggested this on March 30th ...=C2=A0<= /u>

=C2=A0

"PS. But if you choose to go ahead with CRH I would highly advise t= o make your CRH SID a variable length. "

=C2=A0

No feed= back/response was received from authors.=C2=A0

=C2=A0

Thx, R.

=C2=A0

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.c= om> wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote: > > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform = SR in an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network elements on a per flow basis without actually per flo= w or per path signalling or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not requi= re any new mapping plane to be distributed in control plane and to be inser= ted into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comm= ents. Note also work for integrating SRv6 with LISP which is already is pub= lished.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new=C2=A0 f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. C= an you
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID siz= e
> for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable t= o
> me, although if people wanted bigger, I'd be suggesting 64 bits (n= ot
> entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's= own TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequ= ate to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leverage= d to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf= ......org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------

----------------------------------------------------= ----------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------=

--0000000000009f3e650586dfcbd4-- From nobody Fri Apr 19 17:54:17 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30601201D9; Fri, 19 Apr 2019 17:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Ntm-YqQVAW_g; Fri, 19 Apr 2019 17:54:02 -0700 (PDT) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 A75571201D5; Fri, 19 Apr 2019 17:54:01 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id u17so5072009lfi.3; Fri, 19 Apr 2019 17:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EYoQ52QWBHbFckeJJQeFuHTX76lreLqqHTHCoq2/MrY=; b=o+/9+pQlgkbRibha2NUGZy4wPHavCmq89Hw5zJv7FrJdyZieQz29NnaPwQmy+W2UHj sTqUSuf+HYyBD1uyQwqyAJl3kTlBszp/DDE8Va1LaayfYHpcIDpTZhsDkyMBmwLEc/nc EJ2pjV8T1XAAcS0pyzCUkMIhWPqknzhLHcmpNc8zo0o2wJxidAoIoTS6CLWYx4I7xSSy 60S8J0Kb0ftLoWqtsl/bEXrqi1BRiGQRdPNU08FlvAz7S0RMEFzvvJXEbast1ZkgV7lp WYQ2I0Y8XeV1sKuNm0dZ5pVv4eSCP9N6/HYf7atwv7mTh+TDALsi4noEH27pyaokVkfy KWOw== 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=EYoQ52QWBHbFckeJJQeFuHTX76lreLqqHTHCoq2/MrY=; b=LehvG5RjG+28UwHfNbbEqlOZqdsHRS7kPZQveaHS20uxzTIS0tUfS0jJ7uy8pbfl6c WA2Ke2dWLy5xE4aVCVuiZYC2GRWpoeV3Ef2dsdJNJuvL+wTR6X0rECp5Ai4/KbBWSJjV kXv5R93F/6Ux0YqFh55waTMYIHrfLtmCVFacdu+jziNACr1NqToMB7eUoQDNwv5cTEz6 h42Hv2fypH8T8efddqOJC0KgTBzqpFXcXWSV0PmIxi9ouQfmcDDmDDxwZ3qVBG/iupOt cvetnET8R+vX1Z2DSHSxa1EdQPq7xagLlOZ7tXrisBWwlgTWaZ1JQYlgued+WlUYpUnH ypzw== X-Gm-Message-State: APjAAAVMHYOAiiJCxAuMxIKlUnGDvmpnFgDhL8N7/RVzf+DzTz95Dcbl p15hh9etXyd7qLrs3TfF889I7/uoYVtX3eIZvtI= X-Google-Smtp-Source: APXvYqxUHfBOQzpAb6j5Pm4ECM66ItQ/+h7P/exjVXE5GUUPwZAaoNxRzNaO48J8Jqy7lbPJQMIUrESwCb/mICF8rfE= X-Received: by 2002:a19:6619:: with SMTP id a25mr3653288lfc.21.1555721639761; Fri, 19 Apr 2019 17:53:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Fri, 19 Apr 2019 17:53:53 -0700 Message-ID: To: Tom Herbert Cc: Mark Smith , SPRING WG , Dino Farinacci , "ipv6@ietf.org" , "lisp@ietf.org list" , Robert Raszuk Content-Type: multipart/alternative; boundary="000000000000b51c3c0586ebab7e" Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 00:54:06 -0000 --000000000000b51c3c0586ebab7e Content-Type: text/plain; charset="UTF-8" Hi Tom, in draft-mirsky-6man-unified-id-sr we've proposed the use of 20 and 32 bits-long SIDs in SR EH. Two bits-long field also defined in the Flags to identify the length of SID element in the SR EH: 0b00 - 128-bits SID; 0b01 - 20-bits SID; 0b10 - 32-bits SID 0b11 - reserved for future use. Much appreciate your comments on that draft, suggestions. Regards, Greg On Fri, Apr 12, 2019 at 3:09 PM Tom Herbert wrote: > On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrote: > > > > Hi Tom, > > > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: > > > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk > wrote: > > > > > > > > Hi Mark, > > > > > > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary > and a 32 bit alignment, > > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 > network. > > > > > > > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may > also create some opportunities to > > > > > leverage IPv4 support in existing protocols to suite carrying and > processing 32 bit SIDs with some, possibly > > > > > slight, modification. For example, perhaps IPv4 Address Family > support in OSPFv3 (RFC 5838) could be > > > > > somehow leveraged to suit SR. > > > > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > > > I think SR while indeed started with the story of "less control > plane is good for you" now clearly has evolved into not only reduction of > control plane but what can be even more important to some users ability to > request specific behavior via programmed functions of network elements on a > per flow basis without actually per flow or per path signalling or state. > > > > > > > > Yes for some it may be very useful feature and I am sure some will > call it overload of data plane or . There is no one size fits all. > > > > > > > > With that let's observe that till today SR did not require any new > mapping plane to be distributed in control plane and to be inserted into > data plane. This is clearly a precedent. > > > > > > > > Furthermore as we see in companion documents all additional network > functionality is being taken away from SRH and is being shifted to > Destination Options . > > > > > > > > As far as mapping plane I already pointed out in my Vector Routing > proposal that we have one already it is called BGP. One needs to also > observe that we as industry worked number of years of protocol suite called > LISP allowing not only very good mapping plane, but also data plane > integration. CC-ing lisp authors for their comments. Note also work for > integrating SRv6 with LISP which is already is published. > > > > > > > > Since you correctly observed that now SID can be 32 bit and that is > similar to the size of IPv4 my fundamental question is why not use > something which already exists instead of defining some sort of new from > scratch ? > > > > > > > Robert, > > > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > > please provide a reference? > > > > > > > To clarify, I've been thinking about the idea of a smaller SID size > > for IPv6 for a while now (since inserting EHs came up), and thought > > about what would be a generic single size that might suit SR that > > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > > me, although if people wanted bigger, I'd be suggesting 64 bits (not > > entirely coincidentally the common IID size.) > > > > Ron and others have written this draft, which supports SIDS of various > > sizes - 8, 16 or 32 bits - that triggered this discussion. > > > Mark, > > Why not just put a SID length field in the header (like RFC6554 but > more generic). That would allow lengths of 1-16 bytes. Additional > flags could be used to indicate the semantics of the entries. For > instance, they might be actual addresses (128 bits for IPv6, 32 bits > for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) > where the rest of the address can be inferred, indices into a table, > labels, etc. > > Tom > > > "The IPv6 Compressed Routing Header (CRH)" > > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > > > Regards, > > Mark. > > > > > > > As for trying to use something that already exists, why does SR used a > > > fixed size format for SIDs instead of a variable length format like > > > that described in RFC6554? Similarly, why does SR define it's own TLV > > > format instead of using Hop-by-Hop and Destination Options defined in > > > RFC8200? > > > > > > Tom > > > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP > or Vector Routing as an alternative options. I really do not see a room or > need for yet one more mapping plane. What problem does it solve which would > not be already solved elsewhere ? > > > > > > > > Kind regards, > > > > Robert > > > > > > > > > > > >>> 2) Is there an agreement that solutions which require additional > per SR path state in both control plane and now in data plane are really > something we should be endorsing here ? > > > >> > > > >> > > > >> I think so. > > > >> > > > >> My understanding of what SR is fundamentally about is to reduce > control plane state and processing. The trade-off for reduced control plane > state and processing is to instead carry and encode most or all of that > information or its semantics as per-packet overhead. > > > >> > > > >> If the per-packet overhead becomes too large and expensive, then > pushing some of that information and processing back into the control plane > should be ok, as long as there is still a beneficial overall reduction in > control plane state and processing. > > > >> > > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary > and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform > SR in an IPv6 network. > > > >> > > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may > also create some opportunities to leverage IPv4 support in existing > protocols to suite carrying and processing 32 bit SIDs with some, possibly > slight, modification. For example, perhaps IPv4 Address Family support in > OSPFv3 (RFC 5838) could be somehow leveraged to suit SR. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------- > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000b51c3c0586ebab7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,
in=C2=A0draf= t-mirsky-6man-unified-id-sr=C2=A0we've proposed the use of 20 and 3= 2 bits-long SIDs in SR EH. Two bits-long field also defined in the Flags to= identify the length of SID element in the SR EH:
=C2=A0 =C2= =A0 =C2=A0 0b00 - 128-bits SID;
=C2=A0 =C2=A0 =C2=A0 0b01 - 20-bi= ts SID;
=C2=A0 =C2=A0 =C2=A0 0b10 - 32-bits SID
=C2=A0 = =C2=A0 =C2=A0 0b11 - reserved for future use.

Much appreciate your comments on that draft, suggestions.

<= /div>
Regards,
Greg

On Fri, A= pr 12, 2019 at 3:09 PM Tom Herbert <tom@herbertland.com> wrote:
On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.co= m> wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote: > > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform = SR in an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network = elements on a per flow basis without actually per flow or per path signalli= ng or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not requi= re any new mapping plane to be distributed in control plane and to be inser= ted into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane inte= gration. CC-ing lisp authors for their comments. Note also work for integra= ting SRv6 with LISP which is already is published.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new=C2=A0 f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. C= an you
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID siz= e
> for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable t= o
> me, although if people wanted bigger, I'd be suggesting 64 bits (n= ot
> entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-= bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's= own TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequ= ate to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support i= n OSPFv3 (RFC 5838) could be somehow leveraged to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf= .org
> > > Administrative Requests: https://www.ietf.o= rg/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000b51c3c0586ebab7e-- From nobody Fri Apr 19 22:12:16 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885B01200DB; Fri, 19 Apr 2019 22:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=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 MlYE7hbm4DNa; Fri, 19 Apr 2019 22:11:55 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 DD9EB120049; Fri, 19 Apr 2019 22:11:54 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id z16so7307307qtn.4; Fri, 19 Apr 2019 22:11:54 -0700 (PDT) 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=+9ZC9ymwMw0TIXB/DTrr8jNzCYVfnacIhU90DRZGxB8=; b=Inv/KqCW5kuRlRFKmHH9lXPJmDZJNOsNlFHGb5HGckur+nwY4fdoCWhvyMpszYjdzz 0OGYy2rilCEiNwy6S9zei6YQRk65qyWGyOu9+5YmLdClXTRxaJ3IiCNdeWwgIo3jdopg e5ieA/dLZMZ/bnEySYLRmUbx3SVG6Vs7lBWxOG9zqfyU+MqGdjGY/BxDrpVzB3n+y3l6 rFak2JCqB+kd4vilDLgfHrQ7NLKvEE8+juqMm0dvEp8a6LI8oh2MDOqQfqzFKYuPdR3y gg9b+YrIYYnZ7CR3c24E1aw6gPrqQ0u8iRtqBrk6/NRnJWr+9Y39rMR6aSvAsV1+fThg KHeg== 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=+9ZC9ymwMw0TIXB/DTrr8jNzCYVfnacIhU90DRZGxB8=; b=EE3pzKzbzsmBedT5lPeY1lrcAwTeMo055D242k+s+kg7TF70VYYHFEyd5nfvCWHAM/ O8/1BiuK6eHB9VJXmwjEegJ4lh9D0SXR0FizKEW61d3/cimrlADZeLNS7TjqwmWIhas3 ml4ySBPWmaE+4V1Ka8iD4UB+WNlDYV2NJQyy9haBYZoOOdvs9gLDMSOTEaaB0qQzTRgX dCg4bwMeVh3Zpwss9L6hltNOQuthzL6HdWnLUOneHt58Sd5xct7g1ps+wVys9VKoXTq7 bZbIeT3hX80zj1FZDP6DE+pikUK0xJvJjQiWrBIgGZA1rwtc0mtMP03ObpCcKIAIONNk z/Uw== X-Gm-Message-State: APjAAAWxqTzAx2ldVFG4+jHSeprqR1GIEBUHQ5zOmEgQhAiX6wwpGTvu 2t8gqTEws7isIISHryrIQGH7nJmw X-Google-Smtp-Source: APXvYqwVduBGsW9me9UWofslWou18gVMo6AgnGGUdgAl0wX8mSO3nvMCNQPcWqGUdzs5/MlDyMszzw== X-Received: by 2002:a0c:964e:: with SMTP id 14mr6471368qvy.246.1555737113486; Fri, 19 Apr 2019 22:11:53 -0700 (PDT) Received: from ?IPv6:2600:1003:b010:7e2a:215a:3d2f:dcc3:ecea? ([2600:1003:b010:7e2a:215a:3d2f:dcc3:ecea]) by smtp.gmail.com with ESMTPSA id f93sm3652261qtb.16.2019.04.19.22.11.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Apr 2019 22:11:52 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-2601A97C-0C72-4CD4-A101-333FA94EBCAE Mime-Version: 1.0 (1.0) From: Gyan Mishra X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Sat, 20 Apr 2019 01:11:51 -0400 Cc: Ron Bonica , SPRING WG , "ipv6@ietf.org" , Dino Farinacci , "lisp@ietf.org list" Content-Transfer-Encoding: 7bit Message-Id: References: <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> To: Robert Raszuk Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 05:12:00 -0000 --Apple-Mail-2601A97C-0C72-4CD4-A101-333FA94EBCAE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Makes sense. Thank you Gyan Sent from my iPhone > On Apr 19, 2019, at 3:30 AM, Robert Raszuk wrote: >=20 >=20 > And what happens -=20 >=20 > When there is an SRH and Segments Left is not equal to 0 ?=20 >=20 >=20 >> On Fri, Apr 19, 2019 at 4:53 AM Ron Bonica wrote: >> Hi Jim, >>=20 >> =20 >>=20 >> Thanks for asking this insightful question. The answer depends on the SID= type. >>=20 >> =20 >>=20 >> Some service SIDs (e.g., END.DX4, END.DX6, END.DT4, END.DT6) are processe= d only in the following conditions: >>=20 >> =20 >>=20 >> When there is no SRH >> When there is an SRH and Segments Left is equal to 0 >> =20 >>=20 >> Such SIDs should be encoded in the Destination Options header that immedi= ately precedes the upper-layer header. This is because the Destination Optio= ns header that immediately precedes the upper-layer header is only processed= when: >>=20 >> =20 >>=20 >> When there is no SRH >> When there is an SRH and Segments Left is equal to 0 >> =20 >>=20 >> Moreover, Destination options are of variable length. So, each SID can be= as long or short as it needs to be. One SID type can be long while another i= s short and neither needs to be the same length as SIDs that are encoded in t= he IPv6 Routing header. >>=20 >> =20 >>=20 >> The VPN Context Information Option [draft-bonica-6man-vpn-dest-opt] is an= example of such an encoding. It serves the same purpose as many of the SID d= efined in draft-filsfils-spring-srv6-network-programming (e.g., END.DX4, END= .DX6, END.DT4, END.DT6). As more service SIDs of this type are identified, m= ore destination options will be defined. >>=20 >> =20 >>=20 >> Other Service SIDs can be processed when an SRH is present and Segments L= eft is greater than zero. Ideally, these SIDs should be encoded in the Desti= nation Options Header that immediately precedes the Routing header. This is= because the Destination Options Header that immediately precedes the Routin= g header is processed by every segment endpoint. Draft-bonica-6man-seg-end-o= pt offers one such encoding scheme, but it is not the only one. >>=20 >> =20 >>=20 >> Another possibility is to encode these SIDs the Destination Options heade= r that immediately precedes the upper-layer header and required Service Func= tion Instances that support these SIDs to look ahead. >>=20 >> =20 >>=20 >> =20 >>=20 >> = Ron >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> Juniper Internal >> From: James N Guichard =20 >> Sent: Thursday, April 18, 2019 5:57 PM >> To: Ron Bonica ; Robert Raszuk >> Cc: SPRING WG ; ipv6@ietf.org; Dino Farinacci ; lisp@ietf.org list ; James N Guichard >> Subject: RE: [spring] IPv6-compressed-routing-header-crh >>=20 >> =20 >>=20 >> Hi Ron, >>=20 >> =20 >>=20 >> I am wondering about how do you plan to handle service SIDs (or any SID w= ith embedded functions) at intermediate nodes; draft-bonica-6man-vpn-dest-op= t seems to only handle the case where the endpoint will process the destinat= ion option: >>=20 >> =20 >>=20 >> Section 4 says: =E2=80=9CIt MUST NOT appear in a Hop-by-hop Options heade= r and SHOULD NOT appear in a Destination Options header that precedes a Rout= ing header=E2=80=9D. >>=20 >> =20 >>=20 >> If you relax the latter and encode the SID in a destination option preced= ing the CRH (or SRH) then wouldn=E2=80=99t every node in the segment-list ha= ve to process the SID and figure out whether it is a local SID or not? That w= ould seem to be overly complex given you could just encode the SID in the CR= H (or SRH) and only the node where said SID is exposed would process it. >>=20 >> =20 >>=20 >> Thanks! >>=20 >> =20 >>=20 >> Jim >>=20 >> =20 >>=20 >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica=20 >> Sent: Thursday, April 18, 2019 4:30 PM >> To: Robert Raszuk >> Cc: SPRING WG ; ipv6@ietf.org; Dino Farinacci ; lisp@ietf.org list >> Subject: RE: [spring] IPv6-compressed-routing-header-crh >>=20 >> =20 >>=20 >> Robert, >>=20 >> =20 >>=20 >> The Compressed Routing Header (CRH) has exactly one function. That is to r= oute a packet for segment to segment along an SR path. Therefore, SIDs conta= ined by the CRH have only one function. That is to steer packets to the next= segment. >>=20 >> =20 >>=20 >> Granted, we may want to program a service behavior at a segment endpoint.= IPv6 includes a Destination Options header that can be used to convey infor= mation segment endpoints and destination options can contain service SIDs. T= hese service SIDs can be as long or short as they need to be. See draft-boni= ca-6man-vpn-dest-opt for an example. >>=20 >> =20 >>=20 >> = Ron >>=20 >> =20 >>=20 >> =20 >>=20 >> Juniper Internal >> From: Robert Raszuk =20 >> Sent: Thursday, April 18, 2019 10:30 AM >> To: Ron Bonica >> Cc: Gyan Mishra ; Tom Herbert ; SPRING WG ; ipv6@ietf.org; Dino Farinacci ; lisp@ietf.org list >> Subject: Re: [spring] IPv6-compressed-routing-header-crh >>=20 >> =20 >>=20 >> Hi Ron, >>=20 >> =20 >>=20 >> I must observe that your analysis is incorrect.=20 >>=20 >> =20 >>=20 >> SIDs are not only used for TE or traffic steering purposes but what is ev= en more interesting for various functions - for example NFV.=20 >>=20 >> =20 >>=20 >> So you need as much SIDs as possible imagination of your value add networ= k functions - which will be different from those functions at the encap dst w= hich as you indicate in other draft can be carried in destination options.=20= >>=20 >> =20 >>=20 >> That debate is still I think open.=20 >>=20 >> =20 >>=20 >> Thx, >>=20 >> R. >>=20 >> =20 >>=20 >> =20 >>=20 >> On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica wrote: >>=20 >> Gyan, >>=20 >> =20 >>=20 >> Let=E2=80=99s think about how a network operator might choose a SID size=E2= =80=A6. >>=20 >> =20 >>=20 >> Assume that an MAN includes 100 routers. These routers are connected to o= ne another by infrastructure links. Each router has 20 or fewer infrastructu= re links. >>=20 >> =20 >>=20 >> The network operator might assign one loosely routes SID to each router. T= hese loosely routed SIDs have network-wide significance (i.e., the cannot be= reused). >>=20 >> =20 >>=20 >> The network operator might also assign one strictly routed SID to each li= nk.. The strictly routed SIDs have node-local significance only. They can be= reused from one node to another. >>=20 >> =20 >>=20 >> So, in this case, the network operator only needs 120 SIDs. This fits in e= ight bits with plenty of room for growth. >>=20 >> =20 >>=20 >> Now consider another network that includes 30,000 routers. Each router is= connected to its peers by 200 infrastructure links or fewer. This network w= ould need 30,200 SIDs. This would fit in 16 bits. >>=20 >> =20 >>=20 >> A *really big* network might require more than 32,000 SIDs. So, we suppor= t a 32-bit SID... >>=20 >> =20 >>=20 >> = Ron >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> Juniper Internal >> From: Gyan Mishra =20 >> Sent: Wednesday, April 17, 2019 10:00 PM >> To: Ron Bonica >> Cc: Robert Raszuk ; Tom Herbert ;= SPRING WG ; ipv6@ietf.org; Dino Farinacci ; lisp@ietf.org list >> Subject: Re: [spring] IPv6-compressed-routing-header-crh >>=20 >> =20 >>=20 >> =20 >>=20 >> I agree to make the SID align on word boundaries but I am thinking the so= ftware should have hardware independence if at all possible. >>=20 >> =20 >>=20 >> I think 32 bit is a reasonable size. >>=20 >> =20 >>=20 >> =20 >>=20 >> Gyan S. Mishra >>=20 >> IT Network Engineering & Technology Consultant >>=20 >> Routing & Switching / Service Provider MPLS & IPv6 Expert >>=20 >> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT >>=20 >> Mobile =E2=80=93 202-734-1000 >>=20 >> =20 >>=20 >> Sent from my iPhone >>=20 >>=20 >> On Apr 14, 2019, at 7:54 PM, Ron Bonica wrote: >>=20 >> Hi Robert, >>=20 >> =20 >>=20 >> In order to make the CRH ASIC-friendly, we have the following constraints= : >>=20 >> =20 >>=20 >> Support only a small handful of SID lengths >> If at all possible, make them align on word boundaries >> =20 >>=20 >> Currently, we support 8, 16 and 32 bytes. Do you see a reason why we shou= ld support a length greater than 32? Is there some length less than 32 that w= ould be beneficial? >>=20 >> =20 >>=20 >> Ron >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> Juniper Internal >> From: spring On Behalf Of Robert Raszuk >> Sent: Friday, April 12, 2019 6:13 PM >> To: Tom Herbert >> Cc: SPRING WG ; ipv6@ietf.org; Mark Smith ; Dino Farinacci ; lisp@ietf.org list >> Subject: Re: [spring] IPv6-compressed-routing-header-crh >>=20 >> =20 >>=20 >> Hi Tom, >>=20 >> =20 >>=20 >> I already suggested this on March 30th ...=20 >>=20 >> =20 >>=20 >> "PS. But if you choose to go ahead with CRH I would highly advise to make= your CRH SID a variable length. " >>=20 >> =20 >>=20 >> No feedback/response was received from authors.=20 >>=20 >> =20 >>=20 >> Thx, >> R. >>=20 >> =20 >>=20 >> On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert wrote:= >>=20 >> On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrote= : >> > >> > Hi Tom, >> > >> > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: >> > > >> > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wro= te: >> > > > >> > > > Hi Mark, >> > > > >> > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundar= y and a 32 bit alignment, >> > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 n= etwork. >> > > > > >> > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may= also create some opportunities to >> > > > > leverage IPv4 support in existing protocols to suite carrying and= processing 32 bit SIDs with some, possibly >> > > > > slight, modification. For example, perhaps IPv4 Address Family su= pport in OSPFv3 (RFC 5838) could be >> > > > > somehow leveraged to suit SR. >> > > > >> > > > >> > > > Thank you for describing your understanding of fundamentals of SR. >> > > > >> > > > I think SR while indeed started with the story of "less control pla= ne is good for you" now clearly has evolved into not only reduction of contr= ol plane but what can be even more important to some users ability to reques= t specific behavior via programmed functions of network elements on a per fl= ow basis without actually per flow or per path signalling or state. >> > > > >> > > > Yes for some it may be very useful feature and I am sure some will c= all it overload of data plane or . There is no one size fits all. >> > > > >> > > > With that let's observe that till today SR did not require any new m= apping plane to be distributed in control plane and to be inserted into data= plane. This is clearly a precedent. >> > > > >> > > > Furthermore as we see in companion documents all additional network= functionality is being taken away from SRH and is being shifted to Destinat= ion Options . >> > > > >> > > > As far as mapping plane I already pointed out in my Vector Routing p= roposal that we have one already it is called BGP. One needs to also observe= that we as industry worked number of years of protocol suite called LISP al= lowing not only very good mapping plane, but also data plane integration. CC= -ing lisp authors for their comments. Note also work for integrating SRv6 wi= th LISP which is already is published. >> > > > >> > > > Since you correctly observed that now SID can be 32 bit and that is= similar to the size of IPv4 my fundamental question is why not use somethin= g which already exists instead of defining some sort of new from scratch ? >> > > > >> > > Robert, >> > > >> > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you >> > > please provide a reference? >> > > >> > >> > To clarify, I've been thinking about the idea of a smaller SID size >> > for IPv6 for a while now (since inserting EHs came up), and thought >> > about what would be a generic single size that might suit SR that >> > wasn't the same size as an IPv6 address. 32 bits seemed suitable to >> > me, although if people wanted bigger, I'd be suggesting 64 bits (not >> > entirely coincidentally the common IID size.) >> > >> > Ron and others have written this draft, which supports SIDS of various >> > sizes - 8, 16 or 32 bits - that triggered this discussion. >> > >> Mark, >>=20 >> Why not just put a SID length field in the header (like RFC6554 but >> more generic). That would allow lengths of 1-16 bytes. Additional >> flags could be used to indicate the semantics of the entries. For >> instance, they might be actual addresses (128 bits for IPv6, 32 bits >> for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) >> where the rest of the address can be inferred, indices into a table, >> labels, etc. >>=20 >> Tom >>=20 >> > "The IPv6 Compressed Routing Header (CRH)" >> > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 >> > >> > Regards, >> > Mark. >> > >> > >> > > As for trying to use something that already exists, why does SR used a= >> > > fixed size format for SIDs instead of a variable length format like >> > > that described in RFC6554? Similarly, why does SR define it's own TLV= >> > > format instead of using Hop-by-Hop and Destination Options defined in= >> > > RFC8200? >> > > >> > > Tom >> > > >> > > > It will be perfectly fine to have full proper SRv6 with SRH and LIS= P or Vector Routing as an alternative options. I really do not see a room or= need for yet one more mapping plane. What problem does it solve which would= not be already solved elsewhere ? >> > > > >> > > > Kind regards, >> > > > Robert >> > > > >> > > > >> > > >>> 2) Is there an agreement that solutions which require additional p= er SR path state in both control plane and now in data plane are really some= thing we should be endorsing here ? >> > > >> >> > > >> >> > > >> I think so. >> > > >> >> > > >> My understanding of what SR is fundamentally about is to reduce co= ntrol plane state and processing. The trade-off for reduced control plane st= ate and processing is to instead carry and encode most or all of that inform= ation or its semantics as per-packet overhead. >> > > >> >> > > >> If the per-packet overhead becomes too large and expensive, then p= ushing some of that information and processing back into the control plane s= hould be ok, as long as there is still a beneficial overall reduction in con= trol plane state and processing. >> > > >> >> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary= and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform S= R in an IPv6 network. >> > > >> >> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may a= lso create some opportunities to leverage IPv4 support in existing protocols= to suite carrying and processing 32 bit SIDs with some, possibly slight, mo= dification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5= 838) could be somehow leveraged to suit SR. >> > > >> >> > > >> Regards, >> > > >> Mark. >> > > > >> > > > -------------------------------------------------------------------= - >> > > > IETF IPv6 working group mailing list >> > > > ipv6@ietf.......org >> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6= >> > > > -------------------------------------------------------------------= - >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-2601A97C-0C72-4CD4-A101-333FA94EBCAE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Makes sense.

Thank you

Gyan

Sent from my iPhone

On Apr 19, 2019, at 3= :30 AM, Robert Raszuk <robert@raszuk= .net> wrote:

=

And what happens - 

  • When there is an SRH and Segments Left is not equal to 0= ? 


On Fri= , Apr 19, 2019 at 4:53 AM Ron Bonica <rbonica@juniper.net> wrote:

H= i Jim,

<= u> 

T= hanks for asking this insightful question. The answer depends on the SID typ= e.

<= u> 

S= ome service SIDs (e.g., END.DX4, END.DX6, END.DT4, END.DT6) are processed on= ly in the following conditions:

<= u> 

  • When there is no SRH
  • When there is an SRH and Segments Left is equ= al to 0

<= u> 

S= uch SIDs should be encoded in the Destination Options header that immediatel= y precedes the upper-layer header. This is because the Destination Options h= eader that immediately precedes the upper-layer header is only processed when:

<= u> 

  • When there is no SRH
  • When there is an SRH and Segments Left is equ= al to 0

<= u> 

M= oreover, Destination options are of variable length. So, each SID can be as l= ong or short as it needs to be. One SID type can be long while another is sh= ort and neither needs to be the same length as SIDs that are encoded in the IPv6 Routing header.

<= u> 

T= he VPN Context Information Option [draft-bonica-6man-vpn-dest-opt] is an exa= mple of such an encoding. It serves the same purpose as many of the SID defi= ned in draft-filsfils-spring-srv6-network-programming (e.g., END.DX4, END.DX6, END.DT4, END.DT6). As more service SIDs of this ty= pe are identified, more destination options will be defined.

<= u> 

O= ther Service SIDs can be processed when an SRH is present and Segments Left i= s greater than zero. Ideally, these SIDs should be encoded in the Destinatio= n Options Header that immediately precedes the Routing header. This is because the Destination Options Header that imm= ediately precedes the Routing header is processed by every segment endpoint.= Draft-bonica-6man-seg-end-opt offers one such encoding scheme, but it is no= t the only one.

<= u> 

A= nother possibility is to encode these SIDs the Destination Options header th= at immediately precedes the upper-layer header and required Service Function= Instances that support these SIDs to look ahead.

<= u> 

<= u> 

&= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;  Ron

<= u> 

<= u> 

 

Juniper Internal

From: James N Guichard <james.n.guichard@huawei.com>
Sent: Thursday, April 18, 2019 5:57 PM
To: Ron Bonica <rbonica@juniper.net>; Robert Raszuk <robert@raszuk.net>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>; James N Guichard <james.n.guichar= d@huawei.com>
Subject: RE: [spring] IPv6-compressed-routing-header-crh

 

Hi Ron,

 =

I am wondering a= bout how do you plan to handle service SIDs (or any SID with embedded functi= ons) at intermediate nodes; draft-bonica-6man-vpn-dest-opt seems to only han= dle the case where the endpoint will process the destination option:

 =

Section 4 says: =E2=80=9CIt MUST NOT appear in a Hop-= by-hop Options header and SHOULD NOT appear in a Destination Options header t= hat precedes a Routing header=E2=80=9D.

 

If y= ou relax the latter and encode the SID in a destination option preceding the= CRH (or SRH) then wouldn=E2=80=99t every node in the segment-list have to p= rocess the SID and figure out whether it is a local SID or not? That would seem to be overly complex given you could just encod= e the SID in the CRH (or SRH) and only the node where said SID is exposed wo= uld process it.

<= /u> 

Than= ks!

<= /u> 

Jim<= u>

 =

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica
Sent: Thursday, April 18, 2019 4:30 PM
To: Robert Raszuk <robert@raszuk.net>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list &l= t;lisp@ietf.org> Subject: RE: [spring] IPv6-compressed-routing-header-crh

 

R= obert,

<= u> 

T= he Compressed Routing Header (CRH) has exactly one function. That is to rout= e a packet for segment to segment along an SR path. Therefore, SIDs containe= d by the CRH have only one function. That is to steer packets to the next segment.

<= u> 

G= ranted, we may want to program a service behavior at a segment endpoint. IPv= 6 includes a Destination Options header that can be used to convey informati= on segment endpoints and destination options can contain service SIDs. These service SIDs can be as long or short as the= y need to be. See draft-bonica-6man-vpn-dest-opt for an example.

<= u> 

&= nbsp;            = ;            &nb= sp;            &= nbsp;            &nbs= p;            &n= bsp;            =  Ron

<= u> 

 

Juniper Internal

From: Robert Raszuk <robert@raszuk.net>
Sent: Thursday, April 18, 2019 10:30 AM
To: Ron Bonica <rbonica@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Tom Herbert <tom@herbertland.com>; SPRING WG &= lt;spring@ietf.org&= gt;; ipv6@ietf.org; Dino Fa= rinacci <farinac= ci@gmail.com>; lisp@ietf.org list &l= t;lisp@ietf.org> Subject: Re: [spring] IPv6-compressed-routing-header-crh

 

Hi Ron,

 

I must observe that your analysis is incorrect. =

 

SIDs are not only used for TE or traffic steering pur= poses but what is even more interesting for various functions - for example N= FV. 

 

So you need as much SIDs as possible imagination of y= our value add network functions - which will be different from those functio= ns at the encap dst which as you indicate in other draft can be carried in d= estination options. 

 

That debate is still I think open. 

 

Thx,

R.

 

 

On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica <rbonica@juniper.net&g= t; wrote:

G= yan,

&= nbsp;

L= et=E2=80=99s think about how a network operator might choose a SID size=E2=80= =A6.

&= nbsp;

A= ssume that an MAN includes 100 routers. These routers are connected to one a= nother by infrastructure links. Each router has 20 or fewer infrastructure links.

&= nbsp;

T= he network operator might assign one loosely routes SID to each router. Thes= e loosely routed SIDs have network-wide significance (i.e., the cannot be reused).

&= nbsp;

T= he network operator might also assign one strictly routed SID to each link..= The strictly routed SIDs have node-local significance only. They can be reused from one node to another.

&= nbsp;

S= o, in this case, the network operator only needs 120 SIDs. This fits in eigh= t bits with plenty of room for growth.

&= nbsp;

N= ow consider another network that includes 30,000 routers. Each router is con= nected to its peers by 200 infrastructure links or fewer.  This network would need 30,200 SIDs. This would fit in 16 bits.

&= nbsp;

A= *really big* network might require more than 32,000 SIDs. So, we sup= port a 32-bit SID...

&= nbsp;

&= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            Ron

&= nbsp;

&= nbsp;

&= nbsp;

 

Juniper Internal

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Wednesday, April 17, 2019 10:00 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>; Tom Herbert <tom@herbertland.com>; SPRING WG <<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf.org>;= ipv6@ietf.org; Dino Fa= rinacci <farinac= ci@gmail.com>; lisp@ietf.org list &l= t;lisp@ietf.org> Subject: Re: [spring] IPv6-compressed-routing-header-crh

 

 

I agree to make the SID align on word boundaries but I= am thinking the software should have hardware independence if at all possib= le.

 

I think 32 bit is a reasonable size.

 

 

Gyan S. Mishra

IT Network Engineering & Technology Consultant=

Routing & Switching / Service Provider MPLS &= IPv6 Expert

Mobile =E2=80=93 202-734-1000

 

=

Sent from my iPhone


On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=3D40juniper.net@dmarc.ie= tf.org> wrote:

H= i Robert,

&= nbsp;

I= n order to make the CRH ASIC-friendly, we have the following constraints:

&= nbsp;

  • Support only a small handful of SID lengths
  • If at all possible, make them align on word b= oundaries

&= nbsp;

C= urrently, we support 8, 16 and 32 bytes. Do you see a reason why we should s= upport a length greater than 32? Is there some length less than 32 that would be beneficial?

&= nbsp;

&= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;  Ron

&= nbsp;

&= nbsp;

 

Juniper Internal

From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <tom@herbertland.com>
Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Mark S= mith <markzzz= smith@gmail.com>; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list &l= t;lisp@ietf.org> Subject: Re: [spring] IPv6-compressed-routing-header-crh

 

Hi Tom,

 

I already suggested this on March 30th ... 

 

"PS. But if you choose to go ahead with CRH I would highly advise to make y= our CRH SID a variable length. "

 

No feedb= ack/response was received from authors. 

 

Thx,
= R.

 

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com= > wrote:

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.com= > wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net> wrote:
> > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform SR in= an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite car= rying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address = Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals o= f SR.
> > >
> > > I think SR while indeed started with the story of "less contr= ol plane is good for you" now clearly has evolved into not only reduction of= control plane but what can be even more important to some users ability to r= equest specific behavior via programmed functions of network elements on a per flow basis without actually per flow= or per path signalling or state.
> > >
> > > Yes for some it may be very useful feature and I am sure some= will call it overload of data plane or . There is no one size fits all.
= > > >
> > > With that let's observe that till today SR did not require an= y new mapping plane to be distributed in control plane and to be inserted in= to data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional n= etwork functionality is being taken away from SRH and is being shifted to De= stination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector Ro= uting proposal that we have one already it is called BGP. One needs to also o= bserve that we as industry worked number of years of protocol suite called L= ISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comme= nts. Note also work for integrating SRv6 with LISP which is already is publi= shed.
> > >
> > > Since you correctly observed that now SID can be 32 bit and t= hat is similar to the size of IPv4 my fundamental question is why not use so= mething which already exists instead of defining some sort of new  from= scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. Can yo= u
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID size
= > for IPv6 for a while now (since inserting EHs came up), and thought
= > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable to
= > me, although if people wanted bigger, I'd be suggesting 64 bits (not > entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various<= br> > sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR us= ed a
> > fixed size format for SIDs instead of a variable length format lik= e
> > that described in RFC6554? Similarly, why does SR define it's own T= LV
> > format instead of using Hop-by-Hop and Destination Options defined= in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH a= nd LISP or Vector Routing as an alternative options. I really do not see a r= oom or need for yet one more mapping plane. What problem does it solve which= would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which require= additional per SR path state in both control plane and now in data plane ar= e really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to r= educe control plane state and processing. The trade-off for reduced control p= lane state and processing is to instead carry and encode most or all of that= information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensiv= e, then pushing some of that information and processing back into the contro= l plane should be ok, as long as there is still a beneficial overall reducti= on in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet= boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to= perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses, t= hat may also create some opportunities to leverage IPv4 support in existing p= rotocols to suite carrying and processing 32 bit SIDs with some, possibly sl= ight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leveraged= to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > -------------------------------------------------------------= -------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.= ......org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > -------------------------------------------------------------= -------

-----------------------------------------------------= ---------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------<= u>

--------= ------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailma= n/listinfo/ipv6
----------------------------------------= ----------------------------
= --Apple-Mail-2601A97C-0C72-4CD4-A101-333FA94EBCAE-- From nobody Sat Apr 20 12:50:59 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A7212027B for ; Sat, 20 Apr 2019 12:50:47 -0700 (PDT) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 L-M9sFux5vrQ for ; Sat, 20 Apr 2019 12:50:44 -0700 (PDT) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (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 6E2241201AC for ; Sat, 20 Apr 2019 12:50:41 -0700 (PDT) Received: by mail-qt1-x843.google.com with SMTP id i14so8525801qtr.10 for ; Sat, 20 Apr 2019 12:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8cIOafAuD2dsS28F5sWAySH6KcU89OCS2nRrwhffpEY=; b=nWdEaFzQMZDp5FpTV04CTZzVPcyHoy6wzG0WI+UQnJJ/YXuyc1PDRKzu9f7rE5BgNa /nmzK78E36u92FvanqCHRZL98yWJZJuSLQdPHByHb6X+eTfSo2lVO/w+BKiL3a/uBgCj GQC4/YD19iqyXHaogK2EL5+/+lJCKsx+iS7RbnTLo2PMIoTKlu3ucQ5xqXOx753zTsbO VGk52C5N9yUkckHAWmds8kPtHzu1pQbK2MjCYTog1CRA4a3ySxwhFbmLzCR4IAZhmE7r MJdsDUEJpsIsRRxorIemvKJ8fGyHOUieOR7EbC2LNsA8pNb+NgqCoGYbtO2I9PxdUGZ8 wC+Q== 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=8cIOafAuD2dsS28F5sWAySH6KcU89OCS2nRrwhffpEY=; b=Ua3BXkLjzWGPAvV/kPY+Lgunh4ztDHKfsF0UR7ouj3Mo90OZW13297byrxmjcOmooV KwD6S546IunIuDhU1BQQOujVVru2M82FnBht6fGx9sU3QcnyRDIGi1e8AqY6m1eSVDLV MFnwG45kfXUsQogefLsWCxAmkG+YMQCiZVX4nJOx1qKyU98/EOn8MbnoY6o0Rk6N+fh9 FvGGA4JiSilGrA56Iey8ZnJjpvRyzkwwtxBT8zJrH3aNdSV6XA61RkFm+l+Nckc0gPGN OdgCcCkizphQwunJn94FdrVoWHufNXmWWvA39NQb2hCFr687sBQlPVU3ux3qE5wSGe6R eG6A== X-Gm-Message-State: APjAAAU2qZrAD35m4yOUzLSyZsSroPalUtJIKHJWvkrPGevL2jWA9YnV AcEFu6ll0WYb5LN9BOuXL1KI9f3sRveTgupT25WUVw== X-Google-Smtp-Source: APXvYqwUrzMUSaYKBWSOXr3vQCc6PoNeBigv5CTeW9GK4osoqoRHYI9CKimeoLYDVdR2ZEmKjEQuu+NXhfN+GKyngBs= X-Received: by 2002:a05:6214:242:: with SMTP id k2mr2541089qvt.168.1555789840281; Sat, 20 Apr 2019 12:50:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Sat, 20 Apr 2019 12:50:27 -0700 Message-ID: To: Greg Mirsky Cc: Mark Smith , SPRING WG , Dino Farinacci , "ipv6@ietf.org" , "lisp@ietf.org list" , Robert Raszuk Content-Type: multipart/alternative; boundary="000000000000c687930586fb8ca0" Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 19:50:49 -0000 --000000000000c687930586fb8ca0 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 19, 2019, 5:54 PM Greg Mirsky wrote: > Hi Tom, > in draft-mirsky-6man-unified-id-sr > we've > proposed the use of 20 and 32 bits-long SIDs in SR EH. Two bits-long field > also defined in the Flags to identify the length of SID element in the SR > EH: > 0b00 - 128-bits SID; > 0b01 - 20-bits SID; > 0b10 - 32-bits SID > 0b11 - reserved for future use. > Hi Greg, 20 bit fields in a list seems a little odd; how is this packed in a packet? It's more typical to have byte alignment at least and if the fields hold numerical values they would usually be bytes, words, double words, etc. with natural alignment maintained. In a two bit representation of length, I think best possibilities are 16, 32, 64, and 128 bits. Tom > Much appreciate your comments on that draft, suggestions. > > Regards, > Greg > > > On Fri, Apr 12, 2019 at 3:09 PM Tom Herbert wrote: > >> On Fri, Apr 12, 2019 at 1:48 PM Mark Smith >> wrote: >> > >> > Hi Tom, >> > >> > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: >> > > >> > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk >> wrote: >> > > > >> > > > Hi Mark, >> > > > >> > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet >> boundary and a 32 bit alignment, >> > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 >> network. >> > > > > >> > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that may >> also create some opportunities to >> > > > > leverage IPv4 support in existing protocols to suite carrying and >> processing 32 bit SIDs with some, possibly >> > > > > slight, modification. For example, perhaps IPv4 Address Family >> support in OSPFv3 (RFC 5838) could be >> > > > > somehow leveraged to suit SR. >> > > > >> > > > >> > > > Thank you for describing your understanding of fundamentals of SR. >> > > > >> > > > I think SR while indeed started with the story of "less control >> plane is good for you" now clearly has evolved into not only reduction of >> control plane but what can be even more important to some users ability to >> request specific behavior via programmed functions of network elements on a >> per flow basis without actually per flow or per path signalling or state. >> > > > >> > > > Yes for some it may be very useful feature and I am sure some will >> call it overload of data plane or . There is no one size fits all. >> > > > >> > > > With that let's observe that till today SR did not require any new >> mapping plane to be distributed in control plane and to be inserted into >> data plane. This is clearly a precedent. >> > > > >> > > > Furthermore as we see in companion documents all additional network >> functionality is being taken away from SRH and is being shifted to >> Destination Options . >> > > > >> > > > As far as mapping plane I already pointed out in my Vector Routing >> proposal that we have one already it is called BGP. One needs to also >> observe that we as industry worked number of years of protocol suite called >> LISP allowing not only very good mapping plane, but also data plane >> integration. CC-ing lisp authors for their comments. Note also work for >> integrating SRv6 with LISP which is already is published. >> > > > >> > > > Since you correctly observed that now SID can be 32 bit and that is >> similar to the size of IPv4 my fundamental question is why not use >> something which already exists instead of defining some sort of new from >> scratch ? >> > > > >> > > Robert, >> > > >> > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you >> > > please provide a reference? >> > > >> > >> > To clarify, I've been thinking about the idea of a smaller SID size >> > for IPv6 for a while now (since inserting EHs came up), and thought >> > about what would be a generic single size that might suit SR that >> > wasn't the same size as an IPv6 address. 32 bits seemed suitable to >> > me, although if people wanted bigger, I'd be suggesting 64 bits (not >> > entirely coincidentally the common IID size.) >> > >> > Ron and others have written this draft, which supports SIDS of various >> > sizes - 8, 16 or 32 bits - that triggered this discussion. >> > >> Mark, >> >> Why not just put a SID length field in the header (like RFC6554 but >> more generic). That would allow lengths of 1-16 bytes. Additional >> flags could be used to indicate the semantics of the entries. For >> instance, they might be actual addresses (128 bits for IPv6, 32 bits >> for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) >> where the rest of the address can be inferred, indices into a table, >> labels, etc. >> >> Tom >> >> > "The IPv6 Compressed Routing Header (CRH)" >> > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 >> > >> > Regards, >> > Mark. >> > >> > >> > > As for trying to use something that already exists, why does SR used a >> > > fixed size format for SIDs instead of a variable length format like >> > > that described in RFC6554? Similarly, why does SR define it's own TLV >> > > format instead of using Hop-by-Hop and Destination Options defined in >> > > RFC8200? >> > > >> > > Tom >> > > >> > > > It will be perfectly fine to have full proper SRv6 with SRH and >> LISP or Vector Routing as an alternative options. I really do not see a >> room or need for yet one more mapping plane. What problem does it solve >> which would not be already solved elsewhere ? >> > > > >> > > > Kind regards, >> > > > Robert >> > > > >> > > > >> > > >>> 2) Is there an agreement that solutions which require additional >> per SR path state in both control plane and now in data plane are really >> something we should be endorsing here ? >> > > >> >> > > >> >> > > >> I think so. >> > > >> >> > > >> My understanding of what SR is fundamentally about is to reduce >> control plane state and processing. The trade-off for reduced control plane >> state and processing is to instead carry and encode most or all of that >> information or its semantics as per-packet overhead. >> > > >> >> > > >> If the per-packet overhead becomes too large and expensive, then >> pushing some of that information and processing back into the control plane >> should be ok, as long as there is still a beneficial overall reduction in >> control plane state and processing. >> > > >> >> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary >> and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform >> SR in an IPv6 network. >> > > >> >> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may >> also create some opportunities to leverage IPv4 support in existing >> protocols to suite carrying and processing 32 bit SIDs with some, possibly >> slight, modification. For example, perhaps IPv4 Address Family support in >> OSPFv3 (RFC 5838) could be somehow leveraged to suit SR. >> > > >> >> > > >> Regards, >> > > >> Mark. >> > > > >> > > > -------------------------------------------------------------------- >> > > > IETF IPv6 working group mailing list >> > > > ipv6@ietf.org >> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > > > -------------------------------------------------------------------- >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > --000000000000c687930586fb8ca0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 19, 2019, 5:54 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
<= /div>
Hi Tom,
in=C2=A0draft-= mirsky-6man-unified-id-sr=C2=A0we've proposed the use of 20 and 32 = bits-long SIDs in SR EH. Two bits-long field also defined in the Flags to i= dentify the length of SID element in the SR EH:
=C2=A0 =C2= =A0 =C2=A0 0b00 - 128-bits SID;
=C2=A0 =C2=A0 =C2=A0 0b01 - 20-bi= ts SID;
=C2=A0 =C2=A0 =C2=A0 0b10 - 32-bits SID
=C2=A0 = =C2=A0 =C2=A0 0b11 - reserved for future use.
=

Hi G= reg,

20 bit fields in a = list seems a little odd; how is this packed in a packet? It's more typi= cal to have byte alignment at least and if the fields hold numerical values= they would usually be bytes, words, double words, etc. with natural alignm= ent maintained. In a two bit representation of length, I think best possibi= lities are 16, 32, 64, and 128 bits.

Tom


Much appreciate your comment= s on that draft, suggestions.

Regards,
G= reg


On Fri, Apr 12, 2019 at 3:09 PM Tom Her= bert <tom@herbertland.com> wrote:
On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <= ;markzzzsmith@gmail.com> wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com= > wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.ne= t> wrote:
> > >
> > > Hi Mark,
> > >
> > > > As MPLS SR SIDs are 20 bits, then rounding up to an oct= et boundary and a 32 bit alignment,
> > > > I'd think 32 bit SIDs would be adequate to perform = SR in an IPv6 network.
> > > >
> > > > As 32 bit SIDs are also the same size as IPv4 addresses= , that may also create some opportunities to
> > > > leverage IPv4 support in existing protocols to suite ca= rrying and processing 32 bit SIDs with some, possibly
> > > > slight, modification. For example, perhaps IPv4 Address= Family support in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged to suit SR.
> > >
> > >
> > > Thank you for describing your understanding of fundamentals = of SR.
> > >
> > > I think SR while indeed started with the story of "less= control plane is good for you" now clearly has evolved into not only = reduction of control plane but what can be even more important to some user= s ability to request specific behavior via programmed functions of network = elements on a per flow basis without actually per flow or per path signalli= ng or state.
> > >
> > > Yes for some it may be very useful feature and I am sure som= e will call it overload of data plane or . There is no one size fits all. > > >
> > > With that let's observe that till today SR did not requi= re any new mapping plane to be distributed in control plane and to be inser= ted into data plane. This is clearly a precedent.
> > >
> > > Furthermore as we see in companion documents all additional = network functionality is being taken away from SRH and is being shifted to = Destination Options .
> > >
> > > As far as mapping plane I already pointed out in my Vector R= outing proposal that we have one already it is called BGP. One needs to als= o observe that we as industry worked number of years of protocol suite call= ed LISP allowing not only very good mapping plane, but also data plane inte= gration. CC-ing lisp authors for their comments. Note also work for integra= ting SRv6 with LISP which is already is published.
> > >
> > > Since you correctly observed that now SID can be 32 bit and = that is similar to the size of IPv4 my fundamental question is why not use = something which already exists instead of defining some sort of new=C2=A0 f= rom scratch ?
> > >
> > Robert,
> >
> > I don't see in the SRH draft where 32 bit SIDs are defined. C= an you
> > please provide a reference?
> >
>
> To clarify, I've been thinking about the idea of a smaller SID siz= e
> for IPv6 for a while now (since inserting EHs came up), and thought > about what would be a generic single size that might suit SR that
> wasn't the same size as an IPv6 address. 32 bits seemed suitable t= o
> me, although if people wanted bigger, I'd be suggesting 64 bits (n= ot
> entirely coincidentally the common IID size.)
>
> Ron and others have written this draft, which supports SIDS of various=
> sizes - 8, 16 or 32 bits - that triggered this discussion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/= html/draft-bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
>
>
> > As for trying to use something that already exists, why does SR u= sed a
> > fixed size format for SIDs instead of a variable length format li= ke
> > that described in RFC6554? Similarly, why does SR define it's= own TLV
> > format instead of using Hop-by-Hop and Destination Options define= d in
> > RFC8200?
> >
> > Tom
> >
> > > It will be perfectly fine to have full proper SRv6 with SRH = and LISP or Vector Routing as an alternative options. I really do not see a= room or need for yet one more mapping plane. What problem does it solve wh= ich would not be already solved elsewhere ?
> > >
> > > Kind regards,
> > > Robert
> > >
> > >
> > >>> 2) Is there an agreement that solutions which requir= e additional per SR path state in both control plane and now in data plane = are really something we should be endorsing here ?
> > >>
> > >>
> > >> I think so.
> > >>
> > >> My understanding of what SR is fundamentally about is to= reduce control plane state and processing. The trade-off for reduced contr= ol plane state and processing is to instead carry and encode most or all of= that information or its semantics as per-packet overhead.
> > >>
> > >> If the per-packet overhead becomes too large and expensi= ve, then pushing some of that information and processing back into the cont= rol plane should be ok, as long as there is still a beneficial overall redu= ction in control plane state and processing.
> > >>
> > >> As MPLS SR SIDs are 20 bits, then rounding up to an octe= t boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequ= ate to perform SR in an IPv6 network.
> > >>
> > >> As 32 bit SIDs are also the same size as IPv4 addresses,= that may also create some opportunities to leverage IPv4 support in existi= ng protocols to suite carrying and processing 32 bit SIDs with some, possib= ly slight, modification. For example, perhaps IPv4 Address Family support i= n OSPFv3 (RFC 5838) could be somehow leveraged to suit SR.
> > >>
> > >> Regards,
> > >> Mark.
> > >
> > > ------------------------------------------------------------= --------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https:/= /www.ietf.org/mailman/listinfo/ipv6
> > > ------------------------------------------------------------= --------

_______________________________________________
spring mailing list
spr= ing@ietf.org
https://www.ietf.org/mailman/listinfo/spring<= /a>
--000000000000c687930586fb8ca0-- From nobody Sun Apr 21 12:46:11 2019 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E771203E2; Sun, 21 Apr 2019 12:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 7QU5AHT1QbBe; Sun, 21 Apr 2019 12:45:50 -0700 (PDT) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 345621203DB; Sun, 21 Apr 2019 12:45:50 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id t11so7527541lfl.12; Sun, 21 Apr 2019 12:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CuHatCMinUt8K61MjvkUWCeUCzzVMXf/+npgwmMmVMk=; b=FxnDpOScHAmB1J6F7SvUxn1KevAyTvYAExxAPxvVlk0lNI50+8o+t1wvA2J4PQ6vur q1g+7TbtvvISWFtq9BfolBkRHGiLgLU1tBmesWM31SD1tdELi09IFOrX+8DnZPdOyWXG B7KNJZwZjd5eJlCQuhpiYESPsH5xSb4Btqp/LvFwM5Bi0xGC96UVxCz2fzqKAovDIx7R FyX++p/MFuEeKG7aR2npE4bHC1QZ1Ili2LFrSkmXOnIct+mhglIgrf8cZMq0rb/bb05I N6mkj4idf2jrP5dbKfZZRyY9+4jtWPubC5BRItzu+wvhh+qJ6OJo3GzWSZdDXHGhtNSp H9kQ== 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=CuHatCMinUt8K61MjvkUWCeUCzzVMXf/+npgwmMmVMk=; b=V1ypLTKvv/IM021m/ORaT2tM3AvW3H4DiWY2LtUqoxW4WS23f7stSsxlSPZQRRT76i ypAO2vXyRZG2H/d/3nfn6ZltnpbfIjuqDfyljuVQp1klUE128Pute+HaXQ5lq/uwjvHL XzYWs3Jonio712aFRtLruDI5PX/oLd7Ll0Bmu3iSYejQaZ+fgOhOfDtXAbOZEJLW2etX eB/e/SKbZ7ErIrxxHE9EDs6WGgqIyB+zIFqE3d01IAARoHX22BuwRbvIYX9YiAUv84TK 0z9aqnGucZ0XQgImxfcgT943chmpKtgoKuAKfUsTJ0yCmM5teMiSJHpJ1IO41QtXqdk9 SRnQ== X-Gm-Message-State: APjAAAVYUArJKBuaNUUQ8nTIZXfELye7Ht97WfQWr2tckPNSuUp3S3tK wHVgyfI7sk48KLi1/QeBx1OjsBB7tjyznkN5wx8= X-Google-Smtp-Source: APXvYqzb3HwMyfuv+s3JTf0BadnVqXEzZmScKW/FtQMziflQgwsUV6r0P1Xycn0Xdog/n6jLy8bZvQaNQ32IvAwC/78= X-Received: by 2002:ac2:5a11:: with SMTP id q17mr8236063lfn.145.1555875948281; Sun, 21 Apr 2019 12:45:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Sun, 21 Apr 2019 12:45:36 -0700 Message-ID: To: Tom Herbert Cc: Mark Smith , SPRING WG , Dino Farinacci , "ipv6@ietf.org" , "lisp@ietf.org list" , Robert Raszuk Content-Type: multipart/alternative; boundary="0000000000003643be05870f99ae" Archived-At: Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2019 19:45:55 -0000 --0000000000003643be05870f99ae Content-Type: text/plain; charset="UTF-8" Hi Tom, thank you for your feedback and the suggestion. In proposing the use of 20 bits-long SID we've followed the existing IGP-SR extensions. Both draft-ietf-ospf-segment-routing-extensions and draft-ietf-isis-segment-routing-extensions advertisement of 4 octets-long SIDs as well as 20 bits-long (the latter as 20 rightmost bits in 3 octets-long field). Though the proposal to using 20 bits-long SIDs in IPv6 SR EH may be considered as duplication of the draft-ietf-mpls-sr-over-ip, SR EH has very useful property, for example in OAM, of preserving the SR path. I think that we can expand the length of the field in SR EH to support 16 and 64 bits-long SIDs in addition to ones being proposed in the draft. Much appreciate your comments. Regards, Greg On Sat, Apr 20, 2019 at 12:50 PM Tom Herbert wrote: > > > On Fri, Apr 19, 2019, 5:54 PM Greg Mirsky wrote: > >> Hi Tom, >> in draft-mirsky-6man-unified-id-sr >> we've >> proposed the use of 20 and 32 bits-long SIDs in SR EH. Two bits-long field >> also defined in the Flags to identify the length of SID element in the SR >> EH: >> 0b00 - 128-bits SID; >> 0b01 - 20-bits SID; >> 0b10 - 32-bits SID >> 0b11 - reserved for future use. >> > > Hi Greg, > > 20 bit fields in a list seems a little odd; how is this packed in a > packet? It's more typical to have byte alignment at least and if the fields > hold numerical values they would usually be bytes, words, double words, > etc. with natural alignment maintained. In a two bit representation of > length, I think best possibilities are 16, 32, 64, and 128 bits. > > Tom > > >> Much appreciate your comments on that draft, suggestions. >> >> Regards, >> Greg >> >> >> On Fri, Apr 12, 2019 at 3:09 PM Tom Herbert wrote: >> >>> On Fri, Apr 12, 2019 at 1:48 PM Mark Smith >>> wrote: >>> > >>> > Hi Tom, >>> > >>> > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: >>> > > >>> > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk >>> wrote: >>> > > > >>> > > > Hi Mark, >>> > > > >>> > > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet >>> boundary and a 32 bit alignment, >>> > > > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 >>> network. >>> > > > > >>> > > > > As 32 bit SIDs are also the same size as IPv4 addresses, that >>> may also create some opportunities to >>> > > > > leverage IPv4 support in existing protocols to suite carrying >>> and processing 32 bit SIDs with some, possibly >>> > > > > slight, modification. For example, perhaps IPv4 Address Family >>> support in OSPFv3 (RFC 5838) could be >>> > > > > somehow leveraged to suit SR. >>> > > > >>> > > > >>> > > > Thank you for describing your understanding of fundamentals of SR. >>> > > > >>> > > > I think SR while indeed started with the story of "less control >>> plane is good for you" now clearly has evolved into not only reduction of >>> control plane but what can be even more important to some users ability to >>> request specific behavior via programmed functions of network elements on a >>> per flow basis without actually per flow or per path signalling or state. >>> > > > >>> > > > Yes for some it may be very useful feature and I am sure some will >>> call it overload of data plane or . There is no one size fits all. >>> > > > >>> > > > With that let's observe that till today SR did not require any new >>> mapping plane to be distributed in control plane and to be inserted into >>> data plane. This is clearly a precedent. >>> > > > >>> > > > Furthermore as we see in companion documents all additional >>> network functionality is being taken away from SRH and is being shifted to >>> Destination Options . >>> > > > >>> > > > As far as mapping plane I already pointed out in my Vector Routing >>> proposal that we have one already it is called BGP. One needs to also >>> observe that we as industry worked number of years of protocol suite called >>> LISP allowing not only very good mapping plane, but also data plane >>> integration. CC-ing lisp authors for their comments. Note also work for >>> integrating SRv6 with LISP which is already is published. >>> > > > >>> > > > Since you correctly observed that now SID can be 32 bit and that >>> is similar to the size of IPv4 my fundamental question is why not use >>> something which already exists instead of defining some sort of new from >>> scratch ? >>> > > > >>> > > Robert, >>> > > >>> > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you >>> > > please provide a reference? >>> > > >>> > >>> > To clarify, I've been thinking about the idea of a smaller SID size >>> > for IPv6 for a while now (since inserting EHs came up), and thought >>> > about what would be a generic single size that might suit SR that >>> > wasn't the same size as an IPv6 address. 32 bits seemed suitable to >>> > me, although if people wanted bigger, I'd be suggesting 64 bits (not >>> > entirely coincidentally the common IID size.) >>> > >>> > Ron and others have written this draft, which supports SIDS of various >>> > sizes - 8, 16 or 32 bits - that triggered this discussion. >>> > >>> Mark, >>> >>> Why not just put a SID length field in the header (like RFC6554 but >>> more generic). That would allow lengths of 1-16 bytes. Additional >>> flags could be used to indicate the semantics of the entries. For >>> instance, they might be actual addresses (128 bits for IPv6, 32 bits >>> for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) >>> where the rest of the address can be inferred, indices into a table, >>> labels, etc. >>> >>> Tom >>> >>> > "The IPv6 Compressed Routing Header (CRH)" >>> > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 >>> > >>> > Regards, >>> > Mark. >>> > >>> > >>> > > As for trying to use something that already exists, why does SR used >>> a >>> > > fixed size format for SIDs instead of a variable length format like >>> > > that described in RFC6554? Similarly, why does SR define it's own TLV >>> > > format instead of using Hop-by-Hop and Destination Options defined in >>> > > RFC8200? >>> > > >>> > > Tom >>> > > >>> > > > It will be perfectly fine to have full proper SRv6 with SRH and >>> LISP or Vector Routing as an alternative options. I really do not see a >>> room or need for yet one more mapping plane. What problem does it solve >>> which would not be already solved elsewhere ? >>> > > > >>> > > > Kind regards, >>> > > > Robert >>> > > > >>> > > > >>> > > >>> 2) Is there an agreement that solutions which require additional >>> per SR path state in both control plane and now in data plane are really >>> something we should be endorsing here ? >>> > > >> >>> > > >> >>> > > >> I think so. >>> > > >> >>> > > >> My understanding of what SR is fundamentally about is to reduce >>> control plane state and processing. The trade-off for reduced control plane >>> state and processing is to instead carry and encode most or all of that >>> information or its semantics as per-packet overhead. >>> > > >> >>> > > >> If the per-packet overhead becomes too large and expensive, then >>> pushing some of that information and processing back into the control plane >>> should be ok, as long as there is still a beneficial overall reduction in >>> control plane state and processing. >>> > > >> >>> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet >>> boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to >>> perform SR in an IPv6 network. >>> > > >> >>> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may >>> also create some opportunities to leverage IPv4 support in existing >>> protocols to suite carrying and processing 32 bit SIDs with some, possibly >>> slight, modification. For example, perhaps IPv4 Address Family support in >>> OSPFv3 (RFC 5838) could be somehow leveraged to suit SR. >>> > > >> >>> > > >> Regards, >>> > > >> Mark. >>> > > > >>> > > > >>> -------------------------------------------------------------------- >>> > > > IETF IPv6 working group mailing list >>> > > > ipv6@ietf.org >>> > > > Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> > > > >>> -------------------------------------------------------------------- >>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>> >> --0000000000003643be05870f99ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,
thank you for your feedback and the suggestion. In pr= oposing the use of 20 bits-long=C2=A0SID we've followed the existing IG= P-SR extensions. Both draft-ietf-ospf-segment-routing-extensions and=C2=A0d= raft-ietf-isis-segment-routing-extensions advertisement of 4 octets-long SI= Ds as well as 20 bits-long (the latter as 20 rightmost bits in 3 octets-lon= g field). Though the proposal to using 20 bits-long SIDs in IPv6 SR EH may = be considered as duplication of the=C2=A0draft-ietf-mpls-sr-over-ip, SR EH = has very useful property, for example in OAM, of preserving the SR path.
I think that we can expand the length of the field in SR EH to supp= ort 16 and 64 bits-long SIDs in addition to ones being proposed in the draf= t.
Much appreciate your comments.

Regard= s,
Greg

On Sat, Apr 20, 2019 at 12:50 PM T= om Herbert <tom@herbertland.com> wrote:


Hi Tom,
in=C2=A0draft-mirsky-6man-unified-id-sr=C2=A0we&#= 39;ve proposed the use of 20 and 32 bits-long SIDs in SR EH. Two bits-long = field also defined in the Flags to identify the length of SID element in th= e SR EH:
=C2=A0 =C2=A0 =C2=A0 0b00 - 128-bits SID;
=C2=A0 =C2=A0 =C2=A0 0b01 - 20-bits SID;
=C2=A0 =C2=A0 =C2=A0 0b= 10 - 32-bits SID
=C2=A0 =C2=A0 =C2=A0 0b11 - reserved for future = use.

Hi Greg,

20 bit fields in a list seems a little odd; how is this pack= ed in a packet? It's more typical to have byte alignment at least and i= f the fields hold numerical values they would usually be bytes, words, doub= le words, etc. with natural alignment maintained. In a two bit representati= on of length, I think best possibilities are 16, 32, 64, and 128 bits.

Tom
<= br>

Much appreciate your comments on that draft, sugge= stions.

Regards,
Greg


On Fri, Apr 12, 2019 at 3:09 PM Tom Herbert <tom@herber= tland.com> wrote:
On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@= gmail.com> wrote:
>
> Hi Tom,
>
> On Sat, 13= Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
= > >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <rob= ert@raszuk.net> wrote:
> > >
> > > Hi Mark,<= br>> > >
> > > > As MPLS SR SIDs are 20 bits, then = rounding up to an octet boundary and a 32 bit alignment,
> > > = > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 n= etwork.
> > > >
> > > > As 32 bit SIDs are al= so the same size as IPv4 addresses, that may also create some opportunities= to
> > > > leverage IPv4 support in existing protocols to s= uite carrying and processing 32 bit SIDs with some, possibly
> > &= gt; > slight, modification. For example, perhaps IPv4 Address Family sup= port in OSPFv3 (RFC 5838) could be
> > > > somehow leveraged= to suit SR.
> > >
> > >
> > > Thank yo= u for describing your understanding of fundamentals of SR.
> > >= ;
> > > I think SR while indeed started with the story of "= ;less control plane is good for you" now clearly has evolved into not = only reduction of control plane but what can be even more important to some= users ability to request specific behavior via programmed functions of net= work elements on a per flow basis without actually per flow or per path sig= nalling or state.
> > >
> > > Yes for some it may b= e very useful feature and I am sure some will call it overload of data plan= e or . There is no one size fits all.
> > >
> > > W= ith that let's observe that till today SR did not require any new mappi= ng plane to be distributed in control plane and to be inserted into data pl= ane. This is clearly a precedent.
> > >
> > > Furth= ermore as we see in companion documents all additional network functionalit= y is being taken away from SRH and is being shifted to Destination Options = .
> > >
> > > As far as mapping plane I already poi= nted out in my Vector Routing proposal that we have one already it is calle= d BGP. One needs to also observe that we as industry worked number of years= of protocol suite called LISP allowing not only very good mapping plane, b= ut also data plane integration. CC-ing lisp authors for their comments. Not= e also work for integrating SRv6 with LISP which is already is published.> > >
> > > Since you correctly observed that now SI= D can be 32 bit and that is similar to the size of IPv4 my fundamental ques= tion is why not use something which already exists instead of defining some= sort of new=C2=A0 from scratch ?
> > >
> > Robert,> >
> > I don't see in the SRH draft where 32 bit SIDs = are defined. Can you
> > please provide a reference?
> ><= br>>
> To clarify, I've been thinking about the idea of a smal= ler SID size
> for IPv6 for a while now (since inserting EHs came up)= , and thought
> about what would be a generic single size that might = suit SR that
> wasn't the same size as an IPv6 address. 32 bits s= eemed suitable to
> me, although if people wanted bigger, I'd be = suggesting 64 bits (not
> entirely coincidentally the common IID size= .)
>
> Ron and others have written this draft, which supports S= IDS of various
> sizes - 8, 16 or 32 bits - that triggered this discu= ssion.
>
Mark,

Why not just put a SID length field in the header (like RFC6554 but
= more generic). That would allow lengths of 1-16 bytes. Additional
flags = could be used to indicate the semantics of the entries. For
instance, th= ey might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), part= s of addresses (prefixes of suffixes like in RFC6554)
where the rest of = the address can be inferred, indices into a table,
labels, etc.

Tom

> "The IPv6 Compressed Routing Header (CRH)"
> https://tools.ietf.org/html/draft= -bonica-6man-comp-rtg-hdr-03
>
> Regards,
> Mark.
= >
>
> > As for trying to use something that already exist= s, why does SR used a
> > fixed size format for SIDs instead of a = variable length format like
> > that described in RFC6554? Similar= ly, why does SR define it's own TLV
> > format instead of usin= g Hop-by-Hop and Destination Options defined in
> > RFC8200?
&g= t; >
> > Tom
> >
> > > It will be perfectl= y fine to have full proper SRv6 with SRH and LISP or Vector Routing as an a= lternative options. I really do not see a room or need for yet one more map= ping plane. What problem does it solve which would not be already solved el= sewhere ?
> > >
> > > Kind regards,
> > &g= t; Robert
> > >
> > >
> > >>> 2) = Is there an agreement that solutions which require additional per SR path s= tate in both control plane and now in data plane are really something we sh= ould be endorsing here ?
> > >>
> > >>
>= ; > >> I think so.
> > >>
> > >> My = understanding of what SR is fundamentally about is to reduce control plane = state and processing. The trade-off for reduced control plane state and pro= cessing is to instead carry and encode most or all of that information or i= ts semantics as per-packet overhead.
> > >>
> > >= ;> If the per-packet overhead becomes too large and expensive, then push= ing some of that information and processing back into the control plane sho= uld be ok, as long as there is still a beneficial overall reduction in cont= rol plane state and processing.
> > >>
> > >>= As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and a 3= 2 bit alignment, I'd think 32 bit SIDs would be adequate to perform SR = in an IPv6 network.
> > >>
> > >> As 32 bit S= IDs are also the same size as IPv4 addresses, that may also create some opp= ortunities to leverage IPv4 support in existing protocols to suite carrying= and processing 32 bit SIDs with some, possibly slight, modification. For e= xample, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be s= omehow leveraged to suit SR.
> > >>
> > >> Re= gards,
> > >> Mark.
> > >
> > > ----= ----------------------------------------------------------------
> &g= t; > IETF IPv6 working group mailing list
> > > ipv6@ietf.org=
> > > Administrative Requests: htt= ps://www.ietf.org/mailman/listinfo/ipv6
> > > -------------= -------------------------------------------------------

_______________________________________________
spring mailing list<= br> spr= ing@ietf.org
https://www.ietf.org/mailman/listinfo/spring<= /a>