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

Peng Liu <liupengyjy@chinamobile.com> Tue, 03 November 2020 06:04 UTC

Return-Path: <liupengyjy@chinamobile.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 6E1A43A14A6 for <idr@ietfa.amsl.com>; Mon, 2 Nov 2020 22:04:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.329
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qT4QVAQ8Vkz0 for <idr@ietfa.amsl.com>; Mon, 2 Nov 2020 22:04:00 -0800 (PST)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id E5A5C3A14A2 for <idr@ietf.org>; Mon, 2 Nov 2020 22:03:04 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) 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[10.2.50.90]) 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 <liupengyjy@chinamobile.com>
To: idr <idr@ietf.org>
Cc: Susan Hares <shares@ndzh.com>
Message-ID: 2020110314025066815134@chinamobile.com>
Content-Type: multipart/Alternative; boundary="----=_001_NextPart66815134_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/DiznhwvHfdeo5cCsmVWCet22wF0>
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: Tue, 03 Nov 2020 06:04:11 -0000




Yes,support.




Regards,

Peng








Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone:13810146105

email:  liupengyjy@chinamobile.com

 



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

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?