I'm aware that I'm late to the game here so I am not going to oppose the
LC of this draft, but I would say it's a missed opportunity to not give
clear guidance to users and vendors of SRv6 enabled equipment to put in
two very strong recommendations/requirements:
1. Put your customers in VRFs.
2. Vendor must make sure that packets sent to SIDs on interfaces that are
in a VRF, should not be processed as SRv6 packets.
The whole focus on users implementing filtering to protect the SRv6 domain
is operationally fragile. To me it's surprising this is still the main
recommendation.
For MPLS, there was a knob one enabled on the interface to "enable MPLS
frame processing". Without it, MPLS frames are supposed to be dropped.
SRv6 has, as far as I can tell, no such thing. Instead the operator is
supposed to make sure there are ACLs on each and every interface where
SRv6 packets aren't expected.
I would never ever ever deploy SRv6 without first making sure that all
non-SRv6 interfaces were in a VRF, and verify that the vendor equipment
didn't process SRv6 packets received on a VRF enabled interface.
--
Mikael Abrahamsson email: [email protected]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
