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

Takuya Miyasaka <ta-miyasaka@kddi-research.jp> Fri, 13 November 2020 04:16 UTC

Return-Path: <ta-miyasaka@kddi-research.jp>
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 960283A147A for <idr@ietfa.amsl.com>; Thu, 12 Nov 2020 20:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 y8tax3CW9JdX for <idr@ietfa.amsl.com>; Thu, 12 Nov 2020 20:16:19 -0800 (PST)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [192.26.91.6]) by ietfa.amsl.com (Postfix) with ESMTP id 52AA63A1479 for <idr@ietf.org>; Thu, 12 Nov 2020 20:16:18 -0800 (PST)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 41AC7C0EF67A; Fri, 13 Nov 2020 13:16:17 +0900 (JST)
X-Virus-Scanned: amavisd-new at kddi-research.jp
Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFzEY3MxMu_t; Fri, 13 Nov 2020 13:16:11 +0900 (JST)
Received: from safeattach.localdomain (unknown [IPv6:2001:200:601:1a00:20c:29ff:fe79:2280]) by mandala.kddilabs.jp (Postfix) with ESMTP id 42B66C0F0097; Fri, 13 Nov 2020 13:16:11 +0900 (JST)
Received: from [172.19.124.101] (dhcp101.west-4f.cn.kddilabs.jp [172.19.124.101]) by safeattach.localdomain with ESMTP id 0AD4GAqM028809; Fri, 13 Nov 2020 13:16:11 +0900
To: Susan Hares <shares@ndzh.com>, idr@ietf.org
References: <050501d6b0d5$877d5970$96780c50$@ndzh.com>
From: Takuya Miyasaka <ta-miyasaka@kddi-research.jp>
Message-ID: <fe63856d-6827-019f-4e55-d0ff21e8b576@kddi-research.jp>
Date: Fri, 13 Nov 2020 13:16:11 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2
MIME-Version: 1.0
In-Reply-To: <050501d6b0d5$877d5970$96780c50$@ndzh.com>
Content-Type: multipart/alternative; boundary="------------5573C03C9302A5818E882B9F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LZQ6_32iSQnOJ7NRR5JMdCIDxYM>
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: Fri, 13 Nov 2020 04:16:22 -0000

Hi,

I support the adoption of this draft.

I have read the draft and, as an operator, think this is an useful and 
(maybe) essential BGP-LS extension for a controller to build SR-TE path.

Thanks,
Takuya

On 2020/11/02 14:03, Susan Hares wrote:
>
> 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/ 
> <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?
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr