Subject: [Idr] Question about draft-haas-flowspec-capability-bits-02

From: Linda Dunbar <[email-masked]>
Date: Mon, 21 Jun 2021 20:39:14 +0000

Jeff,

Section 2 of the draft-haas-flowspec-capability-bits-02 shows the example of 13 bits representing the capacity.
When the Nth bit is set to 1, does it represent Type N component is supported?

What if more types are proposed later? RFC8956 has Type 14-255 as reserved. I'd assume future drafts can propose more types. Does it mean the Capability value has to be expanded to 255 bits?

A nit: the second paragraph of the Section 1 says that "The components are documented in the Section 3 of RFC8955". But the components are actually specified in the Section 4. Do I miss something?

Thank you
Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 21 Jun 2021 20:51:41 +0000

Jeff,

One more question:
Page 3 first paragraph says that "this is due to the lack of a mandatory length element for the components in the NLRI".

But Section 4.2.1.2 of the RFC8555 Figure 3 shows that the Len can be encoded in the bits. Are you talking about a different "length"?

Linda Dunbar
From: Linda Dunbar
Sent: Monday, June 21, 2021 3:39 PM
To: [email-masked]; [email-masked]
Subject: Question about draft-haas-flowspec-capability-bits-02

Jeff,

Thank you
Linda Dunbar

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Jun 2021 08:34:53 -0400

Linda,

> When the Nth bit is set to 1, does it represent Type N component is supported?

Correct.

> What if more types are proposed later? RFC8956 has Type 14-255 as reserved. I'd assume future drafts can propose more types. Does it mean the Capability value has to be expanded to 255 bits?

It means the protocol needs a serious rewrite.

The component types 14-255 are reserved, but that was partially because
there was no way to incrementally deploy new features.  Addressing that
potentially before a flowspec v2 protocol was a motivation for this draft.

> A nit: the second paragraph of the Section 1 says that "The components are documented in the Section 3 of RFC8955". But the components are actually specified in the Section 4. Do I miss something?

Thanks for bringing that to my attention.  That's a lingering issue from
changing from RFC 5575 where it was in section 3.  If I update the draft
I'll correct it next round.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Jun 2021 08:38:28 -0400

Linda,

> But Section 4.2.1.2 of the RFC8555 Figure 3 shows that the Len can be encoded in the bits. Are you talking about a different "length"?

If you observe the various forms of "length" in RFC 8955 section 4, you'll
see that in some cases it's an explicit one octet length (prefixes) mixed
with numeric op or bitmask op.  The latter two forms provide for a variable
length component type with variable width values.

If I introduce a component 14, how do I know what scheme it uses for length
calculations?  

The implementation must KNOW by the spec.  It is not carried in the
protocol consistently.  That is the problem.

-- Jeff

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 22 Jun 2021 14:15:24 +0000

Jeff, 

Based on the TYPE, the receiver can get the "length" field properly. Why it is a problem? 
Type 1 and Type 2 have Length Field. For the Types using "Numeric Operator" or "Bitmask Operator", there is "Length" field as well. 

If I introduce a new type, Type 14, can I just use the format as Type 1 or Type 2? 

Linda

-----Original Message-----
From: Jeffrey Haas <[email-masked]> 
Sent: Tuesday, June 22, 2021 7:38 AM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Question about draft-haas-flowspec-capability-bits-02

Linda,

> But Section 4.2.1.2 of the RFC8555 Figure 3 shows that the Len can be encoded in the bits. Are you talking about a different "length"?

If you observe the various forms of "length" in RFC 8955 section 4, you'll see that in some cases it's an explicit one octet length (prefixes) mixed with numeric op or bitmask op.  The latter two forms provide for a variable length component type with variable width values.

If I introduce a component 14, how do I know what scheme it uses for length calculations?  

The implementation must KNOW by the spec.  It is not carried in the protocol consistently.  That is the problem.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Jun 2021 14:36:54 -0400

Linda,

> Based on the TYPE, the receiver can get the "length" field properly. Why it is a problem? 

Because for a new component type, you don't know where length is for that
type, nor how long.

> If I introduce a new type, Type 14, can I just use the format as Type 1 or Type 2? 

We can do anything we like as long as we have rules for it.  Right now,
flowspec doesn't have consistent rules among the types.  We have two styles.

If this were a normal TLV protocol, length wouldn't be arbitrarily
specified.  That's one of the motivations for flowspec v2.  And, similarly,
it's what PCEP decided to do when it leveraged flowspec encodings.

The capability bits proposal attempts the middle road: An implementation
must KNOW the rule for a component type.  This lets two implementations
disclose to each other what types they understand.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Jun 2021 20:25:16 +0200

Jeff,

Thinking a bit more on this there could be yet another middle road solution
.. not that I would advocate it, but perhaps would not oppose it.

You may send (read spray in classic BGP way) new Type and mandate it as
MUST that for such new Types MP_REACH would carry only single NLRI. Sure
packing is gone but I am yet to see any study proving packing value with
FSv1.

