Re: [spring] RFC8200 update?

Robert Raszuk <> Sat, 29 February 2020 10:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB1E73A0E6E for <>; Sat, 29 Feb 2020 02:45:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id viArJ5HF_NgL for <>; Sat, 29 Feb 2020 02:45:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 643813A0E6C for <>; Sat, 29 Feb 2020 02:45:22 -0800 (PST)
Received: by with SMTP id w6so5109688otk.0 for <>; Sat, 29 Feb 2020 02:45:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m9tz/QybCUT6ZtAYJKuU6BshrH7CKCiGlr9DUjhDlJ8=; b=RS6m1VXI9kZjkU0EaRI/tKpNMNihjbhU5CJeG36KPnpii8FiWus6nZZtRhZK03ya4f jvlHEV3pRKHVa2mju1I0cg+eKPXru+Hjy3tnijoRMAPlEmJ8dqzHB35d8soKi1H6pw9x 8Rea69EAi2oU8JK5Rcj2Yo7A+WgJ88309B/U3R/972rnpOWLv8EqtGTHimw02Fl8Mcrm 032nhut8GR+DgpJ3JV2viJiLlos2WawHduUnFud54Q0ZqsW51trb6Y9aojCPCo6opGXN zciKJQx9twHQa/0W7u95HxZuQ9V0uMkALXQTngBNzqXSxxHr3vPCyCaqRj+A+7GYryVf WRMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m9tz/QybCUT6ZtAYJKuU6BshrH7CKCiGlr9DUjhDlJ8=; b=CfpLEwKfchFJh9TpDesjMlvWmjhmnoVzAHg1houwH7NLSeJrj9RskTjb8o5q2JBAvu YxbCxgEMTJUfhJMpmO4Nc028Td2tQw2FCFIVvGL6/sq1+4Td9RS9VExvJh/hsOJNg+8B aO3aTMlGz4PKcLdZLaL4zvr7Mm7wanXU0sW+P3Kvl+4y56VTKA2701T/KDA+KSM9Eojp ozjfi92C3z770HLk5YZKI5w7C93KcMX6rCvsOZ6oz5on4o5mnQIQP0Nf8mN9aE29UOU1 HQc0MbPdt5A7fLXCPUcr+Bo64NC1yeVAv5ObmAGQqANdbeZUiFNCBbMnjk9+qHIVbPxz up3g==
X-Gm-Message-State: APjAAAVhmq5oQOBuZFbzJzkmFc3KotkK/WU6wmRKpnEHRRuC73WEjNJQ /J9OBIWm40rt5gSdT0p3q8GIK/h0Mm741hxASDp+9A==
X-Google-Smtp-Source: APXvYqyaiSXP49lLodJcp8UvFwtVwdT53Z3HSrP7mHzAKx5eI6N3iVhHKMXTpxPHlDF+byHNPeO6j8Ms2b0tejpZeIs=
X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr6367318otr.82.1582973120793; Sat, 29 Feb 2020 02:45:20 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Sat, 29 Feb 2020 11:45:11 +0100
Message-ID: <>
To: Mark Smith <>
Cc: Warren Kumari <>, James Guichard <>, SPRING WG List <>, 6man WG <>
Content-Type: multipart/alternative; boundary="0000000000008ddff1059fb4a657"
Archived-At: <>
Subject: Re: [spring] RFC8200 update?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Feb 2020 10:45:30 -0000

Hi Mark,

I actually fully agree with your below note.

However my reasoning to agree perhaps is slightly different then yours :).

I agree on the basis that as defined today in spite huge efforts and good
will by all involved in IPv6 definition it is just not flexible enough to
accommodate current and future needs.

Your reasoning seems to be the opposite - IPv6 is great as is or "it is
what it is: enjoy as served" - and just applications looking for transport
need to be trimmed down to fit it.

Clearly we have different opinions here - but in my books networks are to
serve user needs and carry modern applications as opposed to act as an
emperor telling everyone around how and what can be carried.

And to be very clear - I am not saying you are wrong. Perhaps you look at
train analogy - sure if each passenger would start messing with train
car/wagons construction the train would clearly not go far. But if so we
just need a new train architecture rather then saying - oh no Mr. SR you
can not travel at all.

Many thx,

On Sat, Feb 29, 2020 at 2:13 AM Mark Smith <> wrote:

> On Sat, 29 Feb 2020, 06:55 Warren Kumari, <> wrote:
>> On Fri, Feb 28, 2020 at 9:02 AM Robert Raszuk <> wrote:
>> >
>> > > interestingly enough MPLS took the same approach
>> >
>> > Well not really. As you know, MPLS unicast and multicast have a new
>> ethertype.
>> And this is a critical distinction -- Brian Carpenter's limited domain
>> document (draft-carpenter-limited-domains) says:
>> "Domain boundaries that are defined administratively (e.g. by address
>> filtering rules in routers) are prone to leakage caused by human
>> error, especially if the limited domain traffic appears otherwise
>> normal to the boundary routers. In this case, the network operator
>> needs to take active steps to protect the boundary. This form of
>> leakage is much less likely if nodes must be explicitly configured to
>> handle a given limited domain protocol, for example by installing a
>> specific protocol handler."
> Using IPv6 for SR is fundamentally using the wrong tool for the job.
> IPv6 is an internetworking protocol used to network networks and to
> internetwork all hosts attached to all of those networks.
> The SR problem space is typically limited to local network or sub-network,
> and usually only between network elements, rather than out to end hosts.
> It does make sense to try to use a internetworking protocol to solve a
> local sub-network problem when the internetworking protocol has become
> commodity. The benefits of the cheapness of the commodity protocol should
> outweigh the costs of the drawbacks and compromises that need to be made to
> use it.
> However, the moment customising the commodity to better suit the problem
> starts is the moment the benefits of using the existing commodity start
> being lost. Customise too much and all of the benefits of choosing a
> commodity in the first place disappear.
> That's why I fundamentally think changing IPv6 to suit SR should be
> avoided as much as possible.
> Compromising SR to suit and fit within existing IPv6 would retain the
> benefits of using existing commodity IPv6. Customising IPv6 to suit SR
> risks throwing the commodity benefits "baby out with the bathwater", with
> the more radical the customising, the greater risk.
> Regards,
> Mark.