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

"Stephane Litkowski (slitkows)" <slitkows@cisco.com> Mon, 09 November 2020 09:28 UTC

Return-Path: <slitkows@cisco.com>
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 8123A3A0D9B for <idr@ietfa.amsl.com>; Mon, 9 Nov 2020 01:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IAAw3mRl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=y1XtEWy5
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 zxaQou8ieRnG for <idr@ietfa.amsl.com>; Mon, 9 Nov 2020 01:28:14 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10443A0D94 for <idr@ietf.org>; Mon, 9 Nov 2020 01:28:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21523; q=dns/txt; s=iport; t=1604914092; x=1606123692; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Z/p7U+mKN2iTKNJAfAGzLU3NEOWM+EjtwRsPGs/HJUg=; b=IAAw3mRlI4rOF2aBRcF/ZlPlndtlGvSJm9qW+rXjW4R+mxNmJRaa+bPj W1uRpqwV2eSGZJwWEc1IvGdv9cFP4aw4G/oaJ29Zdo9fOpLLJMmJjpSte S5LMfOL8yugC9dqQLknSg3XPekrMKHV7uZRs6CrfK8y0v/Ka5IcXNe5Yw w=;
X-IPAS-Result: =?us-ascii?q?A0DmGwDBCqlffZRdJa1iHAEBATwBAQQEAQECAQEHAQEVg?= =?us-ascii?q?U8CgSEvIy57WS8uCod8A41UgQWXfIFCgREDVAsBAQENAQEjCgIEAQGESgKCE?= =?us-ascii?q?gIlNwYOAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQECARILEBMBA?= =?us-ascii?q?SkPBAsCAQgOAwQBASEHBzIUCQgCBAESCBqDBYF+VwMOIAEOohcCgTuIaHSBN?= =?us-ascii?q?IMEAQEFgUdBgwgYghADBoE4AYJyikwbgUE/gRABQ4IaNT6BBIFZAgMBgSYBE?= =?us-ascii?q?gEjDBgHCQKDEoIsmwGMDZEcCoJtiQ2SIoIGgRKKEpRGh1qLdIp5jzuGEgIEA?= =?us-ascii?q?gQFAg4BAQWBaiIsPXBwFYMkUBcCDY5WgzqFFIVEdDgCBgoBAQMJfIsILYEGA?= =?us-ascii?q?YEQAQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3AxZo5Lh25VNjCdKlAsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGv6drgE3JG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK9PVpVXs35Yg6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,463,1596499200"; d="scan'208,217";a="621098919"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2020 09:28:11 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A99SCY6004977 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2020 09:28:12 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 03:28:12 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 03:28:11 -0600
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 9 Nov 2020 04:28:11 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YJi2xqByQ3WotVq63RyKb0xTzkfW/QZkCfk4JOw0GsvLcaU1O0VeHSyLyw/96VIjL+WP/SSUMv0rJfiWWasEOb+yEh7OByEjV/tEaEWGkOrvOpO/OFVprS2uE7cIaLgU97nDHXqNangD+7JqSkpAgBDLc6wPZuZGcwt8mZuQ9hA6cf2MKjsjHk2mrROmz8RUQZdscMKWjnnCkyrrOgXgEhVybGRiEG/KZF8oeen4usD72pln0klWxDzpsqdZxdA7ReWRLB103Dzp575s+hI6P1NsepI5UCPPIQpnMMmK41dUNVAbJKsd6xIEFhN8z5O3KI9EW2usgBNjOXNaKvM4CA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nONUBU6W3YlYMgnC68gbQ464YoVLfYviveSqJLzlS6A=; b=njV9YLO7rdEr3A8QUL9k1/AoalDg3wDGaZSRFF4G/jQVds2QKBA5ixSOYoiWHYDwOGaakkouP2/ZPsnGKYc24y1gaFgLlncr9zRQygWzcSZVCQww+W2WRAp4VUnawhvQrOeHW7JoX2n5jPXoTkZLD+hHX/tHzxHMMYnGtKgQk1yWg33XQFWl3f8GyibNQ1Yz+hg/S22k1B0/pVfq7zMAgnVCiZsRoxXToRXiSFlPMlJgeMYlHTitHt4gqNky+rAambjr/867SpNKPqp5zX5iuHcWHaQYHQR1DQ2i72Lx8hbZ0v2rgBEp53vniR68x8KltriyR+xxyPk3lzfQyZisVw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nONUBU6W3YlYMgnC68gbQ464YoVLfYviveSqJLzlS6A=; b=y1XtEWy5WZgM+J7BjyG8KbgApjRN05P0eQkYogXyQV0PIwTM86GYwlPAdmH0CycXnzKoRZ5gbHUi42y6JKTeC1jKfVqLWkRdvwXptDzN76W784U9wq0jIWz5lYjNStAuCMsB/esv+yWZI1W0H/DIeUfni3sEdbH0mpoZBlI8ZeY=
Received: from CO1PR11MB5121.namprd11.prod.outlook.com (2603:10b6:303:94::22) by MWHPR11MB1647.namprd11.prod.outlook.com (2603:10b6:301:d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Mon, 9 Nov 2020 09:28:10 +0000
Received: from CO1PR11MB5121.namprd11.prod.outlook.com ([fe80::c4ed:88c3:cf0d:f5a5]) by CO1PR11MB5121.namprd11.prod.outlook.com ([fe80::c4ed:88c3:cf0d:f5a5%3]) with mapi id 15.20.3541.021; Mon, 9 Nov 2020 09:28:10 +0000
From: "Stephane Litkowski (slitkows)" <slitkows@cisco.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)
Thread-Index: AQHWsoDt6Lr8VUABQe2O6Y7iaRDQV6m/iw4AgAAETLA=
Date: Mon, 9 Nov 2020 09:28:10 +0000
Message-ID: <CO1PR11MB512125F36BEF9AC8FEAE0598C2EA0@CO1PR11MB5121.namprd11.prod.outlook.com>
References: <050501d6b0d5$877d5970$96780c50$@ndzh.com> <SJ0PR11MB5136C14AD3AED30EF5EC128BC2EF0@SJ0PR11MB5136.namprd11.prod.outlook.com> <033001d6b678$08d20280$1a760780$@ndzh.com>
In-Reply-To: <033001d6b678$08d20280$1a760780$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.220.52]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ccf10420-3c76-4edf-ad1b-08d88491c63e
x-ms-traffictypediagnostic: MWHPR11MB1647:
x-microsoft-antispam-prvs: <MWHPR11MB1647BA4B0DE927226910156FC2EA0@MWHPR11MB1647.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: DmBo4MTIMDniOef8GsAnf69OZbeYPLEFt6IqB1Ig0frpV8UOc8TsqpnY2cutEuk74svlZ0m3r6W1Fbew+iTIu0rkmh+Tizd1J7DVBgB9Y1USbodpzjRnHu7K5YyZUBaP/jbZ2w2qHaj4k0cSaTiRnKqSXrO9W8COBW2XU3BSu9IWpT8xl0MVERzv4I02kML3faM9SGc3A2PZqoU9vBis0nONepE62Fp/bccU4oI85HBCf2L5mybtnIz2hYoe8fuwQVkozJ7ex7waFqOsXH5P8f2bx5tgARBQ8c0+gzzOlzj4/07sftRtTEYuaO58U+IKlqnUlhpg1TLDCiBN/r/5+v21zWkJ/Ia6Z22Hlwc0w1S2gYymiOrKo1lYhEje5xqWMfLjMwOW9zHkpE2qGfU9QQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB5121.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(366004)(376002)(39860400002)(346002)(7696005)(53546011)(316002)(64756008)(66446008)(8676002)(66476007)(66556008)(478600001)(110136005)(66946007)(33656002)(83380400001)(186003)(52536014)(76116006)(9686003)(86362001)(5660300002)(71200400001)(26005)(8936002)(2906002)(166002)(6506007)(55016002)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: oftw92nzGqdYrRm579OKG4C3JgXhmR7Ofb8TqUp1dora2WZLqaaVEUXmkYLu53yZV119liBBThu9yC449kqVtlZ+5uiNyokti6HLqr89hjAipv/IuPA+1Gvia9sxpTg/19unxhJymGZvjrxjBf49zVyWtTA3cLobXP/Kt93WMpNmxsz5AU+K69tYYvkKFiDho+58fX4MWOBpfkfXZLKXlyVLJ2jV32lA5FWviJOlw1dmGT+X0rqyhq7tLN82zWmmcYObyRgY1VNku2+Ck7vEPvSWAJVATxRRq79dYmZvlQ+TS0WoHCzRVcgzNVvo8VONWnQRGwV5exzpbcaKp04wepvwXn9hG93mMBnadvVz1/nmhlXUIbpiKjMI5rOBdyP3TxWfWYXrEBxVzXOdzfOvb81NpLyTAcg+z/YFkC9gDnUL19AbQe5cxDu/cIvfLkSY4hDr/dGM+ul0EKsmGLcwqDqKtYx/nT+ZunNwWdIo5RNUsvKYcDhfNjdsDfRnoesnPAw+7m+ulw2m8fzeJ6Qt2Nv2aVE88ZsnAnukjYidSFkAAHysxnHI/TF+qdAa8yzrsuZDh0dewXXdc3hRtnHUVNPJt2Ep2ZFU9vWSJCGYd/PWdkhu0UgwyaIXuAks9Ws9lrvfc3gZO5iV29pFJ7TCLg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CO1PR11MB512125F36BEF9AC8FEAE0598C2EA0CO1PR11MB5121namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5121.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ccf10420-3c76-4edf-ad1b-08d88491c63e
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 09:28:10.3478 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jFZ6b7sxlrbbLiwpNMbRbm0xNgNEDGeEfWC/TSHJvtX5UIk4M0k5sgNg6bQY6F20NYaOLsIaZizFWJ0Eltw8Vg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1647
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/P1ERQuHv0y13vvIXzjQsjB6Yl_E>
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: Mon, 09 Nov 2020 09:28:17 -0000