That way you could in fact also not do any capabilities as the entire
operation basis would be to just silently drop what you do not understand.

Is this really bad ... Well if you ack that even understanding by BGP a new
Type does not guarantee at all that this will end up in data plane maybe
dropping it is not a big deal.

And even if we go to FSv2, capabilities only get you and peer to understand
each other. Any crowd behind the peer is still one big unknown in terms of
new Types support.

But please do not take this message as a change to my opinion that all new
work should go to FSv2. It still stands ... This above is sort of a
response to this thread between Linda and yourself.

Many thx,
R.

On Tue, Jun 22, 2021 at 8:11 PM Jeffrey Haas <[email-masked]> wrote:

> > Type 1 and Type 2 have Length Field. For the Types using "Numeric
> Operator" or "Bitmask Operator", there is "Length" field as well.
> >
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 22 Jun 2021 20:50:35 +0000

This behavior would need a capability too.
Else the session dies with malformed update.

That is the entire issue. FS can't be extended without a new capability
else the session dies with malformed update.

Now that we need a capability, I think Jeff's draft hits the sweet spot.

Oh and BTW, I see the IDR charter says:
chartered to standardize,
develop, and support
but nowhere does it say it can prohibit development.
So, prohibiting development of FSv1 is overstepping the charter, IMO.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Tuesday, June 22, 2021 11:25 AM
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Question about draft-haas-flowspec-capability-bits-02

Jeff,

Thinking a bit more on this there could be yet another middle road solution .. not that I would advocate it, but perhaps would not oppose it.

You may send (read spray in classic BGP way) new Type and mandate it as MUST that for such new Types MP_REACH would carry only single NLRI. Sure packing is gone but I am yet to see any study proving packing value with FSv1.

That way you could in fact also not do any capabilities as the entire operation basis would be to just silently drop what you do not understand.

Is this really bad ... Well if you ack that even understanding by BGP a new Type does not guarantee at all that this will end up in data plane maybe dropping it is not a big deal.

And even if we go to FSv2, capabilities only get you and peer to understand each other. Any crowd behind the peer is still one big unknown in terms of new Types support.

But please do not take this message as a change to my opinion that all new work should go to FSv2. It still stands ... This above is sort of a response to this thread between Linda and yourself.

Many thx,
R.

On Tue, Jun 22, 2021 at 8:11 PM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Linda,

-- Jeff

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Jun 2021 22:56:44 +0200

Still no need for per type capability bits ...

> So, prohibiting development of FSv1 is overstepping the charter, IMO.

That is a very interesting interpretation.

"Do no harm to what is working fine" is to me much more important across
entire IETF then any WG charter itself.

Best,
R.

On Tue, Jun 22, 2021 at 10:50 PM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Idr <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Tuesday, June 22, 2021 11:25 AM
> *To:* Jeffrey Haas <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Idr] Question about draft-haas-flowspec-capability-bits-02
>
>
>
> Jeff,
>
>
>
> Thinking a bit more on this there could be yet another middle road
> solution .. not that I would advocate it, but perhaps would not oppose it.
>
>
>
> Is this really bad ... Well if you ack that even understanding by BGP a
> new Type does not guarantee at all that this will end up in data plane
> maybe dropping it is not a big deal.
>
>
>
> And even if we go to FSv2, capabilities only get you and peer to
> understand each other. Any crowd behind the peer is still one big unknown
> in terms of new Types support.
>
>
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 22 Jun 2021 21:03:03 +0000

I hope you're not suggesting that adding capabilities causes harm.
BGP was working fine before https://datatracker.ietf.org/doc/html/rfc2842
And then we improved it.

Regards,
Jakob.

From: Robert Raszuk <[email-masked]>
Sent: Tuesday, June 22, 2021 1:57 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] Question about draft-haas-flowspec-capability-bits-02

"Do no harm to what is working fine" is to me much more important across entire IETF then any WG charter itself.

Best,
R.

On Tue, Jun 22, 2021 at 10:50 PM Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
This behavior would need a capability too.
Else the session dies with malformed update.

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Tuesday, June 22, 2021 11:25 AM
To: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Question about draft-haas-flowspec-capability-bits-02

Jeff,

Many thx,
R.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Jun 2021 23:08:43 +0200

Nope ... nothing to do with capabilities here.

DDoS is a real problem.  FSv1 is a tool to dynamically signal granular
filtering to mitigate it as close to the src as possible.

The moment you trash it with new capabilities (for example to push
configuration by BGP) you are killing its main use case which is DDoS
protection.

That in my books is a harm to a working BGP extension (FSv1).

Best,
R.

On Tue, Jun 22, 2021 at 11:03 PM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Tuesday, June 22, 2021 1:57 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* Jeffrey Haas <[email-masked]>; [email-masked];
> [email-masked]
> *From:* Idr <[email-masked]> *On Behalf Of *Robert Raszuk