Re: [Idr] [GROW] draft-mauch-bgp-reject

[Rick Casarez <[e-mail]>]

This is interesting since it is definitely a best common practice for
operators to do points 1 and 3 on your list. Is the intention of this
document to enforce a BCP by allowing operators to point to a draft/RFC or
did you want to change how BGP works?

If you just want to document a BCP in draft form (eventually RFC) to use it
as a mechanism to force vendors to change their BGP code/daemons it might
work. Some vendors will have no issue conforming or adding it to their road
map. Although most can point to the fact it is really just a BCP draft and
ignore it unless there is a big surge in demand for conformance from their
customers. After all we all know some vendors who do not conform to RFCs.

If you want to change how BGP is implemented, and be able to more
forcefully push this change to vendors, then Robert is correct and 4271
would need to be updated.

So I guess I would ask you: which way did you want to go?

>>Software MUST provide protection from internal failures preventing the
advertisement and acceptance of routes
>"Vendor software will actually fail-open and not honor the configured
policy.  I’d like to try and capture this case as implementation guidance
to prevent damage to the global internet."

So let me ensure I understand this correctly. The point of this draft is to
protect the internet at large by ensuring policies are always in place. So
what you are saying is vendors should never fail-open correct?

-------------------
Cheers, Rick

Experiences not things.

On Thu, Nov 5, 2015 at 4:38 AM, Robert Raszuk <[e-mail]> wrote:

> Hi Jared,
>
> ​If you are up to fail-open on restart (I guess this is what you mean by
> "internal-failures") and in fact in general regarding your entire draft IMO
> the only way to really enforce anything of that scope is to update 4271
> with the new eBGP rules and state machine.
>
> Otherwise I do not believe that BCP will  be out of the sudden honored by
> vendors. Also I do not think it will be justified to be accept globally as
> an OS upgrade without such strong enforcement.
>
> Thx,
> r.
>
>
>
>> > There is one item I don't understand here:
>> >
>> >   o  Software MUST provide protection from internal failures preventing
>> >      the advertisement and acceptance of routes
>> >
>> > what does that mean (in other words "more verbose explanation, please")?
>>
>> Vendor software will actually fail-open and not honor the configured
>> policy.  I’d like to try and capture this case as implementation guidance
>> to prevent damage to the global internet.
>>
>> - Jared
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
>
> _______________________________________________
> GROW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow
>
>