Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)
Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 13 November 2020 18:53 UTC
Return-Path: <jefftant.ietf@gmail.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 520C23A1036 for <idr@ietfa.amsl.com>; Fri, 13 Nov 2020 10:53:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tDbPr3W9KhwA for <idr@ietfa.amsl.com>; Fri, 13 Nov 2020 10:53:46 -0800 (PST)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88953A0978 for <idr@ietf.org>; Fri, 13 Nov 2020 10:53:46 -0800 (PST)
Received: by mail-pf1-x42a.google.com with SMTP id 10so8386231pfp.5 for <idr@ietf.org>; Fri, 13 Nov 2020 10:53:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=GAo4bDKB4bpAc4twroQhkgBoWjA/7SNv1nG8JW7RjIY=; b=F2FJvb3Bixn3Gq8xpbyGnKCqJ+UwprXyEn/r+mLfjuJkvMR3+yv5ciX3AEaUVHe5Oj UbAr8xVnBnFVRA0KyUq8aqI/ypa47jdvHcpn7RY0/6mN3zxe+LOME4tjM7a4N/7F+lF+ 7oP12Rv4RI6XPOc5slaaayyf0SbtjxR2lqb0tsOHyIOj4DdsTF4pS2luCKjDeonFI/1H AYIoGsenHi4u7rCT/Pn16rXhbFVve1dV3ofj8l+mdJkyPFPR/daYkEYlptToKYRfpN5a sYck/YkCAcGCCsUdFHxQMiFHJysQNHesNmJlUVTCYjWqL3J4jMGvXZHInzYsIsXnL8J0 f3aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=GAo4bDKB4bpAc4twroQhkgBoWjA/7SNv1nG8JW7RjIY=; b=iLdTtL5V63LtmR3wToy6IDOF7yGxe5CPA+w0pPZBJ+2Ms/kPooVb/ecbc+0hosgDqf DA5HIfXnVrjDzeojw4O2/RTsH6hzOmYglOi945AiWHDRIMfE0ASPtUSzUZEqg7VXvZxs mU1QcRlBWy1Ysb+V5phomOawtPI69xKSleroVe54qZWZmaSK8ebNsDWhgohPRb3Z5woC x77m8+a9RNyOOMmeseLR7DyX6+KJVUm7mS39t7oIWkKAXgNjA7MfizEFH+jHsTumwZZo 8ul0jrfve6rJBeQjJqCyuiI0a1anSONTkZYUmGs2wahpgAsCe3Uj9u8DRppIQtdg2Uye 49+w==
X-Gm-Message-State: AOAM530Qj4zqycSmizA6uSqA3mdjBJ7YC1n3VYJ6x0dH2X53tVjylDID iOGkfDouBPp0A++Gmz56NPScpjBv4tE=
X-Google-Smtp-Source: ABdhPJy6/77LAj9J5jKnx6R1wt8vbkds0j0jgiMUELEUw0IF+wCH5N0+qOmOIj0mgxbNdxXnVMtLcQ==
X-Received: by 2002:a17:90a:6586:: with SMTP id k6mr4635786pjj.225.1605293626430; Fri, 13 Nov 2020 10:53:46 -0800 (PST)
Received: from [192.168.1.7] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id d7sm9607585pgh.17.2020.11.13.10.53.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2020 10:53:45 -0800 (PST)
Date: Fri, 13 Nov 2020 10:53:38 -0800
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: "Stephane Litkowski (slitkows)" <slitkows=40cisco.com@dmarc.ietf.org>, idr@ietf.org, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Susan Hares <shares@ndzh.com>
Message-ID: <93312bf6-8929-4837-9686-edb373edc49f@Spark>
In-Reply-To: <02c501d6b924$b4a34b10$1de9e130$@ndzh.com>
References: <050501d6b0d5$877d5970$96780c50$@ndzh.com> <SJ0PR11MB5136C14AD3AED30EF5EC128BC2EF0@SJ0PR11MB5136.namprd11.prod.outlook.com> <033001d6b678$08d20280$1a760780$@ndzh.com> <CO1PR11MB512125F36BEF9AC8FEAE0598C2EA0@CO1PR11MB5121.namprd11.prod.outlook.com> <006801d6b6de$0f89c390$2e9d4ab0$@ndzh.com> <1F8F1206-0583-4262-8837-934C10F2B034@cisco.com> <9346741d-6eda-4fbc-917f-2ac3662aac0b@Spark> <02c501d6b924$b4a34b10$1de9e130$@ndzh.com>
X-Readdle-Message-ID: 93312bf6-8929-4837-9686-edb373edc49f@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5faed638_3d1b58ba_ba5e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZiX27LVH3neh4_r2KTjgMCC10oI>
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 18:53:49 -0000
Sue, I believe this draft should progress in LSR, there are number of issues with encodings proposed that need to be addressed in process. Thanks and have a great weekend! Cheers, Jeff On Nov 12, 2020, 10:50 AM -0800, Susan Hares <shares@ndzh.com>, wrote: > Jeff and Authors of draft-zhu-idr-bgp-ls-path-mtu: > > I do believe the authors agreed to renaming the draft. > > Does the name: draft-xxx-idr-bgp-ls-link-mtu work for > the authors and interested IDR participants. > > As the end of 12 days of the 14 day WG LC, this draft appears > to have general consensus from the WG as a useful draft. > > I plan to allow 2 more days of comment, but at this point > it appears the WG wishes to adopt this draft. > > Here’s my understanding of the best way forward: > > If LSR adopts a version of the draft, IDR will allow the > LSR WG to be the main source as long as cross-working > review occurs so the BGP-only function can be reviewed. > > Please continue to comment on the draft and > the planned progression. > > Cheers, Sue > > From: Jeff Tantsura [mailto:jefftant.ietf@gmail.com] > Sent: Thursday, November 12, 2020 12:53 PM > To: Susan Hares; Stephane Litkowski (slitkows); idr@ietf.org; Acee Lindem (acee) > Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020) > > +1 to everything Acee said > > Cheers, > Jeff > On Nov 10, 2020, 1:01 PM -0800, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>, wrote: > > Speaking as an IDR WG member: > > The name of the draft is wrong – the extension is for a Link MTU and not a path MTU. > > Speaking as LSR Chair: > > We could this in LSR as there is currently no MTU advertisement in the LSAs for OSPFv2 and OSPFv3. Implementations already make use of this information as it is used in the OSPF DBD packets and for LSA packing. Of course, we’d require a more accurate draft name and title. > > Thanks, > Acee > > From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com> > Date: Monday, November 9, 2020 at 4:20 PM > To: "'Stephane Litkowski (slitkows)'" <slitkows=40cisco.com@dmarc.ietf.org>, IDR List <idr@ietf.org> > Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020) > > Stephane: > > My second message to this thread asked a few questions about the technology. > > This information can be more than IGP information. If SR segments statically defined (static or direct interfaces) tunnels and pass the endpoints via BGP tunnel-encaps draft with SR Policy tunnel type, this can just be BGP. > > I’ll keep this WG adoption call going until we can be sure if: 1) it something LSR wants to standardize, and 2) whether there is a BGP only case. It is clear to me that standardizing MTU for a SR segments with stacked tunnel segments passed by BGP was useful. > > The authors should be the ones to propose this in LSR. > > Cheers, Sue > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Stephane Litkowski (slitkows) > Sent: Monday, November 9, 2020 4:28 AM > To: Susan Hares; idr@ietf.org > Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020) > > Hi Sue, > > > The purpose behind this mechanism is to reduce administrative work rather than to reduce the review on drafts. > > That’s exactly my point. If we don’t do OSPF extension now and in the same draft, we leave a gap that will require a new draft for a very very small extension. Just adds process overhead for nothing… > > > Stephane > > > From: Susan Hares <shares@ndzh.com> > Sent: lundi 9 novembre 2020 10:10 > To: Stephane Litkowski (slitkows) <slitkows@cisco.com>; idr@ietf.org > Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020) > > Stephane: > > I want to pick up on your email from two points: > > 1) Why not do everything in LSR? > <WG-chair hat> > If the feature comes with interest in doing all 3 (ISIS, OSPF, and BGP-LS data gathering), then the authors may select to do everything in LSR rather than have 2 or 3 drafts to maintain. > > This is optional and the mechanism may not fit every draft. The drafts may also start out adopted and vetted in LSR and IDR. The purpose behind this mechanism is to reduce administrative work rather than to reduce the review on drafts. > > </wg-chair hat off> > > > 2) TRILL implementations of IS-IS has some MTU subTLV - > > If you are interested in whether this has been implemented in TRILL, you might want to check with Donald Eastlake. My vague and foggy recollection is that had some implementations or came from pre-TRILL implementations. > > > Cheers, Susan Hares > > > > From: Stephane Litkowski (slitkows) [mailto:slitkows@cisco.com] > Sent: Wednesday, November 4, 2020 3:03 AM > To: Susan Hares; idr@ietf.org > Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020) > > Hi, > > “a) Are there ways to pass IGP link MTUs in > the IGPs? If so, is this needed in BGP-LS” > > This is a valid point, most of the time BGP-LS is feeded by IGP LSDBs (of course there are other ways too). While I see that IS-IS has some MTU subTLV coming from TRILL RFC7176 (possibly never been implemented), I don’t see anything for OSPF (I’m not an OSPF expert, so I may have missed it). > Shouldn’t this be checked and validated with LSR WG before adopting ? > > > Stephane > > > From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares > Sent: lundi 2 novembre 2020 06:04 > 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? > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr
- [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-m… Susan Hares
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Chengli (Cheng Li)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Stephane Litkowski (slitkows)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Pengshuping (Peng Shuping)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Peng Liu
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Huzhibo
- [Idr] 回复: WG Adoption for draft-zhu-idr-bgp-ls-pa… zhuyq8
- [Idr] 回复: WG Adoption for draft-zhu-idr-bgp-ls-pa… zhuyq8
- Re: [Idr] 回复: WG Adoption for draft-zhu-idr-bgp-l… Lizhenbin
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Dongjie (Jimmy)
- [Idr] 答复: WG Adoption for draft-zhu-idr-bgp-ls-pa… Weiqiang Cheng
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Pengshuping (Peng Shuping)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Stephane Litkowski (slitkows)
- [Idr] 回复: WG Adoption for draft-zhu-idr-bgp-ls-pa… Tao He(联通集团中国联通研究院-本部)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… licong@chinatelecom.cn
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Ran Pang(联通集团中国联通研究院- 本部)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Susan Hares
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Stephane Litkowski (slitkows)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Susan Hares
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Susan Hares
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Pengshuping (Peng Shuping)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Acee Lindem (acee)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Susan Hares
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Pengshuping (Peng Shuping)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Susan Hares
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Jeff Tantsura
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Susan Hares
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Takuya Miyasaka
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Dhruv Dhody
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Ketan Talaulikar (ketant)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Jeff Tantsura
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Les Ginsberg (ginsberg)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Jeff Tantsura
- [Idr] 答复: WG Adoption for draft-zhu-idr-bgp-ls-pa… Huzhibo
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Ketan Talaulikar (ketant)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Wanghaibo (Rainsword)
- Re: [Idr] 答复: WG Adoption for draft-zhu-idr-bgp-l… Robert Raszuk
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Les Ginsberg (ginsberg)
- [Idr] 答复: WG Adoption for draft-zhu-idr-bgp-ls-pa… Huzhibo
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Susan Hares
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Susan Hares
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Ketan Talaulikar (ketant)
- Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-pa… Jeff Tantsura
- Re: [Idr] [Lsr] WG Adoption for draft-zhu-idr-bgp… Gyan Mishra
- Re: [Idr] [Lsr] WG Adoption for draft-zhu-idr-bgp… Chengli (Cheng Li)