Hi Sue,

> The purpose behind this mechanism is to reduce administrative work rather than to reduce the review on drafts.

That's exactly my point. If we don't do OSPF extension now and in the same draft, we leave a gap that will require a new draft for a very very small extension. Just adds process overhead for nothing...


Stephane


From: Susan Hares <shares@ndzh.com>
Sent: lundi 9 novembre 2020 10:10
To: Stephane Litkowski (slitkows) <slitkows@cisco.com>om>; idr@ietf.org
Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Stephane:

I want to pick up on your email from two points:

1)  Why not do everything in LSR?
<WG-chair hat>
If the feature comes with interest in doing all 3 (ISIS, OSPF, and BGP-LS data gathering), then the authors may select to do everything in LSR rather than have 2 or 3 drafts to maintain.

This is optional and the mechanism may not fit every draft.   The drafts may also start out adopted and vetted in LSR and IDR.    The purpose behind this mechanism is to reduce administrative work rather than to reduce the review on drafts.

</wg-chair hat off>


2) TRILL implementations of IS-IS has some MTU subTLV -

If you are interested in whether this has been implemented in TRILL, you might want to check with Donald Eastlake.   My vague and foggy recollection is that had some implementations or came from pre-TRILL implementations.


Cheers, Susan Hares



From: Stephane Litkowski (slitkows) [mailto:slitkows@cisco.com]
Sent: Wednesday, November 4, 2020 3:03 AM
To: Susan Hares; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Hi,

