IETF Logo Mail Archive

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

"licong@chinatelecom.cn" <licong@chinatelecom.cn> Thu, 05 November 2020 01:23 UTC

Return-Path: <licong@chinatelecom.cn>
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 6D1823A11DF for <idr@ietfa.amsl.com>; Wed, 4 Nov 2020 17:23:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9196H0XCyuv for <idr@ietfa.amsl.com>; Wed, 4 Nov 2020 17:23:28 -0800 (PST)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id 15B603A11DE for <idr@ietf.org>; Wed, 4 Nov 2020 17:23:27 -0800 (PST)
HMM_SOURCE_IP: 172.18.0.218:1366.1860472475
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-140.240.41.113?logid-6c90838ba4db450ea70efe1d91efb1fa (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 09DB22800DC for <idr@ietf.org>; Thu, 5 Nov 2020 09:23:21 +0800 (CST)
X-189-SAVE-TO-SEND: 71080549@chinatelecom.cn
Received: from ([172.18.0.218]) by App0025 with ESMTP id 6c90838ba4db450ea70efe1d91efb1fa for idr@ietf.org; Thu Nov 5 09:23:22 2020
X-Transaction-ID: 6c90838ba4db450ea70efe1d91efb1fa
X-filter-score: filter<0>
X-Real-From: licong@chinatelecom.cn
X-Receive-IP: 172.18.0.218
X-MEDUSA-Status: 0
Sender: licong@chinatelecom.cn
Date: Thu, 05 Nov 2020 09:23:20 +0800
From: "licong@chinatelecom.cn" <licong@chinatelecom.cn>
To: idr <idr@ietf.org>
References: <050501d6b0d5$877d5970$96780c50$@ndzh.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.18.95[cn]
Mime-Version: 1.0
Message-ID: <202011050923197349898@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart512851484770_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Hm9gJn8uB-01RBsE0OMUOxnyeUE>
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: 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
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?

v2.29.0 | Report a Bug | By Email | System Status