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

[Robert Raszuk <[e-mail]>]

Hi Boris,

I really hope that we won't see SNMP counters info inside BGP-LS in
> upcoming time.
>

*Oh for all practical purposes that can be stuffed into a new separate SAFI
:). *

- -

Is there a SR Policy YANG model defined ? Should that not be the first
obvious thing ? Why all over IETF we are defining YANG models and we still
see some islands to pack things into BGP-LS instead ?

I am sitting here and clearly not seeing any consistency.

> 3) Extending the capabilities of existing SR Policy SAFI by adding
signaling there looks like an option for discussion.

I do think so. Hence mentioned. In fact we never try to encode the same
things in multiple places as maintaining it always gets out of sync leading
to inconsistencies.

Cheers,
Robert



> 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 scale
> 3) 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 Policy
> 2) 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
>
>