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

["Jakob Heitz (jheitz)" <[e-mail]>]

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 <[e-mail]>
Sent: Tuesday, June 22, 2021 1:57 PM
To: Jakob Heitz (jheitz) <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Idr] Question about draft-haas-flowspec-capability-bits-02


Still no need for per type capability bits ...

> but nowhere does it say it can prohibit development.
> 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) <[e-mail]<mailto:[e-mail]>> wrote:
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Robert Raszuk
Sent: Tuesday, June 22, 2021 11:25 AM
To: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
Linda,

On Tue, Jun 22, 2021 at 02:15:24PM +0000, Linda Dunbar wrote:
> 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.

> 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?

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

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