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

Susan Hares <shares@ndzh.com> Mon, 09 November 2020 09:37 UTC

Return-Path: <shares@ndzh.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 14CCC3A0DB4 for <idr@ietfa.amsl.com>; Mon, 9 Nov 2020 01:37:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.225
X-Spam-Level: *
X-Spam-Status: No, score=1.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 F_8rA0pV9BYU for <idr@ietfa.amsl.com>; Mon, 9 Nov 2020 01:37:45 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 D23E53A0DAB for <idr@ietf.org>; Mon, 9 Nov 2020 01:37:44 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.107.115.222;
From: "Susan Hares" <shares@ndzh.com>
To: "'Pengshuping \(Peng Shuping\)'" <pengshuping@huawei.com>, "'Stephane Litkowski \(slitkows\)'" <slitkows=40cisco.com@dmarc.ietf.org>, <idr@ietf.org>
References: <050501d6b0d5$877d5970$96780c50$@ndzh.com> <SJ0PR11MB5136C14AD3AED30EF5EC128BC2EF0@SJ0PR11MB5136.namprd11.prod.outlook.com> <4278D47A901B3041A737953BAA078ADE1954049D@DGGEML532-MBX.china.huawei.com>
In-Reply-To: <4278D47A901B3041A737953BAA078ADE1954049D@DGGEML532-MBX.china.huawei.com>
Date: Mon, 9 Nov 2020 04:37:29 -0500
Message-ID: <036701d6b67b$f18b7710$d4a26530$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0368_01D6B652.08BAC640"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQEvXptEERMy9oWMkRU4TGI7ipbTUQG/AvLsAnpv5tqq7GdpUA==
X-Antivirus: AVG (VPS 201108-6, 11/08/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/3_jC_1MoFrB29KftUhcuZ1oFtxE>
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:37:47 -0000

Shuping: 

 

A few questions about the scope of the Link MTU that

 

<individual contributors hat on> 

 

I have few questions application of the Link MTU to non-IGP situations: 

1) Can the Link MTU be passed across a local link upon with a NLRI source
(protocol ID: direct or static)?  

 

2) Can the Link MTU be passed if the link is a tunnel whose encapsulation is
passed by the BGP's tunnel encapsulation attribute
(draft-ietf-idr-tunnel-encaps-19.txt)?  

 

3) If the answer to question 2 is yes, could you provide me with an example
topology where you envision this might happen.   

 

4) If the answer to question 2 is yes,  it possible that the link MTU is
passed for a tunnel of SR policy tunnel type (see
draft-ietf-segment-routing-te-policy-09.txt)?   If so, is the Link MTU a
composite value that works for all segments? 

 

Thank you, Sue 

 <individual contributors hat off>   

 

 

will pass an SR policy tunnel type for the BGP attribute
(draft-ietf-idr-segement-routing-te-policy-09) that refers to a tunnel which


 

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Pengshuping (Peng
Shuping)
Sent: Wednesday, November 4, 2020 9:23 AM
To: Stephane Litkowski (slitkows); Susan Hares; idr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020
to 11/16/2020)

 

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> On Behalf Of Susan Hares
Sent: lundi 2 novembre 2020 06:04
To: 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?