> On Apr 18, 2018, at 7:50 AM, Jeff Haas 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
