From nobody Thu Apr 8 00:39:09 2021 Return-Path: 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 ; 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 ; 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 ; Thu, 8 Apr 2021 00:38:59 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id d13so2342425lfg.7 for ; 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: In-Reply-To: From: Robert Raszuk Date: Thu, 8 Apr 2021 09:38:45 +0200 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "UTTARO, JAMES" , "idr@ietf. org" Content-Type: multipart/alternative; boundary="000000000000c09bec05bf712377" Archived-At: Subject: Re: [Idr] One Admin Domain X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 07:39:09 -0000 --000000000000c09bec05bf712377 Content-Type: text/plain; charset="UTF-8" > 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) 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 On Behalf Of UTTARO, JAMES > Sent: Wednesday, April 7, 2021 6:43 AM > To: Jeffrey Haas ; Robert Raszuk > Cc: idr@ietf. org ; Susan Hares > 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 On Behalf Of Jeffrey Haas > Sent: Wednesday, April 07, 2021 9:25 AM > To: Robert Raszuk > Cc: idr@ietf. org ; Susan Hares > 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 > --000000000000c09bec05bf712377 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

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

r.


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

That draft looks fine. Was it ever submitted? I can't find it in a sear= ch.

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 <jh= aas@pfrc.org>; Robert Raszuk <robert@raszuk.net>
Cc: idr@ietf. org <idr= @ietf.org>; 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.=C2=A0 That said, operators in a single administrat= ive
domain at least can figure this out themselves because they're the ones=
configuring it"

This discussion illustrates that a single administrative domain spanning mu= ltiple ASes should be addressed. Pradosh, John Scudder and I began identify= ing how an OAD ( One Administrative Domain ) should behave in terms of an e= BGP 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.=C2=A0 As operators we have figured out how to create a some= what seamless reachability/forwarding domain upon which services can be ove= rlaid. 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,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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>; 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 info= rmation
> is only known to the peer.
>
> So if I inject flowspec rule from behind the RR the RR will suppress s= ome
> updates but:
>
> * sender will have no clue about it
> * any other flow spec BGP speaker which supports request filtering dow= n 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 spi= rit
> 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 rece= ived
> 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.=C2=A0 Not one.=C2=A0 And it was the strong motivation to remov= e 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'r= e to
something like flowspec v2 will be the longer question.=C2=A0 For such scen= arios,
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 w= ant
it.=C2=A0 But in that scenario, perhaps it's simply better for edge dev= ices to
accept it and simply not install it.

> I think what we have here on the table is an illustration about the gr= owing
> need for domain wide (or set of domains under the same admin) capabili= ty
> distribution such that all BGP speakers could advertise their
> capabilities to interested parties. A bit broader than flowspec, but c= ould
> be useful here.

At the day job, we talk about the "flooding domain" of new featur= es that are
gated on their capabilities.=C2=A0 BGP doesn't provide an explicit conc= ept for
this, but it's become a protocol intrinsic behavior.=C2=A0 Unless you c= onfigure a
capability between two devices, it does't gain the ability to use the feature.=C2=A0 A contiguous set of devices using those capabilities becomes= that
domain.=C2=A0 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 m= uch
of a problem.=C2=A0 Flowspec implementations with disjoint capabilities is = a
place where it could be problematic.=C2=A0 (Again, see section 5.)

---

I don't believe we're likely to come up with a simple answer to BGP=
capability domains soon.=C2=A0 That said, operators in a single administrat= ive
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<= br> you have disjoint flooding domains, if your flowspec rules are independent,=
you can gain benefit.=C2=A0 So, short term for flowspec v1, I think there&#= 39;s
benefit for this feature.

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org
https://urldefense.com/v3/__https://= www.ietf.org/mailman/listinfo/idr__;!!BhdT!zKnvUXaBTauH415pLQgguhjbJ69dkTpI= 04OgwY3aoSSiPV4IGBB2u-MqG68$

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--000000000000c09bec05bf712377--