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

[Boris Hassanov <[e-mail]>]

 Hi Robert,
Thank you for the reply. I really hope that we won't see SNMP counters info inside BGP-LS in upcoming time.
Agree that here we got into a kind of gray area because we started to dilute traditional BGP routing with some other info such as SR Policy state. But it was done, I think, due to necessity to find some workaround for the problem.
Anyway I would prefer to see some variants of SR Policy monitoring/checking in RFC 9256, it sounds incomplete without it, IMO.. Hopefully there will be the updated version with several possible variants  based on a consensus. But we have that we have now.
Regarding those issues which you mentioned:1)  I meant the only one scenario when controller (PCE) sends SR Policy via BGP SR SAFI towards PEs, so there will be only single source of truth and there is an unidirectional way of distribution of SR Policies (PCE->PE) 2) Running one more SAFI (BGP SR) on each PE, ASBR definitely will require additional research and testing, no doubts, since this is about networking scale3) Extending the capabilities of existing SR Policy SAFI by adding signaling there looks like an option for discussion.   
I hope that Ketan or other authors can join this discussion and provide their point of view.
I  ( as a customer) just want to see a standardized approach to get SR Policy state when we use BGP SR Policy SAFi. Because current situation  is quite bad as I mentioned.
SY,Boris 
    On Monday, November 14, 2022 at 12:16:36 AM GMT+3, Robert Raszuk <[e-mail]> wrote:  
 
 Hi Boris,
I think you hit the nail on the head by stating that the proposed mechanism would be carrying "TE state" - be it SR TE or RSVP-TE ... 
IMO while carrying IGP topology information on a per area what BGP-LS was originally accepted for falls into a gray area between routing and network monitoring here "state" has not many common elements with routing. Even local SR BSID expansion is hardly something we should be sending in BGP from each ABR/ASBR. 
Soon we will be carrying SNMP and telemetry with BGP from each node in the network just because it is easy to create a BGP session. 
Here I am observing two major issues: 
A) policy which is sent by any means to a node X can in the same time be also sent to controller
B) the BGP-LS requirement to be enabled and run in each edge node/abr/asbr was never a standardized requirement before. 
And last but important - we already have SAFI 73 to propagate SR policy to nodes. Tell me why we need to redo all of this into BGP-LS instead of using the same code and encoding by sending SAFI 73 from the node (just in case there are some local policy decisions like BDIS expansion) ? 
If authors are talking about splitting the document it seems that SR part can squerly fit SAFI 73. If not, perhaps draft-ietf-idr-segment-routing-te-policy can be adjusted to accommodate it. 
But better start defining non BGP based network monitoring solution. 
Thx a lot,Robert


On Sun, Nov 13, 2022 at 9:46 PM Boris Hassanov <[e-mail]> wrote:

 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