Re: [bess] [GROW] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

[joel jaeggli]

On 5/6/17 10:53 AM, Warren Kumari wrote:
> [ + 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 think this statement elides that the largest impact here is on
operators, which might be participants of either working group but are
by in large not at the ietf.

As an operator the ability to make recommendations based on practice
that has proven to be problematic is ought to be something others in the
ietf would be interested in. e.g. default accept policies have been
shooting operators in the foot with v4 and v6 unicast AFI's since
literally the dawn of time.

> 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
>>
>>
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
___
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

[Warren Kumari]

[ + 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

Re: [bess] Point #3 on draft-ietf-grow-bgp-reject

[Robert Raszuk]

Sorry one typo:

s/to make all receive routes ineligible for best path/to make all receive
routes eligible for best path/

Apologies,
r.


On Sat, May 6, 2017 at 7:10 PM, Robert Raszuk  wrote:

> Dear IDR and BESS WGs members,
>
> As you have either participated or seen from other email exchanges there
> is ongoing communication about change in eBGP specification to mandate by
> default use of policy in order to make all receive routes ineligible for
> best path and to suppress sending them to your peers. And that in spite of
> different opinions of the authors itself at this point is to apply to all
> existing and future AFI/SAFIs.
>
> John S. summarized this point as stated below:
>
>
>
>
> *"3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to
> apply only to Internet routing and not other applications?Pro: the
> motivation section of the document calls out the Internet use caseCon:
> there's no clear, unambiguous way to actually specify this (AFI/SAFI 1/1
> can be used in a VPN context, e.g.). different defaults for different
> AFI/SAFI is confusing for the user and the extra complexity not required."*
>
> So first let me observe that technically it is very clear to know that
> under vrf in a VPN context (towards CEs or inter-as ASBR in option A)
> address family ipv4 or ipv6 unicast is configured. There is no disambiguity
> of it of any sort. Likewise it is also very clear when address family vpnv4
> or vpnv6 is configured over eBGP Inter-AS option B or C sessions.
>
> During IDR discussion 4 individual contributors where opposed to make this
> proposal applicable to any eBGP AFI/SAFI and recommended to make it only
> for IPv4 and IPv6 existing address families. While in the same time only
> voice of 1 with reference to past discussion in GROW WG had taken place
> expressed otherwise. Well this reference to GROW list in 2016 results in
> one voice against, one pro and author concluding that this is pro all AFs.
>
> I think on that point if there is rough consensus at all it is really
> against that.
>
> Now why I am bringing this specific point up ...
>
> * There are numerous SAFIs in use today that even authors of this proposal
> fail to produce any valid in or out policy other then "send all/accept
> all". So even with good will operator will be simply forced to add those
> lines to the configuration. Now fun starts when an implementation code does
> not allow for it in some specific AFI/SAFIs or that manual policy would
> overwrite RTC or ORF based for L2VPN or L3VPN. That effectively means that
> to be complaint to this proposal implementations must change.
>
> * This draft is to update RFC4271 that means that now any newly defined
> AFI/SAFI will also have to define a set of policies to be used to enable it
> over eBGP sessions both in the draft/rfc and in the code. That clearly
> makes it harder for everyone with no gain.
>
> * There are address families today which are opaque to best path and are
> applied when received .. examples BGP-LS or Flow-spec. At most best path is
> run only when sending it out (if at all). The current spec does not limit
> reception of the information but does limit its eligibility for best path
> computation. I think there is room for large number of surprising
> behaviors with that for those SAFIs which carry opaque information to core
> BGP.
>
> * As the spec (as it is written today) applies to all eBGP sessions what
> happens if BGP UPDATE message contains in new SAFI no MP_REACH attribute at
> all and does not carry "routes" ? Would it be explicitly allowed ?
> (Example: draft-ietf-idr-operational-message-00).
>
> *  As the spec (as it is written today) applies to all "routes" received
> or to be sent over eBGP sessions it actually fails to define what is a
> "route" Within MP_REACH we have a concept of NLRI which for different
> address families have been redefined and departed long time back from pure
> definition of ip route.
>
> * If BGP UPDATE message carries only MP_UNREACH attribute .. so
> effectively routes to be withdrawn .. are those still subject to proposed
> policy or not ?
>
>
> Therefor I would like to ask members of both working groups to express
> clear opinion if this proposal and update to RFC4271 specification should
> apply only IPv4 and IPv6 unicast (AFI/SAFI 1/1 & 2/1) or should be extended
> to all AFI/SAFIs we have today and we are going to invent in the future.
>
> If the majority of WG members would choose to have this change applicable
> to all AFI/SAFIs I do ask authors to address in the document all of the
> above points before proceeding forward.
>
> Kind regards,
> Robert.
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Point #3 on draft-ietf-grow-bgp-reject

[Robert Raszuk]

Dear IDR and BESS WGs members,

As you have either participated or seen from other email exchanges there is
ongoing communication about change in eBGP specification to mandate by
default use of policy in order to make all receive routes ineligible for
best path and to suppress sending them to your peers. And that in spite of
different opinions of the authors itself at this point is to apply to all
existing and future AFI/SAFIs.

John S. summarized this point as stated below:




*"3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to
apply only to Internet routing and not other applications?Pro: the
motivation section of the document calls out the Internet use caseCon:
there's no clear, unambiguous way to actually specify this (AFI/SAFI 1/1
can be used in a VPN context, e.g.). different defaults for different
AFI/SAFI is confusing for the user and the extra complexity not required."*

