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 21:20 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 4C8333A1406 for <idr@ietfa.amsl.com>; Mon, 9 Nov 2020 13:20:04 -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 PHIvQNDL9a6l for <idr@ietfa.amsl.com>; Mon, 9 Nov 2020 13:20:02 -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 548323A1407 for <idr@ietf.org>; Mon, 9 Nov 2020 13:20:02 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.107.115.222;
From: "Susan Hares" <shares@ndzh.com>
To: "'Stephane Litkowski \(slitkows\)'" <slitkows=40cisco.com@dmarc.ietf.org>, <idr@ietf.org>
References: <050501d6b0d5$877d5970$96780c50$@ndzh.com> <SJ0PR11MB5136C14AD3AED30EF5EC128BC2EF0@SJ0PR11MB5136.namprd11.prod.outlook.com> <033001d6b678$08d20280$1a760780$@ndzh.com> <CO1PR11MB512125F36BEF9AC8FEAE0598C2EA0@CO1PR11MB5121.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB512125F36BEF9AC8FEAE0598C2EA0@CO1PR11MB5121.namprd11.prod.outlook.com>
Date: Mon, 9 Nov 2020 16:19:41 -0500
Message-ID: <006801d6b6de$0f89c390$2e9d4ab0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01D6B6B4.26B6C8D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEvXptEERMy9oWMkRU4TGI7ipbTUQG/AvLsAaOz/IACYXuwG6rg11KA
Content-Language: en-us
X-Antivirus: AVG (VPS 201109-4, 11/09/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fMLzeky9Z1yjwAalsqn3Fklh2G4>
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 21:20:04 -0000

Stephane: 

 

My second message to this thread asked a few questions about the technology.


 

This information can be more than IGP information.   If SR segments
statically defined (static or direct interfaces) tunnels and pass the
endpoints via BGP tunnel-encaps draft with SR Policy tunnel type, this can
just be BGP. 

 

I'll keep this WG adoption call going until we can be sure if:  1) it
something LSR wants to standardize, and 2) whether there is a BGP only case.
It is clear to me that standardizing MTU for a SR segments with stacked
tunnel segments passed by BGP was useful.

 

The authors should be the ones to propose this in LSR.       

 

Cheers,  Sue 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Stephane Litkowski
(slitkows)
Sent: Monday, November 9, 2020 4:28 AM
To: 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 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
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?