Re: [Idr] 答复: WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Robert Raszuk <robert@raszuk.net> Sat, 14 November 2020 10:13 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2718A3A13A4 for <idr@ietfa.amsl.com>; Sat, 14 Nov 2020 02:13:52 -0800 (PST)
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=unavailable 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 wQcPTaK0uJHI for <idr@ietfa.amsl.com>; Sat, 14 Nov 2020 02:13:50 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 1C1303A0E92 for <idr@ietf.org>; Sat, 14 Nov 2020 02:13:50 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id h23so13944379ljg.13 for <idr@ietf.org>; Sat, 14 Nov 2020 02:13:49 -0800 (PST)
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 :cc; bh=gCyfWIZ/M0TFykaR7pwsQujDBwaGQ3XgoxGccXJBb08=; b=Lf8qwP8rnaj4iI20AoQPqH/9q5NfAWn6P4el8zWTJmUtPFMrWxq6AvakkvN2LX18Re IAld4QHo39NaGAevbkYH0buCUCdGFuYp3ZvrPWzszeW7ruN5demNjegCxBJghr27KN7T T/vxZyF/VTTs03wfSy2DnFejROVFvJ5CHEzS61MdIrxG3kiBWpROOgb5ce4Bjch9LTwd wixa8hhHv7APW77sXnoFyRd7nu1ty6QMENNN0aLONeIkF2eQNbmDXSi/krS5gSsbjoq2 eA1SD4tXQpfiedxRQroHRhbCrkuASAskQrwQp6587GkNuigv5apzEsYZwTTvrS+5lvb7 uKQg==
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=gCyfWIZ/M0TFykaR7pwsQujDBwaGQ3XgoxGccXJBb08=; b=Ujodbi/sE7bffMtExaficTRYk0B/HUmXKhb7Qwgsl5esp5Bj0tn6Dqxj8LwYUgXuSS yvabupttkc4AoxqUwyXQm/HVBfKJXVCgboPmnYk8FdDNt0U6RyGUQajWBdKc5KuEDAJp fv5IwMCRzNEb/Pkqm4Nu3uM6c0v+2Zf3+48wSQ4nVxlxZOU3MscSeo5FDxh2pDH1PymI 4Se9H84BGmPne7mV9L+7EL/gkOl+DcZoSdioQ3NcB+v5r9mz23nRiBeSjp20U/lt9j/6 /F/68bf7Sg50VQixYXrSPwAZAEGY/OtuURTroBFti6ni4RTg3escfDKp1eqWN82Zwteu 8bmg==
X-Gm-Message-State: AOAM533RTehs8CjxkGdYo0btkdYhHz4rSHopcUqoLUepQGXLEyUz1BDL mqwnfh05qErougwxiqSrdK+LYGH/v4lCdOWe2wyq/g==
X-Google-Smtp-Source: ABdhPJz32QjE4Vf5aj+VXaNIUKvG0H2nOEolCuEpUXjNe+zgBz5cbNehWEfSjsSHXyva8hW2l6tdjFBPQbjNvQYeRU8=
X-Received: by 2002:a2e:98c1:: with SMTP id s1mr3020822ljj.30.1605348828222; Sat, 14 Nov 2020 02:13:48 -0800 (PST)
MIME-Version: 1.0
References: <050501d6b0d5$877d5970$96780c50$@ndzh.com> <SJ0PR11MB5136C14AD3AED30EF5EC128BC2EF0@SJ0PR11MB5136.namprd11.prod.outlook.com> <033001d6b678$08d20280$1a760780$@ndzh.com> <CO1PR11MB512125F36BEF9AC8FEAE0598C2EA0@CO1PR11MB5121.namprd11.prod.outlook.com> <006801d6b6de$0f89c390$2e9d4ab0$@ndzh.com> <1F8F1206-0583-4262-8837-934C10F2B034@cisco.com> <9346741d-6eda-4fbc-917f-2ac3662aac0b@Spark> <02c501d6b924$b4a34b10$1de9e130$@ndzh.com> <MW3PR11MB4570FC2597099BC436966F9CC1E60@MW3PR11MB4570.namprd11.prod.outlook.com> <BY5PR11MB4337713244E4871807BA70D4C1E60@BY5PR11MB4337.namprd11.prod.outlook.com> <095760a7fdde4c01b4757cf66656a723@huawei.com>
In-Reply-To: <095760a7fdde4c01b4757cf66656a723@huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 14 Nov 2020 11:13:38 +0100
Message-ID: <CAOj+MMHr-F5zxBpDrN9aPbtkuSWjJ2j9XW0nhMv2=3gGu8ddaQ@mail.gmail.com>
To: Huzhibo <huzhibo@huawei.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, Susan Hares <shares@ndzh.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, "Stephane Litkowski (slitkows)" <slitkows=40cisco.com@dmarc.ietf.org>, "idr@ietf.org" <idr@ietf.org>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a5a79105b40e661b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/T6G-F3NNt05_irqj0PVcqHOIPiU>
Subject: Re: [Idr] 答复: WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Nov 2020 10:13:52 -0000

Hi Huzhibo,

I would like to highlight another aspect of this draft independent in which
(if any) WG it will end up with.

Many network operators today to interconnect their routers purchase
circuits. However those circuits in vast majority use brilliant technology
of VPWS, L2VPN, EVPN ... you name it. So effectively the circuit is just an
illusion and what is really sold is an emulated circuit running as IP
encapsulated L2 packets on someone IP backbone.

And here comes the crux of the issue - depending on the time of the day,
state and events in the carrier's underlay real MTU changes. And today what
is worse routers have no good way to even detect it. Some attempts pop up
here and there (like stuff BFD to 1500 or so), but the point is that what
could be promised, sold and configured on the interface may not be what is
really under the hood.

Things get even more colorful when only some discrete packet sizes fail
while smaller and bigger go through just fine - Swiss-MTU if you will :)

Sure your proposal just uses static MTU like any other mentioned in your
draft consumer of that information but I am bringing it here for two
reasons:

A) Draft needs to consider this problem and discuss dynamics related to
real MTU changes

B) A discussion needs to be started if it would not be much more effective
to simply detect MTU at the data plane between the src and dst in an end to
end fashion rather then using it in control plane as a atomic piece of
assumed truth used to make any path calculation.

Kind regards,
R.