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

[Robert Raszuk <[e-mail]>]

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.