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

Yisong Liu <liuyisong@chinamobile.com> Thu, 05 November 2020 03:13 UTC

Return-Path: <liuyisong@chinamobile.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 996513A1657 for <idr@ietfa.amsl.com>; Wed, 4 Nov 2020 19:13:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uzso6KAYGdT0 for <idr@ietfa.amsl.com>; Wed, 4 Nov 2020 19:13:36 -0800 (PST)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com []) by ietfa.amsl.com (Postfix) with ESMTP id BDD053A1655 for <idr@ietf.org>; Wed, 4 Nov 2020 19:13:35 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[]) by rmmx-syy-dmz-app04-12004 (RichMail) with SMTP id 2ee45fa36dd495d-ad0b7; Thu, 05 Nov 2020 11:13:24 +0800 (CST)
X-RM-TRANSID: 2ee45fa36dd495d-ad0b7
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCC-PC (unknown[]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea5fa36dd0c61-a269b; Thu, 05 Nov 2020 11:13:22 +0800 (CST)
X-RM-TRANSID: 2eea5fa36dd0c61-a269b
MIME-Version: 1.0
x-PcFlag: fcf323cf-a4e1-4927-80c8-5f87e4fbc8e3_5_24609
X-Mailer: PC_RICHMAIL 2.8.2
Date: Thu, 05 Nov 2020 11:13:22 +0800
From: Yisong Liu <liuyisong@chinamobile.com>
To: Susan Hares <shares@ndzh.com>, idr <idr@ietf.org>
Message-ID: 20201105111322339237848@chinamobile.com>
Content-Type: multipart/Alternative; boundary="----=_001_NextPart339237848_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/u5iYuOoIJDF__hWlUZ1uCdz7ZL0>
Subject: [Idr] Re: 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: Thu, 05 Nov 2020 03:13:39 -0000

Hi all

I support the adoption of this draft.



发件人: 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?