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

[Robert Raszuk <[e-mail]>]

All,

Sorry but I would like to express complete opposition to the unconditional
and uncapped accommodation of IGP carried data in BGP - specifically
BGP-LS.

The BGP-LS proposal started very lean ... we just need pieces of topology
sent to controllers from each area. And we promise we use separate BGP
infrastructure to accommodate the separation from any BGP routing data. So
the proposal was accepted.

However now we see a completely different scope being pushed into the
original apparatus with the justification you allowed for 1,2 & 3 so now
you guys have no choice and must allow for 4, 5, 6 --- infinity. Leave
alone that complete separation was only practical on the IETF slides.

So yes I am worried to see what is happening here just as I care about the
Interdomain Routing Protocol.

That uncontrolled push of any IGP extension to BGP is not a good thing.
Today we already see opaque data to topology information being sent.
Tomorrow we have Application Aware Networking which may likely require a
bunch of new IGP extensions. Right around the corner there are folks
pushing for MNA (MPLS Network Actions) with a bunch of new IGP extensions
to surface soon.

Is it wise to stuff it all into BGP tables and data structures just for
convenience that BGP is the only protocol which can establish TCP session
between two end points ?

Kind regards,
Robert












On Wed, Jun 22, 2022 at 3:15 PM Ketan Talaulikar <[e-mail]>
wrote:

> 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
>>
>