So first let me observe that technically it is very clear to know that
under vrf in a VPN context (towards CEs or inter-as ASBR in option A)
address family ipv4 or ipv6 unicast is configured. There is no disambiguity
of it of any sort. Likewise it is also very clear when address family vpnv4
or vpnv6 is configured over eBGP Inter-AS option B or C sessions.

During IDR discussion 4 individual contributors where opposed to make this
proposal applicable to any eBGP AFI/SAFI and recommended to make it only
for IPv4 and IPv6 existing address families. While in the same time only
voice of 1 with reference to past discussion in GROW WG had taken place
expressed otherwise. Well this reference to GROW list in 2016 results in
one voice against, one pro and author concluding that this is pro all AFs.

I think on that point if there is rough consensus at all it is really
against that.

Now why I am bringing this specific point up ...

* There are numerous SAFIs in use today that even authors of this proposal
fail to produce any valid in or out policy other then "send all/accept
all". So even with good will operator will be simply forced to add those
lines to the configuration. Now fun starts when an implementation code does
not allow for it in some specific AFI/SAFIs or that manual policy would
overwrite RTC or ORF based for L2VPN or L3VPN. That effectively means that
to be complaint to this proposal implementations must change.

* This draft is to update RFC4271 that means that now any newly defined
AFI/SAFI will also have to define a set of policies to be used to enable it
over eBGP sessions both in the draft/rfc and in the code. That clearly
makes it harder for everyone with no gain.

* There are address families today which are opaque to best path and are
applied when received .. examples BGP-LS or Flow-spec. At most best path is
run only when sending it out (if at all). The current spec does not limit
reception of the information but does limit its eligibility for best path
computation. I think there is room for large number of surprising
behaviors with that for those SAFIs which carry opaque information to core
BGP.

* As the spec (as it is written today) applies to all eBGP sessions what
happens if BGP UPDATE message contains in new SAFI no MP_REACH attribute at
all and does not carry "routes" ? Would it be explicitly allowed ?
(Example: draft-ietf-idr-operational-message-00).

*  As the spec (as it is written today) applies to all "routes" received or
to be sent over eBGP sessions it actually fails to define what is a "route"
Within MP_REACH we have a concept of NLRI which for different address
families have been redefined and departed long time back from pure
definition of ip route.

* If BGP UPDATE message carries only MP_UNREACH attribute .. so effectively
routes to be withdrawn .. are those still subject to proposed policy or not
?


Therefor I would like to ask members of both working groups to express
clear opinion if this proposal and update to RFC4271 specification should
apply only IPv4 and IPv6 unicast (AFI/SAFI 1/1 & 2/1) or should be extended
to all AFI/SAFIs we have today and we are going to invent in the future.

If the majority of WG members would choose to have this change applicable
to all AFI/SAFIs I do ask authors to address in the document all of the
above points before proceeding forward.

Kind regards,
Robert.
___
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

[Robert Raszuk]

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