Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Ketan Talaulikar <[e-mail]>]

Hi Jeff,

I agree with your views and to elaborate further:

1) The BGP-LS is a product of the IDR WG and hence the base is what the IDR
WG should be mostly focused on. This includes any improvements or fixes to
the base specification. Has there been any discussion in this regard on
this thread? If so, please point me to them and I can start separate
discussion threads on those topics. As many WG members have stated, BGP-LS
is widely implemented and deployments are only going up.

2) Most of the BGP-LS extensions are triggered by newer IGP extensions
(ideally driven by use cases that benefit from getting them into BGP-LS).
These are better handled by the LSR WG with cross-posting notices to the
IDR WG. In fact, such extensions are better added to the corresponding LSR
documents. I believe such an agreement was reached a year or two ago -
perhaps it is time to just enforce this and not accept such BGP-LS
documents for IDR adoption?

3) There are certain BGP-LS extensions that are not associated with IGP
extensions and I guess those would need to be handled in the IDR WG.

Coming to alternate proposals to provide the functionality delivered by
BGP-LS, I would think that RTGWG would be a good place to start.

Thanks,
Ketan


On Wed, Jun 22, 2022 at 5:11 PM Jeffrey Haas <[e-mail]> wrote:

> Robert,
>
>
> On Jun 22, 2022, at 5:05 AM, Robert Raszuk <[e-mail]> wrote:
>
> Hi Jeff,
>
> Again, speaking to the general case... why should it ever be constrained?
>> If the feature exists in the IGP, being able to represent it in BGP-LS is
>> probably reasonable.
>>
>
> Is there any technical reason to send point to point information over a
> point 2 multipoint (aka spray) protocol ?
>
> Is there any benefit for BGP to take that load on its shoulders ?
>
> Is this done purely for convinvence of reusing established by BGP TCP
> session ? IMHO poor justification.
>
>
> Is there any particular reason you're contorting yourself to try to
> justify not putting link state information into the BGP-link state protocol
> extension?
>
> You might not like BGP-LS.  (There many things to not like in it.)  But we
> have it.
>
>
> Are you proposing to bend IDR WG rules and start allowing BGP
> protocol extensions without two shipping interoperable implementations and
> a documented implementation report ? Note that LSR WG does not have such a
> bar.
>
>
> In this case, I think I might be proposing that.
>
> The core BGP-LS mechanism is defined.  We already have cases where groups
> like BESS put stuff into BGP things without passing through similar gates,
> but typically through existing well defined extensions.  We don't require
> full gate procedures when someone creates a FCFS bgp extended community
> outside of IDR.
>
> And perhaps similarly we might not want to require every single link state
> extension already adopted and accepted by LSR to need more than IDR review
> before it's added to the BGP extension to carry their stuff.
>
> Where in the BGP protocol state machine do we have a rate limit to capping
> accepted data (aka churn) from OSPF or ISIS protocols ?
>
>
> I decline to re-open that entire line of discussion from the IDR archives
> for BGP-LS.  Feel free to beat up on the archive server yourself. :-)
>
> Note - I am asking you those questions targeting yourself in both roles -
> IDR WG member and IDR WG co-chair.
>
>
> The above answered wearing both hats.  But that's also why we have more
> the one chair - consensus among ourselves as well needs to be generated.
>
> I suspect this will be a topic for the next IDR chair chat.
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>