Re: [GROW] Terry Manderson's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

Job Snijders wrote: > Maybe I am misunderstanding the intention of your proposed change - can > you elaborate? Are you sure that the problem case you describe isn't > already covered by the existing text? The intention is to document that if there is an existing policy to filter at max prefix

Re: [GROW] Terry Manderson's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

heasley wrote: > Sat, Aug 13, 2016 at 01:18:20PM +0100, Nick Hilliard: >> The second adds a note to say that both the receiving and the sending >> party should explicitly filter out more-specifics unless they're tagged >> with BLACKHOLE. I would be in favour of seeing this noted in the >>

Re: [GROW] I-D Action: draft-ietf-grow-bgp-reject-00.txt

> On Aug 13, 2016, at 1:53 PM, Gert Doering wrote: > > "Neither send nor receive prefixes" or "not bring up the session at all" > are workable alternatives from an operational PoV. I’m ok with implementors doing what XR does by default without "unsafe-ebgp-policy” set.

Re: [GROW] I-D Action: draft-ietf-grow-bgp-reject-00.txt

Hi, On Sat, Aug 13, 2016 at 06:34:12PM +0200, Job Snijders wrote: > On Tue, Feb 16, 2016 at 04:52:35PM -0500, Matthew Ringel wrote: > > The solution for BGP-sans-policy rejection shouldn't fail silently. > > > > It would be useful to add a requirement indicating that the software must > >

Re: [GROW] Terry Manderson's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

On Sat, Aug 13, 2016 at 01:18:20PM +0100, Nick Hilliard wrote: > Job Snijders wrote: > > Nick understands the intent of the draft very well: honoring this > > community is optional and usually (but not always) part of a commercial > > supplier-customer agreement. > > > > We changed the text to

Re: [GROW] Terry Manderson's Discuss on draft-ietf-grow-blackholing-02: (with DISCUSS and COMMENT)

Job Snijders wrote: > Nick understands the intent of the draft very well: honoring this > community is optional and usually (but not always) part of a commercial > supplier-customer agreement. > > We changed the text to the following: > >""" BGP speakers in a bilateral peering relationship