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

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Wed, 04 November 2020 14:22 UTC

Return-Path: <pengshuping@huawei.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 E53EC3A1294 for <idr@ietfa.amsl.com>; Wed, 4 Nov 2020 06:22:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 w6PWstg8dqEy for <idr@ietfa.amsl.com>; Wed, 4 Nov 2020 06:22:42 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CFD3A128E for <idr@ietf.org>; Wed, 4 Nov 2020 06:22:42 -0800 (PST)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CR82x6Shfz67HvP for <idr@ietf.org>; Wed, 4 Nov 2020 22:21:13 +0800 (CST)
Received: from fraeml736-chm.china.huawei.com (10.206.15.217) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 4 Nov 2020 15:22:34 +0100
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 4 Nov 2020 15:22:33 +0100
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.142]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Wed, 4 Nov 2020 22:22:31 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: "Stephane Litkowski (slitkows)" <slitkows=40cisco.com@dmarc.ietf.org>, 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: AdawzOgQ6Lr8VUABQe2O6Y7iaRDQVwBcPlsAABOufDA=
Date: Wed, 4 Nov 2020 14:22:31 +0000
Message-ID: <4278D47A901B3041A737953BAA078ADE1954049D@DGGEML532-MBX.china.huawei.com>
References: <050501d6b0d5$877d5970$96780c50$@ndzh.com> <SJ0PR11MB5136C14AD3AED30EF5EC128BC2EF0@SJ0PR11MB5136.namprd11.prod.outlook.com>
In-Reply-To: <SJ0PR11MB5136C14AD3AED30EF5EC128BC2EF0@SJ0PR11MB5136.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.46.74.242]
Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE1954049DDGGEML532MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QttoFjSAjAiNFlIDdnO4k8whwrI>
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: Wed, 04 Nov 2020 14:22:44 -0000

Hi Stephane,

It has been included in this draft that "[RFC7176] specifies the ISIS mechanism and extensions for link MTU Sub-TLV" which can feed BGP-LS. This was actually suggested by the LSR WG.

Regarding OSPF, people can post corresponding draft to LSR if there is a need. There could be other ways too as you mentioned.

Best regards,
Shuping

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Stephane Litkowski (slitkows)
Sent: Wednesday, November 4, 2020 4:03 PM
To: Susan Hares <shares@ndzh.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)

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?