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

Hi Rob,

Thanks for the reply. Agreed, this is not a new problem for BGP, but I still think it’s an important shortcoming that should be addressed in some manner.

Agreed, understanding session liveliness is important and whether or not a given route was received (or will be received) should be solved generically. There are a number of options to make that happen, I think the important thing would be for SR-TE Policy draft to describe a recommended way in which that could be performed (whatever that mechanism suggestion may be).

Thanks!
Andrew

From: Rob Shakir <rjs@rob.sh>
Date: Saturday, July 28, 2018 at 11:15 PM
To: "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: 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<mailto: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<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr