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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/idr >> > > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
