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

[Rick Casarez <[e-mail]>]

I am willing to help either way.

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

Experiences not things.

On Fri, Nov 6, 2015 at 7:29 AM, Gert Doering <[e-mail]> wrote:

> 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: [phone]           USt-IdNr.: DE813185279
>