[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
- [Lsr] Fwd: Devil's Advocate - Segment Routing, Wh… Robert Raszuk