Re: [Idr] One Admin Domain

Robert Raszuk <robert@raszuk.net> Thu, 08 April 2021 07:39 UTC

Return-Path: <robert@raszuk.net>
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 BE33F3A3E68 for <idr@ietfa.amsl.com>; Thu, 8 Apr 2021 00:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 pyelyt_Ie9kk for <idr@ietfa.amsl.com>; Thu, 8 Apr 2021 00:39:00 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 5A03E3A3E99 for <idr@ietf.org>; Thu, 8 Apr 2021 00:38:59 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id d13so2342425lfg.7 for <idr@ietf.org>; Thu, 08 Apr 2021 00:38:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M8i8nE8yzKfX+jWCDctrj+qM5wA70N3tY7SAC0lDErg=; b=WG58iFfm3FH0Hiz0SMm281geCPGasdfC/k/X9ZnbBI6aCgRJD07s8HjDsq+CJk6FEg xu/Pk062WzNEQj9akn2YBr4Cwwaw8+2/tEW3V9P3+cU1DtY6oet++wVBY30+1w8Kh8hK NZG4avfl88KnHRJG842uzCfWztcuK3wPRmFEOjpFmaslgE/Sp5Rj3NpZbIHM3tWJK+0k +sXiWW3BVkXygkABh7vt8clKD+ZPwK92R6GtGq+VC/ViTcD6CJJjabvJ1XsPzMIba+bS w0LWsW55eN/ZVi/2n9A5rFiUZFMmKBpCucrQi/YToH7WbUuxvhqVv26agB8v6L/RGBiv u4RA==
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=M8i8nE8yzKfX+jWCDctrj+qM5wA70N3tY7SAC0lDErg=; b=UddQnIwUUR5q+mbnsbV1IsyBh+gIET5lYsYrgrMmJMXa/j8x1wYdkHY+LwoZfrb0iX noLj6ETomCWN9oYKt0Hjod+N4O4IBD8iU0uup2bNl1mfcfRsMZhR207HyiO4WJhkOxc4 FTVbJlo507fsMOz1Mk56kqsIoYdgihNRrzwTWZ7CDeXP2cochEgl4FG1Ku5RuAQU+Tvo LI+u52QpCxHBirek09A3VMTDZk/XelZ5OO1DNQYZ3j1E4e/eJGbt4u5edoaellMQ3Ohc DfzAAmKzIwpLFEdoV6r/g2sq90fZNDpoFCIQ0rjYu7nr0DwOAGAKcndQp4rr6C0ywqzb A19Q==
X-Gm-Message-State: AOAM531TLs0RdxEh0Ck6s4S1Iti5ZR1NtSp/D5fOyH4syO5GfVny8kSk r4rHxLskc1YJ52+Tvm/roj6if9zqj90dU5ZUtW2iqw==
X-Google-Smtp-Source: ABdhPJx3OHDAl22oduGAvCV8qlw7GfUTBJ2jcjUF0tswRjmfz1Dr11xCKvrbpGznXqpjj/TAyg5GlV0hdE8qHBUkUzE=
X-Received: by 2002:ac2:46db:: with SMTP id p27mr5178638lfo.396.1617867535582; Thu, 08 Apr 2021 00:38:55 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR11MB32078DF8E3EE49F3248742C7C0759@BYAPR11MB3207.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB32078DF8E3EE49F3248742C7C0759@BYAPR11MB3207.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 8 Apr 2021 09:38:45 +0200
Message-ID: <CAOj+MMGHHLmmVxMdnQrCZDXpqCBdehNF=w88jgOW+hzL1HSz+Q@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
Cc: "UTTARO, JAMES" <ju1738@att.com>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c09bec05bf712377"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OQAIJiUEtjgWnIQc8u0ODY65x-g>
Subject: Re: [Idr] One Admin Domain
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, 08 Apr 2021 07:39:09 -0000

>  That draft looks fine. Was it ever submitted? I can't find it in a
search.

https://tools.ietf.org/html/draft-uttaro-idr-oad-01

r.


On Wed, Apr 7, 2021 at 11:55 PM Jakob Heitz (jheitz) <jheitz=
40cisco.com@dmarc.ietf.org> wrote:

