Re: [Idr] [GROW] Choice of Large vs. Extended Community for Route Leaks Solution

Gyan Mishra <hayabusagsm@gmail.com> Thu, 01 April 2021 02:19 UTC

Return-Path: <hayabusagsm@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 720303A0E7B; Wed, 31 Mar 2021 19:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 bLwO5ztZGBiS; Wed, 31 Mar 2021 19:19:39 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 8F5583A0E82; Wed, 31 Mar 2021 19:19:39 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id l76so597925pga.6; Wed, 31 Mar 2021 19:19:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SYngaM5ttwQBKUI+wbR5tpm8bE+hF6WfUqMDrz7DE+0=; b=ueUSjnPEXNV/GJ8HNzxYR4lNTpRcirYL7PCshMRc0scn9uLDlzE2tTXgFEtdzZ5pbO 27Uv6yHVge3JD/YazPFUV1h8E+3H2nKg8DpzRs+rTjkWLljHqTp9JhKONjjIteq9BGLo lio2mUF/3V5/pLSR6ziJ/YEuXpHbH2yxHC/GL9oSlnJsjrmRlTYydRlFcgLg9/n9CQ4X l7AadejBjQkgzfxEu5bK/7UDN5tVO8BEVJdiWxnuj072OuiUoUoE4vi7/z8oMmZmSV/X Pai1YohTzMgm1FVHM/Jl8AQTmXc6awewk6fbH+SA646a/CYTqxPvW4Jy5gMzYQNywF8k 4Kuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SYngaM5ttwQBKUI+wbR5tpm8bE+hF6WfUqMDrz7DE+0=; b=TLzN7ORZP5H1ydT28GcXoBCppiCy1L8kjjAYtRS8+JrDJs0RF8feslxOrQnNqTFqpT bZoBf50Tfx50p2i3NyJUutouGSxX4VM8IcH1EwXuW5H8RgzAxBHwZiNUlX0E+WtVeodm BIItzugvl8BiMfV48ulpJ2UtXMJJ+WtfC/Y1s/KP3dpbPHBo1pm7Df6b3KVlMOcSAwYt fcGNA09AZxjsajNocWrFDeLSRhGo4ypg7av8/sxnHDOloUVT3A5setRy6o+z1nsDDGQQ GxkEayzKz0MML+siPazUQJEfesDQyqytfi9fnkC6hqftv2HLZyDyELO1gIhlTrldPsul JtRg==
X-Gm-Message-State: AOAM5338r6cl/6WQmN24izbyuZ0ok5vkTAg1PqJWusxRq35LlgyX+Qwg MDFz8w/lEslWWc2MQr/1XhGYrnroUZtdkdQWpk4=
X-Google-Smtp-Source: ABdhPJxrarNRoKrFug/ImhKXeoTHjTE03xxMaahj7PwvBFa71uy7pskc20C7qBFx12ixlqqC7YvHl7xw8SCX8uEA0SE=
X-Received: by 2002:a62:7914:0:b029:1f6:3fdd:4553 with SMTP id u20-20020a6279140000b02901f63fdd4553mr5753409pfc.30.1617243577899; Wed, 31 Mar 2021 19:19:37 -0700 (PDT)
MIME-Version: 1.0
References: <SA1PR09MB814269138AEE1567CEED703B847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <20210331161358.GI24667@pfrc.org> <SA1PR09MB8142C40CC942F7CF7BD05EDF847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <BYAPR11MB3207EA9CAAAA0B1899404A3EC07C9@BYAPR11MB3207.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3207EA9CAAAA0B1899404A3EC07C9@BYAPR11MB3207.namprd11.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 31 Mar 2021 22:19:27 -0400
Message-ID: <CABNhwV39JSf8eWJRwYQ4MA=D6SaA+sWq0eRA=FjtiTyTv26QgA@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, "grow@ietf.org" <grow@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f9dfa305bedfdcc8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xU3hwRlCrMHXmwKYacinfwMOrLg>
Subject: Re: [Idr] [GROW] Choice of Large vs. Extended Community for Route Leaks Solution
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, 01 Apr 2021 02:19:44 -0000

Correction

BGP communities  are optional transitive.  If all communities were not
transitive the knob would not exist in any implementation such as Cisco and
maybe others that have a “send-community” knob requirements manual CLI
command to propagate communities.

