Re: [Lsr] [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: 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 F21E43A1455 for <lsr@ietfa.amsl.com>; Sat, 14 Nov 2020 02:13:51 -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=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 UDJDtl4yNOSU for <lsr@ietfa.amsl.com>; Sat, 14 Nov 2020 02:13:50 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 3FD5A3A13A4 for <lsr@ietf.org>; Sat, 14 Nov 2020 02:13:50 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id y16so14000140ljh.0 for <lsr@ietf.org>; Sat, 14 Nov 2020 02:13:50 -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=Xv25N3R2lEyHkKKRn+jA774xUibR7pq2A/zk8VCNKckhgPg3OO0nXF5qVfrofIW8OV l0KGH+aFwnM+O9vAsQscYDdtkPbF3A3YJbxW48j45nDRTC4kdslPBoTT74LWjsn/0W76 8Mv2g4cPwqVqNVZWSr0XKoxfY1OJpKTgivB5pMXTDZtQiQFlaGdpr5TtWBRNrdNkAREv mSiGHhCWDFX0FUOF+axjJYyMwFDgOOwz6EF6rH5AfwOBVSf3sDwsug0yX4lHd5hclxtg XBNzXpxGmb4Mga18PEj6jrxBMgAWNTLUv5En7ovY8EHQXoacVoabaSl4WzBU0NUmyNbH 6rqA==
X-Gm-Message-State: AOAM533ZrmOByRUwiRJ7erB92jJcJEkT5kC+Pm/jMobFdIdXdo32f33Y naGzE6Gnywg1v2TwdruEMe8pBbAWCmW376dcXYy6sQ==
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/lsr/M_Z1BIo9qmDbxpR-fgQ3oFXTFr0>
Subject: Re: [Lsr] =?utf-8?b?W0lkcl0g562U5aSNOiBXRyBBZG9wdGlvbiBmb3IgZHJhZnQt?= =?utf-8?q?zhu-idr-bgp-ls-path-mtu_=2811/1/2020_to_11/16/2020=29?=
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: 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.