Re: [spring] Comments on < draft-filsfils-spring-net-pgm-extension-srv6-usid-00>

Robert Raszuk <rraszuk@gmail.com> Wed, 17 July 2019 06:42 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC86120072; Tue, 16 Jul 2019 23:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 VtKfai33tLcl; Tue, 16 Jul 2019 23:42:22 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 180DC12006D; Tue, 16 Jul 2019 23:42:22 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id t132so10644113pgb.9; Tue, 16 Jul 2019 23:42:22 -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=lMgFs7dFKvHYOnTIJvRE2gf9lZkO/sp3TvyuRBc+gaA=; b=po03ty6uLtcngZ3F2UxcYoKyLcZfrZcroYligQehksqvsnBj65jlw0QsCP88O5aS1V 35PyL6hiEf1qkwgCKSxNXHCI0xOc3S5/MDeW01s80BDg7HLnuCY9BSZirISvOO/UkEpR MY7CEsPYVdd+HBapSFOLAzsmp46J7tdwaVbKCazRhN1hg7dXyT+NXwsERYGE/VQ1meOO UL43SoLovcGQKb0Rt2qHgzXC5dnS44vpccsshUQrA3x3xcivHQlSoqvk9LSTvhlmeC6c 2gafuT5gW2Fu3T/odV9wW7GBFgv5qBMXsl7HiW0KAglg1R7BHOCsLAoY29xWj8w4KRp9 lCJg==
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=lMgFs7dFKvHYOnTIJvRE2gf9lZkO/sp3TvyuRBc+gaA=; b=AvIzQ09R1FTt+3ZHKoOsGRS27k+nN40B++K5EGjGDZgfM5DaE55QywH+3Vvr2/DgU2 rSQFf/DAwzIA1NkfCbTxrPY4XTD70X8sDuI8/7taXL8xNZTfB14N2ckiKXjBw7mS/hpg ku1Itp4Fm7npEnVBb1X0qvCkRuzL6GZgLSeZO2a5rFd+jwDDXUlIiHnNhf2vwsd0gnmO Fd3KVQTaCUaw2uChYJrgaYwk/ChFAMdogkHEYpbJFlYKB/5H+N1y/rOtIb4Fi1MpegYJ A6ylQtCYm+fb/kIgn8/JEioUtUnJy491KVVIva2QvVY81vjfpgb4F8EiDS8FAFh50qNJ 0Egw==
X-Gm-Message-State: APjAAAX02NUMjFt4zMXkNz5DiyKttR6Wx2mghUoO4JE/4zIbcTxNh1uc Q+v1d8QOCX/AdmE9NWCU1TB22w/MUPVa6utWl60=
X-Google-Smtp-Source: APXvYqxHqK7FYW3uZVeaRutK9rTbuTo9KV3Pb5tXLCvaZo7HQaq0sgw37THEWn2G7UD8XtyEH5TkH02QLp3y9NoPrC0=
X-Received: by 2002:a63:c44c:: with SMTP id m12mr1606572pgg.396.1563345741147; Tue, 16 Jul 2019 23:42:21 -0700 (PDT)
MIME-Version: 1.0
References: <4C892716-11EA-41D1-8062-A2DFF6D735AA@gmail.com>
In-Reply-To: <4C892716-11EA-41D1-8062-A2DFF6D735AA@gmail.com>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Wed, 17 Jul 2019 08:42:10 +0200
Message-ID: <CA+b+ERm=J64WXEkKaR8gNfRfA_f3AqD_H8fvAPUedA43cad-aA@mail.gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
Cc: SPRING WG <spring@ietf.org>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008ff177058ddacb87"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/4WsxwhJNnRJCDCu6zwu8SAkVsa8>
Subject: Re: [spring] Comments on < draft-filsfils-spring-net-pgm-extension-srv6-usid-00>
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2019 06:42:24 -0000

HI Bob,

The way I read this document is that FC00::/8 is just an example. If IETF
decided to allocate a new prefix I think no one will object that.

> How many segments are needed to be identified?  Surely not 2^^112.

The crux of the proposal is in embedding multiple microSIDs in the *single*
IPv6 address. So if we consume say 16 bits for prefix we are left with 112
bits for SIDs.

Say SID would be of 16 bits so we can at most in dst address of single
encapsulated packet impose 7 SIDs. Not sure where you 2 to the power of 112
comes from - there is no "SID stacking" here any more :).

Cheers,
R.

On Wed, Jul 17, 2019 at 5:01 AM Bob Hinden <bob.hinden@gmail.com> wrote:

> Hi,
>
> I was looking at < draft-filsfils-spring-net-pgm-extension-srv6-usid-00>
> and have a few comments.  I am copying the 6MAN list because of its use of
> IPv6 addresses.
>
> The draft says:
>
>    uSID block: A block of uSID's
>
>       It can be any IPv6 prefix allocated to the provider (e.g. /40 or
>       /48), or it can be any block generally available for private use.
>       An SR domain may have multiple uSID blocks.
>
>       In this document we leverage FC00::/8 block reserved for private
>       use as ULA space (RFC4193).  Throughout this document we use
>       FC00::/16 as the illustrated uSID block.  ULA space allows for up
>       to 256 uSID blocks in FC00::/8.
>
> The first sentence in the first paragraph is fine, as it is proposing
> using prefixes assigned to the provider.   The rest is not fine.
>
> ULA space as defined in RFC4193 is not for use like this.   RFC4193
> specifies:
>
>    The Local IPv6 addresses are created using a pseudo-randomly
>    allocated global ID.  They have the following format:
>
>       | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
>       +--------+-+------------+-----------+----------------------------+
>       | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
>       +--------+-+------------+-----------+----------------------------+
>
> It is inappropriate to use the a large portion of ULA space (aka
> FC00::/16) in the manner proposed by this draft.   A better alternative for
> a provider using SRH is to generate an /48 ULA prefix as defined in RFC4193
> and use it for this purpose.  What is proposed in this document will break
> ULAs for everyone else.
>
> This draft (nor any future drafts in Spring) should not be redefining the
> IPv6 address space.   It is also very excessive to use this much address
> space to identify segments in a SRH network.   How many segments are needed
> to be identified?  Surely not 2^^112.
>
> Regards,
> Bob
>
>
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>