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 <rob...@raszuk.net> 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
