Re: [spring] Updating the SPRING WG Charter

Robert Raszuk <robert@raszuk.net> Fri, 08 June 2018 20:43 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 47AD813103A for <spring@ietfa.amsl.com>; Fri, 8 Jun 2018 13:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level:
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 50n-m256Nb6C for <spring@ietfa.amsl.com>; Fri, 8 Jun 2018 13:43:42 -0700 (PDT)
Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48B012F1A5 for <spring@ietf.org>; Fri, 8 Jun 2018 13:43:42 -0700 (PDT)
Received: by mail-pl0-x22b.google.com with SMTP id z9-v6so8918789plk.11 for <spring@ietf.org>; Fri, 08 Jun 2018 13:43:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eI6gzfvJqNyu3SIlqSERecWUHKsSQViTz/AxIUApU8U=; b=E2qPZ8ZEJShgslM5VW4x4hQ40H7ydI+BHBtp5iUPQuUFEE5doZE9n6BVLmT+lm9zdX CznjXy6SqpezaclhQyQelaz2D4xyaEfOyobwZb1Xx1seroJ5ehtDnz+N9BM7C7LdQQB6 4MZnDwtW8u+d7vyfgRwPnaZ5vw8gfhzFx3Tq/MxTUuElqbEG0AR8uUREY+Ci+cxkI9RL IA6yVecG6FsXH5NlAxzixw5YPsfTwLpl58hMMRtjvYLFwLyQEOnWALTrlKcK0lasoMhD /76Ty0lJYSpJcQqYE6wiYtxAElArPC4UgF5Oa/fqQnpe1p/anvNLeDBbqjs1/7rVzJkN Uf0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eI6gzfvJqNyu3SIlqSERecWUHKsSQViTz/AxIUApU8U=; b=VLlllUKIQZj+uugJ28pt8YLD7xPdujqG5Y/6nSNtRVxjg86EsaEsya8eCRwebEYby2 LlGxVfV1eZnq4uUFJspjOlznSRIufMv+4BdkIw5zmbuJFbDTQ7Dk4cxAPNnC+8BFOZ0P 2meY0nsSThJ24Sy1h1azjC/4COGftVEmd41IBGw9bYCsbPitB8LiagtiHM8hxtzTZvHD LxIT5u9We7uHYlEt546lYxdogEBtaGIfaWl5piF181QLpTSjJ9HMPnshdgl7saV48Pse bmzYKFGfdX7BqRpMzAZCBcHA7k2bjQpJY4DIvbAXu4EFsufKMVQZJzrZs6heTI5UQ6Nj fFdw==
X-Gm-Message-State: APt69E1c/rouXiIEmblpcme4C8vzhuSFxOU8/W6PgEEPHVW1NkKb3p/e RAfx+5J9lQe9RxwGVU7FlKcHigJjS0Mw4s9hVBo=
X-Google-Smtp-Source: ADUXVKIyua9T4TBBu8URTsYytnUr0+AGIgWgTGTXg694c6KxIYh8WbMHuq8RwkvnQ1wxanCv61YY9t8QWtVVixgjHms=
X-Received: by 2002:a17:902:7896:: with SMTP id q22-v6mr8136272pll.243.1528490621853; Fri, 08 Jun 2018 13:43:41 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 2002:a17:90a:9202:0:0:0:0 with HTTP; Fri, 8 Jun 2018 13:43:40 -0700 (PDT)
In-Reply-To: <DB5PR0301MB19091032724ED7EDC11F63659D7B0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
References: <8CCB28152EA2E14A96BBEDC15823481A1CB79F12@sjceml521-mbs.china.huawei.com> <16253F7987E4F346823E305D08F9115A99A7D4CE@nkgeml514-mbx.china.huawei.com> <CAHd-QWvx-tkP1Asx3PwM3p2=wjuJm7b=A4Hb-BUnCMRzwT1J8w@mail.gmail.com> <8CCB28152EA2E14A96BBEDC15823481A1CB7FBFE@sjceml521-mbs.china.huawei.com> <CAHd-QWu+184A3Nje_Bmki9A3wwpp=4YyyKTTkWBtLcf_gt7Lvg@mail.gmail.com> <75252B5F-6BCB-4166-ACC1-C9E9697B7B68@cisco.com> <CA802BB9-00E2-4DA4-B7F2-B0ECB5DBD8FD@bell.ca> <DB5PR0301MB1909A63446648764B90DA47D9D640@DB5PR0301MB1909.eurprd03.prod.outlook.com> <CA+b+ERnV1f9LoPUn0N7f5yHS4BWmHRKfdyF62tin2eSXOpx_yw@mail.gmail.com> <a57dfef6-40c6-eece-7c9a-2517fc0c5d16@juniper.net> <CA+b+ER=UknPNDweStHDXvbsuqkL2+r5=5zzS4ujAredew_F_vQ@mail.gmail.com> <DB5PR0301MB19094268D61209CFB345DE609D7B0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <CA+b+ER=WX6WOxM7BhiysZxY39dNYYAHwT2hemR-tD+PLGi+KiQ@mail.gmail.com> <DM5PR21MB018696A5159598D791C30830CA7B0@DM5PR21MB0186.namprd21.prod.outlook.com> <DB5PR0301MB19091032724ED7EDC11F63659D7B0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 08 Jun 2018 22:43:40 +0200
X-Google-Sender-Auth: 6qHRN7N-LGoyY4dUEGdy--X3Y6E
Message-ID: <CA+b+ERmzd1SjX4VqONwQGcUuD7rjuzx1zXb1nE3AyHWErBhMRw@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: Paul Mattes <pamattes@microsoft.com>, "spring@ietf.org" <spring@ietf.org>, Xiejingrong <xiejingrong@huawei.com>, Michael McBride <michael.mcbride@huawei.com>, Rob Shakir <robjs=40google.com@dmarc.ietf.org>, "Zafar Ali (zali)" <zali@cisco.com>, Eric C Rosen <erosen@juniper.net>, "Voyer, Daniel" <daniel.voyer@bell.ca>
Content-Type: multipart/alternative; boundary="0000000000008ee6a5056e277446"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/oJiM5zqLd0YHHdjN3O7nMgWY9Ks>
Subject: Re: [spring] Updating the SPRING WG Charter
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 08 Jun 2018 20:43:45 -0000

Folks,

The only reason why SR-MPLS architecture is using indexes as opposed to
domain wide labels is a claim from few folks that possibly in some networks
deployed platforms would not be able to use the same global label block for
SR.

So SR-MPLS architecture agreed to use index to offset possible per platform
label block.

That said number of real deployment do use global (domain wide) identical
block on all nodes and that is the actual recommendation from section 3.1.2
of SR architecture

"Where possible, it is recommended that identical SRGBs be configured on
all nodes in an SR Domain."

But none of this really matters for the discussion at hand. Embedding
instruction for specific function can be easily done within programmed
domain wide index offset.

Best,
R.


On Fri, Jun 8, 2018 at 10:21 PM, Alexander Vainshtein <
Alexander.Vainshtein@ecitele.com> wrote:

> Robert, Paul and all,
> I concur with Paul.
> Domain-wide labels have been successfully purged from SR-MPLS for quite
> some time now, and, from my POV this purge is irreversible now.
>
> My 2c.
>
> Thumb typed by Sasha Vainshtein
>