Re: [Idr] capability discovery - draft-ietf-idr-segment-routing-te-policy

Andrew,

I'm not sure this is a new problem. For example, if I am performing route
injection from some external source to an RR, I have no knowledge that the
downstream systems that I wish to advertise it to support the <AFI,SAFI>
that I'm injecting for. There must be some other means of discovery.

There are other problems with injecting SR-TE policies via an RR
infrastructure -- consider that even session failure is undetectable in
this scenario (the remote device might have gone away entirely, or not have
a session to the RR). To me, this is simply something that we need to
consider the deployment scenarios for (a good use for the "Operational
Considerations" of this draft), rather than adding protocol machinery in
BGP for. The mechanism to discover liveliness, and whether a policy is
programmed on the target node should be solved generically.

Cheers,
r.

On Fri, 20 Jul 2018 at 12:54 Stone, Andrew (Nokia - CA/Ottawa) <
andrew.stone@nokia.com> wrote:

> Hi all,
>
>
>
> Comment raised in IDR meeting regarding
> draft-ietf-idr-segment-routing-te-policy:
>
>
>
> Assuming an architecture deployment where a controller is peered to a RR
> supporting address families bgp-ls and sr-te-policies, how does the
> controller know which downstream routers in the network support BGP
> advertised SR-TE Policies? as this information (peer session address
> families) is being masked by the RR? For example, if the controller wanted
> to install a BSID on a transient node in the middle of the network, how
> will the controller know that:
>
>
>
> 1) node in network is currently talking BGP
>
> 2) node supports sr-te-policy address family
>
>
>
> Comparatively to PCEP, the PCEP session and its capability TLVs informs
> the controller of this.
>
>
>
> Advertising SR-TE policy via BGP needs a similar ability or a description
> on how best to address this.
>
>
>
> Some suggestions could include:
>
>
>
>    - perhaps advertising capability inside of BGP-LS
>       - But this means router needs to talk BGP-LS or have to relay it
>       through IGP to reach the BGP-LS speaker, similar to
>       draft-ietf-idr-bgp-ls-segment-routing-msd and
>       draft-ietf-isis-segment-routing-msd
>    - Transient downstream router advertises the capability into using
>    same SAFI as sr-te-policy but a different NLRI with a target of one, many
>    or all controllers
>    - external learning such as via BMP, netconf, statically defined on
>    controller… etc?
>
>
>
> Thoughts?
>
>
>
> Thanks
>
> Andrew
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>