[Lsr] Fwd: Devil's Advocate - Segment Routing, Why?

Robert Raszuk <robert@raszuk.net> Thu, 18 June 2020 10:51 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0733A0A65 for <lsr@ietfa.amsl.com>; Thu, 18 Jun 2020 03:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: 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 ifd11c9_-67t for <lsr@ietfa.amsl.com>; Thu, 18 Jun 2020 03:51:18 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 EE9F93A0A62 for <lsr@ietf.org>; Thu, 18 Jun 2020 03:51:17 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id d15so4467692edm.10 for <lsr@ietf.org>; Thu, 18 Jun 2020 03:51:17 -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; bh=2nvPxrUovCmGFzRW55M5Ys73xBi9ao1Mevwue1QEB3A=; b=CfgJ95pMy8cK9nxo7ZJpGUKtd0UP7HvS6wiTXFa5REIGKLebr88ZIWBiBpZJkKBiOI aarpjS20qHjEpZzQuMf9/w4Z9ZP6DH4ppKwT2iNILMLdWoLBy2EomLlRYEShZRCF1Bw0 qhE+YD11h3jZ3BUbxe0l4Yz5XTciEFReI764OK0qEqCrEcTKsw1ON6ZOWVf57CE9YA1A HQ92m0jnTQGqGmAfb6KnrqcfYmyYjkyqtUouR493i5/C+29tHgKABl5oGLiPVGE4HoOZ jtMsnGJD7b/ADvGBnsLcLeuBwS43yvHdny79yqLC8zvsrhpeqGCopMJFWhmKPhFZOIS3 KzZg==
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; bh=2nvPxrUovCmGFzRW55M5Ys73xBi9ao1Mevwue1QEB3A=; b=kY/vSE+1jy8Srm0wgMEyUdqLaH1DyshpM8N2EQDrPQu6G6ZpppszDFT2vPaQVsHnYL 4Jm+XIesYqds17PYASA7vGu16KqcZNSkidFurkPv95n3uN8J5RGf4C/MEQeB5zTt5gwO JKPcdBsaZM3EamJp9zqE7jxOHdfnd/AMLvSDGOljjV053+xcP/z/8KkkUZWKOuP0IoCw XV78ItV+0sFfWCsoCnG8YDPv/yL0enIgUpQFaM3DkwrXUrERAcC2QaqJNgYf3UHYbHr9 C26bVRldEmp5hJIqBaErsM2wj7TZg6OPCuXGYimKOF8c/cuXSOaRCAi9Y0z9PYSAQa80 5SHQ==
X-Gm-Message-State: AOAM53026N/qZeMFSdtJnrU7cMjys8vYcXwkmQYz+ZVYXgRlmGSkRrUX Z0Ah/2J6yCpQ8s/ZFikjlMMUYNP8+Y4yjayiyx4aeUmIOw4=
X-Google-Smtp-Source: ABdhPJy4KwO1nHfv0btRN7AZ+RJyAy9nCjnaSxnIdlyT6qQ1yKA68p37BsERUd/1/OIxJos6ZuRbiqBglkZAAGS7/7U=
X-Received: by 2002:a50:98c1:: with SMTP id j59mr3608353edb.120.1592477476102; Thu, 18 Jun 2020 03:51:16 -0700 (PDT)
MIME-Version: 1.0
References: <86776c06-8795-0283-f36b-782018944363@seacom.mu> <CAAeewD8Y3wP4WgtSAnPcdJdOKqSeZkzD0BceDMJPqtNUEiTebQ@mail.gmail.com> <5b466572-cfdd-e728-3a50-9c840188ec07@seacom.mu> <CAAeewD-fXMtXLTQx_h4G97sQiEZ5ai3AsLkdSzBQzzf6OBSH0w@mail.gmail.com> <CAOj+MMHY_1yaeEtzjj4Bukraqsv5eLz78kp6Ju9joMYtNyKrwQ@mail.gmail.com> <CAAeewD-7-+XTyd6PqiufdrFePiUrmJYv+pFSLv317wePocvVAg@mail.gmail.com>
In-Reply-To: <CAAeewD-7-+XTyd6PqiufdrFePiUrmJYv+pFSLv317wePocvVAg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 18 Jun 2020 12:51:06 +0200
Message-ID: <CAOj+MMH=Er+09dZ3yGEtxZ-XA9cNMMwq7ww73VeF5SSBtAqNhA@mail.gmail.com>
To: lsr@ietf.org
Content-Type: multipart/alternative; boundary="00000000000046b5fa05a8598e23"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/MGjBOPW1cOEy6_STac8WjG04x8g>
Subject: [Lsr] Fwd: Devil's Advocate - Segment Routing, Why?
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 10:51:20 -0000

Just FYI ...

An interesting discussion on nanog/cisco-nsp lists ... started innocent
with SRv6 bashing, now went into IGP - specifically ISIS territory  :)

---------- Forwarded message ---------
From: Saku Ytti <saku@ytti.fi>
Date: Thu, Jun 18, 2020 at 12:43 PM
Subject: Re: Devil's Advocate - Segment Routing, Why?
To: Robert Raszuk <robert@raszuk.net>
Cc: Mark Tinka <mark.tinka@seacom.mu>, nanog@nanog.org <nanog@nanog.org>,
cisco-nsp NSP <cisco-nsp@puck.nether.net>


On Thu, 18 Jun 2020 at 13:28, Robert Raszuk <robert@raszuk.net> wrote:

> To your IGP point let me observe that OSPF runs over IP and ISIS does
not. That is first fundamental difference. There are customers using both
all over the world and therefore any suggestion to just use OSPFv3 is IMHO
quite unrealistic. Keep in mind that OSPF hierarchy is 2 (or 3 with super
area) while in IETF there is ongoing work to extend ISIS to 8 levels. There
is a lot of fundamental differences between those two (or three) IGPs and I
am sure many folks on the lists know them. Last there is a lot of
enterprise networks happily using IPv4 RFC1918 all over their global WAN
and DCs infrastructure and have no reason to deploy IPv6 there any time
soon.  If you are serious about converging to a single IGP I would rather
consider look towards OpenR type of IGP architecture with message bus
underneath.


On Thu, 18 Jun 2020 at 13:43, Saku Ytti <saku@ytti.fi> wrote:

I view the 802.3 and CLNS as liability, not an asset. People who
actually route CLNS are a dying breed,  think just DCN of a legacy
optical.

Many platforms have no facilities to protect ISIS, any connected
attacker can kill the box. Nokia handles generated packets
classification by assigning DSCP value to  application then DSCP to
forwarding-class, which precludes from configuring ISIS qos. Very few
people understand how ISIS works before ISIS PDU is handed to them,
world from 802.3 to that is largely huge pile of hacks, instead of
complete CLNS stack implementation. There is no standard way to send
large frames over 802.3, so there is non-standard way to encap ISIS
for those links. Also due to lack of LSP roll-over, ISIS is subject to
a horrible attack vector which is very difficult to troubleshoot and
solve.

-- 
  ++ytti