[Idr] draft-ietf-idr-flowspec-l2vpn-12

[Robert Raszuk <[e-mail]>]

Dear WG,

I would like to highlight the change to IANA registry which is
being discussed here.

So far flowspec 5575 and 5575bis focused on solving one real problem -
mitigation of DDoS attacks which we are all experiencing daily with
different strength.

With that SAFI 133 and 134 have consistently defined types to describe L3
packets match criteria.

I do not understand why now we are to take SAFI 134 and load 13 new types
on it to define completely irrelevant to FlowSpec original goal L2 packet
match criteria.

Yes implementation may use AFI 25 and SAFI 134 to distinguish it from AFI 1
or 2 and SAFI 134, but it is introducing pure mess and architecturally it
is just ugly.

Moreover the draft in question while defining the protocol extension fails
to identify even a single valid use case for it. L2 VPNs are usually
private and I am not sure about others but I never seen a L2VPN DDoS other
then BPDUs on LAN's spanning tree. I am sure using BGP to mitigate those
type of attacks is an innovative one.

So clearly this has nothing to do with DDoS mitigation, and this is pure
BGP policy push extension.

The draft also skips over fundamental reason why we have SAFI 134 in the
first place. When we run L3VPNs customer may detect a DDoS and signal with
SAFI 133 to a PE about it then PE carries it within SAFI 134 across all PEs
(modulo RTC) where filters may be installed in proper VPNs or pushed again
with SAFI 133 to remote CEs.

Here in L2VPN what protocol will be used to signal DDoS between PE & CE ?
Email ?

Is BGP really now not only Link State transport,  but also configuration
push and ACL push protocol ? Where is this going ? Just because we have a
TCP session there does it make it good idea to load so much new extensions
on top of it ? Oh I forgot the drafts which BGP as an SDN signalling
protocol :).

I would like to reiterate Acee's question - Do we really need to put into
BGP all possible packet formats to transport filters with it around ?

Even if some will say - sure - please separate this via new extension and
new name leaving original FlowSpec to at least have the chance to do what
it intended to do in the first place.

Kind regards,
Robert