On Wed, Mar 31, 2021 at 06:09:42PM -0400, Jeffrey Haas wrote:
> > There is already a separate draft in IDR that has passed WGLC, and it uses
> > a new transitive BGP Path Attribute 'Only to Customer (OTC)':
> > https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15
> > We view that as a longer-term solution, while the EC/LC-based approach is
> > meant to be deployed quickly.
>
> I've been caught napping on the changes in open policy and will have to go
> read this.
If we're talking about 'deploying quickly', something that can be done
on any of the BGP implementations in operation today (capable of
matching a single RFC 1997 BGP community), is to use the NOPEER community.
I really think NOPEER Community [RFC 3765] is suitable as synonymous to
"Only to Customer". It would change the draft from "route leak detection"
into "route leak prevention", but as bgp-open-policy-XX require new code
anyway, this new code might as well use on an existing attribute to
foster incremental deployment.
If future BGP-OPEN compliant BGP speakers end up tagging routes with
NOPEER when received from a "role: peer" BGP neighbor, and automatically
block outbound route announcements towards "role: transit" and "role: peer"
BGP neigbhor sessions, the effect of "Only to Customer" (role: customer)
is achieved.
A confusing aspect in this dialogue:
The meaning of the word 'peer' RFC 3765 is different than the meaning of
the word 'peer' in draft-ietf-idr-bgp-open-policy-15, the latter
document appears to use the word as a description of the positions a
network can have in the 'gao and rexford' model.
When reading draft-ietf-idr-bgp-open-policy-15 keep this mapping in mind:
'role: peer' == RFC 3765 'peer'
'role: provider' == RFC 3765 'peer'
'role: rs' == RFC 3765 'peer'
An implementation which is evaluating whether to export a given best
path to a neighbor which has role ('peer', 'provider', 'rs') as
established through draft-ietf-idr-bgp-open-policy; is RECOMMENDED to
not export routes which carry the NOPEER community.
Using NOPEER (instead of EC or LC) can be implemented on both bgp-open
capable implementations, but also through configuration in existing
deployments.
Reading RFC 3765 it seems appropriate to use this well-known community
'attribute' for this purpose. RFC 3765 is intended as a general purpose
route propagation restriction community. Bgp-open capable
implementations which use NOPEER in this way, are be compatible with
existing deployments of NOPEER.
Kind regards,
Job
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
