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

Peng Liu <> Tue, 03 November 2020 06:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E1A43A14A6 for <>; Mon, 2 Nov 2020 22:04:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.329
X-Spam-Status: No, score=-1.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qT4QVAQ8Vkz0 for <>; Mon, 2 Nov 2020 22:04:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E5A5C3A14A2 for <>; Mon, 2 Nov 2020 22:03:04 -0800 (PST)
Received: from (unknown[]) by rmmx-syy-dmz-app08-12008 (RichMail) with SMTP id 2ee85fa0f28b254-825e4; Tue, 03 Nov 2020 14:02:52 +0800 (CST)
X-RM-TRANSID: 2ee85fa0f28b254-825e4
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from PENG (unknown[]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea5fa0f289639-f1739; Tue, 03 Nov 2020 14:02:52 +0800 (CST)
X-RM-TRANSID: 2eea5fa0f289639-f1739
MIME-Version: 1.0
x-PcFlag: 4a4f996a-08ef-4028-b92a-1d298b5dc971_5_41613
X-Mailer: PC_RICHMAIL 2.8.2
Date: Tue, 03 Nov 2020 14:02:50 +0800
From: Peng Liu <>
To: idr <>
Cc: Susan Hares <>
Content-Type: multipart/Alternative; boundary="----=_001_NextPart66815134_=----"
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: Tue, 03 Nov 2020 06:04:11 -0000




Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone:13810146105



发件人: Susan Hares

时间: 2020/11/02(星期一)13:03

收件人: idr;

主题: [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?