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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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.
>
>