Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)
Jeffrey Haas <jhaas@pfrc.org> Wed, 31 March 2021 14:41 UTC
Return-Path: <jhaas@slice.pfrc.org>
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 611FA3A2AAF for <idr@ietfa.amsl.com>; Wed, 31 Mar 2021 07:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 Xor9hyeofaCE for <idr@ietfa.amsl.com>; Wed, 31 Mar 2021 07:41:34 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 77E553A2AA5 for <idr@ietf.org>; Wed, 31 Mar 2021 07:40:36 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 9E1911E455; Wed, 31 Mar 2021 11:02:39 -0400 (EDT)
Date: Wed, 31 Mar 2021 11:02:39 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, IETF IDR <idr@ietf.org>
Message-ID: <20210331150239.GH24667@pfrc.org>
References: <000501d71940$e9b87420$bd295c60$@tsinghua.org.cn> <BYAPR11MB320799969ECFDA66B32F2BBBC06C9@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV1UotP6Zc-YhvbBbj0XDiH-nnu3raUH9c0agVJ6B-D32A@mail.gmail.com> <BYAPR11MB320787166ECA326B9E05B2B2C06B9@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV071G9LPV4zjDzJU=YvcTHaJ3KP4yzjEuP62mkLLy_njg@mail.gmail.com> <BYAPR11MB3207F0D8480B4B8EF992406CC0689@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV27YxKhmOjYq6v9Yj_Tqe7rV8wHBhdh6Z_oRZ5-U0E_9g@mail.gmail.com> <BYAPR11MB3207DA25A51E243C011D2B35C0679@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV25atsaC=DASeSSzTmBNN8W_Ju2MOhpGG+d-EY=+GJAxQ@mail.gmail.com> <CABNhwV3pyQo=ZMpP08x7a=6Amb=7LqsysAcAMxFtNdzSoRKRVA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABNhwV3pyQo=ZMpP08x7a=6Amb=7LqsysAcAMxFtNdzSoRKRVA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/yrwYy4ngiS0gPnR5LPkJuyIozCg>
Subject: Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)
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: Wed, 31 Mar 2021 14:41:36 -0000
Gyan, On Tue, Mar 30, 2021 at 08:45:29PM -0400, Gyan Mishra wrote: > The last question I had asked about type 2 4 byte AS extended communities > defined in RFC 5568 due the 4 byte AS eating up an extra 2 bytes in the > Global Admin field you are only left with 2 bytes in the Local Admin > field. RFC 8092 was supposed to solve that shortcoming with a larger local > administrative field. > > As this draft is updating RFC 8092, I think it really should account for > shortcomings of 4 byte extended communities. With large communities we > have 10 bytes of data fields even with the 2 high order bytes used we > should still be able to accommodate. Our current status quo with large communities perhaps should serve as a cautionary tale for those who want to "move fast" and "keep it simple". As Sue noted in her chairs' response, there was discussion about transitivity, and about whether we wanted to set aside code space in the new feature for special treatment. The pattern we had as an example of such special treatment is the space set aside for well known communities in RFC 1997. The strong consensus of the working group and the rather fervent portion of the operational community at that time was "keep it simple, ship it now". We did. The feature is now heavily deployed. We don't get to change such a feature easily, there's too many pieces of running code that wouldn't respect the new semantics. One of the hardest thing about working on BGP is dealing with incremental deployment circumstances. We don't have a lot of easy options here. draft-ietf-grow-route-leak-detection-mitigation quite nicely summarizes some of the additional headaches of trying to force behaviors to fit into generic community features. From that document: : On the other hand, BGP Communities do not require a router OS update. : The potential disadvantage of using a Community for the route-leak : detection signal is that it is more likely to be dropped somewhere : along the way in the AS path. Currently, the use of BGP Communities : is somewhat overloaded. BGP Communities are already used for : numerous applications: different types of route marking, route policy : control, blackholing, etc. It is observed that some ASes seem to : purposefully or accidentally remove BGP Communities on receipt, : sometimes well-known ones. Perhaps this issue may be mitigated with : strong policy guidance related to the handling of Communities. : : Large Communities have much higher capacity, and therefore they are : likely to be less overloaded. Hence, Large Community is proposed to : be used for route-leak detection. This document suggests reserving : <TBD1> class for the purpose of transitive well-known Large : Communities that MUST NOT be stripped on ingress or egress. Basically, "people do these things with communities that can break this feature, if carried in communities". "Don't do that" doesn't scale terribly well. -- Jeff
- [Idr] Adoption call for draft-heitz-idr-wklc-02 (… Susan Hares
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Aijun Wang
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Jakob Heitz (jheitz)
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Aijun Wang
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Jakob Heitz (jheitz)
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Aijun Wang
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Acee Lindem (acee)
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Jakob Heitz (jheitz)
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Aijun Wang
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Aijun Wang
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Jakob Heitz (jheitz)
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Aijun Wang
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Brian Dickson
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Aijun Wang
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Jakob Heitz (jheitz)
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Aijun Wang
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Gyan Mishra
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Jakob Heitz (jheitz)
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Jakob Heitz (jheitz)
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Gyan Mishra
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Gyan Mishra
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Jakob Heitz (jheitz)
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Gyan Mishra
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Gyan Mishra
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Brian Dickson
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Gyan Mishra
- Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for … Jakob Heitz (jheitz)
- [Idr] WKLC transitivity considerations (was Re: A… Jeffrey Haas
- Re: [Idr] WKLC transitivity considerations (was R… Jakob Heitz (jheitz)
- Re: [Idr] WKLC transitivity considerations (was R… Jeffrey Haas
- Re: [Idr] WKLC transitivity considerations (was R… Jakob Heitz (jheitz)
- Re: [Idr] WKLC transitivity considerations (was R… Gyan Mishra
- Re: [Idr] WKLC transitivity considerations (was R… Jakob Heitz (jheitz)
- Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for … Gyan Mishra
- Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for … Jakob Heitz (jheitz)
- Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for … Gyan Mishra
- Re: [Idr] WKLC transitivity considerations (was R… Ben Maddison
- Re: [Idr] WKLC transitivity considerations (was R… Jakob Heitz (jheitz)
- Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for … Alexander Azimov
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Nick Hilliard
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Robert Raszuk
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Borchert, Oliver (Fed)
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Gyan Mishra
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Susan Hares
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Brian Dickson
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Jakob Heitz (jheitz)
- Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for … Gyan Mishra
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Robert Raszuk
- Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for … Jeffrey Haas
- Re: [Idr] Adoption call for draft-heitz-idr-wklc-… Jakob Heitz (jheitz)
- Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for … Gyan Mishra