BGP communities going between administrative domains public or private are
mailable and not reliable as operators can and do often delete and reset
communities if desired. Agreed.


On Wed, Mar 31, 2021 at 2:03 PM Jakob Heitz (jheitz) <jheitz=
40cisco.com@dmarc.ietf.org> wrote:

> No community is transitive.
> Not even the transitive extended communities.
>
> In all BGP code I've worked in, not just Cisco, a configuration
> is required to send communities of any kind to an ebgp session.
> By default, no communities are sent to ebgp session
> That's a good thing, because network operators don't want
> junk in the routes transiting across their networks, causing
> churn and memory consumption.
>
> Path attributes are transitive.
> However, several years ago, approximately coinciding with the
> development of RFC7660, there was massive thrust to get attributes
> blocked too. Now we implement path attribute filtering
> and many network operators use it.
>
> Regards,
> Jakob.
>
> -----Original Message-----
> From: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>
> Sent: Wednesday, March 31, 2021 10:17 AM
> To: Jeffrey Haas <jhaas@pfrc.org>
> Cc: Susan Hares <shares@ndzh.com>om>; idr@ietf.org; grow@ietf.org;
> draft-heitz-idr-wklc@ietf.org
> Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks
> Solution
>
> Jeff,
>
> Thank you for the response. My comments inline.
>
> >You can thus just get a FCFS extended community from a
> >transitive space TODAY and
> >it'd probably do most of what you want.  One of the beneficial properties
> >that extended communities have is the transitivity is at least understood
> >and well deployed.
>
> I was hoping for a confirmation of that nature. So, that is good to hear.
>
> >That said, there's still no guarantee that some operator may choose to
> just delete them all at an ASBR.
>
> Yep. It is not a perfect world. But are you suggesting that no
> community-based approach (EC or LC or ?) is worth pursuing?
>
> >...the headache you're going through is trying to avoid the work of
> creating a new attribute.
>
> There is already a separate draft in IDR that has passed WGLC, and it uses
> a new transitive BGP Path Attribute 'Only to Customer (OTC)':
> https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15
> We view that as a longer-term solution, while the EC/LC-based approach is
> meant to be deployed quickly.
>
> >A discussion I'd suggest is that we've had a need for a "BGP routing
> >security" attribute where we can put these various proposals:
> >- It's not a victim of existing community practices.
> >- Policy might still interact with it, but the baseline maintenance
>   expectations can be set for it.
> >- It can be extensible so new components can be added incrementally.
>
> In the above, are you suggesting BGP Path Attribute or a new type of
> Community that comes with transitivity guarantees?
>
> Sriram
> ________________________________________
> From: Jeffrey Haas <jhaas@pfrc.org>
> Sent: Wednesday, March 31, 2021 12:13 PM
> To: Sriram, Kotikalapudi (Fed)
> Cc: Susan Hares; idr@ietf.org; grow@ietf.org;
> draft-heitz-idr-wklc@ietf.org
> Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks
> Solution
>
> Sriram,
>
> (Clearly I'm not Sue...)
>
> Extending the observation I've just made to Gyan, the headache you're going
> through is trying to avoid the work of creating a new attribute.  A result
> of this is a lot of work trying to proscriptively change how people operate
> their networks for more general features.
>
> Extended communities have functionally behaved as more of a protocol
> control
> mechanism in their general history.  They already have behaviors that
> permit
> them to be selectively transitive or non-transitive across ASes.
> Operationally, they MAY be stripped by policy, but sanitization practices
> for them are significantly less codified than RFC 1997 communities.  You
> can
> thus just get a FCFS extended community from a transitive space TODAY and
> it'd probably do most of what you want.  One of the beneficial properties
> that extended communities have is the transitivity is at least understood
> and well deployed.
>
> That said, there's still no guarantee that some operator may choose to just
> delete them all at an ASBR.
>
> A discussion I'd suggest is that we've had a need for a "BGP routing
> security" attribute where we can put these various proposals:
> - It's not a victim of existing community practices.
> - Policy might still interact with it, but the baseline maintenance
>   expectations can be set for it.
> - It can be extensible so new components can be added incrementally.
>
> While I understand a motivation for putting this in communities is "faster
> deployment", take the other example from the life of large communities:
> when
> there's sufficient interest, the feature will show up pretty fast.
>
> -- Jeff (the best time to plant a tree is ten years ago. the second best
> time is now...)
>
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*