Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Robert Raszuk <rraszuk@gmail.com> Thu, 05 September 2019 19:20 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 BCC81120AF7; Thu, 5 Sep 2019 12:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 dvEKtN1wSZNE; Thu, 5 Sep 2019 12:20:32 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 B309A120271; Thu, 5 Sep 2019 12:20:32 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id m3so1945114pgv.13; Thu, 05 Sep 2019 12:20:32 -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=4E5OP3zw8sU7zdJqQDpNIJ3OcL+8G6H6Qn08KOzh9e4=; b=ODvvf64Yteq2llFfAP/oyav0tma5BtqBf7tNP0r0uXeykz3Y1pY1JV3SL5SlXGoRsN 3lU2WV05BbTU7yavbil6VhtL2j6vH22CGbFlU9IG9HKHulX8M0Nt4AhbW5kv7GEEOcwJ qi1ZUDnOcnQtBdqcl3J26UCheWW7Qsc2497DcnKw3fHicxBWdjavk94hvWG+83X9XpSe 71PZ+cbEo5ALK6BdiI/cNt8CwkcivV1aKf006RSqMVyECCDm49sU4Ce3jLNjV4Qmt/ji UlMt1Uct6hRQMdveMRBUp44u2aZzijj1FiP8Mm+M+22cJHMsoSPxediGc1/aRb35xKof C0ow==
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=4E5OP3zw8sU7zdJqQDpNIJ3OcL+8G6H6Qn08KOzh9e4=; b=bJWwdvX0CtChSrT8eRwHrHgH0PAcCNBPjBxORfQ5rwqI/fodkGEPdkPUuTXZBeN0k8 A73pdpx9JRfEeLE4TnR1TkJYuImI83YRbOSMQFwbyLJtbVVVtAI5Pi4orb6PRR2qB5DD b8803IekTP/TpP0OggkHBwoWP5ueMbI5cK8H5hsZwUWd7kb59yGdDI0Jp6O9fQQTSNsK jJ/QstvJslBdC4H2nQ3yKZ2e9NxGduL4OHT4vWdbhM5PXCyNLoAE8Go0AHVFHADWiFJD egVR9Vo+F3134a8g2T7LF0K81AErWkSExtA0FslvPlgrBM0kcI62j2V4cVZ7KeVTH0ld iTAw==
X-Gm-Message-State: APjAAAW5nWfBl06WPNVA5zbT84X8ANMPUKaIrV+u8AeM2cIJLQ63/8Un 1RJp5vTORU7tIo5/lmySQCyzOFzBWTH+jQj3PO4rio7d
X-Google-Smtp-Source: APXvYqwX4WdBGewY+SK3nCy6e3Z4d3lAJG6MPF9OyJXhsp2uQCkA5ymsisyhAdx5tBIefIXIShmiJVl0QLVTfUmRdp0=
X-Received: by 2002:a17:90a:9bc5:: with SMTP id b5mr5666657pjw.107.1567711231504; Thu, 05 Sep 2019 12:20:31 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR05MB54637FEAE1518F83977D274FAEB80@BYAPR05MB5463.namprd05.prod.outlook.com> <538732E2-915B-4952-A439-F4678FCC21B2@employees.org> <4c6b2456-db05-0771-5b98-bfd9f07b220b@si6networks.com> <34AB9F0F-614B-45C2-BD84-7DD53A1D5188@employees.org> <ea9557e5-9025-db78-8862-18454dd549c3@joelhalpern.com> <5200FFA0-E2F1-4491-8D06-0DC6BF87F77A@employees.org> <cdc190f4-315f-f716-951c-6d4ba1f4888d@si6networks.com> <CA+b+ERn6KMGCboERKOMeKAwM3y=1p=sc8j2LnEGYa7h5mz_xxw@mail.gmail.com> <BYAPR05MB5463F429E6AA307D0F313B9AAEBB0@BYAPR05MB5463.namprd05.prod.outlook.com> <CAOj+MMGH25AoQ6hvoKa4jVonPcauD6xY2pgwnZFtwvF559V+vQ@mail.gmail.com> <CALx6S35WeoZs=cOmP0CA0K2Wj_Oc1H_YZr+Ky1W=UL=nF1x4rg@mail.gmail.com>
In-Reply-To: <CALx6S35WeoZs=cOmP0CA0K2Wj_Oc1H_YZr+Ky1W=UL=nF1x4rg@mail.gmail.com>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Thu, 05 Sep 2019 21:20:20 +0200
Message-ID: <CA+b+ERmbEZ7WU8puMcuM6nBhP7rZs2ZiX104Ok5BKqpGaZLjQA@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, Fernando Gont <fgont@si6networks.com>, "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000001077aa0591d337ce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/9qNzStPqJxBWzasiJ_KxaZaFyLM>
Subject: Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)
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: Thu, 05 Sep 2019 19:20:35 -0000

Hi Tom,


> insertion. For instance, I'd invite you do the thought experiment
> about what happens when an intermediate node inserts a header that
> causes the packet to exceed the MTU of some downstream forwarding
> node.


Absolutely.

But SRH is meaningful only within a given domain.

At least I would worry much less about MTU being exceeded when you insert
EH as compared when you encapsulate with complete new header including EH,
DO etc ... which somehow everyone seems to be happy about. I am not seeing
much logic here.

Moreover if you look at telco transport today a lot of "circuits" are
emulated circuits which use encap in the middle of the transports which in
turn runs over their IP networks. How do you deal with such cases when one
day it works and when telco underly reroutes such that it goes via
bottleneck it does not ?

I am seeing this daily. We even wrote IETF drafts to detect this. Now the
BFD draft stuffing is a third attempt to have a tool to detect it. If IPv6
works end to end, hosts to hosts such MTU bottleneck should be part of the
IPv6 transport.

There is no robust protocol mechanism to deal with this.


That's a problem much bigger then SR. See when I am building transport over
third parties I use SLA probes which periodically validates not only SLA
data but also end to end max MTU. When I see an issue I choose
automatically different underlay path such that end applications do not
notice the issue.

Many thx,
R.


>