Re: [bess] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
Hi!
The way I see it, the change proposed in this document is a change to the base
BGP spec – as such, many/all users of BGP will be affected. I expect bess
participants to also participate in idr – I don’t see the need to extend the
discussion.
Alvaro.
On 5/6/17, 1:53 PM, "Warren Kumari" wrote:
>
>The group of users of BGP which this update impacts the most are members
>of BESS WG (cc-ed) and not IDR WG due to the fact that this proposal applies
>to all AFI/SAFIs.
I'll happily admit that I have not been following BESS at all, and so
know very little of what y'all do ("Hi Bess!"). Alvaro, please advise
if BESS is affected to the level that they should have been explicitly
invited to comment?
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
Re: [bess] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
[ + authors ]
On Sat, May 6, 2017 at 3:16 AM, Robert Raszuk wrote:
> Hi Warren,
>
>> This is clearly not unanimous/ not everyone is happy, but (in my view)
>> there is *rough* consensus for this to progress.
>
>
> The group of users of BGP which this update impacts the most are members
> of BESS WG (cc-ed) and not IDR WG due to the fact that this proposal applies
> to all AFI/SAFIs.
I'll happily admit that I have not been following BESS at all, and so
know very little of what y'all do ("Hi Bess!"). Alvaro, please advise
if BESS is affected to the level that they should have been explicitly
invited to comment?
> IMO before you progress anywhere with this IETF LC BESS WG should express
> their formal opinion on it.
>
> Example of in or out eBGP policy where you are sending MAC addresses in
> EVPN AF needs to be provided and explained why it makes sense. Likewise
> examples of RTC AF for L3VPN Inter-as needs to be discussed.
>
> Otherwise the group of people which defined a lot of non ISP uses of BGP may
> be
> suddenly surprised down the read for keeping them out of the loop and have
> customers loosing reachability upon compliant non sequential router OS
> upgrade.
The authors are busy incorporating some final edits (including some
suggested by Alvaro). I would have hoped that all affected parties
would have seen the discussions on GROW / IDR / the IETF LC.
I ask people to please withhold judgment until the new version is released.
I'm about to board a plane (to Budapest), and will be out of email for
many hours...
W
>
> Cheers,
> Robert.
>
> REF: https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-06
>
>
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
[bess] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
Hi Warren, This is clearly not unanimous/ not everyone is happy, but (in my view) > there is *rough* consensus for this to progress. > The group of users of BGP which this update impacts the most are members of BESS WG (cc-ed) and not IDR WG due to the fact that this proposal applies to all AFI/SAFIs. IMO before you progress anywhere with this IETF LC BESS WG should express their formal opinion on it. Example of in or out eBGP policy where you are sending MAC addresses in EVPN AF needs to be provided and explained why it makes sense. Likewise examples of RTC AF for L3VPN Inter-as needs to be discussed. Otherwise the group of people which defined a lot of non ISP uses of BGP may be suddenly surprised down the read for keeping them out of the loop and have customers loosing reachability upon compliant non sequential router OS upgrade. Cheers, Robert. REF: https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-06 ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
