Re: [Idr] Question about BGP Large Communities

"Dongjie (Jimmy)" <jie.dong@huawei.com> Thu, 06 February 2020 09:58 UTC

Return-Path: <jie.dong@huawei.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 AE205120288; Thu, 6 Feb 2020 01:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 8_j7GwfdE66U; Thu, 6 Feb 2020 01:58:50 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509B6120271; Thu, 6 Feb 2020 01:58:50 -0800 (PST)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9350699842B9A3E7E848; Thu, 6 Feb 2020 09:58:48 +0000 (GMT)
Received: from nkgeml702-chm.china.huawei.com (10.98.57.155) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 6 Feb 2020 09:58:48 +0000
Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by nkgeml702-chm.china.huawei.com (10.98.57.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 6 Feb 2020 17:58:45 +0800
Received: from nkgeml701-chm.china.huawei.com ([10.98.57.156]) by nkgeml701-chm.china.huawei.com ([10.98.57.156]) with mapi id 15.01.1713.004; Thu, 6 Feb 2020 17:58:45 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>, John Heasly <heas@shrubbery.net>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>
CC: "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>
Thread-Topic: Question about BGP Large Communities
Thread-Index: AdXbeNI4t0SppYFnSky8PqLGmuct1gAIu5NA//+eogCAACrygP/9XlgQ
Date: Thu, 6 Feb 2020 09:58:45 +0000
Message-ID: <402069c4103c4a4783972e3803327c85@huawei.com>
References: <DM6PR09MB54489301E52DD711E031400984030@DM6PR09MB5448.namprd09.prod.outlook.com> <BN6PR11MB1890AA431F63030DFE310902C0030@BN6PR11MB1890.namprd11.prod.outlook.com> <20200204225458.GB57481@shrubbery.net> <DM6PR09MB544817A892B1F331E972DF9384020@DM6PR09MB5448.namprd09.prod.outlook.com>
In-Reply-To: <DM6PR09MB544817A892B1F331E972DF9384020@DM6PR09MB5448.namprd09.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.182.24]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/s_2OA2rgyuhdYAYWpA1PCelRlY4>
Subject: Re: [Idr] Question about BGP Large Communities
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, 06 Feb 2020 09:58:53 -0000

If I understand it correctly, the proposed mechanism in Jakob's draft requires to change the encoding of Global Administrator in Large community. In general I like this change, it gives LC a structural encoding, which may be useful for future use cases. OTOH, this change typically would require new code and upgrade of devices, which may not meet the requirement mentioned in Brian's mail...

Best regards,
Jie

> -----Original Message-----
> From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Sriram,
> Kotikalapudi (Fed)
> Sent: Wednesday, February 5, 2020 9:29 AM
> To: John Heasly <heas@shrubbery.net>et>; Jakob Heitz (jheitz) <jheitz@cisco.com>
> Cc: idr@ietf.org; grow@ietf.org
> Subject: Re: [GROW] Question about BGP Large Communities
> 
> > > Does anyone want to co-author and suggest changes?
> I would also be glad to participate in that effort.
> 
> I have looked at the proposals in the two drafts (Jacob and John H).
> There are a few observations I would like to share.
> 
> As Alvaro pointed out, RFC 8092 says:
>    This document defines the BGP Large Communities attribute as an
>    optional transitive path attribute of variable length.
> 
> That means *all* BGP Large Communities are transitive. Do you agree?
> RFC 8195 seems to be written in that spirit as well.
> 
> The first 32 bits together are a Global Administrator (GA) ID.
> So, it seems it would not be possible to use any part of it as data.
> Otherwise, collisions (ambiguity) could happen when other LCs use 4-octet
> ASNs in the Global Administrator field. Agree?
> I see Jacob's draft proposes using some portion of the first 32 bits as data.
> The draft that John Heasly shared sets the first 32-bits to ASN value 0 to
> designate WK-LC;  so no part of the first 32-bits is data.
> 
> Another idea to consider:
> Why not request IANA to assign a range of 256 or 1024 or some number (?) of
> 4-byte ASN values to be allocated and used as GA ID for transitive WK-LCs?
> A function (e.g., route-leak protection) that requires transitive WK-LC will be
> allocated one these ASN values.
> Then we don't waste any part of the first 32-bits to designate "type" of LC.
> That cleanly leaves 64 bits for local data (as RFC 8092 specifies) which can
> accommodate two 4-byte ASNs if needed.
> 
> Sriram
> 
> > -----Original Message-----
> > From: John Heasly <heas@shrubbery.net>
> > Sent: Tuesday, February 4, 2020 5:55 PM
> > To: Jakob Heitz (jheitz) <jheitz@cisco.com>
> > Cc: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>ov>; Job
> > Snijders <job@ntt.net>et>; Nick Hilliard <nick@foobar.org>rg>; John Heasly
> > <heas@shrubbery.net>et>; idr@ietf.org; grow@ietf.org;
> > idr-chairs@ietf.org; grow-chairs@ietf.org; a.e.azimov@gmail.com; Brian
> > Dickson <brian.peter.dickson@gmail.com>
> > Subject: Re: Question about BGP Large Communities
> >
> > Tue, Feb 04, 2020 at 08:45:40PM +0000, Jakob Heitz (jheitz):
> > > A set of well known large communities could be useful.
> > > I have a draft that I never submitted attached to this email.
> > > Does anyone want to co-author and suggest changes?
> >
> > Hey Jacob,
> > I'd work on that with you.  Job, Morrow and I also started a draft for
> > Large WKCs, but we have not submitted anything - nor made any recent
> > progress.
> >
> > IIRC, the direction we were intending to use 0 (zero) as the ASN, then
> > define local data part 1 as WKC itself, and local data part 2 to be a
> > value associated.
> >
> > I've attached that I have written so far.  Job and Morrow may or may
> > not endorse this approach at this point.
> >
> > -heas
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow