From nobody Thu Apr 15 06:34:39 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 E1FE73A1FF8 for ; Thu, 15 Apr 2021 06:34:37 -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=ham 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 aIKuMm6y7wxL for ; Thu, 15 Apr 2021 06:34:33 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 862E83A1FFE for ; Thu, 15 Apr 2021 06:34:32 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id j18so39297190lfg.5 for ; Thu, 15 Apr 2021 06:34:32 -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=ZnXPPYGQIruhHRPCZKY3R66CNN/NOqbxqlGInFNIL8A=; b=AqFlK4bawCjeOjWtUl4bvCyVUlm/JWaiQTEthSvlkZSRTGTWGcYRp6/rso15DrdZsp QpYYlh7uV2Q4SN/HPwAtlmumZyguO0MpKJm0ih5K5BlcCyFKglPIf6Nu/QnFZAL5AW3x fwD7oO9QydyGG4WOAu0+MpyxIY+Nls0WgeWPVN4BmveL+pzNpl5ssFhZYm63tQLpvKRn jVU7FDJwnKd9QkGCULTLZB22YjxXpPdtP6siExz8AeBq6bQ3Bl7QFn+8eXalZYr+myvI 93X6r0dMxhafn62UhN2OQveVlOG6/yWH8W5cud7uBciO0M7uqs7D2PeLZ7e1q3g1sxWT HA1Q== 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=ZnXPPYGQIruhHRPCZKY3R66CNN/NOqbxqlGInFNIL8A=; b=r17reguRgqncfOpG8gbayAeQCnhz9c2IA5yx0pqZPiF7gwtw3ckbYL7CdaUUQ0Cajy c/0VekGlkkwrqiuxkWnAIWYwvmW0rCB/8qVjjTTBGkFrSMlSLZ0zPw1zY+CaJzWOYedM WY51qmpc9Yrjys2QPplhWQNXfCHnikopuTzQg0bYTc/9P99gh2shNlxSiMXKikulJRl3 tktTlMH7ru/Ej8OCqS+zwiXnykfhXfF3dtePoch5nXxTJ3N2YUJllxFiRG8LI3UvBvaP O/vBFhhlB9Ygea+pXS0qZamRszBj+QTCn4a+hDRkpTQaiw5sr06aAp+yDqXuCIAsghWt 4GVQ== X-Gm-Message-State: AOAM533qhaIylN8zTbRTyJB8TCJ1QQTXvU29NnIm5euaOQYNnpIh6awX NVuqgociCtMc2NplecQPgoxYAyHIVTsqp+unIekL+A== X-Google-Smtp-Source: ABdhPJxE1O7dnC0NOl4u/x9cAgQv+sHr3wkqick9kp8rr/CawtD+344t8+yJaoGZCsq/xkF/HM/1JqX7egOrFtDaZy4= X-Received: by 2002:ac2:593c:: with SMTP id v28mr2600964lfi.581.1618493669675; Thu, 15 Apr 2021 06:34:29 -0700 (PDT) MIME-Version: 1.0 References: <20210409201047.GA13742@pfrc.org> <4d862ff450b349e6bcdaf96bd4d09b99@huawei.com> <20210412175120.GA25856@pfrc.org> <8ab2391b8a8647d2a8319c71a140ccd5@huawei.com> <20210415004310.GA6652@pfrc.org> <37ECDC72-A91F-4E26-9FCC-D95BBCE9A65D@cisco.com> In-Reply-To: <37ECDC72-A91F-4E26-9FCC-D95BBCE9A65D@cisco.com> From: Robert Raszuk Date: Thu, 15 Apr 2021 15:34:18 +0200 Message-ID: To: "Jakob Heitz (jheitz)" Cc: Jeffrey Haas , "Dongjie (Jimmy)" , "idr@ietf.org" Content-Type: multipart/alternative; boundary="00000000000040a2e405c002ec00" Archived-At: Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-flowspec-capability-bits-02.txt] 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, 15 Apr 2021 13:34:38 -0000 --00000000000040a2e405c002ec00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jakob, Pls see my last msg. It is not about originator assurance that something got installed. It is about operator basic understanding on what is going on in his network from BGP distribution point of view. Also pls observe that capabilities today require session reset. Dynamic capabilities is not there. So if I enable some filtering type on PE I need to reset my session to RR. If more SAFIs travel over this session this will get pretty ugly. Perhaps we should instead define FlowSpec ORF and single new capability "Wait for FS-ORF". FS ORF would signal to peer what types it supports. Simple, easy and non disruptive with pretty much the same end effect. Cheers, R. On Thu, Apr 15, 2021 at 3:24 PM Jakob Heitz (jheitz) wrote: > > > Regards, > Jakob. > > > On Apr 15, 2021, at 2:43 AM, Robert Raszuk wrote: > > =EF=BB=BF > All, > > Yes what Jakob and now Jeff are saying makes sense. If we are to introduc= e > this capability it should be only about what BGP peer understands as part > of the NLRI. Nothing to do with data plane and filtering. Just observe th= at > even if data plane supports it and even of operator enables it filter may > still fail to get installed due to no space. So we never know at BGP leve= l > what got installed and what not. > > > That's being just a little over dramatic. It's the case with all BGP. For > any use case where it really matters and the originator must know exactly > when and where its originated NLRI got installed, we don't use BGP. > > > Now - I am still seriously concerned to add this to v1. Well unless we > also add the notion of optional types. That means that when setting up a > filter (manually or programmatically) types have an "Optional" flag - whi= ch > means that if a peer does not support this type it is ok to drop it and > sent all remaining types in NLRI instead of not sending the entire NLRI a= t > all. > > That would provide some tools to make sure that v1 deployments are intact= . > > Thx, > R. > > > > > > On Thu, Apr 15, 2021 at 5:37 AM Jakob Heitz (jheitz) 40cisco.com@dmarc.ietf.org> wrote: > >> I agree. >> The capability is exchanged only with neighbors and thus is >> not capable of informing the capabilities of all BGP speakers >> in the network. A more capable network management method >> is needed for that. >> >> The BGP capability is only useful to avoid sending a flowspec >> to a neighbor that it would consider as malformed. >> >> Regards, >> Jakob. >> >> -----Original Message----- >> From: Idr On Behalf Of Jeffrey Haas >> Sent: Wednesday, April 14, 2021 5:43 PM >> To: Dongjie (Jimmy) >> Cc: idr@ietf.org >> Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: >> draft-haas-flowspec-capability-bits-02.txt] >> >> Jie, >> >> On Wed, Apr 14, 2021 at 03:21:54PM +0000, Dongjie (Jimmy) wrote: >> > > On Mon, Apr 12, 2021 at 05:04:32PM +0000, Dongjie (Jimmy) wrote: >> > > > Hi Jeff, all, >> > > > >> > > > I've read the recent discussion and the updated version of this >> draft, here are >> > > some thoughts and comments: >> > > > >> > > > I fully agree that incremental deployment of new flowspec >> components is >> > > important, and it does not need to wait for Flowspec 2.0. >> > > > >> > > > Regarding a BGP flowspec component, there could be three different >> > > capabilities: >> > > > >> > > > 1. The capability of parsing and implementing the component >> as a filter >> > > > >> > > > 2. The capability of parsing and propagating the component, >> but not for >> > > local use >> > > > >> > > > 3. The capability of propagating the component further even >> it is not parsed >> > > > >> > > > The first two capabilities are discussed in this thread and the >> updated draft, >> > > and to me it makes sense to distinguish these two capabilities. >> > > >> > > Operationally, how would you expect a BGP Speaker to differentiate >> these two >> > > cases? >> > >> > The assumption here is that not all the nodes are required to implemen= t >> > the filters (or some just don't want to), while they may be on the pat= h >> of >> > the flowspec rule propagation. If this is true, it may be useful for t= he >> > operator to know the set of nodes with the first capability and the se= t >> of >> > nodes with the second capability, although the capability of parsing a= nd >> > propagating is more relevant to this document. These two capabilities >> may >> > be advertised using different mechanisms, as the first capability may = be >> > needed by nodes not directly peered. >> >> Understood. My question is what should a BGP Speaker that has been told >> that the adjacent BGP Speaker can parse a certain set of Flowspec >> components >> but not use some of them do about it? Is it strictly advisory? >> >> If it's strictly advisory, I would advocate that we not worry about >> publishing that part in BGP. One motivation is that capability space is >> still at somewhat of a premium without extended optional parameters. >> >> A second motivation is there may be better mechanisms to publish the >> network >> wide capabilities for using the filters. I'll likely share a proposal i= n >> the upcoming weeks. >> >> > > The third case is unfortunately problematic right now. Deployment >> > > experience has shown implementations aren't willing to deal with ful= ly >> > > "opaque" NLRI. We've had a number of outages resulting from parsing >> bugs >> > > as it is. >> > >> > I understand the problems with the "opaque" NLRI, while if the rule >> > specified in the NLRI is not required (or not capable) to be implement= ed >> > in data plane on a transit node, will it cause less harm to the >> network? >> >> My draft tries to make clear that any device that filters a rule, either >> because it doesn't receive it because of lack of capability of an upstre= am >> node, or lack of local ability, can have potential to result in >> mis-forwarding. Whether it does so or not will depend on the independen= ce >> of the rules. >> >> If my use of "independence" is unclear, I'll share an example next round= . >> >> > > With flowspec v2, the primary obstacle toward opaque but still able >> to be >> > > checked for NLRI high level syntactic correctness can be done. We >> know this >> > > is still problematic once you hit a node where the inner contents ar= e >> validated >> > > and found to be problematic, but at least in this case "treat as >> withdraw" >> > > procedures are capable of being done. >> > >> > Agree flowspec v2 can help with the syntax validation to some extent. >> > While if the NLRI is considered malformed, the "treat as withdraw" err= or >> > handling may not always work. >> >> I think lengths in structured BGP NLRI will likely give us a hybrid >> situation. >> >> Consider an NLRI that has a known prefix length. >> Consider that it has components that have individual sub-lengths that ar= e >> clear in the protocol. >> >> It is possible that the length of the individual components summed >> together >> are still a valid "length" from the top level (the prefix-length) from a >> high level syntactic level, but individual components may be of invalid >> length or syntax. This is similar to the situation for path attributes. >> >> In such a case, the NLRI is malformed, but may be of enough integrity to >> properly handle as an ignore/discard. >> >> The BGP-CAR proposal and perhaps some of the evpn NLRI error handling >> cases have >> some similar overlap to this case. (RFC 7606 tries to be too generic >> about >> "typed NLRI" and I think got it somewhat wrong.) >> >> -- Jeff >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > --00000000000040a2e405c002ec00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jakob,

Pls see my last msg. It is not a= bout originator assurance that something got installed. It is about operato= r=C2=A0basic understanding on what is going on in his network from BGP dist= ribution=C2=A0point of view.=C2=A0

Also pls observ= e that capabilities=C2=A0today require session reset. Dynamic capabilities = is not there. So if I enable some filtering type on PE I need to reset my s= ession to RR. If more SAFIs travel over this session this will get pretty u= gly.=C2=A0

Perhaps we should instead define FlowSp= ec ORF and single new capability "Wait for FS-ORF". FS ORF would = signal to peer what types it supports. Simple, easy and non disruptive with= pretty much the same end effect.=C2=A0

Cheers,
R.

On Thu, Apr 15, 2021 at 3:24 PM Jakob Heitz (jheitz) &l= t;jheitz@cisco.com> wrote:


Regards,
Jakob.


On Apr 15, 2021, at 2:43 AM, Robert Raszuk <robert@raszuk.net&= gt; wrote:

=EF=BB=BF
All,

Yes what Jakob and now Jeff are saying makes sense. If we are to intro= duce this capability it should be only about what BGP peer understands as p= art of the NLRI. Nothing to do with data plane and filtering. Just observe = that even if data plane supports it and even of operator enables it filter may still fail to get installed = due to no space. So we never know at BGP level what got installed and what = not.=C2=A0

That's being just a little over dramatic. It's the case with all BG= P. For any use case where it really matters and the originator must know ex= actly when and where its originated NLRI got installed, we don't use BG= P.


Now - I am still seriously concerned to add this to v1. Well unless we= also add the notion of optional types. That means that when setting up a f= ilter (manually or programmatically) types have an "Optional" fla= g - which means that if a peer does not support this type it is ok to drop it and sent all remaining types in NLRI instead= of not sending the entire NLRI at all.=C2=A0

That would provide some tools to make sure that v1 deployments are int= act.=C2=A0

Thx,
R.





On Thu, Apr 15, 2021 at 5:37 AM Jakob= Heitz (jheitz) <jheitz=3D40cisco.com@dmarc.ietf.org> wrote:
I agree.
The capability is exchanged only with neighbors and thus is
not capable of informing the capabilities of all BGP speakers
in the network. A more capable network management method
is needed for that.

The BGP capability is only useful to avoid sending a flowspec
to a neighbor that it would consider as malformed.

Regards,
Jakob.

-----Original Message-----
From: Idr <idr= -bounces@ietf.org> On Behalf Of Jeffrey Haas
Sent: Wednesday, April 14, 2021 5:43 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com>
Cc: idr@ietf.org
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-flowspec-capabi= lity-bits-02.txt]

Jie,

On Wed, Apr 14, 2021 at 03:21:54PM +0000, Dongjie (Jimmy) wrote:
> > On Mon, Apr 12, 2021 at 05:04:32PM +0000, Dongjie (Jimmy) wrote:<= br> > > > Hi Jeff, all,
> > >
> > > I've read the recent discussion and the updated version = of this draft, here are
> > some thoughts and comments:
> > >
> > > I fully agree that incremental deployment of new flowspec co= mponents is
> > important, and it does not need to wait for Flowspec 2.0.
> > >
> > > Regarding a BGP flowspec component, there could be three dif= ferent
> > capabilities:
> > >
> > > 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0 The capability of parsing and = implementing the component as a filter
> > >
> > > 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0 The capability of parsing and = propagating the component, but not for
> > local use
> > >
> > > 3.=C2=A0 =C2=A0 =C2=A0 =C2=A0 The capability of propagating = the component further even it is not parsed
> > >
> > > The first two capabilities are discussed in this thread and = the updated draft,
> > and to me it makes sense to distinguish these two capabilities. > >
> > Operationally, how would you expect a BGP Speaker to differentiat= e these two
> > cases?
>
> The assumption here is that not all the nodes are required to implemen= t
> the filters (or some just don't want to), while they may be on the= path of
> the flowspec rule propagation. If this is true, it may be useful for t= he
> operator to know the set of nodes with the first capability and the se= t of
> nodes with the second capability, although the capability of parsing a= nd
> propagating is more relevant to this document. These two capabilities = may
> be advertised using different mechanisms, as the first capability may = be
> needed by nodes not directly peered.

Understood.=C2=A0 My question is what should a BGP Speaker that has been to= ld
that the adjacent BGP Speaker can parse a certain set of Flowspec component= s
but not use some of them do about it?=C2=A0 Is it strictly advisory?

If it's strictly advisory, I would advocate that we not worry about
publishing that part in BGP.=C2=A0 One motivation is that capability space = is
still at somewhat of a premium without extended optional parameters.

A second motivation is there may be better mechanisms to publish the networ= k
wide capabilities for using the filters.=C2=A0 I'll likely share a prop= osal in
the upcoming weeks.

> > The third case is unfortunately problematic right now.=C2=A0 Depl= oyment
> > experience has shown implementations aren't willing to deal w= ith fully
> > "opaque" NLRI.=C2=A0 We've had a number of outages = resulting from parsing bugs
> > as it is.
>
> I understand the problems with the "opaque" NLRI, while if t= he rule
> specified in the NLRI is not required (or not capable) to be implement= ed
> in data plane on a transit node, will it cause less harm to the networ= k?

My draft tries to make clear that any device that filters a rule, either because it doesn't receive it because of lack of capability of an upstr= eam
node, or lack of local ability, can have potential to result in
mis-forwarding.=C2=A0 Whether it does so or not will depend on the independ= ence
of the rules.

If my use of "independence" is unclear, I'll share an example= next round.

> > With flowspec v2, the primary obstacle toward opaque but still ab= le to be
> > checked for NLRI high level syntactic correctness can be done.=C2= =A0 We know this
> > is still problematic once you hit a node where the inner contents= are validated
> > and found to be problematic, but at least in this case "trea= t as withdraw"
> > procedures are capable of being done.
>
> Agree flowspec v2 can help with the syntax validation to some extent.<= br> > While if the NLRI is considered malformed, the "treat as withdraw= " error
> handling may not always work.

I think lengths in structured BGP NLRI will likely give us a hybrid
situation.=C2=A0

Consider an NLRI that has a known prefix length.
Consider that it has components that have individual sub-lengths that are clear in the protocol.

It is possible that the length of the individual components summed together=
are still a valid "length" from the top level (the prefix-length)= from a
high level syntactic level, but individual components may be of invalid
length or syntax.=C2=A0 This is similar to the situation for path attribute= s.

In such a case, the NLRI is malformed, but may be of enough integrity to properly handle as an ignore/discard.

The BGP-CAR proposal and perhaps some of the evpn NLRI error handling cases= have
some similar overlap to this case.=C2=A0 (RFC 7606 tries to be too generic = about
"typed NLRI" and I think got it somewhat wrong.)

-- Jeff

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

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