> Jim,
>
> That draft looks fine. Was it ever submitted? I can't find it in a search.
>
> I would add a mechanism to reduce the AS_PATH length.
> When sending out of the OAD, replace the sequence of ASNs in the
> OAD by a single configured master ASN.
> If a route is received by a speaker in any AS in the OAD from a speaker
> not in
> the OAD, then the master ASN in the AS_PATH counts as a loop.
>
> Regards,
> Jakob.
>
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of UTTARO, JAMES
> Sent: Wednesday, April 7, 2021 6:43 AM
> To: Jeffrey Haas <jhaas@pfrc.org>rg>; Robert Raszuk <robert@raszuk.net>
> Cc: idr@ietf. org <idr@ietf.org>rg>; Susan Hares <shares@ndzh.com>
> Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits -
> 3/30 to 4/13
>
> " I don't believe we're likely to come up with a simple answer to BGP
> capability domains soon.  That said, operators in a single administrative
> domain at least can figure this out themselves because they're the ones
> configuring it"
>
> This discussion illustrates that a single administrative domain spanning
> multiple ASes should be addressed. Pradosh, John Scudder and I began
> identifying how an OAD ( One Administrative Domain ) should behave in terms
> of an eBGP and OAD-eBGP learned paths. ( See Attached ).
>
> As an example if we offering RFC 1998 feature to a customer whose VPN
> spans multiple AS domains requires that the operator preserve or reset (
> default ) the LP. The customer may want to scope LP to a given AS or have
> it apply across an OAD.  As operators we have figured out how to create a
> somewhat seamless reachability/forwarding domain upon which services can be
> overlaid. That being said it maybe time to re-look at the scope of an AS
> vis-a-vis Admin domain including capabilities on a router, AS and OAD
> level..
>
> Thanks,
>         Jim Uttaro
>
>
>
>
>
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
> Sent: Wednesday, April 07, 2021 9:25 AM
> To: Robert Raszuk <robert@raszuk.net>
> Cc: idr@ietf. org <idr@ietf.org>rg>; Susan Hares <shares@ndzh.com>
> Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits -
> 3/30 to 4/13
>
> Robert,
>
> I think you're mixing some of the points together.
>
> On Wed, Apr 07, 2021 at 12:29:21PM +0200, Robert Raszuk wrote:
> > I have a question on how practical this proposal is.
> >
> > Fundamental problem with today's BGP capabilities is that the information
> > is only known to the peer.
> >
> > So if I inject flowspec rule from behind the RR the RR will suppress some
> > updates but:
> >
> > * sender will have no clue about it
> > * any other flow spec BGP speaker which supports request filtering down
> the
> > BGP path will never get the chance to receive and apply the filter.
>
> This is explicitly acknowledged in section 5.
>
> It's also indistinguishable from policy.
>
> > Both are IMHO bad. The latter is in fact directly against flowspec spirit
> > to apply filtering as close to the src even if hops on the way are not
> > capable of doing so.
> >
> > So I am yet to be convinced this proposal is useful.
> >
> > Today as a general rule if a router does not support an extension
> received
> > via flowspec it just does not apply it but still can happily propagate
> the
> > update down the road.
>
> Not a single BGP flowspec implementation implemented the "opaque" property
> in RFC 5575.  Not one.  And it was the strong motivation to remove that
> text
> in RFC 8955.
>
> This may change in flowspec v2 where we likely will make the NLRI proper
> type-length-value rather than implied length as it is currently done.
>
> How well the argument to filter unsupported components stands once we're to
> something like flowspec v2 will be the longer question.  For such
> scenarios,
> once we're no longer concerned about propagation characteristics of the
> NLRI, it's quite reasoanble for a route reflector to carry NLRI with
> filtering components it doesn't understand - but edge devices may not want
> it.  But in that scenario, perhaps it's simply better for edge devices to
> accept it and simply not install it.
>
> > I think what we have here on the table is an illustration about the
> growing
> > need for domain wide (or set of domains under the same admin) capability
> > distribution such that all BGP speakers could advertise their
> > capabilities to interested parties. A bit broader than flowspec, but
> could
> > be useful here.
>
> At the day job, we talk about the "flooding domain" of new features that
> are
> gated on their capabilities.  BGP doesn't provide an explicit concept for
> this, but it's become a protocol intrinsic behavior.  Unless you configure
> a
> capability between two devices, it does't gain the ability to use the
> feature.  A contiguous set of devices using those capabilities becomes that
> domain.  That domain may, or may not, have strong overlap with one or more
> ASes under the control of one or more parties.
>
> For many BGP features, knowing what those domain boundaries are isn't much
> of a problem.  Flowspec implementations with disjoint capabilities is a
> place where it could be problematic.  (Again, see section 5.)
>
> ---
>
> I don't believe we're likely to come up with a simple answer to BGP
> capability domains soon.  That said, operators in a single administrative
> domain at least can figure this out themselves because they're the ones
> configuring it.
>
> Right now, we are unable to safely deploy new flowspec features. Even when
> you have disjoint flooding domains, if your flowspec rules are independent,
> you can gain benefit.  So, short term for flowspec v1, I think there's
> benefit for this feature.
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!BhdT!zKnvUXaBTauH415pLQgguhjbJ69dkTpI04OgwY3aoSSiPV4IGBB2u-MqG68$
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>