"a) Are there ways to pass IGP link MTUs in
the IGPs?  If so, is this needed in BGP-LS"

This is a valid point, most of the time BGP-LS is feeded by IGP LSDBs (of course there are other ways too). While I see that IS-IS has some MTU subTLV coming from TRILL RFC7176 (possibly never been implemented), I don't see anything for OSPF (I'm not an OSPF expert, so I may have missed it).
Shouldn't this be checked and validated with LSR WG before adopting ?


Stephane


From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Susan Hares
Sent: lundi 2 novembre 2020 06:04
To: idr@ietf.org<mailto:idr@ietf.org>
Subject: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

This begins a 2 week WG adoption call for
draft-zhu-idr-bgp-ls-path-mtu-04.txt (11/1 - 11/16/2020).

The authors should send in an IPR statement for this draft
by 11/5 so the WG can include the IPR status in their decision.

You can access the draft at:
https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/

Since this draft is reference by an existing IDR draft
I've included a bit of background below to help you place
this draft into the larger context of the SR additions to BGP-LS
and the draft-ietf-idr-tunnel-encaps-19.txt.

This draft does continue BGP-LS additions.  if you
are opposed to any BGP-LS additions rather than
this specific addition, please make that clear in your
comment in this discussion.

The authors requested a WG adoption at IETF 108.
The IDR co-chairs thank the authors for their patience.
This draft has been delayed by process of having a
new document shepherd (Sue Hares) come up to speed
on draft-ietf-idr-tunnel-encapsulation.

Cheers, Sue

Background
===========
Segment Routing technology creates SR tunnels that are
directly overlaid on MPLS or SRv6.  While existing MPLS technology
(LDP and RSV-TE) provides mechanisms to negotiate path MTU
based on individual link MTU limits, the Segment Routing (SR)
on BGP-LS Link Attribute does not pass information on
MTU size per link.

draft-ietf-idr-sr-policy-path-mtu-02.txt sends PATH MTU
information in the tunnel-encapsulation attribute for the tunnel type
SR-Policy that handles segment routing (SR) paths.
However, it lacks the information to create a reasonable
Path size since the BGP-LS Link Attribute does distribute
this information.

The draft proposes adding a new sub-TLV for MTU size
to the BGP-LS Link Attribute TLV, and
draft-ietf-idr-sr-policy-path-mtu-02.txt mentions this
draft as one possible way to distribute the per link
MTU.

Questions for the authors might be:
a) Are there ways to pass IGP link MTUs in
the IGPs?  If so, is this needed in BGP-LS

b) What other mechanisms pass link MTU?