Re: [Idr] Query on split of draft-ietf-idr-te-lsp-distribution

[Boris Hassanov <[e-mail]>]

 Hi Robert and all.
First of all, I am not the author or contributor of the draft, thus saying my personal opinion from a customer side. I agree with your position that BGP is not a universal dump truck.
In practice we have already defined BGP SR Policy SAFI for delivering SR Policy from controller towards edge routers (draft-ietf-idr-segment-routing-te-policy) and it is supported (with some nuances of course) by majority of vendors (more than support SR Policy over PCEP).
So if we use SR Policy over BGP distribution, there is a natural question - how can we get a state of that policy from PE on a controller? In case of PCEP it is quite easy due to enough messages for that.  But not in the case of BGP.
If we already use BGP-LS to signal LSDB to controller, why can't we use LS for signal the state of SR Policy?Yes, there will be more BGP-LS sessions on a controller side, but the amount of signalling should not be huge. So there  will be additional requirement for controller scalability and it  requires careful estimations. it is clear.
I see more problems not in the pushing BGP-LS on each PE for signaling SR Policy state but rather in poor support of that capability at the moment.
 I tested it only with one vendor (partial support) and another one probably may support it too.
So in multivendor case we have quite bad dilemma: very few vendors do support SR Policy over  PCEP (majority support BGP SR) but at the same time only minority of that majority do support signaling SR Policy state in BGP-lS.
What should a customer do in such case? 
Of course we can try to  follow RFC 1925 and move  the problem around , i.e. by developing some in-house verification mechanism, but is this a right approach? Not sure.
Thank you.
SY,Boris


    On Thursday, November 10, 2022 at 01:24:41 AM GMT+3, Robert Raszuk <[e-mail]> wrote:  
 
 Dear Authors and the WG,
I oppose splitting or honestly proceeding with this document. 
SR policy information is a completely new addition to BGP-LS from its original intention to carry a subset of IGP LSDB to a controller. Again BGP is not a universal dump truck. 
For one it requires enabling BGP-LS on *each* edge router which was never required before. All that was required was to enable BGP-LS on one or two (for redundancy) IGP speakers in an area. This proposal takes BGP-LS to a complete new levels. 
For the second SR policies are not coming out of the blue to the SR edge nodes. They are carefully configured by operators or computed by controllers or PCE type elements. So there is a completely different way to communicate them to collectors rather then taking the scenic path and first pushing them to the edges by one protocol (or set of protocols) then collecting them from the edges. 
Moreover it does not work where SR policies are enabled on compute edges not talking BGP-LS. 
Kind regards.Robert. 
On Mon, Nov 7, 2022 at 2:43 PM Ketan Talaulikar <[e-mail]> wrote:

Hello All,
We would like to check with the WG for split of the draft-ietf-idr-te-lsp-distribution into two WG drafts:1) Covering advertisement of SR Policy2) Covering advertisement of RSVP-TE and Local/Configured MPLS Xconnects
The reason being that we are aware of implementations for (1) that allow us to progress towards WGLC for that part. 
Also let us know if there are any implementations for (2).
Thanks,Ketan (on behalf of co-authors)
PS: This was presented in the IDR WG meeting today: https://datatracker.ietf.org/meeting/115/materials/slides-115-idr-01-bgp-ls-advertisement-for-te-policies
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr