> On Apr 18, 2018, at 7:50 AM, Jeff Haas <jh...@juniper.net> wrote: > > It should be noted that my contribution isn't intended to say "Juniper can > support this out the door". Rather, the intent is to start discussion of the > framework that addresses the problem space in a way that's more complete. > With that done, FIBs that don't have the necessary properties to do the work > that eventually comes from this or related documents can eventually be > deployed. > > Now is better obviously. But right now, base BCP 38 (as you note) lives off > of useful hacks. :-)
I’ll read through and provide feedback to the document. There are sections where are erroneous. For example, Loose mode was never ever designed for SAV. People keep putting a share peg in a round hole. Loose mode is a DOS response tool. Another example is the absence of VRF mode. That mode does work with SAV on the downstream (towards the customer) and upstream (on the peering edge). Then you have this statement "It is well known that this method has limitations when networks are multi-homed and there is asymmetric routing of packets.” That is false. BCP84 is wrong. uRPF has been deployed with multi-homed downstream customers. It work _if_ you configure it correctly (i.e. use BGP Weights). But still, the core of this has to get into code capable modes on ASICs, FPGA, & NPs. Feasible path is not something that can be done easily on other vendor implementations (been there - tried that). A working group adoption where the WG takes on the task of pulling multiple vendor microcoders to ensure what is done is _codeable_ and _deployable_ would be a reason for working group adoption. Barry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
