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

"" <> Thu, 05 November 2020 01:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D1823A11DF for <>; Wed, 4 Nov 2020 17:23:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S9196H0XCyuv for <>; Wed, 4 Nov 2020 17:23:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 15B603A11DE for <>; Wed, 4 Nov 2020 17:23:27 -0800 (PST)
Received: from clientip- (unknown []) by (HERMES) with SMTP id 09DB22800DC for <>; Thu, 5 Nov 2020 09:23:21 +0800 (CST)
Received: from ([]) by App0025 with ESMTP id 6c90838ba4db450ea70efe1d91efb1fa for; Thu Nov 5 09:23:22 2020
X-Transaction-ID: 6c90838ba4db450ea70efe1d91efb1fa
X-filter-score: filter<0>
X-MEDUSA-Status: 0
Date: Thu, 05 Nov 2020 09:23:20 +0800
From: "" <>
To: idr <>
References: <050501d6b0d5$877d5970$96780c50$>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart512851484770_=----"
Archived-At: <>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Nov 2020 01:23:30 -0000

Hi All,

I support the adoption of this work.

Best Regards,
Cong Li

From: Susan Hares
Date: 2020-11-02 13:03
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:
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 
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 
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?