Hi,
On Fri, Nov 06, 2015 at 07:16:17AM -0500, Rick Casarez wrote:
> 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?
BCPs for operators exist (RFC7454 for a start).
Implementations need to change, to "fail safe" - if not configured to do
so, neither accept nor send BGP prefixes on eBGP sessions.
[..]
> 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?
If this is what it takes, updating 4271 sounds like a plan.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
