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) <jheitz@cisco.com>
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 <idr-bounces@ietf.org> *On Behalf Of * Robert Raszuk
> *Sent:* Tuesday, June 22, 2021 11:25 AM
> *To:* Jeffrey Haas <jhaas@pfrc.org>
> *Cc:* idr@ietf.org; draft-haas-flowspec-capability-bits@ietf.org
> *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 <jhaas@pfrc.org> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>